Over the past few weeks I’ve had a chance to talk about the prospects for faster payments in the U.S. with representatives from both The Clearing House and the Fed. Both groups, as I’m sure you know, are actively working the space: the Fed with its ongoing Payments Systems Improvement initiative, now with a number of task forces in formation, and The Clearing House with its intention, announced last October, to “build the rails”.
Frankly, I was pretty skeptical last fall. I was worried that The Clearing House banks would be too concerned about cannibalization of wire transfer revenue to move quickly on the build, and I was disappointed that the Fed had backed away from being the direct provider: the “son of Fedwire” option.
But I’ve changed my mind. It sounds like the board of The Clearing House (the CEO’s of some of the biggest banks in the country) is solidly behind the initiative to build, and eager groups are at work on the design process. The Fed’s task forces are a major, well organized initiative, which may end up with the Fed playing a role in some aspect of faster payments operations, or rules – or may just create some pressure to keep The Clearing House (as well as all of the myriad other players – Fiserv, FIS, PayPal, Dwolla, Square et. al) focused on the goals: what I think of as “faster, better, cheaper” payments. (Btw, “better” includes “more secure.”)
Today I want to express my enthusiasm about these developments, beam encouragement at the industry, and advocate for a few additional points that I think are important in the design phase.
- Common Brand– with some 240 million adults and 14,000 or so financial institutions, we need some common terminology so that the phrase “I’ll send you the money by ….” makes sense. This will require individual solution providers to add a common term to their own proprietary brand: “Send money with fastpay (common brand) using your superwallet (proprietary brand)”. Everybody needs to be grown-up about this, and realize that a common term will help the end-users (who, without exception, they claim to care about) more than will insisting on the use of their brand only.
- Flexible Directories– these are going to be “push” payments, so the sender of money needs to know the address of the receiving party. No one wants to remember (or even know) their counterparty’s bank account or credit card information, so some form of directory is going to be needed. My point here is that we should bring some sophistication to the design of this component. This is 2015, not 1995, so we aren’t limited to a flat, “dumb” directory mapping account numbers to telephone numbers, for example. We could instead design a distributed directory that encompasses many different potential “alias” form factors – some controlled by a consumer (such as a phone number), others controlled by a biller, etc. The design could be structured to deliberately encompass existing directories at closed-loop solution providers, for example.
Significantly, this should not be a point of commercial control – it should be within the “zone of collaboration” for all solution providers.
And no, this isn’t the same thing as tokenization – although it is frequently confused with it. Issuer tokenization is primarily for “pull” payments, where you want to hide your “real” account number from the pulling party or wallet, so it isn’t compromised or stolen. A directory is for “push” payments, where you want to design an alias that is both easy to remember and safe to use. So similar – and some of the same concepts may be used – but also many differences.
One idea related to directories that I think is very good is the concept of a “pay code” of some sort – an alias that you give people who you want to receive payment from. Not your phone number – after all, you do change that from time to time, and you probably only have one phone number. You could have multiple “pay codes”, for different reasons – all mapping to various accounts. Banks have tried this in the past with the unsuccessful “UPIC” project. Recently, Square introduced something like this with their $CashTag – a good idea, but limited to users of Square Cash. Let’s refresh the thinking on this, and do it right – for all parties using the new system.
My bottom line here? Let’s not do a simple, “dumb” directory. Let’s take advantage of current technologies and build something sleek and simple – and capable of many things.
- Bi-Directional (and Optional) Interchange – a similar sophistication is going to be needed around interchange in the new system. After all, like all “payments rails”, this system is going to be used for multiple different applications (P2P, B2B, bill payment, purchases, etc. etc.). Some applications are going to need interchange going from sending bank to receiving bank. Other applications are going to need interchange going from receiving bank to sending bank. Yet others will need no interchange at all. Let’s make sure the design of the system anticipates these complexities.
- Ubiquity – finally, as the “user requirements” teams form and debate, let’s keep in mind one simple requirement – ubiquity. Let’s have a system that allows anyone with a bank account to pay anyone else with a bank account – on the same terms, and at the same time. After all checks do it, ACH does it, debit cards do it – surely we want the new thing to be at least as good as the old things? And then, maybe we could think about it allowing payment from anyone with a payment account (not just in a bank!) to transfer money to anyone else with a payment account?
That’s all – just a few things for the teams to think about!
As always, I welcome your comments.
This post was written by Glenbrook’s Carol Coye Benson.
