credit card industry 3
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 transactions, 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 terminal, 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 directly connected, host-to-host, to issuers and/or acquirers, and authorize 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), expiration date, and purchase amount are required. Typically, the "discretionary data" from track 2 is sent as well, but this is not strictly necessary. In applications that do not transmit the PIN with the authorization, it is the responsibility of the merchant to verify identity. 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 petroleum 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 actual 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 financial liability from the acquirer to the issuer.
Typically, an acquirer connects to many issuers, and negotiates different business arrangements with each one of them. But the acquirer generally 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 responsibilities 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 complicated.
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 beyond 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 approved 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 outstanding 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 approved 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 authorizations 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 prevention. I expect this to be the biggest effort in authorization software 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 determine 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 purpose 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 consequences. 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 account. The acquirer would take the slips, sort them by issuer, and send them to the issuing banks, receiving credits by wire once they arrived and were processed. The issuer would receive the slips, microfilm 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. Periodically, the acquirer host and the terminal communicate, and verify that they both agree on the data. In the terminal-based case, the terminal remembers all the important transaction information, and periodically calls the acquirer host and replays it all for several transactions. In either case, once the settlement is complete the merchant account is credited. The acquirer then sends the settlement information 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 investigations. 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 settlement 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 discussion of debit cards. Hang on, we're halfway through this!
Joe Ziegler
att!lznv!ziegler
