BASE24 BIC ISO Interface Manual
BASE24 BIC ISO Interface Manual
BASE24®
Release 6.0 v10
August 2014
ACI Worldwide
Offices in principal cities throughout the world
www.aciworldwide.com
Americas +1 402 390 7600
Asia Pacific +65 6334 4843
Europe, Middle East,
Africa +44 (0) 1923 816393
What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
BIC ISO Interface Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Co-Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Issuer and Acquirer Co-Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Issuer and Acquirer Co-Network Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Internal Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
BIC ISO External Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Store-and-Forward Function. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Multiple Product Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Message Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
BIC ISO Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Supported Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Supported BASE24-atm Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Supported BASE24-pos Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
File Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Transaction Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
Supported Message Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
Interchange Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
Address Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
Self-Service Banking (SSB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
Dynamic Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1
The following table highlights the major changes that have been made in the most recent update to
the BASE24 BIC ISO Interface Manual. The first column of the table lists the sections and
appendixes in which major changes have been made. The second column of the table describes the
major changes for each section or appendix. These changes update the manual to release 6.0,
version 10.
May 2014
Section/ Major Changes
Appendix
2 Updates the valid values for the following LCONF params to 0–7: POS-ACQ-
ILF-MATCH, POS-ACQ-ILF-MATCH-CNP, POS-ISS-ILF-MATCH, POS-ISS-
ILF-MATCH-CNP. (Salesforce #01532389)
5 Updates the “Logging to the ILF” and “Enhanced ILF Matching” topics to indicate
that POS reversals can be logged up to 7 days after the original transaction took
place. (Salesforce #01532389)
May 2013
Section/ Major Changes
Appendix
5 Updates the description of the “Logging to the ILF” process and adds the new
“Enhanced ILF Matching” description.
November 2011
Section/ Major Changes
Appendix
December 2009
Section/ Major Changes
Appendix
1 Updates the “Enhanced EMV Response Code Mapping” topic to refer to the
BASE24 BIC ISO Standards Manual for a complete listing of response codes.
A Adds the following LCONF params to list of assigns and params read during
initialization: ATM-LN-CUTOVER, POS-LN-CUTOVER, POS-B24-TO-POS-
ACCT-TYP-SUPPRS, PRE-VERIFIED-PIN-PAD-CHAR, and PSEUDO-3DES-
CBC-MAC-TYPE.
The BASE24 BIC ISO Interface Manual describes the BIC ISO Interface
process, which is used to establish a communications link between a BASE24
network and a co-network. This co-network may be another BASE24 network,
but may also be any transaction processing network which conforms to the
standards set forth in the BASE24 BIC ISO Standards Manual for message
formats and processing.
This manual describes the BIC ISO Interface process, which uses the International
Organization for Standardization (ISO) 8583:1987 message formats.
Audience
This manual is intended as a reference for those persons responsible for the
interface between BASE24 and a co-network. It provides a comprehensive
description of all the functions performed by the BIC ISO Interface process
involving incoming and outgoing message traffic for both acquirer and issuer
processors.
Prerequisites
The structure and content of the BIC external message is patterned after the
BASE24 external message. The BASE24 external message is similar in nature to
the standard external message developed by the International Organization for
Standardization (ISO)—described in the ISO 8583 (1987) standard, Bank Card
Originated Messages—Interchange Message Specifications—Content for
Financial Transactions. Because of the similarity between the BASE24 external
message and the ISO standard, familiarity with the above document, commonly
referred to as “ISO 8583,” is recommended.
However, there are several differences between the BASE24 external message and
the ISO standard that may be of interest to readers familiar with the ISO standards.
These differences are described throughout this manual. The standards for
message formats and processing to which BIC conforms are set forth in the
BASE24 BIC ISO Standards Manual.
Additional Documentation
The BASE24 documentation set is arranged so that each BASE24 manual presents
a topic or group of related topics in detail. When one BASE24 manual presents a
topic that has already been covered in detail in another BASE24 manual, the topic
is summarized and the reader is directed to the other manual for additional
information. Information has been arranged in this manner to be more efficient for
readers that do not need the additional detail and at the same time provide the
source for readers that require the additional information. This manual contains
references to the following BASE24 publications:
?
The BASE24 Logical Network Configuration File Manual discusses in
detail the assigns and params used in configuring the BIC ISO Interface
process.
?
The BASE24 BIC ISO Standards Manual discusses in detail the
specifications for the BIC ISO External Message. It includes a general
overview of the message, explanations of the external message types used by
the BIC ISO Interface process, a set of message defaults for each BASE24
product, a description of each data element contained in the message, and
descriptions of the message flows between BASE24 and a co-network.
?
The BASE24 External Message Manual discusses in detail the BASE24
external message on which the BIC ISO Interface process is based.
?
The BASE24 Event Message Reference Manual discusses in detail how to
electronically access event message documentation generated by the BIC ISO
Interface process.
?
The BASE24 Text Command Reference Manual describes each text
command sent using the network control facility that can be issued for the
BIC ISO Interface process. This manual includes the corresponding
command syntax used with each command.
?
The BASE24 Base Files Maintenance Manual documents the BASE24 data
entry screens for the External Message File (EMF), the Key File (KEYF), the
Key 6 File (KEY6), the Enhanced Interchange Configuration File (ICFE), the
Acquirer Processing Code File (APCF), the Issuer Processing Code File
(IPCF), the Card Prefix File (CPF), and the Surcharge File (SURF). The
ICFE is used to configure the parameters described in this manual for the BIC
ISO Interface process. The APCF and IPCF are used to configure the
transactions allowed to be sent and received by the BIC ISO Interface
process. The CPF and SURF are used to configure surcharging. The EMF
and the KEYF or KEY6 are used to configure the messages and parameters
described in this manual.
?
The BASE24 Files and Record Structures Reference Manual documents
how to access the file and record structures for the Interchange Log File
(ILF).
?
The BASE24-pos Address Verification Manual documents the BASE24-pos
Address Verification add-on product.
?
The BASE24 Tokens Manual documents token processing. It includes
information on how to configure the tokens that get logged to the Interchange
Log File (ILF), sent in BIC ISO messages, and extracted from the ILF.
?
The BASE24-atm Transaction Processing Manual documents the
BASE24-atm standard internal message format (STM).
?
The BASE24-atm Files Maintenance Manual documents the data entry
screens for the BASE24-atm Terminal Data files (ATD), which is used to link
the SURF with a card prefix or terminal group.
?
The BASE24-pos Transaction Processing Manual documents the
BASE24-pos standard internal message format (PSTM).
?
The device-specific BASE24-atm Self-Service Banking manuals document
the BASE24-atm Self-Service Banking add-on product.
?
The BASE24 Transaction Security Manual discusses in detail Personal
Identification Numbers (PINs), message authentication codes (MACs), and
dynamic key management used to set up transaction security for the BIC ISO
Interface process.
?
The NET24-XPNET Network Control Command Reference Manual
contains details on process, station, line, and device attributes used in
configuring the BIC ISO Interface process.
?
The NET24 Performance Monitoring Manual provides detail on the NET24
Performance Monitoring subsystem.
Software Release
This manual documents standard processing 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. The customer is
responsible for identifying and noting these changes.
Manual Summary
The BASE24 BIC ISO Interface Manual is divided into the following sections:
“Conventions Used in this Manual” follows this preface and describes notation
and documentation conventions necessary to understand the information in the
manual.
Section 5, “Transaction Handling,” describes how the BIC ISO Interface process
handles various types of transactions.
Publication Identification
Three entries appearing at the bottom of each page uniquely identify this BASE24
publication. The publication number (for example, SW-DS004-01 for the
BASE24 BIC ISO Interface Manual) appears on every page to assist readers in
identifying the manual from which a page of information was printed. The
publication date (for example, May-2014 for May, 2014) indicates the issue of the
manual. The software release information (for example, R6.0v10 for release 6.0,
version 10) specifies the software that the manual describes. This information
matches the document information on the copyright page of the manual.
This section explains how field descriptions are documented in this manual.
Field Descriptions
Each field appearing on a file maintenance screen is listed by name and then
described. Field descriptions briefly summarize the contents, purpose, and
permissible values, as shown in the following example taken from the Enhanced
Interchange Configuration File (ICFE).
Example
ACQ STAND-IN AUTH — A flag indicating whether the BASE24 system, when
acting as the acquirer, is allowed to stand in on behalf of the co-network to
authorize transactions. This field is verified at logon to make sure the co-network
is set up correctly. Valid values are as follows:
Y = Stand-in is allowed
N = Stand-in is not allowed
Explanation
Item Description
Example Illustrates a possible entry for the field to further clarify the
value or values that can be entered.
Item Description
Field Length Specifies the size of the field and the type of characters that
can be entered. This length refers to the field and valid
values for the file maintenance screen, not the field in the
DDLs. Possible values are alphabetic, alphanumeric,
hexadecimal, and numeric. The term alphanumeric
includes all alphabetic, numeric, and special characters that
can be entered from a keyboard without using a control
sequence. The term hexadecimal includes all numbers and
the letters A through F.
When a field value cannot be modified by the operator, the
field length is System protected.
Default Value Specifies the value that is automatically placed in the field
when the screen is first displayed or when the F8 key is
pressed to clear the screen.
Data Name Provides the DDL name associated with the field appearing
on the screen. Data names are included in the
documentation to assist in communicating screen and field
issues to your technical staff. Note that screen data is not
always stored in the BASE24 database as it appears on the
screen or as it is described in the field description. If you
need information on how screen data is actually stored,
consult the DDLs.
This section introduces the BASE24 Interchange (BIC) ISO Interface and provides
an overview of BIC ISO Interface process functionality. It also identifies the
BASE24 files used by the BIC ISO Interface process, and the message types
supported.
?
Facilitates message exchange between the BASE24 system and the co-
network.
When the BASE24 system receives a transaction from the co-network, the
BIC ISO Interface translates the message into the appropriate internal
message format and sends the message to a BASE24 Authorization process.
When the BASE24 system receives a transaction for the co-network to
authorize, the BIC ISO Interface process translates the message from the
internal message format to the external message format and forwards the
message to the co-network.
?
Provides store-and-forward capabilities.
When the link between the BASE24 system and the co-network is down, the
BIC ISO Interface process stores certain messages intended for the co-
network in its Store-and-Forward File (SAF). When the link is restored, these
messages are retrieved from the file and sent to the co-network.
?
Facilitates settlement between the BASE24 system and the co-network.
The BIC ISO Interface process produces a set of interchange reports to assist
in reconciling transactions between the BASE24 system and the co-network.
These reports allow the BASE24 participants to reconcile the settlement
positions of the co-network and the BASE24 system. The BIC ISO Interface
process also handles online exchange of reconciliation totals between the
BASE24 system and the co-network.
?
Manages communications between the BASE24 system and the co-network.
The BIC ISO Interface process sends and receives network management
messages to determine the status of the link between the BASE24 system and
the co-network. Network management messages include logon, logoff, echo
test, dynamic key management, and cutover messages.
Internal External
Messages Messages
The BIC ISO Interface process supports communication with co-networks using
the International Organization for Standardization (ISO) message format.
Co-Networks
The BASE24 Interchange, or BIC, connects a BASE24-atm or BASE24-pos
network with a co-network—another BASE24 network or another transaction
processing network that conforms to BIC ISO standards. These standards include
sending and accepting the appropriate form of the BIC ISO external message and
providing the proper message flows to effect processing.
BIC serves as a link between two networks. It allows a cardholder of one network
to initiate a transaction at a terminal belonging to the other network. Although the
co-network can be another BASE24 network, for the purposes of this manual the
co-network is considered to be unknown.
Stations
Stations provide the means by which communications takes place between the
BASE24 system and a co-network. All messages sent to a co-network are actually
sent to the stations defined for the co-network. Likewise, all messages received
from a co-network are actually received from stations.
Stations and their lines must be defined to the XPNET system. Stations and lines
are tied to their respective co-networks through the Enhanced Interchange
Configuration File (ICFE). At least one station is required for each co-network,
and a maximum of 20 stations are allowed per co-network. For information on
defining stations and lines to BASE24, refer to the NET24-XPNET Network
Control Command Reference Manual.
Note: All protocol-level functions between BASE24 and the stations are actually
handled by the XPNET process using HP’s NonStop communications control
software. The BIC ISO Interface process sends and receives messages using the
XPNET process. The XPNET process maintains communications links with the
stations according to the protocols under which the stations are defined.
BASE24-atm
Device Handler
Automated
Teller Machines
BASE24-pos
XX Device Handler/
Router/
Authorization
Point-of-Sale
Terminals
PP
NN
EE BASE24-atm
TT Authorization
The co-network
receives transactions
forwarded by BASE24
for authorization.
BIC ISO
Interface
Co-network
BASE24-pos
Device Handler/
Router/
Authorization
The co-network
forwards transactions
XX
from its own terminal
network to BASE24
for authorization.
PP BASE24-atm
NN Authorization
EE
Co-network
TT
BIC ISO
Interface
Automated Point-of-Sale
Teller Machines Terminals
Note: Because of their general position in the transaction path, issuer co-networks
are also referred to as back-end co-networks and acquirer hosts are also referred to
as front-end co-networks.
Co-networks can also function on behalf of both card issuers (or account owners)
and transaction acquirers, as would be the case when an institution issues cards and
supports its own network of ATM or POS devices.
These options are controlled using the ACQUIRER and ISSUER fields on ICFE
screen 3.
For more information on the STM or PSTM, see the BASE24-atm or BASE24-pos
transaction processing manual.
Store-and-Forward Function
A store-and-forward function is incorporated into the BIC ISO Interface process to
collect transaction messages during periods when a co-network is unavailable.
Message Processing
Due to the variances in processing that must occur in handling messages for
different products, the BIC ISO Interface processes messages differently based on
the message type and product ID for the message. For more information on how
messages flow back and forth between the co-network and the BIC ISO Interface
process, please refer to the following sections, based on the type of message:
?
Network management message flows, including those for dynamic key
management, are documented in section 3.
?
Store-and-forward message flows are documented in section 4.
?
BASE24 transaction flows are documented in section 5.
?
Cutover message flows are documented in section 6.
When a message from the co-network is received by the BIC ISO Interface
process, it is translated from the external message into the appropriate internal
message format. The internal message is then sent to the appropriate BASE24
Authorization process. When the message has been processed, the authorizing
process sends an internal response back to the BIC ISO Interface process. Using
information from the internal message, the BIC ISO Interface process formats an
external response message and sends it back to the co-network.
The following diagram illustrates this incoming message flow. Processing steps
are provided following the illustration.
33 2 1
44 5 66
The following diagram illustrates this outgoing message flow. Processing steps
are provided following the illustration
11 22 33
66 5 4
The following diagram illustrates this outgoing message flow. Processing steps
are provided following the illustration.
1 22
33
BASE24 BIC ISO
Co-
Co-network
Authorization Interface
Process Process
4 5 66
A BIC ISO network can be configured to require that all transactions be routed
through a single member of the BIC ISO network. The example illustrated below
has a primary BASE24 system configured as the focal point for exchanging
transactions within the entire BIC ISO network. In this type of arrangement, the
primary BASE24 system has a separate BIC ISO Interface process for each co-
network to which it is linked. Co-networks A, B, and C are other BASE24 systems
and would each require one BIC ISO Interface process. Co-network D is a non-
BASE24 system and would require a proprietary interface that conforms to BIC
ISO standards for message formats and processing.
Co-network A Co-network B
Co-network C Co-network D
A BIC ISO network can also be configured to allow for certain transactions to be
exchanged directly between members of the BIC ISO network. An example of this
is illustrated below. In this illustration, the configuration consists of a primary
BASE24 system and three co-networks, two of which are other BASE24 systems.
The primary BASE24 system can exchange transactions with each of the three co-
networks; co-networks B and C, which are also BASE24 systems, are configured
to exchange transactions directly with each other. Co-network A is a non-BASE24
system. In this type of arrangement, the primary BASE24 network would require
three BIC ISO Interface processes, co-networks B and C would each require two
BIC ISO Interface processes, and co-network A would require a proprietary
interface that conforms to BIC ISO standards for message formats and processing.
BASE24 Co-network B
BIC ISO BIC ISO BIC ISO BIC ISO BIC ISO
Interface Interface Interface Interface Interface
Supported Transactions
The BIC ISO Interface process provides support for both BASE24-atm and
BASE24-pos transactions.
Different transaction sets are supported by the BIC ISO Interface process
depending on the BASE24 products installed.
?
Balance inquiries
?
Deposits
?
Deposits with cash back
?
EMV PIN unblock
?
Log-only transactions
?
Messages to financial institutions
?
Payments enclosed
?
Payments from/to
?
PIN change
?
Split deposits
?
Transfers
?
Withdrawals
?
Balance inquiries
?
Card verifications
?
Cash advances
?
Cash advance adjustments
?
Check guarantee
?
Check verification
?
Mail or telephone orders
?
Merchandise returns
?
Merchandise return adjustments
?
Normal purchases
?
Preauthorizations
?
Preauthorization completions
?
Purchase adjustments
?
Purchases with cash back
?
Purchase with cash back adjustments
File Usage
The BIC ISO Interface process uses a number of BASE24 files. These files can be
divided into control files and transaction files, and are identified below.
Control Files
Control files contain configuration information and parameters that determine how
the BIC ISO Interface process operates. The control files that contain
configuration information for the BIC ISO Interface process include the following:
?
Acquirer Processing Code File (APCF)
?
Check Authorization Routing File (CART)
?
Enhanced Interchange Configuration File (ICFE)
?
External Message File (EMF)
?
Extract Configuration File (ECF)
?
Issuer Processing Code File (IPCF)
?
Key File (KEYF) or Key 6 File (KEY6)
?
Network Environment File (NEF)
?
Logical Network Configuration File (LCONF)
?
Token File (TKN)
For information on how these files are used to configure the BIC ISO Interface
process, see section 2.
Transaction Files
Transaction files are used to store information about individual transactions
processed through the BIC ISO Interface process. The transaction files used by the
BIC ISO Interface process include the following:
?
Interchange Log File (ILF)
?
Interchange Totals File (ITF)
?
Store-and-Forward File (SAF)
For information on what the ILF contains when it is used by the BIC ISO Interface
process, refer to the ILF Data Definition Libraries (DDLs). For information on the
SAF, refer to the SAF DDLs. The ILF and SAF DDLs can be accessed using the
DDLDOC utility. For information on the DDLDOC utility, refer to the BASE24
Files and Record Structures Reference Manual. For information on the ITF,
refer to section 6.
Interchange Reporting
The BIC ISO Interface process produces two reports: the SETL01-BIS and the
STAT09-BIC. The purpose of these reports is to facilitate settlement between the
BASE24 system and the co-network. For information on these reports, refer to
section 6.
Address Verification
The BIC ISO Interface process supports BASE24-pos address verification
processing. Merchants can use address information supplied by the customer to
verify whether the customer is entitled to use an account when it is not possible to
physically examine the card and the customer’s signature.
Address verification data is added to data element P-63 as a token and is passed
along with any other tokens to the co-network in the BIC ISO external message for
BASE24-pos message types. This token contains address information and
verification results. The presence of data element P-63 in the BIC ISO external
message is determined by the setting of this data element in the External Message
File (EMF). In order for P-63 to be included in the BIC ISO external message, it
must be defined as mandatory or conditional in the EMF.
Split deposit transactions allow BASE24-atm customers to deposit money into two
separate accounts by entering a single transaction. The form of deposit can consist
of an envelope or a check. The following example describes how a split deposit
transaction works. A customer selects a split deposit transaction from an ATM.
The customer is then prompted to enter the split deposit type. The split deposit
type identifies the two account types into which the deposit is to be made. These
accounts can be two checking accounts, two savings accounts, or one checking
account and one savings account. Next, the customer is prompted to enter the full
deposit amount followed by the deposit amount for the first account. BASE24
then computes the amount deposited into the second account. A transaction
request is initiated for the deposit and the request is sent to the authorizing entity.
Data element P-54 can be included in the BIC ISO external message for
BASE24-atm message types. This data element contains the deposit credit amount
established for split deposit transactions. The presence of P-54 in the BIC ISO
external message is determined by the setting of this data element in the EMF. In
order for this data element to be included in the BIC ISO external message, it must
be defined as mandatory or conditional in the EMF.
For more information on the split deposit transaction and on the BASE24-atm self-
service banking add-on product in general, refer to the device-specific
BASE24-atm SSB manual.
Fields in the Key File (KEYF) or Key 6 File (KEY6) and the External Message
File (EMF) must be set to specific values to allow for dynamic key management.
See section 2 for a listing of KEYF, KEY6 and EMF settings.
For more information about dynamic key management, refer to the BASE24
Transaction Security Manual.
Five-day Settlement
The BIC ISO Interface process can support 5-day settlement. An interface using
5-day settlement creates an ILF for Monday when it cuts over on Friday instead of
creating one for Saturday. All transactions taking place after this cutover until the
next cutover on Monday are logged to Monday’s ILF. The totals calculations are
also processed this way.
The cutover date can also be configured to allow for holiday dates. These dates are
treated like weekends: when the interface cuts over on the day before the holiday,
it creates the ILF for the day after the holiday. For example, when the interface
cuts over on December 31, it creates an ILF for January 2. All transactions taking
place on January 1 and January 2 are logged to the ILF for January 2.
Note: Because the ILF for Monday will contain transactions for Saturday, Sunday,
and Monday, the file extents for the ILF should be large enough to allow for an
extra two days’ volume.
$ £
BASE24 BIC ISO
U.K.
Authorization Interface
$ £ Co-network
Process Process
The U.K. co-network sends the transaction to the BIC ISO Interface process in
pounds. The BIC ISO Interface process converts the amount to dollars and
forwards the transaction to the BASE24 Authorization process. The Authorization
process formats a response message and sends it to the BIC ISO Interface process.
The BIC ISO interface converts the currency to pounds and sends the response to
the co-network. The BIC ISO Interface process logs the transaction to its ILF in
dollars.
Amounts passed in the internal message within BASE24 are expressed in the local
currency. Amounts logged to the Interchange Totals File (ITF) are expressed in
the settlement currency. Amounts in the SETL01 and STAT09 reports are
expressed in both the local and settlement currencies.
The BIC ISO Interface process does not perform currency conversion if the
BASE24 system supports Multiple Currency processing, as described in the
“Multiple Currency Support” topic.
Configuration Considerations
Currency conversion requires changes to the following:
?
COBNAMES file on BAxxSRC subvolume, where xx is the number of the
current release. The CURRENCY-CODE-TABLE needs to contain shared
settlement currency code information. Instructions for adding a currency
code are included in that file.
?
Enhanced Interchange Configuration File (ICFE). The CURRENCY CODE
field on ICFE screen 2 needs to be set to the settlement currency. The
NETWORK MANAGEMENT MESSAGE ENABLED field on ICFE screen
3 needs to be set to a value of Y so the settlement currency code can be
exchanged in logon messages. Two fields on ICFE screen 12, BUY RATE
and SELL RATE, need to contain values for issuers and acquirers. For more
information about the ICFE, see section 2.
?
External Message File (EMF). Previously unused fields in the Standard
External Message (SEM) message need to be turned on. See section 2 for
more information about configuring the EMF.
?
Logical Network Configuration File (LCONF). See section 2 for more
information about LCONF parameters.
?
The BIC ISO Interface process uses the CURRENCY-CODE param to
indicate the local currency code.
?
The BIC ISO Interface process uses the ENHANCED-CRNCY-CONV
param to determine whether the amounts in fields P-54, S-95, or S-123
are specified in a single currency (either the transaction currency or the
settlement currency), or in two currencies (both the transaction currency
and the settlement currency). The BIC ISO Interface process on an
acquirer system checks this param whenever it converts the transaction
amounts to the settlement currency. The BIC ISO Interface process on an
issuer system checks this param whenever it receives a request or advice
message that contains the Settlement Currency Code (data element P-
50). The presence of this data element indicates the co-network has
converted the transaction amounts to the settlement currency.
Note: The amount fields in the SEM are limited to 12 digits. Network managers
should keep this in mind when choosing the shared settlement currency. The
working fields used in the calculation of the amount to be sent can accommodate
19 digits, but when the amount is converted to ASCII, more than 12 digits will
cause the transaction formatting to fail. To prevent this possibility, some test
amounts of varying sizes, including representative maximum amounts, should be
calculated on paper before modifying the ICFE conversion rates.
When the Original Currency 6.0 token is added, data is moved from the BIC ISO
external message to the token, as shown in the following table. The Original
Currency Release 6.0 token can then be logged to the Interchange Log File (ILF),
Transaction Log File (TLF), and POS Transaction Log File (PTLF) for use in
settlement processing with the co-network.
TRAN-AMT AMT-1
ADD-AMTS.B24-DEF.AMT AMT-2
CRNCY-CDE CRNCY-CDE
SETL-CONV-RAT CONV-RATE
CONV-DAT CONV-DAT
The BIC ISO Interface process allows multiple currency transactions to pass
unimpeded to and from the co-network.
Customers who use the Multiple Currency add-on products should not configure
the currency conversion processing described in the “Currency Conversion” topic.
If a BASE24 system is set up with a Multiple Currency add-on product and
transactions flow through the BASE24 system in more than one transaction
currency, all BIC ISO Interface processes within that system should be configured
to support the Multiple Currency add-on products.
Note: When using a Multiple Currency add-on product, the BIC ISO Interface
process bypasses Interchange Totals File (ITF) processing because it is not
possible to accumulate totals in different currencies without currency conversion.
You can configure Multiple Currency add-on product support by setting the
MULTI CURRENCY field on Enhanced Interchange Configuration File (ICFE)
screen 3 to a value of Y. The value Y indicates that transactions can pass through
the BIC ISO Interface process in more than one currency, and single currency
conversion processing is not used (i.e., the rates set with the BUY RATE and
SELL RATE fields on ICFE screen 12). If the MULTI CURRENCY field on ICFE
screen 3 is set to a value of Y, the co-network must also support multiple
currencies.
Refer to the BASE24 Base Files Maintenance Manual for more information
about ICFE screen 3. For more information about the BASE24-atm Multiple
Currency and BASE24-pos Multiple Currency add-on products, refer to the
BASE24-atm Multiple Currency Support Manual and the BASE24-pos Multiple
Currency Support Manual, respectively.
Counter Description
Issuer Approval Count The total number of requests to the issuer that
resulted in an approved response during the retrieval
interval.
Issuer Denial Count The total number of requests to the issuer that
resulted in a declined response during the retrieval
interval.
Issuer Force Post Count The total number of requests to the issuer that
resulted in an advice response during the retrieval
interval.
Issuer Reversal Count The total number of reversals during the retrieval
interval.
Issuer Bad PIN Count The total number of requests to the issuer that
resulted in a declined response during the retrieval
interval because of a bad PIN.
Issuer Key Sync Count The total number of requests to the issuer that
resulted in a key synchronization error during the
retrieval interval.
Inbound Request Time- The total number of requests to the issuer that timed
out Count out during the retrieval interval.
Counter Description
Inbound Response Time The average response time of all issuer response
transactions during the retrieval interval. This
counter consists of two counters with the same
name. One counter is a message rate counter that is
the total number of requests to the issuer during the
retrieval interval. The second counter is a response
time counter that displays the average response
time.
The average response time is determined by
dividing the total response time by the total number
of requests to the issuer. The total response time is
measured from the time that the request enters the
BASE24 system until the response exits the
BASE24 system.
Acquirer Denial Count The total number of acquirer requests that resulted
in a declined response during the retrieval interval.
Acquirer Force Post The total number of acquirer requests that resulted
Count in an advice response during the retrieval interval.
Note that this counter is available for the
BASE24-pos product only.
Acquirer Bad PIN The total number of acquirer requests that resulted
Count in a declined response during the retrieval interval
because of a bad PIN.
Acquirer Key Sync The total number of acquirer requests that resulted
Count in a key synchronization error during the retrieval
interval.
Outbound Request The total number of acquirer requests that timed out
Time-out Count during the retrieval interval.
Counter Description
Surcharging Support
The BIC ISO Interface process supports the capability of surcharging. An
institution can configure the BASE24-atm system to assess acquirer fees
(surcharges) on transactions initiated at selected ATMs. Surcharges can be based
on attributes such as terminal type (for example, the location of the ATM), card
prefix or transaction routing, card type, and transaction type. In addition,
surcharges can be based on a flat fee per transaction or on a percentage of the
transaction amount. A negative flat fee (rebate) value is supported.
Surcharging is configured in the Surcharge File (SURF). Fields in the Card Prefix
File (CPF) and the BASE24-atm Terminal Data files (ATD) link the SURF with a
card prefix or terminal group. Refer to the BASE24 Base Files Maintenance
Manual for more information about configuring the SURF and CPF for
surcharging. Refer to the BASE24-atm Files Maintenance Manual for more
information about configuring the ATD.
The surcharge amount is carried in data element P-28 of the BIC ISO external
message. The presence of data element P-28 in the BIC ISO external message is
determined by the setting of this data element in the External Message File (EMF).
In order for this data element to be included in the BIC ISO external message, it
must be defined as mandatory or conditional in the EMF. Refer to the BASE24
External Message Manual for more information about this data element.
In addition, the Surcharge Data token is appended to the message and passed along
with any other tokens to the co-network. This token is used to store surcharge
assessment information defined in the BASE24-atm Terminal Data files (ATD)
and Surcharge File (SURF) and other information filled in at the entry point and by
the Authorization process. Refer to the BASE24 Tokens Manual for more
information about the Surcharge Data token.
The difference between standard mapping and enhanced EMV mapping is how
EMV-related response codes are handled. Using standard mapping, EMV-related
response codes are mapped to more general response codes which can obscure the
reason an EMV transaction is declined. Using enhanced EMV mapping, however,
unique ISO response codes are used that allow EMV-related response codes to
retain their EMV characteristics. For example, an outbound BASE24-atm EMV
response code of 084 would map to 05 under standard mapping and U4 under
enhanced EMV mapping as shown in the table below. Where the former does not
retain the specific reason for the response (due to an ATC check failure), the latter
does.
For a complete list of BASE24-atm response code mappings, refer to the BASE24
BIC ISO Standards Manual.
The type of mapping used for BASE24-atm and BASE24-pos EMV messages is
controlled by the ENHANCED-EMV-RC-MAPPING param in the LCONF.
Param values control the type of mapping as follows:
This section describes the configuration and control of the BIC ISO Interface
process and includes the following:
?
Descriptions of files used by the BIC ISO Interface process
?
Process configuration information
?
Descriptions of institution- and co-network-level controls
?
A description of how stations are defined and used by the BIC ISO Interface
process
?
Descriptions of the timers used by the BIC ISO Interface process and the
processing performed when each timer expires
Assigns
The following assigns identify the names of files that contain BIC ISO Interface
process configuration and control information, or that the BIC ISO Interface
process uses during processing. The BIC ISO Interface process reads these assigns
regardless of the products supported.
APCFEMT — Identifies the name of the Acquirer Processing Code File (APCF)
extended memory table (APCFEMT), which contains APCF records.
ICF — Identifies the name of the Interchange Configuration File (ICF). This
assign is required if the BASE24-REL param is not present or does not contain the
value of 60.
IPCFEMT — Identifies the name of the Issuer Processing Code File (IPCF)
extended memory table (IPCFEMT), which contains IPCF records.
LMCF — Identifies the name of the Log Message Configuration File (LMCF).
RPT — Identifies the name of the Report Perusal File (RPT). This assign is
required if reports are to be run.
SW-RPT-OBEY-FILE — Identifies the name of the obey file used to start the
interchange reports. This entry is required if reports are to be generated.
SW-RPT01-PROG-NAME
SW-RPT09-PROG-NAME — Identify the names of the interchange report
programs. These entries are required if these reports are to be generated.
Params
Several params are used by the BIC ISO Interface process during processing.
These params are as follows.
1 = DDMM
2 = MMDD (default)
If this param is set to a value of Y, the BIC ISO Interface process uses the Key 6
file (KEY6). Otherwise, it uses the Key File (KEYF).
This param is not used if the system supports Multiple Currency processing (the
MULT CURRENCY field on ICFE screen 3 is set to Y).
BASE24-pos Note: BASE24-pos transactions may or may not contain a PIN, and
authorizing systems must be able to differentiate between transactions with a pre-
verified PIN and transactions that do not contain a PIN (i.e., that were not entered
with a PIN). Therefore, for incoming and outgoing BASE24-pos transactions, a
PIN block containing this LCONF pad character is always used to indicate a PIN
has been pre-verified. The absence of the P-52 (Personal Identification Number
Data) data element in the external message is used to indicate the transaction did
not contain a PIN (for incoming BASE24-pos messages, a space-filled P-52 data
element is also acceptable to indicate the transaction did not contain a PIN).
Note: This param is not used if the BASE24 Transaction Security Services (TSS)
process is being used.
Note: This param is not used if the BASE24 Transaction Security Services (TSS)
process is being used.
Note: This param is not used if the BASE24 Transaction Security Services (TSS)
process is being used.
Y = Yes, send the ETX character with external messages (default value).
N = No, do not send the ETX character with external messages.
SW-RPT-STARTUP — The time the BIC ISO Interface process runs its report
obey file. Valid values, in military time, are from 00:00 to 23:59.
Y = Yes, retrieve the ILF record upon receipt of a late response and update it to
reflect that a reversal was sent out (default value).
N = No, do not retrieve the ILF record upon receipt of a late response and
update it to reflect that a reversal was sent out.
Configuring a Co-Network
Each co-network with which BIC ISO Interface process communicates requires a
record in the Enhanced Interchange Configuration File (ICFE). Co-networks are
assigned stations and tied to the BIC ISO Interface processes with which they
communicate using the ICFE.
The table below identifies each timer used by the BIC ISO Interface process, along
with the level at which it is defined and the file in which it is defined. Each of
these timers are discussed later in this section.
The BIC ISO Interface process sends the following messages types directly to the
SAF instead of to the co-network:
?
Reversal messages
?
Force post messages
?
Adjustment messages
?
Chargeback messages
?
Cutover messages
?
Administrative messages
Institutions indicate whether they send text-level acknowledgments using the ACK
FROM SWITCH field on ICFE screen 1.
Note: The BIC ISO Interface process always requires acknowledgments for its
store-and-forward messages. If text-level acknowledgments are not to be sent, the
BIC ISO Interface process requests a logical acknowledgment from the XPNET
process. A logical acknowledgment notifies the BIC ISO Interface process that the
message has been sent successfully to the co-network.
If message authentication is being performed, the setting for this field should be
carefully considered. Some message verification errors can be retried (for
example if the co-network’s security device is down at the time it receives the
message to be authenticated). If this field indicates that text-level
acknowledgments are not required and the message was a store-and-forward
message, the original message will not be available to resend to the co-network.
This is because the message would have been deleted when the XPNET process
returned a logical acknowledgment that the message was sent successfully.
Institutions control when a station is marked down because of timeouts using the
MAXIMUM TIMEOUTS field on ICFE screen 1.
Institutions indicate whether the BIC ISO Interface process can initiate network
management messages using the NETWORK MANAGEMENT MESSAGE
ENABLED field on ICFE screen 3.
Note: This option only controls whether the BIC ISO Interface process can
initiate the network management actions; the BIC ISO Interface process always
responds to the network management messages it receives.
This option can be used to stop processing a message when, due to the number of
timeouts on a store-and-forward message, it becomes apparent that the co-network
cannot process the message. Institutions control this option using the MAX SAF
RETRY field on ICFE screen 3.
This option allows the BIC ISO Interface process to prevent processing when it
becomes apparent that the co-network cannot process a message within the time
limits required because of the number of messages already outstanding to the co-
network.
Once the number of outstanding messages reaches this limit, the BIC ISO Interface
process marks any new request messages destined for the co-network as failed and
returns them to their originating process. The BIC ISO Interface process places
any new advice messages destined for the co-network in the SAF. At this point,
the co-network does not receive additional request or advice messages until the
messages in the queue are either responded to or have timed out.
Note: This feature only affects 0100 and 0200 messages. Other message types are
not included in the count of outstanding messages, nor is their processing affected
in any way.
Data prefix characters are placed in the ICFE using the hexadecimal equivalents
for the ASCII versions of the characters to be sent. For example, suppose a co-
network required the following three characters in front of the message:
ESC 1 B
(escape)
To place these three values in an ICFE record, a co-network would have to enter
hexadecimal equivalents (six characters) for the ASCII representations of these
values, which would be:
1B 31 42
These values would be stored in the ICFE as six characters (1B3142) and would be
converted back to the three ASCII characters at the time the message is created.
Because the BIC ISO Interface process does not support transparent data
communications, protocol characters cannot be used as data prefix characters.
Some characters to avoid are:
01 SOH 02 STX
03 EXT 04 EOT
05 ENQ 06 ACK
10 DLE 15 NAK
16 SYN 17 ETB
1F ITB
Authorization Process
The BIC ISO Interface processes handling requests from acquirer networks
determine the Authorization processes to which to route inbound transaction
requests using the AUTH PROCESS field on ICFE screen 8 for the BASE24-atm
product or ICFE screen 10 for the BASE24-pos product.
The BIC ISO Interface process reads the ICFE at initialization and builds a table of
the stations defined for each co-network.
Station Types
Co-networks can define two types of stations for use by the BIC ISO Interface
process: send/receive stations and receive-only/no output stations. These stations
are described below.
Station types are defined using the TYPE fields on ICFE screen 13.
Send/Receive Stations
Send/receive stations allow for both incoming and outgoing messages. The BIC
ISO Interface process can send messages to and receive messages from the co-
network using this type of station.
When selecting a station to which to send a message, the BIC ISO Interface
process goes through its station table from start to finish until it finds a station
available to receive the message.
If lines have multiple stations on them, the stations from each line should be
alternated when setting up the ICFE station table, and not numbered sequentially.
Alternating the stations balances the transaction load so that if one station is
chosen from one line, the next station chosen is on a different line.
When the BIC ISO Interface process has sent a message to the last station in the
ICFE station table, it begins its next search using the first station in the ICFE
station table. The BIC ISO process never sends messages to receive only stations.
The BIC ISO Interface process can suppress discretionary data such as fields other
than the primary account number (PAN) and the card expiration date in
BASE24-atm and BASE24-pos response messages exchanged between co-hosts or
that is logged to the ILF. It can also suppress card verification data (CVD2) and
address verification data for transactions logged to the ILF.
The BIC ISO Interface process uses the following Logical Network Configuration
File (LCONF) params to determine whether the data is logged to the ILF:
Response Messages
ATM-DISCR-DATA-STM-SUPPRS
POS-DISCR-DATA-PSTM-SUPPRS
If the corresponding param exists and the value indicates that the BIC ISO
Interface process is to suppress discretionary, address verification, or CVD2
information, the data is suppressed. Refer to the “LCONF Assigns and Params”
topic or the BASE24 Logical Network Configuration Manual for more
information about these params.
default External Message File (EMF) records configure the Track 2 Data data
element. As a result, users should consider configuring EMF records that include
the Primary Account Number (P-2) data element and modify the default settings
for the Track 2 (P-35) data element. Refer to the BASE24 ISO Standards Manual
for additional information for modification suggestions.
Configuring Timers
The BIC ISO Interface process uses internal timers to control co-network message
traffic. The length of each of these timers is specified in the ICFE.
The actions taken when a Network Management Message timer expires depend on
the type of message for which the timer was set. If the message was a logon,
logoff, or echo test message, the BIC ISO Interface process performs as follows:
?
The amount of time that the BIC ISO Interface process waits after a station is
marked down before attempting to reestablish communications with the
station.
?
The amount of time the BIC ISO Interface process waits after a new key or
change key message times out before attempting to resend the message.
The number of seconds to use for this timer is taken from the EXTENDED
NETWORK field on ICFE screen 3.
If an Extended Network Management Message timer that was set when a station
was marked down expires before any messages are received from the station, the
BIC ISO Interface process performs the following:
When an Extended Network Management Message timer that was set after a new
key or change key message time out expires, the BIC ISO Interface process
determines whether there is a station available to which to send the message. For
more information on how the BIC ISO Interface process selects a station for
sending a message, see the topic “Selecting Stations for Receiving Messages”
earlier in this section. Depending on whether a station is available, the BIC ISO
Interface process performs as follows:
?
If a station is available, the BIC ISO Interface process sends the new key
message or change key message to that station. The BIC ISO Interface
process sets a Network Management Message timer to wait for the response
to the new key or change key message.
?
If no stations are available, the BIC ISO Interface process, sets an Extended
Network Management Message timer. When this timer expires, the BIC ISO
Interface process attempts to send the message again.
The BIC ISO Interface process only expects text-level acknowledgments to store-
and-forward messages if the ACK FROM SWITCH field on ICFE screen 3
contains the value Y. If text-level acknowledgments are not required from the co-
network, the BIC ISO Interface process expects a logical acknowledgment from
the XPNET process once the message has been sent successfully to the co-
network. In this case, if the co-network rejects the message for any reason, the
message is not resent because it will have already been deleted from the SAF.
Wait-for-Traffic Timer
A Wait-for-Traffic timer is set each time a station is marked up and each time a
previously set Wait-for-Traffic timer expires. The Wait-for-Traffic timer specifies
the length of time that the BIC ISO Interface process waits for traffic on the line
before sending an echo test message. The number of seconds to use for this timer
is taken from the WAIT FOR TRAFFIC field on ICFE screen 3.
The BIC ISO Interface process sets Wait-for-Traffic timers for its send/receive
stations only. Wait-for-Traffic timers are not set for receive-only/no output
stations.
When this timer expires, the BIC ISO Interface process determines whether there
has been any message traffic to or from the station since the timer was set.
Depending on whether there has been traffic on the line, the BIC ISO Interface
process performs as follows:
1. If there has been message traffic, the BIC ISO Interface process simply sets
another Wait-for-Traffic timer.
2. If there has not been message traffic, the BIC ISO Interface process:
a. Sends an echo test message to the station.
b. Sets a Network Management Message timer for the echo test message.
Performance Timer
A performance timer is set for each co-network at the start of that co-network’s
new performance statistics accumulation period. The Performance timer specifies
the interval the BIC ISO Interface process uses for gathering performance
statistics. The number of minutes to use for this timer is taken from the
PERFORMANCE PERIOD field on ICFE screen 3.
For each co-network, the BIC ISO Interface process tracks the number of requests
sent to the co-network, the number and percentage of requests that time out, and
the average response time. These statistics are tracked on an interval basis and are
available for the most current four intervals (interval zero through interval three
with interval zero being the most current). The Performance timer triggers the end
of one interval and the beginning of the next.
When a Performance timer expires, the BIC ISO Interface process performs as
follows:
Note: These statistics are accessed using the PERFORMANCE command entered
from a network control facility. For information concerning the entry of the
PERFORMANCE command and the display of the statistics, please refer to the
description of the PERFORMANCE command in the BASE24 Text Command
Reference Manual.
If this timer expires before a response is received to the message, the BIC ISO
Interface process performs as follows:
2) Sets the STM to indicate the destination was not available. This
identifies the 0200 message as a failure.
3) Sets the STM to cause the Authorization process to generate a 0220
message if it subsequently stands in and authorizes the transaction.
4) Sends the STM to the process where the message originated.
a) If the message is a BASE24-pos message, the BIC ISO
Interface process performs as follows:
1) Retrieves the 0200 message from memory (all 0100 messages are
handled as 0200 messages internally).
The BIC ISO Interface process retains a copy of the PSTM for each
0100 and 0200 message it sends to the co-network until it is
notified that the message was received.
2) Sets the PSTM to indicate the destination was not available. This
identifies the 0200 message as failed.
3) Sets the PSTM to cause the Authorization module to generate a
0200 message if it subsequently stands in and authorizes the
transaction.
4) Sends the PSTM to the process where the message originated.
2. Adds one to the count of consecutive timeouts accumulated for the station.
3. Adds one to the number of request timeouts for the co-network.
The BIC ISO Interface process tracks this information as part of its co-
network performance statistics.
4. Checks the current number of consecutive timeouts accumulated for the
station against the maximum allowed by the MAXIMUM TIMEOUTS field
on ICFE screen 3.
a. If the current number of consecutive timeouts is equal to the maximum
allowed, no further action is taken.
b. If the current number of consecutive timeouts is equal to the maximum
allowed, the BIC ISO Interface process performs as follows:
1) Marks the station down.
2) Verifies that the co-network still has a station available for sending
messages. If no send/receive stations are left up for the co-network,
the BIC ISO Interface process marks the co-network down.
3) Sets an Extended Network Management Message timer for the
station.
?
When the BIC ISO Interface process is initialized or warmbooted
?
When the key for which the timer has been set is exchanged for any reason
The BIC ISO Interface process sets and uses Key Exchange timers for PIN keys
when the PIN KEY TIMER VALUE field on KEYF screen 3 or KEY6 screen 4
contains a nonzero value. PIN Key Exchange timers limit the length of time that
the BIC ISO Interface process uses a particular PIN key to encrypt and decrypt
PINs sent between the BIC ISO Interface process and the co-network. The length
of time to use for these timers is taken from the PIN KEY TIMER INTERVAL and
PIN KEY TIMER VALUE fields on KEYF screen 3 or KEY6 screen 4.
The BIC ISO Interface process sets and uses Key Exchange timers for MAC Keys
when the MAC KEY TIMER VALUE field on KEYF screen 3 or KEY6 screen 4
contains a nonzero value. MAC Key Exchange timers limit the amount of time
that the BIC ISO Interface process uses a particular MAC key to encrypt and
decrypt MACs sent between the BIC ISO Interface process and the co-network.
The amount of time to use for these timers is taken from the MAC KEY TIMER
INTERVAL and MAC KEY TIMER VALUE fields on KEYF screen 3 or KEY6
screen 4.
If a Key Exchange timer expires, the BIC ISO Interface process performs as
follows:
Note: Upon receiving a response from the co-network, the BIC ISO Interface
process clears the flag that indicated a key exchange was pending and sets a new
Key Exchange timer.
The INBOUND PIN KEY, OUTBOUND PIN KEY, INBOUND MAC KEY, and
OUTBOUND MAC KEY fields on KEYF screen 2 can each contain information
for two keys, identified as KEY1 and KEY2. The value in the CURRENT INDEX
field for each type of key identifies which key is currently in use. At the time of a
successful key exchange, the CURRENT INDEX is updated to point to the new
key and the key that was in use becomes the old key.
When processing a transaction, the BIC ISO Interface process uses the new key for
PIN processing or message authentication. If the security device cannot verify the
PIN or the MAC because of a key error, the transaction is tried again using the old
key, if one exists. This timer controls how long the old key exists. When the timer
expires, the old key is cleared from the KEYF.
?
When the BIC ISO Interface process receives a duplicate new key message
from the co-network (carrying a key that was already received in a previous
new key message and stored in the KEYF.)
?
When the BIC ISO Interface process approves a new key message from the
co-network.
?
When the BIC ISO Interface process receives an approved new key response
message from the co-network (i.e., BASE24 sent the host a new key, and the
co-network has responded that the new key has been implemented
successfully).
When a clear old key timer expires, the BIC ISO Interchange Interface processBIC
ISO Interchange Interface process performs as follows.
Note: KEYF information is read into memory by the BIC ISO Interface process at
initialization, and the BIC ISO Interface process performs the following steps on
the KEYF information in memory and in the KEYF file.
1. Determines the type of key for which the timer was set.
2. Determines the key to clear using the value in the CURRENT INDEX field.
Since the value in the CURRENT INDEX field points to the newest key, the
BIC ISO Interface process selects the key not being pointed to by the
CURRENT INDEX field as the one to clear.
3. Sets the selected key value and its check digits in memory to ASCII zeros.
4. Sets the selected key value and its check digits in the KEYF or KEY6 to
binary zeros.
When the report startup timer expires, the obey file containing the commands to
run the report programs is executed.
The SETTLEMENT TIMER field has a default value of 0 when an ICFE record is
added and the operator can modify this value to any value between 0 and 999.
However, the interface process uses a value of 20 minutes in processing when the
SETTLEMENT TIMER field is set to a value of 0.
The BIC ISO Interface process starts this timer when it receives a reply to the
cutover message sent to the co-network. The BIC ISO Interface process waits for
any transactions in progress for the previous BASE24 settlement day to finish
processing. When the timer expires, the BIC ISO Interface process updates the
reconciliation totals for the previous BASE24 settlement day for the last time and
sends these totals to the co-network.
The ITF UPDATE INTERVAL field has a default value of 30 minutes when an
ICFE record is added and the operator can modify this value to any value between
0 and 999. However, the interface process uses a value of 30 minutes in
processing when the ITF UPDATE INTERVAL field is set to a value of 0.
The BIC ISO Interface process also uses a transaction counter to determine when
ITF totals should be updated. The ITF UPDATE MAX TRANSACTIONS field
on ICFE screen 12 indicates the maximum number of transactions that can be
processed between ITF updates.
The BIC ISO Interface process performs the following steps when the ITF update
timer expires or when the transaction count reaches the maximum:
If the default message structures need to be modified, records can be created in the
EMF specifying the new message structures. The BIC ISO Interface process
allows incoming and outgoing messages to be configured individually by an
institution, depending on the information the co-network chooses to send and
receive.
?
If a data element is defined as mandatory, it is always sent in outgoing
external messages and must be present in incoming external messages.
?
If a data element is defined as conditional, it is sent in outgoing messages
under certain conditions. If the element contains data and the data is valid,
the BIC ISO Interface process sends the element in its outgoing external
messages. If the element contains blanks or zeros, it is not sent. Likewise,
the data element may or may not be present in incoming messages.
?
If a data element is defined as not required, the field in the EMF used to
define a data element as mandatory or conditional is left blank. Data
elements defined in this manner are not sent in outgoing external messages
and are not expected in incoming external messages.
Message Type
The message type identifies the external message type being defined by the record.
Any external message type allowed by the BIC ISO Interface process is valid in
this field, except for repeat messages. A repeat message contains the same
information as the original message. The value entered in this field can only be
used with certain values entered in the PROD # field and IN-OUT-IND field. A
table showing valid relationships for external messages to and from a co-network
is provided as follows:
9000 O
0510, 0530 I
0500, 0520 O
Note: Message types in the 9000 range are used to denote rejected messages and
message authentication errors. For example, a message type of 0200 would be
changed to 9200 if it were rejected and a message type of 0420 would be changed
to 9420 if it were rejected. Setting up a record in the EMF for a message type of
9000 is not to control the message structure, but rather to allow for assigning a
single IMS/CICS transaction code equivalent to all rejected messages returned to
the co-network. For further information on assigning an IMS/CICS transaction
code equivalent to a 9000 message, refer to the description of EMF screen 3 in the
BASE24 Base Files Maintenance Manual.
Warning: Special care must be used when adding or updating an EMF record.
If IMS or CICS transaction code equivalents are being used, access to EMF
screen 3 is required in order to perform file maintenance operations (in addition
to any other EMF screen access that may be defined). EMF screen 3 is used to
assign IMS or CICS transaction code equivalents to BASE24 transaction codes
and can consist of up to five pages. The last page containing transaction codes
must be displayed when the function key is pressed to add or update the record
or transaction codes are lost. For example, if the function key is pressed while
screen 1 or screen 2 is displayed, all transaction codes on screen 3 are not
included in the new or updated record. If the function key is pressed while one
of the screen pages is displayed, but it is not the last page containing transaction
codes, the transaction codes on the remaining screen 3 pages are not included in
the new or updated record.
9000 O
0510, 0530 I
0500, 0520 O
3. Review the values for the message type being displayed. If the value for a
specific data element needs to be changed, enter an M (mandatory), a C
(conditional), or a blank (not required) in the field directly to the right of the
appropriate data element number.
4. Display EMF screen 2 by pressing the F9 key. EMF screen 2 allows you to
specify individual data elements to be used during message authentication.
5. Review the values for the message type being displayed. If the value for a
specific data element needs to be changed, enter a Y (include in
authentication) or a blank (do not include in authentication) in the field
directly to the right of the appropriate data element number.
6. Display EMF screen 3 by pressing the F9 key. EMF screen 3 allows you to
assign CICS or IMS equivalents to BASE24 transaction codes.
7. Determine whether any BASE24 transaction codes require IMS or CICS
transaction code equivalents, and perform as follows:
a. If no IMS or CICS transaction codes are required, or if all of the IMS or
CICS transaction codes are displayed on the current page of screen 3,
press the F3 key to add the record. Continue with step 8.
b. If additional IMS or CICS transaction codes are required, add the IMS or
CICS equivalents by making the appropriate entries in the TRANS, IMS
TRAN, and L fields.
If you need more than 30 transaction codes, go to the next screen 3 page
by pressing the F8 key and add the necessary IMS or CICS equivalents.
You must go to a new screen 3 page each time you add 30 transaction
codes.
When you have finished adding the necessary IMS or CICS transaction
code equivalents, add the record to the EMF by pressing the F3 key.
Note: The last screen 3 page containing entries must be displayed when
you add or update the record.
8. Return to EMF screen 1 by pressing the F9 key. Repeat steps 2 through 7 for
any remaining message types to be added to the EMF.
9. Reinitialize the BIC ISO Interface process in order to read the new values.
?
The tokens that get logged to the transaction log files. The transaction log
files affected are the BASE24-atm Transaction Log File (TLF), POS
Transaction Log File (PTLF), and the Interchange Log Files (ILFs).
?
The tokens that get extracted from the transaction log files by the Super
Extract process. Extracting allows the token information to be processed by
the co-network.
?
The tokens that get sent to the co-network with each transaction in the ISO-
based external message.
For more information on configuring the tokens that get logged, extracted, and
sent in the external message, please refer to the BASE24 Tokens Manual.
?
Clear PIN processing. All PINs handled by the co-network are in the clear.
?
Encrypted PINs—security module accessed for PIN processing. All PINs
handled by the co-network are encrypted under the secure keys of a security
module. The security modules that can be used include Atalla Security
Modules and the Thales e-Security (Racal) Host Security Modules.
?
Encrypted PINs—software DES PIN processing. All PINs handled by the co-
network are encrypted in software, using the DES algorithm. No security
module is in use.
This option is controlled using the ENCRYPT TYPE field on KEYF or KEY6
screen 1.
?
Clear PIN processing. All PINs handled by the BASE24 system are in the
clear.
?
Encrypted PINs—security module accessed for PIN processing. All PINs
handled by the BASE24 system are encrypted under the secure keys of a
security module.
This option is controlled using the BASE24 ENCRYPT TYPE field on KEYF or
KEY6 screen 1.
The BIC ISO Interface process supports two types of PIN blocks—ANSI PIN
blocks and PIN/PAD PIN blocks. The interchange can specify one of these two
PIN block types or specify clear PIN, indicating that PINs are not encrypted.
This option is controlled using the PIN BLOCK FORMAT field on KEYF or
KEY6 screen 1.
?
Use the 12 right-most digits of the PAN, excluding the check digit
?
Use the 12 right-most digits of the PAN, including the check digit
?
Use the 12 left-most digits of the PAN
This option is controlled using the ANSI PAN FORMAT field on KEYF or KEY6
screen 1.
The PAD character is specified using the PIN PAD CHARACTER field on KEYF
or KEY6 screen 1.
Number of Keys
The number of keys indicates whether the inbound and outbound keys supported
by the BIC ISO Interface process are the same or different. If the keys are the
same, only one key is generated and used for both inbound and outbound keys. If
the keys are different, a separate key is generated for inbound and outbound keys.
This field is used to determine the number of keys being used for PINs and
message authentication.
The number of different PIN or message authentication keys supported by the BIC
ISO Interface process is specified using the NUMBER OF KEYS field on KEYF
or KEY6 screen 1.
Key Length
The key length indicates the type of key management supported by the BIC ISO
Interface process. This field identifies whether the BIC ISO Interface process
supports single-length Key Encryption Keys (KEKs) or double-length KEKs.
Single-length KEKs consist of one 64-bit key. Double-length KEKs consist of a
key pair consisting of 64 bits each. For more information on single-length and
double-length KEKs, refer to the BASE24 Transaction Security Manual.
The type of key management supported by the BIC ISO Interface process is
specified using the KEY LENGTH field on KEYF or KEY6 screen 1.
The PIN key variant option supported by the BIC ISO Interface process is
specified using the PIN KEY VARIANT field on KEYF screen 3 or KEY6
screen 4.
?
Main — Indicates that this process controls all key generation.
?
Co-network — Indicates that this process shares the control of key
management processing with its co-network. Each co-network is only
responsible for exchanging its inbound key.
?
Secondary — Indicates that this process is not responsible for any key
generation.
?
None — No key processing is supported.
The key processing type supported by the BIC ISO Interface process is specified
using the KEY PROCESSING TYPE field on KEYF screen 3 or KEY6 screen 4.
This option is controlled using the MAC ENCRYPT TYPE field on KEYF or
KEY6 screen 1.
The message authentication data type indicates the character set of the data being
authenticated using MACs. The character set can be either ASCII or EBCDIC.
This is the format of the data prior to performing the MAC calculation. The
BASE24 system and the co-network are required to have the same message
authentication data type format.
The message authentication data character format is specified using the MAC
DATA TYPE field on KEYF or KEY6 screen 1.
The BIC ISO Interface process has a standard set of defaults that it uses for
determining which of the 128 data elements are to be included when authenticating
each external message.
These defaults can be overridden using settings in the EMF . These settings allow
the institution to include or exclude data elements when authenticating the
message. The EMF allows a co-network to alter the combinations of data elements
that are included when authenticating messages.
The BASE24 system also offers the options of authenticating all data elements in
an individual message, or of authenticating all data elements in all messages. Full
message authentication is specified in the EMF for individual messages. If an
EMF record for the specific message type does not exist, the BIC ISO Interface
process checks the KEYF or KEY6 to determine whether all of its messages
should use full message authentication. If the FULL MESSAGE MAC field on
KEYF or KEY6 screen 1 contains the value Y, the entire message is included in
creating the MAC. If the FULL MESSAGE MAC field on KEYF or KEY6 screen
1 contains the value N, the BIC ISO Interface process uses its defaults to determine
which elements should be included in creating and interpreting the MAC.
In addition to using the specified data elements in the MAC generation, the BIC
ISO Interface process uses the ISO literal, BASE24 header, message type
identifier, and primary bit map when it generates a MAC. These message
components are always used in MAC generation, regardless of the EMF, KEYF or
KEY6 settings.
The MAC key variant indicates whether key exchange keys (KEKs) or MAC key
exchange keys (KEKs) need to be generated for message authentication key
translations.
The message authentication key variant option supported by the BIC ISO Interface
process is specified using the MAC KEY VARIANT field on KEYF screen 3 or
KEY6 screen 4.
Reconciliation Totals
The BIC ISO Interface process can be set up to specify whether it should maintain
reconciliation totals to be used during cutover processing. This option is
controlled using the PROCESSING MODE field on ICFE screen 3.
Cutover Relationship
The cutover relationship between BASE24 and the co-network can be defined as
an equal partner or a main and secondary relationship. This option is controlled
using the CUTOVER STATUS field on ICFE screen 12.
The BIC ISO Interface process can be set up to specify how often the Interchange
Totals File (ITF) should be updated during the processing day. This option is
controlled using the ITF UPDATE INTERVAL and ITF UPDATE MAX
TRANSACTIONS fields on ICFE screen 12.
The BIC ISO Interface process can be set up to specify how long it should wait
after a successful cutover before it sends a reconciliation message to the co-
network. This option is controlled using the SETTLEMENT TIMER field on
ICFE screen 12.
Transactions Allowed
The BIC ISO Interface process ensures that inbound transactions from the co-
network are allowed using the Acquirer Processing Code File (APCF) prior to
forwarding the transaction to the authorization process. Similarly, the interface
ensures that outbound transactions are allowed to be sent to the co-network using
the Issuer Processing Code File (IPCF) prior to forwarding the transaction to the
co-network.
The BIC ISO Interface process can be set up to specify the transactions that can be
sent to or from the co-network for authorization. Transactions allowed are
configured using the transaction profiles in the Enhanced Interchange
Configuration File (ICFE). These profiles correspond to records in the Acquirer
Processing Code File (APCF) and the Issuer Processing Code File (IPCF).
Outbound Transactions
Issuer Transaction Profile Processing. Once the issuer transaction profile value
used to read the IPCF extended memory table has been determined, the BIC ISO
Interface process attempts to read the IPCF extended memory table using the
issuer transaction profile value, the message category code from the transaction,
and the ISO processing code for the transaction. The BIC ISO Interface process
calls a utility to map the internal BASE24 transaction code for the transaction to
the corresponding ISO processing code before reading the IPCF extended memory
table.
Using the issuer transaction profile, message category, and ISO processing code,
the BIC ISO Interface process steps through the records in the IPCF extended
memory table looking for a match. If an exact match is not found, certain other
alternatives are allowed. Below is the hierarchy used for selection.
Once a match is found, the record is read to determine whether the transaction is
allowed. If the ON-US TRANSACTION ALLOWED field on IPCF screen 2 is
set to a nonzero value, the transaction is allowed. If the transaction is allowed and
the COMPLETION REQUIRED TO HOST field on IPCF screen 2 is set to a value
of Y, the Router/Authorization module will generate a completion message
indicating whether the transaction is approved or declined and send it to the host
after the transaction has been authorized.
Inbound Transactions
The ACQUIRER TXN PROFILE field on ICFE screens 8 and 10 defines the
transactions allowed from the co-network. The value of the acquirer transaction
profile is used to read the Acquirer Processing Code File (APCF) extended
memory table, which defines all the transactions allowed for the profile and the
accounts on which the transactions can be performed. If an acquirer transaction
profile is not specified, the BIC ISO Interface process uses a value of all asterisks
(wildcard characters) to read the APCF extended memory table. If BASE24
receives a transaction from an interchange that has not been defined as allowed,
the BIC ISO Interface process denies the transaction.
Interface process calls a utility to map the internal BASE24 transaction code for
the transaction to the corresponding ISO processing code before reading the APCF
extended memory table.
Using the acquirer transaction profile, message category, and ISO processing code,
the BIC ISO Interface process steps through the records in the APCF extended
memory table looking for a match. If an exact match is not found, certain other
alternatives are allowed. Below is the hierarchy used for selection.
Once a match is found, the record is read to determine whether the transaction is
allowed.
The APCF also allows you to specify an authorization destination for a transaction
other than the BASE24-atm Authorization process or BASE24-pos Device
Handler/Router/Authorization process specified in the AUTH PROCESS field on
ICFE screen 8 or 10, respectively. This mechanism allows you to route
transactions received from an interchange to an application process. When a
transaction is routed in this way, you can also specify whether the transaction
response returned from the authorization destination is logged to the transaction
log file.
Stand-in Authorization
The BIC ISO Interface process can be set up to specify whether the issuer or
acquirer can stand in to authorize transactions if the link to the authorizing entity is
down. These options are controlled using the ACQ STAND-IN AUTH and ISS
STAND-IN AUTH fields on ICFE screen 12.
Automatic Logon
The BIC ISO Interface process can be set up to automatically log on to the co-
network at startup. If this option is selected, no operator intervention is required to
log on to the co-network. It is done automatically as part of the initialization of the
BIC ISO Interface process. This option is controlled using the AUTO SIGNON
START field on ICFE screen 3.
Product Indicators
The BIC ISO Interface process can be set up to specify which products it can
support. The BIC ISO Interface process currently supports the BASE24-atm and
BASE24-pos products. This option is controlled using the PRODUCT
INDICATOR fields on ICFE screen 12.
Defining Stations
The BIC ISO Interface process can be connected to a maximum of 20 stations.
These stations are defined using the STATION and TYPE fields on ICFE screen
13. The stations defined in the ICFE must also have a corresponding attribute in
the XPNET system.
The SWITCH ID field on ICFE screen 1 can contain an override identifier for the
institution that owns the BASE24 system. The DEFAULT ACQUIRER ID NUM
field on ICFE screen 1 can contain an override identifier for the co-network
institution.
One or more override institution identifiers can be used, and the OVRRD-INST-
ID-FLDS param in the LCONF uses the values 0 through 7 to specify the desired
combination of identifiers to be used.
?
When a transaction containing institution identifiers is acquired by the
institution that owns the BASE24 system, three values in the external
message can be overridden with values from ICFE screen 1 before the
message is sent to the co-network. The value in the SWITCH ID field can be
used to override the acquiring ID, forwarding ID, or both, and the value in the
DEFAULT ACQUIRER ID NUM field can be used to override the receiving
ID.
?
When a transaction is acquired by the co-network institution, the external
message contains institution identifiers. One value in the external message
can be overridden with a value from ICFE screen 1 before the message is sent
to the co-network. The value in the SWITCH ID field can be used to override
the receiving ID.
?
When a transaction is acquired by the institution that owns the BASE24
system, one value from ICFE screen 1 can be moved to the STM or PSTM if
the STM or PSTM field is empty and the corresponding field in the external
message received from the co-network is also empty. The value in the
DEFAULT ACQUIRER ID NUM field can be used to override the receiving
ID.
?
When a transaction is acquired by the co-network institution, one value from
ICFE screen 1 can be moved to the STM or PSTM if the corresponding fields
in the external message received from the co-network are empty. The value
in the DEFAULT ACQUIRER ID NUM field can be used to override the
acquiring ID.
ICFE Screens
This section contains a listing of ICFE fields used by the BIC ISO Interface
process. The ICFE is used by the institution to define institution and terminal
interchange sharing holidays, transaction handling in offline and online situations,
and settlement handling.
The following tables indicate the ICFE fields used by the BIC ISO Interface
process and the expected value. Values in quotation marks (“ ”) are literal values
that must be placed in the corresponding fields. The BIC ISO Interface process
does not use all the fields on all the ICFE screens. These fields are noted with “not
used” in the Values column.
Note: The information contained in the following tables does not indicate
whether a field is required, but rather if a field can be used if you so choose. The
field may or may not be required.
ICFE Screen 1
ICFE screen 1 contains fields establishing interchange identifiers, station names,
default values for certain fields, and report title names to be printed on the
SETL01-BIS and STAT09-BIC reports. The fields on ICFE screen 1 used by the
BIC ISO Interface process and their expected values are indicated in the following
table.
ICFE Screen 1
Field Value
ICFE Screen 1
Field Value
ICFE Screen 2
ICFE screen 2 contains interchange settlement information and pertinent holiday
dates. The fields on ICFE screen 2 used by the BIC ISO Interface process and
their expected values are indicated in the following table.
ICFE Screen 2
Field Value
ICFE Screen 2
Field Value
ICFE Screen 3
ICFE screen 3 is split up into two sections. The first section defines transaction
message timer limits used by the BIC ISO Interface process. The second section
defines the processing options used by the BIC ISO Interface process. The fields
on ICFE screen 3 used by the BIC ISO Interface process and their expected values
are indicated in the following table.
ICFE Screen 3
Field Value
ACQUIRER Y or N
ISSUER Y or N
ICFE Screen 3
Field Value
ACK TO SWITCH Y or N
ICFE Screen 8
ICFE screen 8 contains BASE24-atm processing information for interchanges,
including acquirer and issuer transaction profiles for the transactions allowed. The
fields on ICFE screen 8 used by the BIC ISO Interface process and their expected
values are indicated in the following table.
ICFE Screen 8
Field Value
ICFE Screen 8
Field Value
ICFE Screen 10
ICFE screen 10 defines BASE24-pos processing information for interchanges,
including acquirer and issuer transaction profiles for the transactions allowed. The
fields on ICFE screen 10 used by the BIC ISO Interface process and their expected
values are indicated in the following table.
ICFE Screen 10
Field Value
TIMEOUT ACTION 0, 1, or 2
SETTLE ENTITY 0 or 1
ICFE Screen 10
Field Value
ADJUSTMENT FLAG Y or N
CHARGEBACK FLAG Y or N
ICFE Screen 11
ICFE screen 11 defines POS preauthorization default time and amount, approval
code length, and services allowed to the co-network. The fields on ICFE screen 11
used by the BIC ISO Interface process and their expected values are indicated in
the following table.
ICFE Screen 11
Field Value
ICFE Screen 12
ICFE screen 12 is an interchange-specific screen used exclusively by the BIC ISO
Interface process. It defines options used at logon to determine processing
requirements for the BIC ISO Interface process. All fields on ICFE screen 12 can
be used by the BIC ISO Interface process. ICFE screen 12 is shown below
followed by descriptions of its fields.
ITF UPDATE INTERVAL: 030 (MINUTES) ITF UPDATE MAX TRANSACTIONS: 0200
SETTLEMENT TIMER: 000 (MINUTES) PROTOCOL TYPE: 00
SELL RATE: 00000000 BUY RATE: 00000000
The following fields contain information relevant to the functionality for the BIC
ISO Interface process.
Y = Stand-in is allowed
N = Stand-in is not allowed
Y = Stand-in is allowed
N = Stand-in is not allowed
0 = Equal
1 = Main
2 = Secondary
The value in this field must correspond with the value defined for the co-network
when the relationship is main/secondary or equal/equal. If it is main/secondary,
the main network controls when cutover should occur and is responsible for
sending totals for reconciliation. If it is equal/equal, each partner is responsible for
its own cutover and each must send totals at cutover.
VERSION — The current release of the external message format to be used. This
field is verified at logon to make sure the co-network is set up correctly.
In a release 4.0 BASE24 network, the value of this field must be set to 00. In a
release 5.x BASE24 network, the value must be set to 00 or 01. The value cannot
be set to 60. In a release 6.0 BASE24 network, the value can be set to 00, 01 or 60.
The BASE24 co-networks must use the value of the message format of the oldest
release of BASE24 used by the two co-networks.
ITF UPDATE INTERVAL — The length of time in minutes, the BIC ISO
Interface process waits between updates to the Interchange Totals File (ITF). The
ITF is always updated at the time interval specified in this field. The ITF may also
be updated based on the value specified in the ITF UPDATE MAX
TRANSACTIONS field.
This field has a default value of 30 minutes when an ICFE record is added, and the
operator can modify this value to any value between 0 and 999. However, the
interface process uses a value of 30 minutes in processing when the ITF UPDATE
INTERVAL field is set to a value of 0.
SETTLEMENT TIMER — The number of minutes after the interface has cut
over successfully that the reconciliation message is created.
This field has a default value of 0 when an ICFE record is added, and the operator
can modify this value to any value between 0 and 999. However, the interface
process uses a value of 20 minutes in processing when this field is set to a value of
0.
00 = None
01 = SNA/CICS Protocol
02 = Bisync Multipoint Protocol
03 = X.25 Protocol
04–99 = Reserved for future use
SELL RATE — The rate used to calculate the settlement amount in the shared
currency when the BASE24 network is acting as the issuer. This rate is used when
the shared currency is different from the local currency of the issuer.
The first digit of this field is a scale factor indicating where the decimal should be
placed from the end of the field. The remaining seven characters represent the
conversion factors used to multiply the amounts to convert to settlement or local
amounts.
BUY RATE — The rate used to calculate the settlement amount in the shared
currency when the BASE24 network is acting as the acquirer. This rate is used
when the shared currency is different from the local currency of the acquirer.
The first digit of this field is a scale factor indicating where the decimal should be
place from the end of the field. The remaining seven characters represent the
conversion factors used to multiply the amounts to convert to settlement or local
amounts.
PRODUCT INDICATOR
ICFE Screen 13
ICFE screen 13 is an interchange-specific screen used exclusively by the BIC ISO
Interface process. It describes the stations associated with the BIC ISO Interface
process. All fields on ICFE screen 13 can be used by the BIC ISO Interface
process. ICFE screen 13 is shown below, followed by a description of its fields.
The following fields contain the names of up to 20 stations and the type of each
station with which the BIC ISO Interface process is associated. The stations
defined in the ICFE must also be defined in the XPNET system.
TYPE — A flag indicating the type of station the interface can use. The type of
station must be either send/receive or receive only. Valid values are as follows:
0 = Send/receive
1 = Receive only
The following tables indicate the KEYF fields used by the BIC ISO Interface
process and the expected value. Values in quotation marks (“ ”) are literal values
that must be placed in the corresponding fields. The BIC ISO Interface process
does not use all the fields on all the KEYF screens. These fields are noted with Not
used in the Values column.
For documentation on the KEYF and KEY6 screens and their corresponding field
descriptions, refer to the BASE24 Base Files Maintenance Manual. For
information on BASE24 security, refer to the BASE24 Transaction Security
Manual.
Note: The information contained in the following tables does not indicate
whether a field is required, but rather if a field can be used if you so choose. The
field may or may not be required.
KEYF Screen 1
KEYF screen 1 defines the number of PIN and MAC keys currently being used by
the interface, the length of the key exchange keys (KEKs) used by the interface,
and the PIN and MAC exchange keys used by the interface. In addition, screen 1
contains security information used to set up the PIN and MAC parameters
associated with the BIC ISO Interface process. The fields on KEYF screen 1 used
by the BIC ISO Interface process and their expected values are indicated in the
following table.
KEYF Screen 1
Field Value
KEYF Screen 1
Field Value
KEYF Screen 1
Field Value
KEYF Screen 2
KEYF screen 2 contains inbound and outbound working key information for PINs
and MACs. The fields on KEYF screen 2 used by the BIC ISO Interface process
and their expected values are indicated in the following table.
KEYF Screen 2
Field Value
INBOUND KEYS: CURRENT INDEX 1 1 for the value in the PIN KEY1
field, or 2 for the value in the PIN
KEY2 field.
KEYF Screen 2
Field Value
INBOUND KEYS: CURRENT INDEX 1 1 for the value in the MAC KEY1
field, or 2 for the value in the
MAC KEY2 field.
KEYF Screen 3
KEYF screen 3 contains information on the timer, threshold, and processing
parameters used by the interface for Dynamic Key Management (DKM). It also
identifies the originator and receiver of DKM messages. The fields on KEYF
screen 3 used by the BIC ISO Interface process and their expected values are
indicated in the following table.
KEYF Screen 3
Field Value
KEYF Screen 3
Field Value
CLEAR OLD KEY TIMER VALUE 0 if the old key is not cleared or
1–9999 (seconds)
EMF Screens
This section contains a listing of EMF fields used by the BIC ISO Interface
process. In some EMF fields, the BIC ISO Interface process requires that specific
values be entered. In these cases, the required values are included in the
description. Each description also identifies the EMF fields used by the BIC ISO
Interface process for the screen being described.
Note: The information contained in the following descriptions does not indicate
whether a field is required, but rather if a field can be used if you so choose. The
field may or may not be required.
EMF Screen 1
EMF screen 1 allows the institution to change BASE24 message information.
When the key fields are completed appropriately and the F7 key is pressed, Ms
and Cs are displayed in the fields. An M indicates the data is mandatory and is
always included in the message. A C indicates the data is not mandatory but can
be included in the message. Some fields are left blank. This indicates the field is
not included in the message. All fields on EMF screen 1 can be used by the BIC
ISO Interface process.
The table below indicates the EMF fields used by the BIC ISO Interface process
and the expected value. Values in quotation marks (“ ”) are literal values that must
be placed in the corresponding fields.
EMF Screen 1
Field Value
EMF Screen 1
Field Value
Network management messages can be divided into two categories: those used to
manage the operational status of the communications lines between BASE24 and
the co-network, and those used to manage PIN and message authentication keys
between BASE24 and the co-network.
The BIC ISO Interface process supports the following four types of network
management messages:
?
Logon messages
?
Echo test messages
?
Logoff messages
?
Dynamic key management (DKM) messages
Network management messages are sent as 0800 messages and require 0810
messages in response.
This section describes the message flows that occur when network management
messages are sent.
Stations are marked up and down in the table depending on whether the BIC ISO
Interface process can communicate with them. For instance, if a station fails to
respond appropriately to a message, the BIC ISO Interface process checks the
maximum retries allowed for the co-network’s stations. If the maximum retries
allowed is reached, the BIC ISO Interface process marks the station down and
takes the necessary network management actions to reestablish the link with the
station. Once the link is reestablished, the BIC ISO Interface process marks the
station up.
The BIC ISO Interface process also tracks the status of the co-networks. A co-
network is marked as up if the BIC ISO Interface process can send messages to
and receive messages from at least one of the co-network’s stations. If all of the
stations to a co-network are marked down, the co-network itself is marked down.
Additionally, the BIC ISO Interface process tracks such things as whether the co-
network is logged off, whether store-and-forward processing is in progress for the
co-network, and whether a SAF extract is in progress for the co-network.
The BIC ISO Interface process keeps track of station and co-network information
at all times and logs a message when the status of the co-network changes (for
example, from up to down or at the start of store-and-forward processing).
Note: The BIC ISO Interchange Interface process only tracks the logical ability of
BASE24 to communicate with each station. If a station responds to a message, the
BIC ISO Interface process considers it to be up. If a station fails to respond to a
message the number of times specified in the MAXIMUM TIMEOUTS field on
ICFE screen 3, the BIC ISO Interface process considers the station to be down.
Also, echo test messages do not substitute for logon messages. The BIC ISO
Interface process does not consider the co-network to be logged on and available
for processing transactions until it receives a logon message.
Logon Messages
Logon messages are network management messages used to manage
communications access between BASE24 and a co-network. They are sent as
0800 messages and require 0810 messages in response.
The BIC ISO Interface process initiates logon messages at initialization and upon
receipt of a LOGON command from a network control facility.
At initialization, the BIC ISO Interface process sends a logon message to each
send/receive station.
Upon receiving a LOGON command from the network control facility, the BIC
ISO Interface process sends a logon message to each send/receive station
associated with the co-network indicated in the command.
After a period of being logged off, co-networks can send logon messages to log on
to BASE24.
If the BIC ISO Interface process receives a logon message after the co-network has
been logged off, the BIC ISO Interface process marks the co-network as logged on
and begins sending echo test messages to its stations. The BIC ISO Interface
process then returns a logon response to the co-network. If the BIC ISO Interface
process receives a logon message when the co-network is not logged off, it simply
returns a logon response.
Note: In its responses, the BIC ISO Interface process always sets the Response
Code (P-39) field in the BASE24 external message to 00 to indicate an approval.
The BIC ISO Interface process initiates echo tests under the following
circumstances:
Co-networks can send echo test messages at any time. The BIC ISO Interface
process always returns an echo test response.
Note: In its responses, the BIC ISO Interface process always sets the Response
Code (P-39) field in the BASE24 external message to 00 to indicate an approval.
Logoff Messages
Logoff messages are network management messages used to stop communications
between BASE24 and a co-network. They are sent as 0800 messages and require
0810 messages in response.
BASE24 only attempts to reopen the link to a co-network that is logged off if a
logon command is received from a network control facility. The co-network, on
the other hand, can reopen the link at any time by sending a logon message.
Note: When a co-network is logged off, any transactions in progress are allowed
to complete.
If no logoff response is received, the BIC ISO Interface process still marks the co-
network as logged off, but keeps sending logoff messages to the co-network until a
response is received.
Upon receiving a logoff message, the BIC ISO Interface process marks the co-
network down and logged off and returns a logoff response to the co-network.
Note: In its responses, the BIC ISO Interface process always sets the Response
Code (P-39) field in the BASE24 external message to 00 to indicate an approval.
?
Change key
?
New key
?
Repeat key
?
Verify key
The change key and new key messages can be generated automatically as the
result of a defined threshold being surpassed. In addition, all of these messages
can be generated manually by an operator issuing a text command from a network
control facility. This section provides an overview of how dynamic key
management messages are used. For more information on dynamic key
management, refer to the BASE24 Transaction Security Manual. For more
information on using a network control facility to generate key management
messages, and for complete syntax of the text commands involved, see the
BASE24 Text Command Reference Manual.
A change key message requests that a key processor generate a new PIN
encryption or message authentication key. The receiving processor sends a
response to the change key message and then, in a separate action, generates the
new key and sends it to the requesting process in a new key message.
The BIC ISO Interface process sends this type of message to a co-network when
the co-network is responsible for generating a particular key and the BIC ISO
Interface process has determined that key needs to be changed. The BIC ISO
Interface process could make that determination based on a DKM threshold being
passed or in response to a KEY CHANGE command (the KEY CHANGE
command has the same effect as passing a DKM threshold).
The BIC ISO Interface process can receive this type of message from a co-network
when the BIC ISO Interface process is responsible for generating a particular key
and the co-network wants that key to be changed.
A new key message carries a new PIN encryption or message authentication key
between processors. The receiving processor verifies and begins using the new
key and returns a response to the key-generating processor indicating that the new
key has been implemented.
The BIC ISO Interface process sends this type of message to a co-network when
the BIC ISO Interface process is responsible for generating a particular key and
has either determined that key needs to be changed or been requested by the co-
network to change or repeat the key. This could occur as a result of a DKM
threshold being passed, notification from the co-network (using a change key or
repeat key message), or could occur in response to a KEY CHANGE command
(the KEY CHANGE command has the same effect as passing a DKM threshold).
The BIC ISO Interface process can receive this type of message from a co-network
when the co-network is responsible for generating a particular key and the co-
network has either determined that key needs to be changed or been requested by
the BIC ISO Interface process to change or repeat the key (using a change key or
repeat key message).
A repeat key message requests that a processor that generated a key resend that
key. The processor receiving the repeat key message obtains the requested key
from its database and sends it to the requesting process in a new key message. The
key itself is not changed, nor are any threshold counters affected.
The BIC ISO Interface process only generates a repeat key message as the result of
receiving a KEY REPEAT command. It responds to a repeat key message from
the co-network with a new key message carrying the requested key.
A verify key message requests that a processor that generated a key verify the key
by comparing check digits. The verify key message contains check digits for the
key in question, and the processor receiving the message compares the check digits
in the message with the check digits it has on file for the particular key. The
processor then responds to the verify key message with the results of the check
digit comparison. (If the check digits do not match, the processor that sent the
verify key message should use a change key message to request a new key.)
The BIC ISO Interface process only generates the verify key message as the result
of receiving a KEY VERIFY command. It responds to a verify key message from
a co-network, by comparing check digits for the specified key and returning the
results.
1. Establishes a successful logon with the co-network. At this point, the BIC
ISO Interface process can begin exchanging keys, but does not mark the co-
network up.
2. Exchanges message authentication keys with the co-network if message
authentication is being performed by the BIC ISO Interface process. This
allows the message authentication keys to be put in place prior to the
exchange of PIN keys.
3. Exchanges PIN keys with the co-network if PIN encryption is being
performed by the BIC ISO Interface process. This allows the PIN keys to be
put in place prior to transaction processing.
4. Marks the co-network up. At this point, transactions can be accepted from
and sent to the co-network.
Note: Since this sequence is only required and only occurs at initialization, it is
not included in the logon and key exchange sequences documented in this section.
BASE24-Initiated Logon
In this example, the BIC ISO Interface process logs on to the co-network.
BIC ISO 1
Interface Co-network
Process 3 22
1. If the BIC ISO Interface process cannot send network management messages
to the co-network (the NETWORK MANAGEMENT MESSAGE
ENABLED field on ICFE screen 3 is set to a value of N), the BIC ISO
Interface process marks each station up and the co-network as logged on. If
the BIC ISO Interface process can send network management messages to the
co-network (the NETWORK MANAGEMENT MESSAGE ENABLED field
on ICFE screen 3 is set to a value of Y), the BIC ISO Interface process sends
a logon message to each of the co-network’s send/receive stations. The logon
message is identified by the value 001 in the Network Management
Information Code (S-70) field of the BASE24 External Message. In addition,
the BIC ISO Interface process sets a Network Management Message timer for
each station, and marks each receive-only station up.
2. The co-network returns a logon response from each station. The logon
response is identified by the value 001 in the Network Management
Information Code (S-70) field of the BASE24 external message.
3. The BIC ISO Interface process receives each logon response and checks the
Response Code (P-39) field in the message.
a. If the Response Code field contains zeros, indicating an approval, the
BIC ISO Interface process marks the co-network as up and logged on.
The BIC ISO Interface process also marks the corresponding station up
and sets a Wait-for-Traffic timer for that station.
b. If the Response Code field does not contain zeros, the BIC ISO Interface
process logs a message, marks the co-network as logged off, and ceases
all attempts to communicate with the station. In order to reinstate
communications with the station, the co-network must send a message
from that station.
Co-Network-Initiated Logon
BIC ISO 22 1
Interface Co-network
Process 3
BASE24-Initiated Logoff
In this example, the BIC ISO Interface process logs off from the co-network.
BIC ISO 1
Interface Co-network
Process 3 22
Co-Network-Initiated Logoff
BIC ISO 1
Interface Co-network
Process 22
BIC ISO 1
Interface Co-network
Process 22
1. The co-network sends an echo test message from station A. The echo test
message is identified by the value 301 in the Network Management
Information Code (S-70) field of the BASE24 External Message.
2. The BIC ISO Interface process receives the message and performs the
following steps:
a. Returns an echo test response. The echo test response is identified by
the value 301 in the Network Management Information Code (S-70)
field of the BASE24 External Message.
b. Sends an echo test message and sets a Network Management Message
timer for each of the co-network’s send/receive stations that is down.
BIC ISO 22 1
Interface Co-network
Process 3
BIC ISO 1
Interface Co-network
Process 3 22
1. The BIC ISO Interface process creates a New Key message and sends it to the
co-network. To do this, the BIC ISO Interface process performs as follows:
a. Generates the new key and check digits.
b. Formats a Key Service Message (KSM) containing the new key and the
check digits.
c. Sends an 0800 message to the co-network with the network management
information code set to 162. This message includes the Cryptographic
Service Message data element (S-123) containing the KSM.
d. Sets an internal flag indicating that a key exchange is in progress for the
type of key being sent.
e. Starts a Network Management Message timer for the message. If this
timer expires before an 0810 response is received from the co-network,
the BIC ISO Interface process starts an Extended Network Management
Message timer for the message. If the Extended Network Management
Message timer expires, the BIC ISO Interface process resends the New
Key message.
2. The co-network receives the New Key message, processes it, and returns an
0810 response message with a network management information code of 162
to the BIC ISO Interface process. This message includes the Cryptographic
Service Message data element (S-123) containing either a Response Service
Message (RSM) or an Error Service Message (ESM).
3. The BIC ISO Interface process receives the 0810 response and processes it as
follows:
a. Verifies that the original 0800 message did not time out.
1) If the 0800 message timed out before the 0810 response was
received, the BIC ISO Interface process drops the message, and no
further steps are performed.
2) If the 0800 message has not timed out, processing continues with
the next step.
b. Clears the internal flag indicating that a key exchange is in progress.
c. Continues processing depending on the response code sent in the 0810
response message.
1) If the transaction was denied, the BIC ISO Interface process parses
the Cryptographic Service Message data element (S-123) to
determine why the new key was denied. In this case, the
Cryptographic Service Message data element contains an Error
Service Message (ESM).
a) If the ESM indicates the message was denied because the
BASE24 key counter does not match the key counter
maintained by the co-network, the BIC ISO Interface process
resets its key counter in the KEYF or KEY6 to the value sent
by the co-network. The BIC ISO Interface process then
resends the new key. Processing returns to step 1.
b) If the ESM indicates that any other error occurred, the BIC
ISO Interface process sends a message indicating the error to
the network logging facility and drops the 0810 response.
2) If the transaction was approved, the BIC ISO Interface process
updates the KEYF or KEY6 with the new key, check digit, and
counter information. The BIC ISO Interchange Interface
processBIC ISO Interchange Interface process also reinitializes its
internal key change threshold counters and timers.
BIC ISO 1
Interface Co-network
Process 3 22
1. When the BIC ISO Interface process receives the KEY REPEAT command, it
performs as follows:
a. Verifies that the syntax is correct and that dynamic key management is
supported. If the syntax is incorrect or dynamic key management is not
supported, the BIC ISO Interface process logs a message and drops the
command. If the syntax is correct and dynamic key management is
supported, the BIC ISO Interface process continues with the next step
(step 1b).
b. Determines whether a key exchange is in progress for the key in the
message. If a key exchange is in progress, the BIC ISO Interface
process logs a message and performs no further steps.
c. Sends an 0800 message to the co-network with the network management
information code set to 163. This message includes a blank
Cryptographic Service Message data element (S-123).
d. Starts a Network Management Message timer for the message.
2. The co-network receives the Repeat Key request and processes the message.
The co-network returns an 0810 with a network management information
code of 163 response to the BIC ISO Interface process. This message
includes the Key Service Message (KSM) in the Cryptographic Service
Message data element (S-123).
3. The BIC ISO Interface process receives the 0810 response and processes it as
follows:
a. Verifies that the original 0800 message did not time out.
1) If the 0800 message timed out before the 0810 response was
received, the BIC ISO Interface process drops the message, and no
further steps are performed.
2) If the 0800 message has not timed out, processing continues with
the next step.
b. Continues processing depending on the response code sent in the 0810
response message.
1) If the transaction was denied, the BIC ISO Interface process logs a
message and drops the 0810 message.
2) If the transaction was approved, the BIC ISO Interface process
performs as follows:
a) Verifies that the receiver and originator of the message are
correct. To verify the originator and receiver of the message,
the BIC ISO Interface process compares the receiver ID from
the KSM to the value from the ORIGINATING ID field on
KEYF screen 3 or KEY6 screen 4, and the originator ID from
the KSM to the value from the RECEIVING ID field on
KEYF screen 3 or KEY6 screen 4. If the receiver or originator
does not match the corresponding KEYF or KEY6 values for
this co-network, the BIC ISO Interface process logs a message
and drops the 0810 response.
b) Verifies the keys. To do this, the BIC ISO Interface process
translates the working key sent by the co-network and verifies
the check digits. The check digits generated as a result of
translating the key must match the check digits sent by the co-
network. If the BIC ISO Interface process cannot translate the
key or the check digits do not match, the BIC ISO Interface
process logs a message and drops the 0810 response.
c) Updates the KEYF or KEY6 with the new key and check digit
information.
BIC ISO 1
Interface Co-network
Process 3 22
1. When the BIC ISO Interface process receives the KEY VERIFY command, it
performs as follows:
a. Verifies that the syntax is correct and that dynamic key management is
supported. If the syntax is incorrect or dynamic key management is not
supported, the BIC ISO Interface process logs a message and drops the
command. If the syntax is correct and dynamic key management is
supported, the BIC ISO Interface process continues with the next step
(step 1b).
b. Determines whether a key exchange is in progress for the key in the
message. If a key exchange is in progress, the BIC ISO Interface
process logs a message and performs no further processing.
c. Sends an 0800 message to the co-network with the network management
information code set to 164. This message does not include the
Cryptographic Service Message data element (S-123).
d. Starts a Network Management Message timer for the message.
2. The co-network receives the Verify Key request and processes the message.
The co-network returns an 0810 with a network management information
code of 164 response to the BIC ISO Interface process.
3. The BIC ISO Interface process receives the 0810 response and processes it as
follows:
a. Verifies that the original 0800 message did not time out.
1) If the 0800 message timed out before the 0810 response was
received, the BIC ISO Interface process drops the message, and no
further steps are performed.
2) If the 0800 message has not timed out, processing continues with
the next step.
b. Continues processing depending on the response code sent in the 0810
response message.
1) If the transaction was denied (the Response Code data element
(P-39) contained the value 05), the BIC ISO Interface process logs
a message indicating the co-network denied the request and drops
the 0810 message.
2) If the transaction was approved (the Response Code data element
(P-39) contained the value 00), the BIC ISO Interface process logs
a message indicating that the command was successful and drops
the 0810 message.
3) If the Response Code data element (P-39) contained any other
value, the BIC ISO Interface process logs a message indicating that
the request failed and a Change Key request is required. The BIC
ISO Interface process drops the 0810 message.
ILF
ILF SAF
6. The BIC ISO Interface process formats an 0420 external message and logs
this message to the Store-and-Forward File (SAF) to be sent to the co-
network during store-and-forward processing.
7. If the text-level acknowledgment option is being used, the co-network sends
an 0430 message to the BIC ISO Interface process. Upon receipt of the 0430
message, the BIC ISO Interface process deletes the record from the SAF.
ILF
5. The BIC ISO Interface process deletes the outbound request timer, formats an
0210 internal message with a response code of 70 or 74, and sends it to the
BASE24 Authorization process. A response code of 70 (system failure) is
sent for BASE24-atm messages and a response code of 74 (unable to
authorize) is sent for BASE24-pos messages. The BIC ISO Interface process
also logs a copy of the transaction to the Interchange Log File (ILF).
ILF
1. A co-network sends a request to the BIC ISO Interface process in the 0100 or
0200 external message format.
2. The BIC ISO Interface process reformats the message into the 0200 internal
message format, sends the internal message to the BASE24 Authorization
process for authorization, and starts an inbound request timer to wait for a
response.
3. The BASE24 Authorization process sends the response to the BIC ISO
Interface process in the 0210 internal message format, indicating the message
failed due to a MAC generation error.
4. The BIC ISO Interface process deletes the inbound request timer, formats a
0210 external response message, sends the response to the co-network to be
completed, and logs a copy of the transaction to the Interchange Log File
(ILF).
ILF
1. A co-network sends a request to the BIC ISO Interface process in the 0100 or
0200 external message format.
2. The BIC ISO Interface process reformats the message into the 0200 internal
message format, sends the internal message to the BASE24 Authorization
process for authorization, and starts an inbound request timer to wait for a
response.
3. The BASE24 Authorization process sends the transaction response to the BIC
ISO Interface process in the 0210 internal message format.
4. The BIC ISO Interface process deletes the inbound request timer, formats a
0110 or 0210 external response message, returns the response to the co-
network to be delivered to the ATM or POS device, and logs a copy of the
transaction to the Interchange Log File (ILF).
5. The co-network returns a 0420 message to the BIC ISO Interface process,
indicating the transaction failed to complete as authorized due to a MAC
verification error.
6. The BIC ISO Interface process locates the ILF record for the original
transaction, updates the ILF with the reversal information, formats a 0420
internal message, and sends the internal message to the BASE24
Authorization process.
7. If the text-level acknowledgment option is being used, the co-network sends
an 0430 message to the BIC ISO Interface process.
22 BIC ISO 1
BASE24 33 4
Interface 4 Co-network
Authorization
Process 55 Process
4
ILF
1. A co-network sends a request to the BIC ISO Interface process in the 0100 or
0200 external message format.
2. The BIC ISO Interface process reformats the message into the 0200 internal
message format, sends the internal message to the BASE24 Authorization
process for authorization, and starts an inbound request timer to wait for a
response.
3. The BASE24 Authorization process sends the response to the BIC ISO
Interface process in the 0210 internal message format, indicating the message
failed due to a MAC verification error.
4. The BIC ISO Interface process rejects the message by placing a 9 in the first
position of the message type making it 9210. The BIC ISO Interface process
also places the bit number of the data element causing rejection in the
STATUS field of the BASE24 External Message header. The STATUS field
indicates the message failed due to a MAC verification error. The BIC ISO
Interface process sends the 9210 external message to the co-network. The
BIC ISO Interface process also logs a copy of the transaction to the
Interchange Log File (ILF).
Note: Similar MAC verification failures can occur for all message types
supported by the BIC ISO Interface process, not just 0200 messages (e.g., 0100,
0110, 0120, 0130, 0210, etc.).
The BIC ISO Interface process keeps track of each station and co-network. If a
message bound for a co-network cannot be transmitted, the BIC ISO Interface
process places the message in the Store-and-Forward File (SAF) for later
transmission. When communications with the co-network resume, the messages
in the SAF are sent to the co-network.
The store-and-forward cycle used by the BIC ISO Interface process is single-
threaded, so the oldest SAF records are sent to the co-network first. Records arrive
at the co-network in the same order in which they were added to the SAF.
Messages in the SAF are stored in the format that they are to be sent to the co-
network.
0120, 0220, 0320, 0402, 0402, 0420, 0520 and 0620 messages are placed in the
SAF if the intended co-network is marked down at the time the message is to be
sent. If the BIC ISO Interface process receives one of these message to be sent to
a co-network, but discovers the co-network is marked down, the BIC ISO Interface
process places the message in the SAF without attempting to send it to the co-
network.
In addition, these messages can be added to the SAF as the result of a recoverable
message authentication error. In this case, the link to the co-network may not be
down.
If the BIC ISO Interface process sends a 0120, 0220, 0320, 0402, 0420, or 0620
message to a co-network, but the message times out, the BIC ISO Interface process
changes the 0120 message to a 0121, 0220 to a 0221, 0320 to a 0321, 0420 to a
0421, or 0620 to a 0621 message and places it in the SAF. The 0402 is not
changed before it is placed in the SAF.
0100, 0110, 0200, 0210, 0300, 0310, 0600, and 0610 messages are interactive
messages and their timing is crucial. If they are not processed within a given
period of time, the transactions they represent are declined. Therefore, these
messages are not placed in the SAF.
0130, 0230, 0330, 0412, 0430, 0530, and 0630 messages are acknowledgments or
responses to other messages. Here again, timing is crucial. If a co-network does
not receive a required acknowledgment or response within a given time, the co-
network assumes that BASE24 never received the message and might then send it
again as a duplicate.
?
When the BIC ISO Interface process determines that the SAF record was
processed successfully by the co-network.
If a co-network must send text-level acknowledgments, the BIC ISO Interface
process uses the text-level acknowledgments to determine when the co-
network has processed the SAF records. If the co-network is not required to
send text-level acknowledgments, the XPNET process notifies the BIC ISO
Interface process that the message was sent successfully. In both of these
cases, the BIC ISO Interface process assumes the record was processed
successfully by the co-network and deletes the record.
?
When the BIC ISO Interface process determines that the SAF record cannot
be processed by the co-network.
If the message is returned as failed from the co-network or the same SAF
message has timed out the number of times specified in the MAX SAF
RETRY field on ICFE screen 3, the BIC ISO Interface process assumes the
co-network cannot process the message. In this case, the BIC ISO Interface
process writes the message to its log and deletes it from the SAF.
?
When the record is extracted from the SAF using the SAF extract.
Once a record is extracted to tape, the Super Extract process deletes it from
the SAF.
?
When a text-level or logical acknowledgment is received for a store-and-
forward message.
?
Each time a message is received from the co-network.
If there are store-and-forward messages to send, the BIC ISO Interface process
determines whether a SAF extract is in progress for the co-network. If a SAF
extract is not in progress, the BIC ISO Interface process begins sending the store-
and-forward messages.
The only messages affected in this case are 0402 and 0420 messages going to the
co-network. Instead of being sent to the co-network, these messages are placed in
the SAF to be sent at the end of the store-and-forward processing. This ensures
that a reversal will not reach the co-network before the original transaction.
BIC ISO 1
Interface Co-network
Process 3 2
1. The BIC ISO Interface process sends a store-and-forward message to the co-
network. To do this, it performs the following steps:
a. Reads a record from the SAF.
The BIC ISO Interface process selects the oldest record in the file for the
co-network. The record is a 0120, 0121, 0220, 0221, 0320, 0321, 0402,
0420, 0421, 0520, 0521, 0620, or 0621 message that is already in
external message format.
b. Sets a flag for the co-network to indicate that store-and-forward
processing is in progress. The BIC ISO Interface process performs this
step only on the first store-and-forward message processed.
c. Locates an available send/receive station and sends the message.
d. Sets a Store-and-Forward Message timer for the message.
e. Adds one to the count of store-and-forward messages outstanding.
2. The co-network processes the 0120, 0121, 0220, 0221, 0320, 0321, 0402,
0420, 0421, 0520, 0521, 0620, or 0621 message and returns a 0130, 0230,
0330, 0412, 0430, 0530, or 0630 message if text-level acknowledgments are
required. If text-level acknowledgments are not required, the XPNET
process notifies the BIC ISO Interface process when it has successfully sent
the message to the co-network.
3. Upon receipt of a 0130, 0230, 0330, 0412, 0430, 0530, or 0630 message or
notification from the XPNET process that the store-and-forward message was
sent, the BIC ISO Interface process performs the following steps:
a. Locates and deletes the corresponding record in the SAF.
b. Subtracts one from the number of store-and-forward messages
outstanding.
c. Determines whether more SAF records need to be sent. If more SAF
records need to be sent, the BIC ISO Interface process begins again with
step 1. Otherwise, the BIC ISO Interface process continues processing
acknowledgments as they are received until no more store-and-forward
messages are outstanding. The BIC ISO Interface process then
terminates the store-and-forward processing and resets the flag for the
co-network, indicating that store-and-forward processing is no longer in
progress.
Failed Messages
If a message cannot be processed by a co-network, the message must be returned
with the first position of the message type set to 9.
The co-network can reject the message for several reasons, including retryable
message authentication errors (that is, key synchronization errors and security
device failures). If the message was rejected because of a retryable message
authentication error, the Status field in the external message header contains the
value 196 or 199. In this case, the BIC ISO Interface process resends the message
to the co-network.
When the BIC ISO Interface process receives a message from the co-network that
failed for any other reason, it performs the following steps:
Messages marked as failed by the XPNET process, rather than by the co-network,
are handled as if the messages timed out. For a description of this processing, refer
to the discussion on the Store-and-Forward Message timer in section 2.
This section describes how the BIC ISO Interface process handles various types of
transactions. It describes the basic flow of transaction processing and provides
transaction flow diagrams illustrating how messages to and from the co-network
are handled.
Note: Transaction flow diagrams for cutover messages are provided in section 6.
Introduction
The following transaction flows are described in this section. In most cases, these
flows are described twice—once when the message flow is initiated by BASE24
and once when the message flow is initiated by the co-network.
?
Requests
?
Reversals
?
Timeouts
?
Force Posts
?
Logon
?
Logoff
?
Echo Test
?
Requests containing error conditions
?
Responses
?
Reversals
?
Force posts
?
Reconciliation totals
Whenever a reversal occurs, the BIC ISO Interface process attempts to update the
ILF record already logged for the transaction. To do this, the BIC ISO Interface
process attempts to locate the original request/response message in the ILF.
Generally, BIC ISO Interface will search the current ILF only, meaning that a
reversal must be processed within hours or minutes of the original request
message.
Some interchanges mandate that acquirers and issuers must be able to reverse
certain POS transactions within 7 days of the original transaction taking place. For
consistency, the BIC ISO Interface process can be configured to support enhanced
ILF matching, which allows additional ILFs (which each contain transactions for
an approximate 24-hour period) to be held open. This function means that the BIC
ISO Interface process can locate the original POS request/response message in the
ILF when a reversal message is received up to 7 days later.
Some interchanges have different requirements for reversals of Card Present and
Card Not Present transactions. For example, acquirers and issuers may be required
to reverse a Card Present transaction within 24 hours of the original transaction
taking place, but may be required to reverse a Card Not Present (CNP) transaction
within 72 hours of the original transaction taking place.
The interface supports enhanced matching for a POS reversal via two configurable
parameters (one for acquirer processing and one for issuer processing). The POS-
ACQ-ILF-MATCH parameter specifies the number of previous ILFs the interface
shall search for the original transaction for a POS reversal in its acquirer
processing. The POS-ISS-ILF-MATCH parameter specifies the number of
previous ILFs the interface shall search for the original transaction for a POS
reversal in its issuer processing.
The interface supports enhanced matching for a CNP POS reversal via two
configurable parameters (one for acquirer processing and one for issuer
processing). The POS-ACQ-ILF-MATCH-CNP parameter specifies the number
of previous ILFs the interface shall search for the original transaction for a card not
present POS reversal in its acquirer processing. The POS-ISS-ILF-MATCH-CNP
parameter specifies the number of previous ILFs the interface shall search for the
original transaction for a card not present POS reversal in its issuer processing.
The value of each parameter overrides the value of the corresponding POS reversal
parameter (described above) in card not present transactions.
The additional ILFs are referenced only if at least one of the LCONF parameters is
set to a non-zero value. All four parameters default to zero, which results in
enhanced ILF matching not being performed.
The additional ILFs are used only to search for the associated request/response
when a reversal message is processed. They are not used for any other function,
such as calculating totals when a settlement message is processed, or checking for
a duplicate advice/reversal message.
Rejected Messages
If the BIC ISO Interface process receives an external message that it cannot
process or reformat for internal use, it rejects the message as follows:
1. Changes the first position of the message type to 9. For example, a 0200
message would be changed to a 9200 message, and a 0420 message would be
changed to a 9420 message.
2. Places the bit number of the data element causing rejection or the MAC
verification error encountered in the Status field of the BASE24 External
Message header. For example, if the Track 2 data in the P-35 data element
cannot be parsed, the Status field in the header would be set to 035.
3. Returns the message to the co-network.
These actions are taken on any message that cannot be processed, not just those
requiring a response.
Tracing Transactions
In order to trace transactions, the BIC ISO Interface process uses the Retrieval
Reference Number (P-37) from the external message. The Retrieval Reference
Number is assigned by a message initiator to uniquely identify a transaction. It is a
number that remains unchanged for all messages throughout the life of a
transaction.
Other data elements from the external message that can be used to trace
transactions are listed below. For additional information on these data elements,
refer to the BASE24 BIC ISO Standards Manual.
?
Transaction Amount (P-4)
?
Local Transaction Time (P-12)
?
Local Transaction Date (P-13)
?
Acquiring Institution Identification Code (P-32)
?
Track 2 Data (Primary Account Number) (P-35)
?
Requests
?
Reversals
?
Force Posts
?
Timeouts
ILF
1. A BASE24 Authorization process sends the request to the BIC ISO Interface
process in the 0200 internal message format.
2. The BIC ISO Interface process reformats the message into the 0100 or 0200
external message format, sends the external message to the co-network for
authorization, and starts an outbound request timer to wait for a response
from the co-network.
3. The co-network routes the transaction to the appropriate authorizer. After the
transaction has been approved, the co-network formats the response into the
0110 or 0210 external message format and sends it to the BIC ISO Interface
process.
4. The BIC ISO Interface process deletes the outbound request timer, formats a
0210 internal response message, sends the response to the BASE24
Authorization process to be delivered to the ATM or POS device, and logs a
copy of the transaction to the Interchange Log File (ILF).
BASE24 11 Co-network
BIC ISO 2
Authorization 44 Interface 3
Process 55 Process 66
7
44 66
ILF SAF
1. A BASE24 Authorization process sends the request to the BIC ISO Interface
process in the 0200 internal message format.
2. The BIC ISO Interface process reformats the message into the 0100 or 0200
external message format, sends the external message to the co-network for
authorization, and starts an outbound request timer to wait for a response
from the co-network.
3. The co-network routes the transaction to the appropriate authorizer. After the
transaction is approved, the co-network formats the response into the 0110 or
0210 external message format and sends it to the BIC ISO Interface process.
4. The BIC ISO Interface process deletes the outbound request timer, formats a
0210 internal response message, returns the response to the BASE24
Authorization process to be delivered to the ATM or POS device, and logs a
copy of the transaction to the Interchange Log File (ILF).
5. The BASE24 Authorization process returns a 0420 message to the BIC ISO
Interface process, indicating that the transaction failed to complete as
authorized. The BIC ISO Interface process locates the ILF record for the
original transaction and updates the ILF record with the reversal information.
6. The BIC ISO Interface process formats a 0420 external message and logs this
message to the Store-and-Forward File (SAF) to be sent to the co-network
during store-and-forward processing.
7. If text-level acknowledgment are required, the co-network sends a 0430
message to the BIC ISO Interface process. Upon receipt of the 0430
message, the BIC ISO Interface process deletes the record from the SAF. If
ILF SAF
1. A BASE24 Authorization process sends the request to the BIC ISO Interface
process in the 0200 internal message format.
2. The BIC ISO Interface process determines that the co-network is not
available and sends the message back to the BASE24 Authorization process
to be authorized.
3. The BASE24 Authorization process sends the BIC ISO Interface process a
force post message in the 0220 internal message format. If the transaction
was approved, the BIC ISO Interface process reformats the message into the
0220 external message format and adds the external message to the Store-
and-Forward File (SAF). A copy of the transaction is added to the
Interchange Log File (ILF). If the transaction was declined, the message is
dropped.
4. The BIC ISO Interface process sends the force post transaction to the co-
network using store-and-forward processing when the co-network becomes
available.
5. If the text-level acknowledgment option is being used, the co-network sends a
0230 message to the BIC ISO Interface process. Upon receipt of the 0230
message, the BIC ISO Interface process deletes the record from the SAF. If
text-level acknowledgments are not required, a logical acknowledgment must
be received. If a logical acknowledgment is not received, the record is
deleted from the SAF after the 0220 message is received.
ILF SAF
1. The BASE24 Authorization process sends the request to the BIC ISO
Interface process in the 0200 internal message format.
2. The BIC ISO Interface process reformats the message into the 0100 or 0200
external message format, sends the external message to the co-network for
authorization, and starts an outbound request timer to wait for the response
from the co-network.
3. When the timer expires before a response is received from the co-network,
the BIC ISO Interface process checks to determine whether stand-in
authorization is allowed.
a. If stand-in authorization is allowed, the BIC ISO Interface process
returns the transaction to a BASE24 Authorization process as a 0200
message with the RTE-STAT field set to indicate this condition.
b. If stand-in authorization is not allowed and this is a BASE24-pos
transaction, the BIC ISO Interface process checks the TIMEOUT
ACTION field in the Enhanced Interchange Configuration File (ICFE).
If this field is set to 2, the BIC ISO Interface process attempts to route
the transaction to an alternate destination.
c. If stand-in authorization is not allowed and this is a BASE24-atm
transaction, the BIC ISO Interface process attempts to route the
transaction to an alternate destination.
?
Requests
?
Reversals
?
Force Posts
?
Timeouts
ILF
1. The co-network sends the request to the BIC ISO Interface process in the
0100 or 0200 external message format.
2. The BIC ISO Interface process reformats the message into the 0200 internal
message format, sends the internal message to a BASE24 Authorization
process for authorization, and starts an inbound request timer to wait for the
response.
3. The BASE24 Authorization process sends the response to the BIC ISO
Interface process in the 0210 internal message format.
4. The BIC ISO Interface process deletes the inbound request timer, formats a
0110 or 0210 external response message, returns the response to the co-
network to be completed, and logs a copy of the transaction to the Interchange
Log File (ILF).
ILF
1. The co-network sends the request to the BIC ISO Interface process in the
0100 or 0200 external message format.
2. The BIC ISO Interface process reformats the message into the 0200 internal
message format, sends the internal message to a BASE24 Authorization
process for authorization, and starts an inbound request timer to wait for a
response from the BASE24 Authorization process that received the internal
message.
3. The BASE24 Authorization process sends the transaction response to the BIC
ISO Interface process in the 0210 internal message format.
4. The BIC ISO Interface process deletes the inbound request timer, formats a
0110 or 0210 external response message, returns the response to the co-
network to be delivered to the ATM or POS device, and logs a copy of the
transaction to the Interchange Log File (ILF).
5. The co-network returns a 0420 message to the BIC ISO Interchange Interface
process, indicating that the transaction failed to complete as authorized.
6. The BIC ISO Interface process updates the ILF record for the original
transaction, formats a 0420 internal message, and sends the internal message
to the BASE24 Authorization process.
7. If the text-level acknowledgment option is being used, the BIC ISO Interface
process sends a 0430 message to the co-network.
ILF
1. The co-network sends the BIC ISO Interface process a force post message in
the 0220 external message format.
2. The BIC ISO Interface process reformats the message into the 0220 internal
message format, sends the internal message to a BASE24 Authorization
process, and logs a copy of the transaction to the Interchange Log File (ILF).
3. If completion acknowledgments are required, the BIC ISO Interface process
sends the co-network a 0230 completion acknowledgment.
1. The co-network sends the request to the BIC ISO Interface process in the
0100 or 0200 external message format.
2. The BIC ISO Interface process reformats the message into the 0200 internal
message format, sends the internal message to a BASE24 Authorization
process for authorization, and starts an inbound request timer to wait for a
response from the Authorization process.
3. When the inbound request timer expires, the BIC ISO Interface process
formats a 0110 or 0210 external response message denying the transaction
and sends the 0110 or 0210 message to the co-network.
4. The BASE24 Authorization process sends a late 0210 response to the BIC
ISO Interface process. If the transaction was denied by the BASE24
Authorization process, the BIC ISO Interface process drops the late response.
5. If the transaction was approved, the BIC ISO Interface process formats a
0420 internal reversal message and sends the reversal to a BASE24
Authorization process.
This section describes BIC ISO Interface process cutover processing and report
generation. This includes detailed descriptions of the cutover message flows. This
section also provides samples of the reports generated for the BIC ISO Interface
process.
Introduction
Within the BASE24 system, interchange cutover processing is a management and
reporting function that produces reports for each business day. These reports are
provided to aid in reconciling the BASE24 network with the co-network. Cutover
processing occurs seven days a week.
If both BASE24-atm and BASE24-pos are present, the BIC ISO Interface process
determines when cutover should occur by comparing the cutover times set in the
LCONF for BASE24-atm and BASE24-pos. For example, if BASE24-atm cuts
over at 3:00 p.m. and BASE24-pos cuts over at 9:00 p.m., the BASE24-atm
Settlement Initiator process sends the BIC ISO Interface process a cutover
message at 3:00 p.m. When the BIC ISO Interface process receives the cutover
message, it updates the BASE24-atm processing date and compares the two
cutover times. Since BASE24-atm does not have the last cutover time for the day,
the interchange is not cut over. At 9:00 p.m., the BASE24-pos Main Settlement
process sends the BIC ISO Interface process a cutover message. When the BIC
ISO Interface process receives the cutover message, it updates the BASE24-pos
processing date and compares the two cutover times. Since BASE24-pos has the
last cutover time, the interchange is also cut over.
Note: Both the BASE24-atm Settlement Initiator process and the BASE24-pos
Main Settlement process are referred to as the “Settlement Initiator process”
throughout the message flows presented in this section.
Reversal debit amount — The total amount of all reversal debit transactions
Reversal debit count — The total number of all reversal debit transactions
Reversal credit amount — The total amount of all reversal credit transactions
Reversal credit count — The total number of all reversal credit transactions
Net settlement amount — The net settlement amount for the cutover date just
completed.
These totals are kept for the current processing date, the previous processing date,
and the next processing date. The totals kept by the BIC ISO Interface process are
sent to the co-network in the 0500, 0502, 0520, and 0522 reconciliation messages
and are used by the interchange report programs.
As each transaction is processed by the BIC ISO Interface process, the appropriate
totals are updated based on the type of transaction and the posting date for the
transaction. The following tables summarize how each transaction impacts the
totals listed above. For the purposes of impacting totals, force post transactions
are treated the same as normal transactions, and adjustments are treated the same
as reversals. A key to notations used in each table is provided immediately
following each table.
BASE24-atm Transactions
Transaction Reconcilation Totals
Amounts Counts
Transfer Reversals
Credit Reversals
Credit Reversals
Debit Reversals
Debit Reversals
Authorizations
Transfers
Inquiries
Credits
Credits
Debits
Debits
Withdrawal O +1
Withdrawal Reversal CA O +1
Deposit O +1
Deposit Reversal CA O +1
Split Deposit O +1
Transfer +1
Transfer Reversal +1
Payment From/To +1
Payment Enclosed O +1
Balance Inquiry +1
Key
O = Original transaction amount
CB = Cash back amount
CA = Actual completion amount of the transaction
RA = Replacement amount
+1 = Adds one to specified transaction count
BASE24-pos Transactions
Transaction Reconcilation Totals
Amounts Counts
Transfer Reversals
Credit Reversals
Credit Reversals
Debit Reversals
Debit Reversals
Authorizations
Transfers
Inquiries
Credits
Credits
Debits
Debits
Normal Purchase O +1
Preauthorization +1
Preauthorization CA +1
Completion
Preauthorization CA +1
Completion Reversal
Mail/Phone Order O +1
Merchandise Return O +1
Merchandise Return O +1
Reversal
Cash Advance O +1
Amounts Counts
Transfer Reversals
Credit Reversals
Credit Reversals
Debit Reversals
Debit Reversals
Authorizations
Transfers
Inquiries
Credits
Credits
Debits
Debits
Cash Advance Reversal O +1
Purchase Adjustment N OC +1
Purchase Adjustment N OC +1
Reversal
Merchandise Return OC N +1
Adjustment
Merchandise Return N OC +1
Adjustment Reversal
Check Guarantee O +1
Check Verification O +1
Balance Inquiry +1
Key
O = Original transaction amount
T = Total transaction amount—Purchase with cash back transaction (Purchase
amount + cash back)
OC = Original completed amount—Adjustment transactions
Key
CA = Completed amount—Preauthorization completion transaction
CB = Cash back amount—Purchase with cash back transaction
N = New amount—Adjustment transactions
+1 = Adds one to the specified transaction count
Each time the totals in the ITF are updated, the keys (i.e., addresses) of the last ILF
records included in the accumulated totals are recorded in the ITF with the totals
figures. (Since one ITF can represent totals from up to four ILFs, the totals are
accompanied by up to four ILF dates as well as the record address of the last
accumulated transaction in each of the ILFs.) During warmboot or process
initialization, the BIC ISO Interface process locates the last accumulated
transaction for each of the ILFs indicated in the ITF and reads from that record to
the end of the file, updating the totals in memory for the previous, current, and next
local BASE24 business days. In this way, the BIC ISO Interface process being
restarted can rebuild its memory-resident totals without having to read any ILF in
its entirety.
The ITF status flag tracks the overall progression of events during cutover
processing. Valid values are as follows:
0 = Normal
1 = Waiting for cutover acknowledgment
2 = Cutover message placed in the Store-and-Forward File (SAF)
3 = Ready to send totals
4 = Totals complete
The acquirer status flag tracks the status of acquirer processing. Valid values are
as follows:
0 = Normal
1 = Acquirer totals sent
2 = Acquirer settlement message placed in SAF
3 = Received acquirer acknowledgment
The issuer status flag tracks the status of issuer processing. Valid values are as
follows:
0 = Normal
1 = Issuer totals sent
2 = Issuer settlement message placed in SAF
3 = Received issuer acknowledgment
1. Updates the current business date for the product whose Settlement Initiator
process sent the cutover message.
2. Compares the cutover times found in the LCONF for the BASE24-pos and
BASE24-atm products to determine if the BIC ISO Interface process should
be cut over at this time. BIC ISO Interface process cutover occurs at the later
of the two cutover times.
If the BIC ISO Interface process should not be cut over at this time, no further
cutover steps are taken.
3. Checks to see if the cutover message has already been sent for this date by
comparing the date sent in the cutover message with the previous cutover date
the BIC ISO Interface process keeps in memory.
If the cutover message has already been sent, the BIC ISO Interface process
has already been cut over and no further cutover steps are taken.
4. Updates the reconciliation totals that are kept in memory. To do this, the BIC
ISO Interface process performs the following steps:
a. Moves the current day totals to the previous day totals.
b. Moves the next day totals to the current day totals.
c. Initializes the next day totals to zero.
5. Updates the reconciliation totals dates that are kept in memory. To do this,
the BIC ISO Interface process performs the following steps:
a. Sets the previous reconciliation totals date to the current processing date.
b. Initializes the next reconciliation totals date to blanks.
6. Checks the ICFE information stored in the Process Control Table (PCT) to
determine whether this BIC ISO Interface process is secondary to the co-
network.
The secondary network is not responsible for sending a cutover message to
the co-network. If this process is designated as a secondary network, no
further cutover steps are taken.
7. Formats a cutover message and sends it to the co-network.
8. Determines whether this BIC ISO Interface process is in the main network of
the co-network.
If this BIC ISO Interface process is not in the main network of the co-
network, equal partner settlement has been performed and no further steps are
needed.
If the BIC ISO Interface process is the main network, the BIC ISO Interface
process opens a new ILF and begins logging transaction records to the new
ILF.
1. If this BASE24 network is the main network, no further steps are taken.
2. Determines if a cutover message has already been processed for the co-
network’s processing date by comparing the date from the external message
with the co-network’s posting date kept in the PCT. If so, a message is logged
and no further cutover steps are taken.
3. Updates the current business date for the co-network.
4. Opens and begins logging transaction records to a new ILF.
5. Sends a cutover acknowledgment message to the co-network.
When both the BASE24 network and the co-network are equal partners, each
network informs the other network when cutover occurs. In addition, each
network must send the other network reconciliation totals.
When both networks are not equal partners, BASE24 must be identified as either
the main network or the secondary network in the ICFE. The co-network is either
main or secondary, whichever the BASE24 network is not. Secondary network
cutover must occur before the main network cutover. If it does not, incoming
transactions from the secondary network are denied by the main network.
ILF
1 22
3
4
8
9
1. The BIC ISO Interface process receives notification of cutover from the main
Settlement Initiator process on its network. This is the last cutover message
the BIC ISO Interface process receives for this business day; therefore, it is
BASE24 Interchange node cutover.
2. The BIC ISO Interface process sends an 0800 message with an information
code of 201 to the co-network. This 0800 message contains the business date
for the processing day just ended. The BIC ISO Interface process sets the ITF
status flag to a value of 1 (waiting for a cutover acknowledgment), sets a
cutover acknowledgment timer, and waits for a cutover acknowledgment. All
new requests are denied until the BIC ISO Interface process receives a
cutover acknowledgment message.
If no stations are available or if the cutover message times out, the cutover
message is placed in the Store-and-Forward File (SAF) as an 0820 network
management advice message. If this occurs, the BIC ISO Interface process
sets the ITF status flag to a value of 2 (cutover message placed in SAF).
ILF ILF
55 11
11
2
Co-
Co-network
BIC ISO 33
Interface
Process 44
3. At some point, the co-network sends reconciliation totals to the BIC ISO
Interface process. The co-network sends a type 0500 acquirer reconciliation
totals message to the BIC ISO Interface process.
4. The co-network sends a type 0502 issuer reconciliation totals message to the
BIC ISO Interface process.
Both the 0500 and 0502 totals messages contain totals for all shared activity
for the co-network date that is being cut over.
5. The BIC ISO Interface process logs the acquirer reconciliation totals to the
ILF with a record type of 90 for the business day just closed. The issuer
reconciliation totals are also logged to the same ILF with a record type of 91.
After the BIC ISO Interface process receives both acquirer and issuer totals, it
closes the ILF. The BIC ISO Interface process checks to make sure that no
duplicate reconciliation records are logged to the ILF.
6. The BIC ISO Interface process replies with a type 0510 acquirer
reconciliation acknowledgment message.
7. The BIC ISO Interface process replies with a type 0512 issuer reconciliation
acknowledgment.
ILF ILF
77 33
2
1
44
Co-
Co-network
88
99
1. The BIC ISO Interface process receives notification of cutover from the main
Settlement Initiator process on its network. This is the last cutover message
the BIC ISO Interface process receives for this business day; therefore, it is
BASE24 Interchange node cutover.
2. At some later time, the co-network cuts over and sends an 0800 message with
the information code set to 201 to the BIC ISO Interface process. This 0800
message contains the business date for the processing day just ended.
3. The BIC ISO Interface process creates and opens a new Interchange Log File
(ILF) the first time it receives the business date for the processing day just
ended from the co-network. When the BIC ISO Interface process receives the
0800 cutover message, it creates a new ILF with the new business date, if this
has not yet been done. The current day’s ILF becomes the previous day’s ILF,
and the next day’s ILF becomes the current day’s ILF. In addition to the ILF
parameters in memory and in the ICFE, the BIC ISO Interface process also
updates the ILF information in the ITF: ILF2 information moves to ILF1,
ILF3 information moves to ILF2, and ILF4 information moves to ILF3. A
new date is calculated for ILF4, but the file is not created until the first
transaction for that date arrives. During this update of the ITF, the totals
update is also performed.
4. The BIC ISO Interface process sends an 0810 cutover acknowledgment with
the information code set to 201 to the co-network.
5. At some point, the co-network sends reconciliation totals to the BIC ISO
Interface process. The co-network sends a type 0500 acquirer reconciliation
totals message to the BIC ISO Interface process.
6. The co-network also sends a type 0502 issuer reconciliation totals message to
the BIC ISO Interface process.
7. The BIC ISO Interface process logs the acquirer reconciliation totals to the
ILF with a record type of 90 for the business day just closed. The issuer
reconciliation totals are also logged to the same ILF with a record type of 91.
After the BIC ISO Interface process receives both acquirer and issuer totals, it
closes the ILF. The BIC ISO Interface process checks to make sure that no
duplicate reconciliation records are logged to the ILF.
8. The BIC ISO Interface process replies with a type 0510 acquirer
reconciliation acknowledgment message.
9. The BIC ISO Interface process also replies with a type 0512 issuer
reconciliation acknowledgment message.
ILF ILF
66 11
1
2
Co-
Co-network
33
4
BASE24 BIC ISO 55
Settlement Interface 77
Initiator Process
Process 88
11
11 10
10
1. The co-network cuts over. At some point after cutover, a 0200 financial
request message is sent to the BIC ISO Interface process containing the
business date for the processing day just started. The BIC ISO Interface
process opens a new Interchange Log File (ILF) when it receives the business
date for the processing day just started.
The current day’s ILF becomes the previous day’s ILF, and the next day’s ILF
becomes the current day’s ILF. In addition to the ILF parameters in memory
and in the ICFE, the BIC ISO Interface process also updates the ILF
information in the Interchange Totals File (ITF): ILF2 information moves to
ILF1, ILF3 information moves to ILF2, and ILF4 information moves to ILF3.
A new date is calculated for ILF4, but the file is not created until the first
transaction for that date arrives. During this update of the ITF, the totals
update is also performed.
2. The BIC ISO Interface process receives notification of cutover from the main
Settlement Initiator process on its network. This is the last cutover message
the BIC ISO Interface process receives for this business day; therefore, it is
BASE24 Interchange node cutover.
3. The BIC ISO Interface process sends an 0800 message with the information
code set to 201 to the co-network. This 0800 message contains the business
date for the processing day just ended. The BIC ISO Interface process sets
the ITF status flag to a value of 1 (waiting for a cutover acknowledgment),
sets a network management timer, and waits for a cutover acknowledgment.
All new requests are denied until the BIC ISO Interface process receives a
cutover acknowledgment message.
If no stations are available or if the cutover message times out, the cutover
message is placed in the Store-and-Forward File (SAF) as an 0820 network
management advice message. If this occurs, the BIC ISO Interface process
sets the ITF status flag to a value of 2 (cutover message placed in SAF).
4. The co-network sends an 0810 cutover acknowledgment message to the BIC
ISO Interface process with the information code set to 201. The BIC ISO
Interface process logs a message stating that the cutover acknowledgment
message has been received, deletes the network management timer, and sets
the ITF status flag to a value of 3 (ready to send totals).
In the event the co-network responds late with the 0810 network management
response to a cutover request, it is dropped. The BIC ISO Interface process
sends out an 0820 advice message, and the co-network sends back an 0830
advice response message. When the BIC ISO Interface process receives the
0830 response, it changes the ITF status flag to a value of 3 (ready to send
totals).
5. The BIC ISO Interface process sets a settlement interval timer to expire. This
allows all of the transactions for the old business day to finish. This time
interval is from the SETTLEMENT TIMER field on ICFE screen 12.
6. The BIC ISO Interface process closes the ILF.
7. When the settlement interval timer expires, the BIC ISO Interface process
sends reconciliation totals to the co-network. The BIC ISO Interface process
sends a 0500 acquirer reconciliation totals message to the co-network and
logs a message stating that the acquirer reconciliation totals were sent. The
BIC ISO Interface process sets the acquirer status flag in the ITF to a value of
1 (acquirer totals sent), sets a network management timer, and waits for an
acquirer settlement acknowledgment message.
If no stations are available or if the acquirer reconciliation totals message
times out, the acquirer reconciliation message is placed in the Store-and-
Forward File (SAF). If this occurs, the BIC ISO Interface process sets the
0532 advice response message. When the BIC ISO Interface process receives
the 0532 response, it changes the issuer status flag in the ITF to a value of 3
(received issuer acknowledgment).
11. The BIC ISO Interface process checks the issuer and acquirer status flags to
see if they are both set to 3 (acknowledgments received). If they are both
equal to a value of 3, the BIC ISO Interface process sets the ITF status flag to
a value of 4 (totals complete).
Starting Reports
The BIC ISO Interface process is responsible for starting the interface reports. It
does so by creating an obey file to start the report programs and then running the
obey file automatically at the appropriate time.
Using the time specified in the LCONF param SW-RPT-STARTUP, the BIC ISO
Interface process sets a timer to expire when the reports are to be run. When the
timer expires, the BIC ISO Interface process creates and runs an obey file
containing the Tandem Advanced Command Language (TACL) commands
necessary to run the report programs.
Under normal circumstances, the report programs start and stop without operator
intervention. However, if the BIC ISO Interface process does not start the
programs, they can be started manually by running the report obey file created by
the BIC ISO Interface process from a TACL prompt.
If the report programs abend or fail, they can be restarted in the same way.
Report Overview
The BIC ISO Interface process produces two reports of interchange transaction
activity. These reports are the SETL01-BIS Clearings Statement Report and the
STAT09-BIC Transaction Detail Report. These reports can be used in conjunction
with BASE24-atm and BASE24-pos reports to reconcile the differences between
the BASE24 processing day and the co-network processing day.
This report contains the totals of all transactions logged to the ILF. Reconciliation
records are logged to the ILF with a record type of 90 for acquirer reconciliation
records and a record type of 91 for issuer reconciliation records.
The BIC ISO Interface process calculates totals as an acquirer and as an issuer, and
the transaction type determines whether it is a debit or a credit. Withdrawals and
normal purchases are always counted as debits, and deposits are always treated as
credits.
The report includes a section for transactions that occurred during the BASE24
processing day that did not occur during the co-network processing day. These
transactions are subtracted from the transaction totals for the BASE24 processing
day. This section provides two pieces of information: the net amount of
transactions and the dollar difference between transactions occurring during the
BASE24 processing day that did not occur during the co-network processing day.
Next, a section shows transactions that occurred during the co-network processing
day that did not occur during the BASE24 processing day. These transactions are
added to the transaction totals for the BASE24 processing day. This section
provides two pieces of information: the net amount of transactions and the dollar
difference between transactions occurring during the co-network processing day
that did not occur during the BASE24 processing day.
Once the report program has calculated the debit and credit positions, it compares
the report credits and debits to the reconciliation records. If there are any
discrepancies, a separate page is printed showing the calculated figures and all the
figures received from the co-network.
A sample of the SETL01-BIS Clearings Statement Report for BIC ISO is shown
on the following pages, followed by descriptions of the fields that appear on the
report.
6-27
Report Overview
6-28
SETL01-BIS CLEARINGS STATEMENT REPORT FOR BIC ISO 1 DATE YY/MM/DD
PAGE 2
-----------------------------------------------------------------------------------------------------------------------------------
TRAN DATE DEBIT CREDIT NET
--------- -------------------- ---------------- ----------------------
6-29
Report Overview
6-30
SETL01-BIS CLEARINGS STATEMENT REPORT FOR BIC ISO 1 DATE YY/MM/DD
PAGE 4
-----------------------------------------------------------------------------------------------------------------------------------
TRAN DATE DEBIT CREDIT NET
--------- -------------------- ---------------- ----------------------
6-31
Report Overview
Cutover and Reporting
<LNET> TODAY
The settlement position of the logical network to the co-network for the day this
report is produced.
TRAN DATE — The Interchange Log File (ILF) date (YY/MM/DD) to which
these transactions belong.
DEBIT — The dollar amount the logical network owes the co-network according
to the co-network. Co-network debits include the following:
?
Deposits by co-network cardholders at terminals owned by a BASE24
institution.
?
Withdrawals and cash advances by cardholders belonging to a BASE24
institution at co-network terminals.
CREDIT — The dollar amount the co-network owes the logical network
according to the co-network. Co-network credits include the following:
?
Withdrawals and cash advances by co-network cardholders at terminals
owned by a BASE24 institution.
?
Deposits by cardholders belonging to a BASE24 institution at co-network
terminals.
NET — The net position of the logical network to the co-network according to the
co-network, (credits minus debits). A minus sign (–) indicates a debit position, or
the amount owed to the co-network.
SPAN TODAY
This section summarizes the net position of the logical network to the co-network.
However, if there are multiple logical networks present in the BASE24 system,
this section summarizes the net position of each logical network to the co-network.
COMPUTED TOTALS
This section summarizes the totals computed by the BIC ISO Interface process.
DEBITS COUNT
DEBITS AMOUNT — The total number and amount of all debit transactions.
CREDITS COUNT
CREDITS AMOUNT — The total number and amount of all credit transactions.
DEBITS COUNT
DEBITS AMOUNT — The total number and amount of all acquirer debit
transactions.
CREDITS COUNT
CREDITS AMOUNT — The total number and amount of all acquirer credit
transactions.
DEBITS COUNT
DEBITS AMOUNT — The total number and amount of all issuer debit
transactions.
CREDITS COUNT
CREDITS AMOUNT — The total number and amount of all issuer credit
transactions.
This report contains one detail item for each transaction processed by the BIC ISO
Interface process during its processing day. The information provided for each
transaction includes the cardholder number, transaction type, transaction time,
posting date, and all transaction amounts.
PAGE 01
------------------------------------------------------------------------------------------------------------------------------------
CARDHOLDER NUMBER TRAN DESC PST DAT B24 DAT-TIM B24 RESP CRD LN ATM FROM ACCT #/POS ACCT # TRAN/BAL/ORIG AMOUNT
12345644000004 W/D FROM SAV 861001 MMDD-HHMMSS 7 000 BIC1 0000000000000000000000000000 .00-
R4D1 S1A91004 001059 056 MMDD-HHMMSS A001 00 0000000000000000000000000000 .00-
0000000000000000000000 ACI OMAHA NE ATM 420 420
0.00- 0.00- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<<<<<<<<<<<REVERSAL LAST UPDATE MM/DD HH:MM
12345644000004 W/D FROM SAV 861001 MMDD-HHMMSS 7 000 BIC1 0000000000000000000000000000 .00-
PRO1 S1A91004 001060 057 MMDD-HHMMSS A001 00 0000000000000000000000000000 .00-
0000000000000000000000 ACI OMAHA NE ATM 210 210
0.00- 0.00- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
6-37
Report Overview
6-38
STAT09-BIC TRANSACTION DETAIL REPORT FOR BIC ISO 1
DATE YY/MM/DD
PAGE 02
ATM TRANSACTION SUMMARY
------------------------ APPROVALS DENIALS
PST DAT — The Interchange Log File (ILF) date assigned to this transaction
according to the interchange reporting day.
B24 DAT-TIM — The date and time this transaction occurred according to the
BASE24 reporting day. This date determines whether this transaction is
considered to be part of today’s business.
B24 RESP — The first digit indicates the entity responsible for authorizing this
transaction. The next three digits indicate the response action taken for this
transaction.
SWI DAT-TIM — Date and time of this transaction according to the interchange
reporting day.
SWI RESP — Response code indicating the action taken for this transaction,
assigned by the interchange.
ATM TO ACCT #/POS APPR CODE — The account to which this transaction
was made if this is a BASE24-atm transaction. If this is a BASE24-pos
transaction, this field contains the approval code.
PRD — The product identifier indicating what type of product initiated this
transaction (i.e., BASE24-atm or BASE24-pos).
B24 TYP — The message type the BASE24 system assigned to this transaction.
SWI TYP — The message type the interchange assigned to this transaction.
SPLIT DEP AMT 1 — The first amount involved in a split deposit transaction.
MICR — The magnetic ink character recognition (MICR) data from the check
involved in this transaction.
This appendix provides information on the configuration of the BIC ISO Interface
process. It also describes the processing involved for initialization and network
control.
Startup
The BIC ISO Interface process should be assigned a startup logic of AUTOMATIC
in the XPNET system. AUTOMATIC means that the BIC ISO Interface process is
started automatically when the XPNET node is initiated. This ensures that the BIC
ISO Interface process is ready when it receives its first transaction.
Event Messages
Event messages are routed to certain destinations, based on the routing code that
appears in the event messages. The BIC ISO Interface process routes all of its
event messages with a standard routing code of zero.
The BIC Interface process generates event messages to assist network operators in
performing their daily tasks. Event messages are unsolicited messages generated
by BASE24 processes that provide information regarding the internal condition of
the system. They are a network operator’s primary link to what is actually
occurring in the system. Event messages provide operators with information
ranging from system status, such as the completion of a procedure, to more serious
circumstances requiring operator intervention.
ACI has developed a method that allows customers to access event message
documentation electronically. Event messages are contained in files on a
designated HP NonStop volume and subvolume. Each file contains event
messages for a specific BASE24 process. Files on the designated HP NonStop
volume and subvolume are organized according to product module ID (PMID).
One PMID exists for every BASE24 process. PMIDs identify a specific process in
the BASE24 system (e.g., SWBICI identifies the BIC ISO Interface process).
Providing event message documentation in files on the HP NonStop computer
gives customers greater flexibility by allowing them to print event message
documentation as needed at their location to suit their requirements.
Documentation is available in file form for the event messages generated by the
BIC ISO Interface process. It is located on the HP NonStop SWxxBABI
subvolume in a file named BABILOGM, where xx is the number of the current
release. For a complete explanation of event message documentation, refer to the
BASE24 Event Message Reference Manual.
Initialization
The following steps are taken by the BIC ISO Interface process when it is first
started. To initialize, the BIC ISO Interface process performs as follows:
1. Reads the name of its LCONF. The startup message from the XPNET
process contains the name of the LCONF. This name allows the BIC ISO
Interface process to access the LCONF for the assigns and params it needs for
processing.
2. Opens the LCONF and reads the following assigns and params. If an error
occurs, the BIC ISO Interface process generates an event message and
abends.
Assigns Params
APCFEMT ATM-LN-CUTOVER
EMF ACCT-NUM-TYP
ICF ATM-DISCR-DATA-STM-SUPPRS
ILF ENHANCED-CRNCY-CONV
IPCFEMT ENHANCED-EMV-RC-MAPPING
ITF DATE-DISPLAY-TYPE
KEY6 DES-TRIPLE-SINGLE
KEYF ILF-NOTIFY-INTERVAL
LMCF ILF-NOTIFY-PERCENTAGE
RPT OVRRD-INST-ID-FLDS
RPT-ERROR-FILE POS-ACQ-ILF-MATCH
SAF POS-ACQ-ILF-MATCH-CNP
SW-RPT-OBEY-FILE POS-DISCR-DATA-PSTM-SUPPRS
SW-RPT01-PROG-NAME POS-ISS-ILF-MATCH
SW-RPT09-PROG-NAME POS-ISS-ILF-MATCH-CNP
Assigns Params
TKN POS-LN-CUTOVER
POS-B24-TO-POS-ACCT-TYP-SUPPRS
PRE-VERIFIED-PIN-PAD-CHAR
PSEUDO-3DES-CBC-MAC-TYPE
RACAL-ANSI-METHOD
REVERSAL-BAL-INQ
RSM-TERM-MASTER-KEY
SAF-NOTIFY-INTERVAL
SAF-NOTIFY-PERCENTAGE
SEND-ETX
SPAN-FLAG
SWI-ACQ-AVS-DATA-SUPPRS
SWI-ACQ-CVD2-DATA-SUPPRS
SWI-ACQ-DISCR-DATA-SUPPRS
SWI-ISS-AVS-DATA-SUPPRS
SWI-ISS-CVD2-DATA-SUPPRS
SWI-ISS-DISCR-DATA-SUPPRS
SW-ILF-FILE-RETENTION
SW-RPT-STARTUP
UPDT-ILF-ON-LATE-RESP
3. Reads the LMCF for its modified event messages. The LMCF contains a
record for each modified event message in the system. The BIC ISO
Interface process opens the LMCF, retrieves its modified event messages, and
closes the LMCF. Whenever the BIC ISO Interface process generates an
event message, it checks the LMCF records in memory to determine whether
the message requires modification.
24. Starts the ITF interval timer if the BIC ISO Interface process is set up to keep
totals.
25. If the automatic logon option was selected, sends a logon message to the co-
network.
a. Sends a MAC and PIN key change messages.
b. Starts timers for PIN and MAC key changes.
26. Closes the LCONF and waits for a message from the co-network or a local
BASE24 Authorization process.
27. Closes the TKN.
For detailed descriptions and the syntax of all network control commands, refer to
the BASE24 Text Command Reference Manual.
?
ALTERATTRIBUTE. Directs the BIC ISO Interface process to warmboot
(reallocate) a specified shared extended memory table after it has been
rebuilt. Whenever a shared extended memory table is modified, all processes
that read the table must reallocate the table before the modified data is used in
transaction processing. The Process Control Terminal (PCT) Server process
automatically sends this command to each process specified in an EMT
warmboot notify list param in the Logical Network Configuration File
(LCONF) when a network operator enters an ALTERATTRIBUTE command
from a network control facility. If the command completes successfully, a
message stating that the EMT warmboot completed successfully is displayed
on the network log.
?
CUTOVER. Initiates interchange cutover. The steps taken to cut over the
interchange depend on whether the co-networks are equal partners or one
network is the main network and the second network is the secondary
network. Cutover processing and cutover message flows are described in
section 5.
?
DEVICE STATE. Process-generated commands that inform the BIC ISO
Interface process of the current state of communications between the network
and the co-network.
?
DEBUG. Places the BIC ISO Interface process in the DEBUG state. The
debug message places the BIC ISO Interface process into Inspect and brings
up an Inspect prompt on the home terminal (the terminal on which the
network was brought up). Inspect is an HP NonStop programming tool. This
command should only be used to interactively debug a running process when
in a test environment. Executing this command in a production environment
can result in a significant impact on system performance.
?
DUMP. Directs the BIC ISO Interface process to request a programmatic
dump. A snapshot dump is taken which can then be read using RDEBUG.
?
KEY CHANGE. Requests made by a secondary network or co-network that
a PIN or MAC working key be generated by the other BIC processor. The
other BIC processor can be either a main network or another co-network. If
this command is entered and the BIC ISO Interface process specified is in the
main or co-network whose outbound key requires changing, a new PIN or
MAC working key is generated.
Operators can specify whether to change the inbound, outbound, or both keys
for either PIN or MAC working keys associated with the BIC ISO Interface
process. Co-networks are only responsible for generating their outbound
keys. This command is used with dynamic key management (DKM).
?
KEY REPEAT. Requests that a PIN or MAC key be repeated. This
command is used with DKM and can only be initiated by the secondary
network or co-network to repeat their inbound key.
?
KEY VERIFY. Requests that a PIN or MAC key be verified. This command
is used with DKM and can only be initiated by the secondary network or co-
network to verify their inbound key.
?
LOGOFF. Initiates a logoff sequence for one or more stations. It causes the
BIC ISO Interface process to send a logoff message to each station indicated
in the message.
?
LOGON. Initiates a logon sequence for one or more stations. It causes the
BIC ISO Interface process to send a logon message to each station indicated
in the message.
?
PERFORMANCE. Requests that the performance statistics kept in memory
by the BIC ISO Interface process be sent to the log. The BIC ISO Interface
process tracks performance statistics for each station assigned to it. The
statistics are displayed for the BIC ISO Interface process as a whole. These
statistics are gathered on an interval basis—the interval length being
established in the ICFE—and statistics are available for the last five intervals.
Performance monitoring statistics commands are used to stop and start
performance monitoring.
?
STATUS. Requests the status of the BIC ISO Interface process. The
requested information is sent to the current logging facility.
?
SWL. Changes the event message logging facility from the current facility to
the indicated facility.
?
TOTALS. Requests current information regarding totals for transaction
activity. The requested information is sent to current logging facility. Totals
can be displayed for either the acquirer or the issuer.
?
TRACE OFF. Stops the trace function within the BIC ISO Interface process.
For a description of the trace function, please refer to the TRACE ON
message description.
?
TRACE ON. Starts a trace function within the BIC ISO Interface process.
This trace function generates event messages at periodic intervals while the
trace function is enabled. The event messages display the name of the
procedure from which it was written or other helpful processing information.
The trace function should only be enabled in a test environment. Enabling the
trace function in a production environment can result in a significant impact
on system performance.
?
WARMBOOT. Warmboots the BIC ISO Interface process. Warmboot
processing is similar to process initialization, except that the BIC ISO
Interface process closes all open files after they have been successfully
reopened. If an error is encountered, the old environment is restored.
A E
Acquirer Processing Code File (APCF), 1-17 Echo test messages
Acquirer Processing Code File (APCF) extended from a co-network, 3-4, 3-15
memory table, processing for interchange acquirer from BASE24, 3-4
transaction profiles, 2-48 Encryption type
Acquirer transaction profile, 2-48 BASE24, 2-40
co-network, 2-40
Automatic logon, A-8 message authentication, 2-44
Enhanced Interchange Configuration File (ICFE)
B control files, 1-17
initialization, A-6
BASE24 Interchange
BASE24-atm Standard Internal Message (STM), 1-7 Event messages, A-3
BASE24-pos Standard Internal Message External Message File (EMF)
(PSTM), 1-7 control files, 1-17
BASE24-pos Address Verification, 1-22 full message authentication, 2-44
BIC ISO Interface process functions, 1-2 message authentication, 2-44
Extract Configuration File (ECF), 1-17
C
F
Check Authorization Routing File (CART), 1-17
Failed SAF messages, 4-4
Co-networks
forwarding SAF messages to, 4-4 File usage
logoff messages, 3-5 control files, 1-17
logon messages, 3-3 transaction files, 1-17
monitoring, 3-2 Five-day settlement, 1-25
Configuring Institution IDs, 2-51
Currency conversion support, 1-26 I
Cutover message flows Initialization
equal partner reconciliation/BASE24 cutover, 6-13 dynamic key management at, 3-9
equal partner reconciliation/co-network processing, A-4
cutover, 6-16
ITF status flags, 6-9 Interchange Log File (ILF)
main and secondary reconciliation when BASE24 is initialization, A-6
main, 6-20 logging to the ILF, 5-2
main and secondary reconciliation when BASE24 is transaction files, 1-17
secondary, 6-18 Interchange reporting, 1-21
Cutover processing Interchange Totals File (ITF)
BIC ISO totals, 6-3 BIC ISO totals, 6-8
transaction files, 1-17
D Issuer Processing Code File (IPCF), 1-17
Issuer Processing Code File (IPCF) extended memory
Dynamic key management (DKM) table, processing for interchange issuer transaction
at initialization, 3-9 profiles, 2-47
description, 1-24
Issuer transaction profile, 2-47
ITF status flags, 6-9
K N
Key 6 File Network control commands
control files, 1-17 cutover, A-10
Key File (KEYF) or Key 6 File (KEY6) debug, A-10
automatic logon, 2-50 dump, A-10
control files, 1-17 logoff, A-11
customer balance display, 2-50 logon, A-11
cutover relationship, 2-46 performance, A-11
defining stations, 2-50 status, A-11
full message authentication, 2-44 totals, A-11
message authentication, 2-44 trace off, A-11
product indicators, 2-50 trace on, A-11
reconciliation totals, 2-46 warmboot, A-12
sending a reconciliation message, 2-46 Network Environment File (NEF), 1-17
stand-in authorization, 2-49 Network Management messages
transactions allowed to co-network, 2-47 echo test messages, 3-4
updating the ITF, 2-46 logoff messages, 3-5
logon messages, 3-3
L
Log Message Configuration File (LMCF), A-5 P
Logical Network Configuration File (LCONF) PAD character used in PIN block, 2-41
assigns, 2-2 PAN characters used in PIN block, 2-41
control files, 1-17
params, 2-3 Performance monitoring support, 1-31
Logoff messages PIN block type, 2-41
from a co-network, 3-5, 3-14 PIN processing
from BASE24, 3-5, 3-13 specifying the key length, 2-42
Logon messages specifying the number of keys, 2-42
from a co-network, 3-3, 3-12 Process Control Table (PCT), A-6
from BASE24, 3-3, 3-10
R
M Rejected messages, 5-4
Message authentication Reports
data type, 2-44 SETL01-BIS Clearings Statement Report, 6-25
PIN management keys, 2-43 starting reports, 6-24
specifying the key length, 2-42 STAT09-BIC Transaction Detail Report, 6-36
specifying the number of keys, 2-42 Response codes mapping, 1-35
Message flows Routing code
echo test message, 3-15
event messages, A-3
force post messages from the co-network, 5-16
force post messages to the co-network, 5-10
link-down, 1-11 S
logoff message, 3-13, 3-14
logon message, 3-10, 3-12 Startup logic, A-2
normal, 1-9 Stations
request message from the co-network, 5-14 monitoring, 3-2
request message to the co-network, 5-7 selecting, 2-19
reversal from the co-network, 5-15 Store-and-Forward File (SAF)
reversal to the co-network, 5-8 deleting messages from, 4-4
store-and-forward transaction, 4-6 message processing, 4-6
timeouts of request messages from the co- messages not placed in the, 4-3
network, 5-17 messages placed in the, 4-2
timeouts of requests to the co-network, 5-11 transaction files, 1-17
Multiple Currency Support, 1-30 Store-and-forward messages
failed messages, 4-7
message format, 4-2
message forwarded to a co-network, 4-4
Store-and-forward processing
interspersed messages, 4-5
transmitting SAF messages, 4-2
with BIC ISO Interface processes, 4-1
Supported message types, 1-19
Supported transactions, 1-15
Surcharging support, 1-34
T
Timers
Extended Network Management Message
timer, 3-13, 3-14
ITF update timer, 2-34
Network Management Message timer, 3-10, 3-12,
3-13, 3-14, 3-15
report startup, 2-33
settlement interval timer, 2-33
Store-and-Forward Message timer, 4-6, 4-8
Wait-for-Traffic timer, 3-11, 3-12, 3-13, 3-14
Token File (TKN), 1-17