Digital Transactions Authoritative, insightful and timely information for payments professionals
The RFP is emerging as one of the most important features of real-time payments platforms. Here’s how to implement it.
Request for Payment (RFP) isn’t a novel concept in banking or payments, but it will drive a lot of innovation over the next decade. Many institutions will rely on RFP functionality in the new FedNow service as their primary mechanism for real-time payments because it’s a data-rich, low-risk way to enable fast payments.
The next few years will see many changes as financial institutions develop internal processes and procedures for handling RFPs. To support greater consistency and adoption of the right operational processes, the FedNow Service is built on the ISO 20022 standard, which helps drive industrywide standardization. As more institutions align with the standard, the easier it becomes for everyone to take full advantage of real-time payments.
Integrating real-time payments into the banking ecosystem will put everyone on a fresh learning curve. Right now, the curve feels steep, and everyone is eager to implement best practices, even though not every institution has real-world experience with FedNow and RFPs.
The purpose of this article is to cover RFP best practices as they stand today and how your institution can incorporate them into your payment operations.
A Quick Primer
In many industries, “RFP” stands for “request for proposal.” For banks operating on the FedNow service and other faster-payments rails, it means “request for payment.”
When a customer (the requestor) wants to submit an RFP to another entity (the recipient) using FedNow, there is a straightforward, three-step process to follow:
1. The requestor supplies the originating institution with the following details:
a. Identifying information for the recipient;
b. Identifying information for the requestor, including contact information.
2. The originating institution formats the message with:
a. A reference number. This number is fixed throughout the RFP process and will be associated with the payment.
b. Amount requested: This can be a fixed or flexible amount.
c. Requested execution date for the payment: Essentially, the due date for the RFP.
d. Expiration date: This limits how long an RFP can linger with the recipient without a response.
e. Description: Provides details of the product, service, or transaction the RFP is connected to.
3. The originating institution can include some optional details, such as:
a. An amount modification permitted indicator: This can allow the recipient to pay more or less than the requested amount, depending on the conditions of the transaction. For instance, a recipient may want to pay extra on a loan or credit card statement.
b. An early payment permitted indicator: A business could offer discounts for early payment, or a recipient may want to pay early based on a unique situation.
c. Remittance details: Requestors can include extra information such as ISO 20022 data, an invoice number, or a hyperlink to an itemized invoice.
d. Status codes: Using FedNow, institutions can allow requestors and recipients to view the payment status, including when it was received, shown, accepted, rejected, and completed.
The rich formatting options of the RFP interface allow institutions to embed value-added options for their account holders. This is especially relevant for commercial-banking customers who need to reconcile lots of payments and manage cash flow.
Benefits And Use Cases
Consumers already use some “instant” payment vehicles, even if they offer only the appearance of immediacy, because companies such as Venmo and Block front the money for the recipient until the automated clearing house transfer clears. Commercial customers still operate under the constraints of ACH transfers, paper checks, and wire transfers.
The power of real-time payments will unlock exciting possibilities for many businesses and the consumers who transact with them.
For example, a large property-management company may process thousands of rent payments monthly. It needs to distribute them across hundreds of property owners. This might require three separate ACH transactions, resulting in a two-week delay between the first of the month and when the property owner sees the payment in its bank account. Real-time payments could compress that time down to a day or two.
The robust data capabilities of real-time payments and the RFP protocol also mean that businesses will have a much easier time reconciling invoices, managing receivables/payables, and projecting cash flow.
The standardization of the data is a boon to all parties. Transferring and analyzing real-time payments data generated through the ISO 20022 standard will enable better insights to institutions and customers alike.
Enrolling Requestors And Recipients
Banks can enable real-time payments and RFPs for retail and business accounts. Most requestors are likely to be businesses, and most recipients are likely to be consumers.
If a bank is going to offer RFP-sending capability to its customers, it will need a standard information-capture form to populate the RFP message fields. Banks will also need to verify recipient accounts using a zero-dollar RFP transaction.
Think of the RFP mechanism as a robust feature set that should be integrated into mobile- and online-banking interfaces. Users may not need access to every feature, but they need to manage RFPs, including accepting or rejecting, paying, modifying, reporting fraud, and sorting them.
The interface for end-users is the responsibility of the bank or the vendor providing online and mobile banking. The Federal Reserve states explicitly it is not developing the user experience/user interface for institutions.
Responding to RFPs
When recipients sees an RFP in their account interface, they can respond in multiple ways:
- Pay the amount requested
- Pay more or less (if permitted)
- Decline to pay
A recipient that chooses to decline the RFP can provide pre-written reasons or a brief description of why the RFP was declined:
- Already paid
- Unrecognized sender
- Order canceled
- Duplicate payment
- Narrative (also known as “Other”)
- Unspecified
As you build out the interface for real-time payments and RFPs, you’re going to discover new possibilities to improve the experience. Invite your customers to participate in this process. Include a button that lets them easily write feedback on the interface. This will help guide you in how to make it better.
Don’t worry if the first few iterations aren’t fully polished. It’s critical that you set expectations for your staff and account holders. This is a new process. You’re committed to continuous improvement, not perfection.
Are You Ready?
At FedNow’s launch last summer, 35 banks went live with the service. By early February, that number had grown to 470, it is certain to continue growing. The next months and years will be filled with integrations, exciting product developments, and ongoing market education.
Incorporating real-time payments and RFPs into your product suite paves the way for dramatic changes in how your institution and your customers move money. Financial institutions that begin moving toward this new paradigm will gain a competitive advantage that’s tough to beat.
—Abhishek Veeraghanta is founder and chief executive of Pidgin.
