Your company’s name. The name provided here will be displayed on the Apata portal as the Financial institution name.

Your company’s country of residence.

Card scheme (Network such as Mastercard or Visa).

The name of your issuer (BIN sponsor).

Your issuer’s (BIN sponsor) Visa Business Identifier (BID) A business ID, which is unique to each Visa business customer..

Your issuer’s (BIN sponsor) primary ICA The Interbank Card Association (ICA) number is a four-digit number assigned by Mastercard that identifies an issuing bank. An ICA can have multiple BINs associated with it., as registered with Mastercard.

Your issuer’s (BIN sponsor) Company Name, as registered with Mastercard.

Your issuer’s (BIN sponsor) Company ID, as registered with Mastercard.

Your Thredd Program ID or code. Assigned by Thredd.

Date when you plan to be ready to test 3D Secure in the UAT environment.

Date when you plan to launch 3D Secure for your card programme.

Please check with your Implementation Manager to confirm that this date is feasible. For steps and indicative time scales to launch a 3D Secure service, see Steps in a 3D Secure Biometric/In-app Project.

The AAV/CAVV Accountholder Authentication Value (AAV) and Cardholder Authentication Verification Value (CAVV) are cryptographic values returned by the Access Control Server (ACS) or Card Scheme to the Merchant after a successful cardholder authentication. The merchant includes this value in the authorisation message sent to the issuer. is a cryptographic value which is included in the authorisation message request from the Merchant1 The ACS generates the CAVV/AAV for a successful 3D Secure session; if Stand-In processing is enabled at the Card Scheme (for low-risk transactions), then the Scheme can step in when ACS is down and generate this value. . It indicates that the 3D secure authentication session was successful. You can request that either Thredd or the Card Scheme (Mastercard or Visa) validate this value. Card Scheme validation is typically required if you want the card Scheme to provide Stand-In processing.

If YES: Thredd will validate the AAV/CAVV Accountholder Authentication Value (AAV) and Cardholder Authentication Verification Value (CAVV) are cryptographic values returned by the Access Control Server (ACS) or Card Scheme to the Merchant after a successful cardholder authentication. The merchant includes this value in the authorisation message sent to the issuer.. To set this up:

• Mastercard — encryption keys must be exchanged between Thredd and Apata; No action is required from the Program Manager.

• Visa — encryption keys must be exchanged between Thredd and Apata. Please ensure your Client Information Questionnaire (CIQ) has the correct settings (under the VisaSecure section > ABE1 > K01. Select “I”).

If NO:

• Mastercard — please ensure the BIN has been enroled with the required validation set up at Mastercard (i.e. Mastercard On-Behalf of Services (OBS) AAV Verification Service).

• Visa — please ensure your Client Information Questionnaire (CIQ) has the correct settings (under the VisaSecure section > ABE1 > K01. Select “F” or” V” as appropriate). Please request for Visa to generate the CAVV key and encrypt with Thredd ZCMK (BIN: 476370, ZCMK KCV: 1CB2C9). Share the CAVV key file securely with your Thredd Implementation Manager.

API to use for card enrolment. Options include:

• SOAP — using our traditional XML-based Thredd API.

• REST — using our REST-based Cards API, supporting messages in JSON format.

For more information, see Using the Card Enrolment API.

The cardholder receives an issuer-generated push notification to authenticate within the authenticator or mobile banking app.

The cardholder receives an issuer-generated push notification to authenticate within the authenticator or mobile banking app using a biometric identifier; for example face ID or fingerprint.

The cardholder receives a One-Time Passcode (OTP) via email.

The cardholder receives a One-Time Passcode (OTP) via SMS (text message).

Knowledge Based Authentication (KBA). The cardholder is presented with a Challenge screen asking them to identify a recent payment they made on the card.

Knowledge Based Authentication (KBA). The cardholder is presented with a Challenge screen asking them to provide the answer to a question they have previously supplied.

The cardholder is first requested to authenticate using OTP via SMS and then by KBA.

Default language to apply to all cardholder Challenge screens, configured at product level.

List any additional languages you support. You will also need to specify which language to apply to each card product. Otherwise, the default language will be applied to all products. See Challenge Screens > Supported Languages.

Select the default authentication type to support all BINs or sub-BIN ranges. See the drop down on the 3D Secure PSF for all available options.

This is used for the following purposes: a) to enable a card to be enroled in this type; b) to use as the default type of authentication during a real-time authentication session with Apata; c) to support auto-enrolment.

Select the fallback authentication type to support all sub-BIN ranges. See the drop down on the 3D Secure PSF for all available options.

This is used for two purposes: a) to enable a card to be enroled in this type; b) to use as the fallback type of authentication during a real-time authentication session with Apata, if the default type cannot be used for any reason.

Options are:

NO — All cards must be enroled for OTP SMS and the mobile number must be registered using either the Thredd API or the Cards API; see Using the Card Enrolment API.

YES - Initial Load — Thredd enrol the existing cards to the OTP SMS credential. Thredd use the phone number linked to the card (i.e., the phone number supplied when the card was created or updated).

YES - Continuous — Same as Initial load, however any future cards created will also have their phone numbers automatically registered for 3D Secure in the same way.

Auto-enrolment enrols all active and Live cards. It is not recommended if you wish to exclude some cardholders from enrolment. If using Continuous auto-enrolment, this may restrict your ability to unenrol cards which currently have a live status. See Section 8.2 Card Unenrolment.

Options are:

• NO — All cards must be enroled using either the Thredd API or the Cards API.

• YES — Initial Load only —This will create a biometric credential for all existing card holders which are sent to you for your reference. After initial load, auto-enrolment will be disabled and Program Manager will need to initiate the enrolment in the Thredd API or the Cards API for new card enrolments.

• YES — Continuous — Same as Initial load, however auto-enrolment will remain enabled. New cards created will also have biometric credentials created in the same way. Your organisation will not need to send the Thredd API or the Cards API to enrol new cardholders.

Auto-enrolment enrols all active and Live cards. It is not recommended if you wish to exclude some cardholders from enrolment. If using Continuous auto-enrolment, this may restrict your ability to unenrol cards which currently have a live status. See Section 8.2 Card Unenrollment.

Options are:

• NO — All email addresses for cards must be enroled using either the Thredd API or the Cards API.

• YES — Initial Load only — This will take email addresses which are added when card is created or card details are updated. After initial load, auto-enrolment will be disabled and Program Manager will need to initiate the Thredd API or the Cards API for new card enrolments.

• YES — Continuous — Same as Initial load, however auto-enrolment will remain enabled. New cards created with email addresses will also be enroled in the same way. Your organisation will not need to send the Thredd API or the Cards API to enrol new cardholders.

Auto-enrolment enrols all active and Live cards. It is not recommended if you wish to exclude some cardholders from enrolment. If using Continuous auto-enrolment, this may restrict your ability to unenrol cards which currently have a live status. See Section 8.2 Card Unenrolment.

Time to complete authentication in seconds. Countdown timer will be displayed in the Challenge screen. This is customisable up to 10 minutes (600 seconds) as per EMVCo requirements. The standard is 300 seconds (5 minutes).

If a fallback method is initiated, the timer will be restarted for the new authentication method.

For Out of Band and Biometric authentication, and to access the Thredd oAuth endpoint, in the UAT environment.

Your endpoint for receiving the DelegateSCANotification API call to start an Out of Band or Biometric authentication.

Please only supply one endpoint for the UAT environment.

Please ensure that the provided endpoint is resolving to one or set of (maximum 5) Static IP addresses.

For Out of Band and Biometric authentication, and to access the Thredd oAuth endpoint, in the UAT environment.

Please provide your endpoint IP addresses for connection to the UAT environment. This should be no more than 5 static IP addresses.

For Out of Band and Biometric authentication only in the Production environment.

Your endpoint for receiving the DelegateSCANotification API call to start an Out of Band or Biometric authentication.

Please only supply one endpoint for the UAT environment, and one endpoint for the Production environment.

Please ensure that the provided endpoint is resolving to one or set of (maximum 5) Static IP addresses.

For Out of Band and Biometric authentication only in the Production environment.

Please provide your endpoint IP addresses for connection to the Production environment. This should be no more than 5 static IP addresses.

Total number of questions which the cardholder is required to answer.

Total number of questions which the cardholder is required to answer correctly to successfully authenticate the transaction.

Total number of questions that the cardholder may answer incorrectly before KBA is failed.

The number of times that a cardholder can request for a new OTP to be resent via SMS or Email. The standard retry is 3, however this can be increased up to 5 retries.

The number of times that a cardholder can input the wrong value and still continue the process. After this the authorisation will decline and would need to be re-attempted.

The number of times that a cardholder can enter the incorrect answer for each question.

We recommend you keep this at a minimum to prevent brute force attack.

Text that appears as the sender of the SMS OTP (e.g., Program Manager name or Card brand).

Can be up to 11 alphanumeric characters with no spaces.

This Sender ID will be used for all SMS services. Please make sure to match this with SMS SENDER NAME in the core product Setup Form.

The "From" email address for the email OTP (i.e., from your organisation). Apata will complete the registration to send the OTP Email to your cardholders on your organisation's behalf. An authorisation email will be initiated to the email domain administrator. Authorisation will be required via the link in the email to complete the setup.