Strong Customer Authentication (SCA) for PSD2 APIs

In the guidelines and framework released by the Berlin Group there is a lot of discussions about SCA and the need of this. They present three different main ways in how SCA can be developed and the differences between them. But what type is the most suitable approach for your application and API? Since you only need to implement one of them, if you don’t want them all, which should you choose?

In the graph below each of these 3 authentication methods is described in a simplified way.



Redirect uses the predefined redirect address in the authentication which redirect the user to e.g. a web interface where the SCA is done between the PSU and the ASPSP.

The good part with redirect approach is that the TPP don’t need any detailed information about the individual PSU. The redirect approach is therefore easy to implement for a TPP since they don’t need to implement anything regarding SCA methods in their interface against the PSU.




Decoupled is very similar to redirect with the difference that ASPSP is the one asking the PSU to authenticate itself. This can be done via e.g. a mobile app or any other application/device which is independent from their online banking front-end.

Just as for redirect this SCA method allows the TPP to skip implementing anything regarding SCA at their PSU to TPP interface. Since everything is done between the PSU and the ASPSP




Embedded approach demands more of the TPP in their interface against the PSU. Since they need to how to handle and present the information to the PSU in a good way. Embedded could also include a challenge part e.g. calculation of a OTP and then the TPP also needs to present this information in a good way to the PSU.

For the ASPSP this SCA approach offers a large number of authentication possibilities, since the challenge data could be based on several different methods, e.g. animated picture, black and white color matrix and so on.


 Download the NextGenPSD2 API Swagger