     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
