Card issuing banks and payment acquirers regularly monitor activities on customers’ accounts to check if any of those have a risk of being fraudulent. Investigating every transaction in real time is a complex task which can only be achieved by employing a suite of fraud protection software. In this section, we describe the fraud protection tools and filters (often called “controls”) provided by online merchant, payment acquirers and card issuing banks.
Address Verification System (AVS)
AVS can be used by merchants to validate the billing address provided by the customer at the checkout page against the address information stored at the card-issuing bank. AVS is an issuer-side control, which means enquiries are made during authorisation phase. The issuing bank will respond to the payment acquirer’s request with the result of the authorisation process, along with an AVS
response code. A response code can either be a “full match”, “no match” or “partial match” and it is completely up to the merchant to decide whether to evaluate the response code and take the
appropriate action based on their risk management plan, or not. Regardless of the value of the AVS response, the merchant can still proceed with accepting the transaction as long as there is an
acknowledgement of successful authorisation from the issuing bank. AVS can be further improved at the payment acquirer level through the provision of:
International Shipping/Billing Address Checks (ISF): This flag is used by the merchant to
screen orders requested to be shipped or completed to foreign country. Such transactions trigger ISF flag and a merchant may either decline a transaction or evaluate it with further
International AVS Check: Some merchants limit their services only to domestic customer. For example, Visa checkout [95] only allows US based customers to register their cards on their payment system. Any transactions made using cards issued by foreign banks are declined.
Shipping/Billing Address Mismatch Checks: Orders with different shipping and billing
address are either declined or evaluated with further verification checks.
Postal code Risk List Match Checks: Payment acquirers maintain a history of all fraudulent
transactions made at specific address zones. New orders involving risk zones trigger this flag, indicating the possibility of new fraudulent transaction. However, there is a problem here. Our experiments have confirmed that different websites perform varying levels of validation upon the address field and the address validation is only on the numeric digits:
o Full Validation: the website validates the full postcode digits and the house number, against the address details held by the issuing bank for the cardholder.
o Postcode validation: the website validates the full postcode digits ignoring the door number against the details held by the issuing bank.
o Postcode prefix validation: the website validates only the prefix of the postcode, for example if the cardholder’s full postcode was AB1 2CD the website would validate as correct any postcode starting with 12.
Card Security Code Checks
Issuing banks can also perform CVV2 checks during payment authorisation. For a given PAN, the system generates the CVV2 using (keys) and compare it against value provided by the customers during checkout. Results are later made available for merchants (match or no-match) to decide the outcome for purchase request.
At this point, it is very important to note the shift of liability. Regardless of the outcome from the AVS and CVV2 filters, banks take no responsibility, therefore merchants have to reimburse the card holders for any transactions that are later marked as fraudulent. Card Issuer banks takes fraud liability only for 3D Secure enabled transactions.
Email Service Provider (ESP) and IP Risk List Match Filter
This filter screens for the transaction requests originating from specific domain email addresses. Standard email service providers sometimes keep track of their users’ behaviour which may also include traceable information such as IP address and location information [96]. Not to get traced, fraudsters can use completely random and disposable email addresses which are valid only for a few minutes. Such email id’s are freely available online through domains like [97] and requires no prior user registration. ESP put a hold on any transaction made using fake and short-lived email addresses and warn merchants about the likelihood of cheat.
Velocity Checks
One way to detect potentially fraudulent activities is by monitoring the number of invalid login attempts made in a certain time span. Attackers can develop and use automated tools against checkout systems to learn passwords and another login information. PCI DSS in requirement 8.1.6 [21]
describes testing procedures and guidance to be adopted against brute force attacks to gain unauthorised control of a user account. The requirement states that the procedure to be taken is to restrict continuous login attempts and lock out the affected user account temporarily after five or more attempts. This is called “velocity check” and there are two types of velocity checks that are of
importance here:
IP Address Velocity Checks: Blocking legitimate access to a customer account can
adversely affect the customer’s experience and ultimately might cause loss of business to the merchants. Merchants and acquirers must, therefore, operate an intelligent approach, for example by blocking IP address of known malicious customers attempting to brute force the login, while letting through legitimate customers. Any consecutive login requests originating from blacklisted IP addresses are either blocked or are evaluated under PAN velocity rules which is explained later on.
Limitations: IP address velocity filter works well for login requests originating from static IP addresses. However, attackers can trick the IP velocity filters by making use of dynamic IP addresses. Moreover, many proxy servers and internet service providers forward requests from customers by routing them to merchant websites through a static IP. In such
transactions, IP addresses recorded are of proxy servers’ and not of the actual customers’. This will trigger the IP velocity filter to reject the transactions. The bottom line is that fraudsters using a proxy account are harder to track.
Account/PAN Velocity Checks. Just as IP velocity filters tracks IP addresses, acquirers or merchants can use the account number velocity checks to keep an eye on the frequency of use for card numbers. The advantage of using PAN velocity filters is that: if an attacker bypasses the IP filters, multiple purchase requests targeting compromised card number can still be tracked. For example, in the latest payment processing schemes like Verified by Visa and MasterCard Secure Code, irrespective of customers’ IP address, cards are blocked for making payment after four invalid transaction attempts.
Transaction Amount Checks
When it comes to electronic purchase on the Internet, transactions can be of any value and/or
currency. Largest single online CNP transaction recorded is amounted to 40000000 US DOLLAR(S) by Mark Cuban in 1999 [98]. Card details if compromised, attackers can effort buying a high-value
banking systems usually marks higher value purchase as suspicious until the transaction is actually verified by real cardholders.