Most of us are familiar with the requirements of SCA, but as a reminder, at least two of the following elements are required for an end customer to be authenticated:
When it comes to SCA, there’s one word everyone should know: exempt. Dependent on the scheme, risk-based authentication allows for low-value and low-risk transactions to be exempt from SCA. However, “exempt” implies that these will be exceptions rather than the rule. This is far from the case. With the right approach, and making the best use of the data available, most transactions can be exempt, delivering the best possible customer experience.
3DS2
From a 3DS2 perspective, many financial organizations will be tempted to leave all of this SCA business to their existing access control server (ACS) provider. Now, they will do a fine job with the information available, but — and this is a key point — they can only utilize the information they can see. SCA will include the new, rich authentication data with online credentials such as IP address, browser accepts header, language, screen details and time zone. In addition, the customer’s billing and shipping addresses will be present, which are not available in today’s authorization messages (ISO8583, AS2805). The ACS provider will determine when to request SCA, and the first time you become aware of the transaction will be when the authorization request is received (without the rich data). All you will know is whether SCA occurred.
By working with a suitable provider and bringing risk-based authentication and SCA “in-house,” you will have access to the rich data from the authentication request, which will allow for a deeper, more granular risk assessment. More importantly, it will provide a 360-degree customer view.
360-degree customer view
SCA allows you to answer the following questions to provide a better experience for customers:
Has the customer previously made similar online purchases on the same or different cards?
Is the billing/shipping address a match with the customer master?
Have there been any recent changes, e.g., phone number, mailing address, new card?
Have the online credentials been seen for this card before?
Have the online credentials been seen for the customer’s other cards or digital banking?
How does this request compare to the customer’s last transaction(s), e.g., recent physical purchase in Australia, IP address for this transaction is Singapore?
Is the customer travelling?
Enterprise view
There are benefits to this approach at the enterprise level too, with banks able to utilize data across customers to inform transaction risk analysis.
SCA also allows financial organizations to answer the following by taking an enterprise view:
Are there any previous transactions, by any of your customers, marked as fraudulent with the same online credentials?
Do any online credentials match against your blacklist(s), e.g., risky IP address?
Is the billing/shipping address a match with any of your other customers?
Thus, we are not viewing the authentication request in isolation, assessing only a specific card’s behaviors. There a couple of major reasons why this is important:
An authentication request for that card may appear anomalous compared to previous behavior; however, we can see that the customer’s other cards have been transacting with similar behavior. We can approve with confidence rather than request SCA or worse, decline.
An authentication request for that card may appear like previous behavior; however, we can see that the customer’s other cards and/or accounts have one or more unusual transactions. We can decline with confidence rather than approve a transaction likely to be fraudulent.
If a financial organization handles the authentication request and makes the ultimate decision about when to perform SCA, we can avoid the customer experience nightmare of the cardholder being requested to perform SCA, then declining the subsequent authorization request.
Purchases that might be anomalous for a specific card and would likely trigger SCA, however, can proceed without friction if there are other multiple “green lights” — i.e., previously seen online credentials or similar transactions on the customer’s other card(s).
Why is it so important to deliver a frictionless payment process? The online shopping customer journey can be fragile, with each additional click increasing risk of cart abandonment. Reduced friction rate, applied with confidence, is the goal here.
Another added benefit is a reduction in losses. With the additional data available in real time, combined with a sophisticated financial crime solution that leverages behavioral profiling, machine learning and comprehensive analytics, genuine fraud detection rates will increase, which can save organizations from financial losses and reputational damage.
The CNP Fraud Mitigation Framework mandates that SCA must be applied if card fraud rates, as set by AusPayNet, are exceeded. By performing risk-based authentication in-house with your solution, SCA allows for 100 percent of transactions to be automatically turned on (or off) based on your fraud rates. Lastly, although Consumer Data Right (CDR) legislation today only covers read access for customer accounts, this is regarded as a confidence-builder for the public before the introduction of third-party payment initiation (read/write), as authorized by customers, which could happen as early as 2022.
Put simply, by performing risk-based authentication and controlling SCA in-house, financial institutions will reduce friction in the payment process, increased fraud detection rates and reduced fraud losses.
Register for our webinar Tomorrow’s Customer Protection Today on September 22, with experts from Westpac, BioCatch and ACI discussing the latest trends in fraud prevention.
CustomersPartners
Payments hub 
