Can Blockchains Reduce Fraud and Failed Payments?

Blockchains can validate, clear, and document transfers of value much faster and more securely than traditional methods.

Blockchains offer an extremely efficient and reliable means of processing transactions of any size in a way that reduced the likelihood of fraud and failed payments. If a cryptocurrency wallet says that there is a specific balance present in a specific wallet, then that balance is there; it can be validated using the transaction record held on the thousands of computers on a blockchain. The record cannot be tampered with once it has been created: the distributed ledger is “immutable.” Blockchains are designed so that bad actors, or groups of bad actors, would find it prohibitively expensive or logistically impossible to modify the ledger or to feed it erroneous information. In order to process a transaction, the blockchain validates that a balance is present, and it validates that the owner of the wallet wants to transfer money out of the wallet to a specific recipient wallet, and the balances of the two wallets are immediately updated with the new balances.

This is called a “push” transaction: money flows out or is “pushed,” from the payer’s account once the private key has been used to give permission, and the funds are received by the payee without the need to validate anything. In itself, a push transaction is not a new thing, but the fact that blockchains use them while excluding their less efficient cousins-- “pull” transactions-- is what matters. In pull transactions, the request originates from the merchant or payee who claims to be owed money by Customer A. By swiping a card or having possession of a customer’s payment information, the payee alleges that the payer has agreed to the transaction, but the system has no way to really verify much beyond that, and payers who have been incorrectly or fraudulently charged have to engage the legal department of their card company to seek recompense.

With blockchains, none of that is necessary. With conditional payments systems using smart contracts, escrow accounts, multi-signature transactions, and so forth, various cryptocurrencies are beginning to enliven the dialogue about what can be done more efficiently and more securely using blockchain technology. One company, in particular, Ripple, is using their blockchain protocol to make cross-border “inter-ledger” transactions the new way to settle international business and banking deals.

International payments often have to clear multiple institutions and be converted to local currencies. Companies doing business internationally end up freezing millions of dollars in various currencies just to satisfy the requirements of local banks and governments. Ripple removes the need to use some of the old intermediaries that would all charge their own fees and take long enough to potentially ruin a deal, while businesses would have to use all sorts of futures contracts and hedges for their currency positions. Transactions that used to take a week and involve a lot of different personalities can now take a few seconds, more securely and cheaply than ever before, clearing all necessary legs of an international transaction simultaneously, using the smallest spreads possible from the most trusted market makers. When you have various legs in the journey, as with pull payments, double-spending can happen, intentionally or unintentionally.

Blockchains have solved the double-spending problem because once a bit of currency has moved on the blockchain, as stated before, it cannot be undone or spent from any other wallet. The transparency and redundancy of a blockchain make surreptitious dealings insurmountably difficult. The one problem currently is that some cryptocurrencies, Bitcoin, in particular, do not clear transactions very quickly if the network gets overloaded, so there may be some waiting involved, but once requests for payments have been submitted to the blockchain it is only a matter of time before a legitimate transaction will clear. Any duplicate requests will be disregarded.

 Disclaimers and Limitations

Go back to articles index