Yves here. Get a cup of coffee. This is a deep dive into how Bitcoin works from a payment systems perspective, and why the failure of promoters and journalists to look at it in those terms has led them to greatly overestimate its significance.

And since this post is certain to attract first-time readers, particularly those who are involved in Bitcoin-related ventures, who will be intent on challenging Clive’s conclusions, a warning: We have site policies (see the Policies tab above). Read them or you will waste your time. We welcome robust debate. That requires reading the article in full as a minimum requirement. Making comments that are uninformed reactions to the headline, crassly straw man the piece, recycle Power Point bullets from your last presentation, or are otherwise in bad faith will be deleted.

And regular readers: do not feed the trolls. If we have to rip out a comment that breaks site rules, we have to rip out the entire thread or comment nesting will cease to function.

By Clive, an investment technology professional and Japanophile

Have you ever, as I have, watched something on television, read an article in a newspaper or online – or similar – where the topic has been that with which you’re especially knowledgeable about? Perhaps you’re, say, a teacher and the piece has been about education or child development. Or maybe you’re a mechanic and it is a feature on auto maintenance. You might have a hobby, let’s pick painting, and a non-expert is trying to explain what it is to paint.

Whenever I, being in finance, encounter the output of a journalist or – worse – an economist or a politician trying to tell the audience something about a financial matter (particularly if it is my specialism, consumer finance and money transmission) I rarely hear or read the first sentence without encountering an error of such fundamental magnitude that it renders pretty much everything that follows completely wrong. At first, I thought that it was because my knowledge is about an esoteric or complex subject. Finance really isn’t complex, no matter how many attempts are made to make it so, but I speculated that as it wasn’t exactly commonplace then maybe that excused to all-too-frequent inaccuracies I found when it was covered in the general media.

So I began to tell people I knew what I was encountering. They responded in exactly the same way. Educationalists bemoaned how woeful and wrongly reporting of schooling, teaching and the delivery of learning was compared to how it actually happened – as they knew, as a fact, from their own first-hand knowledge. Social workers told me that it appeared when the subject was reported, those doing the reporting seemed to have no concept whatsoever of what a social worker was. The guy who fixed my leaky pipe said that most of what was on television to do with plumbing was rubbish. And so on.

I suppose I should be expecting it. Journalism has descended into – along with a lot of “professions” a generalist skill set. Add in time pressures, often rigorous imperatives on word counts, readability (or using too long words, if it is television) along with the lack of subject matter knowledge and it is hardly surprising we’re drowning in misinformation.

There are a few – a very few – sources of good information. Specialised financial publications can be one such source. But even there, there’s no guarantees. The Financial Times, for instance, is invariably good to excellent. The Economist, however, is so in hoc to vested interests and conventional wisdom, it is not worth bothering with. Outside the niche media, though, if you read or see a feature on some aspect of finance or economics, you’re more likely to come away dumber than when you started. That is some achievement. I’d like to think that we make Naked Capitalism one such source of sufficiently good quality coverage to help begin to redress the balance of so much wrong thinking caused by wrong understandings.

Take “digital” or “crypto” currencies, of which Bitcoin is the best known. I cannot recall a single incidence where Bitcoin has been reported on (either in the general media or in technology-specific outlets – although the FT’s coverage has been, kudos due, excellent) which hasn’t got so muddled and confused about the subject it is trying to communicate to its readers or viewers that it has ended up so inaccurate as to be risible. The usual problems one sees are where the reporter starts off by trying to explain the implications of Bitcoin as a currency (as a Store of Value, in other words) but then in the next paragraph or the next shot goes to a store or makes an on-line purchase using Bitcoin then waffles on about Bitcoin disrupting the banking sector. At this point, I usually take to throwing things because, as I am by this time probably shouting, the journalist started off describing a currency but then changed the subject to a Money Transmission System but didn’t realise these were two completely different things.

Naturally, they usually then proffer some hopelessly muddle-headed conclusion about what new development is “disrupting” which pre-existing conventional arrangements.

When a new technology or innovation is launched or comes to public attention, the mainstream media gets so besotted and beguiled by the novelty aspects of this, it is relatively easy for boosters and hyping by PR hacks or those who hope to profit in some way by the perceived transformative potential of the development to drown out coherent coverage in a din of confusing noise. It is only later, when the inevitability of the so-called transformative change which is supposed to be brought about by this new innovation turns out to be not quite so inevitable after all, that you can start the long process of trying to sort the facts and the reality from the gibberish.

Bitcoin has reached just such a stage. Recent technical issues have exposed design flaws which were present all along but which were initially only theoretical risks to the reliable operation of the crypto currency. Once they happened, they weren’t theoretical any more. As some fairly large buckets of cold water have been thrown on the ardour of those who worship technology-for-the-sake-of-technology, scammers trying to think of their next con trick and well-intentioned people who look for solutions to the problems finance and economics shoves down our throats on a daily basis but are way too eager to latch onto simplistic solutions to complex problems, we can now begin to present coverage of digital (or crypto) currencies based on facts rather than fiction. And as the hopium is wearing off in respect of Bitcoin, we stand less chance of being accused of being reactionary or committing that great thought-crime as far as technology is concerned, of being negative.

The most important misunderstandings which need correcting are what Bitcoin is and what it is not and by itself never could be. To illustrate this, we will now step through three different every-day transactions but we’ll use three different methods to settle them. First, we’ll use cash. Then, we’ll use a conventional credit or debit card. The, finally, we’ll use Bitcoin. For each variation of the common scenario, we’ll detail the impacts of each payment method on money as a Store of Value, Credit Risk and Debt.

If what you’ve learned about Bitcoin has come largely from the mainstream media, the result will probably surprise you. But the real surprise is in examining just how “disruptive” Bitcoin (and similar) are or, to give the ending away, they aren’t. I hate being teased as a reader so I won’t tease readers here. The only thing that is potentially disruptive in the introduction of recent technical developments in the money and payments systems which greatly influence our lives is the threat to move us to a “cashless society”. Everything else – Bitcoin included – is irrelevant by comparison.

Let’s get going.

The Base Scenario: A Customer purchases goods or services from a Merchant. This could be you walking into a store and buying groceries. It may help new readers if they familiarise themselves with some of the terms which will be used below by reading my earlier piece documenting who the various parties are in a transaction which takes place between a buyer (Customer) and seller (Merchant).

Scenario Variant 1: A Cash Transaction

You draw out cash from a Bank or ATM (you did so prior to the transaction in order to have the cash) or another party gave you the cash prior to the transaction in the Scenario as payment for goods or services you provided to the other party. The Merchant does not extend credit to customers and demands payment in full on completion of the transaction. This could be such as in a supermarket does not allow you to leave the store with your groceries without first paying for them.

Table 1:

Key to Symbols:

○：Always

×：Never

△：Sometimes

Table 1 shows what each party to the transaction does as a result of completing that transaction.

You, the Customer doesn’t originate a Store of Value as, unfortunately, you can’t print your own legal tender bank notes or mint your own coins. You never do that, so you get a cross (×) in the “Originates Store of Value” column. But you have them in your possession as you either withdrew them from the Bank or ATM or someone gave you some cash. You can’t initiate a cash transaction unless you hold the cash, so you get a circle (○) in the “Holds Store of Value” column. The grocery store always demands you hand over the cash to pay for your goods so, again, you get a circle (○) in the “Originates Debt” column because as soon as you pack your shopping and move to take it out the store, you’re indebted to store if you want your weekly groceries. But you have the cash, so you can immediately extinguish the debt you owe to the store by handing over the cash. There can be no other outcome. You either abandon your groceries at the checkout and walk away or you want to take your groceries with you, in which case you’ve created a debt that you must then settle with the cash. So you get a circle (○) in the “Extinguishes Debt” column.

The Token here is the cash. The cash doesn’t print itself. So it gets a cross (×) in the “Originates Store of Value” column. But the cash most definitely does act as a store of value so it too gets a circle (○) in the “Holds Store of Value” column. Paying in cash always irrevocably extinguishes a debt. So the cash also gets a circle (○) in the “Extinguishes Debt” column. Once it has been issued, cash which is in a safe or in your wallet does not by itself create a new debt so, unlike you as the Customer wanting to take your groceries away with you, cash gets a cross (×) in the “Originates Debt” column.

The Token Issuer in this Scenario Variant 1 is the Central Bank. Note that only the Token Issuer gets a circle (○) in the “Originates Store of Value” column. They originate a store of value when they print the notes or mint the coins. In doing do, they originate a debt too, because as the issuer of the token (the cash) they indebt themselves when they send the notes and coins into circulation. Hence the circle (○) in the “Originates Debt” column. Central banks do not, routinely, print notes and mint coins then just keep them in a safe. They produce them with the intention to put them into circulation. So they get a circle (○) in the “Transmits Debt” column. They just can’t keep it to themselves! Now we get to the really important bit, the “Extinguishes Debt” column. Note the triangle (△) symbol in that column. The Central Bank can indeed, on occasions, cancel debt. It is outside the scope of this article why and how that occurs. Readers are invited to consider this further after reading this particular feature.

The Token Network is the system by which the tokens (cash in Scenario Variant 1) are issued, circulated and withdrawn by the Token Issuer, which is the Central Bank. Central banks print cash in bulk and distribute it to regional cash management centres. The cash management centres are used by the banks to send surplus currency back to Central Bank if they have taken in more than they need for their day-to-day operational purposes. The largest merchants, such as retailers like Walmart probably interface directly with the Central Banks’ cash management centres too as their huge cash volumes mean it is more efficient to do so than to have to pay their cash takings into their bank. Bulk users of cash currency such as the banks and the mega retailers “buy” and “sell” notes and coins (at par) to the Central Bank. The various circles (○) and a crosses (×) in the Token Network’s columns should hopefully by now be self-explanatory based on what you’ve just read above. Worth a mention, though, are the triangles (△) in “Originates Credit Risk” and “Transmits Credit Risk” columns. The counterparty to the “buying” and “selling” of cash is the Central Bank. Users of cash currency, such as the banks and supergiant retailers, would be required to post unimpeachable quality collateral with the Central Banks’s cash management centre to access the cash clearing facilities. Thus they introduce some element of credit risk. And of course, it is vaguely feasible that the Central Bank could fail (although such a failure would be a politically initiated event) so we cannot accurately enter circles (○) for “never” in these columns. This would be end-of-the-financial-world-as-we-know-it territory though, but keep an eye on these columns in later Scenarios as this is where it will start to get interesting (not, I am sure, that you’re not completely enthralled so far).

The Merchant exactly mirrors you, the Customer, in this particular scenario. If you’re not sure why this should be, review the earlier paragraph explaining the Customer and how you hold and move your Store of Value (your cash) to the Merchant and how you and the Merchant originate then extinguish your debt during the course of your imaginary grocery-buying transaction.

The Merchant Services Provider in Scenario Variant 1 is the party who the Merchant uses to manage their transactions. For transactions settled in cash, the Merchant will over the course of a day’s trading accumulate cash balances (in the grocery store such as in our example, the tills will get filled with cash takings, these will be periodically emptied into the store’s safe but by the end of the week or the day for really busy stores, this will be full too) and that can’t continue indefinitely. Going back millennia, this is a problem which has existed since cash was invented. Merchants accumulate more cash than they need for day-to-day trading. It is either risky or impractical (or both) to keep the cash on the Merchant’s premises. What you need is somewhere you can send it, for safekeeping, until you might need it again. Somewhere like… yes… a bank! For cash transactions, the Merchant Services Provider’s role is to receive the cash balances from the Merchant. The entries in the Table 1 columns for the Merchant Services Provider (the Merchant’s bank) are the same as those of the Token Network (the Central Bank which issues the cash and manages its distribution in their cash management centres). As previously noted, for very large retailers, these can directly access the services of the Central Bank’s cash management centres so it is not surprising they possess the same properties. In this way, you might be able to see that the Central Bank’s cash management centres – an essential part of the Token Network for managing the cash in circulation – are the Central Bank’s “branches”. For smaller retailers, these cannot access the cash management centres directly so have to use a branch of a bank. This again a credit risk so we have the triangles (△) in “Originates Credit Risk” and “Transmits Credit Risk” columns. You always hope, when you pay your cash into your bank branch, that you can get your money out again later. This almost always happens, but banks have been known to fail. As we can never say “never”, triangles (△) are more appropriate than circles (○).

We’ll move onto Scenario Variant 2 (the same transaction settled using a Debit or Credit card) shortly but before leaving Scenario Variant 1 (cash settlement) it is useful to review the various columns in Table 1 and look for outliners. Which columns have lots of circles (○) or crosses (×)?

Only the Token Issuer always Originates Store(s) of Value. In other words, only the Central Bank can print cash or mint coins. And except under the most outlandish of circumstances (which for the purposes of this Scenario Variant 1 would be the failure of the Central Bank or the collapse in the market for the highest collateral used to access facilities at the cash management centre such as U.S. treasuries, events which are so unlikely they are assumed to be impossible here) no party in the transaction has to hold credit risk. If you, the Customer, pay in cash, the Merchant receives the cash and no credit risk is generated or transmitted. If the Merchant pays the cash into their bank who provides cash handling services to the Merchant, the bank incurs no credit risk. If the bank, as a result of acting as a Merchant Services Provider to multiple Merchants ends up with a surplus of cash and deposits it with the Central Bank’s “branch” at the cash management centre, neither the Merchant’s bank nor the Central Bank has to sit on a credit risk because cash is always guaranteed to irrevocably settle a debt on presentation.

Scenario Variant 2: A Debit or Credit Card Transaction

Table 2:

Key to Symbols:

○：Always

×：Never

△：Sometimes

Table 2 shows what each party to the transaction does as a result of completing that transaction. As a reminder, if you’re unfamiliar with any of the descriptions applied to the different parties, documents who the various parties are in a transaction where a card is used for payment.

The Token (your credit or debit card) when presented and used in a transaction which is authorised by the Token Issuer via the Token Network is a Store of Value, albeit a tokenised one. It represents – is a conduit for – the Store of Value.

What is being tokenised in a card payment transaction? Legal tender as specified in the contract between the various parties in the transaction. To go back to the example of you buying groceries in a supermarket, if the supermarket is in the U.S. then the pricing of the goods being purchased is in U.S. dollars so the transaction is denominated – and must be settled – in U.S. dollars too.

Instead of cash being presented at the supermarket checkout and instantly extinguishing the debt which is created between you, the Customer and the supermarket (the Merchant), a set of – invariably nowadays – electronic tokens are passed around the Money Transmission System (made up of the various parties identified in the first column of the table). These tokens are a token of the cash which is, in Scenario Variant 2, no longer being used as settlement.

But here we can now see the consequence of removing cash – which always extinguishes a debt on presentation – and substituting instead tokens representing cash. The settlement of the whole transaction becomes riddled with credit creation, the inevitable credit risk and debt.

Unlike when the customer pays in cash, in a card settlement at the Merchant, all the Merchant gets is a Token – your card – which represents cash. Note that is most definitely is not cash. The Merchant presents this Token to the Merchant Services Provider (usually through some kind of card reader attached to their checkout or a set of fields on a web page where you type your card number and other details). The Merchant Services Provider hands off another Token (see example in Fig. 1) back to the Merchant which is a promise to settle the amount specified in the transaction back to the Merchant at some point in the future. The Merchant Services Provider only generates their Token – known as an “Authorisation Code” often shortened to “Auth Code” – once it itself has received another Token, via Token Network (such as MasterCard or VISA, for example) from the Token Issuer which is your bank, the one whose name is on the card you just used.

Any and all of these parties can – and not infrequently do – renege on the promise to settle their part of the transaction. The Token Issuer (your bank) can refuse to send the funds it said it would send to the Merchant Services Provider for certain pre-defined reasons. For example, you could dispute the transaction and claim that the goods you bought were not what they were represented to be and you are demanding a refund. The Merchant Services Provider can refuse to pay the Merchant, again, for certain specified reasons such as you were contractually obliged to upgrade to a new version of software on your card reader or website but did not do so and they are withholding remitting funds to you until you comply.

And, of course, you yourself, the Customer, might not have the money in your card account to pay for what you’ve just spent in which case, at first glance, the Token Issuer (who gave you your credit or debit card to use as a Token instead of cash in your transactions) is facing a loss. Let’s explore this last situation in more detail.

If you’ve got the funds in your account (maybe you used a debit card and your checking account had funds to cover the cost of item you just bought) then eventually, once all of the parties in Table 2 have completed their steps in the transaction, we’d arrive at the same conclusion just as if you’d withdrawn cash out of the ATM or at the bank and paid for what you bought using that cash.

But what if you “didn’t have the money” – i.e. you paid by a debit card but were overdrawn in your checking account or you used a credit card which you don’t keep a credit balance in the account for? This would result in the most obviously understood form of credit creation: you’d owe your Token Issuer (the bank or credit card company) the money outstanding on the Token (your card account). This is though just the culmination of a sequence of debt creation and extinguishment which can be traced right through the Money Transmission System back to when you were at the supermarket.

Typically, you end up – rightly – being liable for the debt (to the Token Issuer – your bank or credit card company – in the first instance, but you paying them merely allows them to fund the extinguishing of their debt to the Merchant Services Provider who can then in turn get the money to extinguish their debt to the Merchant). But, as the old English proverb puts it, “There’s many a slip ‘twixt the cup and the lip”. In this game of debt pass-the-parcel, any of the parties to it can find themselves exposed to the credit risks they cannot help but hold.

I appreciate this may seem all very theoretical and even rather irrelevant. So you might be surprised that you experience it on a daily basis if you pay by a credit or debit card and all the stages are presented right there for your study in that mostly ignored or even discarded annoying bit of paper you get each time – the receipt. One of my favourite “small and usually overlooked objects which people don’t appreciate and pay them the attention they deserve” things, it might help to give that receipt a closer look. My hope is that after reading the explanation that follows, readers don’t quite treat it as nonchalantly as you probably do now. Because some pretty profound things are going on here.

Fig. 1 below shows the deceptively simply receipt for a transaction which was settled by a card payment:

I paid for groceries totalling £22.89 and also was offered – and took – £50 “Cashback” (Note 1) which is where the Merchant can issue cash in addition to whatever it is you’ve bought from them as part of the transaction. It’s worth keeping in mind that everything on this innocuous piece of paper has very specific meanings and very specific implications for everyone involved. Here, the amount is fairly trivial. But the same would apply if I’d bough a big ticket item like a vacation or even a vehicle (it is fairly common in the UK for buyers to use a debit card to pay for a vehicle where – and this is a lot less likely – credit isn’t involved in the purchase) where the settlement can run into thousands or even tens of thousands. And the principles in your humble transactions apply in exactly the same way to businesses who are settling invoices for millions – or tens or hundreds of millions.

We’ll start with the wording “Card Tendered”. “Tendered” is one of those wonderful legalistic sounding words. It is used here because something very precise has happened and this needs to be recorded in case anyone disputes the version of events which took place. Here is the dictionary definition of “tender”:

1) tender v. to present to another person an unconditional offer to enter into a contract

2) to present payment to another

3) n. delivery, except that the recipient has the choice not to accept the tender. However, the act of tender completes the responsibility of the person making the tender.

Now let’s step back a word. What did I “tender” ? My card, of course. And looking back at the dictionary / legal definition, I made an offer to the Merchant to enter into a contract. The Merchant did not have to accept my card as payment. But if they did, then my responsibility ends there in terms of making payment.

So far, the action on the reciept has been all about me and the Merchant. But now something else happens. It’s sufficiently important that the Merchant has taken the trouble to highlight on the receipt, complete with capital letters and festooned with asterisks so it must be noteworthy, “***CARDHOLDER COPY***”. This is telling us that what follows isn’t actually anything to do with me, but I’m being informed of what is now going on between the Merchant and other parties. Who are these interlopers who are joining me in the supermarket’s checkout line ?

The next row of the receipt ‘fesses up. “VISA DEBIT”. VISA is of course a well-known card network. And a debit card is a familiar Token which we use for settlement. So “VISA DEBIT” is a Token Network (from Table 2 earlier). After that, we get a mysterious “TID” but this is just short for “Transaction ID” and is a unique reference number identifying this particular transaction. It is hashed out on the receipt for security. “CARD” is my card number, again, hashed out for security. This records the Token (again, from Table 2) being handed out and passed around.

Another mysterious entry follows; this is perhaps the most crucial one so I’ve highlighted it in Fig 1 as Note 2. “AUTH” is followed by a number that isn’t recognisable from anything which has preceded it. What is this number and where did it come from? Well, all these items are listed under the heading “VISA DEBIT”. So it is from there – VISA, the card or Token Network – that the “AUTH” came from. And it was my card – a debit card in this case which was presented as the Token – which is being “AUTH’ed”.

What this means is that the Token Network, VISA in this example, is authorising my Token – my debit card here – for the amount of the transaction. In other words, VISA is telling the Merchant (specified in the “AID” entry which identifies the Acquirer ID, this is card payment-speak for the Merchant Services Provider who is managing all this jiggery-pokery for the Merchant) that it has agreed the transaction is valid. The “AUTH” code is the Token Network’s validation of the chain of claims from the Merchant, through the Merchant Services Provider back to the Token Issuer (my bank, who gave me the card to use a s Token in this way) and then on to me, the Customer.

That is why I got a copy of all this in the receipt. Once I leave the supermarket, the next time I’ll be aware of any of it is when my bank sends me a statement showing that it has taken some money from my account. I’m perfectly entitled to ask my bank “where did that come from?”. Because I am always given a receipt by the Merchant at the time these events took place, the bank can say “check the receipt, it’s all documented there”. And indeed it is. Once you know where to look. Actually, the bank doesn’t really give a flying fig what I think of the matter. But if asked to by a court of law to substantiate the legitimacy of the chain of claims, then this can be proved (although probably it would need the assistance of someone like me as an expert witness to explain it all, as readers will probably be thinking to yourselves by now, it’s not especially obvious unless it is explained to you).

So, all is just fine and dandy, then? I’ve got my groceries and the Merchant has got their money. Well, in the example shown in Fig. 1, yes. But just consider all the steps which had to happen along the way and all the parties who had their fingers in the pie. If you are thinking to yourselves this is all a bit complicated and a series of accidents waiting to happen, you’re right, it is.

First and foremost, note that none of this actually pays anyone anything. It is a process to establish then validate (authorise) a chain of claims. The Merchant makes a claim on the Merchant Services Provider. The Merchant Services Provider makes a claim on the Token Issuer (my bank). All these are supported by the AUTH code. But what happens if the Token Issuer (my bank who gave me my debit card here) decides it isn’t going to honour the claim and refuses to send the money to the Merchant Services Provider?

One of the most obvious reasons could be that it was not actually me at the supermarket using the card, but some nefarious criminal who had just stolen it from me. If I have reported that my Token (my debit card in this example) has been stolen to the Token Issuer (my bank) then I am, legally, perfectly entitled to refuse to pay any liabilities as a result of that Token being used inappropriately. Way, way back, when credit cards were introduced, issuers attempted to foist liability onto Merchants on some occasions where lost or stolen cards were used. Various claims were put forward by the issuers, such as the Merchant should have realised that the person using the card was a man but the name on the card was a woman’s name, or that the person using the card was too young to be able to have one or that the signatures clearly differed, in attempts to avoid having to pay for the resultant losses through fraud.

These attempts were processed through the legal systems of pretty much every jurisdiction. Eventually, after some legal wrangling, courts handed down judgements which said that, as far as a Merchant is concerned, if the Token Issuers (banks giving out cards to the customers) intended their cards to be used as a token for cash, then Merchants were entitled to treat them like cash with regards to their ability – or lack of ability – to intercept fraud. When I say “wrangling”, I mean “wrangling”, wait until we get to Scenario Variant 3: A Bitcoin Transaction for where the fun could really start.

Token Issuers hated this state of affairs and almost immediately started moving to dismantle it. What they came up with was Shift of Liability for Fraudulent Transactions (in the EU) or Merchant Liability Shift for EMV Chip and Pin Card in the U.S. They improved the security of the Token they issued to embed a “chip” in the card containing the Token details. They also allocated a Personal Identification Number (“PIN”) to the Token. After lobbying lawmakers, agreement was reached that if a “Chip and PIN” card was used as a Token, then the Merchant must use PIN verification for the transaction. If they failed to do, liability for any fraud losses would “shift” back to the Merchant.

This is what is going on in Note 3a and Note 3b in the example transaction in Fig 1. A Chip (“ICC”) card was presented and read successfully. A PIN was prompted for and used. The Merchant records this on the receipt. It denotes that, for this transaction, the Merchant has successfully shifted liability for Token misuse back to the Token Issuer.

Fraud isn’t the only problem which could arise. There is also credit risk. Usually we think of credit risk as being if the party liable for a debt cannot pay it due to insolvency or temporary illiquidity. But credit risk can also occur for other reasons which render a borrower unable to pay their debts.

While I successfully survived my trip to the supermarket and lived to tell the tale, what would have happened if I’d died at the checkout? Believe me, such things do happen, and far more often than you’d think. If I’d been accompanied and my quick-thinking companions had called the Token Issuer (my bank) to inform them of my unfortunate demise, the bank would have cancelled the Token and put a block on the account. Depending on the latency in the settlement of the various claims in the Money Transmission System chain, the Merchant’s Merchant Services Provider may well not actually present the claim back to the Token Issuer (my bank) until the end of the day. At that point the Merchant Service Provider would either have their claim denied or they’d get a Chargeback if it had already gone through.

So now the Merchant Services Provider is out of pocket, but that situation doesn’t last long because they deduct their losses from the Merchant. When the Merchant receives notification or gets the Chargeback, they’d probably investigate the situation. Perhaps they have CCTV and when watching the footage, they determine that I had indeed bagged up my groceries and they were on the checkout waiting for me to pick them up and take them – had it not been that I’d met my untimely end. What the Merchant would do then is to pass a Chargeback Reversal message back to the Merchant Services Provider, the Merchant Services Provider would pass this back to the Token Issuer (my debit card’s issuing bank) and reinstate their claim.

But, oh dear, it’s not quite as simple as that. When the Merchant processes their Chargeback Reversal, they notice that “Cashback” was part of the transaction and shows as Note 1 in the example receipt in Fig 1. In almost every case, Merchants are precluded from processing Chargeback Reversals on the Cashback elements of a transaction in the English and Welsh legal jurisdiction (I won’t bore you with the details why). The Merchant would have a claim on my estate, should they wish to pursue it, but if I died in penury, tough luck. The Merchant has to take a loss.

That is why there’s all those triangles (△) denoting “sometimes” in the Extinguishes Debt column of Table 2. Any party can renege, default on or dispute their step of the settlement process leaving the next party in the Money Transmission System left holding the Old Maid (a debt). We’ll leave conventional credit or debit card transactions here and enter uncharted territory with a Bitcoin Transaction.

Scenario Variant 3: A Bitcoin Transaction

Table 3:

Key to Symbols:

○：Always

×：Never

△：Sometimes

As previously, Table 3 shows what each party does in its role in settling a transaction using Bitcoin. The Token may be a smartphone with an app or even a physical token because Bitcoin denominated settlement can be initiated by a card-like form-factor assuming it is supported by the Merchant Services Provider’s infrastructure.

When presented, Bitcoin is used as the Token in the transaction which is authorised by the Token Issuer (Bitcoin) via the Token Network (which is again Bitcoin). This is the essential difference between a conventional card transaction shown in Table 2 and a Bitcoin transaction shown in Table 3. With Bitcoin, Bitcoin issues the Token (Bitcoins) and also records transactions involving that particular sort of Token in their bespoke Token Network. The Bitcoin Token Network is both a Money Transmission and a ledger System – which requires the bulk, distributed processing of “blockchains”.

Just like cash, Bitcoin is a Store of Value. But like a card payment it is a tokenised one. It represents – and is a conduit for – the Store of Value.

Cash settlement always extinguishes the debt arising from that transaction immediately and with finality. Tokenised payments – always and everywhere, it simply does no matter one jot what sort of Token is deployed – never do this. There is, inevitably, with a tokenised method of settlement a minimum of at least one additional party to the transaction, which, again, inevitably, involves credit creation if only for a few milliseconds.

Sometimes the duration of the credit which is created is a lot longer than that because the finality of the debt extinguishment in that step of overall settlement is determined by the contract in force governing the creation and satisfaction of the debt concerned. Card payment transactions can, typically, be disputed for up to 90 days after the date of the transaction. Even the contract governing the transaction isn’t sacrosanct – courts can and have ruled on what is a reasonable and permissible length of time before a transaction can be considered inviolable or the legitimate reasons why they can be voided. This is an important nuance. Contracts can establish the initial outline of how a set of tokenised transactions can be handled by the parties in the contract, but it is not until disputes have arisen and those disputes subject to court rulings – so giving rise to a nice, comprehensive set of case law to reference – that parties can have a good degree of certainty. The maturity of the body of case law influences the degree of credit risk arising.

If you think this article is detailed-bordering-on-the-verbose, just have a read through what was (in English and Welsh law) a landmark judgement about disputed settlement between Card Issuers, Card Networks and Merchants on chargebacks and potentially illegal transactions – and it took nearly 20 years to settle the law in this area. Most jurisdictions had to go through similar pain.

Yves has referred to Bitcoin as “litigation futures”. This is correct. But why is it correct? It is correct simply because of the incontrovertible fact that very little, if any, of the same legal points which have been historically argued and – eventually – settled when a card is used to complete a transaction have been the subject of final rulings when Bitcoin is used. It is inevitable that some of the parties to a Bitcoin transaction will get into disputes. Unless and until higher courts hear and rule on these disputes in key jurisdictions such as the U.S. and the EU it is only possible to tell approximately how existing laws will be interpreted in respect of Bitcoin.

If you’ll forgive the pun, I think that the penny has finally dropped on participants in Bitcoin transactions that, whether they are the Customer, the Merchant or the Merchant Services Provider they are dealing with credit creation, debt and the associated credit risks without any comfort blanket of settled law. Eventually, unless Bitcoin fades into obscurity (but it would almost certainly be replaced by the same thing with a different name), case law will be formed and a sounder legal position established. But who, really, wants to sign themselves up for a complex legal process and put themselves in that world of pain?

That, though, isn’t the main reason why I’m averse to crypto currencies (not just Bitcoin, I can’t single it out). The main reason is that Bitcoin, like all crypto currencies, just isn’t cash.

Cash settlement always precludes the possibility of further credit creation. There may well have been credit creation required in the issuing of the cash (to, in the case of our scenario, the customer buying the goods or services from the merchant) but that is, inevitably, historic. There can be, with cash settlement, no further credit creation as a result of the transaction because the debt which arises from it – a debt owed by the customer to the merchant – is irrevocably extinguished by the cash settlement.

Settlement involving a tokenised payment method (debit or credit card, Bitcoins, baseball cards, whatever) always enables the possibility – it does not mandate it, but only tokenised payment methods facilitate it – of further credit creation.

This means too that a crypto currency such as Bitcoin is always a cashless currency. With all implication of that. You, like I do, may even begin to wonder whether promoters of crypto currencies understand what any potential migration away from cash and into a crypto currency means. Maybe they simply don’t know. Maybe they know but aren’t saying. It never hurts to ask, does it?

Now, what would genuinely be “transformative” and “disruptive” is if the skimming machines that are the credit and debit card Token Issuers (the banks and bank-like entities who put their name on the cards), Token Networks (MasterCard and VISA) and Merchant Services Providers (a motley assortment of toll booth operators) were to be dismantled via nationalisation in recognition that they are, in totem, a Public Utility and best operated as a not-for-profit single entity. Put that on the list of things which ain’t ever gonna happen.

Conversely, when anyone talks or publishes about how this-or-that “innovation” is going to be an “industry game changer”, you can now look them up in one of the tables above and ascertain which of the existing roles they are eyeing up in order to replace an incumbent and, so they no doubt hope, get themselves a piece of the rent seeking action.