AI Agents for Payment Investigation Workflows

Every payments business generates a second, quieter business alongside it. For each million instructions that settle without incident, some thousands do not: the beneficiary reports non-receipt, the payer asks for a recall, a name mismatch stops the credit, a screening hit needs justification, charges are contested. That residue becomes cases, and cases become an operations function that scales with volume and never quite catches up.

Exceptions and investigations is unusual among back-office processes in one respect: almost all the effort goes into reconstruction rather than judgement. By the time an experienced investigator has assembled what happened, deciding what to do about it often takes minutes. That ratio is what makes the work a strong candidate for AI agents — and the fact that the decisions at the end are consequential and clock-bound is what determines how narrowly those agents should be scoped.

Where the effort actually goes

Break a typical non-receipt or recall case into its stages and the manual load concentrates in places with no discretion in them at all.

• Locating the payment. Matching a customer’s description — an approximate amount, an approximate date, a beneficiary name spelled differently from the instruction — to a specific transaction reference in the payment engine.
• Reconstructing the leg-by-leg history. Pulling the outbound instruction, any intermediary traffic, status responses, and returns into a single chronology, when each may live in a different system with a different identifier.
• Explaining a stop. Retrieving the screening or fraud system’s rationale for a hold and translating it into something that can be said to a customer or correspondent without disclosing what must not be disclosed.
• Checking the ledger. Confirming whether funds were debited, held, returned, or credited, and reconciling any charges applied along the way.
• Drafting the response. Producing an inquiry, a correspondent response, or a customer communication in the correct format, with the correct references, saying only what the evidence supports.
• Watching the clock. Tracking the deadline for each case type and escalating before it is missed.

None of that requires a judgement. All of it requires accurate retrieval across systems — the specific thing a governed agent with scoped tool access is good at.

Two clocks that changed the economics

Investigation work has always been costly. Two developments have made the cost harder to absorb by adding staff.

Reimbursement deadlines. In the UK, the Payment Systems Regulator’s mandatory reimbursement regime for authorised push payment fraud took effect on 7 October 2024. In-scope firms must reimburse eligible victims — individuals, microenterprises and charities — up to £85,000 within five business days of a claim, with the receiving firm reimbursing half the amount to the sending firm. A five-business-day window for a case that requires evidence from two institutions leaves very little room for a queue.

Format migration. SWIFT’s exceptions and investigations traffic is moving from free-format MT messages to structured ISO 20022 messages routed through Case Management: camt.110 for an investigation request and camt.111 for the response. From November 2026 it becomes mandatory for institutions to be able to receive a camt.110 with an embedded MT 199 through in-flow translation, and from November 2027 MT messages for exceptions and investigations are to be phased out entirely, with Swift enabling all eligible institutions to send and receive camt.110/111 and the camt.056/camt.029 cancellation pair through Case Management. Payment cancellation requests move to the Stop and Recall service on the same 2027 horizon.

That second change is more interesting than a compliance date, because it alters what automation can do. A free-format MT 199 narrative is a paragraph a human wrote for another human. A camt.110 is a structured request with a typed reason and defined elements — machine-readable input, machine-checkable output, and a much smaller gap between what an agent can safely produce and what needs to be sent.

What an investigation agent workflow looks like

The shape that works is a sequence of narrow agents, each with scoped access, ending in a human decision — the same pattern that holds across governed multi-agent workflows.

1. Intake and classification. An inbound inquiry — a camt.110, a customer complaint, an internal referral — is classified by case type and mapped to the deadline that applies. Classification determines routing, not outcome.

2. Transaction identification. The agent resolves a fuzzy description to candidate transactions using the payment engine’s own search, presenting matches with confidence and reasoning rather than silently picking one. Ambiguity is an output, not something to resolve by guessing.

3. Case assembly. The agent retrieves the full chronology: instruction, status events, correspondent traffic, ledger entries, applied charges, and any screening or fraud events, each with its source reference.

4. Evidence review against the question asked. The agent checks whether the record answers the specific inquiry, and states plainly what is missing — a status response never received, a charge with no matching entry, a gap between debit and credit.

5. Draft response. For structured traffic, a camt.111 populated from the evidence. For a customer, a draft in the bank’s own language. Both carry citations to the underlying records so a reviewer can verify each assertion rather than trusting a summary.

6. Human decision and dispatch. An investigator reviews, corrects, and approves. The approval is recorded against the case, and only then does anything leave the bank. This is the human approval step that makes the rest of the workflow deployable.

The lines that should not be crossed

Several capabilities are technically easy and still the wrong thing to build.

Reimbursement and fraud determinations. Whether a claim is reimbursable, and whether a customer was in fact defrauded, are decisions with regulatory consequences attached. An agent can assemble the evidence and even lay out the options; the determination and its recorded rationale belong to a trained person.

Releasing a screening or sanctions hold. A hold exists because a control fired. Clearing it is a control decision, and automating it removes the control.

Any instruction that moves money. Recalls, returns, credits, and charge reversals must be executed by an authorised person through the systems that already record who authorised them. An agent that can move funds is a fraud vector regardless of how well it is prompted.

Autonomous outbound communication. A response to a correspondent or a customer commits the institution. Draft, review, send — in that order, every time.

Reading beyond the case in hand. An agent working one case should reach that case, not the wider portfolio — scope enforced at the data layer, not by instruction.

Why this workload belongs inside the boundary

Investigation material combines payer and beneficiary identities, account details, correspondent traffic, screening rationale, and — in fraud cases — a customer’s own account of how they were deceived. It is also concentrated: a single case file can contain more linked personal and financial data than a month of ordinary transaction records.

The infrastructure that carries it is equally constrained. Payment interfaces sit in segmented network zones with their own change control and hardening expectations, and introducing an outbound path from that zone to an external inference service is a material architectural change that both internal security and a supervisor will examine closely.

Running the models, the retrieval index over case material, and the audit log inside the bank’s own environment avoids that question rather than answering it — the same reasoning that drives on-premises AI in financial services generally.

Governance and the audit trail

Investigations are examined — by internal audit, by correspondents disputing an outcome, and by the regulator. Three things make an AI capability reviewable enough to survive that. A recorded division of labour per case, so it is unambiguous what the agent produced and what a person decided. A complete action log covering every system queried, record retrieved, and draft generated, retained long enough to reconstruct how a case was handled. And scoped access enforced at the data layer, so the reach of an agent is a property of the platform rather than a promise in a prompt. These are the same decision receipts any regulated agentic workflow needs.

How VDF AI supports payment investigations

VDF AI fits this profile closely: high case volume, heavy retrieval across systems that do not share identifiers, and a decision at the end that must stay with a person. VDF AI Agents handle intake classification, transaction identification, case assembly, and drafting under scoped access policy, so each workflow reaches only the systems and cases it is permitted to see. Retrieval is grounded in the bank’s own payment records, correspondent traffic, and procedures through private RAG, so a case summary reflects the actual record — and every claim in a draft carries a citation a reviewer can check. Human-approval steps sit on every output that leaves the institution. And because the platform runs inside the bank’s own environment, case data and the audit trail stay within the boundary the payments estate already sits behind.