Managing Risk

Managing risk is always a trade-off. You can only make your systems 100% secure by not allowing any transactions. The risk of fraud needs to be balanced against the flexibility and ease of use you want to enable for your customers. Below are details of Thredd products and services that can help to reduce the incidents of fraud.

Cardholder Verification Checks

These are checks which merchants can use to verify the identity of the cardholder:

  • PIN verification - typically a 4-6 digit personal identification number (PIN) is entered by the customer at a POS terminal or ATM and verified by Thredd . PINs are blocked after three incorrect attempts. You can change card PINs and unblock PINs using the Thredd Web Services.

  • Address Verification Service (AVS) – an AVS check compares the billing address used in the transaction with the issuing bank’s address information on file for that cardholder. Depending on whether they match fully, partially, or not at all, the merchant can use that information in their decision on whether or not to accept or cancel the order. AVS is one of the most widely used fraud prevention tools in card-not-present transactions.

Card Verification and Security Checks

When the card is used, there are a number of card verification and security checks that can be performed at the point of sale, to validate that the card is a genuine card:

  • Card Verification Value/Code 1 (CVV1 or CVC1) — a 3-digit number which is located on the card’s magnetic stripe tracks 1 and 2. It is used to help prevent fake magnetic stripe transactions, but is vulnerable to copying if someone can see the original magnetic stripe data. See also Card Verification Value/Code 2 (CVC2 or CVV2).

  • Card Verification Value/Code 2 (CVV2 or CVC2) — a 3-digit number which is located on the card, entered by the customer in an e-commerce transaction. It is used to help prevent fake magnetic stripe transactions, but is vulnerable to copying if someone can see the original magnetic stripe data.

Card Control Groups

Thredd provides a number of options to enable you to manage the risks associated with card payments. For example:

  • Limit groups - Velocity limit group which restricts the frequency and/or amount at which the card can be loaded or unloaded.

  • Usage groups - Group that controls where a card can be used. For example: Point of Sale (POS) or ATM.

Card control groups are set up at the time when you first implement your card program through Thredd. Options are specified using your Thredd Product Setup Form (PSF)Closed The Product Setup Form is a spreadsheet that provides details of your Thredd account setup. The details are used to configure your Thredd account.. You can manage the control groups linked to a card using the Thredd API.

For more information, see the Cards API Website (REST API) or Web Services Guide (SOAP API).

The figure below provides an overview of the types of security measures and controls that can be implemented on a card.

Figure: Flexible options for controlling where and how a card can be used

Permission Lists

You can configure allow and disallow lists which determine where a card can be used, based on the country or Merchant Category Code (MCC).

Cardholder Authentication (3D Secure)

Cardholder authentication, also known as Payer Authentication, is a security process that protects both cardholders and merchants by verifying the cardholder's identity during an online transaction. Examples of cardholder authentication programs are Visa Secure and Mastercard Identity Check, which are both implementations of 3D Secure.

Thredd offers a fully integrated 3D Secure service for both Mastercard and Visa cards. For more information, refer to the 3D Secure Guide.

Fraud Transaction Monitoring

Thredd's Fraud Transaction Monitoring (powered by Featurespace) is a best-in-class, flexible card fraud solution that minimises online and offline card risk and offers real-time detection of card fraud.

Using adaptive behavioural analytics and machine learning, Fraud Transaction Monitoring adapts to new fraud types and identifies unknown threats by detecting unexpected changes (anomalies) in real-time data. This improves transaction monitoring, identifies fraud and reduces the number of occurrences where legitimate transactions are flagged as suspicious, payments are stopped or accounts locked.

For more information, see the Fraud Transaction Monitoring.

Real-time Events and Fraud Alerts

The Thredd Event Delivery System is a comprehensive service designed to facilitate real-time event subscription and notifications delivered to you via webhooks.

You can create webhooks, to enable real -time event notifications and fraud alerts to be sent to your systems, for forwarding on to your cardholders. For example:

  • Alert when a fraud rule is triggered by a transaction.

  • Alert to notify a customer when a card status changes. This event code will also send an EMV chip block script when an irreversible card status is set.

  • Alert to notify a customer when there's a potential scam payment on their card.

For more information see the Cards API Website: Introduction to Webhooks.

BIN Attacks

A BIN attack is a type of automated card fraud attack that if successful can affect hundreds or even thousand of cards and customers, and have a potentially catastrophic impact. BIN attacks are ultimately an attack on the card issuer, but can affect merchants and/or card acquirers, as fraud losses can potentially be 'charged-back' by the card issuer.

BIN attacks can occur by:

  1. Targeting a bank's BIN

    The fraudster chooses a financial institution to target, and acquires their Bank Identification Number (BIN). These numbers are public knowledge, so they are very easy to acquire and serve as an ideal starting point for someone attempting to perform a brute-force attack.

  2. Generating possible card numbers with software

    The BIN is only a portion of the full card number, so the fraudster has to generate possible account numbers for the card. While this can be done manually, typically, fraudsters employ software to generate possible card numbers based on the BIN they are targeting. This enables the fraudsters to generate thousands of potential card combinations for the financial institution they are attacking very quickly.

  3. Testing BINs

    When the fraudsters have generated card numbers, they need to test to ensure that the credentials work and they can complete a purchase. Essentially, they are verifying which cards can be used for fraud. The fraudster will perform a series of small transactions with each number until they succeed.

  4. Perform Fraudulent Transactions

    When a card is successfully used to make a fraudulent transaction, the fraudsters store the information so they can make further fraudulent transactions with it. This is so that when they’ve tested the card works and have the proper credentials, they can begin to commit fraudulent transactions. The fraudster can then continue to commit fraud using the stolen credentials until the card is cancelled or the authentication credentials are changed.

To protect against BIN attacks issuers need to adopt a multi-layered strategy including product design, authorisation system strategies, real-time fraud detection, and tried-and-tested response processes.

The Fraud Transaction Management Portal is well-placed to defend against BIN attacks, helping to overcome weaknesses in issuer or acquirer defences. The Portal uses a unique Adaptive Behavioural Analytics approach that profiles ‘normal’ behaviour and identifies anomalies, with rules that are able to learn in real-time.

How Thredd can Help Mitigate BIN Attacks

The Adaptive Behavioural Analytics approach flags anomalies where flagged transactions confirmed as fraud provides real-time feedback to the model, which can prevent fraud attacks from scaling. As flagged transactions are confirmed as fraud this provides real-time feedback to the model, which can prevent fraud attacks from scaling.

You can help to prevent BIN attacks by setting up rules in Fraud Portal to capture them. For example, when several low volume authorisations happen for the same value in a very short space of time we recommend setting up stateful rules to manage this. Attacks like card testing and enumeration are different from normal cardholder behaviour, so you can use stateful rules to detect these attacks in real-time. These rules use constantly updating entity profiles to check if a merchant is under attack, returning a BIN attack tag alongside the model score.

For example, if a rule detects 10 declines with a response code of 14 from 10 different cards in 30 seconds, it flags the merchant as under attack and a BIN attack reason code is applied. If the rule doesn't trigger again in 3 hours, then the merchant is no longer considered as under attack. It will be scored normally by the model in either case.

For information on how to build rules that can help prevent BIN attacks, see the Fraud AMDL Rules Configuration Guide.