Explaining a Decline

In one line: you owe the customer an explanation, you owe the regulator a specific one, and every explanation is also a hint to whoever is probing you.

Three audiences, three explanations

The customer needs to know what to do next. Not why the model scored them — what action resolves it. "Try a different payment method" or "verify your identity here" is useful; "this transaction was flagged as high risk" is not.

The analyst needs to know which signals drove the score, so they can judge the case quickly. This is the richest explanation and the one that most directly affects operational cost — an analyst who has to reconstruct the reasoning from raw features reviews a fraction as many cases.

The regulator needs a specific, documented reason and evidence that the decision was not made on prohibited grounds. In credit and lending contexts an adverse action notice is a legal requirement with defined content, not a courtesy.

The regulatory row is the one that constrains the architecture. If you must be able to state a reason, the system must be able to produce one for every decision — which is a design requirement, not a feature to add later.

The tension

Every explanation teaches the attacker something.

"Declined because this device has attempted several cards recently" tells a fraudster to rotate devices. "Declined because the shipping address does not match billing" tells them to match the addresses. Each explanation is accurate, useful to the customer, and a specification for evasion.

There is no clean resolution, and the practical position is to vary specificity by audience and by confidence.

To the customer: generic, and action-oriented. "We could not process this — please try another card or contact us." It says what to do without saying what triggered it.

To the analyst: complete. They are trusted, and the operational cost of hiding things from them is large.

To the regulator: complete, in the required format, through the required channel.

And where a decline is high-confidence fraud, say less. Where it is a borderline case likely to be a real customer, say more — because that customer needs to recover, and the information leak is smaller when the case was ambiguous anyway.

Producing reason codes

The mechanism, and it is worth knowing that this constrains model choice.

From rules it is direct: the rule that fired names itself, which is one of the underrated arguments for keeping rules.

From models, feature attribution — which features moved this prediction most, relative to a baseline. Shapley-value-based methods are the standard tool. Two practical difficulties: computing attributions inside a fifty-millisecond budget is not free, and raw feature names are not customer-facing language, so there has to be a mapping from feature to human-readable reason.

A monotonic model is the option most candidates do not know and regulated lenders use heavily. Constrain the model so each feature can only move the score in one direction — more prior fraud on this device can only increase risk, never decrease it. That costs some accuracy and makes explanations trustworthy and stable, which is often the correct trade when the alternative is a model you cannot defend.

That trade — a small accuracy loss for an explanation you can stand behind — is a genuinely good thing to raise, because it shows the regulatory constraint shaping the modelling rather than being bolted on.

Appeals

If you decline people, some declines are wrong, and the wrong ones are exactly the ones you cannot see. An appeal path is both the fair thing and your best source of false-positive labels — the same argument as guardrail appeals, with money attached.

Three requirements, and all three are commonly missed.

Visible at the point of decline. An appeal buried in a help centre generates no signal, because nobody finds it.

Fast. A customer who wanted to buy something today does not care about a decision in five working days. Bounded turnaround, ideally hours.

Fed back automatically. An overturned decline should update the training data and the evaluation set, not just the individual case. Otherwise the same customer is declined again next week and the system has learned nothing.

That third one is where appeal processes usually fail. The case is resolved, the customer is served, and the model that made the error is never told.

Fairness, and why it is structural here

Fraud models are trained on labels shaped by past decisions, so historical bias propagates directly — and unlike a recommender, the consequence is that someone cannot buy things or open an account.

Three obligations worth stating:

Measure decline rates by protected characteristic, where you may legally hold that data, and where you may not, by proxy segments such as geography. You cannot manage disparity you do not measure.

Beware proxies. Postcode encodes a great deal. A model given a postcode learns the demographic pattern whether or not anyone intended it, and it will look like a legitimate risk signal because it correlates with historical labels.

Watch the graph features specifically. Guilt by association is a fairness problem with a technical name — a legitimate customer inheriting risk from a shared household device or a shared address block has done nothing, and the mechanism is invisible to them.

The design response is the one from the graph lesson: keep such signals as model inputs rather than as rules, so their weight is learned in context, and hold the disparity metrics as guardrails on every model change.

Next: measuring whether any of this is working.