The biometric behavior-based characteristics are appropriate, if all given security guidelines are taken into consideration. It is important that the final decision as to which form of credentials should be used for customer authentication, lies with the ASPSPs. If this is not the case, the question arises as to how ASPSPs can verify information given to them by TPPs and how the liability is regulated in the case of unauthorized transactions.
The current interpretation of the text of the directive implies that the authentication must be performed via different authentication channels to ensure independence (“the breach of one element does not compromise the reliability of the other”). However, having different authentication elements would limit the use of mobile banking as the PSU (Payment Service User) might not have access to other devices than the phone. It is therefore beneficial that the authentication factors are sent to a single device (e.g. mobile phone) rather than to multiple channels. It would be possible to separate the authentication factors at a software level to ensure security is not compromised.
Also, we note that paragraph 31 seems in contradiction with the definition of ‘independence’ of channels as it says: “For strong customer authentication the PSCs can be either a valid combination of these elements themselves or something which is only generated when all the elements have been provided (e.g. an algorithm in a chip produces a one-time password or cryptogram, based on a challenge responses where the PSU is asked for a PIN)”.
This would mean that the PSP only needs to validate a single factor for authentication if the second can be ‘presumed’. If this is the case, this would validate the usage of soft tokens and pin/private key technologies on the device as second factor and also satisfy the independence of authentication elements requirement.
We see challenges with respect to customer authentication using the dynamic linking feature. However, the extent of the challenge is unclear and depends upon clarity of Article 97(2).
If the intention of the dynamic linking is simply to ensure that a transaction/change cannot be repudiated once it has been authorized by a PSU (but this link information doesn’t have to be shown to the PSU), then the challenge would be to implement this dynamic linking for bulk transactions (e.g. a PSU initiate payments with different amounts to different accounts at the same time).
If the intention of the dynamic linking is to provide the PSU with an additional insurance that they are authorizing a specific transaction/change by showing them the changed/transaction values before (and/or after?) authorizing the change/transaction (e.g. via a pop-up message or a notification via another channel), then the challenge would be to display this information using current technology/device. This is especially a challenge for changes of fields that only contain textual information (e.g. mailing address), as the amount of information to be shown could be quite large. In case this intent is confirmed, a gradual transition from non-compliant devices to compliant devices should be allowed in order to avoid any disruption of service for the PSU.
Further explanations in regards with dynamic linking would be appreciated when drafting regulatory technical standards.
The clarifications provided are considered as useful examples but they are not seen as an exhaustive list. In fact, it is considered appropriate that the Payment Service User (PSU) could define his own exemptions directly with the ASPSPs (e.g. using “risk-related thresholds” per specific services). It would be beneficial that the agreed white lists (e.g. trusted beneficiaries or easy access to account information) will only be hosted by the ASPSPs.
