Could open banking have a ‘de-risking’ moment?

null
Jack Wilson, VP Policy & Research
7 Mar 2023
Hand pointing at a finger print icon

As Authorised Push Payment (APP) fraud continues to rise, the Payment Systems Regulator (PSR) has proposed measures to make banks more liable for losses suffered by consumers. 

But the impact could be felt more widely than on fraud numbers.

New regulatory measures could inadvertently stifle competition in payments and hold back open banking in the UK.

In this blog post, we look at:

  • how open banking providers rely on banks to make payments

  • why new regulations could result in harsher fraud interventions by banks

  • the unintended ‘de-risking’ effect these interventions could have on open banking payments


Open banking providers rely on banks 

Open banking is part of a regulatory movement that started 20 years ago, to encourage competition and innovation by empowering non-banks to compete in payments and banking services. 

In 2007, the first Payments Services Directive (PSD1) brought about a new category of ‘payment institution’. The catch? These payment institutions had to rely on the very banks they were competing with, to gain access to payment systems. Payment institutions needed bank accounts

All was well at first, until the financial crisis of 2008 led the banks to reconsider the services they offered and in some cases close down accounts entirely (so called ‘de-risking’). 

This was felt acutely by many payment institutions – particularly money transmission services and fintechs. 

This became such a problem that in 2016 new requirements were introduced in the second Payment Services Directive (PSD2) to ensure ‘non-discriminatory’ access to bank accounts for non-bank firms. 

PSD2 also continued the aim of fostering competition in payment services, by supporting a new class of ‘payment initiation service providers’ – PISPs – which today power open banking payments. 

But PISPs rely on banks even more fundamentally than payment institutions:

  • They're reliant on the application programming interfaces (APIs) that banks provide. If a bank’s API goes down, so does the PISP’s service. 

  • Their role is to ‘initiate’ payments (submit payment orders to banks on behalf of customers). The bank is then responsible for executing the payment (actually making it happen). Banks retain the right not to execute the payments, for example, if they suspect fraud or if their policy doesn't allow transactions over a certain value. 

How banks’ risk appetites affect open banking 

Because a PISP’s role is only to initiate payments and not to execute them, ultimate liability for open banking payments rests with the customer’s bank. If an open banking payment goes wrong or if there is fraud, the bank will likely need to refund the customer. 

This means that any general fraud prevention approach a bank has, such as for online banking, is also applied to open banking payments. 

For example, as part of fraud prevention measures, some banks limit daily online banking payments to £25,000, while other banks limit them to £2,000 for new payees. These limits are also applied to payments made via open banking. 

This creates a very inconsistent picture for a PISP trying to provide payment services to businesses, such as savings or investment platforms or high value ecommerce (eg car retail). 

Depending on who the businesses customer banks with, they may or may not be able to use open banking to make payments. 

This has an impact on the competition objectives of open banking. Open banking can offer a more cost-effective payment option to business than, for example, card payments. This is especially the case for high-value payments. But with high values (typically £2,000 and above), more open banking payments are being blocked.

Same activity, same risk?

Applying the same transaction limits across both online and open banking channels, ignores the fact that open banking payments have a lower risk profile to online bank payments (manual bank transfers).

Manual bank transfers, where customers are asked to note down a sort code, account number and reference, and manually input all these details into online banking, are vulnerable to: 

  • Scams: where a customer is tricked into inputting the payee details of a fraudster instead of their intended recipient. There were £479m worth of these so called  ‘authorised push payment’ (APP) scams in 2020.

  • Misdirected payments: where a customer mistypes the payee details and the money goes to the wrong place. Misdirected payments have long been an issue, with the UK Financial Ombudsman signalling its concerns back in 2014.

But, when customers choose to pay a business using open banking

  • The customer doesn't need to enter payee details. This removes human error and the risk of customers being tricked into sending money to a fraudster. The PISP controls where the money goes.

  • The regulated PISP onboards and carries out due diligence with the business receiving the payments. They enter into a commercial contract with that business and undertake due diligence, reducing the likelihood that bad actors will use open banking to commit fraud. 

Could incoming regulation lead to a ‘de-risking moment’ for open banking? 

As part of measures to combat APP scams, the Payment Systems Regulator has consulted on a range of measures, including ‘requiring reimbursement in all but exceptional cases’ by banks. 

Measures are clearly needed to combat APP fraud, which can have a devastating impact on victims. But there also needs to be more consideration of the unintended consequences such measures could have on open banking. 

If banks are liable in more circumstances for APP fraud, they might further decrease transaction limits and block more payments, as part of preventative measures. 

If this ‘de-risking’ is passed on to open banking, it will be more difficult to deliver cost savings to businesses, a consistent service to customers and the competition that open banking was intended to create.

What’s the solution?

In a recent report, the Trustee of OBIE set out some proposed solutions to address the impact of ‘fraud interventions by banks’ on open banking. We agree with the Trustee’s recommendations to: 

  • Remove equivalence: the payment limits banks apply to manual bank transfers would not automatically be the same as those applied to open banking payments. As we've highlighted above, open banking can be a solution to APP scams. 

  • Develop whitelists: whitelists shouldn't be limited to payees that are government departments. Regulated open banking providers should be able to add beneficiaries to whitelists based on meeting due diligence conditions. 

  • Implement transaction risk indicators: these will be an important mechanism for PISPs to share information with banks about payments being initiated. But we need an industry approach to ensure that enhanced information sharing doesn’t result in new types of ‘de-risking’, where, as the Trustee highlights, banks apply blanket (not risk-based) approaches and block certain categories of beneficiary. 

These proposals could all help to reduce the impact and prevalence of transaction limits on open banking payments.

But as long as banks remain ultimately liable for payments initiated by PISPs, they’ll continue to block and limit payments, and PSPs won't be able to intervene.  

A long-term solution might be to shift liability for payments from the bank to the PISP, under an agreement with the bank. 

This is not unprecedented. In card payments, liability for a payment can be shifted from the issuing bank to the acquiring bank or vice versa. But, there are a number of regulatory and operational hurdles to overcome, to make such a shift possible in open banking. 

The UK and EU are undertaking major reviews of payments regulation, including open banking. Now’s the time to re-evaluate access to payment systems, including via open banking, and to address fraud risks in ways which don’t inadvertently impact competition. 

Insights straight to your inbox
Join 10,000+ subscribers getting the latest open banking news.
Latest
checkout
6 Dec 2024

3 tipping points for change within ecommerce payment experiences

Cart abandonment
2 Dec 2024

How to reduce ecommerce cart abandonment

dev sec ops shared responsibility
27 Nov 2024

Devising a delegated alerts model for SecOps

Categories to explore