monogram with initials UKR

Better UX for PSD2 Strong Customer Authentication using Transaction Risk Analysis

Updated: Under: fintech Tags: #PSD2 #IAM #OpenBanking

One of the main highlights of PSD2 is Its keen eye on customer authentication, PSD2 mandates strong customer authentication[1] known as SCA in short. Even though It’s important to keep SCA on the driver’s seat, With an increased number of transactions by users it can quickly become a burden.

Photo by CMDR Shane on Unsplash
Image 1: Photo by CMDR Shane on Unsplash
Photo by CMDR Shane on Unsplash

Strong Customer Authentication

Strong customer authentication as defined by PSD2 is based on two or more factors of authentication. These factors are categorized into three main groups, Knowledge, Possession and inheritance[2].

‘strong customer authentication’ means an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) — PSD2

Icons made by Smashicons / Pixel perfect from www.flaticon.com is licensed by CC 3.0 BY
Image 2: Icons made by Smashicons / Pixel perfect from www.flaticon.com is licensed by CC 3.0 BY
Icons made by Smashicons / Pixel perfect from www.flaticon.com is licensed by CC 3.0 BY

The infographic above shows categories defined by PSD2 for strong customer authentication. In an example for Open Banking, a bank can opt into using user-name, password credentials(Knowledge) as the primary method and SMS one-time password(Possession) as the secondary factor.

User experience issues caused by SCA

With PSD2 mandating SCA in cases where a PSU (Payment Services User) may be heavily consuming open banking resources, SCA protected information will be presented with multi-factor authentication regardless of the action. As it’s now apparent how this can be a huge burden on the PSU.

Transaction Risk Analysis

Even though PSD2 has mandated SCA, it can be exempted using transaction risk analysis known in short as TRA. TRA is a contextual system where applying of SCA is determined by the risk of the transaction. Rules for TRA are defined in the regulatory standards document[3] for implementers to follow.

For example, in the case of a low-value transaction, SCA is exempted thus allowing the PSU to swiftly authorize. Thus increasing UX while not compromising on security.

**References
**[1] PSD2 — Article 97(1)
[2] PSD2 — Article 4(30)
[3] RTS — Article 18