Topics In Demand
Notification
New

No notification found.

Blog
Providing a Frictionless and Secure Customer Journey in PSD2

September 28, 2017

500

0

European leaders have long identified that the future of the financial services lies in the co-existence of the conventional banks with emerging fintech. However, to reach to that stage, security of the customer data is the major challenge. Despite industry efforts, fraudulent transaction levels are on the rise in Europe. 

Payments Services Directive 2 (PSD2) introduces the concept of Strong Customer Authentication (SCA) to provide transaction security. However, this can put Payment Service Providers (PSP) in a Catch 22 situation by having them tread the thin line between transaction security and customer experience.

Let’s see how Risk Based Authentication (RBA) as mandated in the PSD2 guidelines can play the balancing act without compromising on security and ease of use.

What is PSD2?

PSD2 applies to payment services in the European Union (EU) and is framed by European Banking Association (EBA). The directive focuses on all electronic payments including card present and card not present transactions. PSD2 provides data and technology driven directive to regulate the previously unregulated third-party payment service providers.

In doing so, it increases competition with the aim of making payments and account access more innovative, transparent, efficient, and secure for the consumers.

What Are The Key Takeaways From PSD2?

Without going into the nitty-gritties of the guidelines, here’s a summary of the major FAQs.

  • Introduction of New Players: PSD2 defines the role of Third Party Providers (TPPs) and their services. There are two types of TPPs viz. Payment Initiation Service Providers (PISPs) may initiate a payment transaction directly from the customer’s bank account and Account Information Service Providers (AISPs) consolidate the customer’s account and transaction details from multiple banks in one portal
  • Transparent Access to Accounts: PSD2 formulates the rules for access to the customer’s accounts (XS2A). Banks are mandated to open their core banking infrastructure via APIs to licensed TPPs. This will allow TPPs to provide account information services and enable payment initiation services.
  • Strong Customer Authentication: SCA is an authentication process that shall include two or more authentication factors viz. knowledge, possession, inheritance (biometrics). PSD2 mandates the use of SCA whenever the customer initiates any electronic payment transaction, whether to make a payment or access bank/TPP services.

When Will It Be Implemented?

What Exactly is Strong Customer Authentication?

PSD2 introduces strict security requirements for the initiation and processing of electronic payment transactions and access to accounts. One RTS in PSD2 is focused on a definition of Strong Customer Authentication (SCA), including when and how a PSP must ensure it is their customer making a payment or request for account management.

In a nutshell, SCA is a customer authentication process that must include at least two out of the three authentication factor types:

  • Knowledge – something only the customer knows (e.g. password or PIN)
  • Possession – something only the customer possesses (e.g. the card, authentication code generating device, token)
  • Inherence – something the user is (e.g. the use of a fingerprint or voice recognition)

As per the draft technical standard published by the EBA, SCA has to be applied in 3 cases.

  • Online access to payment accounts e.g. bank’s e-banking or via an AISP
  • Initiation of online payment transactions including card present and card not present transactions
  • Any action through a remote channel that may imply a risk of payment fraud, e.g. pin change

PSD2 brings into the jurisdiction, one legged transactions, i.e. those payment transactions where the payer’s or the recipient’s PSP is based outside of the EU. So, SCA has to be performed for these transactions as well.

The impact of PSD2 therefore is more global instead of localized only to Eurozone, as anticipated earlier.

How Does SCA Impact Customer Experience?

Customers have been prioritizing experience over security, but this seems to be slowly changing with regulators driving greater security.

The impact of the requirements for Secure Customer Authentication is set to radically change the customer experience and journey. Initiating a 2-factor authentication for every transaction or account access has a serious impact on customer experience.

‘One click checkouts’ will be thing of the past and many fear it will stifle innovation in the Payments space rather than promote it.

However, EBA has allayed fears of banks, merchants, e-commerce companies, etc. by including clauses for exemptions from Strong Customer Authentication.

The exemptions for SCA are debated, because of the need to find a balance between security, fraud reduction, innovation, competition, user-friendliness and accessibility.

In the EBA guidelines, the situations where a PSP is not obliged to use SCA include when the customer is:

  • Making a contactless payment at point of sale
  • Accessing their payment account data again (subject to time limit)
  • Paying for transport and parking
  • Making a low-value payment
  • Paying a “trusted beneficiary”
  • Making a recurring transaction for the same amount
  • Moving money to another of their account(s) at the same PSP
  • Making a low-risk, remote payment and the PSP has low levels of fraud loss

Evidently, these clauses correspond to either fixed restricted usage rules or prior authenticated parties. But the final case provides PSPs with a certain level of control for transaction, provided they perform Transaction Risk Analysis.

It lays down the foundation of Risk-based authentication of the payment transactions thus playing crucial role in reducing customer friction.

How Does Risk-based Authentication Eliminate The Payment Journey Friction?

Risk-based authentication is not a new concept by the EBA. It has been around for quite some time now. However, this time the concept has emerged as an unambiguous and fair solution for security vs convenience trade-off.

The EBA has mandated PSPs to put in place transaction monitoring mechanisms in order to enable them for detecting unauthorized or fraudulent payment transactions.

PSPs are expected to ensure that the transaction monitoring mechanisms takes into account, at a minimum, certain risk-based factors on a real-time basis:

  • Lists of compromised or stolen authentication elements
  • Amount of each payment transaction
  • Known fraud scenarios in the provision of payment services
  • Signs of malware infection in any sessions of the authentication procedure

What this means for the PSPs is that, using these transaction monitoring systems, they are able to record these parameters and further use them to validate incoming payment transactions from a fraud perspective.

PSPs can use these parameters to risk rate the payment transactions and in turn use it as a criterion to avoid Strong Customer Authentication.

As per PSD2 guidelines, PSPs on a minimum shall –

  • Calculate a risk score based on the transaction monitoring parameters discussed above
  • Identify any abnormal behavioral pattern from the payer
  • Look for unusual information about the payer’s device/software
  • Check for malware within the authentication procedure
  • Look out for known fraud scenarios
  • Check for abnormal locations for the payer
  • Verify whether the payee is in a high-risk location

If there is a fraud indication in any of these checks, then that shall call for either strong customer authentication for the transaction or rejection of the transaction. The final outcome desired is that by using these checks, PSPs shall be able to keep their fraud rates below the reference fraud rates set by EBA for remote payment transactions.

By achieving this, they will be able to accept and process payment transactions without applying further SCA and as a result be able to provide better customer experience.

Reference fraud rates asset by EBA:

Fraud Rate Reporting

The PSPs shall notify the national centralized authorities about their intention of using exemptions from SCA basis the lower fraud rates. The minimum requirement is reporting detailed loss rates by exemption every 90 days.

These statistics must be broken down across all payment types, remote card payments and remote credit transfers, including where no exemption is used. If for a PSP, the monitored fraud rates are above the EUR 100 reference rates for 2 consecutive quarters, then that PSP shall cease the usage of exemption from SCA. However, if the monitored fraud rates fall below the threshold for a consecutive 90 days, they are free to exempt future transactions from SCA.

PSPs also must have real-time fraud management, so that being able to know the trends in fraud rates on a daily basis will allow them to tune authentication policies. Else, how will the PSP know the fraud rates at the time of reporting? Also, Daily Fraud Rate is a better measure of fraud rate compared to the Daily Average Fraud Rate, which is computed at the end of the quarter.

Way Forward

The need of the hour for PSPs is to balance security and customer experience. As evident from the EBA guidelines, there’s no single way to combat the problem. We need a multi-pronged strategy. PSPs must adopt a hybrid approach to fraud detection and prevention, which should include a rules based system, behavior profiling of customers/devices/users, link analysis between entities, and machine learning based predictive risk scoring.

These features can help reduce fraud at the bank while also reducing false positives which in-turn will help PSPs to provide a superior customer experience.


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


© Copyright nasscom. All Rights Reserved.