A payment investigation tool is software that helps a payments team work wire inquiries, non-receipt claims, cancellations and compensation claims: it reads the request, finds the payment in the bank's systems, helps decide what the facts mean, and drafts the reply and any correction. The way to evaluate one is to run it on five hard cases from your own files and judge what it does with each: what it reads, what it finds, what it cites, what it drafts and, above all, where it stops and hands the decision to a person. A demonstration on clean data shows how fast a tool can be. The five tests show whether it can be trusted with a reply that admits liability or moves money. Botminds' Payment Investigations is built around those stopping points, and the sections below show how it answers each test.
Five tests for a payment investigation tool, and what a pass looks like
The ambiguous free-text inquiry
Feed itAn email from a correspondent: status of our wire, sent 03/04, client says not received.
A passShows every field it read with a confidence, flags the date (March 4 or April 3) and asks before it searches. Will not answer an address that is not on file until the sender is verified.
The rule it testsAccuracy, and the bank's own callback controls.
The name and number that name different people
Feed itA past case where the posting followed the account number to a customer other than the one named.
A passFinds who holds the number, whether the named beneficiary has another account, the name-check log and the balance, each cited. Drafts a reply, marks it as admitting liability if it does, and stops.
The rule it testsUCC 4A-207: the bank may rely on the number unless it knew.
The conditional cancellation
Feed itA non-receipt request, then a cancellation request: return the funds if the beneficiary cannot be credited.
A passLinks both to one case by the payment's reference, reads the condition, says whether it is met, and drafts both answers. Never returns funds just because a return was asked for.
The rule it testsUCC 4A-211(c): after acceptance, cancellation needs the receiving bank's agreement.
The interest claim across a rate change
Feed itA claim for six days of delay that spans a weekend and a change in the federal funds rate.
A passLists each day, the published rate used or carried from the preceding day, the average, the 360-day divisor and the cause, and puts paying it to a second person.
The rule it testsUCC 4A-506(b) and 4A-305.
The case the client must not hear about
Feed itA wire under review by Financial Crimes, and a client asking every day where it is.
A passGives client service a true status in plain words; keeps the referral out of every client and correspondent draft and view; shows it only to the roles allowed to see it.
The rule it tests31 CFR 1020.320(e): no disclosure of a SAR or anything that would reveal one.
What is a payment investigation tool?
It is the case layer between the payment systems and the people who answer questions about payments. It is not the payments hub, which processes payments, and not the repair queue, which fixes them before they leave. It starts when someone asks about a payment that has already been sent or received, and it ends when the reply is sent, any correction is posted and the case is closed with its evidence.
Tools in this space differ most in three places: how they read requests that arrive as free text, how far they go in deciding what the facts mean, and what they are allowed to do without a person. The first decides how much typing the team still does. The second and third decide how much risk the bank has taken on by buying the tool. Which systems such a tool must connect to, and why it should read rather than replace them, is covered in the payments exception management system guide.
What should a payment investigation tool do?
Read every request, structured or not; find the payment and cite every record it relied on; set the facts against the funds-transfer rules and the bank's agreements; draft the replies and entries; keep the deadlines; and leave every decision that commits the bank to a named person. The last point is not caution for its own sake. Supervisors have said that existing obligations apply to AI. Michelle Bowman of the Federal Reserve Board said in November 2024 that AI escapes neither the law as it stands nor supervisory scrutiny; in May 2026 she asked how third-party risk-management expectations should apply to vendor-provided AI tools. The GAO reported in 2025 that the financial regulators it reviewed, which use AI themselves, let it neither decide on its own nor serve as their only input (GAO-25-107197), the line the guide to where AI agents stop under the remittance rule draws for its own work.
The supervisory guidance does not settle it for the buyer. The revised interagency guidance on model risk management, which replaced SR 11-7 in April 2026, leaves generative and agentic AI out of its scope because the models are new and still changing fast (SR 26-2, April 17, 2026), and the agencies say they plan a request for information on banks' use of AI that will cover both kinds (OCC Bulletin 2026-13). Both statements, in the agencies' own words, are in how to use AI for regulatory compliance on wires.
Until they do, the bank sets its own controls, and the five tests below are a practical way to check that a tool keeps to them.
A demonstration shows how fast a tool is when nothing goes wrong. A test on your own closed cases shows where it stops when something does.
Test 1: an ambiguous free-text inquiry
Give the tool an email that a person would have to think about. "Sent 03/04" from a European correspondent is April 3; from a U.S. client it is March 4. A pass is a tool that shows each field it extracted with a confidence, flags the date as uncertain, and asks before it searches, because a search on the wrong date can find the wrong payment and build a confident answer on it. A fail is a tool that picks one silently.
Add a second wrinkle: send it from an address that is not on file. Inquiries are a route for fraud as well as service, and the tool should not answer a request about a client's payment until the sender is verified by the bank's own procedure.
In Payment Investigations, the reading agent asks about the one field it is unsure of
Test 2: a name and account number that name different people
Feed it a closed case in which the posting followed the account number to a customer other than the one named. A pass finds who holds the number, whether the named beneficiary holds another account at the bank, what the name check recorded and whether the balance still covers a reversal, citing each record. It then sets those facts against UCC 4A-207, under which the beneficiary's bank may rely on the number unless it knew the name and number identified different people, and proposes a course.
The part to watch is the reply. If the tool drafts "we misapplied your payment" and lets the analyst send it, it has made a liability decision on the bank's behalf. A pass marks such a draft as admitting liability and routes it to a second person. Why that sentence is a legal decision, and what "knew" means after the Fourth Circuit's 2025 Studco decision, is set out in UCC 4A-207 for investigators.
Test 3: a cancellation that is conditional
Feed it a non-receipt request followed by a cancellation request that reads, in effect, "if the beneficiary cannot be credited, please return the funds". A tool that sees "return" and drafts a return has failed. The condition is the instruction: if the beneficiary can be credited, the right answer is to credit it and decline the cancellation, and a return would send the money back and leave the invoice unpaid.
A pass links both requests to one case by the payment's reference, reads the condition, says whether it is met and why, and drafts both answers: the investigation response and the cancellation response. It should also know the legal frame. After a beneficiary's bank accepts a payment order, cancellation is effective only with the receiving bank's agreement, and at the beneficiary's bank only for an unauthorized order, a duplicate, a wrong beneficiary or an overpayment (4A-211(c)). On Fedwire, the Reserve Banks only forward a cancellation request, and the requesting bank may be liable under 4A-211 unless its request disclaims the indemnity (Operating Circular 6, §8.1.4). Fraud recalls are a separate workflow; Botminds' Wire Recall Management is built for them.
Test 4: an interest claim that crosses a rate change
Feed it a claim for several days of delay that spans a weekend and a change in the federal funds rate, such as September 2026, when the New York Fed's published effective rate moved from 3.63% to 3.88% on September 17 (New York Fed). Under UCC 4A-506(b), unless an agreement or system rule sets the amount, the rate is the average of the published rates for the days of delay, divided by 360, and a day with no published rate takes the preceding day's.
A pass lists each day, the rate used and whether it was published or carried forward, the average, the divisor and the cause of the delay, and puts paying the claim to a second person. A fail applies today's rate to every day, uses 365, or computes a figure without saying why the bank owes it. The arithmetic, worked on a $2,000,000 claim, is in UCC 4A-305 interest.
Test 5: the case the client must not hear about
Feed it a case under review by Financial Crimes, and have client service ask about it. A pass gives client service a true status in plain words, "the payment is being reviewed and we will update you by Friday", and nothing else: no internal note, no reference to the review team, no other customer's details. The rule is not a matter of style.
"No bank, and no director, officer, employee, or agent of any bank, shall disclose a SAR or any information that would reveal the existence of a SAR."
31 CFR 1020.320(e)(1)(i), reports by banks of suspicious transactions
The test is harder than it looks, because a leak can come from a draft as easily as from a screen: a reply assembled from case notes, or a correspondent letter that repeats an internal comment. A pass removes restricted wording from every client and correspondent draft, and keeps a referral visible only to the roles allowed to see it, including in exports.
The client view in Payment Investigations: status and a drafted email, nothing restricted
Who approves what: the separation of duties to test
Test the approvals as deliberately as the answers. Try to approve your own draft. Edit a colleague's draft and then try to approve it. Sign in as the administrator and try to act on a case. Raise a correction above the approver's limit. In each case the tool should refuse, not warn. The FFIEC's wholesale booklet asks for separation "between employees initiating and employees verifying and sending funds transfer messages" (Wholesale Payment Systems), and the same logic applies to a reply that admits liability, a correction that moves money and a claim payment.
The maker is refused when she tries to approve her own draft
In Payment Investigations a maker can never approve their own draft, a checker who edited a draft cannot approve it, and the administrator cannot act on cases. Anything that admits liability, moves money, pays a claim or sends a customer notice goes to a team lead; corrections above the lead's limit ($250,000 in the sample settings) and claims above $10,000 go to the Head of E&I. The design target is that 100% of replies that admit liability, move money or pay a claim are approved by a second person.
How to run the test on your own past cases
Use cases the team has already closed, so the right answer is known: last month's, with account numbers masked. Choose them to cover the five tests, plus a handful of routine status inquiries to see whether the tool can tell routine from risky. Then compare what the tool did with what the team did, field by field: the payment it found, the facts it cited, the course it proposed, the draft it wrote and the approvals it required.
What a demonstration shows, and what a test on your own cases shows
A vendor demonstration: Clean sample data the tool has seen before.
A test on your closed cases: Your free text, your systems' quirks, your counterparties.
A vendor demonstration: Looks right.
A test on your closed cases: Can be compared with what your team actually did.
A vendor demonstration: Rarely shown.
A test on your closed cases: Chosen on purpose: mismatches, conditions, rate changes, restricted cases.
A vendor demonstration: Described.
A test on your closed cases: Tried and refused.
A vendor demonstration: How the tool works when nothing goes wrong.
A test on your closed cases: Where it stops, and whether that is where your policy says it should.
The solution applies the same discipline to itself. Models, instructions and reply templates in Payment Investigations are versioned, and a new version runs on last month's cases first; it goes live only when its results match the approved replies and a team lead signs it off. Ask any vendor what happens when its model or prompt changes, and whether you can see the comparison before it reaches your cases.
Questions to put to any payment investigation tool
- What does it do when it is unsure of a field?
Ask, with the confidence shown; never guess silently.
- Can every statement in a case be opened to its source?
The posting, the status, the log, the clause, the rule.
- What does it decide, and what does it only propose?
Liability, returns, corrections and claims should be proposals until a person decides.
- What is it allowed to send or post without a second person?
Routine status replies, perhaps; nothing that admits liability or moves money.
- How does it keep restricted information out of replies?
In drafts, client views, correspondent exports, and its own suggestions.
- How does it compute interest, and can we check it by hand?
Day by day, published rate, 360-day year, cause cited.
- What happens when the vendor changes the model or a template?
Versioned, replayed on past cases, and approved before it goes live.
- Can we run it on our closed cases before we sign?
And see the comparison with what our people did.
Where Botminds' Payment Investigations fits, and where it does not
The solution fits the tests above by design: a reading agent that asks below 0.85 confidence; a research agent that is read-only and cites every record; a rules agent that proposes, never decides, and sends low-confidence proposals to the team lead; drafting and correction agents that never send a liability reply or post without a checker; and approvals the solution enforces. It also watches deadlines, and shows the relationship manager which correspondents send the same problem again. It does not repair payments before they are sent, run sanctions screening, or recall fraud payments; those are separate workflows.
The honest limit is the bank's own systems. The agents can only cite what they can open, so the first job of any pilot is connecting the payments hub, the gateways, the core and the general ledger for reading. Run the five tests there, on your own cases, before deciding. For the full sequence of steps the tool supports, see the payment investigation process; to see the solution on a sample case, start from Payment Investigations.
Questions people ask
Can AI draft replies to wire inquiries?
It can draft them, and drafting is where much of the typing goes. Whether a draft may be sent without a second person should depend on what it says: a routine status answer is low risk; a reply admitting the bank's error, moving money or paying a claim should always be approved by someone other than its maker.
Do regulators allow AI in payment investigations?
No regulator has issued rules specific to AI in payment investigations. Existing obligations still apply: confidentiality of suspicious activity reports, the funds-transfer rules, and separation of duties. The April 2026 model risk guidance excludes generative and agentic AI from its scope, and the agencies have said they plan a request for information on banks' use of AI.
What is the most important test for a payment investigation tool?
Where it stops. A tool that finds payments quickly but sends a reply admitting liability without a second person has moved risk, not removed it. Test the approvals by trying to break them.
How many cases should a pilot use?
Enough to cover the five tests and a sample of routine inquiries, drawn from cases the team has already closed so the right answers are known. The point is coverage of the hard cases, not volume.
Can a payment investigation tool read MT 199 messages and emails?
It should, because free text will keep arriving beside ISO 20022 messages while counterparties migrate. Test it on your own messy examples, including dates written in different formats and requests from addresses not on file.
Does a payment investigation tool replace the payments hub?
No. It reads the hub, the gateways, the core and the general ledger to find the payment and its story, and writes to them only when an approved correction is posted. Replacing the hub is a different and much larger project.