The 3-layer AI architecture that keeps you FCA-compliant.

Every FCA-regulated firm I have walked into in the last eighteen months has an AI project in a bottom drawer somewhere. A chatbot the CMO commissioned. A KYC summariser someone forwarded from a fintech blog. A dealer-desk call scorer. Almost all of them are dead. Almost none of them died because the model was bad. They died at compliance, and they died at compliance because compliance was a review gate at the end of the project instead of an architectural layer at the beginning.

This note is the architecture we build instead — the exact three layers every KJ Capital engagement now ships in production, in the order they are designed. If you take one thing away from it, take this: an AI system inside an FCA-regulated firm is not a model with compliance bolted onto the side. It is a compliance envelope that happens to contain a model.

Layer 1 — the policy layer

The policy layer is a machine-readable expression of what your regulator requires of this specific system. Not a PDF. Not a paragraph in an SMF holder’s handbook. Executable rules.

In practice it is a small typed schema — usually a few hundred lines — that encodes exactly which data classes may enter each model call, which outputs are allowed, which are prohibited, what must be logged, what must be human-reviewed before it reaches a customer, and what triggers an automatic escalation. Every call the system makes passes through this layer before it reaches a model, and every response passes through it again on the way back.

Consumer Duty, SM&CR, SYSC 8 outsourcing, MiFID II record-keeping, PROD 3 governance — all of them collapse into rules the policy layer can express. Once the rules are code, three things become true that are not true in a policy-PDF world. You can prove enforcement rather than assert it. You can update policy in an afternoon rather than a quarter. And when the regulator asks how you would demonstrate control of the system, the answer is a file, not a meeting.

What the policy layer actually contains

Every project is different, but the shape repeats. A typical brokerage or wealth-manager policy layer expresses:

• Data classes with tags (PII, MNPI, transaction data, marketing content) and rules for which can appear in which prompts.
• Output guardrails: what is a suitability recommendation, what is a factual answer, what is marketing — and which of those need human sign-off before customer delivery.
• Retention and residency rules mapped to specific model providers, so a call that would send a certain data class outside the UK simply cannot execute.
• Escalation triggers: confidence below X, disagreement between primary and shadow model, sentiment matching vulnerability indicators, mention of a sanctioned entity.
• Immutable audit hooks — every call is logged with policy version, model version, retrieval sources, and reviewer if one was involved.

Layer 2 — the retrieval and grounding layer

No customer-facing output in a regulated firm should ever be a raw model completion. Every answer, every score, every summary must be grounded in retrieved, cited, versioned source material — your KYC packs, your product terms, your compliance library, your policy documents, your regulator guidance. If the model cannot cite, the model does not answer. That rule alone kills 80% of the failure modes CCOs are worried about.

The retrieval layer is where most in-house AI projects quietly fall apart. Firms buy a vector database, drop a folder of PDFs into it, and call it RAG. Six months later, the system is confidently citing an out-of-date terms document, or worse, mixing terms from a legacy jurisdiction into a UK response. The regulator finds this in a spot check, and the project ends.

The version we build is more disciplined. Sources are versioned per-jurisdiction, per-product, per-effective-date. Retrieval is filtered before the model ever sees a chunk — the wrong jurisdiction cannot even be retrieved. Every response includes not just a citation but the exact retrieved passage, the source document, and the version of that document that was active at the time the answer was generated. When the regulator walks in tomorrow and asks why on the 14th of March a client was told X, you produce the answer, the passages, and the policy version in under five minutes.

Layer 3 — the evaluation and audit layer

The third layer is where firms without deep AI experience almost always underinvest. Evaluations — evals — are the difference between an AI system you can defend and one you cannot.

Every output in a regulated deployment is scored, in near-real-time, against a rubric: is it factually accurate against retrieved sources, does it violate any policy-layer rule, does it exhibit hallucination indicators, does it match tone and reading-age constraints, is it a suitability nudge dressed up as a factual answer. Scores below threshold are routed to a human. Every score is stored. Every model version is stored. Every retrieval version is stored. Together they form the audit substrate you show a supervisor.

This is the layer that lets you upgrade a model. Without evals, swapping GPT-4 for Claude in production is an act of faith. With evals, it is a measurement. You compare the two systems against a scored test set derived from your own production traffic, and you make an informed call. Firms without an evals layer cannot upgrade safely, which means they get stuck on whichever model they launched with, which means they lose ground month over month.

The five metrics we always score

Rubrics are firm-specific, but the same five categories show up in every deployment. Anything below these is not a compliance-safe evals layer.

• Factuality against retrieved sources — did the model stay inside its citations?
• Policy compliance — did any output breach a policy-layer rule, even one that the guardrails caught?
• Vulnerability indicators — did the customer signal financial hardship, cognitive impairment, or coercion, and did the system respond appropriately?
• Suitability drift — did a factual answer creep into a personal recommendation the firm is not permissioned to give?
• Tone and reading age — Consumer Duty demands communications a reasonable customer can understand.

Why the three layers are non-negotiable

The temptation, in every project, is to ship two of the three and promise the third for phase two. Firms ship policy + retrieval and skip evals because evals feel like a testing problem. They ship retrieval + evals and skip policy because policy feels like a legal problem. They ship policy + evals and skip retrieval because it feels like a data-engineering problem.

In every one of those cases, the system that goes into production is not the system that goes into a regulator conversation. The pattern is so consistent I now write it into engagement letters: if any of the three layers is deferred, the project is descoped rather than accelerated. The alternative — shipping a compliance-fragile system into a regulated firm and letting the CCO sort it out — is unprofessional at best and career-ending at worst.

The good news is that the three layers, built together from day one, do not slow projects down. They speed them up. Every downstream decision — which model, which vendor, which use case to open next — becomes a straightforward call instead of a compliance negotiation. The firm moves faster because the compliance envelope is settled.

The regulator conversation

The FCA has been increasingly public about what it expects from AI in regulated firms — a Consumer Duty lens on every customer-facing model, SM&CR accountability for the SMF holder responsible for the system, a documented model-risk-management framework, and evidence of ongoing monitoring rather than one-off validation. The three-layer architecture maps to each of those expectations directly. Policy layer → controls. Retrieval layer → evidenceable grounding. Evals layer → ongoing monitoring.

In practice, the conversation looks like this. A supervisor asks how you know your AI is not giving unsuitable advice. You open a dashboard, filter to the last thirty days of customer-facing outputs, show the eval scores, show the sample of human-reviewed edge cases, show the policy version that was in force, and — if pushed — replay any specific output with the exact passages retrieved. The whole demonstration takes ten minutes. Every firm we have taken through this has ended the conversation with a lower risk rating than they started with.

What this means for your current pilot

If you have an AI pilot in a bottom drawer right now, the honest test is short. Can your team produce the machine-readable policy that governs its outputs, the versioned source library it retrieves against, and the eval scores from the last seven days of runs — in under twenty minutes? If yes, you have an architecture. If any of those does not exist, you have a demo.

The good news is that going from demo to architecture is a six-to-ten-week engagement, not a rewrite. The bad news is that most firms lose six to twelve months first, trying to bolt compliance onto a system that was never designed to accept it. If you would rather skip that step, the £15k Financial AI Diagnostic maps your current state onto the three-layer architecture and produces a costed build plan in two weeks.