Thu, 25 October 2018
For those of you who didn't make it to Money20/20 and want to hear the latest on The Clearing House's Real Time Payments Network (RTP), take a listen to this update conversation with Steve Ledford, SVP at The Clearing House for the RTP Network.
A year ago, The Clearing House got out of the gate with its Real Time Payments Network, a wholly new payments system based on the push payment model.
A lot has changed - more banks have integrated into the system and many more are in process. By the end of June 2019, over 3,000 FIs are expected to connect to RTP, most via their bank processor. B2B payments are taking place over RTP between known parties.
Not All Things
TCH is not attempting to provide everything necessary for a ubiquitous push payment system. It relies on its FI participants and their processors to expose RTP capabilities to their customers. RTP hopesto have bank-friendly fintech partners use its rails through the traditional model that gives the new provider access to bank rails via a sponsor bank.
Thus far, TCH has also steered clear of a native directory service, a necessary feature for broad use in P2P and C2B payments. Given the partial ownership overlap with Zelle's Early Warning Services parent banks and The Clearing House, no one will be shocked if Zelle becomes RTP's lead P2P directory provider. For that matter, few will be surprised when Zelle shifts to RTP for settlement. Of course, at least one business-facing directories will be needed for bill payments to take off.
It's Taking a Lot of Work
Connecting up a financial institution to the RTP Network requires deep integration into the FI’s core system, the software responsible for managing debits and credits. Connecting bank ledgers to any payment system is non-trivial, a fact that impacts how fast banks implement new payment rails like RTP.
Tell Me All About the Payment
A feature of the RTP network that holds enormous promise is its native use of the ISO 20022 messaging format. The standard's flexible and structured qualities--not an oxymoron--provide a major leap in data carrying capability. By representing the payment meta data, for example, ISO 20022 can support invoice information, letters of credit, and other business documents. Accounts receivable and accounts payable systems from multiple vendors will be able to communicate directly, reducing manual data input and data entry errors.
The RTP Push
In the U.S., we are accustomed to pull payment systems. We think nothing of giving our bank account information when we hand over a check or our card data when we hand our card to a merchant. We’re telling the payees where to go get their money so it can be pulled into their account.
RTP and Zelle are both push payment systems. Such systems are characterized by near instant funds availability to the recipient, messaging to send and receiver, and irrevocable payments. That last is very different from the chargeback protections U.S. cardholders, in particular, enjoy. While Reg E applies to the sender's transaction account, accountholder protections will also be prescribed by the FI.
To emulate some push payment attributes, RTP and most other immediate funds transfer systems offer a Request for Payment message type that essentially sends an instant invoice to the payer. The customer may press a Pay Now button that uses the Request for Payment Message on her screen. She then uses bank account credentials to authorize the payment. There may even be a redirect to the bank site. It's a flexible solution applicable to multiple use cases and payment initiation methods like embedded links and QR codes.
Instant Clearing and Settlement
The RTP switch runs software built by Mastercard's Vocalink unit, builder of the now 10 year old Faster Payments system in the UK. The RTP code base, however, is a new version, with native ISO 20022 messaging and an instant clearing and settlement system. That system uses a single, pre-funded account at the Federal Reserve common to all participating financial institutions. A separate ledger operated by TCH is the single source of truth, keeping track of the transfer of ownership of those pre-funded monies. Separate accounts, for each FI at the settlement bank, aren't necessary. So, instant clearing, no batch-based settlement. Lower risk, simpler management.
If you've attended a Glenbrook Payments Boot Camp in the last couple of years, you know RTP and Zelle have some overlapping capabilities. Zelle, however, is targeted at P2P and C2B uses cases. RTP is a set of payment rails open to whatever use cases come along. In the short term, think B2B and payroll but there's no inherent limit to where it can go. Just don't expect it to take over POS payments any time soon. The UK's Faster Payments rails have operated for a decade and have barely touched merchant POS payments.
Another fact boot camp attendees know is that there are two ACH operators in the US: The Clearing House and the Fed. The Fed is now floating the idea of operating an RTP analog of its own. Smaller Fish may be glad to see the Fed operate an alternate system. We'll touch on that more later but the Fed will have a lot of selling to do because, at the very least, adding a new set of rails requires a lot of integration effort by financial institutions and their processors.
And I thought the U.S. payments landscape was settling down. Hah!
Thu, 18 October 2018
The payment industry’s responses to ongoing payment security are many. We have procedural approaches and technical ones. For example, we are requiring merchants to attest to their compliance with PCI security standards that themselves include procedural requirements.
Technical solutions are also called out by PCI and are, of course, being applied across the ecosystem. Encryption of payment data in flight is one approach. In the physical POS world, semi-integrated POS terminals connect directly to the acquirer’s front end instead of passing card transaction data back through the merchant’s workstation and enterprise system.
An important technique, and the topic of this discussion, is tokenization.
Tokenization is an ancient security technique. In the broadest sense, a token is just a dummy representation of something of higher value.
In cards, that means the replacement of a PAN with a number or even an alphanumeric value that represents the underlying PAN. The mapping between the two is stored in a vault with the owner restricting access to that vault. If a hacker gets ahold of a token value, it’s useless. It’s a value that, to the payments ecosystem, is gibberish.
Tokenization is used in pull payment systems where payment credentials are given to the payee by the payer so that the payee has the information necessary to go get the money. Think card numbers or the routing and account numbers on a check.
In card payments, there are two forms of tokenization: merchant and issuer tokenization. Merchant tokenization has been around for more than a decade. A response to PCI, merchants generally outsource that token vault to a third party so they no longer store PANs themselves. When the merchant needs to do a lookup or initiate another payment, the merchant sends the token to the upstream service provider who then looks up the PAN and sends it off for authorization by the acquirer.
That’s been around for awhile.
The newer innovation is what we call issuer tokens - token values that are at the heart of Apple Pay, Google Pay, Samsung Pay and more. These token values are real card numbers, issued by your bank, but unlike a PAN that can be used to initiate a payment everywhere, issuer tokens are expected to come, for example, from specific devices or merchants.
Every card in your Apple Pay wallet is represented by an issuer token and whenever that token is presented for authorization, data about where it’s coming from is sent along too. If the token is sent from another device, for example the one the hacker has, authorization will fail.
This approach is totally compatible with the current card payment system. No changes are needed at the merchant or the acquirer and minimal ones at the issuer.
Glenbrook will be conducting an Insight Webinar on December 13 called Tokenization Fundamentals. Russ Jones will conduct that webinar.
In this Payments on Fire podcast, George talks with Russ about issuer tokenization, its role in the Pays (Apple Pay, Google Pay, Samsung Pay), in e-commerce, and the need for new entities in the payments ecosystem to support tokenization. This gets complicated. There's now the need for token gateways.
Take a listen to the podcast and then sign-up for the webinar. Use the code POF80 to take 10% off the registration price.
Fri, 5 October 2018
In the US, there’s the automatic assumption that payment cards and perhaps PayPal are the way to pay online. But if you’re an ecommerce merchant trying to sell in the Netherlands, you’d better support the domestic system known as iDeal.
Connectivity into domestic payment systems is an important and complex issue. There are over 150 such systems across dozens of countries around the world. While not all are important to a given merchant, most are important to the acquirers and payment service providers serving ecommerce merchants.
Join George and Steve Villegas, VP Partner Management and Head of US Office, of London-based PPRO Group, a company that provides white label connectivity to these domestic systems by serving acquirers and PSPs alike.