What Is a Credit Decisioning Platform and How Does It Differ From an LOS?
A credit decisioning platform is the layer that turns borrower data into a credit outcome — it ingests data, runs analytics and rules, and returns approve, decline, refer or a set of terms. A loan origination system is the workflow and record layer around that decision: intake, stages, approvals, documents, booking. One decides; the other administers.
That is the short version, and it is not the whole problem. Five distinct product categories are sold under overlapping names, and most buying committees discover the boundaries after signing. This page defines each one. For the buying question — whether memo automation replaces your LOS — see does credit memo automation replace your LOS. What sits on the YuSight side of the line is narrow and checkable: a 28-minute sample Credit Assessment Memo carrying 142 citations, with a full audit trail of who changed what.
Key facts
- Regulators now draw a line the vendor market does not. Under SR 26-2 / OCC Bulletin 2026-13 (17 April 2026), a "model" is "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates" — and the guidance explicitly excludes "deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use" (Federal Reserve SR 26-2; OCC). Your rules engine and your scorecard are not the same object under supervision.
- The same guidance puts generative and agentic AI outside its perimeter entirely: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance."
- FICO's own glossary defines a decision platform as tooling for "data ingestion and wrangling, predictive analytics, rules authoring, optimization, service orchestration, asset management, and learning loop" — seven capabilities, none of which is workflow, document custody or booking (FICO).
- Whoever owns the decision owns the explanation. CFPB Circular 2023-03 holds that adverse action notice requirements "apply equally to all credit decisions, regardless of whether the technology used to make them involves complex or 'black-box' algorithmic models" (Federal Register, 17 April 2024).
- YuSight's sample CAM: 28 minutes, 142 citations, every figure traced to source document and page, with full version history — the credit analysis layer's output, handed to whichever system owns the decision.
What are the five categories, and what does each one own?
Definitions first, in the order a file passes through them.
1. Loan origination system (LOS). The system of record for the loan as an object. It knows the application exists, who is on it, what stage it is in, which documents were collected, what was approved on what terms, who approved it, and how that flows onward. Everything with a date and a name attached lives here. An LOS is fundamentally a workflow and custody system that happens to have credit features bolted on.
2. Credit decisioning platform. The system that produces the outcome. It orchestrates data pulls, runs scorecards and models, evaluates policy rules, applies limits, and returns a decision with the reasons behind it. In consumer and small-ticket lending it often runs end to end in under a second. In commercial lending it usually returns a recommendation and a set of conditions rather than a final answer.
3. Rules engine / decision engine. A component, not a platform — although it is sold as both. It evaluates deterministic logic: if DSCR < 1.25 then refer. No statistics, no training data, no drift. It is the part of a decisioning platform a credit policy officer can read and change. Confusing it with a scorecard is the single most common category error in this market, and SR 26-2 now makes that confusion supervisorily visible.
4. Credit analysis layer. The system that produces the judgement inputs. It classifies a messy document set, maps each file to the right entity in a group structure, spreads financials, computes ratios from cited inputs, reconciles bank statements against bureau data, and drafts the memo. It is the only layer whose primary output is evidence rather than a status or a verdict.
5. Core banking system. The system of record for the account. Balances, postings, interest accrual, repayment schedules, existing exposure, delinquency status. It is upstream of underwriting (existing exposure is a decision input) and downstream of it (the booked facility lands here). Nothing in the stack is older or harder to change.
The ownership table
Function | LOS | Decisioning platform | Rules / decision engine | Credit analysis layer | Core banking |
|---|---|---|---|---|---|
Application intake and borrower record | Owns | Consumes | — | Consumes | — |
Pipeline, stages, SLAs, queues | Owns | — | — | Reads | — |
Data orchestration (bureau, banking, tax) | Triggers | Owns | — | Consumes | Supplies exposure |
Scorecards and statistical models | — | Owns | — | — | — |
Deterministic policy rules and limits | Stores | Hosts | Owns | Reads thresholds | Supplies limits data |
Document classification and entity mapping | Stores files | — | — | Owns | — |
Financial spreading and standardisation | Basic module | Rarely | — | Owns | — |
Ratio computation with source traceability | Basic | Consumes | Consumes | Owns | — |
Bank statement and bureau analysis | Rarely | Scores it | — | Owns | — |
Credit memo narrative with citations | Template | — | — | Owns | — |
The decision itself (approve/decline/refer) | Records it | Owns | Executes it | Recommends | — |
Adverse action reasons | Prints them | Owns | Emits codes | Supplies evidence | — |
Risk rating of record | Owns | Calculates | — | Feeds it | Reports it |
Covenant setup and documentation | Owns | — | — | Supplies definitions | Monitors balances |
Booking, accrual, servicing | Hands off | — | — | — | Owns |
Audit trail of who changed what | Owns for the loan | For the decision | Version of the ruleset | Owns for the analysis | For the account |
Read the last row twice. There is no single audit trail. There are five, and an examiner will ask you to reconcile them.
Worked example: one application through all five systems
A $2.4 million equipment term loan plus a $750,000 revolver renewal for a mid-market manufacturer with an existing $3.15 million of facilities. Policy: minimum DSCR 1.25x, maximum TOL/TNW 2.50x, single-obligor limit $6.0 million.
Step 1 — the credit analysis layer computes the ratios. Inputs extracted from the audited FY2025 statements, each carrying a page citation.
Input | Value ($) | Source |
|---|---|---|
Profit after tax, FY2025 | 1,180,000 | Audited FS FY2025, p. 12 |
Depreciation and amortisation | 640,000 | Audited FS FY2025, p. 12 |
Interest on term debt | 395,000 | Audited FS FY2025, p. 41, Note 26 |
Scheduled principal due, next 12m | 1,290,000 | Audited FS FY2025, p. 38, Note 14 |
Total outside liabilities | 8,420,000 | Audited FS FY2025, p. 10 |
Tangible net worth | 3,610,000 | Audited FS FY2025, p. 10 |
DSCR numerator = 1,180,000 + 640,000 + 395,000 = 2,215,000 DSCR denominator = 395,000 + 1,290,000 = 1,685,000 DSCR = 2,215,000 ÷ 1,685,000 = 1.3145 → 1.31x
TOL/TNW = 8,420,000 ÷ 3,610,000 = 2.3324 → 2.33x
Step 2 — core banking supplies existing exposure. Not the LOS, and this catches people out. The LOS knows about applications it has processed; core knows what is actually outstanding, including facilities booked before the LOS was installed.
Existing exposure = 3,150,000. Proposed = 2,400,000 + 750,000 = 3,150,000. Total post-sanction = 3,150,000 + 3,150,000 = 6,300,000
Step 3 — the rules engine evaluates deterministic policy.
Rule | Threshold | Actual | Result |
|---|---|---|---|
Minimum DSCR | ≥ 1.25x | 1.31x | Pass, headroom 0.06x |
Maximum TOL/TNW | ≤ 2.50x | 2.33x | Pass, headroom 0.17x |
Single-obligor limit | ≤ 6,000,000 | 6,300,000 | Fail by 300,000 |
Step 4 — the decisioning platform assembles the outcome. Two rule passes, one hard limit breach, plus a behavioural scorecard output. The platform returns REFER — single obligor limit exceeded, with reason codes, not DECLINE. That distinction is the platform's job, not the engine's: the engine emits a boolean, the platform decides what a boolean means.
Step 5 — the LOS routes and records. Refer means the file goes to the delegated authority for the next limit tier, with the memo attached. The LOS records who it went to, when, what they saw, and what they decided.
Step 6 — core banking books the sanctioned facility at the approved amount and schedule.
The borrower figures, thresholds and limits above are an illustrative worked file built to show where each system sits, not a client case. Substitute your own policy thresholds before using the shape.
Notice what happened at step 3. The breach was not a credit-quality problem — DSCR and leverage both passed. It was a portfolio-concentration problem, detected using a number that only core banking held. A stack where the decisioning platform cannot read live exposure will approve this file and discover the breach at booking.
Where do the boundaries actually blur?
Six places, and each has a question that resolves it.
Blurred boundary | Why it blurs | The question that resolves it |
|---|---|---|
LOS vs decisioning platform | Most LOS products embed a rules engine and call the combination "decisioning" | When policy changes, who edits the rule — and does the change deploy without an LOS release? |
Decisioning platform vs rules engine | Vendors sell the engine as the platform because the engine demos well | Does it orchestrate external data pulls and host models, or only evaluate logic you feed it? |
Decisioning platform vs credit analysis layer | Both claim "underwriting" | Does it read a scanned three-entity statement set, or does it consume ratios someone else computed? |
LOS vs credit analysis layer | Every major LOS ships a spreading module — nCino publishes spreading of "tax returns, audits, company prepared statements, 10-Ks, 10-Qs" (nCino) | Run your worst multi-entity scanned file through it and count analyst touches |
Core banking vs LOS | Core holds exposure and repayment history the LOS needs mid-decision | Is exposure read live at decision time, or copied nightly? |
Data aggregator vs analysis layer | Aggregators return parsed transactions and call it analysis | Does the output resolve to a page in a source document, or is it a JSON blob with no provenance? |
The pattern across all six: the categories are defined by what they are the system of record for, not by what they can display. Any layer can show you a DSCR. Only one of them can defend where it came from.
Is a decision engine a "model"? SR 26-2 says usually not
This matters more than it sounds, because it changes who validates what.
Under the revised guidance a deterministic rule — if TOL/TNW > 2.50 then refer — is not a model. It applies no statistical or financial theory; it applies a policy. It still needs change control, testing and an audit trail, but it does not need independent model validation, back-testing or ongoing performance monitoring in the model-risk sense.
A behavioural scorecard sitting next to it in the same platform is a model, and does. So does a probability-of-default estimate, a cash-flow forecast and a risk-rating algorithm.
And the third category — generative and agentic AI — sits outside the guidance altogether, by the agencies' own words. That is a gap, not a permission. The agencies have signalled a future request for information on AI in model risk management; until then, your own controls are the only controls. The supervisory detail is in model risk management for AI in credit analysis: what SR 26-2 changed, and the architecture that makes generative output defensible in a credit file is in AI hallucination risk in credit analysis.
Practical consequence: when a vendor says "our AI decisioning platform", ask which of the three things inside it are rules, which are models, and which are generative. Those three answers route to three different governance processes and three different validation budgets.
What does each category call itself, and what does it usually mean?
A decoder for vendor language, assembled from how these words are used in practice rather than how they should be.
What the pitch says | What it usually means | What to ask |
|---|---|---|
"End-to-end lending platform" | An LOS with an embedded rules engine | Show me spreading on a scanned multi-entity file |
"AI credit decisioning" | A scorecard plus rules, possibly with an LLM in one step | Which component is statistical, which is deterministic, which is generative? |
"Automated underwriting" | Straight-through processing on clean, structured applications | What percentage of your reference customers' commercial files go straight through? |
"Credit analysis platform" | Spreading and ratios, sometimes a memo | Can I click a figure and land on the source page? |
"Decision engine" | A rules component | Does it pull data, or does it only evaluate what arrives? |
"Real-time decisioning" | Sub-second on consumer or small-ticket files | What is the latency when three years of audited statements must be spread first? |
Consumer and small-ticket lending genuinely decides in milliseconds because the inputs are structured and thin. Commercial lending does not, because the inputs are a 47-document folder in mixed formats. A vendor quoting consumer latency into a commercial conversation has told you which market they built for. The evaluation checklist for that conversation lives in how do you evaluate AI underwriting software for examiner readiness.
Do you need all five?
Structurally, yes — every lender has all five functions whether or not it has five systems.
The question is how many are systems and how many are spreadsheets, email threads and an experienced person's memory. A small commercial lender may run the decisioning platform as a policy document, the rules engine as a credit committee, and the analysis layer as three analysts with Excel. That is a real architecture. It is also the one that fails an examination first, because none of those three produces an audit trail.
Consolidation goes the other way as volume grows: the analysis layer usually gets systematised first (it holds the most hours), then the decisioning platform, then the LOS, and core banking gets replaced roughly never. The broader automation sequencing is set out here, and the build-or-buy version of the question is in build vs buy: should your bank build its own credit analysis AI.
FAQ
What is a credit decisioning platform?
It is the layer that turns borrower data into a credit outcome. It orchestrates data pulls, runs scorecards and models, evaluates policy rules and returns approve, decline, refer or a set of terms, along with the reasons behind that answer.
Is a credit decisioning platform the same as an LOS?
No. A decisioning platform produces the decision; an LOS administers the loan around it — intake, stages, approvals, document custody and booking handoff. Many LOS products embed a rules engine and market the combination as decisioning, which is where the confusion starts.
Do you need both an LOS and a decisioning layer?
Functionally you always have both. Whether they are two systems depends on volume and complexity. Below a few hundred commercial files a year the decisioning layer is often a policy document and a credit committee, which works until someone asks for an audit trail.
What is the difference between a decision engine and a decisioning platform?
The engine evaluates deterministic logic you give it. The platform surrounds that engine with data orchestration, model execution, reason-code generation and champion-challenger testing. Buying an engine and expecting a platform is a common and expensive mistake.
Is a rules engine a model under SR 26-2?
Usually not. The revised guidance defines a model as applying statistical, economic or financial theory to produce quantitative estimates, and explicitly excludes deterministic rule-based processes. A scorecard in the same platform is a model. The two need different governance.
Where does the credit analysis layer fit in?
Upstream of the decision. It classifies documents, maps them to entities, spreads the financials and computes the ratios that the rules and models then consume. Without it, a decisioning platform is evaluating numbers somebody typed in by hand.
Which system should own the audit trail?
Each owns its own — the loan record, the decision and its reason codes, the ruleset version, the analysis and its edit history, the account postings. The work is making them reconcile, because an examiner will trace one file across all five.
Can a decisioning platform read financial statements?
Some ingest structured financial data; very few read a scanned, stamped, multi-entity statement set and work out which entity each page belongs to. That is document intelligence, and it is a different engineering problem from decision orchestration.
How fast should a commercial credit decision be?
Fast decisioning claims usually come from consumer or small-ticket lending, where the inputs are thin and structured. On a commercial file the constraint is not decision latency, it is how long it takes to get trustworthy numbers into the decision.
Key takeaways
- Five categories, five systems of record: the LOS owns the loan, the decisioning platform owns the outcome, the rules engine owns deterministic policy, the credit analysis layer owns the evidence, core banking owns the account.
- The categories are defined by what each is the system of record for, not by what each can display on a screen.
- SR 26-2 separates deterministic rules from models, and puts generative and agentic AI outside the guidance entirely. Three components, three governance routes.
- Live exposure lives in core banking, not the LOS. A decisioning platform that cannot read it will pass concentration limits it should have failed.
- Every lender has all five functions. The question is which of them are systems and which are spreadsheets — and only the systems produce an audit trail.
YuSight is the credit analysis layer. It classifies the document set, maps it to the right entity, spreads the financials, computes the ratios from cited inputs, and drafts a Credit Assessment Memo — a 28-minute sample carried 142 citations — then hands both the document and the structured data to whichever system owns your decision and your loan record, with a complete trail of what the machine produced and what a human changed.
See the audit trail an examiner would see.
This article is general information for credit and risk professionals. Product capabilities described for third-party platforms are drawn from those vendors' own published materials as at August 2026 and should be confirmed in your own evaluation.
