BASE24-eps Transaction Processing

© 2009 by ACI Worldwide, Inc. All rights reserved.

All information contained in this documentation, as well as the software described in it, is confidential and
proprietary to ACI Worldwide, Inc., or one of its subsidiaries, is subject to a license agreement, and may be
used or copied only in accordance with the terms of such license. Except as permitted by such license, no
part of this documentation may be reproduced, stored in a retrieval system, or transmitted in any form or by
electronic, mechanical, recording, or any other means, without the prior written permission of ACI Worldwide,
Inc., or one of its subsidiaries. ACI, ACI Worldwide, and the ACI product names used in this documentation
are trademarks or registered trademarks of ACI Worldwide, Inc., or one of its subsidiaries.

Other companies' trademarks, service marks, or registered trademarks and service marks are trademarks,
service marks, or registered trademarks and service marks of their respective companies.
 Contents

Contents
Preface.............................................................................................................................8
BASE24-eps Transaction Processing..........................................................................12
BASE24-eps Transaction Originators.....................................................................13
BASE24-eps Transaction 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

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

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
BASE24-eps Transaction 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

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

 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

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

Preface

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 BASE24-eps
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.

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

 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.

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

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 processing. 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.

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

 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-by-step
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).

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

BASE24-eps Transaction Processing

BASE24-eps Transaction 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.

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

 BASE24-eps Transaction 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.

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

BASE24-eps Transaction Processing

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.

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

 BASE24-eps Transaction Processing

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 cardholder’s 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.

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

BASE24-eps Transaction Processing

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.

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

 BASE24-eps Transaction Processing

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.

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

BASE24-eps Transaction Processing

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.

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

 BASE24-eps Transaction Processing

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 services—actions or services as defined by the BASE24-eps
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 and—in almost all
cases—processing 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.

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

BASE24-eps Transaction Processing

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 BASE24-eps
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 means—perhaps invoking a

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

 BASE24-eps Transaction Processing

custom component to determine the issuer based on the phone number used to initiate
the transaction.

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

Prefixes

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.

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

 Prefixes

What is a Prefix?
A prefix is a number—the 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 BASE24-eps
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.

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

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.

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

 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
Interchange Prefixes Prefixes Recognized by Unrecognized Prefixes
Algorithm

A prefix that is specifically A prefix that is specifically A prefix that is not A prefix that cannot be
defined to the BASE24-eps defined to the BASE24-eps specifically defined to identified by BASE24-eps by
in the Prefix data source. in an Interchange prefix data BASE24-eps, but can be any means available to it.
source. identified based on an
algorithm match.

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.

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

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

Processing Information Route 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.
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.

Issuer Information Instrument Type

The instrument type to be assumed for the transaction.
This value is moved to the Instrument Type TDE.

Destination Routing
The name of the Destination Routing Profile to use for the transaction.
Profile
This value is moved to the Issuer Routing Profile TDE.

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

 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.

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

Payment Instruments, Cards, and Accounts

Payment Instruments, Cards, and

Accounts

The topics here describe payment instruments, cards, and accounts and how they are
used in BASE24-eps processing.

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

 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.

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

Payment Instruments, Cards, and Accounts

Cards
Cards—that is plastic debit or credit cards—are 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 On-Us
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 prefix—if 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 16–19 digits.

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

 Payment Instruments, Cards, and Accounts

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
system—prior 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.

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

Payment Instruments, Cards, and Accounts

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 two-character
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 configure—at the prefix level—whether 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.

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

 Payment Instruments, Cards, and Accounts

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 00–15 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

0–15 Open
60 Denied - Lost
70 Denied - Stolen
80 Denied - Closed

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

Payment Instruments, Cards, and Accounts

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.

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

 Payment Instruments, Cards, and Accounts

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 cardholder’s 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 customer’s 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

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

Payment Instruments, Cards, and Accounts

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:
IS_PRI_EFF PRI_STAT SCND_STAT
IS_PRI_EXP PRI_STAT_SET SCND_STAT_SET
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.

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

 Payment Instruments, Cards, and Accounts

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 cardholder’s 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).

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

Payment Instruments, Cards, and Accounts

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.
Merchant ID The merchant ID associated with this administrative card. The administrative card can
only be used at POS terminals associated with this merchant.

PIN Information
The following information identifies the PIN information associated with the administrative
card.
Field Description

PVV This is not displayed, but can be changed on the Administrative Card Configuration
window. To change it, the value must be entered twice.
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.

Bad PIN Tries The number of bad PIN tries attempted for the administrative card since the bad PIN tries
was last reset.
Last Reset 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.

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

 Payment Instruments, Cards, and Accounts

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 Batch Close Administrative Day Close Administrative Shift Close 95 (Administrative Subtotal)
(92) (93) (94)
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)
09 (Purchase with Cash 01 (Withdrawal/Cash 20 (Return) A0 (Activation)
Back) Advance)
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 cards—the 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.

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

Payment Instruments, Cards, and Accounts

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 cardholder’s
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
different—and sometimes many different—accounts. 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 selection—also know as Open
Account Relationships (AOR). In these cases, BASE24-eps can be configured to return
all of a cardholder’s defined accounts to the transaction-originating device to allow the
cardholder to choose the account to be used for the transaction.

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

 Payment Instruments, Cards, and Accounts

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 card—assuming the originating device supports it—the 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 accounts—as 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 steps—using the
Positive Balance data source and account balance usages—to 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 11–16 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.

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

Payment Instruments, Cards, and Accounts

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

00 = Default/None 30 = Credit
10 = Savings 38 = Line of Credit
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.

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

 Payment Instruments, Cards, and Accounts

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.
Status values are user-defined for your system in the CommonCodesValues.properties
file. Values of 00–15 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.
Status Description

0–15 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.

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

Payment Instruments, Cards, and Accounts

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.
Status values are user-defined for your system in the CommonCodesValues.properties
file. Values of 00–15 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.
Status Description

0–15 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.

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

 Payment Instruments, Cards, and Accounts

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.

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

Payment Instruments, Cards, and Accounts

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.
Debit Account Balance Information

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.
Current The derived current available balance on the account. This balance is
not stored in the Positive Balance data source; it is computed using the
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.
Current 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
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.
Current 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
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.

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

 Payment Instruments, Cards, and Accounts

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 balances—which are maintained in the Positive Balance
data source—plus 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 processor’s 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

2 Purchase AVAIL_20090305 -$50 LEDG_20090305 -$50
3 Purchase AVAIL_20090306 -$20 LEDG_20090306 -$20
4 Deposit AVAIL_20090306 $200 LEDG_20090306 $800
5 Purchase AVAIL_20090307 -$40 LEDG_20090307 -$40
6 Purchase AVAIL_20090307 -$60 LEDG_20090307 -$60
7 Withdrawal AVAIL_20090308 -$100 LEDG_20090308 -$100
8 Purchase AVAIL_20090308 -$10 LEDG_20090308 -$10
9 Purchase AVAIL_20090308 -$300 LEDG_20090308 -$300

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

Payment Instruments, Cards, and Accounts

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.
Debit Account Balance Information

Available Balance Start of Day $4,000

Date March 6, 2009
Current $4,000 Start of Day

-$20 Usages 3–9

$200 (Usages 1-2, although active,
are not applied because their
-$40
date is prior to March 6.)
-$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 3–9

$800 (Usages 1-2, although active,
are not applied because their
-$40
date is prior to March 6.)
-$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 host-provided
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.

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

 Payment Instruments, Cards, and Accounts

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 host-provided
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 start-of-day
balances—resulting 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.

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

Payment Instruments, Cards, and Accounts

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).
Group Field Description Updated by
Script?

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
Payment Minimum Payment The minimum amount for a payment from the No
Amount account. This typically applies only to credit or
installment-type accounts on which debt is owed.
Next Payment Date The payment due date for a next payment from No
the account.
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

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

 Payment Instruments, Cards, and Accounts

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.

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

Transactions Allowed

Transactions Allowed

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

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

 Transactions Allowed

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:

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

Transactions Allowed

Settings Description

Admin Card Required

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.

On-Us
Specifies whether the acquirer allows the transaction and whether any geographic restrictions
apply. Values are as follows:
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
POS Channel Device Merchant Channel Processing Acquirer Transactions Profile
Configuration
ISO 93 Host ISO8583 (93) Host Interface Processing Acquirer Transactions
Configuration Allowed Profile
ISO 87 Host ISO8583 (87) Host Interface Processing Acquirer Transactions
Configuration Allowed Profile
Interchange Interchange Configuration UI Processing Acquirer Transactions
Allowed Profile

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

 Transactions Allowed

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.

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

Transactions Allowed

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:

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

 Transactions Allowed

Settings Description

Discard Reversals
Specifies whether reversals of this transaction type are to be discarded or forwarded to the
issuer.
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.

Settlement Impact
Specifies whether the transaction is to have 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.

On-Us 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
Not-On-Us
same; Not-On-Us values are intended for use when the acquirer and issuer institution are
not the same. Values are as follows:
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

ISO 93 Host ISO8583 (93) Host Interface Processing Issuer Transactions Allowed
Configuration Profile
ISO 87 Host ISO8583 (87) Host Interface Processing Issuer Transactions Allowed
Configuration Profile
Interchange Interchange Configuration UI Processing Issuer Transactions Allowed
Profile

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

Transactions Allowed

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 transaction’s
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 ON-US
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 not-on-us
transactions, the value in the Acquire Transaction Allowed TDE can override the not-on-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.
On-Us/Not-On-Us On-Us Not-On-Us
Value
(the Acquirer and Issuer Institutions are (the Acquirer and Issuer Institutions are not
the Same) the Same)

Disallowed The transaction is denied. The transaction is denied.

Allowed Internationally The transaction is allowed. 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
below for Allowed Nationally or Allowed in
State.

Allowed Nationally The transaction is allowed if the acquirer The transaction is allowed if the acquirer
institution and issuer institution countries are institution and issuer institution countries are
the same. Otherwise, the transaction is denied. 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.

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

 Transactions Allowed

On-Us/Not-On-Us On-Us Not-On-Us

Value
(the Acquirer and Issuer Institutions are (the Acquirer and Issuer Institutions are not
the Same) the Same)

Allowed in State The transaction is allowed if the acquirer The transaction is allowed if the acquirer
institution and issuer institution states are the institution and issuer institution states are the
same. Otherwise, the transaction is denied. same. Otherwise, the transaction is denied.

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.
Allowed Nationally The transaction is allowed if the acquirer institution and issuer institution countries
are the same. Otherwise, the transaction is denied.
Allowed in State The transaction is allowed if the acquirer institution and issuer institution states are
the same. Otherwise, the transaction is denied.

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.

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

Transaction Routing

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 routing—carried out by the File Update Router
component—that 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.

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

 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
itself—which must have been written specifically to use sequential routing—takes 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 entities—e.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.

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

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 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
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 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
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 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
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 Routing codes and business relationships are specific configuration parameters that
Relationships enable you to route transactions differently in cases where the acquirer and issuer have
a business relationship. Routing Codes and Business Relationships are described in
Defining Business Relationships and Routing Codes for Your System on page 100.
File Update Routing 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.
Sequential 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
scripts, but provides a great deal of added flexibility depending on how you want
transactions processed.

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

 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

1 Do you plan to authorize Identify each payment instrument Proceed to step 3.

transactions for card issuers on the BASE24-eps will need to recognize
system or route transactions for card for the card issuer.
issuers to a host?
If you plan to authorize transactions
on the system, identify the PAN
lengths and prefixes that will be
used with each payment instrument.
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.

2 Do you want to involve multiple Identify and modify the necessary No sequential routing is needed.
external entities in authorizing scripts to include sequential routing.
Proceed to step 3.
transactions for your card issuers
Use these modified scripts as
(i.e., do you want to perform
destinations in your destination
sequential routing )?
routing profiles.
Note: Modifying scripts to include
sequential routing takes
considerable planning and testing.
Proceed to step 3.

3 Does your system support acquiring Proceed to step 3a. Proceed to step 4.
terminals?
3a Are all transactions from all of your Create a single source routing Proceed to step 3b.
terminals to be routed the same profile and assign it to all of your
way? terminals.
Create a single destination routing
profile and use it for all transaction
routing from your terminals.
Proceed to step 4.

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

Transaction Routing

Step Question Yes No

3b Do you want any groups of terminals Create a source routing profile for No business relationship table
to be associated with specific each group of terminals to be needs to be set up for your
acquirers so that a business associated with a specific acquirer terminals.
relationship with an issuer can be and assign the profile to each
No routing codes need to be set
taken into account during routing? terminal in the group.
up.
Create a separate destination route
Specify only default routing codes
profile for any issuer to be included
of all asterisks in your destination
in a business relationship.
routing profile.
Create a business relationship table
Proceed to step 3c.
to associate the source routing
profiles assigned to your terminals
with the destination routing profiles
created for your issuers.
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.

3c Do you want certain groups of Create a source routing profile for Proceed to step 4.
terminals to be routed differently each group of terminals to be routed
from others (aside from any involved the same.
in possible business relationships)?
Create a separate destination route
profile for each group of terminals
to be routed the same.
Proceed to step 4.

4 Do you intend to send outbound Proceed to step 4a Proceed to step 5.

transactions to interchanges?
4a Does the interchange provide an Set up the Interchange Prefix File Proceed to step 4b.
interface prefix file that you plan to in BASE24-eps, and include the
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.

4b Are the interchange transactions Identify the algorithm and include it Proceed to step 4c.
identifiable using an algorithm? in the source routing profile
information.
Proceed to step 5.

4c Can you route to the interchange by Specify the interchange as a default Return to step 4, and verify that
default? in the source routing profile you know how you will route
information. outbound interchange transactions.
Proceed to step 5.

5 Do you intend to accept inbound Proceed to step 5a. End of steps.

transactions from interchanges?

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

 Transaction Routing

Step Question Yes No

5a Are all transactions from all your Create a single source routing Proceed to step 5b.
interchanges to be routed the same profile and assign it to all of your
way? interchange interfaces.
Create a single destination routing
profile and use it for all transaction
routing.
End of steps.

5b Do you want one interchange or any Create a source routing profile for No business relationship table
groups of interchanges to be each interchange to be associated needs to be set up for the
associated with specific acquirers, with a specific acquirer and assign interchanges.
so that a business relationship with the profile to each interchange
No routing codes need to be set
an issuer can be taken into acccount interface.
up for the interchanges. Specify
during routing?
Create a separate destination route only default routing codes of all
profile for any issuer to be included asterisks in your destination routing
in a business relationship. profile
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.

5c Do you want certain groups of Create a source routing profile for End of steps.
interchanges to be routed differently each interchange or group of
from others (aside from any involved interchanges whose transactions
in possible business relationships)? are to be routed the same.
Create a separate destination route
profile for each group of
interchanges to be routed the same.
End of steps.

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

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 it—that 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?
Profiles are named sets of parameter values and settings that can be assigned as a 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.

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

 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.

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

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

Destination Routing Route Code Account Type 1 Account Type 2 Cust Authentication
Profile Method

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

Destination Routing Profile 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.

Route Code 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.
Note: For issuer-to-acquirer routing, a route code of **************** (16 asterisks) is
always used.

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

 Transaction Routing

Transaction Table Field The Transaction Value Compared to the Table Field

Account Type 1 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 2 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.

Cust Authentication Method 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.

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 Destination Route Code Account Type 1 Account Type 2 Cust
Routing Profile Authentication
Method

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

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

Transaction Routing

Search Search Criteria

Hierarchy
Preference Destination Route Code Account Type 1 Account Type 2 Cust
Routing Profile Authentication
Method

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 **************** **************** ** ** *

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

 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

Destination Route Floor Set to the floor limit you want to use for the destination matrix. Transactions equal to or less
Limit than this amount are handled as under-the-floor transactions. Transactions greater than
this amount are handled as over-the-floor transactions.
Alternate Floor Limit Specifies the algorithm to use for alternate floor limit checking if alternate floor limit check
Algorithm 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 Place a check mark in this field if alternate floor limit checking is to be enabled.
Check Indicator
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.

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

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
displayed immediately to the right of the limit amount on the window.
Default Authorization Settings
Field Description

Floor Limit 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
would be taken. If the transaction amount is equal to or less than the $9.99, the Under Limit
Action is taken.

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

 Transaction Routing

Default Authorization Settings

Field Description

Over Limit Action 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
107 — Deny, refer to card issuer
912 — Deny, card issuer not available

Under 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
107 — Deny, refer to card issuer
912 — Deny, card issuer not available

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

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 sets—36 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

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

 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.

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

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:
Stage Component ID Name Required to Host Advice Only

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:
Stage Component ID Name Required to Host Advice Only

Authorization INTFVISA VISA Not Used

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

 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.
Both Set if you want advices sent to the specified destination for approved and denied
transactions.

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.
Stage Component ID Name Required to Host Advice Only

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 cardholder’s 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.

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

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:
Stage Component ID Name Required to Host Advice Only

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 selected—based 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

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

 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.

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

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 BASE24-eps
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.

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

 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:
Stage Component ID Name Required to Host Advice Only

Authorization <host ID> <host name> Not Used

If the alternative 1 destination is BASE24-eps, the destination might be configured as

follows.
Stage Component ID Name Required to Host Advice Only

Authorization IAUT PCBA_PUR Not Used

If the alternative 1 destination is an interchange, the destination might be configured as

follows.
Stage Component ID Name Required to Host Advice Only

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.

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

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

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

 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

Pre-Screen Validates Pre-Screen None Pre-Screen None

transaction fields
(e.g., expiration
dates, card track
data checks, etc.)
using scripts to
obtain better
interchange rates.
Authorization Routes to an Authorization Same as primary Authorization Same as primary
interchange but using a but using a
interface (e.g., different different
MasterCard, Visa, interchange interchange
etc.). processor. processor.
Advice 1 None Advice 1 None Advice 1 None
Advice 2 None Advice 2 None Advice 2 None
Impact 1 None Impact 1 None Impact 1 None
Impact 2 None Impact 2 None Impact 2 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
Primary Destination Alternative Destination 1 Alternative Destination 2

Pre-Screen Negative card Pre-Screen None Pre-Screen None

checks and PIN
verification using
scripts.

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

Transaction Routing

Destination Matrix
Primary Destination Alternative Destination 1 Alternative Destination 2

Authorization Routes to a card Authorization Stand-in Authorization None

issuer interface. authorization
using the positive
card authorization
method and
scripts.
Advice 1 None Advice 1 Route to the card Advice 1 None
issuer.
Advice 2 None Advice 2 None Advice 2 None
Impact 1 Updates usage Impact 1 None Impact 1 None
accumulation
limits.
Impact 2 None Impact 2 None Impact 2 None

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
Primary Destination Alternative Destination 1 Alternative Destination 2

Pre-Screen Validation against Pre-Screen None Pre-Screen None

positive card data
using scripts.
Authorization Routes to a host Authorization Stand-in Authorization None
interface. authorization
using the positive
card with balances
authorization
method and
scripts.
Advice 1 None Advice 1 Route to the host Advice 1 None
interface.
Advice 2 None Advice 2 None Advice 2 None
Impact 1 Updates balances Impact 1 None Impact 1 None
in stand-in
database on
BASE24-eps
system.
Impact 2 None Impact 2 None Impact 2 None

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

 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
Destination Route Code Account 1 Type Account 2 Type Cardholder Authentication
Routing Profile Method

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

Transaction Routing

Destination Matrix Worksheet

The following table can be used as a worksheet to represent one set of under-the-floor
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 destinations—entered 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
Advice 2 Approved - Denied - Both
Impact 1 Not used
Impact 2
Over the Pre-screen
Floor
Authorization
Advice 1 Approved - Denied - Both
Advice 2 Approved - Denied - Both
Impact 1 Not used
Impact 2

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

 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

Known (On-Us) On-Us Prefix Configuration window (Configure Issuer Information Destination Routing
Prefixes > Prefix > On-Us) Profile
Unknown (Not-On-Us) System Prefix Configuration window (Configure no tab Destination Routing
Prefixes > Prefix > Not-On-Us > System Prefix) Profile
Source Code Profiles Routing Configuration Destination/Source no tab Destination Routing
Relationship window (Routing> Profile
Destination/Source Relationship)

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

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?
Profiles are named sets of parameter values and settings that can be assigned as a 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.

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

 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.

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

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.

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

 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

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

Transaction Routing

Algorithm Method
The algorithm method involves comparing a prefix and the PAN length of a card number
to a specific algorithm—one 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.

Value 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
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

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

 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

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.
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.

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

Transaction Routing

Not-On-Us Processing Parameters

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.
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

Destination Routing Profile The name of the destination routing profile to use for the transaction. This value
is moved to the Issuer Route Profile TDE.
Issuer ID 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.

Limit Profile The name of the limit profile to be used for the transaction. This value is moved
to the Limit Profile TDE.
Note: This field is used in authorization, but not specifically for routing.

Issuer Surcharge Profile The name of the surcharge profile to be used for the transaction. This value is
moved to the Surcharge TDE.
Note: This field is used in authorization, but not specifically for routing.

Instrument Type The instrument type to be assumed for the transaction. This value is moved to
the Instrument Type TDE.
Route 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.
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.

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

 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 drop-down 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 Device ATM Channel Configuration window Processing Source Routing Profile
(Configure > ATM > ATM Channel >
ATM (Java) Channel ATM (Java) Channel Configuration Processing Source Routing Profile
Device window (Configure > ATM (Java) >
ATM Channel >
POS Channel Device Merchant Channel Configuration Processing Source Routing Profile
window (Configure > Merchant
Processing > Merchant Channel)
ISO 93 Host ISO8583 (93) Host Interface Processing Source Routing Profile
Configuration window (Configure >
Interface > Host > ISO8583 (93) Host
Interface)
ISO 87 Host BASE24 ISO8583 (87) Host Interface Processing Source Routing Profile
Configuration window (Configure >
Interface > Host > ISO 8583 (87) >
BASE24 ISO8583 (87) Host Interface)
Interchanges (Interchange-Specific) Interface Processing Source Routing Profile
Configuration window (Configure >
Interface > Network )

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

Transaction Routing

Prefix Routing Algorithms

Prefix routing algorithms are basic numerical comparisons that can be applied to not-on-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

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

 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.
Low Prefix High Prefix PAN Length

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.
Low Prefix High Prefix PAN Length

36 36 14

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

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.
Low Prefix High Prefix PAN Length

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.
Low Prefix High Prefix PAN Length

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.
Low Prefix High Prefix PAN Length

4 4 13
4 4 16

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

 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.

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

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-On-Us)
prefixes. Route type is carried in the Route Type TDE.
Prefix Window Tab Field

Known (On-Us) On-Us Prefix Configuration window (Configure Processing Route Type button
Prefixes > Prefix > On-Us) Information
Unknown (Not-On-Us) System Prefix Configuration window (Configure no tab Route Type
Prefixes > Prefix > Not-On-Us > System Prefix)

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

Dest_Pro_A Src_Pro_1 Withdrawal/Cash Advance WDL
(01)
Dest_Pro_A Src_Pro_1 Debit Adjustment (02) PUR

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

 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
Dest_Pro_A Src_Pro_1 Payment From and Payment PYMT
From/To (50)

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 transaction—where 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 profile—actually 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 ****************.

Search Search Criteria

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.

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

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 A’s truck drivers, for example, might be issued a card
to use specifically for purchasing fuel at Company B’s stations. Company B may have
previously agreed to discount fuel purchases whenever a Company A truck driver purchases
fuel at one of Company B’s 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.

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

 File Update Routing

File Update Routing

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. 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.

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

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

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

 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
scripts—changes are in the form of internally-generated file update transactions to be
routed to external entities.

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

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.

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

 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.

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

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 component—to handle any inbound file update (1300-series) messages it
receives.

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

 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

Destination Routing Profile 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.

Source Routing Profile 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.

File Type 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.

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

Component ID 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.

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

File Update Routing

Field Description

Interface Name 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.
Note: To be able to send file updates from the BASE24-eps system, the issuer interface
must support file action or file update messages.

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

 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
processing—can 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
authorized—causing the change to the Card data source).
TDE Description

PAN Set from the original transaction.

Local Date/Time Set from the original transaction.

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

File Update Routing

TDE Description

Card Sequence Number Set from the original transaction if the TDE is present. Otherwise, the TDE is created
and set to 000.
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.
Data Record 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).
Acquirer Route Profile Not set.Note: The fact that this TDE is not set and not taken from the original
transaction has routing implications.

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
receives—based 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.
Source Routing Profile Name 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.

File Type Uses Card data source as the file type

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

 Authorization, Prescreening, and Impacting

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.

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

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 cardholder’s usage information or perhaps changing
a cardholder’s 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).

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

 Authorization, Prescreening, and Impacting

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.

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

Authorization, Prescreening, and Impacting

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 card’s 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.

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

 Authorization, Prescreening, and Impacting

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 cardholder’s 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 card’s 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 cardholder’s 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 card’s track data or
the Card data source (Card).

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

Authorization, Prescreening, and Impacting

How Scripts are Identified

Scripts are divided into two basic categories: top-level scripts, also called business-level
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
<authorization type>_<txn>_<function>_<txn type>

<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.

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

 Authorization, Prescreening, and Impacting

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 sets—based 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

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

Authorization, Prescreening, and Impacting

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
PCBA_RTRN_IM1_RQ Merchandise Return Request
Impacting
PCBA_RTRN_IM1_RV Merchandise Return Reversal
Impacting
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

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

 Authorization, Prescreening, and Impacting

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.

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

Authorization, Prescreening, and Impacting

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 defined—as a set—in 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).

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

 Authorization, Prescreening, and Impacting

Field Description

Authorization Name 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.).
Message Type 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 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
Script Name 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 Enable Flag 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.
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

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

Authorization, Prescreening, and Impacting

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.

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

 Authorization, Prescreening, and Impacting

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 messages—even 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.

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

Authorization, Prescreening, and Impacting

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

Monitor Enable Flag 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.

Approval Threshold The respective thresholds to use for evaluating script approvals, referrals, and denials.
Referral Threshold Thresholds are percentages representing the outside boundaries that you do not want
the script results to cross. In other words, reaching these respective thresholds
Denial Threshold
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.
Note: Scripts that reach these thresholds are automatically disabled. You should
consider the threshold settings carefully.

Minimum Transaction Count The minimum number of transactions that must be processed by the script prior to
computing response percentages.

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

 Authorization, Prescreening, and Impacting

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.
Transactions The number of transactions approved, denied, and referred by the script for the selected
message type number.
Threshold The thresholds set for approvals, denials, and referrals.

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

Authorization, Prescreening, and Impacting

Field Description

Indicator 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.

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

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

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

 Authorization, Prescreening, and Impacting

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.

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

Authorization, Prescreening, and Impacting

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 re-routed,

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.

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

 Authorization, Prescreening, and Impacting

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)

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

Authorization, Prescreening, and Impacting

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).

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

 Authorization, Prescreening, and Impacting

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
itself—which must have been written specifically to use sequential routing—takes 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 entities—e.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.

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

Authorization, Prescreening, and Impacting

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.

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

 Authorization, Prescreening, and Impacting

2. Sets itself as the acquirer—setting 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.

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

Authorization, Prescreening, and Impacting

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

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

 Authorization, Prescreening, and Impacting

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

Sequential Route Information 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
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.

Sequential Route Script Context 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.

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

Authorization, Prescreening, and Impacting

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

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

 Authorization, Prescreening, and Impacting

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.
Default Authorization Settings
Field Description

Floor Limit 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
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
displayed immediately to the right of the limit amount on the window.

Over Limit Action 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
107 — Deny, refer to card issuer
912 — Deny, card issuer not available

Under 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
107 — Deny, refer to card issuer
912 — Deny, card issuer not available

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

Authorization, Prescreening, and Impacting

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.

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

 BASE24-eps Transaction Limits and Usages

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 define—and 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.

It’s 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.

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

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.

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

 BASE24-eps Transaction Limits and Usages

Limit Profiles - Where Limits are Defined

Limit profiles define a set of transaction limits that can be assigned to an institution’s 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?
Profiles are named sets of parameter values and settings that can be assigned as a 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 institution’s 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.

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

BASE24-eps Transaction Limits and Usages

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 institution’s cards and accounts.
Refer to Limit Profiles - Where Limits are Defined on page 143 for information about setting
up limit profiles.
Field Description

Limit Name 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 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.
Usage Period 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
Period Option with a Limit” for information on setting up the usage period.

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.

One Week, Two Weeks The day of the week on which accumulated amounts are
reset.
1st and 15th of each month Not applicable.
Every month, The accumulated amounts are reset in the applicable
month. Options are the 1st through the 28th.
Every 3 months,

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

 BASE24-eps Transaction Limits and Usages

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

Hours 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
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.
Daily, Fixed Number of For daily and fixed number of day usage period options, the usage period is based on the
Days institution cutover time plus the offset defined for the institution. For example, if the usage
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 hours—limits would apply to the 24-hour
period immediately after 11:00pm up to and including 11:00pm the next day.
An institution’s cutover time and offsets are configured in the Balance and Cutover End
Time and Usages Cutover Offset fields on the Institution Configuration window.

Weeks, Months, Annual, For week-, month-, and annual-based usage periods, usages always reset immediately
1st or 15th of the month after 12:01am. For example, if a limit was defined with a usage period of one month, and
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

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

BASE24-eps Transaction Limits and Usages

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

TTL_CASH_WDL The maximum amount of purchases and cash withdrawals allowed against noncredit
accounts.
OFFLINE_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.
TTL_CASH_ADV The maximum amount of cash advances allowed against credit accounts.
OFFLINE_CASH_ADV 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.
TTL_AGGR The maximum aggregate amount of cash disbursements allowed against credit and
noncredit accounts, plus purchases allowed against noncredit accounts.
OFFLINE_AGGR The maximum aggregate amount of cash disbursements allowed offline against
credit and noncredit accounts and purchases 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.
BAD_PIN_TRIES The number of times the cardholder has entered an incorrect PIN at terminals during
the current usage accumulation period.
OVER_DRAFT_LMT The amount available for overdraft on this account.
MIN_CASH_ADV The minimum cash advance amount allowed for transfer or payment transactions
that withdraw funds from a credit account.
CASH_ADV_INCR The standard increment amount used to determine the amount of transfer or payment
transactions that withdraw funds from a credit account.
ATM_PER_PRD_LMT The maximum number of times this card can be used to withdraw cash in a single
usage accumulation period.
ATM_TTL_CSH_WDL The maximum amount of cash withdrawals allowed against noncredit accounts.
ATM_OFF_CSH_WDL 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_TTL_CSH_ADV The maximum amount of cash advances allowed against credit accounts.
ATM_OFF_CSH_ADV 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
authorizing host is unavailable and the BASE24-eps product performs stand-in
authorization.
POS_TTL_PURCH The maximum amount of purchases and cash withdrawals allowed against credit
accounts.
POS_OFF_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_TTL_CSH_ADV The maximum amount of cash disbursements allowed against credit accounts.

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

 BASE24-eps Transaction Limits and Usages

Limit Name Description

POS_OFF_CSH_ADV 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_TTL_CSH_WDL The total amount of purchases and cash withdrawals made against noncredit
accounts.
POS_OFF_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
used when the authorizing host is unavailable and the BASE24-eps product performs
stand-in authorization.
POS_PER_PRD_LMT The maximum number of times a card with this card prefix can be used during a
single usage accumulation period.
POS_TTL_RFND_CR The total amount of refunds and replenishments made against credit and noncredit
accounts.
POS_OFF_RFND_CR The total amount of refunds and replenishments made offline against credit and
noncredit accounts.
POS_NUM_RFND The number of refunds and replenishments this cardholder has performed during
the current usage accumulation period.
POS_PER_RFND_LMT The number of refunds and replenishments this cardholder can perform during the
current usage accumulation period.
ATC_LMT_CHK The maximum number of transactions that can be performed since the last ATC
check (allows for offline authorization by device).
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.
# Limit Name Limit Limit Usage Period Period
Amount Count Option

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

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

BASE24-eps Transaction Limits and Usages

# Limit Name Limit Limit Usage Period Period

Amount Count Option

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.

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

 BASE24-eps Transaction Limits and Usages

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

Cards Card Management window (Customer Limits Limit Profile

Management > Card)
Account Positive Balance Management window (Customer Limits Limit Profile
Management > Positive Balance)
On-Us Card Prefixes On-Us Prefix Configuration window (Configure > Issuer Information Limit Profile
Prefix > On-Us)
Not-On-Us Card System Prefix Configuration window (Configure Not applicable Limit Profile
Prefixes > Prefix > Not-On-Us > System Prefix)

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

BASE24-eps Transaction Limits and Usages

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 way—by 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 account-specific
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.

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

 BASE24-eps Transaction Limits and Usages

Limit Name Limit Limit Count Usage Period Use Expiration Limit Expiration
Amount Period Option Date Date

Same as defined for a limit in the Limits Profile. Refer to Defining a Single Enable the limit to expire (refer to “Setting
Limit on page 144 for information about these fields. Up a Limit or Limit Override to Expire”).

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

Use Expiration Date 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.
Limit Expiration Date The date the corresponding limit will expire—only used if the Use Expiration Date
field contains a check mark.

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.

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

BASE24-eps Transaction Limits and Usages

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 created—that 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.

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

 BASE24-eps Transaction Limits and Usages

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 simplicity’s sake.
Usage Accumulation Exampe
Usages Usage Period Usage Period Usage Period Active
Usage
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.
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); there are now three
active usages, and the total active usage for the current period is $285.
4. A $50 transaction posts Feb-3; a usage is created for $50, with its expiration set to 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 1–3 are expired and no longer
used, there is now one active usage, and the total active usage for the current period
is $50.
5. A $100 transaction posts Feb-3; a usage is created for $100, with its expiration set to
Feb-5; there are now two active usages, and the total active usage for the current period
is $150.

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

BASE24-eps Transaction Limits and Usages

6. A $50 transaction posts Feb-4; a usage is created for $50, with its expiration set to
Feb-5; there are now three active usages, and the total active usage for the current
period is $200.
7. A $100 transaction posts Feb-4; a usage is created for $100, with its expiration set to
Feb-5; there are now four active usages, and the total active usage for the current period
is $300.
8. A $50 transaction posts Feb-5; a usage is created for $50, with its expiration set to Feb-7
(the beginning of the next usage period for the particular limit); since a new accumulation
period has started, the individual usages created in steps 4–7 are expired and no longer
used, there is one active usage, and the total active usage for the current period is $50.
9. A $50 transaction posts Feb-6; a usage is created for $50, with its expiration set to
Feb-7; there are now two active usages, and the total active usage for the current period
is $100.
10. A $25 transaction posts Feb-6; a usage is created for $25, with its expiration set 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.
Usage Instrument 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.
Card Number or Account The card or account number to which the usage applies, depending on the type of instrument
Number to which the usage applies.
Member Number or A card member number if the instrument type is a card; an account type value if the
Account Type instrument type is an account.

The following information is carried for each usage.

Usage-Specific Fields

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

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

 BASE24-eps Transaction Limits and Usages

Usage-Specific Fields

Next Begin Date and The date and time that the next usage period begins for the limit to which this usage
Time corresponds. This is the date and time the usage expires—after which it will no longer be
used for the associated usage.

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 start-of-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 customer’s 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.

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

BASE24-eps Transaction Limits and Usages

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 institution’s cutover time and offsets are configured in the Balance and Cutover End
Time and Usages Cutover Offset fields on the Institution Configuration window.

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

 BASE24-eps Transaction Limits and Usages

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.

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

BASE24-eps Transaction Limits and Usages

The following is a card view of the Usages Management window.

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

 BASE24-eps Transaction Limits and Usages

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.

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

BASE24-eps Transaction Limits and Usages

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).

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

 Preauthorization Holds

Preauthorization Holds

In BASE24-eps, a preauthorization hold is a single, logically discrete, expiration-dated 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 cardholder’s 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.

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

Preauthorization Holds

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 cardholder’s 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 automobile’s 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 cardholder’s 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.

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

 Preauthorization Holds

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 component—using scripts—approves 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.

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

Preauthorization Holds

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

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

 Preauthorization Holds

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.

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

Preauthorization Holds

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.

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

 Preauthorization Holds

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.

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

Preauthorization Holds

Active and Expired Preauthorization Holds

Preauthorization holds are either active or expired. Each hold carries an expiration date
and time—set when the hold is created—that 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 originator—or the number is set to 0—default values will
be used if they are available.

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

 Preauthorization Holds

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

Terminal Used if the terminal does Merchant Channel Processing Default

not provide the expiration Profile Configuration Preauthorization Hold
information.
Host/ Interchange Used if the host or <interface> Default Values Default Pre-Auth. Hold
interchange does not Configuration
provide the expiration window
information.
Prefix Used if the expiration On-Us Prefix Processing Default
information is not provided Information Preauthorization Hold
by the endpoint or by a
default setting.

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

Preauthorization Holds

What Information is Stored For Each

Preauthorization Hold
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 record-level
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.
Hold Instrument 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.
Card Number or Account The card or account number to which the preauthorization hold applies, depending on the
Number type of hold instrument.
Member Number or A card member number if the hold instrument type is a card; an account type value if the
Account Type hold instrument type is an account.

The following information is carried for each hold.

Hold-Specific Fields
Field Description

Hold Type 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 Amount The amount of the preauthorization hold. This could be a positive or negative value
depending on how your scripts handle the preauthorization hold.
Currency Code The currency code associated with the preauthorization hold amount.
Transaction ID 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
this ID. This value must be unique for each preauthorization hold associated with a specific
card or account—it is used as part of the matching criteria when updating/deleting a hold.
Hold Expiration The date and time (timestamp) that a pre-authorization hold transaction expires—after
which it will no longer be used.
Hold Local Transaction The local date and time (timestamp) the terminal sent in the preauthorization hold
Timestamp transaction.

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

 Preauthorization Holds

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

PA The transaction is an actual preauthorization—the 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 true—which
occurs when the acquirer has provided an Authorization Life Cycle Code (a hold interval and number).

AO The transaction is an authorization-only transaction—a follow-up completion message is not expected.

This value is set when the pre_auth_flag in the Preauthorization Hold TDE is set to false—which
occurs when the acquirer has not provided an Authorization Life Cycle Code (a hold interval and
number).

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.

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

Preauthorization Holds

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 processing—assuming 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 simplicity’s
sake.
Preauthorization Hold Example
Usages Usage Period Usage Period Usage Period Active
Usage
Feb-1 Feb-2 Feb-3 Feb-4 Feb-5 Feb-6

1 $215 Feb-3 $215

2 Hold1 $90 $305

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

 Preauthorization Holds

Preauthorization Hold Example

Usages Usage Period Usage Period Usage Period Active
Usage
Feb-1 Feb-2 Feb-3 Feb-4 Feb-5 Feb-6

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
for the current period is $355.
4. A $100 transaction posts Feb-3; a usage is created for $100 with its expiration set 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.
7. A $50 transaction posts Feb-4; a usage is created for $50 with its expiration set to Feb-5
(still the beginning of the next usage period for the particular limit); the total active usage
for the current period is $327.

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

Preauthorization Holds

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.
9. A $60 transaction posts Feb-5; a usage is created for $60 with its expiration set to Feb-7
(the beginning of the next usage period for the particular limit); since a new 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.
11. A $25 transaction posts Feb-6; a usage is created for $25 with its expiration set to Feb-7
(still the beginning of the next usage period for the particular limit); the total active usage
for the current period is $285.

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

 Preauthorization Holds

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 transaction’s 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 issuer’s 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 issuer-generated
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.

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

Preauthorization Holds

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

Upon receipt of the In an environment where both the authorization and completion sides of the transaction
completion are processed online, upon receipt of a completion (1220 message), your scripts would
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.

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

 Preauthorization Holds

Situation Description

Upon receipt of a reversal 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.
Note:
These types of reversals would typically carry a message reason code of 4000 to denote
a customer cancellation.

Based on the hold expiration All preauthorization holds have an expiration date and time associated with them that
date/time 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.

Through Match and Hold In some cases, the authorization stage of a transaction is handled online, but the
processing completion side of the transaction is handled through a backend settlement process.
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.
Through File Update Preauthorization hold delete records can be sent as file update transactions from an
processing ISO 93 host. Refer to File Update Routing on page 103 for information on how this
processing is done.

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.

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

Preauthorization Holds

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.

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

 Preauthorization Holds

The following is an card view of the Preauthorization Hold Management window.

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

Preauthorization Holds

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
online—i.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 files—to parse the file records
and sends them to the Integrated Server (IS) process as completion (1220) messages.

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

 Preauthorization Holds

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).

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

Preauthorization Holds

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

Both Card and Account Institution ID Derived from the PAN field in the Derived from DE 3 (Primary
data record (based on the PAN Account Number) during routing.
prefix).
Preauth Hold ID The Hold ID field in the data S-72, tag 10, subtag 01 (Hold ID)
record. unless the transaction is a Visa
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.
Member Number The Card Sequence Number field DE 23 - Card Sequence Number.
in the data record.
Account Account Number The Account Number field in the DE 102 - Account ID 1.
data record.
Account Type Derived from account type DE 72, tag 10, subtag 02
included in the Processing Code (Account type).
field in the data record.

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

 Check Processing

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/depositor’s 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
necessary—eliminating 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).

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

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).

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

 Check Processing

It’s 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.
A set of sample authorization scripts is delivered with BASE24-eps which provides 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.

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

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 Routing Transit number of the institution on which the check is drawn.
The routing transit number, also known as an institution’s 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.

Account Number Account Number on which the check is drawn.

Check Number The check number of the check involved in the transaction.
Check Amount 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.

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.
Formats Routing Transit Check Sequence Account Number (A)
Number (B) (C) Delimiters and Delimiters and
Delimiters and position position
position

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

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

 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 loaded—as received—by 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).

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

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).

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

 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 check’s 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

Account Type 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 Length The length of the account number for which the routing information in this record applies.
Valid values are 1–28.
This value is part of the primary record key.

Check Routing Transit Number The routing transit number to which the information in this record applies. Values are
right-justified and zero-filled.
This value is part of the primary record key.

Account Number Insert The position within the account number where one or more characters are to be inserted
Position in order to create a unique account number. Valid values are 0–28.
Account Number Insert Value The numeric characters that are to be inserted into the account number to make it
unique. Values are left-justified and blank-filled.

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

Check Processing

Field Description

Institution ID Number The institution’s 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
a transaction—it 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 institution’s 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).

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

 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.
# Institution Sent in the MICR data Replacement Value 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.

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

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

Preapproved Checks There may be situations in which you want to preapprove all checks from a specific
company or institution—perhaps for social security checks or payroll checks from a specific

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

 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.

Predeclined Checks If you wanted to predecline all checks from a specific company or institution—perhaps for
a company in financial trouble or for a firm whose assets have been frozen—you would
add a record to the Check Status data source with the company’s 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.

Registered Checks 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
cardholders who receive—and want to cash—checks 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 cardholder’s 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 institution’s cardholders.
The following is the pertinent information maintained in the Check Status data source for
a preapproved or predeclined check.

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

Check Processing

Field Description

Routing and Transit Number 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.
This value is part of the primary record key.

Checking Account 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.
This value is part of the primary record key.

Cardholder Primary Account A cardholder’s primary account number (PAN) or asterisks.

Number
If this record is for a registered check for a specific cardholder, this field must contain the
cardholder PAN.
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.
This value is part of the primary record key.

Member Number A cardholder’s member number or asterisks.

If this record is for a registered check for a specific cardholder, this field must contain the
cardholder’s 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.
This value is part of the primary record key.

Check Status 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
1 = Deposit only
2 = Deny all checks

Check Retention Status 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
1 = Retain all checks

Check Amount Limit The maximum acceptable check amount—expressed as a whole currency value—for
checks with this routing transit number and checking account number.
Checks above the specified limit are not authorized.
This field need not be set if the Check Status field indicates that the checks should be
declined.

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

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

 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.

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

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 limits—based 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

Check Base Flag Indicates transactions involving checks not 0 = No 0 = No

defined in the Check Status data source
1 = Yes 1 = Yes
should be included in Total Cash
Advance/Total Withdrawal usages and 2 = Use Prefix value
checked against Total Cash Advance/Total
Withdrawal limits.
Check Status Check Indicates transactions involving checks 0 = No 0 = No
Base Flag defined in the Check Status data source
1 = Yes 1 = Yes
should be included in Total Cash
Advance/Total Withdrawal usages and 2 = Use Prefix value
checked against Total Cash Advance/Total
Withdrawal limits.

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

 Stop Payment 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, BASE24-eps
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.

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

Stop Payment Processing

Active and Expired Stop Payments

Stop payments are either active or expired. Each stop payment carries an expiration date
and time—set when the stop payment is created—that 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 stops—active and expired—are 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

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

 Stop Payment Processing

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

Institution ID The institution ID of the financial institution owning the check type specified in the Check
Type field.
Check Type The type of check supported by the institution. Valid values are 01–99. 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 Description A description for the Check Type (e.g. Personal, Business, Government, etc.). The default
value is spaces.
Check Type Expiration A value specifying the expiration interval for the specified check type. Valid values are
Period as follows:
1 = Days (default)
2 = Weeks

Check Type Expiration The number of days or weeks to use for a default expiration period (days or weeks is
Period Value controlled by the Check Type Expiration Period field). For example: if this value is 150
and the Check Type Expiration Interval field is 1, the expiration period would be 150 days.
Valid values are 0–999. 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.

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

Stop Payment Processing

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).

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

 Stop Payment Processing

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 institution’s 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

Institution ID The Institution ID of the institution owning the account specified in the Account Number
field.
This value is part of the primary record key.

Account Number The account number of the customer's account at the institution that has a stop payment
on the check.
This value is part of the primary record key.

Account Type The type of customer account specified in the Account Number field.
This value is part of the primary record key.

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

Stop Payment Processing

Field Description

High Check Number 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.
This value is part of the primary record key.

Low 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.
This value is part of the primary record key.

Amount 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.

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.
Stop Payment Expiration The expiration date (YYYYMMDD) for the stop payment. This can either be set explicitly
Date or calculated based on default parameters (refer to Active and Expired Stop Payments on
page 198).
Check Type 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.
The default value is 00, which indicates no check type value (i.e. (none) on the UI).

Stop Payment Description 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.

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

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

 Stop Payment Processing

might set up two stop payments for ranges of checks where some checks are included in
both ranges.

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

Stop Payment Processing

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 transaction—set in the Institution Number field of the Institution
Configuration window (Configure > Institution). Typically, for card and check-based
processors, the Institution Number is the institution’s transit routing number.
BASE24-eps does provide for mapping the routing transit number carried in a check’s
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.

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

 Stop Payment Processing

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.
High/Low Check Number 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.

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
authorization scripts.

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

Card and Prefix Blocking

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.

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

 Card and Prefix Blocking

German (Sperren) Block Codes

Any two-position alphanumeric code can be used as block codes within BASE24-eps;
however, the following are standard block codes supported in the Sperren file (Germany’s
national negative file). The typical action is also provided for each.
Code Description Action

10 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.

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

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

Card and Prefix Blocking

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.
Preference PAN Card Expiration Date Description
Sequence
Number

1 Exact Match Exact Match Exact Match Blocks transactions on cards with the specified
PAN, card sequence number, and expiration date.
2 Exact Match Exact Match ******* Blocks transactions on cards with the specified
PAN and card sequence number and any
expiration date. Multiple expiration dates may exist
during a reissue period.
3 Exact Match *** Exact Match Blocks transactions on cards with the specified
PAN and any card sequence number for a specific
expiration date.
4 Exact Match *** ****** Blocks transactions on cards with the specified
PAN and any card sequence number and
expiration date.

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.

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

 Card and Prefix Blocking

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.
Preference PAN Length Prefix Expiration Description
Date

1 Exact Match Exact Match Exact Match Blocks transactions on all cards with the indicated
prefix and expiration date.
2 Exact Match Exact Match ******* Blocks transactions on all cards with the indicated
prefix.

Note: PAN length and prefix are always used in conjunction with one another to define
prefixes in the BASE24-eps system.

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

Card and Prefix Blocking

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

Primary Account Number The Primary Account Number (PAN) of the card for which the card block is intended.
This value is part of the primary record key.

Member 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).
This value is part of the primary record key.

Expiration Date 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).
This value is part of the primary record key.

Use Card Block Date/Time 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.
Effective 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.
Refresh Time Stamp 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.

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

 Card and Prefix Blocking

Field Description

Refresh ID An indicator of the refresh that created this record.

This field is informational only and is not set by the Sperren file refresh.

Block Code 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.

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

Card and Prefix Blocking

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

Prefix 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.
This value is part of the primary record key.

PAN Length The length of the Primary Account Numbers (PANs) to which the prefix block record applies.
This value is part of the primary record key.

Expiration Date 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).
This value is part of the primary record key.

Use Prefix Block A check mark that controls whether or not the Prefix Block date/time fields are to be used.
Date/Time A check mark means they are available for use. No check mark means they are not available
for 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.
Refresh Time Stamp 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 ID An indicator of the refresh that created this record.
This field is informational only and is not set by the Sperren file refresh.

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

 Card and Prefix Blocking

Field Description

Block Code 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.

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

German Routing and Authorization (Regional)

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 card’s track 3 data. The short BLZ consists of five
digits and are used in the card’s 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.

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

 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.

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

German Routing and Authorization (Regional)

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 BASE24-eps
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 applied—in addition to the standard (domestic) limits/usages.

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

 German Routing and Authorization (Regional)

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.

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

German Routing and Authorization (Regional)

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.

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

 German Routing and Authorization (Regional)

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

Bad PIN Counter 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).
German Authorization Carries the German Track 3 data. It is created by BASE24-eps German acquiring endpoints
Track 3 whenever the external message contains German track 3 data.
Message Class 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.
Next Online Date 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.
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.
Remaining Amount Can be set by your authorization scripts to provide to an acquiring device the available balance
Available amount remaining for a card. This TDE is typically used for ATM transactions declined by
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

EMV Request 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.
Network Original When German transaction processing codes are translated to BASE24-eps processing
Processing Code codes, the original German processing code is carried in the Network Original Processing
Code TDE.

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

German Routing and Authorization (Regional)

TDE Description

Track 2 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.

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

 German Routing and Authorization (Regional)

Configuring German Routing and

Authorization
Routing and authorizing transactions on German cards received through BASE24-eps
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 3-digit
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
xxx2xxxx 2 1 Private Bank Sector
xxx3xxxx 3
xxx4xxxx 4
xxx7xxxx 7
xxx8xxxx 8

xxx6xxxx 6 1 Co-operative Bank Sector

xxx9xxxx 9

You will also need to set the following values in each of your prefix records.
Field Tab Description

Next Online Date EMV Auth Options The number of days before a chip transaction will be required to be authorized
Period 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.

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

German Routing and Authorization (Regional)

Field Tab Description

PVV 2 Card Track The track 2 offset to the PIN offset 2, PIN verification value 2, or PIN verification
Information 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.

Setting Up Routing for Your On-Us Prefixes (BLZs)

Typically, you would set up separate destination routing profiles to handle your German
transactions—separate 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 BASE24-eps
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.

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

 German Routing and Authorization (Regional)

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
authorization scripts.
A set of sample authorization scripts is delivered with BASE24-eps which provides 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.

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

German Routing and Authorization (Regional)

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

German ISO Interface 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.
Sperren Refresh 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.

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

 BASE24-eps Transaction Flows

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.

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

BASE24-eps Transaction Flows

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

Callback Function A component self-registers a callback function (i.e., function pointer) with another
component. This method of activating functions allows the registering component to
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.
Direct 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.

This diagram shows how the msg_in and msg_out functions would be used between a
Message Delivery component and Acquirer Interface component.

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

 BASE24-eps Transaction Flows

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.

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

BASE24-eps Transaction Flows

• 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.

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

 BASE24-eps Transaction Flows

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 component’s 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.

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

BASE24-eps Transaction Flows

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.

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

 BASE24-eps Transaction Flows

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.

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

BASE24-eps Transaction Flows

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.

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

 BASE24-eps Transaction Flows

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).
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.

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

BASE24-eps Transaction Flows

4. The Acquirer Interface component activates the Router component to determine the
primary authorizer.
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 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.
11. The Journal component logs the transaction to the journal.
12. The Acquirer Interface component creates an external response message from the
TDEs and activates the Message Delivery component.
13. The Message Delivery component sends the response message to the Message
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 14–16).

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

 BASE24-eps Transaction Flows

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.
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.

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

BASE24-eps Transaction Flows

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.
12. The Message Delivery component receives a message from Message Manager.
13. The Message Delivery component activates the correct Acquirer Interface component
using data from the message header and component registration information.
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
Interface component for response processing.
19. The Acquirer Interface component activates the Journal component for 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.

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

 BASE24-eps Transaction Flows

22. The Message Delivery component sends the reversal acknowledgement message to
the message manager.

Sometime later, based on configuration, the SAF Manager process will invoke the Interface
Manager component to send the reversal acknowledgement message to the external
processor.

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

BASE24-eps Transaction Flows

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.

1. The Message Delivery component receives a request message from the Message
Manager.

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

 BASE24-eps Transaction Flows

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. 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 platform-specific
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
using data from the message header and component registration information.

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

BASE24-eps Transaction Flows

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 7–15 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.
17. The Acquirer Interface component activates the Journal component for transaction
logging.
18. The Journal component logs the transaction to the journal.
19. The Acquirer Interface component creates an external response message from the
TDEs and activates the Message Delivery component.
20. The Message Delivery component sends the response message to the message
manager.

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

 BASE24-eps Transaction Flows

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.
The following diagram depicts the component interactions required to process the 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.

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

BASE24-eps Transaction Flows

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 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.

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

 BASE24-eps Transaction Flows

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.
The following diagram depicts the component interactions required to process the messages.
These steps are continued from the External Authorization Request processing.

1. The Message Delivery component receives a response message from the Message
Manager.
2. The Message Delivery component activates the correct Issuer Interface component
using data from the message header and component registration information.
3. The Issuer Interface component activates the Context 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.
5. The Issuer Interface component activates the Timer component. The Timer component
cancels the expiration timer.

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

BASE24-eps Transaction Flows

6. The Issuer Interface component activates the Acquirer Interface component for response
processing.
7. The Acquirer Interface component activates the Journal component for transaction
logging.
8. The Journal component logs the transaction to the journal.
9. The Acquirer Interface component creates an external response message from TDEs
and configuration data and activates the Message Delivery component.
10. The Message Delivery component sends the response message to the message
manager.

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

 BASE24-eps Transaction Flows

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.

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. The
Acquirer Interface component accesses configuration tables and determines the
transaction is not allowed by the acquirer.
3. The Acquirer Interface component activates the Journal component for transaction
logging.
4. The Journal component logs the transaction to the journal.
5. The Acquirer Interface component creates an external response message from TDEs
and configuration data and activates the Message Delivery component.
6. The Message Delivery component sends the response message to the message
manager.

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

BASE24-eps Transaction Flows

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.

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 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.

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

 BASE24-eps Transaction Flows

7. The Acquirer Interface component activates the Journal component for transaction
logging.
8. The Journal component logs the transaction to the journal.
9. The Acquirer Interface component creates an external response message from TDEs
and configuration data and activates the Message Delivery component.
10. The Message Delivery component sends the response message to the message
manager.

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

BASE24-eps Transaction Flows

External Authorization, Prescreen

(Successful)
The following diagram depicts the component interactions involved in processing a
transaction where prescreening has been configured. In this case, the transaction passes
the prescreening checks.

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.

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

 BASE24-eps Transaction Flows

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
component for script execution.
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.
8. The Issuer Interface component activates the Timer component. The Timer component
requests the creation of an expiration timer.
9. The Issuer Interface component activates the Context component.
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.

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

BASE24-eps Transaction Flows

External Authorization, Prescreen (Not

Successful)
The following diagram depicts the component interactions involved in processing a
transaction where prescreening has been configured. In this case, the transaction does
not pass the prescreening checks.

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 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.

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

 BASE24-eps Transaction Flows

6. The Issuer Authorization component selects a prescreen script and activates the Script
component for script execution.
7. In this case, the prescreen fails, and 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 request message from TDEs
and configuration data and activates the Message Delivery component.
11. The Message Delivery component sends the response message to the message
manager.

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

BASE24-eps Transaction Flows

External Authorization, Response With

Impacting
The following diagram depicts the component interactions involved in processing a
transaction that gets routed to an issuer and is configured for impacting by BASE24-eps.

1. The Message Delivery component receives a response message from the Message
Manager.
2. The Message Delivery component activates the correct Issuer Interface component
using data from the message header and component registration information.
3. The Issuer Interface component activates the Context 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.
5. The Issuer Interface component activates the Timer component. The Timer component
cancels the expiration timer.
6. The Issuer Interface component activates the Acquirer Interface component for response
processing.

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

 BASE24-eps Transaction Flows

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.).
9. The Acquirer Interface component activates the Journal component for transaction
logging.
10. The Journal component logs the transaction to the journal.
11. The Acquirer Interface component creates an external response message from the
TDEs and activates the Message Delivery component.
12. The Message Delivery component sends the response message to the message
manager.

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

BASE24-eps Transaction Flows

External Authorization, Request

Timeout/Stand-in
The following diagram depicts the component interactions involved in processing a
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.

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

 BASE24-eps Transaction Flows

7. The Journal component logs the transaction to the journal.

8. The Issuer Interface activates the Router component for rerouting.
9. Router activates the Issuer Authorization component.
10. The Issuer Authorization component selects a financial request script and activates the
Script component for script execution.
11. Upon returning from the script, the Issuer Authorization component activates the Acquirer
Interface component for response processing.
12. The Acquirer Interface determines from the Advice 1 TDE in the transaction that an
advice is required and activates the Issuer Interface component.
13. The advice message is added to the store and forward (SAF) file.
14. The Acquirer Interface component activates the Journal component for transaction
logging.
15. The Journal component logs the transaction to the journal.
16. The Acquirer Interface component creates an external response message from the
TDEs and activates the Message Delivery component.
17. The Message Delivery component sends the response message to the message
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.

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

BASE24-eps Transaction Flows

External Authorization, Station Marked

Down/Stand-in
The following diagram depicts the component interactions involved in processing a
transaction where the primary destination issuer station is marked down and BASE24-eps
uses an alternate destination configured for stand-in authorization.

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 activates an Issuer Interface component named in the routing
configuration (e.g., INTFMDS).

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

 BASE24-eps Transaction Flows

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.
8. The Issuer Authorization component selects a financial request script and 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
Interface component for response processing.
10. The Acquirer Interface determines from the Advice 1 TDE in the transaction that an
advice is required and activates the Issuer Interface component.
11. The advice message is added to the store and forward (SAF) file.
12. The Acquirer Interface component activates the Journal component for transaction
logging.
13. The Journal component logs the transaction to the journal.
14. The Acquirer Interface component creates an external response message from TDEs
and configuration data and activates the Message Delivery component.
15. The Message Delivery component sends the response message to the message
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.

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

BASE24-eps Transaction Flows

External Authorization, Late (Approved)

Response
The following diagram depicts the component interactions involved in processing a
transaction where the issuer returns a late approval (after the transaction has already timed
out).

1. The Message Delivery component receives a response message from the Message
Manager.
2. The Message Delivery component activates the correct Issuer Interface component
using data from the message header and component registration information.
3. The Issuer Interface component activates the Context 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.

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

 BASE24-eps Transaction Flows

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.

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

BASE24-eps Transaction Flows

External Authorization, Late (Denied)

Response
The following diagram depicts the component interactions involved in processing a
transaction where the issuer returns a late denial response (after the transaction has
already timed out).

1. The Message Delivery component receives a response message from the Message
Manager.
2. The Message Delivery component activates the correct Issuer Interface component
using data from the message header and component registration information.
3. The Issuer Interface component activates the Context 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.”

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

 Primary Transaction Identifiers

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.

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

Primary Transaction Identifiers

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 BASE24-eps
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 Version Number 1 = ISO 8583:1993 standard

9 = Product-specific

2 Message Class
1 = Authorization
2 = Financial
3 = File action
4 = Reversal/chargeback
5 = Reconciliation
6 = Administrative
7 = Fee collection
8 = Network management

3 Message Function 0 = Request

1 = Request response
2 = Advice
3 = Advice response
4 = Notification (not supported by BASE24-eps)

4 Transaction Originator 0 = Acquirer

1 = Acquirer repeat
2 = Card issuer
3 = Card issuer repeat
4 = Other

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

 Primary Transaction Identifiers

Position Identifier Values

5 = Other repeat
6–9 = 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

1 Authorization 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 pre-authorization
transactions which are followed up by financial messages or are
non-financial in nature, such as balance inquiries.

2 Financial 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 cardholder’s account for billing or
posting.

3 File action 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.

4 Reversal 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.

4 Chargeback Messages associated with a chargeback transaction.

A chargeback transaction is initiated by a card issuer to partially or
completely nullify a previous financial transaction.
Chargeback transactions can be used if the original transaction had financial
impact on the cardholder’s net position, and the card issuer determines
that a customer dispute exists or that an error or a violation of rules has
been committed.

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

Primary Transaction Identifiers

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 acquirer—although the original transaction can be
re-presented by the acquirer.

5 Reconciliation Messages associated with a reconciliation transaction.

A reconciliation transaction provides financial totals between one acquirer
and one card issuer.

6 Administrative 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).

7 Fee collection 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.
Fee collection transactions have a financial impact and affect reconciliation
totals; however, they do not affect a cardholder account.

8 Network management 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:

• 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.

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

 Primary Transaction Identifiers

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

0 Request A message where the sender informs the receiver that a transaction is in
progress and a response is required to complete the activity.
1 Request response A message that carries the answer to a request.
2 Advice A message where the sender notifies the receiver of an activity that has
been taken, requiring no approval but requiring a response.
3 Advice response A message that carries the answer to an advice.
4 Notification A message where the sender notifies the receiver of an activity taken,
requiring no approval or response.

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

0 Acquirer An acquirer is the party in a message exchange representing the instrument

acceptor (the party who originally initiated the transaction).
1 Acquirer Repeat An acquirer message that is being repeated (sent again immediately) due
to a suspected or real failure of the initial message.
2 Card Issuer 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.
3 Card Issuer Repeat An issuer message that is being repeated (sent again immediately) due to
a suspected or real failure of the initial message.
4 Other 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.
5 Other Repeat 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.
6–9 Reserved Reserved for ISO use.

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

Primary Transaction Identifiers

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 pre-authorization
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-to-issuer
(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

1100 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
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.

1101 Authorization Request Repeat – Identical to an A-I mti_auth_rqst_repeat

Authorization Request (1100) message, except that it
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.
An Authorization Request Response (1110) message is
expected in return for the 1101 message, either approving
or denying the request.

1110 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.

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

 Primary Transaction Identifiers

MTI Description Dir Define Name

An Authorization Request Response (1110) message is

returned in response to an Authorization Request (1100)
or Authorization Request Repeat (1101) message to
approve or deny the request.

1120 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.
An Authorization Advice Response (1130) message is
expected in return for the 1120 message.

1121 Authorization Advice Repeat – Identical to an A-I mti_auth_advc_repeat

Authorization Advice (1120) message, except that it
denotes to the receiver that it is a possible duplicate
message.
An 1121 message is used when a response was expected
to an 1120 message but not received.
An Authorization Advice Response (1130) message is
expected in return for the 1121 message.

1130 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.

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

endpoint, it will either be dropped or handled as a
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
cardholder’s 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.
Table Key: The Dir column indicates the direction of the message, from-acquirer-to-issuer
(A-I) or from-issuer-to-acquirer (I-A). The Define Name column lists the define name used
for the MTIs by BASE24-eps.

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

Primary Transaction Identifiers

MTI Description Dir Define Name

1200 Financial Transaction Request – Requests approval for A-I mti_fncl_rqst

a transaction that, if approved, can be immediately applied
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.

1201 Financial Transaction Request Repeat – Identical to a A-I mti_fncl_rqst_repeat

Financial Transaction Request (1200) message, except
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.

1210 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.

1220 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.
A Financial Transaction Advice Response (1230)
message is expected in response for the 1220 message.

1221 Financial Transaction Advice Repeat – Identical to a A-I mti_fncl_advc_repeat

Financial Transaction Advice (1220) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1221 message is used when a response was expected
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.

1230 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.

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

 Primary Transaction Identifiers

MTI Description Dir Define Name

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

endpoint, it will either be dropped or handled as a
different message type. Financial Notification – Notifies
the receiver of a financial action taken that impacts the
instrument holder’s account.
A 1240 message is used to inform the instrument issuer
of a financial transaction that has completed at the point
of service.
No response message or text-level acknowledgement
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.
MTI Description Dir Define Name

1304 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
or denying the request.

1305 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.
A 1305 message is used when a response was expected
to a 1304 message but not received.
A File Action Request Response (1314) message is
expected in return for the 1305 message, either approving
or denying the request.

1314 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.
1324 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.

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

Primary Transaction Identifiers

MTI Description Dir Define Name

1325 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
receiver that it is a possible duplicate message.
A 1325 message is used when a response was expected
to a 1324 message but not received.
A File Action Advice Response (1334) message is
expected in response to the 1325 message.

1334 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.
1344 Not supported by BASE24-eps. If received at an S-R mti_file_act_ntfy
endpoint, it will either be dropped or handled as a
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.
Table Key: The Dir column indicates the direction of the message, from-acquirer-to-issuer
(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

1420 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.
A Reversal Advice Response (1430) message is expected
in response for the 1420 message.

1421 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.
A 1421 message is used when a response was expected
to a 1420 message but not received. If the original
transaction had financial impact, a reversal backs it out.
A Reversal Advice Response (1430) message is expected
in response for the 1421 message.

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

 Primary Transaction Identifiers

MTI Description Dir Define Name

1430 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.
1440 Not supported by BASE24-eps. If received at an I-A mti_rvsl_ntfy
endpoint, it will either be dropped or handled as a
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.
No response message or text-level acknowledgement
messages are expected in response to a 1440 message.

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 cardholder’s 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.
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-to-issuer
(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

1422 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.
A Chargeback Advice Response (1432) message is
expected in response to the 1422 message.

1423 Chargeback Advice Repeat – Identical to a Chargeback I-A mti_chrgbck_advc_repeat

Advice (1422) message, except that it denotes to the
receiver that it is a possible duplicate message.
A 1423 message is used when a response was expected
to a 1422 message but not received.

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

Primary Transaction Identifiers

MTI Description Dir Define Name

A Reversal Advice Response (1432) message is expected

in response to the 1423 message.

1432 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.
1442 Not supported by BASE24-eps. If received at an I-A mti_chrgbck_ntfy
endpoint, it will either be dropped or handled as a
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.
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-to-issuer
(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

1500 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.
1501 Acquirer Reconciliation Request Repeat – Identical to an A-I mti_acq_rcncl_rqst_repeat
Acquirer Reconciliation Request (1500) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1501 message is used when a response was expected
to a 1500 message but not received.

1502 Issuer Reconciliation Request – card issuer requests I-A mti_iss_rcncl_rqst

acquirer's totals (number and value) for the last
reconciliation period.
1503 Issuer Reconciliation Request Repeat – Identical to an I-A mti_iss_rcncl_rqst_repeat
Issuer Reconciliation Request (1502) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1503 message is used when a response was expected
to a 1502 message but not received.

1510 Acquirer Reconciliation Request Response – Carries card I-A mti_acq_rcncl_rqst_resp

issuer's totals (number and value) in response to a
reconciliation request message; sent in response to a
1500 or a 1501 message.
1512 Issuer Reconciliation Request Response – Carries A-I mti_iss_rcncl_rqst_resp
acquirer's totals (number and value) in response to a

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

 Primary Transaction Identifiers

MTI Description Dir Define Name

reconciliation request message; sent in response to a

1502 or a 1503 message.
1520 Acquirer Reconciliation Advice – Advises of acquirer's A-I mti_acq_rcncl_advc
totals (number and value) for the last reconciliation period.
1521 Acquirer Reconciliation Advice Repeat – Identical to an A-I mti_acq_rcncl_advc_repeat
Acquirer Reconciliation Advice (1520) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1521 message is used when a response was expected
to a 1520 message but not received.

1522 Issuer Reconciliation Advice – Advises of card issuer's I-A mti_iss_rcncl_advc

totals (number and value) for the last reconciliation period.
1523 Issuer Reconciliation Advice Repeat – Identical to an I-A mti_iss_rcncl_advc_repeat
Issuer Reconciliation Advice (1522) message, except that
it denotes to the receiver that it is a possible duplicate
message.
A 1523 message is used when a response was expected
to a 1522 message but not received.

1530 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.
1532 Issuer Reconciliation Advice Response – Carries the A-I mti_iss_rcncl_advc_resp
answer to a reconciliation advice message; sent in
response to a 1522 or a 1523 message.
1540 Not supported by BASE24-eps. If received at an A-I mti_acq_rcncl_ntfy
endpoint, it will either be dropped or handled as a
different message type. Acquirer Reconciliation
Notification – Notifies the card issuer of the acquirer's
totals (number and value) for the last reconciliation period.
There is no response message to an acquirer
reconciliation notification message.

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

endpoint, it will either be dropped or handled as a
different message type. Issuer Reconciliation
Notification – notifies the acquirer of the card issuer's
totals (number and value) for the last reconciliation period.

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.
Although not all are currently supported, they have been identified for future use.

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

Primary Transaction Identifiers

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.
MTI Description Dir Define Name

1604 Administrative Request – Requests information to support S-R mti_admin_rqst

the interchange network.
1605 Administrative Request Repeat – Identical to an S-R mti_admin_rqst_repeat
Administrative Request (1604) message, except that it
denotes to the receiver that it is a possible duplicate
message.
A 1605 message is used when a response was expected
to a 1604 message but not received.

1614 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.
1624 Administrative Advice – Advises of information to support S-R mti_admin_advc
the interchange network.
1625 Administrative Advice Repeat – Identical to an S-R mti_admin_advc_repeat
Administrative Advice (1624) message, except that it
denotes to the receiver that it is a possible duplicate
message.
A 1625 message is used when a response was expected
to a 1624 message but not received.

1634 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.
1644 Not supported by BASE24-eps. If received at an S-R mti_admin_ntfy
endpoint, it will either be dropped or handled as a
different message type. Administrative Notification –
Notifies of an administrative action.
No response message or text-level acknowledgement
messages are expected in response to a 1644 message.

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.

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

 Primary Transaction Identifiers

Table Key: The Dir column indicates the direction of the message, from-acquirer-to-issuer
(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

1720 Acquirer Fee Collection Advice – Advises of a service A-I mti_acq_fee_advc

fee due to be collected.
1721 Acquirer Fee Collection Advice Repeat – Identical to an A-I mti_acq_fee_advc_repeat
Acquirer Fee Collection Advice (1720) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1721 message is used when a response was expected
to a 1720 message but not received.

1730 Acquirer Fee Collection Advice Response – Carries the I-A mti_acq_fee_advc_resp
answer to an acquirer fee collection advice; sent in
response to a 1720 or a 1721 message.
1740 Acquirer Fee Collection Notification – Notifies of a service A-I mti_acq_fee_ntfy
fee due to be collected.
1722 Issuer Fee Collection Advice – Advises of a service fee I-A mti_iss_fee_advc
due to be collected.
1723 Issuer Fee Collection Advice Repeat – Identical to an I-A mti_iss_fee_advc_repeat
Issuer Fee Collection Advice (1722) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1723 message is used when a response was expected
to a 1722 message but not received.

1732 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.
1742 Issuer Fee Collection Notification – Notifies of a service I-A mti_iss_fee_ntfy
fee due to be collected

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.

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

Primary Transaction Identifiers

• 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.
Table Key: The Dir column indicates the direction of the message. Since there is no
delineated acquirer or issuer associated with the message, 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.
MTI Description Dir Define Name

1804 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.

1805 Network Management Request Repeat – Identical to a S-R mti_netwk_mgmt_rqst_repeat

Network Management Request (1804) message, except
that it denotes to the receiver that it is a possible duplicate
message.
An 1805 message is used when a response was expected
to an 1804 message but not received.
A Network Management Request Response (1814)
message is expected in response to the 1805 message.

1814 Network Management Request Response – Carries the R-S mti_netwk_mgmt_rqst_resp

answer to a network management request; sent in
response to a 1804 or a 1805 message.
1824 Network Management Advice – Advises of a network S-R mti_netwk_mgmt_advc
management activity.
1825 Network Management Advice Repeat – Identical to a S-R mti_netwk_mgmt_advc_repeat
Network Management Advice (1824) message, except
that it denotes to the receiver that it is a possible duplicate
message.
A 1825 message is used when a response was expected
to a 1824 message but not received.

1834 Network Management Advice Response – Carries the R-S mti_netwk_mgmt_advc_resp

answer to a network management advice; sent in
response to a 1824 or a 1825 message.
1844 Not supported by BASE24-eps. If received at an S-R mti_netwk_mgmt_ntfy
endpoint, it will either be dropped or handled as a
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.

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

 Primary Transaction Identifiers

BASE24-eps recognizes those product-specific 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, 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.
MTI Description Dir Define Name

9000 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.

9620 Administrative Fraud Report S-R mti_admin_fraud_rpt

9630 Administrative Fraud Report Response R-S mti_admin_fraud_rpt_resp

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

Primary Transaction Identifiers

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

200-series function codes are used in financial transaction (1200-series) messages.
Code Description Define Name

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

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

 Primary Transaction Identifiers

Code Description Define Name

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

300-series function codes are used in file action (1300-series) messages.
Code Description Define Name

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

400-series function codes are used in reversal and chargeback (1400-series) messages.
Code Description Define Name

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 Function Codes

500-series functions codes are used in reconciliation (1500-series) messages.

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

Primary Transaction Identifiers

Code Description Define Name

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 Function Codes

600-series functions codes are used in administrative (1600-series) messages.
Code Description Define Name

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

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

 Primary Transaction Identifiers

Code Description Define Name

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

800-series function codes are used in network management (1800-series) messages.
Code Description Define Name

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

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

Primary Transaction Identifiers

Code Description Define Name

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
887 Sign-off from recovery fnct_nmm_sys_saf_stop_sngl
Codes 887 and 889 should be used only for advice recovery.

888 Start SAF messages fnct_nmm_sys_saf_start_cmn

889 Sign-on to recovery. fnct_nmm_sys_saf_start_sngl
Codes 887 and 889 should be used only for advice recovery.

890 Enter SI mode fnct_nmm_enter_si_mode

891 Exit SI mode fnct_nmm_exit_si_mode
892 Online request for current day’s settlement totals fnct_nmm_cur_recon
893 Online request for previous day’s 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

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.
Code Description Define Name

940 Unsolicited message fnct_admin_unsol_msg

970 Multiple Account Select – More Account 1 data fnct_prvt_more_acct1
available

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

 Primary Transaction Identifiers

Code Description Define Name

971 Multiple Account Select – More Account 2 data fnct_prvt_more_acct2

available
972 Multiple Account Select – No more account fnct_prvt_more_none
data available
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
999 Issuer authentication failure or issuer script fnct_admin_script_auth_fail
results advice

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

Primary Transaction Identifiers

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 BASE24-eps

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.
Code Description Define Name

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

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

 Primary Transaction Identifiers

Code Description Define Name

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
4013 Reversal – unable to deliver message to point of mrc_rvsl_deliver_fail_pt_svc
service
4014 Reversal – suspected malfunction/card retained mrc_rvsl_mlfnct_suspect_keep
4015 Reversal – suspected malfunction/card returned mrc_rvsl_mlfnct_suspect_rtrn
4016 Reversal – suspected malfunction/track 3 not mrc_rvsl_mlfnct_suspect_trk3
updated

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

Primary Transaction Identifiers

Code Description Define Name

4017 Reversal – suspected malfunction/no cash dispensed mrc_rvsl_mlfnct_suspect_no_cash

4018 Reversal – timeout at taking money/no cash mrc_rvsl_timeout
dispensed
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
4364 Customer cancelled transaction (e.g., cancelled an mrc_cust_cancel
interactive message flow such as surcharging)
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

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

 Primary Transaction Identifiers

Code Description Define Name

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
4515 Chargeback – cardholder denies transaction was mrc_chrgbck_crdhldr_dny_txn_final
finalized
4516 Chargeback – non-fulfillment of request for mrc_chrgbck_nonfulfil_rqst_for_info
information
4517 Chargeback – non-fulfillment of request, illegible mrc_chrgbck_nonfulfil_illeg_cpy
copy
4518 Chargeback – cardholder does not recognize mrc_chrgbck_crdhldr_invld_merch_des
merchant description
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
4533 Chargeback – fraudulent transaction prior to mrc_chrgbck_fraud_txn_prior_dat
embossed valid date
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

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

Primary Transaction Identifiers

Code Description Define Name

4541 Chargeback – illegible data mrc_chrgbck_illeg_data

4542 Chargeback – transaction not received mrc_chrgbck_txn_not_recv
4543 Chargeback – duplicate processing by multiple mrc_chrgbck_dup_pro_mult_inst
institutions
4544 Chargeback – cancelling recurring transaction mrc_chrgbck_cncl_recur_txn
4545 Chargeback – currency conversion not allowed mrc_chrgbck_crncy_conv_not_alwd
4546 Chargeback – mail/telephone order transaction mrc_chrgbck_phn_ord_txn_unauth_pur
unauthorized purchaser
4547 Chargeback – card listed on warning bulletin mrc_chrgbck_crd_on_warn_bulltn
4548 Chargeback – cardholder dispute - transaction under mrc_chrgbck_crdhldr_dspt_txn_flr_lmt
merchant floor limit
4549 Chargeback – incorrect account number mrc_chrgbck_incorr_acct_num
4550 Chargeback – cardholder disputes card activated mrc_chrgbck_crdhldr_dspt_phn_txn
telephone transaction
4551 Chargeback – original transaction currency not mrc_chrgbck_orig_txn_crncy_not_prsn
provided
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

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

 Primary Transaction Identifiers

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:
Code Description Define Name

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
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

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

Primary Transaction Identifiers

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:
Code Description Define Name

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
A–I Reserved for ISO use
J–R Reserved for national use
S-Z 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:
Code Description Define Name

0 None term_crd_captr_cap_none
1 Capture term_crd_captr_cap_captr
2–4 Reserved for ISO use
5–7 Reserved for national use
8–9 Reserved for private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

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:

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

 Primary Transaction Identifiers

Code Description Define Name

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
6–7 Reserved for ISO use
8 Reserved for national use
9 Reserved for private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

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:
Code Description Define Name

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
6 Reserved for ISO use
7–8 Reserved for national use
9 Reserved for private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

Position 6 – Card Present

Position 6 contains a code indicating whether the card is present at the point of service.
Valid values are as follows:

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

Primary Transaction Identifiers

Code Description Define Name

0 Card not present crd_not_prsn

1 Card present crd_prsn
2–4 Reserved for ISO use
5–7 Reserved for national use
8–9 Reserved for private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

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:
Code Description Define Name

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
B–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

Position 8 – Cardholder Authentication Method

Position 8 contains a code indicating the method for verifying the cardholder identity. Valid
values are as follows:
Code Description Define Name

0 Unknown crd_input_cap_unknwn
1 Manual, no terminal crd_input_cap_manual

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

 Primary Transaction Identifiers

Code Description Define Name

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
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

Position 9 – Cardholder Authentication Entity

Position 9 contains a code indicating the entity verifying the cardholder identity. Valid values
are as follows:
Code Description Define Name

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
6 Reserved for ISO use
7 Reserved for national use
8–9 Reserved for private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

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:
Code Description Define Name

0 Unknown crd_data_output_cap_unknwn
1 None crd_data_output_cap_none

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

Primary Transaction Identifiers

Code Description Define Name

2 Magnetic stripe write crd_data_output_cap_mag_wrt

3 ICC crd_data_output_cap_icc
4–5 Reserved for ISO use
6–7 Reserved for National use
8–9 Reserved for Private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z 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.
Valid values are as follows:
Code Description Define Name

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
5–6 Reserved for ISO use
7–8 Reserved for national use
9 Reserved for private use
A–I Reserved for ISO use
J–R Reserved for national use
S-Z Reserved for private use

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.
Code Description Define Name

0 No PIN capture capability pin_captr_cap_none

1 Device PIN capture capability unknown pin_captr_cap_unknwn
2 Reserved for ISO use
3 Three characters pin_captr_cap_pin_lgth_3

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

 Primary Transaction Identifiers

Code Description Define Name

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
D–I Reserved for ISO use
J–R Reserved for national use
S PIN has been verified pin_captr_cap_vrfy
T–Z Reserved for private use

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

Primary Transaction Identifiers

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
04 Debit – Check Verification (funds available but not tc_db_chq_vrfy_d
guaranteed)
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

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

 Primary Transaction Identifiers

Tran Code Decription Define Name

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

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

Primary Transaction Identifiers

Tran Code Decription Define Name

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

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

 Primary Transaction Identifiers

Tran Code Decription Define Name

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
A6 Private Use – Online Personalization Terminal (OPT) tc_prvt_german_opt_d
transaction
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
U User defined. Can be any value that starts with a “U” tc_prvt_user_def_d
(U0-UZ). These can include log-only transactions.
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

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

Primary Transaction Identifiers

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

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

 Primary Transaction Identifiers

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.
Code Description Define Name

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
008–059 Reserved for ISO use
060–069 Reserved for national use
070–079 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

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

Primary Transaction Identifiers

Code Description Define Name

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.
Code Description Define Name

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 acquirer’s 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 issuer’s 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

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

 Primary Transaction Identifiers

Code Description Define Name

130–159 Reserved for ISO use

160–167 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.

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

Primary Transaction Identifiers

Code Description Define Name

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 acquirer’s 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
211–259 Reserved for ISO use
260–269 Reserved for customer-specific codes
270–279 Reserved for national use
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
286–299 Reserved for private use

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.
Code Description Define Name

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

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

 Primary Transaction Identifiers

Code Description Define Name

308 Duplicate, new record rejected ac_file_rec_dup_rjct

309 Unknown file ac_file_unkn
310–359 Reserved for ISO use
360–369 Reserved for customer-specific codes
370–379 Reserved for national use
380–399 Reserved for private use

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.
Code Description Define Name

400 Reversal accepted ac_rvsl_ok

401–459 Reserved for ISO use
460–469 Reserved for customer-specific codes
470–479 Reserved for national use
480 Reserved for private use
481 Reversal, original transaction not found ac_rvsl_orig_txn_not_fnd
482–483 Reserved for private use
484 Reversal, original transaction not approved ac_rvsl_orig_txn_not_apprv
485–499 Reserved for private use

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.
Code Description Define Name

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
560–569 Reserved for customer-specific codes

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

Primary Transaction Identifiers

Code Description Define Name

570–579 Reserved for national use

580–599 Reserved for private 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.
Code Description Define Name

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
606 Request cannot be fulfilled—required/requested documentation ac_admin_doc_unavail
is not available
607 Out of window ac_admin_out_of_window
608–659 Reserved for ISO use
660–669 Reserved for customer-specific codes
670–679 Reserved for national use
680–699 Reserved for private use

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.
Code Description Define Name

700 Accepted ac_fee_ok

701–750 Reserved for ISO use
751 Approved, exceeded limit ac_apprv_exceed_lmt
752–759 Reserved for ISO use
760–769 Reserved for customer-specific codes
770–779 Reserved for national use
780–799 Reserved for private use

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

 Primary Transaction Identifiers

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.
Code Description Define Name

800 Accepted ac_nmm_ok

801-859 Reserved for ISO use
860–869 Reserved for customer-specific codes
870–879 Reserved for national use
880–899 Reserved for private use

System Error Action Codes (900-999)

Action codes 900-999 are reserved for denoting system errors.
Code Description Define Name

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

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

Primary Transaction Identifiers

Code Description Define Name

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
924–929 Reserved for ISO use
930–939 Reserved for national use
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
951–983 Reserved for ISO use
984–991 Reserved for customer-specific codes
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
997–999 Reserved for private use

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

 Index

Index
A Business relationship (for purposes of routing)
defining business relationships and routing codes for
Account balances 46, 47 your system 100
deriving current account balances 47
Account types
German account types 218
C
Accounts 28, 40, 41, 42, 44, 45, 46, 47, 49, 50, 51 Card blocking
account activity 50 adding, viewing, updating, and deleting card blocks
account balance information 46 210
account information maintained by BASE24-eps in the block codes 206
Card data source 42 card block processing 208
account information maintained by BASE24-eps in the information stored for each card block record 210
Positive Balance data source 44 what is a card block 206
associating accounts with cards 40 Card-based processors 20
definition 40 card issuers 20
deriving current account balances 47 financial switches 20
field masking of account information 51 see also, non-card-based processors 20
identifying accounts to BASE24-eps 41 terminal acquirers 20
refresh scheduling as it relates to account balances Cards 28, 30, 31, 35, 36, 37, 51
49 administrative cards 37
refreshing account information 45 associating accounts with cards 30
Acquirers 15 associating cards and prefixes 30
Action codes card information maintained by BASE24-eps 31
action codes supported by BASE24-eps 301 configuring cards 30
definition 301 definition 30
Administrative cards 37, 38, 39 field masking of card information 51
setting up administrative cards for use with ATMs 39 how cards are identified in BASE24-eps 30
setting up administrative cards for use with primary and secondary cards 35
point-of-sale terminals 38 refreshing card information 36
Administrative messages (1600s) 273 Cash advances
Algorithm not-on-us prefix search method 92 setting increments 160
American Express setting minimums 160
prefix routing algorithm 97 Chargeback messages (1400s) 271
Auditing, transaction Check processing 183, 184, 188, 192, 193, 195, 196
disabling transaction auditing 72 check limits and usages 196
Authorization environments 17 check-based transactions supported by BASE24-eps
offline authorization 17 184
online authorization 17 check-specific processing features 184
online/offline authorization 17 defining preapproved checks to BASE24-eps 193
Authorization messages (1100s) 266 defining predeclined checks to BASE24-eps 193
enabling preapproved check processing 195
B enabling predeclined check processing 195
how MICR data is used in BASE24-eps check
Bankleitzahl processing 188
see BLZ support 214 preapproval options 192
Block codes 206 preapproved and predeclined checks 192
BLZ (Bankleitzahl) support 214 predecline options 192
BLZ mapping 224 routing check transactions 184
adding, viewing, updating, and deleting BLZ mapping what is a check 183
records 224
components that use BLZ mapping 224
information stored in BLZ mapping records 224
D
Default authorization 72
Destination routing profiles 66

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

Index

Destinations German routing and authorization (continued)

advice 77 track 2 and track 3 support 215
authorization 76 German transaction security 218
impact 77
pre-screen 75
Diners Club
H
prefix routing algorithm 97 Hosts 16
Discover
prefix routing algorithm 98
I
F Issuers 15
Fee collection messages (1700s) 274
File action messages (1300s) 269 L
File update routing 60, 103, 105, 106, 107, 111, 112
file update processing 105 Limit profiles 143, 144
file update transactions resulting from authorization defining a single limit 144
changes to the Card data source 111 Limits and usages
file update types 103 German domestic and international limits and usages.
processing preauthorization hold deletions from a host 216
107
routing Card updates to an external entity 112 M
routing file update transactions to external entities 107
updating BASE24-eps data sources through file MasterCard
updates 106 prefix routing algorithm 98
what are file updates 103 Match and Hold processing 180, 182
what is file update routing 103 what it takes to match on a hold 182
Financial transaction messages (1200s) 267 with the Batch Authorization process 180
Floor limits 71, 78 Message reason codes
From account types supported by BASE24-eps 300 definition 284
Functions codes message reason codes supported by BASE24-eps
definition 278 284
function codes supported by BASE24-eps 278 Message Type Identifiers (MTIs) 262, 266, 267, 269, 270,
271, 272, 273, 274, 275, 276
administrative messages (1600s) 273
G authorization messages (1100s) 266
GeldKarte support 216 chargeback messages (1400s) 271
German routing and authorization 214, 215, 216, 217, fee collection messages (1700s) 274
218, 219, 221, 222, 224 file action messages (1300s) 269
account types 218 financial transaction messages (1200s) 267
bad PIN usage 217 network management messages (1800s) 275
BLZ (Bankleitzahl) support 214 product-specific messages (9000s) 276
BLZ mapping 224 reconciliation messages (1500s) 272
configuring German routing and authorization 221 reversal messages (1400s) 270
domestic and international limits and usages. 216 structure 262
GeldKarte support 216 supported by BASE24-eps 266
German-specific transaction data (TDEs) 219 MICR data
next online date for chip cards 217 definition 186
prefix routing requirements 215 how MICR data is carried in BASE24-eps 187
processing codes 217 how MICR data is used in BASE24-eps check
returning available balances to acquiring devices 217 processing 188
SECCOS 6 card support 216 information contained in MICR data 186
setting up BLZ mapping 222 manipulating MICR data 189
setting up card blocking 222 MICR data formats 186
setting up on-us prefixes 221 MTIs
setting up prefix blocking 222 see Message Type Identifiers (MTIs) 262
setting up routing for not-on-us prefixes and GeldKarte
transactions 222 N
setting up routing for your on-us prefixes 222
Sperren file support 215 Network management messages (1800s) 275

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

 Index

Non-card-based processors 20 Primary cards

see Cards 35
Processing codes
O definition 296
Offline authorization 17 from and to account types supported by BASE24-eps
Online authorization 17 300
Online/offline authorization 17 transaction codes supported by BASE24-eps 296
Product-specific messages (9000s) 276
profiles
P issuer transactions allowed profiles 56
Profiles
Payment instruments 28, 29 acquirer transactions allowed profiles 53
definition 29 transaction limit profiles 143
types 29
Point of service data
definition 289 R
point of service data supported by BASE24-eps 289
Preapproved checks Reconciliation messages (1500s) 272
definition 192 Refresh
Preauthorization hold transactions 162 refresh scheduling as it relates to account balances
Preauthorization holds 49
active and expired preauthorization holds 168 refreshing account information 45
adding, deleting, and modifying preauthorization holds refreshing card information 36
from the ACI Desktop 178 Reversal messages (1400s) 270
adding, deleting, and modifying preauthorization holds Routing codes 99, 100
from your authorization scripts 176 defining business relationships and routing codes for
controlling preauthorization hold processing at the your system 100
prefix level 172 enabling and disabling the use of routing codes at the
definition 161 prefix level 99
how preauthorization holds affect processing 172
information stored for each preauthorization hold 170 S
Interac-specific processing 175
preauthorization hold types 171 Scripting
processing example 172 preauthorization holds 167
scripting 167 script selection by the Router component 81
what happens to expired preauthorization holds 171 SECCOS 6 card support 216
Predeclined checks Secondary cards
definition 192 see Cards 35
Prefix blocking Source routing profiles 88, 95
adding, viewing, updating, and deleting prefix blocks tying source routing profiles to acquirers 95
212 Stand-in authorization
block codes 206 setting up stand-in authorization 80
information stored for each prefix block record 212 Stop payment processing 197, 198, 201, 202, 204
prefix block processing 208 active and expired stop payments 198
what is a prefix block 206 adding, modifying, and removing stop payments 201
Prefix routing algorithms 96, 97, 98 check number requirements 202
American Express algorithm 97 how stop payments affect processing 204
configuring prefix routing algorithms 96 information stored for each stop payment 201
Diners Club algorithm 97 what is a stop payment 197
Discover algorithm 98 Stop payments
MasterCard algorithm 98 active and expired stop payments 198
standard prefix routing algorithms 97 adding, modifying, and removing stop payments 201
Visa algorithm 98 definition 197
Prefixes 22, 23, 24, 25, 26, 27 how stop payments affect processing 204
BASE24-eps prefix processing 25 information stored for each stop payment 201
local (on-us) prefixes 24
non-local (not-on-us) prefixes 24
setting up not-on-us prefixes 27
T
setting up on-us prefixes 26 To account types supported by BASE24-eps 300
what is a prefix? 23 Transaction authorizers
BASE24-eps 14

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

Index

Transaction authorizers (continued) Transaction originators (continued)

hosts 14 point-of-sale device channels 13
interchanges 14 Transaction routing 60, 61, 62, 66, 67, 68, 71, 72, 74, 75,
Transaction codes 76, 77, 78, 79, 80, 81, 82, 83, 85, 87, 88, 89, 90,
supported by BASE24-eps 296 91, 92, 93, 94, 95, 96, 99, 103
Transaction Data Elements (TDEs) 261 acquirer-to-issuer routing 60
Transaction flows 225, 226, 231, 233, 235, 238, 241, 243, advice destinations 77
245, 246, 248, 250, 252, 254, 256, 258, 260 authorization destinations 76
external authorization request 241 default processing 72
external authorization response 243 destination routing profiles
external authorization, late (approved) response 258 destination matrix 74
external authorization, late (denied) response 260 general information 71
external authorization, prescreen (not successful) 250 name and description 67
external authorization, prescreen (successful) 248 transaction table 68
external authorization, request timeout, with stand-in transaction table selection hierarchy 68
254 disabling transaction auditing 72
external authorization, response with impacting 252 file update routing 60, 103
external authorization, transaction not allowed by the floor limits 71, 78
acquirer 245 how alternative destinations for authorization affect
external authorization, transaction not allowed by the other transaction stages 79
issuer 246 impact destinations 77
external authorization,station marked down, with issuer-to-acquirer routing 60
stand-in 256 key concepts 62
how BASE24-eps components interact within the not-on-us prefix search example 93
Integrated Server process 226 not-on-us prefix search methods
internal authorization request/response sequential algorithm 92
authorization to external destinations 238 default 93
internal authorization request/response with advice interchange prefix search 91
233 not-on-us processing parameters 94
internal authorization request/response with reversal pre-screen destinations 75
235 prefix routing algorithms 96
internal authorization request/response, card initiated primary and alternate destination sets 79
231 routing codes 99
Transaction identifier script selection 81
point of service data 289 sequential routing 61
Transaction identifiers 261, 262, 278, 284, 296, 301 setting up stand-in authorization 80
action codes 301 source routing profiles
functions codes 278 name and description 89
message reason codes 284 not-on-us prefix selection table 90
Message Type Identifiers (MTIs) 262 tying source routing profiles to acquirers 95
processing codes 296 TDEs in which destination information is carried. 82
Transaction identifiers (primary) 19 things to think about before setting up transaction
Transaction limit profiles routing 62
assigning limit profiles to cards, accounts, and prefixes tying destination routing profiles to prefixes 87
149 typical destination routing profiles 83
Transaction limits 141, 143, 144, 145, 147, 149, 150, 196 using the not-on-us prefix selection table to recognize
assigning limit profiles to cards, accounts, and prefixes a not-on-us prefix 90
149 worksheets 85
check limits and usages 196 Transaction usages 141, 145
defining a single limit 144 predefined limits and usages 145
defining the usage period associated with a limit 144 time the usage periods start and end 145
examples 147 Transactions 19
limit profiles 143 Transactions allowed
predefined limits and usages 145 acquirer transactions allowed profiles
setting limits for cards and accounts 150 assigning acquirer transactions allowed profiles
time the usage periods start and end 145 to acquirer endpoints 54
Transaction messages 19 how acquirer transactions allowed profiles are
Transaction originators 13 used in processing 55
ATM channels 13 setting up an acquirer transactions allowed profile
hosts 13 53
interchanges 13 definition 52

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

 Index

Transactions allowed (continued) Usages (continued)

issuer transactions allowed profiles information stored for each usage 154
assigning issuer transactions allowed profiles to system-defined usages for deriving current balances
endpoints 57 155
how issuer transactions allowed profiles are used tracking transaction usage 152
in processing 58 usage accumulation example 153
setting up an issuer transactions allowed profile usage naming 155
56 viewing and deleting active usages 157
what happens to expired usages 159
U
V
Usages
active and expired usages 152 Visa
definition 152 prefix routing algorithm 98

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