Providing data for the SCA exemption engine

The SCA exemption learning data interface (POST /sca-exemptions-data) constitutes the near real-time connection for updating the risk engine after the results of a transaction. In general, the payload contains all fields of the original SCA exemption request (POST /sca-exemptions) as well as additional fields about the outcome of the process.

This guide gives a short clarification - especially for non-3DS-related fields - about the expected content and encoding.

A general remark about the SCA exemptions learning data interface:
Although for the individual transaction the real-time SCA exemption request/response seems most important, for a long term precise scoring, the learning data interface is at least as important! It cannot be stressed enough that for successful profiling of past transactions the risk engine must be informed about the outcome of every event. For each initial SCA exemption request/response there must always be, regardless of the outcome of the transactional event, a single learning data message returned to the risk engine. For the risk engine to generate a risk score, it is dependent on:

• Was the previous transaction declined by the issuer with response code "43 Stolen card, pick-up" in authorisation?
• Did the cardholder successfully perform SCA before, at the same merchant, with the same device and should therefore be trusted and not asked for SCA again?
• Did the same card already perform a large number of requests within a short time frame that were either exempted or unsuccessful which could raise suspicion?
• Does the merchant have a large number of unsuccessful requests (maybe all from the same BIN range)?

Those are just some examples that not only the event but in fact also the outcome is necessary to evaluate the subsequent transactions properly. A timely feedback with as much information as possible will improve the risk-scoring's precision and hence the frictionless/exemption rate as well as the fraud protection.

The most important data fields in the learning data message are providing information about the message flow (3DS or non-3DS/ which version was used), the outcome of authentication (failed, successful, not required/frictionless) and the outcome of the authorisation. Similar to the SCA exemption request message, not all fields may be appropriate for all types of transactions. It is possible to send those fields empty or omit the fields, for example:

• A transaction is sent to 3DS for a challenge, the ACS indeed challenges and the cardholder is not able to perform the authentication. Such a transaction will never reach authorisation. There will be no meaningful authorisation response code.
• A transaction is not sent through 3DS (the 3DS Flow Indicator is "NOT_SUBMITTED_TO_3DS"). Obviously, there is no dsTransID or Message Version Number available to share
• A transaction is sent to 3DS 2.2, is successfully challenged and authorised afterwards. In this case, all data fields can be provided in a meaningful fashion. (For completeness: some fields may still be omitted, due to the deviceChannel.)

🚧

Note

For each transaction there should always be exactly one request to the risk engine and, after it's final conclusion, a single learning data message. It does not support the sending of intermediate "status updates", e.g. after 3DS-flow & before authorisation, or after a soft decline before entering 3DS flow (with 3DSReqChallengeInd=04). Only a single learning data message after the final conclusion of an event/transaction/checkout-process is expected.