What are the penalties if PSP's don't comply with the new RTS regulations by Nov 2018?
PSD2 is a European directive that all EU member states need to adopt. Payment Service Providers need to comply with PSD2 requirements in order to be legally recognized as payment service provider with the right to provide services in the EU.
With the issue of the ECB recommendations in Jan. 2013, the ECB published an assessment guide in 2014. Do you expect a similar assessment guide will be issued by EBA on the basis of RTS on SCA and CSC?
We don’t have information that confirms or denies that the EBA would issue a similar assessment guide.
Is SMS compliant with PSD2?
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.
Can mobile and token be counted as two channels and be PSD2-compliant?
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.
When would you use the authentication code? Do you consider it as a second factor?
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.
Is 3D secure protocol for cards enough for SCA or is it mandatory?
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.
What category of the three elements of SCA can you give to OTP over SMS? Is this knowledge or possession?
The user receives the SMS message normally on a personal phone, so this would be a possession element.
Could you clarify the scope of PSD2? Is it only internet payments (browser-based online)? If not, what else?
PSD2 covers browser-based and mobile payments.
Can you tell us more on how you implement behaviour analysis? Is it an extension of DP4APPS SDK?
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:
- Mobile application security with client device data collection
- Multifactor & biometric authentication framework and secure channel for secure communication
- 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.
If the customer authentication for a PSD2 governed transaction uses biometrics, is there any guidance on whether the validation should happen server side or client side? In other words, can the facial, voice be stored on client side (i.e. mobile device) or does it have to be server side?
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.
Has OneSpan received formal assurances from ECB regarding the compliance of their tokens with PSD2 RTS?
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.
Do you intend to label each token model (e.g. DP310) with a PSD2 compliance indication?
OneSpan is not currently planning to do this. Additionally there is no formal certification program for strong authentication solutions under PSD2.
Are OneSpan pin-pad authentication hardware devices compliant?
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.
Is dynamic linking the same as transaction signing?
Yes, it is. The term “dynamic linking” is used by PSD2 and the RTS on SCA.
Does this mean OneSpan supplies the dynamic linking, rather than a seperate entity, such as the PSP?
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 RTS requires channel separation between the app that will use the OTP and the OTP transmission. How do you see 1AA compliance?
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.
How do you comply with the requirement in article 2(2) A) when a customer makes several payments together to different payees?
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.
Does OneSpan have solutions to generate dynamic linking in cases where customers are not willing to use smartphones?
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.
For SMS based authentication, in the case where the 3DS process is used, where an ACS generates the OTP and distributes to the cardholder registered mobile number, do we still need to include the payment details (e.g. beneficiary account number, amount, etc.)?
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.
We have a hardware Digipass 275 with 5 numbers that can be used as a challenge response for dynamic linking. Is this compliant for dynamic linking?
This is most likely compliant with the final draft RTS.
Is the OneSpan Go 6 Digipass compliant with RTS with regards to the dynamic linking requirement for high value payments?
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.
How do hardware-based solutions, such as OTP tokens, provide dynamic linking with single transactions?
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.
Does the PSU have to see the payment details (amount and account) on the token? What you see is what you sign?
“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.
Could you be more specific about multiple transaction signing/authorization possibilities? Does dynamic linking allow multiple transactions / beneficiaries?
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.
Is dynamic linking still necessary for payments below 30 euro in case of transaction monitoring solution implementation?
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.
If exemptions are used, is it correct that SCA in total can be skipped and not just dynamic linking?
That is our understanding as well.
What is OneSpan's opinion of the RTS for corporate banking?
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.
What are the requirements if the customer already has a list of beneficiaries certified with SA but has to make a money transfer with a different value?
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.
To access payment accounts, the RTS allows single factor authentication only after the first time. Access performed with a valid 2 FA should be performed again every 90 days. This is not what you have been presenting, could you explain?
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.
Can payments be whitelisted? If we validate destination for the whitelist and then we allow payments without DL to that destination, should it be sufficient?
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.
Does OneSpan Mobile App Shielding need to be repackaged with the mobile banking app each time there is a version upgrade?
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.
Does app shielding cover the cloning protection?
OneSpan Mobile Security Suite provides a device binding feature that offers cloning protection for mobile apps.
Do you need mobile app shielding when using an SMS solution? SIM app?
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.
Is there any additional security concern with APP2APP implementation vs push?
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.
Do you see the universal windows platform (UWP) and windows tablets as a viable solution platform for SCA in a 2AA or 1AA setup? Is the sandboxing different from iOS/Android?
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 transaction in initiated from TPP APP, which of the presented use cases seems most likely to be used?
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
If two-app authentication is used, do both mobile apps need to use sandboxing OS and mobile app shielding?
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.
Is digipass SDK available/compatible with nativescript?
Yes, this is the case.
Could you elaborate on the secure communication offered by OneSpan Mobile Security Suite? What is used to secure it? What is required on the server?
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.
If the hardware identifier, fingerprint, and pin need to be combined for an application, is there a recommendation for an HMAC algorithm?
We recommend using standard HMAC algorithms, like HMAC-SHA256 or HMAC-SHA3.
To be compliant in 2AA situation, do both apps need to be protected by mobile app shielding? Or only the authentication app?
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.
How do you see the usage of behavioral parameters as authentication factors?
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.
Does OneSpan have a solution to use the 'inherence' factor (biometrics) as authentication element?
Yes, OneSpan Mobile Security Suite supports biometric authentication based on fingerprints, face scan, and the behavior of the user.
Can you discuss TRA for bulk payments?
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.
Can a prevention solution by OneSpan gather all types of transactions, including: e-banking, card, pos, mobile banking, wallets etc.?
Yes, OneSpan Risk Analytics can be used to analyze transactions for different types of payment channels.
Is the OneSpan solution a cloud-based solution? And if yes, private or public?
OneSpan Risk Analytics is available on-premise as well as in the cloud. The cloud version is hosted by OneSpan.
Is OneSpan Risk Analytics compliant with RTS requirements?
Yes, OneSpan Risk Analytics can perform transaction risk analysis according to the requirements in the final draft RTS.
Do we understand correctly that all PSP's need to have TRA, even if they plan to use SCA for all transactions? if so, what is the rationale behind this requirement in your opinion?
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.
Do the directives or guidelines define certain mandates for 2AA and 1AA solutions in case the physical medium is lost or stolen?
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.