Editorial Consultant, Treasury Management International (TMI)
Practical Use Cases for Open Banking
While it remains something of a mystery to many corporate treasurers, open banking is much more than a collection of acronyms and regulatory endeavours. In fact, it is the basis of an evolving financial ecosystem that holds significant potential benefits for modern treasury departments. Here, two senior leaders from Barclays Corporate Banking dispel the myths around open banking and outline practical ways to leverage its opportunities, while streamlining treasury operations.
Open banking might seem like a relatively unexplored concept in the corporate treasury world, but it first came into the spotlight in 2013 – the year that Angela Merkel won her third term in office and David Cameron promised UK voters an in/out referendum on EU membership. At that time, the challenge facing payment regulators was that the existing framework did not adequately regulate new players in the online payments space. Something needed to change, and so the European Commission published its long-awaited proposal for a revised Payment Services Directive (PSD2).
Daniela Eder Head of Payments & Cash Management Europe, Barclays Corporate Banking
The aim of PSD2 was not only to better protect customers online but also to promote innovation in digital payments, whilst also improving cross-border EU payments. The final directive required financial institutions (FIs) to comply with a number of changes by 2018. This included enabling regulated third-party providers (TPPs – see box 1) to access customer data held by the bank via application programming interfaces (APIs), in order to develop new apps and services. Thus, open banking was born.
BOX 1 - What do TPPs do?
Under PSD2, TPPs are regulated entities, many of whom are ‘fintechs’, that provide online payment services. TPPs fall into three broad categories:
BOX 2 - Consent and API security: busting myths
TPPs can only perform the above services with the express permission of the account holder. Every payment initiated by a PISP must be consented to on a transaction-by-transaction basis. AISPs are permitted to request data on behalf of a client that has consented for 90 days. At the end of that period, the client must consent again if they wish to continue using the services of the AISP. This ensures that consent is always proactively given and that, ultimately, the corporate remains in control of their data.
It is also worth noting that the APIs that form the backbone of open banking are highly secure. APIs are a tried and tested technology and they have been widely used in other areas before becoming popular in the treasury sphere.
Although the UK is recognised for leading the way and establishing an Open Banking Implementation Entity in 2016, mainland Europe swiftly followed suit. Countries across the globe, including the US and Singapore, are also now embracing the concept of open banking.
The true incentive
While the history of open banking helps explain its current function in the corporate world, what is arguably most important to understand is that open banking is about much more than confusing terminology, new payments ‘plumbing’ and regulatory compliance.
Daniela Eder, Head of Payments & Cash Management Europe, Barclays, explains: “If you look beyond the acronyms, open banking is about banks and fintechs working together [see box 3] to empower a global community of developers and innovators, while enabling retail and corporate customers to access new products and services – in a frictionless manner. It’s also about opening up new opportunities and efficiencies for all.”
BOX 3 - Valuing fintech and bank collaboration
While ‘collaboration’ has become something of a buzzword, it is one that holds great value in the open banking world, where traditional workflows and proprietary innovation habits are being disrupted. According to a survey conducted by Barclays at Money 20/20, 22% of respondents see a strong role for partnerships between start-ups and established players as the source of such disruption in the payments space. There is also a potential opportunity for fintechs to help financial institutions (and regulators themselves) with regulatory monitoring and compliance in the open banking era. As such, treasurers looking to leverage the full benefits of open banking may wish to engage in dialogue with banks and fintechs that already have successful collaborative partnerships in place, as well as banks that are consistently reviewing the fintech market for future fintech partners.
Source: Alive to Opportunity Report – Barclays
This is especially true in the corporate treasury sphere, says Maarten van Rossum, Head of Global Sales, Financial Institutions Group, Barclays. “From a treasurer’s perspective, open banking offers an alternative conduit through which they can undertake their primary cash management requirements, ranging from payment initiation to balance and transaction reporting and liquidity management, across their various banking partners. It is an alternative, or additional, means to traditional integration routes such as SWIFT, Host-to-Host and EBICS. The idea is to make it easier for treasurers to perform their daily tasks in a seamless way, by aggregating data and enabling essential tasks to be carried out with fewer touchpoints.”
Maarten van Rossum Head of Global Sales, Financial Institutions Group, Barclays
It is understandable, then, that almost half of treasurers (47%) responding to the TMI and Barclays 2021 European Benchmarking Survey are excited by the opportunities that open banking presents (see fig. 1). But what exactly can treasurers expect in concrete terms from open banking? How might their day-to-day lives change for the better?
Use cases for open banking
One of the most obvious use cases for open banking in treasury and the wider finance function is streamlining accounts payable with the support of a PISP. Van Rossum explains: “In simple terms, PISPs enable treasurers to initiate payments from an account with their banking partner(s) without the need to directly use a bank’s channels. Instead, the treasurer can use an application provided by the PISP or use another software package that is supported by the PISP.”
Fig 1 - What opportunities do you see arising from regulatory change?
He continues: “Imagine a company that uses a dedicated accounts payable (AP) software package. Within that package they can see invoices that are due and payments that need to be made, but typically they can’t initiate those payments from there – they must switch across to their banking portal and manually re-key all of the details to make the payments. But if the corporate engages the services of a PISP that supports that software package and has an API to the bank, they can instruct the bank to move money without leaving the AP software.”
Eder elaborates on the benefits: “Rather than using a tedious and error-prone manual workflow, the corporate can simply consent to the required payments within the AP software package and the PISP will send the instructions to the bank automatically. There is no need to switch applications, which is much more efficient. Having fewer touchpoints also results in a smaller window for fraud, cybercrime and human error.”
Another practical application for open banking is around consolidation of bank balances and transactions via an AISP. Van Rossum comments: “Treasurers who have a manual set up often spend a great deal of time downloading Balance and Transaction Reporting (BTR) information from their bank’s online channel into their accountancy software. This activity is a drain on resources – and often takes up the crucial first hours of a treasurer’s day. It’s also a task that has no value in itself; it is a purely manual function and a means to an end.”
If the accountancy software provider became an AISP, or used the technical services of an AISP, however, the corporate could simply consent to the AISP collecting that data on their behalf. “Once consent is given by the corporate, the AISP can collect the data up to four times per day for the next 90 days [see box 2 above]. So, when the treasurer comes in each morning, the accountancy software could already be updated and ready to go. This would free up the treasurer to focus on more value-added strategic tasks, resulting in efficiency and wellbeing benefits,” he observes.
An additional use case for corporates in certain industry sectors could be to become an AISP and/or PISP themselves. “There are two sides to the open banking coin – the account holder and the TPP. Becoming a TPP could be useful if a corporate needs to gather BTR from their clients – as accountancy firms and auditors do, for instance. As an AISP, the firm could enable the end client to consent to seamless collection of the required information, all via API. In turn, the effort on the customer side is reduced and the customer experience is improved,” notes Van Rossum.
Elsewhere, by becoming a PISP, or using the services of one, a retail-focused corporate could offer customers the ability to consent to payment direct from their bank at the checkout as an alternative to card payments or payment wallets. “This means that the customer no longer has to enter their card details or other information, they simply consent to the payment being made by their bank – ensuring that the checkout process runs smoothly,” comments Van Rossum.
Security rules
While there are many more potential use cases for open banking in treasury, the golden rule that binds them is seamless integration. Eder comments: “Integration is something that treasurers consistently seek since they typically deal with disparate systems and banking partners. Yet, integration can also be a source of concern as treasurers naturally worry about other parties having direct access to their data. Although third parties are involved in the open banking model, the corporate always remains in control of the relationship, and of their data. This is paramount.”
The security of open banking APIs is also tightly controlled, thanks to the Regulatory Technical Standards (RTS) for Strong Customer Authentication (SCA) which accompany PSD2. In practical terms, this means that TPPs must offer two-factor authentication as a minimum, adhering to at least two out of three SCA points of proof: knowledge, possession and inherence.
Fig 2 - Potential use cases for open banking
Source: Alive to Opportunity Report - Barclays
‘Knowledge’ typically refers to a password or PIN. ‘Possession’ might be a token for authentication or the possession of a device known to belong to the user. ‘Inherence’ usually involves a fingerprint, face recognition or voice recognition – essentially a characteristic that is unique to the user.
“Often, TPPs use existing bank credentials to pass these security checks. So, using a TPP offers the same level of security as going direct to the bank,” explains Van Rossum. “What’s different is that open banking adds another layer of connectivity and efficiency that simply has not been possible in the past. It’s a huge step forward.”
Eder adds: “For corporates that do not currently have SWIFT or a Host-to-Host connection, open banking and/or direct bank APIs [see box 4] could truly be a game changer. They offer a ‘lite’ version of more traditional integrated connectivity routes, and significant efficiency gains can be made with minimal budget and resources.”
BOX 4 - The direct-to-corporate route
Of course, not every corporate will have a business need for open banking. It will depend on the business and its current and future needs. But even for those corporates that do not require open banking services, or are not yet ready to adopt them, APIs can still be of use.
Van Rossum elaborates: “The move towards open banking has accelerated conversations about the use of APIs as a customer-facing tool in the corporate world. With this in mind, some banks are looking at providing APIs directly to clients who don’t necessarily have a need for open banking but who still want the efficiency and integration that open banking can provide. In this scenario, there is no third party – the API is operated by the bank and integrates directly with the corporate’s TMS or ERP.”
This evolution in corporate/bank connectivity via APIs will offer new alternative integration options to established channels such as SWIFT and Host-to-Host. He comments: “One example could be a payment initiation API, allowing corporates to initiate faster payments from their own workflow tool. Another is a BTR API, which enables data to be transferred directly from the bank into the corporate’s back-office tool in real-time.”
Meanwhile, for those that already have SWIFT or a Host-to-Host connection, there is no reason why, where appropriate, APIs cannot be added to the existing set-up to deliver further efficiencies. Eder notes: “We are entering the era of instant treasury, meaning that practitioners must have actionable insights at their fingertips 24/7/365, and be able to move money at the touch of a button. No treasury department can afford to ignore the potential operational benefits that are on offer through open banking – or the API revolution that it has sparked within the global treasury community.”
Barclays Bank Ireland PLC is registered in Ireland. Registered Office: One Molesworth Street, Dublin 2, Ireland D02 RF29. Registered Number: 396330. A list of names and personal details of every director of the company is available for inspection to the public at the company’s registered office for a nominal fee. Barclays Bank Ireland PLC is regulated by the Central Bank of Ireland.
This article is intended only for an audience in Europe. Where readers are present in the UK it is only intended for persons who have professional experience in matters relating to investments, and any investment or investment activity to referred to within it are available only to such persons.