Loan Origination System Architecture: Decision Engines, Document Intake, Policy Rules and Audit Trails (2026)

Systems architecture analysis only. This article describes software design patterns and is not legal, compliance, credit or financial advice.

A loan decision looks like a single event to the applicant: submit, wait, approved or declined. Inside the lender it is a long-running transaction that touches identity vendors, credit bureaus, income documents, a policy engine, sometimes a machine learning model, a pricing table, a contract generator and a ledger. Every one of those hops can fail, return stale data, or change its answer when you ask twice. Get the seams wrong and you ship duplicate loans, unexplainable declines and audit findings that cannot be reproduced.

Loan origination system architecture matters more in 2026 than it did five years ago because the decision itself is now assembled from many components: deterministic policy, statistical scorecards, document extraction models and, increasingly, language-model assistants for back-office review. Regulators still expect one coherent, explainable, reproducible outcome per application.

This article gives you a reference design: the pipeline stages, where rules and models belong, how document intake should be isolated, how to make every decision replayable, and which failure modes to design against first.

What this covers: the origination pipeline and its state machine, the decision engine and its policy layer, document intake, adverse action and explainability, idempotency and audit design, failure modes, and a practical build checklist.

Context and Background

A loan origination system (LOS) is the software that carries an application from first contact to a funded, boarded loan. It is distinct from the loan servicing system, which owns the account after funding: payments, statements, delinquency and collections. In the older bank stack the LOS was a monolith bought from a vendor, with a rules module bolted on. In the current stack it is usually a set of services around a workflow core, and the boundary with servicing is a deliberate, contract-driven handoff.

Three forces shaped today’s design. First, digital channels removed the loan officer as the integration layer. When a human re-keyed data, inconsistent inputs were caught by eye; with an API-first flow, the system must validate everything itself. Second, lenders now blend sources. A single consumer decision may combine bureau data, bank-account transaction data from an open banking aggregator, payroll data and device signals. Each source has its own latency, cost per call and failure profile. Third, the supervisory expectation around models and automated decisions hardened. In the United States, the Federal Reserve and OCC model risk guidance, SR 11-7, defines model risk as “the potential for adverse consequences from decisions based on incorrect or misused model outputs and reports”, and expects independent validation, ongoing monitoring and an inventory of models in use. The Federal Reserve’s SR 11-7 letter remains the reference text most bank examiners start from, and its logic applies to a score embedded in a LOS exactly as it applies to a stand-alone model.

The practical consequence is that a LOS is no longer judged by how fast it moves an application, but by whether it can answer three questions months later: what did the system know at decision time, which version of policy and models applied, and why did the outcome come out that way. Everything in this article is organized around keeping those three answers cheap.

This post deliberately takes the plumbing view. For the modelling side of underwriting, see our deep dive on credit scoring and underwriting ML with gradient boosting, scorecards and adverse action explainability. For the real-time, point-of-sale variant of the problem, see credit decisioning architecture for BNPL underwriting engines. Here we focus on the platform that hosts those decisions.

Who owns what

A useful framing is to separate four planes. The experience plane is the application front end and partner APIs. The orchestration plane is the workflow engine that sequences steps and owns state. The decision plane holds policy rules, scorecards, pricing and exception logic. The evidence plane is the append-only record of inputs, outputs and versions. Most LOS failures come from letting one plane leak into another: business rules hard-coded in the workflow, workflow state kept only in the decision engine, or evidence reconstructed from mutable tables after the fact.

Reference Architecture: The Origination Pipeline

The core of a LOS is a state machine with durable state, side-effect-free decision steps, and explicit handoffs. An application moves through intake, identity and KYC, data aggregation, decisioning, offer and acceptance, contracting, funding and servicing handoff. Each stage is a bounded service that consumes an immutable snapshot and emits an event, so any stage can be retried, replayed or audited without touching the others.

Figure 1: Reference loan origination system architecture, with the workflow core separating stages and an append-only evidence store beneath them.

The diagram shows the workflow core calling each stage as a service while every stage writes to a shared, append-only evidence store. The decision engine is a pure function over a frozen input bundle; it does not call vendors itself. That single design choice, fetch first and decide second, is what makes the system replayable.

Stage 1: Application and intake

The application stage captures what the applicant says, and just as importantly, records it as stated. Store the submitted values verbatim with a timestamp and the form version, never overwriting them when later stages derive corrected values. Income as stated and income as verified are two different facts, and both feed the decision. Keep the application a structured document with a schema version, because schema drift across product lines is a quiet source of mapping bugs.

Intake must also be idempotent. Mobile clients retry, users double-tap, partners resend webhooks. Give each application an externally supplied idempotency key and a server-generated application identifier, and make creation a get-or-create operation. The design principles carry over directly from payments; our guide on payment API idempotency keys and double-charge prevention covers the key-scoping and request-fingerprint details that apply here too.

Stage 2: Identity, KYC and screening

Know-your-customer checks gate everything that follows, because spending money on bureau pulls for a synthetic identity is waste, and in some cases a legal exposure. Identity verification, sanctions and watchlist screening, and fraud scoring usually run as parallel calls that merge into a single identity assessment. The assessment should be a structured result with a disposition (pass, refer, fail), reason codes and the vendor reference IDs, not a boolean.

For lenders that keep the relationship alive after onboarding, the origination KYC result is the seed of an ongoing risk profile rather than a one-off check. Our write-up on perpetual KYC architecture and continuous risk shows how that handoff works. A practical rule: the LOS owns the point-in-time decision, and the customer risk platform owns the evolving view.

Stage 3: Data aggregation

This stage pulls the evidence the policy needs: credit bureau reports, bank-transaction data, employment and income verification, property or vehicle data for secured loans, and internal data such as prior relationship history. It is the most failure-prone stage because it is the most external. Design it as a set of independent connectors that each return a normalized, versioned data object plus provenance metadata: source, timestamp, request ID, and the permissible purpose or consent reference under which it was fetched.

The output of this stage is the decision input bundle: a single immutable document containing every value the decision may use. Once the bundle is sealed with a content hash, the decision plane reads only from it. That is the seam that gives you reproducibility, and Figure 2 later shows how it is used.

Stage 4: Decisioning

Decisioning evaluates the sealed bundle against policy, scorecards and pricing, and returns a structured decision: approve, decline, refer to manual review, or counteroffer, with reason codes, terms, and the identifiers of every rule set and model that participated. We examine this in detail in the next section.

Stage 5: Offer, acceptance and contracting

An approval is not yet a loan. The offer stage renders terms, discloses what the jurisdiction requires, and captures acceptance with an auditable e-signature trail. Terms need an expiry, because the bundle’s data ages: bureau data and income are valid for a bounded window, and a late acceptance should trigger a re-check or a new decision rather than silently funding on stale evidence. Contract generation must be deterministic from the stored offer and template version, so you can regenerate the exact document later.

Stage 6: Funding and servicing handoff

Funding is where the LOS touches money movement, and it should be treated as a distributed transaction with compensations. Disbursement, ledger entries, lien filing or title steps for secured credit, and boarding onto the servicing system all need to either complete or unwind. The saga pattern fits this: each step has a compensating action, and the orchestrator tracks progress durably. See our comparison of saga orchestration versus choreography and compensating transactions for the trade-offs. Once boarded, the servicing system becomes the system of record for the account, and the LOS keeps the origination file as an immutable historical record.

Orchestration: durable workflow, not a status column

Many homegrown systems model the pipeline as a status field updated by cron jobs and callbacks. That works until a vendor times out mid-stage, a worker crashes after sending a request but before recording the response, or two callbacks arrive out of order. A durable workflow engine solves this by persisting every step’s progress and replaying deterministic workflow code after failure. Our Temporal durable workflow tutorial walks through that model. Whatever engine you choose, require three properties: durable timers (offer expiry, document chase reminders), signals for external events (document uploaded, applicant accepted), and versioned workflow definitions, so in-flight applications finish on the logic they started under.

The Decision Engine: Policy Rules, Scorecards and Strategy

A lending decision engine separates three layers that are often tangled: hard policy (knock-out rules that must hold), statistical risk (a scorecard or model producing a probability or score), and strategy (cutoffs, pricing and limits derived from risk and business goals). Keeping them as separate, independently versioned artifacts lets risk teams change a cutoff without redeploying a model, and lets validators review each layer on its own terms.

Figure 2: Inside the lending decision engine: a sealed input bundle flows through policy knockouts, a score, strategy and pricing, and emits a decision record with versions.

The figure shows a strictly one-way flow. Nothing in the engine reaches out to the network; every value arrives in the bundle. The output is not just “approve” but a decision record naming the policy version, model version, strategy version and the exact bundle hash, which is what lets you re-run the decision later and get the same answer.

Layer 1: The credit policy rules engine

A credit policy rules engine encodes the lender’s written credit policy: minimum age, residency and identity requirements, maximum debt-to-income, loan-to-value caps, bankruptcy and delinquency look-backs, product-specific eligibility, and fraud or sanctions overrides. These are deterministic, human-authored, and reviewed by credit risk and compliance. Good engines express them as data (decision tables, rule sets in a DSL, or a standard such as the OMG’s Decision Model and Notation, DMN) rather than as code buried in services.

Three engineering properties matter more than the choice of product. First, rule evaluation must be total and traceable: for every rule, the engine records fired, not fired, or not evaluable because data was missing. A “not evaluable” outcome is a distinct state, because treating missing data as a pass or as a fail silently changes policy. Second, rules are versioned and effective-dated: a rule set has an identifier, an approval record and an effective window, and the decision record stores which version ran. Third, changes follow a promotion path: author, peer review, backtest against a historical population, shadow run in production, then activate. That path is the control that keeps a one-character typo in a threshold from declining a day’s applicants.

Do not confuse the rules engine with the workflow engine. Workflow decides what happens next in the process; the rules engine decides what the answer is. If your approval thresholds live inside workflow definitions, a policy change becomes a workflow migration, and in-flight applications may be decided under mixed logic.

Layer 2: Scorecards and machine learning models

Statistical risk models turn the bundle into a score or a probability of default. Traditional logistic-regression scorecards remain common for good reasons: they are monotonic, stable, and easy to turn into reason codes because each characteristic contributes additive points. Gradient-boosted trees and other machine learning models can improve rank-ordering power, particularly with rich transaction data, but they add explanation, stability and governance burden. We cover that trade-off in the credit scoring piece linked above, so here we only note the platform requirements.

A model in a LOS should be deployed as a versioned artifact behind a stable interface that takes a feature vector and returns a score plus ranked contributing factors. The feature computation must be shared between training and serving, or at least tested for parity, because training-serving skew is a classic cause of a model that validates well and performs poorly. Pin the feature definitions into the bundle schema so a change in how “months since last delinquency” is derived becomes a visible schema version change.

Treat any model as subject to the validation expectations in SR 11-7: conceptual soundness review, ongoing monitoring against benchmarks, and outcomes analysis against realized performance. The platform’s job is to make that cheap by logging inputs, scores and later outcomes in a joinable form.

Layer 3: Strategy, pricing and exceptions

Strategy converts risk into action. A score band maps to approve, refer or decline; a band plus loan purpose maps to limit and rate; policy exceptions route to an underwriter. Keep strategy as its own versioned artifact, usually a decision table indexed by score band, product and segment. Business teams tune it often, which is exactly why it should not live inside the model.

Referral to manual review deserves first-class design, not a trapdoor. A referred case should arrive in an underwriter workbench with the bundle, the fired rules, the score and the reason codes already assembled, and the underwriter’s override should itself be a structured, attributed decision with a mandatory reason from a controlled list. Override rates are one of the most informative operational metrics a lender has: a rising override rate on one rule often means the rule is miscalibrated. Capture who overrode, under what authority limit, and what the system would have decided.

Explanations as a by-product of the pipeline

The cheapest time to produce an explanation is at decision time. The engine should emit reason codes in a standard internal taxonomy mapped to customer-facing language, ranked by contribution. For scorecards this is the points shortfall versus a reference; for tree models it is typically an attribution method such as Shapley-value-based explanations, which approximate the model’s behavior rather than reveal a literal rule. That distinction matters legally, as the next section shows.

Document Intake and Verification

Loan files run on documents: pay stubs, tax returns, bank statements, bills of sale, title records, incorporation papers for small-business credit. Document intake is the stage most likely to turn a fast pipeline into a slow one, and it is where unstructured data enters a system that otherwise wants strict schemas. The design goal is to convert every document into structured claims with provenance, confidence and a verification status, while keeping the raw file immutable.

Figure 3: Document intake for a loan origination system: classification, extraction, cross-validation and fraud checks produce structured claims with confidence.

The diagram describes a funnel with two exits: high-confidence, internally consistent documents flow straight into the input bundle as verified claims, and anything uncertain goes to a human queue. The queue is not a failure of automation; it is the control that keeps extraction errors out of credit decisions.

Ingest, classify, extract

Uploads land in object storage with a content hash, a malware scan and a quarantine step before anything parses them. Documents arrive as phone photos, scans, native PDFs and screenshots, so classification (is this a pay stub, a bank statement, a driver’s licence?) comes first, then extraction tuned to the type. Extraction technology has shifted: classic OCR plus template or layout models still dominate high-volume, fixed-format documents, while vision-language models handle variable layouts better but need guardrails against plausible-looking mistakes. Our comparison of document AI OCR versus vision-language models covers pipeline choices in depth.

Whatever extracts the fields, treat output as a claim: field name, value, source document, page and bounding region, extractor version, and a confidence score. Never let extraction write directly into the verified-income field. Claims are promoted to verified facts only after validation.

Validate, cross-check and detect tampering

Validation is where intake earns its keep. Arithmetic checks catch extraction errors: do the pay-stub year-to-date figures reconcile with the period figures, do the bank statement’s opening balance, transactions and closing balance add up? Cross-document checks catch inconsistency: does the employer name on the stub match the employment verification, does the name on the statement match the applicant, do the deposits in the bank data match the stated pay cadence? Document-forensics checks look for edited PDFs, mismatched fonts or metadata, and image reuse across applications.

Direct-source verification is preferable to document parsing wherever available. Payroll connections, bank-data aggregation and tax-transcript services return structured data from the originating system, which removes both extraction error and much of the forgery surface. The design implication: model the verification method as a field on every claim (document-extracted, direct-source, manually verified), because policy may treat them differently, for example requiring a larger buffer when income is only document-derived.

Privacy, retention and regional rules

Loan documents are dense with personal data, so isolate the intake zone: separate storage, tight access policies, encryption with per-tenant keys, and short-lived signed URLs for reviewer access. Retention is driven by regulation and product. In the US, Regulation B (the Equal Credit Opportunity Act rule) requires creditors to retain application records and adverse action notices for a prescribed period, commonly cited as 25 months for consumer credit. We could not re-fetch the rule text for this article, so confirm the period and any longer product-specific or state rule against the current 12 CFR 1002.12 and your counsel’s guidance. Retention schedules should be configured data, attached to each object, not an assumption in code.

Adverse Action, Explainability and Fair Lending Hooks

Every decline, and many counteroffers, create a notice obligation. The architecture question is how to produce a correct notice from a decision that may involve rules, a score and a model, without a human reconstructing the reasons. The US framework is used here as the worked example; other jurisdictions have different rules (the EU, for instance, layers GDPR automated-decision provisions and consumer-credit law), so treat the structure as portable and the specifics as local.

What the US rules require, in system terms

Under the Equal Credit Opportunity Act and Regulation B, a creditor must notify an applicant of action taken within 30 days of receiving a completed application, and an adverse action notice must include a statement of action taken, the creditor’s identity, the ECOA anti-discrimination notice, the name of the administering federal agency, and either a statement of specific reasons or a disclosure of the right to request them. The text is at 12 CFR 1002.9 on the CFPB site. Where the decision relied on a consumer report, the Fair Credit Reporting Act adds its own disclosures, which commonly include the credit score used, key factors, and the reporting agency’s contact details; verify the exact current content with counsel.

The reasons rule is the one with architectural weight. Regulation B requires reasons to be specific and to indicate the principal reasons for the action, and the official commentary says they must relate to and accurately describe the factors actually considered or scored. The CFPB’s Circular 2022-03 states that a creditor using a complex algorithm cannot excuse a vague notice by pointing to the model’s opacity, and notes that post-hoc explanation methods approximate a model, so a creditor needs to be able to validate how accurate those approximations are. A companion circular in September 2023 addressed checklist-style reason lists. Be aware that in May 2025 the CFPB announced withdrawal of 67 guidance documents, so check the current status of any circular before citing it in policy; the underlying regulation text does not depend on the circular.

From decision record to notice

The robust pattern is to treat the notice as a pure function of the decision record. The engine emits ranked internal reason codes. A reason catalogue, owned by compliance and versioned like any other policy artifact, maps each internal code to approved customer-facing language, and a rendering service composes the notice from the catalogue version, the decision record and the jurisdiction template. Because every input is stored, you can regenerate the exact notice that was sent.

Three design rules prevent the common failures. First, reasons must come from what the decision actually used. If a gradient-boosted model drove a decline, the notice reasons must be derived from that model’s attributions, not from a nearest-matching entry on a sample checklist. Second, no reason may rest on a feature that the system cannot show was used, which argues for a feature-level lineage record in every decision. Third, counteroffers and partial approvals are decisions too and need the same record, notice logic and timers.

Timers deserve engineering attention. The notification clock starts at a completed application, so “completed” must be an explicit, stored state transition with a timestamp, not an inference. Incomplete-application notices have their own rules. Put the deadlines into the workflow as durable timers with escalation, and report on at-risk applications, not only breaches.

Fair lending hooks

A LOS cannot decide whether a model is fair, but it can make fairness analysis feasible. Store protected-class information only where the law permits and under separate access control, or store the proxy inputs required for approved testing methods. Log every policy and model version so a disparate-impact analysis can attribute outcome differences to specific rules. Keep a challenger framework: run alternate policies or models in shadow mode on live traffic, storing their would-have-been decisions, so a less discriminatory alternative can be evaluated with real data. These are capabilities, not conclusions; the analysis belongs to compliance and legal teams.

Idempotency, Audit Trails and Versioned Policy

The evidence plane is the part of the architecture that turns “we think the system did X” into “we can prove it did X”. It rests on three mechanisms: idempotent commands, an append-only event log, and content-addressed, versioned artifacts.

Idempotency at every boundary

Idempotency is needed at four boundaries: inbound API calls from channels and partners, outbound vendor calls, internal workflow activities, and funding instructions. Inbound calls use a client-supplied key scoped to the tenant and operation, plus a fingerprint of the request body so a reused key with different content is rejected rather than silently accepted. Outbound vendor calls need a deterministic request ID derived from the application and step, so a retry after a timeout does not buy a second, billable bureau pull or, worse, a second hard inquiry on the applicant’s file. Funding instructions need the strictest treatment: a disbursement ID derived from the loan, a uniqueness constraint in the ledger, and reconciliation against the payment rail’s own reference.

The corollary is that retries are safe only when the operation is a pure read or an idempotent write. Anything else must be modeled as a saga step with a compensating action. Where your workflow engine retries activities automatically, review each activity for this property explicitly.

Event-sourced evidence

Record every state change as an immutable event: application received, claim extracted, claim verified, bundle sealed, decision made, offer accepted, loan funded. Current state is a projection of the events. This gives you the full timeline of every file, supports replay when a bug is found, and makes audit queries (“show every application decided under rule set 14 between these dates”) straightforward. Our article on event sourcing and bitemporal data for financial audit trails explains why a bitemporal model, tracking both when something was true and when you learned it, matters when corrections arrive late.

Two details separate a real audit log from a pile of rows. The log must be tamper-evident, for example by chaining event hashes or anchoring periodic digests to write-once storage, because an attacker or a well-meaning engineer with database access can otherwise rewrite history. And it must be complete about negative space: record what was not done and why, such as a bureau call that was skipped because a knock-out rule fired first.

Versioned policy and model artifacts

Every artifact that can change an outcome gets an immutable identifier derived from its content: rule sets, decision tables, scorecards and model binaries, feature definitions, reason catalogues, offer templates and notice templates. The decision record stores the whole set of identifiers. With that, “replay this decision” becomes a deterministic operation: load the sealed bundle by hash, load each artifact by identifier, run the engine, compare the output with the stored result. A mismatch signals non-determinism, a hidden dependency such as a clock or random seed, or a bug, all of which you want to find before an examiner does.

Deployment of those artifacts should be a controlled release with approvals, not a file copy. Effective dating handles the transition: an application decided at 11:59 on the last day of a rule set’s life uses that rule set even if it finishes processing after midnight. Decide explicitly which timestamp governs, usually the moment the bundle is sealed, and record it.

Failure Modes, Capacity and Cost

Figure 4: Common loan origination system failure modes paired with the control that contains each.

Figure 4 pairs the failures that recur across lenders with the architectural control that contains each one. The sections below take them in turn.

Vendor failures and degraded modes

Bureaus, identity vendors and aggregators time out, rate-limit and return partial data. Decide in advance, per source, what the degraded behavior is, and encode it in policy rather than in an exception handler. For a non-critical enrichment source, the decision may proceed without it using a different strategy branch; for a bureau report on a regulated product, the application may have to wait or be referred. Circuit breakers, per-vendor timeouts and a fallback vendor are standard, but the fallback changes data semantics, so the decision record must show which vendor actually supplied the data. Use hedged but idempotent requests carefully: duplicated bureau inquiries can have consumer-facing consequences.

Stale and inconsistent data

Data in the bundle ages. A bank-transaction pull from last week can hide a new overdraft; a bureau report is a snapshot. Put a freshness policy on each source (maximum age at decision, at offer acceptance, and at funding) and re-verify at the later gates where the risk justifies the cost. Inconsistency between sources, such as stated income that conflicts with deposits, should produce a structured conflict flag the policy can act on, not silently pick a winner.

Duplicate funding and partial failure

The worst operational incident in lending is paying out twice, or paying out while the loan fails to board. Defend with idempotent disbursement IDs, a two-phase funding saga with compensations, and an end-of-day reconciliation between LOS funded loans, the ledger and the payment rail. Make funding a separate, tightly permissioned service so that a bug in the offer stage cannot trigger it. For the ledger design behind this, see our notes on double-entry ledger database architecture.

Policy drift and silent regressions

Policy drift happens when production behavior diverges from the written credit policy: a hotfix to a threshold, a rule disabled during an incident and never re-enabled, a feature definition that changed in the data pipeline. Controls are monitoring and governance rather than code: track approval rates, referral rates and override rates by rule and segment, alarm on shifts, and run a nightly job that replays a sample of the day’s decisions against the declared artifact versions. Population stability index monitoring on model inputs and scores is the standard way to detect that applicants have changed relative to the training population.

Capacity and cost

Origination is bursty and cost-asymmetric. Decision compute is cheap; external data is where the money goes, with bureau pulls, income verification and fraud checks often costing more per application than all internal compute. Sequence the pipeline so inexpensive knock-outs run before costly pulls (an underage applicant should never reach the bureau), cache within the freshness window, and measure cost per decided application and cost per funded loan as first-class metrics. Latency budgets differ by product: a point-of-sale decision may need seconds, a mortgage takes days, and the same platform should support both by treating the synchronous path as a time-boxed slice of the same workflow rather than a separate system.

Practical Recommendations

Build around the sealed input bundle. If you do nothing else, separate data gathering from decisioning, hash the bundle, and make the engine a pure function over it. Replayability, explainability, shadow testing and incident forensics all become tractable once that seam exists.

Keep four things independently versioned: rule sets, models, strategy tables and reason catalogues. Treat the combination of identifiers as part of the decision. Put policy changes through authoring, review, backtest, shadow and activation, and make rollback a standard operation.

Choose a durable workflow engine over status flags and cron. Use durable timers for offer expiry and notification deadlines, and signals for external events. Version workflow definitions so in-flight applications finish on the logic they began with.

Design for the humans in the loop. Underwriters need a workbench that assembles the file, and overrides must be structured, attributed and measured. Document reviewers need confidence-ranked queues, not a pile of PDFs.

Make idempotency a platform feature: key scoping, request fingerprints and deterministic outbound IDs, tested with chaos exercises that kill workers mid-step.

A short checklist to review before go-live:

Every decision stores bundle hash, rule, model, strategy and catalogue versions.
A nightly job replays sampled decisions and alerts on mismatch.
Not-evaluable rule states are explicit, and missing data never defaults to pass.
Adverse action notices are generated from the stored decision record and catalogue version.
Notification deadlines run as durable timers with escalation.
Funding has a unique disbursement ID, a saga with compensations and daily reconciliation.
The audit log is append-only and tamper-evident, with retention configured per object.
Vendor degraded modes are written into policy and visible in the decision record.
Shadow and challenger decisions are stored for model governance and fairness testing.

Frequently Asked Questions

What is a loan origination system?

A loan origination system is the software that takes a credit application from first contact through verification, decisioning, offer, contracting and funding, then hands the booked loan to a servicing platform. It orchestrates identity checks, data pulls, policy and score evaluation, and document collection, and it stores the evidence behind each decision. Modern LOS platforms are usually composed of services around a workflow engine and a decision engine rather than a single monolith.

What is the difference between a loan origination system and a loan servicing system?

The origination system owns the life of an application up to funding: intake, underwriting, offer and contract. The servicing system owns the account afterward: payment processing, statements, escrow, delinquency management, collections and payoff. The handoff is a defined contract, typically the final loan terms, schedule and documents, and the LOS keeps the origination file as an immutable historical record that servicing and auditors can reference.

Should credit policy live in a rules engine or in code?

Policy that credit-risk teams must review and change frequently belongs in a rules engine or decision tables with versioning, effective dates, approval records and backtesting, because it can then change without a software release and can be audited in isolation. Code is appropriate for the engine itself and for integrations. The key property is traceability: each rule’s fired, not-fired or not-evaluable status must be recorded per decision.

How do you make an automated lending decision explainable?

Capture the exact inputs in a sealed bundle, record every rule, model and strategy version used, and emit ranked reason codes at decision time. Scorecards give additive reason points; tree-based models need attribution methods that approximate behavior and should be validated for accuracy. Map internal codes to compliance-approved customer language through a versioned catalogue, so the notice is generated from the stored decision rather than reconstructed later.

How do you prevent duplicate loans or double disbursement?

Use idempotency at every boundary: a client-supplied key and request fingerprint on application creation, deterministic request IDs on vendor calls, and a unique disbursement ID derived from the loan with a uniqueness constraint in the ledger. Run funding as a saga with compensations in a separate permissioned service, and reconcile funded loans against the ledger and payment rail daily to catch anything that slipped through.

Can a LOS use machine learning and still satisfy adverse action requirements?

In the US, the CFPB’s Circular 2022-03 states that creditors using complex algorithms must still give specific, accurate reasons, and that opacity is not a defense. Practically this means choosing models whose reasons can be derived and validated, deriving reasons from what the model actually used, and testing explanation accuracy. Check the current status of the circular and consult counsel, since guidance changes and rules differ by jurisdiction.