Instant Payment Exceptions, Fraud and Return-of-Funds Requests. A practitioner deep dive into post-release RTP and FedNow exceptions, fraud classification and reporting, return-of-funds requests and responses, network-specific returned-value mechanics, partial recovery, Regulation E considerations, reconciliation and 24x7 operations.
Instant payments are designed to complete quickly, but speed does not remove exceptions. It changes their character. In ACH or a conventional batch process, an operations team may have hours before settlement, a return window, or a queue in which an item can still be stopped. In RTP and FedNow, the difficult event often arrives after the payment has already crossed the network boundary and settlement has become final. A customer says, “I sent it to the wrong person.” A fraud team discovers an account takeover. A receiving bank accepted the payment but cannot legally make the funds available. An originator reports that the beneficiary was a scammer. A bank times out and does not know whether a payment settled. A return request is accepted for only part of the original amount. A receiving institution has already moved the funds. A consumer disputes the transfer and the bank must separate its legal error-resolution duties from the network’s voluntary return-of-funds process.
That is the subject of Chapter 26.
Chapters 21–25 established the US instant-payment landscape, RTP and FedNow credit-transfer mechanics, Request for Payment, and the reachability/liquidity/routing layer. This chapter does not repeat those foundations. It concentrates on what happens after release, after settlement, or after a fraud/exception signal appears. The central operational principle is:
final settlement does not mean the bank stops investigating; it means recovery must be handled as a new controlled process rather than by pretending the original payment never happened.
Both RTP and FedNow use the Request for Return of Funds (camt.056) and the response to that request (camt.029), but the returned-value mechanics are not identical. FedNow uses pacs.004 as its Payment Return value message. RTP return-of-funds value is generally sent as a new RTP credit transfer (pacs.008) when RTP-send enabled, or another agreed electronic method where appropriate. These events must never be collapsed into one generic “refund” status. A request asks. A response communicates the receiver’s decision or investigation state. A separate value transaction actually returns money.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–2, Sections 4–10 and Sections 11–13. For the next 10 minutes, use the chapter’s three diagrams to separate unknown outcomes, fraud cases, return requests and recovered funds. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: What must be reconciled before an instant-payment recovery case can be financially closed? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why instant-payment exceptions are different
- The exception taxonomy a bank must maintain
- Participants, ownership and investigation responsibilities
- Finality, posting and the recovery boundary
- Fraud before, during and after payment release
- RTP fraud reporting and return-of-funds model
- FedNow fraud reporting and return-of-funds model
- Request for Return of Funds: camt.056
- Return request responses: camt.029
- Returned value: FedNow pacs.004 and RTP return credit transfers
- Customer disputes, Regulation E and network recovery
- Unknown outcomes, duplicate risk and exception evidence
- Reconciliation, accounting and reporting
- 24x7 operations, case management and escalation
- Controls, architecture and testing
- End-to-end cases, role checklist and authoritative references
1. Why instant-payment exceptions are different
An instant-payment exception starts with an uncomfortable fact: by the time a human notices the problem, the network may already have done exactly what it was instructed to do. That difference matters. A fraud alert raised five seconds after release is not the same as a fraud alert raised five seconds before release. A customer calling after settlement cannot be treated as if the payment were still waiting in a queue. The bank must first establish financial truth before it decides what recovery action is available.
The correct first question is therefore not “Can we cancel it?” but “What is the authoritative state of the original payment?” The answer can be pre-release, rejected, unknown, accepted, settled, beneficiary-posted, returned, partially returned, or subject to investigation. Every recovery workflow should start from that state. If the bank skips this step, an operator may send a return request for a payment that never settled, issue a duplicate customer credit, or create a second payment while the original is still financially live.
Instant payments also compress the time available to detect fraud before finality. That increases the importance of preventive controls, but it does not eliminate post-payment controls. Fraud reporting, interbank communication, account monitoring, recipient-fund preservation where legally permissible, case investigation, customer protection and recovery remain essential after settlement. The operating model therefore has two layers: prevent before release and investigate/recover after release.
A bank should also avoid using the word “return” loosely. A payment may be rejected before settlement; that is not a return. A customer may request a refund; that is not automatically a network return. A receiving bank may agree to send funds back; the actual return is a new value message. A return request may be refused because funds are unavailable, because the receiver does not agree with the basis, or because legal restrictions apply. The original payment remains part of the audit trail in every case.
For education and system design, Chapter 26 uses four separate objects: the original payment, the fraud/exception case, the return request, and the return payment. Those four objects can have different identifiers, timestamps, owners and states. A bank-grade platform must correlate them without merging them.
2. The exception taxonomy a bank must maintain
A mature bank does not run one generic “instant payment exceptions” queue. It classifies the event because the correct response depends on what actually went wrong. At minimum, the taxonomy should separate pre-settlement rejects, post-settlement operational exceptions, fraud/scam allegations, erroneous payments, legal/compliance holds, unknown outcomes, customer disputes, return requests, return payments and reconciliation breaks.
Pre-settlement rejects belong primarily to the sending lifecycle. Examples include invalid message data, unreachable participants, amount-limit breaches, insufficient settlement capacity, receiver rejection or failed network validation. These were covered in Chapters 22–25. Chapter 26 only references them to stop a team from treating a reject as a settled-payment recovery case.
Post-settlement posting exceptions occur when the interbank payment has settled but the receiving bank cannot complete normal beneficiary availability or posting. FedNow’s accept-without-posting path is the clearest example of why settlement state and posting state must be held separately. RTP has its own rules around accepting a credit transfer and later returning funds in permitted circumstances. The receiving bank cannot erase final settlement; if funds are sent back, the return is a new financial event.
Fraud exceptions should distinguish unauthorized activity, account takeover, fraudulently induced authorized payments, mule activity, beneficiary impersonation, invoice redirection, business-email compromise, elder exploitation, synthetic identities and other typologies relevant to the bank’s products. Network reason codes are important, but the bank’s internal fraud taxonomy should be richer than the small number of codes carried in an ISO message.
Erroneous payments include wrong beneficiary, wrong account, duplicate initiation, incorrect amount and other customer or bank errors. Some may justify a return request, but a return request does not guarantee recovery. The receiving bank must decide what it can lawfully and operationally return.
Unknown outcomes are not ordinary fraud or return cases. They occur when the sending bank cannot establish whether a released transaction was accepted or settled. Chapter 25 established that OUTCOME_UNKNOWN must block fallback. Chapter 26 carries that principle into investigations: resolve the original state first, then decide whether a return-of-funds process is appropriate.
Consumer disputes can create legal obligations independent of network rules. For covered consumer electronic fund transfers, Regulation E may require investigation and error-resolution steps even if the instant-payment network itself provides only a voluntary or scheme-governed return request process. The bank must never tell a consumer that “the network is final, therefore we have no investigation obligation.” Finality and consumer-protection duties answer different questions.
3. Participants, ownership and investigation responsibilities
An instant-payment exception can involve more parties than the original sender and receiver. The end-to-end chain may include the originator, sender financial institution, receiving financial institution, beneficiary, RTP or FedNow operator, service providers, a correspondent or settlement agent, fraud operations, payment operations, compliance, customer servicing, legal, treasury, accounting and external law-enforcement or regulatory contacts.
The sender financial institution owns the customer-facing decision to investigate the sending-side complaint, determine what happened, establish the original payment state, classify the event and decide whether a return request or other recovery action is appropriate. It must preserve the original message, network identifiers, authentication evidence, fraud-decision evidence, customer instructions and timeline. Sending a camt.056 is not a substitute for conducting that investigation.
The receiving financial institution owns the decision process on the receiving side. It must locate the original payment, identify the beneficiary account, assess whether funds remain available, review fraud or legal restrictions, determine whether a request can be accepted, rejected, held pending investigation or partially executed, and respond using the applicable network process. It should also preserve evidence showing why it made that decision. The receiver’s duty is not simply “send money back when asked”; a bank must follow applicable law, network rules and its own controlled investigation process.
A service provider may transmit messages or operate portions of the exception workflow, but outsourcing connectivity does not outsource the bank’s accountability. A bank needs clear contracts and runbooks defining who detects failures, who creates return requests, who receives camt.029, who releases pacs.004, who stores network acknowledgements, who opens incidents and who can make a customer-affecting decision.
For FedNow participants using correspondents, settlement relationships remain relevant to returns because a pacs.004 is itself a value message that settles through Federal Reserve account structures. For RTP, the funding model and funding-agent relationship similarly matter to the actual return value movement. Chapter 26 does not repeat the liquidity architecture, but operations must understand that a return payment is not a database reversal; it is a new settled transaction that must be funded, accounted for and reconciled.
Internally, ownership should be explicit. Fraud Operations owns fraud classification and investigative judgement. Payment Operations owns network message handling and payment-state truth. Customer Servicing owns communication. Accounting owns ledger integrity. Treasury owns settlement-funding consequences. Compliance and Legal own applicable legal/sanctions questions. A case manager or orchestrator should coordinate these roles so that five teams do not independently credit the same customer.
4. Finality, posting and the recovery boundary
Finality is the line that makes Chapter 26 necessary. When an RTP or FedNow payment settles finally under the applicable network framework, the sending institution cannot simply reverse the original interbank settlement entry because the customer later regrets the payment or fraud is discovered. Recovery must occur through a permitted return process, a separate payment, legal process or other controlled remedy.
This is why banks need at least three separate states: network settlement, beneficiary availability/posting, and customer recovery. A payment can be finally settled while the beneficiary posting is temporarily restricted. A customer can be provisionally credited by their bank while interbank recovery remains unresolved. A receiving bank can return part of the funds while the original payment remains fully recorded as a settled transaction. These are not contradictions; they are different accounting and legal layers.
FedNow explicitly supports pacs.004 as a payment return. Its April 2026 Operating Procedures explain that a previously received pacs.008 can be returned when a participant honors a camt.056, or when the participant itself cannot apply funds that it previously accepted, including certain post-accept-without-posting situations. The procedures also state that a return should generally travel through FedNow when the original payment was FedNow, which improves reconciliation and end-to-end traceability.
RTP similarly supports return-of-funds messaging and has separate guidance on returning funds after an Accept response. The key lesson is the same: acceptance/finality of the original payment and a later return can both be true. A data model that changes the original status from SETTLED to RETURNED loses financial history. A better model keeps the original payment settled and links one or more return events to it.
For partial returns, the original payment amount remains unchanged. The system should derive a recovery position such as RETURNED_AMOUNT, OUTSTANDING_RECOVERY_AMOUNT and RECOVERY_STATUS. This becomes essential when $10,000 was sent, $6,000 is recovered, $4,000 remains unavailable, and the bank separately credits the customer under a legal or commercial remediation decision.
The recovery boundary should therefore be visible in UI and APIs. Before finality, payment processing can still reject or stop under scheme rules. After finality, customer support should no longer see a “Cancel payment” button. It should see actions such as “Open fraud case,” “Request return of funds,” “Record external recovery,” “Issue customer provisional credit,” or “Escalate to investigation,” each with its own authority and evidence requirements.
5. Fraud before, during and after payment release
Fraud control is not one scoring event. An instant-payment bank needs controls at onboarding, beneficiary setup, initiation, authentication, pre-release decisioning, network interaction, receiving, post-payment monitoring and case investigation. Chapter 25 covered the pre-release routing gate; Chapter 26 focuses on what happens when a fraud signal is received after the payment is already financially committed.
A sending bank may learn about fraud from the customer, its own fraud engine, a receiving-bank alert, network fraud-reporting channels, law enforcement, another financial institution or retrospective transaction monitoring. The first response should be to establish whether the allegation concerns an unauthorized EFT, an authorized payment induced by deception, a bank processing error, or another scenario. Those distinctions influence legal obligations, fraud coding and recovery expectations.
For account takeover, the customer may not have actually authorized the transfer even if valid credentials were used by the fraudster. CFPB Regulation E materials make clear that unauthorized EFT analysis is not resolved solely by showing that credentials or an access device were used. By contrast, where the customer themselves intentionally instructed the payment after being deceived, the legal analysis can differ even though the bank still has fraud, complaint and recovery responsibilities under its policies and applicable law.
Receiving banks also need post-credit fraud controls. A newly credited account may rapidly cash out, transfer onward or purchase assets. Real-time mule detection, recipient-risk monitoring and interbank alerts can materially affect recovery chances. Yet holds or restrictions must be legally supportable and operationally governed. “Fraud suspicion” should never become an uncontrolled excuse to freeze customer money indefinitely.
The bank should record fraud as an independent case state: SUSPECTED, CONFIRMED, NOT_CONFIRMED, CUSTOMER_DISPUTE, LAW_ENFORCEMENT_REFERRAL, RECOVERY_REQUESTED, RECOVERY_PARTIAL, RECOVERY_FAILED, CUSTOMER_REMEDIATED, and CLOSED. Network message statuses should feed this case but should not replace it.
A critical operational lesson is that fraud reporting and funds recovery are related but not identical. Reporting a fraud condition to the network or counterparty communicates information. Recovering funds requires an actual return or other value transfer. A camt.056 with a fraud reason is a request/reporting mechanism, not money movement. A pacs.004 is value movement.
6. RTP fraud reporting and return-of-funds model
At the 5 October 2026 audit, The Clearing House library labels the 30 September 2026 RTP Operating and Participation Rules current and lists an October 4 package as upcoming, while the October 4 Operating Rules PDF says its changes are effective October 4, 2026 (except OBO changes effective March 31, 2028). The chapter therefore keeps an explicit version-control warning: confirm the operator's effective package before production activation and do not treat the June 1 baseline as current. The library also lists Message Specifications Version 5.0 and Reports Specification Version 5.2.
RTP uses camt.056 for a Request for Return of Funds and camt.029 for the response. The Clearing House technical documentation describes these as bank-to-bank messages used for errant and fraudulent payments. The actual return of value is handled separately, so the bank must correlate the request/response exchange to the original credit transfer and the resulting return transaction.
RTP’s 2026 fraud-reporting framework matters because a modern bank must classify and report fraud consistently rather than treating every return request as a generic error. Current RTP materials distinguish fraud-reporting reasons and require participants to act on fraud alerts and maintain appropriate controls. The chapter’s practitioner supplement goes deeper into the current FRAD/fraud-classifier treatment and the 2026 reporting updates, including the distinction between unauthorized activity and fraudulently induced payments where applicable.
A return request should include enough original-payment references for the receiving participant to locate the transaction quickly. The sending bank should never construct a request from customer-entered data alone. It should source original identifiers from the immutable payment record and carry the case reference internally so that operations can reconstruct: original pacs.008 → fraud allegation → camt.056 → camt.029 → return value event.
RTP rules also distinguish ordinary return requests from fraud-related and Request-for-Payment-warranty-related situations in their response-time treatment. That is important operationally. A bank cannot use one SLA for every case. Fraud investigations may legitimately require more investigation time than a straightforward erroneous-payment request, while still requiring prompt handling and controlled customer communication.
The operator library currently exposes both a September 30 package labelled current and an October 4 package labelled upcoming, although the October 4 PDF states that its changes are effective October 4, 2026. This is a release-control discrepancy, not a reason to retain June 1 as current. A bank implementation should confirm the operator's effective package, select rules by effective date, and retain the superseded package for historical processing.
7. FedNow fraud reporting and return-of-funds model
FedNow’s current public Operating Procedures are Version 3.6, effective April 28, 2026. They contain dedicated sections for risk mitigation, fraud reporting, Request for Payment warranties, value messages, Return Request (camt.056) and Payment Return (pacs.004), reports and reconciliation, and certification testing. Operating Circular 8, effective April 1, 2026, together with subpart C of Regulation J, supplies the governing funds-transfer framework.
The FedNow model makes the separation between request, response and value especially clear. A participant may send a camt.056 asking another participant to return all or part of a previously settled payment. The receiving participant can respond through camt.029. If funds are actually returned, the return travels as pacs.004. A participant may also initiate a pacs.004 without first receiving a return request in circumstances where it needs to return a payment it previously received.
FedNow’s current Operating Procedures describe camt.029 outcomes including acceptance of the return request (IPAY), rejection (RJCR), pending investigation (PDCR) and partial execution (PECR). Those statuses are operationally powerful because they prevent a binary “yes/no” model. PDCR means the case is alive but unresolved. PECR means the recovery may be partial and the sender must reconcile the amount actually returned rather than assuming full recovery.
For fraud reporting, FedNow permits a sending participant that later identifies fraud to send camt.056 with fraud reason FRAD. A receiving participant returning funds associated with fraud can use pacs.004 with the applicable fraud return reason such as FR01 as described in the current Operating Procedures. The procedures also distinguish Request-for-Payment warranty claims using WNTB. These are not cosmetic codes: they influence reporting, investigation context and downstream analytics.
FedNow’s procedures state that a camt.056 should generally be sent within 60 calendar days from settlement for ordinary use, while fraud-reporting and RfP-warranty cases are not subject to that 60-day guideline. This is exactly why a rules engine must know the reason for the request, not merely the message type.
The procedures also make clear that payment returns are value messages and should be reconciled through FedNow reporting and accounting evidence. A return can be for the full amount or a portion of the original payment. The receiving institution’s value limit does not simply behave like the original outgoing customer credit-transfer limit; return-message validation has its own network rules. This reinforces the need for return-specific controls rather than reusing the ordinary send-payment workflow unchanged.
8. Request for Return of Funds: camt.056
camt.056 is often misunderstood because its name sounds like a reversal. It is not. It is a request from one financial institution to another concerning a previously sent payment. No customer should be told “the money has been returned” merely because the sending bank successfully transmitted a camt.056.
A robust return-request workflow begins with eligibility. The system should confirm that the original payment exists, identify the network, establish that it settled, confirm that no full return has already occurred, classify the reason, calculate the amount being requested, determine whether the applicable rule window or fraud exception is satisfied, and verify that the request is being sent to the correct counterparty.
The request should carry original transaction references, requested return amount, reason and sufficient additional information for the receiving institution to investigate. Internal data should add customer case ID, fraud case ID, operator, timestamp, evidence link, approval trail and customer communication state. Do not overload the ISO free-text field with internal confidential case detail that the counterparty does not need.
Return requests should be idempotent. A customer may call twice, an operations user may refresh a screen, or an API may retry after a timeout. The bank should have a stable return-request business key and prevent duplicate camt.056 messages for the same requested amount/reason unless a deliberate controlled follow-up is allowed. A transport timeout must not cause a blind resend with a new identity.
For partial recovery requests, the system needs an amount model. Suppose the original payment was $25,000 and $5,000 has already been returned. If a later fraud investigation seeks the remaining $20,000, the return-request service must know the outstanding recoverable position and avoid requesting $25,000 again. That position should be derived from settled return value, not merely from return-request responses.
A camt.056 should also open or update a case timer. Operations need to know when the request was transmitted, acknowledged, delivered, responded to and financially satisfied. The correct KPI is not just “requests sent”; it is request-to-response time, recovery rate, partial-recovery rate, ageing by reason, and unresolved exposure.
9. Return request responses: camt.029
camt.029 communicates what happened to the return request. It must be processed as a case event, not as a customer payment status. A receiving bank can accept, reject, indicate pending investigation or communicate partial execution depending on the network’s supported semantics and the scenario.
An accepted response means the receiver has agreed to return funds, but the sending bank should not credit “recovered” value until it sees the actual return settlement or otherwise has authoritative evidence that value came back. The response and the money movement are two separate events.
A rejected response should carry a reason and move the case into a controlled outcome such as RETURN_REQUEST_REJECTED, not PAYMENT_FAILED. The original payment did not fail. It succeeded earlier. What failed was the recovery attempt. Customer communication should preserve this distinction because saying “your payment failed” after the beneficiary already received funds creates serious confusion.
A pending investigation response is a genuine non-final state. The case needs ageing, ownership and follow-up. It should not trigger automatic closure or customer reimbursement unless the bank has a separate legal/policy basis for reimbursement. The bank may decide to provisionally credit a consumer under applicable error-resolution rules while the interbank recovery remains pending; those two state machines must remain separate.
A partial execution outcome means the bank must expect less than the requested amount and reconcile the actual return. The system should support multiple linked return payments if the scheme/process allows recovery in stages, while preventing cumulative returned value from exceeding the original payment unless a separate indemnity/remediation mechanism applies.
Incoming camt.029 messages should be correlated using network and original-payment references, not only a local case number. If correlation fails, the item should enter a repair queue with full raw-message evidence. A bank should never silently discard an unmatched return response because that response may represent a recovery commitment or refusal with customer impact.
Operations dashboards should show the latest counterparty response, response timestamp, requested amount, accepted/expected amount, settled returned amount and outstanding amount. This turns a message exchange into an auditable recovery position.
10. Returned value: FedNow pacs.004 and RTP return credit transfers
The actual return of value is where RTP and FedNow diverge technically. FedNow uses pacs.004 as its Payment Return value message. RTP does not use the same FedNow-style return-value message; when RTP funds are returned, the receiving institution generally sends a new RTP credit transfer (pacs.008) if send enabled, or another agreed electronic return method where appropriate. In either network, returned value is a new financial event with accounting, liquidity, statement, reporting and reconciliation consequences on both sides.
The returned-value transaction must carry enough reference to the original payment for correct application. For FedNow, persist the pacs.004 identifiers and original-payment linkage. For RTP, persist the new return pacs.008 (or alternate return method) identifiers and the original RTP reference. In both cases, maintain the relationship to any camt.056/camt.029 exchange.
A full return does not change the historical fact that the original transfer settled. The original customer debit may remain on the statement and a separate returned-funds credit may appear, depending on product design. Internally, ledger postings should preserve both financial events. Netting them into one invisible zero-value history harms reconciliation and customer servicing.
Partial returns require even stronger modelling. The return amount can be less than the original amount because only part of the funds remains available or the receiving institution agrees to return only part. The sending bank should book exactly the settled returned amount and update recovery exposure accordingly. Customer servicing should say, for example, “$6,000 has been recovered; $4,000 remains under investigation,” rather than “return successful.”
The receiving bank must also prevent over-return. If an original payment of $10,000 already has settled returns totaling $10,000, another pacs.004 linked to that payment should be blocked or escalated unless a distinct adjustment process applies. This requires cumulative-return controls in the payment platform.
A return can also originate without a prior return request in some FedNow scenarios, such as where the receiving participant cannot apply the funds. The bank therefore must not make camt.056 a mandatory foreign key for every pacs.004. The mandatory correlation is to the original value event; the return-request relationship can be optional.
From a treasury perspective, a return consumes value on the returning side and credits value on the original sender’s side. From an accounting perspective, it creates new entries. From a customer perspective, it may restore funds. From a fraud-case perspective, it may reduce loss. These perspectives should reconcile to one return transaction but should not be represented by one overloaded status field.
11. Customer disputes, Regulation E and network recovery
One of the most important educational boundaries in Chapter 26 is the difference between network finality and consumer error-resolution obligations. RTP and FedNow define how participating institutions exchange and settle payments. Regulation E, where applicable, governs rights, liabilities and responsibilities for consumer electronic fund transfers. A bank must assess both.
The CFPB’s Regulation E framework includes rules on unauthorized EFT liability and procedures for resolving errors. CFPB guidance explains that when a consumer alleges an unauthorized EFT, the financial institution generally must investigate the allegation within the applicable regulatory process, report results and correct errors where required. The bank cannot outsource that legal determination to the receiving institution’s response to a camt.056.
The legal classification of the customer’s story matters. If a third party obtained account access information through fraud and then initiated the EFT without the consumer’s actual authority, CFPB guidance recognizes that this can be an unauthorized EFT. If the consumer personally initiated and authorized a transfer after being deceived by a scammer, the Regulation E analysis may be different. Banks need legal/compliance-approved decision trees rather than a fraud agent making legal conclusions from a call script.
Network recovery and customer remediation can therefore diverge. A bank may be required or choose to credit a customer even when no interbank funds are recovered. Conversely, the receiving bank may return funds even where the sender has not yet completed its consumer-error investigation. The accounting platform must distinguish network recovery, customer reimbursement, provisional credit, final customer loss, bank loss and third-party recovery.
The case record should preserve the customer’s allegation, notice date, transaction identification, investigation steps, decision, regulatory timeline, provisional-credit events where applicable, communications, and network-recovery actions. A camt.056 timestamp is one piece of evidence, not the entire investigation.
Commercial and business payments may sit under different legal frameworks, including UCC Article 4A and contractual security procedures. The bank should not apply consumer Regulation E treatment automatically to every RTP/FedNow transaction. Product, customer type, account type, initiation method and governing law all matter.
12. Unknown outcomes, duplicate risk and exception evidence
An unknown outcome is the exception that can create the largest accidental loss if operations treat uncertainty as failure. Suppose the sending bank releases a $250,000 instant payment, loses its connection and receives no final response. The customer sees a spinner. The sender’s orchestration platform times out. If the bank sends a second payment or routes via another rail before determining the original financial state, the beneficiary could receive twice.
Chapter 25 established the NOT_SENT versus OUTCOME_UNKNOWN boundary. Chapter 26 turns that into an investigation workflow. NOT_SENT means the bank has authoritative evidence that no network release occurred. OUTCOME_UNKNOWN means release may have occurred but the final state is not known. Only the latter requires financial-state investigation.
The evidence hierarchy should include local immutable payment events, outbound queue acknowledgement, network technical acknowledgements, network business responses, settlement reports, account postings, receiving-bank communication and operator research tools. Customer screenshots and call statements are useful evidence, but they are not settlement proof.
If investigation proves the payment settled and was fraudulent or erroneous, the bank can consider return-of-funds action. If investigation proves it never left, the bank can safely release a new payment if the customer still wants it. If the state remains unknown, the bank should continue controlled investigation rather than inventing certainty.
Exception evidence must be timestamped and correlated. A useful event chain is CUSTOMER_CONFIRMED → RELEASE_AUTHORISED → MESSAGE_SENT → NETWORK_ACK → SETTLEMENT_EVIDENCE → CUSTOMER_COMPLAINT → FRAUD_CASE_OPENED → CAMT056_SENT → CAMT029_PDCR → PACS004_RECEIVED → RETURN_SETTLED → CUSTOMER_CREDITED → CASE_CLOSED. Every event should identify source system and actor.
13. Reconciliation, accounting and reporting
Instant-payment exception reconciliation is not only “did the return arrive?” It requires several linked reconciliations. The original payment must reconcile to network settlement. The return request must reconcile to a response or ageing state. The return payment must reconcile to its own network settlement. Customer credits or reimbursements must reconcile to the case decision. Fraud-loss accounting must reconcile to recovered value.
A sending bank should maintain an original payment position and a recovery position. For an original $12,000 payment with a $7,000 network return and a $5,000 bank-funded customer reimbursement, the payment position remains $12,000 settled outward. The recovery position records $7,000 recovered from the counterparty. The customer-remediation position records $12,000 credited back to the customer if that is the decision. The bank-loss position is then derived correctly rather than hidden inside one net customer balance movement.
A receiving bank similarly needs to reconcile incoming return requests, outgoing camt.029 decisions, outgoing pacs.004 returns and beneficiary-account debits or restricted funds. If the return settles but the beneficiary account was not debited correctly, the bank has created a financial break.
Reporting should separate volumes and values by exception reason, network, customer segment, fraud typology, return-request outcome and recovery amount. Useful measures include fraud-loss rate, attempted-fraud rate, return-request acceptance rate, partial-recovery rate, median response time, aged pending investigations, unmatched camt.029, unmatched pacs.004, duplicate requests prevented and customer complaints associated with instant payments.
RTP and FedNow network reports should be treated as external evidence and reconciled to internal event stores. FedNow’s Operating Procedures include dedicated reports and reconciliation sections. RTP publishes a Reports Specification. Those sources should drive technical mapping; a generic “daily settlement file” assumption is not enough for 24x7 instant operations.
Accounting cutovers need careful design because the network cycle day may not equal the bank’s local calendar day. FedNow has a specific funds-transfer business-day rollover. A Sunday-evening return can therefore require different accounting-date, cycle-date and customer-value-date fields. The same principle applies to always-on RTP operations: date semantics must be explicit.
14. 24x7 operations, case management and escalation
Instant payments run when traditional back offices may be lightly staffed. That means exception operations cannot depend on “someone will look Monday morning” for every event. Banks need 24x7 monitoring and a tiered support model that distinguishes situations requiring immediate intervention from cases that can follow standard investigation timelines.
Immediate alerts should include high-value unknown outcomes, duplicate-risk conditions, large confirmed fraud, repeated attacks against one recipient, inability to receive return responses, failed pacs.004 settlement, reconciliation imbalances, return queues building rapidly, connectivity failure affecting exception messages, and suspicious concentrations suggesting mule networks.
The case-management system should create one master case with linked work items rather than separate disconnected tickets in fraud, payments and servicing. The master case needs original payment details, customer allegation, fraud classification, network messages, amounts, regulatory clocks, owners, evidence, communications, decisions and recoveries.
Escalation should be amount- and risk-sensitive. A $50 mistaken payment and a $9 million suspected business-email-compromise payment should not wait in the same FIFO queue. Banks should define thresholds for fraud management, treasury, legal and senior operations involvement, while ensuring that regulatory consumer timelines are not deprioritized simply because the amount is small.
Operational runbooks should explicitly cover: how to establish settlement truth; how to send a return request; who approves high-value requests; how to respond to incoming requests; how to preserve funds where lawful; how to issue partial returns; how to handle an unmatched response; how to process a fraud-related return; how to handle service-provider outages; how to communicate with the customer; and how to close the case only after financial and customer positions reconcile.
The strongest control is closure discipline. A case should not close because “camt.029 received.” Closure requires a defined terminal outcome: no payment occurred; payment settled and no recovery was available; full recovery settled; partial recovery settled with residual loss decided; customer reimbursed under applicable policy/law; or another documented resolution.
15. Controls, architecture and testing
A bank-grade Chapter 26 architecture normally includes an exception-event intake service, payment-state resolver, fraud-case system, return-request service, network adapters, case orchestration, accounting/reconciliation services, customer-remediation service, document/evidence store and operational dashboards. The design should reuse the canonical payment identity from Chapters 21–25 rather than creating a new identity universe for investigations.
Key preventive controls include immutable original-payment references, role-based authority for return requests, maker-checker for high-value or sensitive actions, duplicate-request prevention, cumulative-return amount validation, prohibition of cross-rail resend when the original outcome is unknown, and separation of customer reimbursement authority from interbank-return authority.
Detective controls include unmatched-response queues, unmatched-return queues, pending-investigation ageing, camt.056 without acknowledgement, accepted request without subsequent return after the expected period, cumulative return exceeding original amount, return booked without customer/case correlation, and customer credit issued twice.
Technical tests should cover happy path and failure path. At minimum: full return; partial return; request rejected; request pending; duplicate camt.056; late camt.029; pacs.004 without prior camt.056; return exceeding outstanding amount; fraud reason handling; RfP warranty reason separation; unknown original state; service-provider timeout; message replay; network duplicate; receiver unavailable; settlement failure of return; reconciliation mismatch; customer provisional credit before recovery; and recovery after customer remediation.
Non-functional testing matters because fraud events can arrive in bursts. A mule network takedown or systemic issue can generate thousands of related cases. Case orchestration, message correlation and dashboards must remain available under load. Disaster-recovery tests must prove that idempotency keys, case state and cumulative recovery positions survive failover.
Security testing should verify that an attacker cannot abuse a return API to manufacture recovery requests, change original payment references, inject free-text data, bypass approvals or retrieve other customers’ case information. Audit logs should capture before/after values for manual changes and should be protected from ordinary user modification.
A BA should turn these controls into traceable requirements, not just prose. Each requirement should identify trigger, precondition, decision logic, state transition, message, data owner, user visibility, exception outcome, audit evidence and test scenario.
16. End-to-end cases, role checklist and authoritative references
Consider a Sunday 02:14 ET account-takeover case. A consumer’s credentials are compromised and a $4,800 FedNow payment settles to another bank. At 02:18 the customer calls. The sending bank verifies the transaction is settled, opens an unauthorized-EFT investigation, blocks further compromised access, captures the fraud allegation and sends a fraud-related camt.056. The receiving bank acknowledges the message, investigates the beneficiary account and sends camt.029 with pending status while it reviews available funds. Later it agrees to return $3,100 and sends the corresponding pacs.004. The sending bank reconciles the $3,100 network recovery, continues its consumer-error process for the full $4,800, and separately accounts for any customer reimbursement and residual bank loss. The original $4,800 payment remains historically settled; the $3,100 return is a new transaction.
Now change the case. A corporate customer intentionally sends $600,000 to a supplier after a fraudster substitutes bank details in an email. The payment is authorized by the customer under its corporate controls but fraudulently induced. The bank must not automatically label the case an unauthorized consumer EFT. It opens a business-fraud investigation, sends the appropriate network fraud/return request, contacts the receiving bank through controlled channels, preserves evidence and applies the commercial legal framework and customer agreement. Same network mechanics, different legal/customer-treatment analysis.
Change it again. A payment API times out before the sender receives final status. The customer reports “fraud” because the beneficiary says no money arrived. The bank must first resolve whether the original payment settled. Sending a return request before establishing the transaction’s actual state can create noise and misclassification. This is an unknown-outcome investigation first, not a fraud-recovery workflow by assumption.
What each role must know
Business Analyst: distinguish original payment, exception case, return request and return payment; specify states, reason codes, timers, amount positions, customer/legal branches and audit evidence.
Developer: implement immutable correlation, idempotency, cumulative-return controls, message adapters, event ordering and replay-safe processing.
Tester: prove full, partial, rejected, pending, duplicate, unknown, late and failover scenarios—not only the happy path.
Operations: establish payment truth before action, manage ageing, understand request versus value return, and close only after financial reconciliation.
Fraud team: classify the event, preserve evidence, use network fraud-reporting mechanisms correctly and coordinate with receiving institutions.
Customer servicing: never promise recovery merely because a return request was sent; communicate investigation and customer-credit status separately.
Accounting/Treasury: reconcile original settlement, return settlement, customer remediation and residual loss as separate financial positions.
Compliance/Legal: determine applicable Regulation E, UCC Article 4A, sanctions, privacy, complaint and other legal requirements based on the actual customer/product scenario.
Authoritative references
The Clearing House — RTP Document Library (current and upcoming rules, return-of-funds guidance, fraud controls, message and report specifications):
https://www.theclearinghouse.org/payment-systems/rtp/document-library
The Clearing House — RTP Technical Documentation:
https://www.theclearinghouse.org/payment-systems/rtp/technical-documentation
Federal Reserve Financial Services — Operating Circulars, including Operating Circular 8 and current FedNow Service Operating Procedures:
https://www.frbservices.org/resources/rules-regulations/operating-circulars.html
Federal Reserve Financial Services — FedNow Service Resources:
https://www.frbservices.org/resources/financial-services/fednow
Federal Reserve Financial Services — FedNow Service Operating Hours:
https://www.frbservices.org/resources/financial-services/fednow/operating-hours
Consumer Financial Protection Bureau — Regulation E, 12 CFR Part 1005:
https://www.consumerfinance.gov/rules-policy/regulations/1005/
Consumer Financial Protection Bureau — Electronic Fund Transfers FAQs:
https://www.consumerfinance.gov/compliance/compliance-resources/deposit-accounts-resources/electronic-fund-transfers/electronic-fund-transfers-faqs/
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.