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.
Monday, November 29, 2004
Radio Frequency Identification (RFID)
Features of Radio Frequency Identification
TURNING FULL CIRCLE
The term Radio Frequency Identification (RFID), which describes a type of automatic identification system, was first heard of in the 1980s, when it was used to track applications. The genesis of the technology, however, can be traced to World War II, when it was developed by allied forces for radar operators, to enable them to distinguish between friendly and enemy aircraft!
What started out as a technology with predominantly defense uses, RFID has expanded the ambit of its coverage to include a range of applications such as transportation and logistics, manufacturing and processing, security, animal tagging, waste management, time and attendance, postal tracking, airline baggage reconciliation and road toll management. RFID, which offers users more granular, accurate information and provides a means to automate processes that are manual, has proved itself as a technology that results in dramatic supply-chain improvements.
MARKET FORECASTS
The market forecasts for RFID vary. However, here’s what key analysts are predicting about the market:
Frost & Sullivan’s latest report on the World RFID-Based Applications Market reveals that the industry generated revenues totaling US$1.7 billion in 2003. The turnover of this industry is expected to grow to US$ 11.7 billion by 2010.
Datamonitor has forecast a US$ 5-20 billion European market for intelligent tags and their equipment in year 2005, including the UK.
Frost and Sullivan sees a $10 billion global market for RFID and EAS systems in 2005
based RFID systems, including tags, touched around US$ 1.4 billion in 2002. The market for the tags including smart labels was estimated to be around about US$ 0.7 billion.
Global research conducted by IDTechEx, predicts that by 2013 the RFID market will be worth US$ 10 billion, with 50 percent of the revenues being accounted for by hardware (tags and readers) and the rest by software, services and infrastructure
The leaders in smart labels are each shipping 60 to 120 million chip tags a year, i.e., valued at around US$ 100 million each for the tags alone. Philips, as the largest supplier of RFID chips (one per tag) says global consumption for smart labels is expected to be approximately 1.9 billion units in 2004. In the segment of systems and tags, TransCore has sales of US$ 350 million and Savi Technology has US$ 65 million. All the leading analysts see double-digit growth (typically in the region of 25 percent yearly) of RFID markets by value over the next few years. None of the above forecasts for RFID include RFID contact-less smart cards and tickets.
IT MAJORS: GEARING UP FOR RFID
A number of global and Indian IT software and services companies have started vying for a piece of the RFID pie. IT vendors such as Oracle and others are building supply-chain and warehouse management applications that can work with RFID data. Sun Microsystems, for instance, is building a middleware based on standard specifications for RFID and SAP has released middleware products for linking RFID readers to back-end applications and monitoring business-process expectations.
Closer to home, leading Indian IT software companies have taken significant initiatives on the RFID front. Newsline provides a peek into the RFID strategies of a few IT software and services companies:
COGNIZANT
The solution: Cognizant provides an end-to-end RFID solution, spanning applicability assessment, technical and ergonomic feasibility, scenario modeling, ROI analysis and pilot planning, solution architecture, application development and implementation.
RFID strategy: Currently, Cognizant is working on pilots and proof of concepts for some of its customers across verticals in the area of palette and case labeling. Plans are afoot to extend it to item labeling when the prices of RFID tags drop to realistic levels. As the standards for RFID are still evolving, Cognizant's Centers of Excellence are closely tracking trends in this space before large-scale deployment for customers. Cognizant has set up a dedicated RFID Competency Center and Lab in Kolkatawhich houses its Retail Center of Excellence, for developing and testing RFID solutions.
Cognizant has also built an RFID simulator for software based testing of the RFID architecture. The Lab is currently focused on developing a scalable middleware environment to handle enormous amount of data generated by RFID readers and to bridge the gap between the middleware and the backend systems
INFOSYS
The solution: Infosys offers a comprehensive solution for RFID adoption which includes a range of services from concept-to-implementation. The solution enables clients to evaluate the technology in their business context, build a business case, and develop a roadmap for phased adoption. Infosys' RFID solution stack includes pre-built tools, templates, frameworks and reference models that enable customers to unravel the disruptive potential of this technology. Edge Server Lite, the company's ready-to-deploy software stack for RFID event management and integration helps customers to rapidly embark on their RFID initiatives enabling faster time-to-market at a lower total cost of ownership.
Chitale Digitals
In the RFID segment, the company manufactures "Mifare RF Cards" and "Hitag RF Cards". The Mifare Card system is used for "Attendance and Data Management" applications. The Mifare smart card is a contact less or dual interface RF card. Built on the Mifare architecture the product is centered around ISO/IEC 1443, type A standards. Mifare cards and readers are developed by and manufactured by Philips Semiconductor.
The Hitag RF Cards, consisting of read/write devices, data carriers and Antenna readers represents a new generation of secure passive RFID system. HITAG is the first passive RFID system with anti collision capabilities. This allows several data carriers to operate simultaneously within the communication field of Antenna.
So far, the company has completed installations at the Bhabha Atomic Research Center, IRCON and Philips, among other sites.
Patni Computer Systems
PCS set up an RFID lab eight months ago. Supply-chain and RFID consultants man the lab and it has already delivered an RFID pilot based on Auto-ID’s RFID framework that integrates into a SAP back-end for processing transactions.
Wipro Technologies
To understand the issues surrounding RFID deployments in a retail setting, Wipro Technology has started testing RFID in a retail store. The company operates on the campus of its headquarters in Bangalore, India.
In early July, Wipro finished building an RFID system in the 1,000-square-foot campus store. According to Wipro, designing, developing and deploying its own RFID pilot provided the company with a great deal of first-hand experience regarding the kinds of issues its retail customers will face with their own deployments. Besides highlighting the requirements of middleware and software integration, the project also taught the company about the significance of a site survey, the need to design and deploy RFID hardware within the context of the business for which it is deployed, the importance of antenna orientation for smart shelves, the impact of an RFID system on existing business processes and applications and the amount of work required to develop new systems to work with RFID.
Indian IT companies, therefore, need to take a closer look at RFID and enter a market that is expected to rapidly expand over the next few years. As the cost of RFID implementation comes down, standards emerge and users develop stringent safeguards on how RFID systems are deployed (taking care of privacy issues), the market will offer significant opportunities for Indian IT software and services companies. Against this backdrop, Indian Tier 1 and Tier 2 vendors need to develop expertise in providing customized solutions for RFID and perhaps set up separate practices focused on the technology
TURNING FULL CIRCLE
The term Radio Frequency Identification (RFID), which describes a type of automatic identification system, was first heard of in the 1980s, when it was used to track applications. The genesis of the technology, however, can be traced to World War II, when it was developed by allied forces for radar operators, to enable them to distinguish between friendly and enemy aircraft!
What started out as a technology with predominantly defense uses, RFID has expanded the ambit of its coverage to include a range of applications such as transportation and logistics, manufacturing and processing, security, animal tagging, waste management, time and attendance, postal tracking, airline baggage reconciliation and road toll management. RFID, which offers users more granular, accurate information and provides a means to automate processes that are manual, has proved itself as a technology that results in dramatic supply-chain improvements.
MARKET FORECASTS
The market forecasts for RFID vary. However, here’s what key analysts are predicting about the market:
Frost & Sullivan’s latest report on the World RFID-Based Applications Market reveals that the industry generated revenues totaling US$1.7 billion in 2003. The turnover of this industry is expected to grow to US$ 11.7 billion by 2010.
Datamonitor has forecast a US$ 5-20 billion European market for intelligent tags and their equipment in year 2005, including the UK.
Frost and Sullivan sees a $10 billion global market for RFID and EAS systems in 2005
based RFID systems, including tags, touched around US$ 1.4 billion in 2002. The market for the tags including smart labels was estimated to be around about US$ 0.7 billion.
Global research conducted by IDTechEx, predicts that by 2013 the RFID market will be worth US$ 10 billion, with 50 percent of the revenues being accounted for by hardware (tags and readers) and the rest by software, services and infrastructure
The leaders in smart labels are each shipping 60 to 120 million chip tags a year, i.e., valued at around US$ 100 million each for the tags alone. Philips, as the largest supplier of RFID chips (one per tag) says global consumption for smart labels is expected to be approximately 1.9 billion units in 2004. In the segment of systems and tags, TransCore has sales of US$ 350 million and Savi Technology has US$ 65 million. All the leading analysts see double-digit growth (typically in the region of 25 percent yearly) of RFID markets by value over the next few years. None of the above forecasts for RFID include RFID contact-less smart cards and tickets.
IT MAJORS: GEARING UP FOR RFID
A number of global and Indian IT software and services companies have started vying for a piece of the RFID pie. IT vendors such as Oracle and others are building supply-chain and warehouse management applications that can work with RFID data. Sun Microsystems, for instance, is building a middleware based on standard specifications for RFID and SAP has released middleware products for linking RFID readers to back-end applications and monitoring business-process expectations.
Closer to home, leading Indian IT software companies have taken significant initiatives on the RFID front. Newsline provides a peek into the RFID strategies of a few IT software and services companies:
COGNIZANT
The solution: Cognizant provides an end-to-end RFID solution, spanning applicability assessment, technical and ergonomic feasibility, scenario modeling, ROI analysis and pilot planning, solution architecture, application development and implementation.
RFID strategy: Currently, Cognizant is working on pilots and proof of concepts for some of its customers across verticals in the area of palette and case labeling. Plans are afoot to extend it to item labeling when the prices of RFID tags drop to realistic levels. As the standards for RFID are still evolving, Cognizant's Centers of Excellence are closely tracking trends in this space before large-scale deployment for customers. Cognizant has set up a dedicated RFID Competency Center and Lab in Kolkatawhich houses its Retail Center of Excellence, for developing and testing RFID solutions.
Cognizant has also built an RFID simulator for software based testing of the RFID architecture. The Lab is currently focused on developing a scalable middleware environment to handle enormous amount of data generated by RFID readers and to bridge the gap between the middleware and the backend systems
INFOSYS
The solution: Infosys offers a comprehensive solution for RFID adoption which includes a range of services from concept-to-implementation. The solution enables clients to evaluate the technology in their business context, build a business case, and develop a roadmap for phased adoption. Infosys' RFID solution stack includes pre-built tools, templates, frameworks and reference models that enable customers to unravel the disruptive potential of this technology. Edge Server Lite, the company's ready-to-deploy software stack for RFID event management and integration helps customers to rapidly embark on their RFID initiatives enabling faster time-to-market at a lower total cost of ownership.
Chitale Digitals
In the RFID segment, the company manufactures "Mifare RF Cards" and "Hitag RF Cards". The Mifare Card system is used for "Attendance and Data Management" applications. The Mifare smart card is a contact less or dual interface RF card. Built on the Mifare architecture the product is centered around ISO/IEC 1443, type A standards. Mifare cards and readers are developed by and manufactured by Philips Semiconductor.
The Hitag RF Cards, consisting of read/write devices, data carriers and Antenna readers represents a new generation of secure passive RFID system. HITAG is the first passive RFID system with anti collision capabilities. This allows several data carriers to operate simultaneously within the communication field of Antenna.
So far, the company has completed installations at the Bhabha Atomic Research Center, IRCON and Philips, among other sites.
Patni Computer Systems
PCS set up an RFID lab eight months ago. Supply-chain and RFID consultants man the lab and it has already delivered an RFID pilot based on Auto-ID’s RFID framework that integrates into a SAP back-end for processing transactions.
Wipro Technologies
To understand the issues surrounding RFID deployments in a retail setting, Wipro Technology has started testing RFID in a retail store. The company operates on the campus of its headquarters in Bangalore, India.
In early July, Wipro finished building an RFID system in the 1,000-square-foot campus store. According to Wipro, designing, developing and deploying its own RFID pilot provided the company with a great deal of first-hand experience regarding the kinds of issues its retail customers will face with their own deployments. Besides highlighting the requirements of middleware and software integration, the project also taught the company about the significance of a site survey, the need to design and deploy RFID hardware within the context of the business for which it is deployed, the importance of antenna orientation for smart shelves, the impact of an RFID system on existing business processes and applications and the amount of work required to develop new systems to work with RFID.
Indian IT companies, therefore, need to take a closer look at RFID and enter a market that is expected to rapidly expand over the next few years. As the cost of RFID implementation comes down, standards emerge and users develop stringent safeguards on how RFID systems are deployed (taking care of privacy issues), the market will offer significant opportunities for Indian IT software and services companies. Against this backdrop, Indian Tier 1 and Tier 2 vendors need to develop expertise in providing customized solutions for RFID and perhaps set up separate practices focused on the technology
ACH - An overview
ACH
The automated clearinghouse (ACH) is an electronic payments network that allows for the clearing and settlement of debit and credit transactions among financial
institutions. Only financial institutions may have direct links to the ACH, and, through
them, more than 3 million businesses and 100 million consumers originate and receive
ACH transactions.
The ACH was created in the mid-1970s as part of the government’s
efforts to begin dispersing electronically the burgeoning number of government payments
(such as Social Security). Since then the ACH has experienced continued growth. The
network is governed by the Operating Rules of the National Automated Clearinghouse
Association (NACHA – The Electronic Payments Association).
There are currently three ACH Operators –
the Federal Reserve,
Electronic Payments Network (EPN; formerly the New York Automated Clearinghouse, or
NYACH), and
Visa.
Though EPN and Visa are both nonbanks, they are bank-owned.
For transactions sent through the Federal Reserve, settlement may take place in the
Federal Reserve account of each financial institution, or in the Federal Reserve account
of designated correspondents. EPN and Visa both ultimately rely on the Federal Reserve
for settlement.
In 2001, nearly 8 billion transactions, with a corresponding dollar value of $14
trillion, were sent over the ACH network. Of those, traditional uses of the ACH, such as
for payroll direct deposit and automatic bill payment, accounted for over 6 billion
transactions.
The transaction begins with a party providing authorization to an originator. That originator passes entries along to the financial institution that will serve as the originating depository financial institution (ODFI). The ODFI, in turn, sends entries to the operator, which edits the entries and distributes them to the appropriate receiving depository financial institutions (RDFI), and effects settlement. The RDFI posts the item(s) to the receiver’s account.
As with other payments system applications, the ACH network allows for the
participation of third-party processors on behalf of financial institutions. There are four
situations in which third-party processors may be participants in the ACH. In the first
scenario, a financial institution allows a corporate customer to send files directly to the
ACH Operator.19 In the second, a financial institution allows a consumer bill payment
service to collect and then disburse funds by sending files directly to the ACH Operator,
using its account at the ODFI as a pass- through account.20 The third scenario is one in
which the ODFI uses a correspondent financial institution for processing and/or
settlement.21 Finally, in the fourth scenario, the ODFI uses a correspondent financial
institution for processing but not for settlement.
Though the bulk of ACH transactions are generated for traditional payments, the
ACH network is also being used for emerging payments. For example, in 1999 NACHA
implemented rules that allow for the conversion of paper checks to ACH items. Two
such conversion opportunities are paper checks written at the POS and paper checks
received at remittance lockboxes.
The automated clearinghouse (ACH) is an electronic payments network that allows for the clearing and settlement of debit and credit transactions among financial
institutions. Only financial institutions may have direct links to the ACH, and, through
them, more than 3 million businesses and 100 million consumers originate and receive
ACH transactions.
The ACH was created in the mid-1970s as part of the government’s
efforts to begin dispersing electronically the burgeoning number of government payments
(such as Social Security). Since then the ACH has experienced continued growth. The
network is governed by the Operating Rules of the National Automated Clearinghouse
Association (NACHA – The Electronic Payments Association).
There are currently three ACH Operators –
the Federal Reserve,
Electronic Payments Network (EPN; formerly the New York Automated Clearinghouse, or
NYACH), and
Visa.
Though EPN and Visa are both nonbanks, they are bank-owned.
For transactions sent through the Federal Reserve, settlement may take place in the
Federal Reserve account of each financial institution, or in the Federal Reserve account
of designated correspondents. EPN and Visa both ultimately rely on the Federal Reserve
for settlement.
In 2001, nearly 8 billion transactions, with a corresponding dollar value of $14
trillion, were sent over the ACH network. Of those, traditional uses of the ACH, such as
for payroll direct deposit and automatic bill payment, accounted for over 6 billion
transactions.
The transaction begins with a party providing authorization to an originator. That originator passes entries along to the financial institution that will serve as the originating depository financial institution (ODFI). The ODFI, in turn, sends entries to the operator, which edits the entries and distributes them to the appropriate receiving depository financial institutions (RDFI), and effects settlement. The RDFI posts the item(s) to the receiver’s account.
As with other payments system applications, the ACH network allows for the
participation of third-party processors on behalf of financial institutions. There are four
situations in which third-party processors may be participants in the ACH. In the first
scenario, a financial institution allows a corporate customer to send files directly to the
ACH Operator.19 In the second, a financial institution allows a consumer bill payment
service to collect and then disburse funds by sending files directly to the ACH Operator,
using its account at the ODFI as a pass- through account.20 The third scenario is one in
which the ODFI uses a correspondent financial institution for processing and/or
settlement.21 Finally, in the fourth scenario, the ODFI uses a correspondent financial
institution for processing but not for settlement.
Though the bulk of ACH transactions are generated for traditional payments, the
ACH network is also being used for emerging payments. For example, in 1999 NACHA
implemented rules that allow for the conversion of paper checks to ACH items. Two
such conversion opportunities are paper checks written at the POS and paper checks
received at remittance lockboxes.
Cryptography in Financial Network
cryptography in Magnetic stripe cards
The intention of this section is to demonstrate how cryptographic principles are (usually) applied to magnetic stripe cards in a practical context.
PIN Processing
The PIN principle is based on the fact that nobody other than the legitimate cardholder has knowledge of the PIN. Thus when a PIN is provided for a customer:
It must not be stored anywhere in cleartext (except in the secure PIN mailer destined for the customer)
It must not be possible to reverse-engineer the PIN from information on the magnetic stripe or from a centrally held database.
Normally, a PIN is a 4-digit numeric value. Other schemes exist, but we will use this format for illustration as it is a common standard. When a PIN is issued, the sequence of events is as follows:
A 4-digit random number is generated. This is the PIN.
The PIN is combined with other information, such as the account number, to create a block of data for input to the cryptography process.
The input block is triple encrypted using the PIN working keys
Digits are selected from the ciphertext result. These become the Pin Verification Value or Pin Offset.
The PIN Offset is stored
The PIN mailer is printed
Memory is cleared to binary zeroes to remove all traces of the clear PIN.
At this point, the only place the PIN value exists is inside the PIN mailer. The PIN cannot be derived from the PIN offset.
When the card is used and the PIN entered, the PIN offset is calculated again from the entered PIN, using the PIN working keys and compared to the stored offset value to determine if the correct PIN was entered. Clearly this means that when a PIN is validated, the validating system must have access to the PIN working keys used during initial PIN issue or subsequent PIN change.
It should be re-emphasised that the offset comprises selected digits from the ciphertext. Typically this would be 4-6 digits. It is not possible to recreate the keys or derive the PIN from this value.
Notes:
I.In some implementations, the PIN offset is stored on the magnetic stripe on the card. This is intended to be used in terminals which can perform local PIN validation. However, this technique is becoming rare as it prevents deployment of user-selectable PIN's.
II. Where the user is given the option to change PIN, the new offset is calculated in realtime and written to the database. Note that if the PIN is forgotten, it cannot be recreated.
III. The method described above is generic. There are many variations, such as the IBM3624 Method-A, Diebold method, and so on, however the principle remains the same.
IV. In many methods, the framework exists for using different key pairs based on an index value, usually stored on the magnetic stripe. This is a single digit value denoting the index of the key pair to be used. The intent is so that a) the same keys are not used across the entire cardbase, and c) that new keys can be used on re-issue without affecting existing cards.
CVV processing
It was quickly understood that the proliferation of financial cards exposed institutions to risk from counterfeiters. In the credit card world, this came from manufacture of cards with or without magnetic stripe encoding that possessed valid numbers and seemingly valid names and logos. In the ATM card arena, attackers observed PIN number entry 'over the shoulder', collated these PIN's with information from discarded receipts and so on, and constructed their own magnetic stripes on dummy cards for use at their leisure with observed PIN numbers.
These threats and others led to the introduction of the Card Verification Value, a non-derivable sequence of digits constructed by cryptographic process and written to the magnetic stripe of the card. This means that electronic capture of transactions (either at ATM or Point of Sale) are effectively protected against counterfeiters.
A combination of static data such as account number is triple encrypted using a special Card Verification key pair. Selected digits from the result are used to create the CVV, and this is written onto the magnetic stripe.
Similar comments apply to CVV as those for Pin Offset; As the CVV consists of few digits, and triple encryption is used, the CVV keys and values are highly secure and presence of a valid CVV provides an added level of confidence that the card is not counterfeit.
It should be noted that CVV is simply an additional protection method; it is not foolproof. It does not, for instance, protect against fraudulent captures of magnetic stripe data using, say, fake ATM's.
A further development of CVV, CVV2, is used for telephone authorisations. A similar (although not identical) calculation is performed as for CVV, and selected digits from the result are physically printed on the back of the card. These digits can then be requested by a call centre wishing to determine if the caller is really in possession of the card. Once again, this is an additional check, and not foolproof.
Key management
Key management relates to the storage, protection and transmission of keys. A single financial installation will have many DES keys, and these require careful management if they are not to become compromised or confused. One of the worst forms of debugging of computer faults is when cryptography is involved as traces and dumps are meaningless, and it can be very hard to discover that the wrong cryptography keys are being used!
Keys are normally managed in hierarchies. Keys that are actually used for computation, such as PIN validation [working keys] are themselves stored in enciphered format under a key encryption key. Other key sets will exist for transporting keys from one location to another, such as two nodes in a network. These are known as transport keys.
In good key management systems, working keys are never stored or exposed in clear format. Even when they are initially created, they are frequently created by automated process and never known to individuals.
When initial keys are created, the 64 bits are split between two or more individuals, who then toss a coin once for each bit required. The two or more individuals then key in their segment of the random key alone, and thus no one individual ever has sight of a whole key. This method is normally used for initial master key generation.
Although a simple concept, key management can become quite complex in implementation.
In a simple ATM network for instance, a terminal master key is used to encipher working keys in transit. A terminal master key (TMK) is generated for each terminal, split into two halves and printed (or sometimes encoded on a special magnetic card). Each TMK is then installed at their respective ATM's. The host system will then download terminal working keys, enciphered under the respective terminal master key, to each ATM. The terminal working key is then used to encipher PIN data in transit to the host during normal processing. If required, the terminal working key can be changed at regular intervals or through dynamic key exchange - but this process requires careful management.
It should be noted that the biggest single security exposure to DES based cryptographic subsystems is in the exchange of keys, thus good key management procedures are paramount.
Physical implementation
Cryptographic processing and key management is normally performed in specialised, dedicated secure hardware. Although DES can be implemented entirely in software (using products such as IBM's PCF), it is less secure, and the DES algorithm can be quite processor intensive.
There are companies that specialise in dedicated cryptographic units, such as Racal and Atalla. They are commonly called HSM's (Host Security Module) although this is the Racal proprietary name for the unit.
When using these devices, the intent is that all encipher and decipher activity takes place in the secure unit, and that clear keys and cleartext values are never exposed outside the unit.
Physically, HSM's are tamper proof and intended for installation in secure computer rooms. Attempts to open them will result in the destruction of keys contained in the devices.
HSM's are also capable of generating new random keys and random numbers for use as PIN's in a secure manner.
Some applications use physical telecommunications line encryption for added security, and there are a variety of manufacturers of this type of device. They are effectively 'black box' and require no special knowledge.
Examples
Cryptography in a normal ATM withdrawal
Consider a common ATM transaction:
A customer inserts his card in the ATM
The customer enters his PIN
The customer requests cash
The transaction is approved, cash is dispensed
There's an awful lot of cryptography going on in this process. For simplicity, we'll assume the acquiring and issuing bank are the same.
The cryptography activity is identified in italics in the sequence:
1. A customer inserts his card in the ATM
The magnetic stripe is read and stored in a buffer in the ATM
2. The customer enters his PIN
The PIN is entered into a tamper-proof PIN pad The stored PIN is stored in a security module in hardware
3. The customer requests cash
The message is constructed in the ATM The PIN (and possibly more) is enciphered under the Terminal key
The message is sent to the host, possibly enciphered in comms hardware.
On receipt at the host, the comms level encryption is deciphered The CVV is calculated and compared to the value on the magstripe The PIN under the Terminal key is deciphered The PIN offset or PVV is calculated The PIN offset or PVV is compared to the database of PVV's
4. The transaction is approved, cash is dispensed
Note: all the host cryptography functions are normally performed in the Host Security module. No Cleartext values are exposed to application programs or outside the secure environment.
Cryptography in an EFTPoS transaction
Even in a signature authorised environment, the CVV from the magnetic stripe can be validated at the host system to detect counterfeit cards. Clearly this only works in online environments as the CVV validation requires a cryptographic calculation to be performed at the host.
[Note: It is possible, and some manufacturers support, local key storage on EFTPoS devices and distributed terminals. Because of the key management complications, these devices are not considered here]
A more common use of cryptography in EFTPoS environments (and, increasingly in ATM and other traffic) is the MAC (Message Authentication Code). The MAC check can be thought of as a value calculated from the contents of all the critical fields in a message (such as card number and amount) and passed through a cryptographic algorithm. Although the message is carried over transmission lines in clear, the validation of the MAC field at the recipient will determine whether fields have been tampered with. [for the technically minded, MAC can be thought of as an encrypted LRC field]. The overhead of MAC is quite small. (The MAC is defined as 16 bytes in ISO8583).
Other financial cryptography applications
As well as traditional uses of cryptography as described above, interbank networks (such as SWIFT) have historically been large users of cryptographic techniques.
A plethora of new delivery mechanisms and far wider distribution of advanced technology to the public has increased both the interest in and the use of cryptographic techniques.
In cases where cryptography is required for widespread dissemination to the public (such as PC based home banking) ordinary DES is too complex to manage securely. More appropriate and more secure algorithms such as RSA (A "public key" encryption system) have evolved and been deployed in these environments - they are outside the scope of this paper but review of public key algorithms is especially encouraged where appropriate.
Some corporate, EDI and treasury applications use highly secure DES with a combination of techniques - MAC, physical encryption, dynamic key exchange, smart card key storage and so on. In one implementation reviewed, the working key is changed every transaction by the result of a MAC key calculation residue (a so-called "one time" key system).
The intention of this section is to demonstrate how cryptographic principles are (usually) applied to magnetic stripe cards in a practical context.
PIN Processing
The PIN principle is based on the fact that nobody other than the legitimate cardholder has knowledge of the PIN. Thus when a PIN is provided for a customer:
It must not be stored anywhere in cleartext (except in the secure PIN mailer destined for the customer)
It must not be possible to reverse-engineer the PIN from information on the magnetic stripe or from a centrally held database.
Normally, a PIN is a 4-digit numeric value. Other schemes exist, but we will use this format for illustration as it is a common standard. When a PIN is issued, the sequence of events is as follows:
A 4-digit random number is generated. This is the PIN.
The PIN is combined with other information, such as the account number, to create a block of data for input to the cryptography process.
The input block is triple encrypted using the PIN working keys
Digits are selected from the ciphertext result. These become the Pin Verification Value or Pin Offset.
The PIN Offset is stored
The PIN mailer is printed
Memory is cleared to binary zeroes to remove all traces of the clear PIN.
At this point, the only place the PIN value exists is inside the PIN mailer. The PIN cannot be derived from the PIN offset.
When the card is used and the PIN entered, the PIN offset is calculated again from the entered PIN, using the PIN working keys and compared to the stored offset value to determine if the correct PIN was entered. Clearly this means that when a PIN is validated, the validating system must have access to the PIN working keys used during initial PIN issue or subsequent PIN change.
It should be re-emphasised that the offset comprises selected digits from the ciphertext. Typically this would be 4-6 digits. It is not possible to recreate the keys or derive the PIN from this value.
Notes:
I.In some implementations, the PIN offset is stored on the magnetic stripe on the card. This is intended to be used in terminals which can perform local PIN validation. However, this technique is becoming rare as it prevents deployment of user-selectable PIN's.
II. Where the user is given the option to change PIN, the new offset is calculated in realtime and written to the database. Note that if the PIN is forgotten, it cannot be recreated.
III. The method described above is generic. There are many variations, such as the IBM3624 Method-A, Diebold method, and so on, however the principle remains the same.
IV. In many methods, the framework exists for using different key pairs based on an index value, usually stored on the magnetic stripe. This is a single digit value denoting the index of the key pair to be used. The intent is so that a) the same keys are not used across the entire cardbase, and c) that new keys can be used on re-issue without affecting existing cards.
CVV processing
It was quickly understood that the proliferation of financial cards exposed institutions to risk from counterfeiters. In the credit card world, this came from manufacture of cards with or without magnetic stripe encoding that possessed valid numbers and seemingly valid names and logos. In the ATM card arena, attackers observed PIN number entry 'over the shoulder', collated these PIN's with information from discarded receipts and so on, and constructed their own magnetic stripes on dummy cards for use at their leisure with observed PIN numbers.
These threats and others led to the introduction of the Card Verification Value, a non-derivable sequence of digits constructed by cryptographic process and written to the magnetic stripe of the card. This means that electronic capture of transactions (either at ATM or Point of Sale) are effectively protected against counterfeiters.
A combination of static data such as account number is triple encrypted using a special Card Verification key pair. Selected digits from the result are used to create the CVV, and this is written onto the magnetic stripe.
Similar comments apply to CVV as those for Pin Offset; As the CVV consists of few digits, and triple encryption is used, the CVV keys and values are highly secure and presence of a valid CVV provides an added level of confidence that the card is not counterfeit.
It should be noted that CVV is simply an additional protection method; it is not foolproof. It does not, for instance, protect against fraudulent captures of magnetic stripe data using, say, fake ATM's.
A further development of CVV, CVV2, is used for telephone authorisations. A similar (although not identical) calculation is performed as for CVV, and selected digits from the result are physically printed on the back of the card. These digits can then be requested by a call centre wishing to determine if the caller is really in possession of the card. Once again, this is an additional check, and not foolproof.
Key management
Key management relates to the storage, protection and transmission of keys. A single financial installation will have many DES keys, and these require careful management if they are not to become compromised or confused. One of the worst forms of debugging of computer faults is when cryptography is involved as traces and dumps are meaningless, and it can be very hard to discover that the wrong cryptography keys are being used!
Keys are normally managed in hierarchies. Keys that are actually used for computation, such as PIN validation [working keys] are themselves stored in enciphered format under a key encryption key. Other key sets will exist for transporting keys from one location to another, such as two nodes in a network. These are known as transport keys.
In good key management systems, working keys are never stored or exposed in clear format. Even when they are initially created, they are frequently created by automated process and never known to individuals.
When initial keys are created, the 64 bits are split between two or more individuals, who then toss a coin once for each bit required. The two or more individuals then key in their segment of the random key alone, and thus no one individual ever has sight of a whole key. This method is normally used for initial master key generation.
Although a simple concept, key management can become quite complex in implementation.
In a simple ATM network for instance, a terminal master key is used to encipher working keys in transit. A terminal master key (TMK) is generated for each terminal, split into two halves and printed (or sometimes encoded on a special magnetic card). Each TMK is then installed at their respective ATM's. The host system will then download terminal working keys, enciphered under the respective terminal master key, to each ATM. The terminal working key is then used to encipher PIN data in transit to the host during normal processing. If required, the terminal working key can be changed at regular intervals or through dynamic key exchange - but this process requires careful management.
It should be noted that the biggest single security exposure to DES based cryptographic subsystems is in the exchange of keys, thus good key management procedures are paramount.
Physical implementation
Cryptographic processing and key management is normally performed in specialised, dedicated secure hardware. Although DES can be implemented entirely in software (using products such as IBM's PCF), it is less secure, and the DES algorithm can be quite processor intensive.
There are companies that specialise in dedicated cryptographic units, such as Racal and Atalla. They are commonly called HSM's (Host Security Module) although this is the Racal proprietary name for the unit.
When using these devices, the intent is that all encipher and decipher activity takes place in the secure unit, and that clear keys and cleartext values are never exposed outside the unit.
Physically, HSM's are tamper proof and intended for installation in secure computer rooms. Attempts to open them will result in the destruction of keys contained in the devices.
HSM's are also capable of generating new random keys and random numbers for use as PIN's in a secure manner.
Some applications use physical telecommunications line encryption for added security, and there are a variety of manufacturers of this type of device. They are effectively 'black box' and require no special knowledge.
Examples
Cryptography in a normal ATM withdrawal
Consider a common ATM transaction:
A customer inserts his card in the ATM
The customer enters his PIN
The customer requests cash
The transaction is approved, cash is dispensed
There's an awful lot of cryptography going on in this process. For simplicity, we'll assume the acquiring and issuing bank are the same.
The cryptography activity is identified in italics in the sequence:
1. A customer inserts his card in the ATM
The magnetic stripe is read and stored in a buffer in the ATM
2. The customer enters his PIN
The PIN is entered into a tamper-proof PIN pad The stored PIN is stored in a security module in hardware
3. The customer requests cash
The message is constructed in the ATM The PIN (and possibly more) is enciphered under the Terminal key
The message is sent to the host, possibly enciphered in comms hardware.
On receipt at the host, the comms level encryption is deciphered The CVV is calculated and compared to the value on the magstripe The PIN under the Terminal key is deciphered The PIN offset or PVV is calculated The PIN offset or PVV is compared to the database of PVV's
4. The transaction is approved, cash is dispensed
Note: all the host cryptography functions are normally performed in the Host Security module. No Cleartext values are exposed to application programs or outside the secure environment.
Cryptography in an EFTPoS transaction
Even in a signature authorised environment, the CVV from the magnetic stripe can be validated at the host system to detect counterfeit cards. Clearly this only works in online environments as the CVV validation requires a cryptographic calculation to be performed at the host.
[Note: It is possible, and some manufacturers support, local key storage on EFTPoS devices and distributed terminals. Because of the key management complications, these devices are not considered here]
A more common use of cryptography in EFTPoS environments (and, increasingly in ATM and other traffic) is the MAC (Message Authentication Code). The MAC check can be thought of as a value calculated from the contents of all the critical fields in a message (such as card number and amount) and passed through a cryptographic algorithm. Although the message is carried over transmission lines in clear, the validation of the MAC field at the recipient will determine whether fields have been tampered with. [for the technically minded, MAC can be thought of as an encrypted LRC field]. The overhead of MAC is quite small. (The MAC is defined as 16 bytes in ISO8583).
Other financial cryptography applications
As well as traditional uses of cryptography as described above, interbank networks (such as SWIFT) have historically been large users of cryptographic techniques.
A plethora of new delivery mechanisms and far wider distribution of advanced technology to the public has increased both the interest in and the use of cryptographic techniques.
In cases where cryptography is required for widespread dissemination to the public (such as PC based home banking) ordinary DES is too complex to manage securely. More appropriate and more secure algorithms such as RSA (A "public key" encryption system) have evolved and been deployed in these environments - they are outside the scope of this paper but review of public key algorithms is especially encouraged where appropriate.
Some corporate, EDI and treasury applications use highly secure DES with a combination of techniques - MAC, physical encryption, dynamic key exchange, smart card key storage and so on. In one implementation reviewed, the working key is changed every transaction by the result of a MAC key calculation residue (a so-called "one time" key system).
EFT Switching Softwares in the world
This section covers software used to control ATM and EFTPoS networks. This software normally runs on a front-end system, handles the physical ATM and EFTPoS terminal devices, interfaces to the Bank host system and provides 24x7 operation, with stand-in processing where required. This type of software normally also interfaces with National and International switches for ATM sharing arrangements, and can provide authorization interfaces to international card schemes such as Visa and MasterCard. In a 'typical' implementation, it will also manage card issue, PIN validation and so on as well. Increasingly, this class of system is being enabled for e-Commerce support, and provision of other 24x7 services. The software is normally a packaged solution in most institutions. The market, especially in the larger institutions, is dominated by a small number of packages and vendors.
ACI (TSA Inc) Base-24 and Trans-24
Operating on the Tandem (Compaq NonStop Himalaya) platform, Base-24 is an industry standard product that is installed in a wide variety of financial institutions and national switches. Despite the high cost of ownership of Tandem fault tolerant hardware, Base-24 is practically a de facto standard for larger organizations and processes a staggering amount of transactions every day.
TSA also have a product called Trans-24 that operates in the mainframe and Unix environments. This is as a result of the inclusion of the ex-USSI product range (apart from the Stratus version) in the product line - these products used to be called Action 2000.
More information at www.tsainc.com
Arksys
Arksys are a wholly owned (but independently operated) subsidiary of Euronet Services Inc, who provides independent non-bank ATM networks in Europe. You may remember them as Arkansas Systems Inc, but the use of that name seems to be discouraged now.
Arksys have been around a while (since 1975), and quote 200 clients in 70 countries, and is based on AS/400 or PC hardware.
More information at www.arksys.com
eFunds Corporation – Connex
eFunds Corporation was a part of Deluxe Data which is a fairly well established US company (founded in 1915!). eFunds' Connex EFT operates on Tandem or IBM platforms, and is described very briefly on the eFunds’ website at www.efunds.com.
eFunds also produce Unix and NT based products branded IST/xxx (IST stands for Information Switching Technology). Components exist for ATM, EFT, PoS and the Internet.
IFS
Headquartered in Troy, NY, USA, IFS produce the TPII ATM and EFT auth software for Unix and NT platforms using an Oracle database. They claim solutions deployed in 35 countries, but do not quote a number of customers or licenses sold.
The web site contains quite detailed information on the solutions, and is at www.ifsintl.com
Interlink
The UK's Interlink have products and solutions deployed in 180 sites in 60 countries, and have been in the business since 1983. Their Sparrow product uses Unix or NT servers, and is a well-regarded solution for small to medium institutions.
A useful web site is provided at www.ilink.co.uk
Mosaic - Postilion
If I had to tip 'one to watch' in this software arena, it would be South African company Mosaic with their NT based Postilion product.
More information at www.mosaic.co.za The web site is excellent, and also contains a free downloadable Windows Cryptographic calculator (which is excellent) and a l ot of product data.
As a footnote, Postilion is distributed by Logica in the UK, who follow their curious practice of not telling you (on their web site) whose software Postilion is (they used to do this with ON/2 as well when they distributed that product). I must admit that at first glance it looks like Postilion is a Logica product, and that's very misleading.
SDM - OCM24
Stop press! SDM have now been acquired by TSA Inc (see Base-24 above). It appears that this means that TSA will replace existing S/390 offerings with OCM-24, as OCM has a more developed product that will utilize sysplex to provide high availability on the S/390 platform.
As with any of these acquisitions, the integration of products into a cohesive set is a difficult trick. Let's see what happens.
SDM International Inc produce SDM-24, an IBM mainframe based ATM, EFT system. This system tends to be recommended by IBM (SDM are an SDM business partner) in large systems (i.e. mainframe) situations.
SDM are a mature company (they've been around since 1980), based in North Carolina, USA. I don't have any specific information on customers (they're very coy about naming customers on their web site) but they cite 'hundreds' of licenses in eighteen countries. You should be aware that a license does not necessarily equal a customer; a single customer could have multiple licenses.
Traditionally, the mainframe based software products have lost out to the specific fault tolerant hardware based products, simply because they've struggled to provide true 24x7 operation. OCM-24 is CICS based and now provides parallel sysplex support to overcome this.
Their web site, with downloadable PDF brochures on the various modules is at www.sdm-international.com
SLM (SLMSoft.com)
Canadian SLM claims 1,500 customers in 52 countries. (If memory serves me correctly they were related in some way to Oasis originally), and they appear to be leaning more towards the e-commerce, multiple delivery channel model rather than strictly ATM and EFT.
Their web site is extremely slick, but doesn't tell you very much at www.slmsoft.com
ACI (TSA Inc) Base-24 and Trans-24
Operating on the Tandem (Compaq NonStop Himalaya) platform, Base-24 is an industry standard product that is installed in a wide variety of financial institutions and national switches. Despite the high cost of ownership of Tandem fault tolerant hardware, Base-24 is practically a de facto standard for larger organizations and processes a staggering amount of transactions every day.
TSA also have a product called Trans-24 that operates in the mainframe and Unix environments. This is as a result of the inclusion of the ex-USSI product range (apart from the Stratus version) in the product line - these products used to be called Action 2000.
More information at www.tsainc.com
Arksys
Arksys are a wholly owned (but independently operated) subsidiary of Euronet Services Inc, who provides independent non-bank ATM networks in Europe. You may remember them as Arkansas Systems Inc, but the use of that name seems to be discouraged now.
Arksys have been around a while (since 1975), and quote 200 clients in 70 countries, and is based on AS/400 or PC hardware.
More information at www.arksys.com
eFunds Corporation – Connex
eFunds Corporation was a part of Deluxe Data which is a fairly well established US company (founded in 1915!). eFunds' Connex EFT operates on Tandem or IBM platforms, and is described very briefly on the eFunds’ website at www.efunds.com.
eFunds also produce Unix and NT based products branded IST/xxx (IST stands for Information Switching Technology). Components exist for ATM, EFT, PoS and the Internet.
IFS
Headquartered in Troy, NY, USA, IFS produce the TPII ATM and EFT auth software for Unix and NT platforms using an Oracle database. They claim solutions deployed in 35 countries, but do not quote a number of customers or licenses sold.
The web site contains quite detailed information on the solutions, and is at www.ifsintl.com
Interlink
The UK's Interlink have products and solutions deployed in 180 sites in 60 countries, and have been in the business since 1983. Their Sparrow product uses Unix or NT servers, and is a well-regarded solution for small to medium institutions.
A useful web site is provided at www.ilink.co.uk
Mosaic - Postilion
If I had to tip 'one to watch' in this software arena, it would be South African company Mosaic with their NT based Postilion product.
More information at www.mosaic.co.za The web site is excellent, and also contains a free downloadable Windows Cryptographic calculator (which is excellent) and a l ot of product data.
As a footnote, Postilion is distributed by Logica in the UK, who follow their curious practice of not telling you (on their web site) whose software Postilion is (they used to do this with ON/2 as well when they distributed that product). I must admit that at first glance it looks like Postilion is a Logica product, and that's very misleading.
SDM - OCM24
Stop press! SDM have now been acquired by TSA Inc (see Base-24 above). It appears that this means that TSA will replace existing S/390 offerings with OCM-24, as OCM has a more developed product that will utilize sysplex to provide high availability on the S/390 platform.
As with any of these acquisitions, the integration of products into a cohesive set is a difficult trick. Let's see what happens.
SDM International Inc produce SDM-24, an IBM mainframe based ATM, EFT system. This system tends to be recommended by IBM (SDM are an SDM business partner) in large systems (i.e. mainframe) situations.
SDM are a mature company (they've been around since 1980), based in North Carolina, USA. I don't have any specific information on customers (they're very coy about naming customers on their web site) but they cite 'hundreds' of licenses in eighteen countries. You should be aware that a license does not necessarily equal a customer; a single customer could have multiple licenses.
Traditionally, the mainframe based software products have lost out to the specific fault tolerant hardware based products, simply because they've struggled to provide true 24x7 operation. OCM-24 is CICS based and now provides parallel sysplex support to overcome this.
Their web site, with downloadable PDF brochures on the various modules is at www.sdm-international.com
SLM (SLMSoft.com)
Canadian SLM claims 1,500 customers in 52 countries. (If memory serves me correctly they were related in some way to Oasis originally), and they appear to be leaning more towards the e-commerce, multiple delivery channel model rather than strictly ATM and EFT.
Their web site is extremely slick, but doesn't tell you very much at www.slmsoft.com
Types of cards
TYPES OF CARDS
The industry typically divides up cards by the business of the issuer. So there are bank cards (VISA, Master Card, Discover), Petroleum Cards (SUN Oil, Exxon, etc.), and Travel and Entertainment (T&E) cards (American Express, Diners' Club, Carte Blanche). Other cards are typically lumped together as "Private Label" cards. That would include department store cards, telephone cards, and the like. Most private label cards are only accepted by the issuer. People are starting to divide the telephone cards into a separate class, but it hasn't received widespread acceptance. (This is just a matter of terminology, and doesn't affect anything important.)
Cards are also divided by how they are billed. Thus there are credit cards (VISA, MC, Discover, most department store cards), charge cards (American Express, AT&T, many petroleum cards) and debit cards. Credit cards invoke a loan of money by the issuer to the cardholder under pre-arranged terms and conditions. Charge cards are simply a payment convenience, and their total balance is due when billed. When a debit card is used, the amount is taken directly from the cardholder's account with the issuer. Terminology is loose - often people use "credit card" to encompass credit cards and charge cards.
A recent phenomenon is third-party debit cards. These cards are issued by an organization with which the cardholder has no account relationship. Instead, the cardholder provides the card issuer with the information necessary to debit the cardholder's checking account directly through an Automated Clearing House (ACH), the same way a check would be cleared. This is sort of like direct deposit of paychecks, in reverse. ACHs love third-party debit cards. Banks hate them.
Another addition is affinity cards. These cards are valid credit cards from their issuer, but carry the logo of a third party, and the third party benefits from their use. There is an incredible variety of affinity cards, ranging from airlines to colleges to professional sports teams.
HOW THEY MAKE MONEY
Issuers of credit cards make money from cardholder fees and from interest paid on outstanding balances. Not all issuers charge fees. Even those that do, make most of their money on the interest. They really like people who pay the minimum each month.
Issuers of charge cards make money from cardholder fees. Some charge cards actually run at a loss for the company, particularly those that are free. The primary purpose of such cards is to stimulate business.
Issuers of debit cards may make money on transaction fees. Not all debit card transactions have fees. Most debit cards exist to stimulate business for the bank and to offload tellers and back-room departments. To date, third-party debit cards exist solely to stimulate business. Providers of such cards make no direct money from their use.
Acquirers make money from transaction charges and discount fees. Unlike the charges and fees mentioned above, these fees are paid by the accepter, not (directly) by the cardholder. (Technically, it is not legal for the merchants to pass these charges directly to the consumer.) Transaction charges are typically in pennies per transaction, and are sensitive to the type of communication used for the authorization. Discount fees are a percentage of the purchase price and are sensitive to volume and compliance to rules. One way to encourage merchants to follow certain procedures or to upgrade to new equipment is to offer a lower discount fee.
Until fairly recently, the only motivation for accepters was to expand their business by accepting cards. Reduction of fraud was enough reason for many merchants to pay authorization fees, but in many cases, it isn't worth the cost. (That is, it is cheaper to pay the fraud than to prevent it.) Recently, electronic settlement has provided merchants with an added benefit by reducing float on charged purchases. Merchants can now get their accounts credited much faster than before, which helps cash flow.
Companies that issue charge cards are real keen on float reduction. The sooner they can bill you, the sooner they get their money. Credit card companies are also interested in float reduction, since the sooner they bill, the sooner they can start charging interest. Debit cards typically involve little or no float.
Affinity cards usually pay a percentage of purchases to the affinity organization. Although it may seem obvious to take this money from the discount fee, this doesn't work since the issuer is not always the acquirer. The money for this usually comes from the interest paid on outstanding balances. Essentially, the bank is giving a share of its profits to an organization in turn for the organization promoting use of its credit card. The affinity organization is free to use its cut any way it wishes. An airline will typically put it into the frequent flyer program (and credit miles to your account). A college may put the money into the general fund or into a scholarship fund.
THE BUSINESS RELATIONSHIPS
Card acceptors generally sign up with a local acquirer for authorization and settlement of all credit cards. This acquirer may or may not be a card issuer, but certainly will not have issued all the cards that the merchant can accept. The accepter does not generally call one place for VISA and a different place for MC, for example. At one time, this was necessary, but more and more acquirers are connected to all networks and are offering a broader range of services.
Acquirers generally are connected to many issuers, and pay transaction charges and discount fees to those issuers for authorizations. Thus, the acquirer is actually making money on the difference between fees paid and fees billed. Most acquirers gather together transactions from many accepters, allowing them to get volume discounts on fees. Since the accepters individually have lower volume and are not eligible for those discounts, there is a markup that the acquirer can get away with. Acquirers also, of course, provide the convenience of a single contact.
Most large banks are issuers and acquirers. Things get real interesting when it's time to settle up. Some small banks are only issuers. There are third parties that are only acquirers.
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.
The industry typically divides up cards by the business of the issuer. So there are bank cards (VISA, Master Card, Discover), Petroleum Cards (SUN Oil, Exxon, etc.), and Travel and Entertainment (T&E) cards (American Express, Diners' Club, Carte Blanche). Other cards are typically lumped together as "Private Label" cards. That would include department store cards, telephone cards, and the like. Most private label cards are only accepted by the issuer. People are starting to divide the telephone cards into a separate class, but it hasn't received widespread acceptance. (This is just a matter of terminology, and doesn't affect anything important.)
Cards are also divided by how they are billed. Thus there are credit cards (VISA, MC, Discover, most department store cards), charge cards (American Express, AT&T, many petroleum cards) and debit cards. Credit cards invoke a loan of money by the issuer to the cardholder under pre-arranged terms and conditions. Charge cards are simply a payment convenience, and their total balance is due when billed. When a debit card is used, the amount is taken directly from the cardholder's account with the issuer. Terminology is loose - often people use "credit card" to encompass credit cards and charge cards.
A recent phenomenon is third-party debit cards. These cards are issued by an organization with which the cardholder has no account relationship. Instead, the cardholder provides the card issuer with the information necessary to debit the cardholder's checking account directly through an Automated Clearing House (ACH), the same way a check would be cleared. This is sort of like direct deposit of paychecks, in reverse. ACHs love third-party debit cards. Banks hate them.
Another addition is affinity cards. These cards are valid credit cards from their issuer, but carry the logo of a third party, and the third party benefits from their use. There is an incredible variety of affinity cards, ranging from airlines to colleges to professional sports teams.
HOW THEY MAKE MONEY
Issuers of credit cards make money from cardholder fees and from interest paid on outstanding balances. Not all issuers charge fees. Even those that do, make most of their money on the interest. They really like people who pay the minimum each month.
Issuers of charge cards make money from cardholder fees. Some charge cards actually run at a loss for the company, particularly those that are free. The primary purpose of such cards is to stimulate business.
Issuers of debit cards may make money on transaction fees. Not all debit card transactions have fees. Most debit cards exist to stimulate business for the bank and to offload tellers and back-room departments. To date, third-party debit cards exist solely to stimulate business. Providers of such cards make no direct money from their use.
Acquirers make money from transaction charges and discount fees. Unlike the charges and fees mentioned above, these fees are paid by the accepter, not (directly) by the cardholder. (Technically, it is not legal for the merchants to pass these charges directly to the consumer.) Transaction charges are typically in pennies per transaction, and are sensitive to the type of communication used for the authorization. Discount fees are a percentage of the purchase price and are sensitive to volume and compliance to rules. One way to encourage merchants to follow certain procedures or to upgrade to new equipment is to offer a lower discount fee.
Until fairly recently, the only motivation for accepters was to expand their business by accepting cards. Reduction of fraud was enough reason for many merchants to pay authorization fees, but in many cases, it isn't worth the cost. (That is, it is cheaper to pay the fraud than to prevent it.) Recently, electronic settlement has provided merchants with an added benefit by reducing float on charged purchases. Merchants can now get their accounts credited much faster than before, which helps cash flow.
Companies that issue charge cards are real keen on float reduction. The sooner they can bill you, the sooner they get their money. Credit card companies are also interested in float reduction, since the sooner they bill, the sooner they can start charging interest. Debit cards typically involve little or no float.
Affinity cards usually pay a percentage of purchases to the affinity organization. Although it may seem obvious to take this money from the discount fee, this doesn't work since the issuer is not always the acquirer. The money for this usually comes from the interest paid on outstanding balances. Essentially, the bank is giving a share of its profits to an organization in turn for the organization promoting use of its credit card. The affinity organization is free to use its cut any way it wishes. An airline will typically put it into the frequent flyer program (and credit miles to your account). A college may put the money into the general fund or into a scholarship fund.
THE BUSINESS RELATIONSHIPS
Card acceptors generally sign up with a local acquirer for authorization and settlement of all credit cards. This acquirer may or may not be a card issuer, but certainly will not have issued all the cards that the merchant can accept. The accepter does not generally call one place for VISA and a different place for MC, for example. At one time, this was necessary, but more and more acquirers are connected to all networks and are offering a broader range of services.
Acquirers generally are connected to many issuers, and pay transaction charges and discount fees to those issuers for authorizations. Thus, the acquirer is actually making money on the difference between fees paid and fees billed. Most acquirers gather together transactions from many accepters, allowing them to get volume discounts on fees. Since the accepters individually have lower volume and are not eligible for those discounts, there is a markup that the acquirer can get away with. Acquirers also, of course, provide the convenience of a single contact.
Most large banks are issuers and acquirers. Things get real interesting when it's time to settle up. Some small banks are only issuers. There are third parties that are only acquirers.
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.
ATM & Debit cards
The Debit Card originated as a method for bank customers to have access to their funds through Automatic Teller Machines (ATMs). This was seen as a way for banks to automate their branches and save money, as well as a benefit for customers. A secondary intent was for the card to be used as a method of identification when dealing with a human teller. Although that idea never really caught on, it has seen renewed interest from time to time.
One problem with using cards to access bank accounts is that federal regulations required a signature be used for each withdrawal transaction. After much debate, the concept of a Personal Identification Number (PIN) was invented, and federal regulations were modified to allow PINs for use in place of signatures with bank withdrawals. ATMs also faced many other regulatory difficulties. In many states, for example, there are limitations on the number of branches a bank can have. In a conflict that only a lawyer could conceive of, a ruling was required about whether an ATM constitutes a bank branch or not. Since such rulings were made on a state-by-state basis, it varies across the country. This results in some very odd arrangements in some states, because of requirements placed on bank branches.
In early attempts, the card actually carried account information and balances. The cardholder would bring the card into a branch, and bank personnel would "load" money onto the card, based on the customer's actual account balance. The cardholder could then use the card at a stand-alone machine that would update the information on the card as money was withdrawn.
The information was stored on track 3 of the magnetic stripe, as mentioned in an earlier installment. This approach had many problems. It was far too susceptible to fraud, it could not reasonably handle multiple accounts, and it could not be used as a vehicle for other services. Since it was pretty much limited to withdrawals, it didn't even automate much of the bank branch functions.
The online ATM offered a solution to the problems of the early ATM cards. Since the ATM was connected to the bank's host, it was no longer necessary to maintain account balances on the card itself, which removed a major source of fraud. Also, access to multiple accounts became possible, as did additional services, such as bill payment.
Once banks started buying and installing ATMs, they quickly realized that it is very expensive to maintain a large number of machines. Yet customers began demanding more machines, so they could have easier access to their funds. Since many banks in an area would have ATMs, the obvious solution was to somehow cross-connect bank hosts so that customers could use ATMs at other banks, for convenience. The lawyers struck again. Does a shared ATM count as a branch for both banks? Does a transaction at a shared ATM mean that one bank is doing financial transactions for another, which is not allowed? If two banks share ATMs, but refuse to allow a third bank, is that monopolizing or restraint of trade? Strange restrictions on shared ATM transactions resulted.
Soon interchange standards began to evolve, and ATM networks became a competitive tool. Regional and national networks started to emerge. And the lawyers struck again. If a network allows transactions in one state for a bank in another state, isn't that interstate banking, which was at the time forbidden? Should an ATM network that dominates a region become a regulated monopoly? Should an ATM network that gets really big be considered a public utility?
Today, the regional and national networks continue to grow and offer more services and more interconnections. All of the regulatory issues have not been resolved, and this is creating a lot of tension for easing banking restrictions.
An ATM card is just an ATM card, regardless of how many ATMs it works in. Most banks long ago saw an opportunity for the ATM card to be used as a debit card, presumably to replace checks. A tremendous number of checks are used each year, and it costs banks a lot of money to process them. Debit card transactions could cost less to process, given an appropriate infrastructure. Some of the costs could potentially be passed on to the merchants or the consumers, who are notoriously reluctant to directly pay the cost of checks. So far there have been many trials of using ATM cards as debit cards at the point of sale, but they have, in general, met with consumer apathy. In some areas, where banks have aggressively promoted debit, things have gone better. Still, general acceptance of debit seems a ways off.
One interesting twist to the debit card story is the emergence of third party debit cards. Issuers of these cards have no real account relationship with the cardholders. Instead, they obtain permission from the cardholders to debit their checking accounts directly through the Automated Clearing Houses (ACHs); the same way checks are cleared. (Think of it as direct deposit, in reverse.) Oil companies first started experimenting with this a couple of years ago, and it has met with surprising success. Banks dislike this concept, because it competes directly with their debit cards, but isn't subject to the same state and federal regulations. ACHs like this, because it bolsters their business, which otherwise stands to lose a lot by acceptance of debit cards. Merchants generally like this, especially the large retailers, because it allows them to get their payment systems out from under the control of the banks.
THE ATM
An ATM is an interesting combination of computer, communication, banking, and security technology all in one box. A typical machine has a microprocessor, usually along the lines of an 8086, a communications module (which may have it's own microprocessor), a security module (also with a microprocessor), and special-purpose controllers for the hardware. The user interface is typically a CRT, a telephone-style keypad, and some soft function keys. Typically there is a lot of memory, but no disk. The screens and program are usually downloaded from the host at initialization, and are stored in battery-backed RAM indefinitely. The machine typically interacts with the host for every transaction, but it can operate offline if necessary, as dictated by the downloaded program. The downloaded program is often in an industry-standard "states and screens" format that was created by Diebold, a manufacturer of various banking equipment, including ATMs.
Most machines can use a few IBM protocols (BiSync, SNA, and an outmoded but still used "loop" protocol), Burroughs poll/select, and perhaps some others, depending on which communications module is in place. This allows the manufacturer to make a standard machine, and plug in different communications hardware to suit the customer. The IBM BiSync and SNA protocols are most common, with most networks moving toward SNA.
The security modules do all encryption for the ATM. They are sep
arate devices that are physically sealed and cannot be opened or tapped without destroying the data within them. In a truly secure application, no sensitive data entering or leaving the security module is in clear-text. Arranging this and maintaining it is more complicated than I can go into here.
Most ATMs contain two bill dispensers, a "divert" bin for bills, a "capture" bin for cards, a card reader, receipt printer, journal printer, and envelope receptacle. Some ATMs have more than two bill dispensers, and can even dispense coins.
When an ATM is dispensing money, it counts the appropriate bills out of the bill dispensers, and uses a couple of mechanical and optical checks to make sure it counted correctly. If the checks fail, it shunts the bills into the divert bin and tries again. Typically, this is because two bills were stuck together. Sometimes ATM has sensor faults, and divert the total contents of both bill dispensers the first time a user asks for a withdrawal. "Gee, all I did was ask for $50, and this machine made all kinds of funny whirring noises and shut down." Most banks will put twenty-dollar bills in one of the dispensers and five-dollar bills in the other. Some use tens and fives, or tens and twenties. Depending on the denominations of the bills, the size of the dispensers, and the policy of the bank, an ATM can hold tens of thousands of dollars.
The journal printer keeps a running log of every use of the machine, and exactly what the machine is doing, for audit purposes. You can often hear it printing as soon as you put your card in or after your transaction is complete.
When you put an envelope into an ATM, the transaction information is usually printed directly on the envelope, so that verifying the deposit is easier. Bank policies typically require that any deposit envelope be opened and verified by two people. In this, you're actually safer depositing cash at an ATM than giving it to a human teller.
A card will be diverted to the capture bin if it is on the "hot card" list, if the user doesn't enter a correct PIN, or if the user walks away and forgets to take the card.
On some machines, the divert bin, capture bin, envelope receptacle, and bill dispenser bins are all separately locked containers, so that re-stocking can be done by courier services who simply swap bins and return the whole thing to a central site.
The entire ATM is typically housed in a hardened steel case with alarm circuitry built in. Some of these ATMs have been known to survive dynamite explosions. The housing typically has a combination lock on the door, and no single person knows the entire combination. The machine can thus be opened for restocking, maintenance, or repair, only if at least two people are present.
DEBIT CARD PROCESSING
Debit card processing is fairly similar to credit and charge card processing, with a few exceptions. First, in the case of ATMs, the accepter and acquirer are usually the same. For debit card use at the point of sale, the usual acquirer-accepter relationship holds. In general, acquirers may do front-end screening on debit cards, but all approvals are generated by the issuer - the floor limit is zero. This makes it possible to eliminate a separate settlement process for debit card transactions, but places additional security and reliability constraints on the "authorization". Often a separate settlement is done anyway.
One problem that has caused difficulties for POS use of debit cards is the use of PINs. Many merchants and cardholders would rather use signature for identity verification. But most debit systems grew out of ATM systems, and require PINs. This is an ironic reversal of the early ATM card days, when people were trying to avoid requiring signature. Other than the PIN, the information required for a debit transaction is the same as that required for a credit transaction.
One problem with using cards to access bank accounts is that federal regulations required a signature be used for each withdrawal transaction. After much debate, the concept of a Personal Identification Number (PIN) was invented, and federal regulations were modified to allow PINs for use in place of signatures with bank withdrawals. ATMs also faced many other regulatory difficulties. In many states, for example, there are limitations on the number of branches a bank can have. In a conflict that only a lawyer could conceive of, a ruling was required about whether an ATM constitutes a bank branch or not. Since such rulings were made on a state-by-state basis, it varies across the country. This results in some very odd arrangements in some states, because of requirements placed on bank branches.
In early attempts, the card actually carried account information and balances. The cardholder would bring the card into a branch, and bank personnel would "load" money onto the card, based on the customer's actual account balance. The cardholder could then use the card at a stand-alone machine that would update the information on the card as money was withdrawn.
The information was stored on track 3 of the magnetic stripe, as mentioned in an earlier installment. This approach had many problems. It was far too susceptible to fraud, it could not reasonably handle multiple accounts, and it could not be used as a vehicle for other services. Since it was pretty much limited to withdrawals, it didn't even automate much of the bank branch functions.
The online ATM offered a solution to the problems of the early ATM cards. Since the ATM was connected to the bank's host, it was no longer necessary to maintain account balances on the card itself, which removed a major source of fraud. Also, access to multiple accounts became possible, as did additional services, such as bill payment.
Once banks started buying and installing ATMs, they quickly realized that it is very expensive to maintain a large number of machines. Yet customers began demanding more machines, so they could have easier access to their funds. Since many banks in an area would have ATMs, the obvious solution was to somehow cross-connect bank hosts so that customers could use ATMs at other banks, for convenience. The lawyers struck again. Does a shared ATM count as a branch for both banks? Does a transaction at a shared ATM mean that one bank is doing financial transactions for another, which is not allowed? If two banks share ATMs, but refuse to allow a third bank, is that monopolizing or restraint of trade? Strange restrictions on shared ATM transactions resulted.
Soon interchange standards began to evolve, and ATM networks became a competitive tool. Regional and national networks started to emerge. And the lawyers struck again. If a network allows transactions in one state for a bank in another state, isn't that interstate banking, which was at the time forbidden? Should an ATM network that dominates a region become a regulated monopoly? Should an ATM network that gets really big be considered a public utility?
Today, the regional and national networks continue to grow and offer more services and more interconnections. All of the regulatory issues have not been resolved, and this is creating a lot of tension for easing banking restrictions.
An ATM card is just an ATM card, regardless of how many ATMs it works in. Most banks long ago saw an opportunity for the ATM card to be used as a debit card, presumably to replace checks. A tremendous number of checks are used each year, and it costs banks a lot of money to process them. Debit card transactions could cost less to process, given an appropriate infrastructure. Some of the costs could potentially be passed on to the merchants or the consumers, who are notoriously reluctant to directly pay the cost of checks. So far there have been many trials of using ATM cards as debit cards at the point of sale, but they have, in general, met with consumer apathy. In some areas, where banks have aggressively promoted debit, things have gone better. Still, general acceptance of debit seems a ways off.
One interesting twist to the debit card story is the emergence of third party debit cards. Issuers of these cards have no real account relationship with the cardholders. Instead, they obtain permission from the cardholders to debit their checking accounts directly through the Automated Clearing Houses (ACHs); the same way checks are cleared. (Think of it as direct deposit, in reverse.) Oil companies first started experimenting with this a couple of years ago, and it has met with surprising success. Banks dislike this concept, because it competes directly with their debit cards, but isn't subject to the same state and federal regulations. ACHs like this, because it bolsters their business, which otherwise stands to lose a lot by acceptance of debit cards. Merchants generally like this, especially the large retailers, because it allows them to get their payment systems out from under the control of the banks.
THE ATM
An ATM is an interesting combination of computer, communication, banking, and security technology all in one box. A typical machine has a microprocessor, usually along the lines of an 8086, a communications module (which may have it's own microprocessor), a security module (also with a microprocessor), and special-purpose controllers for the hardware. The user interface is typically a CRT, a telephone-style keypad, and some soft function keys. Typically there is a lot of memory, but no disk. The screens and program are usually downloaded from the host at initialization, and are stored in battery-backed RAM indefinitely. The machine typically interacts with the host for every transaction, but it can operate offline if necessary, as dictated by the downloaded program. The downloaded program is often in an industry-standard "states and screens" format that was created by Diebold, a manufacturer of various banking equipment, including ATMs.
Most machines can use a few IBM protocols (BiSync, SNA, and an outmoded but still used "loop" protocol), Burroughs poll/select, and perhaps some others, depending on which communications module is in place. This allows the manufacturer to make a standard machine, and plug in different communications hardware to suit the customer. The IBM BiSync and SNA protocols are most common, with most networks moving toward SNA.
The security modules do all encryption for the ATM. They are sep
arate devices that are physically sealed and cannot be opened or tapped without destroying the data within them. In a truly secure application, no sensitive data entering or leaving the security module is in clear-text. Arranging this and maintaining it is more complicated than I can go into here.
Most ATMs contain two bill dispensers, a "divert" bin for bills, a "capture" bin for cards, a card reader, receipt printer, journal printer, and envelope receptacle. Some ATMs have more than two bill dispensers, and can even dispense coins.
When an ATM is dispensing money, it counts the appropriate bills out of the bill dispensers, and uses a couple of mechanical and optical checks to make sure it counted correctly. If the checks fail, it shunts the bills into the divert bin and tries again. Typically, this is because two bills were stuck together. Sometimes ATM has sensor faults, and divert the total contents of both bill dispensers the first time a user asks for a withdrawal. "Gee, all I did was ask for $50, and this machine made all kinds of funny whirring noises and shut down." Most banks will put twenty-dollar bills in one of the dispensers and five-dollar bills in the other. Some use tens and fives, or tens and twenties. Depending on the denominations of the bills, the size of the dispensers, and the policy of the bank, an ATM can hold tens of thousands of dollars.
The journal printer keeps a running log of every use of the machine, and exactly what the machine is doing, for audit purposes. You can often hear it printing as soon as you put your card in or after your transaction is complete.
When you put an envelope into an ATM, the transaction information is usually printed directly on the envelope, so that verifying the deposit is easier. Bank policies typically require that any deposit envelope be opened and verified by two people. In this, you're actually safer depositing cash at an ATM than giving it to a human teller.
A card will be diverted to the capture bin if it is on the "hot card" list, if the user doesn't enter a correct PIN, or if the user walks away and forgets to take the card.
On some machines, the divert bin, capture bin, envelope receptacle, and bill dispenser bins are all separately locked containers, so that re-stocking can be done by courier services who simply swap bins and return the whole thing to a central site.
The entire ATM is typically housed in a hardened steel case with alarm circuitry built in. Some of these ATMs have been known to survive dynamite explosions. The housing typically has a combination lock on the door, and no single person knows the entire combination. The machine can thus be opened for restocking, maintenance, or repair, only if at least two people are present.
DEBIT CARD PROCESSING
Debit card processing is fairly similar to credit and charge card processing, with a few exceptions. First, in the case of ATMs, the accepter and acquirer are usually the same. For debit card use at the point of sale, the usual acquirer-accepter relationship holds. In general, acquirers may do front-end screening on debit cards, but all approvals are generated by the issuer - the floor limit is zero. This makes it possible to eliminate a separate settlement process for debit card transactions, but places additional security and reliability constraints on the "authorization". Often a separate settlement is done anyway.
One problem that has caused difficulties for POS use of debit cards is the use of PINs. Many merchants and cardholders would rather use signature for identity verification. But most debit systems grew out of ATM systems, and require PINs. This is an ironic reversal of the early ATM card days, when people were trying to avoid requiring signature. Other than the PIN, the information required for a debit transaction is the same as that required for a credit transaction.
Subscribe to:
Posts (Atom)