Strong authentication
Strong authentication is defined as a procedure for the validation of the
identification of a natural or legal person based on two or more elements
categorized as knowledge, possession and inherence. These elements are
independent, in that the breach of one does not compromise the reliability of
the others and is designed in such a way as to protect the confidentiality of
the authentication data.

The concept of strong authentication is in itself nothing new. What is new
however, is its appearance as a detailed regulatory requirement. So far, both
the Payment Services Directive and the Electronic Money Directive contained a
more generic requirement for licensed operators to demonstrate that their
governance arrangements, control mechanisms and procedures are proportionate,
appropriate, sound and adequate. This allows for a system wide
supervisory review of risks and security measures.

The current approach in both the envisaged PSD and Recommendations of the
supervisors in Europe is however to take out and stress one element of the
risk/security puzzle. This approach may turn out to be counterproductive and be
an impediment to achieve retail payments that are as secure, efficient and as
frictionless as possible.

Different market approaches to customer
authentication
Traditionally the banking sector and card schemes have played a major role
in the payments industry. For a long time they acted as the main channel through
which new technological developments were introduced. In this process, strong
authentication in a range of countries became a standard for use in payments.
Further security measures for use in transactions over the Internet were then
being developed as an add-on to the basic design.

More recently, Electronic Money Institutions (EMIs) and Payment Service
Providers (PSPs) have entered the payments value chain using the Internet
as their basic transaction processing initiation channel. As a result, their
approach to payment security tends to be based on a variety of methods, to be
able to counter a range of attacks associated with this inherently unsafe
environment. PSPs have had to move very quickly up the e-payment security
learning curve and found out that they must remain vigilant with respect to new
threats. PSPs are consistently using additional information (geo-location
information, IP address matching, IP address pattern detection, industry blacklists,
comparison against a customer’s existing “profile” etc.) to validate the
interaction with a user.

There is still much to gain by combining the expertise of both the “classic”
and more recently-established providers of payment services. Customers will be
using all kinds of devices as a service entry point; this requires a flexible
approach to authentication. Rather than two-factor authentication we could
speak of multi-factor authentication, which would include the specific
user-payment service provider interaction context. But that is not all.

Stuck with two-factor customer
authentication?
The analytical flaw that underlies the SecurePay recommendations is its strong focus on too detailed a part of the business and security process: customer
authentication. Of course this is quite an important element of the transaction
process, but the overall security of (mobile) retail payments is always
achieved by a proper combination of security measures.

Customers, devices, processes and issuers should all be authenticated properly.
And any risk control structure does not just rest on authentication but on a
wide array of logical and functional controls. These controls may sometimes be
labeled: 'fraud detection' but the quality of the risk prevention that they
achieve can be just as good as one of the classic factors, that are not in
the definition of strong authentication.

It is evident that new authentication measures and security challenges are
being used and developed to achieve a level of security in retail payments
which is contingent on the risks that are relevant in the
user-transaction-device context. We can witness this in the bank, card,
Internet and mobile payment domain. As these developments occur, it is unwise
to freeze one detailed building block of security measures into a regulatory
requirement. This will skew the market into less efficient and more cumbersome
customer experiences, while technically not necessarily safeguarding a strong
level of security.

In particular the mobile domain allows for a wide array of additional
capabilities to achieve the security levels that supervisors desire. It would
therefore be wrong to make the low-value threshold of the PSD the dividing line
between strong and alternative customer authentication measures. A better
approach is to link the degree of authentication to the degree of risks and the
further security measures that are in place. This will allow the market to
develop solutions that achieve both ease of use to the consumer and the desired
level of security.

A more future-proof approach
It is not unlikely that the envisaged inclusion of a detailed requirement on
strong customer authentication may distort the current market developments
rather than allow for further innovation and market development. A more
future-proof approach is desirable.

In my view such an approach would be to allow for a broader 'multi-factor
authentication' which includes authentication based on the user-interaction
context. In addition it would be good to recognise that the quality of
some of the security measures which are often labeled: 'fraud detection' may
have become such that they achieve a similar level of security as the
traditional authentication factors.

We should also allow alternative authentication mechanisms to be used,
dependent on the risk involved, rather than a certain value threshold. It would
then be up to the supervisors to make the context-based and risk-based
assessments on the whole array of security measures as a part of their
supervisor reviews.

This approach should ideally be complemented by excluding todays specific
definitions of strong authentication from the wording of the Payment Services
Directive and replacing them with a generic reference to the relevant security
recommendations.

The result would then be that we will have a clear and flexible security
requirements framework in Europe that sets the boundaries within which the
market can futher innovate and develop.