How SCA Exemptions Are Signalled in 3DS Messages

Most discussion of Strong Customer Authentication exemptions happens at policy level. Which exemptions exist, what the thresholds are, when a regulator expects them to apply. That conversation is well covered.

What gets much less attention is the mechanical question underneath it. When your team decides a transaction qualifies for an exemption, how does that intention actually travel through the protocol, who decides whether it is honoured, and how do you find out what happened?

Three separate data elements are involved, they do different jobs, and confusing them is one of the more common sources of disappointment in SCA markets.

Three elements, three different jobs

The first tells you what the issuer’s Access Control Server can do. The ACS Information Indicator is supplied in card range data and lists, among other things, which exemptions the ACS supports for that card range. Before you request anything, this tells you whether asking is worthwhile.

The second carries what you want. The 3DS Requestor Challenge Indicator is set in the Authentication Request and signals the requestor’s intention, including a request that a particular exemption be applied.

The third reports what happened. The Transaction Challenge Exemption is returned by the ACS and states which exemption, if any, it actually applied.

The order matters. Capability, then request, then outcome. A great deal of confusion dissolves once teams stop treating the middle one as though it were the last one.

Requesting is not receiving

This is the point worth taking away from the whole article.

The 3DS Requestor Challenge Indicator expresses an intention. It does not instruct the ACS. The issuer evaluates the risk associated with the transaction, takes the exemption request into account if one is present, and decides. If an exemption is applicable, the ACS may report it in the response.

Every part of that sentence is permissive. The ACS may apply the exemption. It may report it. The decision belongs to the issuer, and an issuer that judges a transaction risky enough to warrant a challenge will challenge it regardless of what was requested.

Acquiring-side teams sometimes build reporting that counts exemption requests and presents them as exemptions achieved. Those are different numbers, and the gap between them is one of the more useful diagnostics available to an acquirer, because a persistently large gap for a given issuer or merchant segment usually means something about the request is not credible.

The four exemption types the protocol signals

The specification supports signalling for four exemption types, each with a matching capability indicator, request value and outcome value.

Transaction risk analysis. The merchant or their acquiring bank assesses the risk associated with the transaction. If the risk is low, they may request an exemption on the basis that the risk analysis has already been performed.

Low transaction value. The transaction falls below a predefined threshold. The 3DS Server may check that the ACS supports this exemption before requesting it, and the ACS verifies the value against the threshold before applying it.

Trust list. The cardholder has previously added the merchant to a list of trusted beneficiaries. The merchant or 3DS Server, knowing this, may request that no challenge be applied. The ACS verifies that the merchant is genuinely on that cardholder’s list.

Secure corporate payments. The card used is a corporate payment card, such as one used for business expenditure or a card account used for business-to-business payments. The requestor signals this and the ACS verifies the card type.

There is also a distinct outcome value meaning no exemption was applied, which is worth capturing in reporting rather than treating as an absence of data.

Check capability before you ask

For each of the four, the ACS Information Indicator carries a corresponding value telling the 3DS Server whether that exemption is supported for the card range in question.

Using this is straightforward and almost nobody does it. The pattern is: read the card range data, confirm the ACS supports the exemption you intend to request, then request it. Where support is absent, sending the request anyway costs you nothing directly, but it does mean your exemption request statistics are measuring something other than what you think.

This depends entirely on your card range data being current. If your cache has fallen behind the Directory Server, your capability picture is out of date, and you may be either missing newly supported exemptions or requesting ones that have been withdrawn.

A worked example of the shape

Take a low-value transaction in a market where the issuer supports the low value exemption.

The 3DS Server checks the card range data and confirms low value exemption support for the range. It builds the Authentication Request with the purchase amount, currency, currency exponent and date and time populated accurately, and sets the challenge indicator to the value requesting no challenge on low value grounds.

The ACS receives the request, verifies that the transaction value is genuinely below the threshold, determines that a challenge is not necessary, and returns a successful transaction status alongside the exemption value indicating the low value exemption was applied.

Note where the verification sits. The ACS checks the amount itself. Requesting a low value exemption for a transaction that is not low value does not produce an exemption, it produces a challenge and a slightly worse relationship with that issuer’s risk model.

This is optional, and it is not global

The specification supports the exchange of exemption information between the 3DS Server and the ACS, but the presence and use of that information is optional and depends on the regulations applicable in the relevant market.

That qualification does real work. SCA exemptions are a regulatory construct, and outside markets where such regulation applies, the exemption signalling either carries no regulatory meaning or is not used at all. Teams operating across regions should not assume a single exemption strategy travels.

Equally, the protocol capability and the regulatory obligation are separate things. The specification provides a way to express an exemption. Whether an exemption is permissible, and on what basis, is determined by the applicable rules in the relevant jurisdiction, not by the protocol. Organisations should confirm requirements for the markets they operate in rather than inferring them from what the message format allows.

Running on an older protocol version

One practical wrinkle for mixed estates. The outcome element reporting which exemption the ACS applied is available in version 2.3.1, and on version 2.2 it depends on the bridging message extension.

For any organisation still running 2.2 components, this is a concrete example of why the bridging extension matters. Without it, you can request exemptions but you have materially less visibility into what the issuer actually did, which undermines the reporting that would tell you whether your exemption strategy is working.

What to build into your reporting

Three figures, tracked together, tell you almost everything you need.

Exemptions requested, broken down by type. Exemptions applied, from the outcome element rather than inferred. And the ratio between the two, segmented by issuer and by merchant.

A low ratio concentrated on one merchant usually means the risk signals accompanying that merchant’s traffic do not support the request being made. A low ratio concentrated on one issuer usually means a difference in risk appetite, which is a conversation rather than a bug. A low ratio across the board, combined with capability indicators showing support, is worth checking against your card range data freshness before you conclude anything else.

Frequently Asked Questions (FAQs)

How are SCA exemptions requested in 3DS?

The 3DS Requestor Challenge Indicator is used in the Authentication Request to signal that a particular exemption is being requested.

Does requesting an SCA exemption mean it will be granted?

No. The issuer evaluates the transaction risk and ultimately decides whether to apply the requested exemption or require a challenge.

What SCA exemption types can be signalled in 3DS?

The four types covered are transaction risk analysis, low transaction value, trust list and secure corporate payments.

How can a 3DS Server check whether an exemption is supported?

The ACS Information Indicator in the card range data indicates which exemptions the ACS supports for that card range.

How is an applied exemption reported?

The ACS uses the Transaction Challenge Exemption element to report which exemption, if any, was actually applied.

Are SCA exemptions supported in every market?

No. Exemption signalling is optional and its regulatory relevance depends on the rules applicable in each market.

Building exemption handling into your 3DS Server?

ActiveServer is the GPayments 3DS Server solution for acquirers, gateways and payment service providers. Speak with a 3DS specialist about exemption signalling in your market.