Article

Getting PSD2 Authentication right

Getting PSD2 Authentication right

While current guidelines necessitate Two-Factor Authentication, some transactions are exempt. Oliver Dlugosch, CEO of ndgit, clarifies the secure ‘rules of engagement’ for Banks and Payment Service Providers.

PSD2 is nothing if not pragmatic. At the same time as it’s throwing open Europe’s banking doors to healthy competition, it’s also seeking to shut them to potential fraudsters. Legislators are all too aware that any increase in service freedom must not be at the expense of customer security. Hence the inclusion of Strong Customer Authentication (SCA) as a key part of PSD2 requirements.

However, there’s also the acceptance that, while customers want to stay safe, they don’t want any unnecessary friction at the point of service/transaction. That’s why there are also some key exemptions to keep low-risk transactions flowing smoothly. It’s important that banks, their service providers and partners, understand and follow the rules to ensure optimum usability and compliance while maintaining reputation and trust.

Authentication Formats

For PSD2 to address the needs of the digital world, it has to safeguard remote banking and payments against online fraud. In almost all circumstances, Two-Factor Authentication (2FA) is mandatory to fulfil SCA, with many applications requiring more than two security checks to protect customers, merchants, and banks from fraudsters.

Authentication methods can be based on knowledge, something only the user knows e.g. a PIN or password; possession something only the user possesses e.g. a card or mobile phone; or inherence, something the user is e.g. using a biometric feature such as a fingerprint, iris scan or voice recognition. Each element must be independent, to avoid compromising each other and must maintain the confidentiality of the user’s data at all times.

To prevent ‘man in the middle’ attacks, PSD2 also requires all remote transactions including internet and mobile payments to use a unique authentication code which dynamically links the transaction to an exact amount and a specific payee. Any change to either of these is recognised instantly and stops the transaction from being processed. During a dynamically linked transaction, the payer must be aware of both the transaction amount and the payee at all times.

Securing Services and Channels

2FA is obligatory for access to payment accounts online, including aggregated views of payment accounts. It’s also required when making an electronic payment or to perform any action through a remote channel. Under PSD2, banks must also implement detection of fraudulently used identities to help distinguish true customers from cybercriminals.

The challenge for banks is to find ways of achieving this as seamlessly as possible for online and mobile users and for large volume batch processing applications.

Friction-Free Exemptions

PSD2’s strong focus on the user experience allows banks to use adaptive and risk-based authentication to determine when strong customer authentication is actually needed.

To keep electronic payments as convenient and seamless as possible, PSD2 also allows some exemptions from its SCA requirements. These include:

  1. Low value remote online and mobile payments (up to €30)
    EXCEPT: When a cumulative value of €100 is reached.
    Or when 5 payments of up to €30 have been made.
  2. Contactless card payments up to €50.
    EXCEPT: When a cumulative value of €150 is reached.
    Or when 5 contactless payments of up to €50 have been made.
  3. Unattended Payments (kiosks)
    Unattended payment terminals for transport fares and parking fees.
  4. Trusted Transactions
    Online transactions (credit transfers, card-based) towards a trusted beneficiary (i.e. already identified by the payer).
  5. Approved Corporate Payments
    If dedicated payment processes and protocols are used (and if the national competent authority is satisfied with their level of security).
  6. Online Payment Accounts
    When the online payment account is consulted, SCA is needed only the first time it is used and then >90 days after the last SCA.
  7. Low Risk Applications
    If the fraud rates observed by the payment service provider are lower than the pre-set reference fraud rates (as described in the Annex to the Regulatory Technical Standards).

Carrying the Responsibility

Apart from these low risk/low value exceptions, banks are required to implement SCA. The payer can claim full reimbursement from a PSP or bank if there is a breach and no SCA measure was in place, and if they themselves did not act fraudulently.

As well as ensuring SCA on their customer transactions, banks also need to secure API communications, like account administration and manage and enforce access control for authorised third-party providers (TPPs).

As PSD2 beds in, many European banks are still concerned about the implications of adapting to SCA under the new requirements. However, working with API partners like ndgit, they can ensure their services include innovative authentication platforms that support SCA with easy to implement multi-factor authentication modules. By doing this, they can not only protect their business and stay compliant but also deliver a safe, seamless and trusted experience for their customers.


Topics


Share this article