At a Glance
- What this covers: Why FCA AI governance cannot be retrofitted, what AI SDLC governance requires at each development phase, and the three engineering decisions that determine whether your AI system will pass FCA examination.
- Key finding: The most expensive governance failure in regulated AI is not building a non-compliant system. It is building a technically excellent system that cannot demonstrate its own compliance – because it was never instrumented to produce the evidence.
- Business impact: FCA compliance retrofitted after deployment costs 2-5x more than governance built from sprint one. Four things FCA examiners now routinely request cannot be reconstructed after the fact – they must be captured at the time of every inference.
- What you will learn: The four things FCA examiners request that most AI systems cannot produce, what AI SDLC governance changes at each phase, and the three engineering decisions that separate systems that pass FCA examination from those that generate findings.
FCA compliant AI development is the engineering discipline of building explainability, independent validation, and audit logging into a regulated AI system from sprint one – not adding them after deployment when the evidence they were meant to capture no longer exists.
FCA compliance is not a sign-off stage at the end of an AI delivery. It is an architecture decision made at the start of one. Every week a regulated AI system operates without a built-in AI assurance framework is a week of governance debt accumulating – at 2-5x the cost of building it correctly from the beginning.
The FCA’s AI guidance is explicit: regulated firms must demonstrate that AI systems are transparent, explainable, and operating within defined risk parameters. Those demonstrations cannot be produced retrospectively for a system that was not built to produce them. Part of Systango’s AI Governance Layer services series.
I. Why FCA AI governance cannot be retrofitted
The most expensive governance failure in regulated AI is not building a non-compliant system. It is building a technically excellent system that cannot demonstrate its own compliance. Four things FCA examiners now routinely request – and most AI systems cannot produce:
What we typically see in delivery
Across FCA-regulated engagements, the same sequencing mistake shows up at nearly every phase transition:
- Discovery gets treated as a technical scoping exercise, with regulatory requirements mapped later or by a separate compliance team – so the architecture is already partly locked before anyone checks it against FCA, SR 11-7, or PCI DSS requirements.
- Independent validation gets scoped as a checkbox to satisfy before go-live, rather than a workstream with its own team and timeline set up before training begins – which means “independent” ends up meaning “reviewed by someone else on the same team,” not a genuine separation.
- Deployment and governance get treated as sequential rather than simultaneous – the model ships, and the audit logging, drift monitoring, and RBAC enforcement follow “shortly after,” which is exactly the gap that leaves months of ungoverned inference with no retrospective fix.
None of these are compliance failures at the point they happen – each phase’s engineering work is usually done well on its own terms. They’re sequencing failures: the regulatory requirement arrives at the wrong phase to be built in properly, so it either gets skipped or bolted on later at the 2-5x retrofit premium.
II. AI SDLC governance: what changes at each phase
Discovery and scoping
Define regulatory requirements before any architecture is designed. Identify which FCA rules apply – Consumer Duty, MiFID II Article 25, SR 11-7, PCI DSS. Document explainability requirements per decision type. This is the phase where most teams skip FCA AI governance – and where skipping it costs most.
Data preparation and model design
Data provenance must be documented at the point of use, not reconstructed from memory. Training data bias assessment must be completed before training begins. Machine learning compliance at this phase means treating data lineage as an engineering output, not a compliance document.
Development and testing
Independent model validation must be structured before the model trains – with a separate scope, separate owner, and documented independence record. AI regulatory compliance fintech at the testing phase means the validation workstream is set up before the build, not commissioned after deployment.
Deployment and production
The AI assurance layer goes live with the model – not after it. Audit logging, drift monitoring, and RBAC enforcement must be active on day one. A model deployed without its governance layer is not FCA compliant, regardless of how well-governed the development process was. See our AI Engineering & MLOps services for how Systango structures governed deployments.
Ongoing monitoring and change management
Every parameter change, retraining event, and model update must be version-controlled and logged. AI compliance framework fintech at this phase means treating the model governance record as a living document – updated at every change, queryable at every audit.
See our AI-native SDLC page for how these phases are structured as a single delivery framework, rather than five separate governance workstreams.
III. Three engineering decisions that determine FCA examination outcomes
Explainability architecture designed before the model trains: post-hoc explainability tools can approximate explanations for some model types. They cannot produce decision-level traceability the FCA now requires for Consumer Duty compliance. Explainability must be a design requirement from the first sprint.
Independent validation structured as an engineering workstream: validation by the team that built the model does not satisfy SR 11-7 or FCA model risk management expectations. A separate scope, separate team, and documented independence record must be planned before development begins.
Audit logging treated as a first-class engineering deliverable: a complete AI assurance record – inputs, outputs, model version, permission context – must be captured at every inference from day one. Logs started six months after deployment cannot backfill six months of missing evidence.
What this looks like when built correctly
Full case study available here.
Key Takeaways
- The Delivery Snapshot above shows what this looks like in practice: 90% faster compliance reporting and a 50% reduction in post-release defects, achieved by making the assurance layer an engineering deliverable rather than a compliance task bolted on afterward.
- Independent validation by the build team does not satisfy SR 11-7. A separate scope, separate team, and documented independence record must be planned before the first sprint.
- The five SDLC phases in Section 2 each require a different governance action – regulatory mapping at discovery, provenance and bias assessment at data preparation, independent validation before testing, live governance at deployment, and version-controlled change logs afterward. Skipping the requirement at its correct phase is what turns it into a retrofit later.
Most teams are confident their AI system is compliant – the real gap is usually the ability to prove it to a regulator on demand, not the underlying model or architecture itself.
Systango’s AI-native SDLC embeds five governance components into every FCA-regulated AI delivery: decision traceability at inference, training data provenance registry, automated drift detection, reproducible output logging with cryptographic signing, and independent validation documentation structured for FCA examination.
Every FCA compliant AI development engagement begins with regulatory requirements mapping before any architecture is designed – translating FCA rules into engineering specifications, not compliance checklists. As a publicly listed, ISO 27001 certified engineering company with active FCA regulatory delivery experience, explore our AI-native SDLC and AI Readiness Assessment to understand how we approach your specific compliance challenge.
