0% found this document useful (0 votes)
162 views250 pages

BASE24 BIC ISO Interface Manual

The document is the Release 6.0 v10 manual for BASE24® by ACI Worldwide, published in August 2014. It provides detailed information about the software's features, configuration, and supported transactions for electronic payments and banking. ACI Worldwide is a leading provider of electronic payment solutions, processing significant transaction volumes for financial institutions and retailers globally.

Uploaded by

manuelauna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
162 views250 pages

BASE24 BIC ISO Interface Manual

The document is the Release 6.0 v10 manual for BASE24® by ACI Worldwide, published in August 2014. It provides detailed information about the software's features, configuration, and supported transactions for electronic payments and banking. ACI Worldwide is a leading provider of electronic payment solutions, processing significant transaction volumes for financial institutions and retailers globally.

Uploaded by

manuelauna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 250

%,&,62,QWHUIDFH0DQXDO

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

© copyright ACI Worldwide 2014


Publish Date: August 2014
All information contained in this documentation, as well as the software described in it, is
confidential and proprietary to ACI Worldwide, Inc., or one of its subsidiaries, is subject to a
license agreement, and may be used or copied only in accordance with the terms of such license.
Except as permitted by such license, no part of this documentation may be reproduced, stored in
a retrieval system, or transmitted in any form or by electronic, mechanical, recording, or any
other means, without the prior written permission of ACI Worldwide, Inc., or one of its
subsidiaries.
ACI, ACI Payment Systems, the ACI logo, ACI Universal Payments, UP, the UP logo and all ACI
product names are trademarks or registered trademarks of ACI Worldwide, Inc., or one of its
subsidiaries, in the United States, other countries or both. Other parties' trademarks referenced
are the property of their respective owners.

Authorized distribution level: Available under NDA

About ACI Worldwide


ACI Worldwide, the Universal Payments Company, powers electronic payments and banking for
more than 5,000 financial institutions, retailers, billers and processors around the world. ACI
software processes $13 trillion in payments and securities transactions for more than 250 of the
leading global retailers, and 21 of the world's 25 largest banks. Through our comprehensive suite
of software products and hosted services, we deliver a broad range of solutions for payments
processing; card and merchant management; online banking; mobile, branch and voice banking;
fraud detection; trade finance; and electronic bill presentment and payment. To learn more about
ACI, please visit www.aciworldwide.com. You can also find us on Twitter @ACI_Worldwide.
Contents

What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Conventions Used in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. iii
Contents

Five-day Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25


Currency Conversion Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
Configuration Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27
Original Currency Release 6.0 Token. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
Multiple Currency Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
Performance Monitoring Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31
Surcharging Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34
Enhanced EMV Response Code Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35

2: Configuration and Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1


LCONF Assigns and Params . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Assigns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Params. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Configuring a Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Specifying Timer Lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Interspersing Store-and-Forward Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Sending Text-Level Acknowledgments to a Co-Network . . . . . . . . . . . . . . . . . . . 2-13
Expecting Text-Level Acknowledgments from a Co-Network . . . . . . . . . . . . . . . 2-13
Specifying Maximum Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Initiating Network Management Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Enabling Dynamic Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
Specifying Extract File Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Specifying Maximum Store-and-Forward Retries . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Specifying Maximum Outbound Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Specifying Maximum Inbound Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Defining Data Prefix Characters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Authorization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Setting Up Co-Network Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Station Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
Setting Up the ICFE Station Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Selecting Stations for Sending Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Configuring Data Suppression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Configuring Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Network Management Message Timer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22
Extended Network Management Message Timer. . . . . . . . . . . . . . . . . . . . . . . . . . 2-23

May-2014 R6.0v10 SW-DS004-01


iv ACI Worldwide, Inc.
Contents

Store-and-Forward Message Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24


Wait-for-Traffic Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Performance Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25
Outbound Request Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
Inbound Request Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Completion Acknowledgment Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28
Key Exchange Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Clear Old Key Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32
Report Startup Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
Settlement Interval Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33
ITF Update Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34
Configuring External Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-35
Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36
Changing the Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37
Configuring Tokens to be Sent in the External Message . . . . . . . . . . . . . . . . . . . . 2-39
Configuring Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
Co-Network Encryption Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
BASE24 Encryption Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
PIN Block Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
PAN Characters Used in PIN Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
PAD Character Used in PIN Block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41
Number of Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Key Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
PIN Key Variant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42
Key Processing Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
PIN Management Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-43
Configuring Message Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
Configuring Processing Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Cutover and Reconciliation Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Transactions Allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47
Stand-in Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49
Customer Balance Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Automatic Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Product Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Defining Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50
Configuring Institution IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. v
Contents

ICFE Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53


ICFE Screen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-53
ICFE Screen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54
ICFE Screen 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-55
ICFE Screen 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56
ICFE Screen 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57
ICFE Screen 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58
ICFE Screen 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59
ICFE Screen 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65
KEYF and KEY6 Screens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
KEYF Screen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67
KEYF Screen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70
KEYF Screen 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-72
EMF Screens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-74
EMF Screen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-74

3: Network Management and Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1


Monitoring Co-Networks and Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Logon Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Echo Test Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Logoff Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
Dynamic Key Management Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
Dynamic Key Management at Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
Interactive Network Management Message Flows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Logon Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
Logoff Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Echo Test Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Change Key Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16
New Key Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Repeat Key Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Verify Key Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
BASE24-Initiated Request—MAC Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
BASE24-Initiated Transaction Response—MAC Failure . . . . . . . . . . . . . . . . . . . 3-25
BASE24-Initiated Transaction Request—MAC Verification Failure . . . . . . . . . . 3-27
Co-Network-Initiated Transaction Request—MAC Failure. . . . . . . . . . . . . . . . . . 3-29
Co-Network-Initiated Transaction Response—MAC Failure . . . . . . . . . . . . . . . . 3-30

May-2014 R6.0v10 SW-DS004-01


vi ACI Worldwide, Inc.
Contents

Co-Network-Initiated Request—MAC Verification Failure . . . . . . . . . . . . . . . . . 3-31


Denied Request Initiated by BASE24—MAC Failure . . . . . . . . . . . . . . . . . . . . . . 3-32

4: Store-and-Forward Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1


The Store-and-Forward File (SAF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Messages Placed in the SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
Messages Not Placed in the SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3
Deleting Messages from the SAF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Forwarding SAF Messages to a Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Store-and-Forward Message Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Normal Store-and-Forward Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6
Failed Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

5: Transaction Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1


Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Logging to the ILF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Enhanced ILF Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Rejected Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Tracing Transactions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Message Flows to the Co-Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Request Message to the Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Reversal to the Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Force Post Messages to the Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Timeouts of Requests to the Co-Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Message Flows from the Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Request Message from the Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Reversal from the Co-Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15
Force Post Messages from the Co-Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16
Timeouts of Request Messages from the Co-Network. . . . . . . . . . . . . . . . . . . . . . 5-17

6: Cutover and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1


Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
BIC ISO Totals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Interchange Totals File (ITF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
Logging Reversals to the ITF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8
ITF Status Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. vii
Contents

Cutover Message Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10


BASE24 Settlement Initiator Process Sends Cutover Message . . . . . . . . . . . . . . . 6-10
Co-Network Sends Cutover Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Cutover Message Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Equal Partner Reconciliation and BASE24 Cutover . . . . . . . . . . . . . . . . . . . . . . . 6-13
Equal Partner Reconciliation and Co-Network Cutover. . . . . . . . . . . . . . . . . . . . . 6-16
Main and Secondary Reconciliation when the BASE24 Network is Secondary . . 6-18
Main and Secondary Reconciliation when the BASE24 Network is Main . . . . . . 6-20
Starting Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Report Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
SETL01-BIS Clearings Statement Report for BIC ISO . . . . . . . . . . . . . . . . . . . . . 6-25
STAT09-BIC Transaction Detail Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-36

A: BIC ISO Interface Process Startup and Control . . . . . . . . . . . . . . . . . . . . . . A-1


Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2
Event Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3
Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-4
Network Control Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Index-1

May-2014 R6.0v10 SW-DS004-01


viii ACI Worldwide, Inc.
What’s New

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

2 Adds the new params POS-ACQ-ILF-MATCH, POS-ACQ-ILF-MATCH-CNP,


POS-ISS-ILF-MATCH, and POS-ISS-ILF-MATCH-CNP to allow the BIC ISO
Interchange Interface to search additional ILFs when attempting to match a POS
reversal.

5 Updates the description of the “Logging to the ILF” process and adds the new
“Enhanced ILF Matching” description.

6 Updates the description for Cutover Message Flows.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. ix
What’s New

Section/ Major Changes


Appendix

A Adds the new LCONF params POS-ACQ-ILF-MATCH, POS-ACQ-ILF-


MATCH-CNP, POS-ISS-ILF-MATCH, and POS-ISS-ILF-MATCH-CNP in the
table of LCONF assigns/params read on initialization and updates step 14 of the
initialization process.

November 2011
Section/ Major Changes
Appendix

1 Clarifies processing of LCONF param ENHANCED-CRNCY-CONV

2 Clarifies definition of LCONF param ENHANCED-CRNCY-CONV

May-2014 R6.0v10 SW-DS004-01


x ACI Worldwide, Inc.
What’s New

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.

2 Adds the following LCONF params: 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, SEND-ETX, and UPDT-ILF-ON-LATE-RESP.
Updates the SETTLEMENT TIMER and ITF UPDATE INTERVAL fields on
Enhanced Interchange Configuration File (ICFE) screen 12 to better describe
default value processing.
Updates the procedures for using the External Message File (EMF) to correct the
value placed in the INTERF TYP field on an EMF screen for the BIC ISO
Interface.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. xi
What’s New

May-2014 R6.0v10 SW-DS004-01


xii ACI Worldwide, Inc.
Preface

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. xiii
Preface

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.

May-2014 R6.0v10 SW-DS004-01


xiv ACI Worldwide, Inc.
Preface

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

This manual also references the following NET24 publications:

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

In addition to the BASE24 and NET24 publications, this manual contains


references to the ISO 4217 standard, Codes for the Representation of Currencies
and Funds.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. xv
Preface

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 1, “Introduction,” provides basic information about the BIC ISO


Interface process and provides an overview of BIC ISO Interface functionality.

Section 2, “Configuration and Control,” describes the configuration and control


of the BIC ISO Interface process.

Section 3, “Network Management and Operations,” describes the network


management messages supported by the BIC ISO Interface process and provides
message flows that illustrate the processing that occurs when these messages are
sent.

Section 4, “Store-and-Forward Processing,” describes how the BIC ISO


Interface process performs store-and-forward processing. It includes information
about what messages can be placed in the SAF and when messages from the SAF
are sent. It also provides message flows that illustrate store-and-forward
processing.

Section 5, “Transaction Handling,” describes how the BIC ISO Interface process
handles various types of transactions.

Section 6, “Cutover and Reporting,” describes cutover processing and report


generation. Message flows describing how the BIC ISO Interface process handles
various types of cutover transactions are also included in this section.

Appendix A, “Startup and Control,” provides information about the


configuration of the BIC ISO Interface process. It also describes the processing
for initialization and network control.

May-2014 R6.0v10 SW-DS004-01


xvi ACI Worldwide, Inc.
Preface

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. xvii
ACI Worldwide, Inc.
Conventions Used in This 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

Field Length: 1 alphanumeric character


Required Field: Yes
Default Value: N
Data Name: ICFEBICI.ACQ-STAND-IN

Explanation

Each field description is completed by one or more of the following items of


information:

Item Description

Example Illustrates a possible entry for the field to further clarify the
value or values that can be entered.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. xix
Conventions Used in This Manual

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.

Occurs Indicates the number of times the field can be displayed on


the screen. This information is provided only when the
field can be displayed multiple times.

Required Field Specifies whether a value has to be entered in the field.


Possible values are Yes and No. Some fields are required
only under certain conditions. In this case, the entry is Yes,
followed by the conditions that determine when the field is
required.

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.

May-2014 R6.0v10 SW-DS004-01


xx ACI Worldwide, Inc.
1: Introduction

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-1
Introduction

BIC ISO Interface Process Overview


The BIC ISO Interface process, shown in the illustration on the next page, is
responsible for the online message transfer between BASE24 and its co-networks.
This process performs the following functions:

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

May-2014 R6.0v10 SW-DS004-01


1-2 ACI Worldwide, Inc.
BIC ISO Interface Process Overview

BIC ISO Interface Process

The BIC ISO Interface process translates


messages between the BASE24 internal message
format and an external format recognizable to
BASE24 hosts.

Internal External
Messages Messages

BASE24 BIC ISO


BASE24 BIC ISO
Authorization Interface
Authorization Interface
Process Process
Process Process

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-3
Introduction

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.

Issuer and Acquirer Co-Networks


In the financial industry, the terms issuer and acquirer define the parties on
opposite ends of the electronic message exchanges required to authorize and
process transactions.

Issuers are card-issuing or account-owning institutions or their agents. These


institutions or agents are responsible for authorizing cardholder transactions and
keeping track of cardholder accounts. Acquirers are the parties initiating
transactions on behalf of the card acceptors.

May-2014 R6.0v10 SW-DS004-01


1-4 ACI Worldwide, Inc.
BIC ISO Interface Process Overview

Co-networks acting on behalf of an issuer in a BASE24 message exchange are


referred to as issuer co-networks. Issuer co-networks authorize or post
transactions sent to them by the BASE24 system, as shown in the following
diagram.

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-5
Introduction

Co-networks acting on behalf of an acquirer in a BASE24 message exchange are


referred to as acquirer co-networks. Acquirer co-networks support ATM or POS
networks external to the BASE24 system and forward transactions to BASE24 for
authorization, as shown in the following diagram.

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.

May-2014 R6.0v10 SW-DS004-01


1-6 ACI Worldwide, Inc.
BIC ISO Interface Process Overview

Issuer and Acquirer Co-Network Support


The BIC ISO Interface process can function in the role of an issuer or an acquirer.
When the BIC ISO Interface process sends financial transactions to an issuer co-
network for authorization, the BIC ISO Interface process is representing the
transaction acquirer, even though the transaction may not have originated at a
BASE24-controlled terminal. When financial transactions are being sent to the
BIC ISO Interface process for authorization from an acquirer co-network, the BIC
ISO process is representing the card issuer, even though the BIC ISO process may
only forward the transaction to an issuer co-network for authorization.

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.

Internal Message Format


The internal message format is used whenever information is routed between the
BIC ISO Interface process and the rest of the BASE24 system. Depending on the
BASE24 product receiving the message, the internal message is commonly
referred to as the BASE24-atm Standard Internal Message (STM) or the
BASE24-pos Standard Internal Message (PSTM).

For more information on the STM or PSTM, see the BASE24-atm or BASE24-pos
transaction processing manual.

BIC ISO External Message Format


The structure and content of the external message used by the BIC ISO Interface
processes to communicate with their co-networks is patterned after the BASE24
external message. The BASE24 external message is based on the standard
external message developed by the International Organization for Standardization
(ISO). It is a variable-length, variable-content message that can be configured
differently, based on the type of message being sent. Specifications for how the
BIC ISO external message differs from the BASE24 external message can be
found in the BASE24 BIC ISO Standards Manual.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-7
Introduction

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.

When a co-network is unavailable, messages required as notification to the co-


network are stored in the Store-and-Forward File (SAF). These messages are then
transmitted later when communications are restored. For more information on
store-and-forward processing, see section 4.

Multiple Product Support


The same BIC ISO Interface process can be set up to process co-network messages
for multiple BASE24 products. If an institution purchases multiple BASE24
products, the appropriate product code is bound into the BIC ISO Interface process
to allow it to recognize and process transaction messages for each product.

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.

The remainder of this subsection provides an overview of transaction flows for


normal and link-down message processing.

May-2014 R6.0v10 SW-DS004-01


1-8 ACI Worldwide, Inc.
BIC ISO Interface Process Overview

Normal Message Flow

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

BASE24 BIC ISO


Co-network
Authorization Interface
Process Process

44 5 66

1. The co-network sends an external request message to the BASE24 system.


2. The BIC ISO Interface process translates the external request message into an
internal request message.
3. The BIC ISO Interface process sends the internal request message to the
BASE24 Authorization process for authorization.
4. The BASE24 Authorization process authorizes the request and sends an
internal response message to the BIC ISO Interface process.
5. The BIC ISO Interface process translates the internal response message into
an external response message.
6. The BIC ISO Interface process sends the external response message to the co-
network.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-9
Introduction

When a message from a BASE24 Authorization process is received by the BIC


ISO Interface process, it is translated from the internal message into the external
message format. The external message is then sent to the co-network to be
authorized. When the message has been processed, the co-network sends an
external response back to the BIC ISO Interface process. Using information from
the external message, the BIC ISO Interface process formats an internal response
message and sends it back to the BASE24 Authorization process.

The following diagram illustrates this outgoing message flow. Processing steps
are provided following the illustration

11 22 33

BASE24 BIC ISO


Co-network
Authorization Interface
Process Process

66 5 4

1. The BASE24 Authorization process sends an internal request message to the


BIC ISO Interface process.
2. The BIC ISO Interface process translates the internal request message into an
external request message.
3. The BIC ISO Interface process sends the external request message to the co-
network for authorization.
4. The co-network authorizes the request and sends an external response
message to the BIC ISO Interface process.
5. The BIC ISO Interface process translates the external response message into
an internal response message.
6. The BIC ISO Interface process sends the internal response message to the
BASE24 Authorization process.

May-2014 R6.0v10 SW-DS004-01


1-10 ACI Worldwide, Inc.
BIC ISO Interface Process Overview

Link-Down Message Flow

If stand-in authorization is allowed, the acquirer network has the option of


authorizing requests when the link to the issuer network is down. The BIC ISO
Interface process returns the request message to the BASE24 Authorization
process as a failed request needing offline authorization. If the transaction is
approved, a force post message is forwarded to the issuer network when the link is
reestablished. In the illustration below, BASE24 is the acquirer and the co-
network is the issuer.

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

1. The BASE24 Authorization process sends an internal request message to the


BIC ISO Interface process.
2. The BIC ISO Interface process determines that the link to the co-network is
down.
3. The BIC ISO Interface process returns the internal request message to the
BASE24 Authorization process.
4. The BASE24 Authorization process approves the transaction and sends an
internal force post message to the BIC ISO Interface process.
5. The BIC ISO Interface process translates the message into an external force
post message and stores the message until the link to the co-network is
restored.
6. The BIC ISO Interface process sends the external force post message to the
co-network.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-11
Introduction

If stand-in authorization is not allowed and an alternate destination is available, the


link-down situation is handled by using alternate routing to send the transaction to
the alternate destination. However, if stand-in authorization is not allowed and an
alternate destination is not available, the BIC ISO Interface process responds to a
link-down situation by denying all transactions until the link is reestablished.

May-2014 R6.0v10 SW-DS004-01


1-12 ACI Worldwide, Inc.
BIC ISO Networks

BIC ISO Networks


The main purpose of this manual is to describe the connection between a BASE24
system and a single co-network. However, it is possible to connect a BASE24
system to multiple co-networks. This type of a system requires a separate BIC ISO
Interface process for each co-network to which the BASE24 system is connected.

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

BIC ISO Interface BIC ISO Interface

BIC ISO BIC ISO


Interface Interface
BASE24

BIC ISO BIC ISO


Interface Interface

BIC ISO Interface Proprietary Interface

Co-network C Co-network D

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-13
Introduction

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

Proprietary Interface BIC ISO BIC ISO


Interface Interface
Co-network A Co-network C

May-2014 R6.0v10 SW-DS004-01


1-14 ACI Worldwide, Inc.
Supported Transactions

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.

Supported BASE24-atm Transactions


If BASE24-atm is installed, the following transactions are supported by the BIC
ISO Interface process. These transactions are supported for checking, savings, and
credit accounts. The BIC ISO Interface process also supports transactions for
which no account type has been specified.

?
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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-15
Introduction

Supported BASE24-pos Transactions


If BASE24-pos is installed, the following transactions are supported by the BIC
ISO Interface process. These transactions are supported for checking, savings, and
credit accounts. The BIC ISO Interface process also supports transactions for
which no account type has been specified.

?
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

May-2014 R6.0v10 SW-DS004-01


1-16 ACI Worldwide, Inc.
File Usage

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)

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-17
Introduction

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.

May-2014 R6.0v10 SW-DS004-01


1-18 ACI Worldwide, Inc.
Supported Message Types

Supported Message Types


The BIC ISO Interface process supports the following messages between the
BASE24 system and the co-network. Notations appear for each message type to
indicate its use or availability by BASE24 product.

Type Description BASE24-atm BASE24-pos

0100 Authorization Request ?

0110 Authorization Request Response ?

0120 Authorization Advice ?

0121 Authorization Advice Repeat ?

0130 Authorization Advice Response ?

0200 Financial Transaction Request ? ?

0210 Financial Transaction Request Response ? ?

0220 Financial Transaction Advice ? ?

0221 Financial Transaction Advice Repeat ? ?

0230 Financial Transaction Advice Response ? ?

0402 Card Issuer Reversal Request ?

0412 Card Issuer Reversal Request Response ?

0420 Acquirer Reversal Advice ? ?

0421 Acquirer Reversal Advice Repeat ? ?

0430 Reversal Advice Response ? ?

0500 Acquirer Reconciliation Request ? ?

0502 Issuer Reconciliation Request ? ?

0510 Acquirer Reconciliation Request Response ? ?

0512 Issuer Reconciliation Request Response ? ?

0520 Acquirer Reconciliation Advice ? ?

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-19
Introduction

Type Description BASE24-atm BASE24-pos

0521 Acquirer Reconciliation Advice Repeat ? ?

0522 Issuer Reconciliation Advice ? ?

0523 Issuer Reconciliation Advice Repeat ? ?

0530 Acquirer Reconciliation Advice Response ? ?

0532 Issuer Reconciliation Advice Response ? ?

0800 Network/Key Management Request ? ?

0810 Network/Key Management Request Response ? ?

0820 Network Management Advice ? ?

0821 Network Management Advice Repeat ? ?

0830 Network Management Advice Response ? ?

May-2014 R6.0v10 SW-DS004-01


1-20 ACI Worldwide, Inc.
Interchange Reporting

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-21
Introduction

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.

For more information on BASE24-pos Address Verification add-on product, refer


to the BASE24-pos Address Verification Manual.

May-2014 R6.0v10 SW-DS004-01


1-22 ACI Worldwide, Inc.
Self-Service Banking (SSB)

Self-Service Banking (SSB)


The BIC ISO Interface process supports the split deposit transaction option
available through BASE24-atm self-service banking (SSB). Split deposit
transactions can be performed only if the customer has purchased the
BASE24-atm self-service banking Base Application.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-23
Introduction

Dynamic Key Management


The BIC ISO Interface uses working keys to protect transaction data moving
between networks. Working keys are used to maintain the proper security to
protect personal identification numbers (PINs) and verify message authentication
codes (MACs). Working keys should be changed regularly to ensure security. The
monitoring and changing of these keys is known as key management and can be
performed manually using text commands or automatically using dynamic key
management.

Dynamic key management allows co-networks to automatically change working


keys based on thresholds set for time, number of transactions, and number of
single or consecutive errors. One or more working keys can be changed when any
one of the defined thresholds is surpassed.

Dynamic key management requires the use of hardware security modules to


perform PIN encryption, PIN verification, and message authentication. It is not
supported when these functions are performed in software.

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.

May-2014 R6.0v10 SW-DS004-01


1-24 ACI Worldwide, Inc.
Five-day Settlement

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.

Five-day settlement is configured on screen 2 of the Enhanced Interchange


Configuration File (ICFE). See section 2 for more information about the ICFE
screen and its field settings.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-25
Introduction

Currency Conversion Support


The BIC ISO Interface process supports the conversion of currency between two
institutions that do not share the same currency. Institutions have the option of
using the same currency, two different currencies, or different currencies for
acquirer, issuer, and settlement.

The co-networks must first decide on a currency in which to settle transactions. If


the settlement currency is different than the currency of the acquiring bank, the
BIC ISO Interface process converts the local currency to the settlement currency.
If the settlement currency is different from the local currency of the issuer, the BIC
ISO Interface process converts the settlement currency into the local currency.

The following illustrations show transactions taking place between a BASE24


network in the United States and a co-network based in the United Kingdom. The
co-networks have decided to settle transactions in pounds. The first illustration
shows the BASE24 network as the acquirer.

$ £
BASE24 BIC ISO
U.K.
Authorization Interface
$ £ Co-network
Process Process

In this example, a customer of the U.K. institution requests a transaction at a


device owned by the U.S. institution. The BASE24 Authorization process sends
the transaction to the BIC ISO Interface process. The interface converts it to
pounds and sends it to the U.K. institution’s co-network. The co-network sends
the response to the BIC ISO Interface process in pounds. The BIC ISO Interface
process converts the amount to dollars and sends the response to the BASE24
Authorization process. It also logs the transaction in dollars to its Interchange Log
File (ILF).

May-2014 R6.0v10 SW-DS004-01


1-26 ACI Worldwide, Inc.
Currency Conversion Support

The next illustration shows a transaction requested by a customer of the U.S.


institution at a device owned by the U.K. institution. The BASE24 network is the
issuer in this example.
£ $
U.K. BIC ISO BASE24
Co-network Interface Authorization
£ 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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-27
Introduction

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

Original Currency Release 6.0 Token


The BIC ISO Interface process on an issuer system adds the Original Currency
Release 6.0 token (token ID BE) if the transaction currency code (data element P-
49) does not match the local currency code (the CURRENCY-CODE param in the
LCONF).

May-2014 R6.0v10 SW-DS004-01


1-28 ACI Worldwide, Inc.
Currency Conversion Support

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.

BIC ISO External Message Original Currency Release 6.0


Field Token Field

TRAN-AMT AMT-1

ADD-AMTS.B24-DEF.AMT AMT-2

CRNCY-CDE CRNCY-CDE

SETL-CONV-RAT CONV-RATE

CONV-DAT CONV-DAT

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-29
Introduction

Multiple Currency Support


The BASE24-atm and BASE24-pos Multiple Currency add-on products allow
institutions to offer accounts in different currencies, with the ability to define each
account with its own currency. They also allow cardholders to perform
transactions in different currencies at different ATMs and point-of-sale (POS)
devices. This add-on product is available with the BASE24-atm NCR 5XXX and
Diebold 10XX/478X Device Handler processes and the BASE24-pos Standard
POS Device Handler (SPDH) and APACS 30/40 Device Handler modules.

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.

May-2014 R6.0v10 SW-DS004-01


1-30 ACI Worldwide, Inc.
Performance Monitoring Support

Performance Monitoring Support


If you have purchased the NET24 Performance Monitoring subsystem, the BIC
ISO Interface process supports the performance monitoring of transactions, in real
time, between the BASE24 system and interchanges for both the BASE24-atm and
BASE24-pos products. The standard application counters for interchanges are
defined below. For more information on the NET24 Performance Monitoring
subsystem, refer to the NET24 Performance Monitoring Manual.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-31
Introduction

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 Approval The total number of acquirer requests that resulted


Count in an approved response during the retrieval
interval.

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 Reversal The total number of reversals during the retrieval


Count interval.

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.

May-2014 R6.0v10 SW-DS004-01


1-32 ACI Worldwide, Inc.
Performance Monitoring Support

Counter Description

Outbound Response The average response time of all acquirer response


Time 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 acquirer requests received
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 acquirer requests. The total response time is
measured from the time that the request enters the
BASE24 system until the response exits the
BASE24 system.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-33
Introduction

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.

May-2014 R6.0v10 SW-DS004-01


1-34 ACI Worldwide, Inc.
Enhanced EMV Response Code Mapping

Enhanced EMV Response Code Mapping


BASE24 maps response codes carried internally with ISO response codes used in
the BASE24 external message. Two types of mapping are supported: standard
mapping and enhanced EMV mapping.

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.

BASE24-atm Standard Mapping Enhanced EMV Mapping

084 ATC check failure 05 Do not honor U4 ATC check failure

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:

Param Response Code Mapping


Value
BASE24-atm BASE24-pos

0 Standard Mapping Standard Mapping

1 Enhanced EMV Mapping Standard Mapping

2 Standard Mapping Enhanced EMV Mapping

3 Enhanced EMV Mapping Enhanced EMV Mapping

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 1-35
Introduction

May-2014 R6.0v10 SW-DS004-01


1-36 ACI Worldwide, Inc.
2: Configuration and Control

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-1
Configuration and Control

LCONF Assigns and Params


The BIC ISO Interface process uses a number of Logical Network Configuration
File (LCONF) assigns and params in its processing. These assigns and params are
identified below. For more information on configuring the BIC ISO Interface
process using these assigns and params, refer to the BASE24 Logical Network
Configuration File Manual.

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.

EMF — Identifies the name of the External Message File (EMF).

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.

ICFE — Identifies the name of the Enhanced Interchange Configuration File


(ICFE). This assign is required if the BASE24-REL param contains the value of
60.

ILF — Identifies the name of the Interchange Log File (ILF).

IPCFEMT — Identifies the name of the Issuer Processing Code File (IPCF)
extended memory table (IPCFEMT), which contains IPCF records.

ITF — Identifies the name of the Interchange Totals File (ITF).

KEY6 — Identifies the name of the Key 6 File (KEY6).

KEYF — Identifies the name of the Key File (KEYF).

May-2014 R6.0v10 SW-DS004-01


2-2 ACI Worldwide, Inc.
LCONF Assigns and Params

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.

RPT-ERROR-FILE — Identifies the name of the spooler location to receive


report error messages for interchange reports. This assign is required if reports are
to be generated.

SAF — Identifies the name of the Store-and-Forward File (SAF).

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.

TKN — Identifies the name of the Token File (TKN).

Params
Several params are used by the BIC ISO Interface process during processing.
These params are as follows.

ATM-DISCR-DATA-STM-SUPPRS — Specifies whether discretionary data in


the BASE24-atm Standard Internal Message (STM) should be suppressed. Valid
values are Y (suppress) and N (do not suppress), with a default value of N.

ATM-LN-CUTOVER — The time of day all BASE24-atm processes in the entire


logical network are cut over. All institutions must be cut over by this time. Valid
values, in military time, are from 00:00 to 23:59. This param is required for
BASE24-atm.

CURRENCY-CODE — A code indicating the primary type of currency used by


the logical network. Each code consists of a three-digit value. For the currency
code values, refer to the ISO 4217 standard Codes for the Representation of
Currencies and Funds.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-3
Configuration and Control

DATE-DISPLAY-TYPE — A flag indicating the format of the month and day


portion of the dates on reports. This param does not affect dates which include the
year. Valid values are as follows:

1 = DDMM
2 = MMDD (default)

DES-TRIPLE-SINGLE — A code indicating whether an Interchange Interface


process translates PINs from encryption under a double length key using the Triple
Data Encryption algorithm (T-DEA) to encryption under a single length key using
the Data Encryption algorithm (T-DEA) and vice versa. Valid values are as
follows:

Y = Yes, translate PINs from T-DEA encryption to DEA encryption


and vice versa.
N = No, do not translate PINs from T-DEA encryption to DEA
encryption and vice versa.

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

ACCT-NUM-TYP — A flag indicating whether account numbers are stored in


binary or decimal form. The binary form allows the account number to be up to 28
digits in length. The decimal form allows the account number to be up to 19 digits
in length. Valid values are as follows:

D = Decimal format (default)


B = Binary format

ENHANCED-CRNCY-CONV — A code indicating whether enhanced currency


conversion processing is performed. If data elements P-54, S-95, or S-123 are
present in the ISO-based external message for messages acquired by the co-
network or BASE24, this param indicates whether the amounts in these fields are
specified in a single currency or in two currencies. Enhanced currency conversion
is performed if the amounts are specified in two currencies. Valid values are as
follows:

0 = Do not perform enhanced currency conversion processing. (This is the


default value.)

May-2014 R6.0v10 SW-DS004-01


2-4 ACI Worldwide, Inc.
LCONF Assigns and Params

1 = Perform enhanced currency conversion processing for ATM transactions


only.
2 = Perform enhanced currency conversion processing for POS transactions
only.
3 = Perform enhanced currency conversion processing for ATM and POS
transactions.

This param is not used if the system supports Multiple Currency processing (the
MULT CURRENCY field on ICFE screen 3 is set to Y).

ENHANCED-EMV-RC-MAPPING — A code indicating whether enhanced


EMV response code mapping is used. Certain BASE24-atm and BASE24-pos
response codes are used to identify EMV-specific failure conditions. Without
enhanced EMV response code mapping, these response codes are mapped to a
generic ISO response code (e.g., 05—do not honor), and the acquiring system
often cannot identify the reason for a declined EMV transaction. With enhanced
EMV response code mapping, unique ISO response codes are added to identify
EMV-specific failure conditions. Valid values are as follows:

0 = Do not perform enhanced EMV response code mapping. (This is the


default value.)
1 = Perform enhanced EMV response code mapping for ATM transactions
only.
2 = Perform enhanced EMV response code mapping for POS transactions
only.
3 = Perform enhanced EMV response code mapping for ATM and POS
transactions.

ILF-NOTIFY-INTERVAL — The number of writes made to the ILF between


calculating the percentage of file full. Valid values are 10–32766. The default
value is 50.

ILF-NOTIFY-PERCENTAGE — The percentage of file full at which the BIC


ISO Interface process logs a message indicating the ILF is becoming full. The BIC
ISO Interface process continues to log messages at the interval indicated in the
ILF-NOTIFY-INTERVAL param until more file space is made available. Valid
values are 10–99. The default value is 70.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-5
Configuration and Control

OVRRD-INST-ID-FLDS — A code indicating whether the institution ID can be


overridden with values from fields in the Enhanced Interchange Configuration File
(ICFE) record. The ICFE fields that can be overridden are the SWITCH ID and
DEFAULT ACQUIRER ID NUM fields on ICFE screen 1. Valid values are as
follows:

0 = Do not override institution ID values. (This is the default value.)


1 = Override acquiring institution ID only.
2 = Override forwarding institution ID only.
3 = Override acquiring and forwarding institution ID.
4 = Override receiving institution ID.
5 = Override acquiring and receiving institution ID.
6 = Override forwarding and receiving institution ID.
7 = Override acquiring, forwarding, and receiving institution ID.

POS-ACQ-ILF-MATCH — Specifies the maximum number of previous ILFs


that the acquirer processing within the interface accesses when searching for a
match for a POS reversal. Valid values are 0–7. The default value is 0.

POS-ACQ-ILF-MATCH-CNP — Specifies the maximum number of previous


ILFs that the acquirer processing within the interface accesses when searching for
a match for a CNP reversal. Valid values are 0–7. The default value is the value of
POS-ACQ-ILF-MATCH.

POS-B24-TO-POS-ACCT-TYP-SUPPRS — Specifies whether the account


type in the BASE24-pos Standard Internal Message (PSTM) should be suppressed
when the PSTM is mapped to the external message. The BIC ISO Interface
process suppresses the account type from the PSTM by using an account type of
zeroes in the external message. Valid values are Y (suppress) and N (do not
suppress), with a default value of N.

POS-DISCR-DATA-PSTM-SUPPRS — Specifies whether discretionary data


in the BASE24-pos Standard Internal Message (PSTM) should be suppressed.
Valid values are Y (suppress) and N (do not suppress), with a default value of N.

POS-ISS-ILF-MATCH — Specifies the maximum number of previous ILFs that


the issuer processing within the interface accesses when searching for a match for
a POS reversal. Valid values are 0–7. The default value is 0.

May-2014 R6.0v10 SW-DS004-01


2-6 ACI Worldwide, Inc.
LCONF Assigns and Params

POS-ISS-ILF-MATCH-CNP — Specifies the maximum number of previous


ILFs that the issuer processing within the interface accesses when searching for a
match for a CNP reversal. Valid values are 0–7. The default value is the value of
POS-ISS-ILF-MATCH.

POS-LN-CUTOVER — The time of day all BASE24-pos processes in the entire


logical network are cut over. All institutions must be cut over by this time. Valid
values, in military time, are from 00:00 to 23:59. This param is required for
BASE24-pos.

PRE-VERIFIED-PIN-PAD-CHAR — Specifies the value to be repeated in a PIN


block to identify the PIN as pre-verified. The default value is F, but it is possible
for an actual encrypted PIN to result in a PIN block value of all Fs. If used, this
value should be set to a non-hexadecimal character (i.e., a character other than 0-9
or A-F) because the use of any repeated hexadecimal character could have the
same issue as the F character. If this value is set, the host must also be modified to
recognize the new pre-verified PIN block character.

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

BASE24-atm Note: BASE24-atm transactions always require a PIN. Therefore,


for BASE24-atm transactions, a pre-verified PIN can be accurately identified by
the absence of the P-52 (Personal Identification Number Data) data element in the
external message. For outgoing messages, BASE24-atm always identifies a pre-
verified PIN by omitting the P-52 data element. For incoming messages, the host
has several options—BASE24-atm assumes a PIN has been pre-verified if the P-
52 data element is omitted, contains spaces, or is filled by the pad character
specified in this param.

PSEUDO-3DES-CBC-MAC-TYPE — Specifies whether to use the Pseudo


3DES Cipher Block Chaining method of MACing instead of the default 3DES
Cipher Block Chaining method used by the ISO Host Interface process.

Note: This param is not used if the BASE24 Transaction Security Services (TSS)
process is being used.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-7
Configuration and Control

RACAL-ANSI-METHOD — Specifies whether to use the ANSI X9.17


Encryption Method for key exchanges instead of the default Variant Encryption
Method used by the ISO Host Interface process. The ANSI X9.17 Encryption
Method can be used with a Thales (formerly Racal) Hardware security module.

Note: This param is not used if the BASE24 Transaction Security Services (TSS)
process is being used.

REVERSAL-BAL-INQ — Specifies whether balance inquiry transactions can be


reversed. This param is only read if BASE24-atm or BASE24-pos support is
bound into the BIC ISO Interface process.

RSM-TERM-MASTER-KEY — Specifies an encrypted terminal master key


used during hardware message authentication by Thales (formerly Racal) security
devices.

Note: This param is not used if the BASE24 Transaction Security Services (TSS)
process is being used.

SAF-NOTIFY-INTERVAL — The number of writes made to the SAF between


calculating the percentage of file full. Valid values are 10–32766. The default
value is 50.

SAF-NOTIFY-PERCENTAGE — The percentage of file full at which the BIC


ISO Interface process logs a message indicating the SAF is becoming full. The
BIC ISO Interface process continues to log messages at the interval indicated in
the SAF-NOTIFY-INTERVAL param until more file space is made available.
Valid values are 10–99. The default value is 70.

SEND-ETX — A flag indicating whether an interchange interface process sends


the end-of-text (ETX) control character. Valid values are as follows:

Y = Yes, send the ETX character with external messages (default value).
N = No, do not send the ETX character with external messages.

SPAN-FLAG — A value indicating whether totals are written to the Span


Clearings File. Valid values are as follows:

Y = Yes, write totals to the Span Clearings File.


N = No, do not write totals to the Span Clearings File.

May-2014 R6.0v10 SW-DS004-01


2-8 ACI Worldwide, Inc.
LCONF Assigns and Params

SWI-ACQ-AVS-DATA-SUPPRS — A flag indicating whether logging of


address verification data for acquirer transactions to the ILF should be suppressed.
Valid values are as follows:

Y = Yes, suppress logging of address verification data.


N = No, do not suppress logging of address verification data.

SWI-ACQ-CVD2-DATA-SUPPRS — A flag indicating whether logging of card


verification data (CVD2) for acquirer transactions to the ILF should be suppressed.
Valid values are as follows:

Y = Yes, suppress logging of card verification data (CVD2).


N = No, do not suppress logging of card verification data (CVD2).

SWI-ACQ-DISCR-DATA-SUPPRS — A flag indicating whether logging of


discretionary data from Track 1 or Track 2 for acquirer transactions to the ILF
should be suppressed. Valid values are as follows:

Y = Yes, suppress logging of discretionary data from Track 1 or Track 2.


N = No, do not suppress logging of discretionary data from Track 1 or Track 2.

SWI-ISS-AVS-DATA-SUPPRS — A flag indicating whether logging of address


verification data for issuer transactions to the ILF should be suppressed. Valid
values are as follows:

Y = Yes, suppress logging of address verification data.


N = No, do not suppress logging of address verification data.

SWI-ISS-CVD2-DATA-SUPPRS — A flag indicating whether logging of card


verification data (CVD2) for issuer transactions to the ILF should be suppressed.
Valid values are as follows:

Y = Yes, suppress logging of card verification data (CVD2).


N = No, do not suppress logging of card verification data (CVD2).

SWI-ISS-DISCR-DATA-SUPPRS — A flag indicating whether logging of


discretionary data from Track 1 or Track 2 for issuer transactions to the ILF should
be suppressed. Valid values are as follows:

Y = Yes, suppress logging of discretionary data from Track 1 or Track 2.


N = No, do not suppress logging of discretionary data from Track 1 or Track 2.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-9
Configuration and Control

SW-ILF-FILE-RETENTION — The number of days an ILF is to remain on the


system. After the specified number of days, the ILF is purged from the system by
the BIC ISO Interface process. Valid values are 3–99. The default value is 7.

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.

UPDT-ILF-ON-LATE-RESP — A flag indicating whether the BIC ISO Interface


should retrieve the ILF record upon receipt of a late response and update it to
reflect that a reversal was sent out. Valid values are as follows:

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.

May-2014 R6.0v10 SW-DS004-01


2-10 ACI Worldwide, Inc.
Configuring a Co-Network

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.

A number of processing options are controlled at the co-network level, which


enable institutions to set up co-networks with individual processing requirements.
The majority of processing options available at the co-network level are stored in
the ICFE. Other options are specified in the KEYF or KEY6. The processing
options controlled at the co-network level are described below.

Specifying Timer Lengths


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, KEYF, or
LCONF. Some timer intervals are specified once at the interface level, while
others are specified at the interface and product level (e.g., you can specify one
time limit for inbound BASE24-atm messages and a different time limit for
inbound BASE24-pos messages).

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.

Timer Interface Interface/


Level Product
Level

Network Management Message timer ICFE

Extended Network Management Message ICFE


timer

Store-and-Forward Message timer ICFE

Wait-for-Traffic timer ICFE

Performance timer ICFE

Outbound Request timer ICFE

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-11
Configuration and Control

Timer Interface Interface/


Level Product
Level

Inbound Request timer ICFE

Completion Acknowledgment timer ICFE

PIN Key Exchange timer KEYF


or KEY6

MAC Key Exchange timer KEYF


or KEY6

Clear Old Key timer KEYF


or KEY6

Report Startup timer LCONF

Settlement Interval timer ICFE

ITF Update timer ICFE

Interspersing Store-and-Forward Messages


Store-and-forward messages are interspersed with request messages. Interspersing
store-and-forward messages allows other transactions to be processed during store-
and-forward activity, while receiving all store-and-forward messages prior to
further requests may cause requests to be processed offline or be declined because
of an inability to send them to the co-network.

In addition, messages sent to the SAF are single-threaded. Single-threaded means


that only one message of any kind can be outstanding to a station at a time. In this
case, the BIC ISO Interface process must receive a response or the message must
time out before another message can be sent to the station.

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

May-2014 R6.0v10 SW-DS004-01


2-12 ACI Worldwide, Inc.
Configuring a Co-Network

?
Chargeback messages
?
Cutover messages
?
Administrative messages

Sending Text-Level Acknowledgments to a Co-Network


Acquiring institutions must specify whether the co-network expects text-level
acknowledgments from the BIC ISO Interface process. If text-level
acknowledgments are required, BASE24 returns a 0130 message for each 0120
and 0121 message; a 0230 message for each 0220 or 0221 message; a 0430
message for each 0420 or 0421 message; and a 0530 message for each 0520 or
0521 message.

Institutions indicate whether text-level acknowledgments are required using the


ACK TO SWITCH field on ICFE screen 1.

Expecting Text-Level Acknowledgments from a Co-Network


Issuer institutions must indicate whether the BIC ISO Interface process should
expect text-level acknowledgments. If text-level acknowledgments are required,
the BASE24 system expects a 0130 message for each 0120 and 0121 message; a
0230 message for each 0220 or 0221 message; a 0430 message for each 0420 or
0421 message; and a 0530 message for each 0520 or 0521 message.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-13
Configuration and Control

Specifying Maximum Timeouts


Institutions must indicate the number of consecutive timeouts of non-network
management and non-store-and-forward messages that can occur at a station
before the station is marked down. For example, if 3 is specified, the BIC ISO
Interface process marks the station down upon the third consecutive timeout.
However, if only two consecutive timeouts have occurred, the station is not
marked down.

Institutions control when a station is marked down because of timeouts using the
MAXIMUM TIMEOUTS field on ICFE screen 1.

Initiating Network Management Messages


Institutions specify whether the BIC ISO Interface process is allowed to initiate
network management messages (that is, 0800 messages for new key, change key,
verify key, or repeat key).

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.

Enabling Dynamic Key Management


Institutions specify whether the BIC ISO Interface process is allowed to initiate
network management messages for dynamic key management (that is, 0800
messages for new key, change key, verify key, or repeat key commands). This
option limits the ability of the BIC ISO Interface process to perform or solicit key
management requests.

Network management messages for dynamic key management are controlled by


the timers and thresholds on KEYF screen 3 or KEY6 screen 4. If all of the timers
and thresholds on KEYF screen 3 or KEY6 screen 4 are set to the value 0, the BIC
ISO Interface process does not initiate network management messages for
dynamic key management. If any of the timers or thresholds contains a nonzero
value, the BIC ISO Interface process initiates a key management message when
the timer expires or when the threshold is passed.

May-2014 R6.0v10 SW-DS004-01


2-14 ACI Worldwide, Inc.
Configuring a Co-Network

Specifying Extract File Format


The BIC ISO Interface process supports Format 2 files. The FILE FORMAT field
on Extract Configuration File (ECF) screen 3 indicates whether the disk file is
created as a Format 1 or Format 2 file.

Specifying Maximum Store-and-Forward Retries


Institutions set the maximum number of times the BIC ISO Interface process
attempts to send a store-and-forward message to a co-network before sending that
message to the log and deleting it from the SAF.

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.

Specifying Maximum Outbound Messages


The BIC ISO Interface process allows institutions to specify the maximum number
of request messages (that is, 0100, 0200, 0300, 0402, and 0500 messages) or
advice messages (that is, 0120, 0220, 0320, 0420, and 0520 messages) that can be
outstanding to an issuer co-network before the BIC ISO Interface process stops
sending additional messages. Outstanding messages are those messages that have
not been received (for example, a 0210 for a 0200 or a 0230 for a 0220).

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.

Institutions control the number of outstanding request and advice messages to a


co-network using the OUTBOUND field on ICFE screen 3.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-15
Configuration and Control

Specifying Maximum Inbound Requests


The BIC ISO Interface process also provides a parameter for limiting the number
of outstanding 0100 and 0200 messages to a BASE24-atm or BASE24-pos
Authorization process. This parameter controls requests being sent from acquirer
co-networks. Once the number of outstanding 0100 and 0200 messages reaches
this limit, the BIC ISO Interface process declines any new 0100 and 0200
messages coming from the co-network and returns them as 0110 and 0210
messages.

The number of outstanding requests to an Authorization process is controlled


using the INBOUND field on ICFE screen 3.

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.

Defining Data Prefix Characters


The BIC ISO Interface process allows institutions to define certain characters they
want included in front of the messages they receive from the BIC ISO Interface
process. An institution can specify up to nine characters to precede messages to
their co-network system. Each time the BIC ISO Interface process creates an
external message to a co-network, it checks the ICFE for data prefix characters. If
the ICFE contains data prefix characters for the co-network, the BIC ISO Interface
process places these characters at the front of the message.

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.

May-2014 R6.0v10 SW-DS004-01


2-16 ACI Worldwide, Inc.
Configuring a Co-Network

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:

Hex ASCII Display Hex ASCII Display

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-17
Configuration and Control

Setting Up Co-Network Stations


Stations serve as the links between BASE24 and a co-network. All messages sent
to a co-network are actually sent to the stations defined for that co-network.
Likewise, all messages received from a co-network are actually received from the
stations defined to that co-network.

Up to 20 stations can be defined for each co-network, although a recommended


maximum is 10 to 12. A station must first be defined as a co-network station in the
Network Environment File (NEF). The station’s symbolic name can then be
placed in the ICFE to fully define the station.

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.

Receive-Only/No Output Stations

Receive-only/no output stations only allow for messages coming in to BASE24.


BASE24 never uses receive only/no output stations for sending messages to the
co-network. The receive-only/no output station is used to avoid line connection
when using a point-to-point or SNA protocol. In this case, communications are
received on one station and sent from a different station.

May-2014 R6.0v10 SW-DS004-01


2-18 ACI Worldwide, Inc.
Setting Up Co-Network Stations

Setting Up the ICFE Station Table


Stations are numbered from left to right, top to bottom on the ICFE file
maintenance screens. This numbering scheme is of particular importance to co-
networks with multiple stations on their lines.

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.

Selecting Stations for Sending Messages


To select the station to send a message to, the BIC ISO Interface process uses a
technique called round robin. The BIC ISO Interface process begins with the first
station in the ICFE station table. For each subsequent message that the interface
needs to send, it increments the index in the ICFE station table to determine the
next station. The interface evaluates the next station and determines the
availability of the station based upon whether the station is a send or send and
receive station and whether the station is marked up and logged on. The BIC ISO
Interface compares the number of pending transactions for the next available
station to the number of pending transactions for the current station and sends the
message to the station that is least busy.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-19
Configuration and Control

Configuring Data Suppression


The BIC ISO Interface process offers several options for suppressing data
contained in response messages and logged to the Interchange Log File (ILF).

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

ILF Logging When the Interface Acting as an Acquirer


SWI-ACQ-AVS-DATA-SUPPRS
SWI-ACQ-CVD2-DATA-SUPPRS
SWI-ACQ-DISCR-DATA-SUPPRS

ILF Logging When the Interface Acting as an Issuer


SWI-ISS-AVS-DATA-SUPPRS
SWI-ISS-CVD2-DATA-SUPPRS
SWI-ISS-DISCR-DATA-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.

Response message discretionary data suppression occurs in the internal message


structure before it can be used to create the response message, while ILF data
suppression occurs after transaction data has been moved to the ILF record
structure and before it is written to disk.

The suppression of discretionary data can affect the content of messages


exchanged between co-hosts. This is true whether the data has already been
suppressed in response messages that BASE24 receives from an interchange or co-
host, or the data is suppressed by a BASE24 authorization process. In particular,
BASE24 may have to construct the Track 2 Data (P-35) data element, and the

May-2014 R6.0v10 SW-DS004-01


2-20 ACI Worldwide, Inc.
Configuring Data Suppression

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-21
Configuration and Control

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.

Network Management Message Timer


A Network Management Message timer is set each time an 0800 message is sent to
a co-network station. The Network Management Message timer limits the length
of time that the BIC ISO Interface process waits for a response after transmitting
an 0800 message. The number of seconds to use for this timer is taken from the
NETWORK MANAGEMENT field on ICFE screen 3.

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:

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. If the
0800 message was a dynamic key management message, the BIC ISO
Interface process performs as follows:
a. Adds one to the count of consecutive timeouts accumulated for the
station.
b. Checks the number of consecutive timeouts accumulated for the station
against the maximum allowed by the MAXIMUM TIMEOUTS field on
ICFE screen 1.
1) If the current number of consecutive timeouts is less than the
maximum allowed, processing continues with step c.
2) If the current number of consecutive timeouts is equal to the
maximum allowed, the BIC ISO Interface process marks the station
down and 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, so the BIC ISO Interface process marks the co-network
down.

May-2014 R6.0v10 SW-DS004-01


2-22 ACI Worldwide, Inc.
Configuring Timers

c. Sets an Extended Network Management Message timer for the station.


d. If the message that timed out was a new key or a change key message,
sends a message to the network logging facility indicating that the
message expired and that the message will automatically be retried.

Extended Network Management Message Timer


An Extended Network Management Message timer is set each time a co-network
station is marked down and each time a new key or change key message times out.
The Extended Network Management Message timer specifies the following
intervals:

?
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:

1. Sends an echo test message to the station.


2. Sets a Network Management Message timer for the echo test message.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-23
Configuration and Control

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

Store-and-Forward Message Timer


A Store-and-Forward Message timer is set each time a store-and-forward message
is sent to a co-network. The Store-and-Forward Message timer limits the length of
time that the BIC ISO Interface process waits for an acknowledgment after
transmitting a store-and-forward message. The number of seconds to use for this
timer is taken from the STORE AND FORWARD field on ICFE screen 8 for
BASE24-atm and ICFE screen 10 for BASE24-pos.

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.

If this timer expires before an appropriate acknowledgment is received in


response, the BIC ISO Interface process performs as follows:

1. Reads the message from the SAF.


2. Adds one to the SAF retries count for that record. The SAF retries count
indicates the number of times the SAF record has been sent to the co-network.
A separate count is kept for each SAF record.
3. Checks the SAF retries count for the record against the maximum allowed by
the MAX SAF RETRY field on ICFE screen 3.
a. If the SAF retries count is equal to the maximum allowed, the BIC ISO
Interface process performs as follows:
1) Writes the SAF record to its log.
2) Deletes the record from the SAF.
b. If the SAF retries count is less than the maximum allowed, the BIC ISO
Interface process continues with the next step.
4. Marks the SAF message to be resent.

May-2014 R6.0v10 SW-DS004-01


2-24 ACI Worldwide, Inc.
Configuring Timers

5. Updates the message type, if necessary.


If the message type is 0120, 0220, 0320, 0420, or 0520, the BIC ISO Interface
process reads the corresponding record in the SAF and updates the message
type in place to 0121, 0221, 0321, 0421, or 0521 respectively. Message types
0402 and 0412 are not changed.

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-25
Configuration and Control

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:

1. Moves the performance statistics from interval two to interval three.


2. Moves the performance statistics from interval one to interval two.
3. Moves the performance statistics from interval zero to interval one.
4. Zeros out the performance statistics in interval zero to begin accumulating
statistics again.
5. Sets a Performance timer for the co-network.

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.

Outbound Request Timer


An Outbound Request timer is set each time a 0100, 0200, or 0300 message is sent
to a co-network. The Outbound Request timer limits the amount of time that the
BIC ISO Interface process waits for a response from the co-network after
transmitting a request message. The number of seconds to use for this timer is
taken from the OUTBOUND field on the product-specific ICFE screen.

If this timer expires before a response is received to the message, the BIC ISO
Interface process performs as follows:

1. Performs product-specific processing.


a. If the message is a BASE24-atm message, the BIC ISO Interface process
performs as follows:
1) Retrieves the original message from memory.
The BIC ISO Interface process retains a copy of the internal
message for each message it sends to the co-network until it is
notified that the message was received.

May-2014 R6.0v10 SW-DS004-01


2-26 ACI Worldwide, Inc.
Configuring Timers

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-27
Configuration and Control

Inbound Request Timer


An Inbound Request timer is set each time a 0100 or 0200 message is sent to a
BASE24-atm or BASE24-pos Authorization process. The Inbound Request timer
limits the length of time that the BIC ISO Interface process waits for a response
from a BASE24 Authorization process after transmitting a request message. The
number of seconds to use for this timer is taken from the INBOUND field on the
product-specific ICFE screen.

If an Inbound Request timer expires before a response message is received, the


BIC ISO Interface process performs as follows:

1. Retrieves the 0200 message from memory.


The BIC ISO Interface process retains a copy of the external message for
each 0200 message it sends to the Authorization process until a response is
received (the BASE24-pos product handles all 0100 messages as 0200
messages internally).
2. Formats a 0110 or 0210 external message to send to the co-network using the
information from the request. The BIC ISO Interface process:
a. Sets the Responder Code in the BASE24 External Message Header to a
value of 6, indicating that the request is being responded to by the BIC
ISO Interface process.
b. Sets the Response Code (P-39) field in the message to a value of 05
(denied).
c. Sets the Card Issuer FIID and Logical Network (P-61) field in the
message to zeros.
3. Sends the external message to the co-network.
4. Adds one to the number of request timeouts for the BIC ISO Interface
process.

Completion Acknowledgment Timer


A Completion Acknowledgment timer is set each time a 0210, 0220, 0320, 0402,
0412, 0420, or 0520 message is sent to a co-network. The Completion
Acknowledgment timer limits the amount of time that the BIC ISO Interface
process waits for an acknowledgment from the co-network after transmitting an
advice message. The number of seconds to use for this timer is taken from the
COMPLETION ACK field on the product-specific ICFE screen.

May-2014 R6.0v10 SW-DS004-01


2-28 ACI Worldwide, Inc.
Configuring Timers

The BIC ISO Interface process only expects text-level acknowledgments to


completion 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 an acknowledgment from the XPNET
process instead. In this case, the XPNET process returns an acknowledgment once
the message has been sent successfully to the co-network.

If a Completion Acknowledgment timer expires before an appropriate


acknowledgment is received, the BIC ISO Interface process performs as follows:

1. Retrieves a copy of the external message from memory.


The BIC ISO Interface process retains a copy of the external message for
each message it sends to the co-network until it is notified that the message
was received.
2. Changes the message type from 0120, 0220, 0320, 0420, or 0520 to 0121,
0221, 0321, 0421, or 0521 respectively. Message types 0402 and 0412 are
not changed.
3. Places the external message in the SAF.
4. Adds one to the count of consecutive timeouts accumulated for the station.
5. Adds one to the number of request timeouts for the co-network.
6. 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 less than the maximum
allowed, the BIC ISO Interface process takes no further action.
b. If the current number of consecutive timeouts is equal to the maximum
allowed, the BIC ISO Interface process:
1) Marks down the station.
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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-29
Configuration and Control

Key Exchange Timer


Key Exchange timers are used to automatically initiate PIN and MAC key
exchanges. If the BASE24 product is configured for dynamic key management,
one Key Exchange timer is set for each PIN and MAC key being used by the BIC
ISO Interface process. Key Exchange timers are set or reset at the following times:

?
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:

1. Determines the key that needs to be exchanged.


2. Changes the status of the co-network to indicate that a key exchange is
pending.
3. Determines the type of message to send based on the value in the KEY
PROCESSING TYPE field on KEYF screen 3 or KEY 6 screen 4 and the key
direction, as described below:
a. If the KEY PROCESSING TYPE field contains the value N (no key
processing), then no further steps are taken.
b. If the KEY PROCESSING TYPE field contains the value M (main
processor), the message type is a new key message.

May-2014 R6.0v10 SW-DS004-01


2-30 ACI Worldwide, Inc.
Configuring Timers

c. If the KEY PROCESSING TYPE field contains the value S (secondary


processor), the message type is a change key message.
d. If the KEY PROCESSING TYPE field is contains the value C (co-
network processor) and the key direction is outbound, the message type
is a new key message.
e. If the KEY PROCESSING TYPE field is contains the value C (co-
network processor) and the key direction is inbound, the message type is
a new key message.
4. Determines whether a key exchange is already in progress for the specific
key. If a key exchange is already in progress for the specific key, no further
steps are taken. If a key exchange is not in progress for the key, processing
continues with the next step (step 5).
5. Determines whether there is a station available to which to send the message.
Depending on whether a station is available, the BIC ISO Interface process
performs as follows:
a. 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. No further processing is performed at this time.
b. If a station is available, the BIC ISO Interface process performs
according to the type of message, as described below:
1) If the message is a new key message, the BIC ISO Interface process
sends the message to the selected station. The BIC ISO Interface
process sets a Network Management Message timer to wait for the
response. The BIC ISO Interface process also sets a flag to indicate
that a key exchange is in progress and deletes the Clear Old Key
timer for the key being exchanged (if one is still set).
2) If the message is a change key message, the BIC ISO Interface
process sends the message to the selected station. The BIC ISO
Interface process sets a Network Management Message timer to
wait for the response.
6. Adds one to the count of messages outstanding to the station.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-31
Configuration and Control

Clear Old Key Timer


The clear old key timer limits the amount of time that BIC ISO Interface process
attempts to use the old key to verify a PIN or MAC after a key exchange has taken
place.

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.

A clear old key timer is set under the following circumstances:

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

May-2014 R6.0v10 SW-DS004-01


2-32 ACI Worldwide, Inc.
Configuring Timers

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.

Report Startup Timer


The BIC ISO Interface process uses a report startup timer to start the SETL01 and
STAT09 reports. The BIC ISO Interface process starts the timer at initialization
and at interchange cutover. The time for this timer is taken from the LCONF
param SW-RPT-STARTUP.

When the report startup timer expires, the obey file containing the commands to
run the report programs is executed.

Settlement Interval Timer


The settlement interval timer specifies how long to wait after the interface has cut
over successfully before the reconciliation totals are sent to the co-network. The
number of minutes used for this timer is taken from the SETTLEMENT TIMER
field on ICFE screen 12.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-33
Configuration and Control

ITF Update Timer


The BIC ISO Interface process uses an ITF update timer to determine when the
totals kept in the Interchange Totals File (ITF) should be updated. The number of
minutes used for this timer is taken from the ITF UPDATE INTERVAL field on
ICFE screen 12.

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:

1. Updates the transaction totals in the ITF.


2. Resets the ITF update timer.
3. Resets the transaction counter.

May-2014 R6.0v10 SW-DS004-01


2-34 ACI Worldwide, Inc.
Configuring External Messages

Configuring External Messages


The BIC ISO Interface process has a standard set of message structures, or
defaults, that it uses for creating and interpreting external messages. These
message defaults are hard-coded in the BIC ISO Interface process.

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.

Data elements can be defined in the EMF as mandatory, conditional, or not


required.

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-35
Configuration and Control

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:

PROD # Product MSG TYP IN-OUT-IND

00 Base 0800, 0810 I, O, B

9000 O

01 ATM 0200, 0210, 0220, 0230, 0420, I, O, B


0430

02 POS 0100, 0110, 0120, 0130, 0200,


0210, 0220, 0230, 0402, 0412,
0420, 0430

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.

May-2014 R6.0v10 SW-DS004-01


2-36 ACI Worldwide, Inc.
Configuring External Messages

Changing the Defaults


When the default values for a particular message type are not appropriate, a
separate EMF record can be created for each message type. To modify the default
values for any message type, the following steps must be performed. These steps
assume that you are logged on to the BASE24 CRT access system.

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.

1. Display EMF screen 1 by entering EMF in the FILE DESTINATION field at


the bottom of the CRT access screen. From a menu press the F1 key. From a
file screen, press the F16 key.
2. Read the EMF record being changed by completing the field information
shown below and pressing the F2 key. If no record is found, the BIC ISO
Interface process uses EMF default values. The default values can be
displayed by pressing the F7 key.
?
Set the INTERF TYP to BIC
?
Set the PROCESS NAM field to the symbolic name of the BIC ISO
Interface process
?
Set the PROD #, MSG TYP, and IN-OUT-IND fields using any
combination of values from each row of the following table:

PROD # Product MSG TYP IN-OUT-IND

00 Base 0800, 0810 I, O, B

9000 O

01 ATM 0200, 0210, 0220, 0230, 0420, I, O, B


0430

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-37
Configuration and Control

PROD # Product MSG TYP IN-OUT-IND

02 POS 0100, 0110, 0120, 0130, 0200,


0210, 0220, 0230, 0402, 0412,
0420, 0430

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.

May-2014 R6.0v10 SW-DS004-01


2-38 ACI Worldwide, Inc.
Configuring External Messages

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.

Configuring Tokens to be Sent in the External Message


A token is a collection of related data required to perform a specific function. As
transactions are processed and additional information is required, BASE24
processes add tokens to the internal message. The Token File (TKN) is used to
configure the following token processing:

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-39
Configuration and Control

Configuring Key Management


The BIC ISO Interface process reads the Key File (KEYF) for the information it
needs to handle PIN encryption, PIN translation, message authentication, and
dynamic key management. The KEYF contains one record for each BIC ISO
Interface process. The BASE24 Transaction Security Manual describes in detail
the configuration of PIN encryption, PIN translation, message authentication, and
dynamic key management. The key management options available for the BIC
ISO Interface process are described briefly in the paragraphs that follow.

Co-Network Encryption Type


The institution can specify the type of PIN encryption used for messages going to
and coming from the co-network. There are three options:

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

BASE24 Encryption Type


The BASE24 system and the co-network are not required to handle PIN encryption
in the same manner. Each has its own PIN encryption options that are controlled
separately. The BASE24 system can handle PIN encryption in two different ways:

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

May-2014 R6.0v10 SW-DS004-01


2-40 ACI Worldwide, Inc.
Configuring Key Management

This option is controlled using the BASE24 ENCRYPT TYPE field on KEYF or
KEY6 screen 1.

PIN Block Type


The institution can specify the type of PIN block used during encryption. PINs are
not simply fed into the encryption routine as is. Rather, they are presented to the
encryption routines in what is called a PIN block. A PIN block is a 16-digit series
of hexadecimal characters, of which the PIN is a part.

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.

PAN Characters Used in PIN Block


If the ANSI PIN block is selected, the institution can specify which PAN
characters to use in formatting the PIN block. There are three options:

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

PAD Character Used in PIN Block


If the PIN/PAD PIN block is selected, the institution must specify the PAD
character to use in formatting the PIN block. The PAD character is a single
hexadecimal character used to fill out the remaining positions of the PIN block.

The PAD character is specified using the PIN PAD CHARACTER field on KEYF
or KEY6 screen 1.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-41
Configuration and Control

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.

PIN Key Variant


The PIN key variant indicates whether Key Exchange Keys (KEKs) or PIN
Encryption Keys (PEKs) need to be generated for PIN key translations.

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.

May-2014 R6.0v10 SW-DS004-01


2-42 ACI Worldwide, Inc.
Configuring Key Management

Key Processing Type


The key processing type describes whether the BIC ISO Interface process is
performing main, secondary, co-network, or no key processing. The following list
describes each key processing type.

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

PIN Management Keys


There are four types of keys identified by the BASE24 system for use in managing
PINs between the BIC ISO Interface process and an interchange: inbound
encryption keys, outbound encryption keys, intermediate keys, and exchange keys.
The institution must specify the values for these keys.

These options are controlled using KEYF or KEY6 screen 2.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-43
Configuration and Control

Configuring Message Authentication


Message authentication options are configured using parameters set up in two
files: the External Message File (EMF) and the Key File (KEYF) or Key 6 File
(KEY6). The paragraphs that follow discuss the configuration options for using
message authentication with a BIC ISO Interface process.

MAC Encryption Type

The message authentication encryption type indicates whether authentication is


supported, and if so where the encryption is done. BASE24 and the co-network
are required to handle the encryption of the message authentication code (MAC) in
the same manner. Currently, BASE24 only supports message authentication using
a security device.

This option is controlled using the MAC ENCRYPT TYPE field on KEYF or
KEY6 screen 1.

MAC Data Type

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.

Message Elements Encrypted

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.

May-2014 R6.0v10 SW-DS004-01


2-44 ACI Worldwide, Inc.
Configuring Message Authentication

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.

MAC Key Variant

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-45
Configuration and Control

Configuring Processing Options


The following options are used to determine how the BIC ISO Interface process is
configured for cutover and reconciliation with the co-network, transactions
allowed, stand-in authorization, definition of product indicators and stations,
automatic logons and displaying customer balance information.

Cutover and Reconciliation Handling


The following options control how the BIC ISO Interface process handles cutover
and reconciliation with the co-network.

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.

Updating the ITF

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.

Sending a Reconciliation Message

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.

May-2014 R6.0v10 SW-DS004-01


2-46 ACI Worldwide, Inc.
Configuring Processing Options

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

Institutions define the transactions that can be sent to a particular co-network by


specifying an issuer transaction profile value in the ISSUER TXN PROFILE field
on screen 8 (ATM) and screen 10 (POS) of the Enhanced Interchange
Configuration File (ICFE). The value of the issuer transaction profile is used to
read the Issuer Processing Code File (IPCF) extended memory table, which
defines all the transactions allowed for the profile and the accounts on which the
transactions can be performed. If an issuer transaction profile is not specified, the
Interchange Interface process uses a value of all asterisks (wildcard characters) to
read the IPCF extended memory table.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-47
Configuration and Control

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.

Preference Issuer Transaction Message ISO Processing


Profile Category Code

1 Exact match Exact match Exact match

2 Exact match * Exact match

3 **************** Exact match Exact match

4 **************** * Exact match

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.

Acquirer Transaction Profile Processing. Once the acquirer transaction profile


value used to read the APCF extended memory table has been determined, the
Interchange Interface process attempts to read the APCF extended memory table
using the acquirer transaction profile value, the message category code from the
transaction, and the ISO processing code for the transaction. The BIC ISO

May-2014 R6.0v10 SW-DS004-01


2-48 ACI Worldwide, Inc.
Configuring Processing Options

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.

Preference Acquirer Message ISO Processing


Transaction Profile Category Code

1 Exact match Exact match Exact match

2 Exact match * Exact match

3 **************** Exact match Exact match

4 **************** * Exact match

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-49
Configuration and Control

Customer Balance Display


The BIC ISO Interface process can be set up to specify whether customer balance
information for incoming responses from the co-network should be displayed,
printed, or both displayed and printed. This option is controlled using the
CUSTOMER BALANCE DISPLAY field on ICFE screen 1. It is only used when
a transaction is authorized by the co-network.

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.

May-2014 R6.0v10 SW-DS004-01


2-50 ACI Worldwide, Inc.
Configuring Processing Options

Configuring Institution IDs


Under certain conditions, the BIC ISO Interchange Interface process can override
the values moved between the following data elements in ISO-based external
messages and the corresponding fields in the Standard Internal Message (STM) or
POS Standard Internal Message (PSTM), as shown in the following table.

Identifier External Message STM PSTM

Acquiring Acquiring Institution RQST.ACQ- ACQ-INST-ID-


ID Code (P-32) INST-ID-NUM NUM

Forwarding Forwarding Institution FRWD-INST-ID- FRWD-INST-ID-


ID Code (P-33) NUM NUM

Receiving Receiving Institution RCV-INST-ID- RCV-INST-ID-


ID Code (S-100) NUM NUM

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-51
Configuration and Control

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.

May-2014 R6.0v10 SW-DS004-01


2-52 ACI Worldwide, Inc.
ICFE Screens

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.

For complete documentation on ICFE screens 1 through 11 and their


corresponding field descriptions, refer to the BASE24 Base Files Maintenance
Manual. ICFE screens 12 and 13 and descriptions of their fields are provided later
in this section.

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

INTERCHANGE FIID Interchange FIID.

PROCESS Process name as defined in the


XPNET system.

SWITCH TYPE “BICI”

INTERCHANGE LOGICAL NET Logical network identifier.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-53
Configuration and Control

ICFE Screen 1

Field Value

REPORTING NAME BIC ISO Interface name as it


appears on reports.

INSTITUTION ID The institution identifier uniquely


distinguishing this interchange.

SWITCH ID Identifier for the institution that


owns the BASE24 system.

STATION 1 Not used.

STATION 2 Not used.

SIC CODE Not used.

CURRENCY CODE Currency code. If implementing


currency conversion, this value is
the settlement currency.

DEFAULT TERM NUM Not used.

DEFAULT ACQUIRER ID NUM Identifier for the co-network


institution.

CUSTOMER BALANCE DISPLAY 0, 1, 2, or 3.

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

SETTLEMENT HOUR 00–23

SETTLEMENT MINUTE 00–59

May-2014 R6.0v10 SW-DS004-01


2-54 ACI Worldwide, Inc.
ICFE Screens

ICFE Screen 2

Field Value

SETTLEMENT DAYS 0 for five-day settlement, 1 for


seven-day settlement

REPORT PRIORITY 0–255

REPORT CPU CPU number

SWITCH POSTING DATE YYMMDD

HOLIDAY DATES YYMMDD (used with five-day


settlement only)

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

NETWORK MANAGEMENT 0–9999 (seconds)

ACQUIRER Y or N

EXTENDED NETWORK 0–9999 (seconds)

ISSUER Y or N

WAIT FOR TRAFFIC 0–9999 (seconds)

PROCESSING MODE 0 if no totals are to be kept, 1–70 if


totals are to be kept

PERFORMANCE PERIOD 0–9999 (minutes in performance


monitoring period)

AUTO SIGNON START Y or N

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-55
Configuration and Control

ICFE Screen 3

Field Value

MAXIMUM TIMEOUTS 0–9999 (timeouts allowed)

MAX SAF RETRY 0–9999 (SAF retries allowed)

OUTBOUND 0–9999 (outbound transactions


allowed)

ACK TO SWITCH Y or N

INBOUND 0–9999 (inbound transactions


allowed)

ACK FROM SWITCH Y or N

NETWORK MANAGEMENT Y or N. This field should be set to


MESSAGE ENABLED Y if implementing currency
conversion.

TYPE OF INTERCHANGE REPORTS Not used

ILF EXTRACT NUMBER 3–9 (ILFs to be extracted)

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

AUTH PROCESS Authorization process name

DEFAULT ROUTING NUMBER Terminal routing group number

ACQUIRER TXN PROFILE Acquirer transaction profile for


BASE24-atm processing

May-2014 R6.0v10 SW-DS004-01


2-56 ACI Worldwide, Inc.
ICFE Screens

ICFE Screen 8

Field Value

ISSUER TXN PROFILE Issuer transaction profile for


BASE24-atm processing

DEFAULT MERCHANT TYPE Default merchant type

STORE AND FORWARD 0–9999 (seconds)

OUTBOUND 0–9999 (seconds)

INBOUND 0–9999 (seconds)

COMPLETION Not used

COMPLETION ACK Not used

SHARING GROUPS Sharing group codes

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

AUTH PROCESS Authorization process name

REFERRAL PHONE NUMBER Telephone number

RETAILER ID DEFAULT Not used

TIMEOUT ACTION 0, 1, or 2

SETTLE ENTITY 0 or 1

ACQUIRER TXN PROFILE Acquirer transaction profile for


BASE24-pos processing

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-57
Configuration and Control

ICFE Screen 10

Field Value

ISSUER TXN PROFILE Issuer transaction profile for


BASE24-pos processing

ADJUSTMENT FLAG Y or N

CHARGEBACK FLAG Y or N

STORE AND FORWARD 0–9999 (seconds)

OUTBOUND 0–9999 (seconds)

INBOUND 0–9999 (seconds)

COMPLETION Not used

COMPLETION ACK Not used

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

DEFAULT PRE-AUTH AMOUNT Not used

APPROVAL CODE LENGTH 2–6

PRE-AUTH HOLD INCREMENT 0, 1, or 2

PRE-AUTH HOLD TIME 00–99

ALLOWED SERVICES Service code

May-2014 R6.0v10 SW-DS004-01


2-58 ACI Worldwide, Inc.
ICFE Screens

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.

BASE24-ATM ICFE FILE MAINTENANCE LLLL YY/MM/DD HH:MM 12 OF 13


INTERCHANGE FIID: PROCESS:

BASE24 INTERFACE OPTIONS

ACQ STAND-IN AUTH: N ISS STAND-IN AUTH: N


CUTOVER STATUS: 0 VERSION: 00
FIXED LENGTH FORMAT: 0

ITF UPDATE INTERVAL: 030 (MINUTES) ITF UPDATE MAX TRANSACTIONS: 0200
SETTLEMENT TIMER: 000 (MINUTES) PROTOCOL TYPE: 00
SELL RATE: 00000000 BUY RATE: 00000000

PRODUCT INDICATOR (Y/N): N (ATM) N (POS)

DATA PREFIX CHARACTERS


1. 2. 3. 4. 5. 6. 7. 8. 9.
VALID ENTRIES FOR DATA PREFIX CHARACTERS ARE (0 THRU 9) AND (A THRU F)

*********************************** BASE24 ***********************************


NEW PAGE: FILE DESTINATION: NEW LOGICAL NETWORK ID:
F12-HELP

BASE24 INTERFACE OPTIONS

The following fields contain information relevant to the functionality for the BIC
ISO Interface process.

ACQ STAND-IN AUTH — A flag indicating whether BASE24, 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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-59
Configuration and Control

Field Length: 1 alphanumeric character


Required Field: Yes
Default Value: N
Data Name: ICFEBICI.ACQ-STAND-IN

ISS STAND-IN AUTH — A flag indicating whether the co-network, when


acting as the acquirer, is allowed to stand in for BASE24 to authorize transactions
when BASE24 is the issuer. 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

Field Length: 1 alphanumeric character


Required Field: Yes
Default Value: N
Data Name: ICFEBICI.ISS-STAND-IN

CUTOVER STATUS — A flag specifying BASE24’s relationship to the co-


network for cutover and reconciliation processing. Valid values are as follows:

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.

Field Length: 1 alphanumeric character


Required Field: Yes
Default Value: 0
Data Name: ICFEBICI.CTVR-STAT

May-2014 R6.0v10 SW-DS004-01


2-60 ACI Worldwide, Inc.
ICFE Screens

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.

Valid values are as follows:

00 = Release 4.0 format


01 = Release 5.x format
60 = Release 6.0 format

Field Length: 2 numeric characters


Required Field: Yes
Default Value: 00
Data Name: ICFEBICI.VERSION-NUM

FIXED LENGTH FORMAT — A flag indicating whether certain variable-length


data elements in the BIC ISO external message should be sent as fixed-length
fields. Valid values are as follows:

0 = Send variable-length fields


1 = Send fixed-length fields

Field Length: 1 numeric character


Required Field: Yes
Default Value: 0
Data Name: ICFEBICI.FIXED-LGTH-FRMT

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-61
Configuration and Control

Field Length: 3 numeric characters


Required Field: Yes
Default Value: 30
Data Name: ICFEBICI.ITF-UPDT-INTERVAL

ITF UPDATE MAX TRANSACTIONS — The maximum number of


transactions that may occur before the ITF is updated on disk throughout the
processing day. When the number of transactions that have occurred is equal to
the value in this field, the ITF is updated, regardless of the setting in the ITF
UPDATE INTERVAL field. Valid values are 0–9999.

Field Length: 4 numeric characters


Required Field: Yes
Default Value: 0200
Data Name: ICFEBICI.ITF-UPDT-MAX-TRANS

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.

Field Length: 3 numeric characters


Required Field: Yes
Default Value: 000
Data Name: ICFEBICI.SETL

PROTOCOL TYPE — A code indicating the type of protocol message header


processing to be performed. Valid values are as follows:

00 = None
01 = SNA/CICS Protocol
02 = Bisync Multipoint Protocol
03 = X.25 Protocol
04–99 = Reserved for future use

May-2014 R6.0v10 SW-DS004-01


2-62 ACI Worldwide, Inc.
ICFE Screens

If this field is set to 00, no special protocol processing is required. Protocol


processing is performed by the XPNET process.

Field Length: 2 numeric characters


Required Field: Yes
Default Value: 00
Data Name: ICFEBICI.PROTO-TYP

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.

Field Length: 8 numeric characters


Required Field: Required only when supporting currency conversion
Default Value: 00000000
Data Name: ICFEBICI.SELL-RATE

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.

Field Length: 8 numeric characters


Required Field: Required only when supporting currency conversion
Default Value: 00000000
Data Name: ICFEBICI.BUY-RATE

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-63
Configuration and Control

PRODUCT INDICATOR

The following fields indicate the products this interface supports.

ATM — A flag indicating whether BASE24-atm transactions are processed.


Valid values are as follows:

Y = BASE24-atm transactions are processed


N = BASE24-atm transactions are not processed

Field Length: 1 alphanumeric character


Required Field: Yes
Default Value: N
Data Name: ICFEBICI.PROD-IND

POS — A flag indicating whether BASE24-pos transactions are processed. Valid


values are as follows:

Y = BASE24-pos transactions are processed


N = BASE24-pos transactions are not processed

Field Length: 1 alphanumeric character


Required Field: Yes
Default Value: N
Data Name: ICFEBICI.PROD-IND

DATA PREFIX CHARACTERS — Alphanumeric characters that the BIC ISO


Interface process must include at the start of any message being sent to the co-
network. Up to 9 bytes are allowed and they are stored in hex character display
format. These are the ASCII (not EBCDIC) codes. Valid characters are 0–9 and
A–F.

Field Length: 2 alphanumeric characters


Occurs: 9 times
Required Field: No
Default Value: No default value
Data Name: ICFEBICI.DATA-PREFIX-CHARS

May-2014 R6.0v10 SW-DS004-01


2-64 ACI Worldwide, Inc.
ICFE Screens

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.

BASE24-ATM ICFE FILE MAINTENANCE LLLL YY/MM/DD HH:MM 13 OF 13


INTERCHANGE FIID: PROCESS:

BASE24 INTERFACE STATIONS

STATION TYPE DESCRIPTION STATION TYPE DESCRIPTION

*********************************** BASE24 ***********************************


NEW PAGE: FILE DESTINATION: NEW LOGICAL NETWORK ID:
F12-HELP

BASE24 INTERFACE STATIONS

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.

STATION — The symbolic name of the stations to be used for transaction


requests and responses to and from the co-network. At least one station must be
defined.

Field Length: 16 alphanumeric characters


Occurs: Up to 20 times
Required Field: No
Default Value: No default value
Data Name: ICFEBICI.STA.NAM

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-65
Configuration and Control

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

Field Length: 1 numeric character


Occurs: Up to 20 times
Required Field: Required only when the station name is present
Default Value: No default value
Data Name: ICFEBICI.STA.TYP

DESCRIPTION — The description of the value in the type field.

Field Length: System protected


Occurs: Up to 20 times
Data Name ICFEBICI.STA.TYP

May-2014 R6.0v10 SW-DS004-01


2-66 ACI Worldwide, Inc.
KEYF and KEY6 Screens

KEYF and KEY6 Screens


This section contains a listing of KEYF fields used by the BIC ISO Interface
process. The KEY6 contains the same fields as the KEYF, except that PIN
working key fields are on KEY6 screen 2, MAC working key fields are on KEY6
screen 3, and the dynamic key management fields are on KEY6 screen 4. In
addition, the key fields on KEY6 screens allow for double-length keys (i.e., 32
hexadecimal characters instead of 16 hexadecimal characters).

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

DPC/FIID Host DPC number or financial


institution identifier

INTERFACE PROCESS Interface process name

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-67
Configuration and Control

KEYF Screen 1

Field Value

ENCRYPT TYPE 0 for clear PINs, 1 for security


module PIN management, 2 for
software DES PIN management.
This field must contain the value
of 1 if using dynamic PIN key
management.

BASE24 ENCRYPT TYPE 0 for clear PINs, 1 for security


module PIN management

MAC ENCRYPT TYPE 0 for no MAC processing, 1 for


security module MAC processing,
2 for software MAC processing.
This field must contain a 1 if using
dynamic MAC key management.

ANSI PAN FORMAT 0 for the last 12 digits of the PAN,


excluding the check digit; 1 for the
last 12 digits of the PAN,
including the check digit; or 2 for
the first 12 digits of the PAN.

PIN BLOCK FORMAT 0 for clear PINS, 1 for ANSI (PIN/


PAD) PIN block, 3 for PIN/PAD
PIN block. This field must contain
a 1 or 3 if using dynamic PIN key
management.

PIN PAD CHARACTER A–F

MAC DATA TYPE 0 or 1

NUMBER OF KEYS 1 if the same key is used for


inbound and outbound messages,
or 2 if different keys are used for
inbound and outbound messages
or if the KEY PROCESSING
TYPE field on KEYF screen 3 is
set to a value of C.

May-2014 R6.0v10 SW-DS004-01


2-68 ACI Worldwide, Inc.
KEYF and KEY6 Screens

KEYF Screen 1

Field Value

KEY LENGTH 1 for single-length key exchange


keys (KEKs), or 2 for double-
length KEKs

FULL MESSAGE MAC N for authentication of selected


fields, or Y for full message
authentication.

INTERMEDIATE KEYS: CLEAR Clear version of intermediate key

INTERMEDIATE KEYS: ENCRYPTED Encrypted version of intermediate


key

INTERMEDIATE KEYS: CHECK 0–9, A–Z


DIGITS

EXCHANGE KEYS: PIN KEY Two sets of hexadecimal


characters

EXCHANGE KEYS: CHECK DIGITS 0–9, A–Z

EXCHANGE KEYS: MAC KEY Two sets of hexadecimal


characters

EXCHANGE KEYS: CHECK DIGITS 0–9, A–Z

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-69
Configuration and Control

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

OUTBOUND KEYS: PIN KEY1 16 hexadecimal characters

OUTBOUND KEYS: CHECK DIGITS1 4 hexadecimal characters

OUTBOUND KEYS: CURRENT 1 for the value in the PIN KEY1


INDEX 1 field, or 2 for the value in the PIN
KEY2 field.

OUTBOUND KEYS: PIN KEY2 16 hexadecimal characters

OUTBOUND KEYS: CHECK DIGITS2 4 hexadecimal characters

OUTBOUND KEYS: KEY COUNTER 6 hexadecimal characters

INBOUND KEYS: PIN KEY1 16 hexadecimal characters

INBOUND KEYS: CHECK DIGITS1 4 hexadecimal characters

INBOUND KEYS: CURRENT INDEX 1 1 for the value in the PIN KEY1
field, or 2 for the value in the PIN
KEY2 field.

INBOUND KEYS: PIN KEY2 16 hexadecimal characters

INBOUND KEYS: CHECK DIGITS2 4 hexadecimal characters

INBOUND KEYS: KEY COUNTER 6 hexadecimal characters

OUTBOUND KEYS: MAC KEY1 16 hexadecimal characters

OUTBOUND KEYS: CHECK DIGITS1 4 hexadecimal characters

OUTBOUND KEYS: CURRENT 1 for the value in the MAC KEY1


INDEX 1 field, or 2 for the value in the
MAC KEY2 field.

OUTBOUND KEYS: MAC KEY2 16 hexadecimal characters

May-2014 R6.0v10 SW-DS004-01


2-70 ACI Worldwide, Inc.
KEYF and KEY6 Screens

KEYF Screen 2

Field Value

OUTBOUND KEYS: CHECK DIGITS2 4 hexadecimal characters

OUTBOUND KEYS: KEY COUNTER 6 hexadecimal characters

INBOUND KEYS: MAC KEY1 16 hexadecimal characters

INBOUND KEYS: CHECK DIGITS1 4 hexadecimal characters

INBOUND KEYS: CURRENT INDEX 1 1 for the value in the MAC KEY1
field, or 2 for the value in the
MAC KEY2 field.

INBOUND KEYS: MAC KEY2 16 hexadecimal characters

INBOUND KEYS: CHECK DIGITS2 4 hexadecimal characters

INBOUND KEYS: KEY COUNTER 6 hexadecimal characters

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-71
Configuration and Control

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

PIN KEY VARIANT 0 for PIN translation directly from


the PIN KEK parts, or 1 for
translation that includes the
variant 1 constant with the PIN
KEK parts.

MAC KEY VARIANT 0 for translation directly from the


MAC KEK parts, or 3 for
translation that includes the
variant 3 constant with the MAC
KEK parts. This field must be set
to 3 when using dynamic key
management.

PIN KEY TIMER VALUE 0 or 5–1500 if timer interval is


minutes; 0–1000 if timer interval
is hours; or 0–180 if timer interval
is days.

MAC KEY TIMER VALUE 0 or 5–1500 if timer interval is


minutes; 0–1000 if timer interval
is hours; or 0–180 if timer interval
is days.

PIN KEY TIMER INTERVAL D for days, H for hours, or M for


minutes.

MAC KEY TIMER INTERVAL D for days, H for hours, or M for


minutes.

PIN KEY TRAN 0 if a total transaction limit is not


used or 50–100000.

May-2014 R6.0v10 SW-DS004-01


2-72 ACI Worldwide, Inc.
KEYF and KEY6 Screens

KEYF Screen 3

Field Value

MAC KEY TRAN 0 if a total transaction limit is not


used or 50–100000.

PIN KEY ERROR 0 if an error limit is not used or


5–9999

MAC KEY ERROR 0 if an error limit is not used or


5–9999

CONSECUTIVE PIN KEY ERROR 0 if a consecutive error limit is not


used or 5–9999

CONSECUTIVE MAC KEY ERROR 0 if a consecutive error limit is not


used or 5–9999

KMAC SYNCHRONIZATION ERROR 0 if a MAC working key


synchronization error is not used
or 3–9999

CLEAR OLD KEY TIMER VALUE 0 if the old key is not cleared or
1–9999 (seconds)

ORIGINATING ID ID of sender of dynamic key


management messages

RECEIVING ID ID of receiver of dynamic key


management messages

KEY PROCESSING TYPE C if each interface is only


responsible for generating its own
outbound keys, M if the interface
is responsible for all key
generation, S if the interface
receives keys but does not
generate them, or N if dynamic
key management is not used.

NOTARIZATION SUPPORTED “0”

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-73
Configuration and Control

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

INTERF TYP “BIC”

DPC/MOD # Not used

PROCESS NAM Symbolic name of the BIC ISO


Interface process

PROD # 00 for BASE, 01 for the


BASE24-atm product, 02 for the
BASE24-pos product

MSG TYP Allowed external message type or


types

May-2014 R6.0v10 SW-DS004-01


2-74 ACI Worldwide, Inc.
EMF Screens

EMF Screen 1

Field Value

IN-OUT-IND I for incoming, O for outgoing, or


B for both incoming and outgoing

TOKEN GROUP Not used

FULL MSG MAC Y to include all elements when


computing the MAC, N to use the
flag settings for the individual
message elements to determine
which elements are included when
computing the MAC.

MESSAGE ELEMENTS C for conditional, M for


mandatory, or blank if the element
is not used.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 2-75
Configuration and Control

May-2014 R6.0v10 SW-DS004-01


2-76 ACI Worldwide, Inc.
3: Network Management and Operations

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-1
Network Management and Operations

Monitoring Co-Networks and Stations


The BIC ISO Interface process keeps track of the status of all co-networks and
stations with which it communicates using the station table. This station table is
built at initialization and is updated continuously during processing.

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.

May-2014 R6.0v10 SW-DS004-01


3-2 ACI Worldwide, Inc.
Monitoring Co-Networks and Stations

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.

Logon messages are distinguished by a value of 001 in the Network Management


Information Code (S-70) field of the BASE24 external message.

Logon Messages From BASE24

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.

Logon Messages From a Co-network

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-3
Network Management and Operations

Echo Test Messages


Echo test messages are network management messages used to establish whether a
station is available for message processing. They are sent as 0800 messages and
require 0810 messages in response.

Echo tests messages are distinguished by a value of 301 in the Network


Management Information Code (S-70) field of the BASE24 external message.

Echo Test Messages From BASE24

The BIC ISO Interface process initiates echo tests under the following
circumstances:

1. Upon expiration of an Extended Network Management Message timer. This


processing is described in section 2.
2. Upon expiration of a Wait-for-Traffic timer. This processing is described in
section 2.
3. When a co-network initiates a logon after a period of being logged off. The
BIC ISO Interface process sends an echo test to each send/receive station
once the co-network has been marked as logged on.

Echo Test Messages From a Co-Network

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.

May-2014 R6.0v10 SW-DS004-01


3-4 ACI Worldwide, Inc.
Monitoring Co-Networks and Stations

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.

Logoff messages are distinguished by a value of 002 in the Network Management


Information Code (S-70) field of the BASE24 external message. They can be sent
by either BASE24 or a co-network. In either situation, once a co-network is
logged off, BASE24 does not send echo test messages or non-network
management messages to any of the co-network’s stations. Any non-network
management messages that must be forwarded to the co-network are placed in the
SAF instead.

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.

Logoff Messages From BASE24

BASE24 only sends logoff messages to a co-network as a result of a LOGOFF


command issued from a network control facility. BASE24 then expects a logoff
response from the co-network.

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.

Logoff Messages From a Co-Network

When a co-network must log off because of a scheduled down or unavailable


period, it can transmit a logoff message from any of its stations.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-5
Network Management and Operations

Dynamic Key Management Messages


Key management messages make up a subset of network management (0800)
messages. There are four key management messages available:

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

Change Key Message

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.

May-2014 R6.0v10 SW-DS004-01


3-6 ACI Worldwide, Inc.
Monitoring Co-Networks and Stations

New Key Message

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

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.

Verify Key Message

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-7
Network Management and Operations

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.

May-2014 R6.0v10 SW-DS004-01


3-8 ACI Worldwide, Inc.
Dynamic Key Management at Initialization

Dynamic Key Management at Initialization


If BASE24 is set up for dynamic key management, the BIC ISO Interface process
must make sure at initialization that its keys are in place prior to marking a co-
network up and allowing transactions to be processed. To do this, the BIC ISO
Interface process enforces the following sequence of events at initialization as it
begins to establish its communication with a co-network. If dynamic key
management is not being performed, this sequence is not applicable.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-9
Network Management and Operations

Interactive Network Management Message Flows


The remainder of this section contains examples of network management and
dynamic key management message flows, and describes the processing performed
by the BASE24 system for each.

Logon Message Flow


The following pages provide examples of logon sequences and describe the
processing performed by the BIC ISO Interface process.

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.

May-2014 R6.0v10 SW-DS004-01


3-10 ACI Worldwide, Inc.
Interactive Network Management Message Flows

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-11
Network Management and Operations

Co-Network-Initiated Logon

In this example, the co-network logs on to the BASE24 system.

BIC ISO 22 1
Interface Co-network
Process 3

1. The co-network sends a logon message to reestablish communications. The


logon message is identified by the value 001 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. Marks the co-network as logged on.
b. Sets a Wait-for-Traffic timer for each station defined for the co-network.
c. Sends a logon response to the co-network. 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 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. The echo test message is identified by the value
301 in the Network Management Information Code (S-70) field of the
BASE24 External Message.

May-2014 R6.0v10 SW-DS004-01


3-12 ACI Worldwide, Inc.
Interactive Network Management Message Flows

Logoff Message Flow


The following pages provide examples of logoff sequences and describe the
processing performed by the BIC ISO Interface process.

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

1. The BIC ISO Interface process receives a LOGOFF command from a


network control facility. The BIC ISO Interface process sends a logoff
message to each of the co-network’s send/receive stations and starts a
Network Management Message timer for each. The logoff message is
identified by the value 002 in the Network Management Information Code
(S-70) field of the BASE24 External Message.
2. The co-network returns a logoff response (from one or each station). The
logoff response is identified by the value 002 in the Network Management
Information Code (S-70) field of the BASE24 External Message.
3. The BIC ISO Interface process marks the co-network as logged off and clears
the following timers running for the co-network and its stations:
?
Network Management Message timers
?
Extended Network Management Message timers
?
Wait-for-Traffic timers
All other timers are left running to ensure that transactions in progress
complete.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-13
Network Management and Operations

Co-Network-Initiated Logoff

In this example, the co-network logs off from BASE24:

BIC ISO 1
Interface Co-network
Process 22

1. The co-network sends a logoff message to BASE24. The logoff message is


identified by the value 002 in the Network Management Information Code
(S-70) field of the BASE24 External Message.
2. The BIC ISO Interface process receives the logoff message and performs the
following steps:
a. Marks the co-network as logged off.
b. Clears the following timers running for the co-network and its stations:
?
Network Management Message timers
?
Extended Network Management Message timers
?
Wait-for-Traffic timers
All other timers are left running to ensure that current transactions in
progress complete.
c. Sends a logoff response to the co-network. The logoff response is
identified by the value 002 in the Network Management Information
Code (S-70) field of the BASE24 External Message.

May-2014 R6.0v10 SW-DS004-01


3-14 ACI Worldwide, Inc.
Interactive Network Management Message Flows

Echo Test Message Flow


The following example describes how the BIC ISO Interface process handles echo
test messages from the co-network. In this case, the co-network is logged on, but
BASE24 considers the station to be down.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-15
Network Management and Operations

Change Key Message Flow


The diagram below illustrates the message flow between the co-network and BIC
ISO Interface process when the co-network initiates a change key request message.
In this case, the BIC ISO Interface process is responsible for generating the key
being requested. The steps corresponding to the diagram are also described below.

BIC ISO 22 1
Interface Co-network
Process 3

1. The co-network formats and sends an 0800 message with a network


management information code of 161 to the BIC ISO Interface process. This
message includes the Cryptographic Service Message data element (S-123)
containing a Request Service Initiation message (RSI).
2. The BIC ISO Interface process receives the 0800 message and validates it
before responding. To validate the message, the BIC ISO Interface process
performs as follows:
a. Verifies that the RSI is in the correct format. If the RSI is not in the
correct format, the BIC ISO Interface process sets an error flag to a value
of F to indicate that a format error was found.
b. 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 RSI to the value from the
ORIGINATING ID field on KEYF screen 3 or KEY6 screen 4, and the
originator ID from the RSI 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 sets an error flag to a value of H to
indicate that the receiver of originator ID is incorrect.
c. Verifies that there is not already a key exchange action in progress for
the type of key identified in the RSI. The BIC ISO Interface process
checks an internal flag to verify that a key exchange is not currently in
progress. If a key exchange is in progress, the BIC ISO Interface
process sets an error flag to a value of C to indicate that the current
Change Key request cannot be processed.

May-2014 R6.0v10 SW-DS004-01


3-16 ACI Worldwide, Inc.
Interactive Network Management Message Flows

d. Formats an 0810 response message and returns it to the co-network. To


format the response message, the BIC ISO Interface process performs as
follows:
1) If one or more of the above checks failed with an error, the BIC ISO
Interface process formats an 0810 response message with the
response code set to a value of 05 (denied). This message includes
the Cryptographic Service Message data element (S-123)
containing an Error Service Message (ESM). The ERF field in the
ESM includes any error flag values set during the checks. No
further processing is performed.
2) If no errors were encountered in the above checks, the BIC ISO
Interface process formats an 0810 response message with the
response code set to 00 (approved) and a network management
information code of 161. This message includes the Cryptographic
Service Message data element (S-123) containing a copy of the
original RSI. Processing continues with the next step.
3. The BIC ISO Interface process creates a new key and sends it to the co-
network in a New Key message. For a description of this processing, refer to
the “New Key Message Flow” procedure immediately following.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-17
Network Management and Operations

New Key Message Flow


The diagram below illustrates the message flow between the BIC ISO Interface
process and the co-network when the BIC ISO Interface process sends a new key
message. The new key message can be sent manually using text commands or
programmatically when the threshold for a defined working key has been
surpassed. In this scenario, the BIC ISO Interface process is responsible for
generating the key being sent. The steps corresponding to the diagram are also
described below.

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

May-2014 R6.0v10 SW-DS004-01


3-18 ACI Worldwide, Inc.
Interactive Network Management Message Flows

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-19
Network Management and Operations

Repeat Key Message Flow


The diagram below illustrates the message flow between the BIC ISO Interface
process and the co-network when the BIC ISO Interface process initiates a repeat
key message. The BIC ISO Interface process only initiates a repeat key message if
it receives a KEY REPEAT command from a network control facility. The
processing described below starts from the point where the BIC ISO Interface
process receives the text command. The steps corresponding to the diagram are
also described below.

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

May-2014 R6.0v10 SW-DS004-01


3-20 ACI Worldwide, Inc.
Interactive Network Management Message Flows

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-21
Network Management and Operations

Verify Key Message Flow


The diagram below illustrates the message flow between the BIC ISO Interface
process and the co-network when the BIC ISO Interface process initiates a verify
key request message. The BIC ISO Interface process only initiates a verify key
message if it receives a KEY VERIFY command from a network control facility.
The processing described below starts from the point where the BIC ISO Interface
process receives the text command. The steps corresponding to the diagram are
also described below.

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.

May-2014 R6.0v10 SW-DS004-01


3-22 ACI Worldwide, Inc.
Interactive Network Management Message Flows

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-23
Network Management and Operations

BASE24-Initiated Request—MAC Failure


The diagram below illustrates the message flow when a MAC generation failure
occurs on a transaction request initiated by the BASE24 network destined for a co-
network. In this case, a denial response is sent to the BASE24 Authorization
process indicating a MAC security failure condition.

BASE24 11 BIC ISO 22


Authorization Interface Co-network
Process 44 Process
33
11

ILF

1. A BASE24 Authorization process sends a 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 BIC ISO Interface process. The
message fails due to a MAC generation error, and 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).

May-2014 R6.0v10 SW-DS004-01


3-24 ACI Worldwide, Inc.
Interactive Network Management Message Flows

BASE24-Initiated Transaction Response—MAC Failure


The diagram below illustrates the message flow when a MAC generation failure
occurs on a transaction response initiated by the BASE24 network destined for a
co-network and the financial transaction was approved. In this case, a reversal
message is sent to the BASE24 Authorization process indicating a MAC security
failure condition.

BASE24 1 BIC ISO 22


Authorization 44 Interface 3 Co-network
Process 5 Process 6
7
44 66

ILF SAF

1. A BASE24 Authorization process sends a 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 BIC ISO Interface process.
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 an
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).
5. The BASE24 Authorization process returns a 0420 message to the BIC ISO
Interface process, indicating the transaction failed to complete as authorized
due to a MAC generation error. The BIC ISO Interface process locates the
ILF record for the original transaction and updates the ILF with the reversal
information.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-25
Network Management and Operations

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.

May-2014 R6.0v10 SW-DS004-01


3-26 ACI Worldwide, Inc.
Interactive Network Management Message Flows

BASE24-Initiated Transaction Request—MAC Verification


Failure
The diagram below illustrates the message flow when a MAC verification failure
occurs on a transaction request initiated by the BASE24 network destined for a co-
network. In this case, the transaction is rejected and a denial response is sent to the
BASE24 Authorization process indicating the message was rejected.

BASE24 11 BIC ISO 2


Authorization Interface 33 Co-network
Process 5 Process 44
5

ILF

1. A BASE24 Authorization process sends a 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 BIC ISO Interface process.
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 attempts to verify the MAC on the 0110 or
0210 message, but it fails to verify.
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 (i.e., 64 or 128, as appropriate) 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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-27
Network Management and Operations

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

May-2014 R6.0v10 SW-DS004-01


3-28 ACI Worldwide, Inc.
Interactive Network Management Message Flows

Co-Network-Initiated Transaction Request—MAC Failure


The diagram below illustrates the message flow when a MAC generation failure
occurs on a transaction request initiated by the co-network to the BASE24 system
for authorization. In this case, a denial response is sent to the BIC ISO Interface
process indicating a MAC security failure condition.

BASE24 22 BIC ISO 11


Authorization Interface Co-network
Process 33 Process 44
44

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-29
Network Management and Operations

Co-Network-Initiated Transaction Response—MAC Failure


The diagram below illustrates the message flow when a MAC generation failure
occurs on transaction response initiated by the co-network to the BASE24 system
for authorization. In this case, a reversal message is sent to the BASE24
Authorization process indicating a MAC security failure condition.
22 BIC ISO 11
BASE24 33
Authorization Interface 44 Co-network
6 Process 55
Process
7
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 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.

May-2014 R6.0v10 SW-DS004-01


3-30 ACI Worldwide, Inc.
Interactive Network Management Message Flows

Co-Network-Initiated Request—MAC Verification Failure


The diagram below illustrates the message flow when a MAC verification failure
occurs on a transaction request initiated by the co-network and sent to the BASE24
system for authorization. In this case, the transaction is rejected and a denial
response is sent to the BASE24 Authorization process indicating the message was
rejected.

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 3-31
Network Management and Operations

Denied Request Initiated by BASE24—MAC Failure


The diagram below illustrates the message flow when a MAC generation failure
occurs on a transaction request that was denied.

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

BASE24 1 BIC ISO 22


Authorization Interface Co-network
Process 44 Process 33

1. A BASE24 Authorization process sends a 0200 message to the BIC ISO


Interface process.
2. The BIC ISO Interface process reformats the message and sends the 0200 to
the co-network. MAC generation occurs at this point.
3. The co-network cannot verify the MAC so it rejects the transaction and sends
a 9200 message to the BIC ISO Interface process.
4. The BIC ISO Interface process reformats the 9200 message and sends a 0210
message to the Authorization process, indicating the transaction has been
denied.

May-2014 R6.0v10 SW-DS004-01


3-32 ACI Worldwide, Inc.
4: Store-and-Forward Processing

Store-and-forward processing allows for storing transactions that the BASE24


system has processed when a co-network is down or unavailable.

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.

This section describes store-and-forward processing. It includes information on


what messages can be placed in the SAF, when messages are placed in the SAF,
and when messages from the SAF are sent to the co-network. It also contains
messages flows that illustrate store-and-forward processing.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 4-1
Store-and-Forward Processing

The Store-and-Forward File (SAF)


The Store-and-Forward File (SAF) temporarily stores messages bound for a co-
network until those messages can be sent to the intended co-network. The SAF is
a key-sequenced file, and, in general, the messages are processed as first-in, first-
out, as described below.

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.

Co-networks can have store-and-forward messages sent to them using


communications lines, or following long periods of down-time, the SAF can be
extracted to tape in order to keep from clogging communications once
communications have been restored.

Messages Placed in the SAF


The BIC ISO Interface process places the following message types in the SAF:

0120 — Authorization Advice


0121 — Authorization Advice Repeat
0220 — Financial Transaction Advice
0221 — Financial Transaction Advice Repeat
0320 — File Inquiry/Update Advice
0321 — File Inquiry/Update Advice Repeat
0402 — Card Issuer Reversal Request
0420 — Reversal Advice
0421 — Reversal Advice Repeat
0520 — Acquirer Reconciliation Advice
0620 — Administrative Advice
0621 — Administrative Advice Repeat

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.

May-2014 R6.0v10 SW-DS004-01


4-2 ACI Worldwide, Inc.
The Store-and-Forward File (SAF)

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.

Messages Not Placed in the SAF


The BIC ISO Interface process never places the following message types in the
SAF:

0100 — Authorization Request


0110 — Authorization Request Response
0130 — Authorization Advice Response
0200 — Financial Transaction Request
0210 — Financial Transaction Request Response
0230 — Financial Transaction Advice Response
0300 — File Inquiry/Update Request
0310 — File Inquiry/Update Response
0330 — File Inquiry/Update Advice Response
0412 — Card Issuer Reversal Request Response
0430 — Reversal Advice Response
0500 — Acquirer Reconciliation Request
0510 — Acquirer Reconciliation Response
0530 — Acquirer Reconciliation Advice Response
0600 — Administrative Request
0610 — Administrative Response
0630 — Administrative Advice Response

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 4-3
Store-and-Forward Processing

Deleting Messages from the SAF


Records are deleted from the SAF under the following circumstances:

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

Forwarding SAF Messages to a Co-Network


The BIC ISO Interface process checks for the presence of store-and-forward
messages at the following times:

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

May-2014 R6.0v10 SW-DS004-01


4-4 ACI Worldwide, Inc.
The Store-and-Forward File (SAF)

Interspersed SAF Messages

Co-networks have their store-and-forward messages sent to them interspersed with


live transaction messages. This means that the BIC ISO Interface process
continues sending 0100, 0120, 0200, 0220, 0300, 0320, 0600, and 0620 messages
along with its 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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 4-5
Store-and-Forward Processing

Store-and-Forward Message Processing


The general processing flow for SAF messages is the same as for normal
messages. To the co-network, the transactions appear to be happening as the
messages are sent—they are indistinguishable from normal messages. Internally,
the BIC ISO Interface process uses different timers that identify the messages as
SAF records. If the specified timer expires, these messages are left on the SAF to
be resent during store-and-forward processing.

Normal Store-and-Forward Messages


The following diagram illustrates the message exchanges expected by BASE24
when store-and-forward messages are sent to a co-network.

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.

May-2014 R6.0v10 SW-DS004-01


4-6 ACI Worldwide, Inc.
Store-and-Forward Message Processing

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:

1. Writes the message to its log.


2. Deletes the record from the Store-and-Forward File (SAF).
3. Clears the SAF retries count.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 4-7
Store-and-Forward Processing

4. Continues store-and-forward processing with the next record in the Store-


and-Forward File (SAF).

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.

May-2014 R6.0v10 SW-DS004-01


4-8 ACI Worldwide, Inc.
5: Transaction Handling

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-1
Transaction Handling

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

Logging to the ILF


The BIC ISO Interface process logs the following types of messages to the
Interchange Log File (ILF):

?
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

May-2014 R6.0v10 SW-DS004-01


5-2 ACI Worldwide, Inc.
Introduction

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.

If the interface is configured to maintain totals and the original transaction is


located in an old ILF, then the record is not updated when a reversal message is
processed. Instead, the reversal is added to the current day’s ILF as an unmatched
reversal. This approach maintains the integrity of the totals calculated from the
data in the old ILF.

Enhanced ILF Matching


For consistency with other interchange interfaces, the BIC ISO Interchange
Interface can support a POS reversal performed up to 7 days after the original
transaction took place. The interface can be configured to manage seven
additional ILFs, which will be the seven previous ILFs to the current business day.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-3
Transaction Handling

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)

May-2014 R6.0v10 SW-DS004-01


5-4 ACI Worldwide, Inc.
Introduction

?
Local Transaction Date (P-13)
?
Acquiring Institution Identification Code (P-32)
?
Track 2 Data (Primary Account Number) (P-35)

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-5
Transaction Handling

Message Flows to the Co-Network


The following pages describe the message flows for the following transactions
outbound from BASE24 to the co-network.

?
Requests
?
Reversals
?
Force Posts
?
Timeouts

May-2014 R6.0v10 SW-DS004-01


5-6 ACI Worldwide, Inc.
Message Flows to the Co-Network

Request Message to the Co-Network


The diagram below illustrates the message flow when a transaction is initiated by
the BASE24 network and must be sent to the co-network for authorization. The
steps in the diagram are described below.

BASE24 11 BIC ISO 2


Authorization Interface Co-network
Process 44 Process 33
44

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-7
Transaction Handling

Reversal to the Co-Network


When an ATM or POS device connected to the local BASE24 network fails to
complete a transaction as authorized, a reversal message must be sent to the co-
network. The diagram below illustrates message routing when a reversal is sent to
the co-network. The steps in the diagram are described below.

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

May-2014 R6.0v10 SW-DS004-01


5-8 ACI Worldwide, Inc.
Message Flows to the Co-Network

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 0420 message is sent.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-9
Transaction Handling

Force Post Messages to the Co-Network


When the local BASE24 network performs stand-in authorization, it sends the co-
network a force post message for each transaction it authorizes. The diagram
below illustrates message routing when a force post message is sent to the co-
network. The steps in the diagram are described below.

BASE24 11 BIC ISO


Authorization 22 Interface Co-network
Process 3 Process 44
5
33 33

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.

May-2014 R6.0v10 SW-DS004-01


5-10 ACI Worldwide, Inc.
Message Flows to the Co-Network

Timeouts of Requests to the Co-Network


Each time the BIC ISO Interface process sends a 0100 or a 0200 financial
transaction request to the co-network for authorization, the BIC ISO Interface
process starts an outbound request timer. If the outbound request timer expires
before a response is received from the co-network, the transaction is timed out.
The diagram below illustrates message routing when a financial transaction times
out. The steps in the diagram are described below.
Co-network
BASE24 11 BIC ISO 2
Authorization Interface 44
Process 33 Process 5
33 55

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-11
Transaction Handling

d. If stand-in authorization is not allowed and the alternate destination is


not available, the BIC ISO Interface process formats a 0210 internal
response message denying the transaction, returns the response to the
BASE24 Authorization process, and logs a copy of the transaction to the
Interchange Log File (ILF).
4. The co-network sends a 0110 or 0210 late response to the BIC ISO Interface
process. If the transaction was denied by the co-network, the BIC ISO
Interface process drops the late response.
5. If the transaction was approved by the co-network, the BIC ISO Interface
process formats a 0420 external reversal message and adds it to the Store-and-
Forward File (SAF) to be sent to the co-network during store-and-forward
processing.

May-2014 R6.0v10 SW-DS004-01


5-12 ACI Worldwide, Inc.
Message Flows from the Co-Network

Message Flows from the Co-Network


The following pages describe the message flows for the following transactions
inbound to the BASE24 network from the co-network.

?
Requests
?
Reversals
?
Force Posts
?
Timeouts

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-13
Transaction Handling

Request Message from the Co-Network


The diagram below illustrates message routing when a transaction is sent from the
co-network to the BASE24 network for authorization. The steps in the diagram
are described below.

BASE24 22 BIC ISO 11


Authorization Interface Co-network
Process 33 Process 4
4
44

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

May-2014 R6.0v10 SW-DS004-01


5-14 ACI Worldwide, Inc.
Message Flows from the Co-Network

Reversal from the Co-Network


When an ATM or POS device connected to the co-network fails to complete a
transaction as authorized, a reversal message must be sent to the BASE24 network.
The diagram below illustrates message routing when a reversal is sent to the
BASE24 network. The steps in the diagram are described below.

BASE24 22 BIC ISO 11


Authorization 33 Interface 44 Co-network
66 Process 55
Process
77
66 44

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-15
Transaction Handling

Force Post Messages from the Co-Network


The diagram below illustrates message routing when a force post message is sent
to the BASE24 network. The steps in the diagram are described below.

BASE24 2 BIC ISO 11


Authorization Interface Co-network
Process Process 3
3
22

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.

May-2014 R6.0v10 SW-DS004-01


5-16 ACI Worldwide, Inc.
Message Flows from the Co-Network

Timeouts of Request Messages from the Co-Network


Each time the BIC ISO Interface process sends a financial transaction to a
BASE24 Authorization process for authorization, the BIC ISO Interface process
starts an inbound request timer. If the inbound request timer expires before a
response is received from the BASE24 network, the transaction is timed out. The
diagram below illustrates message routing when a financial transaction times out.
The steps in the diagram are described below.
BASE24 22 BIC ISO 1
Authorization Interface 33 Co-network
Process 44 Process
55

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 5-17
ACI Worldwide, Inc.
6: Cutover and Reporting

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-1
Cutover and Reporting

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.

Interchange cutover is initiated by the BASE24-atm Settlement Initiator process or


the BASE24-pos Main Settlement process. As part of product cutover, the
Settlement process sends the BIC ISO Interface process a cutover message. If only
one BASE24 product is present, interchange cutover occurs at the same time as
BASE24 cutover.

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.

May-2014 R6.0v10 SW-DS004-01


6-2 ACI Worldwide, Inc.
BIC ISO Totals

BIC ISO Totals


The BIC ISO Interface process maintains a number of running totals that reflect
the approved transactions processed between the BASE24 network and the co-
network since the last business day cutover. The totals maintained by the BIC ISO
Interface process include the following:

Debit amount — The total amount of all debit transactions

Debit count — The total number of debit transactions

Credit amount — The total amount of all credit transactions

Credit count — The total number of credit transactions

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

Authorization count — The total number of authorization transactions

Inquiries count — The total number of inquiry transactions

Transfers count — The total number of transfer transactions

Transfers reversal count — The total number of transfer reversal transactions

Net settlement amount — The net settlement amount for the cutover date just
completed.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-3
Cutover and Reporting

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.

May-2014 R6.0v10 SW-DS004-01


6-4 ACI Worldwide, Inc.
BIC ISO Totals

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

Deposit W/Cash Back CB O +1 +1

Deposit W/Cash Back O CB +1 +1


Reversal
(Entire Transaction)

Deposit W/Cash Back RA CB +1


Reversal
(Cash Back Amount Only)

Split Deposit O +1

Transfer +1

Transfer Reversal +1

Payment From/To +1

Payment From/To Reversal +1

Payment Enclosed O +1

Balance Inquiry +1

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-5
Cutover and Reporting

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

Normal Purchase Reversal O +1

Preauthorization +1

Preauthorization CA +1
Completion

Preauthorization CA +1
Completion Reversal

Mail/Phone Order O +1

Mail/Phone Order Reversal O +1

Merchandise Return O +1

Merchandise Return O +1
Reversal

Cash Advance O +1

May-2014 R6.0v10 SW-DS004-01


6-6 ACI Worldwide, Inc.
BIC ISO Totals

Transaction Reconcilation Totals

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 W/Cash Back T +1

Purchase W/Cash Back CB T +1


Reversal

Purchase Adjustment N OC +1

Purchase Adjustment N OC +1
Reversal

Merchandise Return OC N +1
Adjustment

Merchandise Return N OC +1
Adjustment Reversal

Cash Advance Adjustment N OC +1

Cash Advance Adjustment N OC +1


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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-7
Cutover and Reporting

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

Interchange Totals File (ITF)


The BIC ISO Interface process accumulates its reconciliation totals in memory
during the business day. These accumulated totals are stored in the Interchange
Totals File (ITF). The BIC ISO Interface process updates the ITF when it has
processed the number of transactions specified in the ITF UPDATE MAX
TRANSACTIONS field on ICFE screen 12 or when the number of minutes
specified in the ITF UPDATE INTERVAL field on ICFE screen 12 have elapsed.

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.

Logging Reversals to the ITF


Because the transaction that is being updated in place may have already been
included in the last ITF update, a reversal could be missed in restart processing
after a process failure. For this reason, a reversal causes all fields in the ITF to be
updated.

May-2014 R6.0v10 SW-DS004-01


6-8 ACI Worldwide, Inc.
BIC ISO Totals

ITF Status Flags


During cutover processing, the BIC ISO Interface process uses three status flags in
the ITF to keep track of the steps that have been performed by the process during
the cutover period. The use of these status flags enables the BIC ISO Interface
process to recover in the event that it is stopped during the cutover period. The
ITF status flags used by the BIC ISO Interface process are described as follows.

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-9
Cutover and Reporting

Cutover Message Processing


The following paragraphs describe the processing performed by the BIC ISO
Interface process when it receives a cutover message from the BASE24 network or
the co-network.

BASE24 Settlement Initiator Process Sends Cutover Message


The following steps are taken by the BIC ISO Interface process when a cutover
message is received from a BASE24 Settlement Initiator process. To cut over, the
BIC ISO Interface process performs as follows:

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.

May-2014 R6.0v10 SW-DS004-01


6-10 ACI Worldwide, Inc.
Cutover Message Processing

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.

Co-Network Sends Cutover Message


The following steps are taken by the BIC ISO Interface process when a cutover
message is received from the co-network. When the cutover message is received,
the BIC ISO Interface process performs as follows:

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-11
Cutover and Reporting

Cutover Message Flows


Cutover processing occurs five or seven days a week. The BIC ISO Interface
process maintains an ILF, which reflects the transaction activity for the co-
network’s business day. For example, when the co-network cuts over to a new
business day, the BIC ISO Interface process closes its oldest ILF, opens a new ILF
for the next day, and starts logging to the ILF reflecting the current business date of
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.

May-2014 R6.0v10 SW-DS004-01


6-12 ACI Worldwide, Inc.
Cutover Message Flows

Equal Partner Reconciliation and BASE24 Cutover


When the BASE24 network and the co-network are equal partners regarding
reconciliation and cutover, the same processing occurs for both. The diagram
below illustrates the message flow when the BASE24 nework cuts over. The steps
in the diagram are described below.

ILF

1 22
3
4

BASE24 BIC ISO 55


Interface Co-network
Settlement
Initiator Process 66
Process

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-13
Cutover and Reporting

3. 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 cutover acknowledgment 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 not processed. The BIC ISO Interface
process sends out the 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).
4. 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.
5. When the settlement interval timer expires, reconciliation totals are sent. 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
acquirer status flag in the ITF to a value of 2 (acquirer settlement message
placed in the SAF). The message type is changed to indicate that this
reconciliation message is a store-and-forward advice message. That is, a
0500 acquirer reconciliation message is changed to a 0520 acquirer
reconciliation advice message.
6. The BIC ISO Interface process sends a type 0502 issuer reconciliation totals
message to the co-network and logs another message stating that the issuer
reconciliation totals were sent. The BIC ISO Interface process sets the issuer
status flag in the ITF to a value of 1 (issuer totals sent), sets a network
management timer, and waits for an issuer settlement acknowledgment
message.
Both the 0500 and 0502 totals messages contain totals for all shared activity
for the BASE24 date that is being cut over.
If no stations are available or if the issuer reconciliation message times out,
the issuer reconciliation message is placed in the Store-and-Forward File
(SAF). If this occurs, the BIC ISO Interface process sets the issuer status flag
in the ITF to a value of 2 (issuer settlement message placed in SAF). The

May-2014 R6.0v10 SW-DS004-01


6-14 ACI Worldwide, Inc.
Cutover Message Flows

message type is changed to indicate that this reconciliation message is a store-


and-forward advice message. That is, the 0502 issuer reconciliation message
is changed to a 0522 issuer reconciliation advice message.
7. The co-network replies with a type 0510 acquirer reconciliation
acknowledgment message. Upon the receipt of the 0510 message, the BIC
ISO Interface process finds and deletes the acquirer network management
timer and sets the acquirer status flag in the ITF to 3 (acquirer
acknowledgment received).
In the event the co-network responds late with the 0510 acquirer
reconciliation response message, it is not processed. The BIC ISO Interface
process sends out a 0520 acquirer reconciliation advice message and the co-
network sends back a 0530 advice response message. When the BIC ISO
Interface process receives the 0530 response, it changes the acquirer status
flag in the ITF to a value of 3 (received acquirer acknowledgment).
8. The co-network replies with a type 0512 issuer reconciliation
acknowledgment message. Upon the receipt of the 0512 message, the BIC
ISO Interface process finds and deletes the issuer network management timer
and sets the issuer status flag in the ITF to a value of 3 (issuer
acknowledgment received).
In the event the co-network responds late with the 0512 issuer reconciliation
response message, it is not processed. The BIC ISO Interface process sends
out a 0522 issuer reconciliation advice message, and the co-network sends
back a 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).
9. The BIC ISO Interface process checks the issuer and acquirer status flags in
the ITF to see if they are both set to a value of 3 (acknowledgments received).
If they are both set to a value of 3, the BIC ISO Interface process sets the ITF
status flag to a value of 4 (totals complete).

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-15
Cutover and Reporting

Equal Partner Reconciliation and Co-Network Cutover


When the BASE24 network and the co-network are equal partners regarding
reconciliation and cutover, the same processing occurs for both. The diagram
below illustrates the message flow when the co-network cuts over. The steps in the
diagram are described below.

ILF ILF

55 11
11
2
Co-
Co-network
BIC ISO 33
Interface
Process 44

1. The co-network sends an 0800 message with an information code of 201 to


the BIC ISO Interface process. This 0800 message contains the business date
for the processing day just ended.
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 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 sends an 0810 cutover acknowledgment
message to the co-network with the information code set to 201.

May-2014 R6.0v10 SW-DS004-01


6-16 ACI Worldwide, Inc.
Cutover Message Flows

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-17
Cutover and Reporting

Main and Secondary Reconciliation when the BASE24 Network


is Secondary
When the two networks are not equal partners regarding reconciliation and
cutover, the secondary network must cut over before the main network. The
diagram below shows the message flow when the BASE24 network is the
secondary network. The steps in the diagram are described below.

ILF ILF

77 33
2
1
44
Co-
Co-network

BASE24 BIC ISO 5


Settlement Interface
Initiator Process 6
Process

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

May-2014 R6.0v10 SW-DS004-01


6-18 ACI Worldwide, Inc.
Cutover Message Flows

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-19
Cutover and Reporting

Main and Secondary Reconciliation when the BASE24 Network


is Main
When the two networks are not equal partners regarding reconciliation and
cutover, the secondary network must cut over before the main network. The
diagram below shows the message flow when the BASE24 network is the main
network. The steps in the diagram are described below.

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.

May-2014 R6.0v10 SW-DS004-01


6-20 ACI Worldwide, Inc.
Cutover Message Flows

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-21
Cutover and Reporting

acquirer status flag in the ITF to a value of 2 (acquirer settlement message


placed in SAF). The message type is changed to indicate that this
reconciliation message is a store-and-forward advice message. That is, the
0500 acquirer reconciliation message is changed to a 0520 acquirer
reconciliation advice message.
8. The BIC ISO Interface process also sends a type 0502 issuer reconciliation
totals message to the co-network and logs another message stating that the
issuer reconciliation totals were sent. The BIC ISO Interface process sets the
issuer status flag in the ITF to a value of 1 (issuer totals sent), sets a network
management timer, and waits for an issuer settlement acknowledgment
message.
Both the 0500 and 0502 totals messages contain totals for all shared activity
for the BASE24 date that is being cut over.
If no stations are available or if the issuer reconciliation message times out,
the issuer reconciliation message is placed in the Store-and-Forward File
(SAF). If this occurs, the BIC ISO Interface process sets the issuer status flag
in the ITF to a value of 2 (issuer settlement message placed in SAF). The
message type is changed to indicate that this reconciliation message is a store-
and-forward advice message. That is, the 0502 issuer reconciliation message
is changed to a 0522 issuer reconciliation advice message.
9. The co-network replies with a type 0510 acquirer reconciliation
acknowledgment message. Upon the receipt of the 0510 message, the BIC
ISO Interface process finds and deletes the acquirer network management
timer and sets the acquirer status flag in the ITF to a value of 3 (acquirer
acknowledgment received).
In the event the co-network responds late with the 0510 acquirer
reconciliation response message, it is dropped. The BIC ISO Interface
process sends out a 0520 acquirer reconciliation advice message and the co-
network sends back a 0530 advice response message. When the BIC ISO
Interface process receives the 0530 response, the acquirer status flag in the
ITF is changed to a value of 3 (received acquirer acknowledgment).
10. The co-network also replies with a type 0512 issuer reconciliation
acknowledgment. Upon the receipt of the 0512 message, the BIC ISO
Interface process finds and deletes the issuer network management timer and
sets the issuer status flag in the ITF to a value of 3 (issuer acknowledgment
received).
In the event the co-network responds late with the 0512 issuer reconciliation
response message, it is dropped. The BIC ISO Interface process sends out a
0522 issuer reconciliation advice message, and the co-network sends back a

May-2014 R6.0v10 SW-DS004-01


6-22 ACI Worldwide, Inc.
Cutover Message Flows

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-23
Cutover and Reporting

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.

May-2014 R6.0v10 SW-DS004-01


6-24 ACI Worldwide, Inc.
Report Overview

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 section provides an overview of the information provided in the interchange


reports. Sample reports are also provided.

SETL01-BIS Clearings Statement Report for BIC ISO


The Clearings Statement Report for BIC ISO reflects the debit, credit, and net
position of the co-network to the BASE24 network.

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-25
Cutover and Reporting

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.

May-2014 R6.0v10 SW-DS004-01


6-26 ACI Worldwide, Inc.
SETL01-BIS CLEARINGS STATEMENT REPORT FOR BIC ISO 1 DATE YY/MM/DD
PAGE 1
-----------------------------------------------------------------------------------------------------------------------------------
TRAN DATE DEBIT CREDIT NET
--------- -------------------- ---------------- ----------------------

ACI Worldwide, Inc.


********** PRO1 TODAY ***********
PRO1 YY/MM/DD 300.00 .00 300.00-

** MINUS INTERCHANGE NOT-TODAY **

May-2014 R6.0v10 SW-DS004-01


SETTLEMENT SUBTOTAL YY/MM/DD 300.00 .00 300.00-

**** ADD INTERCHANGE TODAY *****

SETTLEMENT SUBTOTAL YY/MM/DD 300.00 .00 300.00-

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

********** PRO2 TODAY ***********


Cutover and Reporting

PRO2 YY/MM/DD 450.00 .00 450.00-

** MINUS INTERCHANGE NOT-TODAY **

SETTLEMENT SUBTOTAL YY/MM/DD 450.00 .00 450.00-


**** ADD INTERCHANGE TODAY *****

SETTLEMENT SUBTOTAL YY/MM/DD 450.00 .00 450.00-

ACI Worldwide, Inc.


May-2014 R6.0v10 SW-DS004-01
SETL01-BIS CLEARINGS STATEMENT REPORT FOR BIC ISO 1 DATE YY/MM/DD
PAGE 3
-----------------------------------------------------------------------------------------------------------------------------------
TRAN DATE DEBIT CREDIT NET

ACI Worldwide, Inc.


--------- -------------------- ---------------- ----------------------

********** PRO3 TODAY ***********


PRO3 YY/MM/DD 50.00 .00 50.00-

** MINUS INTERCHANGE NOT-TODAY **

May-2014 R6.0v10 SW-DS004-01


SETTLEMENT SUBTOTAL YY/MM/DD 50.00 .00 50.00-

**** ADD INTERCHANGE TODAY *****

SETTLEMENT SUBTOTAL YY/MM/DD 50.00 .00 50.00-

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

********** SPAN TODAY ***********


Cutover and Reporting

SPAN YY/MM/DD 800.00 .00 800.00-

** MINUS INTERCHANGE NOT-TODAY **

SETTLEMENT SUBTOTAL YY/MM/DD 800.00 .00 800.00-

**** ADD INTERCHANGE TODAY *****

SETTLEMENT SUBTOTAL YY/MM/DD 800.00 .00 800.00-

ACI Worldwide, Inc.


May-2014 R6.0v10 SW-DS004-01
SETL01-BIS CLEARINGS STATEMENT REPORT FOR BIC ISO 1 DATE YY/MM/DD
PAGE 5
-----------------------------------------------------------------------------------------------------------------------------------
CLEARINGS EXCEPTION REPORT

ACI Worldwide, Inc.


****** COMPUTED TOTALS *****

DEBITS CREDITS RVSL/ADJ DEBITS RVSL/ADJ CREDITS


COUNT AMOUNT COUNT AMOUNT COUNT AMOUNT COUNT AMOUNT
------------------------------------------------------------------------------------------------------------------------------------

May-2014 R6.0v10 SW-DS004-01


23 1,150.00 7 350.00 0 .00 7 350.00

****** ACQUIRER SETTLEMENT TOTALS *****

DEBITS CREDITS RVSL/ADJ DEBITS RVSL/ADJ CREDITS


COUNT AMOUNT COUNT AMOUNT COUNT AMOUNT COUNT AMOUNT
------------------------------------------------------------------------------------------------------------------------------------
15 600.00 0 .00 0 .00 0 .00

****** ISSUER SETTLEMENT TOTALS *****

DEBITS CREDITS RVSL/ADJ DEBITS RVSL/ADJ CREDITS


COUNT AMOUNT COUNT AMOUNT COUNT AMOUNT COUNT AMOUNT
------------------------------------------------------------------------------------------------------------------------------------
0 .00 0 .00 0 .00 0 .00

******* END OF REPORT *****

6-31
Report Overview
Cutover and Reporting

DATE — The reporting date (YY/MM/DD) to which these reconciliation figures


apply.

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

MINUS INTERCHANGE NOT-TODAY


The debits, credits, and net amounts not considered part of the co-network
reporting day. These amounts are considered part of the BASE24 network
reporting day.

May-2014 R6.0v10 SW-DS004-01


6-32 ACI Worldwide, Inc.
Report Overview

SETTLEMENT SUBTOTAL — The debit, credit, and net figures not


considered part of the co-network reporting day are subtracted from today’s
business. The result is a reconciliation subtotal for all activity considered as
today’s business by the co-network.

ADD INTERCHANGE TODAY


The debit, credit, and net amounts considered as part of the co-network reporting
day. These amounts are not considered part of the BASE24 network reporting day.

SETTLEMENT SUBTOTAL — The debit, credit, and net figures considered


part of the co-network reporting day are added to today’s business. The result is a
reconciliation subtotal for all activity considered as today’s business by 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.

CLEARINGS EXCEPTION REPORT — The following field descriptions


describe the information that appears on the SETL01 report if there are any
discrepancies between the credits and debits calculated by the BIC ISO Interface
process and the reconciliation records received from 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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-33
Cutover and Reporting

RVSL/ADJ DEBITS COUNT


RVSL/ADJ DEBITS AMOUNT — The total number and amount of all reversal
debit and adjustment transactions.

RVSL/ADJ CREDITS COUNT


RVSL/ADJ CREDITS AMOUNT — The total number and amount of all
reversal credit and adjustment transactions.

ACQUIRER SETTLEMENT TOTALS


This section summarizes the acquirer settlement totals.

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.

RVSL/ADJ DEBITS COUNT


RVSL/ADJ DEBITS AMOUNT — The total number and amount of all acquirer
reversal debit and adjustment transactions.

RVSL/ADJ CREDITS COUNT


RVSL/ADJ CREDITS AMOUNT — The total number and amount of all
acquirer reversal credit and adjustment transactions.

ISSUER SETTLEMENT TOTALS


This section summarizes the issuer settlement totals.

DEBITS COUNT
DEBITS AMOUNT — The total number and amount of all issuer debit
transactions.

May-2014 R6.0v10 SW-DS004-01


6-34 ACI Worldwide, Inc.
Report Overview

CREDITS COUNT
CREDITS AMOUNT — The total number and amount of all issuer credit
transactions.

RVSL/ADJ DEBITS COUNT


RVSL/ADJ DEBITS AMOUNT — The total number and amount of all issuer
reversal debit and adjustment transactions.

RVSL/ADJ CREDITS COUNT


RVSL/ADJ CREDITS AMOUNT — The total number and amount of all issuer
reversal credit and adjustment transactions.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-35
Cutover and Reporting

STAT09-BIC Transaction Detail Report


The BIC Transaction Detail Report provides a complete listing of all interchange
activity. The report is based on the transactions logged to the current day’s ILF.

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.

This report also includes a summary of the transaction detail information


contained in the report.

A sample of the STAT09-BIC Transaction Detail Report is shown on the following


pages, followed by descriptions of the fields that appear on the report.

May-2014 R6.0v10 SW-DS004-01


6-36 ACI Worldwide, Inc.
STAT09-BIC TRANSACTION DETAIL REPORT FOR BIC ISO 1 DATE YY/MM/DD

PAGE 01

------------------------------------------------------------------------------------------------------------------------------------
CARDHOLDER NUMBER TRAN DESC PST DAT B24 DAT-TIM B24 RESP CRD LN ATM FROM ACCT #/POS ACCT # TRAN/BAL/ORIG AMOUNT

ACI Worldwide, Inc.


TRM LN TRM ID SEQUENCE # TRACE # SWI DAT-TIM SWI RESP RV CDE ATM TO ACCT #/POS APPR CODE COMPLETED AMOUNT
ATM TRM OWNER/POS RETLR TRM NAME-LOCATION TRM CITY TRM ST PRD B24 TYP SWI TYP
SPLIT DEP AMT 1 SPLIT DEP AMT 2 MICR
------------------------------------------------------------------------------------------------------------------------------------
12345644000004 W/D FROM SAV 861001 MMDD-HHMMSS 7 000 BIC1 0000000000000000000000000000 .00-
PRO1 S1A91004 001059 056 MMDD-HHMMSS A001 00 0000000000000000000000000000 .00-

May-2014 R6.0v10 SW-DS004-01


0000000000000000000000 ACI OMAHA NE ATM 210 210
0.00- 0.00- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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

CHECK GUAR 0 .00 0 .00


CHECK VERIFY 0 .00 0 .00
Cutover and Reporting

WITHDRAWALS 0 .00 0 .00


DEPOSITS 0 .00 0 .00
BALANCE INFO 0 .00 0 .00
TRANSFERS 0 .00 0 .00
PAYMENTS 0 .00 0 .00
--- ------ --- ------
TOTALS 0 .00 0 .00

ACI Worldwide, Inc.


May-2014 R6.0v10 SW-DS004-01
Report Overview

DATE — The reporting date, in YY/MM/DD format, to which these settlement


figures apply.

CARDHOLDER NUMBER — The number identifying the cardholder who


initiated this transaction.

TRAN DESC — A brief description of the transaction.

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.

CARD LN — The logical network to which this cardholder belongs.

ATM FROM ACCT #/POS ACCT # — The account accessed in this


transaction. This field applies to both BASE24-atm and BASE24-pos
transactions.

TRAN/BAL/ORIG AMOUNT — The transaction amount if this is a


BASE24-atm transaction. If the transaction is a balance inquiry, this field contains
the balance amount. If this is a BASE24-pos transaction, this field contains the
original amount.

TRM LN — The logical network to which this terminal belongs.

TRM ID — The identification number of this terminal.

SEQUENCE # — The sequence number the terminal assigned to this transaction.

TRACE # — An additional identification number the interchange assigned to the


transaction.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-39
Cutover and Reporting

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.

RV CDE — An identifier indicating the reversal code if this transaction was


reversed. If this transaction was not reversed, this field is blank.

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.

COMPLETED AMOUNT — The total amount of the completed transaction.

ATM TRM OWNER/POS RETLR — The terminal-owning institution if this is a


BASE24-atm transaction. If this a BASE24-pos transaction, this field contains the
name of the retailer who owns this terminal.

TRM NAME-LOCATION — The terminal name as assigned by the terminal-


owning institution and its location.

TRM CITY — The city in which this terminal is located.

TRM ST — The state in which this terminal is located.

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.

SPLIT DEP AMT 2 — The second amount involved in a split deposit


transaction.

May-2014 R6.0v10 SW-DS004-01


6-40 ACI Worldwide, Inc.
Report Overview

MICR — The magnetic ink character recognition (MICR) data from the check
involved in this transaction.

TRANSACTION SUMMARY — A summary page of all approved and denied


BASE24 transactions by transaction type. The summary is divided into sections
for BASE24-atm and BASE24-pos transactions.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. 6-41
ACI Worldwide, Inc.
A: BIC ISO Interface Process Startup and
Control

This appendix provides information on the configuration of the BIC ISO Interface
process. It also describes the processing involved for initialization and network
control.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. A-1
BIC ISO Interface Process Startup and 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.

May-2014 R6.0v10 SW-DS004-01


A-2 ACI Worldwide, Inc.
Event Messages

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. A-3
BIC ISO Interface Process Startup and Control

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

ICFE CURRENCY CODE

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

May-2014 R6.0v10 SW-DS004-01


A-4 ACI Worldwide, Inc.
Initialization

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.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. A-5
BIC ISO Interface Process Startup and Control

4. Opens the the Enhanced Interchange Configuration File (ICFE). If an error


occurs, the BIC ISO Interface process logs an error message and abends.
5. Using its process name, reads its own ICFE record.
6. Opens the Token File (TKN) if a TKN assign was found in the LCONF.
7. Initializes the extended memory required for this process.
8. Initializes its timer table.
9. Opens the Key File (KEYF) or Key 6 File (KEY6). If an error occurs, the
BIC ISO Interface process logs an error message and abends.
10. Using its process name, reads its own KEYF or KEY6 record.
11. Builds the Process Control Table (PCT). The PCT contains configuration and
control information for the process. This information is read from the ICFE
and KEYF, and includes all of the controls needed to process transactions.
12. Opens the External Message File (EMF), reads the appropriate records, and
then closes the EMF. If an error occurs, the BIC ISO Interface process logs
an error message and abends.
13. Reads the appropriate TKN records into extended memory.
14. Opens the Interchange Log Files (ILFs) for the current day, the next day, and
up to three previous days. If an error occurs, the BIC ISO Interface process
logs an error message and abends.
15. Initializes the performance counters if the NET24 Performance Monitoring
subsystem is being used.
16. Opens the Store-and-Forward File. If an error occurs, the BIC ISO Interface
process logs an error message and abends.
17. If the BIC ISO Interface process is not a secondary processor, the Interchange
Totals File (ITF) is opened, initialized, and updated.
18. Determines the posting dates for the BASE24-atm product, the BASE24-pos
product, and the co-network by comparing the current time to the
BASE24-atm and BASE24-pos cutover times taken from the LCONF.
19. Updates the ICFE with the current posting dates and then closes the ICFE.
20. Initializes a security device if applicable.
21. Reads the token log records into extended memory.
22. If reports are required, starts a timer to expire when the reports are to be run.
If no reports are to be generated, the BIC ISO Interface process logs an error
message and abends.
23. Starts a performance timer.

May-2014 R6.0v10 SW-DS004-01


A-6 ACI Worldwide, Inc.
Initialization

24. Starts the ITF interval timer if the BIC ISO Interface process is set up to keep
totals.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. A-7
BIC ISO Interface Process Startup and Control

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.

May-2014 R6.0v10 SW-DS004-01


A-8 ACI Worldwide, Inc.
Network Control Commands

Network Control Commands


This section provides a list of the BASE24 commands that can be received by the
BIC ISO Interface process. Many of these commands can be entered by an
operator using a network control facility and serve as a tool that operators can use
to perform network management functions such as changing processing
parameters, warmbooting processes, and monitoring processes.

For detailed descriptions and the syntax of all network control commands, refer to
the BASE24 Text Command Reference Manual.

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. A-9
BIC ISO Interface Process Startup and Control

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

May-2014 R6.0v10 SW-DS004-01


A-10 ACI Worldwide, Inc.
Network Control Commands

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. A-11
BIC ISO Interface Process Startup and Control

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

May-2014 R6.0v10 SW-DS004-01


A-12 ACI Worldwide, Inc.
ACI Worldwide, Inc.
BIC ISO Interface Process Startup and Control

May-2014 R6.0v10 SW-DS004-01


A-14 ACI Worldwide, Inc.
Index

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. Index-1
Index

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

May-2014 R6.0v10 SW-DS004-01


Index-2 ACI Worldwide, Inc.
Index

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

May-2014 R6.0v10 SW-DS004-01


ACI Worldwide, Inc. Index-3
ACI Worldwide, Inc.

You might also like