The European Union’s Second Payment Services Directive requires banks to share customer financial and transaction information with third parties. But there are big questions about whether third-party fintech companies and even major banks are using APIs that are properly secured to transmit such sensitive information.
Open banking levels the playing field for all financial services organizations looking to offer their customers a consolidated way to manage all their financial assets and transactions through one financial services company. The second version of the EU’s directive, called PSD2, went into effect in September 2010.
Before open banking, consumers who wanted to allow third parties to access their accounts had to turn over their login credentials. When consumers access each of their accounts, the financial services company sends the information back from their backend servers, using proprietary APIs, to the consumer’s mobile app or web app, both owned, built, secured and managed by that same financial services company.
Open banking changes that. The promise of open banking is to give consumers a single view into all their financial information across all the different financial services organization they work with and use it for budgeting, financial planning and making financial transactions such as payments and wire transfers.
This requires financial institutions to move away from using its proprietary APIs to a set of open banking APIs that will allow any other financial services company to send and receive API requests to get your financial information so that they can represent it in a single view.
But it’s becoming apparent that API security for open banking isn’t fully there yet. Fraud detection models are built around consumer behavior and parameters. Open banking transactions are not initiated by a consumer but are coming from another financial services company. This could make some fraud detection models in place today obsolete.
In addition, fintech companies need to take a fresh look at API security to ensure the highest levels of in-app security: encrypt all data in the app, including all string and resources, API keys and API Secrets; secure the payload of the API requests so that no one can tamper with any of the financial transactions made from the app; obfuscate the source code of the app to protect the intellectual property of the developer; and harden the app to make tampering and reverse engineering of the app impossible.
Trend Micro, in its
In order to protect consumers from fraudulent use with open banking, banks and new financial services companies need to protect their end-to-end infrastructure with a layered defense system that will maintain data integrity, secure the connection between the app and the multiple backend servers of all the financial institutions involved and protect the keys to the kingdom.
To do so, at a minimum, financial services companies will need to encrypt the data that the API is passing and storing. They will have to protect the API credentials, keys and secrets. And they need to secure the connection and the backend APIs. Moreover, since app developers cannot control the devices on which their apps are installed and operate, they need to build their apps so they can operate securely in a zero-trust environment. And finally, developers have to harden and shield their apps to protect the logic and flow of their apps and protect their own intellectual property.
Open banking could transform online banking, spurring innovation and making transactions far simpler for consumers and the industry as a whole. But without proper app and API security, open banking also vastly expands the potential attack surface for financial institutions. For open banking to work, developers at both banks and third-party fintech companies must make security a top priority.
