Consumer Duty at the code level: what it actually requires.

In full

Consumer Duty is usually handed to the compliance team as a policy document, summarised into a slide deck, and filed. That is how firms end up technically compliant on paper and exposed in production. Read closely, most of the FCA's Consumer Duty is not a policy at all. It is a set of engineering requirements waiting to be written down. If your software cannot produce the evidence, a policy that says you comply is worth very little.

The translation problem

The Duty asks firms to deliver good outcomes for retail customers and, crucially, to be able to demonstrate it. "Demonstrate" is the word that turns a policy into an engineering brief. You cannot demonstrate an outcome you did not record, and you cannot record what your architecture was never built to capture. A firm with the right policy and the wrong data model will fail the part of the Duty that actually bites: evidence.

The Duty does not just ask you to treat customers fairly. It asks you to prove you did, case by case, after the fact.

So the real question is not "do we have a Consumer Duty policy?" It is "when the regulator asks about one customer on one day, can our systems reconstruct what we told them, what we knew, and why we acted as we did?" That is a software question.

Four Duty requirements that are really engineering requirements

1. Avoiding foreseeable harm means recording the inputs

To show you avoided foreseeable harm in a decision, you need to show what the decision was based on. That means capturing the state at the moment of the decision, not just the outcome. If the underlying data has since changed and you only stored the result, you cannot prove the decision was reasonable on what was known then.

2. Consumer understanding means versioned communications

The Duty cares whether customers understood what they were told. To evidence that, every customer-facing communication has to be versioned and reproducible: you must be able to show the exact wording a specific customer saw on a specific date. A template that has since been edited is not evidence of what they actually received.

3. Good outcomes mean measurable outcomes

"Good outcomes" cannot be asserted; they have to be observed across the customer base. That requires the data to be queryable for outcome patterns, not locked in per-customer records you can only read one at a time. The monitoring the Duty expects is a reporting architecture, not a quarterly meeting.

4. Demonstrability means a queryable audit trail

Underneath all of it sits the same requirement: an immutable, queryable record of decisions, communications, and the data behind them. Without it, every other control is an assertion. With it, a regulator's question becomes a query rather than a fire drill.

Where firms get caught

The pattern we see repeatedly is a firm that passed its policy review and still cannot answer a case-level question, because the system was built before the Duty was treated as a software requirement. The data is mutable, communications are templated without versioning, and the audit trail records events but not the state behind them. The policy is immaculate. The evidence does not exist.

• Outcome stored, inputs discarded. You can show what you decided, not that it was reasonable.
• Communications templated, not versioned. You can show the current template, not what the customer saw.
• Audit trail mutable. You can show a record, not that it is the original.

Building the Duty into the architecture

The fix is to treat the relevant Duty obligations as schema decisions, made before application code. State capture on regulated decisions, versioned and reproducible customer communications, an append-only audit trail, and an outcomes data model you can actually query. Build those and the Duty is a property of the system. Skip them and the Duty is a promise your software cannot keep.