How Issuers Should Use 3DS Results When the Authorisation Arrives
Inside many issuers, the Access Control Server (ACS) and the authorisation system belong to different teams, run on different platforms and use different risk models. The ACS decides whether to authenticate the cardholder. Seconds later, the authorisation system decides whether to approve the payment. When the two do not share information, the issuer can approve a transaction its ACS was uneasy about, or decline one its ACS has just authenticated and for which the issuer will normally carry fraud liability.
The merchant side of this hand-off is covered in why authenticated transactions lose their protection at authorisation. This article covers what the issuer does when the authorisation arrives.
What arrives with the authorisation
An authorisation for an authenticated transaction carries the authentication value (such as CAVV for Visa or AAV for Mastercard), the Electronic Commerce Indicator (ECI) and, for Mastercard, the Directory Server Transaction ID in dedicated authorisation fields that Mastercard introduced for EMV 3DS (Mastercard announcement AN 1630). Together they let the issuer, or the network on its behalf, link the authorisation to the authentication.
Checks to run on the authentication data
| Check | Why it matters | If it fails |
|---|---|---|
| The authentication value is valid for this card | Confirms the authentication happened and was not fabricated or copied | Treat the transaction as unauthenticated, under scheme rules |
| The ECI matches the authentication outcome | A full-authentication ECI with an attempt-type value, or the reverse, indicates an error or manipulation | Treat according to the lower level of authentication |
| The authorisation matches what was authenticated | Amount, currency and merchant should be consistent with the authentication, within scheme tolerances | Apply your authorisation risk policy as for a weaker authentication |
| The DS Transaction ID links to an authentication record | Lets the issuer retrieve the ACS decision and risk data for this payment | Investigate; the record may belong to another transaction |
| The authentication is recent enough | Scheme rules govern how long an authentication can support an authorisation | Apply scheme rules for stale authentication |
Card networks offer verification services that check authentication values on the issuer’s behalf. Mastercard’s AAV Verification Service is one example, and its 2018 enhancement is the announcement that introduced the DS Transaction ID fields. Whether the issuer validates directly or relies on the network, the result should be visible to the authorisation decision.
Reconciling the ACS view with the authorisation view
For a fully authenticated transaction, card scheme rules normally place fraud liability with the issuer. Declining it on fraud grounds therefore deserves care: the cardholder has just passed the issuer’s own authentication. A decline is sometimes right, for example on clear signs of account takeover discovered after authentication, but it should be a deliberate decision rather than the result of two models that never see each other’s output.
Practical ways to bring the two together include passing the ACS risk score and challenge outcome into the authorisation model as inputs, agreeing thresholds at which the authorisation system may override an authenticated outcome, and reviewing transactions where the two disagreed.
The reverse case also matters. If the authorisation arrives without authentication and the issuer would have challenged it, a soft decline asking for authentication may be the right response where the scheme and market support it (what a soft decline is and how to respond).
Closing the loop back to the ACS
Authorisation outcomes and fraud reports are the best evidence of how well ACS rules are working. Feed confirmed fraud on frictionless authentications back to the team that tunes risk-based authentication rules (RBA rule tuning), and track frictionless fraud and authenticated declines among the measures in what issuers should measure.
Frequently asked questions
Should an issuer ever decline a fully authenticated transaction?
Sometimes, but rarely and deliberately. The issuer has just authenticated the cardholder and normally carries fraud liability. Decline when new evidence emerges after authentication, not because the authorisation model never saw the ACS result.
Who validates the authentication value?
The issuer, or a card network verification service acting for it. Either way, the validation result should reach the authorisation decision.
What should happen if the authentication value fails validation?
The transaction should be treated as not authenticated, under the card scheme’s rules, and the failure investigated, since it can indicate an integration error on the acquiring side or manipulation.
What if the authorised amount differs from the authenticated amount?
Card schemes set tolerances and rules for how far an authorisation can differ from the authentication. Outside those limits, treat the authorisation as not covered by the original authentication.
Which team should own the link between authentication and authorisation?
Usually fraud strategy, because it spans both models. What matters is that one team owns the thresholds and reviews disagreements.
Connecting authentication and authorisation
GPayments’ ActiveAccess is an Access Control Server for issuers and issuer processors. To discuss how authentication data can support your authorisation decisions, speak with a GPayments 3DS specialist.
