Open Banking to Close Gaps

Written by

Evidently, UK’s Open Banking regulatory mandate can be seen as an opportunity to offer more value to customers by partnering with third parties using Open Application Programming Interfaces (APIs).

The mandate, developed by the Open Banking Implementation Entity, offers a secure way for customers to use financial products and services from apps and websites that have been regulated. The body also publishes numerous refinements to the plan for developing the UK’s Open Banking Standards.
 
As UK banks open their data via secure APIs, third-party providers, including Account Information Service Providers (AISPs) and Payment Initiation Service Providers (PISPs), will be required to adopt these security-oriented approaches to enhance the Open Banking initiative’s objective of closing any security gaps.

AISPs opens up direct access to account data and transactions to third parties, which allows comparison of bank services and other automated services based on the information. On the other hand, PISPs initiate payments from accounts held by banks. 

Third parties adopting security oriented approaches 
There are crucial concerns about information privacy and security that should be addressed before allowing third parties to develop and release apps and services that access and share the customer’s financial data.

It is obvious that the introduction of API environment creates more entry points for potential attackers. In fact, in this new concept of Open Banking, traditional security walls will be rendered ineffective, which might inevitably affect consumer’s trust and data integrity. 

Secure Encryption: In effect, the open banking APIs should be designed securely to evade last minute surprises. Secure encryption strategies should be deployed to offer secure communication channels that helps achieve customer data confidentiality and ensure that no exploitable information is produced from data intercepted by hackers. This encryption should be mandatory for both data in transit (over a secure channel) as well as data at rest.

OAuth 2.0 Authentication Protocol: At the same time, this sector has adopted OAuth 2.0 authentication protocol to provide a secure way to verify digital identities and to offer a formal framework for obtaining and safely sharing consumer consents between the participating entities. This protocol uses tokens that act as entry keys to authenticate activities in open banking operations. 

Secure SDLC: API designers can integrate activities across the SDLC to discover and manage vulnerabilities while developing the code. In this case, security activities, such as code review and penetration testing are incorporated during the development process. Defendza has been part of an Open Banking project and helped design threat modeling as part of SDLC to provide an overview of threats to consider before the API goes into development. 

Secure DevOps Pipeline: The API design process can deploy DevOps tools and philosophies to enhance integration of security automation during the SDLC to ensure that security is incorporated early into API design and implementation.  As part of the secure DevOps (“DevSecOps”) pipeline Security is integrated into every part of the workflow, rather than in the release gateway or in the later stages of a release pipeline. 

Other measures that can be adopted to ensure secure design of APIs include:

  1. Adoption of a reliable security management standard (ISO27001, NIS CSF)
  2. Enforcement of PCI DSS compliance across the sector 
  3. Adoption of a proactive defense approach and threat detection strategies 

Moreover, providers are first required to enroll with the Open Banking Initiative for approval, to prevent scammers from participating, and to ensure that approved service providers have put right measures in place (including the ones mentioned above) to ensure information security and privacy. 

How third parties enroll
Third party providers can become regulated by:

  1. Reviewing the Open Banking Standards to establish if their product or service falls under the requirements of the second Payment Services Directive (PSD2). 
  2. Apply for relevant regulatory permissions from the FCA
  3. Sign up to the Open Banking Directory containing verified information of regulated third parties
  4. Securely test a product or services in the Directory Sandbox using dummy data
  5. Go live after FCA confirms the regulatory status

Based on the above enrollment requirements, third parties should understand that they will be required to demonstrate that they have deployed appropriate information security and privacy measures.

At the same time, there should be plans to whitelist the third-parties with the appropriate security measures in place to help customers identify cybercriminals and fraudsters. However, the process of whitelisting should be monitored and governed to restrict banks from imposing unrealistic criteria that would limit the number of third parties capable of accessing this data.

Ultimately, Open Banking is transforming the future of money as it increasingly offers access to innovative products and services from third parties. Customers will have access to secure apps from approved third parties, which improves the provision of personalized information and services for diverse financial needs in one place. This change requires a high level of privacy and security, especially in an environment where GDPR recommends that the way organizations get consent for sharing user data should be in line with what the owners expect. In effect, all interested third parties will be expected to deploy appropriate measures to maintain security and privacy and ensure that customer transparency and control remain at the center of product and service design.

Defendza’s consultants have delivered projects as part of a large team in one of the largest British multinational investment bank and financial services company. The project was working on Open Banking security and our consultants were responsible for ensuring the API HLA’s (high level architecture) designs, RAML’s (RESTful API Modeling Language) were meeting the security requirements including testing the final API’s before the push into the DevOps pipeline. This is only going to increase given other banks are following the pursuit.

What’s hot on Infosecurity Magazine?