Payment recovery software, in banking, is software that helps a bank get back fraudulent or mistaken payments after they have left: it drafts the request for return on the right rail, follows up with every bank in the chain, tracks what is frozen and returned, and answers the requests other banks send in. The phrase also covers unrelated products, such as tools that retry failed card payments for subscription businesses or audit overpaid supplier invoices, so a buyer should check which problem a vendor solves. For a bank's recall desk, the right test is not whether a tool can produce a camt.056; any template can. It is whether the tool handles the cases that decide how much money comes back: a payment that has already moved to a second bank, a counterparty that goes quiet at 5:50 PM on a Friday, an indemnity that needs a signer, a fraud request against your own customer, a queue of instant payment requests due tomorrow, and an examiner who wants to see why every decision was made.
This page sets out that test. The worked example is Wire & Instant Payment Recall, Botminds' software for recalling fraudulent wires and instant payments and answering inbound requests; its screens show a fictional bank on sample data, and it should be held to the same test as any other product.
Why recall work is growing, in four published numbers
489%
rise in suspicious activity reports on check, ACH and wire fraud, 2014 to 2024
24.8thousand
business email compromise complaints to the FBI’s IC3 in 2025: 24,768
3,900
kill chain incidents in which the IC3 asked banks to freeze funds in 2025
50+
transactions to accounts at several banks that one account takeover incident can contain
What is payment recovery software?
For a bank, it is the system the recall desk works in once a fraudulent payment has left: the place where the customer's report becomes a request, where every bank in the chain is followed, and where frozen and returned money is matched to the recall and the customer is credited. It sits beside the payments hub, the Fedwire, SWIFT and instant payment gateways, the core banking system and case management, reading from them and writing requests and entries through them. It does not stop fraud before the payment is sent; that is fraud prevention, a different purchase covered by Wire Fraud Prevention.
The need is not hypothetical. The federal banking agencies' 2025 request for information on payments fraud cited FinCEN data showing that "the number of Suspicious Activity Reports (SARs) filed related to check, ACH, and wire fraud have increased 489 percent between 2014 and 2024." Each of those reports is a case someone worked, and the wire fraud cases among them are where recalls begin.
A test matrix for payment recovery software: six cases, what to watch, what a pass looks like
1A second hop
The beneficiary’s bank answers: part frozen, part already wired to another bank.
Watch: Does the next bank appear on the recall on its own, with the onward amount and time from the answer?
Pass: An onward request drafted through the beneficiary’s bank and the referral facts updated, both waiting for a person.
2A quiet bank at 5:50 PM on a Friday
No acknowledgment 15 minutes after the request arrived.
Watch: Does it escalate on a clock, using the other bank’s after-hours line?
Pass: A second message, the fraud mailbox, a call script, then the on-call supervisor, each logged.
3An indemnity above the signing limit
The beneficiary’s bank returns funds only on a signed letter.
Watch: Does the letter route to the authorized signer, and can the preparer or approver sign it?
Pass: Drafted from the bank’s template; maker, checker and a separate signer; template version recorded.
4A fraud request against your own customer
Another bank asks for money credited this morning to a new account with credits from several banks.
Watch: Does it read the live balance and the account history, and propose a hold?
Pass: A hold of the lesser of the amount and the balance proposed, the case handed to fraud, a notice that reveals nothing.
5Forty instant return requests due tomorrow
FedNow and RTP requests, mixed reasons and balances.
Watch: Does it propose an answer for each against the next-business-day clock, and stop below its threshold?
Pass: Proposals a specialist accepts in bulk and a supervisor approves as a batch; the hard ones go to a person.
6An examiner’s request
Every recall and inbound request for three weeks.
Watch: Can every value be traced to the message, call note or record it came from?
Pass: An export with account numbers masked and restricted reviews left out unless the BSA officer asks.
The test case: a second hop
Ask the vendor to run a recall in which the beneficiary's bank answers that part of the money is frozen and part has already been wired to another bank. It is the case that separates a request template from a recovery tool, because the sending bank has no relationship with the second bank, the onward wire was the beneficiary's own payment, and the recall now has two chains with two clocks. The FBI's Recovery Asset Team can follow such transfers when it is given the details, and its 2025 report describes doing so on "second hop" transactions; the bank's tool should make those details ready.
In the sample, the beneficiary's bank answered at 3:05 PM that $142,000 of a $186,000 payment was frozen, $38,500 had left by wire to a second bank at 1:31 PM and $5,500 had been taken in cash. At 3:06 PM the Trace agent added the second bank to the recall as an onward station. The return instructions sent at 3:12 PM asked the beneficiary's bank to recall its own 1:31 PM wire, and the agent prepared the law enforcement referral pack, for a person to send. The traced recall, minute by minute, is in how long a wire recall takes.
The recall as a relay: the onward bank added where money moved on
Can software chase multiple banks?
It should, and the case mix is moving that way. The IC3 says that in 2025 its kill chain process saw a rise in account takeover cases, and that "ATO-related incidents can contain upwards of 50 or more transactions to different recipient accounts at multiple banks happening simultaneously via ACH transactions." A desk working those from a spreadsheet cannot see which of fifty banks has gone quiet. Software should show each bank in each chain with its own clock, follow up on silence without being told, and record each bank's real response times so the next recall knows who to call.
Ask to see the follow-up rules as settings, not code: when it writes again, when it asks a person to call, when it escalates to a supervisor, and what it does outside business hours. In the sample bank's settings those are 15, 30 and 60 minutes, with the other bank's after-hours line and the on-call supervisor from 6:00 PM to 7:00 AM Eastern and at weekends. The contact data behind those rules is set out in the contact sheet and message map.
Does recovery software handle FedNow?
It must, in both directions, and the inbound side is usually larger. The FedNow procedures ask a receiving bank to answer each return request by midnight Eastern on the next standard business day, with a final answer to a pending request within 10 business days, and a bank that receives hundreds a month needs those clocks tracked request by request. The sample bank sees about 900 instant payment return requests a month, both ways, and answered 629 of 648 within one business day in its sample month.
Two details are worth testing. The first is whether the tool proposes the right one of the four answers from the balance and the reason, and sends the hard cases to a person. The second is consumer payments: the Philadelphia Fed's Consumer Compliance Outlook notes that a FedNow or RTP transfer to or from a consumer account can be subject to the Electronic Fund Transfer Act and Regulation E, so a consumer's claim against its own bank runs on separate clocks from the interbank request. The receiving side is covered in instant payments recall vs return.
Who approves sends in recovery software?
People, every time, and not the same person twice. A recall request, a return, a hold on a customer's account, a credit and a customer update each move money or speak for the bank, so each should have a maker and a different checker, and indemnities above a limit a separate authorized signer. The software's job is to make those approvals fast, with the evidence beside the button, and impossible to bypass.
What the agents in Wire & Instant Payment Recall do, and where people decide
Agent
Intake and Recall agentsMatch the report to the payment, compare it with 24 months of history, draft the request on the right rail, draft return instructions and indemnities.
Never: send anything; stop without a callback on the number on file.
Agent
Follow-up and Trace agentsKeep each bank’s clock, ask for calls, add onward banks, prepare the law enforcement referral.
Never: contact a customer or law enforcement.
Agent
Freeze agentReads inbound requests, the live balance and the account history; proposes holds and answers; flags mule signs.
Never: places a hold itself.
Agent
Customer update and return-matching agentsDraft plain-language updates; match returns to recalls and propose the entries and the credit.
Never: promise recovery; credit more than came back.
A person decides
Specialist, supervisor, signerPrepare, approve and sign every send, hold, return, credit and update; nobody approves or signs their own work.
Never: approve or sign anything they prepared.
A buyer should also ask how the agents are governed, because the supervisory guidance does not yet do it for them. The 2026 interagency model risk guidance issued through the OCC is explicit about its limits: it places generative and agentic AI models outside its scope, as new and still changing quickly. What that means for any bank running agents is examined in whether a customer risk rating model is a model.
That leaves the controls to the bank and its vendor. In the sample configuration, each agent has a version, a model, a confidence threshold and a score on a golden set of 240 past recalls; a new version runs against those recalls before it goes live, and changes to agents, clocks and roles are proposed by an administrator and approved by the SVP of payment operations. Ask any vendor for the equivalent, and for how overrides are counted.
What audit trail should recall software keep?
Who did what, when, why and on which evidence, for people, agents and the other banks, in a record nobody can edit. An examiner, internal auditor or law enforcement agent should be able to start from any number on a recall, the frozen amount, a time, a signature, and open the message, call note or record it came from. Account numbers should be masked in every export, and anything that would reveal a suspicious activity report should be kept from anyone who does not need it.
The audit trail and a masked export pack for examiners
The customer side: updates that promise nothing
The customer whose money is missing will ask what is happening, and the answer has to be accurate, plain and careful. A good update says what is frozen, what has already left, what happens next and what the customer can do today, and it promises no recovery. It must also never mention a restricted review, because a suspicious activity report and anything that would reveal one are confidential.
The customer hears where the money is, in plain words, checked before it goes
What software cannot do for a recall
It cannot make another bank answer, and nothing in Article 4A or the Fedwire guidance cited on these pages sets a deadline for a beneficiary's bank to answer a wire recall. It cannot decide who bears a loss under the customer's agreement, sign the bank's indemnities, or contact law enforcement on the bank's behalf. It cannot recover money that left before the customer reported, and on the published figures the national programs freeze about half of what reaches them. A vendor who promises a recovery rate is promising something no tool controls.
A spreadsheet recall desk against recovery software, honestly
Spreadsheet, email and phone: Typed from the payments screen; minutes to hours, depending on who is free.
Recovery software: Drafted from the payment order with its references; still needs a maker and a checker.
Spreadsheet, email and phone: In one person’s head and inbox.
Recovery software: Every bank with its clock on one screen, including banks added when money moves on.
Spreadsheet, email and phone: Noticed when someone remembers to check.
Recovery software: Escalated on a clock, with the other bank’s best channel and after-hours line.
Spreadsheet, email and phone: Retyped into notes.
Recovery software: Read, cited and highlighted in the source.
Spreadsheet, email and phone: How fast other banks answer, and how late customers report.
Recovery software: The same.
A scorecard for the demo
Bring your own past recalls, including at least one second hop, one recall that waited on a silent bank and one inbound fraud request, and score the product on these points. None needs a vendor's claimed recovery rate to answer.
A demo scorecard for payment recovery software
- Report to request, on your own case
Time it from a logged report to a request ready for approval, with references copied, not retyped.
- The second hop appears without anyone noticing it
From the other bank’s answer, with the onward amount and time, and the referral facts updated.
- Silence escalates on a clock, after hours too
Shown as settings you can change, with each step logged.
- Maker, checker and signer cannot be the same person
Try to approve your own request; it should refuse.
- Inbound requests get a proposed answer and a hold
Lesser of the amount and the balance, with the account history cited.
- Every number opens its source
The frozen amount should open the other bank’s message with the passage highlighted.
- Customer updates promise nothing and reveal nothing
No message codes, no promise of recovery, no restricted review.
- The export masks and excludes by default
Account numbers masked; restricted reviews only for the BSA officer.
The measures that tell you afterwards whether the tool helped are the ones in the wire fraud recovery rate: minutes from report to request, share frozen, share returned and the reason for every dollar not recovered. Run them on the same past cases before and after.
Questions people ask
How is payment recovery software different from fraud prevention software?
Prevention works before the payment leaves: callbacks, anomaly checks and holds on suspicious wires. Recovery starts after it has left: the request for return, the chase through the chain, the indemnity, the return and the credit. Most banks need both, and they share data, but they are bought and run separately.
Does recovery software replace the Fedwire gateway?
No. It drafts requests and reads answers through the bank's existing Fedwire, SWIFT and instant payment gateways, and reads payments, balances and history from the payments hub and core. Connecting to those systems is the first piece of work in any pilot.
Can recovery software contact law enforcement?
It should prepare the referral, not send it. In the sample configuration the Trace agent assembles the facts FinCEN and the IC3 ask for, and a person files the complaint; the agents never contact law enforcement or a customer themselves.
Do we need separate tools for wires and instant payments?
Not necessarily. Fedwire and FedNow both use a camt.056 request and a camt.029 answer, so one tool can handle both, provided it knows each rail's clocks and rules, including FedNow's next-business-day response guideline and the indemnity disclaimer.
What should a pilot of payment recovery software measure?
On the same set of the bank's past recalls and inbound requests: minutes from report to request, answer times by counterparty, requests answered on time, and the share frozen and returned with the reason for each shortfall. Those are the numbers a board and an examiner will ask about.