How to create rules for RDR powered by Verifi

RDR will automatically “accept” a Visa pre-dispute on your behalf, based on the rules you define as part of enrolment. Rules are composed of conditions that mirror the attributes of the disputed transaction, such as the transaction amount or purchase identifier. In the rule evaluation process, the outcome will result in either an "accept" or a "decline" response.

This guide will walk you through everything you need to know to properly set up your rules to avoid chargebacks through RDR.

Understanding RDR Rules

Rules are composed of the following major elements:

Rule Name

Rule Attributes

Attribute

Definition

Personal Account Number BIN

6-digit Issuer BIN

Transaction Date

Date when the transaction occurred

(E.g. Format: DD/MM/YYYY)

Transaction Amount

Total amount of the transaction

(E.g. Format: 10.00)

Transaction Currency Code

ISO currency code of the transaction

(E.g. GBP)

Purchase Identifier

Unique order identifier assigned to every transaction.

Transmitted to the Issuer by the Acquirer to identify the customer order for automated resolution.

Dispute Category

Code defined by Visa to classify the dispute

(E.g. 10- Fraud, 11- Authorisation, 12- Processing Errors, 13- Consumer Disputes. Please refer to table below for all Dispute Categories)

Dispute Condition Code

Sub-code of the Dispute Category to further classify the Dispute

  • (E.g. 10.4- Other Fraud - Card-Absent environment, 13.3- Not as Described or Defective Merchandise/Services)

Rule Operators

Operator

Definition

Contains

Attribute must include the specified value

EqualTo

Attribute must be equal to the specified value

GreaterThan

Attribute must be greater than the specified value

GreaterThanOrEquals

Attribute must be greater than or equal to the specified value

IsBlank

Attribute does not include a value. Can be True or False.

LessThan

Attribute must be less than the specified value

LessThanOrEquals

Attribute must be less than or equal to the specified value

NotEqualTo

Attribute is not equal to the specified value

StartsWith

Attribute must start with the specified value

IsIn

Attribute must contain the chosen possible values.

  • Note: For Transaction Date, possible values are 30, 60, or 90 days.

IsNotIn

Attribute must not contain the chosen possible values.

  • Note: For Transaction Date, possible values are 30, 60, or 90 days.

Rule Values

Attribute

Format

Possible Values

Possible Operators

Personal Account Number BIN

Number

Should be the 6-digit

Issuer BIN.

Contains, EqualTo, IsBlank,

NotEqualTo, StartsWith

Transaction Date

Date

Date in DD/MM/YYYY

EqualTo, NotEqualTo,

GreaterThan,

GreaterThanOrEquals, IsIn,

IsNotIn, LessThanOrEquals,

LessThan

Transaction Currency

Code

Dropdown or freeform

Alphanumeric

ISO 4217 Currency Codes

Select the transaction’s

currency from the

dropdown. You can select

multiple values for “IsIn”

and “IsNotIn”.

Contains, EqualTo, IsBlank, IsIn,

IsNotIn, NotEqualTo, StartsWith

Purchase Identifier

Alphanumeric

Should be the unique order identifier assigned to every transaction.

Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith

Dispute Category

Dropdown or freeform

Select from the following:

10-Fraud

11-Authorisation

12-Processing Error

13-Consumer

Contains, EqualTo, NotEqualTo,

IsBlank, IsIn, IsNotIn

Dispute Condition Code

Drop down or freeform

Select the appropriate

code from the table below

Contains, EqualTo, NotEqualTo


Rule Setup Considerations

Here are some principles to keep in mind when determining your rules:

  1. Rules must be defined for every Merchant BIN/CAID combination.
  2. Each BIN/CAID can have up to 10 different rules. A rule can have up to 7 conditions.
  3. All fields in the rule (Attribute, Operator, Value) are mandatory. Please do not leave any field blank.
  4. Some Attributes can use approximate match operators such as “StartsWith” or “Contains”. The minimum value for these attributes is at least one character or digit.
  5. As best practice, it is advised to not use the free-form entry (where provided) along with approximate match operators such as “Contains” and “IsIn”. This may result in multiple cases with similar matches being accepted.
  6. Rules are evaluated in sequence (rule one is evaluated first, then rule two, etc.). If there are five rules and the conditions of the first rule are met, then the remaining rules are not evaluated.
  7. If the conditions of any rule are met, then the pre-dispute is “accepted”, resulting in a refund back to the Cardholder.
  8. If a rule has multiple conditions, all conditions of the rule must be met to “accept” liability.
  9. If none of the conditions of all the rules you have created are met, then the pre-dispute is “declined” and results in a chargeback.
  10. For any RDR case that is “accepted”, the Rule Name of the rule that was triggered is shared with the Merchant’s Acquirer and the Issuer of the Cardholder to let them know why the dispute was resolved.

Best Practices for Rule Management

  1. Do not include contradictory dispute categories and condition codes (e.g. a Dispute Category = “10” and a Dispute Condition Code = “12.1”).
  2. A rule should not conflict with another rule (e.g. “Transaction Date IsGreaterThan 01/01/2020” in one rule and “Transaction Date IsLessThan 01/01/2020” in another)
  3. If Transaction Amount is a condition in a rule, it should have a corresponding condition for Transaction Currency Code.
  4. Keep rule names short, explicit, and clear enough to be referenced in RDR communications. It is recommended to keep the name within 30 characters.

Dispute Category and Condition Codes

10. Fraud

11. Authorisation

12. Processing Errors

13. Consumer Disputes

10.1 - EMV liability shift counterfeit fraud

10.2 - EMV liability shift non-counterfeit fraud

10.3 - Other fraud-card present environment

10.4 - Other fraud-card absent environment

10.5 - Visa fraud monitoring program

11.1 - Card recovery bulletin

11.2 - Declined authorisation

11.3 - No authorisation

12.1 - Late presentment

12.2 - Incorrect transaction code

12.3 - Incorrect currency

12.4 - Incorrect account number

12.5 - Incorrect amount

12.6 - Duplicate processing/paid by other means

13.1 - Merchandise/Services not received

13.2 - Cancelled recurring

13.3 - Not as described or defective merchandise/services

13.4 - Counterfeit merchandise

13.5 - Misrepresentation

13.6 - Credit not processed

13.7 - Cancelled merchandise/services

13.8 - Original credit transaction not approved

13.9 - Non-receipt of cash or load transaction value