Whenever someone asks me if a certain transaction type can be processed as an instant payment, I can’t help but think of the old Will It Blend? infomercials. I picture a smiling Tom Dickson, clad in safety glasses and thick rubber gloves, holding said transaction above his mighty blender as he bellows, “Will it process? Let’s find out!”
With that amusing image in mind, let’s break down three transaction types that the instant payment networks can process and shed some light on what a 100% credit push means, with separate opportunities to request funds or share structured data.
First, I promise I won’t go into the ISO nomenclature or talk PAIN and PACS and ADMI ISO 20022 message types. One, no one cares but the developers. And two, other people have already spilled enough digital ink providing intimate portraits of the data exchange parameters.
Instead, I’ll explain in plain English how the sausage is made, what sausages are in market, and what message types (value and non-value) those sausages are encased in.
1. Credit Push Messages
Think of credit push transactions like sending money directly from your financial account to someone else's. They’re super handy for things like paying bills, sending money to friends, or making direct deposits. The best part? The money moves instantly, so there’s no waiting around.
Who’s pushing credits today? Here we find the use cases we’re all familiar with, namely payroll, earned wage access (EWA), wallet defunding, gaming, and some B2B. Mostly, it’s businesses sending to businesses or businesses sending to consumers in straightforward disbursement use cases without a lot of complexity or need for massive amounts of data to be successful. I’m rather fond of the future for loan proceeds, myself – and that’s already the buzz with institutions I meet with.
What hasn’t come into prominence yet? Bill Pay and B2B AR/AP integrations. Billers don’t make it easy to send money to them from your bank account – they don’t just give you their routing and account number (the numbers they are so happy to have from you).
Billers are accustomed to asking permission up front and pulling money – and they like it that way. The people they pull money from, not always so much. Everyone has a gym membership in their history that kept debiting for ages before it could be stopped.
As for integrating for straight-through payment processing between payment processors ... baby steps, folks, baby steps.
2. Request for Payment Messages
Talk about turning the debit pull on its head! What FedNow® Service and RTP® Network have in place is not a monetary or “value” message – it’s a Request for Payment (RFP) message. It’s an ask that provides just enough info that you feel comfortable saying “yes” and sending the money, or “no” and declining the request.
Receiving an RfP is like getting a digital invoice. Someone sends you a request to pay, and you can approve it right away or potentially schedule it for payment later. It's perfect for paying bills and was developed to make the whole process quick and secure, while reducing errors. But getting started isn’t easy. It means rethinking years of user interfaces and learned behavior. And it’s taken a while for the industry to even begin to figure it out.
The RTP Network has some rules to keep requests for payment running smoothly:
- Registering business senders: Only verified businesses can send RFP messages, which helps keep the system secure.
- Limited use cases: RFP is mainly used for things like bill payments and online shopping to prevent misuse.
- Sender ID inclusion: Every RFP message includes a sender ID, so you always know who's asking for the payment.
New Warranty Requirement for Financial Institutions
Why all the infrastructure above? Both instant payment networks have rules requiring the bank sending the request for payment to guarantee that the sender is legit. This is all about building trust and making sure everyone who is playing in the system is on the up-and-up.
Banks are still figuring out how this will work and how to account for the risk in their ROI models. With no historical data to build on, it’s hard to reduce the risk of a bad actor that is, for example, pretending to be a utility asking for money. We’ll get there, but this is a real dilemma for early adopters.
-
3. Request for Information Messages
Request for Information (RFI) is all about gathering details. In the financial world, it enables banks and businesses to exchange structured information in support of end-to-end processing.
So, imagine a conversation between two businesses:
Business 1: Request for Payment : $100 due the first of the month for P.O. #62.
Business 2: Response Request for Payment for P.O. #62: Yes.
Business 2: Credit Push tied to Request for Payment for P.O. #62: Here’s $80.
Business 1: Request for Information tied to credit push tied to RfP for P.O. #62: Why the short pay?
Business 2: Response to Request for Information tied to Request for Information tied to credit push tied to RfP for P.O. #62: Didn’t get five boxes of widgets, sending money for four. Link to document repository with image of delivery notice.
Cool stuff, right? Sadly, there really aren’t any user interfaces designed yet to present this kind of back and forth chatting that we’re aware of. And the decision to use RFI will depend on the ROI of integrating into applications where the exchange of structured data would allow for automated processing. ERP engines, I’m talking to you!
So, there you have it! Credit push messages are in market today with increasing numbers of happy senders and receivers. The industry is working on the Request for Payment call and response, the couple of banks able to receive and present these requests are sitting out in the cold a bit, while Request for Information is a sparkle in some fintech’s eye!
Now back to YouTube and Tom’s 10th anniversary compilation. Oh, yes! It blends.
.svg)
