Using AI Agents Safely for Onboarding, KYC and Reconciliation: A Control Framework for UK Fintech Teams

Using AI Agents Safely for Onboarding, KYC and Reconciliation: A Control Framework for UK Fintech Teams

Product and risk teams want the efficiency of AI agents in onboarding and reconciliation, but most cannot yet show how those agents are controlled, overseen and audited. That gap, not the technology, is what stalls agent projects between pilot and production. This article offers a practical control framework for three jobs: onboarding, KYC checks and reconciliation. For each, it sets out what the agent may decide, what a human must approve, what must be logged and when the agent must stop. It is written for CTOs, CPOs and heads of embedded finance at UK fintechs and brands, and it is a framework for your own design discussions, not legal advice.

Why these three jobs, and why now

Agents are reaching regulated operations through the back office first. Customer-facing advice is where regulators and the press look hardest. Onboarding, KYC and reconciliation are where the repetitive, document-heavy and exception-heavy work sits, which makes them natural candidates for an agent that can read, compare, draft and route.

There is public evidence of this direction in the UK. In October 2026, Finextra, FF News and Sifted reported that Starling Bank had deployed an agentic financial-crime investigator inside its core systems. That is the bank's own claim, and the detail of how it is governed has not been set out in the reporting we have reviewed. Even so, it shows a UK regulated firm placing an agent in a financial-crime workflow rather than only in a pilot.

At least one specialist vendor now markets modules for approving AI agents before they go live and for monitoring them in real time, according to its own published material as we observed it in October 2026. We read that as a sign that buyers are asking the same question this article addresses: not whether an agent can do the work, but how anyone can show that it did the work within limits.

Our view, and it is a view rather than a reported fact: the teams that move fastest will not be the ones with the most capable agents. They will be the ones that can answer four questions for each job on request, from a regulator, a bank partner, an auditor or their own board.

What the FCA has said, and what this article does not claim

On 19 October 2026 the FCA published a speech on AI in finance. As reported by Finextra and as summarised in our market research, it set out examples of good and poor AI practice, asked AI providers to add disclaimers to AI financial advice and acknowledged agentic finance.

Our market research reads this as the FCA applying existing frameworks, including the Consumer Duty and senior manager accountability, to AI, rather than creating new rules specifically for agents. That is our reading of reporting, and you should check it against the FCA's own text.

Three cautions follow.

• We have not reproduced the FCA's examples of good and poor practice. The detail matters, and it should be read at fca.org.uk, in the FCA's own words, not through a summary.
• The disclaimer point concerns AI financial advice. Onboarding, KYC and reconciliation agents are not advice agents. We use the principle only as a prompt to be clear with customers when they are dealing with automated processes. That is our interpretation, not an FCA requirement.
• This is not legal advice. How the FCA's expectations, your regulated partner's requirements and your own legal obligations apply to your firm depends on your circumstances. Take advice from your compliance function or legal counsel before you design or launch.

The framework: four questions for every agent job

The framework is deliberately simple. For each job, write down the answers to four questions before building anything.

1. What may the agent decide? Define the decisions the agent can take alone, inside stated limits.
2. What must a human approve? Define the decisions that always need a named person, and what that person sees when they decide.
3. What is logged? Define the record that lets someone reconstruct what happened, later, without asking the agent.
4. When must the agent stop? Define the conditions under which the agent halts and hands over, rather than carrying on.

Think of each job as sitting on an autonomy ladder with four rungs.

• Observe: the agent reads and summarises. It changes nothing.
• Recommend: the agent proposes an outcome and a human decides.
• Act within limits: the agent decides and acts inside hard limits, with sampling by a human afterwards.
• Act and notify: the agent acts and tells a human at once, who can reverse it.

Most teams should start every job at Recommend and move individual decision types up the ladder only when they have evidence from their own logs. Our position is that autonomy should be earned per decision type, not granted per product. An agent can be trusted to match an exact bank reference and not to waive a failed identity check, in the same workflow, on the same day.

Job one: customer onboarding

Onboarding is where a brand or platform first takes on risk. If you are embedding financial services in an existing customer journey, as in an embedded finance programme, your regulated partner will care a great deal about how new customers are admitted, and so should you.

What the agent may decide

• Whether an application is complete, and which documents or fields are missing.
• Routing: which journey, queue or reviewer an application goes to.
• Drafting plain-language requests to the customer for missing information, from approved templates.
• Pre-filling case notes from the submitted data.

What a human must approve

• Any decision to accept, decline or restrict a customer.
• Any exception to the standard onboarding policy.
• Any change to customer-facing wording the agent uses.
• Any case where the customer is vulnerable, or where the agent has flagged distress or confusion.

What is logged

• The inputs the agent saw, with versions or timestamps.
• Each recommendation, the reasons given, and the policy version applied.
• Who approved, overrode or amended each outcome, and when.
• The model and prompt or configuration version in use at the time.

When the agent stops

• Missing, unreadable or contradictory documents.
• Any mismatch between the data supplied and a trusted data source that the agent cannot resolve using a rule you wrote in advance.
• A customer message that suggests a complaint, a vulnerability or an objection to automated handling.
• Anything outside the product, geography or customer type the agent was approved for.

The test for this job is whether a customer who was declined can be given an accurate account of how the decision was made, by a person, using records that exist.

Job two: KYC checks

KYC is where an agent's mistakes carry the highest cost, because a wrong decision can mean either admitting a customer who should not have been admitted or excluding someone who should have been served. It is also where agent assistance is most tempting, because of the volume of documents, name matches and screening alerts.

Agentic KYC is best understood as agent-assisted evidence handling with human-owned judgement. In our view, the agent should gather and organise; a human should decide.

What the agent may decide

• Whether a document is legible, complete and of an accepted type.
• Whether extracted fields match the application, within a tolerance you have set and tested.
• Which screening hits are clearly unrelated, using deterministic rules you can explain, with the reason recorded.
• How to prioritise the review queue.

What a human must approve

• Any customer risk rating or change to it.
• Any decision to clear, dismiss or escalate a screening alert that is not covered by a pre-agreed rule.
• Any decision to onboard, refuse, exit or report.
• Anything connected to a suspicion of financial crime, which should always reach a named person.

This is the heart of human in the loop financial crime controls: the agent speeds up the work that leads to a judgement, and the judgement stays with someone who is accountable for it. Starling's reported use of an agent in financial-crime investigation, which is the bank's own claim, sits in the same territory, and it underlines why the human decision point needs to be designed rather than assumed.

What is logged

• Every source the agent consulted and what it returned.
• The agent's reasoning summary for each recommendation, stored with the case, not only in a model log.
• The rule or threshold that triggered each automated clearance.
• Each human decision, with the evidence the human actually viewed.
• Counts of overrides, so you can see where the agent and your reviewers disagree.

When the agent stops

• Conflicting identity evidence.
• Any indicator your policy treats as higher risk.
• A confidence level below the threshold you set, or an inability to state a reason.
• Any request, from anyone, to skip a step.
• Repeated tool failures, such as a data source being unavailable. The agent must not substitute a guess.

One design rule is worth stating plainly. Do not let the agent be the only place where its own reasoning lives. If the explanation exists only inside the model's session, you do not have an audit trail.

Job three: reconciliation

Reconciliation is, in our view, the safest place to start with agents in a fintech, because the ground truth is usually in your own ledgers and bank or scheme files, and many errors are detectable by arithmetic. It is not risk-free. An agent that wrongly clears a break, or makes a wrong adjusting entry, can hide a real problem such as a missed payment, a duplicate or a safeguarding shortfall.

What the agent may decide

• Matching items where the match is exact or within a defined rule, such as amount, date window and reference.
• Grouping breaks by likely cause and suggesting an owner.
• Drafting explanations for known, recurring break types.
• Flagging unusual patterns for review.

What a human must approve

• Any adjusting or correcting entry in the ledger.
• Any write-off, however small, above a limit you set.
• Any change to matching rules or tolerances.
• Any break that has been open longer than your policy allows.
• Any break touching customer money, where the effect on the customer needs a decision, not just an entry.

What is logged

• Match rules and tolerances in force, versioned.
• Every automated match and the evidence for it.
• Every break, its age, its assigned owner and its resolution.
• Every attempted or recommended entry, and whether a human accepted or rejected it.

When the agent stops

• Total breaks, or break value, rising beyond a stated threshold in a period.
• Any unexplained break that grows or repeats.
• A source file that is missing, late or in an unexpected format.
• Any instruction that would require the agent to change data it has only been given read access to.

A good reconciliation control has a boring feel. The agent does the matching quickly, a person owns the breaks, and the finance team can see at any point which entries came from an agent and who approved them.

Controls that apply to all three jobs

Beyond the job-specific rules, five controls apply across the framework.

• Named accountability. Each agent job should have one accountable owner inside the firm, with a clear line to whoever carries senior-manager responsibility for the area. Given the FCA's reported emphasis on existing accountability frameworks, we would not design a workflow in which no named individual can explain an agent's output.
• Least privilege. Give the agent only the access required. Prefer read access with proposals over write access with notifications, and keep credentials short-lived and scoped to the job.
• Change control. Treat a change of model, prompt, rule or tool as a change to a control. Version it, test it against a fixed set of past cases and record who approved it.
• Monitoring that people read. Track override rates, queue ages, exceptions and customer complaints that mention automated handling. Someone should review these on a schedule and be able to pause the agent.
• A way to stop it. Every job needs a switch that moves it back down the autonomy ladder, and every team member in the loop should know where it is.

Poor-practice patterns to avoid

The following are patterns we see as weak control designs. They are our analysis, not a list drawn from the FCA's examples.

• Approval theatre. A human clicks approve on every case without seeing the evidence. The control exists on paper and nowhere else.
• Logs that cannot be replayed. You can see what the agent said but not what it was shown.
• Silent exceptions. The agent skips a step when something fails and carries on.
• Autonomy by default. The agent is launched with act-and-notify rights across a whole journey.
• No owner for the model. When the model or prompt changes, nobody is asked to approve it.
• Customer opacity. Customers cannot tell that an automated process is involved, or how to reach a person.

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. For the work described here, that means helping product, risk and engineering teams turn the four questions into build requirements: decision limits, approval screens, evidence stores, logging and stop conditions, built into the agent workflow rather than added afterwards.

If you are scoping an agent for onboarding, KYC or reconciliation, our AI / ML Development team can work with you on the design and build. We build for regulated clients. We are not an FCA-authorised firm and we do not provide legal or regulatory advice, so your compliance function and advisers remain the right people to decide what your obligations require.

A useful first step is a working session in which your product, risk and engineering leads fill in the four questions for a single job. It usually shows quickly where the decision rights are unclear.

FAQ

Can an AI agent make KYC decisions on its own?

In our view, an agent should not own the final KYC judgement. It can gather evidence, check documents against rules and prioritise cases, while a named person decides on risk ratings, escalations and any decision to onboard, refuse or exit a customer. Whether any automation is acceptable for a given decision depends on your regulatory obligations, so take advice for your own circumstances.

What should an AI agent audit trail contain?

An audit trail should let someone reconstruct a decision without asking the agent. It should record the inputs the agent saw, the rule or policy version applied, the recommendation and reasons, the model and configuration version, and who approved or overrode the outcome and when. The reasoning summary should be stored with the case record, not only in a model session.

What has the FCA said about AI agents in financial services?

On 19 October 2026 the FCA published a speech on AI in finance which, as reported, set out good and poor AI practice, asked AI providers to add disclaimers to AI financial advice and acknowledged agentic finance. Our market research reads this as the FCA applying existing frameworks such as the Consumer Duty and senior manager accountability, rather than writing new agent-specific rules. Read the FCA's own text before relying on detail, and note this is not legal advice.

Which job should a fintech automate first: onboarding, KYC or reconciliation?

In our view, reconciliation is usually the safest starting point because much of the ground truth sits in your own ledgers and bank files, and many errors can be detected by rule. Onboarding comes next, with the agent limited to completeness checks and routing. KYC judgements should stay with humans, with the agent assisting on evidence handling. Start every job at the recommend rung and move up only on evidence from your own logs.

When should an AI agent stop and hand over to a person?

An agent should stop whenever it meets conflicting evidence, missing or unreadable inputs, a higher-risk indicator, a confidence level below your threshold, an unexplained break, a tool failure or any request to skip a step. It should never fill gaps by guessing. Write these stop conditions down per job, test them, and make sure a person owns each handover queue.

Conclusion

AI agents can speed up onboarding, KYC and reconciliation, but speed is only useful if you can show control. The four questions, what the agent decides, what a human approves, what is logged and when it stops, give product, risk and engineering teams a shared way to design that control job by job. Start at recommend, earn autonomy from your own evidence, read the FCA's material in its own words, and take advice on your own position.