Airline data leg
This rule allows you to block or trust transactions based on the legs of a journey.
You must submit airline-specific data with the payment request.
Submit each leg individually, in IATA format. Give the leg a positive score to block it, or a negative score to trust it. Set each leg individually. For example, if you create a rule between AMS and JFK, you must create a separate rule between JFK and AMS.
Airline data one way ticket
Triggers if the airline ticket purchased is a one-way ticket. One way airline tickets have a higher probability of being fraud.
You must submit airline-specific data with the payment request.
Bank account is not likely to be a consumer bank account
Triggers if the provided account number is likely not a real consumer bank account.
This rule confirms the provided number has the correct number of digits and has a check digit (for ELV).
Bank account number contains a numeric sequence
This rule fires in situations in which the bank account used for Direct Debit payments has a direct numeric sequence.
Fraudsters attempt numeric sequences of bank account numbers until they get a match - an example of a sequence is a bank account number is 1234567890.
Bank address does not match any branch offices (ELV)
Triggers if the provided bank address does not match any registered branch office for that bank. This rule is specific to ELV payments.
Bank name does not match bank location id (blz.) (ELV)
Triggers if the provided bank name does not match any registered branch office for that bank. This rule is specific to ELV payments.
Billing address differs from delivery address
Triggers if the billing address is different to the delivery address.
An address must be submitted in the payment request for this rule to work properly.
Fraudsters often deliver goods to a different location than indicated in the billing address of the stolen payment details. Addresses are normalized for accurate matching when minor differences in spelling and formatting occur. Comparison is limited to the country, postal code, and house number.
Billing address does not match cardholder address (AVS)
Triggers if AVS reports a mismatched cardholder address. Address Verification System (AVS) is a security feature that verifies the billing address of the cardholder. It does this by comparing the billing address the shopper enters with the address on file with the card issuer. AVS validates the street address and ZIP/postal code of the shopper. AVS gives you better protection against fraud, and lower interchange fees in the United States, as you can qualify for the lowest rate.
AVS for Visa, Mastercard, Discover and American Express is supported by Adyen in all countries, for a limited number of issuing banks. For payments outside Canada, the United States and United Kingdom, some configuration may be required. Contact our Support Team for more information. If AVS is not supported, this risk rule is not performed.
This risk rule is based on the issuer and may not be available for every transaction.
You can configure how the AVS risk rule is triggered:
- Need to Match: Triggers if a request receives a Match does not occur or Unable to perform check response.
- Match or Unable to Perform Check: Triggers if a non-match response is received.
- No Need to Match: Turns off this rule for this data point (address or postal code).
In some scenarios, Adyen receives back an unknown error response. You can select to either allow or disallow transactions with this response.
We recommend setting the risk level for this check as Match or Unable to Perform Check for postal code and address. Turn on Unknown Response OK? to allow unknown error responses.
See Address Verification System (AVS) for more information on how to enable and test AVS, and for an overview of AVS responses.
Card Security Code (CVC2/CVV2/CID) does not match
Triggers if the card issuer responds that the user-entered verification code did not match that of the card.
The issuing bank declines mismatching transactions in most cases, as these transactions have a high likelihood of fraud.
You can configure how this rule is triggered:
- Need to Match: When this is selected, the rule fires when the Match does not occur response, and Unable to perform check response is received.
- Match or Unable to Perform Check: In this configuration, the rule fires when a non-match response is received.
- No Need to Match: Under this configuration, the rule will not fire if a non-match response is received. This essentially turns off this rule.
In some scenarios, Adyen receives back an Unknown error response. You can select to either allow or disallow transactions with this response.
Card/bank account holder name contains a non-alphabetic character
Triggers if the card/account holder name has any non-alphabetic characters in it. Fraudsters sometimes insert random characters in the cardholder name field.
This rule is not triggered by Roman, Hebrew, Cyrillic, Chinese alphabetical characters
Card/bank account holder name is one word
Triggers if the card or bank holder name has one word in it.
Fraudsters often enter one word in the cardholder name field, for example, "Jessica", "John", "Bob". The fraud scores triggers if this happens and attributes a score accordingly.
Triggers if the provided delivery method matches a configured value. This is most commonly used to flag express delivery transactions as higher risk.
Fraudsters want to ensure that as little time as possible passes between them committing a transaction, and receiving their goods. As such, faster delivery methods tend to be higher risk.
Enter a list of blocked delivery methods under Modify blocked delivery methods. The list is comma separated and the rule is case insensitive. For example: mail,email,download.
Email address and shopper name comparison
A match between the cardholder or shopper name with the email address indicates that the shopper is probably legitimate.
Email is likely to be fake or automatically generated
Triggers if the provided email address is likely fake or automatically generated. Fraudsters set up scripts to automate the creation of email addresses. Our prediction algorithm analyzes email address across our entire network and correlates certain attributes with fraud and known card-testing schemes.
Using this data, our risk system determines the probability that the email address is to be fake. You can set a separate risk score for payments that are Somewhat likely to be fraud and Very likely to be fraud. These scores will increase the total risk score of the payment.
Fraudulent behaviour on payment page
Triggers if the algorithm has detected behavior in the card number and/or CVC fields that appear to be scripted.
Fraudsters use scripts to test a set of cards. This risk rule analyses time taken, key-based, and mouse-based behaviors of users interacting with the payment fields.
Using this data, our risk system determines the probability that the behavior is fraudulent. You can set a separate risk score for payments that are Somewhat likely to be fraud and Very likely to be fraud. These scores will increase the total risk score of the payment.
Triggers if the issuing country for the shopper's payment method is in a list of countries which have a high percentage of fraudulent transactions.
Liability shift status
Triggers if a liability shift has not occurred with the transaction. Note that this rule has significant configuration implications.
Liability shift occurs when the liability of chargebacks passes from you to the issuing bank. This occurs when the transaction has been verified through 3D Secure. You can configure the rule to trigger for 3D Secure transactions or all ecommerce credit card transactions.
Be careful when changing 3D Secure settings as they can impact your conversion rate.
This rule is triggered for ecommerce transactions. Recurring (ContAuth) transactions have no liability shift by definition, thus are not analyzed and are accepted by this rule. Contact Support Team if you want to disable ContAuth transactions (via Transaction Rules) on this merchant-level account.
It is also possible to give a negative (trust) score for the rule.
You can determine on which transactions to apply liability shift, all transactions, 3D Secure transactions, or 3D Secure transactions without technical errors.
You can trigger the check on transactions where:
- Full authentication of the cardholder has not taken place: Triggers if the 3D secure server can not authenticate the cardholder. Full authentication is stricter and always requires a (Y)-Authenticated response. The issuing bank may grant a liability shift without an authentication.
- 3D Secure liability shift has not taken place: Triggers if no liability shift has occurred for the selected transaction types. This does not always require full authentication by the user, for example, for automated authorizations performed by the issuing bank.
PayPal auth-result email
Triggers if the shopper email provided matches the shopper email registered with PayPal. The trust score can be used for shoppers that should be considered trustworthy, for example, shoppers with a history of legitimate purchases. Setting a negative score will decrease the chance of a transaction being refused.
PayPal protection eligibility
Triggers if the payment is eligible for seller protection. Set a negative score to decrease the chance of a transaction being refused. Increase the risk score to highlight orders where seller protection is Ineligible.
- Set the level of protection eligibility: Full or Partial.
PayPal verified shopper
Triggers if the PayPal account used by the shopper is verified. Otherwise it will be marked as unverified. This rule also triggers fraud when the payer status is missing. Set a negative trust score for trustworthy shoppers to decrease the chance of a transaction being refused. For example, shoppers with a history of legitimate purchases.
Triggers based on the payment method used. Some payment methods have more instances of fraud. This check lets you change the risk score based on the payment method behavior.
Shopper IP originates from high-risk country
Triggers if the shopper's country (determined by IP address) is in our list of high-risk countries. This check comes with some countries included by default. See How do I add shoppers to a block or trust list? to know more.
Note that IP addresses are not guaranteed indicators of a user's true country. Proxies and VPNs allow for fraudsters to hide their true location. This check should be paired with the use of the shopper using an anonymous proxy check.
Shopper account age
Triggers based on the date the shopper's account was created. This can either be provided as part of the payment request, or the check can use the oldest transaction within the shopper's ShopperDNA network.
Shopper country differs from issuing country
Triggers if the shopper's country is different to the issuing country of the card, which may indicate fraud. Set the risk score based on your business type. For example, Airlines can expect users are not in the country from which their card was issued.
Configure certain country combinations to allow mismatches to occur. For example, where IP addresses are cross countries, such as in Belgium/France/Netherlands.
You may need to provide two configurations for any country-pair. For example, a configuration with 'Belgium/Netherlands' and 'Netherlands/Belgium'.
Shopper email validity
Triggers if the provided shopper email address does not appear to be a real email address.
This risk rule verifies that the email provided in a transaction is valid, using analysis of both the domain and the DNS mail-delivery MX record.
Shopper using anonymous proxy
Triggers if the shopper appears to be using an anonymous proxy service.
Fraudsters often use anonymous proxies to hide their identity. While proxies are not always indicative of fraud (one may use proxies in an office environment), it can be an indicator of possible bad intent.
Time To delivery
Triggers based on how close the transaction is to the delivery date. This can be used by airlines to calculate how far the transaction is to the takeoff time or by ecommerce merchants to correlate with express shipping.
You must provide the delivery time value in the payment request.
Triggers based on the transaction amount. It is common for fraudsters to focus on higher-priced goods, to maximize their gains. This check can be used to either apply increased scrutiny to higher-priced goods or to focus specifically on the average-transaction-value that correlates with chargebacks.
Triggers if the transaction falls within one of the configured time frames.
Fraud can spike at specific times when legitimate transactions are limited, like during the night. This rule allows you to increase or decrease the risk score accordingly.