Account providers (or ASPSPs) that offer access via a dedicated interface are required to ensure that the interface does not create obstacles to the provision of payment initiation (PIS) and account information (AIS) services (together, "TPPs"). Whilst the SCA-RTS offers a couple of examples of what may constitute obstacles, it is not definitive and leaves the detail to competent authorities and the industry to figure out. Inevitably this has led to a great deal of head scratching, arguments and lobbying. After all, one man's obstacle is another man's essential security measure. Perhaps more than any other issue, the question of 'obstacles' has highlighted the inherent tension between open access, customer experience and data security that is at the heart of open finance.

The EBA's Opinion is an attempt to resolve that tension and define where to draw the line. And it is clear that the EBA has listened carefully to all the competing arguments and has sought to tread a fine line. The guidance is rational, sensible and balanced. And will probably please nobody. That in itself suggests the EBA has successfully found the middle ground!

We highlight below some of the significant points from the Opinion.

When is friction in the journey not an obstacle?

This is the key question that the EBA has had to grapple with. For example, if a bank's own logon process is slow and convoluted, can that be an obstacle in itself, or is it just a feature of doing business with that bank? The point of PSD2 was never to make it easier for accounts to be accessed or payments initiated via a TPP than when the customer does this directly, and neither was it to override an account provider's own security measures and checks. This is explicitly acknowledged by the EBA, who note that one measure of whether an interface imposes an obstacle is whether "the authentication procedure with the ASPSP is more cumbersome compared to the equivalent experience [users] have when directly accessing" their accounts.

So does this mean redirection is fine?

Yes (or maybe no!). The short answer is: it depends, but the EBA has confirmed (again) that redirection is not an obstacle in itself. If redirection allows the TPP to rely on all the authentication methods offered by the ASPSP (for the equivalent direct journey), it will likely be fine since – by definition – it is unlikely to add additional obstacles. Broadly, this means app-to-app or decoupled redirection is essential for those ASPSPs that offer an app, but that browser redirection is also fine where the customer journey starts in a browser with the TPP. ASPSPs should also enable their PSUs to use the ASPSP’s authentication app as one of the two-factor SCA elements in an AIS / PIS journey – where this is used for the direct journey.

When using a redirection or decoupled approach, as general guidance, the interaction between the PSU and the ASPSP should be minimised to what is necessary in order for the PSU to authenticate. No unnecessary steps or information should be required compared to the equivalent authentication procedure available to PSUs.

What about redirection at point-of-sale?

The EBA has previously confirmed that a PISP has the right to initiate the same transactions that the ASPSP offers to its own PSUs. That means where an ASPSP offers PSUs the possibility to perform instant payments at the point of sale directly, the ASPSP should allow PSUs to do the same using PISP services.

Otherwise, redirection is still ok (and the EBA confirms that there is no explicit requirement to implement an embedded approach), with the caveat that it must still support all the authentication procedures made available by the ASPSP to its PSUs, or be supplemented by other methods.

Surely having to authenticate the user more than once for one transaction is an obstacle?

Again, not necessarily, but ASPSPs need to test that any 'extra' SCA is essential – and that there is no unnecessary friction or additional step compared to the direct PSU journey.

More specifically, the EBA is of the view that:

• An AIS-only journey shouldn’t require more than one SCA.
• For a single payment initiation via a PISP, a single SCA (for initiating the payment) should generally be sufficient (as long as the PISP transmits all the necessary information to initiate the payment). An additional SCA for accessing account data isn’t required in this scenario because the data accessed by the PISP is limited to data specific to the payment being made (unlike a PSU initiating this directly, who would see other payment account data in their online banking).
• However, requiring two SCAs may not be an obstacle for the purposes of the SCA RTS where the ASPSP has justifiable security concerns (for example, a suspicion of fraud).
• Two SCAs may be required for a combined AIS and PIS journey without being an obstacle (eg where the user needs to access information relating to multiple accounts in order to select one before subsequently initiating a payment).

OK, but re-authenticating a user every 90 days must be an obstacle?

No. In fact, the EBA has confirmed that the requirement to apply SCA applies to each access, including access via an AIS provider, subject only to the limited exemption under Art 10. This seems to put to rest any suggestion that Art 36(5) provides an unlimited SCA-free access to accounts for AIS providers. Instead, Art 36 provides an exception to the rule that AISPs need active involvement of users but remains subject to the application of Art 10.

As a result, ASPSPs must re-authenticate users at least every 90 days, regardless of whether access is direct or via an AISP. This rule seems to apply at account level only though, and does not require re-confirmation of each AISP's right to access the account(s).

The EBA also confirmed that the obligation and responsibility under PSD2 to perform SCA lies with the ASPSP – ASPSPs can delegate to TPPs to perform this on the ASPSP's behalf, but they aren't required to do so. If they do, the parties need to be aware of the risk that this would be an outsourcing.

What about ASPSPs checking a TPP's consent?

Yes. This is an obstacle. It's the PISP/AISP's responsibility to ensure it has obtained the necessary consent, and ASPSPs shouldn’t check this or require a separate consent. Additional checks for corporate account users using AISP/PISP services are also an obstacle.

The EBA has however clarified that PSUs should still be able to request the ASPSP to deny a TPP access to their payment account(s). Maintaining a 'dashboard' showing active consents and permitting cancellation of consents is not discussed by the EBA but would seem to be on the right line of this guidance provided the user is not asked to review or re-confirm those consents periodically.

Finally, a definitive obstacle! And since additional registrations are explicitly called out in the RTS, they must be an obstacle as well?

Not so fast! According to the EBA, requiring additional registrations for TPPs to be able to access the PSUs’ payment accounts are only an obstacle if they go beyond what is "technically necessary" under the RTS in order to ensure secure access to payment accounts. By way of example, the EBA suggests it's ok to have pre-registration of the TPP's app if that is necessary to ensure a secure communication with the ASPSP. We can probably expect a lengthy debate to follow on when that is "necessary", and when it is merely highly desirable.

Summary and next steps

The EBA's Opinion is a valiant attempt to provide clarification on what constitutes an "obstacle" for the purposes of Article 32(3). It won't please everyone, and to some extent it was inevitable that they would fall between two stools, since different parts of the industry have taken at times wildly divergent views on the intent and effect of the RTS. On the whole, though, this Opinion ought largely to be uncontroversial and closely follows the text of PSD2 and the RTS where relevant.

National regulators should take the EBA's clarifications into account as part of their supervisory work and ongoing monitoring under the RTS. If obstacles are identified, national regulators should take action to ensure ASPSPs remove any obstacles as soon as possible.

The EBA will monitor the way in which these clarifications are taken into account and will take action to remedy any inconsistencies, in order to contribute to a level playing field across the EU.