Self-Service Borrower Portals and Lending System Integration

Summary

We build self-service borrower portals and the integrations that connect them to lending systems of record. A portal of this kind lets an applicant complete and submit a loan application, upload supporting documents, sign disclosures electronically, track a decision, view balances and payment schedules, make one-off payments and set up automatic debit. On the other side it removes routine work from a lending team, provided it is genuinely integrated rather than acting as a form that emails somebody.

The Challenge

The portal must never become a second source of truth. Balances, schedules, payoff amounts and account status are computed by the loan management system, and a portal that recomputes any of them will eventually disagree with servicing in front of the borrower. Around that sit external dependencies with their own latency, failure modes and idempotency rules.

Payment handling is where correctness is most unforgiving. ACH transactions settle asynchronously and can be returned afterwards, so treating submission as payment is simply wrong. Consumer lending is heavily regulated, and the portal carries a share of the obligations, so compliance shapes the data model rather than decorating the interface. The mistakes seen most often are storing derived financial figures locally, treating payment submission as completion, hiding permissions in the interface instead of enforcing them server-side, and leaving reconciliation and returned-payment handling until last.

The Solution

A Presentation Layer Over the System of Record

The portal is treated as a presentation and workflow layer over the loan management system. Figures come from that system through its API, with the portal caching only what it needs for responsiveness and never independently computing a value servicing also computes. Where the lending core runs on .NET and Azure with an Angular front end, matching that stack for the portal reduces integration effort, shares identity and infrastructure, and concentrates operational knowledge in one place.

Integration Surface

• Payment gateways for card and ACH transactions, and bank account verification.
• Credit bureau and identity verification services.
• An electronic signature service, document storage, and email and SMS notification channels.
• Every call wrapped in timeouts, retries with idempotency keys and circuit breaking, with a defined borrower-facing behaviour when a dependency is down.

Payments and Money Movement

Payment state is modelled as pending, settled, returned and reversed rather than collapsing into a single success flag. Card payments require tokenisation and a flow that keeps card data out of application scope under PCI DSS, through hosted fields or a redirect. Automatic debit needs an authorisation record capturing amount, frequency and consent evidence, a cancellation path, and advance notification when a scheduled amount changes. Every money movement posts to the servicing system exactly once, with reconciliation run against the processor settlement file.

Compliance, Security and Accessibility

The regulatory surface includes identity verification and anti-money-laundering screening at onboarding, disclosure presentation and consent capture under electronic signature legislation, adverse action handling and record retention. Security follows from it: multi-factor authentication, strict session management, encryption in transit and at rest, least-privilege data access, and an immutable audit trail of every application event, document view, consent and payment. Accessibility is a legal exposure as well as a usability question, so WCAG conformance belongs in design rather than remediation.

Discovery and Design

Work opens with a lending consultant mapping business and technical requirements, the borrower population and its expectations, competing digital offerings, and the applicable regulatory framework, then turning that into a feature map and a permission model. An architect plans the integrations and designs for availability, scalability and secure data exchange before implementation, and interface design is validated on real devices. One decision is worth making deliberately: a responsive web portal usually serves a lending audience better than a native application, because it removes install friction and avoids duplicating regulated flows across two codebases.

What This Delivers

Applicants apply, sign and pay without a phone call, on whatever device they have open, and see a status that matches servicing. Lending staff stop rekeying applications and chasing documents. Payment states are honest, so returned transactions are handled as a normal path instead of a support incident. And every consent, disclosure and document view is recorded in a form that stands up to examination.

Technologies and Tools

Angular.js on the front end, .NET services on Azure, loan management system API integration, payment gateways for card and ACH, bank account verification, credit bureau and identity verification, an electronic signature service, document storage, email and SMS providers, and PCI DSS and WCAG conformance criteria.