Shreyans Mehta, CTO, at Cequence Security discusses what the admonishment of Barclays and Lloyds means for Open Banking APIs
One of the promises of Open Banking was that it would level the playing field, making it possible for new entrants to compete with the banking behemoths but for that to happen there needs to be transparency. Any inaccurate information can skew the market and potentially disadvantage those that rely on that information to compete. So the news that the Competition and Markets Authority (CMA) recently reprimanded both Barclays and Lloyds for breaching the open banking provisions of the Retail Banking Market Investigation Order was significant.
Open Banking relies upon APIs (Application Programming Interfaces) to share data between banks, fintechs and trusted third parties (TTPs) to create a thriving digital ecosystem but it’s down to the banks to ensure those APIs are kept up to date. In the case of Barclays, it failed to do this thirteen times between November 2018 and August 2021, by not disclosing correct fees, interest rates and failing to list 47 ATMs, among other infractions. Lloyds similarly provided incorrect information ten times from March 2017 to August 2021, from failing to update credit card interest rates and cash withdrawal charges to broken links within the APIs to the terms and conditions of three of its bank account products.
Suitably chastened, both banks elected to take steps to try to prevent these issues recurring. Barclays opted to introduce manual controls, staff training and a process to update APIs in line with any changes to its service literature while Lloyds committed to more frequent, periodic checks, training and guidance, and asserted it will be moving towards an automated solution. But does the fact these issues occurred in the first place cast some doubt over the way that Open Banking APIs are managed? Are manual checks sufficient to stop it happening again? And what lessons does this hold for the industry as it becomes more dependent on APIs and moves towards Variable Recurring Payments (VRPs)?
A work in progress
Open Banking APIs adhere to regulations laid down in the European Union’s Payment Services Directive 2 (PSD2) which is mirrored in the Open Banking Regulation in the UK but it’s very much an evolving set of regulations. In June 2020, the European Banking Authority (EBA) took steps to ensure that the customer experience via the API was comparable with that the banks gave to their online customers. It gave national regulators the power to impose fines if access was hindered and it’s those fines which Barclays and Lloyds could have been hit with.
We also saw the EBA Working Group still thrashing out PSD2 just six months ago, with issues ranging from the lack of notification of downtime to TTPs, lack of support for embedded redirection, and the inability to conduct batch processing via APIs, listed among those items for discussion.
While the regulators are doing their utmost to both encourage and enforce the principles of Open Banking, the banks also have to play their part. What the above examples show us is that these organisations aren’t always aware of or in control of their APIs. Creating an inventory of active APIs is key to tracking and managing them effectively. This will allow the financial provider to assign ownership and determine the business function but it also allows APIs to be assessed for misconfigurations, coding errors or potential vulnerabilities and flagged for remediation. Are the APIs exposing sensitive data, do they have weak or poorly implemented authentication, are they in conformance with an OpenAPI specification? Moving towards a model of automated continuous monitoring is the only way to test APIs effectively to ensure the specifications are being observed and that data is adequately protected.
Future focus
Open Banking is the future but it is contingent upon how effectively APIs are managed and protected. The ecosystem which is just starting to become established will see banks able to partner with third parties to expedite loan applications, for example, or to monitor user behaviours and market trends to spot opportunities or even stamp out fraud. A key benefit of APIs is the visibility they confer, allowing the provider to spot anomalous activity, with APIs with push notifications able to alert the account holder and suspend activity.
APIs will also be crucial in the future rollout of Variable Recurring Payments (VRPs). These are expected to replace direct debits and allow consumers to ‘sweep’ or transfer payments between user accounts and, longer term, between the user and businesses. We can expect banks to commercialise their VRPs with TTPs, by setting up payment arrangements with ecommerce outlets or subscriptions, but for this to happen, banks will need to set up ledgers and have APIs that can be monitored, protected and updated in real-time.
It’s this real-time responsiveness that will determine the winners and the losers in the era of Open Banking. Being able to align or update services automatically and to protect API data will be crucial in determining which financial institutions are agile enough to thrive. Yet, for that to happen, the sector will need to start thinking about the complete API lifecycle, from establishing an inventory that maps to risk and compliance demands, to attack detection/prevention, to baking in security during API development.
