1015 lines
51 KiB
Plaintext
1015 lines
51 KiB
Plaintext
/usr/staff/cc/misc [65] cat credit.desc
|
||
From cca.ucsf.edu!ucsfcgl!ucbvax!tut.cis.ohio-state.edu!rutgers!dptg!lznv!ziegle
|
||
Article 2226 of misc.consumers:
|
||
Path: wet!cca.ucsf.edu!ucsfcgl!ucbvax!tut.cis.ohio-state.edu!rutgers!dptg!lznv!z
|
||
>From: ziegler@lznv.ATT.COM (J.ZIEGLER)
|
||
Newsgroups: misc.consumers
|
||
Subject: Credit Card 101 Part 1 of 6 - The Players
|
||
Keywords: Credit Debit Charge Banks
|
||
Message-ID: <1656@lznv.ATT.COM>
|
||
Date: 25 Sep 89 20:13:50 GMT
|
||
Distribution: usa
|
||
Organization: AT&T ISL Lincroft NJ USA
|
||
Lines: 197
|
||
|
||
|
||
Part one in a series of postings about the workings of the credit
|
||
card industry.
|
||
|
||
DEFINITIONS
|
||
-----------
|
||
|
||
First some terms, along with the meanings they have in the industry:
|
||
|
||
Cardholder - an individual to whom a credit card is issued. Typically,
|
||
this individual is also responsible for payment of all charges made
|
||
to that card. Corporate cards are an exception to this rule.
|
||
|
||
Card Issuer - an institution that issues credit cards to cardholders.
|
||
This institution is also responsible for billing the cardholder for
|
||
charges. Often abbreviated to "Issuer".
|
||
|
||
Card Accepter - an individual, organization, or corporation that
|
||
accepts credit cards as payment for merchandise or services. Often
|
||
abbreviated "Accepter" or "merchant".
|
||
|
||
Acquirer - an organization that collects (acquires) credit
|
||
authorization requests from Card Accepters and provides guarantees
|
||
of payment. Normally, this will be by agreement with the Issuer of
|
||
the card in question.
|
||
|
||
Many issuers are also acquirers. Some issuers allow other acquirers to
|
||
provide authorizations for them, under pre-agreed conditions. Other
|
||
issuers provide all their own authorizations.
|
||
|
||
|
||
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 recent 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. Some petroleum stations have gotten away with giving a
|
||
discount for cash, and it has survived court challenges so far.)
|
||
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. Lord only
|
||
knows what a sports team does with the money!
|
||
|
||
|
||
THE 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
|
||
("cardmember" to them) services.
|
||
|
||
VISA is a non-profit corporation (SURPRISE!) 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.
|
||
|
||
|
||
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.
|
||
|
||
In future episodes, I'll explain how standards help all this chaos work
|
||
together, and give details about how the authorization process happens.
|
||
|
||
Joe Ziegler
|
||
att!lznv!ziegler
|
||
|
||
|
||
From cca.ucsf.edu!ucsfcgl!ucbvax!ucsd!rutgers!dptg!lznv!ziegler Fri Sep 29 22:25
|
||
Article 2263 of misc.consumers:
|
||
Path: wet!cca.ucsf.edu!ucsfcgl!ucbvax!ucsd!rutgers!dptg!lznv!ziegler
|
||
>From: ziegler@lznv.ATT.COM (J.ZIEGLER)
|
||
Newsgroups: misc.consumers
|
||
Subject: Credit Card 101, Part 2 of 6 - Standards
|
||
Keywords: credit, debit, banks, standards
|
||
Message-ID: <1658@lznv.ATT.COM>
|
||
Date: 26 Sep 89 21:24:11 GMT
|
||
Distribution: usa
|
||
Organization: AT&T ISL Lincroft NJ USA
|
||
Lines: 208
|
||
|
||
|
||
This is part two in a planned six-part series about the credit card
|
||
industry. It would be best if you read part one before reading
|
||
this part. Enjoy.
|
||
|
||
DEFINITIONS
|
||
-----------
|
||
|
||
Some more new terms that are used in this posting.
|
||
|
||
ABA - American Bankers Association
|
||
|
||
ACH - Automated Clearing House - an organization that mechanically and
|
||
electronically processes checks.
|
||
|
||
ANSI - American National Standards Institute
|
||
|
||
Embossing - creating raised letters and numbers on the face of the
|
||
card.
|
||
|
||
Encoding - recording data on the magnetic stripe on the back of the
|
||
card.
|
||
|
||
Imprinting - using the embossed information to make an impression on a
|
||
charge slip.
|
||
|
||
Interchange - sending authorization requests from one host (the
|
||
acquirer) to another (the issuer) for approval.
|
||
|
||
ISO - International Standards Organization
|
||
|
||
NACHA - National Automated Clearing House Association
|
||
|
||
PAN - Personal Account Number. The account number associated with a
|
||
credit, debit or charge card. This is usually the same as the
|
||
number on the card.
|
||
|
||
PIN - Personal Identification Number. A number associated with the
|
||
card, that is supposedly know only to the cardholder and the card
|
||
issuer. This number is used for verification of cardholder
|
||
identity.
|
||
|
||
|
||
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 numerics, 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 Network E(something) 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.
|
||
|
||
In the next installment, I'll describe how an authorization happens, as
|
||
well as how the settlement process gets the bill to you and your money
|
||
to the merchant. After that I'll describe various methods of fraud,
|
||
and how issuers, acquirers, and accepters protect themselves. Stay
|
||
tuned.
|
||
|
||
Joe Ziegler
|
||
att!lznv!ziegler
|
||
|
||
|
||
From cca.ucsf.edu!ucsfcgl!ucbvax!tut.cis.ohio-state.edu!rutgers!dptg!lznv!ziegle
|
||
Article 2307 of misc.consumers:
|
||
Path: wet!cca.ucsf.edu!ucsfcgl!ucbvax!tut.cis.ohio-state.edu!rutgers!dptg!lznv!z
|
||
>From: ziegler@lznv.ATT.COM (J.ZIEGLER)
|
||
Newsgroups: misc.consumers
|
||
Subject: Credit Card 101, Part 3 - Authorization and Settlement
|
||
Keywords: credit, banks, authorization
|
||
Message-ID: <1661@lznv.ATT.COM>
|
||
Date: 27 Sep 89 21:56:38 GMT
|
||
Distribution: usa
|
||
Organization: AT&T ISL Lincroft NJ USA
|
||
Lines: 282
|
||
|
||
|
||
Here's part 3 in my six-part series on the credit card industry.
|
||
This part discusses how authorization and settlement work. This is
|
||
a long one. It will help if you have read parts 1 and 2, since I
|
||
had to leave out a lot of overlap to keep this from getting
|
||
ridiculous. Enjoy.
|
||
|
||
|
||
THE ACCEPTER
|
||
--- --------
|
||
|
||
An important fact to note is that a card accepter does not have to get
|
||
approval for any purchases using credit or charge cards. Of course, a
|
||
merchant is usually interested in actually getting money, and so must
|
||
participate in some form of settlement process (see below). Usually,
|
||
the most acceptable (to a merchant) forms of settlement are tied (by
|
||
the acquirer) to authorization processes. However, a merchant could
|
||
simply accept all cards without any validation, and eat any fraud that
|
||
results.
|
||
|
||
A merchant typically makes a business arrangement with a local bank or
|
||
some other acquirer for authorization and settlement services. The
|
||
acquirer assigns a merchant identifier to that merchant, which will
|
||
uniquely identify the location of the transaction. (This facilitates
|
||
compliance with federal regulations requiring that credit card bills
|
||
identify where each purchase was made.) The acquirer also establishes
|
||
procedures for the merchant to follow. The procedures will vary by
|
||
type of the merchant business, geographic location, volume of
|
||
transactions, and types of cards accepted.
|
||
|
||
If the merchant follows the procedures given by the acquirer and a
|
||
transaction is approved, the merchant is guaranteed payment whether the
|
||
card in question is good or bad. The purpose of authorization is to
|
||
shift financial liability from the acceptor to the acquirer.
|
||
|
||
There are two basic tools used - bulletins and online checks.
|
||
Bulletins may be hardcopy, or may be downloaded into a local controller
|
||
of some form. Online checks could be done via a voice call, a
|
||
standalone terminal, or software and/or hardware integrated into the
|
||
cash register.
|
||
|
||
A low-volume, high-ticket application (a jewelry store) would probably
|
||
do all its authorizations with voice calls, or may have a stand-alone
|
||
terminal. A high-volume, low-ticket application (a fast-food chain)
|
||
will probably do most of its authorizations locally against a bulletin
|
||
downloaded into the cash register controller. Applications in between
|
||
typically merge the two - things below a certain amount (the "floor
|
||
limit") are locally authorized after a lookup in the bulletin, while
|
||
things over the floor limit are authorized online.
|
||
|
||
Usually a lot of effort is taken to use the least expensive tools that
|
||
are required by the expected risk of fraud. Typically, communication
|
||
costs for authorizations make up the biggest single item in the overall
|
||
cost of providing credit cards.
|
||
|
||
Large accepters are always a special case. Airlines are usually
|
||
directly connected, host-to-host, to issuers and/or acquirers, and
|
||
authorize everything online. Likewise for many petroleum companies and
|
||
large department stores. Some large chains use different approaches at
|
||
different locations, either as a result of franchising oddities or due
|
||
to volume differences between locations. A lot of experimentation is
|
||
still going on as well - this is not a mature market.
|
||
|
||
For voice authorizations, the merchant ID, PAN, expiration date, and
|
||
purchase amount are required for an approval. Some applications also
|
||
require the name on the card, but this is not strictly necessary. For
|
||
data authorizations, the merchant ID, PAN, PIN (if collected),
|
||
expiration date, and purchase amount are required. Typically, the
|
||
"discretionary data" from track 2 is sent as well, but this is not
|
||
strictly necessary. In applications that do not transmit the PIN with
|
||
the authorization, it is the responsibility of the merchant to verify
|
||
identity. Usually, this should be done by checking the signature on
|
||
the card against the signature on the form. Merchants don't often
|
||
follow this procedure, and they take a risk in not doing so.
|
||
|
||
In most applications, the amount of the purchase is known at the time
|
||
of the authorization request. For hotels, car rentals, and some
|
||
petroleum applications, an estimated amount is used for the
|
||
authorization. After the transaction is complete (e.g. after the gas
|
||
is pumped or at check-out time), another transaction may be sent to
|
||
advise of the actual amount of the transaction. More on this later.
|
||
|
||
|
||
THE ACQUIRER
|
||
--- --------
|
||
|
||
The acquirer gathers authorization requests from accepters and returns
|
||
approvals. If the acquirer is an issuer as well, "on us" transactions
|
||
will typically be turned around locally. As before, the acquirer does
|
||
not have to forward any requests on to the actual issuer. However,
|
||
acquirers are not willing to take the financial risks associated with
|
||
generating local approvals. Thus most transactions are sent on to the
|
||
issuers (interchanged). The purpose of interchange is to shift
|
||
financial liability from the acquirer to the issuer.
|
||
|
||
Typically, an acquirer connects to many issuers, and negotiates
|
||
different business arrangements with each one of them. But the
|
||
acquirer generally provides a uniform interface to the accepter. Thus,
|
||
the interchange rules are sometimes less stringent than those imposed
|
||
on the accepter. Also, most issuers will trust acquirers to with
|
||
responsibilities they would never trust to accepters. The acquirer can
|
||
therefore perform some front-end screening on the transactions, and
|
||
turn some of them around locally without going back to the issuer.
|
||
|
||
The first screening by the acquirer would be a "sanity" test, for valid
|
||
merchant ID, valid Luhn check on PAN, expiration date not past, amount
|
||
field within reason for type of merchant, etc. After that, a floor
|
||
limit check will be done. Issuers generally give acquirers higher
|
||
floor limits than acquirers give accepters, and floor limits may vary
|
||
by type of merchant. Next, a "negative file" check would be done
|
||
against a file of known bad cards. (This is essentially the same as
|
||
the bulletin.) Then a "velocity file" check may be done. A velocity
|
||
file keeps track of card usage, and limits are often imposed on both
|
||
number of uses and total amount charged within a given time period.
|
||
Sometimes multiple time periods are used, and it can get fairly
|
||
complicated.
|
||
|
||
Transactions that pass all the checks, and are within the authority
|
||
vested in the acquirer by the issuer, are approved by the acquirer.
|
||
(Note that, under the business arrangement, financial liability still
|
||
resides with the issuer.) An "advice" transaction is sometimes sent to
|
||
the issuer (perhaps at a later time), to tell the issuer that the
|
||
transaction took place.
|
||
|
||
Transactions that "fail" one or more checks are denied by the acquirer
|
||
(if the cause was due to form, such as bad PAN) or sent to the issuer
|
||
for further checking. (Note that "failure" here can mean that it's
|
||
beyond the acquirer's authority, not necessarily that the card is bad.)
|
||
Some systems nowadays will periodically take transactions that would
|
||
otherwise be approved locally, and send them to the issuer anyway.
|
||
This serves as a check on the screening software and as a
|
||
countermeasure against fraudulent users who know the limits.
|
||
|
||
Transactions that go to the issuer are routed according to the first
|
||
six digits of the PAN, according to the ISO registry mentioned in an
|
||
earlier section. Actually, it's a bit more complicated than that,
|
||
since there can be multiple layers of acquirers, and some issuers or
|
||
acquirers will "stand in" for other issuers when there are hardware or
|
||
communication failures, but the general principal is the same at each
|
||
point.
|
||
|
||
|
||
THE ISSUER
|
||
--- ------
|
||
|
||
An issuer receiving an interchanged transaction will often perform many
|
||
of the same tests on it that the acquirer performs. Some of the tests
|
||
may be eliminated if the acquirer is trusted to do them correctly.
|
||
This is the only point where a velocity file can actually detect all
|
||
usage of a card. This is also the only point where a "positive file"
|
||
lookup against the actual account can be done, since only the issuer
|
||
has the account relationship with the cardholder. If a PIN is used in
|
||
the transaction, only the issuer can provide true PIN verification -
|
||
acquirers may be able to do only "PIN offset" checking, as described in
|
||
a previous section. This is one reason why PINs have not become
|
||
popular on credit and charge cards.
|
||
|
||
An account typically has a credit limit associated with it. An
|
||
approved authorization request usually places a "hold" against the
|
||
credit limit. If the sum of outstanding holds plus the actual
|
||
outstanding balance on the account, plus the amount of the current
|
||
transaction, is greater than the credit limit, the transaction is
|
||
(usually) denied. Often in such a case the issuer will send back a
|
||
"call me" response to the merchant. The merchant will then call the
|
||
issuer's number, and the operator may even want to talk to the
|
||
cardholder. The credit limit could be extended on the spot, or
|
||
artificially high holds (from hotels or car rental companies) could be
|
||
overlooked so that the transaction can be approved.
|
||
|
||
The difference between the credit limit and the sum of holds and
|
||
outstanding balance is often referred to as the "open to buy" amount.
|
||
Once a hold is placed on an account, it is kept there until the actual
|
||
the transaction in question is settled (see below), in which case the
|
||
amount goes from a hold to a billed amount, with no impact on the open
|
||
to buy amount, theoretically. For authorizations of an estimated
|
||
amount, the actual settled amount will be less than or equal to the
|
||
approved amount. (If not, the settlement can be denied, and the
|
||
merchant must initiate a new transaction to get the money.)
|
||
Theoretically, in such a case, the full hold is removed and the actual
|
||
amount is added to the outstanding balance, resulting in a possible
|
||
increase in the open to buy amount.
|
||
|
||
In practice, older systems were not capable of matching settlements to
|
||
authorizations, and holds were simply expired based on the time it
|
||
would take most transactions to clear. Newer systems are starting to
|
||
get more sophisticated, and can do a reasonable job of matching
|
||
authorizations for actual amounts with the settlements. Some of them
|
||
still don't match estimated amounts well, with varying effects. In
|
||
some cases, the difference between actual and estimated will remain as
|
||
a hold for some period of time. In other cases, both the authorization
|
||
and the settlement will go against the account, reducing the open to
|
||
buy by up to twice the actual amount, until the hold expires. These
|
||
problems are getting better as the software gets more sophisticated.
|
||
|
||
Some issuers are also starting to use much more sophisticated usage
|
||
checks as well. They will not only detect number of uses and amount
|
||
over time, but also types of merchandise bought, or other patterns to
|
||
buying behavior. Most of this stuff is new, and is used for fraud
|
||
prevention. I expect this to be the biggest effort in authorization
|
||
software for the next few years.
|
||
|
||
American Express does things completely differently. There are no
|
||
credit limits on AMEX cards. Instead, AMEX relies entirely on usage
|
||
patterns, payment history, and financial data about cardmembers to
|
||
determine whether or not to automatically approve a transaction. AMEX
|
||
also has a policy that a cardmember will never be denied by a machine.
|
||
Thus, if the computer determines that a transaction is too risky, the
|
||
merchant will receive a "call me" message. The operator will then get
|
||
details of the transaction from the merchant, and may talk to the
|
||
cardmember as well, if cardmember identity is in question or a large
|
||
amount is requested. To verify cardmember identity, the cardmember
|
||
will be asked about personal information from the original application,
|
||
or about recent usage history. The questions are not the same each
|
||
time. If an unusually large amount is requested, the cardmember may be
|
||
asked for additional financial data, particularly anything relating to
|
||
a change in financial status (like a new job or a promotion). People
|
||
who are paranoid about Big Brother and computer databases should not
|
||
use AMEX cards.
|
||
|
||
|
||
SETTLEMENT
|
||
----------
|
||
|
||
So far, no money has changed hands, only financial liability. The
|
||
purpose of settlement is to shift the financial liability back to the
|
||
cardholder, and to shift the cardholder's money to the merchant.
|
||
Theoretically, all authorization information can be simply discarded
|
||
once an approval is received by a merchant. Of course, contested
|
||
charges, chargebacks, merchant credits, and proper processing of holds
|
||
require that the information stay around. Still, it is important to
|
||
realize that an authorization transaction has no direct financial
|
||
consequences. It only establishes who is responsible for the financial
|
||
consequences to follow.
|
||
|
||
Traditionally, a merchant would take the charge slips to the bank that
|
||
was that merchant's acquirer, and "deposit" them into the merchant
|
||
account. The acquirer would take the slips, sort them by issuer, and
|
||
send them to the issuing banks, receiving credits by wire once they
|
||
arrived and were processed. The issuer would receive the slips,
|
||
microfilm them (to save the transaction information, as required by
|
||
federal and state laws) charge them against the cardholder's accounts,
|
||
send credits by wire to the acquirer, and send out the bill to the
|
||
cardholder. Problem is, this took time. Merchants generally had to
|
||
wait a couple of weeks for the money to be available in their accounts,
|
||
and issuers often suffered from float on the billables of about 45
|
||
days.
|
||
|
||
Therefore, nowadays many issuers and acquirers are moving to on-line
|
||
settlement of transactions. This is often called "draft capture" in
|
||
the industry. There are two ways this is done - one based on the host
|
||
and one based on the terminal at the merchant's premises. In the
|
||
host-based case, the terminal generally only keeps counts and totals,
|
||
while the acquirer host keeps all the transaction details.
|
||
Periodically, the acquirer host and the terminal communicate, and
|
||
verify that they both agree on the data. In the terminal-based case,
|
||
the terminal remembers all the important transaction information, and
|
||
periodically calls the acquirer host and replays it all for several
|
||
transactions. In either case, once the settlement is complete the
|
||
merchant account is credited. The acquirer then sends the settlement
|
||
information electronically to the issuers, and is credited by wire
|
||
immediately (or nearly so). The issuer can bill directly to the
|
||
cardholder account, and float can be reduced to an average of 15 days.
|
||
|
||
The problem is, what to do with the paper? Current regulations in many
|
||
states require that it be saved, but there is no need for it to be sent
|
||
to the issuer. Also, for contested charges, a paper trail is much more
|
||
likely to stand up in court, and much better to use for fraud
|
||
investigations. Currently, the paper usually ends up back at the
|
||
issuer, as before, but it doesn't need to be processed, just
|
||
microfilmed and stored.
|
||
|
||
Much of the market still uses paper settlement methods. Online
|
||
settlement will replace virtually all of this within the next 5 to 10
|
||
years, because of its many benefits.
|
||
|
||
This was pretty long, but there is a lot of information, and I skimmed
|
||
over a lot of details. Future installments should be shorter. Coming
|
||
up next is a discussion of fraud and security, and then a special
|
||
discussion of debit cards. Hang on, we're halfway through this!
|
||
|
||
Joe Ziegler
|
||
att!lznv!ziegler
|
||
|
||
|
||
From cca.ucsf.edu!ucsfcgl!ucbvax!agate!shelby!rutgers!dptg!lznv!ziegler Fri Sep
|
||
Article 2355 of misc.consumers:
|
||
Path: wet!cca.ucsf.edu!ucsfcgl!ucbvax!agate!shelby!rutgers!dptg!lznv!ziegler
|
||
>From: ziegler@lznv.ATT.COM (J.ZIEGLER)
|
||
Newsgroups: misc.consumers
|
||
Subject: Credit Card 101, Part 4 of 6 - Fraud and Security
|
||
Keywords: credit cards, ATM, bank, security, fraud
|
||
Message-ID: <1662@lznv.ATT.COM>
|
||
Date: 28 Sep 89 21:23:44 GMT
|
||
Distribution: usa
|
||
Organization: AT&T ISL Lincroft NJ USA
|
||
Lines: 240
|
||
|
||
|
||
This is part four of a planned six-part series on the credit card
|
||
industry. It will be helpful if you have read parts one through
|
||
three, as I use a lot of terminology here that was introduced
|
||
earlier. Enjoy.
|
||
|
||
|
||
WARNING
|
||
-------
|
||
|
||
This installment describes various methods of perpetrating fraud
|
||
against credit and charge card issuers, acquirers, and cardholders.
|
||
Legal penalties for using these methods to commit fraud are severe.
|
||
The reason for sharing this information is so that consumers will be
|
||
aware of the importance of security and be aware of the procedures used
|
||
by financial institutions to protect against fraud. Neither I nor my
|
||
employer advocate use of the fraudulent methods described herein.
|
||
|
||
All the information here is publicly available from other sources.
|
||
Unnecessary detail is purposely not included, particularly as it
|
||
applies to detection and prevention of fraud.
|
||
|
||
|
||
CARDHOLDER FRAUD
|
||
---------- -----
|
||
|
||
The most common type of fraud against credit cards is cardholders
|
||
falsifying applications to get higher credit limits than they can
|
||
afford to pay, or to get multiple cards that they cannot afford to pay
|
||
off. Sometimes this is done with intent to defraud, but most often it
|
||
is done out of desperation or sheer financial ineptitude. Those who
|
||
intend to defraud generally use the multiple-card approach. They give
|
||
false names and financial data on several (sometimes as many as
|
||
hundreds) of applications. Often, the address of a vacant house that
|
||
the crook has access to is given, making it difficult to track the
|
||
crook's real identity. Once cards start showing up, the crook uses
|
||
them for cash advances or charges merchandise that is easy to sell,
|
||
like consumer electronics. The crook will run all the cards up to the
|
||
limit immediately, and will generally move on by the time the bills
|
||
start arriving. This type of fraud is not applicable to debit cards,
|
||
since they require an available account balance equal to or greater
|
||
than any purchases or withdrawals.
|
||
|
||
Protecting against this type of fraud, either intentional or otherwise,
|
||
is exactly the purpose of credit bureaus such as TRW. Issuers have
|
||
become more aware of the need for careful screening of applications,
|
||
and are using better techniques for detecting similar applications sent
|
||
to multiple issuers. More sophisticated velocity file screening can
|
||
also be used to detect possibly fraudulent usage patterns. Since this
|
||
is a method of fraud that can be used to gain really large amounts of
|
||
money, it is a high priority with issuers' security departments.
|
||
|
||
A variant of this scheme is much like check kiting. Can you use your
|
||
VISA to pay your MasterCard? Well, you might be able to manage it, but
|
||
if you're doing it with intent to defraud, you can be prosecuted.
|
||
Kiting schemes typically don't last long, have a low payoff, and are
|
||
very easy to detect.
|
||
|
||
Another type of cardholder fraud is simply contesting legitimate
|
||
charges. Most often, retrieving the documents gives pretty convincing
|
||
proof. Frequently, a family member will be found to have used the card
|
||
without the cardholder's permission. Such cases are usually pretty
|
||
easy to resolve. In the case of an ATM card, cameras are often placed
|
||
at ATMs (sometimes hidden) to record users of the machine. The camera
|
||
is usually tied to the ATM, so that a single retrieval stamp can be
|
||
placed on the film and the ATM log. If a withdrawal is contested, the
|
||
bank can then retrieve the picture of the person standing at the
|
||
machine, and conclusively tie that picture to the transaction.
|
||
|
||
A type of cardholder fraud that is endemic only to ATMs is making false
|
||
deposits. You could, theoretically, tell the ATM that you are
|
||
depositing a large amount of money, and put in an empty envelope. Most
|
||
banks will not let you withdraw amounts deposited into an ATM until the
|
||
deposit has been verified, but some will allow part of the deposit to
|
||
be withdrawn. Typically, you can't get away with much. If you have
|
||
any money actually in your account, the bank has easy, legal recourse
|
||
to seize those funds. Most banks have no sense of humor about such
|
||
things, and will remove ATM card privileges after the first offense.
|
||
|
||
|
||
THIRD-PARTY FRAUD
|
||
----------- -----
|
||
|
||
The simplest way for a third party to commit fraud is for them to get
|
||
their hands on a legitimate card. There is a large black market for
|
||
credit cards obtained from hold-ups, break-ins and muggings. Perhaps
|
||
one of the cruelest methods of getting a card is a "Good Samaritan"
|
||
scam. In such a scam, credit cards are stolen by pick-pockets,
|
||
purse-snatchers, etc. That same day, someone looks up your number in
|
||
the phone book and calls you up. "I just found your wallet. All the
|
||
money is gone, but the credit cards and your driver's license are still
|
||
here. It just happens that I'll be in your neighborhood next Wednesday
|
||
and I'll drop it off then." Since the cards are found, you don't
|
||
report them stolen, and the crooks get until next Wednesday before
|
||
you're even suspicious. If such a thing happens to you, ask if you can
|
||
come and pick the cards up immediately. A true good samaritan won't
|
||
mind, but a crook will stall you. If you can't get your hands on the
|
||
cards immediately, report them as stolen. Most issuers will be able to
|
||
get you a new card by next Wednesday, anyway.
|
||
|
||
Often stolen cards will be used for a time exactly as is. The best
|
||
tool for preventing this is verification of the signature, but this is
|
||
ineffective because most merchants don't consistently check signatures
|
||
and some people don't even sign their cards. (I guess these people
|
||
figure that all purse snatchers are accomplished forgers as well.)
|
||
Many cards will eventually be modified as the various security schemes
|
||
start catching up.
|
||
|
||
It is a very easy matter, for example, to re-encode a different number
|
||
on the magnetic stripe. Since the card still looks fine, a merchant
|
||
will accept it and run it through the POS terminal, completely ignorant
|
||
of the fact that the number read off the back is not the same as that
|
||
on the front. Although the number on the front would fail a negative
|
||
file check, the number on the back is one that hasn't been reported
|
||
yet. A card can be re-encoded almost any number of times, as long as
|
||
you can keep coming up with new valid PANs. To protect against this,
|
||
some merchants purposely avoid using the magnetic stripe. Others have
|
||
terminals that display the number read from the stripe, so the cashier
|
||
can compare it to the number on the card. Some issuers are
|
||
experimenting with special encoding schemes, to make re-encoding
|
||
difficult, but most of these schemes would require replacing the entire
|
||
embedded base of POS terminals. An interesting approach I've seen
|
||
(it's probably patented) uses a laser to burn off the parts of the
|
||
magnetic stripe where zeroes are encoded, leaving only the ones. This
|
||
severely limits the changes you can make to the card number. Some
|
||
issuers use the "discretionary data" field to encode data unique to the
|
||
card, that a crook would not be able to guess, to combat this type of
|
||
fraud.
|
||
|
||
Since an ATM doesn't have a human looking at the card, it is
|
||
especially susceptible to re-encoding fraud. A crook could get a
|
||
number from a discarded receipt and encode it on a white card blank,
|
||
which is easy to obtain legally. Many people use PINs that are easy to
|
||
guess, and the crook has an easy job of it. Most ATMs will not give
|
||
you your card back if you don't enter a correct PIN, and will only give
|
||
you a few tries to get it right, to prevent this type of fraud.
|
||
Velocity file checks are also important in detecting this. You should
|
||
always take your ATM receipts with you, pick a non-obvious PIN, and
|
||
make sure that nobody sees you enter it.
|
||
|
||
One place that a crook can get valid PANs to encode on credit cards is
|
||
from dumpsters outside of stores and restaurants. The credit slip
|
||
typically is a multipart form, with one copy for you, one for the
|
||
merchant, and one for the issuer (ultimately). If carbon paper is
|
||
used, and the carbons are discarded intact, it's pretty easy to read
|
||
the numbers off of them. Carbonless paper and forms that either rip
|
||
the carbons in half or attach them to the cardholder copy automatically
|
||
are used to prevent this.
|
||
|
||
There are a lot of scams for getting people to tell their credit card
|
||
numbers over the phone. Never give your card number to anyone unless
|
||
you are buying something from them, and make sure that it is a
|
||
legitimate business you are buying from. "Incredible deal!! Diamond
|
||
jewelry at half price!! Call now with your VISA number, and we'll rush
|
||
you your necklace!!" When you don't get the necklace for four weeks,
|
||
you might start to wonder. When you get your credit card bill, you'll
|
||
stop wondering.
|
||
|
||
There are other, more sophisticated ways to modify a credit card. If
|
||
you're skillful, you can change the embossing on the card and even the
|
||
signature on the back. For most purposes, these techniques are more
|
||
trouble than they're worth, since it's not difficult to come up with a
|
||
new stolen card, or fake ID to match the existing card.
|
||
|
||
|
||
MERCHANT FRAUD
|
||
-------- -----
|
||
|
||
There are many urban rumors of merchants imprinting a card multiple
|
||
times while the cardholder isn't looking, and then running through a
|
||
bunch of charges after the cardholder leaves. I don't know of any case
|
||
where this is an official policy of a merchant, but this is certainly
|
||
one technique a dishonest cashier could use. The cashier can then take
|
||
home a bunch of merchandise charged to your account. Although some
|
||
people are afraid of this happening in a restaurant, where a waiter
|
||
takes your card away for a while, it's actually less likely there,
|
||
since there isn't anything the waiter can charge against your card and
|
||
take home.
|
||
|
||
A merchant could also make copies of charge slips, to sell the PANs to
|
||
other crooks. (See above for use of PANs.) Most credit card
|
||
investigation departments are sensitive to this possibility, and catch
|
||
on real fast if it's happening just by looking at usage history of
|
||
cards with fraudulent charges.
|
||
|
||
A merchant is also in a position to create many false charges against
|
||
bogus numbers, to attempt to defraud the acquirer or issuer. These
|
||
schemes are usually not too effective, since acquirers generally
|
||
respond very quickly to an unusual number of fraudulent transactions by
|
||
tightening restrictions on the merchant.
|
||
|
||
|
||
ACQUIRER AND ISSUER FRAUD
|
||
-------- --- ------ -----
|
||
|
||
The place to make really big bucks in fraud is at the acquirer or
|
||
issuer, since this is where you can get access to large amounts of
|
||
money. Fortunately, it's also fairly easy to control things here with
|
||
audit procedures and dual control. People working in the back offices,
|
||
processing credit slips, bills, etc. have a big opportunity to "lose"
|
||
things, introduce false things, artificially delay things, and
|
||
temporarily divert things. Most of the control is standard banking
|
||
stuff, and has been proven effective for decades, so this isn't a big
|
||
problem. A bigger potential problem to the consumer is the possibility
|
||
of an employee at the issuer or acquirer selling PANs to crooks. This
|
||
would be very hard to track down, and could compromise a large part of
|
||
the card base. I know of no cases where this has happened.
|
||
|
||
Programmers, in particular, are very dangerous because they know where
|
||
the data is, how to get it, and what to do with it. In most shops,
|
||
development is done on completely separate facilities from the
|
||
production system. Certification and installation are done by
|
||
non-developers, and developers are not allowed any access to the
|
||
production facilities. Operations and maintenance staff are monitored
|
||
very carefully as well, since they typically have access to the entire
|
||
system as part of their jobs.
|
||
|
||
Another type of fraud that is possible here is diversion of materials,
|
||
such as printed, but not embossed or encoded, card blanks. Such
|
||
materials are typically controlled using processes similar to those
|
||
used at U.S. mints. Since most of the cards issued in the United
|
||
States are actually manufactured by only a handful of companies, it's
|
||
not too hard to keep things under control.
|
||
|
||
There are many types of fraud that can be perpetrated by tapping data
|
||
communication lines, and using protocol analyzers or computers to
|
||
intercept or introduce data. These types of fraud are not widespread,
|
||
mainly because of the need for physical access and because
|
||
sophisticated computer techniques are required. There are message
|
||
authentication, encryption, and key management techniques that are
|
||
available to combat this type of fraud, but currently these techniques
|
||
are far more costly than the minimal fraud they could prevent. About
|
||
the only such security technique that is in widespread use is
|
||
encryption of PINs.
|
||
|
||
The next episode will be devoted to debit cards, and the final episode
|
||
will talk about the networks that make all this magic happen.
|
||
|
||
Joe Ziegler
|
||
att!lznv!ziegler
|
||
|
||
|
||
/usr/staff/cc/misc [66]
|
||
<< DOS Shell >>. Type 'EXIT<11>' to return to Telix.
|
||
|
||
|
||
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|
||
|
||
Another file downloaded from: NIRVANAnet(tm)
|
||
|
||
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
|
||
Salted Slug Systems Strange 408-454-9368
|
||
Burn This Flag Zardoz 408-363-9766
|
||
realitycheck Poindexter Fortran 415-567-7043
|
||
Lies Unlimited Mick Freen 415-583-4102
|
||
Tomorrow's 0rder of Magnitude Finger_Man 408-961-9315
|
||
My Dog Bit Jesus Suzanne D'Fault 510-658-8078
|
||
|
||
Specializing in conversations, obscure information, high explosives,
|
||
arcane knowledge, political extremism, diversive sexuality,
|
||
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
|
||
|
||
Full access for first-time callers. We don't want to know who you are,
|
||
where you live, or what your phone number is. We are not Big Brother.
|
||
|
||
"Raw Data for Raw Nerves"
|
||
|
||
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|