Take me through how your system decides to approve or decline a loan, and how it explains a decline to the applicant.

Short answer

A credit decision runs hard policy rules first, then scorecard, affordability, pricing and limit assignment. To explain a decline later, store the decision record with inputs, rule versions, model version, cut-off, binding constraint and applicant-specific reason codes instead of regenerating the answer from today's model.

Two different machines wearing one name

A credit decision is not one computation. It is a deterministic policy filter and a statistical scorecard, composed in a defined order, and conflating them is the fastest way to lose this question.

Policy rules are things the bank has decided it will not do, expressed as conditions on facts. Applicant below the minimum age for the product. Address outside the lending footprint. An existing account in default. A regulatory prohibition. These are hard, binary and auditable, and they are written by risk policy people rather than learned from data. They are also the ones a court or an ombudsman will read literally, so they must be legible as rules and not as coefficients.

The scorecard is different in kind. It consumes bureau data, application data and internal behavioural data, and it produces an estimate of the probability that this applicant goes bad within a defined outcome window. It does not decide anything. It ranks. Whether a given rank is approved depends on a threshold that lives outside the model entirely.

The order matters and you should state it out loud. Hard policy declines run first and short-circuit, because there is no point scoring an application you are forbidden to write, and because if you score first you will eventually explain a decline in terms of a score when the real reason was a rule. Then the score. Then affordability, which is its own calculation on verified income and committed outgoings, and which can decline an applicant the scorecard liked. Then pricing and limit assignment for those who pass, which is where the score is used as a continuous quantity rather than a threshold test.

Where the cut-off comes from

The cut-off is a business decision dressed as a number. You take the score distribution over a representative population, and for each candidate threshold you can read off two curves: the proportion of applicants approved, and the expected bad rate among those approved. Moving the threshold trades one against the other, and the choice is made against the margin on the product, the cost of funds, the loss given default and the appetite the risk committee has signed off.

That means the honest answer to "why is the cut-off there" is never "that is where the model said". It is that at this threshold the portfolio's expected loss sits inside appetite at an approval rate the business can fund. A candidate who can say this — and who knows that different segments and different products carry different cut-offs, and that a swap-set analysis is how you evaluate a change — is demonstrating that they understand the model is an input to a decision made by people.

Cut-offs also drift in effect without being edited. If the applicant mix shifts, the same threshold approves a different population, which is why threshold monitoring is paired with population stability monitoring rather than left alone until the next model refresh.

What an adverse-action explanation demands of the architecture

When you decline, you owe the applicant specific principal reasons for that decision, in terms they can act on. That obligation is unremarkable as a piece of text and brutal as an engineering requirement, because it constrains what you must have captured at the moment of the decision.

Three things follow. First, the decision must be a stored, immutable record, not a log line: the inputs as they were resolved, including which bureau file was pulled and when, the identity and version of every policy rule that evaluated, the model version and the score, the cut-off in force, and the outcome with its binding constraint. Second, the reason must come from the constraint that actually bound. If a policy rule declined the application, the reason is that rule, and quoting the score instead is both wrong and unfalsifiable.

If the score was the binding constraint, the reason must be attributed to this applicant's features relative to the population, not to the model's global importances — "your model weights utilisation heavily" is a fact about the model, not a reason about the applicant. Third, the explanation must be reproducible from the record alone, because the model that made the decision will have been retrained by the time anyone asks.

{
  "decisionId": "d-9f3c1a",
  "decidedAt": "2026-07-14T09:22:41Z",
  "policyBundle": "consumer-unsecured@2026.06.2",
  "scorecard": "uk-unsecured-app-v7",
  "bureauPull": { "provider": "…", "reference": "…", "pulledAt": "…" },
  "inputs": { "…": "resolved values, as used, not as later corrected" },
  "score": 612,
  "cutOff": 640,
  "outcome": "decline",
  "bindingConstraint": "scorecard-cutoff",
  "reasonCodes": ["R14", "R02", "R31"]
}

The bindingConstraint field is the one that earns credit. It is what lets you answer a complaint without re-running anything, and it is what stops the explanation pipeline from having to guess which of several failing conditions was the operative one.

The version you decided under is not the version you have

Here is where competent answers separate from adequate ones. Most candidates will describe generating an explanation. Very few will notice that the explanation must be of a past decision, and that regenerating it against current state produces an answer that is coherent, well formatted and wrong. Retraining changes the score. A policy edit changes which rules fire. A bureau file that has since been updated changes the inputs. Replay against today's system and you may find the applicant would now be approved, which tells the applicant nothing about why they were declined and tells the regulator that you cannot reconstruct your own decisions.

So the model, the policy bundle and the reason-code mapping are all versioned artefacts, retained for as long as the decision must be defensible, and the decision record pins the exact version of each. If your explanation service needs the old scorecard to produce a per-applicant attribution, then the old scorecard has to remain executable, which is an argument for shipping models as immutable, self-contained artefacts rather than as code that only runs against the current library versions.

The parts people forget to mention

Two more signals worth volunteering. Manual overrides need to be first-class: an underwriter who approves outside policy is creating an exception that must be recorded with a reason and monitored in aggregate, because a high override rate means the policy no longer matches what the bank is willing to do and the documented policy has quietly become fiction. And proxy discrimination is not solved by omitting protected characteristics from the inputs, since a feature set drawn from postcode, device and transaction history can reconstruct them; the control is testing outcomes across groups on the decisions you actually made, which is another thing the stored decision record makes possible.

An explainable credit decision is not a model with an interpretability library bolted on. It is an immutable record of which rule or which threshold bound, under which pinned versions, complete enough that the applicant's reason can be derived a year later without running anything current.

---

© 2026 Preptima. Originally published at preptima.com.