This question evaluates architecture and systems engineering competencies related to building scalable, compliant financial platforms, including data modeling, API and event-driven workflow design, security, and regulatory integration.
##### Question
Design a scalable end-to-end loan application system for a small lending startup. Cover user loan-product selection, application intake, internal underwriting workflow, integration with external credit-history and bank-statement services, decisioning, and fund disbursement.
Quick Answer: This question evaluates architecture and systems engineering competencies related to building scalable, compliant financial platforms, including data modeling, API and event-driven workflow design, security, and regulatory integration.
You are a software engineer at a small lending startup. Design a scalable, compliant loan origination system (LOS) that takes an applicant from browsing loan products all the way through to funded money in their account.
The platform offers unsecured term loans to small businesses and consumers. A complete design should cover the full origination lifecycle:
User experience & product selection
— browse loan products (amount, term, APR ranges, eligibility hints); pre-qualification via a soft credit / cashflow pre-check with user consent; a multi-device, save-and-resume application.
Application intake
— capture applicant identity, business info, income/cashflow, purpose, and documents; KYC/CIP and AML/OFAC screening; consent management (credit-pull authorization, bank-data access); document upload and read-only bank-account linking via an aggregator.
Underwriting workflow (internal)
— orchestrate the slow steps (credit pull, bank-statement fetch, identity/fraud checks); a rule engine plus ML scoring; a manual-review queue with an analyst console; audit trail and reason codes.
External integrations
— credit bureau(s) for soft/hard pulls; bank-statement/cashflow aggregation (read-only); payment rails for disbursement (ACH/wire) with webhooks. Each vendor must be replaceable.
Decisioning & offer
— risk scoring and credit policy producing approve/deny/conditional; pricing, limit assignment, and an amortization schedule; ECOA-compliant adverse-action notices with specific reasons.
Funding / disbursement
— e-sign and KBA, vaulting of signed agreements; idempotent payouts, an internal ledger, and reconciliation; status tracking and notifications.
Your deliverable is to describe the architecture, a high-level data model, the critical APIs, the eventing/queueing model, the application's workflow states, failure handling, and how you would scale — including key trade-offs and assumptions. Provide at least one small numeric example for pricing/decisioning.
Constraints & Assumptions
Volume:
peak traffic of ~2,000 applications/day, with bursts to ~5 req/s. Auto-path decisions within
minutes
; funding within
hours
.
Scope:
unsecured term loans to small businesses and consumers; horizontal scalability and
vendor replaceability
are explicit goals.
Non-functional / compliance targets:
PII security (encryption in transit and at rest), key management, RBAC; idempotency, retries, and circuit breakers for vendor calls; observability, audit logs, data retention, and GDPR/CCPA deletion; feature flags and phased rollout.
Assume KYC, bank aggregation, e-sign, bureau access, and payment rails are available as third-party vendors; the orchestration, underwriting policy, analyst console, and ledger are built in-house.
Clarifying Questions to Ask Guidance
Borrower mix:
consumer, small-business, or both at launch? This changes the data captured (personal vs. business identity) and which bureau/data sources matter.
Regulatory perimeter:
US-only or multi-jurisdiction? Which regimes bind us (FCRA, ECOA, NACHA cutoffs, state usury/APR caps, GDPR/CCPA)? This drives consent, disclosures, and retention.
Decision SLA vs. completeness:
when a vendor is slow or a file is thin, do we prefer a fast automated decision or route to a human? What is the acceptable manual-review rate?
Buy vs. build boundary:
which components are bought vendor SDKs (KYC, aggregation, e-sign, rails) vs. built in-house (orchestration, policy, ledger, console)?
Out of scope:
are loan
servicing
(repayment collection, delinquency, charge-off), secondary-market sale, and corporate accounting beyond the disbursement ledger out of scope?
Funding mechanics:
ACH only, or wire too? Same-day vs. next-day ACH? Single disbursement or draws?
What a Strong Answer Covers Guidance
Right-sized scope:
explicitly notes this is a vendor-coordination, correctness, and compliance problem — not a QPS problem — and sizes the volume to justify that framing.
Architecture & service boundaries:
clear decomposition (product catalog, application/state, identity/KYC, bureau adapter, bank-data adapter, underwriting, decision/offer, e-sign, funding, ledger, notifications) with a stated reason for each boundary, and a
durable orchestrator
as the spine.
Application state machine:
explicit states and legal transitions from draft through funded/declined, with terminal states and where decisions/reason codes are recorded.
High-level data model:
core entities (applicant, application, consent, bureau report, bank link, features, decision, offer, agreement, disbursement, ledger, audit log) with
PII handling
(field-level/envelope encryption, token references, raw docs in encrypted object storage).
Critical APIs:
borrower, internal/staff, and HMAC-verified vendor webhooks; async (
202
) where vendor fan-out is involved.
Underwriting & pricing:
rules-then-ML, versioned policy/model, feature assembly, plus a concrete numeric example (amortization payment and an expected-loss / risk-based-pricing check).
Eventing, queues, idempotency:
domain events, dead-letter handling, and idempotency for both client mutations and money movement.
Failure handling:
vendor timeouts, thin-file fallback, delayed bank data, duplicate applications, fraud signals, missed/duplicate payout webhooks, stuck workflows — with a "fail safe, never to a payout" principle.
Security, privacy, compliance:
encryption, RBAC/ABAC, FCRA permissible purpose, ECOA adverse-action, OFAC/AML, retention with legal-hold carve-outs, and a tamper-evident audit trail.
Observability, scaling, rollout:
key business + system metrics, backpressure/concurrency control, model shadow mode, and phased launch.
Trade-offs:
durable workflow vs. event choreography; buy vs. build; rules vs. ML; strong consistency for state/money vs. eventual for analytics.
Follow-up Questions Guidance
How do you guarantee
exactly-once disbursement
end-to-end given client retries, workflow retries, and replayed payment webhooks? Walk through the layers of defense.
A bureau or bank-data vendor degrades (high latency / partial outage) for an hour. How does the system behave, and what is the borrower's experience?
How would you design the
audit trail
so a regulator can reconstruct exactly why any given application was approved or denied, and so the log is tamper-evident?
The ML model's predicted defaults start drifting from actuals after launch. How do you detect this, and how does shadow-mode rollout plus monitoring let you respond safely?
How do you reconcile
GDPR/CCPA deletion
with statutory financial-record retention requirements?