Loan Origination System

Application to funded loan

Design the system that takes a consumer loan from application to funding, where steps wait for days, every vendor call is safe to retry, and every decision can be explained and replayed.

Overview

A loan origination system (LOS) is everything a lender runs between 'I want to borrow $12,000' and 'the money is in your account'. The applicant fills in a form and uploads documents; the lender verifies who they are, pulls their credit report, decides whether to lend and at what rate, sends an offer, collects an electronic signature, sends the money, and hands the new loan to the servicing system that collects payments for the next few years.

The traffic is small: ten thousand applications a day is well under one request a second on average. What makes it hard is time and correctness. One application can wait seconds for a credit bureau, hours for an underwriter, and days for the applicant to upload a pay stub or sign. Every outside call can time out after it has already done the work (and billed you). And because lending is regulated, every decision must be explainable to the applicant and reproducible later, with the exact data and rules used at the time.

So the design centers on three ideas: model the application as a durable workflow (a state machine whose progress survives crashes and can sleep for weeks), make every step an idempotent activity safe to retry, and store every decision as an append-only record with its inputs, rule version and reasons.

Questions to ask first

What kind of loans? — Unsecured consumer installment loans; mortgages out of scope
Volume? — 10,000 applications a day, peak 5 times the average
How much is automated? — About 70% decided by the engine; the rest go to underwriters
Who are the outside parties? — An identity (KYC) vendor, a credit bureau, an e-sign vendor, a bank payment rail
How long can an application stay open? — An offer is valid for 30 days; incomplete applications get a deadline
Regulatory needs? — US: specific reasons on every adverse action, records kept, no discrimination on a prohibited basis

What you will be able to do

Model a loan application as a long-running workflow with explicit states and durable timers.
Call slow third parties (bureau, KYC, e-sign, payment rails) so that retries never double-pull, double-sign or double-fund.
Combine a rules engine, a score model and a manual review queue, and decide which applications go where.
Store decisions so they can be explained (adverse action reasons) and replayed exactly under the rule version used.
Protect applicants' personal data while still letting underwriters and auditors do their jobs.

Key concepts

Durable workflow
Application state machine
Durable timers
Idempotent activities
Rules engine and score model
Manual review queue
Versioned rule sets
Decision replay
Adverse action reasons
PII vault and tokens

Functional requirements

Start, save and resume an application; collect the applicant's details
Request and accept documents (pay stubs, bank statements, ID images); scan them before anyone opens them
Verify identity and pull a credit report
Decide automatically where the rules allow, otherwise route to an underwriter
Generate an offer (amount, rate, term) that expires
Collect an electronic signature on the agreement
Fund the loan once and hand it to servicing
Send the applicant notices: incomplete application, approval, adverse action with reasons

Non-functional requirements

No step runs twice with an outside effect: one bureau pull, one signature envelope, one disbursement per application step
An application survives any process crash and resumes where it stopped
Engine decisions in under 5 seconds at p95 when the vendors answer (a target we chose)
Every decision reproducible from stored inputs and the rule version
Personal data encrypted, tokenized outside the vault, and every read of it logged
99.9% availability for the applications API (a target we chose)

Interview questions

Why model the application as a workflow instead of a status column and cron jobs?
How do you avoid pulling credit twice or funding a loan twice?
How does the system decide which applications go to an underwriter?
An examiner asks why an applicant was declined eight months ago. What do you show?
What must an adverse action notice contain, and how does the design produce it?
Can you use a machine learning model for underwriting?
How do you handle documents safely?
How would you scale this?