Frictionless authentication rates vary enormously between issuers running the same EMV 3DS specification, and the gap is rarely down to the ACS software itself. It’s down to configuration: how much data is being fed into the risk engine, how aggressively challenge rules are set, and how often the rule set is actually reviewed against real outcomes rather than left on its initial configuration.
GPayments has built ACS technology since 1999 and provides ActiveAccess to issuers across 33 countries, alongside ActiveServer, ActiveSDK, and TestLabs. This is a practical breakdown of what actually moves frictionless rates, based on how RBA engines evaluate risk and where issuers typically leave performance on the table.
Data Volume Is the First Lever, and Most Issuers Underuse It
The EMV 3DS authentication request (AReq) supports well over 100 data fields covering device fingerprint, browser characteristics, billing and shipping address match, transaction and cardholder account history, and merchant context. Industry analysis of live implementations consistently finds that most merchants populate only 60 to 70% of the fields the AReq supports, which directly costs frictionless rate on the issuer side: a risk engine given a thinner data set has less to work with and defaults toward caution, meaning more transactions get pushed to challenge than the underlying risk actually warrants.
This is a two-sided problem, but the issuer side of it, the RBA engine and how it’s configured to use available data, is the lever an issuer directly controls regardless of what any given merchant sends. An RBA engine that only scores a narrow subset of fields, or weights them in ways that haven’t been revisited since initial deployment, fails to maximise the frictionless rate, even when merchants are sending rich data.
The Four Dimensions Worth Tuning
|
Dimension |
What to Review |
|
Data inputs |
Which AReq fields the engine actually scores, and whether device, behavioural, and merchant-context signals are all in use, not just the core transaction fields |
|
Rule flexibility |
Whether rules can be created, tested, and adjusted by issuer staff directly, or require vendor engagement for every change |
|
Response latency |
Whether risk scoring completes well within checkout tolerance; delays compound with mobile redirect and challenge-flow overhead |
|
Analytics visibility |
Whether frictionless rate, challenge completion rate, and false-decline patterns are visible by BIN range, geography, and merchant category, not just in aggregate |
Analytics visibility is the dimension most often skipped, and it’s the one that makes ongoing tuning possible at all. Without segmented visibility into where challenges are being triggered unnecessarily, tuning becomes guesswork rather than a data-driven process.
The Challenge Indicator Is Frequently Misconfigured
The 3DS Requestor Challenge Indicator signals a merchant’s preference for frictionless versus challenge treatment, and issuers weight it as one input among several, not an instruction to follow blindly. A static configuration, always requesting frictionless regardless of risk, or always defaulting to challenge, undermines the RBA engine’s own risk scoring. Dynamic configuration that reflects actual transaction risk (low-risk returning customers flagged for frictionless treatment, new accounts or high-value transactions flagged for challenge) gives the engine a more useful signal to weigh alongside its own data-driven score.
Latency Compounds Quietly
Research into real-world 3DS friction has found that a large majority of authentication attempts introduce noticeable delay, on average adding around 37 seconds to checkout, well past the point where cardholders start abandoning. Total authentication time, including risk scoring, should stay well under 30 seconds end to end. Slow risk scoring on the ACS side doesn’t just cost the current transaction; it degrades the cardholder’s tolerance for the entire authentication step, making challenge abandonment more likely on top of an already imperfect frictionless rate.
Review Cadence Matters More Than Initial Configuration
An RBA rule set tuned once at deployment and left alone doesn’t stay well-tuned. Fraud patterns shift, cardholder behaviour shifts with new devices and channels, and merchant portfolios change. Segmented analytics by BIN range, geography, and merchant category exist specifically to catch where the current rule set has drifted out of alignment with actual risk, whether that shows up as challenge rates creeping up on legitimate transactions or fraud slipping through frictionless approval in a specific segment. Reviewing this quarterly, at minimum, rather than treating the initial rule set as permanent, is what separates issuers with genuinely strong frictionless rates from issuers running the same configuration since go-live.
|
Where GPayments Fits ActiveAccess includes a built-in RBA engine with rules issuers can create, test, and adjust directly, plus adapter-based APIs for third-party RBA integration where an issuer prefers an external risk engine. Combined with segmented analytics dashboards, this supports the kind of ongoing tuning cycle that keeps frictionless rates aligned with actual risk rather than drifting from an initial configuration. |
Frequently Asked Questions
What is a good frictionless authentication rate for 3DS?
Well-tuned issuers commonly see frictionless rates in the range of 70 to 85% for regular, low-risk transactions, though this varies by market, portfolio, and risk appetite. A frictionless rate significantly below this range for an established cardholder base is usually a sign of under-tuned RBA rules or insufficient transaction data, rather than an accurate reflection of underlying fraud risk.
Why do frictionless rates vary so much between issuers on the same 3DS version?
Frictionless rate differences are usually driven by configuration, not the underlying software version. Issuers that populate and score a wider range of AReq data fields, tune challenge rules regularly against segmented performance data, and configure the challenge indicator dynamically based on actual transaction risk achieve materially higher frictionless rates than issuers running an initial configuration unchanged since deployment.
How much data should be sent in a 3DS authentication request?
The EMV 3DS AReq supports well over 100 data fields, but industry analysis of live implementations finds most merchants send only 60 to 70% of what’s supported. Populating the full range of relevant fields, including device fingerprint, address match indicators, and account history, gives the issuer’s risk engine materially more to work with when deciding between frictionless and challenge treatment.
What is the 3DS Requestor Challenge Indicator, and how should it be used?
The Challenge Indicator is a field a merchant sends to signal a preference for frictionless or challenge treatment on a given transaction. It should be set dynamically based on actual transaction risk, for example flagging low-risk returning customers for frictionless treatment and high-value or new accounts for challenge, rather than statically requesting the same treatment for every transaction, which undermines the issuer’s own risk scoring.
How often should RBA rules be reviewed once deployed?
At minimum quarterly, and sooner if segmented analytics show challenge rates rising on legitimate transaction segments or fraud slipping through frictionless approval in a specific BIN range, geography, or merchant category. Fraud patterns and cardholder behaviour shift continuously, and a rule set tuned once at deployment degrades in effectiveness without ongoing review.
How does GPayments’ ActiveAccess support RBA tuning?
ActiveAccess includes a built-in RBA engine with rules issuers can create, test, and adjust directly, along with adapter-based APIs for integrating a third-party risk engine where preferred. Segmented analytics dashboards support ongoing tuning by showing frictionless rate, challenge completion rate, and risk patterns by BIN range, geography, and merchant category.
|
Leaving Frictionless Rate on the Table? Talk to GPayments about tuning your ActiveAccess RBA rules against segmented performance data: gpayments.com/contact |