Risk Management and Fraud Prevention Technical FAQs

The 3DS challenge screens support multiple languages, and the language displayed is determined by the cardholder's web browser language settings (e.g., English, French). Here are the key points regarding language support:

• Default Language: You must specify a default language in the 3DS Product Setup Form (PSF).

• Additional Languages: You can specify additional languages and provide the translated text for each language.

• Fallback to Default: If the cardholder's browser is set to a language that has not been configured in Cardinal (i.e., not provided in the PSF), the screens are displayed in the default language.

• Screen Text Limit: Each screen has its own character limit. Consult with the 3DS team to confirm the specific limits per screen.

For more information on language support on Apata, see the 3D Secure Guide (Apata): Challenge Screens.

For more information on language support on Cardinal, see the3D Secure Guide (Cardinal): Cardinal Configuration of RDX Biometric and Screens

Thredd's 3D Secure service provides support for displaying the 3D Secure Challenge screens in multiple languages. You can specify the languages you want to support using the Challenge Screen tab of the 3DS Product Specification Form Thredd Product Setup form used for 3D Secure programme configuration. For details, contact your Implementation Manager.. For more information, see:

• 3D Secure Guide (Apata): Challenge Screens — for Program Managers using the Thredd Apata 3D Secure Service

• 3D Secure Guide (Cardinal): Cardinal Configuration of RDX Biometric and Screens — for Program Managers using the Thredd Cardinal 3D Secure Service

Please raise a Thredd support ticket if you require support for additional languages.

For Apata, language can be configured at both the product level and the card level.

For Cardinal, it is configured at the BIN level, as implemented for 3DS. It follows the cardholder’s browser or device language settings.

If the preferred language isn’t supported, the default language is used. One of the languages needs to be specified as default, which is used when the device is set to a language that is not available.

You can override the default language and specify the language of the 3DS challenge screens at the individual card level:

The specific credential types available depend on the 3D Secure provider (e.g., Apata or Cardinal) and the configuration set up for the card. The following are examples of 3D Secure credentials:

• Knowledge-Based Authentication (KBA) — this involves verifying the cardholder's identity based on information only they would know. For example: Answering a security question like "What was your first pet's name?"

• One-Time Password (OTP) — enables the cardholder to enter a one-time password to authenticate the transaction. Options include:

  • OTP SMS: A one-time password is sent to the cardholder via SMS.

  • OTP Email: A one-time password is sent to the cardholder via email (Apata only)

• Biometric/In-App Authentication — this method uses biometric data (e.g., fingerprint or facial recognition) or in-app authentication to verify the cardholder's identity. It provides a seamless and secure authentication experience.

For more details on implementing these credential types, refer to the respective 3D Secure guides:

• 3D Secure Guide (Apata)

• 3D Secure Guide (Cardinal)

Yes. Thredd can automatically enrol all your cards in the 3D Secure service: you can request auto-enrolment by specifying the authorisation types to auto-enrol on your 3DS Product Setup Form (PSF).

Auto-enrol options include:

• None — there is no auto-enrolment. You will need to do this using either Thredd API.

• Initial load — Thredd creates the authentication type credentials (e.g., OTP SMS or BIOMETRIC) for all existing cards.

• Continuous — same as Initial load, however any future cards created will also have their credentials automatically registered for 3D Secure in the same way.

Auto-enrolment enrols all live and active cards (Note: This job runs every 10 minutes in production). It is not recommended if you wish to exclude some cardholders from enrolment.

Thredd auto-enrols the cards in the default main and fallback authentication methods. Auto-enrolment is available for OTP SMS, OTP Email, Out of Band (OOB) and Biometric authentication methods. Where a fallback method is not in use, the cards are enrolled to the default method only.

Auto-enrolment Logic

• For OTP SMS, Thredd auto-enrols using the mobile number linked to the card as the number for sending the SMS message to the cardholder during an SMS OTP authentication session.

• For OTP Email, Thredd auto-enrols using the email address linked to the card.

• For Biometric Authentication, Thredd auto-enrols using the initial Biometric credential value provided at product level. For example: BIOMETRIC.

For information on managing 3D Secure credentials using the REST API, see the Cards API Website: Managing 3D Secure Credentials.

For information on managing 3D Secure credentials using the SOAP web services, see the Web Services Guide: 3D Secure Credentials (Cardinal and Apata).

The 3D Secure whitelist is a list of trusted merchant sites, which are exempted from further authentication checks during the 3D Secure process. This list is maintained by the cardholder, and helps support frictionless authentication on trusted websites.

• For more information on how to set up and manage authentication rules using the Apata service, see the Secure (Apata) Guide: Managing Authentication Rules.

• For more information on how to set up and manage authentication rules using the Cardinal service, see the Secure (Cardinal) Guide: Appendix 1: Cardinal 3D Secure Rules.

Authentication rules are applied to a card program and associated card ranges. The whitelist is applicable to EEA and UK programmes only, and only available on the Apata service.

In order to support Whitelist exemptions via Apata on Mastercard networks, when enrolling your cards/BIN ranges in the Mastercard ISSM tool, you must enable the Whitelisting supported by ACS option under Additional Services.

No. If a mobile number or email address is added to the card or updated using the Cards API or web services, the mobile number or email address will need to be updated separately, using the Update 3DS Credentials API.

For Apata, Thredd sends the OTP SMS to the DelegateOTPNotification endpoint that you specified in your 3DS Product Setup Form.

The message content displayed to the cardholder is shown in the MessageContent field.

For more information, see the 3D Secure Guide (Apata service): Using the Delegated SMS API.

In the event of a BIN attack, when viewing transactions in Thredd Portal Thredd Portal is Thredd's new web application for managing your cards and transactions on the Thredd Platform. or Smart Client Smart Client is Thredd's legacy desktop application for managing your account on the Thredd Platform., you will see a high volume of declined transactions with a Response Status (DE039) ‘14 - Invalid card number (no such number)’. Typically, these transactions have the same BIN, merchant name, and Acquirer ID (AID) and the Notes field shows the reason for the decline as unknown card number, unknown PAN, and unknown token.

Where a specific merchant location is repeatedly used for BIN attacks, with no valid transactions, Thredd can block the merchant location. Merchant locations where there is a mix of fraudulent and valid transactions are not blocked, as this would impact legitimate cardholder transactions. Thredd will also not block merchant locations where only a small volume of transactions which may indicate a BIN attack are observed.

For more information, refer to Fraud Transaction Monitoring Guides and Managing Risk: BIN Attacks.