PSD2 & Open Banking Cyber Security Considerations

Open Banking

Evidently, 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.   

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 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.

PSD2

PSD2 aims at making safer payments with increased consumer data protection to ensure a level playing field. European payments council have come up with The Regulatory Technical Standards that define the implementation requirements for payment service providers in order to comply with PSD2. The two main definitions in this standard relate to strong customer authentication (SCA) and secure open standards of communication (CSC).This is directly applicable to EU member states.

SCA (Secure Customer Authentication) has to be applied:

• When a user (whether an individual or corporate) accesses their online account
• When making online payments
• Any other actions through remote channels with a potential risk of payment fraud/attacks

In order to apply SCA (Strong customer authentication), identity must be verified using two of the following three criteria:

• What the user knows (PIN, password)
• What the user has (security token)
• What the user is (biometric verification)

For all remote transaction, an additional element that must be added include a unique authentication code linking the transaction to an amount and payee. Certain exemptions to SCA exist where payments are of low value, unattended terminals for transport fares, etc.

The RTS’ second principle is Common and Secure Communication (SCA) that ensures secure communication channels provided by ASPSP (Account servicing payment service provider) to AISP (Account information service provider) or PISP (Payment initiation service provider). This could be via a dedicated interface such as API or using the customer online banking interface.

For a financial service provider to adhere to use Open Banking APIs, they have to comply to one or both of the following:

• AISP, stands for Account Information Service Provider, are authorised entities that are permitted to connect to banks on customers’ behalf. These AISP’s provide a service to consumer and are authorised to ‘read-only’ access of bank account information. Examples of these providers include online comparison tools, money management tools, financial products.
• PSIP stands for Payment initiation service provider , are authorised entities that are permitted to connect to bank account and perform payments on a customers’ behalf. An example would be an online mobile application that tracks users expenses to alert before bank balance goes low, or one click checkouts at online stores.

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 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.  

Open Banking is opening greater value to businesses by ensuring efficient and compelling customer service to their users. Rapid spike in digital banks in UK itself is paving way forward for SMEs (Small to medium enterprises) to understand and leverage the technological advances to improve their financial positions. Overall, there is a strong desire for businesses to move towards open banking quickly and this is also encouraged by the fact that supply chains react to its implementation quicker.   

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.  These experiences include 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.

Cyber Security in Financial Services

Cyber risks pose a constant threat to financial services. Financial service businesses are constantly investing in attack protections to protect the vast amounts of data from reputation, regulatory and/or legal implications.

Technological advances have made banking faster and innovative by improving products to consumers. Like financial risk management, technical risk management plays a key role in avoiding major disasters.  If not kept secure, or monitored and acted upon, cyber security attack can bring business operations to complete stop in no time. There is a wealth of information online detailing about how data breaches are hitting reputation along with authorities/ICO fines. Most businesses in this sector highlight cyber weaknesses in the following three areas - People, third party management and protecting their assets.

Private equity firms, hedge funds, wealth management firms require constant checks on their controls to ensure minimal attack surface. The financial sector businesses store and process sensitive information such as banking accounts, personal details, futures and investments details, clients' data, proprietary products, tools, algorithms, trading information. All this information is always at risk  from both external and internal threat actors.

Why select Defendza to help you?

Defendza is a specialist provider offering cyber security consulting, training services and managed security services. We deliver a truly independent third-party opinion, unbiased expertise free from any inclinations towards vendor partnerships, reselling objectives or promoting any security products. We pride ourselves in being a partner of choice for our clients and helping with their IT security and compliance requirements.

Our experience in the financial services industry extends to the broadest set of technological choices in use across Tier 1, Tier 2 banking, insurance and other financial services businesses. Be it be banking transformation programs, ATM networks, High Risk platforms such as futures trading, investment banking products, smart card authentication devices, we have the skill-set to deliver you the required validation against your development and implementation. Read our financial industry sector insight to learn more on our work.