To combine a bureau score with your own model in a single loan decision, you orchestrate them rather than pick one: run both scores in the same policy, decide which governs in which situation, and define explicit rules for what happens when they disagree. That is score orchestration. The bureau score handles the population it knows well (thick-file applicants with repayment history). Your own model, often built on alternative or cash-flow data, handles the population the bureau is blind to (thin-file, new-to-credit, or self-employed borrowers). Neither replaces the other. A decisioning engine runs both alongside your document-derived signals and resolves them into one outcome.
This guide is the operator's playbook for combining a bureau score with your own model: the four orchestration patterns (cascade, override, weighting, conflict rules), when each one governs, and how to wire it into a single auditable policy. It is written for credit and risk teams who already have a bureau feed and are now adding (or have already built) an internal model, and need both to coexist without one quietly overruling the other by accident.
Why Score Orchestration Beats Picking One Score
Every score has a population where it is strong and a population where it is weak. A bureau score is built on repayment history, so it is sharp on borrowers with a thick file and near-useless on borrowers with no file at all. An internal model built on bank-statement cash flow or alternative data is the inverse: it can underwrite a thin-file applicant the bureau cannot see, but it may be less calibrated on a complex, heavily-indebted borrower the bureau has years of data on.
If you pick one score and apply it to everyone, you accept the weakness of that score on the population it does not understand. Pick the bureau score alone and you decline good thin-file applicants the bureau simply has no data on. Pick your own model alone and you may underprice risk on thick-file borrowers with a default history your model never learned from. Score orchestration is the refusal to make that trade. You keep both, and you decide, per applicant, which one is in charge.
This is a policy problem, not a modeling problem. The question is not "which score is better" but "under what conditions does each score govern, and what do we do when they conflict." That logic lives in your decisioning engine, not inside either model. The model produces a number. The engine decides what the number means for this applicant.
The Four Score Orchestration Patterns
There are four core patterns for combining multiple scores in one decision. Most real policies use two or three of them together, layered. Here is each one, what it does, and when it governs.
1. Cascade (waterfall)
A cascade tries scores in priority order and uses the first one that returns a usable result. The classic case: try the bureau score first. If the applicant is thin-file and the bureau returns no-hit or a low-confidence score, fall through to your internal cash-flow model. The cascade is about coverage. It guarantees every applicant gets scored by whichever model can actually see them, instead of dropping the no-hits.
Use a cascade when your scores cover different populations and rarely both apply with full confidence to the same applicant. The bureau owns thick-file, your model owns thin-file, and the cascade routes each applicant to the score that can underwrite them.
2. Override (champion with veto)
An override designates one score as the primary decision-maker and lets a second score veto or escalate in specific conditions. For example: approve on the bureau score, but if your fraud-and-affordability model flags the cash flow as insufficient to service the loan, override the approval to a refer. The primary score carries the decision; the secondary score has a narrow, defined right to intervene.
Use overrides when one score is authoritative for the approve/decline call but a second signal must be able to stop a bad decision the primary score cannot see. Affordability and fraud overrides are the most common, because a bureau score says nothing about whether this month's cash flow can actually cover the repayment.
3. Weighting (blended score)
Weighting combines two or more scores into a single blended number using fixed or conditional weights, for example 60% bureau and 40% internal model, then decisions on the blend. This is the pattern to reach for when both scores genuinely apply to the same applicant and each carries independent, additive signal. The weights encode how much you trust each score for that segment.
Use weighting only when both scores are well-calibrated on the same population and you have the data to justify the weights. Blending two scores that disagree because they see different things (rather than because they are noisy) destroys signal. Weighting works best on the overlap population where both the bureau and your model are confident, not as a default for everyone.
4. Conflict rules (disagreement handling)
Conflict rules define what happens when two scores point in opposite directions: bureau says approve, internal model says decline. The naive answer (average them) is usually wrong, because a sharp disagreement is itself a signal that something needs a human eye. The disciplined answer is to route material conflicts to manual review, or to apply the more conservative score when the gap exceeds a threshold.
Use explicit conflict rules whenever you run more than one score on the same applicant. Without them, conflicts get resolved by whichever rule happens to fire first in your policy, which is an accident, not a decision. Naming the conflict and routing it deliberately is what separates an orchestrated policy from a pile of stacked rules.
Score Orchestration Patterns at a Glance
The table below summarizes the four patterns, what each optimizes for, and when it governs. Read it as a menu, not a sequence: a mature policy layers a cascade for coverage, an affordability override for safety, and conflict rules for the disagreements that remain.
| Pattern | How it combines scores | Optimizes for | When it governs |
|---|---|---|---|
| Cascade (waterfall) | Try scores in priority order, use the first usable result | Coverage of every applicant, including no-hits | Scores cover different populations (thick-file vs thin-file) |
| Override (champion with veto) | One primary score decides, a second can veto or escalate | Safety against a blind spot in the primary score | Affordability or fraud must be able to stop an approval |
| Weighting (blended score) | Combine scores into one number with fixed or conditional weights | Precision on the population both scores see well | Both scores are calibrated on the same applicant |
| Conflict rules | Detect disagreement, route to review or apply the conservative score | Catching the cases neither score should decide alone | Two scores point in opposite directions by a material gap |
How to Build a Score Orchestration Policy: A Checklist
Orchestration goes wrong when teams wire scores together implicitly, one rule at a time, until no one can say which score actually drove a given decision. The fix is to design the orchestration explicitly, in this order.
- Map each score to its population. Write down, per score, the segment where it is authoritative (bureau: thick-file; internal model: thin-file or self-employed) and where it is weak. This map is the foundation of every routing decision.
- Choose the governing pattern per segment. For each population, decide which pattern applies: cascade for the no-hit fall-through, override for the affordability veto, weighting for the well-covered overlap. One policy, multiple patterns, each scoped to a segment.
- Define conflict rules before you go live. Decide in advance what a material disagreement is (a band gap, a points threshold) and where it routes. Do not discover your conflict behavior in production.
- Keep models as inputs, not decisions. Every score, bureau or internal, enters the policy as a signal. The decision lives in the policy layer, so you can swap a model or re-weight without rewriting the logic around it.
- Make every path auditable. For any decision, you should be able to show which score governed, why, which overrides fired, and how a conflict was resolved. If you cannot replay it, you cannot defend it to a regulator or a credit committee.
- Add the signals scores ignore. Bureau scores and most internal models say nothing about document authenticity or whether the stated income reconciles with the bank statements. Those document-derived signals belong in the same policy, alongside the scores.
Score-Agnostic by Design: How Floowed Orchestrates
Floowed is two products on one platform, and score orchestration is exactly the job the platform is built to do.
The Decisioning Engine (the no-code policy builder for credit and risk teams) is score-agnostic by design. Bring any bureau score, any third-party score, or your own internally built model, and it is absorbed unchanged as an input. Floowed does not compete with scoring vendors and does not push its own score: CredoLab, Zest, a bureau model, your data-science team's logistic regression, all of them are signals the engine orchestrates. You build the cascade, the overrides, the weights, and the conflict rules visually, and the credit officer operates the policy without waiting on engineering. For the distinction between orchestrating scores and being a score, see credit decisioning vs credit scoring, and for why this is more than if/then logic, see decision engine vs rules engine.
The reason orchestration on Floowed is stronger than orchestration on a bare rules engine is the other product. Document Intelligence reads and analyses any loan document at any quality (handwritten passbooks, photographed bank statements, skewed scans) into decision-ready data: it normalizes income, runs bank-statement and cash-flow analysis (average daily balance, debt-service coverage), and surfaces fraud and tampering signals. That gives your orchestration a third class of input the scores cannot provide. The affordability override that vetoes a clean bureau approval is powered by real cash-flow analysis, not a self-reported number. The conflict rule that routes a disagreement to review can also see whether the documents behind the application reconcile at all. See cash-flow underwriting and bank-statement analysis software for how those signals are produced, and what is document intelligence for the capability itself.
In production at Alon Capital, founder Rene de Jesus puts it plainly: "Floowed reads the documents, runs our credit policy, and surfaces a decision in minutes." That single sentence is the whole loop: documents become data, the policy orchestrates every score and signal against that data, and a decision comes out with its reasons recorded.
A Worked Example: Bureau Score Plus Cash-Flow Model
Concretely, here is one policy that uses three of the four patterns together for a working-capital loan.
- Cascade for coverage. Pull the bureau score first. Thick-file applicants get a confident bureau score. No-hit and thin-file applicants fall through to the internal cash-flow model built on Document Intelligence's bank-statement analysis, so no one is dropped for lack of a bureau file.
- Override for affordability. Whichever score governs, a clean approval still passes through an affordability check: if debt-service coverage from the analysed bank statements is below threshold, the approval is overridden to a refer. The bureau score never sees this month's cash flow; the override does.
- Conflict rule for disagreement. When both scores apply and they disagree by more than a defined band, the case routes to manual review rather than auto-deciding. A bureau approve against an internal-model decline is treated as a signal in itself.
The result is one decision, produced in minutes, that used the right score for each applicant, refused to approve anyone the cash flow cannot support, and escalated the genuine edge cases to a human, with every step recorded. That is what orchestration buys you that a single score never can. For where this fits in the wider automation picture, see automated underwriting systems and the no-code credit policy builder guide.
Frequently Asked Questions
Can you use a bureau score and your own model in the same loan decision?
Yes. You orchestrate them in one policy: run both scores, decide which governs for which applicant (typically bureau for thick-file, your model for thin-file), and define explicit rules for what happens when they disagree. A decisioning engine runs both as inputs and resolves them into one outcome.
What is the difference between a cascade and a weighted score?
A cascade tries scores in priority order and uses the first usable one, so a given applicant is decided by a single score. Weighting blends multiple scores into one number for the same applicant. Use a cascade when scores cover different populations, weighting when both apply confidently to the same applicant.
What should happen when two scores disagree?
Do not average them. A material disagreement is itself a signal. Route the case to manual review, or apply the more conservative score when the gap exceeds a defined threshold. Decide this with an explicit conflict rule before going live, not implicitly through rule ordering.
Does combining scores mean Floowed replaces my bureau or scoring vendor?
No. Floowed is score-agnostic and does not compete with scoring vendors. It absorbs any bureau score, third-party score, or your own model unchanged, as inputs, and orchestrates them in your policy alongside document-derived signals. Your scoring vendors stay; Floowed decides what to do with their output.
Where do document signals fit in score orchestration?
Alongside the scores, as a third class of input. Bureau scores and internal models say nothing about document authenticity or whether stated income reconciles with bank statements. Document Intelligence supplies those signals (affordability, fraud, cross-document validation) so your overrides and conflict rules can act on evidence, not self-reported numbers.
Orchestrate Your Scores in One Policy
The fastest way to see score orchestration is to build it. Bring your bureau score and your own model, wire a cascade, an affordability override, and a conflict rule in the Decisioning Engine, and run a real application through it. Pricing is consumption-based on credits and sized to your operation on one short call, well under the large enterprise platforms.
Start free and run a loan application yourself, or book a demo and we will walk you through orchestrating your scores.
Last updated 2026-06-09 by Kira, Floowed's AI Flow Architect.