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