Consumer Duty and AI in UK financial services

The FCA’s Consumer Duty raises the burden of proof on automated decisions. Any decision that affects a retail customer must now be reconstructable after the fact and defensible against four outcomes: products and services, price and value, consumer understanding, and consumer support. A model that cannot show why it decided what it decided is a conduct-risk liability, however accurately it scores.

The Duty adds no model standard and no statute number you can cite in a design review. It is written as principles and cross-cutting rules, so it never tells you which log lines to keep. That is an engineering decision. Under the old regime a pricing model or a decline engine was judged mostly on whether it worked. Under the Duty it is judged on the outcome it produced for a named person on a given date, and on whether the firm can demonstrate that outcome was good. Accuracy is necessary and no longer sufficient. Most of the failures I see are engineering failures dressed up as governance gaps.

What the Duty actually asks a model to show

The cross-cutting rules are the part that bites: act in good faith, avoid foreseeable harm, and enable customers to pursue their financial objectives. Translate those into questions you can put to a running system.

• For a given decision, what were the exact input features, the model version, and the threshold in force at that moment? This is point-in-time correctness. If your feature store serves current values but you cannot replay historical ones, you cannot answer.
• Was any input a proxy for something you would not price on directly? Postcode standing in for ethnicity, or a device signal correlated with age, produces foreseeable harm even when no protected attribute appears in the training data.
• Where the outcome was adverse, is there a specific reason the customer can act on? The consumer understanding outcome and the adverse-action logic overlap here, and a generic disclosure satisfies neither.

None of that is satisfied by a model card or a fairness report run once at deployment. The Duty is an ongoing obligation, so the evidence has to be produced continuously by the pipeline rather than assembled by hand when a review lands.

Fair value is a lifecycle question

Price and value is where AI creates the most exposure, because dynamic and personalised pricing is exactly what modern systems are built to do. The rule is that price must be reasonable relative to the benefit the customer receives. A model that optimises for margin will, left alone, learn to charge the most to the people least likely to shop around. Nothing is malfunctioning when this happens. The model is doing exactly what it was trained to do, and the Duty treats that result as harm.

Engineering for fair value means building the value assessment into the decision path rather than reviewing it quarterly:

• Segment outcomes and monitor them by cohort, including price walking on renewal, claims ratios where relevant, and the gap between best and worst price offered for materially similar risk.
• Set a defensible ceiling on personalisation. If the model can price two near-identical customers very differently, you need a documented reason for the spread, or a cap that closes it.
• Watch for drift that erodes value silently. A retention model retrained on recent behaviour can start penalising loyalty without anyone touching a business rule. Here, drift monitoring earns its keep as a conduct control, not only as a check on predictive accuracy.

The firms that struggle are the ones that ran a value assessment at launch, filed it, and let the model keep learning. The assessment goes stale the moment the model updates.

Build the evidence trail into the pipeline

The Duty makes a demand that maps cleanly onto data engineering: reproducibility. When a review or a complaint arrives, you need to reconstruct the decision precisely, and that is only possible if the pipeline was designed for it from the start.

• Version everything that touches a decision together: the model artefact, the feature definitions, the threshold configuration, and the input snapshot. A decision record should point to all four by immutable reference.
• Guard against lookahead and leakage in the features that feed outcome monitoring, not just training. If your fair-value dashboard uses a feature computed with information that was not available at decision time, the dashboard is telling you a comforting lie.
• Keep lineage from raw source to served feature, so that when entity resolution merges two customer records you can show the decision used the right one. Misattributed decisions are a fast route to a foreseeable-harm finding.
• Give the audit trail a retention horizon that matches the product, not the log-rotation default. A mortgage decision may need to be explainable years later.

The cost here is real and front-loaded. Retrofitting point-in-time reconstruction onto a system built to serve current scores is expensive and often only partly possible. Doing it at design time comes down to a schema decision and a discipline about what you write on every decision.

What outcome monitoring has to measure

The last piece separates a compliant paper exercise from a working control. Consumer Duty holds a senior manager accountable for outcomes, so the monitoring has to measure outcomes that manager can be questioned on. AUC and precision tell no one whether customers got a good deal.

Build the monitoring around outcome signals: complaint rates by cohort, decline reasons that cluster in ways that suggest a proxy, the share of customers who could have got a better outcome elsewhere in your own book, and support friction such as customers who abandon a straight-through process and never come back. Set a false-positive budget for any control that blocks or flags a customer. An over-eager fraud or affordability model creates its own harm by excluding people who should have been served.

Treat every one of those signals as a control with an owner, a threshold, and an escalation path. The Duty exists to catch a bad outcome while it is happening to a hundred customers, before it reaches ten thousand and surfaces in the complaints data at quarter-end. A report compiled after the fact has already missed the moment that mattered.