FedNow's request for payment
An In-Depth Analysis of FedNow's Request for Payment Features
Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace
Today, we're set to delve deeply into the details of the FedNow request to pay flow. While we've previously provided a broad overview of the 'request to pay' functionality, this will be our inaugural exploration of a specific implementation. For a comprehensive understanding, we suggest revisiting our introductory articles on request to pay and FedNow before proceeding further.
As a quick refresher for those who may be new to the subject or need a recap and do not want to read the full articles, 'Request to Pay' (RTP) operates on a carefully orchestrated sequence of steps, each integral to the process:
The RTP initiation is a stage specific to the creditor whereby the content of the RTP is populated in function of the transaction requirements. Mandatory elements such as the amount to be paid, transaction reference, creditor should be included at this stage. The RTP presentment can be defined as the moment when the RTP is received by the debtor or payer. It can be assumed that once created, the RTP is immediately sent and presented as there is no business need to delay this stage, even though for technical reason there could be a certain delay until the moment when it is made available to the payer. The acceptation or refusal is the moment when the debtor utilises an application (mobile application, Web browser) installed in a physical device to accept or refuse the RTP, usually by clicking on “confirm”, “accept”, “pay” button, or “decline/refuse” button. The status report is the step where the debtor acceptation or refusal is transmitted to the creditor via a status report message. Depending on the use case the status report can be linked with the payment initiation. In case of acceptation, the payer gives to its PSP the instruction to initiate the payment. The payment initiation, even though not part of the RTP lifecycle itself, is included to illustrate the close link it has with the RTP, as it uses payment data from the RTP and performed upon the payer’s action.
RFP is simply a way for a person or organization (the requestor) to request an instant payment from another person or organization
Now that the general understanding is clear we can begin our analysis of FedNow’s RTP implementation in terms of the messages that are exchanged. Let's analyze the simplified version first of the transaction flow during a successful case scenario where the debtor accepts the request from the creditor:
The creditor or biller initiates the process, distinguishing it from the conventional push-based customer credit transfer. This is done by the creditor agent sending a pain.013 message, containing the payment details, to the debtor agent.
The debtor will receive a notification through their banking application, and decides whether the reject or accept the payment. In the successful case scenario presented down below, will proceed to accept the transaction.
The receiving institution will respond the acceptance via a pain.13 message to inform the creditor agent of the decision.
Subsequently, on the requested execution date (provided in the request) the receiving institution will initiate a customer credit transfer, utilizing the beneficiary payment details provided in the pain.014 message.
In the messages depicted in the diagram above, we have chosen to omit the specifics of the business application header since all messages are prefixed with such header, as detailed in our last article. We have excluded as well the details of the customer credit transfer messages, pacs.008, as these have been presented on multiple occasions. For more comprehensive information on the customer credit transfer details, you can review all the specifics in the following article.
Also, as a reminder of the system messages involved, see the previous happy flow with the acknowledgements from FedNow included:
Most important fields in the request for payment message pain.013 include:
Group header: Used to uniquely identify a request for payment sent through FedNow.
Message identification: Unique for a given calendar day.
Creation date and time: Date and time of when the message is created in UTC
Number of transactions: Default value 1
Initiating party: Person or entity initiating the request. This can either be the biller/creditor or the party that initiated on behalf of the biller.
Payment information: Used to provide detailed information on the debit side of the transaction.
Payment information identification: Unique reference of this RFP
Payment method: Default value ‘TRF’, only 1 payment transfer method allowed so far.
Requested execution date: Date and time the debtor agent should initiate the transfer if the decision of the debtor was to honor the request.
Expiry date: Specifies the timeframe beyond the initial due date during which the Request for Payment (RFP) remains valid for acceptance. This date serves as the ultimate deadline by which the debtor's agent can present the RFP to the debtor for either acceptance or rejection. Beyond this expiry date, the RFP should become inoperative, disallowing any further actions related to it.
Debtor
Debtor account
Debtor Agent
Once the request expires it will be marked in the debtor agent storage as expired and therefore will not be anymore applicable to be operated by the debtor and will be no longer shown in the App. The expiry date serves as an extended grace period set by the creditor within which the payment can be completed. According to FedNow's architectural design, this grace period should not exceed a duration of 365 days into the future.
Let’s review now the last group of fields in the pain.013 request:
Credit Transfer Transaction: Mandatory and single occurrence block used to provide detailed information on the credit side of the payment transaction.
Payment identification: Contains all possible ISO 20022 references for this request.
Instruction Id
End to End Id
UETR
Payment Type information: Consumer, Business or Government payment request.
Payment Condition: The Creditor can specify some optional conditions around the payment if the it is accepted.
Amount modification allowed: Whether or not the debtor may instruct payment for an amount different than in the request. Usually the modification will be linked with the early payment condition.
Early Payment allowed: Whether or not the debtor may instruct payment before the requested execution date. The creditor provides the debtor with the flexibility to complete the payment prior to the stipulated execution date. This option is frequently associated with incentives such as early payment discounts.
Guaranteed Payment request: Whether or not the creditor requests guarantee from the debtor agent to execute the payment.
Amount: requested amount
Charge Bearer: default SLEV: Charges are to be applied following the rules agreed in the service level and/or scheme, in this case FedNow.
Ultimate debtor
Having thoroughly examined the individual fields within the Request for Payment, let us now proceed to explore the corresponding request for payment response mechanism (pain.014 R-message). This is the message that the FedNow participant uses to inform another FedNow participant about the processing status of a request for payment previously sent through the FedNow service. This message either informs that a request for payment has been rejected y the FedNow service for failing the business validations or contains the response of the participant that received the request for payment. One scenario in which the FedNow business rules might reject the initial pain.013 is when the receiving participant of the request is not set to receive requests for payment messages, or when the routing number is not in FedNow’s routing table. See below the most important fields of a request for payment response:
Message identifier: Must be unique for a given calendar day.
Creation Date time: date and time when the message is created by the sender.
Initiating party: Person or entity that initiated the request (pain.013), typically the creditor.
Debtor Agent: FedNow participant to whom the request for payment was sent.
Creditor Agent: FedNow participant that sent the request for payment.
References to the original pain.013 to which this response responds to: All references that appear in the initial request will be provided in the response.
Original message identification
Original message name identification
Original creation date time
Original instruction identification
Original end to end identification
Original UETR
Transaction status:
Accepted: Request for payment has been accepted by the debtor.
Presented: Request has been presented to the debtor an now the debtor needs to take the decision.
Rejected: Request has been rejected either by FedNow service, debtor agent or by the debtor.
Received: Request was received by the participant, like an end to end acknowledgement of reception as opposed to the admi.007 message.
Status reason information: Group of fields used to further explain the response. For instance, when the request is rejected this field might give extended information on the rejection reason.
Payment condition status:
Accepted amount: Amount that was finally accepted to be paid.
Early Payment: If the request allowed the early payment in this field will be instructed the date before the requested execution date. Indication whether the debtor will instruct the payment before the due date. This condition in the design allows the biller to implement a discount feature for early payments.
Guaranteed Payment: Indication whether the debtor agent guarantees to send the funds transfer for the accepted amount on the execution date. During the initiation of a payment request, an institution has the option to activate the 'guaranteed payment' field. When this field is set, the creditor's agent is effectively requesting the debtor's agent to ensure the funds transfer will occur on the designated execution date, irrespective of the debtor's account balance at that time. A physical or online merchant presents an RTP to a consumer. Upon acceptation the merchant can benefit from a guarantee of payment so that the delivery of goods or services can start immediately. It is important to note that the payment guarantee is an optional flag sent with the request and the receiving bank might respond negatively to such requirement.
.
The request for payment cancellation request (camt.055) is a specialized message initiated by the creditor's agent with the intention of nullifying a previously submitted request for payment. Depending on various conditions and protocols, the debtor's agent has the option to respond either affirmatively, thereby agreeing to the cancellation, or negatively, which means the request for cancellation might not be honored.
Scenarios in which the request for payment cancellation may not be honored by the debtor's agent include situations where the original payment request has already expired or if the corresponding pay-out has been initiated. Under these circumstances it is too late to cancel therefore the debtor's agent is likely to issue a negative response to the cancellation request. Should the current state of the payment request permit cancellation, the debtor's agent will proceed to nullify the request. Subsequently, the debtor will be informed about this change in circumstances. Following these actions, the debtor's agent will issue a positive response confirming the cancellation, which will be sent back to the creditor's agent for acknowledgment.
Most important fields of this message include:
Case identification: Identification of this cancellation request in the case management system.
Cancellation reason information
Originator: Person or entity that assigned the cancellation request reason
Reason code: Alphanumeric character that specifies the reason for the cancellation request.
Additional information
In this article, we have delved into the details of FedNow's implementation of the 'Request for Payment' mechanism. Among the most noteworthy features designed into this system are several key functionalities. First, there is the option for advance payment, allowing transactions to be secured well before the due date. Second, the system includes the capability for the creditor's agent to solicit a guarantee for the funds transfer from the debtor's agent, thereby ensuring that the transaction will proceed as planned. Lastly, the architecture also allows for the cancellation of previously issued payment requests, offering added flexibility and control in transaction management.