Yes, with conditions. Nothing in FCA rules bans automated triage, but FG21/1 and the Consumer Duty mean you must show vulnerability was recognised and acted on, not filtered out. Complaints reporting is also being reworked, so check the current return before you build. Every routing decision needs a record of what the system saw and who decided.
Do FCA rules allow AI to triage complaints?
Yes. The FCA's complaints rules in DISP set out what has to happen to a complaint, not what software you may use to help you do it. You have to acknowledge it promptly, investigate it competently, diligently and impartially, assess it fairly, issue a final response inside the deadline, and tell the complainant about their right to refer the case to the Financial Ombudsman Service. Nothing there stops a machine reading the file first and sorting it.
What it does stop is any tool that weakens one of those duties. I apply two tests before a triage step goes near a live queue. First: could a handler take this case over right now, with everything the system has already seen in front of them. Second: could you reconstruct, nine months later, why this complaint went down this route and not another one. If either answer is no, the step is not ready for customers.
What does FG21/1 expect on spotting vulnerability?
FG21/1, the FCA's finalised guidance on the fair treatment of vulnerable customers, expects your people and your processes to recognise vulnerability and respond to it. It sets out four drivers of vulnerability, and it is worth reading the guidance itself rather than a summary of it. The obligation is practical: understand the needs of your customer base, equip staff to spot characteristics of vulnerability, and act when they do.
Complaints are where this gets difficult. Vulnerability is rarely declared in a form field. It arrives sideways, in one clause of a long message about a charge or a delay, often from someone who is not asking for help with the thing they are actually struggling with. A triage layer that reads only the complaint category will step straight past it.
So I treat the job as surfacing signals for a person, not classifying a customer. The output is a flag plus the exact sentence that caused it, attached to the case. A handler decides what it means.
Where does automated triage go wrong?
Three ways, consistently.
Category-first design. The model picks one label and the rest of the message is discarded on the way to the queue. The vulnerability signal is almost always in the part that got discarded.
Thresholds tuned by queue length. You set a confidence bar for automatic routing. Exceptions pile up. Someone lowers the bar to clear the backlog. Decisions have quietly moved from people to software and nobody recorded the moment it happened.
Learning from your own history. Train on past handling and the system inherits whatever your past handling missed. Unusual phrasing, a relative writing on someone's behalf, a blunt short complaint with none of the expected words in it: all scored as routine, because that is how they were treated before.
The fixes are unglamorous. Keep the original wording with the case. Tune vulnerability flags for recall and accept the false positives, because a handler dismissing a flag costs minutes and a missed disclosure costs a customer. Log every threshold change as a change, with a name against it and a reason.
What does the Consumer Duty add?
It moves the question from process to outcome. Under PRIN 2A you must act to deliver good outcomes for retail customers, and two of the four outcomes land directly on complaints handling: consumer understanding and consumer support. Support must not put unreasonable barriers in the way of someone who needs it.
Triage can become that barrier without anyone intending it. An extra automated step, a self-service loop, a routing decision that adds four days for the customer least able to absorb four days: each one is a worse outcome delivered efficiently.
The Duty also requires you to monitor outcomes, identify where groups of customers are getting poor ones, and act on what you find. That is a data obligation before it is a governance one. If your triage keeps no record of what it saw and what followed, you cannot produce that evidence at all, and you certainly cannot put it in front of a board. It is the same evidencing problem I set out in evidencing good outcomes with a tamper-evident record.
What is changing in complaints reporting?
The reporting side is moving. The FCA has reworked the complaints reporting process: the policy statement is PS25/19, Improving the Complaints Reporting process, and the direction has been towards more structured data about complaints, including data about customer vulnerability. I am not going to reproduce a field list or a commencement date here, because those are the details that move as rules are made and amended. Check the current DISP reporting requirements and the FCA's latest publication on complaints reporting before you design anything.
The engineering advice does not depend on the detail. Capture at case level, timestamped, with the signal and the human decision stored as separate records. Any new aggregate can then be derived from data you already hold. Firms that store only a final category and a closed date will meet the next change with a spreadsheet and a month of manual work.
What must you evidence for each routed complaint?
Six things, per complaint, retrievable without a developer.
- What arrived, as it arrived: the text, the channel, the timestamp.
- What the system extracted, including any vulnerability signal and the wording behind it, with the version of the model that produced it.
- The route taken, and the rule or score that produced that route.
- The named person who reviewed it, and when.
- What they changed, if anything.
- Where the case went next.
This is what the Open Audit Record is for. Every consequential action is sealed under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. The purpose is not secrecy. It is that your auditor can take an exported record away and verify it offline with a public key, using tools that are not ours.
That makes the record tamper-evident, which is a narrower and more honest claim than tamper-proof. Someone with enough access can still alter a stored record. What they cannot do is alter it without verification failing afterwards. For a complaints lead who has to stand behind a file in front of a regulator, evident beats proof by assertion.
Should AI ever close or reject a complaint?
No. Not in a design I would sign off. Upholding, rejecting, offering redress and closing are judgements with consequences for a real person, and they are the decisions that get tested later by the Ombudsman.
In SIOS, consequential actions wait for a named individual to approve them. The system prepares, summarises and proposes. A person decides, and their name sits in the record next to what they were shown at the time.
There is a data protection dimension as well. UK data protection law constrains decisions taken solely by automated means where they have legal or similarly significant effects on someone, and the ICO's guidance is the place to start on that. A rejected complaint is not obviously outside the scope of that argument. Keeping a person genuinely in the decision, rather than rubber-stamping a generated letter, keeps you clear of it.
How do you run complaints AI without the data leaving the firm?
You run it on hardware you own. A complaints file holds some of the most sensitive text a regulated firm ever writes down: money trouble, bereavement, family circumstances, third parties named in passing by a customer who never consented to anything.
SIOS is built for that constraint. It runs on the customer's own hardware, it is offline capable, and there is no data egress. Fifty specialised models, and private knowledge bases built from the firm's own procedures and past decisions rather than from a general corpus.
Where we actually are, plainly. The closed beta is open and one regulated company is onboarding as a design partner. I am not naming the company or its sector. A local OCR runtime has read scanned PDFs in controlled tests, and the extraction and ingestion integration into SIOS is still being completed. That matters here, because complaints arrive as scans and phone photographs of letters far more often than anyone plans for.
I am also not claiming the system detects vulnerability. It surfaces signals and records what was seen and who decided. That is the claim I can evidence, and evidence is the whole point.
None of this is an argument against cloud. Cloud remains the right place for plenty of non-regulated work, and the companies building that layer are doing something we depend on. The assumption worth refusing is narrower: that a regulated firm has to ship its complaints file offsite and then take a vendor's word for what happened to it afterwards. More on the sector picture in AI for UK financial services.
Frequently asked questions
Can AI decide the outcome of a complaint?
No. Treat the outcome as a human decision. Software can read the file, summarise it, pull the relevant procedure and propose a route, but upholding, rejecting, offering redress and closing all carry consequences for a real person and get tested later by the Ombudsman. In SIOS a named individual approves every consequential action before it takes effect.
Do we have to tell a customer that AI handled their complaint?
DISP does not ask you to describe your tooling. UK data protection law does expect your privacy information to be clear about how personal data is processed, so if a model reads complaint text, say so there. My practical advice: keep a named person accountable for the outcome, and never let your complaints wording imply a human read something no human read.
How do we prove the AI did not miss a vulnerability?
You cannot prove that across a population, and anyone promising it is selling something. What you can do is evidence each case: the original wording retained, what the system flagged and why, what the handler saw, what they decided and when. Seal those records so they verify independently, then sample-test the cases nobody flagged.
What vulnerability data will we have to report?
Check the current DISP reporting requirements and the FCA's most recent publication on complaints reporting, because the return is being reworked and the detail moves. Build for it regardless: capture vulnerability signals and handler decisions as separate timestamped records at case level, and you can derive whatever aggregate the next return asks for without a manual exercise.
Can we run complaints AI without sending customer data outside the firm?
Yes. SIOS runs on hardware you own, is offline capable and has no data egress, with private knowledge bases built from your own procedures. The closed beta is open and one regulated company is onboarding as a design partner. I am not naming the company or its sector. Document extraction and ingestion into SIOS is still being completed, which matters if your complaints arrive as scans.
Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.
Top comments (0)