Executive Summary: An explainable lending decision keeps six layers separate: source evidence, normalized signals, lender policy, credit scoring, exception review, and the authorized outcome. When an API result, mapped status, model score, and decision all appear as one green field, the credit file cannot explain which fact came from a source and which judgment came from the lender. Cobalt provides business data within documented coverage. It is not the lender's decisioning engine. The framework below shows how risk and engineering teams can preserve that boundary while still automating high-volume workflows.
What Are the Six Layers?
1. Source evidence
Source evidence is what an authoritative system or documented data product returned, with the exact query, coverage, timestamp, and availability. Examples include a state entity record, name and EIN result, UCC filing, OFAC candidate, or court docket.
2. Normalized signal
A normalized signal maps source-specific values into a stable internal schema. It might preserve the original state status while adding an internal category such as `registered`, `inactive`, or `unknown`. The original value must remain available.
3. Policy rule
Policy is the lender-owned instruction that routes evidence. It decides whether a mismatch triggers correction, whether an unsupported jurisdiction invokes a fallback, and when a reviewer is required.
4. Model output
A model combines approved features into a statistical or rules-based recommendation. The model should consume documented signals, not untraceable vendor labels.
5. Exception review
An exception is a case that cannot advance under the default rule. The reviewer receives the conflict, relevant evidence, permitted actions, and closure criteria.
6. Authorized outcome
The final decision is the lender's authorized result, with the policy and evidence versions used. It should not overwrite the preceding layers.
Evidence describes the file. Policy and models interpret it. An authorized lender outcome decides it.
Why Does Provenance Matter?
Different products answer different questions. IRS TIN matching compares a submitted name and TIN pair.[1] OFAC describes its search score as a measure of name similarity, not a determination that a party is sanctioned.[2] PACER provides federal court case and docket access, while state systems remain separate.[3]
Flattening those outputs into one risk flag discards meaning. A tax mismatch, sanctions candidate, and civil complaint need different review paths.
How Should the Evidence Layer Be Designed?
Store each source event with:
1. Subject identity and internal ID.
2. Exact input and jurisdiction.
3. Coverage status.
4. Raw source value or controlled evidence reference.
5. Retrieval time and source availability.
6. Product and schema version.
7. Any known completeness limitation.
8. Superseding-event link.
Cobalt's public documentation describes several verification products and their request and response patterns.[4] The lender should carry the documented limitations into its own schema rather than replacing them with a universal pass.
How Should Normalization Work?
Normalization should make values comparable without pretending the sources are uniform. Preserve both the source value and the mapped category.
source_value: "FTB Suspended"
normalized_category: "not_in_good_standing"
mapping_version: "ca-sos-2026-08"California publishes definitions for its business-search status fields.[5] Another jurisdiction may use different terms or omit the field. `unknown` and `unavailable` are valid states. They should not be forced into clean or adverse.
How Should Policy Consume Signals?
Policy should name the owner, condition, route, and evidence required for closure.
• Identity mismatch. Correct the input or request certified evidence.
• Unsupported UCC jurisdiction. Use an approved authoritative fallback.
• OFAC candidate above review threshold. Send the underlying candidate data to compliance review.
• Court name candidate. Resolve identity and procedural posture before materiality review.
• Source unavailable. Retry within a bounded window or hold.
• Several state entities. Resolve the entity identifier before credit scoring.
FinCEN describes risk-based CDD procedures for covered financial institutions, including customer identity, risk profiles, and ongoing monitoring.[6] Institutions must map their own applicable obligations rather than treating a vendor response as legal policy.
Where Should the Credit Model Begin?
The model should begin only after identity and coverage dependencies are satisfied. Features must identify their source, transformation, time, missing-value rule, and permitted use.
Do not encode `no returned UCC filing` as `no lien` unless coverage and search identity are proven. Do not encode `no court case returned` as `no litigation` outside confirmed jurisdictions. Do not encode an OFAC score below a threshold as a permanent clearance.
What Makes an Exception Queue Defensible?
Each exception needs one cause, one owner, one next action, an aging rule, and a closure state. A generic `manual review` status creates a backlog rather than a control.
• `correct_input`
• `request_evidence`
• `retry_source`
• `search_fallback`
• `compliance_review`
• `credit_review`
• `closed_supported`
• `closed_not_supported`
Record who closed the case, what evidence changed, and which policy authorized the outcome.
What Should the Decision Record Contain?
The authorized outcome should reference, rather than copy over, the earlier artifacts:
1. Evidence-event IDs.
2. Normalization versions.
3. Policy version.
4. Model version and recommendation.
5. Exception dispositions.
6. Decision authority and timestamp.
7. Adverse or customer-facing reason process where applicable.
The Federal Reserve's authentication guidance illustrates a broader layered-control principle: reliable programs use multiple controls and governance rather than relying on one class of information.[7]
What Should Risk Teams Monitor?
• Evidence events missing coverage or timestamps.
• Normalization values mapped to unknown.
• Policy fallbacks by product and jurisdiction.
• Model inputs with missing provenance.
• Exceptions by cause, age, and owner.
• Overrides by policy and model version.
• Decisions made while a required source was unavailable.
• Reopened cases after new evidence arrived.
These measures test the framework's integrity. Approval, loss, and pricing outcomes require separate analysis.
What Is the Practical Implementation Order?
Define the six objects and owners before connecting another API. Ingest immutable source evidence, normalize it with a versioned map, route it through lender policy, pass approved features to the model, resolve exceptions, and store the authorized outcome with references to every layer.
Cobalt can supply entity, TIN/EIN, UCC, OFAC, court, contractor-license, and multi-state source results within documented coverage. The lender owns normalization choices, policy, scoring, exceptions, and decisions.
Ready to test the framework on one clean file and one coverage exception? Schedule a Cobalt Intelligence demo and bring the evidence fields your current decision record preserves.
.jpg){kind=small}
.png)