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:


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]

88 thoughts on “A simple explanation of how money moves around the banking system

  1. I think for day to day transactions (buying groceries and so forth), players like Coinbase will start alleviating a lot of the pressure on the blockchain. In a similar fashion, they will act as a bank, only changing the numbers in between accounts.

  2. Hi Simon,

    I’m inclined to agree. I think there are two major forces driving us towards this sort of outcome. 1) the “average” user is likely to trust a reassuring brand more than themselves to manage their wallet, driving a move to a bank-like “safekeeping” business model and 2) the blockchain may not be the best vehicle for micro-payments. Combine those two observations and you end up with your prediction: there is a gap in the market for off-blockchain ‘aggregators’ of smaller transactions.

    But I also know that many of the core developers, with infinitely more knowledge of the system disagree with this analysis!


  3. Great post. Bitcoin protocol works well between untsted parties that know what are they up to, non reverse, etc. In this case, no need for a Central Bank. Most average users, as you say, still need trusted relations, so there will always be a trusted layer above Bitcoin for anyone in need for it, giving some space to the current retail banking model. Banks do have a place in the Bitcoin scenario, same as today, but the difference is that you could still operate without them if you wish. Banks will be just another option.

  4. Excellent article Richard. I found myself asking a few questions as I read it, most of which you answered.
    “CHAPS payments cost about £25″. Do they really, or is that just the price? Do they charge that much because they want to make money, or because they want to dissuade us from using that method or because they really do cost?
    Are SWIFT messages signed? In other words if they contain non repudiation then surely they are a transfer of value rather than just the veil that you describe, however your focus is on whether the sender will go bust rather than deny sending it so it’s not relevant here.
    Surely this whole thing is just an model to allow us to understand things. There’s still no actual value moving around, so it’s not much more true than just saying that you’re moving money. But of course it is a much more thorough model that allows you to do more things.
    Surely bitcoin is still just the movement of liabilities. It still doesn’t have a real value until the sender gives up their sheep and the recipient receives a goat (or whatever else it is that makes the money have value to them). – I know you answered this by comparing to a gross settlement system rather than to real value.

  5. Pingback: A Simple Explanation of How Money Moves Around The Banking System | Enjoying The Moment
  6. Pingback: Linux Mint Czech - Bitcoin, a ako sa pohybujú peniaze v bankovom systéme at Linux Mint CZ&SK
  7. Great article, it’s always easier to understand with small examples.
    BUT I really didn’t like the graphs you did, mostly because the arrows go both ways. In the first example for instance, the arrow going from Alice to the bank shouldn’t go both ways. But it’s just my opinion.

  8. @Jaumenuez I agree; I think we’ll see a federated model of the sort you describe – but, also as you say, with the option of going “direct” for those who know how to and want to

    @benjamin – thanks. Good point re the diagrams; you’re right. The arrows are confusing. Sorry!

    @sean – thanks for the link

    @kassner – I left FX as an “exercise for the reader” but you’re right… the principles can be extended. e.g. imagine Barclays held a *dollar* account with Citi. That would give Barclays customers a way of making Dollar payments – and so on. Indeed, this cross-border example is what most people think of when you say “correspondent banking”. If you follow this line of reasoning, the counterparty risk problems becomes even greater and you end up with a need for an “RTGS for FX”, if you like. This motivated the creation of the CLS Bank.

  9. @Sam:

    * CHAPS – fair point. They’re “charged” at about £25. They probably cost a lot less.
    * SWIFT messages – not sure if they’re cryptographically signed but the key thing that SWIFT offers that the internet does not is security at the end points and within the network. i.e. if you receive a SWIFT message purporting to be from Barclays, you can be pretty sure it *is* from Barclays!
    * Bitcoin is interesting – because it doesn’t really fit the “liability” model. My holding of Bitcoins are nobody else’s liability. This makes them quite unlike any major currency today – and far more like gold or a commodity.

  10. Thank you very much for an interesting and educational blog post. I found it interesting because it sheds *some* light on a recent banking problem that left me quite stumped.

    I recently attempted a $5000 bill payment from a debit account to a credit card, and due to a policy restriction, the bank holding the debit account canceled the payment. When I called their customer service department, they informed me of the restriction and told me I could try again that day. I tried again, and the payment went through fine. However, I was quite surprised when I checked my credit card account a few days later and discovered that both payments had been processed on their side leaving me with a $5000 credit balance! The debit account was only debited once. I called the credit card company and everything they could see on their end showed two successful and proper payments. I called the debit account company and spent over an hour on the phone with various people there, but none of them could find any trace of the duplicate payment. All they could see was the canceled bill pay and the successful one, but they couldn’t find any evidence of the extra $5000 that I received.

    Of course, I’d love to just take the money and run, but I feel it is likely that one day, they will audit or balance their accounts and discover it, then come asking me for the money.

    If you are interested, I’d love to get some insight into how this happened and maybe some tips on who I could ask to speak with that might be able to do something about it since it appears to be out of the league of the customer service department. I’m sorry for being a bit vague with the details, but I believe that this problem might actually be a reproducible flaw in their system, and I don’t want to set them up for fraudsters to take advantage of it.

  11. @Daniel Einspanjer

    Rinse, repeat. :)

    Serioulsy, would be interested to find out what the result of this “error” ends up being.

  12. Good explanation of the different transfer systems. Could you please add snippets of the following equivalents for India into the explanations at appropriate places?
    1. Net settlement system done in batches several times a day – NEFT (National Electronic Fund Transfer) Monday through Saturday.
    2. RTGS (it’s the same definition as above), done through the central bank – Reserve Bank of India. There is a minimum transfer amount of Rs. 200, 000 (called Rs. 2 Lakhs locally) for using RTGS, while there is no minimum for NEFT.
    3. IMPS – Immediate Payment Service – instant, multiple channels (like SMS, web, etc.) and available 24 x 7 (unlike NEFT and RTGS that are not available on holidays and Sundays).

    The fee for using these services varies across banks, amounts and account types.

  13. Pingback: How Your Money Moves In The Banking System | Terraformed
  14. @jorge — Yeah, I’m not about to try and see if it is a vulnerable flaw in their system. It is easily provable that the first time was an accident and I went to great lengths to document my notification to them. If I go trying it again “just to see if it works” I’d quite likely be facing criminal charges from them regardless of whether it is their own stupid fault for not listening to me. :/

  15. Excellent tutorial, there. :)

    From the viewpoint of teaching the basics to people with no professional finance background, though, there’re a couple of more questions I’d like to hear an answer for:

    1. What’s the difference between commercial bank account and retail bank account? I’ve never heard of such terms.
    2. If these international RTGS services do exist, what is it that’s retarding their use? If I make an account transfer from my bank to some account abroad, they’re always saying it’s going to take a long time. Are even the services of central banks so expensive that the real time transfer is only a service to those who are ready to pay more?

  16. @indiasurfer – thanks for the comments. It’s great to get insight into the equivalent systems elsewhere.

    Could you say a little more about how IMPS works? Who runs it? The central bank? A third party? Do funds ultimately arrive at a bank account? It sounds a little like a more advanced version of the UK’s Faster Payments service – in which funds are shown in recipients accounts immediately but the banks only settle amongst themselves every so often – but it would be great to hear more.



  17. Great article. Would it be possible for you to take some time to write a similar piece on securities trading and settlement. That would be awesome!

  18. I have a question: If we already have a central bank system for moving money around, why do we still have the deferred net settlement systems like ACH around?

  19. visite http://www.placasparceria.com.br

    Desenvolvemos Brindes Corporativos e Pessoais, Placas de Homenagem para diversas ocasiões, Placas Comemorativas, Medalhas, Trofeus, Gravação a Laser, Corte a Laser, Corte acrilico, Gravação Laser acrilico, Troféus em aço, Troféus Esportivos, Pins, Projetos Especiais, Campanhas Publicitárias, Crachás, placas anti-corrosão, placas de Inauguração, Chaveiros, Brindes Empresarias, no mais alto padrão de acabamento, Empresa localizada em São Paulo.

  20. Pingback: Somewhere else, part 94 | Freakonometrics
  21. Pingback: A simple explanation of how money moves around the banking system / goccedisaggezza
  22. Thanks for the pretty thorough explanation :)

    What I’m wondering: If the system is instant, why does a SEPA transfer still take a whole day to arrive?

  23. Pingback: Coder Read #20131127: XOWA, an offline application for Wikipedia | Coders Grid
  24. This is worth reading a number of times. Always good to have a better understanding of something we use everyday, but don’t ever get told how it all actually works. As crucial to our lives as plumbing or electricity. Have reblogged it on http://leifdavidsen.wordpress.com/

  25. Pingback: How Money moves around the Banking System | AccidentalCapitalist
  26. Nice read. Though I understand that there is a lot more to this than I care to know.
    I have been reading the book “Lords of Finance” – the story of the great depression.

  27. Pingback: Link blog: filtering, england, censorship, transfer | Name and Nature
  28. Pingback: Links & reads for 2013 Week 48 | Martin's Weekly Curations
  29. Pingback: From the Archives: 11/25/2013 Edition « whatsjohnreading
  30. Pingback: Linkspam, 12/6/13 Edition — Radish Reviews
  31. Pingback: Links: Mandela and Great Leaders; WTO deal in Bali; How Money Works
  32. Stellar writing Richard. What are your favorite books on this topic and banking/transactional processing in general?

  33. Pingback: Ban Bitcoin! (demands VISA) | gert.is
  34. @marinatin thanks for the feedback. I really like Alec Nacamuli’s book on payment systems (disclosure: he’s a colleague) and the European Central Bank did a great book on how securities processing systems work. From a business perspective, Celent often produce good papers on the custody business.

  35. Pingback: Reading List 21st Nov, 2013 | Capsule
  36. Pingback: A simple explanation of how money moves around the banking system | The Renewable ChallengeThe Renewable Challenge
  37. Pingback: A Simple Explanation of How Shares Move Around the Securities Settlement System | Richard Gendal Brown
  38. Pingback: Bitcoin isn’t Money—It’s the Internet of Money | The Ümlaut
  39. Pingback: Links von 15.11.2013 bis 09.01.2014 | Mythopoeia 2.0
  41. Pingback: Bitcoin, a ako sa pohybujú peniaze v bankovom systéme - Linux Mint CZ&SK
  42. Pingback: payment21® blog » What does Bitcoin mean in terms of clearing and settlement for the global banking industry?
  43. Pingback: Fun economic reading | MuddyHorse Farm and Tech
  44. Pingback: Übersicht: Wie bewegt sich Geld in unserem Finanzsystem um die Welt? | Vomitorium
  45. Pingback: Compilado de enlaces | programacion@droope
  46. Pingback: Ripple is hard to understand, but it’s worth making the effort: there’s a deep insight at its core | Richard Gendal Brown
  47. Hi my name is David, I want to show you how you can generate thousands dollars is automatically.Automatic Website Builder is the best website builder software on the market for creating, publishing, managing and monetizing new and existing websites with the help of Google AdSense and other pay-per-click and Clickbank, Amazon affiliate programs. Equipped with innovative features that are not available anywhere else, our automatic website generator enables you to build top-quality websites for virtually unlimited revenue. VISIT THIS LINK http://bit.ly/1jv2rUH

  48. David- Great article. Wish you had a bitcoin tip address posted so I could show a little support! Another idea is that hopefully services like ChangeTip will integrate with WordPress soon.

  49. Hi Richard – Really nice explanation of what is/can become a complex topic.
    You may also consider adding something on how some deferred net settlement schemes/solutions have solved for the Settlement Finality problem – eg the use of authorisation systems and payment guarantees in use with the card schemes and similar with FPS.

  50. Pingback: Bitcoin and Bankers: Reflections on a panel discussion | Richard Gendal Brown
  51. I understand so far – RTGS system as explained by your really applies to all the banks in one country having an account with the central bank. I however need to send money from country a to country b – it begs the question do central banks have their own central bank to central bank clearing system.

  52. @Mendi – good question and yes. It’s called CLS Bank. Probably worth a post in its own right – but plenty of info on wikipedia, etc., about it and why it was created( namely: the failure of Herstatt Bank in 1974, which made it clear to everybody quite how much risk is hidden inside the correspondent banking system)

  53. Why can’t International transfers simply go through the VISA network. Since international remittance is so expensive. And VISA is only 2-3%?

  54. @sida – I guess we have to distinguish between international remittance and regular international payments. My guess is that recipients of remittances (typically) don’t have access to payment cards (hence remittance firms’ agent networks) and that regular international payments probably cost a bit less than an international visa transaction. Just a hunch though – it’s a good question

  55. That helped a lot, great article! There are just a few things that I don’t understand though:

    1) What happens when a customer of Bank A wants to send funds to a customer of Bank B when the two banks have different currencies and Bank A does not have enough funds at Bank B to complete the transfer? Lets also assume that Bank A also does not have enough funds at a path of correspondent banks or central banks to get to Bank B and that more money needs to be sent from A to B than from B to A.

    I guess the gist is that Bank A’s accounts are underfunded at correspondent banks.

    What must Bank A then do to complete the transfer? Must it send cash on a ship?

    2) Also, how is it that my local bank has physical foreign currency notes for withdrawal?


  56. Hi! Do banks use their own bank branches as correspondent banks? For example, can BNP Paribas in France us BNP Paribas in New York as its correspondent bank account?

  57. @Charly – 1) I guess you’re talking about the problem of liquidity management, etc. One option is for the short bank to buy what it needs on the FX market (e.g. if they’re a British bank, find a counterparty somewhere who is willing to sell the target currency for pounds). Another option is to delay the payment… i.e. defer paying out until enough funds to cover it have arrived, etc

    2) Not sure why this would be a problem… think of the bank as a retailer… they have some foreign currency in stock (in their inventory), which they have presumably already paid for. And they recoup the cost when they sell it to you.

  58. @MZ – Good point. Banks certainly do use their overseas entities to make payments abroad. So perhaps one way to interpret my piece is to think of smaller regional banks that don’t have their own international network.

  59. Pingback: The “Unbundling of Trust”: how to identify good cryptocurrency opportunities? | Richard Gendal Brown
  60. So sidechains become interesting when you consider bitcoins future is arguably as the RTGS for cross border transactions without countries that don’t have reliable central banks or correspondent banks.

    I’m curious if stellar could be a bitcoin sidechain. So you get a layered model.

    P2P payments
    Custodians to manage that as a liability on case of lost or stolen devices
    Stellar and other sidechains facilitate inter p2p service transactions and custodial relationships
    The Custodians then use bitcoin as an RTGS where there is no central bank.

  61. Somebody pointed out to me in private conversation the other day that you don’t need a sidechain to integrate with stellar/ripple – a gateway is all you need!

  62. It should be technically trivial to scale up the transaction volume to “PayPal-level” (I’m actually working on code to test that right now); scaling up to “Visa-level” will be trickier, but processing financial transactions is much easier than all the other things computers can do quickly (video, speech recognition, 3D rendering…) nowdays.

    I’ll be pushing to keep Bitcoin transactions cheap and accessible to everybody, not just people with millions of dollars to move around.

  63. @gavin – thanks for the comment. It’s a fair point… we do have to look at large numbers in context and with the perspective of time. e.g. imagine all 2bn internet users wanted to do one on-blockchain transaction per year. You’d need to be able to process about 64tps (I think. I really hope I didn’t screw up the maths). So, allowing for EVERYBODY to do one a month would need about 1000tps (ignoring for now that peaks would be way in excess). Assume 250bytes/tx and you’re looking at about 21Gb per day…. about 100Tb per year. A petabyte for a decade of transactions. 10^15 or so, give or take an order of magnitude.

    Now some people will need to do far more transactions but not everybody is going to use a system like this so perhaps these are reasonable numbers to play with.

    10^15 *sounds* like a lot — and maybe the real requirement is higher…. but we already know we’ll have to deal with at least 10^21 bytes routinely in the broader IT industry a few years from now. And the idea of storing this on thousands of nodes is obviously troublesome. But it’s not *obviously* insane (well, maybe a little bit insane).

  64. Hello Webmaster do you want unlimited content for your site?

    100% unique and human readable. Type in google:
    Nyschash’s Rewriter

  65. Pingback: Distributed Ledgers and Disintermediation of Trust | Crypto 2.0
  66. Pingback: A Simple Model for Smart Contracts | Richard Gendal Brown

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s