Your bank's AI agent can issue the refund. Can you prove it should have?
A customer writes in at 11pm. They've been charged twice for the same £42 order. A year ago that complaint waited until morning for someone in the disputes team. Today an AI agent can read it, check the two transactions and send the refund in under a minute, and most banks and payment firms already have the technology to do it.
What they don't have is a way for the risk team to say yes. Agent projects in regulated finance rarely stall in engineering. They stall at sign-off, when risk, compliance and security ask four questions before anything touches a customer's money.
The four questions
Which agent did this, and who owns it? "The AI did it" isn't an answer a regulator accepts, so every agent needs its own identity and a named owner.
What stops it going beyond its job? A refunds agent has no reason to change a credit limit or add a payee, and its permissions should say so.
Who approved the big decisions? Large or unusual actions need a named person to approve them, and a record of who did and when.
Can we stop it, and prove what happened? When something goes wrong you need the agent stopped at once and the whole story in one export for the auditor.
A refunds agent, start to finish
Take a disputes and refunds agent at a UK digital bank. This is an illustration of the controls rather than a customer story, and it is the same walkthrough we publish on our financial services page.
The agent is registered with its own cryptographic key and an owner in the disputes team. It may read transactions and issue refunds; it can't add payees, change limits or move money between accounts. Before it acts it declares what it is about to do, for example "refund up to £42 for complaint #4821", and anything outside that is flagged as off intent.
Every refund then goes to Vorim before it reaches the payment system, and comes back as allow, deny or escalate. With a typical set of rules, a £42 refund for a customer with history goes straight through. From £500 it waits for a named person in disputes, and from £5,000 it needs two. More than 20 refunds in ten minutes stops the agent, the same agent can never raise and approve the same payment, and touching a decoy account quarantines it. A request nobody answers times out as a no.
If something does go wrong, one click stops the agent and every agent it handed work to, and Vorim signs a record of how quickly the stop took effect. Every action, decision and approval is signed, so an auditor can check the record without asking us.
Where the money is
Agents only save money once they are allowed to run, which is why sign-off matters more than the model. Routine, low-value cases go to the agent and people spend their time on the ones above your limits. Risk teams can inspect the controls instead of trusting a slide, so pilots stop sitting in review for months. Money limits, velocity limits and circuit breakers cap what a faulty or compromised agent can lose. And "what did the agent do on 3 March, and who approved it?" becomes one query instead of a week in the logs.
We don't quote an industry savings figure. The honest version is a sum you run on your own numbers, taking the cases moved to the agent, multiplying by the difference between what a person and the agent cost per case, minus the escalated cases people still handle.
The rules you already work under
Vorim doesn't make a firm compliant on its own, and it isn't legal advice. What it gives you is the evidence those frameworks ask for. That means a record of what an agent did for each customer under the FCA's Consumer Duty, and a named owner and a signed approver for each decision under SM&CR. For operational resilience, and for DORA if you're an EU firm, it means an instant stop with a measured, signed time, plus logs that stream to your SIEM. And for high-risk AI under the EU AI Act, a person approves the decisions you choose.
What we tested before writing this
We ran a bank refunds agent, a credit-decision agent at a lender and a payment-initiation agent with sub-agents through both our SDKs and the API, 133 checks in all, covering the happy path, the sad path and the awkward cases. Two approvers pressing approve and deny at the same instant. A refund of exactly £500. Amounts sent as "750", "£750.00", "1,500.50" or "1e6". A forged signature, a replayed request, a webhook aimed at an internal address, an agent trying to release itself.
The tests found one gap worth admitting. An amount the gate couldn't read, such as "£20k", already went to review under an amount rule, but under a declared intent it slipped through as on intent. We fixed it this week, so both now treat an unreadable amount the same way.
What we won't claim
We don't have a named financial services customer to show you yet. Vorim controls what your agents are allowed to do and proves what they did, but it doesn't make a model's judgement correct or replace your model risk work. That's why we start with a pilot measured on your numbers rather than ours.
Start with one workflow
The pilot is one agent and one workflow for 30 days. We begin in shadow mode, where your rules record what they would have decided without blocking anything, and switch them on once you trust what you see. At the end you have the signed record and a short report on cases resolved without a person, time to resolve, escalations, value blocked and time to answer an audit.
The full walkthrough, the rules and the regulatory mapping are on vorim.ai/financial-services. If you run agents near money, book a call from that page and bring one workflow.