Everything in the card dispute system rests on one structural fact: a card payment can be reversed after the fact. The issuer holds the cardholder's money, settlement runs on a delay, and the network rules give the issuer a tool to pull funds back through the acquirer. Reason codes, representment, and Compelling Evidence all assume that reversibility exists.
Account-to-account (A2A) rails break that assumption. On real-time payment systems the money leaves the sender's account and lands in the recipient's account in seconds, and settlement is final. There is no issuer holding the funds, no acquirer in the middle, and no chargeback message in the standard. When a payment goes wrong on these rails, the card playbook does not transfer. This lesson maps what does.
Why irrevocability changes the mechanism
A chargeback is a network-guaranteed reversal. The card networks built a four-party clearing layer specifically so that the issuer can debit the acquirer without the merchant's consent, subject to the rules.
Instant A2A rails are built the opposite way. On The Clearing House's RTP network and on the Federal Reserve's FedNow Service, payments are credit-push, they settle 24/7, and they are irrevocable once submitted. A sending institution cannot revoke or recall a payment after it enters the network. The design goal was certainty of funds for the receiver, which is the inverse of the cardholder-protection goal that produced the chargeback.
That trade is deliberate. It also means the recourse a cardholder takes for granted does not have an equivalent on these rails. What exists instead is a request, not a guarantee.
Request, not reversal
On RTP, when a sending participant determines a payment was fraudulent or sent in error, it sends a Request for Return of Funds message (camt.056). For fraud it carries the reason code FRAD. The receiving participant responds with camt.029, and outside of fraud claims it is generally expected to respond within 10 business days.
The structural point is what the receiving bank is not obligated to do. It is not required to return the money. If the funds have already been withdrawn from the receiving account, which is the normal outcome of a successful scam, there is nothing left to send back. FedNow works the same way: it provides bank-to-bank messaging to request a return, but the return depends on cooperation and on the money still being there.
So the dispute mechanism on A2A is best understood as facilitated cooperation between two banks, not an adjudicated reversal between four parties. The leverage a card issuer has does not exist.
The recourse gap, and who falls into it
The gap is sharpest for authorized push payment (APP) fraud: scams where the customer is tricked into sending the payment themselves.
In the US, Regulation E protects consumers against unauthorized electronic fund transfers. An APP scam is, by the regulation's definition, authorized. The customer initiated and approved it, even though they were deceived. That authorization is what disqualifies the transaction from Reg E recovery. Zelle's own user agreement reflects this: payments sent to an enrolled recipient are treated as final and irreversible and cannot be disputed.
Compare the two failure modes:
- Unauthorized transfer. A bad actor takes over the account and sends money the customer never approved. This is covered under Reg E, and the bank generally bears the loss.
- Authorized push payment scam. The customer is manipulated into sending the money themselves. The transfer is authorized, Reg E does not reach it, and the customer typically bears the loss unless a voluntary return succeeds.
The same deception that a card network might treat as a fraud chargeback on a card produces no equivalent right on an A2A rail. That is the recourse gap.
A worked example
A small business owner receives an email that looks like it comes from a supplier, with new bank details and an urgent invoice. The owner logs into their bank app and sends a $40,000 RTP payment to the new account.
On a card, an unauthorized or misrepresented charge of this kind would trigger a dispute, a reason code, and a representment contest, with the issuer holding the funds in the meantime. On RTP, the $40,000 settled in seconds and is gone. The sending bank can fire a camt.056 with FRAD at the receiving bank, but by the time the owner realizes the supplier never changed details, the receiving account has usually been drained. The receiving bank has no obligation to make the sender whole, and no funds to return. Recovery now depends on speed of reporting and on the money not yet having moved on.
How the rails are trying to close it
The networks are layering controls on top of irrevocable settlement rather than adding reversibility.
FedNow lets participants build negative lists of accounts they will not send to or receive from, and rejects messages that fail those checks. It added a fraud-reporting capability so institutions can flag a suspect payment quickly, plus account activity thresholds and value and velocity controls by customer segment. The Federal Reserve also folded its ScamClassifier model into the reporting flow. These are pre-settlement and detection tools, not post-settlement reversals.
Regulation is moving faster outside the US. In the UK, a mandatory APP reimbursement regime took effect on 7 October 2024 for Faster Payments and CHAPS. It caps reimbursement at £85,000 per claim, splits the cost equally between the sending and receiving payment firms, and requires the refund within five business days, or up to 35 days where more investigation is needed. In the first three months, around 86 percent of money lost to in-scope APP scams was returned to victims.
Brazil takes a third approach. Pix runs a Special Return Mechanism (MED) operated through the central bank, letting a victim trigger a block and return when there are signs of fraud. Effectiveness is constrained by the same physics as everywhere else: the central bank reported that only about 9 percent of requests were refunded in 2023, with most denials caused by the receiving account already being empty or closed.
The takeaway
On card rails, recourse is a property of the system: the chargeback is built in. On A2A rails, recourse is a policy choice layered on top, because the settlement layer itself is irrevocable by design.
Two things follow for anyone building dispute operations across rails. First, do not assume a dispute primitive exists on an instant rail just because one exists on cards. The default is a request the receiving bank can decline, and a window that closes the moment the funds move on. Second, the defense shifts left. With no reliable reversal, the controls that matter are pre-send: confirmation of payee, negative lists, velocity limits, and fast fraud reporting between institutions. Where the UK and Brazil have legislated or mandated a return, that is regulation supplying the recourse the rail does not, and the cost lands on the banks, not a network clearing layer. Build for the rail you are actually on, not the one whose rules you already know.