Base24EPS TransactionProcessing

TCS
BASE24-eps Transaction
Processing
BASE24-eps
Saikat
4/17/2014
BASE24-eps Transaction Processing
Contents
Preface........................................................................................................................8
Processing..........................................................................12
Originators.....................................................................13
Authorizers.....................................................................14
Issuers and Acquirers.............................................................................................15
Hosts......................................................................................................................16
Authorization Environments....................................................................................17
Transactions and Transaction Messages................................................................19
Card-based Processors..........................................................................................20
Prefixes.........................................................................................................................
..22
What is a Prefix?....................................................................................................23
Local (On-Us) and Non-Local (Not-on-Us) Prefixes...............................................24
BASE24-eps Prefix Processing..............................................................................25
Setting Up On-Us Prefixes.....................................................................................26
Setting Up Not-On-Us Prefixes...............................................................................27
Payment Instruments, Cards, and
Accounts..............................................................28
Payment Instruments..............................................................................................29
Instrument Types...........................................................................................29
Cards......................................................................................................................30
Configuring Cards.........................................................................................30
How Cards are Identified in BASE24-eps......................................................30
Card Information Maintained by BASE24-eps...............................................31
Primary and Secondary Cards......................................................................35
Refreshing Card Information.........................................................................36
Administrative Cards..............................................................................................37
Setting Up Administrative Cards for Use with Point-of Sale Terminals..........38
Setting Up Administrative Cards for Use with ATMs......................................39
Accounts.................................................................................................................40
Associating Account with Cards....................................................................40
Identifying Accounts to BASE24-eps.............................................................41
Account Information Maintained by BASE24-eps in the Card Data Source...42
Account Information Maintained by BASE24-eps in the Positive Balance Data
Source.44
Refreshing Account Information....................................................................45
Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 3
Contents
Account Balance Information.........................................................................46
Deriving Current Account Balances Using the Account Balance Information.47
Refresh Scheduling as it Relates to Account Balances.................................49

Account Activity......................................................................................................50
Field Masking of Card and Account Information.....................................................51
Transactions
Allowed....................................................................................................52
Acquirer Transactions Allowed Profiles...................................................................53
Setting Up an Acquirer Transactions Allowed Profile.....................................53
Assigning Acquirer Transactions Allowed Profiles to Acquirer Endpoints......54
How Acquirer Transactions Allowed Profiles are Used in Processing...........55
Issuer Transactions Allowed Profiles......................................................................56
Setting up an Issuer Transactions Allowed Profile.........................................56
Assigning Issuer Transactions Allowed Profiles to Endpoints........................57
How Issuer Transactions Allowed Profiles are Used in Processing...............58
Transaction
Routing......................................................................................................60
Things to Think About Before Setting Up Transaction Routing...............................62
Destination Routing Profiles...................................................................................66
Destination Routing Profile Name and Description.............................................67
Destination Routing Profile Transaction Table.....................................................68
Destination Routing Profile General Information.................................................71
Destination Routing Profile Destination Matrix....................................................74
Typical Destination Routing Profiles.......................................................................83
Transaction Routing Worksheets............................................................................85
Tying Destination Routing Profiles to Prefixes........................................................87
Source Routing Profiles..........................................................................................88
Source Routing Profile Name and Description....................................................89
Source Routing Profile Not-on-Us Prefix Selection Tables..................................90
Using the table to Recognize a Not-on-us Prefix for Processing ..................90
Not-on-Us Prefix Search Methods.................................................................90
Selection Table Example...............................................................................93
Not-On-Us Processing Parameters...............................................................94
Tying Source Routing Profiles to Acquirers............................................................95
Prefix Routing Algorithms.......................................................................................96
Configure Prefix Routing Algorithms.............................................................96
Standard Prefix Routing Algorithms..............................................................97
Routing Codes........................................................................................................99
4 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29
Contents
Enabling and Disabling the Use of Routing Codes at the Prefix Level..........99
Defining Business Relationships and Routing Codes for Your System.......100
File Update
Routing....................................................................................................103
Defining File Update Routing for Your System......................................................109
File Update Transactions Resulting from Authorization Changes to the Card Data
Source.111
Authorization, Prescreening, and
Impacting.............................................................113
BASE24-eps Authorization Methods for On-Us Cards.........................................116
How Scripts are Identified....................................................................................118
Tying Script Sets to Routing.................................................................................121
Configuring Script Sets to Use as Routing Destinations......................................122

Monitoring Script Set Performance.......................................................................125
Enabling and Disabling Authorization Scripts.......................................................130
More About Scripts...............................................................................................131
Sequential Routing...............................................................................................133
Default Authorization............................................................................................139
Approval Codes....................................................................................................140
BASE24-eps Transaction Limits and
Usages............................................................141
Limit Profiles - Where Limits are Defined.............................................................143
Defining a Single Limit..........................................................................................144
Assigning Limit Profiles to Cards, Accounts, and Prefixes...................................149
Setting Limits for Cards and Accounts.................................................................150
Tracking Transaction Usage..................................................................................152
Viewing and Deleting Active Usages....................................................................157
What Happens to Expired Usages.......................................................................159
Cash Advance Minimums and Increments for an Account...................................160
Preauthorization
Holds...............................................................................................161
What are Preauthorization Transactions?.............................................................162
Authorization Scripts Scripting Preauthorization Hold Processing..................167
Active and Expired Preauthorization Holds..........................................................168
What Information is Stored For Each Preauthorization Hold................................170
How Preauthorization Holds Affect Processing....................................................172
Additional Optional Processing (Interac)..............................................................175
Adding, Deleting, and Modifying Preauthorization Holds from Your Authorization
Scripts.176
Adding, Viewing, Modifying, and Deleting Preauthorization Holds from the ACI
Desktop.178
Match and Hold Processing.................................................................................180
How Match and Hold Works with the Batch Authorization Process.............180
Contents
What It Takes to Identify Holds for Deletion..........................................................182
Check
Processing.......................................................................................................183
MICR Data............................................................................................................186
How MICR Data is Used in BASE24-eps Check Processing...............................188
Manipulating MICR Data......................................................................................189
Preapproved and Predeclined Checks.................................................................192
Check Limits/Usages............................................................................................196
Stop Payment
Processing..........................................................................................197
Active and Expired Stop Payments......................................................................198
Adding, Modifying, and Removing Stop Payments...............................................201
How Stop Payments Affect Processing................................................................204
Card and Prefix
Blocking............................................................................................206
Card and Prefix Block Processing........................................................................208
Adding, Viewing, Updating, and Deleting Card Blocks.........................................210
Adding, Viewing, Updating, and Deleting Prefix Blocks........................................212

German Routing and Authorization
(Regional)........................................................214
German-Specific Transaction Data.......................................................................219
Configuring German Routing and Authorization...................................................221
BLZ Mapping........................................................................................................224
Flows.................................................................................225
How BASE24-eps Components Interact Within the Integrated Server Process....226
BASE24-eps Transaction Flow Summaries..........................................................230
Internal Authorization Request/Response, Card-Initiated....................................231
Internal Authorization Request/Response With Advice........................................233
Internal Authorization Request/Response/Reversal.............................................235
Internal Authorization Request/Response, Sequential Authorization to External
Destinations.238
External Authorization Request............................................................................241
External Authorization Response.........................................................................243
External Authorization, Transaction Not Allowed by the Acquirer.........................245
External Authorization, Transaction Not Allowed by the Issuer............................246
External Authorization, Prescreen (Successful)...................................................248
External Authorization, Prescreen (Not Successful)............................................250
External Authorization, Response With Impacting...............................................252
External Authorization, Request Timeout/Stand-in...............................................254
External Authorization, Station Marked Down/Stand-in........................................256
External Authorization, Late (Approved) Response.............................................258
Contents
External Authorization, Late (Denied) Response.................................................260
Primary Transaction
Identifiers..................................................................................261
Message Type Identifiers (MTIs)...........................................................................262
Message Type Identifier (MTI) Structure.....................................................262
Message Type Indicators (MTIs) Supported by BASE24-eps.....................266
Function Codes....................................................................................................278
Function Codes Supported by BASE24-eps...............................................278
Message Reason Codes......................................................................................284
Message Reason Codes Supported by BASE24-eps.................................284
Point of Service Data............................................................................................289
Point of Service Data Supported by BASE24-eps.......................................289
Processing Codes................................................................................................296
Transaction Codes Supported by BASE24-eps...........................................296
From and To Account Types Supported by BASE24-eps............................300
Action Codes........................................................................................................301
Action Codes Supported by BASE24-eps...................................................301
Preface
The BASE24-eps Transaction Processing User Guide describes the various

features and
processing concepts associated with BASE24-eps transaction processing. It is
intended
to provide a general understanding of BASE24-eps transaction processing and to
assist
in configuring and implementing various BASE24-eps transaction processing
features.
Audience
This user guide is intended for readers seeking an understanding of BASE24-eps
transaction
processing and more specifically for those BASE24-eps business users who
handle the
configuration of transaction processing business data through the ACI Desktop
(e.g., setting
up prefixes and routing).
Prerequisites
This user guide assumes a familarity with the ACI desktop user interface.
Windows and
tabs are referenced by name throughout the manual, and menu paths are
provided for
accessing windows through the ACI desktop; however, screen shots, information
about
the ACI desktop, and procedures for basic window functions (e.g., adding,
deleting, updating
and viewing records) are generally left to the BASE24-eps online help and these
manuals:
The ACI DesktopUser Interface Manual describes how to use the ACI desktop
user
interface.
The BASE24-eps Windows Reference User Guide describes each of the BASE24eps
windows and tabs available through the ACI desktop user interface. Screen shots
of
each window and tab are provided along with information for each field on the
window
or tab.
Additionally, much of setting up BASE24-eps transaction processing involves
writing and
configuring your own authorization scripts for processing transactions.This
manual touches
on different areas where scripts fit into transaction processing, but it does not
describe
how scripts are designed or written. Because authorization scripts control a
significant
amount of processing, an understanding of the scripts you plan to use is
recommended.

Preface
Mentions are made throughout this manual to the following BASE24-eps manuals
which
provide additional information about scripting.
The BASE24-eps Scripting Manual provides detailed information on the
scripting
capability of BASE24-eps, the Script Repository window, the Script Editor,
scriptsyntax,
scriptable objects, exported operators, and writing standards.
The BASE24-eps Sample Fundamental Authorization Scripts Delivery Document
provides
information about delivered sample scripts that are designed for authorization
processing,
the naming conventions of these scripts, implementation, and scripted
authorization
methods. This manual is delivered with the BASE24-eps install.
Additional Documentation
The following manuals contain supplemental information related to transaction
processing:
The BASE24-eps Transaction Security Manual describes how to configure and
implement
BASE24-eps transaction security, including PIN encryption, PIN verification,
message
authentication, message data encryption, card verification, dynamic card
verification,
EMV card authentication, secure Internet validation, and dynamic key
management.
The manual also describes how hardware security modules are integrated into
BASE24-eps processing and the duties they can assume as a part of that
processing.
The BASE24-eps Multiple Currency Manual describes the processing and
configuration
of the BASE24-eps Multiple Currency add-on module.

The BASE24-eps EMV Support Guide provides information about configuring
BASE24-eps to process EMV (Europay, MasterCard, and Visa) cards and describes
the processing of BASE24-eps EMV transactions.
The BASE24-eps Journal User Guide provides an overview of transaction journals
and
their use in a BASE24-eps system.
The BASE24-eps Environment Management User Guide describes environment
attributes
and how to configure these attributes.
The BASE24-eps ISO 8583:1993 Host External Message Manual provides detailed
information on the layout of the external message used by ISO 8583:1993 hosts.
Software
This user guide documents standard processing for the current BASE24-eps version
as
of its publication date. Software that is not current and custom software modifications
(CSMs) may result in processing that differs from the material presented in this
manual.
Preface
Manual Summary
The following is a summary of the contents of this user guide:
BASE24-eps Transaction Processing on page 12 - provides a set of introductory
topics defining basic terms and concepts related to transaction processing.
Prefixes on page 22 - Defines and describes prefixes and how they are used in
BASE24-eps transaction processing.
Payment Instruments, Cards, and Accounts on page 28 - Defines payment
instruments, cards, and accounts and describes how they are supported by
BASE24-eps.
Information is included about how account activity and account balances are
handled.
Transactions Allowed on page 52 - Defines Transactions allowed, which is a
basic
transaction screening function that BASE24-eps provides as a part of routing and
authorization, and describes how to configure it for acquirers and issuer endpoints.
Transaction Routing on page 60 - Describes transaction routing and how it is
configured within BASE24-eps.
File Update Routing on page 103 - Describes file update routing and how it is
configured
within BASE24-eps. File update routing is a specialized form of routing--carried out
by
the File Update Router component--that enables the routing of file updates and file
update transactions in the BASE24-eps system.
Authorization, Prescreening, and Impacting on page 113 - Describes the basics
of
authorization, prescreening, and impacting, all of which are carried out by scripts.
Basic
information is provided about how scripts are used and identified for processing.
Information is also provided about sequential routing, which is a script-based form of
routing, and about default authorization.
BASE24-eps Transaction Limits and Usages on page 141 - Describes
transaction
limits and usages and how they are supported by BASE24-eps. Information is
provided
about how limits are set and how usages are tracked.
Preauthorization Holds on page 161 - Describes preauthorization holds and how
they
are used within BASE24-eps. Information is included about preauthorization
transactions
and match and hold process*sing. The latter provides the capability to introduce
batch
records of settled transactions into the BASE24-eps system for the purpose of
removing
their corresponding holds.
Check Processing on page 183 - Describes how check processing is supported
by
BASE24-eps. Information is included about MICR data handling by BASE24-eps and
how preapproved and predeclined checks can be defined to BASE24-eps.
Stop Payment Processing on page 197 - Describes how stop payment

processing is
supported by BASE24-eps.
Card and Prefix Blocking on page 206 - Describes how card and prefix blocks
are
supported by BASE24-eps.
Preface
German Routing and Authorization (Regional) on page 214 - Describes the
German
regional routing and authorization support provided by BASE24-eps for German
cards
processed through German endpoints.
BASE24-eps Transaction Flows on page 225 - Provides diagrams and step-bystep
processing descriptions of how BASE24-eps handles various types of transactions.
Primary Transaction Identifiers on page 261 - Provides reference information for
several transaction identifiers that are of primary importance to processing: Message
Type Identifiers (MTIs), function codes, message reason codes, point of service
data,
processing codes, and action codes.
Publication Identification
Two entries appear at the bottom of each page to uniquely identify this BASE24-eps
publication: the publication date (for example, Sep-2009 for September 2009) and
the
publication number (for example, ES-CS000-29 for the BASE24-eps Transaction
Processing
User Guide).
Preface
Processing
BASE24-eps provides the means by which a transaction originator can request and
receive
authorization for an action on a customer card or account from a transaction
authorizer.
The role of BASE24-eps in transaction processing includes the following:
Routing transactions from the transaction originator to the appropriate authorizer.
Participating in or carrying out authorization on behalf of the institutions for which it
processes.
Journaling all transactions for later processing and settlement.
BASE24-eps can accept transactions from a variety of sources. Likewise, it can
involve a
number of different authorizers in its processing.
BASE24-eps Transaction Originators

BASE24-eps can accept transactions for authorization from several different types of
originators.
ATM Channels
Automated teller machines (ATMs) can be directly attached to BASE24-eps, in which
case
transactions are originated by customers or service personnel at the ATM.
Communications
between the ATM and BASE24-eps are controlled by ATM Channel Manager
components.
Point-of-Sale Device Channels

Point-of-sale (POS) devices can be directly attached to BASE24-eps, in which case
transactions are originated by customers, service personnel, or retail clerks at the
point of
sale. Communications between the POS device and BASE24-eps are controlled by
Merchant Channel Manager components.
Hosts
Host computers can be set up to control ATM or POS device networks and forward
transactions to BASE24-eps. In this case, communications between these acquirer
hosts
and BASE24-eps are controlled by an ISO Host Interface component.
Interchanges
Interchanges can act as switches to forward transactions to BASE24-eps for
authorization.
In this case, communications between the interchange acquiring the transaction and
BASE24-eps are controlled by Interchange Interface components.
BASE24-eps Transaction Authorizers

BASE24-eps can route transactions to several types of authorizers.
BASE24-eps
BASE24-eps can be set up to authorize transactions in those situations where
cardholder
files are maintained on the BASE24-eps system.
Hosts
Hosts can be set up to authorize transactions in situations where cardholder files are
maintained on the host computer. In this case, BASE24-eps can pre-screen the
transactions
before sending them to the host and can also be set up to stand in and authorize
transactions for a host in situations where communications between BASE24-eps
and the
host system are down.
Interchanges
Interchanges can be used to forward transactions to other networks for authorization.
Issuers and Acquirers

Transaction originators and authorizers are generally defined by the EFT industry
terms
acquirer and issuer. An acquirer, or transaction acquirer, is the party that originates a
transaction. An issuer, or card issuer, is an institution that issues cards or owns
accounts
that can be used in EFT transactions.
Whether an entity is defined as an issuer or an acquirer depends on the perspective
from
which the transaction is viewed. Intermediary networks and processors that receive
transactions from a transaction originator and authorize them or forward them
elsewhere
for authorization can be acting on behalf of both the acquirer and the issuer.
From the acquirer point of view, intermediary networks are acting on behalf of the
issuer.
For example, a cardholder initiates a transaction at an ATM belonging to institution A.
In
this case, institution A is the transaction acquirer. Institution A sends the transaction
to an
intermediary network that, in turn, sends the transaction to institution B for
authorization.
Institution B owns the cardholders account and issued the cardholder the card;
therefore,
institution B is the true issuer. However, from the point of view of institution A, the
intermediary network is performing as an issuer on behalf of institution B since
institution
A had to send the transaction to the intermediary network before it could reach its
authorizing
destination.
From the issuer point of view, intermediary networks are acting on behalf of the
acquirer.
As in the above example, institution B views the intermediary network as an acquirer
since
the intermediary network is the entity that sent it a transaction to be authorized.
BASE24-eps can process transactions on behalf of an issuer or an acquirer,
depending
on where a transaction originates and who is to authorize the transaction. For
example,
when BASE24-eps sends a transaction to a back-end host for authorization,
BASE24-eps
represents the acquirer in the message exchange and the back-end host represents
the
issuer. On the other hand, when a transaction is sent to BASE24-eps for
authorization,
the sending host represents the acquirer and BASE24-eps represents the issuer.
Hosts
Hosts can play a prominent role in the transaction processing performed by

BASE24-eps.
A host is an external mainframe computer system with which BASE24-eps interacts,
either
online or by batched tape, to authorize transactions and/or update cardholder
records.
Although the term host generally refers to an actual computer or system of
computers, the
term also refers to the institution or organization responsible for the host computer
system
and its processing. For example, in the phrase, the host can opt to receive advice
messages, the term host actually refers to the BASE24-eps-defined institution in
control
of the host computer, rather than the computer itself.
Hosts are assigned identification numbers and are defined to BASE24-eps in the
Host
Interface Configuration data source (HISO93_INTERFACE). Each host must have a
record
in the HISO93_INTERFACE to be recognized by BASE24-eps.The
HISO93_INTERFACE
contains options that allow you to specify individual processing parameters for each
host.
Authorization Environments
Authorization environments define the general level of participation BASE24-eps is
to have
in the authorization of transactions.You need to be aware of the level of participation
you
want BASE24-eps to have when planning your routing and authorization.
Online Authorization
In an Online Authorization environment, a host performs all authorization processing
(i.e.,
the host system is the authorizer). If BASE24-eps cannot communicate with the host
(i.e.,
is unable to send transactions for processing), it declines all transaction requests in
which
the host is the destination.
Though BASE24-eps is not the authorizer, it can be configured to prescreen
transactions
in an online authorization environment. In this case, if a transaction does not meet
the
prescreening requirements, the transaction is declined, and BASE24-eps sends a
deny
response to the originator and notifies the host. If the transaction does meet
prescreen
requirements, the transaction is then forwarded to the host for authorization.
Therefore, in this environment, authorization scripts would be limited to prescreening
functions.
Offline Authorization
In Offline Authorization environments, all authorization processing is performed by
BASE24-eps; authorization requests are not forwarded to the host. As a result,
scripts will
perform more extensive processing and data checking than those scripts used in an
online
authorization environment.
In offline authorization, BASE24-eps maintains account and payment-instrument
data and
transaction journal files. As a result, data file information must be exchanged and
updated
periodically between BASE24-eps and the host.
In this environment, your authorization scripts would need to handle all aspects of
transaction authorization.
Online/Offline Authorization
In a combined Online/Offline Authorization environment, BASE24-eps can be
configured
to prescreen transactions for a host as in the online authorization environment.
However,
in this environment, BASE24-eps also stands in for the host and authorizes
transactions
when communication with the host is down. The transactions BASE24-eps
authorizes are
stored in a store-and-forward (SAF) file for forwarding to the host when
communication is
restored.
Data file information is exchanged and updated periodically as in the offline
authorization
environment.
In this environment, your authorization scripts would typically be divided between
prescreening functions to be performed prior to sending a transaction to the host,
impacting
functions to update the BASE24-eps data base once a transaction is returned from
the
host, and authorization functions to be performed should the host be offline. The
latter
functions/scripts might impose tighter restrictions given that the host is unavailable.
Transactions and Transaction Messages

From a processing standpoint, transactions are actually carried out through one or
more
transaction messages. Messages are the means by which information is exchanged
between parties, typically in a request/response interaction where one party requests
an
action and the other either says yes or no or offers an alternative. In some cases,
there
may be additional messages. In some cases, one party may have taken an action
and
may simply be notifying the other party. In all cases, however, the messages used
are
based on a standard and are exchanged based on the protocols established by the
standard.
Each message carries pertinent transaction information and is built with unique
characteristics that allow transaction processors to identify the intended purpose of
the
message and the specific actions or services to be performed related to the
message.
From a BASE24-eps perspective, each transaction message can be thought of as a
discreet
request for some type of service related to a transaction.
BASE24-eps can receive messages from a variety of endpoints or channels to which
it is
connected. Endpoints can include ATM or POS devices, hosts, and interchanges.
BASE24-eps can also initiate messages as part of its processing. A transaction
message
can represent a request for an authorization or another type of action, a response
(and
possible authorization) to a previous request, or a notification that a particular action
has
taken place. In any case, the receipt of a message by BASE24-eps from a
connected
endpoint, or the creation of a specific transaction message by BASE24-eps, initiates
a
prescribed set of actions or servicesactions or services as defined by the BASE24eps
system owner.
Primary Identifiers: Message Type Identifier (MTI) and

Processing
Code
Although there are many transaction message characteristics that can and do
influence
the services provided by BASE24-eps, all messages processed by BASE24-eps are
differentiated by two primary identifiers: a Message Type Identifier (MTI) and a
processing
code. Regardless of the endpoint originating a message, all transaction messages
are
defined within BASE24-eps by a set of recognized MTIs andin almost all
casesprocessing codes (network management messages do not carry processing
codes).
Transactions to and from various endpoints (entities outside the BASE24-eps
system)
must be translated between the business rules, protocols, and processing
requirements
of the respective endpoints and the internally normalized processing values by which
BASE24-eps recognizes and processes the transactions. Message translation is one
function of the various BASE24-eps channel interfaces on behalf of ATM/POS
devices,
hosts, or interchanges.
Card-based Processors
There are three broad categories into which BASE24-eps card-based processors
typically
fall: terminal acquirers, financial switches, and card issuers. Each has its own routing
and
authorization requirements. A single BASE24-eps institution could fall into a single
category
or any combination of the three.
Terminal Acquirers
Terminal acquirers are processors that use the BASE24-eps system to drive ATM or
POS
terminal networks. These processors typically maintain an extensive terminal
database
and route transactions through interfaces to external interchanges. Terminal
acquirers
typically have little or no stand-in authorization capabilities and maintain interfaces to
multiple interchanges.
Financial Switches
Processors who use the BASE24-eps system to route acquired transactions to card
issuers
act as a financial switch. These processors do not drive terminals and are mainly
concerned
with routing transactions acquired from an interchange to a card issuer. Financial
switches
can have substantial stand-in authorization capabilities.
Card Issuers
Card issuers are processors that use the BASE24-eps system to authorize
transactions.
These processors typically maintain a substantial card database and connect to a
host.
Card issuers may or may not drive terminals.Their main concern is authorizing
transactions
acquired from an interchange. Because the account of record is maintained on a
host, the
host is the primary authorization destination. However, card issuers typically have
substantial
stand-in authorization capabilities when the host link is unavailable.
Non-Card-Based Processors
Typically, cards or card numbers are used to initiate financial transactions, and in the
interest of clarity, this is the type of processing described throughout the BASE24eps
product documentation unless specifically noted to the contrary.

Important to note, BASE24-eps is adaptable to other types of instruments. For
example,
where card-based acquirers use a card prefix obtained from the primary account
number
(PAN) of a card to determine the issuer, other types of processors might use
customized
components to determine the issuer/authorizer of a transaction. For instance, a
mobile
phone acquiring component might use an entirely different meansperhaps invoking
a
custom component to determine the issuer based on the phone number used to
initiate
the transaction.
Prefixes
Much of BASE24-eps routing and authorization processing is controlled at the prefix
level,
meaning that processing can be set up differently for different prefixes. The topics
here
describe prefixes and how they are used in BASE24-eps processing.
Prefixes
What is a Prefix?
A prefix is a numberthe first portion of a larger number, such as the primary
account
number (PAN) for a credit or debit card account. In BASE24-eps, prefixes are used
in
conjunction with the overall length of the PAN to identify the issuer of a card account.
In the following example, the indicated card number would be recognized as a match
on
the values defined for the prefix and length.
Card Number Prefix Length
5011 1234 1234 1234 5011 16 position
A card issuer can be assigned a single prefix or several. However, with the BASE24eps
system, each prefix must be unique to a card issuer. That is, no two card issuers can
be
assigned the same prefix.This uniqueness enables BASE24-eps to use the prefix to
identify
transactions that involve local issuers (institutions) defined to the system.
Also, because of their fundamental uniqueness within BASE24-eps, a significant
portion
of authorization processing is defined at the prefix level. That is, BASE24-eps
institutions
can specify different processing parameters for each of their prefixes.

Note: Cards are a typical form of financial instrument used in transactions. The term
card
is used here to mean instrument.
Prefixes
Local (On-Us) and Non-Local (Not-on-Us)

Prefixes
As part of BASE24-eps transaction processing, prefixes are defined as local (on-us)
or
non-local (not-on-us).
Note: The BASE24-eps definitions of on-us and not-on-us are different from the
strict
industry-standard definition of the terms, where an on-us transaction means the
acquirer
and issuer institutions are the same, and a not-on-us transaction means the acquirer
and
issuer institutions are different.
Local (On-Us) Prefixes

Card issuers can be local to the BASE24-eps system, which means that the issuer is
defined as a BASE24-eps institution and each prefix for which the institution issues
cards
is defined as an on-us prefix to the system as well.Transactions acquired by
BASE24-eps
on cards with on-us prefixes are referred to as on-us transactions and are typically
authorized by BASE24-eps or a back-end host.
On-us prefixes are defined to BASE24-eps using the On-Us Prefix Configuration
window
(Configure > Prefix > On-Us). The information from this window is used to populate
the
Prefix data source (Prefix).
Non-Local (Not-on-Us)
Card issuers can be non-local to the BASE24-eps system, meaning their prefixes are
not
defined as on-us prefixes. Prefixes associated with these non-local card issuers,
called
not-on-us prefixes, must still be defined to BASE24-eps in order to be be recognized
and
processed.
Not-on-us prefixes are defined to BASE24-eps using the System Prefix Configuration
window (Configure > Prefix > Not-On-Us > System Prefix). The information from
this
window is used to populate the System Prefix data source (System_Prefix).
Transactions acquired by BASE24-eps on cards with these not-on-us prefixes are
referred
to as not-on-us transactions and are typically sent to an interchange for processing.
Prefixes
BASE24-eps Prefix Processing

The initial identification of a transaction acquired by BASE24-eps is based on the
prefix of
the transaction PAN in conjunction with the PAN length.
Prefixes for acquired transactions fall into the following general categories:
On-Us Prefixes Not-On-Us Prefixes
Prefixes Recognized by Unrecognized Prefixes
Algorithm
Interchange Prefixes
A prefix that cannot be
identified by BASE24-eps by
any means available to it.
A prefix that is not
specifically defined to
BASE24-eps, but can be
identified based on an
algorithm match.
A prefix that is specifically
defined to the BASE24-eps
in an Interchange prefix data
source.
A prefix that is specifically
defined to the BASE24-eps
in the Prefix data source.
When the Acquirer Interface component invokes the Prefix component to determine
the
transaction issuer, it first determines whether the issuer is a known (recognized)
issuer by
searching for a match on the prefix in the Prefix external memory table
(Prefix_OLTP).
If a match is found, the component invokes the Transaction component to add to the
transaction the Issuer Route Profile and Route Type TDEs, as well as several other
TDEs
not specifically used in routing and returns control to the Prefix component.
If the Prefix component does not find a match in the Prefix external memory table, it
attempts
to find one using the methods defined in the System Prefix external memory table
(System_Prefix_OLTP).These methods include searching Interchange Prefix data
sources,
testing the transaction prefix against an algorithm, or using a default value. The
Prefix
component uses the methods in the order in which they are defined in the System
Prefix
external memory table.
When the Prefix component finds a match on the transaction prefix, it invokes the
Transaction component to add to the transaction the Issuer Route Profile and Route
Type
TDEs and returns control to the Acquirer Interface component.
If a match is not found in either the Prefix or System Prefix external memory tables,
the
transaction is denied.
Prefixes
Setting Up On-Us Prefixes

Local issuers (institutions) must define each on-us prefix to be processed by
BASE24-eps
using the On-Us Prefix Configuration window (Configure > Prefix > On-Us). Each
prefix
must be explicitly defined, along with the BASE24-eps processing associated with
the
prefix.
Much of BASE24-eps routing and authorization processing is controlled at the prefix
level,
meaning that processing can be set up differently for different prefixes.
The information from the On-Us Prefix Configuration window is used to populate the
Prefix
data source, from which the Prefix external memory table is built.
Identifying a Prefix
The key used to identify a prefix is actually the prefix itself and length of the PAN in
which
the prefix can be found. Thus, when you define a prefix you are actually defining it in
combination with the PAN length.
Note: An institution must be defined to which an on-us prefix belongs.
Defining On-Us Prefix Routing Parameters

There are only a few routing parameters configured for a prefix, which makes sense
because
at the point the prefix is identified, the issuer is known.
On-Us Prefix Configuration Window Setting (for Routing)
Tab Field Description
The route type value to be used for the transaction. Values are as
follows:
Processing Information Route Type
Acquirer and Issuer Means that a business relationship should
be taken into consideration, and transactions will be evaluated for a
route code.
Issuer Only Means that a business relationship does not exist for
this prefix and transactions will not be evaluated for a route code.
This value is moved to the Route TypeTDE.
Refer to Enabling and Disabling the Use of Routing Codes at the
Prefix Level on page 99 for more information about how this field is
used.
The instrument type to be assumed for the transaction.
Issuer Information Instrument Type
This value is moved to the Instrument Type TDE.
The name of the Destination Routing Profile to use for the transaction.
Destination Routing
Profile
This value is moved to the Issuer Routing Profile TDE.

Prefixes
Setting Up Not-On-Us Prefixes

The controls for recognizing and processing transactions with not-on us prefixes are
defined
through the Source Routing Profile, which are assigned to the various acquiring
endpoints.
Refer to Source Routing Profiles on page 88 for information about the Source
Routing
Profile.
Prefixes
Payment Instruments, Cards, and

Accounts
The topics here describe payment instruments, cards, and accounts and how they
are
used in BASE24-eps processing.
Payment Instruments, Cards, and Accounts
Payment Instruments
A payment instrument is a device by which consumers can initiate payment
transactions.
Cards are the typical payment instrument used in the payments industry, and in the
interest
of clarity, cards are the instrument type assumed throughout the BASE24-eps
product
documentation unless specifically noted to the contrary. Important to note, however,
BASE24-eps is adaptable to other types of instruments as well.
Instrument Types
Instrument type is a one- or two-character user-defined identifier (code) used
throughout
BASE24-eps to identify types of payment instruments. Each instrument defined to
the
system must have a corresponding instrument type associated with it.
In a card-based payment system, the instrument type represents the branding of the
card,
such as Visa Debit, Visa Credit, American Express, and MasterCard, among others.
Defining Your Instrument Types

Instrument types are defined for the BASE24-eps system in the Instrument Type
(Instrument_Type) data source and can be viewed and managed using the
Instrument
Type Configuration window (Configure > Instrument Type). Once defined,
instrument
types can be selected as valid types for the various instruments (i.e., cards) you
want to
define.
Cards
Cardsthat is plastic debit or credit cardsare a type of payment instrument. They
serve
as evidence of one or more accounts and act as a mechanism for accessing the
accounts
using the many electronic funds transfer (EFT) channels available.
Configuring Cards
Cards are configured on the Card Management window (Customer Management >
Card)
or the Administrative Card Configuration windows (Configure > Administrative
Card).
Associating Cards and Prefixes

Any cards to be processed by BASE24-eps must have their prefixes defined to the
system
as on-us (known) prefixes. For information on on-us prefixes, refer to Setting Up OnUs
Prefixes on page 26 for information about setting up on-us prefixes.
Prefix definitions specify processing parameters and associated limits for a prefix.
These
parameters and limits can be used in authorization or prescreening processing for
cards
that belong to the prefixif the parameters and limits have not been defined more
specifically for the card.
Associating Accounts with Cards

BASE24-eps supports up to 80 accounts associated with a single card. Refer to
Accounts
on page 40 for more information about accounts and associating them with cards.
How Cards are Identified in BASE24-eps

Cards are identified to BASE24-eps using several identifiers that are important to
understand.
Primary Account Numbers (PANs)

Cards are identified by a primary account number (PAN) that is embossed on the
front of
the card and encoded on the magnetic strip.
The PAN is a composite number that contains a prefix consisting of the bank
identification
number (BIN) of the card issuer followed by a possible regional identifier, an
individual
account identifier that includes part of the account number, and a check digit or code
that
verifies the authenticity of the embossed account number or the PAN on the track.
The
length of a PAN varies by card type but is typically 1619 digits.
You can view the PAN of a card defined to BASE24-eps in the Card Number field on
the
Card Management window (Customer Management > Card).
Member Numbers
The member number is a card sequence number used to identify an individual

member
when several members have the same card number. This enables you to issue
different
plastics with the same PAN, but different member numbers, and define each with its
own
unique card record in BASE24-eps. If a card has only one member, the
corresponding
member number would be 000, and there would only be one BASE24-eps record
representing the card. If there were multiple members (e.g., 001, 002, 003), each
could
have his or her own plastic and each plastic would have its own BASE24-eps record.
The member number associated with a card is identified in the Member Number field
of
the Card Management window (Customer Management > Card).
Institution (Card Issuer)

The institution that issued a card is identified by its institution ID. All cards defined to
the
BASE24-eps system must have a corresponding issuer institution defined to the
systemprior to adding the cards.
The card issuing institution is identified for the card in the Institution ID field of the
Card
Management window (Customer Management > Card).
Institution records are accessed and updated using the Institution Configuration
window
(Configure > Institution).
Card Information Maintained by BASE24-eps

Card information is maintained in the Card, Card Account, and Card Account
Multibyte
data sources.
Customer ID
The customer ID of the Card record identifies the name of the customer or business
to
which the card was issued.
You can view or change the customer ID associated with a card on the General tab
of the
Card Management window.
Note: Depending on your environment, a multibyte version of the customer ID can
be
entered. If present, the multibyte value is carried in the Card Account Multibyte data
source.
Depository Type
The depository type specifies the preferred type of deposit for the card used by the
customer: Standard or Commercial.
Your scripts can use this value to set the Depository Type TDE. The Depository Type
TDE
can then be used by those device handler components that support the capability to
specify
to terminals the depository to open for deposit transactions.
You can view or change the depository type associated with a card on the General
tab of
the Card Management window.
Card Types
Card types are a specific form of instrument type. They are a one- or two-character
user-defined identifier (code) used throughout BASE24-eps to identify the type of
card.
Each card defined to the system must have a corresponding card type associated
with it.
Refer to Payment Instruments on page 29 for information about how available
instrument
types are defined in the system.
You can view or change the card type associated with a card on the General tab of
the
Card Management window.
Note: The INSTRM_TYP Card object script operator returns the one or twocharacter
code representing the instrument type of the card used in a transaction.
PIN Information/PIN Verification Value (PVV)

PIN verification during transaction processing can require the use of a PIN
verification
value (PVV), which is combined with the customer-entered PIN and other data to
allow for
verification.
BASE24-eps enables you to configureat the prefix levelwhether the PVV will be
acquired from the card itself (in the track data), or from the Card record, or not at all.
This
prefix setting is specified in the PIN Location fields on the On-Us Prefix Configuration
window. If the prefix setting indicates the PVV is to be acquired from the Card record,
the
PVV needs to be placed in the Card record for those cards associated with the
prefix.
The PVV is not displayed; it is carried in the Card data source, but you can change it
from
the General tab of the Card Management window. The PIN verification value is
masked
on the window and must be entered twice to ensure that it is entered correctly.
For information about PIN verification, refer to the BASE24-eps Transaction Security
Manual.
Last PIN Change Date

The date and time of the last PIN and PIN verification value change for the card is
displayed
in the Last PIN Change field on the General tab of the Card Management window.
This
date is updated in the following situations:

A new PVV is entered on the Card Management window.
The new PVV is created as the result of an online PIN change transaction.
A new PVV is created as the result of the cardholder choosing a PIN on the first
online
transaction for the card.
The PVV is set by a partial-file refresh or file update transaction.
The PVV change date is set explicitly by a partial-file refresh or file update
transaction.
Check Processing
BASE24-eps check processing enables you to specify at the prefix and card level
whether
to evaluate check-based transactions against your total cash advance and total
withdrawal
limits. If defined at the card level, these settings are on the General tab of the Card
Management window. For information about these check settings, refer to Check
Limits/Usages on page 196.
Card Status
Card status indicates whether a card is open, closed, lost, stolen, or pending
activation.
This information is critical to authorization processing in that the status of a card is a
major
factor in determining processing allowed on the card. For example, transactions
would
typically be denied for lost, stolen, and closed status cards, however, transactions on
cards
that are lost or stolen might also provide the opportunity to retain the card on behalf
of the
card issuer.
Status values are user-defined for your system in the
CommonCodesValues.properties
file. Values of 0015 are intended for Open statuses; values 16-99 are for other
values.
The default values here correspond to values in the standard authorization scripts
delivered
with the BASE24-eps application. These values can and should be changed for
specific
environments.
Value Description
015 Open
60 Denied - Lost
70 Denied - Stolen
80 Denied - Closed

You can view or change the card status associated with a primary or secondary card
on
the Status tab of the Card Management window.
Note: The system tracks the date and time the status last changed for primary and
secondary cards defined in the BASE24-eps system. This information is displayed in
the
Status Last Change Date fields on the Status tab of the Card Management window.
Effective Date
If you want a card to become usable as of a specific date, you can set an effective
date
for the card. The effective date is intended to be the first date BASE24-eps will
authorize
transactions on a card and can be used by your authorization scripts for that purpose
(currently, the sample authorization scripts do not include this processing).
You can view or change the effective date associated with a primary or secondary
card
on the Status tab of the Card Management window.
Placing a check mark in the Use Effective Date field on that tab enables the
associated
date field and can also be used by your authorization scripts to control whether or
not to
use the effective date field in processing.
Note: The system tracks the date and time the effective date last changed for
primary
and secondary cards defined in the BASE24-eps system. This information is
displayed in
the Effective Last Change Date fields on the Status tab of the Card Management
window.
Expiration Date
If you want a card to expire as of a specific date, you can set an expiration date for
the
card.The expiration date is the last date BASE24-eps will authorize transactions on a
card.
You can view or change the expiration date associated with a primary or secondary
card
on the Status tab of the Card Management window.
Placing a check mark in the Use Expiration Date field on that tab enables the
associated
date field. The date placed in that date field is the last date the card will be usable.
Note: The system tracks the date and time the expiration date last changed for
primary
and secondary cards defined in the BASE24-eps system. This information is
displayed in
the Expiration Last Change Date fields on the Status tab of the Card Management
window.
Card Limits
The limits profile and the limit overrides to be used by a card are specified on the
Limits
tab of the Card Management window. For information about these limit profiles and
overrides, refer to Assigning Limit Profiles to Cards, Accounts, and Prefixes on page
149.
Note that card usages are maintained in their own data source and are not part of
the card
record.
Cardholder Address/Address Verification Settings

The cardholder address associated with a card consists of two lines of cardholder
address
information and the postal code for the cardholder address. This information can be
entered
for informational purposes or it can be used in address verification service
processing (AVS
processing).
AVS processing gives merchants the capability to use the cardholders address
information
to confirm that a customer is entitled to use an account in situations where it is not
possible
to physically examine the card and the customers signature.
You can view or change the address information on the Address tab of the Card
Management window.
If you want to use the cardholder address information for address verification, place
a
check mark in the Use Address Verification field on the Address tab of the Card
Management window. Leaving this field blank means the cardholder address
information
is being used for informational purposes only and will not be used for address
verification.
Note: Depending on your environment, multibyte versions of the two customer
address
lines and postal codes can be entered. If present, these multibyte values are carried
in the
Card Account Multibyte data source.
Note: The CRD_AVS_FLG Card object script operator is used to check the Use
Address
Verification field. If the flag is enabled, the ADDR_VRFY Card object script operator
can
be used to invoke address verification processing.
Accounts
BASE24-eps supports up to 80 accounts associated with a single card. These are
set up
on the Accounts tab of the Card Management window. Refer to Accounts on page 40
for
more information about accounts and associating them with cards.
Primary and Secondary Cards

When institutions reissue cards, there can be a period of time when two physical
cards
are in circulation with the same card number (and member number), but different
expiration
dates.
BASE24-eps enables you to configure the following information separately for
primary and
secondary cards in the same Card record.
Card Status
Effective Date
Expiration Date
In processing, the primary and secondary cards are differentiated by their expiration
date
(i.e., the expiration date on the card can be compared to the expiration dates for the
primary
and secondary cards in the Card record).
You can view or change the primary and secondary card information on the Status
tab of
the Card Management window.
Script Operators
The following Card object script operators are used in support of primary and
secondary
cards:
SCND_STAT
SCND_STAT_SET
PRI_STAT
PRI_STAT_SET
IS_PRI_EFF
IS_PRI_EXP
IS_SCND_EFF PRI_STAT_SET_NOTIFY SCND_STAT_SET_NOTIFY
IS_SCND_EXP
These operators can be used to determine whether the card used to initiate a
transaction
is the primary (original) or secondary (reissued) card by comparing the expiration
date of
the card to the primary and secondary card expiration dates in the Card data source.
The
operators can also be used to activate the secondary card when the first transaction
using
the card is received and/or the operators can be used to promote the secondary card
to
become the primary card. Refer to the BASE24-eps Scripting Manual for more
information
about these and other script operators.
Refreshing Card Information

Card information is carried in the Card (Card), Card Account(Card_Account), and
Card
Account Multibyte (Card_Account_Multibyte) data sources. These data sources can
be
refreshed using full-file or partial-file refreshes.
For information about refreshes, refer to the BASE24-eps File Refresh User Guide.
The Last Time the Card Information Was Refreshed

At the bottom of the General tab on the Card Management Window is information
about
the last time (Refresh Timestamp) the card record was refreshed from a host and the
identifier of the batch (Refresh ID) used to refresh the record.
If timestamp and ID information is not provided, it indicates that the card record has
not
been updated by a refresh.

Note: Card information in the Card (Card), Card Account(Card_Account), and Card
Account
Multibyte (Card_Account_Multibyte) data sources can also be updated using file
update
transactions. This type of update does not update the refresh date information.
Administrative Cards
Administrative cards are a special type of card identified within BASE24-eps for
different
forms of administrative channel processing.
The processing and configuration requirements of an administrative card can vary
depending
on the type of channel in which they are used:
ATM terminal-owning institutions issue administrative cards for servicing and
settling
terminals.
Point-of-sale terminal owners typically issue administrative cards at the merchant
level
for settlement purposes.
Administrative cards enable terminal-owning institutions or merchants to initiate
administrative transactions at an ATM or point-of-sale terminal, respectively.
Cardholder
transactions, such as a return or an adjustment, can be configured to require the
input of
an administrative card as well as the cardholders card.
For transactions acquired in the BASE24-eps system from a channel device (e.g.,
ATMs
or point-of-sale terminals) using an administrative card, transactions are authorized
in
scripts using the same Card script operators in scripts that are used to access
non-administrative card information.
Transactions Allowed
The Admin Card Required field on the Acquirer Transactions Allowed Profile
Configuration
window (Configure > Transactions Allowed > Acquirer Transactions Allowed)
specifies
whether an administrative card is required to enter a transaction.
Prefix Considerations
Large ATM or point-of-sale network owners may want to issue administrative cards
using
a card prefix reserved for just administrative cards while smaller ATM or point-of-sale
network owners may want to designate a range of card numbers from within their
cardholder
base to be used as administrative cards. In either case, the card prefix for
administrative
cards must be configured as an on-us prefix.
If an entire card prefix is configured to be used exclusively for ATM administrative

cards,
set the Instrument Type field on the Issuer Information tab of the On-Us Prefix
Configuration
window to AD (Administrative).
Setting Up Administrative Cards for Use with

Point-of
Sale Terminals
Administrative cards for point-of-sale terminals are configured and accessed on the
Administrative Card Configuration window (Configure > Administrative Card). Data
from
this window is stored in the Administrative Card data source (Admin_Card).
Before entering an administrative card record, you must configure the on-us card
prefix to
be used to recognize the administrative card number and the merchant with which
the
administrative card is associated.
Identification Information
The following information identifies the administrative card.
Field Description
Card Number The number of the administrative card.
User Name The user name associated with the administrative card.
The merchant ID associated with this administrative card. The administrative card can
only be used at POS terminals associated with this merchant.
Merchant ID
PIN Information
The following information identifies the PIN information associated with the
administrative
card.
Field Description
This is not displayed, but can be changed on the Administrative Card Configuration
window. To change it, the value must be entered twice.
PVV
PVV Key Index Specify the PVV Key Index to be used with the PVV.
Usage Information
The following information identifies the usage information associated with the
administrative
card.
Field Description
Last Used The date the card was last used.
The number of bad PIN tries attempted for the administrative card since the bad PIN tries
was last reset.
Bad PIN Tries
The date the bad PIN tries were last reset. Typically, the entry of a correct PIN causes
the bad PIN tries to reset to zero.
Last Reset

Allowed Transactions
Administrative cards can only be used to initiate those transaction types that are
specifically
enabled for the card.
The check boxes in the Allowed Transaction Types section of the Administrative Card
Configuration window indicate the transactions the administrative cardholder is
allowed to
perform with the card. A check mark in the box next to the transaction type means
the
administrative cardholder is allowed to perform that transaction; otherwise, the
transaction
is not allowed. The following is a list of transaction types that can be enabled for an
administrative card.
Allowed Transaction Types
Administrative Shift Close 95 (Administrative Subtotal)
(94)
Administrative Day Close
(93)
Administrative Batch Close
(92)
30 (Available Funds Inquiry 31 (Balance Inquiry) 38 (Card Verification Inquiry) 03 (Check Guarantee)
04 (Check Verification) 22 (Credit Adjustment) 02 (Debit Adjustment) 00 (Purchase)
01 (Withdrawal/Cash 20 (Return) A0 (Activation)
Advance)
09 (Purchase with Cash
Back)
5C (Bulk Authorization) 2A (Funds Disbursement) 9U (Offline Phone Top Up) 0A (Phone Top Up)
Setting Up Administrative Cards for Use with ATMs

Administrative cards for ATM terminals are configured and accessed on the Card
Management window and are stored in the Card data source (Card). They are
similar to
customer cardsthe major difference is that the Card Type field on the General tab
of the
Card Management window must be set to a value of AD - Administrative. Also, a
usage
would typically be configured for the administrative card to accumulate bad PIN tries
on
the Usages Management window.
Before entering an administrative card record, you must configure the on-us card
prefix to
be used to recognize the administrative card number.
Accounts
Accounts, in the context of the BASE24-eps configuration, typically refer to the
accounts
tied to a card rather than to the card itself. Accounts basically represent the
underlying
card-issuer institutional accounts to which a card has access, such as the
cardholders
checking, savings, and credit accounts.
Associating Account with Cards
The association, or tying, of accounts to cards within BASE24-eps is very flexible. A

card
can have single account tied to it, it can have up to 80 different accounts tied to it of
varying
types, or it can have no accounts tied to it at all.
Accounts are set up on the Accounts tab of the Card Management window. Account
balance
information is accessed using the Positive Balance Management window.
The reason for associating accounts with cards is that while transactions are initiated
using
cards, transactions also typically involve or affect different types of accounts (e.g.,
withdrawal
from savings, a purchase on a credit account, or a transfer from savings to
checking).
By associating one or more accounts with cards, your authorization scripts can
involve
specific account information in authorizing transactions initiated with the card.The
following
are typical purposes for which account information is used.
Verifying Cardholders Have Access to an Appropriate Account

The presence of accounts can enable your authorization scripts to determine
whether a
cardholder has access to the type of account(s) needed for a particular transaction.
Every
account defined to BASE24-eps has a type and status associated with it. Thus, if a
transaction is attempted on a card that does not have access to an account of the
required
type and status, the transaction can be denied. For example, on an attempted
withdrawal
from savings, authorization scripts can check for the presence of an open savings
account
associated with the card and deny the transaction if one is not found.
Enabling Cardholders to Access and Select From Multiple

Accounts
Associating multiple accounts with a card can enable a card to transact business on
differentand sometimes many differentaccounts. A straightforward example
might be
setting up a checking and credit account for the card to be used for debit and credit
transactions. A more involved example might be used in processing environments
where
the transaction-originating devices support multiple account selectionalso know as
Open
Account Relationships (AOR). In these cases, BASE24-eps can be configured to
return
all of a cardholders defined accounts to the transaction-originating device to allow
the
cardholder to choose the account to be used for the transaction.
The latter approach might be useful, if for example, a cardholder was set up to make
certain
types of purchases for a number of clients. In this case, each client might establish
his or
her own account and each of those accounts would be associated with the card.
Then, for
transactions on the cardassuming the originating device supports itthe accounts
would
be passed back to allow the cardholder to choose the account for making the
purchase.
Verifying Cardholders Have Sufficient Funds Available on Their

Accounts
Beyond simply associating accounts with the card, BASE24-eps also supports the
capability
of maintaining balance and usage information for each of these accountsas well as
other
account-level activity information. This is supported through the Positive Balance
data
source, which enables authorization processing to take balance information into
consideration when evaluating a transaction for approval. In this case, once the
account
is chosen for a transaction, the authorization scripts can take additional stepsusing
the
Positive Balance data source and account balance usagesto determine whether
sufficient
funds are available to allow the transaction.
Identifying Accounts to BASE24-eps

Accounts are identified to BASE24-eps using several identifiers that are important to
understand. These identifiers are used in both the Card record and the Positive
Balance
records to identify an account.
Institution ID
The institution ID is the identifier of the institution that owns the account. This
institution
ID must match the institution ID of the card with which the account is associated.
Account Number
The account number is the primary identifier for the account. The length of an
account
number varies but is typically 1116 digits.
You can view the account numbers of the accounts associated with a card in the
Account
Number field on the Accounts tab of the the Card Management window (Customer
Management > Card).
Account Types
The account type is a code used to identify the type of account represented by the
account
number.

If the same account number is used to access different types of accounts, the
positive
balance data for each type of account is configured in a separate Positive_Balance
record.
If an account number has only one type of account or if only one positive balance
record
is to be used as the default for an account number with several associated types of
accounts, set the account type to Default Account (00).
Note: The account type affects which fields are displayed on the Balances tab as
discussed
below.
The following table shows which account types are considered debit and credit.
Debit-Type Accounts Credit-Type Accounts
30 = Credit
38 = Line of Credit
00 = Default/None
10 = Savings
11 = Savings - Money Market 9B = Installment Loan
12 = Savings - Certificate of Deposit 9C = Mortgage Loan
20 = Checking
21 = Checking - Money Market
39 = Corporate Card
40 = Universal Account
50 = Investment Account
58 = CD
60 = Stored Value - Reloadable
67 = Stored Value - Disposable
9M = Other
Note: The DFLT_ACCT_TYP Card script operator can be used access the account
type
during transaction processing.
Account Information Maintained by BASE24-eps in

the
Card Data Source
The information maintained for an account in the Card data source is minimal.
Additional
information relating to an account is carried in the Positive Balance data source.
Note: This account information can be refreshed using a Card refresh.
Account Status
The account status is a value assigned to each account to be able to determine
certain
characteristics of the account.
Account status values are Open or Closed. An account must have an open account
status
to be used in processing.The status change date is the date and time on which the
account
status was last changed.
values.
delivered
specific
environments.
Status Description
015 Open
90 Closed
Note: Changes to the account status on the Card data source do not affect the
account
status in the Positive Balance data source and vice versa.
Note: If you create new status values for your institution, it is important that you also
evaluate your script logic to ensure that those values are interpreted correctly.
Note: The system tracks the date and time the status last changed. This information
is
displayed in the Status Last Change Date fields on the Status tab of the Card
Management
window (Customer Management > Card).
Account Description
Your authorization scripts can be set up to use a default account type for a card. For
example, if you want all POS transactions for a cardholder to use a default account
of
checking, you would set the default account type to checking.
Note: Depending on your environment, multibyte versions of the account
descriptions can
be entered. If present, these multibyte values are carried in the Card Account
Multibyte
data source.
Account Type Default

Your authorization scripts can be set up to use a default account type for a card. For
example, if you want all POS transactions for a cardholder to use a default account
of
checking, you would set the default account type to checking.
Basically, the default account type is used if there is no account type supplied in an
incoming
message. Having an account type is important because it used in authorization (e.g.
different limits/usages are typically used for credit and debit accounts).
You can view or change the Account Type Default on the Accounts tab of the Card
Management window.
Account Information Maintained by BASE24-eps in

the
Positive Balance Data Source
The BASE24-eps system maintains account balance data and other information in
the
Positive Balance data source (Positive_Balance) for each account belonging to a

cardholder
whose card issuer uses the Positive Balance Authorization method.
Account Currency Code

Each account has associated with it the currency code denoting the currency in
which the
various balances and amount information are displayed.
You can view or change the currency code on the General tab of the Positive
Balance
Management window.
Script Information: To access currency code information in scripts, use the
CRNCY_CDE
PBAL object script operator. Refer to the BASE24-eps Scripting Manual for more
information
about the PBAL object.
Account Status
The account status is a value assigned to each account to be able to determine
certain
characteristics of the account.
Account status values are Open or Closed. An account must have an open account
status
to be used in processing.The status change date is the date and time on which the
account
status was last changed.
values.
delivered
specific
environments.
Status Description
015 Open
90 Closed
You can view or change the account status on the Status tab of the Positive Balance
Management window.
Note: If you create new status values for your institution, it is important that you also
evaluate your script logic to ensure that those new values are interpreted correctly.
Note: Changes to the account status on the Card data source do not change affect
the
account status in the Positive Balance data source and vice versa.
Note: The system tracks the date and time the status last changed. This information
is
displayed in the Status Last Change Date fields on the Status tab of the Positive
Balance
Management window (Customer Management > Positive Balance).
Balances
Refer to Account Balance Information on page 46.
Limits
The limits profile and the limit overrides to be used by an account are specified on
the
Limits tab of the Positive Balance Management window. For information about these
limit
profiles and overrides, refer to Assigning Limit Profiles to Cards, Accounts, and
Prefixes
on page 149. Note that balance usages are maintained in their own data source and
are
not part of the positive balance record.
Activity
Refer to Account Activity on page 50.
Refreshing Account Information

Account balance records are carried in the Positive Balance (Positive_Balance) data
source. This data source can be refreshed using full-file or partial-file refreshes.
For information about refreshes, refer to the BASE24-eps File Refresh User Guide.
The Last Time the Positive Balance Information Was Refreshed

At the bottom of the General tab on the Positive Balance Management Window is
information
about the last time (Refresh Timestamp) the account record was refreshed from a
host
and the identifier of the batch (Refresh ID) used to refresh the record.
If timestamp and ID information is not provided, it indicates that the account record
has
not been updated by a refresh.
Note: The Positive Balance data source can also be updated using file update
transactions.
This type of update does not update the refresh date information.
Account Balance Information

BASE24-eps maintains basic account balance information in the Positive Balance
data
source. The balance information differs based on whether the account type is
considered
a debit or credit account.
Refer to Identifying Accounts to BASE24-eps on page 41 for a listing of available
debit
and credit account types.
You can view balance information for an account on the Balances tab of the Positive
Balance Management window (Customer Management > Positive Balance).
Debit Account Balance Information

The following balance information is either maintained, or derived from information,
in the
Positive Balance data source for debit accounts.

Available Balance Start of Day The available balance on the account at the start of the indicated date.
Date The business date whose available balance information is presented.
The derived current available balance on the account. This balance is
not stored in the Positive Balance data source; it is computed using the
Current
start of day balance plus or minus any active usages since the start of
the business day specified in the Date field.
Ledger Balance Start of Day The ledger balance on the account at the start of the indicated date.
Date The business date whose ledger balance information is presented.
The derived current ledger balance on the account. This balance is not
stored in the Positive Balance data source; it is computed using the start
Current
of day balance plus or minus any active usages since the start of the
business day specified in the Date field.
Credit Account Balance Information

The following balance information is either maintained, or derived from information,
in the
Positive Balance data source for credit accounts.
Credit Account Balance Information
Available Credit Start of Day The available credit on the account at the start of the indicated date.
Date The business date whose credit balance information is presented.
The derived current available credit on the account. This balance is not
stored in the Positive Balance data source; it is computed using the start
Current
of day balance plus or minus any active usages since the start of the
business day specified in the Date field.
Credit Limit The credit limit on the account.

Deriving Current Account Balances Using the

Account
Balance Information
Current account balances are not maintained in the Positive Balance data source.
Rather
they are freshly calculated whenever they are needed for processing or display.
Current
balances are based on start of day balanceswhich are maintained in the Positive
Balance
data sourceplus or minus any applicable active usages.
Start of day balances and their corresponding dates are static data in the online
transaction
path and are not updated during transaction processing. As such, the Positive
Balance
data source is not undergoing updates as transaction processing affects balances. If
a
current balance is needed for transaction processing, applicable active usages are
retrieved
and applied to the start-of-day balance to derive the current balance.
The start of day balance and data can be provided by refresh or file update or set
using
the ACI desktop.
Example of Deriving a Current Balance
There are three usage names that are system-defined specifically for the purpose of
tracking
balance changes. Their formats are as follows:
AVAIL_yyyymmdd For available balances of debit accounts
LEDG_yyyymmdd For ledger balances of debit accounts
AVAILCR_yyyymmdd For available credit of credit accounts
The following is a sample list of active usages on a debit account based on a set of
transaction processed on the account. In this case, the processors authorization
scripts
are set up to create available and ledger balance usages for debit accounts. For
information
on active versus expired usages, refer to Tracking Transaction Usage on page 152.
Active Usages
# Transaction Name Amount Name Amount
1 Purchase AVAIL_20090305 -$500 LEDG_20090305 -$500
4 Deposit AVAIL_20090306 $200 LEDG_20090306 $800
7 Withdrawal AVAIL_20090308 -$100 LEDG_20090308 -$100

Note: Transaction #4 is a deposit, and this case, the authorization scripts are set up
to
add the full amount of the $800 deposit to the ledger balance but only a percentage
of the
deposit to the available balance ($200 in this case).
Based on the active usages in the table above, current balances would be computed
as
follows using the indicated start of day information.
Available Balance Start of Day $4,000
Date March 6, 2009
Current $4,000 Start of Day
-$20 Usages 39
(Usages 1-2, although active,
are not applied because their
date is prior to March 6.)
$200
-$40
-$60
-$100
-$10
-$300
$3,670 Derived Balance
Ledger Balance Start of Day $5,000
Date March 6, 2009
Current $5,000 Start of Day
-$20 Usages 39
(Usages 1-2, although active,
are not applied because their
date is prior to March 6.)
$800
-$40
-$60
-$100
-$10
-$300
$5,270 Derived Balance
Because current balances are derived by applying active usages that were created
with
dates on or after the date of the start-of-day balance, it is assumed that the hostprovided
start-of-day balances would always include any transaction activity that occurred
prior to
the date. Thus, in this example, usages 1 and 2 represent transactions that would
have
already been processed and included in the host-provided start-of-day balances.
Refresh Scheduling as it Relates to Account

Balances
Because current balances are derived by applying active usages that were created
with
dates on or after the date of the start-of-day balance, it is assumed that the hostprovided
start-of-day balances always include any transaction activity that occurred prior to
the date.
Also, your usage retention needs to be long enough to keep usages active until they
can
be processed and reflected in the host-provided start-of-day balances. For instance,
if your
retention period was set to one day and you refreshed your start-of-day balances
every
three days, your usages would expire two days before being included in your startof-day
balancesresulting in inaccurate current balances. Generally, it is better to have
usage
retention periods longer than your refresh cycle rather than shorter. Thus, you need
to
evaluate your refresh cycle against your usage retention.
Account Activity
The Positive Balance data source contains the account activity information.
The account activity information is described in the following table. All of this
information
can be accessed by your authorization scripts, and some of it can be updated. The
table
identifies those fields that can be updated by your authorization scripts.
All of it can be refreshed or updated by file update, and all of it can be viewed for an
account
from the Activity tab of the Positive Balance Management window (Customer
Management
> Positive Balance).
Updated by
Script?
Group Field Description
Deposit Last Deposit Amount The amount of the last deposit on the account. Yes
Last Deposit Date The date of the last deposit on the account. Yes
The minimum amount for a payment from the No
account. This typically applies only to credit or
installment-type accounts on which debt is owed.
Minimum Payment
Amount
Payment
The payment due date for a next payment from No
the account.
Next Payment Date
Withdrawal Last Withdrawal Amount The amount of the last withdrawal on the account. Yes
Last Withdrawal Date The date of the last withdrawal on the account. Yes
Interest Accrued The accrued interest on the account. No
YTD The year-to-date interest on the account. No

Field Masking of Card and Account

Information
BASE24-eps provides for masking sensitive cardholder data when displayed on
windows
of the ACI desktop user interface.
Security Best Practices: Cross-industry best practices recommends that sensitive
cardholder data be masked when displayed on windows of the ACI desktop.
The values displayed in the following fields are masked according to the default
CARD
and ACCOUNT masks provided in the FieldMasking.xml file. For Java servers, this
file is
located in the JavaSF/config folder, for UI servers this file is located in the
UIServer/ESConfig folder.
For these fields, the masked value is displayed in the clear only when the field is
currently
in focus or the mouse is hovering over the field.
ACI desktop User Interface Window Tab > Field Mask
Administrative Card Configuration Card Number CARD
Card Management Card Number CARD
Card Management Find > Card Number CARD
Card Management Accounts > Account Number ACCOUNT
Journal Perusal Primary Account Number CARD
Journal Perusal Account Number ACCOUNT
Positive Balance Management Account Number ACCOUNT
Positive Balance Management Find > Account Number ACCOUNT
EMaskedComponents for these fields use the FieldMasking.xml file to mask the
display
of sensitive customer data. For detailed information about the FieldMasking.xml file
and
the CARD and ACCOUNT masks, refer to the ACI Java Server Framework
Reference
Guide.
Security Best Practices: Access to other customer-sensitive information such as
balances, transaction amounts, and address information is controlled through the
assignment of window permissions to users.

Transactions allowed is a term used for a basic transaction screening function that
BASE24-eps provides as a part of routing and authorization for acquirer and issuer
endpoints. Essentially, it specifies which transactions an acquirer or issuer accepts
and
under what circumstances.
Allowed transactions are set up using the following types of profiles, which can then
be
assigned to one or more entities.
Acquirer Transactions Allowed Profile
Issuer Transactions Allowed Profile
Acquirer Transactions Allowed Profiles

Acquirer Transactions Allowed profiles contain a list of transactions you define as
allowed
by acquirer endpoints and under what circumstances. Each profile is given a name
which
is then used to assign the profile to an acquirer interface.
What is a Profile?
Profiles are named sets of parameter values and settings that can be assigned as a
group
and shared amongst multiple entities. Profiles enable configuration and reuse of
common
values, saving time in setup and adding consistency.
Setting Up an Acquirer Transactions Allowed

Profile
Acquirer Transactions Allowed profiles are created and viewed on the Acquirer
Transactions
Allowed Profile Configuration window.
Data entered on this window is stored in the Acquirer Transactions Allowed data
source
(Acquirer_Txn_Allowed) and is accessed from an external memory table
(Acquirer_Txn_Allowed_OLTP) during processing.
How Transactions are Identified in Profiles

Transactions listed in the Transactions Allowed profile are identified by their message
category (class) and processing code.
The following are examples of several withdrawal transactions as they might be
included
in a profile. For a complete list of supported values, refer to Processing Codes on
page
296.
Note: If a transaction is not included in the profile, it is not allowed.
Message Category Processing Code
Transaction Code Account Type 1 Account Type 2

Financial 01 20 00
Financial 01 21 00
Financial 01 58 00
Acquirer Profile Settings for each Transaction

Each transaction specified in an acquirer profile has the following information set for
it:
Settings Description
A flag indicating whether or not an administrative card is required for the transaction. A check
mark means an administrative card is required; no check mark means an administrative card
is not required.
Admin Card Required
Specifies whether the acquirer allows the transaction and whether any geographic restrictions
apply. Values are as follows:
On-Us
Disallowed - the specified transaction is not allowed by the acquirer.
In State - transaction is allowed in state by the acquirer if the acquirer and issuer institution
are the same.
Nationally - transaction is allowed nationally by the acquirer if the acquirer and issuer institution
are the same.
Internationally - transaction is allowed internationally by the acquirer if the acquirer and issuer
institution are the same.
Note:
The geographically-qualified settings, italicized above, all allow the transaction to pass the
initial transaction allowed check. The specific geographic information from this field is added
to the Acquire Transaction Allowed TDE, which is evaluated when Issuer Transaction Allowed
processing occurs.
Assigning Acquirer Transactions Allowed Profiles

to
Acquirer Endpoints
You must assign an Acquirer Transaction Allowed Profile to each device or interface
that
will acquirer transactions. This enables the interface to check the profile information
to
determine whether a type of transaction is allowed.
Acquirer Transactions Allowed Profiles are assigned to the various entities using the
field
settings shown in the table below.
Type of Acquirer Window Tab Field
ATM Channel Device ATM Channel Configuration Transaction Profiles Acquirer Transactions Profile
ATM (Java) Channel Device ATM Channel Configuration Processing Acquirer Transactions Profile
Merchant Channel Processing Acquirer Transactions Profile
Configuration
POS Channel Device
Acquirer Transactions
Allowed Profile
ISO8583 (93) Host Interface Processing
Configuration
ISO 93 Host
Allowed Profile
Configuration
ISO 87 Host
Allowed Profile
Interchange Interchange Configuration UI Processing

How Acquirer Transactions Allowed Profiles are

Used
in Processing
When the transaction enters the Integrated server process, the acquirer interface
checks
the transaction against the Acquirer Transaction profile.
If the type of transaction is not included in the profile, or if the type of transaction is
included
in the profile but it is set to be Disallowed, the transaction is not allowed. In this case,
the
acquirer interface denies the transaction with an action code of 120 (Denied,
transaction
not permitted to terminal), invokes the Journal component to log the denial to the
journal
(NoFI), and returns the transaction to the acquirer.
If the Admin Card Required field in the profile indicates that an administrative card is
required for the transaction (and the Transaction Originator TDE indicates the
originator
is a terminal), the acquirer interface invokes the Admin Card component. The Admin
Card
component validates that an administrative card was used to initiate the transaction
by
verifying the presence of the Admin PAN TDE. If the Admin PAN TDE is not present,
the
transaction is denied with an action Code 111 (Denied, invalid card number), at
which point
the transaction is journaled and the denial is returned to the acquirer.
If the transaction has not been denied, the acquirer interface moves the value from
the
On-Us field in the profile to the Acquire Transaction Allowed TDE and the transaction
is
allowed to proceed (the Acquire Transaction Allowed TDE is used when the Issuer
Transaction Allowed processing occurs.
Issuer Transactions Allowed Profiles

Issuer Transactions Allowed profiles contain a list of transactions you define as
allowed
by issuers and under what circumstances. Each profile is given a name which is then
used
to assign the profile to an issuer.
What is a Profile?
Profiles are named sets of parameter values and settings that can be defined as a
group
and shared amongst multiple entities. Profiles enable configuration and reuse of
common
values, saving time in setup and adding consistency.
Setting up an Issuer Transactions Allowed Profile

Transactions Allowed profiles are created and viewed on the Issuer Transactions
Allowed
Profile Configuration window.
Data entered on this window is stored in the Issuer Transactions Allowed data source
(Issuer_Txn_Allowed) and is accessed from an external memory table
(Issuer_Txn_Allowed_OLTP) during processing.
How Transactions are Identified in Profiles

Transactions listed in the Transactions Allowed profile are identified by their message
category (class) and processing code.
The following are examples of several withdrawal transactions as they might be
included
in a profile. For a complete list of supported values, refer to Processing Codes on
page
296.
Note: If a transaction is not included in the profile, it is not allowed.
Message Category Processing Code
Transaction Code Account Type 1 Account Type 2
Financial 01 20 00
Financial 01 21 00
Financial 01 58 00
Issuer Profile Settings for each Transaction

Each transaction specified in an issuer profile has the following information set for it:
Settings Description
Specifies whether reversals of this transaction type are to be discarded or forwarded to the
issuer.
Discard Reversals
In some cases, the Issuer may not want to receive reversals real time but would process the
reversal later, perhaps after an extract.
This value is added to the Auth Route Dest TDE. If a transaction is to be reversed, the value
in that TDE is checked to determine whether to discard the reversal or send it to the issuer.
Specifies whether the transaction is to have settlement impact.
Settlement Impact
If this value is set, it is added to the Settlement Impact TDE.
Note: The Settlement Impact TDE is not used by BASE24-eps, but is extracted with the
journal file, so the host can use the value if they want.
Specifies whether the issuer allows the transaction and whether any geographic restrictions
apply. On-Us values are intended for use when the acquirer and issuer institution are the
same; Not-On-Us values are intended for use when the acquirer and issuer institution are
not the same. Values are as follows:
On-Us
Not-On-Us
Disallowed - the specified transaction is not allowed by the acquirer.
In State - transaction is allowed in state.
Nationally - transaction is allowed nationally.
Internationally - transaction is allowed internationally.
Assigning Issuer Transactions Allowed Profiles to

Endpoints
You must assign an Issuer Transactions Allowed Profile to each prefix supported by
your
system issuers.You must also assign an Issuer Transactions Allowed Profile to each
interface through which the system sends transactions to be authorized by external
authorizers.
Issuer Transactions Allowed Profiles are assigned to the different entities using the
field
settings shown in the table below.
Type of Assignment Window Tab Field
Prefixes On-Us Prefix Configuration Issuer Information Issuer Transactions Profile
Issuer Transactions Allowed
Profile
Configuration
ISO 93 Host
Profile
Configuration
ISO 87 Host
Profile
Interchange Interchange Configuration UI Processing

How Issuer Transactions Allowed Profiles are

Used in
Processing
From an issuer point of view, transaction are either authorized by BASE24-eps by
authorization script or routed out through an interface to be approved by an external
entity
(e.g., a host or interchange).
If the Transaction is Authorized by BASE24-eps

Where the transaction issuer is determined to be a BASE24-eps institution, the
transactions
prefix is defined to the system, and the Issuer Transaction Allowed profile associated
with
the transaction prefix is used to determine whether or not the transaction is allowed
by the
issuer.
If the transaction is acquired by a device owned by the same institution that issued
the
card (i.e., the acquirer institution ID and issuer institution ID are the same), the ONUS
value is used.
If the transaction is acquired through an interchange or from a device owned by
institution
other than the issuer (i.e., the acquirer institution ID and issuer institution ID are not
the
same) , the NOT-ON-US value is used.
The following table shows the processing that occurs in this case. Note that for noton-us
transactions, the value in the Acquire Transaction Allowed TDE can override the noton-us
value in the Issuer Transactions Allow profile if the TDE value is more restrictive.
Transactions that are denied are given an action code of 119 (Denied, transaction
not
permitted to cardholder), journaled, and returned to the transaction acquirer.
Not-On-Us
(the Acquirer and Issuer Institutions are not
the Same)
On-Us
(the Acquirer and Issuer Institutions are
the Same)
On-Us/Not-On-Us
Value
Disallowed The transaction is denied. The transaction is denied.
The transaction is allowed.
If the Acquire Transaction Allowed TDE
specifies a country or state restriction, that
restriction overrides this setting and the
transaction would be evaluated as described
Allowed Internationally The transaction is allowed.
below for Allowed Nationally or Allowed in
State.
The transaction is allowed if the acquirer
institution and issuer institution countries are
the same. Otherwise, the transaction is denied.
If the Acquire Transaction Allowed TDE
specifies a state restriction, that restriction
overrides this setting and the transaction would
be evaluated as described below for Allowed
in State.
institution and issuer institution countries are
Allowed Nationally

Not-On-Us
(the Acquirer and Issuer Institutions are not
the Same)
On-Us
(the Acquirer and Issuer Institutions are
the Same)
On-Us/Not-On-Us
Value
institution and issuer institution states are the
same. Otherwise, the transaction is denied.
institution and issuer institution states are the
same. Otherwise, the transaction is denied.
Allowed in State
External Authorization
If a transaction needs to be routed out through an interface component for
authorization,
the Issuer Transactions Allowed profile associated with the interface component
sending
the transaction is checked prior to sending the transaction. For example, if a
transaction
is being sent to Visa, the Issuer Transactions Allowed profile associated with the Visa
interface component is the profile checked.
In this case, the NOT-ON-US value in the profile is used to determine whether the
transaction is allowed as described in the table below. Transactions that are denied
are
given an action code of 119 (Denied, transaction not permitted to cardholder),
journaled,
and returned to the transaction acquirer.
On-Us Value Description
Disallowed The transaction is denied.
Allowed Internationally The transaction is allowed.
The transaction is allowed if the acquirer institution and issuer institution countries
are the same. Otherwise, the transaction is denied.
Allowed Nationally
The transaction is allowed if the acquirer institution and issuer institution states are
Allowed in State
Note: If the Issuer Authorization (IAUT) component sends a transaction to an

interface
as a part of sequential routing, the interface will make the same determination based
on
the Issuer Transactions Allowed profile.
Transaction Routing
Transaction routing is the processing within BASE24-eps that identifies transactions
arriving
from their source endpoints, determines the destinations to which they are to be sent
for
processing, and delivers them to these destinations. It is highly configurable and
adaptable
to any number of business requirements. However, generally speaking, transaction
routing
falls into the following types.
Acquirer-to-Issuer Routing
For transactions originating from an acquirer source, the destination is ultimately an
authorizing issuer. This the typical transaction routing scenario, where an acquirer
source
can be a channel device or an interface. A destination can be an internal destination
(i.e.,
the name of an authorization script configuration) using the Issuer Authorization
component
or an external destination (i.e., the name of an issuer interface) using the
interchange-specific interface component.Transactions to be sent to an external
destination
can also be routed to the Issuer Authorization component for prescreening before the
transaction is sent on to the interface.
Issuer-to-Acquirer Routing
For transactions originating from an issuer interface source (e.g., chargebacks), the
destination is the acquirer interface of the original transaction. In this case, the
typical
source and destination roles are reversed. The issuer source is always external (i.e.,
the
name of an issuer interface) using the interface-specific Issuer Interface component,
while
the acquirer destination is also an external destination (i.e., the name of an acquirer
interface) using the interface-specific Acquirer Interface component.
File Update Routing

File Update Routing is a specialized form of routingcarried out by the File Update
Router
componentthat enables the routing of file update transactions in the system. File
update
transactions, as their name suggests, carry updates that can be applied to specific
types
of files either on the BASE24-eps system (such as the card and positive balance
data
sources) or on external systems (such as interchange warning bulletins and negative
card
files). Routing of file update transactions is handled separately from the routing of
other
transactions (refer to File Update Routing on page 103.
Transaction Routing
Sequential Routing
Sequential routing is a specialized form of transaction routing that can be built into
your
authorization scripts to enable a single transaction to be routed sequentially to one or
more
external destinations for processing. It differs from general transaction routing in that
it is
performed entirely by your authorization scripts.
From a general routing perspective, transactions are routed for authorization to an
Issuer
Authorization component and authorization script. At that point, the authorization
script
itselfwhich must have been written specifically to use sequential routingtakes
over to
perform the necessary processing.
Sequential routing provides an added level of flexibility in that you can set up your
BASE24-eps authorization scripts to involve multiple external entitiese.g., ACI
Proactive
Risk Manager (PRM), ACI Smart Chip Manager (SCM), or multiple hosts. For
instance,
by routing a transaction to ACI Proactive Risk Manager (PRM), you can provide
online real
time scoring as input into the authorization of the transaction.You could route a
transaction
to ACI Smart Chip Manager (SCM) as part of EMV processing.You could use
sequential
routing to support mobile top-up transactions or for integration with third-party bill
payment
providers. Or you could send transactions to a specific host for data aggregation.
Ultimately,
a single transaction response is journalled and returned to the consumer, who
perceives
the occurrence as one business transaction.
Sequential routing uses specific exported operators and requires modifications to the
authorization scripts to handle the various multiple routing functions. For information
on
setting up sequential routing, refer to Sequential Routing on page 133 and the
BASE24-eps
Scripting Manual.
Transaction Routing
Things to Think About Before Setting Up

Transaction Routing
Due to the highly flexible and configurable nature of BASE24-eps transaction routing,
there
are a number of key configuration concepts you need to understand and a number of
basic
questions that need to be answered before deciding how you want to set up your
transaction
routing.
Key Transaction Routing Concepts

Due to the highly flexible and configurable nature of BASE24-eps transaction routing,
there
are a number of key configuration concepts you need to understand before deciding
how
you want to set up your transaction routing. These concepts are summarized below,
with
references to the other topics that explain them.
Concept Description
Destination routing profiles are a set of destination and routing parameters that can be
assigned and reused. The controls that are part of each destination routing profile are
Destination Routing Profiles
quite powerful and understanding them helps to understand how you will need to configure
your routing. Destination routing profiles are described in Destination Routing Profiles on
page 66.
Prefixes are a primary identifier for routing transactions. When a transaction enters the
BASE24-eps system, the card prefix associated with the transaction may or may not be
Prefixes
recognized by BASE24-eps.Your routing configuration needs to be set up to handle both
situations. Prefixes are described in Prefixes on page 22.
Source routing profiles are a set of routing parameters, associated with the source of a
transaction, that can be assigned and reused. Every acquiring component must be
Source Routing Profiles
assigned a Source Routing Profile, which identifies the acquirer for participation business
relationships and points to the destination routing profiles to use in cases where transaction
prefixes are not recognized by BASE24-eps. Source routing profiles are described in
Source Routing Profiles on page 88.

Routing codes and business relationships are specific configuration parameters that
enable you to route transactions differently in cases where the acquirer and issuer have
Routing Codes and Business
Relationships
a business relationship. Routing Codes and Business Relationships are described in
Defining Business Relationships and Routing Codes for Your System on page 100.
From a routing perspective, file update transactions are handled differently from other
types of transactions. File update routing is described in File Update Routing on page
103.
File Update Routing
A script-based approach that enables your authorization scripts to route transactions to
multiple external entities.This approach requires modifying and adapting your authorization
Sequential Routing
scripts, but provides a great deal of added flexibility depending on how you want
transactions processed.

Transaction Routing
Key Questions to Deciding What Type of Transaction Routing

Configuration You Need
The following questions walk you through some of the things you need to consider
when
setting up routing.
Step Question Yes No
Identify each payment instrument Proceed to step 3.
BASE24-eps will need to recognize
for the card issuer.
If you plan to authorize transactions
on the system, identify the PAN
lengths and prefixes that will be
used with each payment instrument.
Do you plan to authorize
transactions for card issuers on the
system or route transactions for card
issuers to a host?
1
Identify the authorization scripts you
want to use for authorizing the
transactions for the card issuer.
Set up a prefix record for each prefix
and PAN length combination to be
used to identify each payment
instrument, specifying in each prefix
record a destination route profile
and route type that will direct the
transactions to the appropriate
authorization script or host interface.
Proceed to step 2.
No sequential routing is needed.
Proceed to step 3.
Identify and modify the necessary
scripts to include sequential routing.
Use these modified scripts as
destinations in your destination
routing profiles.
Do you want to involve multiple
external entities in authorizing
transactions for your card issuers
(i.e., do you want to perform
sequential routing )?
2
Note: Modifying scripts to include
sequential routing takes
considerable planning and testing.
Proceed to step 3.
Does your system support acquiring Proceed to step 3a. Proceed to step 4.
terminals?
3
Create a single source routing Proceed to step 3b.
profile and assign it to all of your
terminals.
Create a single destination routing
profile and use it for all transaction
routing from your terminals.
Are all transactions from all of your
terminals to be routed the same
way?
3a
Proceed to step 4.

Transaction Routing
No business relationship table
needs to be set up for your
terminals.
No routing codes need to be set
up.
Create a source routing profile for
each group of terminals to be
associated with a specific acquirer
and assign the profile to each
terminal in the group.
Create a separate destination route
profile for any issuer to be included
in a business relationship.
Do you want any groups of terminals
to be associated with specific
acquirers so that a business
relationship with an issuer can be
taken into account during routing?
3b
Specify only default routing codes
of all asterisks in your destination
routing profile.
Create a business relationship table
to associate the source routing
profiles assigned to your terminals
with the destination routing profiles
created for your issuers.
Proceed to step 3c.
Identify the transaction types that
can be accepted from these
terminals and tie them to route
codes in your business relationship
table.
Include route codes in your separate
destination routing profiles.
Proceed to step 3c.
Create a source routing profile for Proceed to step 4.
each group of terminals to be routed
the same.
profile for each group of terminals
to be routed the same.
Do you want certain groups of
terminals to be routed differently
from others (aside from any involved
in possible business relationships)?
3c
Proceed to step 4.
Do you intend to send outbound Proceed to step 4a Proceed to step 5.

transactions to interchanges?
4
Set up the Interchange Prefix File Proceed to step 4b.
in BASE24-eps, and include the
Does the interchange provide an
interface prefix file that you plan to
4a
use to identify prefixes to be routed name of the file in the
to them? INTERCHANGE prefix routing fields
of the source routing profile
information.
Proceed to step 5.
Identify the algorithm and include it Proceed to step 4c.
in the source routing profile
information.
Proceed to step 5.
Are the interchange transactions
identifiable using an algorithm?
4b
Return to step 4, and verify that
you know how you will route
outbound interchange transactions.
Specify the interchange as a default
in the source routing profile
information.
Proceed to step 5.
Can you route to the interchange by
default?
4c
Do you intend to accept inbound Proceed to step 5a. End of steps.
transactions from interchanges?
5

Transaction Routing
Create a single source routing Proceed to step 5b.
profile and assign it to all of your
interchange interfaces.
Create a single destination routing
profile and use it for all transaction
routing.
Are all transactions from all your
interchanges to be routed the same
way?
5a
End of steps.
No business relationship table
needs to be set up for the
interchanges.
No routing codes need to be set
up for the interchanges. Specify
only default routing codes of all
asterisks in your destination routing
profile
Create a source routing profile for
each interchange to be associated
with a specific acquirer and assign
the profile to each interchange
interface.
profile for any issuer to be included
in a business relationship.
Do you want one interchange or any
groups of interchanges to be
associated with specific acquirers,
so that a business relationship with

an issuer can be taken into acccount
during routing?
5b
Create a business relationship table Proceed to step 5c.
to associate the source routing
profiles assigned to your
interchanges with the destination
routing profiles created for your
issuers.
Identify the transaction types that
can be accepted from these
interchanges and tie them to route
codes in your business relationship
table.
Include route codes in your separate
destination routing profiles.
Proceed to step 5c.
Create a source routing profile for End of steps.
each interchange or group of
Do you want certain groups of
interchanges to be routed differently
5c
interchanges whose transactions
are to be routed the same.
profile for each group of
interchanges to be routed the same.
from others (aside from any involved
in possible business relationships)?
End of steps.

Transaction Routing
Destination Routing Profiles

Destination routing profiles are modular sets of routing configuration parameters that
designate destinations and related processing based on certain key aspects of a
transaction.
They play a major role in transaction routing and provide a great deal of routing
flexibility.
As such, it is helpful to examine individual aspects of these profiles to understand
how
they work and how to set them up for your system.
Each profile can be thought of as containing the following configuration parameters.
Name and Description - each profile is identified by a name and optional
description.
The name is used throughout the BASE24-eps system to identify the destination
routing
profile.
Transaction Table - a table consisting of multiple entries you set up to match
transactions
against. If a transaction matches the criteria for a specific entry, the entry is selected.
Each table entry has a set of general information, destination matrix, and default
processing associated with itthat you set up.
General Information - General processing parameters associated with a single
transaction
table entry, which includes default processing (i.e., what to do if a transaction cannot
be routed).
Destination Matrix - the set of destinations and related controls associated with a
single
transaction table entry.
Destination routing profiles are configured using the Destination Routing Profile
Configuration window (Configure > Routing > Profile Description > Destination
Routing
Profile) and Routing Configuration - Destination window (Configure > Routing >
Destinations). The profile information on these windows is stored in the Route data
source
(Route) and used to build the Route external memory table (Route_OLTP).
What is a Profile?
group
to and shared amongst multiple entities. They allow you to define one set of values
and
use those same values over and over, saving time in set up and adding consistency.
In
the case of destination routing profiles, they allow one or more issuers to share
routing
configurations.
Transaction Routing
Destination Routing Profile Name and

Description
Each destination routing profile is identified by a profile name and optional profile
description.
Each destination routing profile is identified by a profile name and profile description.
The
profile name is used throughout the BASE24-eps system to identify the profile. The
description can be used to provide a descriptive label for the profile (this is many
times
useful because the profile name itself can be cryptic depending on the naming
conventions
you use).You might, for example, use the description to highlight the business
purpose of
the profile.
The profile name is entered in the Destination Routing Profile field on the Routing
Configuration - Destination window (Configure > Routing > Destinations) as the
first
step in adding a profile. Once a profile name is entered, you can enter routing
information
for the profile. Then, when you click save to add the profile, a dialogue box is
displayed
and you are prompted to enter a profile description. Both the name and description
are
required; the destination routing profile cannot be added without them.
Once a destination routing profile has been added, it becomes available for selection
in
Destination Routing Profile drop-down lists on other windows.
Setting Up a Default Destination Routing Profile With a Name

of All
Asterisks (****************)
Due to the selection hiararchy used to search the Transaction Table in the
destination
routing profile, you may want to or need to create a default destination routing profile
that
has a name of all asterisks (****************). For more information on how the
transaction
table in the destination routing profile is used, refer to Destination Routing Profile
Transaction Table on page 68.
Transaction Routing
Destination Routing Profile Transaction

Table
Each destination routing profile has a transaction table associated with it. The
transaction
table consists of one or more entries you set up for comparing transactions to.
During routing, once a destination routing profile and route code are identified for a
transaction, they are combined with several other pieces of transaction information
and
compared to the transaction table criteria.
If a transaction matches the transaction criteria for a particular entry, which can
include
wildcarding (asterisk values), that entry is selected for the transaction, along with the
general information and destination matrix defined for the entry.
The transaction table is created using the Routing Configuration - Destination
window
(Configure > Routing > Destinations).
Transaction Match Criteria

The following are the values that are compared to the transaction information to find
a
match.You set up various combinations of these values in the table in order of
selection
preference.
Destination Routing Profile Transaction Table Values
Cust Authentication
Method
Destination Routing Route Code Account Type 1 Account Type 2
Profile
This transaction table information combines to form the key of the Route data source
(Route) records, which contain the destination routing data associated with the entry.
The
following table identifies the specific transaction fields that are compared to the
values in
the table.
Transaction Table Field The Transaction Value Compared to the Table Field
The destination routing profile (name) identified for the transaction, carried in the
Issuer Route Profile TDE of the transaction.
If no exact match is found for the Issuer Route Profile TDE, table entries are searched
for an exact match on a default destination routing profile name of **************** (16
asterisks). If no entries contain 16 asterisks, there is no match.
Destination Routing Profile
The Routing Code identified for the transaction.
If no exact match is found, table entries are searched for an exact match on a default
route code of **************** (16 asterisks). If no entries contain 16 asterisks, there
is no match.
Route Code
Note: For issuer-to-acquirer routing, a route code of **************** (16 asterisks) is
always used.

Transaction Routing
Transaction Table Field The Transaction Value Compared to the Table Field
The Account 1 Type identified for the transaction, carried in the Processing Code
TDE of the transaction.
Table entries containing ** match on any account type.
Account Type 1
The Account 2 Type identified for the transaction, carried in the Processing Code
TDE of the transaction.
Table entries containing ** match on any account type.
Account Type 2
The Cardholder Authentication Method identified for the transaction, carried in the
Point of Service TDE of the transaction.
Table entries containing * match on any method.
Cust Authentication Method
Selection Hierarchy/Preferences
The Router component uses the preference hierarchy shown in the table below for
comparing transactions to the transaction table. The hierarchy is set up to enable the
Router component to find the most specific matches first and the least specific
matches
last. This enables you to set up general routing entries that can be used for the
majority
of transactions and override them with more specific entries for special routing
purposes.
The Router component cycles through the Route external memory table (built from
Route
data source) using these preferences until a matching entry is found.
Use of asterisks: Asterisks in the Account 1 Type, Account 2 Type, and Cardholder Authentication Method fields
denote a match on any value. For example, asterisks in the Account 1 Type field would match any account type.
By contrast, where the table denotes asterisks in the Destination Routing Profile and Route Code fields
(highlighted in
gray), the Router component is looking for an exact match on **************** (16 asterisks). In order to match the
former,
a Destination Profile must be created with the name **************** and to match the latter, a route code must be
created
called ****************.
When routing from an issuer to an acquirer, a route code of 16 asterisks is always used.
Search Search Criteria
Hierarchy
Preference Cust
Authentication
Method
Destination Route Code Account Type 1 Account Type 2
Routing Profile
1 Exact match Exact match Exact match Exact match Exact match
2 Exact match Exact match Exact match Exact match *
3 Exact match Exact match Exact match ** Exact match
4 Exact match Exact match Exact match ** *
5 Exact match Exact match ** Exact match Exact match
6 Exact match Exact match ** Exact match *

7 Exact match Exact match ** ** Exact match
8 Exact match Exact match ** ** *
9 Exact match **************** Exact match Exact match Exact match

Transaction Routing
Hierarchy
Preference Cust
Authentication
Method
Destination Route Code Account Type 1 Account Type 2
Routing Profile
10 Exact match **************** Exact match Exact match *
11 Exact match **************** Exact match ** Exact match
12 Exact match **************** Exact match ** *
13 Exact match **************** ** Exact match Exact match
14 Exact match **************** ** Exact match *
15 Exact match **************** ** ** Exact match
16 Exact match **************** ** ** *
17 **************** Exact match Exact match Exact match Exact match
18 **************** Exact match Exact match Exact match *
19 **************** Exact match Exact match ** Exact match
20 **************** Exact match Exact match ** *
21 **************** Exact match ** Exact match Exact match
22 **************** Exact match ** Exact match *
23 **************** Exact match ** ** Exact match
24 **************** Exact match ** ** *
25 **************** **************** Exact match Exact match Exact match
26 **************** **************** Exact match Exact match *
27 **************** **************** Exact match ** Exact match
28 **************** **************** Exact match ** *
29 **************** **************** ** Exact match Exact match
30 **************** **************** ** Exact match *
31 **************** **************** ** ** Exact match
32 **************** **************** ** ** *

Transaction Routing
Destination Routing Profile General

Information
General information in the destination routing profile contains general processing
controls
associated with a single transaction table entry. Once a transaction table entry is
selected
for routing a transaction, these controls apply to the transaction. These controls are
set on
the General Information tab of the Routing Configuration - Destination window
(Configure
> Routing > Destinations).
Floor Limits
Floor limits are amount thresholds that enable you to differentiate transaction
handling
based on whether a transaction is over or under a specific amount: transactions over
a
floor limit can be handled one way; transactions under the floor limit can be handled
differently.
To illustrate, if you set a floor limit to $50 USD, you can set up one type of handling
for
transactions of $50 or less and another type of handling for transactions more than
$50.
In this case, the floor limits control which set of destinations are used in a particular
destination matrix.
The floor limits for each transaction table entry are set on the General Information
tab of
the Routing Configuration - Destination window (Configure > Routing >
Destinations).
The currency for the floor limit is based on the country abbreviation value set in the
LGNT_COUNTRY_ABBR Environment attribute. The currency used for these limits
is
displayed immediately to the right of the limit amount on the window.
Note: A different floor limit is used for default processing. For information about this
floor
limit, refer to Default Authorization on page 139.
Floor Limit Settings
Field Description
Set to the floor limit you want to use for the destination matrix.Transactions equal to or less
than this amount are handled as under-the-floor transactions. Transactions greater than
this amount are handled as over-the-floor transactions.
Destination Route Floor
Limit
Specifies the algorithm to use for alternate floor limit checking if alternate floor limit check
is enabled by the Alternate Floor Limit Check Indicator flag.
Currently, the only product value supported in this field is EMV_ROUTE, which is used with
EMV processing. For information about EMV routing, refer to the BASE24-eps EMV Support
Guide.
Alternate Floor Limit
Algorithm
Place a check mark in this field if alternate floor limit checking is to be enabled.
If alternate floor limit checking is enabled, the Alternate Floor Limit Algorithm is used for
floor limit checking. Otherwise, the standard floor limit checks are performed.
Alternate Floor Limit
Check Indicator

Transaction Routing
Floor Limit Settings
Field Description
Typically, alternate floor limit checks are implemented through customer modifications to
BASE24-eps. However, alternate floor limit checks can be used with standard EMV
processing. For information about EMV routing, refer to the BASE24-eps EMV Support
Guide.
Disable Transaction Auditing

The Transaction Auditing Indicator check box disables transaction/TDE auditing. It
should
be set to a check mark when sequential routing is used in scripts.
The reason for this is that in sequential routing the transaction is sent to multiple
issuers
and the cumulative effect of the transaction data is maintained. If the transaction
needs to
be rerouted for one of the issuers, the changes made to the transaction are not to be
backed out (undone).
Default Processing
If a transaction cannot be routed to a primary or alternate authorizer using a selected
destination matrix, default processing is invoked.

Default processing is straightforward: the amount of the transaction is compared to a
default
floor limit and then either approved, declined, or referred based on whether it is over
or
under the floor limit. This is call default authorization. Default processing is
configured for
each Transaction Table entry.
Default processing is performed by the Default Authorization component, which is
invoked
by the Router component. Scripts are not invoked to carry out default authorization.
Note: No impacting is performed for transactions authorized by default.
Default processing is defined in the Default Authorization Information fields on the
General
Information tab of the Routing Configuration - Destination window (Configure >
Routing
> Destinations).
The currency for the default floor limit is based on the country abbreviation value set
in the
LGNT_COUNTRY_ABBR Environment attribute. The currency used for these limits
is
Default Authorization Settings
Field Description
Specify the floor limit used for differentiating default actions. For example, if you set this
field to $9.99 and the transaction amount is greater than the $9.99, the Over Limit Action
Floor Limit
would be taken. If the transaction amount is equal to or less than the $9.99, the Under Limit
Action is taken.

Transaction Routing
Field Description
Specifies whether to approve, refer, or decline the transaction if the transaction amount is
greater than the floor limit. The action codes used in each case are as follows:
000 Approved
Over Limit Action
107 Deny, refer to card issuer
912 Deny, card issuer not available
Specifies whether to approve, refer, or decline the transaction if the transaction amount is
equal to or less than the floor limit. The action codes used in each case are as follows:
000 Approved
Under Limit Action

Transaction Routing
Destination Routing Profile Destination

Matrix
The destinations you define within a destination routing profile orchestrate how a
transaction
will be processed. All of these destinations are configured on the Routing
Configuration -
Destination window (Configure > Routing > Destinations).

Transactions are compared to the entries in the transaction table of the destination
routing
profile. Each set of entries in the transaction table points to a specific destination
matrix
to be used to route a transaction.
A destination matrix consists of six destination sets36 different possible
destinations in
all, as represented in the following table. There is a great deal of built-in flexibility, but
not
all destinations are required. It depends on the routing required by your business.
Destinations and Transaction Stages

Destinations within the destination matrix are defined in sets. Sets are intended for
use
under different circumstances (as implied by the table), but each set basically
defines the
same thing: the routing to be used for different stages of a transaction. A single set of
destinations is highlighted in the following table. This particular set identifies primary
Transaction Routing
destinations to be used for transactions that are under the floor limit (set in the
General
Information).
The following are the actual values that define a single set of destinations. They
define to
BASE24-eps where a transaction is to be routed at different stages of its
processing.These
values are defined in the destination routing profile.
Pre-Screen Destination
The Pre-Screen destination specifies a destination to which BASE24-eps is to send
a
transaction for prescreening. Prescreening enables the BASE24-eps system to make
preliminary standard checks on transactions and decline those that do not meet the
preliminary requirements before transactions are sent to a host or interchange
destination
for authorization. This prevents unnecessary processing by the host or interchange.
Transaction Routing
Typical prescreening processing for cards may include checking the card status,
expiration
date, card verification, verifying the cardholder PIN, or checking withdrawal limits.
For
check-based transactions, prescreening might include screening the checks for
preapproval,
predeclines, or stop payments.
If a Prescreen destination is specified, the transaction is sent to that destination first.
If
there is not a Prescreen destination specified, the transaction is sent to Authorization
destination.
If prescreening is required before a transaction is to be routed to host or interchange,

you
would enter IAUT in the Component ID field and the name of the prescreening
authorization
script configuration in the Name field. The following is an example where the
PCBA_PUR_PS script configuration is set up to handle request message types:
Stage Component ID Name Required to Host Advice Only
Pre-Screen IAUT PCBA_PUR_PS Not Used
If the transaction does not pass the prescreening evaluations imposed by the
specified
script, the transaction is denied. If it does pass the prescreening, the transaction is
sent
to the Authorization destination.
Note: The BASE24-eps database is impacted during prescreening only if a
transaction
is denied as a result of prescreening checks. The BASE24-eps database is not
impacted
when a transaction passes the prescreening checks because the transaction is not
yet
committed.
Authorization Destination
The Authorization destination is the destination to which a transaction request is sent
to
be authorized.
For transactions authorized on the BASE24-eps system, the destination is the Issuer
Authorization component and the name of an authorization script configuration.The
following
is an example:
Authorization IAUT PCBA_PUR Not Used
For transactions authorized on a host or an interchange, the destination is the

interface
component that communicates with the host or interchange. The following is an
example:
Authorization INTFVISA VISA Not Used

Transaction Routing
Advice Destinations
The Advice destinations are the destinations to which transaction advices are to be
sent.
You can configure up to two advices to be generated and routed to a host or
interchange
for each transaction processed. The destinations are denoted using the component
ID of
the component to which the advices are to be sent.
These fields also control whether or not advices are generated. If no destination is
set, no
advices are generated or sent. If a destination is configured, you can also control the
circumstances under which an advice is generated, using the Required to Host
Advice
Only field. Values can be set as follows:

Required to Host Advice Only Set
Value Description
Not Set if you want no advices sent to the specified destination.
Denied Set if you want advices sent to the specified destination for denied transactions only.
Approved Set if you want advices sent to the specified destination for approved transactions only.
Set if you want advices sent to the specified destination for approved and denied
transactions.
Both
The following is an example of how you might set up advices to be sent for approved
transactions. In this case, the advices are sent to the HISO93_ISS_01 host interface
component.
Advice 1 INTFHI93 HISO93_ISS_01 Approved
Impact Destinations
The Impact destinations are the destinations to which approved transactions can be
sent
for impacting.
Impacting is the application of the transaction to account totals and usages
maintained on
the BASE24-eps system. If cardholder account balances and usages are maintained
on
the BASE24-eps system, you can configure the Router component to send the
transaction
to an authorization script configuration to impact the cardholders balance and usage
information if the transaction is approved.
Impacting destinations are typically only used when transactions are authorized by a
host
and data sources need to be updated in the BASE24-eps system. Impacting
destinations
are not typically required if BASE24-eps is authorizing transactions, because the
data
sources are updated as a part of the authorization process.
Transaction Routing
You can configure up to two destinations for impacting, each consisting of a
component
ID and script. If impacting is required, you would enter IAUT in the Component ID
field and
the name of the impacting authorization script configuration in the Name field.The
following
is an example where the PCBA_PUR_IMP script configuration is set up to handle
response
message types:
Impact 1 IAUT PCBA_PUR_IMP Not Used
Floor Limits
Each destination matrix has a floor limit associated with it. This floor limit is defined
in the
Destination Route Floor Limit field on the General Information tab of the Routing
Configuration - Destination window (Configure > Routing > Destinations).
When a destination matrix is selectedbased on a transaction table entry match

the
transaction amount is compared to the floor limit and a corresponding set of
destinations
is chosen for the transaction.
Under-the-Floor If the transaction amount is equal to or under the specified floor
limit,
the Under Floor destinations are used.
Over-the-Floor If the transaction amount is greater than the specified floor limit,
the
Over Floor destinations are used.
Transactions over the floor limit would use the highlighted destinations in the matrix
below.
Transactions equal to or under the floor limit would use the destinations in the
unhighlighted
columns of the matrix below
Transaction Routing
Primary and Alternative Destination Sets

Destinations are organized into Primary, Alternative 1, and Alternative 2 destination
groups
to provide for fallback processing.The Router component routes and, if necessary,
reroutes
the transaction to the primary and alternative destinations as follows:
Primary Destinations Tried first.
Alternative 1 Destinations Tried if a transaction sent to a primary destination
either
times out or fails, or the named script is disabled.
Alternative 2 Destinations Tried if a transaction sent to an Alternative 1
destination
either times out or fails, or the named script is disabled.
To illustrate: If a transaction sent to the primary authorization destination either times
out
or fails, the transaction is rerouted to the first alternative authorization destination.
Then,
if the transaction sent to the first alternative authorizer either times out or fails, the
transaction is rerouted to the second alternative authorization destination.The matrix
below
highlights the destinations used for an over-the-floor limit transaction.
How Alternative Destinations for Authorization Affect Other

Transaction Stages
The Pre-Screen, Advice, and Impact destinations used are always based on the
authorization destination used.Thus, whether a primary or alternate authorization
destination
is used affects the Pre-Screen, Advice, and Impact destinations used as well.
Transaction Routing
In the example below, if an over-the-floor transaction had to be rerouted to
alternative
destination 1 for the Authorization, the alternate destination 1 Pre-screen, Advice,

and
Impact destinations would be the destinations used for the transaction regardless of
what
was set in the primary destination Pre-screen, Advice, and Impact destinations.
Thus, you
will want to consider the Pre-screen, Advice, and Impact destinations that go with
each
authorization destination and set them accordingly.
For example, if the primary authorization destination is a host, and the alternate
destination
is BASE24-eps for stand-in authorization, you might set up a Primary Pre-Screen
destination
to prescreen the transaction before sending it to the host. In this case, you would not
typically set up an Alternate Destination 1 Pre-Screen destination because BASE24eps
would be performing full stand-in authorization and prescreening would not be
required.
However, if you did configure an Alternate Destination 1 Pre-Screen destination, it
would
be performed. Similarly, you might set up Primary Destination Impact destinations to
update
the BASE24-eps data sources following a host authorization, but would not typically
set
up Alternate Destination 1 Impact destinations if BASE24-eps was standing in to
authorize
the transaction, because BASE24-eps would update its data sources as a part of its
authorization processing.
Setting Up Stand-in Authorization

If an external processor is configured as the primary authorizer destination for a
transaction,
you can configure the BASE24-eps system, or another external processor, to
perform
stand-in authorization when the primary external processor is unavailable.
To configure the BASE24-eps system to stand-in for the primary external processor,
you
would configure the Issuer Authorization component and an authorization script
configuration
as the first alternate authorizer.To configure another external processor to stand-in
for the
primary external processor, you would configure an Interface component and
interface
name of the external processor standing in as the first alternate authorizer.
Transaction Routing
The following table highlights the destinations as they might be chosen for stand-in
authorization.
In this case, the primary destination might be a host, set up something like the
following:
Authorization <host ID> <host name> Not Used
If the alternative 1 destination is BASE24-eps, the destination might be configured as

follows.
Authorization IAUT PCBA_PUR Not Used
If the alternative 1 destination is an interchange, the destination might be configured

as
follows.
Authorization <interface ID> <interface name> Not Used
Script Selection
When the Router component selects the Issuer Authorization component and the
name
of an authorization script configuration as the destination for a transaction, the Issuer
Authorization component must still determine the actual script to be executed. The
Issuer
Authorization component reads the Authorization Script external memory table
(Authorization_Script_OLTP) using the name of the authorization script configuration
from
the Authorizer Routing Destination TDE and the message type of the transaction
from the
Message Type Identifier (MTI) TDE. When a matching entry is found, the component
retrieves the name of the actual script to be executed.
Transaction Routing
An authorization script configuration comprises individual scripts for the various
transaction
message types (e.g., financial request, financial advice, reversal advice, etc.). An
authorization script configuration name can be the same as an actual script or it can
be
different.
The Authorization Script external memory table is built from data entered on the
Authorization Script Configuration window (Configure > Script > Authorization
Script).
For detailed information on configuring authorization scripts, refer to Configuring
Script
Sets to Use as Routing Destinations on page 122 and the BASE24-eps Scripting
Manual.
Transaction Data Elements (TDE) in which Destination

Information
is Carried
Transactions are routed and re-routed by the Router component. Each time a
transaction
is routed or rerouted, the Router component invokes the Transaction component to
update
the appropriate TDE with the new routing destination (i.e., first or second alternate in
the
case of re-routing). Depending on the destinations you set up, the following TDEs
can be
updated during rerouting:
Pre-screen Routing Destination

Authorization Routing Destination
Advice 1 Required
Advice 2 Required
Impact 1 Routing Destination
Impact 2 Routing Destination
Transaction Routing
Typical Destination Routing Profiles

Each type of processor can have its own unique routing and authorization
requirements.
Examples are provided here for terminal acquirers, financial switches, and card
issuers.
Keep in mind that a single BASE24-eps institution can be set up for all three types of
processing.
Terminal Acquirers
Terminal acquirers typically perform basic pre-screening, interface to multiple
interchanges,
and have little or no stand-in authorization capabilities. Typical settings for terminals
acquirers might be as follows:
Destination Matrix
Primary Destination Alternative Destination 1 Alternative Destination 2
Validates Pre-Screen None Pre-Screen None
transaction fields
Pre-Screen
(e.g., expiration
dates, card track
data checks, etc.)
using scripts to
obtain better
interchange rates.
Same as primary
but using a
Same as primary Authorization
but using a
Routes to an Authorization
interchange
Authorization
interface (e.g., different different
interchange
processor.
interchange
processor.
MasterCard, Visa,
etc.).
Advice 1 None Advice 1 None Advice 1 None
Impact 1 None Impact 1 None Impact 1 None
Financial Switches
Financial switches typically perform basic pre-screening, interface to multiple
interchanges,
and have substantial stand-in authorization capabilities. Typical settings for financial
switches might be as follows:
Destination Matrix
Negative card Pre-Screen None Pre-Screen None

checks and PIN
Pre-Screen
verification using
scripts.

Transaction Routing
Destination Matrix
Stand-in Authorization None
authorization
Routes to a card Authorization
issuer interface.
Authorization
using the positive
card authorization
method and
scripts.
Route to the card Advice 1 None
issuer.
Advice 1 None Advice 1
Updates usage Impact 1 None Impact 1 None
accumulation
limits.
Impact 1
Card Issuer
Card issuers typically perform basic pre-screening, route to a back-end host for
primary
authorizations, and have substantial stand-in authorization capabilities in the event
that
the host is not available. They also send advices to a host and need to apply
transactions
to the BASE24-eps card and account database. Typical settings for card issuers
might be
as follows:
Destination Matrix
Validation against Pre-Screen None Pre-Screen None
positive card data
using scripts.
Pre-Screen
Stand-in Authorization None
authorization
Routes to a host Authorization
interface.
Authorization
using the positive
card with balances
authorization
method and
scripts.
Route to the host Advice 1 None
interface.
Advice 1 None Advice 1
Updates balances Impact 1 None Impact 1 None
in stand-in
Impact 1
database on
BASE24-eps
system.

Transaction Routing
Transaction Routing Worksheets

The following are some worksheets you can print or copy to use to collect the
information
you will need for defining your destination routing profiles.
Transaction Table Worksheet

The following table can be used as a worksheet to compile the combinations of
transaction
values to associate with the destination routing profile. Note that each entry you
define ties
to a specific destination matrix. These values are entered on the Routing
Configuration Destination window (Configure > Routing > Destinations).
Transaction Table
Cardholder Authentication
Method
Destination Route Code Account 1 Type Account 2 Type
Routing Profile

Transaction Routing
Destination Matrix Worksheet

The following table can be used as a worksheet to represent one set of under-thefloor
and over-the-floor destinations for a destination matrix.You can use the worksheet to
create a set of primary, alternate 1, or alternate 2 destinationsentered on the
Primary
Destination, Alternate Destination 1, and Alternate Destination 2 tabs of the Routing
Configuration - Destination window (Configure > Routing > Destinations).
Destination Tab Worksheet (Primary, Alternate 1, or Alternate 2)
Floor Description Component ID Name Required to Host
Under the Pre-screen Not used
Floor
Authorization
Advice 1 Approved - Denied - Both
Impact 1 Not used
Impact 2
Over the Pre-screen
Floor
Authorization
Impact 1 Not used
Impact 2

Transaction Routing
Tying Destination Routing Profiles to

Prefixes
Destination routing profiles are tied into BASE24-eps processing at the prefix level,
based
on known (on-us) and unknown (not-on-us) prefixes, and to source routing profiles in
order
to establish business relationships (for establishing routing codes).
Destination routing profiles are tied into BASE24-eps processing using the field
settings
shown in the table below.
Each of these fields provides a set of existing values you can select from in a
dropdown
list, or you can click on the field label link to enter a new value on the Source Routing
Profile Configuration window (Configure > Routing > Profile Description > Source
Routing Profile).
Association Window Tab Field
Destination Routing
Profile
On-Us Prefix Configuration window (Configure Issuer Information
> Prefix > On-Us)
Known (On-Us)
Prefixes
Destination Routing
Profile
System Prefix Configuration window (Configure no tab
> Prefix > Not-On-Us > System Prefix)
Unknown (Not-On-Us)
Prefixes
Destination Routing
Profile
Routing Configuration Destination/Source no tab
Relationship window (Routing>
Destination/Source Relationship)
Source Code Profiles

Transaction Routing
Source Routing Profiles

Source routing profiles are modular sets of routing configuration parameters that are
tied
to the transaction acquirers defined to BASE24-eps.
They work in conjunction with prefix routing to identify how to process transactions
that
cannot be identified as having on-us prefixes. For these transactions, the profiles
also
identify the destination routing profiles to be used, which is necessary for
establishing a
business relationship (refer to Defining Business Relationships and Routing Codes
for
Your System on page 100).
Every acquiring endpoint must have a source routing profile associated with it to
define
how transactions received from the acquirers are handled. Refer to Tying Source
Routing
Profiles to Acquirers on page 95 for information about how this is done.
Each profile can be thought of as containing the following configuration parameters.
Name and Description - each profile is identified by a name and optional

description.
The name is used throughout the BASE24-eps system to identify the source routing
profile.
Not-On-Us Prefix Selection Table - a table consisting of multiple entries you set up
to
compare transaction prefixes to. If a transaction prefix matches the criteria for a
specific
entry, the processing information is used for the transaction.
What is a Profile?
group
to and shared amongst multiple entities. They enable you to define one set of values
and
use those same values over and over, saving time in set up and adding consistency.
In
the case of source routing profiles, they allow one or more acquirers to share routing
configurations.
Transaction Routing
Source Routing Profile Name and

Description
Each source routing profile is identified by a profile name and optional profile
description.
Both are entered on the Source Routing Profile Configuration window (Configure >
Routing
> Profile Description > Source Routing Profile).
The profile name is used throughout the BASE24-eps system to identify the profile.
The
optional description can be used to provide a descriptive label for the profile (this is
many
times useful because the profile name itself can be cryptic depending on the naming
conventions you use).You might, for example, use the description to highlight the
business
purpose of the profile.
Once a source routing profile has been entered and saved, the name becomes
available
for selection in Source Routing Profile drop-down lists on other windows.
Setting Up a Default Source Routing Profile With a Name of All

Asterisks (****************)
You may want or need to set up a default source routing profile that has a name of all
asterisks (****************). This might be necessary to define a system-wide default
profile
that could be used for any acquirer in the BASE24-eps system.
Transaction Routing
Source Routing Profile Not-on-Us Prefix

Selection Tables
A not-on-us prefix selection table is essentially a list, in priority order, of methods to
be
carried out for identifying a not-on-us prefix.
When attempting to process a not-on-us prefix, BASE24-eps uses the source routing
profile
associated with the transaction to identify the not-on-us prefix selection table, which
is
used to identify how a not-on-us prefix is to be processed for that source routing
profile.
Using the table to Recognize a Not-on-us Prefix

for
Processing
When trying to find a match on a not-on-us prefix, the search specified by the first
table
entry is tried, following by the second table entry and third, and so on until a match is
found.
Once a match is found, the table entry further defines how the transaction is to be
processed.
You define the not-on-us prefix selection table on the System Prefix Configuration
window
(Configure > Prefix > Not-On-Us > System Prefix). The information from the
System
Prefix Configuration window is used to populate the System Prefix data source
(System_Prefix) from which the System Prefix external memory table
(System_Prefix_OLTP)
is built.
Refer to Not-on-Us Prefix Search Methods on page 90 for an explanation of how
different
not-on-us search methods can be configured for the not-on-us prefix selection table.
If the Not-on-Us Prefix Selection Table Does Not Produce a

Match
If a default method is not configured on the System Prefix Configuration window
(Configure
> Prefix > Not-On-Us > System Prefix) and the issuer cannot be determined, the
transaction is logged to the journal profile associated with the value NOFI (No
Financial
Institution).
Not-on-Us Prefix Search Methods

There are three basic types of not-on-us prefix search methods that can be used in a
not-on-us prefix selection table: Interchange Prefix method, Algorithm method, and
Default.
Transaction Routing
Interchange Prefix Search Method

The interchange prefix search method involves searching a specific Interchange
Prefix
data source for a prefix match. Typically, searches of this type are defined first
because
they are looking for exact prefix matches.
Many interchanges periodically provide tapes or files containing the valid prefixes of
its
members to each of their member institutions. BASE24-eps enables you to place this
information in an Interchange Prefix data source using IPF refreshes.You can also
use
the Interchange Prefix Configuration window (Configure > Prefix > Not-On-Us >
Interchange Prefix) to create and maintain Interchange Prefix data sources in the
event
that prefix tapes are not provided by an interchange.
To create an entry in the not-on-us prefix selection table using the interchange prefix
search
method for routing, create the entry on the System Prefix Configuration window
(Configure
> Prefix > Not-On-Us > System Prefix) using the following key values.
Field Setting
Type Set to INTERCHANGE PREFIX.
Value Specify the assign name of the interchange prefix data source to be searched.
Institutions that send transactions to multiple interchanges can support multiple

Interchange
Prefix data sources.Thus, you can define multiple entries of this type to allow for
searching
these multiple data sources.
Typically, interchange prefix searches are defined first in the table (followed by
algorithm
and default searches), because they are based on exact prefix matches.
Since not-on-us prefix selection tables are tied to source routing profiles, it may
make
sense to sequence the entries based on the type of traffic received from the acquirer.
For
example, if it is known that a large percentage of transactions received from a group
of
acquirers using a specific source routing profile is destined for a particular
interchange, it
might make sense to place the prefix search through that interchange prefix data
source
first.
In the following truncated entry example, two interchange prefix files would be
searched
in order. The first would be the Visa prefixes and the second would be the MDS
prefixes.
If a prefix is found, the processing data from the entry would be used.
Type Value
INTERCHANGE PREFIX IPRFX_VISA
INTERCHANGE PREFIX IPRFX_MDS
Transaction Routing
Algorithm Method
The algorithm method involves comparing a prefix and the PAN length of a card
number
to a specific algorithmone that identifies a specific category of issuer for purposes
of
routing (typically, the algorithms identify issuers associated with a specific
interchange).
Typically, these searches are defined following the Interchange Prefix searches.
Although you may not have information available to recognize a specific prefix or
card, the
interchange to which a card belongs is many times recognizable by applying certain
algorithms to the card number, which would be enough to route the transaction to the
interchange for processing. In that case, the interchange would be able to route the
transaction to the appropriate issuer.
To create an entry in the not-on-us prefix selection table using an algorithm search
method
for routing, create the entry on the System Prefix Configuration window (Configure >
Prefix > Not-On-Us > System Prefix) using the following key values.
Field Setting
Type Set to ALGORITHM.
Specify the algorithm to be used. Any algorithm specified here must be defined on the System
Algorithm Configuration window (Configure > Prefix > Not-On-Us > System Algorithm).
The following algorithms are typically configured:
American Express
Value
Diners Club
Discover
MasterCard
Visa
Institutions that send transactions to multiple interchanges can support multiple

algorithms.
Thus, you can define multiple algorithm entries in the not-on-us prefix selection table.
Typically, algorithm search entries are defined in the table following the interchange
prefix
searches. The reason, is that interchange prefix searches are based on exact prefix
matches; the algorithm are not exact matches.
In the following truncated entry example, three algorithm searches would be applied
to the
transaction in order.The first would be the Visa algorithm check, followed by the
MasterCard
algorithm check, followed by the American Express algorithm check. If a match is
found,
the processing data from the entry would be used.
Type Value
ALGORITHM Visa
ALGORITHM MasterCard
ALGORITHM American Express

Transaction Routing
Default Prefix Handling

The default method enables you to assign processing parameters by default when a
matching prefix cannot be found after exhausting all of the search methods
discussed
above. Thus, this method should only be used in the last entry for a not-on-us prefix
selection table.
To create a default entry in the not-on-us prefix selection table, create the entry on
the
System Prefix Configuration window (Configure > Prefix > Not-On-Us > System
Prefix)
using the following key values.
Field Setting
Type Set to DEFAULT.
Value Leave blank.
Selection Table Example

be
The following example defines the Type and Value key fields of a sample not-on-us
prefix
selection table.
Not-on-Us Prefix Selection Table
Priority Type Value
1 INTERCHANGE PREFIX IPRFX_VISA
2 INTERCHANGE PREFIX IPRFX_MDS
3 ALGORITHM American Express
4 ALGORITHM Discover
5 DEFAULT
Based on the table above, the following searches would be attempted:

1. Exact prefix match in the Visa Interchange Prefix data source (IPRFX_VISA).
2. Exact prefix match in the MasterCard Debit Switch (MDS) Interchange Prefix data
source
(IPRFX_MDS).
3. The American Express algorithm would be applied to the transaction prefix and
card
number.
4. The Discover algorithm would be applied to the transaction prefix and card
number.
5. The default entry parameters would apply if a match could not be found in the
prior
entries.
Transaction Routing
Not-On-Us Processing Parameters

be
The following information is specified for each entry in the not-on-us prefix selection
table.
If a transaction prefix matches an entry, the following information from the table is
used
for the transaction:
Field Description
The name of the destination routing profile to use for the transaction. This value
is moved to the Issuer Route Profile TDE.

The issuer ID to be journaled with the transaction. This value is moved to the
Issuer TDE.
Note: This field is used in authorization, but not specifically for routing.
Issuer ID
The name of the limit profile to be used for the transaction. This value is moved
to the Limit Profile TDE.
Limit Profile
The name of the surcharge profile to be used for the transaction. This value is
moved to the Surcharge TDE.
Issuer Surcharge Profile
The instrument type to be assumed for the transaction. This value is moved to
the Instrument Type TDE.
Instrument Type
The route type value to be used for the transaction. Values are as follows:
Acquirer and Issuer Means that a business relationship should be taken into
consideration, and transactions will be evaluated for a route code.
Route Type
Issuer Only Means that a business relationship does not exist for this prefix
and transactions will not be evaluated for a route code.
This value is moved to the Route Type TDE.
Refer to Enabling and Disabling the Use of Routing Codes at the Prefix Level
on page 99 for more information about how this field is used.

Transaction Routing
Tying Source Routing Profiles to Acquirers

You must specify a source routing profile for each device or interface that will
acquirer
transactions. Source routing profiles are tied to the acquirer using the field settings
shown
in the table below.
Each of these fields provides a set of existing values you can select from a dropdown list,
or you can click on the field label link to enter a new value on the Source Routing
Profile
Configuration window (Configure > Routing > Profile Description > Source
Routing
Profile).
The Acquirer Interface component retrieves the source routing profile from its
database
and creates the Acquirer Route Profile TDE.
Type of Acquirer Window Tab Field
ATM Channel Configuration window Processing Source Routing Profile
(Configure > ATM > ATM Channel >
ATM Channel Device
ATM (Java) Channel Configuration Processing Source Routing Profile
window (Configure > ATM (Java) >
ATM Channel >
ATM (Java) Channel
Device
Merchant Channel Configuration Processing Source Routing Profile
window (Configure > Merchant
Processing > Merchant Channel)
POS Channel Device
ISO8583 (93) Host Interface Processing Source Routing Profile
Configuration window (Configure >
ISO 93 Host
Interface > Host > ISO8583 (93) Host

Interface)
BASE24 ISO8583 (87) Host Interface Processing Source Routing Profile
ISO 87 Host
Interface > Host > ISO 8583 (87) >
BASE24 ISO8583 (87) Host Interface)
(Interchange-Specific) Interface Processing Source Routing Profile
Interface > Network )
Interchanges

Transaction Routing
Prefix Routing Algorithms

Prefix routing algorithms are basic numerical comparisons that can be applied to noton-us
card numbers to identify an organization or group to which the card issuer belongs
(typically
an interchange) for routing purposes.
Although, information may not be available in the BASE24-eps system to recognize
a
specific prefix or card number for routing a transaction, certain ranges of prefixes
and card
number lengths are associated with certain interchanges. Thus, the interchange to
which
a card belongs can be identified by applying prefix routing algorithms to the card
number.
For example, Diners Club card numbers are 14 characters in length and start with
36.
Thus, cards meeting that criteria can be identified as having been issued by a Diners
Club
issuer, and depending on your routing requirements, you can use that algorithm to
identify
transactions to be routed to the Diners Club interchange.
Configure Prefix Routing Algorithms

There are a number of industry-standard prefix routing algorithms, and you can
create
your own depending on your routing requirements; however, each prefix routing
algorithm
you plan to use must be defined on the System Algorithm Configuration window
(Configure
> Prefix > Not-On-Us > System Algorithm).
Once a prefix routing algorithm is defined on the System Algorithm Configuration
window,
you can select it on the System Prefix Configuration window (Configure > Prefix >
Not-On-Us > System Prefix) from the Value field pull-down list.
The definition for each prefix routing algorithm consists of one or more entries. Each
entry
consists of fields (described below) that define a prefix range and PAN length to be
included
as part of the algorithm:
Field Setting
Low Prefix The lowest prefix in the range to be considered a match.
High Prefix The highest prefix in the range to be considered a match.
PAN Length The length of the PANs whose prefixes are to be compared to low-to-high prefix range.
The following is an example of a single algorithm definition involving three separate

entries
on the System Algorithm Configuration window:
Low Prefix High Prefix PAN Length
292929 292931 14
292929 292931 15
292929 292935 16

Transaction Routing
This algorithm would match any of the following card numbers:
A 14-digit card number that starts with prefixes of 292929, 292930 or 292931.
A 15-digit card number that starts with prefixes of 292929, 292930 or 292931.
A 16-digit card number that starts with prefixes of 292929 through 292935.
Standard Prefix Routing Algorithms

You can create your own prefix routing algorithms, depending on how you want to
set up
your routing; however, there are a number of standard card issuer algorithms that
you may
want to consider configuring and using.
American Express Algorithm

If a primary account number starts with 34 or 37, the card issuer is considered to be
American Express regardless of the length of the primary account number.
To set up this algorithm, you would configure two entries on the System Algorithm
Configuration window for each length of PAN supported. For example, if you support
American Express cards with PAN lengths of 15 and 16, you would need to configure
the
following records.
34 34 15
34 34 16
37 37 15
37 37 16
Diners Club Algorithm

If a primary account number is 14 positions in length and starts with 36, the card
issuer is
considered to be Diners Club.
To set up this algorithm, you would configure one entry, as follows, on the System
Algorithm
Configuration window.
36 36 14

Transaction Routing
Discover Algorithm
If a primary account number is 16 positions in length, the first four positions are
6011, and
the fifth and sixth positions fall in the range of 00 through 09 or 20 through 99, the
card
issuer is considered to be Discover.

To set up this algorithm, you would configure two entries, as follows, on the System
Algorithm Configuration window.
601100 601109 16
601120 601199 16
MasterCard Algorithm
If a primary account number starts with 51, 52, 53, 54, or 55, the card issuer is
considered
to be MasterCard regardless of the length of the primary account number.
To set up this algorithm, one entry would be required on the System Algorithm
window for
each length of PAN supported. For example, if you support MasterCard cards with
PAN
lengths of 11, 12, 13, and 14, you would need to configure the following entries.
51 55 11
51 55 12
51 55 13
51 55 14
Visa Algorithm
If a primary account number is 13 or 16 positions in length and the first position is a
4, the
card issuer is considered to be Visa.
To set up this algorithm, you would configure two entries, as follows, on the System
Algorithm Configuration window.
4 4 13
4 4 16

Transaction Routing
Routing Codes
Routing codes are user-defined values created specifically to enable you to set up
unique
routing parameters and destinations based on the card prefix, the transaction code
of a
transaction, and the business relationship between the acquirer and issuer involved
in the
transaction.
Essentially, routing codes provide another significant level of differentiation when
evaluating
transactions for processing. There are several key concepts for understanding the
use of
routing codes:
Routing codes only apply to transactions being routed from acquirer to issuer. They
cannot be defined nor used for transactions being routed from an issuer to an
acquirer.
Use of routing codes is enabled or disabled at the prefix level. This means that for
each
known or unknown prefix you set up for processing transactions, you must specify
whether or not to evaluate the transactions for a business relation and routing code.
Routing codes can be only be defined for transactions where a business

relationship
exists between the acquirer and issuer. Business relationship in this context has a
very
specific meaning.
Enabling and Disabling the Use of Routing Codes

at
the Prefix Level
Each prefix you identify for some type of processing in the BASE24-eps system has
a
Route Type indicator associated with it that specifies whether or not a business
relationship
should be taken into consideration between the acquirer and issuer involved in a
transaction.
The derivation and use of route codes depends on how you set the Route Type for
the
prefix.
Route Type Settings

Route Type has the following values associated with it:
Acquirer and Issuer Means that a business relationship should be taken into
consideration and transactions will be evaluated for a route code.
Issuer Only Means that a business relationship does not exist for this prefix and
transactions will not be evaluated for a route code.
Transaction Routing
During prefix processing, if the Route Type specifies Acquirer and Issuer, the
Router
component checks for a route code, based on the destination routing profile and
source
routing profile identified for the transaction. If the Route Type specifies Issuer Only,
the
Router component does not check for a route code.
Where Route Type is Set

The table below lists where the field is set for known (On-Us) and unknown (Not-OnUs)
prefixes. Route type is carried in the Route Type TDE.
Prefix Window Tab Field
Processing Route Type button
Information
On-Us Prefix Configuration window (Configure
> Prefix > On-Us)
Known (On-Us)
Prefixes
System Prefix Configuration window (Configure no tab Route Type
Unknown (Not-On-Us)
Prefixes
Defining Business Relationships and Routing

Codes
for Your System

A Business relationship, as it relates to route codes, simply mean that the destination
routing profile and source routing profile identified for a transaction have been linked
together on the Routing Configuration - Destination/Source Relationship window
(Configure
> Routing > Destination/Source Relationship).
The premise is that destination routing profiles are defined to control the issuer side
of the
transaction and the source routing profiles are defined to control the acquiring side of
the
transaction. Thus, specific destination routing profiles can be defined for specific
issuers,
and specific source routing profiles can be defined for specific acquirers. These
profiles
can then be associated to create the business relationships, and the routing for
transactions
that involve these associated profiles take routing codes into consideration.
The data on the Routing Configuration - Destination/Source Relationship window is
organized as shown in the table excerpt below.
Note: Data from the Routing Configuration - Destination/Source Relationship window
is
stored in the Acquirer/Issuer Relation data source (Acquirer_Issuer_Relation), which
is
used to build the Acquirer/Issuer Relation external memory table
(Acquirer_Issuer_Relation_OLTP), which is used by the Routing component.
Destination Routing Profile Source Routing Profile Transaction Code Route Code
(These values establish the business relationship)
Dest_Pro_A Src_Pro_1 Purchase (00) PUR
Withdrawal/Cash Advance WDL
(01)
Dest_Pro_A Src_Pro_1
Dest_Pro_A Src_Pro_1 Debit Adjustment (02) PUR

Transaction Routing
Destination Routing Profile Source Routing Profile Transaction Code Route Code
(These values establish the business relationship)
Dest_Pro_A Src_Pro_1 Deposit (21) DEP
Dest_Pro_A Src_Pro_1 Balance Inquiry (31) INQ
Dest_Pro_A Src_Pro_1 Transfer (40) XFER
Payment From and Payment PYMT
From/To (50)
Dest_Pro_A Src_Pro_1
The key for selecting a specific route code consists of the destination routing profile
and
source routing profile (which establishes the existence of a business relationship)
and
transaction code of the transaction.
The first line of the table specifies that a purchase transactionwhere the selected
destination routing profile is Dest_Pro_A and the source routing profile is Src_Pro_1
would
be assigned a route code of PUR. In this case, PUR would be used for determining
the
correct destination matrix in the destination routing profileactually the Route data
source
(Route), and the Route external memory table (Route_OLTP).
Note: From a configuration standpoint, the use of route codes needs to be
coordinated
with the destination matrixes defined in the destination routing profile. For example, if
you
want to handle those transactions in the example above in a unique manner, you
would
need to set up your destination routing profile transaction table to include an entry
with a
route code of PUR.
Selection Hierarchy/Preference for Selecting a Route Code

The Router component uses the Issuer Route Profile TDE, Acquirer Route Profile
TDE,
and the first two positions of the Processing Code TDE to search the Acquirer/Issuer
Relation external memory table (Acquirer_Issuer_Relation_OLTP), and selects an
entry
based on the following preference:
Use of asterisks: Where the table denotes asterisks in the Destination Routing Profile and Source Routing
Profile
fields, the Router component is looking for an exact match on **************** (16 asterisks). In order to match the
former,
a Destination Routing Profile must be created with the name ****************, and to match the latter, a Source
Routing
Profile must be created called ****************.
Hierarchy
Preference Destination Routing Profile Source Routing Profile Transaction Code
1 Exact match Exact match Exact match
2 **************** Exact match Exact match
3 Exact match **************** Exact match
4 **************** **************** Exact match
Once the most-preferred match is found, the Router component retrieves the route
code
value from the external memory table entry.
Transaction Routing
Using Routing Codes

Routing codes can be used for any number of situations, but fleet-card processing
provides
a good example of where business relationships may exist between issuers and
acquirers.
Fleet-card processors often issue cards on behalf of companies who employ drivers
to
transport goods or people. Company As truck drivers, for example, might be issued
a card
to use specifically for purchasing fuel at Company Bs stations. Company B may
have
previously agreed to discount fuel purchases whenever a Company A truck driver
purchases
fuel at one of Company Bs stations.
When setting up routing, this relationship can be taken into consideration when
determining
a routing destination (typically, this would require a separate set of authorization
scripts
that would identify the fuel purchases for discounts).
Basic Steps for Establishing Business Relationship Using

Routing
Codes
There are a number of configuration requirements that come into play when setting
up
routing to include business relationships. The following are the basic steps required
to set
up business relationships and routes codes within BASE24-eps.
1. Create a destination routing profile to route transactions for the acquirers and
issuers
involved in the business relationship you are creating. Include in the transaction table
of the profile all of the routing codes you plan to use (refer to step 4).
2. Set up your Prefix information. For any prefixes for which you plan to process
transactions
under this business relationship, specify a Routing Type of Acquirer and Issuer and
the destination routing profile you created in step 1.
3. Create a source routing profile to use for the acquirers involved in the business
relationship and assign the source routing profile to those acquirers from which
transactions are to be received.
4. Set up a destination/source relationship table so that the destination routing profile
created in step one and the source routing profile created in step 3 are associated.
Include in the table all of the transactions codes you plan to accept, along with the
corresponding routing codes to be assigned to each of those transaction codes.
Transaction Routing
File Update Routing

File Update Routing is a specialized form of routingcarried out by the File Update
Router
componentthat enables the routing of file updates and file update transactions in
the
BASE24-eps system. File updates and file update transactions, as their name
suggests,
carry updates that can be applied to specific types of files either on the BASE24-eps
system
(such as the card and positive balance data sources) or on external systems (such
as
interchange warning bulletin and negative card files).
File update transactions are typically used to keep file changes synchronized
between two
processing entities (such as a host and BASE24-eps or a host and an interchange).
What are File Updates?
File updates, in the context of file update routing, refer specifically to file updates and
file
update transactions that originate in the following ways.
Real-time file update transactions sent to BASE24-eps from an external host.
These
are received through the HISO 93 Host Interface component.
Partial-file refresh record actions (i.e., add, replace, update, or delete record) on
data
sources supported by partial-file refresh.
Certain authorization-related changes to the Card data source (i.e., changes made
by
an authorization script). Authorization scripting can be modified to route certain types
of Card changes as file update transactions to external entities.
Note: In this context, file updates do not include those changes made through the
ACI
desktop user interface.
File Update Types

There are a number of BASE24-eps data sources and interchange files that can be
updated
through file update processing.
BASE24-eps Data Source File Updates
The File Update Route component can accept and process file updates for the
following
BASE24-eps data sources.
File Update Routing
Number File Type
01 Card/Card Account/Card Account Multibyte data source updates and inquiries
02 Positive Balance data source updates
10 Preauthorization Hold Delete
26 Check Status data source updates
27 Stop Payment data source updates
Interchange File Updates

The File Update Route component accepts and processes file updates for the
following
interchange file updates.
Number Description
04 Star Negative File Updates
05 Visa Stop Payment Order
06 Visa Card Recovery Bulletin
07 Banknet File Updates
08 EPS-Net File Updates
09 Equens File Updates
12 JCB Negative File Update
13 AEGN Negative File Updates
14 NYCE Negative File Updates
15 Fifth Third File Update
16 SHAZAM Negative File Updates
17 NETS Negative File Updates
18 Presto (Publix) Negative File Updates
19 EPOC (Accel/Exchange) File Updates
20 MDS Dispute Processing
21 CO-OP Negative File Updates
22 MDS File Updates
23 e-rsb File Updates
24 PRICE File Updates
25 SPAN 2 Dispute File Updates

45 Pulse Negative File Update
46 Visa DPS File Update
47 Star File Update
48 Elan Host File Updates
50 Interac File Updates
91 FDR File Updates

File Update Routing
The Basics of File Update Processing

The File Update Router component is at the center of file update processing. Its
function
is to receive file updates and pass them to the appropriate components for action.
The File
Update Router can receive the following types of file updates:
Real-time file update transactions (1304 messages) through the HISO 93 Host
Interface
component. These transactions can include file updates to both BASE24-eps data
sources and interchange files.
Partial-file refresh record actions (i.e., add, replace, update, or delete records) from
the
Partial-File Refresh component.These actions include file updates to BASE24-eps
data
sources only; they support no external routing.
Authorization-related changes to the Card data source made by your authorization
scriptschanges are in the form of internally-generated file update transactions to
be
routed to external entities.
File Update Routing
Updating BASE24-eps Data Sources Through File Update

For each BASE24-eps data source that can be updated through file update
processing,
there is a corresponding component that actually performs the file update actions. At
startup, each of these components registers with the File Update Router component,
which
enables the File Update Router component to recognize and pass the file updates it
receives
to the correct components for action.
No configuration of the File Update Route data source is required for processing file
updates
to the BASE24-eps data sources. The internal registration of the components is
automatic
and all that is needed. The exception is if any file update transactions coming in
through
the HISO 93 Host Interface component need to be sent to external entities as well.
Data source update processing can be invoked by the HISO 93 Host Interface if
those
types of file updates are supported and sent by a host; data source update
processing is
used as a part of standard refresh processing by the Partial-File Refresh component.

File Update Routing
Routing File Update Transactions to External Entities

When a file update transaction is received by the File Update Router component, it
uses
the File Update Route data source to determine whether to send the transaction to
one or
more external entities. If the File Update Router finds one or more routing entries
that apply
to the transaction, it will pass the transaction to the specified components for sending
the
transactions to the external entity.
Processing Preauthorization Hold Deletions from a Host

Preauthorization hold delete records can be sent as file update transactions from an
ISO
93 host. This requires configuration of the the File Update Router to be able to
recognize
a Preauthorization Hold file update type and to call the Preauthorization component
when
one is received.
File Update Routing
The following is an illustration of the basic flow of these messages using file updates.
The transactions arrive as 1304 messages at the BASE24-eps ISO 93 Host
Interface
component.The host interface component invokes the File Update Router which
recognizes
the Preauthorization Hold file update and invokes the Preauthorization component to
delete
the specified hold. The host interface component then creates a 1314 response
message,
journals it, and sends it to the host.
How the ISO 93 Host Interface Component Invokes the File

Update
Component
If file update routing is in use by the ISO 93 Host Interface component, the ISO Host
Interface component automatically invokes the File Update Router component
instead
of the Router componentto handle any inbound file update (1300-series)
messages it
receives.
File Update Routing
Defining File Update Routing for Your

System
File update routing is defined on the File Update Router Configuration window
(Configure
> Routing > File Update Router). Data from the File Update Router window is
stored as
table entries in the File Update Router data source, which is used to build the File
Update
Router external memory table (File_Update_Route_OLTP) used by the File Update
Router
component.
Upon receipt of a file update transaction, the File Update Router searches for one or
more
applicable table entries in the File Update Router external memory table
(File_Update_Route_OLTP) and uses those table entries to determine the
component and
interface to which to pass the transaction.
Note: Setting up file update routing is only required if you want to route file updates
to
external entities. Updates to BASE24-eps data sources do not require records in the
File
Update Route data source.
Information Stored for Each File Update Route Table Entry

File Update Route table entries are divided into key fields and destination fields.
Key Fields
The File Update Route key fields are used to find table entries that match the
transaction.
You can set up your table entries so that a single file update transaction can match
multiple
entries in order to route transactions to multiple destinations.
Field Description
The name of the destination routing profile identified for the transaction.
This key value is compared to the Issuer Route Profile TDE of the transaction.
The name of the source routing profile identified for the transaction. This value can
be set to ANY to allow for a match on any source routing profile.
This key value is compared to the Acquirer Route Profile TDE of the transaction.
Source Routing Profile
The type of file updates to be routed using this record. For a list of file update types,
refer to File Update Routing on page 103.
File Type
Destination Fields
Once a table entry is selected, the destination to which the file update transaction is
to be
routed is determined from the following fields of the entry. If multiple table entries are
selected, copies of the file update transactions are sent to each destination.
Field Description
The component ID of the interface component to which the type of file update
transactions specified in the File Type field are to be routed.
Component ID

File Update Routing
Field Description
The name of the interface component to which the type of file update transactions
specified in the File Type field are to be routed. This will match the name of the interface
as defined in the Interface Configuration (Configure > Interface).
From the ACI desktop user interface, you must select a component in the Component
ID field before you select an interface name, because the component that you select
determines the interfaces that are valid for that component.
Interface Name
Note: To be able to send file updates from the BASE24-eps system, the issuer interface
must support file action or file update messages.

File Update Routing
File Update Transactions Resulting from

Authorization Changes to the Card Data
Source
Certain type of updates to the Card data source (Card)resulting from authorization
script
processingcan be sent in real-time to external entities as file update transactions.
This
requires modifying the appropriate authorization scripts to use specific exported
operators
created for this purpose.
Note: This file update processing is supported through authorization scripts only.
Changes
to the Card data source made in other ways (e.g. through partial-file refresh or from
the
ACI desktop user interface) cannot be routed to external entities as file update
transactions.
Exported Operators
In addition to updating values in the Card, certain exported operators can be used to
instruct
the Card component to format a 1304 file update message and pass it to the File
Update
Router component. Thus, when certain values are changed in the Card, file update
transactions can be sent to external entities to note these changes.
This table identifies the exported operators that can be used to create file update
transactions for the corresponding Card changes.These exported operators can be
written
into your authorization scripts as needed. Refer to the BASE24-eps Scripting Manual
for
information about the use of exported operators in your scripts.
Exported Operator Card Field
CSM_BUF_SET_NOTIFY CSM Buffer
PRI_STAT_SET_NOTIFY Primary Instrument Status
PVV_SET_NOTIFY PVV
SCND_STAT_SET_NOTIFY Secondary Instrument Status
File Update Transactions Create by the Exported Operators

This table describes how several TDEs are set by the Card component when
creating the
1304 file update transactions to be passed to the File Update Router component. In
some
cases, the TDEs are set from the original transaction (i.e., the one being
authorizedcausing the change to the Card data source).
TDE Description
PAN Set from the original transaction.

Local Date/Time Set from the original transaction.

File Update Routing
TDE Description
Set from the original transaction if the TDE is present. Otherwise, the TDE is created
and set to 000.
Card Sequence Number
Acquirer Set from the original transaction.
Issuer Route Profile Set from the original transaction.
MTI Set to 1304.
Function Code Set to 302, indicating a change.
Formats the appropriate Card data source subtags (refer to the tag 01 description
for the Data Record (S-72) data element in the BASE24-eps ISO 8583:1993 Host
External Message Manual).
Data Record
Not set.Note: The fact that this TDE is not set and not taken from the original
transaction has routing implications.
Acquirer Route Profile
Routing Card Updates to an External Entity

The File Update Router component routes file update transactions produced by the
Card
component in basically the same manner as any other file update transaction it
receivesbased on the destinations configured in the File Update Route data
source.The
one exception is how the key data is derived to read the File Update Route external
memory
table (shown in this table).
Table Key What Key Data is Used
Destination Routing Profile Name Specified in the Issuer Route Profile TDE.
Because the Acquirer Route Profile TDE is not included in the 1304 message, the
File Update Router component uses the value of the DFLT_FUR_ACQ_RTE_PRFL
Environment attribute.
If this attribute is not configured, the default value of FUR_ACQ_RTE is used.You
must take this into account when configuring destinations for this type of transaction.
Source Routing Profile Name
File Type Uses Card data source as the file type

File Update Routing
Authorization, Prescreening, and

Impacting
Acting on behalf of an issuer, BASE24-eps can be configured to perform
prescreening or
authorization for transactions that it recognizes as on-us. Additionally, impacting may
be
required to update BASE24-eps data sources if transactions are routed to a host for
authorization. BASE24-eps authorization, prescreening, and impacting are carried
out
using scripts.
What is Authorization?
Authorization is the process of determining whether a transaction is approved,
denied, or
referred based on a set of authorization requirements defined by the transaction

authorizer.
The transaction authorizer is a business or processing entity, representing the owner
of
the card or account involved in the transaction, selected during transaction routing to
make
the authorization decision on the transaction. Authorization decisions can be made
based
on any number of transaction evaluation criteria.Typically, things such as proper PIN
entry,
card or account statuses, and transaction count and amount limits are evaluated to
make
sure the transaction is entered by an authorized person using a valid payment
instrument
and does not exceed the spending limits set for the instrument. As a part of
transaction
authorization, the transaction authorizer would also typically track and update any
transaction activity and usages it maintains for authorizing transactions.
From a BASE24-eps perspective, the authorizer can be an internal set of scripts or it
can
be an external system, such as an interchange or host.
Within BASE24-eps, authorization processing is carried out using script sets set up
as
Authorization routing destinations (refer to Destination Routing Profile Destination
Matrix
on page 74). Because authorization is scripted, it is very flexible and can be modified
and
uploaded without stopping and restarting BASE24-eps.
Scripting Note: Authorization scripts must make an authorization decision and make appropriate updates to the
BASE24-eps database. This would include setting the action code and other pertinent data for the transaction
and
updating any database files necessary to reflect the effects of the transaction.

Authorization, Prescreening, and Impacting
What is Prescreening?
Prescreening is the process of checking certain transaction properties before
performing
full authorization processing, thus reducing unnecessary processing by the
authorizer for
those transactions that fail to meet certain basic requirements, such as PIN
verification.
Prescreening is commonly performed in a transaction processing environment in
which
one system acquires transactions and another system performs final authorization.
The
system acquiring the transaction might be set up to perform certain prescreening
checks
that must be passed prior to sending the transaction to the other system for
authorization.
Within BASE24-eps, prescreening is typically only performed when transaction
authorization
is carried out by a host. In this case, you would set up BASE24-eps to do the
prescreening,
and then route the transaction to a host for authorization. If BASE24-eps is to be the
transaction authorizer, you would not set up BASE24-eps to also prescreen the
transaction.
BASE24-eps prescreening is carried out using script sets set up as Prescreen
routing
destinations (refer to Destination Routing Profile Destination Matrix on page 74).
Because
prescreening is scripted, it is very flexible and can be modified and uploaded without
stopping and restarting BASE24-eps.
Scripting Note: Prescreening scripts should not perform BASE24-eps database updates unless a transaction is
denied
by the scripts. If a transaction passes the prescreening checks, the scripts should not update the BASE24-eps
database
because if the transaction is sent externally and the transaction outcome changes, no capability exists to back
out the
database changes made by the prescreening scripts. On the other hand, if the transaction is denied by the
scripts,
corresponding updates to the BASE24-eps database would be expected.
What is Impacting?
Impacting, in the context of authorization and prescreening, is the act of updating
authorization-related data sources as a result of the approval or denial of a
transaction by
a host. This could include updating a cardholders usage information or perhaps
changing
a cardholders status.
Impacting is typically only required when hosts are set up to authorize transactions,
but
BASE24-eps maintains specific authorization data sources for purposes of
prescreening
transactions or standing in for authorization should the host not be available.
Impacting,
as such, is not required when BASE24-eps authorizes transactions, because all of
the
necessary files would typically be updated as a part of the authorization processing.
Within BASE24-eps, impacting is carried out using script sets set up as Impact 1 or
Impact
2 routing destinations (refer to Destination Routing Profile Destination Matrix on
page
74). Because impacting is scripted, it is very flexible and can be modified and
uploaded
without stopping and restarting BASE24-eps.
Scripting Note: Impacting scripts should only update the BASE24-eps database (usages, status changes, etc.)
based
on the transaction outcome provided by the external entity.They should not change the outcome of a transaction
(e.g.,
changing one action to another). The reason is that these scripts are invoked after the transaction decision has
been
made (e.g., advices would have already been sent and there is no capability to generate reversals should you
change
the action code).

Use of Scripts
One of the key features of BASE24-eps is its flexible authorization scripting
capability. This
feature provides customers with the ability to easily modify authorization (and
prescreening
and impacting) logic to meet their own needs.
ACI delivers a set of sample authorization scripts with BASE24-eps. These sample
scripts
provide BASE24-eps customers a set of fundamental payment authorization services
that
can be adapted as a customer sees fit. It is important to note that these scripts are
provided
as examples only and should not be considered ready-for-processing.
For information about the BASE24-eps sample scripts, refer to the BASE24-eps
Sample
Fundamental Authorization Scripts Delivery Document. For information about using
and
modifying scripts, refer to the BASE24-eps Scripting Manual.
Role of the Issuer Authorization Component (IAUT)

The Issuer Authorization component (IAUT) is the BASE24-eps component that
actually
executes authorization, prescreening, and impacting scripts within the Integrated
Server
(IS) process. Any time a script is executed, it is the IAUT component that must be
invoked
to execute it.
If BASE24-eps is to perform authorization, prescreening, or impacting, IAUT must be
specified as the Component ID in your Authorization, Prescreen, Impact 1, and
Impact 2
routing destinations. In addition, each routing destination must specify the particular
script
set to be run in each situation. Refer to Destination Routing Profile Destination
Matrix
on page 74 for information about setting up these destinations.
BASE24-eps Authorization Methods for

On-Us
Cards
All authorization processing must be implemented through your authorization scripts.
ACI
provides sample authorization scripts for the three basic authorization methods
described
below as well as several variations (e.g., EMV processing).
If used, it is expected that these scripts be thoroughly examined and modified to fit
your
environment. As such, you can script other variations or other authorization methods
as
well.The Sample Fundamental Authorization Scripts Delivery Document contains a
current
list of BASE24-eps sample authorization scripts.
Default authorization is an exception in that no script is required (refer to Default
Authorization on page 139).
Note: BASE24-eps can only authorize transactions on cards with prefixes that it
recognizes
as on-us (refer to Local (On-Us) and Non-Local (Not-on-Us) Prefixes on page 24).
Negative Authorization With Usage Accumulation Method

(NEGU)
The Negative Authorization with Usage Accumulation method, also known as the
Negative
Card with Usages (NEGU) method, authorizes transactions using negative
identification.
The BASE24-eps authorization script set, in this case, assumes the card is good if it
is not
found in the Card data source. Therefore, you would only configure bad cards (e.g.,
lost
or stolen cards) for this authorization method.
Usage accumulation is tracked with this authorization method. If the transaction is a
cash
disbursement, the usage accumulation totals are checked against transaction limits
(set
in this case at the prefix level). Based on those totals and limits, the BASE24-eps
authorization scripts approve, decline, or refer the transaction request and update
the
usages appropriately.
Because only bad cards are maintained on file, processors using this method can
only
perform PIN verification when the PIN offset is obtained from the cards track data.
Positive Authorization Method (PCA)

The Positive Authorization method, also known as the Positive Card with Usages
(PCA)
method, authorizes transactions using positive identification. For the transaction to
be valid,
a record must exist in the Card data source for the card initiating the transaction, and
the
status of the account for the card must be good.
Usage accumulation is tracked with this authorization method. If the transaction is a
cash
disbursement, the amount previously disbursed, plus any holds, plus the new
transaction
amount, must not exceed the cardholders transaction limits. Based on these totals
and
limits, the BASE24-eps authorization scripts approve, decline, or refer the

transaction
request and updates totals appropriately.
Because all cards to be processed are maintained on file, processors can perform
PIN
verification for this method when the PIN offset is obtained from the cards track data
or
the Card data source (Card).
Positive Balance Authorization Method (PCBA)

The Positive Balance Authorization method, also known as the Positive Card with
Usages
and Balances (PCBA) method, authorizes transactions using positive identification
and
account balance information (the latter to ensure the cardholder has sufficient funds
available to settle the transaction). For the transaction to be valid, a record must
exist in
the Card data source for the card initiating the transaction, and the status of the
account
for the card must be good.
Usage accumulation is tracked with this authorization method also. If the transaction
is a
cash disbursement, the amount previously disbursed, plus any holds, plus the new
transaction amount, must not exceed the cardholders transaction limits. In addition,
a
record must also exist for the account in the Positive Balance data source, and the
amount
of the transaction must not exceed the balance in the account. Based on these
totals,
limits, and balances, the BASE24-eps authorization scripts approve, decline, or refer
the
transaction request and update the totals and balances appropriately.
Because all cards to be processed are maintained on file, processors can perform
PIN
verification for this method when the PIN offset is obtained from the cards track data
or
the Card data source (Card).
How Scripts are Identified

Scripts are divided into two basic categories: top-level scripts, also called businesslevel
scripts, and subscripts. Top-level scripts can call subscripts, and subscripts can call
subscripts. However, from a configuration perspective, you will need to be able to
identify
your top-level scripts. These are the scripts that you will need to configure into script
sets
for the Issuer Authorization component (IAUT) to use.
Top-Level Script Naming
Top-level (or business level) authorization scripts provided by ACI use the following
naming
convention.
Naming Convention
<authorizationtype>_<txn>_<function>_<txntype>
<authorization type> - Up to four characters describing the authorization method for

which
the script is used.
NEGU = Negative Card with Usages Auth
NEGU_E = Negative Card with Usages Auth with EMV
PCA = Positive Card Auth
PCA_E = Positive Card Auth with EMV
PCBA = Positive Card with Usages and Balances Auth
PCBA_E = Positive Card with Usages and Balances Auth with EMV
<txn> - Up to five characters describing the type of transaction the script is written to
process. The following are examples:
ADV = Cash advance
DEP = Deposit
INQ = Balance Inquiry
PINCH = PIN change (PCHG is also used)
PCHG = PIN change (PINCH is also used)
PMNT = Payment
PUBK = PIN unblock
PUR = Purchase
RTRN = Return
XFR = Transfer
WDL = Withdrawal
<function> - Up to three characters describing the function of the message that the
script
is written to carry out.
AU = Authorization
PS = Prescreening
IM = Impacting
IM1 = Impacting account 1
IM2 = Impacting account 2
<txn type> - Up to two characters describing the type of message the script is written
to
process.
RQ = Request (online and stand-in)
FP = Force Post
RV = Reversal
Script Set Naming

Top-level (or business-level) authorization scripts must be configured into script sets
in
order to be assigned as routing destinations.Typically, the recommended naming for
script
sets follows the naming scheme of the top-level scripts included in the setsbased
on the
first two portions of the name, the authorization method and transaction type (e.g.
PCBA_DEP, PCBA_INQ, etc.).
Sample Script Naming

The following is a list of sample top-level scripts provided for the Positive Card with
Usages
and Balances (PCBA) authorization method. They are provided here to give you a
sense
of the types of scripts provided and naming used. A full listing of sample scripts is
provided
in the BASE24-eps Sample Fundamental Authorization Scripts Delivery Document.
The
first column lists the recommended script set name to be used for each set of scripts.
Script Set Name Script Name Description
PCBA_DEP PCBA_DEP_AU_FP Deposit Force Post
PCBA_DEP_AU_RQ Deposit Request
PCBA_DEP_AU_RV Deposit Reversal
PCBA_DEP_IM2_RQ Deposit Request Impacting
PCBA_DEP_IM2_RV Deposit Reversal Impacting
PCBA_DEP_PS_RQ Deposit Pre-Screening
PCBA_INQ PCBA_INQ_AU_RQ Balance Inquiry Request
PCBA_INQ_IM1_RQ Balance Inquiry Request Impacting
PCBA_INQ_PS_RQ Balance Inquiry Pre-Screening
PCBA_PINCH PCBA_PINCH_AU_FP PIN Change Force Post
PCBA_PINCH_AU_RQ PIN Change Request
PCBA_PINCH_AU_RV PIN Change Reversal

Script Set Name Script Name Description
PCBA_PINCH_IM_RQ PIN Change Request Impacting
PCBA_PINCH_IM_RV PIN Change Reversal Impacting
PCBA_PINCH_PS_RQ PIN Change Pre-Screening
PCBA_PMNT PCBA_PMNT_AU_FP Payment Force Post
PCBA_PMNT_AU_RQ Payment Request
PCBA_PMNT_AU_RV Payment Reversal
PCBA_PMNT_IM1_RQ Payment Request Impacting
PCBA_PMNT_IM1_RV Payment Reversal Impacting
PCBA_PMNT_PS_RQ Payment Pre-Screening
PCBA_PUR PCBA_PUR_AU_FP Purchase Force Post
PCBA_PUR_AU_RQ Purchase Request
PCBA_PUR_AU_RV Purchase Reversal
PCBA_PUR_IM1_RQ Purchase Request Impacting
PCBA_PUR_IM1_RV Purchase Reversal Impacting
PCBA_PUR_PS_RQ Purchase Pre-Screening
PCBA_RTRN PCBA_RTRN_AU_FP Merchandise Return Force Post
PCBA_RTRN_AU_RQ Merchandise Return Request
PCBA_RTRN_AU_RV Merchandise Return Reversal
Merchandise Return Request
Impacting
PCBA_RTRN_IM1_RQ
Merchandise Return Reversal
Impacting
PCBA_RTRN_IM1_RV
PCBA_RTRN_PS_RQ Merchandise Return Pre-Screening
PCBA_WDL PCBA_WDL_AU_FP Withdrawal Force Post
PCBA_WDL_AU_RQ Withdrawal Request
PCBA_WDL_AU_RV Withdrawal Reversal
PCBA_WDL_IM1_RQ Withdrawal Request Impacting
PCBA_WDL_IM1_RV Withdrawal Reversal Impacting
PCBA_WDL_PS_RQ Withdrawal Pre-Screening
PCBA_XFR PCBA_XFR_AU_FP Transfer Force Post
PCBA_XFR_AU_RQ Transfer Request
PCBA_XFR_AU_RV Transfer Reversal
PCBA_XFR_IM1_RQ Transfer Request Impacting
PCBA_XFR_IM1_RV Transfer Reversal Impacting
PCBA_XFR_PS_RQ Transfer Pre-Screening

Tying Script Sets to Routing

Your routing configuration defines the destinations to which the various transactions
you
process are to be routed.
The following is a destination matrix from a destination routing profile used in
transaction
routing. Scripts can be specified for the yellow-highlighted types of destinations.
Refer to
Destination Routing Profiles on page 66 for information about setting up destination
routing
profiles.
Looking closer, each destination is actually defined using the following values. To
specify
the use of a script, you must set the component ID value to IAUT and the Name
value to
the name you have assigned to the script set to be used. The following is an
example of
the script sets you might assign to the destination for handling purchase
transactions.
Configuring Script Sets to Use as Routing

Destinations
In order for a script set to be specified as a destination in your routing configuration,
it must
first be definedas a setin the Authorization Script (Authorization_Script) data
source.
The Authorization Script data source does not contain the actual scripts, but rather
defines
those scripts sets to be named as authorization, prescreening, and impact routing
destinations.
A script set is actually a collection of one or more top-level scripts. To be selected for
and
included in a script set, the actual scripts must have been written and reside in the
Script
Repository (this is discussed in the BASE24-eps Scripting Manual).
The Authorization Script Configuration window (Configure > Script > Authorization
Script) is used to access the Authorization Script data source. The following is an
example
of viewing the PCBA_PUR script set from that window.
Defining the Script Set and the Scripts Contained in the Script
Set
The Authorization Name, Message Type, Script Name and Script Enable Flag fields
on
the Authorization Script Configuration window define the script set and the scripts
included
in the set. These fields are described below. The other fields on the window are used
to
control performance monitoring for the script set (refer to Monitoring Script Set
Performance
on page 125).
Field Description
The name of the script set. This name is used in your routing configuration to identify the
script set. Typically, the name is based on the authorization method and transaction type
for the scripts included in the set (e.g., PCBA_DEP, PCBA_PUR, etc.).
Authorization Name
The type of message to which the specified script is to be applied. The specified script will
only be invoked for messages of the type indicated. Message type values are displayed on
the window. For clarity, the corresponding message type is provided here as well.
Message Type
Message Type MTI
Authorization Request 1100
Authorization Response 1110
Authorization Advice 1120
Authorization Advice Response 1130
Financial Request 1200
Financial Request Response 1210
Financial Advice 1220
Financial Advice Response 1230
Reversal Advice 1420
Charge Back Advice 1422
Reversal Advice Response 1430
Charge Back Advice Response 1432
Administrative Request 1604
The top-level script used to process the type of message specified in the Message Type
field. Available scripts are displayed from the Script Repository for selection.
Script Name
A flag indicating whether or not the script is enabled. A check mark means the script is
enabled; no check mark means the script is disabled.
To be used, a script must be enabled. Refer to Enabling and Disabling Authorization Scripts
on page 130 for information about the implications of disabled scripts.
Script Enable Flag
Note: Information about whether a script is enabled or disabled is maintained in active
memory and written to the Authorization Script data source only after the number of
transactions defined in the ACTV_SCRIPT_STATS_UPDT_INTRVL environment attribute
are processed. Refer to the BASE24-eps Environment User Guide for more information
about this attribute.
Example Script Set

The following is an example of the PCBA_PUR script set. Once defined, the
PCBA_PUR
name could be used in your routing configuration.
Authorization Name Message Type Script Name
PCBA_PUR Authorization Request (1100) PCBA_PUR_AU_RQ
Authorization Advice (1120) PCBA_PUR_AU_FP
Financial Request (1200) PCBA_PUR_AU_RQ

Authorization Name Message Type Script Name
Financial Advice (1220) PCBA_PUR_AU_FP
Reversal Advice (1420) PCBA_PUR_AU_RV
In this configuration, the PCBA_PUR_AU_RQ script would be used to process 1100

and
1200 message types, the PCBA_PUR_AU_FP script would be used to process 1120
and
1220 message types, and the PCBA_PUR_AU_RV script would be used to process
the
1420 message type.
Monitoring Script Set Performance

You can configure your script sets to be monitored for the percentage of times each
script
in the set produces an approval, denial, or referral. This can be useful when setting
up
your scripts and script sets to make sure they are performing (i.e., producing results)
as
expected. Script monitoring also enables you to set thresholds for disabling scripts
should
they produce results that are outside your expected norms.
The configuration for monitoring is done from the Authorization Script Configuration
window.
The actual monitoring information is viewed from the Active Scripts Statistics and
Management window.
Usage Note: It is recommended that scripts be monitored in test environments to validate processing, or
periodically
in production environments to isolate problems. It is not recommended that scripts continuously be monitored in a
production environment because doing so will increase transaction processing time.
What is Monitored
Script monitoring tracks the percentage of time the scripts in a script set are setting
approval,
denial, and referral action codes for the various message types processed by the
script
set. For example, if a particular script has processed 1000 transactions and
approved 950,
the approval rate is 95%. Denials and referrals would make up the remaining 5% of
the
transactions.
In addition, script monitoring also enables you to set percentage thresholds for
approvals,
denials, and referrals that, if reached, will automatically disable the corresponding
script.
You would set these thresholds in testing to make sure the expected levels of
approvals,
denials, and referrals are not falling outside normal boundaries (e.g., the script is
approving
less than an expected percentage or denying/referring more than an expected
percentage
of transactions). The intent is to be able to identify scripts that may not be set up
properly
based on your business model.
As script results are monitored against these thresholds, they are color-coded on the
BASE24-eps windows from green to yellow to red as they approach the thresholds.
Scripts are monitored, relative to the script sets and message types to which they
are
assigned. For example if the same script is used to process both 1100 and 1200
message
types for a single script set, separate percentages are kept for 1100 and 1200
message
results. If the script denies an 1100 message, the denial percentage for 1100
messages
is affected, but not the denial percentage for 1200 messageseven though the
same
script is being used for both types of messages. Likewise, the script might be
disabled for
one message but not the other (e.g., it might be disabled for processing 1100
messages
but not 1200 messages). This concept holds true whether the same script is
configured
multiple times in the same script set or multiple times across multiple script sets.
Each
specific use of the script is monitored separately.
Setting up a Script Set to be Monitored

The Authorization Script Configuration window (Configure > Script > Authorization
Script) is used to access the Authorization Script data source, which contains the
controls
for script monitoring. The following is an example for the PCBA_PUR script set.
Note: Before configuring monitoring, you must define your script set and the scripts
to be
included in the set (refer to Configuring Script Sets to Use as Routing Destinations
on page
122).
The following fields are set to control monitoring for each top-level script defined in a
script
set.
Field Description
A flag indicating whether or not the script is monitored for the specified message type.
A check mark means the script is monitored; no check mark means the script is not
monitored.
Script monitoring is specific to the use of the script for this script set and message
type. The same actual script may be specified for multiple message types and in
multiple script sets, but this check mark only enables monitoring for this specific use
of the script.
Monitor Enable Flag
The respective thresholds to use for evaluating script approvals, referrals, and denials.
Thresholds are percentages representing the outside boundaries that you do not want
the script results to cross. In other words, reaching these respective thresholds
indicates a serious problem with the script. For example, a script that approves or
denies 100% of the transactions it processes is likely one to be examined.
Approval Threshold
Referral Threshold
Denial Threshold
Note: Scripts that reach these thresholds are automatically disabled.You should
consider the threshold settings carefully.
The minimum number of transactions that must be processed by the script prior to
computing response percentages.
Minimum Transaction Count
Monitoring Script Performance

The rates, transaction counts, and thresholds for scripts are displayed on the Active
Script
Statistics and Management window (System Operations > Active Script
Statistics).The
information from the window is read from the Active Script Statistics data source.
Viewing Statistics for a Specific Script Set and Message Type

Script sets are displayed in the left-hand pane of the window. To display the
statistics,
select a script set and then select the message type number. The following
information is
displayed for the selected message type.
Field Description
Refresh every ___ minutes The number of minutes to use for a refresh timer, if a refresh timer is started.
The number of transactions approved, denied, and referred by the script for the selected
message type number.
Transactions
Threshold The thresholds set for approvals, denials, and referrals.

Field Description
The actual percentage of measured transactions that are approved, denied, and referred.
The Indicator fields will be green, yellow, or red depending on the monitoring zone into
which the percentage falls.
Indicator
Monitoring Zones
The Indicator field on the Active Script Statistics and Management window displays
the
percentage of measured transactions that are approved, denied, and referred and
are
highlighted as green, yellow, or red depending on the monitoring zone into which the
percentage falls. The following table describes how transactions are categorized into
monitoring zones.
A script is disabled if any one of the thresholds is actually reached. A message is
displayed
on the status bar at the bottom of the window to indicate that the script is disabled.
Monitoring Zones
Action Zone Description
The number of approved transactions is more than 25% above the
script approval threshold.
Approvals Safe (green)
The number of approved transactions is 1025% above the script
approval threshold.
Warning (yellow)
The number of approved transactions is less than 10% above the
script approval threshold.
Critical (red)
The script is automatically disabled if the number of approved
transactions is equal to or less than the script approval threshold.
Disabled
The number of denied transactions is more than 25% below the script
denial threshold.
Denials Safe (green)
The number of denied transactions is 1025% below the script denial
threshold.
Warning (yellow)
The number of denied transactions is 10% or less below the script

denial threshold.
Critical (red)
The script is automatically disabled if the number of denied
transactions is equal to or greater than the script denial threshold.
Disabled
The number of referred transactions is more than 25% below the
script referral threshold.
Referrals Safe (green)
The number of referred transactions is 1025% below the script
referral threshold.
Warning (yellow)
The number of referred transactions is 10% or less below tcript
referral threshold.
Critical (red)
The script is automatically disabled if the number of referred
transactions is equal to or greater than the script referral threshold.
Disabled

Refreshing Script Performance Data

You can refresh the script performance data by either clicking the refresh button on
the
window or by setting a refresh timer on the window to automatically refresh the
transaction
counts every specified number of minutes.
You can use the Refresh button to refresh the information displayed on the window,
but
not if the timer is running.
You start the automatic refresh by setting a number of minutes and clicking the start
refresh
timer button.You stop the automatic refresh by clicking the stop refresh timer button.
Enabling and Disabling Authorization

Scripts
Authorization scripts must be enabled in order to be used.You can enable and
disable
any script manually. Scripts can also be automatically disabled.
Note: Only top-level scripts are enabled and disabled. Subscripts are not.
Manually Enabling and Disabling Scripts

You can manually enable or disable a script by setting the Script Enabled Flag field
on the
Authorization Script Configuration window (Configure > Script > Authorization
Script).
Placing a check mark in the field enables a script; removing the check mark disables
a
script.
Note: Manually enabling a script does not necessarily mean that it will stay enabled.
Issues
with a script can cause it to be automatically disabled.
Automatically Disabling Scripts
A script used in authorization processing can be disabled automatically for the

following
reasons:
The script is monitored and one or more of the approve, deny, and refer rates do
not
meet requirements.
The script fails to set a response action code in the TDE.ACT_CDE operator.
A script runtime error, such as divide by zero, is encountered.
When an authorization script is disabled, the transaction being processed is rerouted,
such as to an alternate destination. If no other destinations are configured or cannot
be
used, the transaction is authorized by the default authorization.
If an impact script is disabled, the Exception Reason Code TDE is set for the
transaction
to indicate a system error and that the issuer is inoperative, an event is logged, and
processing continues normally.
If a reversal script is disabled, the Exception Reason Code TDE is set for the
transaction
to indicate a system error and that the issuer is inoperative, an event is logged, the
message
state is set to authorization not processed, and processing continues.
More About Scripts

Most of the information available about scripting is contained in the BASE24-eps
Scripting
Manual.
How Scripts Access Transaction Data

While parsing a transaction, BASE24-eps creates transaction data elements (TDEs).
Each
TDE represents transaction data, and when created, registers (exports) script
operators
that allow scripts to get and set transaction data, and identify any additional
authorization
destinations.
Card data and associated account (positive balances), limit, usage, and
preauthorization
hold data are accessed through Card and Positive Balance script objects and related
operators.The operators available for accessing and manipulating these data are
described
in the BASE24-eps Scripting Manual.
Setting Action Codes

Authorization scripts set the Action Code TDE to denote the response action
determined
for the transaction. Though there are numerous action codes, all actions are
categorized
as either approve, deny, or refer.
Each script used in authorization processing must set the Action Code TDE
(TDE.ACT_CDE) to a valid response action code. The TDE is set in scripts using the
TDE.ACT_CDE_SET operator. For example, the script statement below sets the
Action
Code TDE to a value of 101, which is a deny response for the reason that the
payment
instrument of the transaction being authorized had expired.
TDE.ACT_CDE_SET(101);
Note: Refer to Action Codes Supported by BASE24-eps on page 301 for a list of all
action
codes supported by BASE24-eps.
Working with Approval Codes

The Approval Code TDE provides the script operators to set and get the approval
code.
To get the approval code in script, use the TDE.APPRV_CDE exported operator.
This
operator returns the approval code of the transaction being processed or null if the
approval
code has not been generated.
To set the approval code in script, pass the transaction amount and PAN to the
TDE.APPRV_CDE_GEN exported operator. For example:
TDE.APPRV_CDE_GEN(txn_amount,txn_pan)

Note: Note that setting approval codes is not required through scripting because
approval
codes are generated by BASE24-eps automatically if a transaction is approved (refer
to
Approval Codes on page 140).
Sequential Routing
Sequential routing is a specialized form of transaction routing that can be built into
your
authorization scripts to enable a single transaction to be routed sequentially to one or
more
external destinations for processing. It differs from general transaction routing in that
it is
performed entirely by your authorization scripts.
From a general routing perspective, transactions are routed for authorization to an
Issuer
Authorization component and authorization script set. At that point, an authorization
script
itselfwhich must have been written specifically to use sequential routingtakes
over to
performs the necessary processing.
Sequential routing provides an added level of flexibility in that you can set up your
BASE24-eps authorization scripts to involve multiple external entitiese.g., ACI
Proactive
Risk Manager (PRM), ACI Smart Chip Manager (SCM), or multiple hosts. For
instance,
by routing a transaction to ACI Proactive Risk Manager (PRM), you can provide
online real
time scoring as input into the authorization of the transaction.You could route a
transaction
to ACI Smart Chip Manager (SCM) as part of EMV processing.You could use
sequential
routing to support mobile top-up transactions or for integration with third-party bill
payment
providers. Or you could send transactions to a specific host for data aggregation.
Ultimately,
a single transaction response is journaled and returned to the consumer, who
perceives
the occurrence as one business transaction.
Sequential routing is carried out using exported operators that provide access to
several
standard script-level routing functions.
Routing to a destination
Detecting the need to re-route a transactions to a secondary destination if a
particular
destination is unavailable
Reversing a transaction
Sending advices
Caution: If sequential routing is used in scripts, the Transaction Auditing Indicator for
the applicable route code on the Routing Configuration - Destination window must be
selected. Selecting this option disables transaction/TDE auditing. The reason for this
is that in sequential routing, the transaction is sent to multiple issuers and the
cumulative
effect of the transaction data is maintained. If the transaction needs to be rerouted
for
one of the issuers, the changes made to the transaction are not to be backed out or
undone.
Routing to a Destination from an Authorization Script

When a transaction is routed to an external destination during script processing, the
processing of the applicable script is suspended, the script context and transaction
data
are stored, and the transaction is routed to the specified destination. When the
transaction
response is returned, the script context and transaction data are retrieved, and
processing
of the script is resumed (and the same transaction could be routed to additional
external
destinations).
Note: Only top-level (business-level) authorization scripts (scripts specified for your
Authorization destinations) have the capability to perform sequential routing.
Prescreening
scripts (scripts specified for your Pre-Screen destinations) cannot perform seqential
routing.
Also, subscripts cannot perform sequential routing.
Note: For each external destination, transaction processing time increases, which
increases
the wait-time for the transaction originator expecting a response. Business impacts,
such
as time-out considerations, host processing capability, and customer expectations
should
be reviewed before implementing scripted destination processing.
Use of the SEQL_RTE_AUTH_RQST Script Operator
Basic destination routing is carried out within an authorization script using the
SEQL_RTE_AUTH_RQST script operator. This script operator can be invoked
multiple
times from a script to route a transaction to multiple external entities. The
SEQL_RTE_AUTH_RQST exported operator requires the following parameters:
Component ID and Name of the interface that is to receive the transaction (e.g.,
INTFHI93
and HISO93, respectively, for the ISO 8583:1993 Host Interface)
An optional true/false flag indicating whether a reversal is required to the specific
destination in the event that the transaction does not ultimately complete as
authorized.
For example, the script statement below specifies that a transaction is to be routed to
an
ISO 93 host interface (as identified by the INTFHI93 component ID) named
intf_host_93.
SEQL_RTE_AUTH_RQST(INTFHI93,intf_host_93,false);
Note: Authorization scripts that use the SEQL_RTE_AUTH_RQST operator for

sequential
routing must be identified by the keyword ROOT, but only authorization scripts
identified
as ROOT can be suspended (a requirement for sequential routing).
Request Processing
When the SEQL_RTE_AUTH_RQST exported operator is invoked from a script, the
Issuer
Authorization component performs the following processing:
1. Stores the current acquirer component ID from the Acquirer Component ID TDE to
the
Original Acquirer Component ID TDE.
2. Sets itself as the acquirersetting or overwriting the existing acquirer component
ID
with the Issuer Authorization component ID in the Acquirer Component ID TDE. This
ensures that a response from the issuer is returned to the Issuer Authorization
component
instead of the original acquirer component.
3. Sets up the Issuer Collection Index TDE based upon whether issuer-specific data
is
saved for that transaction leg or not.
If the Issuer Collection Index TDE does not exist, the Issuer Authorization
component
adds it with a current index of one and sets the first entry in the collection with a flag
indicating whether issuer-specific information is to be kept.
If the Issuer Collection Index TDE does exist, the Issuer Authorization component
increases the current index by one and adds a new entry in the collection after the
last entry with a flag indicating whether issuer-specific information is to be kept.
4. Invokes a new script component method (msg_send_extrn_suspend) to suspend
current
script processing.
If the function returns no error, continue.
If the function returns an error, return an error or false to the client.
Response Processing
When the Issuer Authorization component receives a response, it performs the
following
processing:
If the Original Acquirer Component ID TDE is present, which indicates that a
sequential
routing scenario is taking place, the Issuer Authorzation component performs the
following:
1. Restores the saved acquirer component ID (i.e., it replaces the acquirer
component
ID in the Acquirer Component TDE with the acquirer component ID from the Original
Acquirer Component ID TDE).
2. Invokes a new script component method (msg_send_extrn_resume) to resume
current
script processing.
If the function returns no error, continue.
If the function returns an error, return an error or false to the client.
If the Original Acquirer Component ID TDE is not present, which indicates no
sequential
routing scenario is taking place, current processing is performed.
Re-routing to an Alternate Destination From an Authorization

Script
Sequentially routing provides the capability to re-route transactions in scripts to
provide
for situations where a particular destination is unavailable. Re-routing differs from
simply
routing to a next destination in a planned sequence in that if a planned destination
fails to
respond, the transaction can be sent to an alternative destination.
Re-routing uses the same SEQL_RTE_AUTH_RQST script operator used to route
transactions to any destination. The key to re-routing is being able to determine
whether
a transaction failed and needs to be re-routed. This can be built into scripts using the
TDE.SEQL_RTE_TX_LEG_STAT exported operator of the Sequential Route
Transaction
Leg Status TDE. The Sequential Route Transaction Leg Status TDE is set by the
Routing
component, and the TDE.SEQL_RTE_TX_LEG_STAT operator returns the value R if
re-routing is required or N if re-routing is not required.
The Issuer Authorization component removes the Sequential Route Transaction Leg
Status
TDE after a transaction is successfully re-routed.
Reversing a Transaction
Creating and sending a reversal to a destination is carried out within an authorization
script
using the SEQL_RTE_ RVSL_RQST script operator. Sending a reversal can be
necessary
if a transaction does not complete as intended and needs be reversed by a
destination
that processed the transaction through sequential routing.
When a 1100, 1120, 1200, or 1220 transaction is routed to a destination from an
authorization script using the SEQL_RTE_AUTH_ RQST script operator, the
Sequential
Route Issuer Auth State TDE is set to indicate that sequential routing was performed.
The
SEQL_RTE_ISS_AUTH_ST exported operator of the Sequential Route Issuer Auth
State
TDE can be checked to determine whether sequential routing was performed (1
indicates
sequential routing was performed). This exported operator can be checked in
reversal
scripts if all destinations invoked during processing need to be notified of the reversal
being
generated.
The SEQL_RTE_ RVSL_RQST script operator requires the following parameters:
Component ID and Name of the interface that is to receive the reversal.
Sending Advices
To send advices to a host to indicate that re-routing, such as stand-in processing,
was
performed, use the TDE.ADVC1_REQ_UPDT and TDE.ADVC2_REQ_ UPDT script
operators to override the configuration specified in the routing configuration. Each
operator
requires a single value:
A = Advice 1 (or 2) required for approvals
B = Advice 1 (or 2) required for both approvals/denials
D = Advice 1 (or 2) required for denials

N = Advice 1 (or 2) required for none
Here is an example line in a script:

TDE.ADVC1.REQ_UPDT(B);
This allows the scripts to override those settings in your configured routing
destination for
the transaction. For example, for re-routed transactions, you might want to override
the
following approved-only settings to generate advices for both approved and denied
transactions (an operator value B).
Transaction Data Elements (TDEs)

The following TDEs are added to the transaction when sequential routing is invoked.
None
of these TDEs are logged to the Journal data source.
TDE Description
Issuer Collection Index. Contains the index of the current issuer as well as the
destinations routed to in order to access the proper issuer data within the
Sequential Route Information
collections of the issuer-specific TDEs that have been identified as pertinent in
a sequential routing scenario.
Original Acquirer Component ID. Contains the original acquirer component ID
value temporarily during a sequential route scenario when the Issuer
Authorization component overrides the acquirer component ID value in the
Acquirer Component ID TDE with its own component ID.
This allows responses to be returned to the Issuer Authorization component
from an interface component, instead of to the original acquirer component,
during a sequential routing scenario.
Contains the current script context information and script compilation timestamp
for use in a sequential routing scenario.
The information in this TDE is overwritten for each new destination in a
sequential routing scenario.
Sequential Route Script Context

In addition to the above TDEs that are added to the transaction when sequential
routing
is invoked, the following TDEs are updated on each leg of a sequential routing
scenario
with the information pertinent to that external destination:
Action Code
Authorizer Routing Destination
Default Authorization
If a transaction cannot be authorized by a primary or alternate authorizer using a
selected
destination matrix, default authorization processing is invoked.
Default authorization processing is straightforward. No scripts are involved. The
Router
component invokes the Default Authorization component which simply compares the
amount of the transaction to a default floor limit and then approves, declines, or
refers the
transaction based on whether it is over or under the floor limit.
Default authorization processing is configured as a part of routing to act as an
authorization
option of last resort. Default processing is defined in the Default Authorization
Information
fields on the General Information tab of the Routing Configuration - Destination
window
(Configure > Routing > Destinations).The following information is set for each
Transaction
Table entry.
Note: If a transaction is authorized by default, it generally indicates that a problem

exists,
such as a routing configuration or host communication problem. As a result, an event
message is logged to indicate default authorization has occurred. No impacting is
performed
for transactions authorized by default. Also, this method of authorization does not
allow
for matching reversals or advices.
Field Description
Specify the floor limit used for differentiating default actions. For example, if you set
this field to $9.99 and the transaction amount is greater than $9.99, the Over Limit
Floor Limit
Action would be taken. If the transaction amount is equal to or less than $9.99, the
Under Limit Action is taken.
The currency used is based on the country abbreviation value set in the
LGNT_COUNTRY_ABBR Environment attribute (e.g., if this attribute is set to a value
of USD, the default floor limit is in U.S. dollars). The currency used for these limits is
Specifies whether to approve, refer, or decline the transaction if the transaction amount
is greater than the floor limit. The action codes used in each case are as follows:
000 Approved
Over Limit Action
Specifies whether to approve, refer, or decline the transaction if the transaction amount
is equal to or less than the floor limit. The action codes used in each case are as
follows:
000 Approved
Under Limit Action

Approval Codes
Approval codes are unique identifiers created by transaction authorizers at the time a
transaction is approved to be used to validate the authenticity of the approval.
Approval
codes are only generated when a transaction is approved and can be used by
acquirers
as evidence of the approval. Approval codes are not generated if a transaction is
denied
or referred.
In BASE24-eps, approval codes are carried in the Approval Code TDE, which is
optionally
logged to journal files.You can use the Journal TDE Suppression window (Configure
>
Journal > Journal TDE Suppression) to suppress the logging of the Approval Code
and
other TDEs.
How BASE24-eps Handles Approval Codes

If a transaction is authorized by BASE24-eps, the BASE24-eps Issuer Authorization
component automatically generates an approval code and places it in the Approval
Code
TDE if an authorization script approves a transaction. Likewise, the Default

Authorization
component automatically generates an approval code and places it in the Approval
Code
TDE if default authorization is used and the default action code is an approval.
If a request is sent externally for authorization, it is the responsibility of the external
issuer
to generate the approval code. In this case, the BASE24-eps interfaces set the
Approval
Code TDE from the external response message. If the external issuer does not
generate
an approval code, the transaction will not have an approval code.
Note: Acquirer components set the Approval Code TDE, but only the maximum
Approval
Code Length which indicates to the issuer the maximum length of the approval code
they
should generate.
How BASE24-eps Generates Approval Codes

BASE24-eps creates approval codes by taking a binary representation of the hour,
minute,
and second elements of the transaction time and then adding to this the transaction
amount
and each digit of the PAN. For example, if the transaction time is 01:11:59, the binary
representation of 011159 is used as a basis for the approval code.
The length of the approval is determined from the approval code length set by the
acquirer
component in the Approval Code TDE.
BASE24-eps Transaction Limits and

Usages
BASE24-eps transaction limits are user-defined limits on transaction activity allowed
on
accounts and payment-instruments (cards) defined to the BASE24-eps system.
BASE24-eps
provides a basic structure for defining and implementing transaction limits, but
transaction
limits are implemented almost entirely using authorization scripts that you write. As
such,
there is a great deal of flexibility available to you, and you can create transaction
limits for
virtually any type of transaction activity you want to limit.
Generally speaking, though, transaction limits can be thought of in two basic forms:
A maximum monetary amount that can be approved during a single usage period
for
some type of transaction activity.
A maximum number of occurrences that can be approved during a single usage

period
for some type of transaction activity.
Transaction limits are typically defined relative to a particular span of time called a
usage
period. In BASE24-eps, each transaction limit you define has as its own specific
usage
period defined for it as well. As such, one limit might have a usage period of a day,
another
could have a usage period of a week, another a month, another several hours, and
so on.
It simply depends on how you choose to set up your limits. BASE24-eps also
facilitates
tracking transaction activity, called usage, separately for each limit you defineand
relative
to the usage period you have defined for the limit.
BASE24-eps transaction limits are configured using limit profiles. For more
information
about configuring transaction limits, refer to Limit Profiles - Where Limits are Defined
on
page 143. For information about tracking and viewing transaction activity, refer to
Tracking
Transaction Usage on page 152.
Its Done With Scripts

All limit and usage processing must be implemented through your authorization
scripts.
This fact cannot be overemphasized.The BASE24-eps system provides the basic
capability
and structure for defining limits and tracking corresponding usage. However, the way
in
which these limits and usages are handled depends entirely on what your
authorization
scripts do with them.
BASE24-eps Transaction Limits and Usages
Limits and usages are accessed from scripts using Limits and Usages exported
operators
and the Card and PBAL script operators (the latter for access to the Card and
Positive
Balance data sources, respectively). The BASE24-eps Scripting Manual describes
the
various functions available through these operators.
A set of sample authorization scripts is delivered with BASE24-eps which provides
some
basic templates for processing and predefined limits. If used, it is expected that
these
scripts and limits be thoroughly examined and modified to fit your environment.The
Sample
Fundamental Authorization Scripts Delivery Document contains a current list of
BASE24-eps
sample authorization scripts.

Limit Profiles - Where Limits are Defined

Limit profiles define a set of transaction limits that can be assigned to an institutions
cards
and accounts. Once a profile is assigned to a card or account, the transaction limits
in the
profile can be used by your authorization scripts for imposing transaction limits on
those
cards and accounts.
Limit profiles can also be assigned at the prefix level, in which case the limits defined
in
the profile can be used by your authorization scripts when processing transactions
on any
card or account associated with the prefix. Refer to Assigning Limit Profiles to Cards,
Accounts, and Prefixes on page 149 for information on assigning limit profiles.
Limit profiles are configured on the ACI desktop using the Limit Profile Management
window
(Customer Management > Limit Profile).
What is a Profile?
group
to and shared amongst multiple entities. They allow you to set up one set of values
and
use those same values over and over, saving time, in set up, and adding
consistency. In
the case of Limit profiles, they allow one or more cards, accounts, or prefixes to
share a
single set of limits.
Limit Profile Name and Institution

Each limit profile is identified by a profile name and institution ID. The profile name is
used
throughout the BASE24-eps system to identify the profile. The institution ID limits the
assignment of a profile to a specific institutions cards, accounts, or prefixes.
Currency
Each limit has a currency code associated with it which controls the currency in
which the
limit amount is expressed. Currency conversion between the currency of a
transaction and
the currency of the limit is performed if necessary. Refer to the BASE24-eps Multiple
Currency User Guide for more information on currency conversion.
Setting Up Limits within a Limit Profile

A Limit profile can contain one or more limits. Refer to Defining a Single Limit on
page 144
for information about setting up each limit.
Defining a Single Limit

Single (i.e., individual) limits are defined in a limit profile. Information is provided here
about
how to set up a single limit.
Each limit contains the values described in the table below which are defined in
corresponding fields on the Limit Profile Management window. Limits are not shared
amongst profiles. If the same limit is to be part of multiple profiles, it must be defined
in
each profile.
Keep in mind, limit profiles are defined at the institution level which is to say they can
only
be applied to a single institutions cards and accounts.
Refer to Limit Profiles - Where Limits are Defined on page 143 for information about
setting
up limit profiles.
Field Description
The name of the limit. This is the exact name by which the limit is referenced in scripts.
Refer to Pre-defined Sample Limits and Usages for names that are set up in the sample
scripts provided with BASE24-eps.
Limit Name
Limit Amount The amount associated with the limit. This field is set to zero if the limit is for a count.
Limit Currency Code A currency code identifying the currency in which the limit amount is specified.
Limit Count The count associated with the limit. This field is set to zero if the limit is for an amount.
These fields define the usage period associated with the limit. The amount and count are
allowed within this usage period specified. Refer to Defining the Usage Period Associated
with a Limit for information on setting up the usage period.
Usage Period
Period Option
Defining the Usage Period Associated with a Limit

Each limit defined in the limit profile has a specific usage period associated with it.
This
usage period defines the length of time to which the limit is to be applied.The usage
period
is defined by the Usage Period and Period Option fields on the Limit Profile
Management
window.
Usage Period Period Option
Usages not Cleared Not applicable.
With this option, the accumulated usage amounts and
transaction counts are never cleared.
Fixed number of days The number of days of the usage period.
The day of the week on which accumulated amounts are
reset.
One Week, Two Weeks
1st and 15th of each month Not applicable.
The accumulated amounts are reset in the applicable
month. Options are the 1st through the 28th.
Every month,
Every 3 months,

Usage Period Period Option
Every 6 months,
Every Year
Daily, except Saturdays, Sundays, and holidays Not applicable.
Daily, except Sundays and holidays Not applicable.
Daily, except Saturdays and holidays Not applicable.
Fixed number of hours The number of hours of the usage period.
The Actual Time a Usage Period Starts and Ends

The actual time at which usage periods start and end differs depending on the type
of
usage period you choose. This table describes the starting and ending times based
on
type of usage period. For information on how usages are tracked, refer to Tracking
Transaction Usage on page 152.
Usage Period Time Description
Increment
If the usage period option is a fixed number of hours, the usage period begins when the
first transaction occurs on the card or account to which the limit applies. For example, if
Hours
2 hours is selected and the first transaction occurs at 8:05am, the usage period would
start for that card or account at 8:05am and end at 10:05am. A new usage period would
then start with the first transaction that occurs after 10:05am. If the first transaction after
10:05am occurs at 10:45am, the new usage period would start for the card or account at
10:45am and expire at 12:45pm (10:45am plus 2 hours). The subsequent usage period
would start with the first transaction after 12:45pm, and so on.
For daily and fixed number of day usage period options, the usage period is based on the
institution cutover time plus the offset defined for the institution. For example, if the usage
Daily, Fixed Number of
Days
period is one day, the institution cutover occurs at 6:00pm, and the offset is 300 minutes,
the usage would reset immediately after 11:00pm hourslimits would apply to the 24-hour
period immediately after 11:00pm up to and including 11:00pm the next day.
An institutions cutover time and offsets are configured in the Balance and Cutover End
Time and Usages Cutover Offset fields on the Institution Configuration window.
For week-, month-, and annual-based usage periods, usages always reset immediately
after 12:01am. For example, if a limit was defined with a usage period of one month, and
Weeks, Months, Annual,
1st or 15th of the month
the start of the next usage period for that limit was March 23 at 12:01am, all usages
applicable to the limit that are created on or after March 23 at 12:01am up to April 23 at
12:01am would be given an expiration date of April 23, 12:01am.
Pre-defined Sample Limits and Usages

To understand some of the underlying concepts, it is helpful to see examples of how
limits
can be defined. The following table contains many of the limits defined in the sample
authorization scripts delivered with BASE24-eps. The limits and their usages follow
the
limit/usage naming convention where the usage takes its name from the limit to
which it
corresponds.The limits you choose to use need not be named or implemented as
described
here. What is critical, however, is that the limits you choose to write into your scripts
correspond to those you define in your limit profiles.
Note: The Sample Fundamental Authorization Scripts Delivery Document contains a
current list of limits defined in the BASE24-eps sample authorization scripts along
with
additional information about the sample scripts.
Limit Name Description
The maximum amount of purchases and cash withdrawals allowed against noncredit
accounts.
TTL_CASH_WDL
The maximum amount of purchases and cash withdrawals allowed offline against
noncredit accounts. The amount in this field is used only when the authorizing host
is unavailable and the BASE24-eps product performs stand-in authorization.
OFFLINE_CASH_WDL
TTL_CASH_ADV The maximum amount of cash advances allowed against credit accounts.
The maximum amount of cash advances allowed offline against credit accounts.
The amount in this field is used only when the authorizing host is unavailable and
the BASE24-eps product performs stand-in authorization.
OFFLINE_CASH_ADV
The maximum aggregate amount of cash disbursements allowed against credit and
noncredit accounts, plus purchases allowed against noncredit accounts.
TTL_AGGR
The maximum aggregate amount of cash disbursements allowed offline against
credit and noncredit accounts and purchases allowed offline against noncredit
OFFLINE_AGGR
accounts. The amount in this field is used only when the authorizing host is
unavailable and the BASE24-eps product performs stand-in authorization.
The number of times the cardholder has entered an incorrect PIN at terminals during
the current usage accumulation period.
BAD_PIN_TRIES
OVER_DRAFT_LMT The amount available for overdraft on this account.
The minimum cash advance amount allowed for transfer or payment transactions
that withdraw funds from a credit account.
MIN_CASH_ADV
The standard increment amount used to determine the amount of transfer or payment
transactions that withdraw funds from a credit account.
CASH_ADV_INCR
The maximum number of times this card can be used to withdraw cash in a single
usage accumulation period.
ATM_PER_PRD_LMT
ATM_TTL_CSH_WDL The maximum amount of cash withdrawals allowed against noncredit accounts.
The maximum amount of cash withdrawals allowed offline against noncredit accounts.
The amount in this field is used only when the authorizing host is unavailable and
the BASE24-eps product performs stand-in authorization.
ATM_OFF_CSH_WDL
ATM_TTL_CSH_ADV The maximum amount of cash advances allowed against credit accounts.
The maximum amount of cash advances allowed offline against credit accounts
using the BASE24-atm product. The amount in this field is used only when the
ATM_OFF_CSH_ADV
authorizing host is unavailable and the BASE24-eps product performs stand-in
authorization.
The maximum amount of purchases and cash withdrawals allowed against credit
accounts.
POS_TTL_PURCH
The maximum amount of purchases and cash withdrawals allowed offline against
noncredit accounts. The amount in this field is used only when the authorizing host
is unavailable and the BASE24-eps product performs stand-in authorization.
POS_OFF_PURCH
POS_TTL_CSH_ADV The maximum amount of cash disbursements allowed against credit accounts.

Limit Name Description
The maximum amount of cash disbursements allowed offline against credit accounts.
The amount in this field is used when the authorizing host is unavailable and the
BASE24-eps product performs stand-in authorization.
POS_OFF_CSH_ADV
The total amount of purchases and cash withdrawals made against noncredit
accounts.
POS_TTL_CSH_WDL
The total amount of purchases and cash withdrawals made offline against noncredit
accounts. The amount in this field is always used with offline processing, and is also
POS_OFF_CSH_WDL
used when the authorizing host is unavailable and the BASE24-eps product performs
stand-in authorization.
The maximum number of times a card with this card prefix can be used during a
single usage accumulation period.
POS_PER_PRD_LMT
The total amount of refunds and replenishments made against credit and noncredit
accounts.
POS_TTL_RFND_CR
The total amount of refunds and replenishments made offline against credit and
noncredit accounts.
POS_OFF_RFND_CR
The number of refunds and replenishments this cardholder has performed during
the current usage accumulation period.
POS_NUM_RFND
The number of refunds and replenishments this cardholder can perform during the
current usage accumulation period.
POS_PER_RFND_LMT
The maximum number of transactions that can be performed since the last ATC
check (allows for offline authorization by device).
ATC_LMT_CHK
DEP_CR_AMT_PRD Amount of Deposit Credits
DEP_CR_NUM_PRD Number of Deposit Credits
MAX_DEP_CR_AMT Maximum Deposit Credit Amount
DEP_CR_PCT Deposit Credit Percent
MAX_DEP_CR_NUM Maximum Number of Deposit Credit
MAX_CR_PER_DEP Maximum Credit Per Deposit
MAX_DEP_CR_AMT Maximum Deposit Credit Amount
Limit Examples
The following are several examples of limits that could be set up in a limit profile. In
this
case, the limits are based on those defined in the BASE24-eps sample scripts. They
are
also in United States currency.
Period
Option
Limit Usage Period
Count
Limit
Amount
# Limit Name
1 TTL_CASH_WDL $7,000 n/a Fixed number of days 7
2 OFFLINE_CASH_WDL $2,000 n/a Fixed number of days 1
3 TTL_CASH_ADV $7,000 n/a One Week Monday
4 OFFLINE_CASH_ADV $1,500 n/a Fixed number of days 1
5 ATM_PER_PRD_LMT 2 Fixed number of days 1

Period
Option
Limit Usage Period
Count
Limit
Amount
# Limit Name
6 TTL_AGGR $20,000 1st and 15th of each month n/a
7 OFFLINE_AGGR $2,500 Fixed number of days 1
1. TTL_CASH_WDL - Limits purchases and cash withdrawals allowed against

noncredit
accounts to $7,000 over a seven-day period.
2. OFFLINE_CASH_WDL - Limits offline purchases and cash withdrawals against
noncredit
accounts to $2,000 in a single day. This limit would typically be used when the
authorizing
host is unavailable and the BASE24-eps product performs stand-in authorization.
3. TTL_CASH_ADV - Limits cash advances allowed against credit accounts to

$7,000
from Monday of one week to Monday of the next.
4. OFFLINE_CASH_ADV - Limits offline cash advances against credit accounts to
$1,500
in a single day. This limit would typically be used when the authorizing host is
unavailable
and the BASE24-eps product performs stand-in authorization.
5. ATM_PER_PRD_LMT - Limits the number of cash advances to 2 in a single day.
6. TTL_AGGR - Limits cash disbursements allowed against credit and noncredit
accounts,
plus purchases allowed against noncredit accounts to $20,000 from the first through
the 14th of the month and from the 15th through the end of the month .
7. OFFLINE_AGGR - Limits offline cash disbursements against credit and noncredit
accounts and purchases allowed offline against noncredit accounts to $1,500 in a
single
day. This limit would typically be used when the authorizing host is unavailable and
the
BASE24-eps product performs stand-in authorization.
Assigning Limit Profiles to Cards,

Accounts,
and Prefixes
Once defined, limit profiles can be assigned to individual cards or accounts or
prefixes. If
assigned to cards and accounts, the limits defined in the profile can be used by your
authorization scripts when processing transactions on these cards or accounts. If
assigned
at the prefix level, the limits defined in the profile can be used by your authorization
scripts
when processing transactions on any card or account associated with the prefix.
The following table identifies the fields in which the limit profiles are assigned.
Type Window Tab Field
Card Management window (Customer Limits Limit Profile
Management > Card)
Cards
Positive Balance Management window (Customer Limits Limit Profile
Management > Positive Balance)
Account
On-Us Prefix Configuration window (Configure > Issuer Information Limit Profile
Prefix > On-Us)
On-Us Card Prefixes
System Prefix Configuration window (Configure Not applicable Limit Profile
Not-On-Us Card
Prefixes

Setting Limits for Cards and Accounts
The basic approach to setting up limits for a card or account is to create a limit profile
and
then assign it to those cards, accounts, and prefixes to which the limit profile applies.
Refer to Limit Profiles - Where Limits are Defined on page 143 for information on
setting
up limit profiles.
BASE24-eps provides the capability to add additional limits for a specific card or
account.
It also provides the capability to override one or more limits in the limits profile for a
specific
card or account. This could, for instance, enable you to set individual cash advance
limits
for a specific account or perhaps to override a general cash advance limit defined in
a
profile.
Assigning a Limit Profile to a Card or Account

The limits profile to use for a card is specified in the Limit Profile field on the Limits
tab of
the Card Management window.This is a pull-down menu that lists all available limit
profiles.
The limits profile to use for an account is specified in the Limit Profile field on the
Limits
tab of the Positive Balance Management window. This is a pull-down menu that lists
all
available limit profiles.
Adding or Overriding Individual Limits for a Card or Account

Adding new limits for a specific card or account, or creating limits that override
existing
limits in the limit profile is done basically the same wayby adding these limits to the
Limits
tab of the Card Management or Positive Balance Management window.
New limits are limits fully defined in the card and account record and not included in
a limit
profile associated with the card or account. These new limits can only be used with
those
cards or accounts for which they are defined.
Override limits override a matching limit defined in a profile. If a limit of the same
name is
configured in both the limit profile and on the card or account limit tab, the limit on
the tab
overrides the limit in the limit profile for the particular card or account.
New and override limits are set up with basically the same fields as are used to set
up
limits in a limit profile. Refer to Defining a Single Limit on page 144 for a description
of setting
up individual limits in a limits profile. The difference is that the card- and accountspecific
limits can be set up to expire. The following table summarizes the fields used for
card- and
account-specific limits.
Note: BASE24-eps provides for a maximum of six new limits or overrides for a single
card
or account.
Limit Expiration
Date
Use Expiration
Date
Period
Option
Usage
Period
Limit Limit Count
Amount
Limit Name
Enable the limit to expire (refer to Setting
Up a Limit or Limit Override to Expire).
Same as defined for a limit in the Limits Profile. Refer to Defining a Single
Limit on page 144 for information about these fields.
Setting Up a Limit or Limit Override to Expire

An expiration date can be configured for each additional limit or limit override so that
it only
applies for a temporary period of time. The following fields are associated with each
limit
and used for this purpose.
Field Description
Placing a check mark in this field activates the Limit Expiration Date for a particular
limit (row). If this field is left blank when you save a card record, the limit does
not expire.
Use Expiration Date
The date the corresponding limit will expireonly used if the Use Expiration Date
field contains a check mark.
Limit Expiration Date
When the limits are retrieved from the Card or Positive_Balance data source, the
transaction
date and time is compared to the limit expiration dates, and if a limit has expired, it is
not
used.
Tracking Transaction Usage

In order to impose transaction limits over a set period of time, related transaction
activity
needs to be tracked over that period of time so that the cumulative effects of that
transaction
activity can be included when evaluating any new transactions against the limits.
BASE24-eps provides for tracking transaction activity through its implementation of
usages.
What are Usages?

In BASE24-eps, a usage is a single, logically discrete, expiration-dated record of
some
type of transaction activity on a card or account. Usages are designed to correspond

directly
to the limits you have defined for your authorization scripts. For example, if you limit
total
withdrawals on a card or account, you would likely track all withdrawals. In this case,
you
would write your scripts to create a usage for every withdrawal. That way, all of the
usages
occurring within a usage period can be tallied to determine how much has been
withdrawn.
BASE24-eps provides the capabilities needed to enable your scripts to create and
accumulate usages relative to each of your defined transaction limits and to use the
accumulated usages to determine whether a transaction would cause the
corresponding
limit to be exceeded.
Note: Usages are still maintained at the card/account level even if limits are defined
at
the prefix level. The key is that prefix limits still actually define limits for those cards
and
accounts associated with the prefix. Thus, the usage still needs to be tracked at the
card/account level.
Active and Expired Usages

Usages are either active or expired. Each usage carries an expiration date and time
set
when the usage is createdthat identifies the start of next usage period for the limit
to
which the usage corresponds.
For example, if a limit was defined with a usage period of one week and the start of
the
next usage period for that limit was Monday, February 23 at 12:01am, all usages
applicable
to the limit that are created on or after Monday, February 16 at 12:01am up to
Monday,
February 23 at 12:01am would be given an expiration date of February 23, 12:01am.
Prior to the expiration date and time, the usage is considered active. As of the
expiration
date and time, the usage is considered expired.
Active usages are viewable from the Usages Management window. Expired usages
are
not.
Usage Accumulation Example

The following example illustrates in a very basic way how usages are created,
accumulated,
and expired for a single limit that you might define in your authorization scripts. In
this case,
the limit has a fixed-day usage period of 2 days.
Note: The beginning of each new usage period, as well as the usage expiration
involves
both a date and time; however, just the date has been used here for simplicitys
sake.
Usage Accumulation Exampe
Active
Usage
Usages Usage Period Usage Period Usage Period
Feb-1 Feb-2 Feb-3 Feb-4 Feb-5 Feb-6
1 $215 Feb-3 $215
2 $20 Feb-3 $235
3 $50 Feb-3 $285
4 $50 Feb-5 $50
5 $100 Feb-5 $150
6 $50 Feb-5 $200
7 $100 Feb-5 $300
8 $50 Feb-7 $50
9 $50 Feb-7 $100
10 $25 Feb-7 $125
1. A $215 transaction posts Feb-1; a usage is created for $215, with its expiration set
to
Feb-3 (the beginning of the next usage period for the particular limit); the total active
usage for the current period is $215.
2. A $20 transaction posts Feb-1; a usage is created for $20, with its expiration set to
Feb-3; there are now two active usages, and the total active usage for the current
period
is $235.
Feb-3
(still the beginning of the next usage period for the particular limit); there are now
three
active usages, and the total active usage for the current period is $285.
Feb-5
(the beginning of the next usage period for the particular limit); since a new
accumulation
period has started, the individual usages created in steps 13 are expired and no
longer
used, there is now one active usage, and the total active usage for the current period
is $50.
to
period
is $150.
Feb-5; there are now three active usages, and the total active usage for the current
period is $200.
to
Feb-5; there are now four active usages, and the total active usage for the current
period
is $300.
Feb-7
accumulation
period has started, the individual usages created in steps 47 are expired and no
longer
used, there is one active usage, and the total active usage for the current period is
$50.
period
is $100.
to
Feb-7; there are three active usages, and the total active usage for the current
period
is $125.
What Information is Stored for Each Usage

BASE24-eps provides for storing individual usages in the Usage data source and
displaying
them on the Usages Management window. Each usage record written to the Usage
data
source can contain up to 85 actual usages. Usages are stored with the following
information
(shown as record-level fields and usage-specific fields). Authorization scripts write
and
read these values using script operators.
Record-Level Fields
Field Description
Institution ID The institution ID of the institution to which the card or account belongs.
The type of instrument to which the usage applies: Card or Account. Card is represented
in the data record as CD; account is represented in the data record as AC.
Usage Instrument
The card or account number to which the usage applies, depending on the type of instrument
to which the usage applies.
Card Number or Account
Number
A card member number if the instrument type is a card; an account type value if the
instrument type is an account.
Member Number or
Account Type
The following information is carried for each usage.

Usage-Specific Fields
Limit Usage Name A name assigned to the usage (refer to Usage Naming).
The amount of the usage. This could be a positive or negative value depending on how your
scripts handle the usages.
Limit Usage Amount
Currency Code The currency code associated with the usage amount.

Usage-Specific Fields
The date and time that the next usage period begins for the limit to which this usage
corresponds. This is the date and time the usage expiresafter which it will no longer be
used for the associated usage.
Next Begin Date and
Time
Usage Naming
All usages are created and acted on by your authorization scripts. Although it is not
required,
it is highly recommended that you adopt a convention for naming your usages where
the
usage name matches the limit to which it corresponds. The following table shows the
basic
suggested relationship between the limit and usage names.
Limit Name Usage Name
TTL_CASH_WDL TTL_CASH_WDL
OFFLINE_CASH_WDL OFFLINE_CASH_WDL
TTL_CASH_ADV TTL_CASH_ADV
OFFLINE_CASH_ADV OFFLINE_CASH_ADV
ATM_PER_PRD_LMT ATM_PER_PRD_LMT
TTL_AGGR TTL_AGGR
OFFLINE_AGGR OFFLINE_AGGR
System-Defined Usages for Deriving Current Balances

There are three usage names that are system-defined specifically for the purpose of
tracking
balance changes. The formats of the usage names are as follows:
AVAIL_yyyymmdd For available balances of debit accounts
LEDG_yyyymmdd For ledger balances of debit accounts
AVAILCR_yyyymmdd For available credit of credit accounts
These usages are used by the Positive Balance component for calculating current
balances,
which the Positive Balance component makes available to your authorization scripts
through
exported operators.
The Positive Balance component computes a current balance by accessing the startof-day
balance in the Positive Balance data source and adding or subtracting the
corresponding
usages. For example, when a $100 withdrawal transaction is processed, your
authorization
script could create a $100 AVAIL_yyyymmdd usage and write it to the Usage data
source.
Then, when called upon (by script) to do so, the Positive Balance component would
derive
the customers current available balance by subtracting the $100 usage from the
start-of-day
available balance. Thus, if the customer started with an available balance of $1,500,
and
had an AVAIL usage of $100, the derived current available balance would be $1,400.
The dates (yyyymmdd) included in the usage names represents the capture date of
the
transaction, which is also the date of the journal file to which a transaction is logged.
The
capture date is determined as follows:
ATM device handlers The posting date of the ATM terminal file.
POS device handlers The posting date from the device message or posting date
from the POS terminal file.
Network Interfaces Per the logical network cutover time. If the transaction is
before
the logical network cutover time, the capture date is set to the current date. If the
transaction is on or after the logical network cutover time, the capture date is the
current
date plus one day.
Host Interface The posting date from the external message. If the posting date is
not
present, the capture date is calculated the same as for network interfaces.
The expiration date/time for the AVAIL_yyyymmdd, LEDG_yyyymmdd, and
AVAILCR_yyyymmdd usages works the same as for other usages: the usages
remain
active up to the expiration date/time. However, the expiration date/time are
calculated
differently for these usages.
The expiration date is calculated using the number of days set in the Balance Usage
Retention Period field on the Settings tab of the Institution Configuration window. So
if a
transaction is processed on March 1 and the number of days is set to two, the
expiration
date would be March 3.
The expiration time is based on the institution cutover time plus the offset defined for
the
institution. For example, if the institution cutover occurs at 6:00pm, and the offset is
300
minutes, the expiration time would be 11:00pm.
An institutions cutover time and offsets are configured in the Balance and Cutover
End
Time and Usages Cutover Offset fields on the Institution Configuration window.
Viewing and Deleting Active Usages

Active usages for both accounts and cards can be viewed using the Usages
Management
window (Customer Management > Usages). This window also enables you to delete
any
of the listed usages.
The following is an account view of the Usages Management window.
The following is a card view of the Usages Management window.
What Happens to Expired Usages

Usages that expire are written over automatically in the Usages data source as new
usages
are created for cards or accounts. Typically, space is recycled and no action is
required
to clean up expired usages. However, if a large number of card and account records
have
become inactive, it may be advisable to delete the expired usages manually in order
to
reclaim file storage space.
To delete expired usages, use the Process Control window to deliver a CLEANUP
command
to the RFSH destination identifying Usage Cleanup as the component. Refer to the
BASE24-eps Process Control User Guide for more information.
Cash Advance Minimums and Increments

for
an Account
A cash advance minimum is the lowest amount allowed for a cash advance; a cash
advance
increment is the increment (in whole current units) in which cash advances must be
requested. For example, if a cash advance minimum is $100 and the increment is
$50,
the allowable cash advance amounts would be $100, $150, $200, $250, and so on
up to
the maximum cash advance allowed. Cash advances for amounts such as $50 (too
low),
$75 (too low and incorrect increment), or $175 (incorrect increment) would not be
allowed.
BASE24-eps provides the capability to set and support cash advance minimums and
increments for those accounts defined in the Positive Balance data source (note that
this
capability is not supported at the instrument/card level).
Minimum and increment values are set in the Minimum and Increment fields in the
Cash
Advance section of the Limits tab on the Positive Balance Management window and
are
stored in the Positive Balance (PBAL) data source.Values are set as whole currency
units.
If the increment is $0, any amounts equal to or greater than the minimum amount up
to
the maximum amount allowed for a cash advance transaction are allowed.
Use of the cash advance minimum and increment are script-driven, which is to say
that
the evaluation must be carried out by your authorization scripts. When processing a
cash
advance on an account, the values would need to be accessed, by exported
operator,
from the PBAL data source and acted on by your scripts (i.e., denied if transaction
amount
is less than the minimum or not divisible by the increment).
Preauthorization Holds
In BASE24-eps, a preauthorization hold is a single, logically discrete, expirationdated hold
for a specific transaction amount placed on a card or account to ensure that
sufficient funds
are retained to pay for amount of the hold.
Preauthorization holds are typically created as part of processing preauthorization
transactions, although they can be added manually as well. The net effect of a hold
is that
cardholders cannot use their entire available account balance, but are instead
restricted
to the amount of their balance minus the amount of any outstanding holds against it
this
would be in addition to any usage on the card or account. The actual account
balance is
not affected in this case, only the cardholders ability to use all of it. Holds are given
expiration dates and once expired have no further impact on processing. They can
also
be removed manually or as part of transaction processing.
BASE24-eps provides the capability to support preauthorization transactions and to
support
and manage preauthorization holds on payment instruments (cards) and accounts
defined
to the BASE24-eps system.
What are Preauthorization Transactions?

Preauthorization transactions are transactions completed in two stages: an
authorization
stage and a completion stage. The authorization stage is intended to place a
preauthorization hold on funds from a cardholders card or account when goods are
purchased but the final cost to the cardholder cannot be determined exactly.The
completion
stage is the follow-up to the purchase once the final cost of the transaction is known.
Not all point-of-sale environments support the concept of a preauthorization.
However,
self-service fueling stations and hotel stays are two classic scenarios in which
preauthorization transactions are used by the merchant.
Self-service Fueling Stations

In the self-service fueling station, a cardholder swipes a card at a fuel pump. Once
pumping
has begun, it is difficult for the fueling station merchant to reclaim the product that
has
been pumped into an automobiles tank if it is found that the cardholder does not
have
enough available funds to cover the purchase. To minimize this risk, a fueling station
merchant can initiate a preauthorization transaction for a pre-determined amount that
is
an approximation of the final cost of an automobile fill-up. As a result of the
preauthorization,
those funds are placed on hold at the issuing bank. After the fuel dispensing has
completed,
the final price of the transaction is determined, and a completion transaction can be
sent
to the issuing bank to remove the hold on funds and apply the actual cost of the
transaction.
Hotel Stays
In the case of a hotel stay, preauthorizations can be used to minimize the risk of
having a
patron stay at the hotel for a time, and then not have the funds at the end of the stay
to
pay for their visit. The hotelier can reserve funds in the cardholders account to cover
the
expected cost of the stay by initiating a preauthorization transaction. Once the hotel
patron
checks out of the hotel, the final cost can be calculated and the holds on funds can
be
removed and replaced by the actual cost.
Basic Preauthorization Transaction Flow

Transactions involving a preauthorization would typically be set up to flow in the
following
manner. This information is provided as an example to help understand the concepts
of
preauthorization. Routing and authorization within BASE24-eps is highly configurable
and
controlled by the configuration choices you make and how your authorization scripts
are
written. Other components are involved as well.
1. At the beginning of the transaction, before the final total is known, the acquirer
sends
a purchase request for an upper-limit amount as a 1100 authorization request
message.
It is received by the Acquirer component and routed to the Issuer Authorization
component.
2. The Issuer Authorization componentusing scriptsapproves the transaction,
places
a hold on the card or account for the requested amount using the Preauthorization
Hold
component, and returns a 1110 response message to the acquirer component. The
retrieval reference number sent in authorization request is used as the
preauthorization
sequence number.
3. The Acquirer component journals the 1110 message and returns the message to
the
transaction originator.
4. Once the final total is known and the goods or services are delivered, the
transaction
originator generates a 1220 preauthorization completion request with the final
total.The
1220 contains the same retrieval reference number as the original 1100. It is
received
by the acquirer component, which routes the transaction to the Issuer Authorization
component.
5. The Issuer Authorization component processes the 1220 preauthorization
completion
request. It removes the hold using the Preauthorization Hold component, adds usage
information for the actual amount of the transaction using the Usages component,
and
returns the 1220 message to the acquirer component.
6. The acquirer component journals the 1220 message and returns a 1230 message
to
the transaction originator.
Incremental Authorization Example

The following is an example in which incremental authorization is used. There are no
specific configuration parameters to provide for this, so if required, this type of
processing
would need to be written into your scripts.
In the case of incremental authorization, multiple preauthorization completion
transactions
could be used to adjust an original preauthorization hold. In this case, the original
hold
would be reduced by the amount of the subsequent completion messages.
BASE24-eps scripts currently support incremental authorization for certain Visa
transactions
only, in which case, the presence of a specific TDE, along with the same
preauthorization
hold ID is used to identify a 1220 preauthorization completion message as an update
to a
hold rather than the final amount of the transaction. Note that for Visa incremental
authorization transactions, Visa uses its own transaction ID for matching holds rather
than
the hold ID used by BASE24-eps. Also, the message types to and from Visa would
differ
from those used internally by BASE24-eps.
1. At the beginning of the transaction, the acquirer sends a purchase request as a

1100
authorization request message. The transaction is approved, a hold is placed on the
card or account, and a 1110 response message is journaled and returned. The
retrieval
reference number sent in the authorization request is used as the preauthorization
sequence number. For this example, the hold amount is $500.
2. The acquirer sends a completion message as a 1220 preauthorization completion
request with the same retrieval reference number for the amount the hold is to be
decreased. The transaction is approved, the hold is updated, a new expiration date
and
time is set, a usage is added, the 1220 message is journaled and a 1230 message is
returned. In this example, if the amount sent was $100, the hold would be reduced
by
$100 to $400 and a $100 usage would be added.
Note: This process could be repeated any number of times as long as the proper
information is sent and the transaction amount is less than (or equal to) the hold
amount
that remains.
3. Once the final hold is to be removed, the acquirer sends a normal 1220
preauthorization
completion request with the amount equal to the amount of the hold remaining. The
1220 contains the same retrieval reference number as the original 1100. The hold is
removed, the final amount of the hold is added as a usage, the 1220 message is
journaled, and a 1230 message is returned to the transaction originator. In this
example,
the preauthorization completion request would be for $400, which is the amount of
the
hold remaining.
Authorization Scripts Scripting

Preauthorization Hold Processing
For the most part, preauthorization hold processing must be implemented through
your
authorization scripts. This fact cannot be overemphasized. The BASE24-eps system
provides the basic capability and structure for creating and managing holds.
However, the
way in which these preauthorization holds are handled depends on what your
authorization
scripts do with them.
Holds are created and accessed from scripts using Preauthorization Hold exported
operators
and the Card and PBAL script operators (the latter for access to the Card and
Positive
Balance data sources, respectively). The BASE24-eps Scripting Manual describes

the
various functions available through these operators.
The set of sample authorization scripts delivered with BASE24-eps provides some
basic
templates for preauthorization processing. If used, it is expected that these sample
scripts
be thoroughly examined and modified to fit your environment. The Sample
Fundamental
Authorization Scripts Delivery Document contains a current list of BASE24-eps
sample
authorization scripts.
Active and Expired Preauthorization Holds

Preauthorization holds are either active or expired. Each hold carries an expiration
date
and timeset when the hold is createdthat identifies the date and time after which
the
hold should no longer be applied to the card or account.
Prior to the expiration date and time, the hold is considered active. As of the
expiration
date and time, the hold is considered expired. For example, if a hold is created with
an
expiration of February 28 at 11:00, it will be active up to that date and time. On
February
28 at 11:00, it will be considered expired.
Active holds are viewable from the Preauthorization Hold Management window.
Expired
holds are not.
How is the Expiration Date/Time Determined

The expiration date and time associated with a preauthorization hold is determined
when
the hold is created, based on a expiration increment value and number supplied in
the
transaction.The increment value and number can be supplied by the transaction
originator
or it can be set up as a default within BASE24-eps. The following are examples of
how the
expiration date and time are calculated for several holds.
Note: The hold increment value and number can also be referred to as the
Authorization
Life Cycle Code.
Creation Specified Interval Expiration
Date Time Increment Number Date Time
Mar-1 6:00 Hours 1 Mar-1 7:00
Mar-1 6:00 Hours 4 Mar-1 10:00
Mar-1 6:00 Days 1 Mar-2 6:00
Mar-1 6:00 Days 2 Mar-3 6:00
Mar-1 6:00 Month 1 Apr-1 6:00
Getting Expiration Information from the Transaction Originator

BASE24-eps supports the capability for transactions originators to provide the
increment
value and number for creating the hold expiration date/time. If provided by the
transaction
originator, this information is moved into the Preauthorization TDE by the interface or
channel manager communicating with the transaction originator. If increment
information
is not provided by the transaction originatoror the number is set to 0default
values will
be used if they are available.
Hold Expiration Defaults Settings

BASE24-eps supports the capability of setting up default expiration parameters that
can
be used if they are not supplied by the transaction originator. The following table
describes
how the defaults are set and under what circumstances they are used.
Default Settings
Type Usage Window Tab Field
Default
Preauthorization Hold
Merchant Channel Processing
Profile Configuration
Used if the terminal does
not provide the expiration
information.
Terminal
<interface> Default Values Default Pre-Auth. Hold
Configuration
window
Used if the host or
interchange does not
provide the expiration
information.
Host/ Interchange
Default
Processing
Information
Used if the expiration On-Us Prefix
information is not provided
by the endpoint or by a
default setting.
Prefix

What Information is Stored For Each

BASE24-eps provides for storing individual preauthorization holds in the
Preauthorization
Hold data source and displaying them on the Preauthorization Hold Management
window.
Each record written to the Preauthorization Holds data source can contain up to 70
actual
holds.
Preauthorization holds are stored with the following information (shown as recordlevel
and hold-specific fields). Authorization scripts write and read these values using
script
operators.
Record-Level Fields
Field Description
Institution ID The institution ID of the institution to which the card or account belongs.
The type of instrument to which the preauthorization hold applies: Card or Account. Card
is represented in the data record as CD; account is represented in the data record as AC.
Hold Instrument
The card or account number to which the preauthorization hold applies, depending on the
type of hold instrument.
Card Number or Account
Number
A card member number if the hold instrument type is a card; an account type value if the
hold instrument type is an account.
Member Number or
Account Type
The following information is carried for each hold.

Hold-Specific Fields
Field Description
The type of preauthorization hold transaction. This is a user-defined value that can be
used to categorize holds. For information about possible values, refer to Preauthorization
Hold Types.
Hold Type
The amount of the preauthorization hold. This could be a positive or negative value
depending on how your scripts handle the preauthorization hold.
Hold Amount
Currency Code The currency code associated with the preauthorization hold amount.
The preauthorization hold ID (also know as the preauthorization sequence number) of the
hold. BASE24-eps processing uses the retrieval reference number of the transaction for
Transaction ID
this ID.This value must be unique for each preauthorization hold associated with a specific
card or accountit is used as part of the matching criteria when updating/deleting a hold.
The date and time (timestamp) that a pre-authorization hold transaction expiresafter
which it will no longer be used.
Hold Expiration
The local date and time (timestamp) the terminal sent in the preauthorization hold
transaction.
Hold Local Transaction
Timestamp

Preauthorization Hold Types

The preauthorization hold type is a user-defined value that can be used to categorize
holds.
BASE24-eps can support any value, but sample scripts use the preauthorization hold
type
to differentiate the following basic differences.
Preauthorization Hold Types
Value Description
The transaction is an actual preauthorizationthe transaction originator is expecting to send a
follow-up completion message with the final amount of the transaction.
This value is set when the pre_auth_flag in the Preauthorization Hold TDE is set to truewhich
occurs when the acquirer has provided an Authorization Life Cycle Code (a hold interval and number).
PA
The transaction is an authorization-only transactiona follow-up completion message is not expected.
This value is set when the pre_auth_flag in the Preauthorization Hold TDE is set to falsewhich
occurs when the acquirer has not provided an Authorization Life Cycle Code (a hold interval and
number).
AO
What Happens to Expired Holds

Holds that expire are written over automatically in the Preauthorization Holds data
source
as new holds are created. So, typically, space is recycled and no action is required to
clean
up expired holds. However, if a large number of card and account records have
become
inactive, it may be advisable to delete the expired holds manually in order to reclaim
file
storage space.
To delete expired holds, use the Process Control window to deliver a CLEANUP
command
to the XMLS destination identifying PreAuth Hold as the component. Refer to the
BASE24-eps Process Control User Guide for more information.
How Preauthorization Holds Affect

Processing
Preauthorization processing is carried out through authorization scripts, so the actual
processing depends on how you code your scripts. However, the general intent of a
preauthorization hold is to reserve a specific amount for a period of time so a
cardholder
cannot spend that amount for something else.
As such, when determining balance information and checking limits for purposes of
authorizing a transaction, it is typical to take preauthorization holds into account. In
this
way, they are quite similar to usages (refer to Tracking Transaction Usage on page
152).
Controlling Processing at the Prefix Level

BASE24-eps provides a control setting at the prefix level that can be used by your
authorization scripts to determine whether or not to include preauthorization holds in
authorization processing.
The Hold Balance Check field on the Processing Information tab of the On-Us Prefix
window
is available to specify whether or not preauthorization holds are to be considered
when
checking limits and balances for cards and accounts with the corresponding prefix.
This
flag is stored as hld_bal_chk in the Prefix data source (Prefix).
Your scripts can use this setting to control the inclusion of preauthorization hold
processing
at the prefix level. There is an exported operator for this setting. The BASE24-eps
sample
scripts use this value in processing.
Preauthorization Hold Example

The following example illustrates in a basic way how preauthorization holds are
created
and interact with purchase and daily usages to impact processingassuming the
Hold
Balance Check field on the Processing Information tab of the On-Us Prefix window is
set
(and being acted upon by your scripts).
In this example, the limits have a fixed-day usage period of 2 days, and the
preauthorization
holds have expiration dates based on information sent from the endpoint.
Note: The beginning of each new usage period, as well as the usage and hold
expirations
involves both a date and time; however, just the date has been used here for
simplicitys
sake.
Active
Usage
1 $215 Feb-3 $215
2 Hold1 $90 $305

Active
Usage
3 $50 Feb-3 $355
4 $100 Feb-5 $190
5 Hold2 $100 $290
6 Hold2 -$100 $190
$87 Feb-5 $277
7 $50 Feb-5 $327
8 Hold3$200 $527
9 $60 Feb-7 $350
10 Hold1 -$90 $260
11 $25 Feb-7 $285
1. A $215 transaction posts Feb-1; a usage is created for $215 with its expiration set
to
Feb-3; the total active usage for the current period is $215.
2. The cardholder rents a car on Feb-2. The car company authorizes the transaction,
placing a $90 preauthorization hold on the account for four days. Because
preauthorization holds are included in the usages in this example, the total active
usage
for the current period is $305.
3. A $50 transaction posts Feb-2; a usage is created for $50 with its expiration set to
Feb-3
(still the beginning of the next usage period for the particular limit); the total active
usage
to
Feb-5; since a new accumulation period has started, the individual usages created in
steps 1 and 3 are expired and no longer used; there is now one active usage ($100)
and one active hold ($90), and the total active usage for the current period is $190.
5. The cardholder gets gas on Feb-3. The gas pump authorizes the transaction,
placing
a $100 preauthorization hold on the account. Because preauthorization holds are
included
in the usages in this example, the total active usage for the current period is $290.
6. The final gas total is $87, and the gas pump sends a completion for the gas
transaction.
The $100 preauthorization hold is removed, and an $87 usage is created. There are
now two active usages ($100 and $87) and one active hold ($90), and the total
active
usage for the current period is $277.
Feb-5
usage
8. The cardholder checks in at a hotel on Feb-4. The hotel authorizes the
transaction,
placing a $200 preauthorization hold on the account for a week. Because
preauthorization
holds are included in the usages in this example, the total active usage for the
current
period is $527.
Feb-7
accumulation
period has started, the individual usages created in steps 4, 6, and 7 are expired and
no longer used; there is one active usage ($60) and two active holds ($90 and $200),
and the total active usage for the current period is $350.
10. The $90 hold created in step 2 expires; there is now one active usage ($60) and
one
active hold ($200), and the total active usage for the current period is $260.
to Feb-7
usage
Additional Optional Processing (Interac)

The standard BASE24-eps sample scripts include several Interac-specific
processing
functions. These added functions illustrate optional processing that can be added to
the
scripts to adapt processing to your requirements.
Preauthorization Hold ID
In standard processing, BASE24-eps uses the transactions retrieval reference
number as
the preauthorization hold ID. In the case of Interac, the preauthorization hold ID is
created
by concatenating the retrieval reference number and the approval code created by
BASE24-eps. The retrieval reference number does not change over the life of a
transaction
and is alway included in completions. Interac acquirers would need to return the
approval
code with the completion so that the preauthorization hold ID can be determined.
Time Limits on Completions

In standard processing, BASE24-eps does not impose time limits on the receipt of a
completion message. In the case of Interac, the following time limits are imposed on
the
receipt of a completion message.
1. The terminal must send the completion request message to the issuer within two
hours
of the authorization request having been made. In this case, the terminal local time in
the completion must be no more than two hours after the terminal local time in the
original preauthorization request.
2. The completion message must be received by the issuer within 24 hours of the
authorization request. This requirement is based on the issuers system time. The
preauthorization completion must arrive no more than 24 hours after the
preauthorization
request.
If the time limits are not met, the authorization scripts would set the Exception
Reason
Code TDE marking the transaction as a no post on the journal and set the Issuer
Generated
Reversal Required TDE to notify the interface component to generate an issuergenerated
reversal (should the interface component support that functionality). Scripts would
not
remove the hold nor update usages when an exception occurs while processing a
completion message.
Adding, Deleting, and Modifying

Preauthorization Holds from Your
Authorization Scripts
Your authorization scripts need to be able to add and delete preauthorization holds;
the
scripts may need to modify holds as well, depending on the type of processing your
system
is set up to do.
Note: You can add, view modify, and delete preauthorization holds from the ACI
Desktop
as well (refer to Adding, Viewing, Modifying, and Deleting Preauthorization Holds
from the
ACI Desktop on page 178).
Adding Preauthorization Holds During Transaction Processing

BASE24-eps scripting provides the capability to place a preauthorization hold on a
card
or account during processing of an authorization request (message type 1100).
Scripts invoke the Preauthorization Hold component to add preauthorization holds to
the
Preauthorization Hold data source. The Preauthorization Hold component calculates
and
sets the expiration date/time of the hold based in the increment value and number
provided
with the transaction.
It uses the retrieval reference number from the transaction as the preauthorization
hold
ID.
Removing Preauthorization Holds

BASE24-eps supports the capability to remove preauthorization holds in a number of
ways
depending on your approach to handling preauthorization holds.
Situation Description
In an environment where both the authorization and completion sides of the transaction
are processed online, upon receipt of a completion (1220 message), your scripts would
Upon receipt of the
completion
typically match the completion to the hold, remove the hold, and apply the amount of
the completed transaction.
If the cardholder cancels the transaction after the initial preauthorization approval arrives,
but before the completion is sent, the terminal must send a completion showing a final
amount of $0.

Situation Description
In an environment where both the authorization and completion sides of the transaction
are processed online, there must be the ability to cancel a hold if something prevents
the purchase from actually taking place.
If the cardholder cancels the request before the initial preauthorization approval arrives,
the acquirer must reverse the preauthorization request. Upon receipt of a reversal (1420
message), your scripts would typically match the reversal to the hold and remove the
hold.
Upon receipt of a reversal
Note:
These types of reversals would typically carry a message reason code of 4000 to denote
a customer cancellation.
All preauthorization holds have an expiration date and time associated with them that
are used by scripts to determine whether or not the holds are active.
If holds are not specifically removed by completion or reversal messages, your scripts
should stop treating them as active as of their expiration dates.
Based on the hold expiration
date/time
In some cases, the authorization stage of a transaction is handled online, but the
completion side of the transaction is handled through a backend settlement process.

Through Match and Hold
processing
BASE24-eps supports a process called match and hold, by which transactions can be
processed in batch form to remove corresponding preauthorized holds. Refer to Match
and Hold Processing on page 180 for information on how match and hold processing is
done.
Preauthorization hold delete records can be sent as file update transactions from an
ISO 93 host. Refer to File Update Routing on page 103 for information on how this
processing is done.
Through File Update
processing
Modifying Preauthorization Holds

It is possible to invoke the Preauthorization Hold component to modify a
preauthorization
hold amount and calculate and set a new expiration date/time.This would typically be
used
in incremental authorization situations and would need to be written into your
authorization
script based on how you handle this type of processing.
Adding, Viewing, Modifying, and Deleting

Preauthorization Holds from the ACI
Desktop
Preauthorization holds can be created, viewed, modified, and deleted from the ACI
desktop
using the Preauthorization Hold Management window (Customer Management >
Preauthorization Hold).
The following is an account view of the Preauthorization Hold Management window.
The following is an card view of the Preauthorization Hold Management window.
Match and Hold Processing

BASE24-eps match and hold processing provides the capability to introduce batch
records
of settled transactions into the system for the purpose of removing their
corresponding
holds.
Why You Would Do This

The intent of pre-authorization holds is to place a temporary hold on account funds
until
the final (actual) amount of a transaction is determined and either authorized or
settled.
In some environments, both sides of the preauthorization transaction are not handled
onlinei.e., the authorization side of the transaction might be handled online but the
completion side of the transaction could be handled through a back-end settlement

process.
In this case, the initial transaction would create a hold, but there would be no
corresponding
online completion transaction to remove it. Instead, the transaction would be
processed
as part of the merchant settlement of tickets. At that time, the transaction would be
settled
and the actual balances would be adjusted, but the preauthorization hold could
remain in
place depending on its expiration timeframe.
The BASE24-eps match and hold function provides capability for BASE24-eps to
remove
holds based on batch files of a matched transactions sent from settlement systems,
such
as ACI Payments Manager. Matched transactions are essentially preauthorized
transactions
that have been settled.
How Match and Hold Works with the Batch

Authorization Process
Match and hold records are introduced into the BASE24-eps system in batch files.
The
Batch Authorization process is used to process the batch filesto parse the file
records
and sends them to the Integrated Server (IS) process as completion (1220)
messages.
The following is an illustration of the basic flow of match and hold messages.
In the IS process, the completion messages are received by a Batch Authorization
Interface
component which routes them to the Issuer Authorization component for processing.
The
Issuer Authorization component processes the message through its normal
authorization
scripts (deleting the hold), journals the 1230 message, and returns a 1230 message
to the
Batch Authorization processing through the Batch Authorization Interface
component.
Match and hold is intended to work concurrently with other online transaction
processing.
The Batch Auth process can throttle the number of messages sent to the IS process
so
as not to overwhelm the current online transaction processing.
For information on the Match and Hold record layouts and how the Batch
Authorization
process handles match and hold record processing, refer to the BASE24-eps Batch
Authorization User Guide.
Match and Hold Completion Messages are a Special Form of

1220
Message
The match and hold completion (1220) messages do not contain all of the
information
needed for a typical 1220 advice message. Consequently, they should not be routed
outside
the match and hold transaction flow (for example, to a host).
What It Takes to Identify Holds for

Deletion
For a preauthorization hold delete action initiated through match and hold or file
update
processing, information must be provided to the Preauthorization Hold component to
identify
the hold to be deleted.
The following values are used in each case to identify the hold to be deleted. If a
hold
cannot be found based on these values, the deletion will not be processed.
Hold Type Hold Value Match and Hold Record File Update
Derived from DE 3 (Primary
Account Number) during routing.
Derived from the PAN field in the
data record (based on the PAN
prefix).
Both Card and Account Institution ID
S-72, tag 10, subtag 01 (Hold ID)
unless the transaction is a Visa
The Hold ID field in the data
record.
Preauth Hold ID
increment authorization
transaction, in which case, S-72,
tag 10, subtag 03 (Transaction
ID) is used.
Card Card Number The PAN field in the data record. DE 3 - Primary Account Number.
The Card Sequence Number field DE 23 - Card Sequence Number.
in the data record.
Member Number
The Account Number field in the DE 102 - Account ID 1.
data record.
Account Account Number
DE 72, tag 10, subtag 02
(Account type).
Derived from account type
included in the Processing Code
field in the data record.
Account Type

Check Processing
BASE24-eps provides a basic infrastructure for processing card-initiated transactions

that
involve the presentation of a check for cashing or deposit.
A typical transaction of this type might involve a cardholder at an ATM. The
cardholder
would initiate the transaction using his or her card, select a cash or check deposit
transaction
and insert the check (a single check). The ATM would read the check MICR data on
the
check and include it in the request to BASE24-eps so it can be used to identify the
check
for specific types of processing.
What is a Check?
A check is a negotiable instrument that instructs a financial institution to pay a
specific
amount of a specific currency from a specified demand (checking) account held in
the
maker/depositors name with that institution. Both the maker and payee may be a
person
or legal entity (e.g., corporation or business).
Historically, checks have been paper documents that physically changed hands from
the
maker to the payee. The payee would receive the funds represented by the check
when
the check was presented-either in person or through a settlement process-to the
financial
institution on which the check was drawn. The paper instrument was, in effect,
redeemed
for the funds it represented.
However, check processing has changed over the years. In most instances, a check
need
no longer physically change hands. Rather, an electronic image of the check is
legally
sufficient to represent the transaction. In this case, the physical check can be
scanned and
captured electronically at the point of origin and archived there for future retrieval if
necessaryeliminating the expense and manual effort surrounding the paper
instrument.
The payment itself can be processed as an electronic transaction using the captured
check
image and the check MICR data.
Globally, the use of checks is on the decline. In some countries, checks can only be
issued
by corporations and governments. In other countries, checks are not considered a
valid
payment instrument at all. However, checks do still have a significant market
presence
and where they are in use, it becomes important to process them efficiently and to
support
their unique security requirements (e.g., stop payments).

Check Processing
Check-Based Transactions Supported by BASE24-eps

BASE24-eps supports check processing for the following types of transactions.
Cash check (processing code A2)
Check deposit (processing code 24)
Check deposit with cash back (processing code 29)
By interpreting the MICR data sent from the acquiring endpoint on check-related
transactions, BASE24-eps can determine the routing transit number of the institution
that
issued the check and the account number (associated with that routing transit
number) on
which the check was written/drawn. This information enables BASE24-eps to
perform
check-based processing in its authorization of the transaction. Refer to MICR Data
on page
186 for more information about MICR data and how it is used.
Routing Check Transactions

BASE24-eps uses standard routing for check transactions, based on the prefix of the
card
used to initiate the transaction (i.e., account-based routing based on the checking
account
is not supported).
In order to support routing of check transactions, you need to set up a routing code
for
each type of check transaction supported. This requires the presence of a business
relationship between the acquirer and issuer involved in the transaction. Refer to
Defining
Business Relationships and Routing Codes for Your System on page 100, for
information
about setting up route codes and the meaning of business relationships.
Check-Specific Processing Features

Your authorization scripts can be written to perform several specific check
processing
features:
Recognizing preapproved or predeclined checks (refer to Preapproved and
Predeclined
Checks on page 192).
Recognizing checks with stop payments on them and acting on the stop payment
(refer
to Stop Payment Processing on page 197). Stop payment processing is a separate
add-on
feature.
Including or excluding check amounts in overall usage evaluations (refer to Check
Limits/Usages on page 196).
Check Processing
Its Done With Scripts

All check processing must be implemented through your authorization scripts. The
BASE24-eps system provides the basic capability and structure for defining check
processing. However, the way in which check processing is handled depends
entirely on
how your authorization scripts carry it out.
The Check Status and Account Routing components used in check processing are
accessible from your scripts using various exported operators. For information on the
various exported and script operators available to you, refer to the BASE24-eps
Scripting
Manual.
some
basic templates for processing. If used, it is expected that these scripts be
thoroughly
examined and modified to fit your environment. The Sample Fundamental
Authorization
Scripts Delivery Document contains a current list of BASE24-eps sample
authorization
scripts.
Check Processing
MICR Data
MICR is an abbreviation for Magnetic Ink Character Recognition, which is a
character-recognition technology adopted by the banking industry to facilitate the
processing
of checks. MICR data is printed on the physical check, enabling the information to be
electronically read and recognized for processing.
MICR is standardized by ISO 1004 and although the character sets are fairly
standard,
the MICR formats (actual format of data) encoded on the check can differ by country.
Information Contained in the MICR Data

MICR data carries the following pieces of information about a check.
MICR Data Description
Routing Transit number of the institution on which the check is drawn.
The routing transit number, also known as an institutions ABA number, is a
nine-digit bank code used in the United States which appears at the bottom of
negotiable instruments to identify the financial institution on which the instrument
is drawn.
Routing Transit Number
Account Number Account Number on which the check is drawn.
Check Number The check number of the check involved in the transaction.
The amount of the check involved in the transaction. Normally, this data is only
included if the check has been cashed. However, in some cases, such as rebate
checks, the amount is included in the MICR data when the check is issued.
Check Amount
MICR Data Formats

Depending on the financial institutions involved, the MICR data can be presented in
any
of the following formats, all of which are recognized and supported by BASE24-eps.
Account Number (A)
Delimiters and
position
Check Sequence
(C) Delimiters and
position
Routing Transit
Number (B)
Delimiters and
position
Formats
TBBBBBBBBBTAAAAAAA*CCCCCC$ T T beginning * $ end T * middle
*CCCCCC* TBBBBBBBBBTAAAAAAA* T T middle * * beginning T * end
*CCCCCC* TBBBB-BBBBTAAAAAAA* T T middle * * beginning T * end
TBBBBBBBBBTCCCC*AAAAAAA* T T beginning T * middle * * end
TBBBB-BBBBTCCCC*AAAAAAA* T T beginning T * middle * * end
TBBBBBBBBBTCCCC*AA-AAA-AA* T T beginning T * middle * * end
TBBBBBBBBBTAAAAAAA*CCCCCCC T T beginning * end T * middle

Check Processing
How BASE24-eps Carries MICR Data (MICR TDE)

Within BASE24-eps, check MICR data is carried in the MICR TDE for transactions
that
involve checks. It is loadedas receivedby the channel or interface component
sending
the message.
In certain situations, the MICR data may require manipulation for purposes of being
able
to look up check status and stop payment records (refer to Manipulating MICR Data
on
page 189).
Check Processing
How MICR Data is Used in BASE24-eps

Check Processing
BASE24-eps ability to process checks is predicated on the capability to acquire and
interpret
the check MICR data for the check-based transaction being authorized.
BASE24-eps sample scripts are set up to handle processing as follows, based on
what is
available from the MICR data. Keep in mind, this processing can be changed as
needed
in your scripts.
If a script is unable to derive the routing transit number or the account number from
the
MICR data, the transaction is authorized based on the card information only.
If there is an amount symbol ($) in the check MICR data, it is assumed that the
check
has been previously processed and the transaction is declined. Baseline scripting
uses
an action code 107 (Denied, Refer to Card Issuer).
If a routing transit number and account number are available from the MICR data,
the
Account Routing data source is searched for possible MICR manipulation
instructions.
If a routing transit number and account number are available from the MICR data
the
Check Status data source can be searched for a possible match.
If a routing transit number, account number, and check serial number are identified
in
the MICR data, the Stop Payment data source (if configured) can be searched for
possible stop payments. If no check serial number is available, the Stop Payment
data
source cannot be searched (even if configured).
Check Processing
Manipulating MICR Data

In some cases, it may be necessary for BASE24-eps to modify the account numbers
and
routing transit numbers it receives in a checks MICR data in order to match
corresponding
numbers carried in the BASE24-eps database. For example, when banks merge or
are
acquired, the merging institutions might have customers with the same account
numbers,
or the account numbers might be of different sizes. In other cases, routing transit
numbers
available in the MICR data might need to be mapped to different routing transit
numbers
to match routing transit numbers defined within BASE24-eps.
BASE24-eps provides the capability to modify account numbers and routing transit
numbers
through the Account Routing data source and the Account Routing component.The
Account
Routing data source contains the data necessary for modifying the numbers. The
Account
Routing component can be invoked by your authorization scripts to use the Account
Routing
data source information to perform the modification.
The purpose of the modification is to change the account numbers and transit routing
numbers presented in the actual check MICR data so that they can be used to match
records in the Check Status or Stop Payment data sources.
Note: When an account number or transit routing number is modified, the old
numbers in
the MICR Data TDE are overwritten with the new values. The old values are not
kept.
Account Routing Data Source Record Content

The Account Routing data source (account_routing) is accessed from the Account
Routing
window (Configuration > Account Routing). It has an OLTP. The data contained in a
single
record is described in the table below.
Field Description
The account type for which the routing information applies.The account types supported
are those that may be entered by the customer at an ATM.

This value is part of the primary record key.
Account Type
The length of the account number for which the routing information in this record applies.
Valid values are 128.
Account Length
The routing transit number to which the information in this record applies. Values are
right-justified and zero-filled.
Check Routing Transit Number
The position within the account number where one or more characters are to be inserted
in order to create a unique account number. Valid values are 028.
Account Number Insert
Position
The numeric characters that are to be inserted into the account number to make it
unique. Values are left-justified and blank-filled.
Account Number Insert Value

Check Processing
Field Description
The institutions institution number to be used for processing the transaction.This field
contains a replacement value for the transit routing number sent in the MICR data of
Institution ID Number
a transactionit becomes the transit routing number to be used to process the
transaction.
This field can contain only numeric characters.
Note: Institution numbers are different from institution IDs.They are set in the Institution
Number field of the Institution Configuration window (Configure > Institution); typically,
they are the institutions transit routing number.
Example of Converting Account Numbers

The following are examples of several Account Routing data source settings. In
these
examples, three different financial institutions with differing account number
structures and
lengths are being manipulated to match a fourth account number structure.
Field Institution-1 Institution-2 Institution-3
Account Length 7 5 8
Insert Position 1 1 1
Insert Values 55500 7770000 7780
The following are examples of account numbers belonging to the institutions defined
in
the table above, before and after their manipulation. Note that item 7 is an example
of an
account number from Institution-4, for which no manipulation is defined.
# Institution Before After
1 Institution-1 1234567 555001234567
2 Institution-1 5678901 555005678901
3 Institution-2 12345 777000012345
4 Institution-2 56789 777000056789
5 Institution-3 12345678 778012345678
6 Institution-3 56789012 778056789012
7 Institution-4 111234567890 111234567890
Example of Converting Institution Numbers (Routing Transit

Numbers)
The following are examples of several Account Routing data source settings. In
these
examples, three different financial institutions with differing routing transit numbers
are
being manipulated to match a fourth routing transit number (123456789 in this

example).
Check Processing
Note: MICR manipulation enables institutions to map one or more routing transit
numbers
to other routing transit numbers to provide flexibility during transition periods (for
example,
when one institution acquires and absorbs another institution).
Account Routing Fields Institution-1 Institution-2 Institution-3
Routing Transit Number 345678912 456789123 678912345
Institution Number 123456789 123456789 123456789
The following are before and after examples of routing transit numbers, based on the
Account Routing settings in the table above.
Replacement Value in the MICR
data
# Institution Sent in the MICR data
1 Institution-1 345678912 123456789
2 Institution-2 456789123 123456789
3 Institution-3 678912345 123456789
4 Institution-4 123456789 123456789
In this case, the MICR data routing transit number of institutions 1 through 3 would
be
replaced with 123456789. Institution-4 would not have an Account Routing record,
and its
MICR data routing transit number would be processed as is: as 123456789.
Check Processing
Preapproved and Predeclined Checks

BASE24-eps supports the capability to preapprove or predecline checks for use with
check-based transactions.
What are Preapproved and Predeclined Checks?

Preapproved and predeclined checks are checks drawn on specific checking
accounts
that an institution defines to BASE24-eps for automatic approval or denial or
approval or
denial under certain circumstances.
Checking accounts to be preapproved or predeclined are defined to BASE24-eps in
the
Check Status data source using their routing transit number and checking account
number.
In check-based transactions, BASE24-eps can then use the contents of the check
MICR
data to determine whether the account in the transaction is defined in the Check
Status
data source.
Note: Predeclined checks differ from stop payments in that stop payments are
created
for a specific account number and check number or range of check numbers. Stop
payments
are a separate add-on to check processing (refer to Stop Payment Processing on

page
197).
Preapproval and Predecline Options

Checking accounts defined in the Check Status data source can be set up to enable
the
following options:
Approving or declining any checks on the account.
Approving or declining checks on the account, but only when a specified cardholder
is
involved in the transaction.
Returning or retaining checks on the account in situation when a transaction is
declined.
Approving checks on the account for deposit only.
Approving checks on the account, but only up to a specified limit.
Examples of Uses
There are a variety of ways you can use the preapproval and predecline options
available
to you. Several are described below.
Option Description
There may be situations in which you want to preapprove all checks from a specific
company or institutionperhaps for social security checks or payroll checks from a specific
Preapproved Checks

Check Processing
Option Description
firm. In this case, you would add a record to the Check Status data source with the routing
transit and checking account number for the check-issuer, and set the Check Status value
to approve all checks.
Then if, for instance, a Social Security check is presented for cashing, it would be approved
regardless of the cardholder initiating the transaction.
You could also set a maximum amount if you wanted to impose a limit on the amount of
the checks to accept, but that would affect all checks on the account.
If you wanted to predecline all checks from a specific company or institutionperhaps for
a company in financial trouble or for a firm whose assets have been frozenyou would
Predeclined Checks
add a record to the Check Status data source with the companys routing transit and
checking account number and set the Check Status value to decline all checks.
Then if a check was presented on that account, it would be declined regardless of the
cardholder initiating the transaction.
You can also set a check retention value to indicate whether predeclined checks should
be retained or returned.
A registered check is a form of preapproved check that is only approved if it is presented
by a specific cardholder. Registering checks might be used by an institution for customer
Registered Checks
cardholders who receiveand want to cashchecks at recurring and predictable intervals.
For example, the cardholder might receive a monthly dividend or payroll check from an
out-of-state bank and want to cash it on a regular basis. In this case, the cardholder and
check-issuer are both known to the institution, which lessens the likelihood of fraud. In this
case, you would add a record to the Check Status data source with the routing transit and
checking account number for the check-issuer, and set the Check Status value to approve
all checks. In addition, you would add to the record the cardholders card number and
member number. Then, the checks would be approved, but only if presented for payment
by the cardholder. Anyone else presenting a check from the institution would not be
automatically approved.
You could also set a maximum amount if you wanted to impose a limit on the amount of
the checks to accept.
Defining Preapproved and Predeclined Checks to BASE24-eps
To define preapproved or predeclined check accounts to BASE24-eps, the accounts

must
be added to the Check Status data source (check_status). The Check Status data
source
contains one record for every preapproved/predeclined action you define.
The Check Status data source can be accessed from the Check Status Management
window (Customer Management > Check Management). It can also be refreshed
or
updated through file update processing from a HISO 93 host. For refresh
information, refer
to the BASE24-eps File Refresh User Guide. For file update information, refer to the
BASE24-eps ISO 8583:1993 Host External Message Manual.
Preapproved or predeclined checks are defined at the institution level, which is to
say they
can only be applied to transactions by a specific institutions cardholders.
The following is the pertinent information maintained in the Check Status data source
for
a preapproved or predeclined check.
Check Processing
Field Description
The routing transit number or identification number of the check-issuing institution whose
checking account information is being defined in the record.
The routing transit number from the check MICR data in a transaction is used to match
this value.
Routing and Transit Number
The checking account number whose information is being defined in the record.
The checking account number from the check MICR data in a transaction is used to
match this value.
Checking Account Number
A cardholders primary account number (PAN) or asterisks.
If this record is for a registered check for a specific cardholder, this field must contain the
cardholder PAN.
Cardholder Primary Account
Number
If this record is for a preapproved or predeclined check, this field must be set to asterisks
because the record is not intended to be specific to a cardholder.
A cardholders member number or asterisks.
If this record is for a registered check for a specific cardholder, this field must contain the
cardholders member number
Member Number
If this record is for a preapproved or predeclined check, this field must be set to asterisks
because the record is not intended to be specific to a cardholder.
A code specifying the disposition of checks with this routing transit number and checking
account number. Valid values are as follows:
0 = Accept all checks
Check Status
1 = Deposit only
2 = Deny all checks
A code indicating the retention status for declined transactions for checks with this routing
transit number and checking account number. Valid values are as follows:
0 = Return all checks
Check Retention Status
1 = Retain all checks
The maximum acceptable check amountexpressed as a whole currency valuefor
checks with this routing transit number and checking account number.
Checks above the specified limit are not authorized.

Check Amount Limit
This field need not be set if the Check Status field indicates that the checks should be
declined.
Currency code for the amount in the Check Amount Limit field.
This field need not be set if the Check Status field indicates that the checks should be
declined.
Check Amount Currency
Code

Check Processing
Enabling Preapprove and Predecline Check Processing (Prefix

Level) During Prescreening
BASE24-eps provides a prefix-level configuration setting for enabling or disabling
preapprove and predecline check processing during transaction prescreening.
Check processing can be included in the prescreening or authorization stage of a
transaction
based on your scripts.
The Check Status Prescreen flag on the Check Processing tab of the On-Us Prefix
Configuration window (Configuration > Prefix > On-Us) is available to specify
whether or
not the Check Status data source should be checked prior to sending a transaction
to a
host. This flag is stored in the Prefix data source (Prefix).
Thus, your scripts can use this setting to control the inclusion of preapprove and
predecline
check processing at the prefix level during prescreening.
Check Processing
Check Limits/Usages
Because check transactions involve cash disbursements, it is useful to consider how
usages
and limits are to be applied to check-based transactions.You might, for instance,
want to
establish separate limits and usages for check-based transactions.You might also
want
to include check transactions in your total cash advance and total withdrawal limits
under
certain circumstances when authorizing transactions for a cardholder.
Including Check Transactions in Total Cash Advance/Total

Withdrawal Limits
BASE24-eps supports configuration settings at the prefix and card level that can be
used
by your scripts to determine whether to evaluate check-based transactions against
your
total cash advance and total withdrawal limitsbased on whether or not a check is
found
in the Check Status data source. For example, if a check is registered, the institution
may
not want to include the check in the total cash advance or withdrawal limits.
Conversely,
if the check is not defined to the system, the institution may want to make sure
cashing
the check does not take the cardholder over his or her cash advance or withdrawal
limits
for the card.
The following table lists the configuration fields available to you. The prefix-level
versions
of the fields are set on the Check Processing tab of the On-Us Prefix Configuration
window
(Configuration > Prefix > On-Us) and are accessed by the Prefix component. The
card-level versions of the fields are set on the General tab of the Card Management
window
(Customer Management > Card) and accessed by the Card component.
Card-level settings are provided to override the prefix settings for specific
cardholders.
Field Description Prefix Values Card Values
0 = No
1 = Yes
0 = No
1 = Yes
Indicates transactions involving checks not
defined in the Check Status data source
should be included in Total Cash
Advance/Total Withdrawal usages and
Check Base Flag
2 = Use Prefix value
checked against Total Cash Advance/Total
Withdrawal limits.
0 = No
1 = Yes
0 = No
1 = Yes
Indicates transactions involving checks
defined in the Check Status data source
should be included in Total Cash
Advance/Total Withdrawal usages and
Check Status Check
Base Flag
2 = Use Prefix value
checked against Total Cash Advance/Total
Withdrawal limits.

Check Processing
Stop Payment Processing

BASE24-eps provides the infrastructure to support stop payment processing for
check-based
transactions. Stop payment processing includes the capability to create, modify, and
cancel
stop payment orders, as well as to verify checks against the list of stop payment
orders.
Note: Stop payment processing is a separate add-on to check processing and is
only
available if you have purchased the add-on.
What is a Stop Payment?

A stop payment is an order to a financial institition not to honor the payment of a
negotiable
instrument, such as a check, after it has been delivered but before it has been
cashed. In
the case of a check-based transactions, institutions need to be able to deny payment
on
checks for which stop payment orders have been placed.
Stop payments are defined to BASE24-eps in the Stop Payment data source using
their
checking account number and check number. In check-based transactions, BASE24eps
can then use the contents of the check MICR data to determine whether the check
involved
in the transaction is defined in the Stop Payment data source.
Stop payment orders typically have expiration dates. For example, a stop on a
personal
check might be 90 days, while a stop on a bank check might be 50 weeks. Up to the
expiration date, a stop is considered active; after the expiration date, the stop is
considered
expired.
Note: Stop payments differ from predeclined checks in that stop payments are
created
for a specific account number and check number or check number range. For
information
about predeclined checks processing, refer to Preapproved and Predeclined Checks
on
page 192.
Active and Expired Stop Payments

Stop payments are either active or expired. Each stop payment carries an expiration
date
and timeset when the stop payment is createdthat identifies the date and time
after
which the stop payment should no longer be used.
Prior to the expiration date and time, the stop is considered active. As of the
expiration
date and time, the stop is considered expired. For example, if a stop is created with
an
expiration of February 28 at 11:00, it will be active up to that date and time. On
February
28 at 11:00 it will be considered expired.
All stopsactive and expiredare viewable from the Stop Payment Management
window
(Customer Service > Stop Payments) until they are deleted.
How is the Expiration Date/Time Determined
The expiration date and time associated with a stop payment can be set explicitly
when
the stop payment is created (e.g., by refresh, file update, or through the ACI
Desktop), or
they can be created using a default.
If an expiration date and time are not specified for a stop payment, the Stop Payment
component will search for an applicable Check Type data source record and if found,
use
the values in that record to calculate an expiration date and time (refer to Defining
the
Default Expiration Term for Stop Payments).
What this means is that in the case of partial-file refreshes and file updates, if the
expiration
date is not provided in the Stop Payment record information for a new record, the
Stop
Payment component will use the Check Type data source for determining an
expiration
date and time.
If no Check Type record is found, the Stop Payment component will use the
STOP_PMNT_EXP_DAYS environment variable to calculate the expiration date and
time.
The following are examples of how the expiration date and time are calculated based
on
a default.
Creation Specified Interval Expiration
Date Time Increment Number Date Time
Mar-1 6:00 Days 5 Mar-6 6:00
Mar-1 6:00 Days 120 Jun-29 6:00
Mar-1 6:00 Week 8 Apr-26 6:00

Defining the Default Expiration Term for Stop Payments

The Check Type data source (check_type) provides the institution the capability to
configure
a default amount of time that a stop payment order will be in effect for a particular
check
type. The Check Type data source is used to calculate the expiration date and time
of the
stop payment in the event they are not explicitly provided when the stop payment is
added
to the Stop Payment data source.
The following fields are maintained for a Check Type data source record. These
fields are
set using the Check Type Configuration window (Configuration > Check Type).
Note: If a default is required and no Check Type record is found, the
STOP_PMNT_EXP_DAYS environment variable is used as the default to calculate
an
expiration date and time.
Field Description
The institution ID of the financial institution owning the check type specified in the Check
Type field.
Institution ID
The type of check supported by the institution. Valid values are 0199. For example: 01
could indicate personal check, 02 a business check, etc.
The check types values can differ from institution to institution. For example, BankTwo
might use 01 to specify a personal check, whereas BankThree might use 02.
Check Type
A description for the Check Type (e.g. Personal, Business, Government, etc.).The default
value is spaces.
Check Type Description
A value specifying the expiration interval for the specified check type. Valid values are
as follows:
1 = Days (default)
Check Type Expiration
Period
2 = Weeks
The number of days or weeks to use for a default expiration period (days or weeks is
controlled by the Check Type Expiration Period field). For example: if this value is 150
Check Type Expiration
Period Value
and the Check Type Expiration Interval field is 1, the expiration period would be 150 days.
Valid values are 0999. The default value is 90.
What Happens to Expired Stops

Expired stop payments cease to impact processing; however, they remain on file
until they
are specifically removed.
Changing the Expiration Date on a Stop Payment

You can change the date on a Stop Payment by modifying it through the ACI
Desktop or
through partial-file refresh or file update transactions.
Deleting Expired Stop Payments

You can remove expired stop payments the same way you remove active stop
payments
(refer to Adding, Modifying, and Removing Stop Payments on page 201).
Adding, Modifying, and Removing Stop

Payments
BASE24-eps stop payment orders can be added, modified, or removed using the
following
methods:
Through the ACI desktop using the Stop Payment Management window (Customer
Service > Stop Payments).
Full-file refresh and partial-file refreshes. For information on performing refreshes,
refer
to the BASE24-eps File Refresh User Guide.
Online file updates through the ISO 8583:1993 Host Interface component. For
information
setting up external messages for these file updates, refer to the BASE24-eps ISO
8583:1993 Host External Message Manual.
Sending a CLEANUP command to the XMLS destination and identifying Stop
Payment
as the component. This deletes all expired stop payments. Refer to the BASE24-eps
Process Control User Guide for more information about this command.
What Information is Stored For Each Stop Payment

BASE24-eps provides for storing stop payments in the Stop Payment data source
(stop_payment) and displaying them on the Stop Payment Management window
(Customer
Service > Stop Payments). Each record written to the Stop Payment data source
contains
a single stop payment, for either a single check or a single range of checks.
Stop payments are defined at the institution level which is to say they can only be
applied
to transactions on a specific institutions cardholders. The same stop payment cannot
be
applied across multiple institutions.
The following is the pertinent information maintained in the Stop Payment data
source for
a stop payment.
Field Description
The Institution ID of the institution owning the account specified in the Account Number
field.
Institution ID
The account number of the customer's account at the institution that has a stop payment
on the check.
Account Number
The type of customer account specified in the Account Number field.
Account Type

Field Description
The check number of the stop payment, or for a range of check numbers, the highest check
number in the range. The check number is right-justified and zero-filled on the left.
High Check Number
For a range of check numbers, this field contains the lowest check number in the range.
The check number is right-justified and zero-filled on the left.
If the stop payment record is for a single check, rather than a range of checks, this field will
contain the same value as the High Check Number field.
Low Check Number
The amount of the check, in whole and fractional currency units, for which the stop payment
has been issued. The default value is zero.
For a range of check numbers, this field must contain a zero. For a single check number
(i.e. not a range), this field can contain a value greater than or equal to zero.
Amount
Currency Code The ISO currency code of the check amount. The default value is 840 for U.S. dollars.
Stop Payment Date The date (YYYYMMDD) of the stop payment. The default value is the current system date.
Stop Payment Time The time (hhmmss) of the stop payment. The default value is the current system time.
The expiration date (YYYYMMDD) for the stop payment. This can either be set explicitly
or calculated based on default parameters (refer to Active and Expired Stop Payments on
page 198).
Stop Payment Expiration
Date
The type of check for which the stop payment is intended. Valid values are 00 to 99 (e.g.,
01 could denote a personal check, 02 a business check, etc).
Check type values can differ from institution to institution (e.g., one institution might use 01
to specify a personal check where another institution might use 02 to specify a personal
check.
Check Type
The default value is 00, which indicates no check type value (i.e. (none) on the UI).
A message regarding the stop payment order.This can be any data about the stop payment
order that the institution chooses to place on the file. The default value is spaces.
Stop Payment Description
Check Number Requirements

The Stop Payment data source supports only numeric check numbers up to a
maximum
of eleven significant digits.
Leading zeros are not considered part of the check number. For example, a check
number
entered manually at a teller terminal could be sent as 0035, where the same check
number
read electronically at an ATM might be included in the MICR data as 0000035.
BASE24-eps
would recognize both of these check numbers as as a match for check number 35
on the
Stop Payment data source.
Note: When entering stop payment orders on single checks, system editing prohibits
the
entry of multiple stop payment orders for the same check number. However, when
entering
stop payment orders for check ranges, that type of system editing is not performed.
For
example, you could add one stop payment for an individual check and a second stop
payment for a range of checks that includes the individual check. In another
scenario, you
might set up two stop payments for ranges of checks where some checks are
included in
both ranges.
How Stop Payments Affect Processing

Stop payment processing is carried out through authorization scripts, so the actual
processing depends on how you code your scripts. However, the general intent of a
stop
payment is to deny attempts to cash checks on which stop payments have been
placed.
As such, when determining processing for a check-based transaction, it is typical to
look
for a stop payment prior to sending the transaction to a host.
Enabling Stop Payment Processing (Prefix Level) During

Prescreening
BASE24-eps provides a prefix-level configuration setting for enabling or disabling
stop
payment check processing during transaction prescreening.
Stop Payment processing can be included in the prescreening or authorization stage

of a
transaction based on your scripts.
The Stop Payment Prescreen Check flag on the Check Processing tab of the On-Us
Prefix
Configuration window (Configuration > Prefix > On-Us) is available to specify
whether
or not the Stop Payment data source should be checked prior to sending a
transaction to
a host. This flag is stored in the Prefix data source (Prefix).Your scripts can use this
setting
to control the inclusion of stop payment processing for cards with the same prefixes
during
prescreening.
Institution Number and Routing Transit Number Requirement

BASE24-eps can only access the Stop Payment data source if the routing transit
number
in the check MICR data matches the Institution Number of the institution that issued
the
card being used in the transactionset in the Institution Number field of the
Institution
Configuration window (Configure > Institution). Typically, for card and check-based
processors, the Institution Number is the institutions transit routing number.
BASE24-eps does provide for mapping the routing transit number carried in a
checks
MICR data to other values when needed to provide for this matching (refer to
Manipulating
MICR Data on page 189).
How Stop Payment Processing Works

BASE24-eps scripts can invoke the Stop Payment component each time a check is
cashed
at an ATM to ensure no stop payments exist. Stop Payment processing can be
included
in prescreening prior to sending a transaction to a host or when a transaction is
authorized
by BASE24-eps.
The Stop Payment component searches for stop payment items in the Stop Payment
data
source, and if a match is found on an active stop payment, the transaction is denied.
Otherwise, the transaction processing continues. The Stop Payment component also
sets
the Self Service Banking Check TDE to indicate that the check is to be retained.
Sample BASE24-eps scripts deny the transaction with a 107 (Denial, Refer to Card
Issuer)
action code.
Check Matching Criteria
The Stop Payment component uses the following transaction information to

determine
whether there is a match in the Stop Payment data source.
Stop Payment Field Compared to this transaction data
Institution ID Institution ID of the institution that issued the card used in the transaction.
Account Number Account number in the check MICR data included in the transaction.
Account Type Account type from the processing code of the transaction.
Check number in the check MICR data included in the transaction. The match can either
be exactly on the high or low check number or anything between the two numbers.
High/Low Check Number
Authorization Scripts Scripting Stop Payment Processing

For the most part, stop payment processing must be implemented through your
authorization
scripts. The BASE24-eps system provides the basic capability and structure for
creating
and managing stop payments. However, the way in which these stop payment are
handled
depends on what your authorization scripts do with them.
The Stop Payment component used in stop payment processing are accessible from
your
scripts using various exported operators. For information on the various exported
and
scripts operators available to you, refer to the BASE24-eps Scripting Manual.
The sample check processing scripts delivered with BASE24-eps provide some
basic
templates for stop payment processing. If used, it is expected that these scripts be
thoroughly examined and modified to fit your environment. The Sample
Fundamental
Authorization Scripts Delivery Document contains a current list of BASE24-eps
sample
Card and Prefix Blocking

BASE24-eps provides the basic infrastructure for placing and enforcing blocks on
cards
and prefixes.
What is a Card Block?

Within BASE24-eps, a card block is an authorization function used to deny
transactions
or provide specialized processing on a card based on the presence of a card block
record.
Cards to be blocked are defined to the BASE24-eps system in the Card Block data
source
which can be used by your authorization scripts to deny transactions or take
specialized
scripted actions on transactions initiated using one of these cards.
What is a Prefix Block?
Within BASE24-eps, a prefix block is an authorization function used to deny

transactions
or provide specialized processing for a specific prefix based on the presence of a
prefix
block record. Prefixes to be blocked are defined to the BASE24-eps system in the
Prefix
Block data source which can be used by your authorization scripts to deny
transactions or
take specialized scripted actions on transactions acquired for one of these prefixes.
Block Codes
Block codes are two-position codes associated with a card or prefix block to indicate
the
nature of the block and the action to take. A block code is included in each card block
and
prefix block record.
In card or prefix block processing, a block code is returned to your authorization
script if a
block record is found.The resulting action must be determined by your authorization
script,
but in most cases, the purpose of a block code is to call for the denial of
transactions.
Certain block codes, however, denote that the block is no longer in place and the
card or
prefix is unblocked. If the block code indicates the card or prefix is unblocked, your
scripts
would typically allow the transaction to pass (i.e., not deny it due to a card or prefix
block).
It is important to note that scripts can be written to perform whatever processing
actions
you want to take.
German (Sperren) Block Codes

Any two-position alphanumeric code can be used as block codes within BASE24eps;
however, the following are standard block codes supported in the Sperren file
(Germanys
national negative file). The typical action is also provided for each.
Code Description Action
Active (unblocked). Unblock
Note: This value does not appear in the database; it is used by the
Sperren file refresh to note that block code should be changed to 11.
10
11 Sperren delete (unblock) Unblock
20 Blocked by customer (at branch) Block
21 Blocked by bank (e.g., delinquent) Block
23 Blocked by system (e.g., three bad PINs) Block
24 Blocked by telephone call to Help desk Block

Card and Prefix Block Processing
BASE24-eps card and prefix block processing is orchestrated through your

authorization
scripts.Your authorization scripts can invoke the Card Block component or the Prefix
Block
component to check for records in the Card Block and Prefix Block data sources
respectively
and return a block code if a record is found.
Based on the values returned by the Card Block or Prefix Block component, your
scripts
must then determine the actions to take and, if the transaction is denied, the
appropriate
action code to set (based on the returned block code).
Card Block Processing

To perform card block processing, your scripts must be written to call the Card Block
component. The Card Block component uses specific transaction data to read the
Card
Block data source to determine whether a record can be found. If a record is found,
the
Card Block component returns the block code contained in the record.
The Card Block component uses the PAN, Card Sequence Number, and Expiration
Date
to locate a record in the Card Block data source. The component looks for a record
based
on the following preference.
Card Expiration Date Description
Sequence
Number
Preference PAN
Blocks transactions on cards with the specified
PAN, card sequence number, and expiration date.
1 Exact Match Exact Match Exact Match
PAN and card sequence number and any
2 Exact Match Exact Match *******
expiration date. Multiple expiration dates may exist
during a reissue period.
PAN and any card sequence number for a specific
expiration date.
3 Exact Match *** Exact Match
PAN and any card sequence number and
expiration date.
4 Exact Match *** ******
Prefix Block Processing

To perform prefix block processing, your scripts must be written to call the Prefix
Block
component. The Prefix Block component uses specific transaction data to read the
Prefix
Block data source to determine whether a record can be found. If a record is found,
the
Prefix Block component returns the block code contained in the record.
The Prefix Block component uses the PAN length, Prefix, and Expiration Date to
locate a
record in the Prefix Block data source. The component looks for a record based on
the
following preference.
Expiration Description
Date
Preference PAN Length Prefix
Blocks transactions on all cards with the indicated
prefix and expiration date.
1 Exact Match Exact Match Exact Match
Blocks transactions on all cards with the indicated
prefix.
2 Exact Match Exact Match *******
Note: PAN length and prefix are always used in conjunction with one another to
define
prefixes in the BASE24-eps system.
Adding, Viewing, Updating, and Deleting

Card
Blocks
BASE24-eps defines card blocks in the Card Block data source (card_block). Each
record
in the Card Block data source represents a single card block.
Card block records can be added, viewed, updated, or deleted using the Card Block
Configuration window (Customer Management > Card Block) on the ACI desktop
user
interface.
Note: Card block records can also be added or updated using Sperren file
refreshes.The
Sperren file is a national negative file used in Germany for blocking debit cards. For
information on performing Sperren file refreshes, refer to the BASE24-eps File
Refresh
User Guide. Card block records cannot be deleted by the Sperren file refresh. To
remove
a card block through refresh, you would update the block code to unblock the record.
What Information is Stored for Each Card Block Record

The following information is maintained in the Card Block data source for each card
block
record.
Field Description
The Primary Account Number (PAN) of the card for which the card block is intended.
Primary Account Number
The card sequence number of the card for which the card block is intended.
If the record is for a block against a specific card sequence number, this field should contain
the card sequence number of the card. If the record is for a block against any card sequence
number associated with the PAN, this field should be set to 999 (displayed as asterisks on
the ACI desktop).
Member Number
The expiration date (YYYYMM) of the card on which the block has been placed.
If the record is for a block against a specific expiration date, this field should contain the
expiration date of the card. If the record is for a block against any expiration date, this field
should be set to 999999 (displayed as asterisks on the ACI desktop).
Expiration Date
A check mark that controls whether or not the Card Block date/time fields are to be used.
A check mark means they are available for use. No check mark means they are not available
for use.
Use Card Block Date/Time
Date/time fields indicating the date and time the customer placed the block on the card.
This information is set from the Card Block Date and Card Block Time fields in the Sperren
refresh detail record.
Effective Date/Time
Timestamp (YYMMDDhhmmss) of the refresh that created this record. This information is
set from the File Creation Date and File Creation Time fields in the Sperren refresh file
header.
Refresh Time Stamp

Field Description
An indicator of the refresh that created this record.
This field is informational only and is not set by the Sperren file refresh.
Refresh ID
The block code specifying the type of block. Any two-position alphanumeric code can be
used; however, certain standard block codes are supported by Sperren.
Block Code

Adding, Viewing, Updating, and Deleting

Prefix Blocks
BASE24-eps defines prefix blocks in the Prefix Block data source (prefix_block).
Each
record in the Prefix Block data source represents a single prefix block.
Prefix block records can be added, viewed, updated, or deleted using the Prefix
Block
Configuration window (Customer Management > Prefix Block) on the ACI desktop
user
interface.
Note: Prefix block records can also be added or updated using Sperren file
refreshes.
The Sperren file is a national negative file used in Germany for blocking debit cards.
For
information on performing Sperren file refreshes, refer to the BASE24-eps File
Refresh
User Guide. Prefix block records cannot be deleted by the Sperren file refresh. To
remove
a prefix block through refresh, you would update the block code to unblock the
record.
What Information is Stored for Each Prefix Block Record

The following information is maintained in the Prefix Block data source for each
prefix block
record.
Field Description
The prefix to which the prefix block record applies. The prefix is used in conjunction with
the PAN length to identify the prefix to which the prefix block record applies.
Prefix
The length of the Primary Account Numbers (PANs) to which the prefix block record applies.
PAN Length
The expiration date (YYYYMM) of the cards to which the prefix block applies.
If the record is for a block against a specific expiration date, this field should contain the
expiration date. If the record is for a block against any expiration date, this field should be
set to 999999 (displayed as asterisks on the ACI desktop).
Expiration Date
A check mark that controls whether or not the Prefix Block date/time fields are to be used.
A check mark means they are available for use. No check mark means they are not available
for use.
Use Prefix Block
Date/Time
The date/time the customer placed the block on the prefix. This information is set from the
Card Block Date and Card Block Time fields in the Sperren refresh detail record.
Prefix Block Date/Time
Timestamp (YYMMDDhhmmss) of the refresh that created this record. This information is
set from the File Creation Date and File Creation Time fields in the Sperren refresh file
header.
Refresh Time Stamp
An indicator of the refresh that created this record.
This field is informational only and is not set by the Sperren file refresh.
Refresh ID

Field Description
The block code specifying the type of block. Any two-position alphanumeric code can be
used; however, certain standard block codes are supported by Sperren.
Block Code

German Routing and Authorization

(Regional)
BASE24-eps provides the capability to route and authorize transactions on German
cards
received through German acquiring channels (specifically, through BASE24-eps
German
channel managers).
German card-based transactions have a number of country-specific processing
requirements
you must consider when setting up BASE24-eps to process these transactions.
Those
requirements are discussed here.
BLZ (Bankleitzahl) Support

BLZs (Bankleitzahls) are bank route codes (or sort codes) used in Germany in place
of
prefixes to identify the owner/issuer of a card. There are two forms of BLZs. The long
BLZ
consists of eight digits and are used in a cards track 3 data. The short BLZ consists
of five
digits and are used in the cards track 2 data. Here are examples of account number
formats
from the PAN data in tracks 2 and 3 of a German card.
Track Data Contents
Track 3 PAN Long BLZ (8) + Account Number (10) + Check Digit
Track 2 PAN Branch Code (3) + Short BLZ (5) + Account # (10) + Check Digit (1)
Long and short BLZs can differ, and as a result, the PAN information can differ for a
card
depending on which track is available in a transaction. In order to maintain a single
PAN-to-card relationship, BASE24-eps always uses the track 2 version of the
account
number. Likewise, BASE24-eps prefix processing is based on using the track 2
version of
the PAN with the branch code and short BLZ as the prefix (and a PAN length of 19).
In processing situations where only the long BLZ is available, BASE24-eps always
attempts
to map the long BLZ to an equivalent branch code and short BLZ combination. So
you
must set up the appropriate mappings for any long BLZ you are to process. For
information
on BLZ mapping, refer to BLZ Mapping on page 224.
German Routing and Authorization (Regional)
German Track 2 and Track 3 Support

German domestic debit cards contain both track 2 and track 3 data, and depending
on the
acquiring endpoint, BASE24-eps can receive track 2 and/or track 3 data in
transactions.
When track 3 data is received, the acquiring endpoint will use that data to set the
German
Authorization Track 3 TDE.
If track 2 data is available, BASE24-eps acquiring endpoints will use that data to set
the
PAN TDE.
If the track 2 data is not available, BASE2-eps acquiring endpoints will attempt to
map the
track 3 BLZ information to a track 2 branch code and a short BLZ and use that
information
to set the PAN TDE.
Track Data Contents
Track 3 PAN Long BLZ (8) + Account Number (10) + Check Digit
Track 2 PAN Branch Code (3) + Short BLZ (5) + Account # (10) + Check Digit (1)
If track 2 is not available and the track 2 mapping is unsuccessful, the BASE24-eps
acquiring
endpoints will move the PAN data from track 3 to the PAN TDE to be used for
specialized
routing.
German Prefix Routing Requirements

BASE24-eps routing is based on prefixes. If the PAN TDE contains the track 2 PAN
(set
from either the track 2 data received with the transaction or from the mapping the
track 3
PAN), BASE24-eps will use the 3-digit branch code and 5-digit short BLZ
combination from
the TDE as the prefix for routing the transaction.
If the PAN TDE contains the track 3 PAN data, the system uses specialized routing
based
on the track 3 PAN long BLZ. In this case, the routing prefix used is the fourth digit
(or the
fourth, fifth, and sixth digits) of the track 3 long BLZ. Prefixes must be set up to
handle the
specialized routing.
The BASE24-eps German Prefix component handles the necessary routing
requirements
for processing German cards. The German Prefix component is invoked by German
acquiring endpoint components (instead of the Prefix component) for German-based
card
transactions.
Sperren File Support

The Sperren file is a national negative file used in Germany for blocking debit cards.
German
debit card blocking within BASE24-eps is carried out using the Card Block and Prefix
Block
data sources, and Sperren file refreshes can be used for keeping these data sources
up
to date. Refer to the BASE24-eps Refresh User Guide for information about the
Sperren
File refresh. For information about card and prefix blocking, refer to Card and Prefix
Blocking
on page 206.
Note: The Card Block and Prefix Block data sources cannot be updated using File
Updates
through the HISO 93 interface.
GeldKarte Support (Routing Only)

Germany supports a national chip-based electronic purse scheme, called GeldKarte,
under
which German cards can be issued.
BASE24-eps does not support authorization of GeldKarte transactions; however,
transactions on GeldKarte cards can be routed through BASE24-eps to a GeldKarte
host
for authorization.
This transaction passthrough requires setting up a separate destination routing
profile for
GeldKarte routing and establishing route codes for the GeldKarte transaction
processing
code to be routed. Refer to Routing Codes on page 99 for more information about
route
codes and establishing business relationships. The BASE24-eps processing code

used
for Geldkarte transactions is A6.
SECCOS 6 Card Support

BASE24-eps supports transaction routing and authorization for SECCOS 6 cards
(German
EMV standard) through scripting. BASE24-eps sample authorization scripting
provides
examples of EMV plausibility checking for ATM and POS transactions. For more
information
about EMV and SECCOS 6 processing, refer to the BASE24-eps EMV Support
Guide.
Domestic and International Limits and Usages

German card limits and usages are typically configured at the card record level
based on
the card type and whether transactions are acquired domestically (inside Germany)
or
internationally (outside Germany).
Limit and usage handling is carried out by your authorization scripts, and BASE24eps
sample scripts include example international limits/usages that can be used for
international
transactions.The sample scripts use the Institution (Issuer) Country Code TDE to
determine
whether the card was issued by a German institution and the Card Acceptor Name
TDE
or Message Class TDE to determine whether the transaction originated from a
German
device. If a card is not a German card from a German device, the international
limits/usages
would be appliedin addition to the standard (domestic) limits/usages.
German Processing Codes

German processing codes are translated to and from BASE24-eps processing codes
by
BASE24-eps German acquiring endpoints. Therefore, standard BASE24-eps
processing
codes are used within BASE24-eps. The original German processing codes
presented
with the transactions are carried in the Network Original Processing Code TDE in
case the
transaction needs to be routed to another German endpoint.
Mapping of German processing codes to and from BASE24-eps processing codes is
performed by the BASE24-eps components receiving and sending German
transactions.
Refer to the documentation for those endpoints for information on how the
processing
codes are mapped.
German Bad PIN Usage

German bad PIN tracking requires returning the number of PIN tries remaining to the
transaction-initiating device rather than the number of PIN tries attempted (which is
the
BASE24-eps standard for PIN processing).This processing is handled by your
authorization
scripts, which can be modified to return remaining PIN tries.
The number of remaining PIN tries is carried in the Bad PIN Counter TDE for return
to the
acquiring device. Scripts are typically written to disable a card if no PIN tries remain,
so
you would also need to adjust your authorization scripts to update the card status
appropriately when the number of remaining PIN tries reaches zero.
Returning Available Balances to the Acquiring Device

BASE24-eps can be scripted to return the remaining available balance where
required by
certain types of transactions.The Remaining Amount Available TDE is used for this
purpose.
BASE24-eps sample scripts have included examples of calculating the remaining
available
balance for the following transactions:
Transactions originating from German ATMs declined by BASE24-eps due to an
overlimit
condition.
ec-cash with chip transactions originating from German POS devices approved or
declined by BASE24-eps.
Next Online Date for Chip Cards

BASE24-eps can be scripted to return in responses to chip card transactions the
next date
a card must be authorized online. The Next Online Data Period field in the Prefix
data
source enables you to set a date offset value (number of days) at the prefix
level.Your
scripts can then use this value for computing the next online date for a chip card
processed
with the corresponding prefix.
The Next Online Date TDE is used to carry the data for the transaction. This TDE
supports
two exported operators which can be used by your authorization scripts: one for the
date
offset value (number of days) from the Prefix data source and one for the calculated
date
(current system date plus the number of days offset).
German Account Types

Account types are not included in transactions on German cards. Consequently,
account
types are not available for configuring routing. Thus, you would need to configure
default
account types, or implement the account types through your authorization scripts.
German Transaction Security

BASE24-eps transaction security for German transactions is described in the
BASE24-eps
Transaction Security User Guide.
German-Specific Transaction Data

BASE24-eps includes certain German-specific data in its transaction TDEs in order
to
support German routing and authorization.
The Transaction Data Elements (TDEs) in which German-specific data is carried are
described here. First are German-specific TDEs, followed by the other BASE24-eps
TDE
in which data is carried for processing German card transactions.
German-Specific TDEs
The following German-specific TDEs are used to carry transaction data specific to
German
card processing.
TDE Description
Can be set by your scripts to return the number of PIN tries remaining to the transaction-initiating
device. This is in contrast to the number of PIN tries attempted (which is the BASE24-eps
standard for PIN processing).
Bad PIN Counter
Carries the German Track 3 data. It is created by BASE24-eps German acquiring endpoints
whenever the external message contains German track 3 data.
German Authorization
Track 3
Set by German acquiring endpoints to identify German acquiring devices. This TDE can be
used by your authorization scripts to determine whether or not a transaction originated at a
German device. Values of ATMN, ATNC, PSNC, and PSNM denote a German device.
Message Class
Can be set by your authorization scripts to provide the next date a chip card must be authorized
online. This TDE can be set using the Next Online Date Period field in the Prefix data source.
Next Online Date
This TDE has two exported operators: one to set a date offset value (number of days) from the
Prefix data source and one to set a computed next online date.
Can be set by your authorization scripts to provide to an acquiring device the available balance
amount remaining for a card. This TDE is typically used for ATM transactions declined by
Remaining Amount
Available
BASE24-eps due to an overlimit condition or for POS ec-cash with chip transactions approved
by BASE24-eps.
Other TDEs Carrying German-Specific Data

The following standard BASE24-eps TDEs are used to carry transaction data
specific to
German card processing.
TDE Description
For EMV requests, the next online date and bad PIN counter information is carried in the
EMV Request TDE. For German transactions, corresponding response information will
always be carried in the Next Online Date and Bad PIN Counter TDEs.
EMV Request
When German transaction processing codes are translated to BASE24-eps processing
codes, the original German processing code is carried in the Network Original Processing
Code TDE.
Network Original
Processing Code

TDE Description
An exported operator is used to set the PIN Verification Number (PVN 2) Offset value used
in German card processing. This value would be set from the PVV 2 field in the Prefix data
source.
Track 2

Configuring German Routing and

Authorization
Routing and authorizing transactions on German cards received through BASE24eps
German channel managers requires some specific configuration.
Setting Up On-Us Prefixes

There are two basic forms of on-us prefixes to consider for German routing and
authorization, depending on the track data to be received in transactions. If you will
be
routing using prefixes from track 2, you will need to set up a prefix record for each 3digit
branch code and 5-digit short BLZ combination that is to be considered an on-us
prefix in
the system (using a PAN length of 19).
If you are planning to use German-specific track 3 routing (i.e., routing based on the
fourth
digit or fourth, fifth, and sixth digits of the long BLZ in track 3), you will need to set up
prefix
records for any of the following track 3 values you plan to process as on-us prefixes.
On-us prefix records are set up using the On-Us Prefix Configuration window
(Configuration
> Prefixes > On-Us) in the BASE24-eps desktop user interface.
Long BLZ Prefix PAN Length Authorizer
xxx100xx 100 3 Postbank Sector
xxx5xxxx 5 1 Savings Bank Sector
2 1 Private Bank Sector
3
xxx2xxxx
xxx3xxxx
xxx4xxxx 4
xxx7xxxx 7
xxx8xxxx 8
6 1 Co-operative Bank Sector
9
xxx6xxxx
xxx9xxxx
You will also need to set the following values in each of your prefix records.
Field Tab Description
The number of days before a chip transaction will be required to be authorized
on-line. Valid values are 0 through 999. The default value is 30.
During transaction processing, your scripts can use this value to populate the
Next Online Date TDE.
Next Online Date EMV Auth Options
Period

Field Tab Description
The track 2 offset to the PIN offset 2, PIN verification value 2, or PIN verification
number 2 depending on the type of PIN verification being used.
This offset allows for retrieval of the indicated value from cards issued with
this prefix. The value in this field is required if the indicated value is to be
retrieved from the card and the PIN Verification Type is Dual PVN.
Card Track
Information
PVV 2
Setting Up Routing for Your On-Us Prefixes (BLZs)

Typically, you would set up separate destination routing profiles to handle your
German
transactionsseparate from the profiles you might use to route your non-German
on-us
prefixes.
Your destination routing profiles need to specify, as authorization destinations, the
Issuer
Authorization component (IAUT) and the authorization scripts that you have written
to
include German authorization processing.
Setting Up Routing for Not-On-Us Prefixes and GeldKarte

Transactions
BASE24-eps does not support authorization for GeldKarte transactions. However,
GeldKarte
transactions can be routed out to GeldKarte hosts. To do this, you will need to set up
a
Destination Profile for GeldKarte transactions and establish route codes for the
GeldKarte
transaction processing code to be routed. Refer to Routing Codes on page 99 for
more
information about route codes and establishing business relationships. The BASE24eps
processing code used for Geldkarte transactions is A6.
Setting Up BLZ Mapping

You will need to establish BLZ mapping to map long BLZs to any branch code and
short
BLZ combinations you plan to use as on-us prefixes. This is required if you plan to
use the
Sperren file refresh, because the Sperren file records contain long BLZs only, and
the Card
and Prefix Block data sources they refresh use the branch code and short BLZ. BLZ
mapping may also be required for processing transactions, depending on the track
data
you will receive in the transactions. If only track 3 is received, you will either need to
route
these transactions using specialized German track 3 routing or map them to track 2
prefixes
and PANs. For additional information, refer to BLZ Mapping on page 224.
Setting up Card and Prefix Blocking

Sperren File processing is handled using the Card and Prefix Block features. If you
need
to be able to block cards or prefixes, you will need to set up card and/or prefix
blocking.
Refer to Card and Prefix Blocking on page 206 for information about this feature.
You will also need to establish your Sperren File refreshes to update the Card and
Prefix
Block data sources. Refer to the BASE24-eps File Refresh User Guide for
information on
setting up your Sperren file refresh.
Modifying Your Authorization Scripts to Support German

Authorization Requirements
Much of the German routing and authorization processing is implemented through
your
some
basic templates for German authorization processing. If used, it is expected that
these
scripts be thoroughly examined and modified to fit your environment. The Sample
Fundamental Authorization Scripts Delivery Document contains a current list of
BASE24-eps
sample authorization scripts.
BLZ Mapping
BASE24-eps provides for mapping long BLZs to corresponding 3-digit branch code
and
5-digit short BLZ combinations using the German BLZ Mapping data source
(BLZ_Map).
Each record in the German BLZ Mapping data source represents a single mapping
of one
long BLZ to one branch code and short BLZ combination. Branch code and short
BLZ
combinations are intended to be used as prefixes for German authorization
processing.
Adding, Viewing, Updating, and Deleting BLZ Mapping Records

German BLZ Mapping records can be added, viewed, updated, or deleted using the
German
BLZ Mapping window (Configure > German BLZ Mapping) on the ACI desktop
user
interface.
What Information is Stored For Each BLZ Mapping Record
The following information is maintained in the German BLZ Mapping data source for
each
German BLZ Mapping record.
Field Description
Long BLZ The 8-digit long Bankleitzahl (BLZ). This value is used as the primary record key.
Branch Code The 3-digit branch code associated with the short BLZ. This field defaults to 672.
Short BLZ The 5-digit short Bankleitzahl (BLZ) associated with the specified branch code.
Components that Use BLZ Mapping

The components listed in this table use the German BLZ Mapping data source for
mapping
long BLZs to branch code and short BLZ combinations. This is done using the long
BLZ
value as a key to look up records in the BLZ Mapping data source. If a record is
found, the
corresponding branch code and short BLZ are used. If a record is not found, the
mapping
fails and the component takes action based on the failure.
Component Description
Maps the long BLZ to a branch code and short BLZ as part of converting German track 3 PAN
data to corresponding track 2 PAN data. If a mapping record cannot be found, the track 3 PAN
data is used for routing the transaction.
German ISO Interface
Maps the long BLZ to a branch code and short BLZ to create a prefix to populate records in
the Card Block and Prefix Block data sources during a refresh. If a mapping record cannot be
found, the refresh skips the refresh record.
Sperren Refresh

BASE24-eps Transaction Flows

This collection of topics describe and illustrate various types of transaction flows that
can
occur within the BASE24-eps Integrated Server (IS) process.
How BASE24-eps Components Interact

Within the Integrated Server Process
Components interact by activating functions within each other. There are two
methods for
activating a function.
Method Description
A component self-registers a callback function (i.e., function pointer) with another
component. This method of activating functions allows the registering component to
Callback Function
be activated later by the component with which the callback function was registered.
The function msg_in is an example of using the callback function method. Multiple
components register a msg_in function with the Message Delivery component.
The class being activated must be known by its actual name and only public functions
can be activated. The function msg_out is an example of such a public function. The
msg_out function is a function of the Message Delivery component only.
Direct
This diagram shows how the msg_in and msg_out functions would be used between
a
Message Delivery component and Acquirer Interface component.

During Global Initialization

During global initialization, components that initially process transaction messages
(e.g.,
acquirer/issuer interface and channel manager components) register their symbolic
names
with the Component Factory and Message Delivery components.
The Component Factory component receives the name of a callback function to
invoke
that instantiates a respective component (e.g., acquirer/issuer interface and channel
interface components). The respective component is not instantiated, however, until
the
first time it is used.The Message Delivery component receives the name of the
component.
Component Factory Processing - First Transaction

The Component Factory component is used to create the optional components as
they
are needed for transaction processing. The following diagram illustrates this basic
flow.
The Message Delivery component receives a request message from the message
manager. It checks its component registry and finds that no component has
registered
to process the request message.
The Message Delivery component requests the Component Factory to create the
Acquirer
Interface component.
The Component Factory constructs the Acquirer Interface component.
Once constructed, the Acquirer Interface component registers its message-in (i.e.,
msg_in) callback function with the Message Delivery component.
The Message Delivery component looks in its registry again. This time, the
component
exists, and the Message Delivery component activates the msg_in function of the
Acquirer
Interface component.
Subsequent Transactions
Once the Acquirer Interface has been instantiated and registered its callback
function, the
Component Factory component is no longer involved until another component is
needed.
The Message Delivery component activates a components functions directly.
The Message Delivery component receives a request message from the message
manager.
The Message Delivery component checks its component registry and finds that the
component that will initially process the request message has registered a callback
function.The Message Delivery component activates the callback (e.g., msg_in)
function
of the Acquirer Interface component.
BASE24-eps Transaction Flow

Summaries
The following diagrams summarize the processing steps that occur within the
BASE24-eps
Integrated Server (IS) process during the processing of various types of transactions.
Diagram Key
In the diagrams that follow, abbreviations are used for names of the components.
The
abbreviations are as follows:
Abbreviation Component
MD Message Delivery component
CHNL MGR Channel Manager component
ACQ I/F Acquirer Interface component
PRFX Prefix component
RTR Router component
ISS AUT Issuer Authorization component
SC Scripting component
ISS I/F 1 Issuer Interface component
CTXT Context component
TIMR Timer component
ISS I/F 2 Issuer Interface component
JRNL Journal component
The abbreviation Dest is used to indicate a destination.

Internal Authorization Request/Response,

Card-Initiated
Transactions initiated with a magnetic-striped card require identification of the card
issuer.
Card issuers are determined using the prefix portion of the card number (PAN). The
issuer_determine function in the Prefix component is invoked to determine the card
issuer
identity, issuer route profile, issuer transaction profile, card track information (e.g.,
which
track to use), and transaction security parameters.
The following diagram illustrates the component interactions required to process the
request
and response messages.
1. The Message Delivery component receives a request message from the Message
Manager.
2. The Message Delivery component activates the correct Acquirer Interface
component
using data from the message header and component registration information.
3. The Acquirer Interface component accesses configuration tables, parses the

message,
creates TDEs, and activates the Prefix component.
The Prefix component determines the issuer of the card-based transaction according
to the primary account number (PAN) in the message. The Prefix component also
adds
prefix-level data to the TDE collection.
4. The Acquirer Interface component activates the Router component to determine
routing.
5. The Router component accesses configuration tables and determines a routing
destination using the Route Type, Acquirer Route Profile, Issuer Route Profile, Route
Code, Account Type 1, Account Type 2, and Authentication Method information.
Routing
destinations may include the Issuer Authorization component and Issuer Interfaces.
In this case, the Router component activates the Issuer Authorization
component.When
the Issuer Authorization component is named as a routing destination, an
Authorization
script-set name must also be provided. The Authorization script-set name identifies
a
group of scripts that may call other scripts for financial requests, authorization
advices,
reversal advices, and others.
6. The Issuer Authorization component selects a financial request script and
activates the
Script component for script execution.
7. After returning from the script, the Issuer Authorization component activates the
Acquirer
Interface component for response processing.
8. The Acquirer Interface component activates the Journal component for transaction
logging.
9. The Journal component logs the transaction to the journal.
10. The Acquirer Interface component creates an external response message from
the
TDEs and activates the Message Delivery component.
11. The Message Delivery component sends the response message to the Message
manager.
Internal Authorization Request/Response

With
Advice
An advice message is optionally sent to an external entity as notification that an
authorization
has taken place (i.e., stand-in authorization).
request
Manager.
component
message,
adds
the
primary authorizer.
Routing
component.When
Authorization
a
advices,
activates the
Acquirer
8. The Acquirer Interface determines from the Advice 1 TDE in the transaction that
an
advice is required and activates the Issuer Interface component.
9. The advice message is added to the store and forward (SAF) file.
10. The Acquirer Interface component activates the Journal component for
transaction
logging.
the

manager.
Sometime later, based on configuration, the SAF Manager process will invoke the
Interface
Manager component to send the advice message to the external processor (steps
1416).
Internal Authorization
Request/Response/Reversal
Reversal requests can be sent to the payments engine from an external processor
following
the normal completion of external authorization request and response processing.
Reversal
requests occur when a message is received indicating the acquirer of the original
transaction
reversed a previously approved financial transaction.
request
Manager.
component
message,
adds
routing.
Routing
component.When
Authorization
a
advices,
activates the
Acquirer
logging.
the
manager.
12. The Message Delivery component receives a message from Message Manager.
component
14. The Acquirer Interface component activates the Journal component.
15. The Journal component retrieves the original transaction data from the journal.
16. The Acquirer Interface component activates the Issuer Authorization component.
17. The Issuer Authorization component selects a reversal script and activates the
Script
component for script execution.
18. Upon return from the script, the Issuer Authorization component activates the
Acquirer
transaction
logging.
20. The Journal component logs the reversal transaction to the journal.
21. The Acquirer Interface component activates the Message Delivery component for
reversal
acknowledgement processing.
22. The Message Delivery component sends the reversal acknowledgement
message to
the message manager.
Interface
Manager component to send the reversal acknowledgement message to the external
processor.
Internal Authorization Request/Response,
Sequential Authorization to External

Destinations
The BASE24-eps product has the capability to perform sequential authorization (or
sequential routing). Sequential authorization gives you the ability to process a
transaction
message into one or more messages to destinations that are then routed individually
as
part of authorization processing.
The following diagram depicts the component interactions required to process the
messages
using sequential authorization.
Manager.
component
message,
adds
routing.
Routing
component.When
Authorization
a
advices,
activates the
Script component for script execution. The Script component executes the script.
7. Using an Issuer Authorization exported operator from the script, the Issuer
Authorization
component activates the Issuer Interface component. The original acquirer
information
is saved in a TDE, the Issuer Authorization component is set as the interim acquirer,
and the script execution information is suspended by saving script execution context
in
a TDE for use in later processing prior to the Issuer Interface component being
activated.
8. The Issuer Interface component accesses configuration tables and creates an
external
request message from TDEs and configuration data. It activates the Timer
component
to create an expiration timer and activates the Context component to save the
context
of the transaction (not shown). The Issuer Interface component activates the
Message
Delivery Component.
9. The Message Delivery Component sends the request message to the platformspecific
message manager.
10. The platform-specific message manager sends the message to the specific
issuer
destination.
11. The issuer destination returns the response.
12. The message manager sends the message to the Message Delivery component.
13. The Message Delivery component activates the correct Issuer Interface
component
14. The Issuer Interface component activates the Context component to retrieve the
original
transaction data to use (deleting it from the Context data source) and activates the
Timer
component to cancel the expiration timer (not shown). It then activates the Acquirer
Interface component. Since the Issuer Authorization component was defined as the
acquirer, the Issuer Authorization component is activated.
15. The Issuer Authorization component uses a script execution TDE to determine
that
sequential routing is executing and requests the Script component to resume the
script
at the appropriate line of execution. The Script component resumes the script
starting
at the appropriate line of execution.
Steps 715 repeat n times, depending on the number of destinations called.
16. When all processing in the script is complete (including routing to all external
destinations), the Issuer Authorization component activates the original Acquirer
interface
for response processing.
transaction
logging.
the
20. The Message Delivery component sends the response message to the message
manager.
External Authorization Request

Upon receipt of a transaction request message from an external source, such as a
payment
device or processor, the Message Delivery component activates the msg_in function
in
the respective acquirer component for message translation and issuer identification.
The
acquirer component to activate is obtained from the header portion of the request
message.
Transactions initiated with a magnetic-striped card require identification of the card
issuer.
Card issuers are determined using the prefix portion of the card number (PAN). The
issuer_determine function in the Prefix component is invoked to determine the card
issuer
identity, issuer route profile, issuer transaction profile, card track information (which
track
to use), and transaction security parameters.
Transactions initiated with a token other than a card that does not contain a card
number
do not require processing by the Prefix component.
messages.
Manager.
component
message,
adds
routing.
5. The Router component activates an Issuer Interface component respective to the
name
(e.g., INTFMDS) provided in the routing configuration. When the Issuer Interface
component is named as a routing destination, an interface name (e.g., MDS) must

also
be provided. The interface name identifies the processing and control configuration.
The Issuer Interface component accesses configuration tables and creates an
external
request message from TDEs and configuration data.
6. The Issuer Interface component activates the Timer component. The Timer
component
requests the creation of an expiration timer.
7. The Issuer Interface component activates the Context component.
8. The Context component either saves the context to a Context data source or, if on
an
HP NonStop platform, sends a message to the Context Manager process to save the
context in a memory collection.
9. The Issuer Interface component activates the Message Delivery component.
10. The Message Delivery component sends the request message to the message
manager.
External Authorization Response

Upon receipt of a transaction response message from an external processor, the
Message
Delivery component activates the msg_in function in the respective issuer
component for
message rerouting. The name of the issuer component to invoke is obtained from
the
header portion of the request message.Transaction data elements (TDEs) are rebuilt
from
previously saved request message context.
messages.
These steps are continued from the External Authorization Request processing.
1. The Message Delivery component receives a response message from the
Message
Manager.
component
4. The Context component retrieves the original transaction from the the Context
data
source or, if on an HP NonStop platform, sends a message to the Context Manager
process to retrieve the original transaction. The transaction is deleted from context at
this time.
component
cancels the expiration timer.
6. The Issuer Interface component activates the Acquirer Interface component for
response
processing.
logging.
TDEs
and configuration data and activates the Message Delivery component.
manager.
External Authorization, Transaction Not

Allowed by the Acquirer
The following diagram depicts the component interactions required to process a
transaction
where the transaction is not allowed by the acquirer.
Manager.
component
using data from the message header and component registration information. The
Acquirer Interface component accesses configuration tables and determines the
transaction is not allowed by the acquirer.
logging.
TDEs
manager.
External Authorization, Transaction Not

Allowed by the Issuer
The following diagram depicts the component interactions involved in processing a
transaction where the transaction is not allowed by the issuer.
Manager.
component
message,

adds
routing.
5. The Router component activates an Issuer Interface component respective to the
name
(e.g., INTFMDS) provided in the routing configuration. When the Issuer Interface
component is named as a routing destination, an interface name (e.g., MDS) must
also
be provided. The interface name identifies the processing and control configuration.
The Issuer Interface component accesses configuration tables and determines the
transaction is not allowed by the issuer.
6. The transaction is not allowed by the issuer, so the Issuer Interface activates the
Acquirer
Interface for response processing.
logging.
TDEs
manager.
External Authorization, Prescreen

(Successful)
transaction where prescreening has been configured. In this case, the transaction
passes
the prescreening checks.
Manager.
component
message,
adds

routing.
5. The Router component activates the Issuer Authorization component.When a
transaction
is to be prescreened, the Issuer Authorization component is named as a routing
destination and an authorization script-set name must also be provided. The
authorization script-set name identifies a group of scripts that may include individual
scripts for prescreening requests, financial requests, authorization advices, reversal
advices, and others.
6. The Issuer Authorization component selects a prescreen script and activates the
Script
7. Upon successful completion of the prescreen script, the Router component
activates
an Issuer Interface component respective to the name (INTFMDS) provided in the
routing
configuration. When the Issuer Interface component is named as a routing
destination,
an interface name (MDS) must also be provided. The interface name identifies the
processing and control configuration. The Issuer Interface component accesses
configuration tables and creates an external request message from TDEs and
configuration data.
component
requests the creation of an expiration timer.
10. The Context component either saves context to a Context data source or, if on
an HP
NonStop platform, sends a message to the Context Manager process to save the
context
in a memory collection.
11. The Issuer Interface component activates the Message Delivery component.
12. The Message Delivery component sends the request message to the message
manager.
External Authorization, Prescreen (Not

Successful)
transaction where prescreening has been configured. In this case, the transaction
does
not pass the prescreening checks.
Manager.
component
message,
adds
routing.
5. The Router component activates the Issuer Authorization component.When a
transaction
is to be prescreened, the Issuer Authorization component is named as a routing
destination and an authorization script-set name must also be provided. The
authorization script-set name identifies a group of scripts that may include individual
scripts for prescreening requests, financial requests, authorization advices, reversal
advices, and others.
6. The Issuer Authorization component selects a prescreen script and activates the
Script
7. In this case, the prescreen fails, and the Issuer Authorization component activates
the
Acquirer Interface component for response processing.
logging.
10. The Acquirer Interface component creates an external request message from
TDEs
manager.
External Authorization, Response With

Impacting
transaction that gets routed to an issuer and is configured for impacting by BASE24eps.
Message
Manager.
component
4. The Context component retrieves and subsequently deletes the original

transaction data
from a Context data source or, if on an HP NonStop platform, sends a message to
the
Context Manager process to retrieve and subsequently delete the original
transaction
data from a memory collection.
component
cancels the expiration timer.
6. The Issuer Interface component activates the Acquirer Interface component for
response
processing.
7. Based on the TDE settings, the Acquirer Interface component determines that
impacting
is required and activates the Issuer Authorization component.
8. The Issuer Authorization component selects an impact script and activates the
Script
component for script execution. Typically, impact scripts are written to update
BASE24-eps card and limits tables (account balance, usage, etc.).
logging.
the
manager.
External Authorization, Request

Timeout/Stand-in
transaction where the transaction is routed to an issuer but times out. In this case,
BASE24-eps is configured to stand in to authorize the trasaction.
1. The timer expiration message is received by the Message Delivery component.
2. The Message Delivery component activates the Timer component.
3. The Timer component activates the Issuer Interface component.
4. The Issuer Interface component activates the Context component to retrieve and
delete
the transaction context.
5. The Context component retrieves the transaction and deletes the transaction
context
from a Context data source or, if on an HP NonStop platform, sends a message to
the
Context Manager process to retrieve the transaction and delete the transaction
context
from a memory collection.
6. The Issuer Interface component activates the Journal component for transaction
logging.
8. The Issuer Interface activates the Router component for rerouting.
9. Router activates the Issuer Authorization component.
activates the
11. Upon returning from the script, the Issuer Authorization component activates the
Acquirer
an
transaction
logging.
the
manager.
Interface
Manager component to send the advice message to the external processor.
External Authorization, Station Marked

Down/Stand-in
transaction where the primary destination issuer station is marked down and
BASE24-eps
uses an alternate destination configured for stand-in authorization.
Manager.
component
message,
adds
routing.
5. The Router component activates an Issuer Interface component named in the
routing
configuration (e.g., INTFMDS).
6. The Issuer Interface component accesses the configuration tables for the
interface,
determines the station to the issuer is marked down (and no other stations are
available),
and activates the Router component for routing to an alternate destination.
Note: When an Issuer Interface component is named as a routing destination, an
interface name (e.g., MDS) must also be provided. The interface name identifies the
processing and control configuration using the interface name.
7. Router activates the Issuer Authorization component for stand-in processing.
activates the
Script component for script execution. The Script component executes the script.
9. Upon return from the script, the Issuer Authorization component activates the
Acquirer
an
transaction
logging.
TDEs
manager.
Interface
Manager component to send the advice message to the external processor.
External Authorization, Late (Approved)

Response
transaction where the issuer returns a late approval (after the transaction has
already timed
out).
Message
Manager.
component
4. Since the transaction request timer has already timed-out, a context record will not
be
found.Therefore, the response is considered late. Since the response was an
approved,
financial transaction, it must be reversed.
5. The Issuer Interface component creates a reversal advice message and adds it to
the
SAF. The late response contains enough information to reverse the transaction.
6. The Issuer Interface component activates the Journal component for transaction
logging.
7. The Journal component logs the reversal transaction to the journal.
8. Later, when SAF processing is initiated by the SAF Manager process, the reversal
advice record is read from the SAF.
9. The Message Delivery component is activated.
10. The Message Delivery component sends the reversal advice message to the
message
manager.
External Authorization, Late (Denied)

Response
transaction where the issuer returns a late denial response (after the transaction has
already timed out).
Message
Manager.
component
4. Since the transaction request timer has already timed-out, the response is
considered
to be late. Also, because the response indicates that the transaction was denied, the
response message is dropped.
Primary Transaction Identifiers

The characteristics of a BASE24-eps transaction are defined by the information in
the
Transaction Data Elements (TDEs) of the transaction messages that carry out the
transaction. Many TDEs influence the processing of a transaction; however several
TDEs
are of primary importance for identifying the nature of the transaction message and
directing
basic processing of the message within BASE24-eps.
These primary transaction identifiers are defined here. For a comprehensive
summary of
all of the TDEs included in BASE24-eps transactions, refer to the BASE24-eps
Transaction
Data Element Reference Guide.
Message Type Identifiers (MTIs)

Message Type Identifiers (MTIs) are four-digit, industry-standard identifiers used to
classify
transaction messages. They are a primary identifier used by transaction processors
to
determine the basic kind of transaction message with which they are dealing.
Internally,
BASE24-eps uses MTIs that adhere to the ISO 8583:1993 standard. Within
BASE24-eps,
the MTI associated with a transaction message is carried in the Message Type
Identifier
Transaction Data Element (TDE).
Message Type Identifier (MTI) Structure

Each of the four positions of the Message Type Identifiers (MTIs) used by BASE24eps
defines a characteristic of the message.
The following table shows the structure of the MTI and the values used within
BASE24-eps.
Note: MTIs for messages being sent outside BASE24-eps may be translated to
different
formats as required.
Position Identifier Values
1 = ISO 8583:1993 standard
9 = Product-specific
1 Version Number
1 = Authorization
2 Message Class
2 = Financial
3 = File action
4 = Reversal/chargeback
5 = Reconciliation
6 = Administrative
7 = Fee collection
8 = Network management
0 = Request
1 = Request response
3 Message Function
2 = Advice
3 = Advice response
4 = Notification (not supported by BASE24-eps)
0 = Acquirer
1 = Acquirer repeat
4 Transaction Originator
2 = Card issuer
3 = Card issuer repeat
4 = Other

Position Identifier Values
5 = Other repeat
69 = Reserved for ISO use
MTI Classes
The second position of the Message Type Indicator (MTI) identifies the message
class.
Classes categorize messages of a similar kind for purposes of identification and
processing.
The following is a brief description of each of the various message classes supported
by
BASE24-eps. Column one is the corresponding value from the second position of the
MTI.
Value Class Description
Messages associated with an authorization transaction.
An authorization transaction is an approvalwithout a guarantee of
fundsgiven by the card issuer to the acquirer.
1 Authorization
The cardholders account is not impacted by the transaction amount even
if the transaction is approved, and the availability of funds at settlement is
not guaranteed.
Authorization transactions are sometimes referred to as pre-authorization
transactions which are followed up by financial messages or are
non-financial in nature, such as balance inquiries.
Messages associated with a financial transaction.
A financial transaction is an approval or guarantee of funds given by the
card issuer to the acquirer that permits the immediate application of the
approved transaction amount to the cardholders account for billing or
posting.
2 Financial
Messages associated with a file update transaction.
A file update transaction is used to add, change, delete, or replace a file
or record. In addition, file action transactions can be used to inquire into a
file or perform card administration functions, such as reporting lost or stolen
cards.
3 File action
Messages associated with a reversal transaction.
A reversal transaction is initiated by an acquirer to partially or completely
nullify the effects of a previous financial or authorization transaction.
4 Reversal
Reversal transactions use advice or notification message types since the
activity has already occurred and the transaction typically cannot be
declined by the card issuer.
Messages associated with a chargeback transaction.
A chargeback transaction is initiated by a card issuer to partially or
completely nullify a previous financial transaction.
4 Chargeback
Chargeback transactions can be used if the original transaction had financial
impact on the cardholders net position, and the card issuer determines
that a customer dispute exists or that an error or a violation of rules has

been committed.

Value Class Description
Chargeback transactions use advice or notification message types since
the activity has already occurred and typically the transaction cannot be
declined by the acquireralthough the original transaction can be
re-presented by the acquirer.
Messages associated with a reconciliation transaction.
A reconciliation transaction provides financial totals between one acquirer
and one card issuer.
5 Reconciliation
Messages associated with an administrative transaction.
An administrative transaction is used when two institutions have identified
a need for the exchange of information (e.g., retrieval requests).
6 Administrative
Note: Not supported by BASE24-eps. Messages associated with a fee
collection transaction.
A fee collection transaction is used to collect or disburse miscellaneous
service fees. Fee collection transactions can originate from an acquirer or
a card issuer and typically cannot be declined.
7 Fee collection
Fee collection transactions have a financial impact and affect reconciliation
totals; however, they do not affect a cardholder account.
Messages associated with a network management transaction.
A network management transaction is used to control the system security
and operating condition of the interchange network and can be initiated by
any interchanging party. Types of network management messages:
8 Network management
System Condition Messages. Used to establish and report system
availability and to give instructions for message handling during periods
of system unavailability.
System Security Messages. Used to control security aspects of the
interchange system, such as key and password management and
security alerts.
System Accounting Messages. Used to identify the end of a
reconciliation period.
System Audit Control Messages. Used to test integrity of interchange
links and/or used as part of an integrity check or failure recovery
scheme.
MTI Functions
The third position of the Message Type Indicator (MTI) identifies the message
function,
which defines for the message class the type of service required by the message.
Transactions, by definition, involve two sides communicating in some manner.
Typically,
one side is asking for something and the other side is answering in some manner. In
some
cases, one side is simply notifying the other that something occurred and may or
may not
require an answer.The ISO 8583:1993 standard defines the protocol for this
communication
by assigning message functions and specifying the situations where they are used.
These
same functions are used by BASE24-eps.
The following is a brief description of each of the various message functions

supported by
BASE24-eps. Column one is the corresponding value from the third position of the
MTI.
Value Message Function Description
A message where the sender informs the receiver that a transaction is in
progress and a response is required to complete the activity.
0 Request
1 Request response A message that carries the answer to a request.
A message where the sender notifies the receiver of an activity that has
been taken, requiring no approval but requiring a response.
2 Advice
3 Advice response A message that carries the answer to an advice.
A message where the sender notifies the receiver of an activity taken,
requiring no approval or response.
4 Notification
MTI Transaction Originators

Transactions messages, by their nature, have a defined originator and recipient.The
fourth
position of the Message Type Indicator (MTI) identifies the type of message
originator. It
also identifies whether or not the message is a repeat of a previous message.
From an industry perspective, originators and recipients are documented in terms of
acquirers and issuers, and certain kinds of transactions are generated by each. For
example,
acquirers initiated purchases and withdrawals, where issuers initiate chargebacks.
Where
the originator is non-specific, as is the case for file updates and a network
management
messages, an originator of other is used.
The ISO 8583:1993 standard also uses the Transaction Originator portion of the MTI
to
denote repeated sends of the same message. Note that while the originator value
can
change from 0 to 1, 2 to 3, or 4 to 5 to denote a repeat, the originator (acquirer,
issuer,
other) does not change through the life of the transaction. The following are the
possible
values allowed in the fourth position of the MTI.
Value Originator Description
An acquirer is the party in a message exchange representing the instrument
acceptor (the party who originally initiated the transaction).
0 Acquirer
An acquirer message that is being repeated (sent again immediately) due
to a suspected or real failure of the initial message.
1 Acquirer Repeat
An issuer is the party in a message exchange representing the transaction
authorizer, who is, or is acting on behalf of, the institution that issued the
instrument (e.g., card or account) by which the transaction was initiated.
2 Card Issuer
An issuer message that is being repeated (sent again immediately) due to
a suspected or real failure of the initial message.
3 Card Issuer Repeat
The originating party in the message exchange represents neither an
acquirer nor issuer in the context of the transaction. This value is used for
file update and network management messages.
4 Other
A message with an originator value of 4 is being repeated (sent again

immediately) due to a suspected or real failure of the initial message.
5 Other Repeat
69 Reserved Reserved for ISO use.

Message Type Indicators (MTIs) Supported by

BASE24-eps
Message Type Indicators (MTIs) are used to identify the general function of a
transaction
message. Every transaction message processed by BASE24-eps has an associated
MTI.
BASE24-eps recognizes those message types described in the following topics.
Authorization Messages (1100s)

Authorization messages are messages associated with an authorization transaction.
An
authorization transaction is an approval "without a guarantee of funds" given by the
card
issuer to the acquirer. The cardholder's account is not impacted by the transaction
amount
even if the transaction is approved, and the availability of funds at settlement is not
guaranteed. Authorization transactions are sometimes referred to as preauthorization
transactions which are followed up by financial messages or are non-financial in
nature,
such as balance inquiries.
BASE24-eps recognizes those authorization messages listed in the following table.
Although
not all are currently supported, they have been identified for future use.
Table Key: The Dir column indicates the direction of the message, from-acquirer-toissuer
(A-I) or from-issuer-to-acquirer (I-A). The Define Name column lists the define name
used
for the MTIs by BASE24-eps.
MTI Description Dir Define Name
Authorization Request Requests approval for an A-I mti_auth_rqst
authorization transaction.
An 1100 message is used when the transaction cannot
complete at the point of service until the response
message is received indicating the action to be taken. It
is not intended to permit the application of this transaction
1100
to the instrument holder (e.g., cardholder) account for the
purpose of issuing a bill or statement, except surcharges.
An Authorization Request Response (1110) message is
expected in return for the 1100 message, either approving
or denying the request.
Authorization Request Repeat Identical to an A-I mti_auth_rqst_repeat
Authorization Request (1100) message, except that it
1101
denotes to the receiver that it is a possible duplicate
message.
An 1101 message is used when a response was expected
to an 1100 message but not received.

Authorization Request Response Carries the answer I-A mti_auth_rqst_resp
to an authorization request; sent in response to a 1100
or a 1101 message.
Indicates the approval of funds or the action to be taken.
1110

returned in response to an Authorization Request (1100)
or Authorization Request Repeat (1101) message to
approve or deny the request.
Authorization Advice Advises of an authorization carried A-I mti_auth_advc
out on behalf of the card issuer.
An 1120 message is not intended to permit application
of the transaction to the instrument holder (e.g.,
cardholder) account for the purpose of issuing a bill or
statement, except surcharges.
1120
An Authorization Advice Response (1130) message is
expected in return for the 1120 message.
Authorization Advice Repeat Identical to an A-I mti_auth_advc_repeat
Authorization Advice (1120) message, except that it
1121
message.
An Authorization Advice Response (1130) message is
expected in return for the 1121 message.
Authorization Advice Response Carries the answer to I-A mti_auth_advc_resp
an authorization advice; sent in response to a 1120 or a
1121 message.
An 1130 message indicates whether the card issuer
accepts or rejects the transfer of financial liability.
1130
Not supported by BASE24-eps. If received at an A-I mti_auth_ntfy
endpoint, it will either be dropped or handled as a
1140
different message type. Authorization Notification
Notifies of an authorization action.
An 1140 message is used to inform the instrument issuer
of an authorization transaction that has completed at the
point of service.
No response message or text-level acknowledgement
messages are expected in response to an 1140 message.
Financial Transaction Messages (1200s)

Financial transaction messages are messages associated with a financial
transaction. A
financial transaction is an approval or guarantee of funds given by the card issuer to
the
acquirer that permits the immediate application of the approved transaction amount
to the
cardholders account for billing or posting.
BASE24-eps recognizes those financial transaction message types listed in the
following
table. Although not all are currently supported, they have been identified for future
use.
used
Financial Transaction Request Requests approval for A-I mti_fncl_rqst
a transaction that, if approved, can be immediately applied
1200
to the account of the customer for billing or statement
purposes.
A 1200 message is used when the transaction cannot
complete at the point of service until the response
message is received indicating the action to be taken.
Use of a financial request message does not imply that
the cardholder is present (e.g. telephone or mail order).
A Financial Transaction Request Response (1210)
message is expected in return for the 1200 message,
either approving or denying the request.
Financial Transaction Request Repeat Identical to a A-I mti_fncl_rqst_repeat
Financial Transaction Request (1200) message, except
1201
that it denotes to the receiver that it is a possible duplicate
message.
A 1201 message is used when a response was expected
to a 1200 message but not received.
A Financial Transaction Request Response (1210)
message is expected in return for the 1201 message,
either approving or denying the request.
Financial Transaction Request Response Carries the I-A mti_fncl_rqst_resp
answer to a financial request; sent in response to a 1200
or a 1201 message.
A 1210 message indicates the approval or guarantee of
funds or the action to be taken. An approval impacts the
customer account.
1210
Financial Transaction Advice Advises of a previously A-I mti_fncl_advc
completed financial transaction carried out on behalf of
the card issuer.
An approval impacts the customer account.
1220
A Financial Transaction Advice Response (1230)
message is expected in response for the 1220 message.
Financial Transaction Advice Repeat Identical to a A-I mti_fncl_advc_repeat
Financial Transaction Advice (1220) message, except
1221
message.
to a 1220 message but not received. An approval impacts
the customer account.
A Financial Transaction Advice Response (1230)
message is expected in response for the 1221 message.
Financial Transaction Advice Response Carries the I-A mti_fncl_advc_resp
answer to a financial advice; sent in response to a 1220
or a 1221 message.
A 1230 message indicates whether the card issuer
accepts or rejects the transfer of financial liability.
1230

Not supported by BASE24-eps. If received at an A-I mti_fncl_ntfy

1240
different message type. Financial Notification Notifies
the receiver of a financial action taken that impacts the
instrument holders account.
A 1240 message is used to inform the instrument issuer
of a financial transaction that has completed at the point
of service.
messages are expected in response to a 1240 message.
File Action Messages (1300s)

File action messages are messages associated with a file update transaction. A file
update
transaction is used to add, change, delete, or replace a file or record. In addition, file
action
transactions can be used to inquire into a file or perform card administration
functions,
such as reporting lost or stolen cards.
BASE24-eps recognizes those file action message types listed in the following table.
Although not all are currently supported, they have been identified for future use.
Table Key: The Dir column indicates the direction of the message. Since there is no
delineated acquirer or issuer associated with the message, the indicators of
from-sender-to-receiver (S-R) and from-receiver-to-original-sender (R-S) are used to
denote
a relative direction. The Define Name column lists the define name used for the MTIs
by
BASE24-eps.
File Action Request Requests a file be updated. S-R mti_file_act_rqst
A File Action Request Response (1314) message is
expected in return to the 1304 message, either approving
1304
File Action Request Repeat Identical to a File Action S-R mti_file_act_rqst_repeat
Request (1304) message, except that it denotes to the
receiver that it is a possible duplicate message.
1305
A File Action Request Response (1314) message is
File Action Request Response Carries the answer to a R-S mti_file_act_rqst_resp
file action request; sent in response to a 1304 or a 1305
message.
1314
File Action Advice Advises of what should be added, S-R mti_file_act_advc
deleted, or replaced in a file or record.
A File Action Advice Response (1334) message is
expected in response to the 1324 message.
1324

File Action Advice Repeat Identical to a File Action S-R mti_file_act_advc_repeat
Advice (1324) message, except that it denotes to the
1325
A File Action Advice Response (1334) message is
File Action Advice Response Carries the answer to a R-S mti_file_act_advc_resp
file action advice; sent in response to a 1324 or a 1325
message.
1334
Not supported by BASE24-eps. If received at an S-R mti_file_act_ntfy
1344
different message type. File Action Notification Notifies
of a file action.
Reversal Messages (1400s)

Reversal messages are messages associated with a reversal transaction. A reversal
transaction is initiated by an acquirer to partially or completely nullify the effects of a
previous
financial or authorization transaction. Reversal transactions use advice or notification
message types since the activity has already occurred and the transaction typically
cannot
be declined by the card issuer.
BASE24-eps recognizes those reversal message types listed in the following table.
Although
not all are currently supported, they have been identified for future use.
used
Reversal Advice Reverses an earlier authorization or A-I mti_rvsl_advc
financial transaction.
A 1420 message is used when a transaction was initially
approved but not actually completed as the authorizer
was advised. If the original transaction had financial
impact, a reversal backs it out.
1420
A Reversal Advice Response (1430) message is expected
in response for the 1420 message.
Reversal Advice Repeat Identical to a Reversal Advice A-I mti_rvsl_advc_repeat
(1420) message, except that it denotes to the receiver
that it is a possible duplicate message.
to a 1420 message but not received. If the original
transaction had financial impact, a reversal backs it out.
1421
in response for the 1421 message.

Reversal Advice Response Carries the answer to a I-A mti_rvsl_advc_resp
reversal advice; sent in response to a 1420 or a 1421
message.
1430
Not supported by BASE24-eps. If received at an I-A mti_rvsl_ntfy
1440
different message type. Reversal Notification Notifies
of a reversal action.
A 1440 message notifies the receiver of an action taken
that reverses a previously authorized transaction (financial

or nonfinancial).
Reversal notification messages are used to inform the
transaction acquirer of an authorization or financial
transaction that has been reversed.
Chargeback Messages (1400s)

Chargeback messages are messages associated with a chargeback transaction. A
chargeback transaction is initiated by a card issuer to partially or completely nullify a
previous financial transaction. Chargebacks transactions can be used if the original
transaction had financial impact on the cardholders net position, and the card issuer
determines that a customer dispute exists or that an error or a violation of rules has
been
committed. Chargeback transactions use advice or notification message types since
the
activity has already occurred and typically the transaction cannot be declined by the
acquirer
although the original transaction can be re-presented by the acquirer.
BASE24-eps recognizes those chargeback message types listed in the following
table.
used
Chargeback Advice Charges back an earlier financial I-A mti_chrgbck_advc
transaction.
A 1422 message notifies an acquirer that a previously
completed charge to a cardholder account is not valid
and that the acquirer will be charged back that amount.
1422
A Chargeback Advice Response (1432) message is
Chargeback Advice Repeat Identical to a Chargeback I-A mti_chrgbck_advc_repeat
Advice (1422) message, except that it denotes to the
1423

in response to the 1423 message.
Chargeback Advice Response Carries the answer to a A-I mti_chrgbck_advc_resp
chargeback advice; sent in response to a 1422 or a 1423
message.
1432
Not supported by BASE24-eps. If received at an I-A mti_chrgbck_ntfy
1442
different message type. Chargeback Notification
Notifies of a chargeback action.
Reconciliation Messages (1500s)
Reconciliation messages are messages associated with a reconciliation transaction.

A
reconciliation transaction provides financial totals between one acquirer and one
card
issuer.
BASE24-eps recognizes those reconciliation message types listed in the following
table.
used
Acquirer Reconciliation Request Acquirer requests or A-I mti_acq_rcncl_rqst
provides card issuer's totals (number and value) for the
last reconciliation period.
1500
Acquirer Reconciliation Request Repeat Identical to an A-I mti_acq_rcncl_rqst_repeat
Acquirer Reconciliation Request (1500) message, except
1501
message.
Issuer Reconciliation Request card issuer requests I-A mti_iss_rcncl_rqst
acquirer's totals (number and value) for the last
reconciliation period.
1502
Issuer Reconciliation Request Repeat Identical to an I-A mti_iss_rcncl_rqst_repeat
Issuer Reconciliation Request (1502) message, except
1503
message.
Acquirer Reconciliation Request Response Carries card I-A mti_acq_rcncl_rqst_resp
issuer's totals (number and value) in response to a
1510
reconciliation request message; sent in response to a
1500 or a 1501 message.
Issuer Reconciliation Request Response Carries A-I mti_iss_rcncl_rqst_resp
acquirer's totals (number and value) in response to a
1512

reconciliation request message; sent in response to a
1502 or a 1503 message.
Acquirer Reconciliation Advice Advises of acquirer's A-I mti_acq_rcncl_advc
totals (number and value) for the last reconciliation period.
1520
Acquirer Reconciliation Advice Repeat Identical to an A-I mti_acq_rcncl_advc_repeat
Acquirer Reconciliation Advice (1520) message, except
1521
message.
Issuer Reconciliation Advice Advises of card issuer's I-A mti_iss_rcncl_advc
1522
Issuer Reconciliation Advice Repeat Identical to an I-A mti_iss_rcncl_advc_repeat

Issuer Reconciliation Advice (1522) message, except that
1523
it denotes to the receiver that it is a possible duplicate
message.
Acquirer Reconciliation Advice Response Carries the I-A mti_acq_rcncl_advc_resp
answer to a reconciliation advice message; sent in
response to a 1520 or a 1521 message.
1530
Issuer Reconciliation Advice Response Carries the A-I mti_iss_rcncl_advc_resp
answer to a reconciliation advice message; sent in
1532
Not supported by BASE24-eps. If received at an A-I mti_acq_rcncl_ntfy
1540
different message type. Acquirer Reconciliation
Notification Notifies the card issuer of the acquirer's
There is no response message to an acquirer
reconciliation notification message.
Not supported by BASE24-eps. If received at an I-A mti_iss_rcncl_ntfy
1542
different message type. Issuer Reconciliation
Notification notifies the acquirer of the card issuer's
Administrative Messages (1600s)

Administrative messages are messages associated with an administrative
transaction. An
administrative transaction is used when two institutions have identified a need for the
exchange of information (e.g., retrieval requests).
BASE24-eps recognizes those administrative messages listed in the following table.
delineated acquirer or issuer associated with the message, the indicators of
denote
by
BASE24-eps.
Administrative Request Requests information to support S-R mti_admin_rqst
the interchange network.
1604
Administrative Request Repeat Identical to an S-R mti_admin_rqst_repeat
Administrative Request (1604) message, except that it
1605
message.
Administrative Request Response Carries the answer R-S mti_admin_rqst_resp
to an administrative request; sent in response to a 1604
or a 1605 message.
1614
Administrative Advice Advises of information to support S-R mti_admin_advc
the interchange network.

1624
Administrative Advice Repeat Identical to an S-R mti_admin_advc_repeat
Administrative Advice (1624) message, except that it
1625
message.
Administrative Advice Response Carries the answer to R-S mti_admin_advc_resp
an administrative advice; sent in response to a 1624 or
a 1625 message.
1634
Not supported by BASE24-eps. If received at an S-R mti_admin_ntfy
1644
different message type. Administrative Notification
Notifies of an administrative action.
Fee Collection Messages - Future Use (1700s)

Not supported by BASE24-eps. Fee collection messages are messages
associated with
a fee collection transaction. A fee collection transaction is used to collect or disburse
miscellaneous service fees. Fee collection transactions can originate from an
acquirer or
a card issuer and typically cannot be declined. Fee collection transactions have a
financial
impact and affect reconciliation totals; however, they do not affect a cardholder
account.
BASE24-eps recognizes the fee collection message types listed in the following table
as
reserved for future use.
used
Acquirer Fee Collection Advice Advises of a service A-I mti_acq_fee_advc
fee due to be collected.
1720
Acquirer Fee Collection Advice Repeat Identical to an A-I mti_acq_fee_advc_repeat
Acquirer Fee Collection Advice (1720) message, except
1721
message.
Acquirer Fee Collection Advice Response Carries the I-A mti_acq_fee_advc_resp
answer to an acquirer fee collection advice; sent in
1730
Acquirer Fee Collection Notification Notifies of a service A-I mti_acq_fee_ntfy
fee due to be collected.
1740
Issuer Fee Collection Advice Advises of a service fee I-A mti_iss_fee_advc
due to be collected.
1722
Issuer Fee Collection Advice Repeat Identical to an I-A mti_iss_fee_advc_repeat
Issuer Fee Collection Advice (1722) message, except
1723
message.
Issuer Fee Collection Advice Response Carries the A-I mti_iss_fee_advc_resp
answer to an issuer fee collection advice; sent in response
to a 1722 or a 1723 message.
1732
Issuer Fee Collection Notification Notifies of a service I-A mti_iss_fee_ntfy
fee due to be collected
1742
Network Management Messages (1800s)

Network management messages are messages associated with a network
management
transaction. A network management transaction is used to control the system
security and
operating condition of the interchange network and can be initiated by any
interchanging
party.
Types of network management messages include:
System Condition Messages. Used to establish and report system availability and
to
give instructions for message handling during periods of system unavailability.
System Security Messages. Used to control security aspects of the interchange
system,
such as key and password management and security alerts.
System Accounting Messages. Used to identify the end of a reconciliation period.
System Audit Control Messages. Used to test integrity of interchange links and/or
used
as part of an integrity check or failure recovery scheme.
BASE24-eps recognizes those network management message types listed in the
following
table. Although not all are currently supported, they have been identified for future
use.
delineated acquirer or issuer associated with the message, indicators of
denote
by
BASE24-eps.
Network Management Request Requests a network S-R mti_netwk_mgmt_rqst
management activity.
A Network Management Request Response (1814)
message is expected in response to the 1804 message.
1804
Network Management Request Repeat Identical to a S-R mti_netwk_mgmt_rqst_repeat
Network Management Request (1804) message, except
1805

message.
A Network Management Request Response (1814)
message is expected in response to the 1805 message.
Network Management Request Response Carries the R-S mti_netwk_mgmt_rqst_resp
answer to a network management request; sent in
1814
Network Management Advice Advises of a network S-R mti_netwk_mgmt_advc
management activity.
1824
Network Management Advice Repeat Identical to a S-R mti_netwk_mgmt_advc_repeat
Network Management Advice (1824) message, except
1825
message.
Network Management Advice Response Carries the R-S mti_netwk_mgmt_advc_resp
answer to a network management advice; sent in
1834
Not supported by BASE24-eps. If received at an S-R mti_netwk_mgmt_ntfy
1844
different message type. Network Management
Notification Notifies of a network management action.
Product-Specific Messages (9000s)

Product-specific messages are messages associated with actions outside the ISO
industry
standard for transaction processing.
BASE24-eps recognizes those product-specific message types listed in the following
table.
delineated acquirer or issuer associated with the message, indicators of
denote
by
BASE24-eps.
Message Reject. Not supported by BASE24-eps. R-S mti_msg_rjct
If received at an endpoint, it will either be dropped or
handled as a different message type.
9000
9620 Administrative Fraud Report S-R mti_admin_fraud_rpt
9630 Administrative Fraud Report Response R-S mti_admin_fraud_rpt_resp

Function Codes
Function codes are three-digit codes used to identify the specific purpose of a
message
within its message class. The function code associated with a transaction is carried
in the
Function Code TDE.
Function Codes Supported by BASE24-eps

Function codes are grouped based on the transaction messages with which they can
be
used. Each group is described below, along with values that BASE24-eps supports.
Table Key: The Code column identifies the function codes used by BASE24-eps.
The
Description column describes the function code. The Define Name column lists the
define
name used for the code by BASE24-eps.
100-Series Function Codes

100-series function codes are used in authorization (1100-series) messages.
Code Description Define Name
100 Original authorization amount accurate fnct_auth_orig_amt_accurate
101 Original authorization amount estimated fnct_auth_orig_amt_estimate
102 Replacement authorization amount accurate fnct_auth_rplmt_amt_accurate
103 Replacement authorization amount estimated fnct_auth_rplmt_amt_estimate
104 Resubmission amount accurate fnct_auth_rsubm_amt_accurate
105 Resubmission amount estimated fnct_auth_rsubm_amt_estimate
106 Supplementary authorization amount accurate fnct_auth_sup_amt_accurate
107 Supplementary authorization amount estimated fnct_auth_sup_amt_estimate
108 Inquiry fnct_auth_inq
172 Recurring Payment fnct_recur_pmnt

200-series function codes are used in financial transaction (1200-series) messages.
200 Original financial request/advice fnct_fncl_orig
201 Previously approved authorization amount same fnct_fncl_auth_apprv_amt_ok
202 Previously approved authorization amount differs fnct_fncl_auth_apprv_amt_eif
203 Resubmission of a previously denied financial request fnct_fncl_rsubm_deny

204 Resubmission of a previously reversed financial transaction fnct_fncl_rsubm_rvsl
205 First representment fnct_fncl_rprsmt_1
206 Second representment fnct_fncl_rprsmt_2
207 Third or subsequent representment fnct_fncl_rprsmt_3

300-series function codes are used in file action (1300-series) messages.
300 File unassigned fnct_file_unassign
301 Add record fnct_file_rec_add
302 Change record fnct_file_rec_chng
303 Delete record fnct_file_rec_del
304 Replace record fnct_file_rec_rplmt
305 Inquire fnct_file_inq
306 Replace file fnct_file_rplmt
307 Add file fnct_file_add
308 Delete file fnct_file_del
309 Card administration fnct_file_crd_admin

400-series function codes are used in reversal and chargeback (1400-series)
messages.
400 Full reversal, transaction did not complete as approved fnct_rvsl_full
401 Partial reversal, transaction did not complete for full amount fnct_rvsl_part
450 First full chargeback fnct_chrgbck_full_1
451 Second full chargeback fnct_chrgbck_full_2
452 Third full chargeback fnct_chrgbck_full_3
453 First partial chargeback fnct_chrgbck_part_1
454 Second partial chargeback fnct_chrgbck_part_2
455 Third partial chargeback fnct_chrgbck_part_3

500-series functions codes are used in reconciliation (1500-series) messages.
500 Final reconciliation fnct_rcncl_final
501 Checkpoint reconciliation fnct_rcncl_chkpt
502 Final reconciliation in a specified currency fnct_rcncl_final_crncy
503 Checkpoint reconciliation in a specified currency fnct_rcncl_chkpt_crncy
504 Request for reconciliation totals fnct_rcncl_ttl_rqst
570 Batch close fnct_rcncl_btch_clos
571 Shift close fnct_rcncl_shift_clos
572 Daily close fnct_rcncl_dly_clos
573 Clerk totals fnct_rcncl_clerk_ttls
574 Batch subtotals fnct_rcncl_btch_subttls
575 Shift subtotals fnct_rcncl_shift_subttls
576 Daily subtotals fnct_rcncl_dly_subttls
585 Issuer stand-in totals unavailable fnct_rcncl_iss_standin_ttls_unavail
586 Acquirer stand-in totals unavailable fnct_rcncl_acq_standin_ttls_unavail
587 Acquirer settlement totals unavailable fnct_rcncl_acq_setl_ttls_unavail
588 Acquirer switch totals available fnct_rcncl_acq_switched_avail
589 Acquirer stand-in totals available fnct_rcncl_acq_standin_avail
590 Issuer switch totals available fnct_rcncl_iss_switched_avail
591 Issuer stand-in totals available fnct_rcncl_iss_standin_avail
592 Acquirer gross interchange value totals fnct_rcncl_acq_giv_avail
593 Acquirer gross interchange value totals unavailable fnct_rcncl_acq_giv_unavail
594 Issuer gross interchange value totals fnct_rcncl_iss_giv_avail
595 Issuer gross interchange value totals unavailable fnct_rcncl_iss_giv_unavail
596 Acquirer switch totals unavailable fnct_rcncl_acq_switched_unavail
597 Acquirer stand-in totals unavailable fnct_rcncl_acq_standin_unavail
598 Issuer switch totals unavailable fnct_rcncl_iss_switched_unavail
599 Issuer stand-in totals unavailable fnct_rcncl_iss_standin_unavail

600-series functions codes are used in administrative (1600-series) messages.
600 Original receipt, retrieval request fnct_admin_orig_rqst
601 Original receipt, repeat retrieval request fnct_admin_orig_rqst_repeat
602 Original receipt, fulfillment fnct_admin_orig_rqst_conf
603 Copy, retrieval request fnct_admin_cpy_rqst

604 Copy, repeat retrieval request fnct_admin_cpy_rqst_repeat
605 Copy, fulfillment fnct_admin_cpy_rqst_conf
650 Unable to parse message fnct_admin_parse_fail
651 MAC verification error fnct_admin_mac_vrfy_err
689 Logon fnct_admin_logon
690 Logoff fnct_admin_logoff
691 Load request fnct_admin_load
692 Handshake request fnct_admin_handshake

800-series function codes are used in network management (1800-series)
messages.
801 System condition/sign-on fnct_nmm_sys_cond_signon
802 System condition/sign-off fnct_nmm_sys_cond_signoff

803 System condition/unavailable fnct_nmm_sys_cond_unavail
804 System condition/message originator's system in backup fnct_nmm_sys_cond_backup
805 System condition/special instruction fnct_nmm_sys_cond_instruct
806 System condition/initiate alternate routing fnct_nmm_sys_cond_alt_rte
809 System security/key request (inbound key) fnct_nmm_sys_sec_key_rqst_in
810 System security/key request (outbound key) fnct_nmm_sys_sec_key_rqst_out
811 System security/key change (both keys) fnct_nmm_sys_sec_key_chng
812 System security/security alert fnct_nmm_sys_sec_alert
813 System security/password change fnct_nmm_sys_sec_pswd_chng
814 System security/device authentication fnct_nmm_sys_sec_dev_auth
815 Start transmission of advices (SAF) fnct_nmm_sys_saf_end
816 Stop transmission of advices (SAF) fnct_nmm_sys_saf_strt
817 System security/key change (inbound key) fnct_nmm_sys_sec_key_chng_in
818 System security/key change (outbound key) fnct_nmm_sys_sec_key_chng_out
819 System condition/sign on acquirer-only processor fnct_nmm_sys_cond_signon_acq
820 System condition/sign on issuer-only processor fnct_nmm_sys_cond_signon_iss
821 System accounting/cutover (future) fnct_nmm_sys_acct_cutover
822 System accounting/checkpoint (future) fnct_nmm_sys_acct_chkpt
823 System condition/sign off acquirer-only processor fnct_nmm_sys_cond_signoff_acq
824 System condition/sign off issuer-only processor fnct_nmm_sys_cond_signoff_iss
825 Update acquirer key fnct_nmm_sys_sec_key_chng_acq

826 Update issuer key fnct_nmm_sys_sec_key_chng_iss
831 System audit control/echo test fnct_nmm_sys_aud_echo_test
832 Acquirer system audit control/echo test fnct_nmm_sys_aud_echo_test_acq
833 Issuer system audit control/echo test fnct_nmm_sys_aud_echo_test_iss
834 Message not accepted bad format fnct_nmm_sys_cond_msg_err
880 Prefix sign-on fnct_nmm_sys_cond_signon_cmn
881 Sign-on fnct_nmm_sys_cond_signon_sngl
882 Prefix sign-off fnct_nmm_sys_cond_signoff_cmn
883 Sign-off fnct_nmm_sys_cond_signoff_sngl
884 Process next advice fnct_nmm_sys_pro_nxt_advc
885 SAF end-of-file fnct_nmm_sys_saf_eof
886 Stop SAF messages fnct_nmm_sys_saf_stop_cmn
Sign-off from recovery fnct_nmm_sys_saf_stop_sngl
Codes 887 and 889 should be used only for advice recovery.
887
888 Start SAF messages fnct_nmm_sys_saf_start_cmn
Sign-on to recovery. fnct_nmm_sys_saf_start_sngl
Codes 887 and 889 should be used only for advice recovery.
889
890 Enter SI mode fnct_nmm_enter_si_mode
891 Exit SI mode fnct_nmm_exit_si_mode
892 Online request for current days settlement totals fnct_nmm_cur_recon
893 Online request for previous days settlement totals fnct_nmm_setl_recon
894 Start dual SAF mode fnct_nmm_sys_saf_start_dual
895 Key Repeat inbound key fnct_nmm_sys_sec_key_repeat_in
896 Key Repeat outbound key fnct_nmm_sys_sec_key_repeat_out
897 Key Verify inbound key fnct_nmm_sys_sec_key_vrfy_in
898 Key Verify outbound key fnct_nmm_sys_sec_key_vrfy_out
899 New Key Request inbound and outbound keys fnct_nmm_sys_sec_key_rqst

900-series function codes can be used in various messages. These function codes
are for
general use and typically defined when more specific function codes are not
appropriate.
940 Unsolicited message fnct_admin_unsol_msg
Multiple Account Select More Account 1 data fnct_prvt_more_acct1
available
970

Multiple Account Select More Account 2 data fnct_prvt_more_acct2
available
971
Multiple Account Select No more account fnct_prvt_more_none
data available
972
973 Customer List More data available fnct_prvt_more_cust
974 Key Repeat inbound and outbound keys fnct_nmm_sys_sec_key_repeat
975 Key Verify inbound and outbound keys fnct_nmm_sys_sec_key_vrfy
985 Non-VSS Funds Transfer Totals fnct_admin_non_vss_xfer_tot
986 VCRSF non-fulfillment fnct_admin_vcrsf_non_fulfillment
987 VCRSF issuer dispute fnct_admin_vcrsf_dispute_iss
988 VCRSF acquirer dispute fnct_admin_vcrsf_dispute_acq
989 Text message fnct_admin_text_msg
990 VIFD alert fnct_admin_chris_alrt
991 CVV Generate request fnct_admin_cvv_gen_rqst
992 CVV2 generate request fnct_admin_cvv2_gen_rqst
993 VSS Funds Transfer Totals fnct_admin_vss_xfer_tot
994 Acquirer-generated fraud advice fnct_admin_fm_acq_fraud_advc
995 Issuer-generated fraud advice fnct_admin_fm_iss_fraud_advc
996 Fraud advices destined for acquirers fnct_admin_to_acq_fraud_advc
997 Fraud advices destined for issuers fnct_admin_to_iss_fraud_advc
998 VCRSF dispute fnct_admin_vcrsf_dispute
Issuer authentication failure or issuer script fnct_admin_script_auth_fail
results advice
999

Message Reason Codes

Message reason codes are four-digit numeric codes carried in a transaction
message that
provide the receiver of a request, advice, or notification message with the reason or
purpose
of that message. For original authorizations, financial, and file action transactions,
the
message reason code identifies why the type of message was sent (e.g., why an
advice
was sent instead of a request). If the transaction is a reversal or adjustment, the
message
reason code indicates the reason the reversal or adjustment was generated. In
BASE24-eps,
message reason codes are carried in the Message Reason Code TDE.
Message Reason Codes Supported by BASE24eps

BASE24-eps supports the message reason codes listed in the following table.
Table Key: The Code column identifies the message reason code.The Description
column
describes what the message reason code means.The Define Name column lists the
define
name used within BASE24-eps to denote the message reason code.
1000 Advice stand in for issuer mrc_advc_stand_in_iss
1001 Advice issuer signed off mrc_advc_iss_signoff

1002 Advice issuer timeout original request mrc_advc_iss_timeout_rqst
1003 Advice issuer unavailable mrc_advc_iss_unavail
1004 Advice terminal processed mrc_advc_term_proc
1005 Advice ICC processed mrc_advc_icc_proc
1006 Advice under floor limit mrc_advc_under_flr_lmt
1007 Advice stand-in acquirer mrc_advc_stand_in_acq
1500 Request ICC application, common file error mrc_rqst_icc_cmn_file_err
1501 Request ICC application file error mrc_rqst_icc_appl_file_err
1502 Request ICC random selection mrc_rqst_icc_random_selct
1503 Request terminal random selection mrc_rqst_term_random_selct
1504 Request terminal error ICC mrc_rqst_term_err_icc
1505 Request online forced by ICC mrc_rqst_onl_icc
1506 Request online card acceptor mrc_rqst_onl_crd_accpt
1507 Request online forced by CAD to be updated mrc_rqst_onl_cad_updt
1508 Request online forced by terminal mrc_rqst_onl_term
1509 Request online forced by card issuer mrc_rqst_onl_iss
1510 Request over floor limit mrc_rqst_over_flr_lmt
1511 Request merchant suspicious mrc_rqst_mrch_suspect

2000 Representment general invalid chargeback mrc_rprsnt_general_invld_chrg
2001 Representment invalid acquirer reference number mrc_rprsnt_invld_acq_ref_num
2002 Representment no documentation for chargeback mrc_rprsnt_no_doc_for_chrgbk
2003 Representment correct transaction date provided mrc_rprsnt_txn_dat_provid
2004 Representment correct merchant description mrc_rprsnt_mrch_descr_provid
2005 Representment correct merchant location mrc_rprsnt_mrch_loc_provid
2006 Representment incorrect tran date on chargeback mrc_rprsnt_txn_dat_incor_chrg
2007 Representment tran less than merchant floor mrc_rprsnt_txn_less_mrch_floor
2008 Representment tran authorized by issuer mrc_rprsnt_txn_auth_by_iss
2009 Representment no error, amount correct mrc_rprsnt_no_err_amt_correct
2010 Representment no altered amount mrc_rprsnt_no_alter_amt
2011 Representment credit previously issued mrc_rprsnt_crdit_prev_issued
2012 Representment original tran was valid mrc_rprsnt_orig_txn_valid
3000 File action lost card mrc_file_crd_lost
3001 File action stolen card mrc_file_crd_stolen
3002 File action undelivered card mrc_file_crd_undeliver
3003 File action counterfeit card mrc_file_crd_cntrft
4000 Reversal customer cancellation mrc_rvsl_cust_cancel
4001 Reversal unspecified, no action taken mrc_rvsl_unspecified_no_act
4002 Reversal suspected malfunction mrc_rvsl_mlfnct_suspect
4003 Reversal - format error, no action taken mrc_rvsl_frmt_err_no_act
4004 Reversal completed partially mrc_rvsl_compl_part
4005 Reversal original amount incorrect mrc_rvsl_orig_amt_bad
4006 Reversal response received too late mrc_rvsl_resp_late
4007 Reversal card acceptor device error mrc_rvsl_crd_accpt_dev_err
4008 Reversal deposit out of balance mrc_rvsl_dep_out_of_bal
4009 Reversal no check in envelope mrc_rvsl_no_chq
4010 Reversal payment out of balance mrc_rvsl_pmnt_out_of_bal
4011 Reversal deposit out of balance, applied mrc_rvsl_dep_out_bal_appl
4012 Reversal payment out of balance, applied mrc_rvsl_pmnt_out_bal_appl
Reversal unable to deliver message to point of mrc_rvsl_deliver_fail_pt_svc
service
4013
4014 Reversal suspected malfunction/card retained mrc_rvsl_mlfnct_suspect_keep
4015 Reversal suspected malfunction/card returned mrc_rvsl_mlfnct_suspect_rtrn
Reversal suspected malfunction/track 3 not mrc_rvsl_mlfnct_suspect_trk3
updated
4016

4017 Reversal suspected malfunction/no cash dispensed mrc_rvsl_mlfnct_suspect_no_cash
Reversal timeout at taking money/no cash mrc_rvsl_timeout
dispensed
4018
4019 Reversal timeout at taking card/no cash dispensed mrc_rvsl_timeout_keep
4020 Reversal invalid response, no action taken mrc_rvsl_resp_invld_no_act
4021 Reversal timeout waiting for response mrc_rvsl_timeout_resp
4351 Reversal suspicious reversal mrc_rvsl_mlfnct_suspect_cash
4352 Reversal suspicious reversal amount known mrc_term_excpt_amt_known
4353 Reversal suspicious reversal amount unknown mrc_term_excpt_amt_unknown
4354 Reversal suspicious reversal amount known mrc_cons_excpt_amt_known
4355 Reversal suspicious reversal amount unknown mrc_cons_excpt_amt_unknown
4356 MAC failure mrc_mac_failure
4357 MAC Key Sync Error mrc_mac_key_sync_err
4358 Invalid MAC value mrc_invld_mac_val
4359 Data Encryption error mrc_data_encrpt_err
4360 Data encryption key sync error mrc_data_encrpt_key_sync_err
4361 Data encryption/decryption failed mrc_invld_data_encrpt_val
4362 Reversal cash retained mrc_cash_ret_aft_cons_access
4363 Reversal system malfunction mrc_rvsl_sys_mlfnct
Customer cancelled transaction (e.g., cancelled an mrc_cust_cancel
interactive message flow such as surcharging)
4364
4365 Hardware Security Module (HSM) error mrc_sec_dev_fail
4366 PIN key sync error mrc_pin_key_sync_err
4367 PIN length error mrc_pin_lgth_err
4368 Reversal duplicate transaction mrc_rvsl_dup_txn
4369 Reversal reconciliation error mrc_rvsl_rcncl_err
4370 Invalid merchant mrc_advc_invld_mrch
4506 Reversal chargeback mrc_rvsl_netwk_advc_chrgbck
4500 Chargeback invalid merchant mrc_chrgbck_invld_mrch
4501 Chargeback invalid transaction mrc_chrgbck_invld_txn
4502 Chargeback customer dispute mrc_chrgbck_cust_dspt
4503 Chargeback expired card mrc_chrgbck_exprd_crd
4504 Chargeback transaction not permitted to terminal mrc_chrgbck_txn_not_prmit_to_term
4505 Chargeback security violation mrc_chrgbck_sec_violation
4506 Chargeback system malfunction mrc_chrgbck_sys_malfnct
4507 Chargeback disputed transaction amount mrc_chrgbck_dspt_txm_amt

4508 Chargeback authorized amount exceeded mrc_chrgbck_auth_amt_excd
4509 Chargeback authorized time limit exceeded mrc_chrgbck_auth_tim_lim_excd
4510 Chargeback credit submitted as a debit mrc_chrgbck_cr_sbmt_as_db
4511 Chargeback debit submitted as a credit mrc_chrgbck_db_sbmt_as_cr
4512 Chargeback duplicate processing of a transaction mrc_chrgbck_dup_pro_txn
4513 Chargeback credit not received mrc_chrgbck_cr_not_rcv
4514 Chargeback fraudulent transaction mrc_chrgbck_fraud_txn
Chargeback cardholder denies transaction was mrc_chrgbck_crdhldr_dny_txn_final
finalized
4515
Chargeback non-fulfillment of request for mrc_chrgbck_nonfulfil_rqst_for_info
information
4516
Chargeback non-fulfillment of request, illegible mrc_chrgbck_nonfulfil_illeg_cpy
copy
4517
Chargeback cardholder does not recognize mrc_chrgbck_crdhldr_invld_merch_des
merchant description
4518
4519 Chargeback stand-in processing not allowed mrc_chrgbck_stand_in_pro_not_alwd
4520 Chargeback stand-in processing criteria not fulfilled mrc_chrgbck_stand_in_pro_not_fulfil
4521 Chargeback transaction exceeds floor limit mrc_chrgbck_txn_excd_flr_lmt
4522 Chargeback declined authorization mrc_chrgbck_dcln_txn
4523 Chargeback non-matching account number mrc_chrgbck_non_mtch_acct_num
4524 Chargeback error in addition mrc_chrgbck_err_in_add
4525 Chargeback altered amount mrc_chrgbck_altr_amt
4526 Chargeback missing signature mrc_chrgbck_missing_sig
4527 Chargeback missing card imprint mrc_chrgbck_missing_crd_imprnt
4528 Chargeback cancelled preauthorized transaction mrc_chrgbck_cncld_preauth_txn

4529 Chargeback delinquent reconciliation mrc_chrgbck_delinq_recon
4530 Chargeback currency conversion errors mrc_chrgbck_crncy_conv_err
4531 Chargeback claim or defense on receipt of goods mrc_chrgbck_clm_on_rspt_gds
4532 Chargeback defective merchandise mrc_chrgbck_dfct_mrchndse
Chargeback fraudulent transaction prior to mrc_chrgbck_fraud_txn_prior_dat
embossed valid date
4533
4534 Chargeback imprint of multiple slips mrc_chrgbck_imprnt_mult_slps
4535 Chargeback warning bulletin/exception file mrc_chrgbck_warn_bulltn
4536 Chargeback late presentment mrc_chrgbck_late_prsnt
4537 Chargeback no show disputed mrc_chrgbck_no_show_dsptd
4538 Chargeback advance lodging deposit mrc_chrgbck_adv_lodg_dep
4539 Chargeback cardholer disputes transaction date mrc_chrgbck_crdhldr_dspt_txn_dat
4540 Chargeback card not yet effective mrc_chrgbck_crd_not_eff

4541 Chargeback illegible data mrc_chrgbck_illeg_data
4542 Chargeback transaction not received mrc_chrgbck_txn_not_recv
Chargeback duplicate processing by multiple mrc_chrgbck_dup_pro_mult_inst
institutions
4543
4544 Chargeback cancelling recurring transaction mrc_chrgbck_cncl_recur_txn
4545 Chargeback currency conversion not allowed mrc_chrgbck_crncy_conv_not_alwd
Chargeback mail/telephone order transaction mrc_chrgbck_phn_ord_txn_unauth_pur
unauthorized purchaser
4546
4547 Chargeback card listed on warning bulletin mrc_chrgbck_crd_on_warn_bulltn
Chargeback cardholder dispute - transaction under mrc_chrgbck_crdhldr_dspt_txn_flr_lmt
merchant floor limit
4548
4549 Chargeback incorrect account number mrc_chrgbck_incorr_acct_num
Chargeback cardholder disputes card activated mrc_chrgbck_crdhldr_dspt_phn_txn
telephone transaction
4550
Chargeback original transaction currency not mrc_chrgbck_orig_txn_crncy_not_prsn
provided
4551
4552 Chargeback mail/telephone order on expired card mrc_chrgbck_phn_ord_exp_crd
4553 Chargeback transaction not as described mrc_chrgbck_txn_not_as_dscrb
4554 Chargeback non-receipt of merchandise mrc_chrgbck_non_rcpt_mrchndse
4555 Chargeback services not rendered mrc_chrgbck_svrc_not_rndrd
4556 Chargeback merchandise not as described mrc_chrgbck_mrchndse_not_as_dscrb
6001 Retrieval request cardholder request or dispute mrc_admin_crdhldr_rqst_or_dspt
6499 Fulfillment notification mrc_admin_fulfillment
9600 Check book order mrc_prvt_cheque_book_order
9601 Statement order mrc_prvt_stmt_order

Point of Service Data

Point of service data is a 12-position set of industry-standard codes used to identify
the
capabilities of the terminal initiating a transaction and the specific conditions that are
(or
were) present at the time a transaction took place at the point of service and/or when
the
transaction was initiated. The point of service data associated with a transaction is
carried
in the Point of Service TDE.
Point of Service Data Supported by BASE24-eps

Point of service data is made up of 12 separate values each with its own individual
meaning.
Each position of the point of service data is described below, along with values that
BASE24-eps supports.
Table Key: The Code column identifies the codes used by BASE24-eps for the
position
of the point of service code.The Description column describes the code.The Define
Name
column lists the define name used for the code by BASE24-eps. Values without
define
names are not supported for specific processing by BASE24-eps, but can be passed
through the system if received from an acquirer.
Position 1 Card Data Input Capability

Position 1 contains a code indicating the primary means of getting the information on
the
card into the terminal. Valid values are as follows:
0 Unknown crd_input_cap_unknwn
1 Manual, no terminal crd_input_cap_manual
2 Magnetic stripe read crd_input_cap_mag_stripe
3 Bar code crd_input_cap_bar_cde
4 OCR crd_input_cap_ocr
5 ICC crd_input_cap_icc
6 Key Entry crd_input_cap_key_entry
7 Proximity ICC crd_input_cap_prox_icc
8 Proximity magnetic stripe crd_input_cap_prox_mag_stripe
AI Reserved for ISO use
JR Reserved for national use
S-Z Reserved for private use

Position 2 Cardholder Authentication Capability

Position 2 contains a code indicating the primary means of verifying the cardholder
at this
terminal. When no order of priorities can be made, a value of 6 is used. Valid values
are
as follows:
0 No electronic authentication crdhldr_auth_cap_no_elec_auth
1 PIN crdhldr_auth_cap_pin
2 Electronic signature analysis crdhldr_auth_cap_elec_sig
3 Biometrics crdhldr_auth_cap_biometric
4 Biographic crdhldr_auth_cap_biographic
5 Electronic authentication inoperative crdhldr_auth_cap_elec_inoper
6 Other crdhldr_auth_cap_other
7 Reserved for ISO use
8 Reserved for national use
9 Reserved for private use
Position 3 Card Capture Capability

Position 3 contains a code indicating whether the terminal has the ability to capture a
card.
Valid values are as follows:

0 None term_crd_captr_cap_none
1 Capture term_crd_captr_cap_captr
Position 4 Operating Environment

Position 4 contains a code indicating whether the terminal is attended by the card
acceptor
and its location. Valid values are as follows:
0 No terminal used oper_envmt_no_term
1 On premises of card acceptor, attended oper_envmt_on_crd_acpt_attnd
2 On premises of card acceptor, unattended oper_envmt_on_crd_acpt_unattnd
3 Off premises of card acceptor, attended oper_envmt_off_crd_acpt_attnd
4 Off premises of card acceptor, unattended oper_envmt_off_crd_acpt_unattnd
5 On premises of cardholder, unattended oper_envmt_on_crdhldr_unattnd
Position 5 Cardholder Present

Position 5 contains a code indicating whether the cardholder is present at the point
of
service and, if not, the reason why the cardholder is not present.Valid values are as
follows:
0 Cardholder present crdhldr_prsn
1 Cardholder not present, unspecified crdhldr_not_prsn_unspec
2 Cardholder not present, mail order crdhldr_not_prsn_mail_ordr
3 Cardholder not present, telephone crdhldr_not_prsn_telephone
4 Cardholder not present, standing authorization crdhldr_not_prsn_stndg_auth
5 Cardholder electronic order crdhldr_elec_order
Position 6 Card Present

Position 6 contains a code indicating whether the card is present at the point of
service.
0 Card not present crd_not_prsn
1 Card present crd_prsn

Position 7 Card Data Input Mode

Position 7 contains a code indicating the method used to input the information from
the
card to the terminal. Valid values are as follows:
0 Unspecified crd_input_mde_unknwn
1 Manual, no terminal crd_input_mde_manual
2 Magnetic stripe read crd_input_mde_mag_stripe
3 Bar code crd_input_mde_bar_cde
4 OCR crd_input_mde_ocr
5 ICC crd_input_mde_icc
6 Key entered crd_input_mde_key_entry
7 Complete magnetic stripe crd_input_mde_compl_mag_stripe
8 Electronic commerce crd_input_mde_elec_commerce
9 Proximity ICC crd_input_mde_prox_icc
A Proximity magnetic stripe crd_input_mde_prox_mag_stripe
BI Reserved for ISO use
Position 8 Cardholder Authentication Method

Position 8 contains a code indicating the method for verifying the cardholder
identity.Valid
values are as follows:
0 Unknown crd_input_cap_unknwn
1 Manual, no terminal crd_input_cap_manual

2 Magnetic stripe read crd_input_cap_mag_stripe
3 Bar code crd_input_cap_bar_cde
4 OCR crd_input_cap_ocr
5 ICC crd_input_cap_icc
6 Key Entry crd_input_cap_key_entry
7 Proximity ICC crd_input_cap_prox_icc
8 Proximity magnetic stripe crd_input_cap_prox_mag_stripe
Position 9 Cardholder Authentication Entity

Position 9 contains a code indicating the entity verifying the cardholder identity.Valid
values
are as follows:
0 Not authenticated crdhldr_auth_ent_not_auth
1 ICC crdhldr_auth_ent_icc
2 CAD crdhldr_auth_ent_cad
3 Authorizing agent crdhldr_auth_ent_auth_agent
4 By merchant crdhldr_auth_ent_merch
5 Other crdhldr_auth_ent_other
Position 10 Card Data Output Capability
Position 10 contains a code indicating the ability of the terminal to update the card.
Valid
values are as follows:
0 Unknown crd_data_output_cap_unknwn
1 None crd_data_output_cap_none

2 Magnetic stripe write crd_data_output_cap_mag_wrt
3 ICC crd_data_output_cap_icc
67 Reserved for National use
89 Reserved for Private use
Position 11 Terminal Output Capability

Position 11 contains a code indicating the ability of the terminal to print or display
messages.
0 Unknown term_output_cap_unknwn
1 None term_output_cap_none
2 Printing term_output_cap_prnt
3 Display term_output_cap_dspy
4 Printing and display term_output_cap_prnt_dspy
Position 12 PIN Capture Capability

Position 12 contains a code indicating the length of PIN that the acquirer endpoint is
capable
of capturing. BASE24-eps also uses a value of S in this field to indicate that the PIN
has
been verified.
0 No PIN capture capability pin_captr_cap_none
1 Device PIN capture capability unknown pin_captr_cap_unknwn
3 Three characters pin_captr_cap_pin_lgth_3

4 Four characters pin_captr_cap_pin_lgth_4
5 Five characters pin_captr_cap_pin_lgth_5
6 Six characters pin_captr_cap_pin_lgth_6
7 Seven characters pin_captr_cap_pin_lgth_7
8 Eight characters pin_captr_cap_pin_lgth_8
9 Nine characters pin_captr_cap_pin_lgth_9
A Ten characters pin_captr_cap_pin_lgth_10
B Eleven characters pin_captr_cap_pin_lgth_11
C Twelve characters pin_captr_cap_pin_lgth_12
DI Reserved for ISO use
S PIN has been verified pin_captr_cap_vrfy
TZ Reserved for private use

Processing Codes
Processing codes are six-digit codes consisting of three separate values used to
identify
the type of transaction: a two-character transaction code, a two-character from
account
type, and a two-character to account type.
The format of the BASE24-eps processing code is xxyyzz, where xx is the
transaction
code, yy is the from account type, and zz is the to account type. Processing codes
are
carried in the Processing Code TDE of the transaction.
Transaction Codes Supported by BASE24-eps

Transaction codes are two-position values that identify the basic type of transaction
being
processed. Transaction codes are the first two positions of the transaction
processing
code.
BASE24-eps supports the transaction code values listed in the following table. Not
all
acquirers and issuers support all of the transaction codes listed. Nor do all acquirers
and
issuers support all transaction code and account type combinations that could be
included
in a processing code recognizable to BASE24-eps. Refer to the vendor
documentation for
your acquiring and issuing endpoints to determine the processing codes (transaction
code
and account type combinations) supported by the endpoint.
Table Key: The Tran Code column identifies the transaction code. The Description
column
describes the action represented by the transaction code. The Define Name column
lists
the define name used for the transaction code by BASE24-eps.
Tran Code Decription Define Name
blanks Blank No Transaction Code tc_space_d
00 Debit Goods and Services tc_db_goods_svc_d
01 Debit Cash tc_db_cash_d
02 Debit Adjustment tc_db_adj_d
03 Debit Check Guarantee (funds guaranteed) tc_db_chq_guar_d
Debit Check Verification (funds available but not tc_db_chq_vrfy_d
guaranteed)
04
05 Debit Eurocheque tc_db_euro_chq_d
06 Debit Travelers Check tc_db_tchq_d
07 Debit Letter of Credit tc_db_letter_cr_d
08 Debit Giro (Postal Banking) tc_db_giro_d
09 Debit Goods and Services with Cash Disbursement tc_db_goods_svc_cb_d
0A Private Phone Top-Up tc_prvt_phn_top_up_d
0B Debit Fee Collection tc_db_fee_collection_d

10 Debit Non-cash Financial Instrument (e.g., Wire Transfer) tc_db_non_cash_d
11 Debit Quasi-cash and Scrip tc_db_scrip_d
17 Debit Fast Cash tc_db_fast_cash_d
18 Debit Private Use tc_db_prvt_18_d
19 Debit Private Use tc_db_prvt_19_d
20 Credit Return tc_cr_return_d
21 Credit Deposit tc_cr_dep_d
22 Credit Adjustment tc_cr_adj_d
23 Credit Check Deposit Guarantee tc_cr_chq_dep_guar_d
24 Credit Check Deposit tc_cr_chq_dep_d
28 Credit Deposit with Cash Back tc_cr_dep_cb_d
29 Credit Check Deposit with Cash Back tc_cr_chq_dep_cb_d
2A Funds Dispursement tc_funds_disburse_d
2B Credit Prepaid Load tc_cr_pre_pd_load_d
2C Original Credits tc_orig_cr_d
2D Cash Deposit with Cash Back tc_cr_cash_dep_cb_d
2E Cash Deposit tc_cr_cash_dep_d
30 Inquiry Available Funds Inquiry tc_inq_avail_funds_d
31 Inquiry Balance Inquiry tc_inq_bal_d
38 Card Verification tc_inq_crd_vrfy_d
39 Statement Print (inbound/outbound) tc_inq_stmt_prnt_d
3A Mini-Statement Inquiry Check Clear (inbound/outbound) tc_inq_chq_clr_d
3B Mini-Statement Inquiry Last Debit/Credit (inbound/outbound) tc_inq_last_dbcr_d
3C Mini-Statement Inquiry Last Source (inbound/outbound) tc_inq_last_src_d
3D Mini-Statement Inquiry Last Check (inbound/outbound) tc_inq_last_chq_d
3E Mini-Statement Inquiry Last Debit (inbound/outbound) tc_inq_last_db_d
3F Mini-Statement Inquiry Last Credit (inbound/outbound) tc_inq_last_cr_d
3G Mini-Statement Inquiry Last Transfer (inbound/outbound) tc_inq_last_xfer_d
3H Inquiry Customer Vendor tc_inq_cust_vndr_d
3J Inquiry Scheduled Payment tc_inq_sched_pmnt_d
3K Inquiry Scheduled Transfer tc_inq_sched_xfer_d
3L Inquiry Last Payment and Transfer tc_inq_last_pmnt_and_xfer_d
3M Inquiry Scheduled Transaction tc_inq_sched_txn_d
3N Inquiry Account List tc_inq_acct_list_d
40 Transfer Cardholder Accounts Transfer tc_xfer_acct_d
48 Transfer Private Use tc_xfer_prvt_48_d

49 Transfer Private Use tc_xfer_prvt_49_d
4A Transfer Future tc_xfer_acct_futr_d
4B Transfer Recurring tc_xfer_acct_recur_d
50 Payment (can include both a from and to account type) tc_pmnt_d
56 Payment to (only a to account is present) tc_pmnt_to_d
58 Payment Enclosed tc_pmnt_enclose_d
59 Payment Private Use tc_pmnt_prvt_59_d
5A Payment Payment Future tc_pmnt_futr_d
5B Payment Recurring tc_pmnt_recur_d
5C Bulk Authorization tc_pmnt_bulk_auth_d
5D Return Payment tc_pmnt_rtrn_d
5E Scheme Return Payment tc_pmnt_schme_rtrn_d
5F Corporate Dated Payment tc_pmnt_corp_futr_d
5G Payment To Third Party tc_pmnt_to_thrd_prty_d
5H Payment From Third Party tc_pmnt_from_thrd_prty_d
7S Private Use PIN Unblock tc_pin_unblk_d
7T Private Use EMV Management PIN Change tc_prvt_emv_mgmt_pin_chng_d
7U Private Use EMV Management PIN Unblock tc_prvt_emv_mgmt_pin_unblk_d
90 PIN Change tc_prvt_pin_chng_d
91 PIN Verify tc_prvt_pin_vrfy_d
92 Private Use Close Batch tc_prvt_setl_btch_clos_d
93 Private Use Close Day tc_prvt_setl_dly_clos_d
94 Private Use Close Shift tc_prvt_setl_shift_clos_d
95 Private Use Batch Subtotals tc_prvt_setl_ttls_d
95 Private Use Administrative Subtotals tc_prvt_admin_subttl_d
95 Private Use Network Management Message tc_prvt_nmm_d

96 Private Use Administrative Load tc_prvt_admin_load_rqst_d
97 Private Use Initial Cash tc_prvt_setl_init_cash_d
98 Private Use Add Cash tc_prvt_setl_add_cash_d
99 Private Use EMV Script Management tc_prvt_emv_script_mgmt_d
9A Private Use Scheduled Payment tc_prvt_sched_pmnt_d
9B Private Use Scheduled Future Payment tc_prvt_sched_pmnt_futr_d
9C Private Use Scheduled Recurring Payment tc_prvt_sched_pmnt_recur_d
9D Private Use Scheduled Future Transfer tc_prvt_sched_xfer_futr_d
9E Private Use Scheduled Recurring Transfer tc_prvt_sched_xfer_recur_d
9F Private Use Delete Scheduled Payment tc_prvt_sched_pmnt_del_d

9G Private Use Delete Scheduled Transfer tc_prvt_sched_xfer_del_d
9H Private Use Change Scheduled Payment tc_prvt_sched_pmnt_chng_d
9I Private Use Administrative Check Proof List tc_prvt_cpl_prnt_d
9J Private Use Change Scheduled Transfer tc_prvt_sched_xfer_chng_d
9K Private Use Customer Add tc_prvt_cust_sign_up_d
9L Private Use Customer Inquiry tc_prvt_cust_info_inq_d
9M Private Use Customer Update tc_prvt_cust_info_chng_d
9N Private Use Customer Vendor Add tc_prvt_cust_vndr_add_d
9P Private Use Customer Vendor Delete tc_prvt_cust_vndr_del_d
9Q Private Use Customer Vendor Update tc_prvt_cust_vndr_chng_d
9R Private Use Master Vendor List Inquiry tc_prvt_mstr_vndr_inq_d
9S Private Use Master Vendor Add tc_prvt_mstr_vndr_add_d
9T Private Use Customer Vendor Master List tc_prvt_cust_vndr_mstr_list_d
9U Private Use Phone Top-Up tc_prvt_phn_crd_pur_d
9V Private Use Loan Application tc_prvt_loan_appl_d
9W Private Use Message to Bank tc_prvt_msg_to_bnk_d
9X Private Use History Inquiry All Transactions tc_prvt_hist_inq_d
9Y Private Use Administrative Balance Standard Cash tc_prvt_admin_bal_std_cash_d
9Z Private Use Administrative Balance Current Cash tc_prvt_admin_bal_cur_cash_d
A0 Private Use Prepaid Activation tc_prvt_pre_pd_actvty_d
A1 Private Use Log Only tc_prvt_log_only_d
A2 Private Use Check Cashing tc_prvt_chq_cash_d
A3 Private Use Card Capture tc_prvt_crd_captr
A4 Private Use Card Return tc_prvt_crd_rtrn
A5 Private Use EMV Log Only tc_prvt_emv_log_only_d
Private Use Online Personalization Terminal (OPT) tc_prvt_german_opt_d
transaction
A6
A7 Private Use GeldKarte transaction tc_prvt_german_gdk_d
P Private Use CSM Use tc_prvt_rpq_2_d
Q Private Use CSM Use tc_prvt_rpq_3_d
R Private Use CSM Use tc_prvt_rpq_1_d
User defined. Can be any value that starts with a U tc_prvt_user_def_d
(U0-UZ). These can include log-only transactions.
U
X Private Use Channel Use tc_prvt_dist_1_d
Y Private Use Channel Use tc_prvt_dist_2_d
Z Private Use Channel Use tc_prvt_dist_3_d

From and To Account Types Supported by

BASE24-eps
From account types and to account types are two-position values that identify the
account
types involved in a transaction: from account type, the type of account from which
funds
are being taken by the transaction; to account type, the type of account to which
funds are
being added by the transaction. From account types are the third and fourth
positions of
the transaction processing code. To account types are the fifth and sixth positions of
the
transaction processing code.
BASE24-eps supports the from and to account values listed in the following table.
Not all
acquirers and issuers support all of the account types listed. Nor do all acquirers and
issuers support all transaction code and account type combinations that could be
included
in a processing code recognizable to BASE24-eps. Refer to the vendor
documentation for
your acquiring and issuing endpoints to determine the processing codes (transaction
code
and account type combinations) supported by the endpoint.
Table Key: The Code column identifies the account type.The Description column
describes
the account type.
Code Description
00 Not specified
10 Savings
20 Checking (DDA)
30 Credit
38 Credit line
40 Universal account
50 Investment account
58 CD
59 IRA
60 Stored Value Reloadable cash card account (transfer value)
67 Stored Value Disposable cash card
90 NOW
9A Commercial loan
9B Installment loan
9C Mortgage loan
9M Other

Action Codes
Action codes are three-digit numeric codes carried in a transaction message that
define
the action taken on the transaction message. In a request-response situation, the
action
code is the answer provided by the responder regarding the request.
In BASE24-eps, action codes are carried in the Action Code TDE and can be set
using
the TDE.ACT_CDE_SET script operator. Action codes that can be displayed on ACI
desktop
windows are defined in the CommonCodeValues.properties file, which can be
modified as
necessary.
Action Codes Supported by BASE24-eps
BASE24-eps supports the action code values listed here. Action codes are grouped
according to what they are used for.
Table Key: The Code column in the tables identifies the action code. The
Description
column describes the action represented by the action code. The Define Name
column
lists the define name by which the action code is known in BASE24-eps.
Approved Action Codes (000-099)

Action codes 000-099 are reserved for approved actions.
000 Approved ac_apprv
001 Approved, honor with identification ac_apprv_id
002 Approved for partial amount ac_apprv_part_amt
003 Approved (VIP) ac_apprv_vip
004 Approved, update Track 3 ac_apprv_updt_trk3
005 Approved, account type specified by card issuer ac_apprv_iss_at
006 Approved for partial amount, account type specified by card issuer ac_apprv_part_amt_iss_at
007 Approved, update ICC ac_apprv_updt_icc
070079 Reserved for customer-specific codes
080 Approved, backup ac_apprv_backup_prvt
081 Approved, overdraft ac_apprv_ovrdft_prvt
082 Approved, surcharge ac_apprv_surch_prvt
083 Approved, OAR ac_apprv_oar_prvt

084 Approved, no EMV script ac_apprv_no_emv_script_prvt
Declined Action Codes, With No Card Pickup (100-199)

Action codes 100-199 are reserved for declined actions that do not require a card
pickup.
100 Denied, do not honor ac_deny_do_not_honor
101 Denied, expired card ac_deny_crd_exp
102 Denied, suspected fraud ac_deny_fraud_suspect
103 Denied, card acceptor contact acquirer ac_deny_crd_accpt_see_acq
104 Denied, restricted card ac_deny_crd_restrict
105 Denied, card acceptor call acquirers security department ac_deny_crd_accpt_acq_sec
106 Denied, allowable PIN tries exceeded ac_deny_pin_tries_exceed
107 Denied, refer to card issuer ac_deny_iss_rfrl
108 Denied, refer to card issuers special conditions ac_deny_iss_rfrl_spcl_cond
109 Denied, invalid merchant ac_deny_mrch_invld
110 Denied, invalid amount ac_deny_amt_invld
111 Denied, invalid card number ac_deny_crd_num_invld
112 Denied, PIN data required ac_deny_pin_req
113 Denied, unacceptable fee ac_deny_fee_unaccpt
114 Denied, no account of type requested ac_deny_no_acct
115 Denied, requested function not supported ac_deny_fnct_not_sup
116 Denied, not sufficient funds ac_deny_funds_unavail
117 Denied, incorrect PIN ac_deny_pin_bad
118 Denied, no card record ac_deny_crd_rec_not_found
119 Denied, transaction not permitted to cardholder ac_deny_txn_not_alwd_crdhldr
120 Denied, transaction not permitted to terminal ac_deny_txn_not_alwd_term
121 Denied, exceeds withdrawal amount limit ac_deny_wdl_amt_lmt_exceed
122 Denied, security violation ac_deny_sec_violation
123 Denied, exceeds withdrawal frequency limit ac_deny_wdl_freq_lmt_exceed
124 Denied, violation of law ac_deny_law_violation
125 Denied, card not effective ac_deny_crd_not_effective
126 Denied, invalid PIN block ac_deny_pin_blk_invld
127 Denied, PIN length error ac_deny_pin_lgth_err
128 Denied, PIN key synchronization error ac_deny_kpt_sync_err

129 Denied, suspected counterfeit card ac_deny_crd_cntrft_suspect

160167 Reserved for customer-specific denial codes
168 ARQC failed, decline, return card ac_deny_arqc_fail_dcln
169 ARQC failed, refer ac_deny_arqc_fail_rfrl
170 CVR failed, decline, return card ac_deny_cvr_fail_dcln
171 CVR failed, refer ac_deny_cvr_fail_rfrl
172 TVR failed, decline, return card ac_deny_tvr_fail_dcln
173 TVR failed, refer ac_deny_tvr_fail_rfrl
174 ATC failed, decline, return card ac_deny_atc_fail_dcln
175 ATC failed, refer ac_deny_atc_fail_rfrl
176 Denied, fallback check ac_deny_fallback_chk_dcln
177 Referred, fallback check ac_deny_fallback_chk_rfrl
178 Denied, reason online code fail ac_deny_roc_fai_cdln
179 Denied, reason online code refer ac_deny_roc_fail_rfrl
180 Denied, amount not found ac_deny_amt_not_found_prvt
181 Denied, PIN change required ac_deny_pin_chng_req_prvt
182 Denied, new PIN invalid ac_deny_pin_new_invld_prvt
183 Denied, issuer/bank not found ac_deny_bank_not_found_prvt
184 Denied, issuer/bank not effective ac_deny_bank_not_effect_prvt
185 Denied, customer/vendor not found ac_deny_cvndr_not_found_prvt
186 Denied, customer/vendor not effective ac_deny_cvndr_not_effct_prvt
187 Denied, customer/vendor account invalid ac_deny_cvndracct_invld_prvt
188 Denied, vendor not found ac_deny_vndr_not_found_prvt
189 Denied, vendor not effective ac_deny_vndr_not_effect_prvt
190 Denied, vendor data invalid ac_deny_vndr_data_invld_prvt
191 Denied, payment data invalid ac_deny_pmnt_dat_invld_prvt
192 Denied, personal information not found ac_deny_prsnl_not_found
193 Denied, scheduled transaction already exists ac_deny_schedtxns_exist_prvd
194 Denied, user not allowed to perform the requested function ac_deny_oper_lvl_too_low_prvt
195 Denied, print mini-statement instead ac_deny_mini_stmt_avail_prvt
196 Denied, no statement data available ac_deny_no_stmt_avail_prvt
197-199 Reserved for private use
Declined Action Codes, With Card Pickup (200-299)

Action codes 200-299 are reserved for declined actions that require a card pickup.
200 Retain card, do not honor ac_keep_do_not_honor
201 Retain card, expired card ac_keep_crd_exp
202 Retain card, suspected fraud ac_keep_fraud_suspect
203 Retain card, card acceptor contact acquirer ac_keep_crd_accpt_see_acq
204 Retain card, restricted card ac_keep_crd_restrict
205 Retain card, card acceptor call acquirers security department ac_keep_crd_accpt_acq_sec
206 Retain card, allowable PIN tries exceeded ac_keep_pin_tries_exceed
207 Retain card, special conditions ac_keep_spcl_cond
208 Retain card, lost card ac_keep_crd_lost
209 Retain card, stolen card ac_keep_crd_stolen
210 Retain card, suspected counterfeit card ac_keep_crd_cntrft_suspect
280 ARQC failed, decline, retain card ac_keep_arqc_fail
281 CVR failed, decline, retain card ac_keep_cvr_fail
282 TVR failed, decline, retain card ac_keep_tvr_fail
283 ATC failed, decline, retain card ac_keep_atc_fail
284 Fallback check, decline, retain card ac_keep_fallback_chk_fail
285 Denied (keep card), reason online code fail ac_keep_roc_fail
File Action Message Action Codes (300-399)
Action codes 300-399 are reserved for use with file action messages (MTIs in the
1300
range). Refer to File Action Messages (1300s) on page 269 for information about
these
message types.
300 Successful ac_file_ok
301 Not supported by receiver ac_file_unsup
302 Unable to locate record on file ac_file_rec_not_found
303 Duplicate record, old record replaced ac_file_rec_dup_replace
304 Field edit error ac_file_fld_edit_err
305 File locked out ac_file_lock
306 Not successful ac_file_not_ok
307 Format error ac_file_frmt_err

308 Duplicate, new record rejected ac_file_rec_dup_rjct
309 Unknown file ac_file_unkn
Reversal/Chargeback Message Action Codes (400-499)

Action codes 400-499 are reserved for use with reversal and chargeback messages
(MTIs
in the 1400 range). Refer to Reversal Messages (1400s) on page 270 and
Chargeback
Messages (1400s) on page 271 for information about these message types.
400 Reversal accepted ac_rvsl_ok
481 Reversal, original transaction not found ac_rvsl_orig_txn_not_fnd
484 Reversal, original transaction not approved ac_rvsl_orig_txn_not_apprv
Reconciliation Message Action Codes (500-599)

Action codes 500-599 are reserved for use with reconciliation messages (MTIs in the
1500
range). Refer to Reconciliation Messages (1500s) on page 272 for information about
these
message types.
500 Reconciled, in balance ac_rcncl_in_bal
501 Reconciled, out of balance ac_rcncl_out_of_bal
502 Amount not reconciled, totals provided ac_rcncl_amt_not_ok_ttl
503 Totals not available ac_rcncl_ttl_unavail
504 Not reconciled, totals provided ac_rcncl_not_ok_ttl
505-559 Reserved for ISO use

Administrative Message Action Codes (600-699)

Action codes 600-699 are reserved for use with administrative messages (MTIs in
the 1600
range). Refer to Administrative Messages (1600s) on page 273 for information about
these
message types.
600 Accepted ac_admin_ok
601 Not able to trace back original transaction ac_admin_trc_fail
602 Invalid reference number ac_admin_ref_num_invld
603 Reference number/PAN incompatible ac_admin_ref_num_pan_invld
604 POS photograph is not available ac_admin_photo_unavail
605 Item supplied ac_admin_item_supplied
Request cannot be fulfilledrequired/requested documentation ac_admin_doc_unavail
is not available
606
607 Out of window ac_admin_out_of_window
Fee Collection Message Action Codes (700-799)

Action codes 700-799 are reserved for use with fee collection messages (MTIs in the
1700
range). Refer to Fee Collection Messages - Future Use (1700s) on page 274 for
information
about these message types.
700 Accepted ac_fee_ok
751 Approved, exceeded limit ac_apprv_exceed_lmt

Network Management Message Action Codes (800-899)

Action codes 800-899 are reserved for use with network management messages
(MTIs in
the 1800 range). Refer to Network Management Messages (1800s) on page 275 for
information about these message types.
800 Accepted ac_nmm_ok
801-859 Reserved for ISO use
System Error Action Codes (900-999)

Action codes 900-999 are reserved for denoting system errors.
900 Advice acknowledged, no financial liability accepted ac_sys_advc_ack_no_liability
901 Advice acknowledged, financial liability accepted ac_sys_advc_ack_liability
902 Invalid transaction ac_sys_txn_invld
903 Re-enter transaction ac_sys_txn_reenter
904 Format error ac_sys_frmt_err
905 Acquirer not supported by switch ac_sys_acq_unsup
906 Cutover in process ac_sys_cutover_in_proc
907 Card issuer or switch inoperative ac_sys_iss_inoperative

908 Transaction destination cannot be found for routing ac_sys_rte_dest_not_found
909 System malfunction ac_sys_malfnct
910 Card issuer signed off ac_sys_iss_signoff
911 Card issuer timed out ac_sys_iss_timeout
912 Card issuer unavailable ac_sys_iss_unavail
913 Duplicate transmission ac_sys_xmit_dup
914 Not able to trace back to original transaction ac_sys_trc_fail
915 Reconciliation cutover or checkpoint error ac_sys_rcncl_err
916 MAC incorrect ac_sys_mac_bad
917 MAC key synchronization error ac_sys_kam_sync_err
918 No communication keys available for use ac_sys_comm_key_unavail
919 Encryption key synchronization error ac_sys_encrypt_key_sync_err
920 Security software/hardware error, try again ac_sys_sec_err_retry

921 Security software/hardware error, no action ac_sys_sec_err_no_act
922 Message number out of sequence ac_sys_msg_num_invld
923 Request in progress ac_sys_rqst_in_prog
940 Database error ac_sys_datab_err_prvt
941 Currency code not supported ac_sys_crncy_cde_unsup_prvt
942 Amount format error ac_sys_frmt_err_amt_prvt
943 Customer/vendor format error ac_sys_frmt_err_cvndr_prvt
944 Data format error ac_sys_frmt_err_dat_prvt
945 Name format error ac_sys_frmt_err_nam_prvt
946 Account format error ac_sys_frmt_err_acct_prvt
947 Recurring data error ac_sys_recur_data_err_prvt
948 Update not allowed ac_sys_updt_not_alwd_prvt
949 Invalid capture (posting) date ac_sys_captr_dat_invld_prvt
950 Violation of business arrangement ac_sys_bus_violation
992 Vendor authorization failed ac_sys_vndr_auth_fail
993 Vendor authorization rejected ac_sys_vndr_auth_rjct
994 Vendor customer ID invalid ac_sys_vndr_cust_id_invld
995 Vendor customer account limit reached ac_sys_vndr_cust_acct_lmt_exceed
996 Vendor system unavailable ac_sys_vndr_sys_unavail

Base24EPS TransactionProcessing

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Base24EPS TransactionProcessing

Caricato da

Copyright:

Formati disponibili

TCS

BASE24-eps Transaction Processing

Refresh Scheduling as it Relates to Account Balances.................................49

Configuring Script Sets to Use as Routing Destinations......................................122

Adding, Viewing, Updating, and Deleting Prefix Blocks........................................212

The BASE24-eps Transaction Processing User Guide describes the various

up prefixes and routing).

8 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29

of the BASE24-eps Multiple Currency add-on module.

Stop Payment Processing on page 197 - Describes how stop payment

BASE24-eps Transaction Originators

Point-of-Sale Device Channels

BASE24-eps Transaction Authorizers

Issuers and Acquirers

Hosts can play a prominent role in the transaction processing performed by

Transactions and Transaction Messages

Primary Identifiers: Message Type Identifier (MTI) and

product documentation unless specifically noted to the contrary.

can specify different processing parameters for each of their prefixes.

Local (On-Us) and Non-Local (Not-on-Us)

Local (On-Us) Prefixes

BASE24-eps Prefix Processing

Setting Up On-Us Prefixes

Defining On-Us Prefix Routing Parameters

26 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29

Setting Up Not-On-Us Prefixes

Payment Instruments, Cards, and

Defining Your Instrument Types

Associating Cards and Prefixes

Associating Accounts with Cards

How Cards are Identified in BASE24-eps

Primary Account Numbers (PANs)

The member number is a card sequence number used to identify an individual

Institution (Card Issuer)

Card Information Maintained by BASE24-eps

PIN Information/PIN Verification Value (PVV)

Last PIN Change Date

date is updated in the following situations:

Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29 | 33

Payment Instruments, Cards, and Accounts

Cardholder Address/Address Verification Settings

Primary and Secondary Cards

Refreshing Card Information

The Last Time the Card Information Was Refreshed

been updated by a refresh.

If an entire card prefix is configured to be used exclusively for ATM administrative

Setting Up Administrative Cards for Use with

38 | Sep-2009, Release 1.0 Version 09.2 Publication Number: ES-CS000-29

Setting Up Administrative Cards for Use with ATMs

Associating Account with Cards

The association, or tying, of accounts to cards within BASE24-eps is very flexible. A

Verifying Cardholders Have Access to an Appropriate Account

Enabling Cardholders to Access and Select From Multiple

Verifying Cardholders Have Sufficient Funds Available on Their

Identifying Accounts to BASE24-eps

Payment Instruments, Cards, and Accounts

Account Information Maintained by BASE24-eps in

Account Type Default

Account Information Maintained by BASE24-eps in

Positive Balance data source (Positive_Balance) for each account belonging to a

Account Currency Code

Refreshing Account Information

The Last Time the Positive Balance Information Was Refreshed

Account Balance Information