Open banking, the new framework designed to offer a wider choice of financial services to customers by levelling the playing field between incumbent banks and fintechs, has been a gamechanger for the sector’s cyber-security. Once in full control of the whole customer journey, banks are now mandated to make account data, or even accounts themselves, accessible to third-party providers (TPPs). In this new set-up, banks and the fintechs they previously competed with become partners whose reputation and business success are mutually dependent.
Take the delicate touchpoints between banks, customer PISPs (Payment Initiation Service Providers) and merchant in e-commerce as an example. PISPs can initiate a direct credit transfer from the customer’s account to the merchant’s, making payments faster – and much cheaper for the latter. PISPs are the interfaces between the buyer, the merchant and the bank, but it’s the joint responsibility of the bank and the PISP to ensure nothing happens without the consent of the customer. Complex consent management mechanisms ensure that every aspect of the transaction is meets the customer’s approval: the accounts the transfer should take place between, the PISP to carry out the transaction, and so on.
Although an intricate system of encryption, using tokens and strong customer authentication (SCA), has been developed to guarantee the security of the open banking system, due diligence by banks and third parties are still essential. Unless the identities of the players are continuously checked by authentication processes and behavioural analysis, fraudsters will be able to impersonate customers, banks and third parties, and game the entire ecosystem. Using cross-site scripting (XXS) techniques they can add malicious content to vulnerable sites. They can clone log-in pages. By exploiting human psychology through social engineering, they can persuade users to share credentials and security tokens with them. And with the help of AI, even biometric identifiers such as voice can be susceptible to fraud.
APIs: a vulnerability at the heart of open banking?
The preferred method for banks to open up their customers’ accounts and data to third parties, and the only one which is SCA-enabled, is through APIs. APIs ensure that two applications can communicate with each other and exchange information over a network using a common language. They are often compared to waiters or messengers, as they “run” between applications, databases and devices. Banks have been using private APIs for some time now, but they are not exclusive to the financial sector. According to a OnePoll study, businesses currently manage 363 different APIs on average, the majority of which (69 per cent) are exposed either to the public or to business partners.
It comes as no surprise, then, that with APIs becoming ubiquitous, the number of attacks against them are also on the increase. Sloppy API endpoints can contain sensitive information such as login credentials and browsing history. But even well-designed ones invite a type of attack called credential stuffing.
Wednesday 7 August 2019 was a black day for the financial services sector, when financial services were targeted by more than 55 million malicious login attempts globally, according to a report from content delivery and cybersecurity company AKAMAI. Getting locked out of your account by simply typing in the wrong password twice is certainly irritating, but digital banking is a tricky balancing act between security and usability. Naturally, organisations that publish APIs go to great lengths to make them as usable as possible. Which means many of them don’t apply any rate limiting to their APIs, and allow unlimited log-in attempts. And good and bad requests that APIs receive look rather similar. Even APIs that throttle attempts can be played by a low and slow approach – the bombardment of a login page making sure the number of attempts doesn’t exceed the limit at any one time.
Although bots can send out tens of thousands of credentials in a minute, and can also mimic mouse movement, typing and clicking, the frequent change of cloud service providers and the use of proxy networks can be telltale signs.
Layered prevention systems
The apparent lack of a panacea for preventing cyber-crime in open banking is a strong case for a layered approach to security. Vulnerabilities in one layer of the system can be offset by the strength of other measures on another layer. And authentication in the case of transactions exempt from SCA can be strengthened by transaction risk analysis (TRA) monitoring factors, such as payment patterns and behaviours, location and devices used to detect fraudulent activity with the help of machine learning and AI.
The Confirmation of Payee scheme, essentially an account name-checking service that points out any discrepancies between account numbers and the names on the account, is an additional tool for preventing customers from lining the pockets of fraudsters. Another recent attempt to make APIs more resilient to attacks has been the establishment of the Financial-grade API (FAPI) standard by the OpenID Foundation, with a view to supplying online financial service providers with guidelines on how to implement an open, flexible and easy-to-use system with advanced security features. The first two businesses to achieve FAPI confluence last year were digital identity managing platform ForgeRock and Ping Identity. The certification is another major step towards a robust multi-layered open banking security system. And the more businesses earn it, the more robust the entire system will be.