Voice AI Bank Details Capture: Sort Code and Account Number

A caller reads out a six-digit sort code and an eight-digit account number so you can send a refund, set up a Direct Debit or register a new payee. Your voice AI agents hear it, confirm it and write it to the ledger. If a single digit is wrong, the money does not fail politely. It leaves the account and lands somewhere real, in someone else's account, and getting it back is slow, uncertain and expensive. That is what makes bank details different from every other field a voice agent captures: a mistyped reference number stalls a query, but a mistyped account number moves money.

The stakes are not abstract. UK Finance reported that authorised push payment (APP) fraud losses rose to £576.4 million in 2025, up 19 per cent, across 248,070 cases, with business losses of £75.6 million inside that total. Misdirected and mis-captured payments sit in the same operational family: the payment instruction was wrong, and the money went where it should not have. Since 7 October 2024 there is a mandatory reimbursement regime that decides who pays when that happens, and it changes how any enterprise should think about capturing payment details on an automated line.

This guide is deliberately narrow. It covers UK sort code and account number capture for refunds, Direct Debit setup and payee registration, whether business-to-consumer or business-to-business. It does not cover card payments: capturing a card number over voice is a PCI DSS problem with its own controls, and everything in that post stands. Here the question is narrower and, for most enterprises, more common: what does a governed voice agent do with a spoken sort code and account number, and who carries the loss when it gets one wrong.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system for placing AI where money and risk actually move.

Against that risk, the wider adoption picture is familiar. McKinsey's State of AI found that around 88 per cent of organisations now use AI somewhere, yet only about 6 per cent capture material earnings impact, and Stanford's AI Index reports fewer than 10 per cent of firms have fully scaled it in any function. Payment capture is exactly the kind of high-consequence workflow where the gap between using AI and running it safely is widest, which is why the design decisions below matter more than the demo.

Should a voice AI agent capture bank details over the phone at all?

Not always. The honest default is to decide deliberately rather than by habit. A voice AI agent should capture a sort code and account number on the line only when the flow is high volume and it can apply read-back, a modulus check and a name match before anything is written. For a rare, high-value one-off, a secure link or a callback to a trained human is often safer. Treat capture as a governed decision.

The reason to be selective is that a bank detail, once captured, becomes a payment instruction that something downstream will act on. The design question is therefore not "can the agent hear the digits" but "should this particular call be allowed to originate a payment instruction at all." The framework below is the operating model we use inside our DATS consulting system: decide the channel, confirm the capture, validate the pair, verify the name, and escalate anything that does not cleanly pass.

This is where a governed platform earns its place. A self-serve builder will happily let you capture and store the digits; the harder work is wiring the validation and escalation gates around them so a mismatch never silently becomes a payment. That is a core part of how we design an AI operating model for regulated workflows, and it is the difference between a demo that captures bank details and a system you can put in front of an auditor.

How does a voice agent read back a sort code and account number accurately?

A voice agent reads back a sort code and account number the disciplined way it handles any high-consequence identifier: capture the digits, group them as the caller expects, and play them back for explicit confirmation. A UK sort code is six digits, usually spoken in three pairs, and an account number is eight digits. The agent should confirm the full pair in one read-back and never treat a first-pass recognition as final for a payment field.

The read-back mechanics for high-stakes numbers, digit grouping, phonetic confirmation, and re-prompting on low recognition confidence, are covered in depth in our guide to reference number capture accuracy, and the same discipline that governs a date of birth used for verification applies here with one raised bar: for a payment field, confirmation is mandatory, not optional. Where a reference number can tolerate a "did you mean" recovery, a sort code and account number must be explicitly confirmed digit-group by digit-group, because the cost of a silent mishear is a misdirected payment rather than a stalled lookup. Enterprises migrating these flows from keypad entry should read our note on DTMF and IVR migration before assuming speech capture is always the right input mode for numeric payment data.

What does the modulus check actually prove?

The modulus check is a mathematical test that confirms a sort code and account number are a compatible pair, and nothing more. UK banks apply the industry modulus checking rules for the Pay.UK schemes to reject combinations that cannot exist. It catches a mistyped digit before a payment is attempted. What it does not do is confirm the account is open, holds funds, or belongs to the person the caller named. It proves compatibility, not ownership.

That distinction is the whole reason the next control exists. A modulus check will happily pass a valid, well-formed account number that belongs to a complete stranger, so it can catch a fat-fingered digit but not a fraud and not a caller who transposed two accounts they both hold. The weighting is published in the Validating Account Numbers specification for the Pay.UK schemes, and we cover the weighted calculation and the exception rules in the reference number capture guide; for payment capture, the point to hold is narrower. The modulus check is a cheap first gate that removes impossible pairs. It is not the control that tells you the money will reach the right person.

What is Confirmation of Payee and why does it matter for voice capture?

Confirmation of Payee (CoP) is a name-checking service that verifies whether the account name a caller gives matches the name registered on the receiving account, returning a match, a close match or no match. It was mandated by the Payment Systems Regulator, and by the end of October 2024 most transactions across Faster Payments and CHAPS were covered. For a voice agent, CoP is the control that turns a valid account number into the right person's account.

CoP matters for voice capture because it addresses exactly the gap the modulus check leaves open. A caller can give you a perfectly valid sort code and account number that belongs to the wrong person, through error or through a scam, and only a name match surfaces that before the money moves. The regulator gave the largest banking groups Specific Direction 10 in 2019 and later directed around 400 more firms to offer the service, extending coverage across the industry through Pay.UK's model. In a governed voice AI deployment, a CoP no-match or close-match result is not a soft warning to be clicked past; it is an escalation trigger that routes the call to a human and blocks the automated write. The reader-facing takeaway is simple: if your voice flow originates payment instructions, a name-match gate belongs in it.

Who bears the loss when a voice agent captures the wrong bank details?

Under the UK regime that began on 7 October 2024, the payment firms bear the direct reimbursement cost, not the enterprise that captured the details. The Payment Systems Regulator's mandatory requirement obliges payment service providers to reimburse most victims of authorised push payment fraud on Faster Payments, with the cost split equally between the sending and receiving firm. The reimbursement duty binds the banks; your exposure is different, and often overlooked.

The maximum level of reimbursement is set at £85,000 per claim, reduced from an original £415,000, and the Bank of England set the same ceiling for CHAPS. The rules give the sending firm five business days to reimburse a valid claim, with provision to pause that deadline while it investigates. The regulator's own assessment of that level is worth quoting directly:

This level will mean 99.8% of all Faster Payments APP scams by volume, and 90% by value, are fully reimbursed, providing they fall in scope of the policy.

So where does the enterprise sit? The reimbursement rules govern the banks, but a mis-captured payment instruction is your operational failure, and two things follow. First, if your voice agent originates a payment that goes wrong, the disputes, chargebacks and goodwill costs land on your operation even though the statutory reimbursement duty sits with a bank. Second, and more usefully, your call recording and structured logs are the evidence of what the caller actually said and what the agent confirmed. A clean, timestamped record of the read-back, the modulus result and the CoP outcome is what lets you resolve a dispute quickly and demonstrate that the instruction was captured and confirmed correctly. In this regime, data quality is not a nicety; it is your position in an argument about who pays. It is worth noting that the Payment Systems Regulator's own future is changing: the government has confirmed it will consolidate the regulator's functions into the Financial Conduct Authority, pending legislation, though the reimbursement requirement itself remains in force throughout.

The same evidence discipline underpins our AI execution office, where we run governed AI workflows in production and keep the audit trail that regulated disputes depend on.

How should you store and secure a spoken sort code and account number?

A spoken sort code and account number is personal data under UK GDPR and must be handled with care, even though it is not special category data and, unlike a card number, is not in PCI DSS scope. Not being PCI-scoped does not mean uncontrolled: the recording of the caller speaking the digits is still personal data, held on a lawful basis, encrypted, access-controlled, and kept only as long as the payment purpose requires.

Practically, that means three things for a voice deployment. Retain the payment portion of a recording only as long as you need it to evidence the instruction, then apply retention and redaction so the raw digits are not sitting in a general-purpose transcript store. Restrict who and what can read the payment fields, treating them as a sensitive subset rather than ordinary call metadata. And document the lawful basis and the data-protection design the way you would for any other high-risk personal data you capture on the line. Note too that the moment the same call also captures a card number, PCI DSS scope returns immediately for that portion, so keep the two flows separate by design. The Information Commissioner's Office expects data minimisation and purpose limitation to be built in, and a payment field is precisely where those principles are tested. This is the kind of control set we build into an AI operating model rather than bolt on afterwards.

What is the best voice AI setup for capturing bank details in 2026?

The best setup depends on volume, risk appetite and governance needs, and for high-stakes payment capture the honest answer favours a governed platform over a self-serve builder. Self-serve tools such as Vapi, Retell AI, Bland AI and Synthflow are fast to prototype but push validation, escalation and evidence design onto you. Enterprise platforms such as PolyAI and Dilr Voice wire modulus and Confirmation of Payee gates, mismatch escalation and auditable recording in by default. Match the tool to the consequence.

There is a scenario where a competitor wins, and it is worth being honest about it. If you are a single-product business taking a handful of simple refunds a week, a self-serve agent that captures the pair and hands off to a human for anything unusual may be all you need, and paying for enterprise governance would be over-engineering. Equally, for a rare high-value payment, the best voice AI setup may be one that deliberately does not capture the details on the line at all, and instead routes the caller to a secure link or a trained agent. The strongest deployments choose the channel per call rather than forcing every payment through the same automated path, which is exactly the judgement our DATS methodology is designed to make explicit.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, read how we build an approach to placing AI in regulated systems, or browse more voice AI engineering guides.

Is capturing a sort code and account number covered by PCI DSS?

No. PCI DSS applies to cardholder data, so a card number, expiry and security code fall in scope, but a sort code and account number do not. That does not make them low risk: they are personal data under UK GDPR and must be encrypted, access-controlled and retained only as needed. If the same voice flow also captures a card, PCI DSS scope returns for that part, which is why card handling stays a separate, more tightly scoped workflow.

Can a voice agent set up a Direct Debit over the phone?

Yes, within the Direct Debit scheme rules. A paperless Direct Debit can be set up over the phone using the AUDDIS process, but the caller must be the account holder or authorised to instruct, advance notice of collection must be given, and the Direct Debit Guarantee applies. For a voice agent, the mandate becomes a durable record: capture the pair, validate and name-match it, then log the instruction so the mandate and its Guarantee obligations stay auditable.

Does Confirmation of Payee stop all misdirected payments?

No. Confirmation of Payee checks whether the account name matches the sort code and account number given; it does not confirm ownership, prevent a caller from authorising a payment to a scammer, or guarantee funds arrive. A no-match or close-match should block the automated write and escalate to a human, but a full match is not a licence to skip judgement. It is one control among several: a governed voice deployment layers read-back, modulus, CoP and escalation.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.