Loan Origination Workstation with Rules

Project overview

We built a loan origination workstation for a lender offering personal, vehicle and small-business loans through branches. Officers capture applications, scan identity and income documents, and receive an immediate rules-based recommendation; credit analysts and managers review referred loans and approve within their limits.

The project covered discovery, UX, a .NET desktop client and services, a SQL Server database, the rules engine, scanner integration and branch roll-out. It is part of our fintech app development practice and shares audit patterns with our insurance portal project.

The client and the challenge

Applications were filled in on paper, photocopied and couriered to head office, where analysts re-keyed them and applied credit policy from a manual. Decisions were inconsistent between analysts, policy changes took weeks to reach branches, and incomplete files bounced back and forth. Branch officers had no visibility of where an application stood once it left the branch, so customers called repeatedly for updates and officers phoned head office on their behalf.

The lender wanted complete applications captured at the branch, consistent policy applied automatically, clear routing of exceptions to the right approver, and a defensible record of every decision — while some branches had unreliable connectivity.

Solution architecture & delivery

The .NET client walks the officer through applicant details, employment, income, existing obligations, collateral and the requested product, validating each step and blocking submission until mandatory documents are attached. Documents are scanned from branch scanners directly into the application, classified by type and compressed. If the connection drops, the draft and scans are held in encrypted local storage and submitted when it returns.

Credit policy is expressed as rules in a versioned rule set stored in SQL Server, edited by the credit team through an admin tool rather than by developers. Rules cover eligibility, affordability ratios, maximum amounts by product and collateral, and knock-out conditions. Each submission is evaluated against the rule set in force, producing approve, refer or decline with the list of rules that fired, and new rule versions are tested against a set of historical applications before they are published. Officers see the status of every application they submitted, from received and under review to approved with conditions or declined, together with the reasons shared by credit, so they can answer customer questions without calling head office.

Referred applications are routed to analysts by product and amount, and approval limits per role decide who can sign off. Analysts can request more documents or conditions, and the officer sees the request in the branch queue. Credit bureau checks are only run after the applicant's consent is recorded, and results are visible only to credit roles.

Every field change, rule outcome, override and approval is written to an audit log with the user and reason; overrides of a decline require a mandatory justification and a second approver. Once approved, loan agreements are generated for printing and signing, and the booked loan is sent to the core lending system over its API. Workstations update automatically through a managed channel.

Key features we built

• Guided application capture with validation and mandatory document checks
• Direct scanning of identity, income and collateral documents into the file
• Encrypted local drafts that submit when connectivity returns
• Versioned credit rules edited by the credit team, tested before publishing
• Approve, refer or decline outcomes with the rules that fired
• Referral routing by product and amount with role-based approval limits
• Consent capture before credit bureau checks, with restricted result visibility
• Audit log with justified, dual-approved overrides and agreement generation

How we delivered it

1. Discovery. Following applications from branch to decision, translating the credit manual into candidate rules with the credit team, and listing documents per product.
2. Rules design. Modelling the rule format and back-testing it against historical applications to confirm it reproduced intended policy.
3. Build. Two-week sprints on capture, scanning, rules, routing and core system integration, with automated tests for every rule and approval limit.
4. Branch pilot. Pilot at a few branches with analysts double-checking outcomes, then tuning rules and screens before wider roll-out.
5. Roll-out and support. Region-by-region deployment, officer training and ongoing support, with the rules team publishing policy changes independently.

Technology choices

• .NET — a single platform for the Windows workstation, scanner integration, rules evaluation and back-end services with strong typing and testing.
• SQL Server — transactional storage for applications, rule versions and audit logs, with the security and reporting a regulated lender expects.

Outcomes

• Applications arrive at credit complete, with documents attached, instead of being couriered and re-keyed
• Credit policy is applied the same way at every branch through the rules engine
• Policy changes reach branches when the credit team publishes a new rule version
• Referred loans go straight to an analyst with the authority to decide them
• Every decision and override has a recorded reason and approver

FAQ