Your AI Denied the Loan. Can You Prove Why?
In credit decisioning, governance is not the policy around the model. It is the institution’s ability to reconstruct the decision.
By Raj Brar, Founder of Argus AI Labs
In the 1990s, I worked in automotive diagnostics as vehicles were becoming computer systems on wheels. I ran three diagnostic centres, and one of them grew to a team of 15 engineers.
A fault code could tell us where to begin. It could not tell us what had actually failed.
The code might point to a sensor, but the cause could be a damaged wire, a weak ground, a control module, or another component feeding bad information into the system. Replacing the part named by the code was easy. Proving the failure meant tracing the signal, testing the relationships, and preserving enough evidence to justify the repair.
That distinction matters in credit decisioning.
A model can produce a score. A rules engine can return a decline. A lender can generate a notice. None of those things, by itself, proves that the institution understands why a person was denied credit.
The real governance test comes later: Can the institution reconstruct the decision from the data that entered the system, through the model and rules that were active at that moment, to the reasons given to the applicant and the human review that followed?
If it cannot, the institution does not have governed AI. It has an outcome it may be unable to defend.
Credit decisions expose the difference between policy and control
Most AI governance programs look stronger from the boardroom than they do inside the workflow.
There is an AI policy. There is a model inventory. There are approval committees, risk classifications, and vendor questionnaires. Each item may be necessary. Together, they can still leave a basic operational question unanswered:
Why did this applicant receive this decision?
In the United States, this is not an abstract question. Regulation B requires a creditor’s adverse-action reasons to be specific and to identify the principal reasons for the action. The exact regulatory guidance surrounding complex algorithms has changed—the CFPB withdrew Circulars 2022-03 and 2023-03 in May 2025—but the underlying rule did not disappear. A lender still needs a defensible connection between the decision it made and the reasons it provides.
The model cannot simply be described as too complex to explain.
The supervisory framework is also moving. In April 2026, the Federal Reserve issued SR 26-2, replacing SR 11-7 and its 2021 clarification. The revised guidance is risk-based and tailored to a bank’s size, complexity, model use, and exposure. It emphasizes governance, documentation, validation, inventory, and effective challenge.
SR 26-2 also draws an important boundary: generative and agentic AI are outside its scope.
Out of scope does not mean a free zone. It creates an architecture problem. A bank may have established model-risk controls for a quantitative underwriting model while new AI components enter the surrounding workflow—document extraction, fraud investigation, applicant communication, exception handling, or agent-assisted review.
The decision path can cross systems governed under different rules.
Policy will not hold that path together. Evidence will.
The argument against heavier governance is partly right
Business leaders are right to worry that governance can slow deployment.
If every change waits for a committee, every exception requires a spreadsheet, and every review depends on a small group of specialists, the control system will become a bottleneck. Teams will route around it, vendors will update faster than the institution can review them, and governance will drift away from the system it is supposed to govern.
The answer is not to remove the controls. It is to stop treating governance as a sequence of meetings.
The strongest controls operate inside the decision path. They capture the model version automatically. They preserve the data snapshot or the reproducible reference to it. They record which rules fired, which factors materially affected the outcome, who approved an override, and what explanation reached the applicant.
This changes the economics of review. A human does not have to supervise every low-risk event in real time. The system can route decisions according to consequence, confidence, novelty, and reversibility. Reviewers spend their time on the decisions that carry the greatest risk or fall outside established boundaries.
Good governance does not put a human in front of every decision. It makes human authority explicit where the consequences require it.
A decision record has to survive the model
Financial institutions often document models as objects: purpose, owner, validation date, performance threshold, approved use, and version history.
That is necessary, but the consumer experiences a decision, not a model.
A single credit decision can depend on multiple components: application data, bureau data, derived features, an underwriting model, policy rules, pricing logic, fraud controls, third-party services, and a manual exception. If those elements leave separate logs with different identifiers and retention periods, the institution may be able to describe the system without being able to reconstruct the event.
For a consequential decision, the evidence record should connect at least:
- the application and material input data used at decision time;
- the source, lineage, and effective date of that data;
- the model, rules, thresholds, and versions that were active;
- the factors that materially affected the outcome;
- any human review, override, or exception;
- the adverse-action reasons delivered to the applicant;
- the approvals and ownership attached to the decision path; and
- the later changes that would produce a different result today.
This is not a demand to retain everything forever. Regulation B has specific record-retention requirements, and other obligations will vary by product and jurisdiction. The design question is narrower: during the period when a decision must be reviewed, can the institution reproduce the evidence without rebuilding it by hand from six vendors and three internal teams?
If the answer is no, the audit trail is a scavenger hunt.
The vendor owns the product. The institution owns the decision.
Buying an underwriting model or an AI service does not transfer accountability for the decision made with it.
The OCC’s interagency guidance on third-party relationships applies across the relationship lifecycle: planning, due diligence, contracting, ongoing monitoring, and termination. SR 26-2 also makes clear that third-party models remain subject to risk management and validation appropriate to their use.
That changes the questions procurement and risk teams must ask.
Can the institution obtain the evidence required to validate a decision? Will the vendor preserve the relevant logs for the necessary period? Can a model or feature change be tied to the affected decisions? What happens to the evidence when the contract ends? Can the institution export it in a usable form, or does the vendor remain the only party capable of interpreting it?
A vendor can provide technology. It cannot provide institutional accountability by contract.
A practical way to classify the review path
I evaluate automated actions on two axes: consequence and reversibility.
This is not a regulatory classification. It is an operating tool for deciding where authority, evidence, and human review belong.
| Decision type | Example in credit operations | Appropriate control |
|---|---|---|
| Lower consequence, readily reversible | An AI system prioritizes an application for document follow-up | Automated execution with logging and sampled review |
| Lower consequence, difficult to reverse | An AI system suppresses a prequalified offer a consumer should have received | Monitoring, defined recovery path, and owner review |
| Higher consequence, reversible | An AI system places an application on a temporary fraud hold | Strong evidence capture, time limit, and prompt human escalation |
| Higher consequence, difficult to reverse | An AI system contributes to a mortgage denial or materially worse credit terms | Predefined authority, reconstructable evidence, specific reasons, and meaningful review |
The point is not to turn every action into a four-box exercise. It is to prevent a common governance mistake: applying the same review process to every system because the organization has classified all of them as “AI.”
The system should become more demanding as consequence rises and reversibility falls.
Sovereignty begins with the evidence, not the server location
Data residency is often treated as evidence of control. It is not enough.
An institution can keep every byte in an approved jurisdiction and still depend on a vendor for the model history, feature logic, logs, or explanation layer required to defend a decision. The data may be resident while the decision evidence remains outside the institution’s practical control.
This is where sovereignty becomes operational.
Who controls access to the record? Who sets retention? Who can change the model or the explanation logic? Who holds the keys? Can the institution export the evidence in a form it can independently review? Can it prove which version was active when the decision occurred?
Custody is not governance. The requirement is verifiability.
The European Union has made the stakes explicit by classifying AI used to evaluate the creditworthiness or credit score of natural persons as high-risk under the EU AI Act, apart from systems used to detect financial fraud. The compliance mechanics differ from U.S. credit law, but the architectural pressure points are familiar: data governance, documentation, logging, human oversight, accuracy, and accountability.
Different regimes are converging on the same practical demand. An institution must be able to show how a consequential system operated, not merely state that it was governed.
What building governed intelligence taught us at Argus
At Argus AI Labs, we confronted this problem in a different high-consequence domain: legal intelligence built around Mexican federal tax law.
The challenge was not retrieving text. A system could find a relevant provision and still be wrong because it relied on the wrong authority, missed an amendment, ignored when a rule was effective, or applied a source outside the question’s legal context.
We had to architect for provenance, authority, temporal validity, applicability, versioning, and human review. The answer needed an evidence path back through the sources that supported it. When the underlying law changed, the system had to preserve what was true at the time without pretending that yesterday’s answer and today’s answer came from the same state of the world.
Credit decisioning is a different legal and operational domain. I am not presenting a legal-intelligence system as a banking credential. The relevant lesson is architectural: when an answer or decision has consequences, the evidence cannot be an afterthought generated for an auditor. It has to be part of the product.
For a lender, that means connecting the application, source data, derived features, active model and policy versions, decision factors, explanation, and review into one governed record. At Argus, we call this evidence readiness: the ability to assemble the decision trail quickly because the system preserved it as the work occurred.
That is the difference between logging activity and governing a decision.
Start with the decision, not the model inventory
If I were evaluating a lender’s credit-decision architecture, I would work through it in this order:
- Inventory consequential decisions. Identify where credit is denied, delayed, repriced, reduced, or subjected to an exception. Then map the models, rules, data sources, and people involved.
- Classify consequence and reversibility. Use the classification to determine validation depth, approval authority, review timing, and escalation.
- Assign one accountable owner. Cross-functional participation matters, but a decision path without an owner becomes a collection of partial responsibilities.
- Design the evidence record. Define the minimum artifacts required to reconstruct the decision before selecting the logging tools.
- Embed the control points. Capture versions, reasons, approvals, exceptions, and data references automatically wherever possible.
- Test the control path. Verify that identifiers, versions, ownership, escalation, and evidence capture remain connected from application through outcome.
The final step exposes what governance documents usually hide. Missing identifiers, vendor dependencies, overwritten model versions, irreproducible features, and vague ownership appear quickly when the control path is tested end to end.
Pick any decision
That is the test I would use with a bank’s leadership team.
Pick any consequential credit decision from the period your institution is required to retain. Do not pick the cleanest case. Do not give the team advance notice. Ask them to show the information used, the systems and versions involved, the reasons that drove the outcome, the explanation sent to the applicant, and the human authority behind any exception.
Then measure how long it takes.
If the answer requires a special investigation, the governance system is not operating at the level the policy suggests. If the evidence depends on a vendor’s goodwill, the institution does not fully control it. If the reasons cannot be tied to the actual factors used, the explanation is theatre.
In diagnostics, the code was never the proof. It was the beginning of the investigation.
An AI-generated credit decision should be treated the same way. The outcome is not evidence that the system worked. The institution earns that conclusion only when it can prove how the decision was made.
About the author
Raj Brar is the founder of Argus AI Labs and an AI systems architect focused on turning enterprise data, workflows, and expert knowledge into governed intelligence. His work is shaped by more than three decades of building and diagnosing complex operating systems across technology, business, and cross-border transactions.
For the system design behind this accountability test, see our AI governance architecture for financial services.