RfP (Request for Payment) for TCH RTP

The Clearing House (TCH) has implemented Request for Pay (RfP) on its Real-Time Payments Network payment rail (called RTP). This is a messaging framework that involves a payee initiating a request for a specific transaction from a payer. It has emerged as a powerful real-time payments channel useful for organizations, merchants, banks, acquirers, and billers. 

RFPs are “pull” payments: a customer receives an RfP, reviews it, and then consents to have the funds debited (“pulled”) from their account. It can be used in various cases: in B2B, P2P, B2C or C2B payments e.g. a utility company requesting payment for services from a business or consumer. 

Terminology difference

Around the world the same functionality goes by different names: Collect money (UPI) in India, Request for Payment (RfP) in the US, Request 2 Pay in Europe (R2P) or Request To Pay (RTP) in the UK. US was already using RTP as an abbreviation for Real-Time Payments, so not to confuse anyone (we’re all confused anyway) they decided to coin their own term for it. When someone tells you they’re experts in RTP field better ask them what exactly they mean.  

In the US not only name is different. Unlike in many other regions of the world, there was no obligation for banks in the US to introduce the new standard, and correspondingly few financial institutions have looked into the subject in greater depth, leaving the field for payment solutions primarily to third-party providers and to card schemes. 

Request for payment

The Request for Payment event describes a scenario when a Payee wants a Payer to send funds that are due to them. This is a multi-step event that starts with sending a Request for Payment (RfP) Message (underlying message used by participants is pain.013). 

The Payer, having been notified that the Payee is requesting funds, may initiate instructions to: 

(a) make the Payment with a Credit Transfer Message (pacs.008), 

(b) inform the Payee that a Payment is scheduled or planned to be paid in full or in part with a Response to RfP Message (pain.014),

(c) indicate that the Payment will not be made with a Response to RfP Message (pain.014)

Let’s now take a closer look at each of the possible flows described above! 

Step 1: Event begins when the Payee’s FI receives instructions to transmit an RfP Message from the Payee. The Payee’s FI may perform account authorization and transaction verifications before sending the RfP Message (pain.013) to the RTP System. 

Step 2: The RTP System performs a series of formatting, process, and business rule validations of the RfP Message (pain.013) and routes it to the Payer’s FI. 

Step 3: The Payer’s FI then replies with the required response, Message Status Report (pacs.002), confirming delivery of the Request to the Payer. 

Step 4: Change: After confirmation by the Payer to initiate the credit transfer, Payer’s FI then sends a new Credit Transfer Message (pacs.008) to the RTP System which validates the Message and routes it to the Payee’s FI for processing.  

Step 5: Payee’s FI sends the RTP System a Message Status Report (pacs.002) indicating a response to Credit Transfer pacs.008 message.                                                                      

Note: Credit Transfer Message must be submitted with a reference to the Payment Information ID found in the RfP Message (pain.013) that requested the funds.  

If the Payee requires additional information be sent in relation to the RFP message so that the Payer knows the reason why the payment is being requested, the Payee may optionally instruct the Payee’s FI to initiate a Remittance Advice Message (remt.001) to the Payer’s FI with the additional information (e.g., complete invoice information). The Payer’s FI then passes that information along to the Payer via their Channel Application. 

Another way to answer RfP Message (pain.013) is by Response to the RfP (pain.014).  This message indicates the nature of the coming Payment: partial payment, overpayment, or payment scheduled for a future date. It includes the amount and date the Payment will be made and would then be followed by a Credit Transfer Message (pacs.008). This is a way of acknowledging the RFP so the Payee doesn’t continue sending further RFPs. It also helps the Payee better understand their expected cash flow.  

The flow starts and ends the same way as the previous one. What is different?  

Step 1: After sending Response to RfP (pacs.002) confirming delivery of the Request to the Payer Payer’s FI sends Response to the RfP (pain.014)                                                                                                                 

Step 2: Payee’s FI sends Message Status Report (pacs.002) indicating the Response to RfP Message (in this case pain.014) had been successfully received.                                           

A negative response can be sent in two scenarios:  

• if the Payer indicates that a Payment will not be made in response to the RFP 
• if the Payer’s FI no longer makes Payment of an RFP available to the Payer 

In both cases Response to RFP Message (pain.014) will be submitted by the Payer’s FI indicating that a Payment will not be made in response to the RFP and including a reason code describing why this is the case. Flow is very similar to Affirmative response with RFPR (flow above) but in this case there is no Credit Transfer. 

Reason code can be either proprietary or ISO code. Below are examples of possible codes: 

The Payee may wish to “expire” an RFP if they have received payment for the particular debt or invoice through another payments system or channel (e.g., a consumer pays a bill via a biller’s website).

Step 1: An RFP Expiry Message (camt.056) is generated by the Payee’s FI on behalf of Payee and passed to the RTP System. The Payee’s FI will reference the original Credit Transfer Message’s Instruction ID. 

Step 2: The RTP System performs a series of format and business rule validations on the Message and if successful, passes the RfP Expiry to the Payee’s FI. 

Step 3: Having received the RFP Expiry, the Payee’s FI must respond with a Message Status Report confirming that the message was received and processed or indicating a reason why the RFP Expiry was unable to be processed (e.g., original transaction not found).  

The RFP Expiry message follows the same flow and steps as the Request for Return message as described below.  

Request for return of funds

The Request for Return of Funds Event begins after a successful Credit Transfer (pacs.008) occurs. First steps are exactly the same as in the first flow described on this page – RfP Affirmative Response with Credit Transfer. To attempt to recover the funds Payer FI can send Request for Return of Funds (RFR) Message (camt.056) in three cases: 

• Payer has made an error in its Payment; 
• Payer has claimed a Payment was unauthorized; 
• Payer’s FI has had a processing issue. 

Step 1: A RFR Message (camt.056) is generated by the Payer’s FI and passed to the RTP System. The Payer’s FI will reference the original Credit Transfer Message’s Instruction ID in RFR so the Payee’s FI can match this request to one of their previously received Payments. 

Step 2: The RTP System performs a series of format and business rule validations on the Message and if successful, passes the RFR to the Payee’s FI 

Step 3: Having received the RFR, the Payee’s FI must respond with a Message Status Report (pacs.002) confirming that the RFR was received and processed OR indicating a reason why the RFR was unable to be processed (e.g., original transaction could not be found). 

The Payee’s FI is expected to then determine if funds can be returned to the Payer and send Response to Request for Return of Funds (RFRR) Message (camt.029) within 10 business days (except for RFRR messages that are sent due to claimed fraud or breach of a Request for Payment warranty). 

At this point Payee’s FI has 4 possibilities:   

• Full Return – the Payee’s FI generates two Messages: An RFRR Message (camt.029) indicating the Payee has agreed to return the funds in full and a Credit Transfer Message (pacs.008) with the amount of funds being returned  

• Partial Return – the Payee’s FI generates same two messages, but in this case camt.029 indicates that the Payee (or Payee’s FI) has agreed to return some of the funds and a Credit Transfer Message will be generated for the amount of funds being returned 
• Return outside of RTP System – If the funds will be either fully or partially returned via a method external to the RTP System (e.g., ACH, Fedwire or CHIPS) then the Payee’s FI generates a RFRR Message (camt.029) indicating the Payee has agreed to fully or partially return the funds and references a unique ID associated with the external payment method used. 

• Negative case – If the Payee decides not to return the funds or does not respond within the investigation timeline, the Payee’s FI will generate a RFRR Message (camt.029) indicating the Payee has denied the Payer’s request. 

Request for information

There are times when a Payee receives a Payment but cannot identify exactly what it is for and more information is needed from the Payer to determine how to handle it (e.g., a discrepancy in amount, invoice number, etc.). In this case the Request for Information message (camt.026) is used. 

The Payer, having been notified that the Payee is requesting additional information, may either 

(a) provide the information to the Payer’s FI and initiate instructions to reply to the Payee, 

(b) indicate that the requested information is not available, 

(c) ignore the RFI and do not reply with the information requested. 

Step 1: The Payee’s FI sends an RFI Message (camt.026) to the RTP System. The RFI Message will reference the original Credit Transfer Message’s Instruction ID. 

Step 2: The RTP System performs a series of format and business rule validations on the Message and sends the RFI to the Payer’s FI. 

Step 3: The Payer’s FI, having received the RFI must respond with a Message Status Report confirming delivery of the message to the Payer.

Step 4: The Payer instructs the Payer’s FI to send a Response to the RFI (RFIR) Message (camt.028) along with the information requested by the Payee. The Payer’s FI will reference the RFI and pacs.008. 

Step 5: This Message is sent back to the Payee’s FI via the RTP System and the Payee’s FI then informs the Payee and makes the response data available using its Channel Application. 

Step 6: The Payee’s FI then sends a Message Status Report back to the Payer’s FI via the RTP System. 

If the Payer indicates that they do not want to reply to the RFI or if the Payer’s FI no longer makes the RFI available to the Payer, the Payer’s FI may optionally send a RFIR Message following the same flow described in the positive case above. Difference is that negative response to RFI will have an indicator in the Message that notifies the Payee’s FI (and Payee) that information will not be sent in response to the RFI. 

RFI Message can also be used in a number of other circumstances, including: 

• Payer requests information related to a Request for Payment; 
• Payer’s FI requests information from the Payee’s FI related to the posting of a Credit Transfer that was accepted or accepted without posting (beneficiary claims non-receipt);  
• Payee’s FI requests information from the Payer’s FI related to the presentment of an RFP that was previously accepted. 

RFP via digital wallet

Because of the integration of TCH and digital wallets you can use Request for Payment option via Zelle or Venmo app. All you need to do is have your email address or U.S. mobile number enrolled with one of the providers. Below there’s an infographic how it works in Zelle app: 

Conclusion

As Request-for-Payment gains traction in the United States, it is expected to reshape payment practices alongside instant payments, facilitating faster, more secure, and more efficient transactions in upcoming years. RfP has the capacity to streamline invoicing, optimize cash flow management, and elevate consumer experiences, making it a transformative presence in the dynamic realm of digital payments. Especially now, when the service is integrated with digital wallets. With the introduction of FedNow this year and its Request-to-Pay services, there will be expanded visibility and market ubiquity for this payment method. TCH and The Federal Reserve have a crucial role to play in facilitating greater collaboration between financial institutions and billers, thereby fostering increased adoption and usage of Request-for-Payment (RfP) services.