GDPR and automated decisions in finance AI

Article 22 does not forbid your model from deciding. It restricts a decision based solely on automated processing that carries legal or similarly significant effects on a person, unless it is necessary for a contract, authorised by Union or member-state law, or backed by explicit consent. Meet one condition and you still owe safeguards. That is the whole game for finance AI.

Most teams read the article as a prohibition and either bolt a human onto every decision or route the whole question to legal and wait. Both are expensive in different ways. The engineering job is narrower: decide which decisions actually fall inside Article 22, build the safeguards those decisions require, and let everything else run straight through.

What counts as an automated decision

The phrase that does the work is “based solely on automated processing” combined with “legal effects” or effects that “similarly significantly affect” the person. Declining a loan, closing an account, freezing a payment, pricing insurance, filing a suspicious activity report that gets someone off-boarded: all of these clear the significance bar without much argument. A fraud score that merely orders a manual review queue usually does not, because a person still decides.

The trap is the word “solely.” A human in the loop only takes you out of Article 22 if that human genuinely decides. The CJEU made this concrete in the SCHUFA judgment (C-634/21, December 2023): a credit score can itself be the automated decision under Article 22 when a third party draws “strongly” on it and the score plays a determining role in whether credit is granted. So the analyst downstream who approves whatever the score says is not a safeguard. They are a formality, and the decision is still automated.

Two questions decide the classification, and both are answerable from your architecture rather than from opinion:

• Does the reviewer have the data, the time, and the mandate to reach a different conclusion? If the interface shows a score and an approve button and nothing else, the answer is no.
• Is there a threshold below which the system acts with no human touch at all, whether that means straight-through approval, auto-decline, or auto-file? Everything under that threshold is squarely in scope.

We map this at the level of the decision, not the model. One model can feed both an in-scope auto-decline and an out-of-scope review queue. The Article 22 obligations attach to the branch, so the branch is where we instrument.

Engineering the safeguards into the runtime

When a decision is in scope, Article 22(3) requires that you let the person obtain human intervention, express their point of view, and contest the outcome. These are runtime capabilities. A policy PDF does not deliver any of them. If the system cannot reconstruct why it decided as it did at the moment it decided, none of the three is real.

That reconstruction is a lineage problem. The right to contest is only meaningful if you can answer, for a decision made on a specific date, what the model was, what features it saw, and what those feature values were at that instant. This is where point-in-time correctness stops being a training-set nicety and becomes a legal obligation. If your feature store serves the current value of a feature when someone contests a decision made two quarters ago, you are explaining a decision that never happened.

Concretely, for every in-scope decision we persist:

• The model version and the exact feature vector as served, snapshotted at decision time, not recomputed on demand.
• The decision, the threshold it crossed, and the reason codes that ranked highest for that specific record.
• Whether a human reviewed it, who, and what they could see and change.

Reason codes deserve care. A SHAP-style attribution over your production features is a defensible basis for the “meaningful information about the logic” that Articles 13 to 15 require, but only if the features are human-legible. “Attribute f_2291” explains nothing to a data subject and nothing to a regulator. We resolve attributions back to named, documented features before they leave the system, and we keep the mapping under version control so an explanation given in June is still reproducible in December.

The explanation you actually owe

There is a persistent myth of a broad “right to explanation” in GDPR. The enforceable text gives the person meaningful information about the logic involved and the significance and envisaged consequences of the processing (Articles 13 to 15). The explicit right to an explanation of a particular decision lives in Recital 71, which guides interpretation but does not create a standalone obligation. Sector rules often go further. A US adverse-action notice must state specific principal reasons, and EU consumer-credit law now requires a meaningful explanation when a refusal rests on automated assessment. Both set a higher bar than GDPR alone.

We build to the stronger requirement and let it satisfy the weaker one. That means the reason codes generated for an adverse-action notice are the same artifacts that answer a GDPR access request, drawn from the same snapshot, so the story a person is told never depends on which regulation prompted the question. Divergent explanations across channels are how organisations get caught, because the person compares them.

None of this requires a human to touch every decision, which is the fear that stalls these projects. It requires that in-scope decisions carry an audit trail dense enough to reconstruct and contest them, that the human-review path have real authority where you claim one, and that the threshold separating automated from reviewed be a deliberate, documented number rather than an accident of where someone set a cutoff. Build those three and straight-through processing and Article 22 stop being in tension.