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

The FCA's Consumer Duty came into force in July 2023. Most firms treated it as a policy and governance exercise — update the board pack, review the product governance framework, update the complaints procedure. That work is necessary. But Consumer Duty also has direct technical implications that don't show up in the policy documentation.

The core obligation is to demonstrate good outcomes for retail customers. Demonstrating this requires evidence. Evidence requires data. Data requires a system that captures the right information at the right points in the customer journey. If the system doesn't capture it, the evidence doesn't exist, and the demonstration is impossible.

The affordability assessment is the most concrete example. MCOB 11.6 has required documented affordability assessments for mortgage lending for years. Consumer Duty adds a quality dimension: the assessment must be appropriate to the customer's circumstances. To demonstrate appropriateness after the fact, you need the inputs, the outputs, and the rationale — all stored immutably at the point of assessment.

What 'immutably stored at the point of assessment' means technically: a database record that captures the customer's income figure, the stress test rate used, the maximum loan amount produced, the product recommended, and the timestamp. The record must not be editable after creation. If the affordability needs to be reassessed, a new record is created. The original is retained. This is not a complicated data model — but it needs to be designed intentionally.

ESIS and KFI documents have a similar requirement. The document delivered to the customer must be reproducible. If the FCA asks, twelve months later, what information a customer received before taking out a product, you need to be able to produce the exact document. This means storing either the full document or the complete set of inputs from which it was generated, plus the template version. A content hash that allows you to detect tampering helps.

Customer communication records under Consumer Duty need to meet FCA record-keeping requirements: generally three years for non-designated investment business, five years for designated investment business. The system needs to store the communication type, the content or a reference to it, the timestamp, and the delivery confirmation. For email this is standard. For WhatsApp, SMS, or in-app notifications, it requires intentional design.

Product suitability documentation is where many firms are underprepared. If your platform recommends products to customers, the recommendation rationale needs to be captured. Not just the product recommended — but why it was recommended given the customer's circumstances. This is a structured data problem. The recommendation engine needs to produce a record that captures the suitability criteria assessed and the outcome. This record must be tied to the customer record and retained.

The practical implication for engineering teams: Consumer Duty is not a compliance checkbox. It is a set of data retention and audit trail requirements that need to be present in the system architecture from the start. Retrofitting them to a system that wasn't designed for them is expensive. Designing them in from the beginning adds perhaps 15–20% to the initial schema design work, and saves a compliance remediation project later.

We've built these patterns into Gable Mortgages' platform from day one. The FCA sign-off reflected it. This isn't magic — it's standard compliance engineering applied before the architecture decisions were locked.

Working through a similar problem?