You may also be interested in:


Blockchain: 3 Potential Use Case Complications

  • By Pankaj Gindodia
  • Published: 6/26/2017

There are substantial issues that we may face in using blockchain for some of the use cases that have been bandied around. While the technology has massive potential, it may be necessary to analyze the whole business process of these use cases before we try to fit blockchain in.

Cross-border transactions

First let’s see how the correspondent banking arrangement is used today for cross-border payments. Let’s use an example of a cross-border transfer from India (INR) to the United States (USD). An Indian bank sends a 103 message through SWIFT to Citibank, informing it of the impending transfer to a beneficiary’s account. But Citibank will not credit its customer, because it has not been settled in USD from the Indian Bank. For this, ideally the Indian Bank has to be the member of CHIPS in U.S.  

CHIPS will choose only those banks that have a robust USD balance sheet to become its members. The Indian bank cannot directly become a member and has to go through a correspondent bank that will settle Citibank in USD.  

Now let’s say a blockchain for USD replaces CHIPS, so that a peer-to-peer transfer can happen. The transactions would have to be settled on a gross basis, vastly increasing the USD liquidity requirement which is really not a good option.

Additionally, the sender in India would have to first buy USD—say, USD in the form of a virtual currency—from a bank or an exchange house first by providing INRs, into their own private wallet or in a wallet maintained with these intermediaries. This conversion transaction remains completely out of the blockchain. This is also the case with bitcoin, when we buy bitcoins from a bitcoin exchange.

Also, if the wallet is being held with the bank/exchange house for maintaining virtual USD, then they own your private keys in their own mutable database without the security of a blockchain. When a transfer happens on the blockchain, it would be displayed as a transfer occurring from the bank’s/exchange house’s wallets to the beneficiary in the blockchain and not from the sender’s wallet.

As for the costs—to make the blockchain really immutable, a lot of computing power is needed to record each and every transaction. Given the daily volumes of cross-border transactions, the computing power required will need to be massive compared to what is required for handling bitcoin transactions currently.

Anonymous transactions

If we really want to use blockchain for overground use cases, then it cannot remain 100 percent anonymous—at least not to regulators. These wallets/accounts will be opened by following sufficient KYC diligence processes, unlike bitcoin wallets. So while the nodes/users processing these transactions may not be aware of the sender and the recipient of the transaction, an authority with sufficient access should be able to track down the actual senders and recipients from the addresses/virtual accounts used.

There are talks going on to have a permissioned blockchain, with only limited nodes processing the data and/or having access to it. This vastly reduces the computing power to insert data into the blockchain and renders it mutable. Hence, such architecture does not remain a ‘blockchain’, but a shared/distributed network of servers holding the information, which is the case even with mission critical database servers.

Smart contracts

Smart contracts are contracts wherein the legal conditions are codified objectively, and the results of these conditions are enforced upon their fulfillment. These conditions are triggered by the data provided to this contract by the ‘oracles’, which can be an independent regulatory or auditing body or a technology framework. The current view is that, through the use of a blockchain, smart contract conditions and their results are democratized, and it would become very difficult to dispute them. 

I think, since the results of the contract depend on the data provided by oracles, this data itself can be disputed in a court of law. Additionally, these contracts are often so one-sided that they cannot stand the scrutiny of the court, and the defaulting party receives relief. But if such one-sided contracts are enforced through a blockchain, it may become an uphill task for the defaulter to recover their money.

Moreover, for smart contracts to be enforced, both parties would have to maintain sufficient balances in the currency of the blockchain to meet their obligations. This might be very difficult to maintain given the trade cycle of the industry. So even though the result is known from the execution of the contract, it might not be enforced, and a court of law might be required to resolve the issue.

Maintenance and execution of smart contracts in a blockchain also requires money. Already there are practices where only the smart contract is maintained in the blockchain, and its execution is done on true copies maintained by the stakeholders on their local databases to save on the costs.

Ultimately, I think where a good, strong and independent regulating and auditing authority exists, smart contracts and their results can be maintained by all stakeholders on their own servers and digitally signed by this authority and without resorting to the need of a blockchain. If required, the value/money, like the bank account details, can also be maintained with this authority in order to enforce smart contracts successfully.

Pankaj Gindodia is an independent business consultant for commercial banking.

CFO Playbook by SERRALA:

Strengthen Your Finance Departments’ Offense and Learn About Best-In-Class Cash Visibility and Finance Process Efficiency Now

Click To Find Out How the CFO Playbook Can Help You

Copyright © 2020 Association for Financial Professionals, Inc.
All rights reserved.