The FCA Consumer Duty came into force in July 2023. Three years later, I'm still walking into firms where the compliance team has signed off "Consumer Duty compliant" and the actual system architecture tells a different story.
The Duty isn't a box to check. It's an ongoing obligation to monitor and evidence that customers are receiving good outcomes across four areas: products and services, price and value, consumer understanding, and consumer support.
That obligation has technical implications that your compliance consultant won't tell you about—because most compliance consultants don't know what they're looking for in a database schema.
This is the checklist I use when assessing whether a firm's technology stack actually supports Consumer Duty compliance.
Outcome 1: Products and Services
The Duty requires you to demonstrate that your products are designed for the target market and produce good customer outcomes. Technically, this means:
Customer segmentation data must be captured and queryable. You need to be able to run "what percentage of customers using Product X are in the target market defined in the product design document?" If your CRM doesn't segment customers by the same dimensions as your product target market definition, you can't answer that question.
Product performance monitoring at the customer level. Aggregate product metrics are insufficient. You need individual-level outcome data: did each customer who bought this product achieve the outcome it was sold to deliver? For a savings product, that's whether the customer actually saved money. For an insurance product, that's whether claims were paid appropriately.
Audit trail on product eligibility decisions. When a customer is sold a product, what data was available to the system at the point of sale, and what rules determined eligibility? This needs to be queryable by customer ID and by decision date.
Outcome 2: Price and Value
The Duty requires you to monitor whether the price customers pay delivers fair value relative to the benefit received. Technically:
Unit economics at the customer segment level. Not just company-wide profitability—you need to be able to compare the margin profile of customers who achieve good outcomes versus those who don't. If your highest-margin customers are also the ones with the worst outcomes, that's a fair value problem.
Pricing rule version history. Every change to your pricing algorithm or fee structure must be versioned and timestamped with the ability to reconstruct what any customer would have been charged at any historical point.
```sql -- Version your pricing rules CREATE TABLE pricing_rules ( id UUID PRIMARY KEY, version INTEGER NOT NULL, effective_from TIMESTAMPTZ NOT NULL, effective_to TIMESTAMPTZ, rule_definition JSONB NOT NULL, created_by UUID REFERENCES users(id), approved_by UUID REFERENCES users(id), created_at TIMESTAMPTZ DEFAULT NOW() );
-- Link every charge to the rule version that generated it CREATE TABLE customer_charges ( id UUID PRIMARY KEY, customer_id UUID REFERENCES customers(id), amount DECIMAL(12,4) NOT NULL, currency CHAR(3) NOT NULL, pricing_rule_version_id UUID REFERENCES pricing_rules(id), charged_at TIMESTAMPTZ NOT NULL ); ```
Refund and fee waiver tracking with rationale. Every time you waive a fee or issue a refund, the data needs to capture why, by whom, and what outcome was achieved. This data informs your fair value assessments.
Outcome 3: Consumer Understanding
Customers must be able to understand the product and the information you provide about it. Technically:
Communication audit logging. Every substantive communication with a customer—email, push notification, in-app message—must be logged with timestamp, content version, and delivery confirmation. The FCA can ask "what did customer X receive and when?" You need to be able to answer that.
Disclosure version management. When you update your terms, fee schedule, or key product information document, you need to know which version each customer has seen and whether they have acknowledged it.
```typescript interface CustomerDisclosure { customerId: string; documentType: 'terms' | 'key_information' | 'fee_schedule'; documentVersion: string; presentedAt: Date; acknowledgedAt?: Date; // null if presented but not yet acknowledged presentationChannel: 'web' | 'mobile' | 'email'; ipAddress?: string; userAgent?: string; } ```
Readability scoring on outbound communications is increasingly expected. Tools like the Flesch-Kincaid readability score can be applied to email templates and in-app copy programmatically during content review.
Outcome 4: Consumer Support
Customers must be able to get support that meets their needs. Technically:
Complaint handling pipeline with full audit trail. Every complaint—regardless of channel—must be logged with intake timestamp, classification, assigned owner, action taken, and resolution. Regulatory reporting on complaint handling metrics is required, so this data must be aggregatable.
Vulnerable customer identification and accommodation. The FCA expects firms to identify customers who may need additional support. The technical implementation: a vulnerability flag on the customer record, with version history showing when it was set and by whom, and system behaviour changes triggered by that flag—slower timeouts on automated calls, escalation to human support on first contact attempt, exclusion from certain automated communication flows.
Response time SLA monitoring. Track the time between complaint receipt and first substantive response, between first response and resolution. Breach of SLA must trigger automated escalation. These metrics are reviewed by the FCA during supervision.
The Audit Question
The test I apply to every system I'm assessing: imagine an FCA supervisory review. They request the complete interaction history for customer ID 12345 from inception to present, including every communication, every transaction, every pricing decision, every vulnerability flag change, and the rationale for each.
Can you produce that in four hours?
If the answer is no—if you'd need to query five different systems, export to spreadsheets, and manually correlate the data—your architecture doesn't support Consumer Duty compliance regardless of what your compliance documentation says.
Build for auditability from the start. It's not technically complex. It requires discipline about logging, version control on decisions, and a data model that preserves history rather than overwriting it. These are not expensive architectural choices. But they are architectural choices, and retrofitting them onto a system that wasn't designed with them is substantially more painful than building them in.
Consumer Duty compliance is ultimately a data problem. The firms that get it right are the ones whose engineers understood that before the lawyers told them it was a requirement.