New Money Hub


@current level
New Money Hub
Money and Credit Conversion

@sibling files
Introduction to crypto-finance
Business requirements for smart contract platforms
Bitcoin as conceptual art

Home > Crypto-finance > Introduction to crypto-finance

Introduction to crypto-finance

Cryptography has been used in banking for many years now. Online banking relies heavily on data encryption, and few of us can image a life without online banking any more. The SWIFT network is the backbone of worldwide banking, and all messages sent via SWIFT are of course also encrypted. So one could say that there is already a lot of "crypto" in today's finance.

Nowadays, the expression "crypto-finance" specifically means the use of blockchain or distributed ledger technology in finance.

An example: SWIFT

Let's take SWIFT as an example. Although the expression "SWIFT payment" is often heard, in fact SWIFT is simply a very secure messaging system. No actual funds are transferred over SWIFT. Here is how it works:

  • Bank A will send a SWIFT message to Bank B, for example requesting a transfer of funds to another bank
  • Bank B does the transfer (which may also involve SWIFT messages)
  • Bank B then sends a confirmation to Bank A, stating that the transfer was done
  • Bank A, although it has received confirmation, has not received proof of the transfer. It cannot be 100% sure that the transfer was actually done; there may have been a computer glitch or some other problem.

To overcome this limitation, we could create a world-wide central clearinghouse for banks. However, this is very unlikely to happen, mostly for political reasons.

Overcoming SWIFT's limitations

But it is also possible to use new concepts of crypto-finance. How would this work?

Suppose a group of banks set up a common network, with each bank representing one or more nodes in that network. Each node maintains a ledger of all the positions and transactions of all the banks in the system. The nodes constantly communicate with each other, and the ledgers are synchronised across nodes in real time.

A transaction occurs through the exchange of messages a bit like SWIFT. For example, Bank A sends a message to Bank B: "transfer 1 million Euros from account ac1 to account ac2". If Bank B acknowledges and confirms the request, then that confirmation open a transaction in the system. This is followed by a consensus-building process across nodes, after which the transaction, if confirmed, becomes part of the ledger (i.e. of all the ledgers). The payment has been made.

Both Bank A and Bank B, as well as the account holders of the accounts that are being debited and credited, can see and verify the transaction in the ledger, they can see the payment.

In such a system, there is no longer a difference between the message and the payment. The message is the payment.

Such a system will be highly resilient. If a node goes down, the system continues to function. When that node then comes back online, it "catches up" with the other nodes and quickly becomes synchronised again. And of course, each bank may choose to have 2 nodes, or more, to avoid being down.

In addition to resiliency, you can imagine the cost efficiency of such a shared system. It eliminates the need to install and maintain complex IT systems at each individual bank, it reduces the need for software and hardware redundancy, it simplifies operations a great deal. There is also much less need for reconciliation.

Data confidentiality, KYC and other features

In a network of subsidiaries belonging to the same group, each bank does not necessarily need to hide its information from the other members. However, if the banks are independent of each other, each bank in the network will clearly not want to show the other banks the details of its operations. Each bank should see only the details of its own customer accounts, and only as much about the system’s transactions as is necessary. The rest should be rendered opaque via encryption.

In parallel, regulators could be given access to the data of specific banks that are under their supervision, or even just to a certain groups of clients across all banks, for example clients of a certain nationality.

Banks will also require additional features such as KYC (know your customer), the ability to block accounts in case of fraud or theft of identity, and others.

As these features become available, widespread acceptance of distributed ledger technologies in banking will become possible.


(adapted from the text of an allocution made by Alex Kampa on 5th June 2015 at the conference "Crypto-finance for the financial community", which was organised by Hiero a.s.b.l. and held at Lalux Assurances, Leudelange)