First, a few acronyms as a reminder (and some new ones):
- ASPSP - Account Servicing Payment Service Provider
- TPP - Third Party Provider
- PSD2 - European Union Revised Payment Services
- AISP - Account Information Service Provider
- PISP - Payment Initiation Service Provider
- CBPII - Card Based Payment Instrument Issuer
A full glossary is available here.
Challenges with Open Banking
Open Banking set out a big challenge for banks to support the required interfaces in a timely manner. Conforming to a fresh set of requirements is not a simple task but neither is learning how to effectively and safely use a novel workflow. This reveals the second Open Banking challenge - furthering user education and developing good habits.
Complexity of Implementation
At the top level the Open Banking APIs can be viewed as having two main areas. First is the Open Data API - this allows banks to publish unrestricted information about services such as details of the account types they offer and any special deals. The second area is the Read/Write API, which has 3 distinct components:
- AISP - a TPP with access to this area is able to request customers to share their account details, balances, and transaction history.
- PISP - a TPP with access to this area is able to set up payments in accordance to consents obtained from customers.
- CBPII - a TPP with access to this area could provide advanced credit card services, for example, issue single-use virtual credit cards for online shopping and charge these back to the same bank account.
From a technical side, supporting the Open Banking API requires the bank to create a new inbound channel for account and payment access. While the specification defines the externally published interface to use, internal architecture and integration is up to the banks. This can be a task akin to developing internet banking or adding mobile banking from scratch - despite the backend banking platform remaining the same, it is a brand new frontend. Unless all required frontend actions are already processed through a common standardised internal API, implementing support for Open Banking can be a monstrous task of re-engineering the whole infrastructure. Furthermore, this could yield yet another stack of software for the bank to support internally.
Conversely, an existing well abstracted API for interacting with the backend services can reduce the complexity significantly - all that is needed is a thin frontend to support the Open Banking API syntax and any additional logic checks; validation of all interactions can be offloaded to already existing control logic. However, even in this case, it is not a simple feat to deliver a whole new externally facing interface while ensuring the absence of functional or security shortcomings.
Importance of Good User Interfaces
The user roles and security model for the ecosystem are sound, but the Open Banking model does bend the rules around the classical advice of "only trust your bank for banking". Let's have a brief look at how an end user could set up viewing their account balances through an account aggregation app. In a simplified description (the next post will include a more in-depth review of the process), a typical interaction flow is as follows:
- Customer decides to use the TPPs app and begins interacting with the TPP,
- TPP sets up a consent with the relevant bank to view the account balances for this user,
- TPP redirects the customer to their own bank with a reference to the created consent,
- Customer authorises the consent directly through their bank and gets redirected back to the TPP,
- The authorisation flow finishes, and the TPP now has access to the account balances,
- The customer can now view their balance from this bank through the TPP.
From this, we can see that customers are expected to interact with TPPs, but also to know from what exact point onwards they should only trust the bank itself. This problem of unclarity around handoffs to the user’s bank also affects 3D Secure – the technology used to verify online transactions. In our case, the risk is greater as Open Banking requires the customer to perform full authentication and offers vastly more functionality.
For someone not intimately familiar with the security model of Open Banking and the process of multiple hand-offs back and forth, this can easily be confusing. As usual, uncertainty among users opens the door for abusing the system.
It is in the banks' best interest to ensure that users only consent to what they wanted to. No matter with whom the legal responsibility for users unintentionally granting excessive consents lies, being known as the bank that helps mislead their customers is a label nobody desires. Banks need to make it clear to the user what they are consenting to and who they are granting privileges to - the user must be presented with the full details and consequences of the proposed consent. While a TPP’s goal is to have users grant them access, a bank must ensure this cannot be done under false pretences or by tricking the user.
Banks need to ensure users understand the authorisation flow of Open Banking, and know how to identify whether they have been securely handed over to the bank's site. Otherwise, a TPP could mimic a bank's consent authorisation page and harvest the user's credentials, for example, in order to authorise a wholly different consent. While the users are encouraged to interact with TPPs, a clear line needs to be drawn regarding what information should be kept only between the user and their bank.
Anatomy of the Threat
Sadly, it is not feasible to assume that all the TPPs will be as responsible as we'd like. The risk of a maliciously acting TPP is somewhat reduced as TPPs need to be regulated by a financial authority, however, this is not an insurmountable barrier for an advanced attacker. In addition to malicious TPPs, a legitimate TPP could become compromised due to a breach from a technical attack against them or through the work of malicious insiders.
A poorly set up application may be resilient to direct attacks, but could allow an attacker to automate interactions through the TPP, and rely on the legitimate TPP application features to enable fraud. For example, an attacker could attempt to gain access to a large number of bank accounts by asking for permissions to them via a TPP’s application. In this case, the victims would only need to be directed to the consent authorisation journey on their bank’s website. Although this attack requires consenting from each victim, a carefully planned social engineering campaign paired with a poor user interface from the TPP or bank websites makes this a feasible attack path.
Lastly, banks typically operate a robust and mature security governance regime, however, TPPs can often be recently founded startups. The TPPs may bring revolutionary business visions and ideas, but often will have less depth of experience in managing security risks. As such, it is fair to say that one of the many TPPs is more likely to suffer a major compromise than one of the banks.
Mitigation of the Risk
Ultimately, banks are responsible for addressing both of the above areas of concern:
- Weaknesses in the implementation of the APIs they expose;
- Attackers leveraging customer’s unfamiliarity of a new trust model.
This is not to say TPPs are off the hook – achieving the final result, a safe and healthy financial ecosystem, mandates that all actors put in their best effort. TPPs need to build secure applications; they also play a major role in developing user habits around interacting with Open Banking apps. TPPs need to collaboratively establish a consistent and recognisable pattern to ensure security for all participants. However, banks control the money (and data) and are thus the final gatekeepers. It falls upon them to monitor TPPs' behaviour and to make it difficult for anyone to abuse the platform. It is not acceptable for a bank to take a position of "the TPP is regulated, they are not a risk" or "if the TPP acts maliciously, their access will be revoked - not our problem". We need to create a nurturing society that helps users adapt to the emerging technologies without introducing undue risk.
Establishing a barrier to entry for TPPs limits the exposure of the system. Similarly, suspending or revoking access from TPPs associated with malicious activity helps contain attacks. Open Banking provides the public key infrastructure (PKI) and verification of each participating organisation. However, in a model where TPPs interact directly with banks, only the banks have sufficient information to make decisions about the legitimacy of a pattern of operations. Based on this, banks are able to react to an attack and inform Open Banking of a maliciously behaving TPP.
Naturally, there is a balance to be struck between preventative and reactive measures - relying on a well proven fraud prevention and detection mechanism can provide good additional protection. However, aggressively blocking TPPs based on false positive detections of malicious activity will only harm the platform. Every bank should treat any TPP (including their own, should they have one) uniformly as an untrusted external entity. Any interaction with the APIs should be scrutinised as it comes through an exposed service, much like for online and mobile banking web services. While the APIs require authentication, the set of authenticated users can be large and this is not within the full control of the bank. A bank cannot trust a TPP more than they would any other external entity.
As with any complex changes, there is an inherent security risk associated with new deployments. However, the human aspect of a new interaction model with banks can carry equally many risks.
Fundamentally, banks need to drive the development of answers to challenges spanning both of these areas to ensure the Open Banking ecosystem can thrive and flourish. To do so, they must work together with one another and the TPPs to discover the most effective ways of conveying critical information to customers and thwarting complex attacks trying to leverage the new platform.
The next and final post of the series will further examine the security and permission models underpinning Open Banking services. We will also explore some internal penetration testing tooling for assessing our clients’ implementations.