In September 2019, an updated European Union (EU) regulation, namely the Revised Payment Service Directive, and a global Open Banking API standard have entered into force. A few days after the official deadline, there were over 205 third-party providers (TPP) willing to assist businesses and individuals with payment initiation or account information services, and about 56 percent of them are from the United Kingdom.
Both initiatives are generally aimed to provide people with better awareness and more control over their financial data. Even though the PSD2 banking directive is mainly associated with the EU, it has had a global effect. Banking organizations in the United States and Asia introduce the same or identical standards to supply their consumers with convenient services that are on par with the European ones.
What’s It All About? — The Definition of Open Banking API and PSD2 Regulation
We’ve already discussed the Open Banking and PSD2 difference in one of our previous articles, but to make a long story short, they are set to encourage competition in the financial services market and help individuals better manage their money.
What is Open Banking?
It is a set of rules that compels banking institutions to build and open up their application programming interfaces (APIs) to external providers, granting access to customer and payment information, with the consent or knowledge of account holders. Consequently, third parties can create new services and products to enhance personal finance management (PFM) and offer more financial transparency choices.
What is Open Banking API?
Application programming interfaces are a set of protocols and codes that enable different software solutions to communicate with each other and exchange necessary information. Within the context of Open Banking, these APIs ensure secure interaction between third-party providers, mainly fintech firms, and online banking systems.
What is PSD2 in simple terms?
The Revised Payment Service Directive is the updated version of the PSD1 dated back to 2007. Under this regulation, banking organizations are obliged to share account information with external service providers with the approval of account holders. Consequently, clients can utilize Account Information Service Providers (AISPs) to collect data from several accounts that they may have and get a comprehensive view of all in one place. Additionally, users can pay for goods and services at the checkout of any online store that allows Payment Initiation Services. In fact, this functionality is also a part of the Open Banking API platform. But most importantly, PSD2 binds payment providers to use Strong Customer Authentication (SCA) to confirm online transactions.
What Does Strong Customer Authentication (SCA) Regulation Mean?
Strong Customer Authentication or SCA is a European dispositive standard that makes it incumbent upon companies to integrate additional authentication factors into their checkout process. It requires to employ two or more elements of the mentioned below:
- Something the user knows, like personal identification number (PIN) or password;
- Something the user has, like mobile phone, token, wearables, or a Smart Card;
- Something the user is, like fingerprints, retinal scans, or facial features.
Apart from the checkout flow, it’s critical to have these PSD2 security measures in place when payment service users (PSUs) log in to their transactional accounts online or perform any actions via remote access channels, which may entail payment fraud risks.
The Main Points of Regulatory Technical Standards on PSD2 and Strong Customer Authentication (September 2019)
- Financial organizations must grant third-party payment providers (TPPs) with access to their core banking and payment systems via dedicated APIs.
- APIs must be delivered under the same class of service, similar to the bank’s own products, like online banking. At this point, the availability and performance criteria are specified by the ERPB’s API Evaluation Group.
- The established API standard should be inspired by a registered industry benchmark, like Open Banking UK or Berlin Group NextGenPSD2.
- The mobile app, channel, or device where the transaction data is shown must be unaffected by the one where the payment was initialized.
- The authentication code should contain the recipient and the amount paid. This information should go through all the authentication stages (generation, queuing, application) and be displayed to the payer.
- The RTS defines exceptions for non-performing PSD2 secure customer authentication measures, such as entering a recognition code for each transaction, based on the next principles: payment recurrence, a particular payee, a use case or channel, or period of access to the account (90 days at the most).
- Bank-specific technical documentation, methodology, tools, and examples should be published on the corporate website and be available for free download.
The Basics of API Security or Merely Trust No One
Initially, these interfaces have been recognized as a reliable and secure B2B communication method. Unfortunately, hackers don’t rest on their laurels and hone their skills. Consequently, Gartner predicts that by 2022, API abuse will be the most common line of attack. Considering the PSD2-Open Banking requirements, what’s to be done about that?
First and foremost, API security standards should be an indispensable constituent of the API engineering process, and you should start with the proper architecture model.
To prevent risks and meet the PSD2-Open Banking UK standards, companies should follow the ‘do not trust’ principle and thus ensure a more resilient and stable future for their interfaces. The security layer within the API architecture should inherently cover the issues associated with:
- Access auditing;
- Threat discovery;
Working on API implementation, software developers in the banking sector should also include the need for adequate protection against distributed denial of service attacks (DDoS). Fortunately, most systems with open APIs are built from scratch, and organizations can obstruct attacks in the core stack, as well as keep the intelligence at lower layers safe. To address the primary PSD2 challenges in security companies should:
- Manage traffic — adopt traffic management guidelines like throttling and rate restriction on the number of applications in a given time to secure the infrastructure from getting overloaded;
- Verify messages — apply Data Masking principles to hide inside intelligence when logged;
- Encrypt data — protect all communication utilizing field- and message-level encoding, such as Transport Layer Security (TLS) methods;
- Authorize and authenticate — acknowledge approved TPPs with TPP certificates provided by a QTSP, list licensed TPPs collected from the EBA Register, and regularly verify against the revocation list;
- Prevent attacks — implementing PSD2 don’t forget about underlying online banking security risks and insulate system against content-based abusive actions, such as corrupted JSON or XML threats or script injection attacks.
PSD2 and Open Banking Security: Are Banking Systems Ready Now?
When we define PSD2, we realize that this regulation is aimed at mitigating the security risks of mobile banking and making it safer. However, this paper analyzes the readiness of banks and financial institutions for existing and potential risks that may emerge in the short run.
Fifty-eight percent of individuals solely in the UK worry about falling prey to fraudulent activities or financial crime, and twelve percent of people have fallen victim to financial scams in the past year. On the back of Open Banking and PSD2 requirements, fintech startups gain more authority; however, we cannot ignore the fact that the greatest losses recorded in the financial sector have been disseminated among smaller firms. We’ve found several issues with API security that can lead to penalties:
- some banking and fintech APIs and websites include confidential customer information such as access tokens, IMEI codes, or transaction data in their URLs;
- there are banking mobile applications that connect to external agents like advertisers or data analytics companies;
- banking organizations still employ outdated data aggregating and sharing methods, and screen scraping (also known as ‘direct access’ technique) is one of them;
- in the UK, banking firms are working on the financial grade API (FAPI) protocol to add another security layer in the authentication procedure between banks and new fintechs; however, it is still in progress.
These are just some of the problems that banking and financial institutions should address in the first instance, before the implementation of Open Banking API and PSD2 regulations.
Open Banking and Security Risks: What to Expect After the Implementation?
The new concept with open APIs that provide access to banking data brings about further possibilities for hackers. For instance, banking information is of interest to attackers since it includes a holder’s income, goods, and services that they have bought, personal preferences, and even physical location at the moment of card payment. Additionally, attackers can set up malicious fintechs to get access to customers' account data, and according to the PSD2 API specification, the permission will be granted for up to 24 months, so a lot of information and important transactions can get into wrong hands.
Later on, you can find summaries of the main attacks that we anticipate in the near future:
#1 Attacks against customers
End-users still remain the most vulnerable target. Mass email phishing has been out there for several years, and it tends to be less productive today, but with the all-around introduction of PSD2, the situation may change.
Phishing emails with something like “We’re a third-party provider A of bank B. Currently, we’re refreshing your account details, click here” can seem more relevant and innocent, especially after the adoption of the latest regulations. Additionally, malicious budgeting apps and fake banking solutions to intercept account credentials are hardly unique.
#2 Attacks on fintech firms
In most cases, fintech companies are small and less experienced next to traditional banks, which turns them into perfect targets for attackers. Our experience has shown that too often, startups don’t have team members who are fully dedicated to financial services cyber threats so that they can be exposed to hackers acting as an authorized bank or a banking client.
Servers of fintech companies are ideal for capturing users' banking data, and currently, there are a few middleware providers in the Open Banking area that collaborate with multiple TPPs simultaneously. Hacking one of these firms will disturb several fintechs, and neither the stakeholders nor the users will be on to the situation. Such types of threats, including brute forcing and supply chain attacks, are difficult for banks to trace.
#3 Attacks on API directly
According to the PSD2 objectives and guidelines, APIs should be public, so in fact, attackers can easily understand how the system works and unleash extraordinary responses from the back-end via the cut-and-try method. Malicious actions can include DDoS attacks and lead to system downtime, so it’s critical to follow the API security standards that we’ve described above.
#4 Attacks on mobile apps or platforms
Working with fintechs and financial services companies globally, we’ve faced the fact that most of the systems are implemented as mobile applications, and we realize that the latter will also become a target for hackers. Finding out the username and password would allow attackers to review account data and perform various banking operations, including but not limited to financial transfers.
PSD2, Open Banking, and Cyber Security: How Modern Technologies Can Address Financial Services Cyber Threats?
As banks deliver on APIs, try to comply with the PSD2 security requirements, and expose their core systems and infrastructures to TPPs, all of that creates new opportunities for defrauders at a time when financial institutions have already been on the losing side in the fight against fraud.
With the introduction of new regulations, the rules of the PSD2 fraud prevention game have changed dramatically. Banks used to rely on clients interacting with their systems directly, so it was up to banks to collect all the necessary information and decide whether an operation is fraudulent or not. But under the Open Banking and PSD2 regulations, many customers may no longer use their banks' websites, thus cutting down on the amount of relevant information accessible for the banks.
In this context, ensuring a safe and reliable infrastructure for TPPs will be an immense challenge for banking organizations. Most of them opt for off-the-shelf software, but its fraud score models require sustained training for over six months. Consequently, enabling new transactions via TPPs, banks will need at least six months to produce scores revealing the transaction risks. In the meanwhile, banking analytics departments need to adopt emerging technologies and advanced tools to monitor transactions proactively and create their own rules to stop fraud.
Taking all of this into account, the implementation of inherence as the second authorization element delivers on both user experience and Strong Customer Authentication (SCA) requirements. Biometric authentication is already in widespread use since it is convenient for users, easy to integrate, and works immediately. And most importantly, combining it with passwords PSD2 solution providers make validation more elaborate and so compliant with the Regulatory Technical Standards (RTS). Unfortunately, the technology is still immature in terms of hardware and this authentication factor is recommended for use on Apple devices only.
Another essential element of inherence is behavioral analytics. Checking the user’s location, time, or behavior against their typical patterns, financial organizations can gain a precise understanding of the risks and authentication levels needed. Since behavioral profiling is executed in the background, it doesn’t disturb the user journey and goes unnoticed by customers. It is a comparatively new approach, and today companies put it in place with the use of Data Science and Artificial Intelligence.
On Top of That Keep an Eye Open for GDPR Security Requirements
Introduced in the spring of 2018, the GDPR security statement has already changed the risk landscape substantially. The changes included design, accountability, and privacy reviews, along with high penalty charges for non-compliance. At that time, financial institutions already experienced challenges with data processing, growing number, and scale of cyberattacks, as well as public anxiety over individual data privacy.
Today’s wave of regulations, combined with GDPR data security policy, offers businesses a great opportunity to build powerful APIs with a maximum focus on security and privacy. Working on application programming interfaces cater to the following principles:
- treat privacy as an integral part of your software system and design;
- opt for data minimization and set maximum privacy as default priorities;
- stay proactive and try to foresee and prevent malicious events, instead of relieving the consequences;
As banks must have implemented Open Banking API and PSD2 standards by September 2019, it’s critical for all the players to have a comprehensive security strategy or partnership with a reliable fintech security company. Building an API from scratch offers particular opportunities since teams can turn security into their major business assets and promote a customer-centered mindset within the organizations. Most importantly, financial firms need to be dynamic and agile to keep pace with increasing customer expectations and advancing business goals.
Open Banking security standards can present numerous conveniences and benefits that have never existed before. Nevertheless, account holders must educate themselves on the accountability, integrity, and cybersecurity approach of any company or provider that they admit to their banking data.