What the FCA's October AI Statement Means for Teams Building Financial Products: Good Practice, Poor Practice and Disclaimers on AI Advice
Product and risk teams building AI into regulated products have been asking the same question for months: what does the FCA actually expect? On 19 October the regulator gave a partial answer. It published examples of good and poor practice in AI, said that AI providers should add disclaimers to AI financial advice, and acknowledged agentic finance. It also made a choice that matters more than any single item on that list: it is applying existing frameworks to AI rather than writing new rules for agents.
This article is deliberately narrow. It is built only on that 19 October evidence, it separates what was reported from what we infer, and it ends with a control checklist that is our own analysis, not the FCA's. It is not legal advice, and anyone acting on it should read the FCA's own text first.
What the FCA said on 19 October, and what we cannot tell you
The statement was made in a speech published on the FCA's website. As reported, it contained four points relevant to product teams.
- AI providers should add disclaimers to AI financial advice.
- The FCA published examples of good and poor AI practice.
- The FCA acknowledged agentic finance, meaning AI systems that act, not just advise.
- The FCA is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating new rules for agents.
That is the extent of what we are prepared to put in the reported-fact column. We have not reproduced the FCA's lists of good and poor practice, because our evidence is a summary of the speech rather than a full reading of it, and a paraphrase of a regulator's examples is precisely the kind of thing that drifts from the original. If you build products in this area, read the source and map it to your own features. Treat everything below as a way of organising that work, not a substitute for it.
We have also not set out to cover the wider regulatory picture around agentic AI and governance, which we have written about before. This piece is limited to what changed on 19 October.
The important point: existing frameworks, not new rules
It is tempting to read a regulatory statement on AI as the start of a new compliance category with its own checklist and its own deadline. The reported position points the other way. The FCA is saying, in effect, that the obligations you already carry apply to AI-driven activity, and that it expects firms to work out what that means in practice.
Our interpretation is that this puts the weight on product design rather than paperwork. A rulebook written for AI agents would give teams something to tick off. Existing frameworks demand something harder: that you show how a particular AI feature, in a particular journey, meets standards you were already held to.
What "existing frameworks" implies for a product team
Two of the frameworks named in the reporting are worth thinking through in product terms.
Consumer Duty is concerned with outcomes for retail customers. For an AI feature, the question is not whether the model is sophisticated but whether the customer ends up better or worse off, whether they understood what they were being told, and whether the firm can evidence that it checked. A feature that produces fluent but unreliable financial guidance has a Consumer Duty problem regardless of how it is labelled.
Senior-manager accountability is concerned with named responsibility. For an AI feature, someone senior has to be answerable for it. That is easy to say and awkward to do when the feature spans product, data science, engineering and compliance. Teams that cannot say who owns an AI system's behaviour in production are exposed whatever the technology.
Neither point is new, and that is the point. The regulator has not created a safe harbour for AI, and it has not created an exemption either.
Disclaimers on AI advice: useful, but not a control
The reported expectation that AI providers add disclaimers to AI financial advice is the part most likely to be implemented badly, because it is the part that is easiest to implement at all.
A disclaimer is a disclosure. It tells a customer something about the nature of what they are reading. That has value, and the FCA's signal suggests it is expected. But a disclaimer does not change the quality of the advice, and it does not turn an unsafe design into a safe one. Our view is that teams should treat it as one element in a set of controls, not as the control.
Some practical implications follow, and they are analysis rather than requirements.
- Place the disclosure where the customer meets the output, not in terms and conditions. A notice nobody sees does little work.
- Make it specific about what the AI is doing. "This is AI-generated" tells a customer less than a plain statement of what the output is and what it is not.
- Keep it consistent across channels. If your app, web journey and chat all present AI output, the disclosure should not vary between them without reason.
- Do not let it carry weight it cannot bear. If the feature would be hard to defend without the disclaimer, the disclaimer is not the fix.
We are deliberately not proposing wording. The reporting does not give us the FCA's expectations on form or content, and we would rather say so than guess. That is another reason to read the speech itself.
Reading "good and poor practice" without the list in front of you
A published set of good and poor practice examples is more useful than a rule, if you use it well. It gives you test cases.
Once you have the FCA's text, a sensible process is as follows. List the AI features in your product and in your roadmap. For each, read the good-practice examples as questions you should be able to answer, and the poor-practice examples as failure modes you should be able to rule out. Where you cannot answer or rule out, you have found a design task, not a compliance task.
It is worth doing this per feature rather than per product. An AI summary of account activity, an AI assistant that answers questions about a product and an AI system that recommends a financial action are different things with different risk profiles, even if they share a model. Treating them as one "AI feature" is how weak points hide.
A control checklist for teams building AI into regulated products
What follows is Innovify's analysis of the controls a product team would sensibly want in place, given the reported direction of travel. It is not the FCA's list, and it does not claim to match it. Use it to structure your own review once you have read the source.
- Purpose and boundary. Write down what the AI feature is for, what it is not allowed to do, and what it should do when a request falls outside that boundary. Poorly bounded features are where unexpected behaviour tends to start.
- Named accountability. Identify the senior person answerable for the feature's behaviour in production, and make sure they can see what it is doing.
- Customer outcome monitoring. Define how you will know whether customers are better or worse off because of the feature, and who reviews that evidence, how often.
- Disclosure. Decide what the customer is told, where and when, and test whether they understand it.
- Human oversight. Specify where a person reviews, approves or can override, and what triggers escalation. Be precise about which parts are automated, because a vague "human in the loop" is not a control.
- Data and explainability. Know what data the feature uses and be able to explain, in terms a reviewer can follow, why it produced a given output.
- Logging and evidence. Keep a record sufficient to reconstruct what the AI said or did, to whom, when and on what basis. If you cannot reconstruct it, you cannot defend it.
- Change control. Treat model, prompt and data changes as changes to a regulated product, with testing and sign-off.
- Third-party dependency. If the feature relies on an external model or provider, understand what happens when that dependency changes, fails or behaves differently.
None of these items is exotic. Most teams will recognise them from existing risk practice. The work is applying them to a system whose behaviour is probabilistic and can change without a code release.
Agentic finance: what the acknowledgement signals, and what it does not
The reporting says the FCA acknowledged agentic finance. We do not have detail on what it said, and we should not invent it. What can reasonably be said is limited: the regulator is aware that AI systems are beginning to act, not only to advise, and its stated approach is to apply existing frameworks to them.
For product teams that has one clear implication. If an AI feature can take an action on a customer's behalf, the accountability and outcome questions above become sharper, because the consequence of an error is no longer a wrong answer but a wrong action. The checklist's boundary, oversight and logging items matter most there. Beyond that, we would be cautious about anyone offering a confident view of how the FCA will treat agents specifically. The evidence we have does not support it.
Building compliance in, not bolting it on
The practical risk in a statement like this is sequencing. Teams build the feature, then ask compliance to review it, then discover that a control they need cannot be added without redesign. Moving the control questions to the start is cheaper and, more importantly, produces a better product.
That means putting the checklist above into discovery rather than pre-launch review. It means testing the questions that matter in a proof of concept with real users, not only the question of whether the model performs. A feature that works technically but that users misread, or that reviewers cannot oversee, has failed a test that a technical demonstration would never have run.
It also means treating AI development and governance as one workstream. The control decisions affect the architecture: what is logged, where a human intervenes, how disclosures are rendered, how changes are released. Retrofitting them is slow. Designing them in is what compliance by design means in practice.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance, and we design compliance in from day one. We build for regulated clients; this article is not legal advice, and it says nothing about anyone's regulatory status.
If you are building AI into a financial product, our AI / ML Development work is where the engineering and the control design meet. If you want to test an AI feature's controls before committing to a build, Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding. Explore Innovify AI Labs to see how a scoped test could be set up around the control questions in this article.
FAQ
What did the FCA say about AI on 19 October?
As reported, the FCA said AI providers should add disclaimers to AI financial advice, published examples of good and poor AI practice, and acknowledged agentic finance. It also indicated that it is applying existing frameworks, including Consumer Duty and senior-manager accountability, rather than creating new rules for agents. Read the FCA's own speech for the detail.
Does the FCA require disclaimers on AI financial advice?
The reporting says the FCA indicated that AI providers should add disclaimers to AI financial advice. We have not seen the regulator's wording on form or content, so firms should read the source and take their own advice on what is required. A disclaimer is best treated as one control among several, not a substitute for the others.
Is there a new FCA rulebook for AI agents?
Not according to the reporting. The FCA is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than writing new rules for agents. For product teams that means demonstrating how each AI feature meets standards that already apply, rather than waiting for an AI-specific rulebook.
How does Consumer Duty apply to AI features?
Consumer Duty is concerned with outcomes for retail customers, so the question for an AI feature is whether customers end up better off, understood what they were told and can be shown to have been treated well. The reporting says the FCA is applying it to AI. How it applies to a specific feature is a matter for your compliance and legal advisers.
What should a product team do first?
Read the FCA's published good and poor practice, then list your AI features and test each one against them. Where you cannot answer a good-practice question or rule out a poor-practice example, treat it as a design task. Name a senior owner for each feature and make sure its behaviour can be reconstructed from logs.
Conclusion
The 19 October statement does not hand product teams a new checklist. It tells them that the standards they already work to apply to AI, and that disclosures, good practice and accountability all matter. The sensible response is to read the source, test each AI feature against it, assign a named owner and design the controls in from the start. Anything more confident than that would go beyond the evidence.
