Data sharing with ASPSPs will support A2ART2 implementation, says industry

by Project Open Banking

Share this post

The Payments Association’s members have recommended four short-term measures to the PSR to help define the functional requirements of account-to-account retail transactions (A2ART) without the need of additional regulatory or structural changes.

Representatives from companies such as Starling Bank, American Express, Nationwide, Visa, Mastercard, Bottomline, Clearscore, Vyne, Pennies, Tink, Eversheds Sunderland, Baker Botts and many more came together to discuss the future open banking model.

The Payments Association’s recommendations to the PSR on functional capabilities

Short term

  • More information to be passed about merchants from TPPs to ASPSPs, to adjust payment limits/transaction blocks – TPPs say they could provide this information to remove the transaction limits that have been imposed to prevent fraud.
  • Liability responsibility could be shared between sending and receiving ASPSPs (and in some cases PISPs) – some TPPs support a whitelist of their merchants but would want to share the liability to allow for higher transaction limits.
  • Exposed SCA journeys need to be made as intuitive as possible.
  • Increase the granularity of payment information and status codes from ASPSPs.


Long term

  • Consideration needs to be given to the impact on related areas like VRP, decoupled SCA, APP and payment fraud, and extended API access

Through series of workshops during August and September 2022, the Payments Association’s members discussed the four policy areas of interest regarding A2ART and the future open banking model.

According to the PSR, operational and technical standards of A2ART, as opposed to person-to-person A2A transactions, should meet the functional requirements for retail transactions. This, for example, includes the ability of the retailer to support subscription payments.

Following the Payment Systems Regulator’s (PSR) request to members for their comments on how A2ART2 should function and what the requirements should be, The Payments Association made seven short-term and three long-term recommendations across the four areas.

On the functional capabilities, members of The Payments Association suggested that:

  • More information on merchants should be passed from the third party provider (TPP) to account servicing payment service providers (ASPSPs) to adjust payment limits/transaction blocks.
  • Liability responsibility could be shared between sending and receiving ASPSPs (and in some cases payment initiation service providers (PISPs)).
  • Exposed strong customer authentication (SCA) journeys should be made as intuitive as possible.
  • The granularity of payment information and status codes from ASPSPs should be increased.
  • Consideration should be given in the long term to the impact on related areas like variable recurring payments (VRPs), decoupled SCA, authorised push payment (APP) and other payment fraud, and extended application programming interface (API) access.

Learning from the European example

Members say the PSR must take note of past mistakes by other regulators when it embarks on changes to A2ART because a reduced scope or a measure that lacks certainty will be of little use.

For example, the API Evaluation Group recommended in 2018 functionalities for APIs to achieve alignment to the PSD2, the RTS on SCA and SC and the European Banking Authority (EBA) Opinion, and to ensure good market-facing outcomes. From an initial list of over 100 functionalities, group participants reduced this number to 37, followed by the banks calling upon the EBA to decide which of these were explicit legal requirements. Eventually, only 23 functionalities were imposed and implemented.

“As a result, desired API functionalities which would have improved payment certainty and user experience have not been implemented,” The Payment Association’s members note. Discussions to include them are now happening but this extra effort could have been avoided.

“While the UK’s faster payments scheme is not as problematic as the EU example, whenever a payment is not executed instantly or there is no means of certainty of outcome, it limits use cases of A2ART, merchant acceptance of this new payment method, and transaction success rates,” say members. They warn that if this occurs with A2ART, it could limit the growth and acceptance of the initiative more broadly.

For A2ART to work as intended, members believe it is vital to provide certainty and confidence to merchants, end users, and PISPs. Open Banking defines a series of status codes, but not all banks have implemented them, such as the ACSC, which would improve clarity on why transactions succeed or fail.

“Ensuring payments certainty should be explored further in respect of the materiality of the issue to merchants, and what options there could be to improve impediments,” say members in their collective response to the PSR.

“Understanding payment status, why payments have failed, and removing uncertainty can help PISPs, ASPSPs, merchants and banks to provide many value-adds throughout the ecosystem, remove friction from payment flows, improve conversion rates, and ensure a good user experience,” they add. “Certainty is seen as more of a value-add than settlement.”

Industry change without regulation

A2ART starts after the purchase decision for a good or service at the point at which the retailer asks for payment.

There are multiple steps for A2ART, but these may not all be sequential. Nevertheless, A2ART needs the functionality (for ASPSPs, PISPs, retailers, or customers) for each relevant step to reduce payment failures, ensure payment certainty and a good user experience.

Not all changes require regulatory approval, though.

The known issue is that bank payment limits prevent high-value payment initiation service (PIS) transactions, such as for car purchases, holidays, investment, tax payments, and more.

“Some ASPSPs have been found to offer inconsistent payment limits, with some providing lower limits via PISPs than via their online banking channel,” members note.

Although the Financial Conduct Authority (FCA) has issued a letter regarding such limits, the industry has seen little improvement.

“These limits are partly being justified as a method of APP fraud prevention, [but] payments initiation has a lower APP fraud rate than manual bank transfers, evidenced by over 20 years of experience in Europe,” say members.

The Open Banking Implementation Entity’s (OBIE) new standards on transaction risk indicators (TRIs) have also not yielded the expected results either because adoption is voluntary for both ASPSPs and TPPs.

As such, members say more information should be passed from the TPP to ASPSPs, allowing payment limits and transaction blocks to be adopted. One of the blockers has been fraud liability, but TPPs and ASPSPs say a liability share on fraud could resolve this impasse.

This would provide fairer incentives for ASPSPs to raise their transaction limits. For example, if a merchant is fraudulent, a receiving bank has greater visibility of transactions across all payment channels for that merchant than the sending bank or the PISP, and therefore should hold or share the liability.

Some TPPs also supported a whitelist of their merchants where they had high confidence in their KYC, therefore facilitating an exchange of a liability share for higher transaction limits. The Payments Association has called on the PSR to investigate these points further.

Creating a better customer experience

Industry participants say several additional changes could improve the merchant and customer payment journeys, such as clearer information and a more intuitive SCA process.

For example, the PSR could consider how ASPSPs can offer consistent information and provide adequate details when PISPs initiate payments, such as resolving the unspecified payment error codes. Members say this could help the merchant and customer payment experience and build better trust in Open-Banking-enabled payments.

“The lack of payment status information keeps PISPs from understanding and communicating to both the payer and the merchant what the status of the payment is and if the payment has successfully been executed,” say members.

“Increasing granularity of payment information and status codes would not necessarily require new standards, but simply the further adoption of existing standards by ASPSPs,” according to member firms. “This could mean the adoption of the existing standards by non-CMA-9 ASPSPs, or that the CMA-9 and non-CMA-9 ASPSPs utilise standards to a greater degree than is currently the case.”

On SCA, members point out that a PIS does not enjoy the SCA exemptions for payments articulated in the regulatory technical standards (RTS) and the SCA journey should also be designed to be “as intuitive as possible, whether for merchant-initiated transactions, consumer browser experience or app-to-app redirect journeys”. However, an alternative could be to allow PISPs to innovate around the ASPSP’s provided SCA journeys by, for instance, allowing TPPs to create embedded or delegated SCA journeys.

Regardless, these short-term changes would need to be considered alongside long-term goals. The Payments Association’s members believe the PSR needs to consider how A2ART will impact VRPs, decoupled SCA, APP and payment fraud, and extended API access to be truly successful.

More To Explore


Are you a member of The Payments Association?

Member benefits include free tickets, discounts to more tickets, elevated brand visibility and more. Sign in to book tickets and find out more.


Log in to access complimentary passes or discounts and access exclusive content as part of your membership. An auto-login link will be sent directly to your email.

Continue reading

This content is only available to subscribers - please see instructions below!

Continue reading

This content is only available to members - please see instructions below!

Become a member to continue reading

Having trouble signing?

We use an auto-login link to ensure optimum security for your members hub. Simply enter your professional work e-mail address into the input area and you’ll receive a link to directly access your account.

First things first

Have you set up your Member account yet? If not, click here to do so.

Still not receiving your auto-login link?

Instead of using passwords, we e-mail you a link to log in to the site. This allows us to automatically verify you and apply member benefits based on your e-mail domain name.

Please click the button below which relates to the issue you’re having.

I didn't receive an e-mail

Tip: Check your spam

Sometimes our e-mails end up in spam. Make sure to check your spam folder for e-mails from The Payments Association

Tip: Check “other” tabs

Most modern e-mail clients now separate e-mails into different tabs. For example, Outlook has an “Other” tab, and Gmail has tabs for different types of e-mails, such as promotional.

Tip: Click the link within 60 minutes

For security reasons the link will expire after 60 minutes. Try submitting the login form again and wait a few seconds for the e-mail to arrive.

Tip: Only click once

The link will only work one time – once it’s been clicked, the link won’t log you in again. Instead, you’ll need to go back to the login screen and generate a new link.

Tip: Delete old login e-mails

Make sure you’re clicking the link on the most recent e-mail that’s been sent to you. We recommend deleting the e-mail once you’ve clicked the link.

Tip: Check your security policies

Some security systems will automatically click on links in e-mails to check for phishing, malware, viruses and other malicious threats. If these have been clicked, it won’t work when you try to click on the link.

Need to change your e-mail address?

For security reasons, e-mail address changes can only be complete by your Member Engagement Manager. Please contact the team directly for further help.

Still got a question?