AFPP Handbook 2025 PDF

Participants in Faster Payments systems are required to follow certain procedures before originating and/or receiving messages. For example, there are requirements related to testing, fraud, compliance issues, ensuring participant availability, validating the receiving account, and message validatio...

Participants in Faster Payments systems are required to follow certain procedures before originating and/or receiving messages. For example, there are requirements related to testing, fraud, compliance issues, ensuring participant availability, validating the receiving account, and message validation, to name a few. Participants must ensure they have a steady network connection and the ability to respond to system messages as well as have sufficient liquidity to settle payments. Both FedNow and RTP require participants to sign-on to the system in order to confirm that they are fully connected and active participants prior to sending and receiving transactions. The rest of this section covers the requirements of the various Faster Payment networks that participants must comply with as well as the required message validations prior to message submission to the network. Participants must establish a participant profile according to their business needs and risk tolerance before sending or receiving payments. Each FedNow participant and service provider is required to follow the FedNow Service’s operating procedures and technical specifications, including, but not limited to, ensuring continuous availability and making funds immediately available. Participants are required to notify the Federal Reserve if they are unable to send/receive messages to or from the system and must establish monitoring and alerting capabilities to resolve any issues. Participants are expected to have an information security program for physical and logical system components and are expected to conduct an annual assessment of compliance with the Federal Reserve’s FedLine security requirements. All messages exchanged through FedNow require a digital signature generated by participants. Participants are required to use public/private key pairs to support digital message signing. Each FedNow participant shall adopt and maintain: Procedures for screening sanction lists against their customer base A compliance program A Bank Secrecy Act (BSA)/anti-money laundering (AML) compliance program 40  TABLE 25. SUMMARY OF FEDNOW REQUIREMENTS PRIOR TO RECEIVING/ORIGINATING TRANSACTIONS Establish a participant profile Follow FedNow’s operating procedures and technical specifications Ensure continuous availability and the ability to make funds immediately available to users Designate a settlement account, either a Master Account or a settlement account maintained by a correspondent Ensure appropriate monitoring and alerting capabilities are in place to resolve any issues that may arise Have information security programs in place, as well as compliance and AML programs Each participant must comply with the RTP operating rules and technical specifications, which must be tested and audited. Participants must also specify a settlement account and ensure adequate funds to settle obligations. Other requirements include the implementation of an OFAC compliance program. Prior to submitting a payment message to the RTP network, sending participants must: Have satisfied prefunding requirements Ensure that the payment message complies with the applicable RTP operating rules and technical specifications Provide the sender with the name of the receiver associated with the receiving account for payments originating from consumer accounts. Participants must first transmit a sign-on request (ISO 20022 message ID: admn.001) message to be reachable on the RTP network. Participants must be able to initiate ACH files in the format established in the Nacha Operating Rules. The Nacha Operating Rules include a general requirement that ACH Participants comply with U.S. law, including but not limited to compliance with sanctions programs. Other requirements include that participants conduct risk assessments of their ACH activities and implement risk management programs as well as have security policies and procedures related to the initiation, processing, and storage of information in place. Other requirements include: Verification of originator or third-party sender identity Enter into an origination agreement with each originator for which the ODFI will originate entries Becoming a Mastercard Send participant involves registering for the required programs and services, and meeting program eligibility requirements as well as adhering to the service’s standards and rules (including agreements, licenses, and establishing a settlement account). Originators will not be able to use the APIs in the Mastercard Test Facility (MTF) or production environments until they are approved and onboarded. Once registered and onboarded, originators are given keys and a unique partner reference ID. THE 2025 AFPP HANDBOOK 41 The table below summarizes some of the steps required prior to launching Mastercard Send. Figure 4. Mastercard Send – simplified implementation overview An originating acquirer (either itself, or through its merchants or service providers that originate an Original Credit Transaction), must: Validate sender data and comply with applicable anti-money laundering laws and regulations and anti-terrorist financing standards Provide proper disclosure to the sender regarding the collection of sender data Notify Visa before it or its Merchant or service provider start to process any Original Credit Transactions. Visa Direct requires the originator (who can also be merchants, P2P payments providers, etc.) to ensure that all stages of transaction processing, including transaction submission, financial settlement, dispute management, and reporting, are in place before launching Visa Direct. Originators are expected to perform Know Your Customer (KYC), fraud, and eligibility checks on the sender and/or recipient. Visa also recommends that institutions screen transactions for high-risk and/or sanctioned transactions and set velocity limits. Participants must also ensure compliance with the Payment Card Industry (PCI) Data Security Standards and applicable law(s). The table below summarizes the implementation steps that originators must follow prior to launching Visa Direct. 42  Figure 5 Visa Direct – simplified implementation overview Source: Visa Direct Funds Disbursement Program Considerations for Enablers and Processors Push to Card, January 2020 The payments process flow consists of multiple messages. These steps may vary according to how Faster Payment networks process transactions. The information below summarizes these steps in five stages: the ini- tiation stage, validation stage, response/processing stage, settlement stage, and posting and notification stage. In addition to the above stages, Faster Payments networks also define the processes involved in instances when the payment fails as well as the process involved in payment returns. 1. Initiation stage: User initiates a payment 2. Validation stage: Sender FI sends the Customer Credit Transfer (CCT) (pacs.008) to FedNow FedNow receives CCT (pacs.008) message from the sender FI and runs through all applicable validations. o If the message fails one of the validation checks, FedNow either: - Rejects the message immediately and sends a message reject (admi.002) with the appropriate reason code to the sender FI, or - Continues processing through validations to collect any additional errors. The FedNow Service then sends a payment status message (pacs.002) with the consolidated appropriate error reason code(s). The message passes all validations and is sent to the Receiver FI. 3. Response stage: The receiver FI begins to validate the CCT (pacs.008) message from FedNow. The receiver FI reviews the message and responds with either: THE 2025 AFPP HANDBOOK 43  o Accept o Accept without post o Reject 4. Settlement stage: FedNow processes the pacs.002 message from the receiver FI and runs it through all applicable validation checks. FedNow checks that the payment timeout clock has not expired for the CCT (pacs.008). FedNow confirms settlement relationships, assigns a settlement date, and settles the transaction by recording it. 5. Posting and notification stage: FedNow sends a payment status report (pacs.002) within seconds as confirmation to the sender FI as acknowledgement, and to the receiver FI as advice of credit. Upon receipt of advice of credit (pacs.002), the receiver FI makes the funds available to the recipient immediately and notifies the recipient of funds availability. FedNow delivers the confirmation of posting payment status report (pacs.002) with the code “ACCC” (“accepted”) to the Sender FI regarding the availability of funds. TABLE 26. SIMPLIFIED STAGES IN A FASTER PAYMENTS TRANSACTION – FEDNOW Sender Initiates a payment message Sending FI Authenticates the Sender FI sends Upon receipt of sender and receives pacs.008 pacs.002, notifies the payment sender (optional) instruction Faster Payment FedNow receives Processes pacs.002 Sends pacs.002 as system pacs.008 and runs and runs validations. confirmation to validations, then If timeout not sender and receiver sends message to expired, FedNow FIs receiver FI settles the payment Receiver FI Receives pacs.008 Responds with Makes funds and validates pacs.002 and either available and notifies Accept, Accept the recipient without post, or Reject 1. Initiation stage: the sending FI authenticates the payer and receives a payment instruction from the payer via a supported channel. 2. Validation stage: The payer’s FI performs account and payment verification and approval, such as: i. Check the sender’s account balances ii. Earmark funds for the debit 44  iii. Perform fraud checks The payer’s FI creates a credit transfer message (pacs.008) and sends it to the RTP network. RTP performs a series of formatting, process, and business rule validations. The message passes validations and is routed to the receiver FI. RTP awaits a response for a period defined as the “time-out period”. 3. Response stage: The receiver FI receives the message from RTP and conducts its own validations to ensure its correctness and security. The receiver FI sends RTP a “message status report” (pacs.002) indicating that the credit transfer has either been accepted, rejected, or accepted without posting. 4. Settlement stage: RTP validates that the response was received within the time-out period. Following, RTP settles the transaction. RTP then passes the response along to the sending FI, which then informs the sender of the payment’s status. 5. Posting and notification stage: RTP provides a message status report called a “message receiver confirmation” message to the receiver FI, notifying that the transaction has been settled. The receiver FI makes the funds immediately available to the receiver. TABLE 27. SIMPLIFIED STAGES IN A FASTER PAYMENTS TRANSACTION – RTP Sender Initiates a payment message Sending FI Authenticates the Performs account Informs the sender sender and receives and payment the payment verification and instruction via a approval. supported Channel Creates a pacs.008 Application and sends to RTP Faster Payment Performs a series of Validates the Confirms to the system formatting, process, response and sending and receiving and business rule (assuming no time- FI pacs.002 validations. Message out), settles the is routed to the payment receiver’s FI Receiver FI Receives the message Sends RTP a message Makes funds and conducts its own status report pacs.002 available and notifies validations indicating either the recipient Accepted, Accepted Without Posting, or rejected THE 2025 AFPP HANDBOOK 45  1. Initiation stage: the originator initiates a payment instruction. 2. Validation stage: the ODFI then validates the payment instruction. 3. Processing stage: The ODFI debits the sender’s account. The ODFI then sends their ACH file to an ACH Operator. 4. Settlement stage: The ACH Operator forwards aggregated batches to the RDFI The ACH Operator calculates and instructs interbank net settlements through Fed Master Accounts (four times daily). 5. Posting and notification stage: The RDFI updates the receiver’s account accordingly (i.e., posts funds) unless conditions require a return. The receiver sees updated or pending fund balance reflected in their account. TABLE 28. SIMPLIFIED STAGES IN A FASTER PAYMENTS TRANSACTION – SAME DAY ACH Originator Initiates a sending ACH instruction Sending FI /ODFI Authenticates the Validates the Sends their ACH files sender and receives instruction and debits to the ACH operator the ACH instruction the sender’s account EPN / FedACH Forwards aggregated Calculates and batches to receiver FI instructs interbank net settlement through Fed Master Accounts Receiver FI /RDFI Validates the Notifies receiver receiver’s account and updates them accordingly 1. Initiation stage: the sender initiates a payout or P2P money transfer through a payment solution. 2. Validation stage: the sending FI validates the sender data and submits the payment to the network. 3. Processing stage: the network routes the payment using debit card or international bank routing credentials. 4. Posting and notification stage: The network forwards the money transfer to the receiver FI. The receiver FI receives the payment, posts the funds to the receiver’s account, and notifies the receiver. 5. Settlement stage: payment transactions are settled once per day. 46  TABLE 29. SIMPLIFIED STAGES IN A FASTER PAYMENTS TRANSACTION – VISA DIRECT Sender User initiates payment message Sending FI Performs account & payment verification and approval. Submits payment Visa Direct Network routes Forwards money Settles payment payment using debit transfer to receiver FI transactions once card or international daily bank routing credentials Receiver FI Receives payment, posts funds to receiver’s account & notifies receiver 1. Initiation stage: the sender initiates a payment transaction. 2. Validation stage: The sending FI authenticates and screens the sender. The sending FI makes a payment transfer API POST request to Mastercard Send Mastercard Send validates the request, including: i. API request checks ii. Transaction controls iii. Limit validations When the request is validated, Mastercard Send transmits the payment transaction request to the receiving FI via the relevant network for approval. 3. Response stage: The receiving FI approves or declines the payment transaction request and then sends a response back to Mastercard Send. Mastercard Send then transmits the API response to the sending FI. 4. Posting and notification stage: the receiving FI credits the receiver’s account and notifies the receiver. 5. Settlement stage: Mastercard Send instructs settlement. THE 2025 AFPP HANDBOOK 47  TABLE 30. SIMPLIFIED STAGES IN A FASTER PAYMENTS TRANSACTION – MASTERCARD SEND Sender User initiates payment message Sending FI Requests payment transfer by making payment transfer API Post request to Mastercard Send Mastercard Send Validates request with Instructs settlement API request checks, transaction controls, limit validations, etc. Message is transmitted to the receiver’s FI via relevant network Receiver FI Approves or declines Credits the receiver’s the payment account and notifies transaction request the receiver and a sends response Before participants submit messages to the rail, they must ensure that messages are consistent with system requirements and message specifications. Specific requirements for each Faster Payments rail are described below. All ISO 20022 messages, including value and non-value messages, are subject to FedNow’s ISO rules and guidelines, security procedures, and processing standards. System preparation applies to all participants and must be implemented before sending messages, including: Ensure accuracy of message content Ensure connection to the system, including meeting technical, operational, and security protocols Ensure that the participant’s profile is appropriate: o A participant profile to send and receive customer credit transfers o A participant profile for receiving credit transfers only o LMT send and receive o LMT receive only Ensure that message queues (endpoints) are established with the FedNow Service Reference FedNow’s participant list and Broadcast Messages to validate that the intended receiver FI is active and signed on to the system 48  Use of a reliable time server and include the timestamp in the payment message to determine start of the payment timeout clock. Adhere to the FedNow Service network limits Ensure having an active public key(s) for message signature Use a unique message identifier, also referred to as the unique message ID, assigned to each new message Ensure that the value message is $0.01 or greater Implement a system to support the defined receiver response time rules and guidelines Ensure that the XML syntax and FedNow Service ISO 20022 schema rules are followed Some message types have other items that participants must validate. The table below shows validation items for FedNow participants sending customer credit transfers. See Appendix 4 for validation items for other message types. TABLE 31. VALIDATIONS FOR CUSTOMER CREDIT TRANSFER – FEDNOW Valid message signature Valid message size XML syntax Authorized sender Confirm unique message ID FedNow Service ISO 20022 schema rules followed Sending and Receiving FIs are FedNow participants, are active and signed on, and have profiles to send & receive payments or receive only. Sender must have a profile for sending and receiving payments Payment timeout clock has not been exceeded Message is not future dated Message is within Receiver FI reserved response time Message is within FedNow Service network transaction limit or Sender FI transaction limit Sender and Receiver FIs have valid settlement relationships Optional: Negative list check, if enabled Messages must be submitted according to RTP’s technical documentation which defines the standard message formats used within RTP. Prior to submitting credit transfers to RTP, the sending institution checks the sender’s account balances, earmarking funds for the debit, and performs fraud checks. Participants must validate that the payment does not exceed the maximum transaction limit for each message. Prior to submitting ACH entries to the ACH Operator, originating financial institutions must validate: That the file is not a duplicate of one that has previously been processed The originator information, including qualification to originate The field contents, such as codes and numeric requirements. Each entry type has specific conditions that must be met in order for the entry to be considered properly authorized. THE 2025 AFPP HANDBOOK 49  Eligibility for SameDay ACH processing Dollar totals at batch and file levels and That origination activity does not exceed agreed-upon limits That there is a valid agreement/authorization from the end user to initiate this payment When originating financial institutions consolidate multiple ACH files, they must: Ensure that the file contents are valid and will meet the ACH Operator’s criteria Assign trace numbers to each record which must be unique within a batch Mastercard Send participants must send payment transfer messages in the formats requested by Mastercard Send. It is implied that sending participants must validate that messages follow the guidelines and that participants must enforce the applicable transaction limits and conduct value and velocity checks to confirm compliance with those limits. Aside from payment message validation, Mastercard Send provides participants with optional Value Added Services (VAS) to help them validate the existence and eligibility of the accounts used for funds transfers. Mastercard Send recommends, but does not mandate, participants to use the Account Information Service and Account Verification Service (in that order) to check sender and recipient card accounts prior to making payment transfer API calls. Account Information Service to check: The sending card account is eligible to send funds The receiving card account is eligible to receive payment transfers Account Verification Service (AVS) to check: The sending card account is still valid/open and verify the provided sender’s details The receiving card account is still valid/open and verify the provided recipient’s details Visa provides the technical specifications for exchanging messages through the available APIs within its API Developer Center. The type of information that must be included when using the different APIs available differs slightly due to the different functionalities they deliver, but all generally require the below information. Participants are expected to validate that this information is included and that the message complies with the processing guidelines. An acquiring BIN and its country code Business Application Identifier (BAI): This is a two-character code that identifies the intended use of a push payment. Information about an individual sender or sending entity: These fields identify the sender and sender transaction narrative as it will appear on the cardholder’s statement. Participants also validate that the card is eligible to receive OCTs and that it is a valid account. Visa Direct also makes VAS available to help participants validate the information of the user’s account, such as the Account Look-up API, which helps validate key characteristics of a recipient card before initiating the transfer, such as country, card type, block status, etc. 50 Numerous parties and processes play a role in the Faster Payments transaction flow. Each party must ensure that its part of the payment flow operates smoothly and adheres to both operational and technical rules. This section describes the points of failure for messages across the payment flow, the reasons why payment messages fail, the techniques implemented to mitigate payment rejections and failures, and the responsibilities of sending financial institutions when receiving message rejections and failures. Participants exchange a series of messages, including value and non-value messages, as part of the process flow in Faster Payments transactions. When it comes to FedNow and RTP, one particular non-value message exchanged in the response stage is the payment status report (pacs.002). In the FedNow and RTP systems, receiving financial institutions respond to the sending institution with a pacs.002 message indicating whether the credit transfer has been accepted, rejected, or accepted without posting. FedNow and RTP also use pacs.002 to notify the receiving FI that the response has been received within the time-out period and the transaction has been settled, allowing the receiving FI to make the payment immediately available to the receiver. See the figure below for a simplified process flow of a credit transfer within RTP showing when are message status reports (pacs.002) used. Participants can also send a payment status request (pacs.028) to FedNow/RTP or another participant to inquire about the status of a previously sent message. Status report messages and response messages help participants acknowledge every step of the payment flow and allow them to react when one of these steps fails. Figure 6. Example of a successful credit transfer in RTP Source: The Clearing House Customer Documentation, Introduction to the RTP system, October 2020 Similarly, participants in push-to-card networks exchange messages that indicate if the receiving institution approved or declined the transaction. Participants can also exchange messages to obtain the latest status of the payment message. THE 2025 AFPP HANDBOOK 51 A payment message can fail for any number of reasons, though specific points of failure are linked to the involved parties at each step. For instance, the sending FI and its access channels are the potential point of failure during the initiation stage, though the sending end user needs to ensure that sufficient funds are avail- able in the sending account to initiate the payment. If the end user is initiating the payment via a third-party provider, this is another potential point of failure because the third-party provider needs to have a secure connection to the Faster Payments network. Once a payment message moves to the validation stage the sending FI must ensure the necessary information is included in the payment message that it is submitted in the correct format. Payment messages can be rejected or fail at different points throughout the Faster Payments flow, which is illustrated in the table below. TABLE 32. POTENTIAL POINTS OF FAILURE IN THE FASTER PAYMENTS FLOW – FEDNOW & RTP Note that some Faster Payment networks within the scope of this handbook post funds to the receiver’s account before funds are settled. This means the above figure will look slightly different for different types of Faster Payments rails. 52  TABLE 33. SUMMARY OF POTENTIAL FACTORS INVOLVED IN FASTER PAYMENT FAILURE – FEDNOW & RTP Sender Insufficient funds, (initiation failure in initiation channels) channels Sending FI Suspected fraud Inaccuracy of the message Inability to receive or illicit activities, contents, inappropriate payment status report exceeding value participant profile, and notify sender limits, 24/7 incorrect keys for message availability, and signature, lack of a unique failure in connection message identifier, incorrect to third-party service XML syntax and ISO provider 20022 schema, and issues with system connection System Lack of 24/7 Lack of 24/7 availability, Lack of 24/7 connection availability, malfunctioning systems and availability, malfunctioning connection to network malfunctioning systems and systems and connection to connection to sending FI network and sending FI Liquidity Unavailable provider settlement account with sufficient liquidity FedNow Invalid message signature, Inability to exchange Unable to process Inability to send TCH RTP incorrect XML syntax response messages messages and payment status and ISO 20022 schema, with sending and validation, timeout, reports to sender and lack of a unique message receiving institution unsuccessful receiver. ID, timeout, exceeding transaction network transaction limits, settlement future dated payment, inappropriate or incorrect participants and profiles Liquidity Unavailable provider settlement account System Lack of 24/7 availability, Lack of 24/7 Lack of 24/7 connection malfunctioning systems and availability, availability, connection to network malfunctioning malfunctioning systems and systems and connection to connection to network network and receiving FI Receiver FI Inability to open, read and Inability to send a Inability to receive validate the message, and message response payment status report timeout and post funds to receiver The following section describes the specific factors that cause failure in the processing of Faster Payments. Validation takes place at various stages of the payments message flow. Potential factors contributing to payment message failures include connection issues, system availability, lack of reach, inaccurate information THE 2025 AFPP HANDBOOK 53 in the payment message, and data formatting issues. Security failures, such as those pertaining to message signing, and settlement issues, such as a lack of liquidity, are also potential points of failure. Issues around fraud, and money laundering can also cause a payment to fail, even if the payment in question is not actually fraudulent or be related to money laundering. The figure below summarizes the factors that may cause a message to fail at each stage of the payment flow for an RTP and FedNow payment message. The factors that can lead to payment message failure are the same with Visa Direct and Mastercard Send, though the failures occur at different times within the payment flow due to differences in how settlement takes place. The figure below summarizes potential factors involved in a Mastercard Send funds transaction failure. TABLE 34. SUMMARY OF POTENTIAL FACTORS INVOLVED IN FASTER PAYMENT FAILURE – MASTERCARD SEND Sender (initiation Failure in initiation channels) channels Sending FI Suspected fraud or Invalid sending and Unavailable settlement illicit activities, lack receiving account, account of user agreement, invalid message invalid funding formats, exceeding source and failures value and velocity, while securing funds lack of unique ID System connection Malfunctioning Malfunctioning systems systems and and connection to connection to network network and sending FI Liquidity provider Unavailable settlement account with insufficient liquidity at the time of settlement Mastercard Failures in API Timeout, network request checks, communication transaction controls, issues and exceeding limits Liquidity provider Unavailable settlement account System connection Malfunctioning Malfunctioning systems and systems and connection to connection to network network and receiving FI Receiver FI Validation errors, Invalid receiving missing required account, and user data agreement With regards to Same Day ACH payments, suspected fraud or illicit activities, failures in the user authentication and authorization process, duplicated files, missing or incorrect information within the payment message, lack of eligibility for same-day ACH processing, lack of liquidity for payment settlement, and exceeding limits on the dollar totals at the batch and/or file levels are all potential causes of failures. 54 Both participants and Faster Payments system operators use tools and processes to minimize message rejections and failures throughout the payment flow. The specific validations that every participant should conduct prior to submitting messages to the network and at every following step are clearly defined (e.g., validating message syntax and the ISO 20022 syntax, validating unique message IDs, etc.) within FedNow’s operating guidelines. There are validation requirements and processes for every step of the payment flow and participants (through FedNow) share the status of the payment to provide certainty to the counterparty. FedNow also recommends participants refer to a reliable time server to support accurate tracking of the processing time and avoid unnecessary rejections (i.e.,, due to timeouts). Participants must be continuously available and ensure appropriate monitoring and alerting capabilities to resolve potential issues. When issues occur, participants are expected to sign off from receiving credit transfer messages. Broadcast messages are used to notify participants of changes to participant availability to receive credit transfers as well as a list of participating routing transit numbers. When it comes to preventing rejections and failures related to settlement, FedNow enables FI-to-FI liquidity management transfers in support of liquidity needs. When it comes to RTP, as with FedNow, participants must be continuously available and validate messages before submitting them to the network, though payment messages are validated by the relevant party at every step of the payment flow. Message status reports and confirmations are used in RTP as they are in FedNow. RTP also uses system-level messages to control which participants are active on the system. Participants must provide immediate responses to messages and receiving participants must accept generally all payment messages that are consistent with RTP operating guides. Regarding settlement issues, participants must monitor their prefunded positions and provide supplemental funding when needed to ensure settlement. Participants can receive alerts from the system when their prefunded position falls below a certain value and they are encouraged to have arrangements with each other to transfer liquidity if needed during non-Fedwire hours. Participants in Same Day ACH validate messages prior to submission. The Nacha Operating Rules specify how files, batches, and entries should be structured and the type of information to be included. In the ACH Network the RDFI can create a “notification of change” to notify the ODFI that a posted entry contains invalid or erroneous information and should be changed (e.g., notification that something about a bank account has changed). Participants are advised to implement analyses of transaction errors. Both Visa Direct and Mastercard Send provide value-added services to help participants validate the information provided in payment messages prior to payment submission. For example, sending FIs can validate that the card is eligible to receive push-to-card transactions and that it is a valid account. THE 2025 AFPP HANDBOOK 55  TABLE 35. EXAMPLES OF METHODS USED TO MITIGATE MESSAGE REJECTIONS AND FAILURES IN FASTER PAYMENTS RAILS Provide a list of necessary validations prior to message submission Validating the existence and availability of receiving accounts Sharing the status of the payment throughout the payments flow Ensuring continuous availability and ensure proper monitoring and alerting of issues System-wide messages that communicate participant availability Flexible options to support liquidity needs Monitoring settlement accounts Analyzing transaction errors Faster Payments networks define specific actions that each party has to conduct when messages are rejected by the network or by another participant. This section describes the actions to correct failures or react to failures by Faster Payment rail. The steps below summarize the sending FI’s responsibilities at each stage of the payment message (pacs.008) flow. If FedNow does not receive the pacs.008 from the sending FI, the sending FI should wait a minimum of 25 seconds to inquire about its status. o The sending FI can send a payment status request to the FedNow Service (pacs.028) or search in the FedNow interface Adhoc Query Tool. If FedNow responds “message is not found”, the sending FI can resend the message with the same previously used message ID. If FedNow does not respond, the sending FI should check its connection. If FedNow does receive the pacs.008 from the sending FI but the message fails a validation (i.e.,, the message is rejected by FedNow), the sending FI needs to review the error code description and correct the error to ensure that subsequent messages meet requirements. If a payment is rejected, the FedNow Service sends a message (ISO message pacs.002) to the Sender FI notifying it that the payment was rejected. If the Receiver FI has received the contents of a payment message in a request for confirmation but does not respond before the timeout clock expires, the Receiver FI also receives a message notifying that the payment has been rejected. If the Sender FI resubmits a payment message that the FedNow Service already received, it needs to include a new unique message identification number. Otherwise, the service rejects the message based on the duplicate identification number. Sending FIs should wait a minimum of 25 seconds if it does not receive a pacs.002 status report message before inquiring as to its status. 56 TCH cancels payment messages and notifies the sending and receiving FIs if the receiving FI fails to respond to a payment message from the RTP network within the established timeframe. FedNow also does this. Rejected RTP payments are not settled. Sending FIs should ensure that sending users receive confirmation that their payment was rejected (or successful) within seconds. When it comes to rejections related to insufficient settlement funds, sending participants must make sure that they have sufficient liquidity before submitting payment messages and leverage the existing processes and tools for liquidity management (e.g., FI-to-FI transfers, prefunded balance warning notifications, etc.). As with FedNow, participants can send a payment status report (pacs.028) to inquire about the outcome of the transaction if a processing error results in the participant not knowing the outcome of the transaction. The ACH Network supports return/reject entries for specific reasons. Returns/ rejections can be initiated from one of two sources: the ACH Operator and the RDFI. This section will focus on returns by the ACH Operator, for example, those transactions that never reached the RDFI. In these cases, the ODFI must: Forward the return to the originator for action: the originator should be notified that entries were returned by the ACH Operator so that it can initiate a corrected entry or contact the receiver about using an alternate method of payment. Reinitiate an entry for the originator if it has been returned because of insufficient or uncollected funds. Sending FIs should be aware of the processing windows offered by ACH Operators for the processing of returns. After sending a transaction (Payment Transfer API), the sending FI must await a response from the receiving FI. In some cases, such as timeouts or network communication issues, a transaction response can have an ‘unknown’ status. Mastercard Send will continue trying to retrieve the status from the receiver network, though sending FIs are recommended to perform an API lookup (Payment Transfer API GET request) on the relevant transaction after a minute to retrieve more information for a payment transfer, including its latest status. Sending FIs should not resubmit a transaction that has an ‘unknown’ status because the original transaction may have been processed successfully. In order to resubmit the same transaction, sending FIs must first use a GET request to check the status of the original transaction request to ensure that Mastercard Send has not financially processed the transaction. Only when the original transaction is in ‘ERROR’ should they resubmit the transaction. Given that Mastercard Send transactions may consist of one or both of these steps: 1) Funding transaction to secure the funds that will be transferred (e.g., in the case that the originating institution is not the sender’s account issuer) and 2) Payment transaction to transfer the funds to the Receiving Institution. When a payment transaction is not completed (i.e.,, declined), the originator must reverse the funding transaction that secured the funds i.e.,, they must return the funds to the funding source. The funding reversal must be submitted within 30 minutes of the funding transfer request. As with Mastercard Send, a Visa Direct transaction can consist of pull funds transaction and a subsequent push funds transaction. This means that originators can use the Funds Transfer APIs (or the ISO transaction) to pull THE 2025 AFPP HANDBOOK 57 funds from a Visa card account and to push funds into a Visa card account. In this context, if the push funds transaction fails, originators must return funds to the sending user (i.e.,, they must reverse the pull transaction). Exceptions processes are carried out when messages are rejected, fail, or in other scenarios, such as when a receiving FI accepts a payment but will not post the funds to the receiver until further validations are conducted (‘accept without posting’ message). Both FedNow and RTP allow participants to accept payment messages without posting. Other examples include exceptions processes that participants carry out to request a return of funds or “notification of change” messages utilized in Same Day ACH to notify the ODFI that a posted entry contains invalid or erroneous information and should be changed. As new use cases for Faster Payment rails emerge, new types of exceptions processes are developed. Request- to-pay, for example, has required defining processes for canceling requests. The following section describes the exceptions-handling processes in different Faster Payment networks and the tools enabling these processes to be carried out. Different payment messages can lead to different types of exceptions. This section describes the main exceptions processes related to each Faster Payment rail. TABLE 36. MAIN EXCEPTIONS PROCESSES PER FASTER PAYMENTS RAILS (FEDNOW, RTP AND SAME DAY ACH) FedNow Those related to payment returns (return requests), message rejects (i.e., the receiving FI rejects the payment message), canceling RFP messages, and ‘accept without posting’ messages. RTP Same Day ACH Reversing files and entries, notifications of change, and returning entries (i.e.,, the receiving FI or the ACH operator rejects the payment). Faster Payments rails provide tools to enable exceptions processing in a reasonable amount of time such as non-value messages, participant and system alerts, system notifications, and participant service support centers. This section summarizes the tools available to participants by Faster Payments rail. FedNow participants use non-value messages to initiate exceptions processes such as payment return requests or RFP cancellations as well as to receive information regarding the status of a payment. Messages Payment status (pacs.002): informs the sender of the status of a previously sent message to another participant or FedNow. The response will indicate whether the credit transfer was Accepted, Accepted without Posting, or Rejected. “Accepted without Posting” responses and “Rejected” responses imply an exception handling process. Payment status request (pacs.028): request the processing status (from the system or another participant) of a previously sent message. 58  Information request (camt.026): Receiving FI asks the sending FI to provide further information on a previously sent customer credit transfer to understand the purpose of the payment. Ping message (admi.004): to check the connection to FedNow Message reject (admi.002): inform a participant or FedNow that the message has been rejected or that the participant cannot process the message. Return request (camt.056): Request a participant to return some or all of a previously settled payment or liquidity transfer. Payment return message (pacs.004): Return previously received funds. Return request response (camt.029): Processing status of a previously sent return request (camt.056). RFP cancellation request (camt.055): Request to cancel a previously sent RFP (pain.013). RFP cancellation request response (camt.029): Processing status of an RFP cancellation request. Other tools: FedNow interface Adhoc Query Tool: participants can run ad-hoc queries for information retrieval via the FedNow interface and filter by time to see messages that were sent to FedNow. FRB Services Support Center: The support center provides technical and service setup support for using, installing, or navigating the service as well as problem reporting. FedNow Service public key list: Participants are required to maintain a list of all active FedNow public keys. Participants must initially use the FedNow interface to obtain the FedNow public key. After the participants have the initial list, they can use the FedNow interface or MQ Messaging to maintain it. Activity reports: includes account activity reports Similar to FedNow, participants in the RTP network have specific messages available to initiate exceptions processes. Messages: Message status report (pacs.002): informs the sender of the status of a previously sent message to another participant or FedNow. The response will indicate whether the credit transfer was Accepted, Accepted without Posting, or Rejected. “Accepted without Posting” Payment status request (pacs.028): request the processing status from another participant of a previously sent message. Request for information (camt.026): Receiving FI asks the sending FI to provide further information on a previously sent customer credit transfer to understand the purpose of the payment. Response to request for information (camt.028): the sending FI sends a response to camt.026 message sent by the receiving FI Request for return of funds (camt.056): Request a participant to return some or all of a previously settled payment or liquidity transfer. Camt.056 messages are also used to indicate “request for payment expiry (RFPE)”: Sent by receiving FI to mark a previously sent RFP as expired so that a payment is not THE 2025 AFPP HANDBOOK 59  made in response to the RFP. In addition, Camt.056 messages are also used to notify system time-out: Sent by RTP to the receiving FI when such FI does not respond within the system SLAs. Response to request for return of funds (camt.029): Processing status of a previously sent return request (camt.056) Other tools: Activity reports: includes account activity reports For Same Day ACH, exceptions handling refers to entries that do not post to the receiver’s account, questions or requests for additional information, file/entry reversals, etc. When an entry does not post, the RDFI must either manually post the entry; manually post the entry and initiate a notification of change; or return (i.e.,, reject) the entry. Payment returns are exchanged through return reason code messages that contain the reason for rejection. Messages/processes: Return entries: The ACH Network allows for returning (i.e.,, rejecting payments), the process allows participants not to accept an entry and to return it to the originator through the ACH Network. An ACH return is a communication that indicates why the entry could not be completed as intended. The reason for return is communicated via a return reason code to the participant receiving the return (e.g., insufficient funds, invalid account number, closed account, etc.). These are called return codes and they consist of an R followed by two numeric digits (i.e.,, R01). Originators may reinitiate returned entries only if: o the entry was returned for insufficient funds o the entry was returned for stopped payment and re-initiation has been authorized by the receiver (e.g., recurring funds collections/debit transfers), or o the sending FI / its sender has taken corrective action to remedy the reason for the return In certain cases, the ODFI can request the RDFI to return entries (request returns). Reversing files and reversing entries: An originator, its ODFI, or an ACH Operator may initiate a reversing entry to reverse all entries of an erroneous or duplicate file or to correct an erroneous or duplicate entry. Notifications of change: are used to notify the sender of an ACH payment that something about a bank account has changed. Mastercard Send and Visa Directs’ APIs are also used to reverse funding transactions when the subsequent push payment fails (usually because the push payment was declined by the receiving issuer or in the event of a timeout). In such case, the originating participant must return the funds to the sending user. Mastercard Send – Messages / APIs: Funding API (POST request): Creates a funding transaction to secure (pull) funds from a sending account that will be sent to a receiver. Includes a “Funding Reversal API” that enables participants to 60  reverse a funding transaction (within 30 minutes) if the associated payment transaction is declined or rejected (due to an error). Payment Transfer API (POST request): This API is used to push funds to a receiving account. o When the payment is sent to the network and processed, Mastercard includes the Network Response Codes (ISO Codes) from the receiving network in the payment transfer API response messages. The response code indicates an issuer’s reason for approving or declining a transaction. Mastercard send provides participants with a list of error reason codes. This helps participants understand the reason for decline and carry out the appropriate exceptions process. o In case of failed payments (or those with ‘unknown’ status), Mastercard Send allows participants to process transactions with “Idempotency”. This means that participants can make the same Payment Transfer API POST request multiple times without worrying about the transaction being processed multiple times. If Mastercard Send detects that a request matches a previous transaction request submitted within the preceding 24-hour period, it will ensure that the transaction is processed only once. If the transaction has already been processed, Mastercard Send will respond with the current status of the transaction. If Mastercard Send did not receive or process the original request (in other words, Mastercard Send has not seen this transaction request before), it will process the transaction and provide a response. Payment Transfer API (GET request): Used to retrieve more information for a payment transfer, including its latest status. Example uses include getting the network decline code and description when a transaction is declined, getting the latest status when a transaction response was ‘Unknown’, retrieving transaction history and research purposes. Visa Direct – Messages / APIs: Funds Transfer API: The Funds Transfer API can pull funds from the sender’s Visa account (in preparation for pushing funds to a recipient’s account) in an Account Funding Transaction (AFT). The Funds Transfer API also pushes funds to the recipient’s Visa account using an Original Credit Transaction (OCT). If a transaction is declined, the Funds Transfer API can return the funds to the sender’s funding source in an Account Funding Transaction Reversal (AFTR). o The API response indicates if the transaction was approved or declined. If declined, participants can obtain a reason code for the decline. Visa shares a list of reason codes and descriptions which help participants carry out the appropriate exceptions handling process. Query API (GET request): This API is used to check whether a PullFunds, PushFunds or ReverseFunds transaction was processed successfully if received by Visa. This API is also used to retrieve the detailed lifecycle or history of a transaction (e.g. original transaction, chargeback, chargeback reversal etc). The Query API allows participants to query in real-time the processing status of Visa Direct (Account Funding and Original Credit) transactions as well as other related transactions that are part of the Visa Direct suite of transactions (reversals, adjustments, chargebacks and re-presentments). Participants can invoke the Query API when there is no response returned from Visa or when the response is returned with errors (e.g., 500, 400, 404, etc.). Additionally, it allows service providers to query the history of transactions and return the entire transaction set related to the original Visa Direct transaction. A transaction set will include approved and settled original Visa Direct transactions, reversals, chargebacks, adjustments, and re-presentments. Refund API: The Refund API is used to process a merchandise return (refund) transaction to a Visa card. The refund transaction is typically associated with a previous merchant payment. The refund can be for the entire amount of a previous transaction or portions of it. Visa also supports a Merchandise Return Reversal API, which is used to reverse a refund that was previously processed. THE 2025 AFPP HANDBOOK 61 Other tools: Visa Resolve Online: a dispute resolution platform that helps issuers and acquirers manage the dispute life cycle. Users of VROL may retrieve transaction information online, receive financial information related to disputes, exchange information and documentation, electronically, submit pre-filing and case filings electronically, receive financial messages, report fraud, and manage exception file listings. Faster Payments rails offer participants specific tools designed to consolidate failed or rejected payment messages. This enables participants to comprehend and analyze the reasons behind these issues, facilitating a thorough examination of the information. By identifying patterns, participants can enhance their processes for better efficiency. These methods include various types of reports (such as Mastercard’s daily transaction report) and the ability to query the system (such as the FedNow interface Adhoc Query Tool) to retrieve information on failed messages. Various activity reports and the FedNow interface Adhoc Query Tool Participants can also send a retrieval request message (admi.006) and the FedNow Service will return a copy of payment messages sent. One retrieval request (admi.006) can be used to request up to 50 messages. Participants can use the retrieval request to retrieve messages for the current or prior seven business days. Activity reports (mainly for reconciliation) ACH Operators provide detailed activity reports, such as FedACH’s: Notification of Change (NOC) report, which provides information on NOCs received ACH Return Item report, which provides information for return items and operator-rejected entries received. (Also available in a machine-readable file.) ACH Return Ratio report, which helps participants monitor return activity ACH Return Reason report, which provides summary-level information on reason codes for returned entries Sending FIs typically maintain a record of errors, with notes on their nature and frequency, to indicate basic deficiencies in the total system within the ODFI’ internal controls. Other tools include the FedACH Exception Resolution Service which provides a 13-month archive to access and view all cases sent or received by a FI. Daily transaction report (DTR) shows all approved and declined transactions processed by Mastercard Send APIs. Mismatched and adjustment transaction report (MAT) shows transactions that are settled in a different way (and for a different amount) than what was processed and reported by the Mastercard Send APIs. 62  Participants can subscribe to receive the VisaNet Settlement Service (VSS) reports (provide reconciliation and settlement data at a summary level) and Single Message System (SMS) reports and raw data (which provide transaction-level research, participants can also create custom reports). Reconciliation information through “Reports API” provides reporting capabilities such as transaction reconciliation data in the API response. The data includes both push and pull transaction details and any exceptions such as chargebacks and reversals. Methods to help participants reduce exceptions processing are available at several steps of the payment flow, from pre-message submission to final settlement. This section describes the methods used by each Faster Payments rail. Mechanisms designed to reduce the need for exceptions processing are initiated from the start of the payment flow, where the sending FI conducts its own anti-fraud checks. This step serves to diminish the volume of payment return requests and, more importantly, minimizes the impact of fraud on end users. Subsequently, each participant in the payment flow undertakes its own validations as the payment message moves through the system. For example, all participants must ensure accuracy of message contents, that the participant profile has an active status and is enabled to send or receive the message, is connected to the service, ensures that the message has a unique ID, correct use of business application headers, ensure messages are sent to connected participants, etc. – all prior to payment submission. The message is sent to the receiving FI once the payment message is processed by FedNow or RTP, and the receiving FI has the option to accept the payment, reject it, or accept it without posting. Opting for acceptance without posting grants the receiving FI additional time to perform its own checks and validations, allowing for the request of further information from the sending FI. Following this, the receiving FI may either reject the payment or proceed with posting it. Consequently, receiving FIs possess the flexibility to subject it to further review rather than immediately rejecting a payment. This approach enhances the likelihood of successfully processing more messages. During the settlement stage, both FedNow and RTP enable participants to implement tools and processes to meet their liquidity requirements. This measure serves to decrease the cases of payments being rejected due to insufficient liquidity. Other examples used by these Faster Payment rails include using broadcast messages, active participant lists, and providing participants with a message validations checklist within the rulebook and rejecting messages that appear to be duplicated. THE 2025 AFPP HANDBOOK 63  TABLE 37. FEDNOW AND RTP – METHODS USED TO REDUCE EXCEPTIONS PROCESSING Sender Sending FI Anti-fraud checks Message validation Notifies sender prior to submission FedNow & RTP Formatting and Validation and Confirmation to the business rule settlement sending and receiving validation FIs Receiver FI Message validation Can respond with Posts and notifies ‘accept’, ‘accept receiver without posting’, or ‘rejected’. Receiver FI can request more information from the Sending FI Participants in ACH Network are advised to conduct anti-fraud checks to combat unauthorized returns and malicious users, and validate that the message is properly structured, is not duplicated, falls within the network limits, and contains the necessary information prior to submission. If the RDFI detected an error in the account information during the processing stage, it can send a Notification of Change (NOC), which helps the ODFI update the account information so future payments are sent correctly. Reversals are also available in Same Day ACH where the ODFI can send reversals and correct files/entries when it detects an error. Both Visa Direct and Mastercard Send provides participants with VAS through APIs that help reduce payment rejections and retries, reducing exceptions processing. For example, participants can use APIs such as Visa’s Account Look-up API or Mastercard’s Account Verification Service (AVS). These tools are usually utilized at the payment initiation stage. Participants must also validate other aspects of the payment message prior to submitting it to the network, such as validating that the card is eligible to receive push-to- card transactions and account validity. At the processing stage participants can inquire about the status of the payment before initiating exceptions processing, meaning these APIs help participants understand whether or not the payment has already been rejected, the reasons for rejections, or if it can still be processed. 64  TABLE 38. MASTERCARD SEND & VISA DIRECT – METHODS USED TO REDUCE EXCEPTIONS PROCESSING Sender Sending FI Anti-fraud checks Account and APIs to inquire as APIs to inquire as payment verification to the status of the to the status of the (available APIs for payment payment this purpose) Push-to-card Message validation Settles payment Network Receiver FI Sends a response Message validation (Mastercard Send) Accept without post (ACWP) is one of the three available responses a receiver FI can use in response to payment messages (pacs.008 or pacs.004) in both FedNow and RTP. An ACWP message means that the receiving FI has not yet determined whether to send an “accept” or “reject” message and will not provide immediate funds availability to the receiver. Some receiving FIs conduct real-time transaction screening for legal or compliance reasons. If a receiving participant’s screening software generates a match that could indicate the receiving user is not permitted to receive the payment, the participant may respond with an ACWP message. This allows the FI to investigate further. Participant may only submit an “accept without posting” message if: It requires additional time to review the message for compliance or legal reasons or The payment is returning funds to a closed account in response to the participant’s request for return and a) the participant has closed the receiver’s account identified in the payment due to unauthorized activity; b the receiver has another account with the participant, or the participant is in the process of establishing a new account for the receiver; and c) the participant cannot satisfy the immediate funds availability requirement of the “accept” response because it needs time to credit the payment to the receiver’s other account. Note that a payment message ‘accepted without posting’ is immediately and finally settled in the same way as all accepted payments. This means that the sending FI is obligated to pay the amount of the payment message even when the receiving FI sends an accept without posting payment status message. If the receiving FI blocks or rejects the pacs.008, it should include a reason in a pacs.002 message for the sender FI to review. The receiving FI must also return the funds via a payment return (pacs.004) message. Participants must reject the transaction or make funds available to the recipient by midnight Eastern Time of the next standard business day (Monday through Friday, except holidays), unless the participant is concerned with breaching applicable law (e.g., compliance). In this case, FedNow requires the participant provide a status of pending (PDNG) response to the sending FI by the ACWP availability deadline described above. The THE 2025 AFPP HANDBOOK 65 receiving FI must notify the sending FI upon resolution of the investigation and in response to any inquiry from the sending FI. Participants must determine whether to accept or reject the message by 11:59 p.m. local time the next business day following its accept without posting message, except in cases in which the payment is being reviewed for compliance with applicable sanctions laws. Some types of faster payments are inherently irrevocable due to the speed of their payments processing. Therefore, the only way funds can be recovered in case of a mistake is through a payment return. However, for a payment to be returned the recipient of the original transaction must consent to the funds to be sent back to the originator. This process begins by the originator sending a return request through the payment system, which then must be accepted or rejected by the recipient of the original payment. 1. Initiation stage: user initiates a return request (camt.056) 2. Validation stage: The sending FI generates a return request and sends it to the FedNow service with a return request reason code and message details for the original customer credit Transfer (pacs.008) or a liquidity management transfer (pacs.009) The FedNow Service receives return request message and runs through all applicable validations 3. Response stage: Receiver FI receives return request message and begins message validations The receiver’s FI reviews and determines if it intends to accept the message i. Affirmative case (Full return) 1. Sends FedNow Service a return request response with code IPAY indicating it intends to accept the return request ii. Affirmative case (Partial return) 1. Sends FedNow Service a return request response with code PECR, indicating it intends to partially accept the return request iii. Negative case 1. Sends return request response with code RJCR to FedNow Service along with the reason for rejection; or 2. Responds to the FedNow Service with code PDCR, indicating return request requires further review. FedNow Service validates return request response from receiver FI and passes through to sender FI 4. Payment return stage: the Receiving FI initiates a payment return (pacs.004) message 66  TABLE 39. FEDNOW – PROCEDURES FOR PROCESSING ‘REQUESTS FOR RETURNS’ Sender Initiates return request Sending FI Performs anti-fraud checks Sends return request to the FedNow Service FedNow Receives return request Validates return request and runs through response from Receiver applicable validations; FI and passes through to when message passes all Sending FI validations, it is sent to the Receiver FI Receiver FI Receives return request The Receiving FI message and begins to initiates a payment return validate the message (pacs.004) message if it intends to return the payment 1. Initiation stage: user initiates a Request for Return of Funds (RFR) Message 2. Validation stage: the Sending FI generates an RFR Message that references the original CT Message’s Instruction ID and passes it to the RTP System. 3. Response stage: The Receiver FI receives the RFR and responds with a Message Status Report either confirming that the RFR was received and processed or indicating a reason why the RFR was unable to be processed. The Receiver’s FI then determines if funds can be returned to the Sender and transmits the appropriate Message(s) to the RTP System. i. Affirmative case (Full or partial return) 1. Response to Request for Return of Funds (RFRR) Message indicating the Receiving FI has agreed to fully or partially return the funds 2. CT Message with the amount of funds being returned ii. Affirmative case made outside of RTP System 1. RFRR Message indicating the Receiving FI has agreed to fully or partially return the funds 2. References a unique ID associated with the external payment method used iii. Negative case 1. RFRR Message indicating the Receiver/Receiving FI has denied the Sender’s request The RTP System performs a series of formatting, process, and business rule validations on the messages and routes them to the Sending FI 4. Payment return stage: the Receiving FI generates an RTP Credit Transfer if it intends to return the payment THE 2025 AFPP HANDBOOK 67  TABLE 40. RTP – PROCEDURES FOR PROCESSING ‘REQUESTS FOR RETURNS’ Sender Initiates return request Sending FI Generates RFR message and passes to the RTP System RTP Performs a series of Performs formatting, format and business process, and business rule rule validations and if validations and routes the successful, passes the RFR Messages to Sending FI to the Receiving FI Receiver FI Receives return request The Receiving FI message and responds generates a RTP Credit with a Message Status Transfer if it intends to Report. Then determines return the payment if funds can be returned to the Sender and transmits the appropriate RFRR Message to the RTP System. Like account-to-account payment transactions, an entry or a file of entries that has been transmitted to the ACH Network cannot be recalled but may be requested to be returned under limited circumstances. In such cases the ACH Network allows two scenarios where 1) a Sending ODFI attempts to correct an erroneous entry or file by transmitting a reversing entry or reversing file to the RDFI (reversal) or 2) a Sending ODFI requests the RDFI to return an erroneous entry (request for return). The following processes demonstrate the implementation steps for both reversals and request for returns. Reversals (files and/or entries) 1. Reversal initiation stage: The sender initiates a reversing entry or a reversing file. The originator or its FI must submit reversals following the format and timing required by Nacha. An originator or ODFI initiating a reversing file must concurrently initiate a correcting file, unless the erroneous file was a duplicate. Note that the originator must make a reasonable attempt to notify the receiver of the reversing entry and the reason for the reversing entry no later than the Settlement Date of the reversing entry. Nacha does not specify the method (i.e.,, email, telephone, etc.) 2. Response/approval stage: This does not always guarantee successful recovery from error since reversals, like other entries, may be returned/rejected by the RDFI for insufficient funds or other valid reasons. Request for return 1. Request for return initiation stage: Originator initiates a request for return by contacting a designated ACH contact at the ODFI. The ODFI, not the originator, should make the request to the RDFI. 68  2. Response/approval stage: The RDFI may agree to return the entry, but it is not required to do so. If the RDFI does agree, it may ask the ODFI for a letter of indemnification prior to returning the entry. The RDFI should use Return Reason Code R06 (Returned at the Request of the ODFI) to return the entry. Both Mastercard Send and Visa Direct enable senders and the sending FIs to use a funds transfer API to return funds. For push-to-card networks, if a push payment fails to complete, the sending FI must reverse the original transaction pulling funds from the sender’s account. In the case where Mastercard Send funds transfers involve funding transactions before payment transactions, the Originating Institution/Transaction Initiator (OI/TI) requests the reversal of funding transactions that were originally transmitted to secure the funds to be transferred. For Visa Direct, when the Original Credit Transaction (OCT) is declined, the Account Fund Transfer is reversed using the Adjustment API. The funds are pushed back to the sender’s Visa account after a financial message called an Account Funding Transaction Reversal (AFTR) has been initiated. In this case, there is no 24-hour limitation in the AFTR. The original pull funds transaction can be reversed using either the ReverseFunds operation for a single account or the MultiReverseFunds operation for multiple accounts simultaneously. The following steps summarize the process of returning funds for push-to-card networks. 1. Initiation stage: OI/TI initiates a funding reversal API request when a payment transfer is unsuccessful. 2. Validation stage: the card network validates the request and, if accepted, transmits the request message to the sending FI for approval. 3. Response stage: Sending FI receives the funding reversal transaction request and either approves or declines the request. The response is passed to the card network and then the network forwards the API response to the OI/TI. 4. Payment return stage: OI/TI begins a payment transaction to transfer funds to the sending FI. TABLE 41. MASTERCARD SEND – PROCEDURES FOR PROCESSING ‘REQUESTS FOR RETURNS’ Sender Originating Initiates a funding reversal Begins a payment Institution/ API request when a transaction to transfer Transaction Initiator payment transfer is funds to the Sending FI unsuccessful Push-to-card Network Validates the request Receives the API response and if OK, transmits the and forwards to the OI/ request to the Sending FI TI Sending FI Receives the funding Submits funding reversals reversal transaction request and either approves or declines the request THE 2025 AFPP HANDBOOK 69 While most types of Faster Payments transactions are final and irrevocable once the payment is settled, financial institutions may submit requests for returns and reversals in case the transactions are deemed fraudulent or due to error. FedNow’s credit transfers can be returned either when a FedNow participant decides to honor a return request (camt.056) message or when the FedNow participant cannot apply the funds it received, for example, when rejecting a payment after initially responding with an accept without posting status. Once a payment return (pacs.004) is initiated the message follows the same end-to-end processing across the FedNow Service as a customer credit transfer (pacs.008). For that reason, the return request (camt.056) message also can be used to report fraud. Similarly, a liquidity management transfer (pacs.009) can be returned if a participant determines it is necessary. The sending FI in RTP may initiate a Request for Return if it encounters errors in the payment, claims unauthorized transactions, or experiences processing issues leading to incorrect payments. These include unauthorized RTP payments, erroneous RTP payments, or RTP payments made in response to fraudulent payment requests. A sender or sending FI issuing a Request for Return bears no liability to the receiving participant, as it does not constitute the cancellation of an RTP payment. The receiving participant is not obliged to return funds in these cases. All credit transfers are finalized upon the system’s processing of the positive response message from the receiver FI. On the other hand, a Request for Return of Funds serves as an appeal to the receiver FI to investigate the possibility of fund retrieval, with no guarantee of successful recovery. The ODFI in Same Day ACH can rectify an incorrect entry or file by sending a reversing entry to the RDFI. This addresses entries transmitted erroneously or without the proper authorization of the originator. When the sending ODFI has made processing errors it can request the RDFI to return an entry. These instances include duplications, incorrect payment orders, variations in payment amounts, unauthorized credit entries (e.g., corporate account takeover), and discrepancies in the timing of debit or credit entries. However, relying on reversals does not guarantee a successful correction of errors, as they may be rejected due to reasons such as insufficient funds or other valid causes. The decision to return an entry lies at the discretion of the RDFI. File reversals can be initiated to fix issues like duplicated files or files with a significant number of incorrect entries. It is the responsibility of the party that originated the duplicate or erroneous file to reverse that file. A failure by the ODFI to fund a credit file is not considered a valid reason for initiating a file reversal. Each reversing file must be in the format required by ACH specifications. For push-to-card networks the sending FI must reverse the original pull funds transactions when payment transactions fail for reasons that can include a lack of funds. For Visa Direct the original pull funds transaction can be reversed using the Adjustment API, which initiates a financial message called an Account Funding Transaction Reversal (AFTR). The ReverseFunds operation can be processed for a single account or multiple accounts simultaneously. A reversal of an originating credit transaction can be processed only when the reasons for the reversal include incorrect payment credentials, incorrect transaction amount, duplicate processing, or incorrect transaction code. 70 When it comes to submitting requests for returns, each payment service operator requires a specific timeframe for senders and sending FIs to follow. The FedNow Service strongly recommends that receiver FIs respond as soon as possible, but no later than midnight of the next standard business day. Only FIs that decide to investigate for future information can take up to ten standard business days. The RTP system also indicates that receiver FIs should respond within ten standard business days of receiving the request for return. When there is a need for further investigation of the claimed fraud or breach of warranty, FIs can take longer than ten days. For Same Day ACH every reversing entry should be sent to the ACH Operator within a timeframe that ensures it reaches or is accessible to the RDFI within five banking days from the settlement date of the erroneous entry. Both the sender and ODFI are required to transmit each reversing file promptly and, when applicable, respond to a correcting file, to the ACH Operator within five banking days following the settlement date. When returning funding transactions, Mastercard Send requires that funding reversals be submitted within 30 minutes of the funding transfer request. For Visa Direct, a reversal of an Original Credit Transaction (OCT) must be processed within one business day of the processing date of the transaction. TABLE 42. FASTER PAYMENTS NETWORK – TIME FRAMES FOR PROCESSING ‘REQUESTS FOR RETURNS’ FedNow Receiver FI should respond to the return request as soon as possible, but no later than midnight of the next standard business day. RTP Receiver FI should respond within 10 banking days of receiving the request for the return of funds, however may take longer than 10 banking days to investigate the claimed fraud or breach of warranty. Same Day ACH Sending FI/ODFI must transmit the file to the ACH Operator within 24 hours of the discovery of the error, and Receiver FI/RDFI should receive the reversal file within 5 banking days after the settlement date. Mastercard Send Receiver FI must submit funding reversals within 30 minutes of the funding transfer request. Visa Direct OCT reversals must be processed within one business day of the processing date of the transaction. Faster Payment rails utilize various methods to create, record, and retain information needed to evaluate issues that may arise after a payment has been initiated. These methods can involve monitoring, payment tracing, incident tracking, and using transaction IDs, though specific procedures for handling such transaction exceptions can vary depending on the faster payment rail. All return request (camt.056) messages contain a unique message identification, assigner, assignee, and creation date time. The case is assigned a unique identification and the creator of the investigation case when the investigation of the request begins. This can include contact details in case further discussion of the request or a request response is needed. Return request messages must also indicate a reference to the original customer credit transfer. This information comprises of original message identification, original message name identification, original creation date time, original instruction ID, original end-to- end ID, original interbank settlement amount and settlement date, etc., to help the other counterparty identify the transaction requested to be returned. Cancellation reason information is required, which THE 2025 AFPP HANDBOOK 71 specifies the reason for the return request and should contain a code from the ISO 20022 externalized CancellationReason1Code list. Reason code FRAD, for instance, is be used to report fraud and meets the FedNow Service fraud reporting requirement. When RTP allows for an exception handling process to return funds from a previous transaction transfer, it requires the sending FI include a reference to the original transaction’s unique ID in the response to the request for funds message. The RTP System Operator can then identify the request and validate the message. If the receiver FI intends to accept the request and return a partial or full fund, the receiver FI must also include a reference to the original credit transfer’s unique ID. For Same Day ACH reversals it is necessary that the word “REVERSAL” is placed in the Company Entry Description Field of each Company/Batch Header Record. In addition, ODFIs must ensure that the sender or ODFI’s name reflects the RDFI identified in the erroneous entry being reversed when initiating a reversal. The ODFI of the reversing entry may make negligible variations to the original content of the Company Name field, such as for accounting or tracking purposes, on condition that the name of the sender remains readily recognizable to the receiver. Same Day ACH further recommends that ODFIs set a reasonable level of monitoring and tracking parameters that look out for questionable transactions that are classified Code R17 (File Record Edit Criteria/Entry with Invalid Account Number Initiated Under Questionable Circumstances). Mastercard manages and records the information needed for post-transaction exception evaluation by employing transaction identifier codes to track payments. These codes serve as unique identifiers, ensuring a connection between various authorization requests and the corresponding transaction. Transaction identifier codes for Mastercard require the following identifying data elements: transaction date, a Trace ID code, a BankNet reference number, and the date of the payment settlement. The unique identifier generated becomes a critical part of the transaction authorization and clearing process and is used in tracking payments as a part of exception processing. Visa Direct utilizes the status of Direct API calls which include various error codes, HTTP status code returned in the response, and other informat