By Rui Ribeiro, CEO and Co-Founder of Jscrambler and Mohamed Gamil, CEO and Co-Founder of dotConnect

By now, we could hardly consider open banking and PSD2 as news. The updated Payment Services Directive has been rolling out since 2015, giving open banking a significant global push.

But one aspect of open banking that is still in the works is the new security requirements for banking institutions. PSD2, for instance, outlines a series of regulatory technical standards (RTS) such as strong customer authentication, secure open standards of communication, and incident reporting, which organizations must put in place to keep their customers secure while ensuring compliance with PSD2.

Today, with new paradigms such as DevSecOps, we know that security has a key role to play since the very early stages of application development. As such, the security controls required in the age of open banking must be ingrained in the application itself. But how has this impacted development teams? Have PSD2 and open banking effectively reshaped the development workflows in banking applications? Are banking institutions ready to adhere to PSD2’s deadline of March 2022?

A new opportunity for fintechs and incumbents alike

The global push for open banking that we’re witnessing today is driven mainly by new technologies and new regulatory initiatives. Under open banking, banks are required to provide open APIs to be used by third-party providers (TPPs), allowing them to access customers’ financial data or initiate transactions on their behalf. This process is always done with the consent of the end customer, in such a way that customer is directed to the financial institution and has to consent to the sharing of their data with the TPP.

While open banking may seem like a logical step forward in an industry that has yet to keep on pace with today’s rapidly evolving technological landscape, it has been met with resistance from the incumbents’ side, who argue that open banking mostly benefits fintechs while leaving little reciprocity for banks.

Another key challenge of open banking is ensuring the privacy and security of customers’ data. The very nature of open banking (allowing access to customers’ financial data and operations) defies a long-standing principle of banking — the strict protection of customer information under highly controlled environments.

So, as open banking looks set to become the new paradigm in the financial industry, it’s critical that organizations address this much larger attack surface and are able to protect customer data after it leaves the banks’ premises.

Security ingrained during app development

One major concern when it comes to open banking is social engineering attacks, which are aimed at compromising users’ credentials. Framing these attacks in the context of open banking, where banks are interconnected with hundreds of third-party services, the risk becomes much higher. If the attackers managed to compromise users’ login credentials for a third-party provider, they could potentially gain access to those users’ data or get control over their bank accounts.

With this threat in mind, one of the main requirements of PSD2’s RTS is strong customer authentication (SCA). SCA requires the use of at least two different authentication elements to ensure that the transactions are initiated by the client and processed for the client without any interference. It also stipulates the usage of dynamic linking to link the payment details to the specific customer and trigger a confirmation through a different channel, reducing the risk in case one of the channels has been compromised.

However, SCA is one of many requirements needed for secure open banking. The list goes on to include transaction monitoring, application shielding, and more. These all address what is one of today’s most exposed endpoints, the client-side — everything that exists between a user and the platform that the user interacts with, such as the users’ device or a browser. For decades though, banking institutions have been mostly concerned with protecting the server-side, not paying that much attention to the client endpoint.

So, meeting these strict security requirements requires application development teams to adopt multiple layers of security from within the banking application itself.

One of the most prevalent strategies to reduce the attack surface on the client-side is protecting the source code. Through obfuscation, encryption, and a series of runtime protection techniques, this strategy thwarts attackers’ attempts to hijack the code and see the logic behind the app while planning or automating attacks.

Another important strategy is ensuring that any traffic incoming from the endpoint is signed using payload signatures with dynamic keys to ensure the integrity of the traffic. Just like dynamic linking, this is a strategy that must be ingrained in the application itself.

All of these security layers have definitely shaped fintechs and financial app development companies like dotConnect. They embraced this security-first framework to deliver secure and PSD2-compliant banking platforms and ensure that banking institutions will be ready to meet the PSD2 deadline of March 2022.

As we get closer to this deadline, the horizon for open banking looks much clearer. There might still be some obstacles left to overcome, but we are clearly on the verge of a turning point in the paradigm of banking, signaling the beginning of an era of secure, versatile open banking for all.