What’s in a Name? RTP vs RTRP vs IPS vs Faster Payments
One of the fun things about working on a global trend is watching the alphabet soup of acronyms and buzzwords diverge and converge.
The US and UK are largely still using the term “faster payments,” and you hear that from international financial institutions like the World Bank. The rest of the world seems to be debating between “real-time payments (RTP)” or “instant payment systems (IPS).”
Now, sometimes that doesn’t quite cover it. I also hear “real-time retail payments (RTRP)” for people who want to emphasize that these are small transactions. In some markets, however, this is confusing because it implies retail merchant payments (which
is only one use case – albeit an important one). Other times you hear “instant and interoperable payment systems” to emphasize the open-loop nature. Interoperability is important, but generally, we haven’t come across anyone using the simpler instant payment
system that doesn’t imply some kind of interoperability.
So, whether we talk about “real-time payments” (RTP) or “instant payment systems” (IPS), I think we can all agree we’re talking about the same thing. Specifically, we’re talking about push-only, irrevocable, open interoperable payment systems that offer
clearing within a second or two.
For our purposes, we’ll use IPS.
To Be Or Not to Be… Inclusive
The definition in question today hinges on one important nuance of interoperability: what is “inclusive interoperability?”
It’s not good enough to just say, “I know it when I see it” because a lot of deliberate decisions in policy, business, and technology have to be made to counter industry inertia to ensure that the inclusivity part happens.
There are, unfortunately, more examples of non-inclusive IPSs than inclusive ones.
All Classes of Financial Institution Need to Be Included
In building an inclusive payment system, we need to meet people where they are, i.e. the financial institution where they are currently served. It’s not enough to say, “Any regulated financial institution (FI)
can join the payment scheme.” That’s like saying, “Anyone can buy a new iPhone.” Yeah, with enough resources they can — but doesn’t that defeat the purpose of saying we’re including those that don’t have resources? The financial institutions that
serve the last mile are operating on razor-thin margins as it is (if they were raking in the cash we’d call them predatory, wouldn’t we?)
Very often, saying “any FI can join” omits the second half of the sentence: “as long as they meet the legal, security, compliance and liquidity requirements.” Well, if the system was built for banks, then that translates to “become a bank.” The entire system
needs to be designed to meet these financial institutions as close to their current state as possible.
Security and liquidity must be designed to ease participation without increasing risk to larger institutions. The business models of mobile money and microfinance are fundamentally different from banks, so the business rules of the scheme must take that
into consideration. Customer due diligence and know-your-customer (KYC) standards are different across classes of FI. Even transaction protocols and identifiers are managed very differently.
Many systems we see being built today can cost upwards of $250,000 just for technology integration –
if you have a high-end core banking system. And that doesn’t account for the cost of business process changes and hiring an army of lawyers and security experts to ensure compliance.
My recommendation is to change our language from, “all classes of regulated financial service providers (FSPs) are
allowed to participate” to “all FSPs are enabled to participate.”
Inclusive Use Case Design
It’s hard to think of how a system is inclusive. It’s perhaps better to describe what the end user should experience. What is an inclusive peer-to-peer (P2P) payment? What is an inclusive merchant payment?
There are some standards we see developing that will help answer these questions:
- P2P must be alias-based. Any IPS system still using routing numbers and account numbers is non-inclusive. Period.
- The sender should get a confirmation about the recipient and all fees before they hit send.
- With merchant payments, merchant-presented static QR codes allow merchants who don’t have a point of sale (POS) machine or dedicated smartphone to accept payments.
In a one-person shop like a fruit stand, the last point means that the merchant can help the next customer while the first customer is still paying. Beyond that, centrally-generated QR codes ensure small FIs can also acquire merchants.
Combining with the previous section, effective interoperability across banks and non-banks means tiered know-your-customer (KYC) is not an edge case — it is
the important case. Merchant self-registration for a limited volume of daily transactions significantly lowers the barrier to adoption. Third-party payment initiation should be enabled to ensure that small institutions can partner with fintechs to offer
their clients a great customer experience without lock-in.
Bringing the Last Mile into the Digital Economy
Of the nearly 1.4 billion people worldwide who do not have access to traditional financial services, 90% have mobile phones.
Inclusive interoperable payment systems help central banks, hub operators, and other financial institutions collaborate to bring financial services to the entire population – including the underbanked. Once the underbanked establish a history, other financial
services like loans become possible. This opens up opportunities for the financially underserved to make big improvements to their lives. IIPSs also grow the customer base for the financial institutions and businesses that serve them.
It’s hard to argue with a triple-win like that.