When one party wants to be paid by another party – preferably as soon as possible – the request for payment (RFP) feature of an instant payment can make the process a snap.

By using RFP, a business can present a bill through a customer’s mobile banking app, and the customer can then approve the prefilled information about the payment amount and requestor in a single step. A simple enough example, but RFP is a powerful tool that financial institutions and their customers can use to unlock additional value in a variety of payment use cases.

When the FedNow^SM Service launches in 2023, RFP will be one of the key features of the new instant payments service. Among other things, it will allow financial institutions and other service providers to build instant bill pay services that can help their consumer and business customers conveniently send e-invoices, receive instant bill payments and better manage cash flow.

This article describes the RFP features that will be available with the FedNow Service and then puts them together to walk through a hypothetical transaction flow.

How does an RFP work and why is it important?

To reiterate, RFP is simply a way for a person or organization (the requestor) to request an instant payment from another person or organization (the recipient).

A requestor creates an RFP by providing the required information to its financial institution,¹ which formats and sends the message through the FedNow instant payment network. The network routes the message to the recipient’s financial institution, which presents it to the recipient via its front-end or mobile app. The recipient can authorize an instant payment in response.

RFP will allow for the exchange of rich data and provide an opportunity for customized payment options. For instance, it incorporates underlying transaction details, so it can serve as a useful record of the transaction. With simple invoices, it may serve as a way for a business to streamline reconciliation processes.

Financial institutions can also play a more integral role in the bill payment process by offering certain RFP capabilities like status tracking, the option to pay a bill early, and the ability to make partial payments with a message indicating the reason (for example, if goods were damaged).

Highlights of required RFP elements

Like any instant payment transaction, an RFP includes the account details of the requestor and recipient, such as their routing and account numbers. The RFP message must include several additional data elements for the payment, including:

• End-to-end identification: A reference code/number passes from the requestor to the recipient and remains unchanged throughout the RFP chain. It will be associated with the resulting payment, if authorized, for reconciliation purposes.
• Amount due: This element simplifies the work required of recipients. They merely need to review the amount of money being requested to ensure accuracy rather than inputting the amount themselves and potentially making a mistake.
• Requested execution date: This element informs recipients by when a payment is requested. It can also be used to nudge recipients to complete a payment in a timely manner, such as when a bill’s due.
• Expiry date: This is the date and time after which recipients will no longer be able to view or access an RFP.² While requestors may allow customers to complete a payment after the requested execution date, the expiry date sets a time limit around how long recipients can pay. This limit can reduce situations where outdated RFPs remain in recipients’ banking apps even after they paid via another channel.

Optional RFP elements

In addition to the required elements, RFPs can include additional information to customize or enhance the value of instant payment services. Below are the names of some of these elements, descriptions of each, details around which party provides the information, and why the information could be useful.

• Amount modification allowed indicator: This element enables requestors to allow recipients to adjust the amount paid via an RFP. Some payments may require an exact amount, but others may benefit from the flexibility to be higher or lower than the original amount due. For example, recipients may wish to pay more on their credit card bill, or they may pay less if disputing a portion of it.
• Early payment allowed indicator: Requestors can also allow recipients to complete a payment before the Requested Execution Date. In some instances, requestors might offer an incentive to customers, such as a discount for paying an invoice before the due date. Alternatively, recipients may want to schedule their utility payment before the due date for peace of mind.
• Remittance information: Requestors have multiple options for including invoice details and remittance data in an RFP. They may display the information via a 140-character description or hyperlink to more details. They could also leverage ISO^® 20022 specifications to provide more customized and detailed information in the message itself. By adding this information, the RFP message can help streamline payment and accounting processes.
• Status codes: Financial institutions can offer a value-add service by enabling requestors and recipients to check the status of their RFPs. The status codes include when a requestor’s financial institution has received an RFP, when a recipient’s financial institution has presented it to the recipient, when a recipient has accepted it,³ and whether it was rejected by a recipient or financial institution. Requestors can benefit from this feature because it can help them investigate delays or challenges in completing RFPs. It can also confirm whether recipients have scheduled payment for upcoming RFPs.

With these elements, financial institutions and other service providers can create additional features for their customers. For instance, they can enhance a bill presentment service by helping billers send a detailed invoice with an integrated remittance feature. And they can enhance their bill pay service by enabling bill payers to make partial payments that include a message about the items on the invoice the partial payment covers. They could also add the ability for requestors to create a sequence of recurring RFP payments, including at varied times and for varied amounts. And recipients’ financial institutions could offer their customers the convenience of being able to automatically accept all incoming RFPs from a given requestor and even automatically schedule payments for the entire bill series.

An RFP transaction flow example

With all this context in mind, below is an illustration of each step to create an RFP transaction for a customer named Lindsey, who pays her mobile phone bill via RFP.

1. Preliminary onboarding: Lindsey’s financial institution informs her about the ability to complete transactions via RFP. She also receives a mailer from her mobile phone service provider about the service. Lindsey is interested in the capability, so she logs into her mobile provider account to input her bank account details and register for monthly RFPs.
2. Requestor begins process: During each billing cycle, the mobile service provider (“biller”) generates the relevant information for Lindsey’s RFP, which includes the biller’s identifying information, the amount due, expiry and requested execution dates, and whether Lindsey can modify the amount due or pay early. The biller then sends the information to its financial institution.
3. Financial institutions route information: The biller’s financial institution receives the information and creates the relevant ISO 20022 message to send via the FedNow Service. The network sends the information to Lindsey’s financial institution, which confirms that the designated account exists and is eligible to receive an RFP.
4. Communication and completion of payment: Lindsey’s financial institution notifies her via text message that she has a bill due from her phone service. She clicks a link in the text message to log into her bank’s mobile app, reviews the details to ensure they’re correct, and has the option to schedule the payment or complete it in the moment. She taps “accept” on the screen to complete the transaction.
5. Completion of instant payment: Through end-to-end identification, the same payment message flows from the recipient’s financial institution through the network and back to the requestor’s financial institution, which passes the remittance information to Lindsey’s mobile service provider and credits her account. Lindsey’s financial institution posts a message to notify her when the payment is complete.

This is one example of how an RFP transaction can work. Because financial institutions have various optional RFP elements at their disposal, they have the power to consider how they could use each one to enhance their customers’ experience.

Key takeaways

1. Request for payment allows a potential recipient of an instant payment to request an instant payment from another person or organization. An RFP can make it easy for the recipient to initiate the payment, as well as provide a record of the payment for the requestor.
2. RFPs require that the requestor input key information like the amount due, the date to complete the payment and the expiry date to complete the payment.
3. With RFP, financial institutions play a central role, giving them the opportunity to offer a new set of value-added payment services to their customers. This includes bill presentment/e-invoicing, payment status tracking and detailed remittance information to support automated reconciliation.

Footnotes

¹Note that a financial institution must also have the ability to send instant payments in order to receive an RFP in the FedNow Service.

²The longest duration for an expiry date is one year after the requested execution date.

³Once a recipient has accepted an RFP, they can choose to either initiate it immediately or schedule it for a future date.

Top of Page