SWIFT believes that possession elements can indeed be in data form. In the event that they are in data form we would, however, recommend that other means of authentication are used in combination with them and that mitigating controls are established to avoid dependence on any single form of authentication. Examples of such controls include: the restriction of data that can be used at the payment service user’s (PSU) premises; the stringent control of access to the data; a requirement for a second person to approve a transaction; and limiting transactions to a maximum value based on risk.

Yes, we agree that behaviour-based characteristics are appropriate and can complement inherence, knowledge, and possession elements. Anomalies in normal patterns of behaviour during the customer authentication process can be particularly helpful in identifying fraudulent activity.

The practicality or convenience of some authentication methods can lead to over-dependence on them. An example includes the use of SMS for verification by the same mobile phone that was used to make the payment. This type of over-dependency can be difficult to avoid but it should be managed as far as possible. An ideal customer authentication process would include several independent methods of authentication, used in combination with each other.

It is impractical to require a PSU to confirm the amount and payee for each transaction when making bulk payments. In this situation, dynamic linking should be applied to the aggregated amount, rather than to each payment amount individually.

Yes, the clarification suggested is useful. We suggest that a common baseline of personalised security credentials should be defined and protected, but how they should be protected should be left to the discretion of the Payment Service Provider.

Obsolete personalised security credentials should be safely destroyed so that they cannot be reactivated and re-used.

No, we cannot suggest an alternative to a third-party review that would provide the same level of assurance.

We believe that the clarifications outlined in paragraph 63 are comprehensive and suitable. We would also recommend that a minimum baseline set of requirements is specified, although how they should be met should not be specified.

The clarifications suggested should not be too restrictive, particularly as regards the underlying technology. This will keep costs down where systems already meet the minimum set of requirements.
Specifying standards is helpful, as long as the standards are common and open, and thus do not hinder innovation.

We agree that that e-IDAS regulation could be considered as one of the solutions for facilitating strong customer authentication, however it should not be the only solution as there may be other ways to achieve strong customer authentication.

Strong Customer Authentication based on the use of (personal) credentials is key, and is well addressed by e-IDAs. Indeed, under the e-IDAS regulation, the use of electronic seals partially addresses risks related to confidentiality and the integrity of personalised security credentials, whilst the electronic signature seal creation device gives some degree of assurance on the confidentiality and accountability electronic signatures. The protection of personal credentials to ensure their validity over time is, however, equally important to consider – and is an element that is not covered the e-IDAS regulation. This element should be further addressed.

On the other hand, the e-IDAS regulation is quite specific on how technical solutions should be implemented. Our recommendation is that any further guidelines on how strong customer authentication should be achieved should be sufficiently flexible to allow the industry to develop innovative and varied solutions.