Real Time Fraud Screening

This document is a technical introduction to the Retail Decisions (ReD) Service. It assumes the reader has familiarity with the DataCash Credit and Debit Card service. Further detailed information to assist integration with the Service is available in the Developers Guide.

The ReD Service screens transactions before authorisation takes place.

There are two components which are used by the Service: screening databases and transaction rules

Screening Databases

ReD checks all transactions against global screening databases when processing ebitGuard transactions. ReD holds one of the world's largest and most up-to-date screening databases dedicated to protecting CNP merchants from known fraudsters.

ReD's databases are continually updated as new information is received. Around 20,000 cards are added daily, making the databases invaluable weapons against so-called 'same day' fraud.

Most of the information currently stored on ReD's databases consists of card numbers. However some additional information is also stored, and the screening databases' capabilities are being expanded to make storage of additional information easier.

This information enables ReD to screen out transactions on known fraudulent cards, CNP dispute-prone e-shoppers, known fraudulent originating or destination phone numbers or IP addresses and known lost and stolen foreign cards.

Transaction Rules

Sector specific statistical rules are applied in real time to identify high risk transactions, as are an appropriate combination of simple, compound and analytical velocity rules. The criteria used include card number, BIN range, country of issue, card type, merchandise type, delivery address, originating IP address and email address.

There are two types of Transaction Rules model:

  • Standard Model - specific to the customer spending patterns in your market sector. It is constantly being fine-tuned to provide optimal screening for your sector.
  • Bespoke Model - enables you to apply specific rules that reflect your experience and business needs. Detailed historic and chargeback transaction data is the key to effectively configuring a bespoke model. The analysis and development of a bespoke model will take around three or four weeks.

Requirements

Before you can go live with this service you will need the following:

  • an account set up with DataCash for Credit and Debit Card Processing
  • the account to be configured for ReD
  • the ability to send the extended XML data set to our servers

If you are already accepting payments, you will need to provide data about your customers, transactions and any existing chargebacks you may have received. This information will be analysed in order to tune the system to your business requirements.

Transaction Processing Models

Both the one stage and two stage transaction processing models can be used. These are outlined in the Credit and Debit Card Service. When using the two stage model, the fraud screening takes place for the first stage of the transaction.

A small number of transactions may be returned as potentially fraudulent. For these transactions, you may review the customer details and accept the transaction if you feel confident.

Transaction Type Effect Uses
accept_fraud Allows processing of transaction Enables a potential fraudulent transaction to be accepted

Performing Transactions

Both authorisations and accept_fraud transactions require the client and password to be provided, along with additional information as outlined below:

Authorisation Requests

The following information will be taken from the standard Credit and Debit Card transaction request:

  • the card number
  • card expiry date
  • issue number or start date
  • value and currency
  • the transaction type
  • the date and time of transaction

For merchants using the market sector model, the following details about the customer should be considered to be the very minimum. Each of the fields triggers one or more rules, so if the fields are not provided, the service will be running sub-optimally:

  • customer name
  • customer contact details - including email address, telephone number and IP address
  • the delivery address
  • the billing address, if it is different from the delivery address
  • cv2 details

The more information that can be provided, the more accurate a picture of the customer can be built. You should send as much as you can. Additional information can also include:

  • details of the items in the order
  • customer age / age-range
  • additional contact details
  • customer history
  • recipient details
  • delivery mechanism details

Merchants using a bespoke model should ensure that the correct information is provided.

Over-riding challenges

To enable a challenged transaction to be processed, two additional pieces of information are required:

  • the datacash reference of the transaction
  • the transaction type - accept_fraud

Return Codes

The three basic ReD Responses for authorisation requests:

  • Accept
  • Challenge
  • Deny

There are no error codes generated specifically for this service, though the general error codes may be generated. The Support Centre also contains extensive examples for most error codes. Illustrations and suggestions are given to help you prevent them from occurring.

Accept

An Accept response indicates that the transaction has not triggered any of the rules and is unlikely to be fraudulent. There are two varients of Accept Responses.

Challenge

Occasionally, there will be transactions which are probably fraudulent, but for which the evidence is not strong enough to issue an automatic Deny response. These return a Challenge response. The payment is sent to the bank for authorisation. Provided the bank authorised the transaction, you have the option of accepting it using the accept_fraud transaction, up to seven days after it was submitted. There are two types of Challenge Responses.

Deny

A Deny response indicates that a transaction is almost certainly fraudulent. Transactions that are denied are not passed to the bank for authorisation. There are four varients of the Deny response.

Reporting

The results of the ReD fraud screening are available in the Bank Card section of Reporting. Transactions which have been screened will display additional information about the outcome of the check.

ReD also provide a Customer Service Interface (CSI) which shows full details of the transaction and highlights which components have been used to screen the transaction.