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
BUSINESS ANALYST
FEB 13 – OCT 14
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
BUSINESS ANALYST
PROJECT: CREDIT CARDS -AUTHORIZATION & DISPUTE MANAGEMENT SYSTEM
OCT 10 – DEC 12
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
BUSINESS ANALYST
AUG 08 – SEP 10
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
BUSINESS ANALYST
E- COMMERCE CREDIT CARDS
JUN 06 – JUL 08
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 – TS1
Personal Cards – TS2
VANPIV
DEFINITIONS
----------Some
more
new
ABA
-
ANSI
Clearing
-
Embossing
card.
-
Imprinting
charge
creating
recording
-
using
Interchange
acquirer)
to
ISO
raised
data
the
-
PAN
credit,
number
-
Personal
debit
or
Personal
are
used
on
the
mechanically
and
checks.
and
on
numbers
magnetic
The
This
Number.
stripe
to
on
make
requests
from
issuer)
an
Institute
the
face
of
the
the
back
of
the
impression
one
for
Clearing
number
a
slip.
(the
approval.
Organization
House
account
number
associated
is
usually
the
same
the
A
on
host
Standards
Automated
Identification
that
Standards
information
Number.
card.
on
posting.
Association
National
International
Account
charge
this
Bankers
sending
authorization
another
(the
National
in
an
organization
processes
letters
embossed
-
NACHA
House
American
-
Encoding
card.
that
American
ACH
Automated
electronically
PIN
terms
associated
Association
with
a
as
the
card.
with
the
card,
that
is
issuer.
This
identity.
supposedly
number
know
is
only
used
to
the
cardholder
for
verification
and
of
THE
---
the
card
cardholder
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
they
go
through
are
a
formal
comment
and
officially
review
procedure
PHYSICAL
--------
before
adopted.
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
run
which
large
their
department
stores
and
supermarkets
(those
credit
authorization
through
their
cash
communicate
using
synchronous
that
take
cards)
register
controllers,
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
att!lznv!ziegler
Here's
part
3
in
my
six-part
series
on
the
part
discusses
how
authorization
and
settlement
one.
It will help if you have read parts 1 and
out
a
lot
of
overlap
to
keep
this
from
Ziegler
credit
card
industry.
This
work.
This
is
a
long
2, since I had to leave
getting
ridiculous.
Enjoy.
THE
--An
ACCEPTER
-------important
fact
to
note
is
that
a
card
accepter
does
not
have
to
get
approval
for
any
purchases
using
credit
or
charge
cards.
Of
course,
a
merchant
is
usually
interested
in
actually
getting
money,
and
so
must
participate
in
some
form
of
settlement
process
(see
below).
Usually,
the
most
acceptable
(to
a
merchant)
forms
of
settlement
are
tied
(by
the
acquirer)
to
authorization
processes.
However,
a
merchant
could
simply
accept
all
cards
without
any
validation,
any
eat
any
fraud
that
results.
A
merchant
typically
makes
a
business
arrangement
with
a
local
bank
or
some
other
acquirer
for
authorization
and
settlement
services.
The
acquirer
assigns
a
merchant
identifier
to
that
merchant,
which
will
uniquely
identify
the
location
of
the
transaction.
(This
facilitates
compliance
with
federal
regulations
requiring
that
credit
card
bills
identify
where
each
purchase
was
made.)
The
acquirer
also
establishes
procedures
for
the
merchant
to
follow.
The
procedures
will
vary
by
type
of
the
merchant
business,
geographic
location,
volume
of
transactions,
and
types
of
cards
accepted.
If
the
merchant
follows
the
procedures
given
by
the
acquirer
and
a
transaction
is
approved,
the
merchant
is
guaranteed
payment
whether
the
card
in
question
is
good
or
bad.
The
purpose
of
authorization
is
to
shift
financial
liability
from
the
acceptor
to
the
acquirer.
There
are
two
basic
tools
used
bulletins
and
online
checks.
Bulletins
may
be
hardcopy,
or
may
be
downloaded
into
a
local
controller
of
some
form.
Online
checks
could
be
done
via
a
voice
call,
a
standalone
terminal,
or
software
and/or
hardware
integrated
into
the
cash
register.
A
low-volume,
high-ticket
application
(a
jewelry
store)
would
probably
do
all
its
authorizations
with
voice
calls,
or
may
have
a
stand-alone
terminal.
A
high-volume,
low-ticket
application
(a
fast-food
chain)
will
probably
do
most
of
its
authorizations
locally
against
a
bulletin
downloaded
into
the
cash
register
controller.
Applications
in
between
typically
merge
the
two
things
below
a
certain
amount
(the
"floor
limit")
are
locally
authorized
after
a
lookup
in
the
bulletin,
while
things
over
the
floor
limit
are
authorized
online.
Usually
a
lot
of
effort
is
taken
to
are
required
by
the
expected
risk
costs
for
authorizations
make
up
the
cost
of
providing
use
the
least
expensive
tools
that
of
fraud.
Typically,
communication
biggest
single
item
in
the
overall
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
iden-
tity.
card
this
Usually,
this
against
the
procedure,
should
be
done
signature
on
the
and
they
take
by
checking
the
form.
Merchants
a
risk
in
signature
on
the
don't
often
follow
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
against
as
a
check
fraudulent
on
the
screening
software
users
who
and
know
as
a
the
countermeasure
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
and
the
buy
by
problems
some
period
of
time.
In
other
cases,
both
the
authorization
settlement
will
go
against
the
account,
reducing
the
open
to
up
to
twice
the
actual
amount,
until
the
hold
expires.
These
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
ment
will
because
the
market
still
uses
replace
virtually
all
of
of
paper
settlement
methods.
this
within
the
next
5
its
many
Online
to
10
settleyears,
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
att!lznv!ziegler
This
is
part
four
dustry.
It
will
be
as
I
use
a
lot
Ziegler
of
a
planned
six-part
series
on
the
credit
card
inhelpful
if
you
have
read
parts
one
through
three,
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
necessary
to
information
detail
is
detection
here
is
publicly
available
from
other
sources.
Unpurposely
not
included,
particularly
as
it
applies
and
prevention
of
fraud.
CARDHOLDER
---------The
most
common
type
of
fraud
sifying
applications
to
get
higher
to
pay,
or
to
get
multiple
cards
FRAUD
----against
credit
cards
is
cardholders
falcredit
limits
than
they
can
afford
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
VISA
to
pay
your
MasterCard?
Well,
you
might
be
able
to
if
you're
doing
it
with
intent
to
defraud,
you
can
be
ing
schemes
typically
don't
last
long,
have
a
low
payoff,
easy
to
you
use
your
manage
it,
but
prosecuted.
Kitand
are
very
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
----------The
simplest
way
for
a
third
their
hands
on
a
legitimate
credit
cards
obtained
from
one
of
the
cruelest
methods
scam.
In
such
a
scam,
FRAUD
----party
to
commit
fraud
is
for
them
to
get
card.
There
is
a
large
black
market
for
hold-ups,
break-ins
and
muggings.
Perhaps
of
getting
a
card
is
a
"Good
Samaritan"
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
bogus
numbers,
to
attempt
schemes
are
usually
not
spond
very
quickly
to
an
tightening
restrictions
ACQUIRER
--------
AND
---
position
to
create
many
false
to
defraud
the
acquirer
or
too
effective,
since
acquirers
unusual
number
of
fraudulent
on
the
ISSUER
------
charges
against
issuer.
These
generally
retransactions
by
merchant.
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
will
next
talk
Joe
att!lznv!ziegler
Part
EVOLUTION
---------
episode
about
will
the
be
devoted
networks
to
that
debit
cards,
make
all
and
the
final
this
magic
episode
happen.
Ziegler
5
OF
--
Debit
DEBIT
-----
Cards
CARDS
-----
The
debit
card
originated
as
a
method
for
bank
customers
to
have
access
to
their
funds
through
Automatic
Teller
Machines
(ATMs).
This
was
seen
as
a
way
for
banks
to
automate
their
branches
and
save
money,
as
well
as
a
benefit
for
customers.
A
secondary
intent
was
for
the
card
to
be
used
as
a
method
of
identification
when
dealing
with
a
human
teller.
Although
that
idea
never
really
caught
on,
it
has
seen
renewed
interest
from
time
to
time.
One
problem
with
using
cards
to
access
bank
accounts
is
that
federal
regulations
required
a
signature
be
used
for
each
withdrawal
transaction.
After
much
debate,
the
concept
of
a
Personal
Identification
Number
(PIN)
was
invented,
and
federal
regulations
were
modified
to
allow
PINs
for
use
in
place
of
signatures
with
bank
withdrawals.
ATMs
also
faced
many
other
regulatory
difficulties.
In
many
states,
for
example,
there
are
limitations
on
the
number
of
branches
a
bank
can
have.
In
a
conflict
that
only
a
lawyer
could
conceive
of,
a
ruling
was
required
about
whether
an
ATM
constitutes
a
bank
branch
or
not.
Since
such
rulings
were
made
on
a
state
by
state
basis,
it
varies
across
the
country.
This
results
in
some
very
odd
arrangements
in
some
states,
because
of
requirements
placed
on
bank
branches.
In
early
attempts,
the
card
actually
carried
account
information
and
balances.
The
cardholder
would
bring
the
card
into
a
branch,
and
bank
personnel
would
"load"
money
onto
the
card,
based
on
the
customer's
actual
account
balance.
The
cardholder
could
then
use
the
card
at
a
stand-alone
machine
that
would
update
the
information
on
the
card
as
money
was
withdrawn.
The
information
was
stored
on
track
3
of
the
magnetic
stripe,
as
mentioned
in
an
earlier
installment.
This
approach
had
many
problems.
It
was
far
too
susceptible
to
fraud,
it
could
not
reasonably
handle
multiple
accounts,
and
it
could
not
be
used
as
a
vehicle
for
other
services.
Since
it
was
pretty
much
limited
to
withdrawals,
it
didn't
even
automate
much
of
the
bank
branch
functions.
The
online
ATM
offered
a
solution
to
the
problems
of
the
early
ATM
cards.
Since
the
ATM
was
connected
to
the
bank's
host,
it
was
no
longer
necessary
to
maintain
account
balances
on
the
card
itself,
which
removed
a
major
source
of
fraud.
Also,
access
to
multiple
accounts
became
possible,
as
did
additional
services,
such
as
bill
payment.
Once
banks
started
buying
and
installing
ATMs,
they
quickly
realized
that
it
is
very
expensive
to
maintain
a
large
number
of
machines.
Yet
customers
began
demanding
more
machines,
so
they
could
have
easier
access
to
their
funds.
Since
many
banks
in
an
area
would
have
ATMs,
the
obvious
solution
was
to
somehow
cross-connect
bank
hosts
so
that
customers
could
use
ATMs
at
other
banks,
for
convenience.
The
lawyers
struck
again.
Does
a
shared
ATM
count
as
a
branch
for
both
banks?
Does
a
transaction
at
a
shared
ATM
mean
that
one
bank
is
doing
financial
transactions
for
another,
which
is
not
allowed?
If
two
banks
share
ATMs,
but
refuse
to
allow
a
third
bank,
is
that
monopolizing
or
restraint
of
trade?
Strange
restrictions
on
shared
ATM
transactions
resulted.
Soon
interchange
standards
began
to
evolve,
and
ATM
networks
became
a
competitive
tool.
Regional
and
national
networks
started
to
emerge.
And
the
lawyers
struck
again.
If
a
network
allows
transactions
in
one
state
for
a
bank
in
another
state,
isn't
that
interstate
banking,
which
was
at
the
time
forbidden?
Should
an
ATM
network
that
dominates
a
region
become
a
regulated
monopoly?
Should
an
ATM
network
that
gets
really
big
be
considered
a
public
utility?
Today,
the
regional
and
national
networks
continue
to
more
services
and
more
interconnections.
All
of
the
have
not
been
resolved,
and
this
is
creating
a
lot
of
ing
banking
grow
and
offer
regulatory
issues
tension
for
easrestrictions.
An ATM card is just an ATM card, regardless of how many
ATMs it works
in. Most banks long ago saw an opportunity for the ATM card to be used
as
a
debit
card,
presumably
to
replace
checks.
A
tremendous
number
of
checks are used
each year, and it costs banks a lot of money to process
them.
Debit
card
transactions
could
cost
less
to
process,
given
an
appropriate
infrastructure.
Some
of
the
costs
could
potentially
be
passed
on
to
the
merchants
or
the
consumers,
who
are
notoriously
reluctant
to
directly
pay
the
cost
of
checks.
So
far
there
have
been
many
trials
of
using
ATM
cards
as
debit
cards
at
the
point
of
sale,
but
they
have,
in
general,
met
with
consumer
apathy.
In
some
areas,
where
banks
have
aggressively
promoted
debit,
things
have
gone
better.
Still,
general
acceptance
of
debit
seems
a
ways
off.
One
interesting
twist
to
the
debit
card
story,
as
mentioned
earlier,
is
the
emergence
of
third
party
debit
cards.
Issuers
of
these
cards
have
no
real
account
relationship
with
the
cardholders.
Instead,
they
obtain
permission
from
the
cardholders
to
debit
their
checking
accounts
directly
through
the
Automated
Clearing
Houses
(ACHs),
the
same
way
checks
are
cleared.
(Think
of
it
as
direct
deposit,
in
reverse.)
Oil
companies
first
started
experimenting
with
this
a
couple
of
years
ago,
and
it
has
met
with
surprising
success.
Banks
dislike
this
concept,
because
it
competes
directly
with
their
debit
cards,
but
isn't
subject
to
the
same
state
and
federal
regulations.
ACHs
like
this,
because
it
bolsters
their
business,
which
otherwise
stands
to
lose
a
lot
by
acceptance
of
debit
cards.
Merchants
generally
like
this,
especially
the
large
retailers,
because
it
allows
them
to
get
their
payment
systems
out
from
under
the
control
of
the
banks.
THE
---
ATM
---
An
ATM
is
an
interesting
combination
of
computer,
communication,
banking,
and
security
technology
all
in
one
box.
A
typical
machine
has
a
microprocessor,
usually
along
the
lines
of
an
8086,
a
communications
module
(which
may
have
it's
own
microprocessor),
a
security
module
(also
with
a
microprocessor),
and
special-purpose
controllers
for
the
hardware.
The
user
interface
is
typically
a
CRT,
a
telephone-style
keypad,
and
some
soft
function
keys.
Typically
there
is
a
lot
of
memory,
but
no
disk.
The
screens
and
program
are
usually
downloaded
from
the
host
at
initialization,
and
are
stored
in
battery-backed
RAM
indefinitely.
The
machine
typically
interacts
with
the
host
for
every
transaction,
but
it
can
operate
offline
if
necessary,
as
dictated
by
the
downloaded
program.
The
downloaded
program
is
often
in
an
industry-standard
"states
and
screens"
format
that
was
created
by
Diebold,
a
manufacturer
of
various
banking
equipment,
including
ATMs.
Most
machines
can
use
a
few
IBM
protocols
(bisync,
SNA,
and
an
outmoded
but
still
used
"loop"
protocol),
Burroughs
poll/select,
and
perhaps
some
others,
depending
on
which
communications
module
is
in
place.
This
allows
the
manufacturer
to
make
a
standard
machine,
and
plug
in
different
communications
hardware
to
suit
the
customer.
The
IBM
bisync
and
SNA
protocols
are
most
common,
with
most
networks
moving
toward
SNA.
The
security
modules
do
all
encryption
for
the
ATM.
They
are
separate
devices
that
are
physically
sealed
and
cannot
be
opened
or
tapped
without
destroying
the
data
within
them.
In
a
truly
secure
application,
no
sensitive
data
entering
or
leaving
the
security
module
is
in
cleartext.
Arranging
this
and
maintaining
it
is
more
complicated
than
I
can
go
into
here.
Most
ATMs
contain
"capture"
bin
for
printer,
and
envelope
dispensers,
and
two
bill
dispensers,
a
"divert"
bin
for
bills,
a
cards,
a
card
reader,
receipt
printer,
journal
receptacle.
Some
ATMs
have
more
than
two
bill
can
even
dispense
coins.
When
an
ATM
is
dispensing
money,
it
counts
the
appropriate
bills
out
of
the
bill
dispensers,
and
uses
a
couple
of
mechanical
and
optical
checks
to
make
sure
it
counted
correctly.
If
the
checks
fail,
it
shunts
the
bills
into
the
divert
bin
and
tries
again.
Typically,
this
is
because
two
bills
were
stuck
together.
I've
seen
ATMs
have
sensor
faults,
and
divert
the
total
contents
of
both
bill
dispensers
the
first
time
a
user
asks
for
a
withdrawal.
"Gee,
all
I
did
was
ask
for
$50,
and
this
machine
made
all
kinds
of
funny
whirring
noises
and
shut
down."
Most
banks
will
put
twenty-dollar
bills
in
one
of
the
dispensers
and
five
dollar
bills
in
the
other.
Some
use
tens
and
fives,
or
tens
and
twenties.
Depending
on
the
denominations
of
the
bills,
the
size
of
the
dispensers,
and
the
policy
of
the
bank,
an
ATM
can
hold
tens
of
thousands
of
dollars.
The
journal
printer
keeps
a
running
log
of
and
exactly
what
the
machine
is
doing,
for
ten
hear
it
printing
as
soon
as
you
put
transaction
is
every
use
of
the
machine,
audit
purposes.
you
can
ofyour
card
in
or
after
your
complete.
When
you
put
an
envelope
into
an
ATM,
the
transaction
information
is
usually
printed
directly
on
the
envelope,
so
that
verifying
the
deposit
is
easier.
Bank
policies
typically
require
that
any
deposit
envelope
be
opened
and
verified
by
two
people.
In
this,
you're
actually
safer
depositing
cash
at
an
ATM
than
giving
it
to
a
human
teller.
A
card
list,
if
away
will
the
be
diverted
to
the
user
doesn't
enter
and
forgets
capture
bin
a
correct
to
if
it
is
PIN,
or
take
on
the
if
the
the
"hot
user
On
some
machines,
the
divert
bin,
capture
bin,
envelope
receptacle,
bill
dispenser
bins
are
all
separately
locked
containers,
so
that
stocking
can
be
done
by
courier
services
who
simply
swap
bins
and
turn
the
whole
thing
to
a
central
card"
walks
card.
and
reresite.
The
entire
ATM
is
typically
housed
in
a
hardened
steel
case
with
alarm
circuitry
built
in.
These
suckers
have
been
known
to
survive
dynamite
explosions.
The
housing
typically
has
a
combination
lock
on
the
door,
and
no
single
person
knows
the
entire
combination.
The
machine
can
thus
be
opened
for
restocking,
maintenance,
or
repair,
only
if
at
least
two
people
are
present.
DEBIT
-----
CARD
----
PROCESSING
----------
Debit
card
processing
is
fairly
similar
to
credit
and
charge
card
processing,
with
a
few
exceptions.
First,
in
the
case
of
ATMs,
the
accepter
and
acquirer
are
usually
the
same.
For
debit
card
use
at
the
point
of
sale,
the
usual
acquirer-accepter
relationship
holds.
In
general,
acquirers
may
do
front-end
screening
on
debit
cards,
but
all
approvals
are
generated
by
the
issuer
the
floor
limit
is
zero.
This
makes
it
possible
to
eliminate
a
separate
settlement
process
for
debit
card
transactions,
but
places
additional
security
and
reliability
constraints
on
the
"authorization".
Often
a
separate
settlement
is
done
anyway.
One
problem
that
has
caused
difficulties
for
POS
use
of
debit
cards
is
the
use
of
PINs.
Many
merchants
and
cardholders
would
rather
use
signature
for
identity
verification.
But
most
debit
systems
grew
out
of
ATM
systems,
and
require
PINs.
This
is
an
ironic
reversal
of
the
early
ATM
card
days,
when
people
were
trying
to
avoid
requiring
signature.
Other
than
the
PIN,
the
information
required
for
a
debit
transaction
is
the
same
as
that
required
for
a
credit
transaction.
One
last
installment
on
the
networks
that
tie
this
all
together,
and
the
Credit
Card
101
course
will
be
exam
you
will
be
graded
entirely
you
are
Joe
att!lznv!ziegler
Part
complete.
There
will
be
on
classroom
participation.
failing
no
final
Most
of
miserably...
Ziegler
6
ACCESS
-----For
most
credit
card
applications,
the
the
single
biggest
factor
in
overall
half
of
the
total.
For
that
reason,
tions,
depending
on
the
provider,
constraints.
-
Networks
NETWORKS
--------
cost
of
the
access
network
is
costs,
often
accounting
for
over
there
are
many
different
soluthe
application,
and
geographical
The
simplest
form
of
access
network
uses
800
service,
in
one
of
its
many
forms.
Terminals
at
merchant
locations
across
the
country
dial
an
800
number
that
is
terminated
on
a
large
hunt
group
of
modems,
connected
directly
to
the
acquirer's
front-end
processor
(FEP).
The
FEP
is
typically
a
fault-tolerant
machine,
since
an
outage
here
will
take
out
the
entire
service.
A
large
acquirer
will
typically
have
two
or
more
centers
for
terminating
the
800
service.
This
allows
better
economy,
due
to
the
nature
of
800
service
tariffs,
and
allows
for
disaster
recovery
in
case
of
a
failure
of
one
data
center.
An
advantage
of
800
service
is
that
it
is
quite
easy
to
cover
the
entire
country
with
it.
It
also
provides
the
most
effective
utilization
of
your
FEP
resources.
(A
little
queuing
theory
will
show
you
why.)
However,
800
service
is
quite
expensive.
It
always
requires
10
(or
11)
digits
dialed,
and
in
areas
with
pulse
dialing
it
can
take
almost
three
seconds
just
to
dial
1-800.
The
delay
between
dialing
and
connection
is
longer
for
800
calls
than
many
other
calls,
because
of
the
way
the
calls
get
routed.
All
of
this
adds
to
the
perceived
response
time
at
the
merchant
location,
even
though
the
acquirer
has
no
control
over
it.
Large
acquirers
prefer
to
offer
some
form
of
local
access
service.
In
this
service,
terminals
at
the
merchants
dial
a
local
telephone
number
to
gain
access
to
the
acquirer.
Typically,
the
local
number
actually
connects
to
a
packet
network,
which
then
connects
to
the
acquirer.
If
the
packet
network
is
a
public
network,
the
terminal
must
go
through
a
login
sequence
to
get
connected
across
the
packet
network.
Typically,
local
calls
are
much
less
expensive
than
800
service
calls,
and
local
calls
typically
connect
faster
than
800
calls.
The
cost
of
those
calls
are
absorbed
by
the
merchants
directly.
In
those
few
remaining
areas
where
local
calls
are
still
free
from
a
business
line,
this
works
out
well
for
the
merchant.
Otherwise,
the
merchant
can
end
up
spending
a
lot
of
money
on
phone
calls.
Usually,
the
acquirer
has
to
offer
lower
prices
to
accepters
who
use
local
calls,
to
help
offset
this.
Even
so,
these
networks
are
generally
much
less
expensive
for
the
acquirers.
Such
networks
are
difficult
to
maintain,
due
to
the
distributed
nature
of
the
access
network.
Since
most
packet
networks
are
much
more
likely
to
experience
failures
than
the
phone
network
is,
the
merchant's
POS
terminal
is
usually
programmed
to
dial
an
800
number
for
fallback
if
the
local
number
doesn't
work.
Also,
it
is
generally
not
cost-effective
to
cover
every
free
calling
area
in
the
entire
country
with
access
equipment,
so
some
800
service
is
required
anyway.
There
is
also
an
administrative
headache
associated
with
keeping
track
of
the
different
phone
numbers
that
When
you
have
tens
formidable.
each
of
merchant
thousands
across
the
of
terminals
country
needs
to
dial.
to
support,
this
can
be
Acquirers
are
beginning
to
experiment
with
Feature
Group
B
(FGB)
access.
FGB
access
was
the
method
of
access
used
to
get
to
alternative
long-distance
carriers
before
"equal
access"
was
available.
The
tariffs
are
still
on
the
books,
and
they
are
favorable
for
this
application.
FGB
access
provides
a
single
number,
nationwide,
for
all
merchants
to
dial
in
order
to
gain
access
to
the
acquirer.
The
call
has
simpler
(hence,
presumably,
faster)
routing
than
800
service,
and
the
call
is
charged
to
the
acquirer,
not
the
accepter.
FGB
access
does
have
to
terminate
on
equipment
that
is
physically
located
in
the
Local
Access
Toll
Area
(LATA)
where
the
call
originated,
so
there
is
the
problem
of
having
distributed
equipment,
as
above.
This
also
implies
that
it
is
not
cost-effective
to
deploy
FGB
access
everywhere,
as
well.
There
are
also
some
technical
oddities
of
FGB,
due
to
its
original
intent,
that
have
made
it
difficult
to
implement
so
far.
The
other
big
switched
access
capability
that
is
likely
to
have
an
impact
in
the
future
is
ISDN.
So
far,
this
has
been
inhibited
by
limited
availability
and
lack
of
adequate
equipment
on
the
merchant
end,
but
it
could
be
very
beneficial
when
these
problems
are
solved.
Private-line
networks
are
pretty
straightforward
applications
of
point-to-point
and
multipoint
private
lines.
Since
private
lines
are
quite
expensive,
engineering
of
the
networks
is
challenging.
Usually,
sophisticated
software
is
used
to
determine
the
optimum
placement
of
concentrators
in
order
to
minimize
costs.
Since
tariffs,
real
estate
prices,
and
business
needs
change
frequently,
maintaining
a
stable,
cost-effective
network
is
hard
work.
A
typical
asynchronous
private
line
network
will
have
multiplexers
at
remote
sites,
with
backbone
links
to
companion
multiplexers
at
a
central
site.
Synchronous
private
line
networks
may
use
multiplexers,
or
remote
controllers,
or
remote
FEPs,
depending
on
the
application
and
the
availability
of
real
estate.
INTERCHANGE
-----------
NETWORKS
--------
Interchange
networks
physically
consist
mostly
of
point-to-point
private
lines.
In
many
of
the
large
interchange
networks,
there
is
a
central
"switch"
that
takes
transactions
from
acquirers
(thereby
acting
as
an
issuer),
and
routes
them
to
issuers
(thereby
acting
as
an
acquirer).
Often
the
switch
provider
will
actually
be
an
acquirer
or
issuer
as
well,
but
this
is
not
always
the
case.
Usually,
the
provider
of
the
switch
defines
standard
message
formats,
protocols,
and
interchange
rules.
These
formats
and
protocols
usually
comply
with
national
and
international
standards,
but
sometimes
do
not.
Often
the
switch
will
provide
translation
between
different
message
formats
and
protocols.
The
switch
provider
is
generally
very
concerned
that
settlement
complete
successfully.
Failure
to
settle
with
one
or
more
large
issuers
can
leave
the
switch
provider
with
an
overnight
deficit
of
a
couple
million
dollars.
Even
though
this
is
a
temporary
situation,
it
has
significant
financial
impact.
In
some
completely
current
separate
networks,
facilities,
authorization
and
with
separate
settlement
hosts
in
take
place
on
some
cases.
This
is
mainly
due
to
the
history
of
the
industry
in
this
country.
Recall
that
authorizations
were
originally
done
by
voice
calls,
and
settlement
was
done
by
moving
paper
around.
These
two
processes
were
automated
at
different
times,
by
separate
means.
Thus
VISA
has
a
BASE
1
network
for
authorization,
and
a
BASE
2
network
for
settlement.
Likewise,
MasterCard
has
INET
and
INES,
one
for
authorization
and
one
for
settlement.
These
functions
are
becoming
less
and
less
separated
as
communication
and
computer
facilities
evolve,
and
will
probably
be
completely
integrated
over
the
next
five
to
ten
years.
Interchange
networks
are
probably
the
most
volatile
part
of
the
ATM
market
right
now.
There
is
currently
a
shakeout
going
on
in
much
of
the
market,
with
larger,
more
aggressive
regionals
buying
out
standalone
networks
and
smaller
regionals.
This
causes
local
banks
to
change
local
and
national
network
affiliation
from
time
to
time.
So
a
card
may
work
in
a
given
ATM
one
day,
but
fail
in
that
machine
the
next,
which
confuses
many
consumers.
Most
large
regional
and
national
networks
have
operating
regulations
requiring
labeling
of
ATMs
and
cards, so that if you see the same logo on your card and the ATM, you
can
be
pretty
sure
it
will
work.
Some
regionals
are
interconnected,
and
others
are
not.
The
two
biggest
nationals,
Cirrus
and
Plus,
have
operating
regulations
that
effectively
prohibit
a
member
of
one
network
from
connecting
to
the
other.
But
a
regional
on
Cirrus
could
be
connected
to
a
regional
on
Plus.
In
that
case,
whether
a
machine
will
take
your
ATM
card
depends
on
the
routing
algorithm
used.
In
most
cases,
the
acquirer
will
have
a
table
of
issuers
that
are
directly
connected,
and
will
send
anything
else
to
the
regional
switch.
The
regional
switch
will
have
a
table
of
each
issuer
it
is
directly
connected
to,
and
tables
of
which
cards
are
acceptable
to
other
regionals
it
interchanges
with.
Anything
else
goes
to
the
national
switch.
The
same
process
happens
in
reverse
from
there.
Often
the
order
of
search
in
the
routing
tables
is
determined
by
fee
scales,
not
geography,
so
transactions
can
be
routed
in
completely
non-obvious
ways.
So
the easiest
way
to tell
if
your card
will
work
in
a given
ATM
is
to
stick
the
card
in
and
try.
I
don't
know
of
any
machine
that
will
eat
a
card
just
because
it
can't
route
the
transaction
it
will
generally
give
some
non-specific
message
about
being
unable
to
complete
the
transaction
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't
sure
what
the
fee
is
going
to
be
if
your
bank
passes
those
fees
on
to
you.
Sometimes
the
fee
will
be
printed
on
the
receipt,
but
usually
it
isn't.
If
you
do
the
transaction
in
a
foreign
country,
you
may
not
know
the
exchange
rate
used.
(I
once
couldn't
balance
my
checkbook
for
a
month
until
I
got
a
statement
with
the
transaction
I
did
at
Banc
du
Canada
in
Montreal.)
But
if
you
need
the
money
and
are
willing
to
pay
the
fee,
you
have
little
to
lose
by
trying
out
just
about
any
ATM.
This
completes
the
course
enjoyable and informative.
in
Credit
Card
101.
Hope
you
all
found
it