Blog article
See all stories »

Blockchain apps and the need for remediation

In the recent story on Finextra Swift confirms multiple cases of fraudulent message traffic, attackers compromised back end computers and other devices to authenticate and initiate transactions.

In a blockchain based architecture, this is a salient example of why trusted intermediaries and transaction reversal / fraud remediation process are very important for wide public service deployments. Relying on a free for all, fully distributed public ledger may prove unacceptable for use cases where customers have no choice in the risk they are taking.

In another story on eBay, where the author is demonstrating how eBay can prevent fraud using blockchain, the promise of an escrow intermediary is correctly outlined. Most online marketplaces operate on this principle anyway as they take on the risk to protect consumers and also encourage worry free transactions. Various penalties of fraud are imposed on the culprits thus discouraging these acts. Various payment arrangements between vendors also help support this intermediary risk model. 

When it comes to enterprise and more public service type applications of blockchain, the remediation and customer service aspects are much needed. Primarily because at every stage of a customer transaction, we must be able to hold a single party accountable for an action or event. Holding the end users responsible only works in a limited number of cases. Blockchain does address many other common scenarios such as enabling companies to proactively trigger transactions in order to reward loyalty for example.

Blockchain has tremendous benefits of bringing in transparency in banking and faster throughput of business processes such as payments and settlements. However, an examination beyond technical aspects and algorithms is very much needed if we want to drive true customer adoption when an open architecture is offered as the only option. Multiple parties in a value chain will need to come together because this cannot be achieved by one party alone. Image credit.




Comments: (2)

Graham Seel
Graham Seel - BankTech Consulting - Concord 28 April, 2016, 00:59Be the first to give this comment the thumbs up 0 likes

The recent Bank of Bangladesh / SWIFT incident underlines where the weakest link may be for distributed ledger applications. The weakness in that case was the point of entry to the trusted, secured network (in this case it was the vulnerability of a SWIFT Alliance gateway, but it could have been anything on the bank's side given their primitive security measures). Integration of distirbuted ledgers with legacy infrastructure will remain a challenge for some time. 

A Finextra member
A Finextra member 03 May, 2016, 14:30Be the first to give this comment the thumbs up 0 likes

Thanks Graham. Valid point. Also, it's not just legacy integration that is the problem. Systems can always be hacked into so remediation methods are a must. Tighter integration with multi factor Identity and Access Management software is also needed I think.

Now hiring