281 lines
16 KiB
Plaintext
281 lines
16 KiB
Plaintext
Here's part 3 in my six-part series on the credit card industry. This
|
|
part discusses how authorization and settlement work. This is a long
|
|
one. It will help if you have read parts 1 and 2, since I had to leave
|
|
out a lot of overlap to keep this from getting ridiculous. Enjoy.
|
|
|
|
|
|
THE ACCEPTER
|
|
--- --------
|
|
|
|
An important fact to note is that a card accepter does not have to get
|
|
approval for any purchases using credit or charge cards. Of course, a
|
|
merchant is usually interested in actually getting money, and so must
|
|
participate in some form of settlement process (see below). Usually,
|
|
the most acceptable (to a merchant) forms of settlement are tied (by
|
|
the acquirer) to authorization processes. However, a merchant could
|
|
simply accept all cards without any validation, any eat any fraud that
|
|
results.
|
|
|
|
A merchant typically makes a business arrangement with a local bank or
|
|
some other acquirer for authorization and settlement services. The
|
|
acquirer assigns a merchant identifier to that merchant, which will
|
|
uniquely identify the location of the transaction. (This facilitates
|
|
compliance with federal regulations requiring that credit card bills
|
|
identify where each purchase was made.) The acquirer also establishes
|
|
procedures for the merchant to follow. The procedures will vary by
|
|
type of the merchant business, geographic location, volume of transac-
|
|
tions, and types of cards accepted.
|
|
|
|
If the merchant follows the procedures given by the acquirer and a
|
|
transaction is approved, the merchant is guaranteed payment whether the
|
|
card in question is good or bad. The purpose of authorization is to
|
|
shift financial liability from the acceptor to the acquirer.
|
|
|
|
There are two basic tools used - bulletins and online checks. Bulletins
|
|
may be hardcopy, or may be downloaded into a local controller of some
|
|
form. Online checks could be done via a voice call, a standalone ter-
|
|
minal, or software and/or hardware integrated into the cash register.
|
|
|
|
A low-volume, high-ticket application (a jewelry store) would probably
|
|
do all its authorizations with voice calls, or may have a stand-alone
|
|
terminal. A high-volume, low-ticket application (a fast-food chain)
|
|
will probably do most of its authorizations locally against a bulletin
|
|
downloaded into the cash register controller. Applications in between
|
|
typically merge the two - things below a certain amount (the "floor
|
|
limit") are locally authorized after a lookup in the bulletin, while
|
|
things over the floor limit are authorized online.
|
|
|
|
Usually a lot of effort is taken to use the least expensive tools that
|
|
are required by the expected risk of fraud. Typically, communication
|
|
costs for authorizations make up the biggest single item in the overall
|
|
cost of providing credit cards.
|
|
|
|
Large accepters are always a special case. Airlines are usually di-
|
|
rectly connected, host-to-host, to issuers and/or acquirers, and autho-
|
|
rize everything online. Likewise for many petroleum companies and
|
|
large department stores. Some large chains use different approaches at
|
|
different locations, either as a result of franchising oddities or due
|
|
to volume differences between locations. A lot of experimentation is
|
|
still going on as well - this is not a mature market.
|
|
|
|
For voice authorizations, the merchant ID, PAN, expiration date, and
|
|
purchase amount are required for an approval. Some applications also
|
|
require the name on the card, but this is not strictly necessary. For
|
|
data authorizations, the merchant ID, PAN, PIN (if collected), expira-
|
|
tion date, and purchase amount are required. Typically, the "discre-
|
|
tionary data" from track 2 is sent as well, but this is not strictly
|
|
necessary. In applications that do not transmit the PIN with the au-
|
|
thorization, it is the responsibility of the merchant to verify iden-
|
|
tity. Usually, this should be done by checking the signature on the
|
|
card against the signature on the form. Merchants don't often follow
|
|
this procedure, and they take a risk in not doing so.
|
|
|
|
In most applications, the amount of the purchase is known at the time
|
|
of the authorization request. For hotels, car rentals, and some petro-
|
|
leum applications, an estimated amount is used for the authorization.
|
|
After the transaction is complete (e.g. after the gas is pumped or at
|
|
check-out time), another transaction may be sent to advise of the ac-
|
|
tual amount of the transaction. More on this later.
|
|
|
|
|
|
THE ACQUIRER
|
|
--- --------
|
|
|
|
The acquirer gathers authorization requests from accepters and returns
|
|
approvals. If the acquirer is an issuer as well, "on us" transactions
|
|
will typically be turned around locally. As before, the acquirer does
|
|
not have to forward any requests on to the actual issuer. However,
|
|
acquirers are not willing to take the financial risks associated with
|
|
generating local approvals. Thus most transactions are sent on to the
|
|
issuers (interchanged). The purpose of interchange is to shift finan-
|
|
cial liability from the acquirer to the issuer.
|
|
|
|
Typically, an acquirer connects to many issuers, and negotiates differ-
|
|
ent business arrangements with each one of them. But the acquirer gen-
|
|
erally provides a uniform interface to the accepter. Thus, the
|
|
interchange rules are sometimes less stringent than those imposed on
|
|
the accepter. Also, most issuers will trust acquirers to with respon-
|
|
sibilities they would never trust to accepters. The acquirer can
|
|
therefore perform some front-end screening on the transactions, and
|
|
turn some of them around locally without going back to the issuer.
|
|
|
|
The first screening by the acquirer would be a "sanity" test, for valid
|
|
merchant ID, valid Luhn check on PAN, expiration date not past, amount
|
|
field within reason for type of merchant, etc. After that, a floor
|
|
limit check will be done. Issuers generally give acquirers higher
|
|
floor limits than acquirers give accepters, and floor limits may vary
|
|
by type of merchant. Next, a "negative file" check would be done
|
|
against a file of known bad cards. (This is essentially the same as
|
|
the bulletin.) Then a "velocity file" check may be done. A velocity
|
|
file keeps track of card usage, and limits are often imposed on both
|
|
number of uses and total amount charged within a given time period.
|
|
Sometimes multiple time periods are used, and it can get fairly compli-
|
|
cated.
|
|
|
|
Transactions that pass all the checks, and are within the authority
|
|
vested in the acquirer by the issuer, are approved by the acquirer.
|
|
(Note that, under the business arrangement, financial liability still
|
|
resides with the issuer.) An "advice" transaction is sometimes sent to
|
|
the issuer (perhaps at a later time), to tell the issuer that the
|
|
transaction took place.
|
|
|
|
Transactions that "fail" one or more checks are denied by the acquirer
|
|
(if the cause was due to form, such as bad PAN) or sent to the issuer
|
|
for further checking. (Note that "failure" here can mean that it's be-
|
|
yond the acquirer's authority, not necessarily that the card is bad.)
|
|
Some systems nowadays will periodically take transactions that would
|
|
otherwise be approved locally, and send them to the issuer anyway. This
|
|
serves as a check on the screening software and as a countermeasure
|
|
against fraudulent users who know the limits.
|
|
|
|
Transactions that go to the issuer are routed according to the first
|
|
six digits of the PAN, according to the ISO registry mentioned in an
|
|
earlier section. Actually, it's a bit more complicated than that,
|
|
since there can be multiple layers of acquirers, and some issuers or
|
|
acquirers will "stand in" for other issuers when there are hardware or
|
|
communication failures, but the general principal is the same at each
|
|
point.
|
|
|
|
|
|
THE ISSUER
|
|
--- ------
|
|
|
|
An issuer receiving an interchanged transaction will often perform many
|
|
of the same tests on it that the acquirer performs. Some of the tests
|
|
may be eliminated if the acquirer is trusted to do them correctly. This
|
|
is the only point where a velocity file can actually detect all usage
|
|
of a card. This is also the only point where a "positive file" lookup
|
|
against the actual account can be done, since only the issuer has the
|
|
account relationship with the cardholder. If a PIN is used in the
|
|
transaction, only the issuer can provide true PIN verification -
|
|
acquirers may be able to do only "PIN offset" checking, as described in
|
|
a previous section. This is one reason why PINs have not become
|
|
popular on credit and charge cards.
|
|
|
|
An account typically has a credit limit associated with it. An ap-
|
|
proved authorization request usually places a "hold" against the credit
|
|
limit. If the sum of outstanding holds plus the actual outstanding
|
|
balance on the account, plus the amount of the current transaction, is
|
|
greater than the credit limit, the transaction is (usually) denied.
|
|
Often in such a case the issuer will send back a "call me" response to
|
|
the merchant. The merchant will then call the issuer's number, and the
|
|
operator may even want to talk to the cardholder. The credit limit
|
|
could be extended on the spot, or artificially high holds (from hotels
|
|
or car rental companies) could be overlooked so that the transaction
|
|
can be approved.
|
|
|
|
The difference between the credit limit and the sum of holds and out-
|
|
standing balance is often referred to as the "open to buy" amount. Once
|
|
a hold is placed on an account, it is kept there until the actual the
|
|
transaction in question is settled (see below), in which case the
|
|
amount goes from a hold to a billed amount, with no impact on the open
|
|
to buy amount, theoretically. For authorizations of an estimated
|
|
amount, the actual settled amount will be less than or equal to the ap-
|
|
proved amount. (If not, the settlement can be denied, and the merchant
|
|
must initiate a new transaction to get the money.) Theoretically, in
|
|
such a case, the full hold is removed and the actual amount is added to
|
|
the outstanding balance, resulting in a possible increase in the open
|
|
to buy amount.
|
|
|
|
In practice, older systems were not capable of matching settlements to
|
|
authorizations, and holds were simply expired based on the time it
|
|
would take most transactions to clear. Newer systems are starting to
|
|
get more sophisticated, and can do a reasonable job of matching autho-
|
|
rizations for actual amounts with the settlements. Some of them still
|
|
don't match estimated amounts well, with varying effects. In some
|
|
cases, the difference between actual and estimated will remain as a
|
|
hold for some period of time. In other cases, both the authorization
|
|
and the settlement will go against the account, reducing the open to
|
|
buy by up to twice the actual amount, until the hold expires. These
|
|
problems are getting better as the software gets more sophisticated.
|
|
|
|
Some issuers are also starting to use much more sophisticated usage
|
|
checks as well. They will not only detect number of uses and amount
|
|
over time, but also types of merchandise bought, or other patterns to
|
|
buying behavior. Most of this stuff is new, and is used for fraud pre-
|
|
vention. I expect this to be the biggest effort in authorization soft-
|
|
ware for the next few years.
|
|
|
|
American Express does things completely differently. There are no
|
|
credit limits on AMEX cards. Instead, AMEX relies entirely on usage
|
|
patterns, payment history, and financial data about cardmembers to de-
|
|
termine whether or not to automatically approve a transaction. AMEX
|
|
also has a policy that a cardmember will never be denied by a machine.
|
|
Thus, if the computer determines that a transaction is too risky, the
|
|
merchant will receive a "call me" message. The operator will then get
|
|
details of the transaction from the merchant, and may talk to the
|
|
cardmember as well, if cardmember identity is in question or a large
|
|
amount is requested. To verify cardmember identity, the cardmember
|
|
will be asked about personal information from the original application,
|
|
or about recent usage history. The questions are not the same each
|
|
time. If an unusually large amount is requested, the cardmember may be
|
|
asked for additional financial data, particularly anything relating to
|
|
a change in financial status (like a new job or a promotion). People
|
|
who are paranoid about Big Brother and computer databases should not
|
|
use AMEX cards.
|
|
|
|
|
|
SETTLEMENT
|
|
----------
|
|
|
|
So far, no money has changed hands, only financial liability. The pur-
|
|
pose of settlement is to shift the financial liability back to the
|
|
cardholder, and to shift the cardholder's money to the merchant.
|
|
Theoretically, all authorization information can be simply discarded
|
|
once an approval is received by a merchant. Of course, contested
|
|
charges, chargebacks, merchant credits, and proper processing of holds
|
|
require that the information stay around. Still, it is important to
|
|
realize that an authorization transaction has no direct financial con-
|
|
sequences. It only establishes who is responsible for the financial
|
|
consequences to follow.
|
|
|
|
Traditionally, a merchant would take the charge slips to the bank that
|
|
was that merchant's acquirer, and "deposit" them into the merchant ac-
|
|
count. The acquirer would take the slips, sort them by issuer, and
|
|
send them to the issuing banks, receiving credits by wire once they ar-
|
|
rived and were processed. The issuer would receive the slips, micro-
|
|
film them (to save the transaction information, as required by federal
|
|
and state laws) charge them against the cardholder's accounts, send
|
|
credits by wire to the acquirer, and send out the bill to the
|
|
cardholder. Problem is, this took time. Merchants generally had to
|
|
wait a couple of weeks for the money to be available in their accounts,
|
|
and issuers often suffered from float on the billables of about 45
|
|
days.
|
|
|
|
Therefore, nowadays many issuers and acquirers are moving to on-line
|
|
settlement of transactions. This is often called "draft capture" in
|
|
the industry. There are two ways this is done - one based on the host
|
|
and one based on the terminal at the merchant's premises. In the
|
|
host-based case, the terminal generally only keeps counts and totals,
|
|
while the acquirer host keeps all the transaction details. Peri-
|
|
odically, the acquirer host and the terminal communicate, and verify
|
|
that they both agree on the data. In the terminal-based case, the ter-
|
|
minal remembers all the important transaction information, and peri-
|
|
odically calls the acquirer host and replays it all for several
|
|
transactions. In either case, once the settlement is complete the mer-
|
|
chant account is credited. The acquirer then sends the settlement in-
|
|
formation electronically to the issuers, and is credited by wire
|
|
immediately (or nearly so). The issuer can bill directly to the
|
|
cardholder account, and float can be reduced to an average of 15 days.
|
|
|
|
The problem is, what to do with the paper? Current regulations in many
|
|
states require that it be saved, but there is no need for it to be sent
|
|
to the issuer. Also, for contested charges, a paper trail is much more
|
|
likely to stand up in court, and much better to use for fraud investi-
|
|
gations. Currently, the paper usually ends up back at the issuer, as
|
|
before, but it doesn't need to be processed, just microfilmed and
|
|
stored.
|
|
|
|
Much of the market still uses paper settlement methods. Online settle-
|
|
ment will replace virtually all of this within the next 5 to 10 years,
|
|
because of its many benefits.
|
|
|
|
This was pretty long, but there is a lot of information, and I skimmed
|
|
over a lot of details. Future installments should be shorter. Coming
|
|
up next is a discussion of fraud and security, and then a special dis-
|
|
cussion of debit cards. Hang on, we're halfway through this!
|
|
|
|
|
|
Joe Ziegler
|
|
att!lznv!ziegler
|