By John Bertrand for Digitalist Mag
With digital innovation comes cybercrime and the responsibility to protect against it. This was clearly shown by the Bangladesh Central Bank’s recent loss of $80 million and secure financial messaging provider SWIFT’s response: “We cannot secure our customers’ environments and cannot assume responsibility for that.”
The “if it ain’t broke, don’t fix it” mindset has to go, along with legacy systems that lack ongoing, up-to-date protection. These are relics of a pre-digital, less sophisticated world in which core systems offered minimum security and even sensitive data flowed freely.
The link between SWIFT, blockchain, and apps to banking systems often happens through an API, a set of functions and procedures that enable applications that can access the features or data of an operating system linked to a bank account. By October 2017, standardized APIs will become mandatory in Europe.
The EU Payment Service Directive (PSD2) is designed to accelerate banking innovation and simplify payments. Under it, banks will need their customers to allow others to access their account.
SWIFT recently stated that alliance interface software is mandatory, and Reuters reported the Bank of England is calling for banks to check if they are compliant with excellent security practices.
History shows that some of our greatest technological advances have come from blending existing products together and using them in very different ways. The mining industry gave us the steam engine, which in turn transformed transportation and consigned the barge and the horse and cart to the leisure industry.
Many institutions fear that APIs offer cybercriminals “open sesame” access to data. Technology can create a structured cybersecurity environment as a best practice, but ultimately, people are responsible for cybercrime.Celent estimates that nearly 60% of fraud involves insiders, and CERT’s 2014 report showed that 37% of cybercrime involved insiders.
Cybercrime comes from three distinct sources: “joy riders,” sophisticated criminals, and organized crime/hostile nations. All three are able to deploy powerful, state-of-the-art computers and programs. Accordingly, banks must be fully aware of who their employees are, both permanent and contract, and what they are doing. Bad actors, bad agents, and malicious insiders often exist in unexpected places.
The blockchain provides provenance of any asset from day one, with five or more distributed ledgers/endpoints making it virtually fraud-proof. The next step is to move blockchain from “proof of concept” to a common industrialized solution.
Blockchain with APIs allows STP (straight-through processing) of asset and payment activity between buyers and sellers. All assets and liabilities must be registered on the general ledger of buyers and sellers, and compliance with Know Your Customer (KYC), Anti Money Laundering (AML), and Accounts Payable processes is required.
Secure, fraud-resistant, compliant STP with ongoing provenance is a winning prospect for all organizations. It has taken decades for banks to reach 90% STP for automating payments. While that shows great improvement, the cost of addressing the remaining 10% rivals that of the 90%, and that cost is likely to become the bank’s liability. Blockchain with APIs would provide 100% STP from the start.
The ultimate goal is, of course, end-to-end (E2E) cybersecurity. Both SWIFT and blockchain are part of the solution, and buyers, sellers, and their banks are another. At a minimum, E2E encryption and token-based data authentication should be required.
It’s time for banking to embrace the “digital yellow brick road.” Unlike the false threat of lions and tigers and bears faced by Dorothy and friends in the fantasy world of Oz, blockchain and cybercrime and APIs represent a very real threat—and a solution. Let’s eliminate the threat of cybercrime by taking blockchain seriously now.
First appeared at DI