Merchants who follow protocol, sending basic payment information to their merchant banks for authorization, often believe that receiving an authorization code means the credit card is good and there''s no risk that the charge will be disputed or reversed later. In fact, all that an authorization code from the merchant bank means is that the card number that was submitted is a valid credit card number, it hasn''t been reported stolen, and the amount of purchase does not put the card holder above his credit limit.

There are a number of ways in which the charge can still be reversed, even if these three conditions are met. The most likely situation is that the person using the card number might not have been the authorized user of the card. If the cardholder left a receipt somewhere with his card number, and someone else picked it up, then the card number may be compromised without the cardholder being aware of it. Since the card hasn''t left the cardholder''s possession, it hasn''t been reported as stolen. Under this scenario, the merchant is out of luck. The cardholder will contest the charge and win.

There are three levels of fraud protection that merchants can implement to guard against credit card fraud. In order of increasing security, they are:

• Address verification
• Risk profiling using a service like eFalcon
• Enhanced risk profiling using a service like Retail Decisions in conjunction with eFalcon

Address Verification
Many merchants assume that address verification is taking place when they submit a request for authorization to their merchant bank, when in fact, AVS (address verification services) are an enhancement to the standard request for authorization that merchants submit. Additionally, a request can be authorized even if the address given by the purchaser doesn''t match the billing address. It''s up to the merchant to evaluate the AVS return code that accompanies the authorization code to see whether and to what degree the address matches, then to make a decision based on all the information as to whether to ship products to the purchaser.

The AVS return codes are as follows:
X: Exact match, address and 9-digit zip code
Y: Exact match, address and 5-digit zip code
A: Address matches, zip code does not
W: 9-digit zip code matches, address does not
Z: 5-digit zip code matches, address does not
N: Address and zip code do not match
U: Address information is unavailable
R: Retry, system is unavailable
S: Service not supported
E: Data not available / Error invalid

As you can see from the list, there is a range of possible matches. If a merchant chooses to use AVS, then it needs to have policies in place for handling each possible AVS return code. The policies may be based on a combination of the return code and the purchase amount, or the return code with some flexibility for returning customers. The important thing to note is that even if the AVS return code is N for not matching, the bank may authorize the purchase based on the card number being valid, the amount being within the credit limit, and the card number not being on a reported stolen list.

Risk Profiling
One company has been offering fraud prediction services for the credit card industry for many years, predating the online retail industry by nearly a decade. With the rise of the Internet, HNC Software now offers a service to e-businesses on an ASP model called eFalcon.

Merchants that use eFalcon become part of the HNC consortium of merchants. This means that they get the advantage of information gleaned not only from their own transaction requests, but also from those of all the other merchants in the network. eFalcon becomes smarter and more powerful, the more merchants and transactions there are that pass through it. It accumulates profiles of shopping behavior to help in the fraud evaluation. It knows, for example, that I tend to shop up until 11pm EST, and spend up to $120 online routinely. Consequently, any purchase request that took place after 11pm EST for much in excess of $120 might be flagged as suspicious for my card number.

A merchant sends up to 150 parameters of the purchase to eFalcon in real time, and receives back a score for the purchase, ranging from 1 to 999. The higher the number, the higher the probability of fraud associated with this purchase. High scoring should be investigated by the merchant, either by following up with a phone call, or by requesting additional information from the purchaser on a page. eFalcon charges a flat fee for each transaction, depending on volume. eFalcon scores the transaction based on the profile associated with the card number, the merchant''s SIC code, and other factors. It does not, however, make a specific recommendation to accept or decline the purchase. Again, the merchant needs to make that decision on its own, based on the risk of fraud it''s willing to accept.

Enhanced Risk Profiling
eFalcon gives the merchant a very valuable tool to assist with assessing risk. Retail Decisions adds another layer of fraud prevention by working with merchants to create and automate policies for using the eFalcon data. Retail Decisions has a series of risk-management processes that they can use to help the merchant determine more narrowly whether to authorize the purchase or not.

Retail Decisions interprets the probability provided by eFalcon and works with the merchant to put rules in place using their own database of the compromised cards listed in the EWB (electronic warning bulletin), which is published weekly. Since compromised card numbers don''t stay on the EWB for more than a month (the card issuer pays for the listing), a card may once have been reported as compromised, then not be listed when the merchant receives it. In that situation, the merchant is liable for any chargebacks. Since Retail Decisions keeps a database of old EWB card numbers, the merchant using Retail Decisions would have the information it needed about the card to evaluate whether it should accept the purchase, deny the purchase, or challenge the purchaser to provide additional information about the credit card, such as the name of the issuing bank.

Retail Decisions can help a merchant make sense of the risk score assigned by eFalcon, and take appropriate action to accept the purchase when appropriate and deny the purchase when appropriate. Retail Decisions also has a database of high fraud ship-to addresses, so that it can take that information into account when helping a merchant make an accept/decline decision.

Human Intervention Necessary
Regardless of which fraud-prevention strategies a merchant uses, ultimately, a human being has to make policy decisions as to what the threshold for risk acceptance will be. While it''s time-consuming to call customers when the merchant thinks there may be a fraudulent purchase in process, both eFalcon and Retail Decisions mentioned it as a very effective method of preventing fraud. Despite a merchant''s misgivings that a customer might be offended by having his purchase challenged, both reported to me that customers are delighted that merchants are looking out for them.

Until some sort of client-side authentication that guarantees non-repudiation, such as SET or Wave Systems gains general acceptance, managing fraud will be a partly manual process. Ultimately, it''s the merchant that needs to decide what kind of risk he''s willing to take.

Alexis D. Gutzman is an E-commerce Technology Author and Consultant and author of The HTML 4 Bible, FrontPage 2000 Answers!, and ColdFusion 4 for Dummies. Her newest book, The E-commerce Arsenal: 12 Technologies You Need to Prevail in the Digital Arena will be out in October. She can be reached at agutzman@internet.com