ABRAHAM

SUMMARY:

8 years of experience as Business Analyst in Online banking and Financial Services with expertise in E-Commerce and solid understanding of Business Requirement gathering, Business Process flow, Business Process Modeling

Well versed in Software Development Life Cycle (SDLC) management models namely, Rational Unifies Process (RUP), Waterfall, Joint and Rapid Application Development (JAD/RAD), Prototype based, and agile models.

Experience in business Software requirement analysis, Process modeling, Process flow and Quality assurance skills using different methodologies

In depth strong working knowledge of the Software Development Life Cycle (SDLC) phases such as Planning, Analysis/Design, Development, and Testing for the software/system development process.

Experienced in gathering requirements, creating Use-Case design and analysis and specifications, Scenarios, Workflow diagrams, process flows and technical documentation, using Unified Modeling Language (UML), MS Office Suite, and Rational Suite.

Proficient on designing and implementing basic SQL queries for QA testing and report using SQL Server In-depth knowledge of Commercial Card Processing systems and Total System (TSYS) Experience in dealing with different data sources ranging from Flat files, SQL server, MS Access and Excel Extensive experience in creating and maintaining source to target data mapping documents Experience in Relational Data Modeling with very good focus on creating ER Diagrams. Performed Gap Analysis Experience in Project tracking, management, and reporting using MS Project and in doing presentations and

recommendations to plant heads and corporate management. Developed/executed test scenarios, Test Cases, Test Plans and use cases to support the development team and

business groups.  Testing along with issue/bug tracking, in addition to maintaining Test Matrix and Requirements Traceability Matrix (RTM).

Strong documentation and analytical skills, strong problem-solving skills. Organized, goal-oriented, self-starter, and ability to master new technologies, manage multiple tasks while

following through from start to completion with limited supervision.

PROFESSIONAL EXPERIENCE:

PNC BANK, PITTSBURGH, PA FEB 13 – OCT 14 BUSINESS ANALYST

PNC Bank is one of the largest providers of financial transaction processing services. It was the core credit card and billing application project. The aim of the project was to implement a centralized billing system that maximizes automation. The system performs all the functions of credit card processes such as Approval, Marketing, Payment, Getting Credit Bureau Report and Transaction Summary.

Responsibilities:

Worked with Project manager to identify best approach for gathering requirements Performed Reviews and Audits for various processes Gathered Business Requirements, created Functional Requirements Document (FRD) and analyzed

data/workflows, defined the scope, financial projections and cost/benefit analysis; progressed from Problem Statement to well-documented designs. Prepared user guidelines for easy access of the application.

Used RUP-iterative process to Conduct Data Analysis to find missing data fields in the application and customize them and extensively used Rational Requisite Pro.

Designed and developed Use Cases, Activity Diagrams, Sequence Diagrams, OOD using UML and Business Process Modelling.

Used MS Word & Visio to document data flow of the AS IS process and TO BE process. Conducted JAD sessions to get SME’s input on how to implement the application for Group Disability Claims. Defined the processed to load data from source database to target database Retrieved Data using SQL queries and did Data Mapping and Data analysis. Gathered Business requirements for Integration points and mapped them with Functional requirements.

Extensively used MS Excel during the course of the project. Worked as an Interface between the users and the different teams involved in the application development for better

understanding of the business and IT processes.

Analyzed Business Requirements from Black Box testing perspective; reviewed Test Strategy, Traceability Matrices and Test Plans to ensure that test cases reflect user needs for the functional, performance, usability and security requirements.

Created sample Wire frames to make system better understood by Business and technology teams. Performed GAP analysis to identify the gap between the optimized allocation and integration of the inputs, and the

current level of allocation. Created AS-IS and TO-BE business process flow diagrams, Integrate process flow diagrams to show end-to-end

business model and business process mapping exercise including swim lanes. Performed Data Analysis and Data validation by writing basic queries against the database. Followed the UML based methods by using Visio to create Use Cases, Activity Diagrams, Sequence Diagrams, and

Collaboration Diagrams. Identified Test Harnesses, which assisted QA effort in reducing the redundancy of Automation Scripts and made them

more reusable. Experience in the documentation of system and business requirements and specifications, design and development of

use and test-case scenarios and root-cause analysis, GAP analysis, developing test plans, test scripts using SQL, conducting System Integration testing (SIT), user acceptance testing (UAT), training, and implementing new processes and technology.

BANK OF AMERICA, CHARLOTTE, NC OCT 10 – DEC 12 BUSINESS ANALYSTPROJECT: CREDIT CARDS -AUTHORIZATION & DISPUTE MANAGEMENT SYSTEM

Project involved ADM services for mission critical system (runs 24x7) called Host Link (which is a point-of-sale (POS) transaction routing and capture system that routes credit card, debit card and check guarantee transactions from merchants’ POS devices to external authorizing hosts. The system captures approved transactions and creates credit card settlement and funding files for external processing.) and CADRE (which is back office exceptions processing application that integrates imaging and artificial intelligence to assist dispute analysis in resolving the disputes related to the credit / debit card transactions).

Responsibilities:

Conducted user interviews at both in-house and client locations, gathering and analysing requirements using Requisite Pro.

Extensively used Agile Methodology in the process of the project management based on SDLC. Designed and developed Use Cases, Activity Diagrams, Sequence Diagrams, Object Oriented Design (OOD) using

UML Gathered and documented Business Requirements, created Functional specifications and translated them into

Software Requirement Specifications. Performed Gap analysis by identifying existing technologies, documenting the enhancements to meet the end state

requirements. Responsible for identifying and documenting business rules and creating detailed Use Cases Handled Commercial Card Processing systems, Electronic Data System (EDS) and Total System (TSYS) Participated in the process of internal and external auditing activities and developed timelines for project delivery,

and managed projects and resources to successful completion Involved in Data Analysis & Mapping to track all data elements used in the application from the user interface

through different interfaces to the target databases in which they are stored.  Participated in creating logical and physical data models, their enhancement. Based on the data models, worked with

business architect, to create the software solution models. Designed and implemented SQL queries for QA testing and report / data validation Helped in creating of Data-Mapping best practices document including visual processes and trained team members

on Data Mapping process and tools. Worked with development and testing teams to accomplish timely release of objectives. Developed test cases and test scripts and assisted Quality Assurance activities, with system integration testing and

user acceptance testing (UAT), developing and maintaining quality procedures and ensuring that appropriate documentation is in place

COMMERCE BANK PITTSBURG, PA AUG 08 – SEP 10BUSINESS ANALYST

Commerce Bank is the principal subsidiary of Commerce Bank shares Inc., a $13.9 billion regional bank holding company. Commerce offers online services such as 24-hour online account access to credit card accounts, instant online account opening for deposit accounts, instant decisions for Aria visa, Providian (Visa and Master) credit cards and loan comparisons. Project CAS (Card Authentication Systems): 24-hour online access to repay, where customers can login and view their account information. They can make online payments, change their contact information and contact customer service representatives for questions.

Responsibilities:

Used Prototyping method to gather additional requirements from the users in order to describe the business needs in terms of the system being created.

Involved in creating business requirements document and Functional Requirements Document (FRD) and translating them to technical specifications

Developed an analysis model that includes Use Case diagrams, and Activity diagrams using UML methodologies in Rational Rose, which provided the development team a view of the requirements for design and construction phases.

Used the guidelines and artifacts of the Rational Unified Process (RUP) to strategize the Implementation of Rational Unified Process effort in different iterations and phases of the System Development Life Cycle (SDLC)

Responsible for completing weekly project status reports. Documented requirements associated change requests with requirements and connected requirements with Use

cases in Requisite Pro and created different traceability views. Business Process Modeling to understand the shortcomings of the existing system Performed and evaluated the benefits of the new system and generated workflows. Helped in creating of data-mapping best practices document including visual processes and trained team members

on data mapping process and tools Used Crystal Reports to gather data and design reports based on the database Microsoft SQL Server. Worked to create Data Mapping Documents and worked with business to write transformation rules. Actively participated in the process of data mapping and data modeling of product and benefit systems and

ensuring all data fields are functioning correctly. Designed and developed the Test plan and Test case documents. Closely worked with Users and Technical team in managing and handling User requested Changes and User

Conflicts. Developed documentation templates, specifications and schedules for technical writing deliverables. Analyzed and interpreted the technical information in order to compose User Manuals.

HUNTINGTON NATIONAL BANK, COLUMBUS, OH JUN 06 – JUL 08BUSINESS ANALYSTE- COMMERCE CREDIT CARDS

The Huntington National Bank provides innovative retail and commercial financial products and services and also offers retail and commercial financial services online. The project scope was to encompass certain additional functionality such as Payment Processing, Performance Reporting, Customer Service, Credit Bureau Report and Transaction Summary to the existing credit card system and offer convenience and ease of use to the staff and cardholders.

Responsibilities:

Responsible for gathering requirements from users, mainly Risk Professionals. Functioned as the primary liaison between the operations and the technical team and resolved process issues

throughout the project cycle. Collaborated with the marketing team in identifying the needs of the customers. Established a Business Analysis methodology around the RUP (Rational Unified Process). Facilitated numerous Joint Application Development (JAD) sessions utilized for the creation of design documents

and system specifications for applications. Developed logical and physical data models and created source to target mappings, schema crosswalks and defined

processes to load data from source database into the target data. Involved in entire Information System Portal Management and keeping the deliverables up to date.

Used MS-Visio to document current work flows, manual processes and end-to-end processing of system interactions Writing Complex SQL queries and optimizing SQL Queries. Developed and executed associated project plans and test scripts for User Acceptance Testing (UAT) and

subsequent user training. Involved in managing the project scope and designing use cases and project plans. Played a key role in the planning, testing, and implementation of system enhancements and conversions. Analyzed research on operational procedures and identified opportunities for improvement with an emphasis on

automation and efficiency.

Issuer,Acquirer,Authorisation,Clearing,Settlements

Commercial/Business Cards – TS1Personal Cards – TS2

VANPIV

DEFINITIONS-----------

Some more new terms that are used in this posting.

ABA - American Bankers Association

ACH - Automated Clearing House - an organization that mechanically andelectronically processes checks.

ANSI - American National Standards Institute

Embossing - creating raised letters and numbers on the face of thecard.

Encoding - recording data on the magnetic stripe on the back of thecard.

Imprinting - using the embossed information to make an impression on acharge slip.

Interchange - sending authorization requests from one host (theacquirer) 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 acredit, debit or charge card. This is usually the same as thenumber on the card.

PIN - Personal Identification Number. A number associated with thecard, that is supposedly know only to the cardholder and the cardissuer. This number is used for verification of cardholderidentity.

THE ORGANIZATIONS--- -------------

ISO sets standards for plastic cards and for data interchange, amongother things. ISO standards generally allow for national expansion.Typically, a national standards organization, like ANSI, will take anISO standard and develop a national standard from it. National stan-dards are generally subsets of the ISO standard, with extensions as al-lowed in the original ISO standard. Many credit card standardsoriginated in the United States, and were generalized and adopted byISO later.

The ANSI committees that deal with credit card standards are sponsoredby the ABA. Most members of these committees work for banks and otherfinancial institutions, or for vendors who supply banks and financialinstitutions. Working committees report to governing committees.

All standards go through a formal comment and review procedure beforethey are officially adopted.

PHYSICAL STANDARDS-------- ---------

ANSI X4.13, "American National Standard for Financial Services -Financial Transaction Cards" defines the size, shape, and otherphysical characteristics of credit cards. Most of it is of interestonly to mechanical engineers. It defines the location and size of themagnetic stripe, signature panel, and embossing area. This standardalso includes the Luhn formula used to generate the check digit for thePAN, and gives the first cut at identifying card type from the accountnumber. (This part was expanded later in other standards.) Also, thisstandard identifies the character sets that can be used for embossing acard.

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 inthe appendix of ANSI X4.13 itself. Almost all the cards I have useFarrington 7B, but Sears uses OCR-A. (Sears also uses the optional,smaller card size as, allowed in the standard.) These character setsare intended to be used with optical character readers (hence the OCR),and large issuers have some pretty impressive equipment to read thoseslips.

ENCODING STANDARDS-------- ---------

ANSI X4.16, "American National Standard for Financial Services - Finan-cial Transaction Cards - Magnetic Stripe Encoding" defines thephysical, chemical, and magnetic characteristics of the magnetic stripeon the card. The standard defines a minimum and maximum size for thestripe, and the location of the three defined encoding tracks. (Somecards have a fourth, proprietary track.) 

Track 1 is encoded at 210 bits per inch, and uses a 6-bit coding of a64-element character set of numerics, alphabet (one case only), andsome special characters. Track 1 can hold up to 79 characters, six ofwhich are reserved control characters. Included in these six charac-ters is a Longitudinal Redundancy Check (LRC) character, so that a cardreader can detect most read failures. Data encoded on track 1 includePAN, country code, full name, expiration date, and "discretionarydata". Discretionary data is anything the issuer wants it to be. Track 1 was originally intended for use by airlines, but many AutomaticTeller Machines (ATMs) are now using it to personalize prompts with

your name and your language of choice. Some credit authorization ap-plications are starting to use track 1 as well.

Track 2 is encoded at 75 bits per inch, and uses a 4-bit coding of theten digits. Three of the remaining characters are reserved asdelimiters, two are reserved for device control, and one is left unde-fined. In practice, the device control characters are never used, ei-ther. Track 2 can hold up to 40 characters, including an LRC. Dataencoded on track 2 include PAN, country code (optional), expirationdate, and discretionary data. In practice, the country code is hardlyever used by United States issuers. Later revisions of this standardadded a qualification code that defines the type of the card (debit,credit, etc.) and limitations on its use. AMEX includes an issue datein the discretionary data. Track 2 was originally intended for creditauthorization applications. Nowadays, most ATMs use track 2 as well.Thus, many ATM cards have a "PIN offset" encoded in the discretionarydata. The PIN offset is usually derived by running the PIN through anencryption algorithm (maybe DES, maybe proprietary) with a secret key.This allows ATMs to verify your PIN when the host is offline, generallyallowing restricted account access.

Track 3 uses the same density and coding scheme as track 1. The con-tents of track 3 are defined in ANSI X9.1, "American National Standard- Magnetic Stripe Data Content for Track 3". There is a slight contra-diction in this standard, in that it allows up to 107 characters to beencoded on track 3, while X4.16 only gives enough physical room for 105characters. Actually, there is over a quarter of an inch on each endof the card unused, so there really is room for the data. In practice,nobody ever uses that many characters, anyway. The original intent wasfor track 3 to be a read/write track (tracks 1 and 2 are intended to beread-only) for use by ATMs. It contains information needed to maintainaccount balances on the card itself. As far as I know, nobody is actu-ally using track 3 for this purpose anymore, because it is very easy todefraud.

COMMUNICATION STANDARDS------------- ---------

Formats for interchange of messages between hosts (acquirer to issuer)is defined by ANSI X9.2, which I helped define. Financial message au-thentication is described by ANSI X9.9. PIN management and security isdescribed by ANSI X9.8. There is a committee working on formats ofmessages from accepter to acquirer. ISO has re-convened the interna-tional committee on host message interchange (TC68/SC5/WG1), and ANSImay need to re-convene the X9.2 committee after the ISO committee fin-ishes. These standards are still evolving, and are less specific thanthe older standards mentioned above. This makes them somewhat lessuseful, but is a natural result of the dramatic progress in the indus-try.

ISO maintains a registry of card numbers and the issuers to which theyare assigned. Given a card that follows standards (Not all of themdo.) and the register, you can tell who issued the card based on thefirst 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 migrat-

ing toward SNA. There are exceptions, of course. Message formats usedfor ATMs vary with the manufacturer, but a message set originally de-fined 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 mostsmaller stores (i.e. not at department stores), restaurants and hotelsuse a dial-up asynchronous protocol devised by VISA. There are twogenerations of this protocol, with the second generation just beginningto get widespread acceptance.

Many petroleum applications use multipoint private lines and a polledasynchronous protocol known as TINET. This protocol was developed byTexas Instruments for a terminal of the same name, the Texas Instru-ments Network E(something) Terminal. The private lines reduce responsetime, but cost a lot more money than dial-up.

NACHA establishes standards for message interchange between ACHs, andbetween ACHs and banks, for clearing checks. This is important to thisdiscussion due to the emergence of third-party debit cards, as dis-cussed in part 1 of this series. The issuers of third-party debitcards are connecting to ACHs, using the standard messages, and clearingPOS purchases as though they were checks. This puts the third partiesat an advantage over the banks, because they can achieve the same re-sults as a bank debit card without the federal and state legal restric-tions imposed on banks.

In the next installment, I'll describe how an authorization happens, aswell as how the settlement process gets the bill to you and your moneyto the merchant. After that I'll describe various methods of fraud,and how issuers, acquirers, and accepters protect themselves. Staytuned.

Joe Ziegleratt!lznv!zieglerHere's part 3 in my six-part series on the credit card industry. Thispart discusses how authorization and settlement work. This is a longone. It will help if you have read parts 1 and 2, since I had to leaveout 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 getapproval for any purchases using credit or charge cards. Of course, amerchant is usually interested in actually getting money, and so mustparticipate in some form of settlement process (see below). Usually,the most acceptable (to a merchant) forms of settlement are tied (bythe acquirer) to authorization processes. However, a merchant couldsimply accept all cards without any validation, any eat any fraud thatresults.

A merchant typically makes a business arrangement with a local bank orsome other acquirer for authorization and settlement services. Theacquirer assigns a merchant identifier to that merchant, which willuniquely identify the location of the transaction. (This facilitatescompliance with federal regulations requiring that credit card bills

identify where each purchase was made.) The acquirer also establishesprocedures for the merchant to follow. The procedures will vary bytype of the merchant business, geographic location, volume of transac-tions, and types of cards accepted.

If the merchant follows the procedures given by the acquirer and atransaction is approved, the merchant is guaranteed payment whether thecard in question is good or bad. The purpose of authorization is toshift financial liability from the acceptor to the acquirer.

There are two basic tools used - bulletins and online checks. Bulletinsmay be hardcopy, or may be downloaded into a local controller of someform. Online checks could be done via a voice call, a standalone ter-minal, or software and/or hardware integrated into the cash register.

A low-volume, high-ticket application (a jewelry store) would probablydo all its authorizations with voice calls, or may have a stand-aloneterminal. A high-volume, low-ticket application (a fast-food chain)will probably do most of its authorizations locally against a bulletindownloaded into the cash register controller. Applications in betweentypically merge the two - things below a certain amount (the "floorlimit") are locally authorized after a lookup in the bulletin, whilethings over the floor limit are authorized online.

Usually a lot of effort is taken to use the least expensive tools thatare required by the expected risk of fraud. Typically, communicationcosts for authorizations make up the biggest single item in the overallcost of providing credit cards.

Large accepters are always a special case. Airlines are usually di-rectly connected, host-to-host, to issuers and/or acquirers, and autho-rize everything online. Likewise for many petroleum companies andlarge department stores. Some large chains use different approaches atdifferent locations, either as a result of franchising oddities or dueto volume differences between locations. A lot of experimentation isstill going on as well - this is not a mature market.

For voice authorizations, the merchant ID, PAN, expiration date, andpurchase amount are required for an approval. Some applications alsorequire the name on the card, but this is not strictly necessary. Fordata authorizations, the merchant ID, PAN, PIN (if collected), expira-tion date, and purchase amount are required. Typically, the "discre-tionary data" from track 2 is sent as well, but this is not strictlynecessary. In applications that do not transmit the PIN with the au-thorization, it is the responsibility of the merchant to verify iden-tity. Usually, this should be done by checking the signature on thecard against the signature on the form. Merchants don't often followthis procedure, and they take a risk in not doing so.

In most applications, the amount of the purchase is known at the timeof the authorization request. For hotels, car rentals, and some petro-leum applications, an estimated amount is used for the authorization. After the transaction is complete (e.g. after the gas is pumped or atcheck-out time), another transaction may be sent to advise of the ac-tual amount of the transaction. More on this later.

THE ACQUIRER--- --------

The acquirer gathers authorization requests from accepters and returns

approvals. If the acquirer is an issuer as well, "on us" transactionswill typically be turned around locally. As before, the acquirer doesnot have to forward any requests on to the actual issuer. However,acquirers are not willing to take the financial risks associated withgenerating local approvals. Thus most transactions are sent on to theissuers (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, theinterchange rules are sometimes less stringent than those imposed onthe accepter. Also, most issuers will trust acquirers to with respon-sibilities they would never trust to accepters. The acquirer cantherefore perform some front-end screening on the transactions, andturn some of them around locally without going back to the issuer.

The first screening by the acquirer would be a "sanity" test, for validmerchant ID, valid Luhn check on PAN, expiration date not past, amountfield within reason for type of merchant, etc. After that, a floorlimit check will be done. Issuers generally give acquirers higherfloor limits than acquirers give accepters, and floor limits may varyby type of merchant. Next, a "negative file" check would be doneagainst a file of known bad cards. (This is essentially the same asthe bulletin.) Then a "velocity file" check may be done. A velocityfile keeps track of card usage, and limits are often imposed on bothnumber of uses and total amount charged within a given time period.Sometimes multiple time periods are used, and it can get fairly compli-cated.

Transactions that pass all the checks, and are within the authorityvested in the acquirer by the issuer, are approved by the acquirer.(Note that, under the business arrangement, financial liability stillresides with the issuer.) An "advice" transaction is sometimes sent tothe issuer (perhaps at a later time), to tell the issuer that thetransaction 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 issuerfor 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 wouldotherwise be approved locally, and send them to the issuer anyway. Thisserves as a check on the screening software and as a countermeasureagainst fraudulent users who know the limits.

Transactions that go to the issuer are routed according to the firstsix digits of the PAN, according to the ISO registry mentioned in anearlier section. Actually, it's a bit more complicated than that,since there can be multiple layers of acquirers, and some issuers oracquirers will "stand in" for other issuers when there are hardware orcommunication failures, but the general principal is the same at eachpoint.

THE ISSUER--- ------

An issuer receiving an interchanged transaction will often perform manyof the same tests on it that the acquirer performs. Some of the testsmay be eliminated if the acquirer is trusted to do them correctly. This

is the only point where a velocity file can actually detect all usageof a card. This is also the only point where a "positive file" lookupagainst the actual account can be done, since only the issuer has theaccount relationship with the cardholder. If a PIN is used in thetransaction, only the issuer can provide true PIN verification -acquirers may be able to do only "PIN offset" checking, as described ina previous section. This is one reason why PINs have not becomepopular 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 creditlimit. If the sum of outstanding holds plus the actual outstandingbalance on the account, plus the amount of the current transaction, isgreater than the credit limit, the transaction is (usually) denied. Often in such a case the issuer will send back a "call me" response tothe merchant. The merchant will then call the issuer's number, and theoperator may even want to talk to the cardholder. The credit limitcould be extended on the spot, or artificially high holds (from hotelsor car rental companies) could be overlooked so that the transactioncan 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. Oncea hold is placed on an account, it is kept there until the actual thetransaction in question is settled (see below), in which case theamount goes from a hold to a billed amount, with no impact on the opento buy amount, theoretically. For authorizations of an estimatedamount, the actual settled amount will be less than or equal to the ap-proved amount. (If not, the settlement can be denied, and the merchantmust initiate a new transaction to get the money.) Theoretically, insuch a case, the full hold is removed and the actual amount is added tothe outstanding balance, resulting in a possible increase in the opento buy amount.

In practice, older systems were not capable of matching settlements toauthorizations, and holds were simply expired based on the time itwould take most transactions to clear. Newer systems are starting toget more sophisticated, and can do a reasonable job of matching autho-rizations for actual amounts with the settlements. Some of them stilldon't match estimated amounts well, with varying effects. In somecases, the difference between actual and estimated will remain as ahold for some period of time. In other cases, both the authorizationand the settlement will go against the account, reducing the open tobuy by up to twice the actual amount, until the hold expires. Theseproblems are getting better as the software gets more sophisticated.

Some issuers are also starting to use much more sophisticated usagechecks as well. They will not only detect number of uses and amountover time, but also types of merchandise bought, or other patterns tobuying behavior. Most of this stuff is new, and is used for fraud pre-vention. I expect this to be the biggest effort in authorization soft-ware for the next few years.

American Express does things completely differently. There are nocredit limits on AMEX cards. Instead, AMEX relies entirely on usagepatterns, payment history, and financial data about cardmembers to de-termine whether or not to automatically approve a transaction. AMEXalso has a policy that a cardmember will never be denied by a machine.Thus, if the computer determines that a transaction is too risky, themerchant will receive a "call me" message. The operator will then get

details of the transaction from the merchant, and may talk to thecardmember as well, if cardmember identity is in question or a largeamount is requested. To verify cardmember identity, the cardmemberwill be asked about personal information from the original application,or about recent usage history. The questions are not the same eachtime. If an unusually large amount is requested, the cardmember may beasked for additional financial data, particularly anything relating toa change in financial status (like a new job or a promotion). Peoplewho are paranoid about Big Brother and computer databases should notuse AMEX cards.

SETTLEMENT----------

So far, no money has changed hands, only financial liability. The pur-pose of settlement is to shift the financial liability back to thecardholder, and to shift the cardholder's money to the merchant.Theoretically, all authorization information can be simply discardedonce an approval is received by a merchant. Of course, contestedcharges, chargebacks, merchant credits, and proper processing of holdsrequire that the information stay around. Still, it is important torealize that an authorization transaction has no direct financial con-sequences. It only establishes who is responsible for the financialconsequences to follow.

Traditionally, a merchant would take the charge slips to the bank thatwas that merchant's acquirer, and "deposit" them into the merchant ac-count. The acquirer would take the slips, sort them by issuer, andsend them to the issuing banks, receiving credits by wire once they ar-rived and were processed. The issuer would receive the slips, micro-film them (to save the transaction information, as required by federaland state laws) charge them against the cardholder's accounts, sendcredits by wire to the acquirer, and send out the bill to thecardholder. Problem is, this took time. Merchants generally had towait a couple of weeks for the money to be available in their accounts,and issuers often suffered from float on the billables of about 45days.

Therefore, nowadays many issuers and acquirers are moving to on-linesettlement of transactions. This is often called "draft capture" inthe industry. There are two ways this is done - one based on the hostand one based on the terminal at the merchant's premises. In thehost-based case, the terminal generally only keeps counts and totals,while the acquirer host keeps all the transaction details. Peri-odically, the acquirer host and the terminal communicate, and verifythat they both agree on the data. In the terminal-based case, the ter-minal remembers all the important transaction information, and peri-odically calls the acquirer host and replays it all for severaltransactions. In either case, once the settlement is complete the mer-chant account is credited. The acquirer then sends the settlement in-formation electronically to the issuers, and is credited by wireimmediately (or nearly so). The issuer can bill directly to thecardholder account, and float can be reduced to an average of 15 days.

The problem is, what to do with the paper? Current regulations in manystates require that it be saved, but there is no need for it to be sentto the issuer. Also, for contested charges, a paper trail is much morelikely to stand up in court, and much better to use for fraud investi-gations. Currently, the paper usually ends up back at the issuer, asbefore, but it doesn't need to be processed, just microfilmed and

stored.

Much of the market still uses paper settlement methods. Online settle-ment will replace virtually all of this within the next 5 to 10 years,because of its many benefits.

This was pretty long, but there is a lot of information, and I skimmedover a lot of details. Future installments should be shorter. Comingup next is a discussion of fraud and security, and then a special dis-cussion of debit cards. Hang on, we're halfway through this!

Joe Ziegleratt!lznv!zieglerThis is part four of a planned six-part series on the credit card in-dustry. 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 fraudagainst credit and charge card issuers, acquirers, and cardholders. Le-gal penalties for using these methods to commit fraud are severe. Thereason for sharing this information is so that consumers will be awareof the importance of security and be aware of the procedures used byfinancial institutions to protect against fraud. Neither I nor my em-ployer advocate use of the fraudulent methods described herein.

All the information here is publicly available from other sources. Un-necessary detail is purposely not included, particularly as it appliesto detection and prevention of fraud.

CARDHOLDER FRAUD---------- -----

The most common type of fraud against credit cards is cardholders fal-sifying applications to get higher credit limits than they can affordto 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 isdone out of desperation or sheer financial ineptitude. Those who in-tend to defraud generally use the multiple-card approach. They givefalse names and financial data on several (sometimes as many as hun-dreds) of applications. Often, the address of a vacant house that thecrook has access to is given, making it difficult to track the crook'sreal identity. Once cards start showing up, the crook uses them forcash advances or charges merchandise that is easy to sell, like con-sumer electronics. The crook will run all the cards up to the limitimmediately, and will generally move on by the time the bills start ar-riving. This type of fraud is not applicable to debit cards, sincethey require an available account balance equal to or greater than anypurchases or withdrawals.

Protecting against this type of fraud, either intentional or otherwise,is exactly the purpose of credit bureaus such as TRW. Issuers have be-come more aware of the need for careful screening of applications, andare using better techniques for detecting similar applications sent tomultiple issuers. More sophisticated velocity file screening can alsobe used to detect possibly fraudulent usage patterns. Since this is amethod 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 yourVISA to pay your MasterCard? Well, you might be able to manage it, butif you're doing it with intent to defraud, you can be prosecuted. Kit-ing schemes typically don't last long, have a low payoff, and are veryeasy to detect.

Another type of cardholder fraud is simply contesting legitimatecharges. Most often, retrieving the documents gives pretty convincingproof. Frequently, a family member will be found to have used the cardwithout the cardholder's permission. Such cases are usually prettyeasy to resolve. In the case of an ATM card, cameras are often placedat ATMs (sometimes hidden) to record users of the machine. The camerais usually tied to the ATM, so that a single retrieval stamp can beplaced on the film and the ATM log. If a withdrawal is contested, thebank can then retrieve the picture of the person standing at the ma-chine, and conclusively tie that picture to the transaction.

A type of cardholder fraud that is endemic only to ATMs is making falsedeposits. You could, theoretically, tell the ATM that you are deposit-ing a large amount of money, and put in an empty envelope. Most bankswill not let you withdraw amounts deposited into an ATM until the de-posit has been verified, but some will allow part of the deposit to bewithdrawn. Typically, you can't get away with much. If you have anymoney actually in your account, the bank has easy, legal recourse toseize those funds. Most banks have no sense of humor about suchthings, 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 gettheir hands on a legitimate card. There is a large black market forcredit cards obtained from hold-ups, break-ins and muggings. Perhapsone 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 inthe phone book and calls you up. "I just found your wallet. All themoney is gone, but the credit cards and your driver's license are stillhere. It just happens that I'll be in your neighborhood next Wednesdayand I'll drop it off then." Since the cards are found, you don't re-port them stolen, and the crooks get until next Wednesday before you'reeven suspicious. If such a thing happens to you, ask if you can comeand 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 cardsimmediately, report them as stolen. Most issuers will be able to getyou a new card by next Wednesday, anyway.

Often stolen cards will be used for a time exactly as is. The besttool for preventing this is verification of the signature, but this isineffective because most merchants don't consistently check signaturesand some people don't even sign their cards. (I guess these peoplefigure that all purse snatchers are accomplished forgers as well.) Many cards will eventually be modified as the various security schemesstart catching up.

It is a very easy matter, for example, to re-encode a different numberon the magnetic stripe. Since the card still looks fine, a merchantwill accept it and run it through the POS terminal, completely ignorantof the fact that the number read off the back is not the same as thaton 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 reportedyet. A card can be re-encoded almost any number of times, as long asyou can keep coming up with new valid PANs. To protect against this,some merchants purposely avoid using the magnetic stripe. Others haveterminals that display the number read from the stripe, so the cashiercan compare it to the number on the card. Some issuers are experiment-ing with special encoding schemes, to make re-encoding difficult, butmost of these schemes would require replacing the entire embedded baseof POS terminals. An interesting approach I've seen (it's probablypatented) uses a laser to burn off the parts of the magnetic stripewhere zeroes are encoded, leaving only the ones. This severely limitsthe changes you can make to the card number. Some issuers use the"discretionary data" field to encode data unique to the card, that acrook 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 especiallysusceptible to re-encoding fraud. A crook could get a number from adiscarded receipt and encode it on a white card blank, which is easy toobtain legally. Many people use PINs that are easy to guess, and thecrook has an easy job of it. Most ATMs will not give you your cardback if you don't enter a correct PIN, and will only give you a fewtries to get it right, to prevent this type of fraud. Velocity filechecks are also important in detecting this. You should always takeyour ATM receipts with you, pick a non-obvious PIN, and make sure thatnobody sees you enter it. 

One place that a crook can get valid PANs to encode on credit cards isfrom dumpsters outside of stores and restaurants. The credit sliptypically is a multipart form, with one copy for you, one for the mer-chant, and one for the issuer (ultimately). If carbon paper is used,and the carbons are discarded intact, it's pretty easy to read the num-bers off of them. Carbonless paper and forms that either rip the car-bons in half or attach them to the cardholder copy automatically areused to prevent this.

There are a lot of scams for getting people to tell their credit cardnumbers over the phone. Never give your card number to anyone unlessyou are buying something from them, and make sure that it is a le-gitimate business you are buying from. "Incredible deal!! Diamondjewelry at half price!! Call now with your VISA number, and we'll rushyou 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'llstop wondering. 

There are other, more sophisticated ways to modify a credit card. Ifyou're skillful, you can change the embossing on the card and even thesignature on the back. For most purposes, these techniques are moretrouble than they're worth, since it's not difficult to come up with anew stolen card, or fake ID to match the existing card.

MERCHANT FRAUD-------- -----

There are many urban rumors of merchants imprinting a card multipletimes while the cardholder isn't looking, and then running through abunch of charges after the cardholder leaves. I don't know of any casewhere this is an official policy of a merchant, but this is certainlyone technique a dishonest cashier could use. The cashier can then takehome a bunch of merchandise charged to your account. Although somepeople 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 andtake home.

A merchant could also make copies of charge slips, to sell the PANs toother crooks. (See above for use of PANs.) Most credit card investi-gation departments are sensitive to this possibility, and catch on realfast if it's happening just by looking at usage history of cards withfraudulent charges.

A merchant is also in a position to create many false charges againstbogus numbers, to attempt to defraud the acquirer or issuer. Theseschemes are usually not too effective, since acquirers generally re-spond very quickly to an unusual number of fraudulent transactions bytightening restrictions on the merchant.

ACQUIRER AND ISSUER FRAUD-------- --- ------ -----

The place to make really big bucks in fraud is at the acquirer or is-suer, since this is where you can get access to large amounts of money. Fortunately, it's also fairly easy to control things here with auditprocedures and dual control. People working in the back offices, pro-cessing credit slips, bills, etc. have a big opportunity to "lose"things, introduce false things, artificially delay things, and tempo-rarily 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 em-ployee at the issuer or acquirer selling PANs to crooks. This would bevery hard to track down, and could compromise a large part of the cardbase. I know of no cases where this has happened.

Programmers, in particular, are very dangerous because they know wherethe data is, how to get it, and what to do with it. In most shops, de-velopment is done on completely separate facilities from the productionsystem. Certification and installation are done by non-developers, anddevelopers 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 theirjobs.

Another type of fraud that is possible here is diversion of materials,such as printed, but not embossed or encoded, card blanks. Such mate-rials are typically controlled using processes similar to those used atU.S. mints. Since most of the cards issued in the United States areactually manufactured by only a handful of companies, it's not too hardto keep things under control.

There are many types of fraud that can be perpetrated by tapping datacommunication lines, and using protocol analyzers or computers to in-tercept or introduce data. These types of fraud are not widespread,mainly because of the need for physical access and because sophisti-cated computer techniques are required. There are message authentica-tion, encryption, and key management techniques that are available tocombat this type of fraud, but currently these techniques are far morecostly than the minimal fraud they could prevent. About the only suchsecurity technique that is in widespread use is encryption of PINs.

The next episode will be devoted to debit cards, and the final episodewill talk about the networks that make all this magic happen.

Joe Ziegleratt!lznv!zieglerPart 5 - Debit Cards

EVOLUTION OF DEBIT CARDS--------- -- ----- -----

The debit card originated as a method for bank customers to have accessto their funds through Automatic Teller Machines (ATMs). This was seenas a way for banks to automate their branches and save money, as wellas a benefit for customers. A secondary intent was for the card to beused as a method of identification when dealing with a human teller. Although that idea never really caught on, it has seen renewed interestfrom time to time. 

One problem with using cards to access bank accounts is that federalregulations required a signature be used for each withdrawal transac-tion. After much debate, the concept of a Personal Identification Num-ber (PIN) was invented, and federal regulations were modified to allowPINs for use in place of signatures with bank withdrawals. ATMs alsofaced many other regulatory difficulties. In many states, for example,there are limitations on the number of branches a bank can have. In aconflict that only a lawyer could conceive of, a ruling was requiredabout whether an ATM constitutes a bank branch or not. Since such rul-ings were made on a state by state basis, it varies across the country. This results in some very odd arrangements in some states, because ofrequirements placed on bank branches. 

In early attempts, the card actually carried account information andbalances. The cardholder would bring the card into a branch, and bankpersonnel would "load" money onto the card, based on the customer's ac-tual account balance. The cardholder could then use the card at astand-alone machine that would update the information on the card asmoney was withdrawn. The information was stored on track 3 of the mag-netic stripe, as mentioned in an earlier installment. This approachhad many problems. It was far too susceptible to fraud, it could notreasonably handle multiple accounts, and it could not be used as a ve-hicle for other services. Since it was pretty much limited to with-drawals, it didn't even automate much of the bank branch functions. 

The online ATM offered a solution to the problems of the early ATMcards. Since the ATM was connected to the bank's host, it was nolonger necessary to maintain account balances on the card itself, whichremoved a major source of fraud. Also, access to multiple accounts be-came possible, as did additional services, such as bill payment.

Once banks started buying and installing ATMs, they quickly realizedthat it is very expensive to maintain a large number of machines. Yetcustomers began demanding more machines, so they could have easier ac-cess to their funds. Since many banks in an area would have ATMs, theobvious solution was to somehow cross-connect bank hosts so that cus-tomers could use ATMs at other banks, for convenience. The lawyersstruck again. Does a shared ATM count as a branch for both banks? Doesa transaction at a shared ATM mean that one bank is doing financialtransactions for another, which is not allowed? If two banks shareATMs, but refuse to allow a third bank, is that monopolizing or re-straint of trade? Strange restrictions on shared ATM transactions re-sulted.

Soon interchange standards began to evolve, and ATM networks became acompetitive tool. Regional and national networks started to emerge. And the lawyers struck again. If a network allows transactions in onestate for a bank in another state, isn't that interstate banking, whichwas at the time forbidden? Should an ATM network that dominates a re-gion become a regulated monopoly? Should an ATM network that gets re-ally big be considered a public utility?

Today, the regional and national networks continue to grow and offermore services and more interconnections. All of the regulatory issueshave not been resolved, and this is creating a lot of tension for eas-ing banking restrictions.

An ATM card is just an ATM card, regardless of how many ATMs it worksin. Most banks long ago saw an opportunity for the ATM card to be usedas a debit card, presumably to replace checks. A tremendous number ofchecks are used each year, and it costs banks a lot of money to processthem. Debit card transactions could cost less to process, given an ap-propriate infrastructure. Some of the costs could potentially bepassed on to the merchants or the consumers, who are notoriously reluc-tant to directly pay the cost of checks. So far there have been manytrials of using ATM cards as debit cards at the point of sale, but theyhave, in general, met with consumer apathy. In some areas, where bankshave aggressively promoted debit, things have gone better. Still, gen-eral acceptance of debit seems a ways off.

One interesting twist to the debit card story, as mentioned earlier, isthe emergence of third party debit cards. Issuers of these cards haveno real account relationship with the cardholders. Instead, they ob-tain permission from the cardholders to debit their checking accountsdirectly through the Automated Clearing Houses (ACHs), the same waychecks are cleared. (Think of it as direct deposit, in reverse.) Oilcompanies 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 subjectto the same state and federal regulations. ACHs like this, because itbolsters their business, which otherwise stands to lose a lot byacceptance of debit cards. Merchants generally like this, especiallythe large retailers, because it allows them to get their payment sys-tems out from under the control of the banks.

THE ATM --- ---

An ATM is an interesting combination of computer, communication, bank-ing, and security technology all in one box. A typical machine has amicroprocessor, usually along the lines of an 8086, a communicationsmodule (which may have it's own microprocessor), a security module(also with a microprocessor), and special-purpose controllers for thehardware. The user interface is typically a CRT, a telephone-stylekeypad, and some soft function keys. Typically there is a lot ofmemory, but no disk. The screens and program are usually downloadedfrom the host at initialization, and are stored in battery-backed RAMindefinitely. The machine typically interacts with the host for everytransaction, but it can operate offline if necessary, as dictated bythe downloaded program. The downloaded program is often in anindustry-standard "states and screens" format that was created byDiebold, 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 perhapssome others, depending on which communications module is in place. This allows the manufacturer to make a standard machine, and plug indifferent communications hardware to suit the customer. The IBM bisyncand SNA protocols are most common, with most networks moving towardSNA.

The security modules do all encryption for the ATM. They are separatedevices that are physically sealed and cannot be opened or tapped with-out destroying the data within them. In a truly secure application, nosensitive data entering or leaving the security module is in cleartext. Arranging this and maintaining it is more complicated than I can gointo here.

Most ATMs contain two bill dispensers, a "divert" bin for bills, a"capture" bin for cards, a card reader, receipt printer, journalprinter, and envelope receptacle. Some ATMs have more than two billdispensers, and can even dispense coins.

When an ATM is dispensing money, it counts the appropriate bills out ofthe bill dispensers, and uses a couple of mechanical and optical checksto make sure it counted correctly. If the checks fail, it shunts thebills into the divert bin and tries again. Typically, this is becausetwo bills were stuck together. I've seen ATMs have sensor faults, anddivert the total contents of both bill dispensers the first time a userasks for a withdrawal. "Gee, all I did was ask for $50, and this ma-chine made all kinds of funny whirring noises and shut down." Mostbanks will put twenty-dollar bills in one of the dispensers and fivedollar bills in the other. Some use tens and fives, or tens and twen-ties. Depending on the denominations of the bills, the size of thedispensers, and the policy of the bank, an ATM can hold tens of thou-sands 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 of-ten hear it printing as soon as you put your card in or after yourtransaction is complete.

When you put an envelope into an ATM, the transaction information isusually printed directly on the envelope, so that verifying the depositis easier. Bank policies typically require that any deposit envelopebe opened and verified by two people. In this, you're actually saferdepositing 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 walksaway and forgets to take the card.

On some machines, the divert bin, capture bin, envelope receptacle, andbill dispenser bins are all separately locked containers, so that re-stocking can be done by courier services who simply swap bins and re-turn the whole thing to a central site.

The entire ATM is typically housed in a hardened steel case with alarmcircuitry built in. These suckers have been known to survive dynamiteexplosions. The housing typically has a combination lock on the door,and no single person knows the entire combination. The machine canthus be opened for restocking, maintenance, or repair, only if at leasttwo people are present.

DEBIT CARD PROCESSING----- ---- ----------

Debit card processing is fairly similar to credit and charge card pro-cessing, with a few exceptions. First, in the case of ATMs, the ac-cepter and acquirer are usually the same. For debit card use at thepoint of sale, the usual acquirer-accepter relationship holds. In gen-eral, acquirers may do front-end screening on debit cards, but all ap-provals are generated by the issuer - the floor limit is zero. Thismakes it possible to eliminate a separate settlement process for debitcard transactions, but places additional security and reliability con-straints on the "authorization". Often a separate settlement is doneanyway.

One problem that has caused difficulties for POS use of debit cards isthe use of PINs. Many merchants and cardholders would rather use sig-nature for identity verification. But most debit systems grew out ofATM systems, and require PINs. This is an ironic reversal of the earlyATM card days, when people were trying to avoid requiring signature. Other than the PIN, the information required for a debit transaction isthe same as that required for a credit transaction.

One last installment on the networks that tie this all together, andthe Credit Card 101 course will be complete. There will be no finalexam - you will be graded entirely on classroom participation. Most ofyou are failing miserably...

Joe Ziegleratt!lznv!zieglerPart 6 - Networks

ACCESS NETWORKS------ --------

For most credit card applications, the cost of the access network isthe single biggest factor in overall costs, often accounting for overhalf of the total. For that reason, there are many different solu-tions, depending on the provider, the application, and geographicalconstraints.

The simplest form of access network uses 800 service, in one of itsmany forms. Terminals at merchant locations across the country dial an800 number that is terminated on a large hunt group of modems, con-nected directly to the acquirer's front-end processor (FEP). The FEPis typically a fault-tolerant machine, since an outage here will takeout the entire service. A large acquirer will typically have two ormore centers for terminating the 800 service. This allows bettereconomy, due to the nature of 800 service tariffs, and allows for di-saster recovery in case of a failure of one data center. An advantageof 800 service is that it is quite easy to cover the entire countrywith it. It also provides the most effective utilization of your FEPresources. (A little queuing theory will show you why.) However, 800service is quite expensive. It always requires 10 (or 11) digits di-aled, and in areas with pulse dialing it can take almost three secondsjust to dial 1-800. The delay between dialing and connection is longerfor 800 calls than many other calls, because of the way the calls getrouted. 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 numberto gain access to the acquirer. Typically, the local number actuallyconnects to a packet network, which then connects to the acquirer. Ifthe packet network is a public network, the terminal must go through alogin sequence to get connected across the packet network. Typically,local calls are much less expensive than 800 service calls, and localcalls typically connect faster than 800 calls. The cost of those callsare absorbed by the merchants directly. In those few remaining areaswhere local calls are still free from a business line, this works outwell for the merchant. Otherwise, the merchant can end up spending alot of money on phone calls. Usually, the acquirer has to offer lowerprices 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 natureof the access network. Since most packet networks are much more likelyto experience failures than the phone network is, the merchant's POSterminal is usually programmed to dial an 800 number for fallback ifthe local number doesn't work. Also, it is generally not cost-effec-tive to cover every free calling area in the entire country with accessequipment, so some 800 service is required anyway. There is also anadministrative headache associated with keeping track of the differentphone numbers that each merchant across the country needs to dial. When you have tens of thousands of terminals to support, this can beformidable.

Acquirers are beginning to experiment with Feature Group B (FGB) ac-cess. FGB access was the method of access used to get to alternativelong-distance carriers before "equal access" was available. Thetariffs 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 hassimpler (hence, presumably, faster) routing than 800 service, and thecall is charged to the acquirer, not the accepter. FGB access doeshave to terminate on equipment that is physically located in the LocalAccess Toll Area (LATA) where the call originated, so there is theproblem of having distributed equipment, as above. This also impliesthat 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 limitedavailability and lack of adequate equipment on the merchant end, but itcould be very beneficial when these problems are solved.

Private-line networks are pretty straightforward applications ofpoint-to-point and multipoint private lines. Since private lines arequite expensive, engineering of the networks is challenging. Usually,sophisticated software is used to determine the optimum placement ofconcentrators in order to minimize costs. Since tariffs, real estateprices, and business needs change frequently, maintaining a stable,cost-effective network is hard work. A typical asynchronous privateline network will have multiplexers at remote sites, with backbonelinks to companion multiplexers at a central site. Synchronous privateline networks may use multiplexers, or remote controllers, or remoteFEPs, depending on the application and the availability of real estate.

INTERCHANGE NETWORKS----------- --------

Interchange networks physically consist mostly of point-to-point pri-vate lines. In many of the large interchange networks, there is a cen-tral "switch" that takes transactions from acquirers (thereby acting asan issuer), and routes them to issuers (thereby acting as an acquirer). Often the switch provider will actually be an acquirer or issuer aswell, but this is not always the case. Usually, the provider of theswitch defines standard message formats, protocols, and interchangerules. These formats and protocols usually comply with national andinternational standards, but sometimes do not. Often the switch willprovide translation between different message formats and protocols. 

The switch provider is generally very concerned that settlement com-plete successfully. Failure to settle with one or more large issuerscan leave the switch provider with an overnight deficit of a couplemillion dollars. Even though this is a temporary situation, it hassignificant financial impact.

In some current networks, authorization and settlement take place oncompletely separate facilities, with separate hosts in some cases. This is mainly due to the history of the industry in this country. Re-call that authorizations were originally done by voice calls, andsettlement was done by moving paper around. These two processes wereautomated at different times, by separate means. Thus VISA has a BASE1 network for authorization, and a BASE 2 network for settlement. Likewise, MasterCard has INET and INES, one for authorization and onefor settlement. These functions are becoming less and less separatedas communication and computer facilities evolve, and will probably becompletely integrated over the next five to ten years.

Interchange networks are probably the most volatile part of the ATMmarket right now. There is currently a shakeout going on in much ofthe market, with larger, more aggressive regionals buying outstandalone networks and smaller regionals. This causes local banks tochange local and national network affiliation from time to time. So acard may work in a given ATM one day, but fail in that machine thenext, which confuses many consumers. Most large regional and nationalnetworks have operating regulations requiring labeling of ATMs andcards, so that if you see the same logo on your card and the ATM, youcan be pretty sure it will work.

Some regionals are interconnected, and others are not. The two biggestnationals, Cirrus and Plus, have operating regulations that effectivelyprohibit a member of one network from connecting to the other. But aregional on Cirrus could be connected to a regional on Plus. In thatcase, whether a machine will take your ATM card depends on the routingalgorithm used. In most cases, the acquirer will have a table of issu-ers that are directly connected, and will send anything else to the re-gional switch. The regional switch will have a table of each issuerit is directly connected to, and tables of which cards are acceptableto other regionals it interchanges with. Anything else goes to the na-tional switch. The same process happens in reverse from there. Oftenthe order of search in the routing tables is determined by fee scales,not geography, so transactions can be routed in completely non-obviousways.

So the easiest way to tell if your card will work in a given ATM is tostick the card in and try. I don't know of any machine that will eat acard just because it can't route the transaction - it will generallygive some non-specific message about being unable to complete thetransaction and spit the card back out. Of course, if the transaction

is completed from a machine that you're not sure of, you also aren'tsure what the fee is going to be if your bank passes those fees on toyou. Sometimes the fee will be printed on the receipt, but usually itisn't. If you do the transaction in a foreign country, you may notknow the exchange rate used. (I once couldn't balance my checkbook fora month until I got a statement with the transaction I did at Banc duCanada in Montreal.) But if you need the money and are willing to paythe fee, you have little to lose by trying out just about any ATM.

This completes the course in Credit Card 101. Hope you all found itenjoyable and informative.