A simple explanation of how Apple Pay works (probably): It’s all about tokenization

Forget contactless point-of-payment… that’s a solved problem. Apple’s use of tokenization is the interesting part

[USUAL DISCLAIMER: I have no inside info, these are personal views]

I’ve been using a beta version of ApplePay on my iPhone 4 for some time now…

ApplePayBeta

My very old, but very effective, Barclaycard contactless PayTag, stuck to my iPhone 4

The interesting question is how Apple chose to embed the card details inside the phone

To understand why, we have to rewind to March, when something curious happened: a body called “EMVCo” released a technical specification document for something called “tokenization”.

It was curious because it seemed to solve a problem that was already being solved by other players in the card industry. Make no mistake, however: the problem is a big one. Here’s what I mean.

I’ve written extensively about how Payment Cards implement the “pull model”.  When you want to pay for something, you hand over your card details to the merchant and then hope that those details don’t get into the wrong hands as they pass from merchant to their acquirer to the switch and finally to the bank that issued the card in the first place.

PushPull

In particular, the big problem is what happens when companies with millions of cards on file get hacked. Think of major online retailers who save your card details for you. It’s very convenient for you but it only works because they’ve stored your card details on their servers. If they get hacked, then millions of people are at risk of theft and card issuers will have to reissue millions of new cards. It’s a huge pain.

PushPull2

When you allow a merchant to keep your card details on file, you have to trust all the actors in the blue oval not to mess up…

However, there’s a really cool thing you can do to make this system much safer. It’s called tokenization. Here’s the idea:

  • When you enter your card details on a merchant’s website for the first time and tick the “save my details for next time” button, the merchant doesn’t store your card details right way.
  • Instead, they send the details to their merchant acquirer – e.g. Elavon – and ask them to issue a token.
  • The acquirer creates a random number that might look like a credit card number in some cases – the token – and returns it to the merchant.
  • The acquirer records all this information in its own database (i.e. the real card details, the token they issued and which merchant they issued the token to, etc).
  • The merchant stores only the token in their database, not the real card number.

Now, next time you try to buy something from that merchant, they send the token they’ve stored to the acquirer. The acquirer checks that the token is valid and that it came from the right merchant. And, if so, they convert it back to the real card number and process the transaction as normal.

The really important point here is that we no longer really care as much about the merchant’s security. If they get hacked, it’s not as much of a problem: the tokens are useless to anybody else. The acquirer will only accept them if they’re presented by the original merchant. If the hacker tries to use them somewhere else, they simply won’t work.

Excellent! A really simple system that dramatically reduces the risk of fraud and lowers risk and cost for merchants. You can think of it as if the “circle of trust” has been shrunk:

PushPull3

If merchants use tokenization services, the implications if they get hacked are far less serious. (TSP stands for “Token Service Provider”)

And this is nothing new. Acquirers have offered this service for ages for merchants who wanted to use it.

Great. Problem solved?

Not so quick….

Now think about Apple Pay and think about the challenges Apple faced in getting this to work.

Here’s how contactless payments are supposed to work when you pay for goods in store: the cashier rings up the price and activates the contactless pad so you can pay. You tap your contactless card and you’re done. This piece is completely normal: anybody with a contactless (“PayWave” or “PayPass”) card can do that today. It’s what I’ve done with the PayTag on my iPhone 4 for ages.

But how do you get a phone to pretend to be a contactless card? Well that’s a solved problem too. Android devices have done it in various ways for years, for example.

So what’s the problem? The answer is: security. Sure… you can put somebody’s card details into the “Secure Element” of a phone (or do something clever with Host Card Emulation) but if you’re putting the real card number in there then you face all the same risks a merchant faces… if somebody were to figure out how to hack into your system, you’ve got a big problem on your hands… And in Apple’s case, imagine if almost 1 billion payment cards were compromised!

So it would be much safer if you stored a token on the phone, rather than the card details themselves. That way, if the system is broken, you can just invalidate all the Apple tokens and you’re done.

But there’s a really subtle problem

How does a firm like Apple get the tokens? Remember: they want to emulate a contactless card so that the customer can use the phone to pay at a merchant. You don’t know which merchant acquirer any given merchant uses so an acquirer-specific token is useless!

So Apple can’t use the merchant acquirer services to get its tokens… imagine it put a First Data token on its phones. What happens if you try to pay for something at a merchant who uses Elavon? It isn’t going to work…

And this is where the EMVCo spec comes in. In short, the EMVCo spec proposes is that tokenization be standardized and it implies strongly that it should be the schemes (or maybe issuers) who perform the work, not the acquirers.

Effectively, they’re proposing the circle of trust be tightened even further:

PushPull4

I scratched my head at first… apart from perhaps being a power grab, why would anybody bother change this simple model?

The answer was on page 26, section 3.8 and the introduction of the idea of a “token requestor”. What the EMVCo spec highlighted – and what I missed at the time – was that it isn’t only merchants who might want to create tokens… other players might need to as well… players like telcos and Apple:

“Payment Token Requestors may be traditional participants within the payments industry or newly emerging participants. Potential Token Requestors include, but are not limited to Card-on-file Merchants, Acquirers, Acquirer Processors, and payment gateways on behalf of Merchants, Payment enablers, such as original equipment manufacturer (OEM) device manufacturers, Digital wallet providers, Card Issuers”

(EMVCo Tokenisation Spec, page 26-27, my emphasis)

Of course!

Imagine you were trying to build something like Apple Pay. This is exactly what you would need. You’re faced with consumers with cards from thousands of issuers and you want to create tokens that can be processed by merchants who use one of tens of acquirers.

You need a system that gives you a token that all acquirers can process and which the schemes can route to the right issuers… it makes sense that it be the schemes who provide such a services. Indeed, Visa Inc have written about their service here.

And so I think that’s what’s going on. Apple is acting as a “Token Requestor” in the EMVCo model. When you enter your card details or take a picture of your card with your iPhone 6, Apple will call the Token Service for the appropriate network – let’s assume Visa. Visa will check the details (maybe your postal code, CVV2, etc) and perhaps authorize with the issuer.

And Visa will then issue Apple with a token. This token will only work for contactless payments and it will be associated with Apple so it can be revoked in the event of a problem. But it will look just like an ordinary card number so acquirers will be able to process it without even realizing it’s a token.

And it’s this token that will be stored on the phone’s secure element and passed to merchants every time you use it.   So, in many ways, Apple Pay could turn out to be astonishingly standard-compliant.

In summary, my take on the interesting aspects of the Apple Pay announcement are:

  • It’s looks like a really nice use of the EMVCo “Token Requestor” concept
  • It relies on schemes having Token Service Providers up and running so don’t expect it to roll out everywhere, for all schemes, any time soon.
  • It’s surprisingly vanilla.
  • It’s conceivable that Apple is taking zero cut from any of this. They’re certainly not in the transaction flow in any meaningful way
  • But notice how much leverage it gives them over issuers. It would be easy to refuse to include an issuer’s cards on the platform unless the issuer pays up. That has the interesting property that deals could be done on a case-by-case basis and different issuers may have different deals.

 

This is, of course, just my analysis from public information. I have no inside knowledge and I could be completely wrong. In particular, I’m struggling to reconcile my analysis with some claims that Apple Pay will use a different token for every purchase. I don’t understand how that would work, unless we assume the phone is online at point of purchase? Anybody know for sure? Am I way off the mark?

A simple explanation of fees in the payment card industry

I wrote a piece last month explaining how the payment card industry works.  I talked about the various actors (acquirers, issuers, schemes, merchants, etc) and pointed out how weird it is that everybody knows the Mastercard and Visa brand names yet nobody actually has a relationship with them. One of the questions I didn’t address there was fees.  Who makes all the money? Why does it seem so expensive?

Let’s start with the standard four-party model: Merchants, Acquirers, Issuers and Schemes:

Four Party Model Fees 1

The four-party model: Merchants obtain card processing services from Acquirers, who route transactions via Schemes to Issuers, who debit Consumers’ accounts.

A Worked Example

The key point is that one firm from each category is going to be involved in every payment card transaction.  So it’s interesting to ask: how much do they get paid?

Let’s take a concrete example and work it through.  Bear in mind: this is just an example. As you’ll see, there are almost infinite variations and some merchants will pay fees considerably higher than the ones I discuss below.  Also, note: this information all comes from public sources.  I use company names below for clarity but I have no private insight or information into their fee structures

The Scenario

Let’s imagine I’m using a Visa Debit card, issued by a US bank (let’s say Bank of America) to buy $100 of goods from an online retailer.   What happens?  From my perspective, of course, it’s obvious: I’m paying $100!

Four Party Model Fees 2

Imagine I am using my Visa Debit Card, issued by Bank of America to pay for $100 goods from an online retailer.

The Merchant’s Perspective: The Merchant Discount Fee

What does the merchant see?  Well, the merchant will have a contract with an acquirer.  What does that look like?  Let’s take an example.  Costco have a page on their website that refers small merchants to Elavon for acquiring services.  Let’s use the pricing displayed on that page for Online transactions:

1.99% plus 25c per transaction (plus some other recurring/monthly fees, etc)

Many readers will be thinking that seems low but let’s go with it for now.

So, for our $100 transaction, we can calculate how much money the merchant will actually receive from Elavon/Costco:

  • Transaction value: $100
  • Elavon/Costco takes 1.99% + 25c = $2.24. This is often called the “merchant discount fee
  • So merchant gets $97.76

So our picture now looks like the one below:

Four Party Model Fees 3

Merchant receives $97.76 from the $100 transaction. Elavon gets $2.24.  But how is the $2.24 distributed between the acquirer, issuer and scheme?

The Issuer’s Perspective: The Interchange Fee

So we know how much money the merchant has paid to the “credit card industry”. But how is that money allocated between all the participants?   Visa Inc has a very helpful document on their website, which tells us part of the story: Visa U.S.A. Interchange Reimbursement Fees.

The key word here is “Interchange”.  Interchange is the fee that gets paid to whoever issued the card – and it’s set by the scheme (Visa in this case).   You’ll see in that document that this is not straightforward… there are pages and pages of rates:  the interchange fees vary based on whether the card was present or not – and on the type of good or service being bought, whether it was a debit or credit card, whether it was a corporate card, whether it was an international transaction and lots of other criteria…

So let’s just pick a simple example.  We’ll go with page 2 – “CPS/e-Commerce Basic, Debit” (Card not present).

Aside: CPS means that the merchant has complied with various Visa rules (such as validating customer address to reduce fraud risk, etc) and has thus qualified for a low cost option.  

So the issuer is entitled to 1.65% + 15c

  • Transaction value: $100
  • Issuer receives 1.65% + 15c = $1.80.  This is the interchange fee
  • So issuer owes $98.20 to the other participants (Visa, Elavon and the Merchant)

And we already know that the merchant only gets $97.76 of that money (their merchant discount fee was $2.24, remember?).  So that means there is 44c left to share between Visa and Elavon.

The diagram below shows the current state of the calculation:

Four Party Model Fees 4

Interchange Fee (what the issuer gets) is $1.80

So how is the remaining 44c allocated?

We’ve assumed the switch is Visa so we need to know much they charge.  CardFellow.com has a good explanation.

We’ve assumed a Visa Debit card so, according to that site, Visa’s fee, which we call the “Assessment” is 0.11%.   There is a menu of other charges that might apply but we’ve assumed this is a low-risk “CPS” transaction so we’ll assume none of them apply.  (In reality, the 1.55c “Acquirer Processing Fee” probably applies)

  • Transaction value: $100
  • Visa assessment is 0.11% so Visa charges 11c. 
  • So there is $98.09 to pass on to the acquirer.

And if there is $98.09 to pass on to the acquirer and we know that the merchant receives $97.76, that must mean there is 33c left for Elavon.

So there we have it… in this VERY SIMPLE, highly contrived – and probably unrepresentative – example, we end up with the result in the diagram below:

  • Consumer pays $100
  • Issuer receives $1.80
  • Visa receives $0.11
  • Acquirer receives $0.33
  • Merchant receives $97.76 – overall fee $2.24

Four Party Model Fees 6

Final picture showing how the merchant’s $2.24 fee is allocated

As I’ve stressed above, this is just a simple example but it shows two key points:

1) It is the issuer who receives the bulk of the fees (this is, in part, how they fund their loyalty schemes, etc)

2) The schemes actually earn the least, per transaction, of any of the participants.  This underlines, again, how powerful their business model is:  by being at the centre of a very sticky network, they can earn a lot of money overall by charging very low per-transaction fees.   [Edit 2013-08-10 10:35 : it’s also worth noting that the acquirers and schemes have pretty much fixed-cost infrastructures – unlike issuers, who need to hire customer service and debt collection staff in proportion to number of cards issued. So the schemes and acquirers also benefit disproportionately from rising volumes.  So: low fees for schemes/acquirers for sure… but HUGE volume is what enables them to make big profits]

[Note: I use blog posts like this to help clarify my own thinking and understanding – as well as to share knowledge…  and there are one or two pieces here where I’m not 100% confident I got it totally correct… so please do tell me where I’m wrong if you spot something]

[Update 2014-08-09 18:47 Minor typos and replaced last diagram]

Why the payment card system works the way it does – and why Bitcoin isn’t going to replace it any time soon

The Payment Card Industry’s weird business model is a work of genius

Regular readers will know that I am extremely optimistic about the long-term potential of Bitcoin and cryptocurrency technology to revolutionise the financial system. But that doesn’t mean I think they will overturn all aspects of the system.

In particular, I am skeptical of claims that Bitcoin will have a meaningful impact on retail payments and break the stranglehold of the payment card companies.

Of course, many people disagree with me. Articles such as this one from last year are typical of the genre: “credit card companies” are accused of charging obscenely high fees, hindering innovation and being ripe for disruption.

IMG_1600

Payment Cards fees might seem expensive but does it mean they are vulnerable to disruption?

Now, it’s true that the fees do seem expensive at first glance but, as David Evans has argued, it’s not obvious that the Bitcoin payment processors are really that much cheaper, once you take into account their spreads and the costs of getting into and out of Bitcoin at each end.

But the main reason I think the incumbents are in such a strong position is because the industry has extremely strong network effects, which leads to formidable barriers to entry. Would-be Bitcoin entrepreneurs need to understand this structure if they are to succeed.

The Payment Card Industry is marvellous and weird at the same time

When you step back and think about it, the modern payment card industry is a marvel – an underappreciated, underrated miracle of contemporary commerce: you can travel to any corner of the earth, armed only with a piece of plastic bearing the Visa or Mastercard logo. It’s a minor miracle.

But when you look at the businesses of the major card brands, they turn out to be really, really strange companies. They simply don’t do what most of us think they do.

Take a card out of your pocket… chances are, it will be a Visa or Mastercard, or maybe UnionPay if you’re one of my Chinese readers. Let’s assume it’s a Visa card for now. And we’ll worry about American Express later, because they’re different to all the rest.

Here’s one of my Visa cards again:

IMG_1600

A Visa debit card, issued by first direct bank.

Notice something strange. There are two brands on the card. There is the Visa logo and there is one for first direct, the division of HSBC with whom I hold my current account.   Most other consumer products don’t have two firms’ logos on them. Something strange is going on.

Now, it it was first direct that issued the card to me, not Visa.

It is first direct’s website I visit to see my balance, not Visa’s

And it’s first direct I would call if something went wrong, not Visa.

I don’t have any relationship with Visa at all.

There’s no Visa call centre I can call if I have a problem with my card and there’s no Visa app on my phone.  This is strange: a hugely powerful global brand and yet the billions of consumers who use it don’t have a relationship with them.

It gets stranger. Another little-known fact is that no retailer anywhere in the world has a relationship with Visa either!  So we have one of the world’s most recognizable brands and nobody who uses their “product” has any relationship with them.

It’s worth thinking through why this might be and why it is such a powerful model.

How would you build a credit card system if you were doing it from scratch?

Imagine you run a bank in a world before credit cards.   Wouldn’t it be great if your customers could go to local shops and “charge” their purchases to an account that you hold for them?   You could make money offering credit to the customers and make some more money charging the merchants for providing this service.

This is what Bank of America did in California in the 1950s. They issued credit cards to lots of their customers in various cities and signed up local retailers to accept them. Great – the payment card industry was born! You could think of the model looking something like this:

Cards Picture 1

A simple card scheme: a bank issues cards to its customers and reimburses local merchants who accept those cards

But this model has two really unfortunate problems:

  • Your competitors are going to copy this and you’ll soon have schemes like this popping up all over the country, all run by different banks, on different systems, racing to sign up consumers and merchants onto their product
  • Your customers will travel. And they will be very upset when they discover they can’t use your card in a merchant who only takes a different bank’s cards

You would end up with the situation in the diagram below: a merchant who banked with Bank B wouldn’t accept cards issued by Bank A. Why would they? They had no relationship with Bank A and who’s to say cards from Bank A would even work with their machines?!

Cards Picture 2

Why would cards issued by Bank A be accepted by a merchant who uses Bank B if Bank A and Bank B operate competing schemes?

If you were running one of the banks, how might you respond to this problem?

One answer might be to view this as an arms race: perhaps the best strategy is for banks to enter an all-out war… sign up as many merchants as they can… sign up as many customers as they can and bet that you’ll be the last firm standing when the industry shakes out. Obvious problem: it would be ruinously expensive and what happens if it ends in stalemate? You still have the same problem.

But there’s another option… what if you cut deals with other banks: agree for them to accept your cards at their merchants in exchange for you accepting their cards at your merchants. This sounds quite promising but… obvious problem: how on earth would the merchant handle this? They’d need a huge book by every till that listed precisely which banks they could accept card payments from and which ones weren’t allowed. It would be chaos… But perhaps it points the way

A flash of insight – who are you really competing with?

Let’s recap: you’re a bank executive trying to build a payment card business. But your competitors are all trying to do the same and it’s going to end in tears: you’ll confuse the merchants with hundreds of different card types or you’ll go bankrupt trying to be “last man standing”.

It feels like having other banks accept your cards at their merchants would be good… but how to make it work?

And this is where a flash of insight changed the world.

Somebody realized that the cards “business” was actually two businesses.

The first business is all about offering credit to your customers, managing their accounts and processing their payments. We could call this card issuing.

And the second business is all about enabling merchants to accept card payments and get reimbursed. We could call this merchant acquiring.


 

Aside: we call it “acquiring” because it’s helpful to model the card payment as a receivable that the processor purchases (acquires) from the merchant at a small discount, which you can think of as the processing fee.


This is the key point: issuing and acquiring are totally different businesses which don’t compete with each other.

Sure… all the issuers compete with each other.

And all the acquirers compete with each other.

But the issuers don’t compete with the acquirers.

Indeed, they have a really strong incentive to co-operate… the issuers want all the acquirers to accept their cards… and the acquirers want to offer their merchants the ability to accept as many cards as possible.

So let’s imagine a group of issuers teamed up with a group of acquirers. And imagine they agreed that the acquirers would all process the cards of all the issuers in the group: every issuer’s card would be accepted by every acquirer.   They could use this forum to hammer out some standards: they would agree a common way to process cards, timescales for reimbursement, rules for what happens if something goes wrong… they’d define a “scheme”.

Now… this scheme would need two things: consumer recognition and merchant recognition. Consumers would need to know their card would be accepted at a participating merchant. And participating merchants would need to know a given card was part of the scheme.

So we need a brand. This brand would be something you could put on the cards and place in the shop window. It is how a merchant would know an issuer’s card was part of this scheme and it is how card holders would know a merchant was able to accept cards from that scheme.

One of these schemes is, of course, Visa. Another is Mastercard. And so on. And this is why cards carry two brands…. One to identify the issuer and one to identify the scheme.

In this way, the card schemes have created a system that allows merchants, who only have a relationship with their own bank, to accept payment cards issued by hundreds of other banks, without having to have any relationship with those banks at all.   The only thing that matters to them is that the issuer’s card is issued on the relevant scheme.

And this model has really strong network effects… the more issuers and acquirers in the scheme, the more useful the scheme is to card holders and merchants. It’s self-reinforcing.

Talk is cheap… how does it work in practice?

OK. So we have a paper agreement that says an acquiring bank will accept any valid transaction made with a Visa-badged card.   But how? How do they get approval from the issuer for the transaction? How do they get reimbursed? How does it work in reality?

Do all members of a scheme have to have a relationship with every other member so they can route the transaction to them for payment? That would be expensive and error-prone.

So this is where the scheme re-enters the picture.   In addition to maintaining a powerful brand and setting the rules, they also run a switch: the merchant acquirers send all their Visa transactions to Visa itself… and Visa then forwards them on to the appropriate issuer.   Similarly for Mastercard and the other schemes.

So we end up with a hub-and-spoke model… with Visa at the centre. (And Mastercard and Union Pay and so forth).

Cards Picture 3

Issuers and Acquirers are members of a “scheme”, which sets the rules and acts as a central “switch” to route transactions. It means merchants with one bank can accept payments from customers of another bank, without having to maintain bilateral relationships

So now we can see why card schemes are so successful: their globally-recognised brands create networks that anybody aspiring to issue or process cards need to be part of. It’s a self-reinforcing virtuous circle that is extremely hard to disrupt

And this is why Visa’s “customers” are the issuing and acquiring banks… not end-consumers… Visa exists so that issuers can receive broad acceptance of their cards… and so that merchants can, in turn, offer broad acceptance.

But the schemes depend on consumer recognition – hence why they spend so much money advertising to consumers, even though the consumers are not their customers.

What does this have to do with Bitcoin? Push versus Pull

Notice something really important: this is a pull system… the reason you need all this infrastructure is because your card information has to get all the way from the terminal in the merchant back to the issuer so the issuer can pull the money from your account and send it back to the merchant.

By contrast, Bitcoin is a push system: once you know the merchant’s “account” details, you can just push the payment to them. So why do you need all these intermediaries?

If you were a Bitcoin payment firm trying to break into the retail market, perhaps that’s where you’d start? After all, it’s true that most of the payment card infrastructure simply isn’t needed in the Bitcoin world.

But notice how I set up this story. The infrastructure was the last thing I talked about. For me, the two most important things are:

1)   Global acceptance.

2)   The rulebook

Think about what Visa and Mastercard have achieved: they offer global acceptance and predictable behavior.   Wherever you are in the world, you can be pretty sure somebody will accept your card and you know how it will work and that there is a well-understood process when things go wrong. This offer is powerful. Ask yourself: if you could only take one payment instrument with you on a round-the-world trip, what would it be? If you couldn’t stake a stack of dollar bills, I suspect you’d opt for a credit card.

And this predictability – a consequence of the rulebook – is important: consumers enjoy considerable protections when they use a major payment card. They can dispute transactions and, in some countries, their (credit) card issuer is jointly liable for failures of a merchant. Consumers like to be nannied… even if they have to pay for the privilege!

So for those who aspire to overturn the incumbents, you need a strategy for how you will become the consumer’s “default” or preferred payment mechanism.

American Express has achieved this through a joint strategy of having large corporates mandate its use for business expenses and offering generous loyalty benefits to consumers… they effectively pay their customers to use their cards.

PayPal has achieved it through making the payment experience easier – but note, even here, many PayPal payments are fulfilled by a credit card account!

And this is why I harbor doubts about whether Bitcoin will become a mainstream retail payments mechanism, at least in the major markets… why would a consumer prefer it over their card?  Perhaps the openness and possible resistance to card suspension/censorship will attract sufficient users.  But it’s not obvious.

For me, the opportunity lies elsewhere: high-value payments, smart property and so forth.  But I could, of course, be wrong.  It wouldn’t be the first time…

An aside on history and factual accuracy

I know this account would scandalize a historian but that’s OK: It’s not intended to be historically accurate… the idea is to share intuition on why things are the way they are.

Some of the more important topics I’ve ignored or deliberately simplified include:

  • I’ve not explored the difference between Visa Inc (public company) and Visa Europe (owned by its members)
  • I’ve ignored the “three-party” schemes like American Express.
  • I’ve also ignored fee structures and the importance of interchange.
  • I’ve also not discussed the role of processors… specialist firms who effectively outsource the work of issuers and acquirers
  • Security
  • … and lots more

 

Ripple is hard to understand, but it’s worth making the effort: there’s a deep insight at its core

Ten dollars in your pocket is not the same as ten dollars in the bank and neither are the same as a ten dollar credit on your electric bill or the ten dollars your friend owes you. Ripple is simply a manifestation of this insight.

I spent a couple of hours at the Startupbootcamp Fintechathon last weekend. I was there to share ideas on what types of finance problem are a good fit for block chain solutions – and which ones might be best solved using other techniques.

When I arrived, the audience were deep in videoconference with Ryan Terribilini of Ripple Labs. I thought he did a great job of answering their questions about Ripple and I decided it was time I finally tried to get my head around it.

The conclusion I have come to is that Ripple is built on a really deep insight:

Not all dollar, euro and sterling liabilities are the same.

And Ripple is nothing more than a platform that makes this insight explicit.

Here’s how I finally wrapped my head around Ripple

I wrote a piece last year about how money moves around the banking system. I wrote:

Perhaps the most important thing we need to realise about bank deposits is that they are liabilities. When you pay money into a bank, you don’t really have a deposit… you have lent that money to the bank. They owe it to you.  It becomes one of their liabilities. That’s why we say our accounts are in credit: we have extended credit to the bank.  Similarly, if you are overdrawn and owe money to the bank, that becomes your liability and their asset.

I then explained how the payment system is really little more than a bunch of systems for transferring these obligations around.  Where Ripple encourages us to think more deeply is about whose obligations they are.

Imagine I owe my friend Bob £50 and that we are both customers of Barclays bank. When it’s time for me to pay him back, I instruct a “transfer” online. I tell the bank to reduce what they owe me by £50 and increase what they owe to Bob by £50. The bank remains flat… the only difference is to whom they owe the money.

This is the same story I told in my piece about the payments system.

Setup1

Richard and Bob both trust Barclays as an issuer of pounds. So Richard can pay Bob by transferring the money inside Barclays

But think about just happened:

  • Before the transfer, I owed £50 to Bob.
  • After the transfer, the bank owes £50 to Bob.

Bob still doesn’t have the £50 in his hand… all that’s happened is that somebody else now owes him the money.   But this is just fine for Bob…. He trusted me to owe him the money and he also trusts his bank to owe it to him.

Setup2

Bob previously had a £50 “asset” issued by Richard. Now he has a £50 asset issued by Barclays. Richard’s debt to Bob is settled and Bob is happy.

OK – so that’s obvious, perhaps.

But notice how it only worked because Bob trusted both me and the bank.

And also notice that he doesn’t trust us in the same way.   He’d probably be quite happy to have thousands of pounds in his bank account. I suspect he’d be very uncomfortable lending me more than £50.

Not all dollar, euro or sterling asset deposits are the same!  It matters who issues them.

It is highly likely that Bob prefers to be owed money by his bank than by me. £50 owed by me is not the same as £50 owed by the bank.

And this is the Ripple insight.

This is a really powerful observation

Imagine now that the situation is a little more complicated.  Bob and I are sitting in a café. I don’t have any cash and Bob can’t remember his account details. How am I going to pay him?  A Barclays transfer isn’t going to work.

Out of the corner of my eye, I see that the café sells prepaid debit cards. Excellent! I use my own debit card to buy a £50 prepaid debit card and hand it to Bob.   My debt is settled, right?

Not so fast….

What makes me think Bob would be happy to accept a prepaid debit card from an issuer he’s never heard of? Are they insured? What happens if they go bust before he can spend the cash?

£50 on a prepaid debit card is not the same as £50 in cash or a £50 IOU from a friend or £50 owed by Barclays bank.   And it is Bob’s choice whether to trust that card.

It turns out that Bob doesn’t trust this card… So we have a problem. I don’t have his bank account details and he won’t accept a prepaid debit card. How am I going to pay him?

Conveniently for my story, it just so happens that my friend Carol is sitting at the table next to us. Bob doesn’t know Carol so I introduce them to each other.

It turns out that Carol is trying to buy some goods online and has forgotten to bring her credit card. The goods cost £50 and she just happens to have £50 in cash in her purse. (It really is a most amazing coincidence…)

So the situation is something like the diagram below. We see that I have nothing that Bob will accept as payment but that Carol might be able to help us bridge the gap. (I’ve added some detail to show that each person might trust each issuer to different extents – it’s not a yes or no question)

Setup3

How can Richard pay Bob when there are no issuers of pound sterling that Bob trusts that Richard is able to use?

Here’s what we could do: I could give Carol the prepaid debit card (she needs something she can use online and the £50 balance is well below the £1000 limit that she is willing to trust the card company for) and she can then give the £50 in cash to Bob. Bob is happy to take the cash: he also trusts the Bank of England, the issuer of the notes.

Great: Bob now has £50 issued by somebody he trusts. I’ve managed to pay Bob what I owe him by enlisting the help of a prepaid debit card provider and Carol… even though Bob didn’t trust the prepaid debit card and he doesn’t even know Carol.

Setup4

Richard can pay Bob by “rippling” his transaction through multiple issuers and intermediaries, finding a route of trust that wouldn’t have been possible otherwise.

Yes, yes, I know…. It’s an utterly contrived example.  But it makes the point: not all pounds, dollars and euros are the same. It all depends on the issuer: when we open a bank account in the UK, we’re saying we trust that bank to issue GBP liabilities to us.     When we lend £50 to a friend, we’re saying we trust that friend to issue GBP IOUs. And we all trust different groups of issuers and to different extents.

So how does this relate to Ripple?

The answer is that Ripple is a general purpose ledger and payment network based on the key insight that when you try to pay somebody, it’s only going to work if they end up with an asset that was issued by an issuer they trust.

In our case, Bob trusted me, he trusted Barclays and he trusted the Bank of England. But he didn’t trust the prepaid debit provider and he doesn’t trust Carol – so a £50 balance issued by the prepaid debit card provider was never going to satisfy Bob.

But, because Carol and I both trusted the prepaid debit provider and both Carol and Bob trusted the Bank of England – and Carol actually had some notes issued by the Bank of England in her purse – I was able to settle my debt to Bob by routing it through the prepaid debit card provider and through Carol.

The lesson of all this is that if you’re going to build a system that represents real-world currency balances and make payments between them, you really need to think about who issues those balances.

And once you get this point, the point of Ripple becomes clear:  it’s a way for one person to hold funds issued by issuers he or she trusts – and to pay anybody else by transforming those funds into balances issued by issuers that the recipient trusts.

Sure – there’s more to it than that…. But once you get the idea that any individual participant will only trust balances issued by certain issuers, the whole point and design of the network becomes clear.

But this isn’t really about Richard, Bob and Carol: think about the banks themselves and major corporations

The example in this post feels contrived, because it is.  But imagine you’re a major bank.  You have precisely this problem: you have correspondent banking arrangements around the world.  You have separately capitalised and regulated subsidiaries around the world.  And you need to make payments to people and firms all over the world on behalf of yourself and on behalf of your customers.

You need to keep track of balances issued by hundreds of legal entities around the world and need to instruct transfers and exchanges thousands of times per day.

Today, you do this through correspondent banking arrangements, the SWIFT network and multiple other intermediaries and communication platforms.

If I understand the vision correctly, Ripple sees itself as a universal, distributed ledger for simplifying and rationalising this complicated landscape.

Will it work? Will the banks and major firms adopt it? Who knows. But the underlying insight is deep and it feels like they’ve figured out something that is important.

Postscript: What about Bitcoin?

It amuses me when I see Bitcoin and Ripple discussed in the same context because, for me, they’re completely different.   The core of Bitcoin is all about building a trust-free decentralized transaction ledger for tracking the ownership and transfer of scarce tokens – Bitcoins. And the whole point of Bitcoins is that they are counterparty-risk-free assets: my Bitcoin is not somebody else’s liability.

By contrast, Ripple is all about dealing with assets that are somebody else’s liability. So the focus in Ripple is on representing liabilities issued by identifiable issuers and enabling them to be transferred between individuals on a network.

They share some similarities but they’re not the same thing at all.

A simple explanation of how money moves around the banking system

Twitter went mad last week because somebody had transferred almost $150m in a single Bitcoin transaction. This tweet was typical:

There was much comment about how expensive or difficult this would have been in the regular banking system – and this could well be true.  But it also highlighted another point: in my expecience, almost nobody actually understands how payment systems work.  That is: if you “wire” funds to a supplier or “make a payment” to a friend, how does the money get from your account to theirs? 

In this article, I hope to change this situation by giving a very simple, but hopefully not oversimplified, survey of the landscape.

First, let’s establish some common ground

Perhaps the most important thing we need to realise about bank deposits is that they are liabilities. When you pay money into a bank, you don’t really have a deposit. There isn’t a pot of money sitting somewhere with your name on it. Instead, you have lent that money to the bank. They owe it to you.  It becomes one of their liabilities. That’s why we say our accounts are in credit: we have extended credit to the bank.  Similarly, if you are overdrawn and owe money to the bank, that becomes your liability and their asset.  To understand what is going on when money moves around, it’s important to realise that every account balance can be seen in these two ways.

Paying somebody with an account at the same bank

Let’s start with the easy example. Imagine you’re Alice and you bank with, say, Barclays. You owe £10 to a friend, Bob, who also uses Barclays. Paying Bob is easy: you tell the bank what you want to do, they debit the funds from your account and credit £10 to your friend’s account.  It’s all done electronically on Barclays’ core banking system and it’s all rather simple: no money enters or leaves the bank; it’s just an update to their accounting system.  They owe you £10 less and owe Bob £10 more. It all balances out and  it’s all done inside the bank: we can say that the transaction is “settled” on the books of your bank.  We can represent this graphically below: the only parties involved are you, Bob and Barclays.  (The same analysis, of course, works if you’re a Euro customer of Deutsche Bank or a Dollar customer of Citi, etc)

Single Bank Settlement

But what happens if you need to pay somebody at a different bank?

This is where it get more interesting.  Imagine you need to pay Charlie, who banks with HSBC. Now we have a problem: it’s easy for Barclays to reduce your balance by £10 but how do they persuade HSBC to increase Charlie’s balance by £10?  Why would HSBC be interested in agreeing to owe Charlie more money than they did before?  They’re not a charity! The answer, of course, is that if we want HSBC to owe Charlie a little more, they need to owe somebody else a little less.

Who should this “somebody else” be?  It can’t be Alice: Alice doesn’t have a relationship with HSBC, remember.  By a process of elimination, the only other party around is Barclays. And here is the first “a ha” moment…  what if HSBC held a bank account with Barclays and Barclays held a bank account with HSBC? They could hold balances with each other and adjust them to make everything work out…

Here’s what you could do:

  • Barclays could reduce Alice’s balance by £10
  • Barclays could then add £10 to the account HSBC holds with Barclays
  • Barclays could then send a message to HSBC telling them that they had increased their balance by £10 and would like them, in turn, to increase Charlie’s balance by £10
  • HSBC would receive the message and, safe in the knowledge they had an extra £10 on deposit with Barclays, could increase Charlie’s balance.

It all balances out for Alice and Charlie… Alice has £10 less and Charlie has £10 more.

And it all balances out for Barclays and HSBC.  Previously, Barclays owed £10 to Alice, now it owes £10 to HSBC. Previously, HSBC was flat, now it owes £10 to Charlie and is owed £10 by Barclays.

This model of payment processing (and its more complicated forms) is known as correspondent banking. Graphically, it might look like the diagram below.  This builds on the previous diagram and adds the second commercial bank and highlights that the existence of a correspondent banking arrangement allows them to facilitate payments between their respective customers.

Correspondent Banking

This works pretty well, but it has some problems:

  • Most obviously, it only works if the two banks have a direct relationship with each other. If they don’t, you either can’t make the payment or need to route it through a third (or fourth!) bank until you can complete a path from A to B. This clearly drives up cost and complexity. (Some commentators restrict the use of the term “correspondent banking” to this scenario or scenarios that involve difference currencies but I think it helpful to use the term even for the simpler case)
  • More worryingly, it is also risky. Look at the situation from HSBC’s perspective.  As a result of this payment, their exposure to Barclays has just increased.  In our example, it is only by £10.  But imagine it was £150m and the correspondent wasn’t Barclays but was a smaller, perhaps riskier outfit: HSBC would have a big problem on its hands if that bank went bust.  One way round this is to alter the model slightly: rather than Barclays crediting HSBC’s account, Barclays could ask HSBC to debit the account it maintains for Barclays. That way, large inter-bank balances might not build up. However, there are other issues with that approach and, either way, the interconnectedness inherent in this model is a very real problem.

We’ll work through some of these issues in the following sections.

[Note: this isn’t *actually* what happens today because the systems below are used instead but I think it’s helpful to set up the story this way so we can build up an intuition for what’s going on]

Hang on… why are you making this so complicated? Can’t you just say “SWIFT” and be done with it?

It is common when discussing payment systems to have somebody wave their hands, shout “SWIFT” and believe they’ve settled the debate.  To me, this just highlights that they probably don’t know what they’re talking about 🙂

The SWIFT network exists to allow banks securely to exchange electronic messages with each other. One of the message types supported by the SWIFT network is MT103. The MT103 message enables one bank to instruct another bank to credit the account of one of their customers, debiting the account held by the sending institution with the receiving bank to balance everything out.  You could imagine an MT103 being used to implement the scenario I discussed in the previous section.

So, the effect of a SWIFT MT103 is to “send” money between the two banks but it’s critically important to realise what is going on under the covers: the SWIFT message is merely the instruction: the movement of funds is done by debiting and crediting several accounts at each institution and relies on banks maintaining accounts with each other (either directly or through intermediary banks).  Simply waving one’s hands and shouting “SWIFT” serves to mask this complexity and so impedes understanding.

OK… I get it. But what about ACH and EURO1 and Faster Payments and BACS and CHAPS and FedWire and Target2 and and and????

Slow down…..  Let’s recap first.

We’ve shown that transferring money between two account holders at the same bank is trivial.

We’ve also shown how you can send money between account holders of different banks through a really clever trick: arrange for the banks to hold accounts with each other.

We’ve also discussed how electronic messaging networks like SWIFT can be used to manage the flow of information between banks to make sure these transfers occur quickly, reliably and at modest cost.

But we still have further to go… because there are some big problems: counterparty risk, liquidity and cost.

The two we’ll tackle first are liquidity and cost

We need to address the liquidity and cost problem

First, we need to acknowledge that SWIFT is not cheap. If Barclays had to send a SWIFT message to HSBC every time you wanted to pay £10 to Charlie, you would soon notice some hefty charges on your statement.  But, worse, there’s a much bigger problem: liquidity.

Think about how much money Barclays would need to have tied up at all its correspondent banks every day if the system I outlined above were used in practice. They would need to maintain sizeable balances at all the other banks just in case one of their customers wanted to send money to a recipient at HSBC or Lloyds or Co-op or wherever.  This is cash that could be invested or lent or otherwise put to work.

But there’s a really nice insight we can make:  on balance, it’s probably just as likely that a Barclays customer will be sending money to an HSBC customer as it is that an HSBC customer will be sending money to a Barclays customer on any given day.

So what if we kept track of all the various payments during the day and only settled the balance?

If you adopted this approach, each bank could get away with holding a whole lot less cash on deposit at all its correspondents and they could put their money to work more effectively, driving down their costs and (hopefully) passing on some of it to you.  This thought process motivated the creation of deferred net settlement systems.  In the UK, BACS is such a system and equivalents exist all over the world.  In these systems, messages are not exchanged over SWIFT.  Instead, messages (or files) are sent to a central “clearing” system (such as BACS), which keeps track of all the payments, and then, on some schedule, calculates the net amount owed by each bank to each other.  They then settle amongst themselves (perhaps by transferring money to/from the accounts they hold with each other) or by using the RTGS system described below.

This dramatically cuts down on cost and liquidity demands and adds an extra box to our picture:

Deferred Net Settlement

It’s worth noting that we can also describe the credit card schemes and even PayPal as Deferred Net Settlement systems: they are all characterised by a process of internal aggregation of transactions, with only the net amounts being settled between the major banks.

But this approach also introduces a potentially worse problem: you have lost settlement finality. You might issue your payment instruction in the morning but the receiving bank doesn’t receive the (net) funds until later.  The receiving bank therefore has to wait until they receive the (net) settlement, just in case the sending bank goes bust in the interim: it would be imprudent to release funds to the receiving customer before then.  This introduces a delay.

The alternative would be to take the risk but reverse the transaction in the event of a problem – but then the settlement couldn’t in any way  be considered “final” and so the recipient couldn’t rely on the funds until later in any case.

Can we achieve both Settlement Finality and Zero Counterparty Risk?

This is where the final piece of the jigsaw fits in.    None of the approaches we’ve outlined so far are really acceptable for situations when you need to be absolutely sure the payment will be made quickly and can’t be reversed, even if the sending bank subsequently goes bust.  You really, really need this assurance, for example, if you’re going to build a securities settlement system: nobody is going to release $150m of bonds or shares if there’s a chance the $150m won’t settle or could be reversed!

What is needed is a system like the first one we outlined (Alice pays Bob at the same bank) – because it’s really quick – but which works when more than one bank is involved.  The multilateral bank-bank system outlined above sort-of works but gets really tricky when the amounts involved get big and when there’s the possibility that one or other of them could go bust.

If only the banks could all hold accounts with a bank that cannot itself go bust… some sort of bank that sat in the middle of the system.  We could give it a name.  We could call it a central bank!

And this thought process motivates the idea of a Real-Time Gross Settlement system.

If the major banks in a country all hold accounts with the central bank then they can move money between themselves simply by instructing the central bank to debit one account and credit the other.  And that’s what CHAPS, FedWire and Target 2 exist to do, for the Pound, Dollar and Euro, respectively. They are  systems that allow real-time movements of funds between accounts held by banks at their respective central bank.

  • Real Time – happens instantly.
  • Gross – no netting (otherwise it couldn’t be instant)
  • Settlement – with finality; no reversals

This completes our picture:

RTGS

I thought this article had something to do with Bitcoin?

Well done for getting this far.  Now we have a question: can we place Bitcoin on this model?

My take is that the Bitcoin network most closely resembles a Real-Time Gross Settlement system. There is no netting, there are (clearly) no correspondent banking relationships and we have settlement, gross, with finality.

But the interesting thing about today’s “traditional” financial landscape is that most retail transactions are not performed over the RTGS. For example, person-to-person electronic payments in the UK go over the Faster Payments system, which settles net several times per day, not instantly.   Why is this?  I would argue it is primarily because FPS is (almost) free, whereas CHAPS payments cost about £25.  Most consumers probably would use an RTGS if it were just as convenient and just as cheap.

So the unanswered question in my mind is: will the Bitcoin payment network end up resembling a traditional RTGS, only handling high-value transfers?  Or will advances in the core network (block size limits, micropayment channels, etc) occur quickly enough to keep up with increasing transaction volumes in order to allow it to remain an affordable system both for large- and low-value payments?

My take is that the jury is still out: I am convinced that Bitcoin will change the world but I’m altogether less convinced that we’ll end up in a world where every Bitcoin transaction is “cleared” over the Blockchain.

[Updated several times on 25 November 2013 to correct minor errors and to add the link to my Finextra video at the end]

Where is the power in the mobile payments ecosystem?

I am a member of the UK and Ireland affiliate to the IBM Academy of Technology.  We held our Autumn symposium in Birmingham a few weeks ago and I had the pleasure of hearing about Droplet and meeting one of their management team, David Roberts.

Droplet is a mobile payment system that allows individual to pay merchants using a very simple app, with their unique selling point appearing to be that no other infrastructure is required (no POS terminals, no card readers, …) and that neither the payer nor the recipient is charged for the service.   I’ll leave this aspect of their business model to one side for now as I’m not sure if the details have been publicly disclosed (and it’s not what motivated me to write this post in any case).  What interested me was that it ticks my “push rather than pull” button. I discussed why I like this model here and so I’m always interested in those who are implementing it for real.

Right now, they seem to be targetting local retailers (such as my favourite pizza delivery joint) but it made me wonder: what would it take for a system such as this to be adopted by a major retailer? What are the incentives and game-theoretic chains of logic that help us make sense of this question?

Imagine you’re a major retailer. What are your options?

  • You could build your own system – perhaps licensing technology from a startup such as Droplet – maybe integrating it with your loyalty card system.  But you immediately run into a problem: what incentive does any other retailer have to accept it? They’d surely be extremely wary of ceding control to a competitor. So we have to assume this approach would lead to an arms race, with all major retailers launching their own mobile payment systems. The costs would surely be prohibitive and consumers would surely rebel: would you really want to have to load (and configure and remember the PIN) for tens or hundreds of different apps?   In the ensuing shakeout, perhaps a couple of retailers gain dominance… but if you were CEO of a retailer, how much would you be willing to risk on a bet that you’d be one of the winners?  The odds are against you.
  • Alternatively, the retailer could make a bold statement and adopt a system provided by a neutral third party.  Perhaps a major grocer would simply announce that they will start accepting payments over Droplet or Zapp or in partnership with one of the card networks.  The problem here is: why would you gift an endorsement so valuable to an independent company?  You’d surely be tempted to negotiate a sweetheart deal, which would surely leak and you’d be back to square one: nobody else would want to support it.
  • A different approach might be simply to announce acceptance of multiple systems: let a thousands flowers bloom.  But now you have the problem of consumer confusion and staff training. And staff training will be bad enough with only one option. Indeed, I consider it the most significant inhibitor of a move from “pull” to “push” payments.

For these reasons, I’m increasingly convinced that the optimal response for most major retailers is simply to do nothing! Wait. See how the market plays out. Then be a fast follower.  But I’d love to hear somebody make an argument that says I’m wrong…

Lessons from Bitcoin: Push versus Pull

Bitcoin is going to change the world – but not for the reasons we commonly assume. One subtle way in which it will change the world is through its influence on other players in the payment ecosystem.

At the heart of the Bitcoin system is the idea of a transaction: at its simplest, this is a transfer of value from one Bitcoin user to another – a credit transfer, if you like.

Consider what this isn’t. This isn’t a direct debit. It isn’t a credit card authorisation. Nor is it the creation of a debt or a precursor to a subsequent billing cycle.  Is is the closest thing we have in the digital world to a person-to-person cash payment.

In this way, we can think of a Bitcoin payment as analagous to a SEPA Credit Transfer, a UK Faster Payments transaction or, more generally, a wire transfer.   Push, not pull.

Graphically, we could depict this as the consumer pushing value directly to the merchant, just like with cash:

Image

Now, consider how that differs to most other forms of electronic payments in the retail space.  They are, almost invariably, achieved through the use of one or more card schemes.

But think about how they work…

The customer thinks they’re paying.  But, really, they’re not. Instead, when they sign the chitty or enter their PIN, they are initiating a supremely sophisticated choreography of immense complexity.

They are, in reality, authorising the merchant to pull the payment from their account, with the request being routed through several intermediaries.

Graphically, it looks something like this:

Image

This model has its advantages but it also suffers from severe problems: the most obvious of which is that if you’re moving payment authorisations around, you need to be maniacally focussed on security: there’s a reason why PCI-DSS exists.

It’s easy to understand why the system was built the way:  what else would you have done with 1960s technology?  The pull model employed by the card processors is a wonder of the world.  But it’s also an artefact of its time.  Would you design it that way if you were starting from scratch today?  I would contend that a system that doesn’t need PCI-DSS, doesn’t need acquirers, doesn’t need issuers, doesn’t need switches and doesn’t require you to trust any third parties has much to commend it.

For this reason, I use this “Push versus Pull” metaphor as a quick heuristic for evaluating payments startups I come across in my day job…