Introduction to the basic concepts of FALCON

At Luno we’re constantly trying to think of innovative and practical ways to bring the power of cryptocurrency to everyone. Based on feedback from a number of multinational institutions, small businesses, Bitcoin companies and regulators, we embarked on developing a system that can bridge the gap between the current reality of international money transfers, and the promise of Bitcoin.

Bitcoin is often touted as the answer to international remittance and more effective settlement. While just looking at the technology would certainly suggest that a world where we primarily move Bitcoin around would be a much simpler one to operate in, the reality of the current situation is that Bitcoin adoption is still very small.

Many people are already sending money in the form of Bitcoin across borders in a peer-to-peer fashion, and enjoy paying less fees plus having near real-time settlement; but these are typically sophisticated users, in sophisticated markets, with access to earn and spend Bitcoin directly, or easy access to an exchange market where Bitcoin can effectively be traded for local fiat currency.

Here I hope to briefly introduce the basic concepts of what we envision for FALCON, and highlight some of the obvious advantages and challenges. Much is still to be done and we hope FALCON will enjoy a large community effort to help evolve and drive it into broad acceptance.

FALCON is an open protocol, used to simplify and streamline the experience of doing transfers. The gateways implementing FALCON are envisioned to be institutions that hold customer accounts and who want to offer international transfers to their clients. To simplify the discussion I will refer to these as banks, but it should be understood that it is a much broader category.

The current system

Currently, the process of sending small amounts of money is very expensive. It typically involves getting a quote from the sending bank, that works on an exchange rate that allows a generous spread for the bank. An exchange fee is also lobbed on top of the transaction. So if I want to send $100 from Singapore to Kenya, that typically costs me, as the sender ~$130.

A message is then sent to the recipient bank, or to an intermediate corresponding bank. The goal is to send a message along the chain of correspondent banks that each have relationships and accounts with the other banks; and then to offset and settle between these banks, eventually resulting in liability transferred in such a way that the recipient bank can credit the account of the receiver with the $100. Only, each of the intermediate banks, as well as the receiving bank will also charge a somewhat arbitrary fee. This easily results in another $25 being subtracted from the the amount received, leaving the receiver with only $75 worth of Kenya Shillings.

That is bad enough with sending something as commonly traded as USD. But if you are sending SGD for example, the transaction might just never complete due to a lack of appetite for Singapore Dollars in Kenya or at any of the intermediary banks. In this case the sender will eventually (days later) receive his $100 back in his account, but he will typically not be refunded the fees. During this time neither the sender or the receiver will have any visibility into what is happening with the transaction.

Note: this is not a hypothetical example – it has actually happened to us as a business, and continues to happen at a large scale for many businesses, especially SME’s, across a number of markets.

The fees are used to facilitate the transfer between correspondent banks. Banks need to take on some risk from other banks. They will have accounts at a number of other banks, spreading their liability and risk, while growing a network to facilitate a mechanism whereby transactions are offset between themselves by adjusting correspondent bank accounts.

FALCON: The basic protocol

The basic principle behind FALCON, is that banks need not trust each other for settlement and as such do not need correspondent bank accounts. FALCON does away with the need to pass liabilities (trust lines) around. Instead value is always transferred. The exchange rates are market related, and the fees can be much lower; transferring value instantly does not require a lot of risk priced in.

To accomplish this, FALCON is dependent on using a cryptocurrency as an intermediary transfer of value. We assume the cryptocurrency is Bitcoin, but in principle it could be any cryptocurrency.

FALCON is based on fiat-Bitcoin conversion quotes and value is transferred immediately. Initially it won’t always be cheaper than typical transfers, and transactions won’t always be possible in every market. But if a transaction is possible, it will be quoted exactly before the transfer is initiated, and it will be completed in a couple of minutes after the quote is accepted.

The sender will ask his bank for a quote to send $100 worth of Kenyan Shilling to a recipient in Kenya. The sending bank will in turn request a quote from the receiving bank for how much Bitcoin would be required in order for it to credit the recipient account with the $100 equivalent in Kenyan Shillings. It will also supply relevant transaction detail including a unique refund Bitcoin address.

The receiving bank responds as part of the request cycle with a quote for x amount of Bitcoin that will guarantee the settlement, as well as a unique Bitcoin address that will be expecting the payment; and an expiration timestamp. If the detail for the receiver is not valid, or the local market for Bitcoin is not liquid enough, then relevant error messages will be returned to the sending bank instead.

On a success response, the sending bank will then get or calculate how much USD is needed to buy the required Bitcoin, and display that quote to the sender. The sender can accept the quote, upon which time the sending bank executes the local trade and sends Bitcoin to the transaction Bitcoin address.

The receiving bank will see the transaction, immediately execute a local sell trade, and pay the $100 equivalent to the receiver’s account.

The various quotes will include spreads, and the volatility of the market and exchange fees will be priced into the quotes. If the market is particularly volatile, or seems risky or illiquid, the receiving bank isn’t obliged to respond with a quote. When presented with a quote, the sender is similarly free to discard it.

Bitcoin is only used for the transfer. The volatility risk for any given five minute timeframe is very low, so spreads will typically be very low too.

Senders and receivers won’t even have to know that Bitcoin is involved in their transaction. Some gateways could explicitly be Bitcoin gateways, senders could send Bitcoin directly from their Bitcoin wallet while the receiver could get local fiat money in their accounts at the receiving institution.

Practicalities

Coordinating banking relationships, especially with regards to AML requirements is still a barrier, but a trusted central certificate authority can validate gateways, provide authentication, and coordinate a registry of member gateways. No certificate authority or registry exists yet, but we foresee at least one such entity being formed as a collaboration by some industry players in the near future. Gateways are also welcome to set up direct relationships themselves or just use FALCON internally.

Gateways need access to Bitcoin liquidity, either in the local market, or if regulation allows, sourced across borders. Bitcoin broker services that provide quotes can be used (Luno has such a service), or gateways can trade directly on exchanges.

FALCON is quite capable to fit into the current financial system. The senders and receivers could be correspondent banks, and communication could conceivably still happen via SWIFT messages. FALCON adoption could slowly grow and still co-exist with current systems while global and local Bitcoin liquidity improves.

Initially the big advantages will be speed of execution, and competitive pricing in some channels, especially for small amounts. Eventually it could form a much bigger part of a much more distributed and simpler global payment network.

Luno and some of our partners are currently evaluating and testing FALCON, but the protocol is explicitly open for feedback and co-development. We are anticipating that there will be broader interests and that more people see the potential and want to join in the design, development, testing or including it in current payment networks. There is also many opportunities for certificate authorities to create networks of trusted gateways.

It will be a long time before global transfers rely on cryptocurrencies, but in the meantime it is good to see and work on practical Bitcoin based systems that can easily fit into current scenarios and bridge the gap between now and the future of crypto-based global commerce.

More information

To find out more about FALCON, visit https://bitx.co/falcon

If your institution wants to participate in experiments, or help drive the ongoing development you’ll find the proper communication channels there too.