Access Networks
For most credit card applications, the cost of the access network is the single biggest factor in overall costs, often accounting for over half of the total. For that reason, there are many different solutions, depending on the provider, the application, and geographical constraints.
The simplest form of access network uses 800 service, in one of its many forms. Terminals at merchant locations across the country dial an 800 number that is terminated on a large hunt group of modems, con- nected directly to the acquirer's front-end processor (FEP). The FEP is typically a fault-tolerant machine, since an outage here will take out the entire service. A large acquirer will typically have two or more centers for terminating the 800 service. This allows better economy, due to the nature of 800 service tariffs, and allows for di- saster recovery in case of a failure of one data center. An advantage of 800 service is that it is quite easy to cover the entire country with it. It also provides the most effective utilization of your FEP resources. (A little queuing theory will show you why.) However, 800 service is quite expensive. It always requires 10 (or 11) digits di- aled, and in areas with pulse dialing it can take almost three seconds just to dial 1-800. The delay between dialing and connection is longer for 800 calls than many other calls, because of the way the calls get routed. All of this adds to the perceived response time at the mer- chant location, even though the acquirer has no control over it.
Large acquirers prefer to offer some form of local access service. In this service, terminals at the merchants dial a local telephone number to gain access to the acquirer. Typically, the local number actually connects to a packet network, which then connects to the acquirer. If the packet network is a public network, the terminal must go through a login sequence to get connected across the packet network. Typically, local calls are much less expensive than 800 service calls, and local calls typically connect faster than 800 calls. The cost of those calls are absorbed by the merchants directly. In those few remaining areas where local calls are still free from a business line, this works out well for the merchant. Otherwise, the merchant can end up spending a lot of money on phone calls. Usually, the acquirer has to offer lower prices to accepters who use local calls, to help offset this. Even so, these networks are generally much less expensive for the acquirers. Such networks are difficult to maintain, due to the distributed nature of the access network. Since most packet networks are much more likely to experience failures than the phone network is, the merchant's POS terminal is usually programmed to dial an 800 number for fallback if the local number doesn't work. Also, it is generally not cost effective to cover every free calling area in the entire country with access equipment, so some 800 service is required anyway. There is also an administrative headache associated with keeping track of the different phone numbers that each merchant across the country needs to dial. When you have tens of thousands of terminals to support, this can be formidable.
Acquirers are beginning to experiment with Feature Group B (FGB) ac- cess. FGB access was the method of access used to get to alternative long-distance carriers before "equal access" was available. The tariffs are still on the books, and they are favorable for this appli- cation. FGB access provides a single number, nationwide, for all mer- chants to dial in order to gain access to the acquirer. The call has simpler (hence, presumably, faster) routing than 800 service, and the call is charged to the acquirer, not the accepter. FGB access does have to terminate on equipment that is physically located in the Local Access Toll Area (LATA) where the call originated, so there is the problem of having distributed equipment, as above. This also implies that it is not cost-effective to deploy FGB access everywhere, as well. There are also some technical oddities of FGB, due to its original in- tent, that have made it difficult to implement so far.
The other big switched access capability that is likely to have an im- pact in the future is ISDN. So far, this has been inhibited by limited availability and lack of adequate equipment on the merchant end, but it could be very beneficial when these problems are solved.
Private-line networks are pretty straightforward applications of point-to-point and multipoint private lines. Since private lines are quite expensive, engineering of the networks is challenging. Usually, sophisticated software is used to determine the optimum placement of concentrators in order to minimize costs. Since tariffs, real estate prices, and business needs change frequently, maintaining a stable, cost-effective network is hard work. A typical asynchronous private line network will have multiplexers at remote sites, with backbone links to companion multiplexers at a central site. Synchronous private line networks may use multiplexers, or remote controllers, or remote FEPs, depending on the application and the availability of real estate.
Thursday, December 23, 2004
Tuesday, December 21, 2004
SETTLEMENT - An overview
SETTLEMENT
Between Acquirer and Issuer, money has changed ,Thats 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.
Between Acquirer and Issuer, money has changed ,Thats 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.
What do you mean by Acquirer and Issuer?
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 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 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.
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 prevention. 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 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.
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 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 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.
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 prevention. 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 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.
Organizations and Standards
THE ORGANIZATIONS
ISO sets standards for plastic cards and for data interchange, among other things. ISO standards generally allow for national expansion. Typically, a national standards organization, like ANSI, will take an ISO standard and develop a national standard from it. National standards are generally subsets of the ISO standard, with extensions as allowed in the original ISO standard. Many credit card standards originated in the United States, and were generalized and adopted by ISO later. The ANSI committees that deal with credit card standards are sponsored by the ABA. Most members of these committees work for banks and other financial institutions, or for vendors who supply banks and financial institutions. Working committees report to governing committees. All standards go through a formal comment and review procedure before they are officially adopted.
PHYSICAL STANDARDS
ANSI X4.13, "American National Standard for Financial Services - Financial Transaction Cards" defines the size, shape, and other physical characteristics of credit cards. Most of it is of interest only to mechanical engineers. It defines the location and size of the magnetic stripe, signature panel, and embossing area. This standard also includes the Luhn formula used to generate the check digit for the PAN, and gives the first cut at identifying card type from the account number. (This part was expanded later in other standards.) Also, this standard identifies the character sets that can be used for embossing a card. Three character sets are allowed - OCR-A as defined in ANSI X3.17, OCR-B as defined in ANSI X3.49, and Farrington 7B, which is defined in the appendix of ANSI X4.13 itself. Almost all the cards I have use Farrington 7B, but Sears uses OCR-A. (Sears also uses the optional, smaller card size as, allowed in the standard.) These character sets are intended to be used with optical character readers (hence the OCR), and large issuers have some pretty impressive equipment to read those slips.
ENCODING STANDARDS
ANSI X4.16, "American National Standard for Financial Services - Financial Transaction Cards - Magnetic Stripe Encoding" defines the physical, chemical, and magnetic characteristics of the magnetic stripe on the card. The standard defines a minimum and maximum size for the stripe, and the location of the three defined encoding tracks. (Some cards have a fourth, proprietary track.)
Track 1 is encoded at 210 bits per inch, and uses a 6-bit coding of a 64-element character set of numeric, alphabet (one case only), and some special characters. Track 1 can hold up to 79 characters, six of which are reserved control characters. Included in these six characters is a Longitudinal Redundancy Check (LRC) character, so that a card reader can detect most read failures. Data encoded on track 1 include PAN, country code, full name, expiration date, and "discretionary data". Discretionary data is anything the issuer wants it to be. Track 1 was originally intended for use by airlines, but many Automatic Teller Machines (ATMs) are now using it to personalize prompts with your name and your language of choice. Some credit authorization applications are starting to use track 1 as well.
Track 2 is encoded at 75 bits per inch, and uses a 4-bit coding of the ten digits. Three of the remaining characters are reserved as delimiters, two are reserved for device control, and one is left undefined. In practice, the device control characters are never used, either. Track 2 can hold up to 40 characters, including an LRC. Data encoded on track 2 include PAN, country code (optional), expiration date, and discretionary data. In practice, the country code is hardly ever used by United States issuers. Later revisions of this standard added a qualification code that defines the type of the card (debit, credit, etc.) and limitations on its use. AMEX includes an issue date in the discretionary data. Track 2 was originally intended for credit authorization applications. Nowadays, most ATMs use track 2 as well. Thus, many ATM cards have a "PIN offset" encoded in the discretionary data. The PIN offset is usually derived by running the PIN through an encryption algorithm (maybe DES, maybe proprietary) with a secret key. This allows ATMs to verify your PIN when the host is offline, generally allowing restricted account access.
Track 3 uses the same density and coding scheme as track 1. The contents of track 3 are defined in ANSI X9.1, "American National Standard - Magnetic Stripe Data Content for Track 3". There is a slight contradiction in this standard, in that it allows up to 107 characters to be encoded on track 3, while X4.16 only gives enough physical room for 105 characters. Actually, there is over a quarter of an inch on each end of the card unused, so there really is room for the data. In practice, nobody ever uses that many characters, anyway. The original intent was for track 3 to be a read/write track (tracks 1 and 2 are intended to be read-only) for use by ATMs. It contains information needed to maintain account balances on the card itself. As far as I know, nobody is actually using track 3 for this purpose anymore, because it is very easy to defraud.
COMMUNICATION STANDARDS
Formats for interchange of messages between hosts (acquirer to issuer) is defined by ANSI X9.2, which I helped define. Financial message authentication is described by ANSI X9.9. PIN management and security is described by ANSI X9.8. There is a committee working on formats of messages from accepter to acquirer. ISO has re-convened the international committee on host message interchange (TC68/SC5/WG1), and ANSI may need to re-convene the X9.2 committee after the ISO committee finishes. These standards are still evolving, and are less specific than the older standards mentioned above. This makes them somewhat less useful, but is a natural result of the dramatic progress in the industry.
ISO maintains a registry of card numbers and the issuers to which they are assigned. Given a card that follows standards (Not all of them do.) and the register, you can tell who issued the card based on the first six digits (in most cases). This identifies not just VISA, MasterCard, etc., but also which member bank actually issued the card.
DE FACTO INDUSTRY STANDARDS
Most ATMs use IBM synchronous protocols, and many networks are migrating toward SNA. There are exceptions, of course. Message formats used for ATMs vary with the manufacturer, but a message set originally defined by Diebold is fairly widely accepted.
Many large department stores and supermarkets (those that take cards) run their credit authorization through their cash register controllers, which communicate using synchronous IBM protocols.
Standalone Point-of-Sale (POS) devices, such as you would find at most smaller stores (i.e. not at department stores), restaurants and hotels use a dial-up asynchronous protocol devised by VISA. There are two generations of this protocol, with the second generation just beginning to get widespread acceptance.
Many petroleum applications use multipoint private lines and a polled asynchronous protocol known as TINET. This protocol was developed by Texas Instruments for a terminal of the same name, the Texas Instruments Numerical Entry Terminal. The private lines reduce response time, but cost a lot more money than dial-up.
NACHA establishes standards for message interchange between ACHs, and between ACHs and banks, for clearing checks. This is important to this discussion due to the emergence of third-party debit cards, as discussed in part 1 of this series. The issuers of third-party debit cards are connecting to ACHs, using the standard messages, and clearing POS purchases as though they were checks. This puts the third parties at an advantage over the banks, because they can achieve the same results as a bank debit card without the federal and state legal restrictions imposed on banks.
ISO sets standards for plastic cards and for data interchange, among other things. ISO standards generally allow for national expansion. Typically, a national standards organization, like ANSI, will take an ISO standard and develop a national standard from it. National standards are generally subsets of the ISO standard, with extensions as allowed in the original ISO standard. Many credit card standards originated in the United States, and were generalized and adopted by ISO later. The ANSI committees that deal with credit card standards are sponsored by the ABA. Most members of these committees work for banks and other financial institutions, or for vendors who supply banks and financial institutions. Working committees report to governing committees. All standards go through a formal comment and review procedure before they are officially adopted.
PHYSICAL STANDARDS
ANSI X4.13, "American National Standard for Financial Services - Financial Transaction Cards" defines the size, shape, and other physical characteristics of credit cards. Most of it is of interest only to mechanical engineers. It defines the location and size of the magnetic stripe, signature panel, and embossing area. This standard also includes the Luhn formula used to generate the check digit for the PAN, and gives the first cut at identifying card type from the account number. (This part was expanded later in other standards.) Also, this standard identifies the character sets that can be used for embossing a card. Three character sets are allowed - OCR-A as defined in ANSI X3.17, OCR-B as defined in ANSI X3.49, and Farrington 7B, which is defined in the appendix of ANSI X4.13 itself. Almost all the cards I have use Farrington 7B, but Sears uses OCR-A. (Sears also uses the optional, smaller card size as, allowed in the standard.) These character sets are intended to be used with optical character readers (hence the OCR), and large issuers have some pretty impressive equipment to read those slips.
ENCODING STANDARDS
ANSI X4.16, "American National Standard for Financial Services - Financial Transaction Cards - Magnetic Stripe Encoding" defines the physical, chemical, and magnetic characteristics of the magnetic stripe on the card. The standard defines a minimum and maximum size for the stripe, and the location of the three defined encoding tracks. (Some cards have a fourth, proprietary track.)
Track 1 is encoded at 210 bits per inch, and uses a 6-bit coding of a 64-element character set of numeric, alphabet (one case only), and some special characters. Track 1 can hold up to 79 characters, six of which are reserved control characters. Included in these six characters is a Longitudinal Redundancy Check (LRC) character, so that a card reader can detect most read failures. Data encoded on track 1 include PAN, country code, full name, expiration date, and "discretionary data". Discretionary data is anything the issuer wants it to be. Track 1 was originally intended for use by airlines, but many Automatic Teller Machines (ATMs) are now using it to personalize prompts with your name and your language of choice. Some credit authorization applications are starting to use track 1 as well.
Track 2 is encoded at 75 bits per inch, and uses a 4-bit coding of the ten digits. Three of the remaining characters are reserved as delimiters, two are reserved for device control, and one is left undefined. In practice, the device control characters are never used, either. Track 2 can hold up to 40 characters, including an LRC. Data encoded on track 2 include PAN, country code (optional), expiration date, and discretionary data. In practice, the country code is hardly ever used by United States issuers. Later revisions of this standard added a qualification code that defines the type of the card (debit, credit, etc.) and limitations on its use. AMEX includes an issue date in the discretionary data. Track 2 was originally intended for credit authorization applications. Nowadays, most ATMs use track 2 as well. Thus, many ATM cards have a "PIN offset" encoded in the discretionary data. The PIN offset is usually derived by running the PIN through an encryption algorithm (maybe DES, maybe proprietary) with a secret key. This allows ATMs to verify your PIN when the host is offline, generally allowing restricted account access.
Track 3 uses the same density and coding scheme as track 1. The contents of track 3 are defined in ANSI X9.1, "American National Standard - Magnetic Stripe Data Content for Track 3". There is a slight contradiction in this standard, in that it allows up to 107 characters to be encoded on track 3, while X4.16 only gives enough physical room for 105 characters. Actually, there is over a quarter of an inch on each end of the card unused, so there really is room for the data. In practice, nobody ever uses that many characters, anyway. The original intent was for track 3 to be a read/write track (tracks 1 and 2 are intended to be read-only) for use by ATMs. It contains information needed to maintain account balances on the card itself. As far as I know, nobody is actually using track 3 for this purpose anymore, because it is very easy to defraud.
COMMUNICATION STANDARDS
Formats for interchange of messages between hosts (acquirer to issuer) is defined by ANSI X9.2, which I helped define. Financial message authentication is described by ANSI X9.9. PIN management and security is described by ANSI X9.8. There is a committee working on formats of messages from accepter to acquirer. ISO has re-convened the international committee on host message interchange (TC68/SC5/WG1), and ANSI may need to re-convene the X9.2 committee after the ISO committee finishes. These standards are still evolving, and are less specific than the older standards mentioned above. This makes them somewhat less useful, but is a natural result of the dramatic progress in the industry.
ISO maintains a registry of card numbers and the issuers to which they are assigned. Given a card that follows standards (Not all of them do.) and the register, you can tell who issued the card based on the first six digits (in most cases). This identifies not just VISA, MasterCard, etc., but also which member bank actually issued the card.
DE FACTO INDUSTRY STANDARDS
Most ATMs use IBM synchronous protocols, and many networks are migrating toward SNA. There are exceptions, of course. Message formats used for ATMs vary with the manufacturer, but a message set originally defined by Diebold is fairly widely accepted.
Many large department stores and supermarkets (those that take cards) run their credit authorization through their cash register controllers, which communicate using synchronous IBM protocols.
Standalone Point-of-Sale (POS) devices, such as you would find at most smaller stores (i.e. not at department stores), restaurants and hotels use a dial-up asynchronous protocol devised by VISA. There are two generations of this protocol, with the second generation just beginning to get widespread acceptance.
Many petroleum applications use multipoint private lines and a polled asynchronous protocol known as TINET. This protocol was developed by Texas Instruments for a terminal of the same name, the Texas Instruments Numerical Entry Terminal. The private lines reduce response time, but cost a lot more money than dial-up.
NACHA establishes standards for message interchange between ACHs, and between ACHs and banks, for clearing checks. This is important to this discussion due to the emergence of third-party debit cards, as discussed in part 1 of this series. The issuers of third-party debit cards are connecting to ACHs, using the standard messages, and clearing POS purchases as though they were checks. This puts the third parties at an advantage over the banks, because they can achieve the same results as a bank debit card without the federal and state legal restrictions imposed on banks.
Players and their Roles in Electronic Payments
PLAYERS AND THEIR ROLES
American Express (AMEX) is a charge card issuer and acquirer. (Their other businesses are not important to this discussion.) All AMEX purchases are authorized by AMEX. They make most of their money from the discount fees, which is why they have the highest discount fee in the industry. That's one reason why AMEX isn't accepted in as many places as VISA and MC, and a reason why many merchants will prefer another card to an AMEX card. The control AMEX has over authorization allows them to provide what they consider to be better cardholder ("card member" to them) services.
VISA is a non-profit corporation that is best described as a purchasing and marketing coalition of its member banks. VISA issues no credit cards itself - all VISA cards are issued by member banks. VISA does not set terms and conditions for its member banks - the banks can do pretty much as they please in signing cardholders. All VISA charges are ultimately approved by the card issuer, regardless of where the purchase was made.
Many smaller banks share their account databases with larger banks, third parties, or VISA itself, so that the bank doesn't have to provide authorization facilities itself. Master Card (MC) is very much like VISA.
There are some differences that are important to those in the industry, but from the consumers standpoint they operate pretty much the same.
Discover cards are issued by a bank owned by Sears. All Discover purchases are authorized by Sears.
Most petroleum cards, if they are even authorized, are authorized by the petroleum company itself. There are exceptions. Fraud on petroleum cards is so low that the main reason for authorization is to achieve the float reduction of electronic settlement.
American Express (AMEX) is a charge card issuer and acquirer. (Their other businesses are not important to this discussion.) All AMEX purchases are authorized by AMEX. They make most of their money from the discount fees, which is why they have the highest discount fee in the industry. That's one reason why AMEX isn't accepted in as many places as VISA and MC, and a reason why many merchants will prefer another card to an AMEX card. The control AMEX has over authorization allows them to provide what they consider to be better cardholder ("card member" to them) services.
VISA is a non-profit corporation that is best described as a purchasing and marketing coalition of its member banks. VISA issues no credit cards itself - all VISA cards are issued by member banks. VISA does not set terms and conditions for its member banks - the banks can do pretty much as they please in signing cardholders. All VISA charges are ultimately approved by the card issuer, regardless of where the purchase was made.
Many smaller banks share their account databases with larger banks, third parties, or VISA itself, so that the bank doesn't have to provide authorization facilities itself. Master Card (MC) is very much like VISA.
There are some differences that are important to those in the industry, but from the consumers standpoint they operate pretty much the same.
Discover cards are issued by a bank owned by Sears. All Discover purchases are authorized by Sears.
Most petroleum cards, if they are even authorized, are authorized by the petroleum company itself. There are exceptions. Fraud on petroleum cards is so low that the main reason for authorization is to achieve the float reduction of electronic settlement.
Monday, December 20, 2004
Contact Less CHIP Transactions:-
Contact Less CHIP Transactions:-
---------------------------------------------------
New payment methods are being developed and introduced in the payment industry.
One of these new methods is the use of contactless chips that are embedded within a Visa card.
The contactless chip transmits Track 2 data wirelessly without direct physical contact between the card and the terminal.
Visa will implement changes to add new values to identify contactless chip transactions.
Visa U.S.A. will support the issuance of cards with contactless chips and the processing of transactions originated from a contactless chip.
Any Visa credit or Visa debit card may be issued with a contactless chip in accordance with the standards published by Visa.
These Visa contactless chip cards consist of one of the following:
1), a magnetic stripe Visa card with an embedded contactless chip
2) a Visa Smart Debit Credit (VSDC) chip card that has a magnetic stripe and supports a contactless chip.
The contactless chip employs radio frequency identification (RFID) technology that enables the chip to communicate with a point-of-sale (POS)
device that is enabled with a RFID receiver.
All contactless terminals must support RFID technology at the point-of-sale in accordance with the technical specifications ISO 14443 A and B and the Visa
Financial Messaging Specification for Contactless Payment.
The contactless chip employs radio frequency identification (RFID) technology that enables the chip to communicate with a point-of-
sale (POS) device that is enabled with a RFID receiver. A Visa contactless chip card and RFID-enabled terminal
communicate wirelessly so that the magnetic stripe information is sent from the chip to the terminal.
---------------------------------------------------
New payment methods are being developed and introduced in the payment industry.
One of these new methods is the use of contactless chips that are embedded within a Visa card.
The contactless chip transmits Track 2 data wirelessly without direct physical contact between the card and the terminal.
Visa will implement changes to add new values to identify contactless chip transactions.
Visa U.S.A. will support the issuance of cards with contactless chips and the processing of transactions originated from a contactless chip.
Any Visa credit or Visa debit card may be issued with a contactless chip in accordance with the standards published by Visa.
These Visa contactless chip cards consist of one of the following:
1), a magnetic stripe Visa card with an embedded contactless chip
2) a Visa Smart Debit Credit (VSDC) chip card that has a magnetic stripe and supports a contactless chip.
The contactless chip employs radio frequency identification (RFID) technology that enables the chip to communicate with a point-of-sale (POS)
device that is enabled with a RFID receiver.
All contactless terminals must support RFID technology at the point-of-sale in accordance with the technical specifications ISO 14443 A and B and the Visa
Financial Messaging Specification for Contactless Payment.
The contactless chip employs radio frequency identification (RFID) technology that enables the chip to communicate with a point-of-
sale (POS) device that is enabled with a RFID receiver. A Visa contactless chip card and RFID-enabled terminal
communicate wirelessly so that the magnetic stripe information is sent from the chip to the terminal.
Subscribe to:
Posts (Atom)