PSD2 Question & Answer Forum

One of the goals of EBA in its RTS was to stay technology-neutral to provide as much room as possible for innovation. The challenge was to not be very prescriptive when specifying the requirements. Ultimately, no specific technology is banned by RTS, however, some of the existing practices are not going to be fully compliant with SCA requirements anymore. We can say that SMS can be seen as a possession element, as normally it can only be read by the intended recipient of the SMS message. So in theory, SMS fulfils the requirement for possession element, and it can therefore be used as a building block of a transaction signing solution.

In order to meet the Dynamic Linking requirements, the SMS message needs to include the payment information, i.e. the amount of money and information about the payee, besides the authentication code. The Dynamic Linking requirements also indicate that the confidentiality and integrity of the payment information needs to be protected. This could imply that the payment information needs to be encrypted. However, decrypting the content of an SMS message would require an app on the mobile phone's SIM card or on the phone itself, which is not practical.

In the end, the use of SMS implies having a high level of security for the user’s device, protection against SIM-swapping fraud, protection against possible SMS interception and misuse. In reality today, these are very difficult challenges. Different competent authorities currently have different opinions about the usage of SMS. Several authorities discourage the usage of SMS, while others allow it. We monitor these opinions and will update this FAQ when there is a clear decision.

According to PSD2, the authentication mechanism must be constructed from two of three possible authentication elements, i.e. something only the user has, something only the user knows, and the something only the user is.

The authentication code must always be used to authenticate a user. The authentication code must be generated by an authentication mechanism that is constructed from two of three possible authentication elements, i.e. something only the user has, something only the user knows, and the something only the user is.

3D Secure is indeed a protocol which can be used by PSPs to build a solution to comply with the SCA requirements for card-based payments.

The user receives the SMS message normally on a personal phone, so this would be a possession element.

PSD2 covers browser-based and mobile payments.

OneSpan's behavioral authentication is an extension to OneSpan Mobile Security Suite. Behavioral authentication allows to not only accurately and seamlessly prove the user’s identity, it can also spot specific behaviors, for example bot attacks. More info is available here.

Customers of OneSpan Mobile Security Suite can leverage their existing implementation by only adding new necessary components of the solution. To achieve the best combination of security and user friendliness, it is important today to combine all of the three elements: 

1. Mobile application security with client device data collection 
2. Multifactor & biometric authentication framework and secure channel for secure communication 
3. Fraud and risk analysis software for analyzing user inputs, devices, behavior and applying decision making in real time across multiple channels OneSpan's solution suite covers all these areas. 

More info on PSD2 compliance.

The Regulatory Technical Standards (RTS) on Strong Customer Authentication do not specify whether the biometric verification needs to happen on the client- or server-side. So both options are allowed.

At this moment, there is no formal certification program for specific products under PSD2. As such, it is not possible for OneSpan to obtain formal assurance. However, OneSpan discusses compliance of its products in informal ways with competent authorities in order to make sure we correctly interpret the RTS and to make sure our products comply.

OneSpan is not currently planning to do this. Additionally there is no formal certification program for strong authentication solutions under PSD2.

The dynamic linking requirements in the RTS state that the authentication code must be calculated over certain transaction information, including the amount of money and information about the payee (e.g. the payee's bank account number).

Additionally, the payer must be made aware of this transaction information. Finally, the confidentiality, integrity and authenticity of the transaction information must be protected at all times. Based on these requirements, we can say the following about using PIN-pad authentication hardware devices:

• This device provides a very high possession and knowledge elements security level 
• This device provides a way for the end-user to enter amount and payee details and include them in generating a unique authentication code 
• The user is aware of actions with such a device. Hence the hardware Digipass with PIN-pad, if used with transaction data signing mode, is compliant with dynamic linking requirements.

Yes, it is. The term “dynamic linking” is used by PSD2 and the RTS on SCA.

It is the responsibility of the PSP to perform strong authentication of its users. OneSpan can provide PSPs with products and services to perform strong authentication.

The final draft RTS does not require channel segregation anymore. As indicated in the comments in the final draft RTS, this language was removed from the draft RTS, because it was confusing.

For bulk payments, the authentication code must be calculated based on the total amount of money of all payment combined and based on the account numbers of all beneficiaries.

Today OneSpan provides authentication solutions to more than 2,000 banks worldwide, with various use cases, business needs, user groups, and regulatory requirements. This is possible, because OneSpan offers a very large range of solutions that can cover all possible needs. For example, OneSpan provides very simple to use PSD2-compliant devices with large screens, buttons, and even voice commands for elderly users: Digipass 301

Optionally, in the SWYS space, a popular option is to use one of the high-end devices with a robust rubber keyboard: Digipass 770

This device does not need thorough user input, only needs customer’s approval and short PIN entry. The user acceptance studies conducted by OneSpan customers show a very high adoption rate and essential decline in helpdesk calls from users when switching to this technology.

Our interpretation of the dynamic linking requirements in the final draft RTS is indeed that the payment information needs to be included in the SMS message for payment authentication.

This is most likely compliant with the final draft RTS.

In general, the Go-tokens do not generate authentication codes over payment information (such as the amount of money). For this reason, it cannot be used for Dynamic Linking, which is always required for payments above 500 euro.

In general, users can enter payment information, such as the amount of money and the beneficiary account number, into hardware tokens. This can happen via the keypad of the token, via a USB cable or by scanning a visual code. The hardware token can then use the payment information to calculate an authentication code according to the dynamic linking requirements.

“See What You Sign” on hardware tokens can be used to comply with the dynamic linking requirement, but it is not the only option. Displaying the data in a mobile app is very likely to be acceptable as well.

The final draft RTS states that, in case of bulk payments, the authentication code must be calculated over the total amount of money of the payments, as well as information about the beneficiaries of the various payments.

No, dynamic linking is not required for payments below 30 EUR, as long as the cumulative amount or the number of previous remote electronic payment transactions initiated by the payer since the last application of strong customer authentication does not, respectively, exceed EUR 100 or five consecutive individual remote electronic payment transactions.

That is our understanding as well.

The RTS on SCA provide minimum security requirements for authenticating users. In case of corporate banking, users typically perform payments of relatively high amounts. Therefore, we expect banks to protect their corporate banking applications with authentication mechanisms that are stronger than required by the RTS on SCA.

As indicated in Article 13 of the final draft RTS, SCA is not required for payments to trusted beneficiaries. For the precise conditions, please consult the article itself.

Article 10 of the final draft RTS states that payment service providers are not exempt from the application of strong customer authentication to payers who want to inquire about their balance or consult their payment history from the last 90 days if either one of the following conditions is met:

• The payment service user is accessing online their account balance or payment history from the first 90 days of paragraph 1 for the first time
   
• The last time the payment service user accessed online their payment history from the past 90 days of paragraph 1 and strong customer authentication was applied more than 90 days ago.

Article 13 of the final draft RTS allows the payment service provider not to perform strong customer authentication if the payer initiates a payment transaction where the payee is included in a list of trusted beneficiaries previously created. See Article 13 for the details.

There are two parts of this question:

• Each time the PSP is about to release its mobile app to the app market app shielding needs to be applied for the app to be protected. The good news is that the app shielding wrapping takes several seconds and thus it does not affect app release cycles of the PSP.
   
• Because the OneSpan Mobile App Shielding solution is regularly updated to defend against evolving mobile threats, it's also recommended that PSPs shield their apps with the latest release to ensure the highest possible level of protection.

OneSpan Mobile Security Suite provides a device binding feature that offers cloning protection for mobile apps.

The mobile device where the SMS arrives might also contain an authentication app (in the 1aa or 2aa scenario), where the SMS needs to be entered. This app would need to be protected using mobile app shielding.

In our opinion these are two equally safe approaches that ultimately rely on the same underlying technology of secure communication channel. We do see them being optimal with different usage models. Many of the banks will implement the authentication application that would work in the following configuration: 

When the transaction is initiated inside the mobile banking app, the App2App communication link will be established towards the authentication app installed on the same device. This provides the ability to switch between two apps automatically, which improves the user experience. 

When the transaction is initiated on the web browser from another device (PC or tablet), the PUSH notification will be sent towards the authentication app installed on the mobile device of the user. Alternatively, with almost the same user experience, the optical scan & sign process can be used. 

You can find more information about Cronto solutions here: Cronto Sign

For App2App with secure communication channel, the data exchange between the apps happens via backend in an encrypted format.

The sandboxing techniques of Universal Windows Platform (UWP) are similar to Android and iOS. UWP adopted many of the concepts from Android and iOS. Windows 10 Mobile allows running UWP apps only, so the sandboxing mechanisms are of comparable strength as Android and iOS here. Standard Windows 10 allows running both UWP and regular Windows applications, so the sandboxing is less strong than Android or iOS.

When the user is using a TPP app, most likely we see one of the following three use cases: 

• PUSH notification from the bank to the authentication app provided by the financial institution. This does not need specific integration between parties.
   
• App2App communication between a TPP app and authentication app provided by the financial institution. This requires minimal integration of authentication service between TPP and the financial institution. 
   
• Embedded mobile security framework into TPP app. This implies that TPP will not rely on the financial institution's implementation of the authentication but provide its own. 

In all three options, TPPs and financial institutions will need to collect data inputs from user’s devices and perform a thorough analysis across multiple applications, channels, and endpoints for complete risk assessment. The best option is to implement a dedicated risk software, such as OneSpan Risk Analytics, which provides: 

• Real-time detection of sophisticated fraud 
   
• Processing of large amounts of data points to detect abnormal user behavior, suspicious transactions, and atypical navigation in the payment application 
   
• Accurate risk scoring and threat mitigation across all common mobile devices (e.g. mobile phones and tablets) 
   
• Operations invisible to end users, mitigating fraud while providing the best possible user experience
   

Sandboxing is applied by the OS (e.g. Android or iOS) of the mobile device to every app running on the device. Mobile app shielding should be applied to the authentication app.

Yes, this is the case.

The Secure Communications functionality of OneSpan Mobile Security Suite provides the ability to create a secure communication channel between the app and the server, protecting the confidentiality, integrity, and authenticity of all payment information. OneSpan Mobile Security Suite comes with both client-side and server-side SDKs to establish the secure channel. In this way PSPs can easily set up a secure channel without having to manage the complexity of the secure channel themselves.

We recommend using standard HMAC algorithms, like HMAC-SHA256 or HMAC-SHA3.

The authentication app needs to be protected with mobile app shielding. The banking app may be protected, but it is not required in the final draft RTS.

Yes, we see this as a possible inherence element. The comments from the EBA to the final draft RTS also indicate that this is possible.

Yes, OneSpan Mobile Security Suite supports biometric authentication based on fingerprints, face scan, and the behavior of the user.

In case of bulk payments, the authentication code for SCA must be calculated based on the total amount of money of all payments combined and based on the account numbers of all beneficiaries. There are no specific provisions about TRA for bulk payments.

Yes, OneSpan Risk Analytics can be used to analyze transactions for different types of payment channels.

OneSpan Risk Analytics is available on-premise as well as in the cloud. The cloud version is hosted by OneSpan.

Yes, OneSpan Risk Analytics can perform transaction risk analysis according to the requirements in the final draft RTS.

Indeed, PSPs always need to use TRA even if they use SCA. TRA provides a second layer of security next to SCA. TRA is useful to protect against social engineering attacks, whereby an adversary tries to convince the genuine user to confirm a payment using SCA when the payment is actually fraudulent.

The final draft RTS states that the authentication procedure should include, in general, transaction monitoring mechanisms to detect attempts to use a payment service user’s personalized security credentials that were lost, stolen, or misappropriated. This applies to all authentication solutions, not just those in the 2aa or 1aa category.