Are You Ready for Open Banking?

Historically, banks are seen as very conservative entities, not known for sharing their internal processes or customer data. This closed environment is driven by the inherent security risks associated with the world of finance. However, implemented last year, new international legislation is poised to regulate an unprecedented level of openness in this sector. New governances such as Open Banking Standards (UK), Open Banking Farrell Report (Australia), and PSD2 (Europe) are causing ripples of disruption even outside of their geographical borders.

While these regulations are not occuring in the United States, like the General Data Protection Regulation (GDPR), they will impact any organization that wants to influence markets internationally. By the same token, these regulations are igniting innovation by changing the way consumers engage with their financial service providers and pay for goods and services. It forces organizations such as banks, retirement service providers, and mortgage lenders to enter the API economy, requiring unprecedented API exposure of core platforms from these entities. It also allows for a level of transparency that gives downstream, 3rd-party applications new access to account information, payment transactions and approval, and general financial services data. Obviously, this exposure brings new security risks for all internationally-focused banks.

The threat landscape

In this new era, the threat landscape is complex, with attacks ranging from DDOS to sophisticated targeted attacks like SQL, command injections, and a variety of ever evolving bots, continuously morphing and changing their attack signatures.

According to the 2018 Verizon Data Breach Report, “81% of all hacking-related breaches leveraged either stolen and/or weak passwords”. As per a F5 Security report, “the highest percentage (70%) of the breach reports for Q1 2018 were web injections that stole customer payment card information”. It is also expected that by 2022, API attacks are going to be a major attack vector. Today, we are looking at a world where the majority of the banks in the affected countries have not exposed their APIs—that changes this year.

Once banks expose their customer data APIs, it’s very likely that credential abuse attacks will increase significantly. As early as July 2019, Australian, British and European banks will need to “design a good system that will both benefit customers and protect their data”. In essence, these banks must rethink their API and security perimeters, build security into their device layer, and trust no one—the basic concept of the zero trust model.

As per a report by Shape Security, “online banking applications are one of the most lucrative target for cybercriminals”. In fact, US consumer banks currently suffer massive losses due to 2 billion credential stuffing attacks a day.

Shape Security 2018 Report: Daily Volume of Credential Stuffing Attacks by Industry (US)

The Idea of Zero Trust

As an increasing number of banks move to the cloud, it is critical to move past the traditional on-premises, perimeter-based approach, and toward a modern, identity centric approach. Forrester’s Zero Trust Model and Google’s BeyondCorp are two ideas that follow this approach by assuming that all access to corporate resources should be restricted until the user has proven their identity. In addition, users must pass access permissions, while their device passes a security profile check. These approaches also highlight the idea that the perimeter is no more secure than the outside, meaning that your security solution should assume that all access is untrusted, until the end user is able to prove otherwise.

An Australian case study: PSD2 and GDPR

Europe, UK and AU open banking are governed by the Payment Services Directive (PSD2) and the GDPR. The aim is to foster healthy competition and innovation in banking while improving security. As previously described, it requires banks to open their APIs to 3rd-party providers for access to customer accounts, gather and manage customer consent for 3rd-party application access, and implement a strong form of customer authentication (SCA). PSD2 also introduces a liability shift, as the providers who fail to authenticate a transaction appropriately will now be held liable for any resulting breaches.

A common use case

How does this work in the real world? For Australia a common use case that PSD2 supports starts with an end user or Payment Services User (PSU). A PSU simply wishes to interact with a 3rd-party information provider or app (such as Mint) or Account Information Service Provider (AISP) to get actionable insights from their accounts across several banks. The 3rd-party app retrieves information from each bank by interacting with the end user’s bank APIs, giving the user innovative and value-added data.

In order to make these interactions happen, Australian banks must now abide by PSD2 and GDPR, opening up their customer data via APIs for transaction accounts, savings accounts, and credit cards by July 2019. This also requires banks to manage customer consent for 3rd-party application access and to implement a strong form of SCA.

An Open Banking solution and how Okta can help

Let’s look at a highly simplified view of Okta’s Open Banking Solution architecture.

In a real-world example, an end user might be looking for better ways to invest their bank balance, and using a 3rd-party application to get investment advice. In order to provide this advice, the 3rd-party application or Service Provider (SP) needs the end user’s account and bank balance information. To get this, it sends an OAuth2 Authorization request to the end user’s bank.

Because the bank uses Okta, the request is sent to Okta’s API Access Management endpoint, which is Okta’s implementation of the OAuth 2.0 standard, to secure the bank’s APIs. Along with other components like Universal Directory for identity and user management, and Okta’s Adaptive Multi Factor Authentication, Okta API Access Management will manage the Oauth flow.

PSD2 requires implementation of a strong form of SCA. So Okta policies can be configured to implement this, and the configured policies can be used to determine the necessary factors to be applied for authentication. If the 2nd factor configured is an Okta Verify request, for example, the end user’s Touch ID can be used to authenticate.

Now that the end user is authenticated, PSD2 requires the end user’s consent for the 3rd party to access their bank data. Okta completes this process by sending an OAuth authorization code back to the 3rd party. The 3rd party then exchanges the authorization code for an OAuth access token via a secure back-channel API call to Okta. The 3rd party then uses the access token to make the API call to the bank.

Okta evaluates the authorization policies and forwards the request with the needed scope and identity to the bank API. The bank then validates the access token, completes the transaction and returns the result to the 3rd party. This full solution meets all the compliance and security requirements, while also providing a simple and seamless end user experience.

A path toward being prepared

As we look at the myriad of international regulation changes coming this year, API security is a critical consideration for any bank operating on a global scale. And with the simultaneous rise in hacking-related breaches that involve compromised credentials, MFA is a critical piece of the security puzzle.

So, to mitigate the latest threats and improve their overall security posture, banks should be using this threat intel to aggressively monitor services, set up proper API Access Management for their APIs, and update authentication policies. Banks must also enforce best practices while setting policies, and allow their end users to choose only the most secure MFA factors.

In this world of constantly changing regulations, Okta is leading the way and constantly innovating in the Identity and Access Management space. By adapting Okta, internationally-focused banks can rest assured that they have a reliable and consistently evolving solution that moves as quickly as the ever-changing regulatory space.

For more information and resources, check out our Open Banking landing page and our Implications Around PSD2 and Open Banking whitepaper.