WIREDGOV

One key change is the expansion of the timeframe for Strong Customer Authentication (SCA) renewal for accessing Account Information Service Provider domains’ to every 180 days, up from 90 days in PSD2; something the FinTech sector have been long-calling for.

Europe introduces Payment Services Regulation (PSR1) following success of PSD2

• The new regulation covers strong customer authentication, open banking, and APIs
• Changes to the authentication renewal period
• Introduces need for permissions dashboard
• Strengthens access to APIs

Additionally, payment orders made by mail order or telephone order (MOTO) are no longer subject to SCA. The European Banking Authority will develop draft standards to specify the requirements and any exemptions from the application of SCA taking in to account criteria such as the level of risk involved in the service provided, the amount or recurrence of the transaction, or the payment channel used for the execution of the transaction.

The regulation also introduces accessibility requirements for SCA, ensuring that all customers, including persons with disabilities, elderly persons, and those without access to digital channels have a means to perform SCA. The performance of SCA shall not be dependent on possession of a smartphone.

The regulation also strengthens transaction monitoring mechanisms to improve prevention and detection of fraudulent transactions. Payment service providers are allowed to exchange unique identifiers with each other when there is sufficient evidence to assume that there was a fraudulent payment transaction.

However, the proposals do not change the list of payment services established in PSD2, and the list of exclusions remains largely unchanged.

Overall, these changes aim to improve security and accessibility for customers while also improving fraud prevention and detection and build upon the success of PSD2.

Liability

The liability provisions in PSR1 are much the same as in PSD2. For example, where a payment is made through a Payment Initiation Service Provider (PISP), the Account Servicing Payment Service Providers (ASPSP) must immediately refund the user, but if the PISP is liable for the unauthorised payment transaction, it shall compensate the ASPSP at its request.

A new measure has been introduced to check that the bank account number (IBAN) matches the account name. Payment service providers are required to provide users with a service checking that the unique identifier of the payee matches the name of the payee as provided by the payer and notifying the payment service provider of the payer of any detected discrepancy. Payment service providers will be liable if, when a credit transfer is authorised wrongly, they did not notify the payer of a discrepancy between the unique identifier and the name of the payee provided by the payer.

Permissions dashboard

ASPSPs are to provide users with a ‘permission dashboard’ integrated into user interface - to monitor and manage permissions they have given to AISPs and/or PISPs to access their data. This is the same as in the EU’s Framework for Financial Data Access (their open finance framework). 

Access to APIs

PSR1 introduces a new article dedicated entirely to ‘prohibited obstacles to data access’ and provides an extensive list of what these obstacles are. ASPSPs are required to put in place at least one dedicated interface to allow data exchanges with AISP/PISP, but there is no obligation to maintain another interface as a fallback. However, in the case of unavailability of the dedicated interface, ASPSPs must offer an alternative solution to AISP/PISP during the period of unavailability. Dedicated interfaces must use standards of communication issued by EU or international standardisation organisations. ASPSPs are also required to publish quarterly statistics on the availability and performance of their dedicated interface on their website, with success measured by the number of successful account information requests over the total number of account information requests. Additionally, ASPSPs must provide testing facilities to allow TPPs to test their software and applications used for offering payment services to users.