Explainable credit decisions: how to answer a decline with evidence
Every decline raises one question: why? How to build credit decisions you can explain to customers, the board and regulators — even with an ML model involved.
Updated July 2026 · 6 min read
In short
A credit decision is explainable when the record captures its inputs, the policy version, the path taken and the outcome. With that in place, answering the customer, the board or the regulator is a procedure backed by evidence, not a reconstruction.
Every credit decision eventually raises the same question: why? The declined applicant asks it, the board asks it when delinquency moves, and the regulator asks it during an audit. An institution that cannot answer with evidence does not have a communication problem: it has a decision architecture problem.
Written byMariano Sokal · COO at uFlow
COO at uFlow. Works with banks, fintechs and retailers across Latin America on how credit policies are governed: who decides, how a change is controlled, and what evidence remains for audit and the regulator.
Why explainability stopped being optional
The pressure comes from three directions at once. The customer expects a concrete, actionable reason, not a generic "you do not meet the requirements". Much of the consumer financial protection framework across Latin America is moving toward requiring that a decline be explainable, with obligations that vary by country. And inside the institution, risk and audit need to understand what the engine is deciding in order to govern it.
The common trap is trying to reconstruct the explanation after the fact, from scattered logs and the team's memory. A reliable explanation is not reconstructed — it is recorded at the moment of the decision.
What a decision must record to be explainable
For any decision to be explainable months later, the record has to capture four things at execution time:
- The inputs: which variables and values the policy received, including — when enabled — the evidence from the responses returned by the data providers that were queried.
- The logic: the exact policy version that ran, with the rules, matrices and cutoffs in force at that moment.
- The path: which branches executed and how each relevant condition evaluated.
- The outcome: the final decision and the intermediate variables that determined it.
- In uFlow that record is part of the design: executions are stored as transactions you can query by identifier, date or authorized variables, subject to the permissions of each installation.
Explaining decisions that involve a model
The statistical score is the hardest part to explain — and the reason it is better to let the model inform and the policy decide. When the model output feeds explicit rules (cutoffs, matrices, exclusions), the explanation of the individual case becomes concrete again: "the score fell below the cutoff for this product and this segment".
Two additions strengthen the explanation: recording which model version took part in each decision, and keeping the model's input variables inside the transaction record — so later analysis can also reconstruct the context of the score.
The operating flow of a customer complaint
With a complete record, answering a complaint stops being an investigation and becomes a procedure:
The practices described here must be adapted to the regulations, credit policies and consumer protection and personal data obligations that apply in each country.
- Find the transaction by its identifier (or by variables the institution has authorized and indexed).
- Reconstruct the path: which rules applied, with which values, and which policy version made the decision.
- If the doubt is about the source data, retrieve the evidence of what the credit bureau reported that day, subject to access permissions.
- Answer with facts: the concrete reason for the decline and, where applicable, what would have to change for a reassessment.
- Leave the case documented: the same record serves the next complaint and the report to the regulator.
Technical documentation
How this is implemented in the engine, step by step.
Common questions
What should the response to a declined applicant include?+
The main reason in plain language (for example: debt level reported by the credit bureau above the policy threshold), which data point determined it, and what options the customer has: correct an incorrect data point with the source, or reapply when their situation changes. All of that comes out of the transaction record.
Can you explain a decision that involved machine learning?+
Yes, if the architecture allows it: the model contributes a score and the policy turns it into a decision through explicit rules that are recorded. The explanation of the individual case rests on those rules and their cutoffs; explaining the model itself is part of model risk governance (validation, monitoring, documentation).
Related topics
Decision traceability and audit: how to explain every credit decision
Every credit decision should be explainable: what data came in, which rules ran, why it was approved or declined. End-to-end audit traceability.
ObservabilityMonitoring credit decisions in production: transactions, errors and raw responses
What to watch once a policy is live: searching transactions by ID, date or variable, analyzing errors, and reaching each provider's original response.
ProductHow the uFlow decision engine does it
Governance, versioning and traceability built into the engine, without slowing the business down.
Explore all guides or read the glossary.
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.