Base II Clearing Ep Release 4 Operations Guide

BASE II Clearing Edit Package
Operations Guide
Effective: 15 April 2023
Release 4
Visa Supplemental Requirements
© 2010-2023 Visa. All Rights Reserved.

Visa Confidential
Important Information on Confidentiality and Copyright
Notice: The Visa Confidential label signifies that the information in this document is proprietary and CONFIDENTIAL
to Visa. It is distributed to Visa participants for use exclusively in managing their Visa programs. It must not be
duplicated, published, distributed or disclosed, in whole or in part, to merchants, cardholders or any other person
without prior written permission from Visa.
The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively the
"Trademarks") are Trademarks owned by Visa. All other trademarks not attributed to Visa are the property of their
respective owners.
This document is a supplement of the Visa Core Rules and Visa Product and Service Rules. In the event of any conflict
between any content in this document, any document referenced herein, any exhibit to this document, or any
communications concerning this document, and any content in the Visa Core Rules and Visa Product and Service Rules,
the Visa Core Rules and Visa Product and Service Rules shall govern and control.
Visa does not provide legal, regulatory, tax or financial advice. Each participant is fully responsible for ensuring that its
program operates in Compliance with applicable legal and regulatory requirements and is responsible for conducting
independent legal and regulatory reviews through its legal counsel.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE
PERIODICALLY ADDED TO THE INFORMATION HEREIN: THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS
OF THE PUBLICATION. VISA MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE
PROGRAM(S) DESCRIBED IN THIS PUBLICATION AT ANY TIME.
If you have technical questions or questions regarding a Visa service or questions about this document, please
contact your Visa representative.
Contents
Chapter 1 • BASE II Edit Package Overview
BASE II Clearing Edit Package Documentation. . . . . . . . . . . . . . . . . . . . . . 14
Chapter 2 • How BASE II Clearing Edit Package Works

Edit Package Key Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Edit Package Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Mainframe and PC Edit Package for Windows. . . . . . . . . . . . . . . . . . . . . 17
PC Edit Package for Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Edit Package Processing Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Edit Package Outgoing Processing. . . . . . . . . . . . . . . . . . . . . . . . . .19
Edit Package Incoming Processing. . . . . . . . . . . . . . . . . . . . . . . . . . 20
Chapter 3 • BASE II Clearing Edit Package Installation

Edit Package Coordinator Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Supported Platforms and Operating Systems for Edit Package. . . . . . . . . . . . . . . 24
Edit Package Mainframe Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Mainframe Edit Package Operational Requirements. . . . . . . . . . . . . . . . . . 26
Edit Package Mainframe Installation Package Overview. . . . . . . . . . . . . . . . . 28
Subscribe to Edit Package Release 4. . . . . . . . . . . . . . . . . . . . . . . 29
Change Management (CM) Option. . . . . . . . . . . . . . . . . . . . . . . .29
Prepare for Edit Package Mainframe Installation. . . . . . . . . . . . . . . . . . . . 31
Install Edit Package Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Modify and Execute the Edit Package Setup Job to Allocate and Populate Libraries. . . 35
Modify and Run Job to Link Object Modules in Edit Package. . . . . . . . . . . . 37
Modify the Install Utility Job in Edit Package. . . . . . . . . . . . . . . . . . . .37
Modify the Options File in Edit Package. . . . . . . . . . . . . . . . . . . . . .38
Execute the INSTALL Job and Verify Output in Edit Package. . . . . . . . . . . . . 40
Modify and Run DLLBUILD Job to Link Object Modules and Execute EPTBLSPT. . . . . 45
15 April 2023 Visa Confidential 3

BASE II Clearing Edit Package – Operations Guide
Execute Final Setup Job in Edit Package. . . . . . . . . . . . . . . . . . . . . .47
Verify Edit Package Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Understanding the Initial Test Plan for Edit Package. . . . . . . . . . . . . . . . 48
Execute an Outgoing Run Using TC Format in Edit Package. . . . . . . . . . . . . 48
Execute an Incoming Run Using TC Format in Edit Package. . . . . . . . . . . . . 50
Executing an Outgoing Run Using VML in Edit Package. . . . . . . . . . . . . . . 52
Executing an Incoming Run Using VML in Edit Package. . . . . . . . . . . . . . . 54
Edit Package Release 3 and Release 4 Differences. . . . . . . . . . . . . . . . . . . . . 56
Edit Package Processing Related Documentation. . . . . . . . . . . . . . . . . . . . . 57
Edit Package Run Control Options Customization. . . . . . . . . . . . . . . . . . . . . 58
Chapter 4 • Edit Package Outgoing Processing Cycle

Edit Package Outgoing Control Program. . . . . . . . . . . . . . . . . . . . . . . . . 59
Edit Package Outgoing Input Requirements. . . . . . . . . . . . . . . . . . . . . . . 61
Edit Package Outgoing System Initialization. . . . . . . . . . . . . . . . . . . . . . . 62
Edit Package Outgoing Files Creation. . . . . . . . . . . . . . . . . . . . . . . . . . 63
Edit Package Outgoing Exception, Control, and Summary Report Production. . . . . . . . . 65
Edit Package History File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Edit Package Outgoing Log Report Production. . . . . . . . . . . . . . . . . . . . . . 65
Edit Package Outgoing Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . 65
Edit Package Outgoing Run Severe Errors. . . . . . . . . . . . . . . . . . . . . . .66
CTF/VML Errors in Edit Package. . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Edit Package Outgoing Messages. . . . . . . . . . . . . . . . . . . . . . . . . . 66
Edit Package Outgoing Run Error Types. . . . . . . . . . . . . . . . . . . . . . . 67
Edit Package Outgoing Processing Files. . . . . . . . . . . . . . . . . . . . . . . . . 68
Edit Package Repository Table Files. . . . . . . . . . . . . . . . . . . . . . . . . 74
Permanent and Temporary Edit Package Run Control Options Files. . . . . . . . . . . .75
Edit Package Currency Conversion Rates File (Optional). . . . . . . . . . . . . . . . .75
Edit Package History File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Edit Package Rejected Item File. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Edit Package Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Edit Package Incoming Run Hold File. . . . . . . . . . . . . . . . . . . . . . . . 76
Edit Package Backup Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Edit Package Work and Sort Files. . . . . . . . . . . . . . . . . . . . . . . . . . 77
Edit Package Report Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Outgoing Edit Package Processes Controlled By Run Control Options. . . . . . . . . . . . 78
Outgoing Edit PackageE Processes Controlled by Data (TC Formats). . . . . . . . . . . . . 79
Chapter 5 • Edit Package Incoming Processing Cycle

Edit Package Incoming Control Program. . . . . . . . . . . . . . . . . . . . . . . . . 81
Edit Package Incoming Input Requirements. . . . . . . . . . . . . . . . . . . . . . . 83
Edit Package Incoming System Initialization. . . . . . . . . . . . . . . . . . . . . . . 84
Edit Package Incoming CTF/VML Creation. . . . . . . . . . . . . . . . . . . . . . . . 86
Edit Package Incoming Exception, Control, and Summary Report Production. . . . . . . . . 87
Edit Package Incoming File Updates/Creation. . . . . . . . . . . . . . . . . . . . . . . 88
Edit Package Incoming Log Report Production. . . . . . . . . . . . . . . . . . . . . . 89
Edit Package Incoming Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . 89
Edit Package Incoming Severe Errors. . . . . . . . . . . . . . . . . . . . . . . . . 89
Edit Package Incoming Messages. . . . . . . . . . . . . . . . . . . . . . . . . . 89
Edit Package Incoming Error Types. . . . . . . . . . . . . . . . . . . . . . . . . 90
Edit Package Incoming Return Codes. . . . . . . . . . . . . . . . . . . . . . . . 91
Edit Package Incoming Processing Files. . . . . . . . . . . . . . . . . . . . . . . . . 93
Edit Package Incoming File and Table Types. . . . . . . . . . . . . . . . . . . . . 102
Incoming Edit Package Processes Controlled by Run Control Options. . . . . . . . . . . . 104
Incoming Edit Package Process Controlled By Data. . . . . . . . . . . . . . . . . . . . 106
Chapter 6 • Edit Package Run Control Options

Types of Edit Package Run Control Options. . . . . . . . . . . . . . . . . . . . . . . 108
Permanent Edit Package Run Control Options. . . . . . . . . . . . . . . . . . . . . . 108
Temporary Edit Package Run Control Options. . . . . . . . . . . . . . . . . . . . . . 109

Edit Package Profile Parameter Syntax. . . . . . . . . . . . . . . . . . . . . . . .110
Temporary Edit Package Run Control Option Syntax. . . . . . . . . . . . . . . . . 110
Edit Package Run Control Options at a Glance. . . . . . . . . . . . . . . . . . . . . . 111
AUTOUPDT – Request Repository Updates. . . . . . . . . . . . . . . . . . . . . . . 117
BLKTRNCURAMT – Blank Transaction Identifier Tolerance by Currency. . . . . . . . . . . .118
BLKTRNIDTOLER – Blank Transaction - Identifier Tolerance Checking. . . . . . . . . . . . 119
CENTRBIN – Center BASE II CIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
CENTRCODE – Center Security Code. . . . . . . . . . . . . . . . . . . . . . . . . . 120
CENTRNAME – Center Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
CHARSET – Character Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
COUNTRY – Country Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
DATEFORMAT – Date Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
DATESEP – Date Separator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
DESTNAME – Destination Application Name. . . . . . . . . . . . . . . . . . . . . . .126
DIRECTION – Run Outgoing or Incoming. . . . . . . . . . . . . . . . . . . . . . . . 126
DLLNAME – Name Load DLLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
DLLPARM – Pass Parameter to a DLL. . . . . . . . . . . . . . . . . . . . . . . . . . 128
DLLPARM Options for VML Builder. . . . . . . . . . . . . . . . . . . . . . . . . 129
DLLPARM Options for Parser. . . . . . . . . . . . . . . . . . . . . . . . . . . .130
DLLPARM Rule Processor Options. . . . . . . . . . . . . . . . . . . . . . . . . 130
DLLPARM Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
DUPBATCH – Duplicate Batch Detection. . . . . . . . . . . . . . . . . . . . . . . . 131
DUPBATCH Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . 132
EXCPRPTFMT – Exception Report Format. . . . . . . . . . . . . . . . . . . . . . . . 133
EXCPRPTSEQ – Exception Report Sequence. . . . . . . . . . . . . . . . . . . . . . . 134
EXTRACT – Extract and Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Edit Package History File Report. . . . . . . . . . . . . . . . . . . . . . . . . . 135
VID, ARDEF, and Value Extract Report. . . . . . . . . . . . . . . . . . . . . . . . 136
LOG File Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

LOGLOC Argument Syntax for z/OS. . . . . . . . . . . . . . . . . . . . . . . . . 137
LOGLOC Argument Syntax for Windows. . . . . . . . . . . . . . . . . . . . . . . 138
FEERPTFMT – Fee Transaction-Based Format. . . . . . . . . . . . . . . . . . . . . . .138
FILEIDMOD – Specify File Identification Modifier. . . . . . . . . . . . . . . . . . . . . 139
FILELOC – File Location. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
FILELOC Argument Syntax for z/OS. . . . . . . . . . . . . . . . . . . . . . . . . 141
FILELOC Argument Syntax for Windows. . . . . . . . . . . . . . . . . . . . . . . 142
FILEOUT – File Output Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
FILETYPE – Specify File Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
FPOSTCURAMT – Force-Post Tolerance by Currency. . . . . . . . . . . . . . . . . . . 143
FPOSTTOLER – Force-Post Tolerance Checking. . . . . . . . . . . . . . . . . . . . . . 144
HISTPURGE – History Maintenance Processing. . . . . . . . . . . . . . . . . . . . . . 145
HISTRETPD – History Retention Period. . . . . . . . . . . . . . . . . . . . . . . . . 146
INPUTSEQ – Input Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
INTERNAL – Internal Application Indenter. . . . . . . . . . . . . . . . . . . . . . . . 148
ITEMCURAMT – Item Tolerance by Currency. . . . . . . . . . . . . . . . . . . . . . . 148
ITEMTOLER – Item-Level Tolerance Checking. . . . . . . . . . . . . . . . . . . . . . 149
ITFHASH – ITF Data Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
LANG – Language Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
MAXBATRECS – Number of Records in a Batch. . . . . . . . . . . . . . . . . . . . . . 152
MESSAGE – Write a Message on the Log. . . . . . . . . . . . . . . . . . . . . . . . 153
NETAGENT – Network Agent Threads. . . . . . . . . . . . . . . . . . . . . . . . . .153
NOSEQ – No Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . 154
NUMDECSEP – Number Decimal Separator. . . . . . . . . . . . . . . . . . . . . . . 155
NUMTHOUSEP – Number Thousands Separator. . . . . . . . . . . . . . . . . . . . . 155
OUTCHARSET – Outgoing Output File Character Set. . . . . . . . . . . . . . . . . . . 156
PORT – TCP/IP Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
PROFILE – Configuration Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
PROFILE Parameter Set Defaults. . . . . . . . . . . . . . . . . . . . . . . . . . 158

REJITFLIM – ITF/VTF Error Threshold. . . . . . . . . . . . . . . . . . . . . . . . . . 159
REJMSGLIM – Error Reporting Threshold. . . . . . . . . . . . . . . . . . . . . . . . 160
REPORTS – Generate Summary Reports. . . . . . . . . . . . . . . . . . . . . . . . . 162
RERUN – ITF/VTF Error Threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . 163
RERUN - Outgoing Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . 163
RERUN - Incoming Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . 164
RUNCURAVG – Run Tolerance Amount and Currency. . . . . . . . . . . . . . . . . . . 165
RUNDATE – Run Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
RUNMODE – Run Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
RUNTOLER – Run Tolerance Checking. . . . . . . . . . . . . . . . . . . . . . . . . 168
SAVEREJECT – Save File Rejects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
SAVERETURN – Save Returned Transactions. . . . . . . . . . . . . . . . . . . . . . . 170
SHUTDOWN – Service Termination Event. . . . . . . . . . . . . . . . . . . . . . . . 172
SOURCENAME – Identify Processing Center Source. . . . . . . . . . . . . . . . . . . .172
SPLITBYARD – Split ITF/VTF by Account Range. . . . . . . . . . . . . . . . . . . . . . 173
SPLITBYBIN – Split ITF/VTF by Destination Identifier. . . . . . . . . . . . . . . . . . . 174
SPLITBYPID—Split ITF/VTF by Product ID. . . . . . . . . . . . . . . . . . . . . . . . 176
SPLITBYSET – Split ITF/VTF by Settlement Flag. . . . . . . . . . . . . . . . . . . . . . 177
SPLITBYTC – Split ITF/VTF by CTF Transaction. . . . . . . . . . . . . . . . . . . . . . 178
SPLITBYTT – Split ITF/VTF by VML Transaction. . . . . . . . . . . . . . . . . . . . . . 179
SPLITINFIL – Split ITF/VTF Into Multiple Files. . . . . . . . . . . . . . . . . . . . . . .181
SPLITCONLY – Write Collection-Only Transactions Into a Separate Outgoing File. . . . . . . 183
SPLITCONLY - Outgoing Interchange File Split. . . . . . . . . . . . . . . . . . . . 183
SPLITCONLY - CONLY File Type. . . . . . . . . . . . . . . . . . . . . . . . . . .184
SPLITCONLY - Collection-Only Reports. . . . . . . . . . . . . . . . . . . . . . . 184
STOPRC – Stop If Return Code High. . . . . . . . . . . . . . . . . . . . . . . . . . 185
START – Service Initialize Event Definition. . . . . . . . . . . . . . . . . . . . . . . . 185
TABLEDATE – Effective Date for Table Values. . . . . . . . . . . . . . . . . . . . . . . 186
TBLKEY AND TBLDATA – TABLE OVERRIDE. . . . . . . . . . . . . . . . . . . . . . . .187

TBLKEY – TABLE KEY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
TBLDATA – TABLE DATA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
VID and ARDEF Table Overrides. . . . . . . . . . . . . . . . . . . . . . . . . . 188
TIMESEP – Time Separator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
TRANRPTSEQ – Transaction Report Sequence. . . . . . . . . . . . . . . . . . . . . . 198
TRIALRUN – Trial Run. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
TRNINPRT – Print Incoming Reports. . . . . . . . . . . . . . . . . . . . . . . . . . 199
TRNNOINPRT – Stop Incoming Report Printing. . . . . . . . . . . . . . . . . . . . . 200
TRNOOUTPRT – Stop Outgoing Report Printing. . . . . . . . . . . . . . . . . . . . . 201
TRNOPASS – Exclude Transactions From Output. . . . . . . . . . . . . . . . . . . . . 202
TRNOUTPRT – Print Outgoing Reports. . . . . . . . . . . . . . . . . . . . . . . . . 203
TRNPASS – Include Transactions on Output. . . . . . . . . . . . . . . . . . . . . . . 204
VALERROR – Validation Errors Reported. . . . . . . . . . . . . . . . . . . . . . . . .205
VALIDATE – Validation Edits Bypass. . . . . . . . . . . . . . . . . . . . . . . . . . .205
WORKDIR – Work Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
WRITEHEADR – Incoming Header Record. . . . . . . . . . . . . . . . . . . . . . . . 206
Chapter 7 • Support Utilities, Extract, and On-Request Reporting

EP4U010—Install Setup Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
EP4U100—Initialize History File. . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
EP4U130—Apply TC 54 Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
EP4U132—Load Repository Files From Master. . . . . . . . . . . . . . . . . . . . . . 211
EP4U140—Apply Software Updates From Visa Online (VOL). . . . . . . . . . . . . . . . 211
Edit Package Extract and On-Request Reporting. . . . . . . . . . . . . . . . . . . . . 211
Combined (ACQ/ISS ID & ARD) (EP–304) File Extract Utility. . . . . . . . . . . . . . 213
Appendix A • System Modules and Files

Edit Package System Components. . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Edit Package Repository Files. . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Edit Package Repository File Contents. . . . . . . . . . . . . . . . . . . . . . 215

Edit Package Core Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Edit Package Workstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Edit Package Workstation Client-Server Overview. . . . . . . . . . . . . . . . . 220
EP Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
EP Workstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
Edit Package Software Updates and Distribution. . . . . . . . . . . . . . . . . . . . . 221
Edit Package Distribution Events. . . . . . . . . . . . . . . . . . . . . . . . . . 221
Edit Package Initial Software Installation. . . . . . . . . . . . . . . . . . . . . . .221
Edit Package Subsequent Software Updates. . . . . . . . . . . . . . . . . . . . . 222
Edit Package Repository File Updates. . . . . . . . . . . . . . . . . . . . . . 222
Edit Package Core Updates. . . . . . . . . . . . . . . . . . . . . . . . . . 222
EP Workstation Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Edit Package Application Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . 224
Edit Package Repository File Maintenance. . . . . . . . . . . . . . . . . . . . . . 224
Actions to Keep Edit Package Repository Files Current. . . . . . . . . . . . . . . 224
Out-of-Date Edit Package Repository Tables. . . . . . . . . . . . . . . . . . . 225
Edit Package Software Code Maintenance—Mainframe and PC. . . . . . . . . . . . . 226
Edit Package Return Code of 6 During Incoming Run. . . . . . . . . . . . . . . 226
VOL Processing Updates for Edit Package. . . . . . . . . . . . . . . . . . . . 226
Appendix B • Edit Package File Layouts

Edit Package Currency Conversion Rates File Layout. . . . . . . . . . . . . . . . . . . 229
Edit Package History File Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Edit Package History Backup File Layout. . . . . . . . . . . . . . . . . . . . . . . . 237
Edit Package Incoming Run Hold File Layout. . . . . . . . . . . . . . . . . . . . . . 238
Edit Package Log File Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Permanent Edit Package Run Control Options File Layout. . . . . . . . . . . . . . . . . 239
Edit Package TC 33 Extract File Layout. . . . . . . . . . . . . . . . . . . . . . . . . 240
Edit Package Rejected Item File Layout. . . . . . . . . . . . . . . . . . . . . . . . . 241
Edit Package Returned Item File Layout. . . . . . . . . . . . . . . . . . . . . . . . . 244

Temporary Edit Package Run Control Options File Layout. . . . . . . . . . . . . . . . . 245
Edit Package Repository Profile Table File Layout. . . . . . . . . . . . . . . . . . . . . 246
Edit Package Repository Value Table File Layout. . . . . . . . . . . . . . . . . . . . . 247
Edit Package Repository Table File - Account Range Definition (ARDEF) Table Layout. . . . . 248
ARDEF File Header Record Layout. . . . . . . . . . . . . . . . . . . . . . . . . 249
ARDEF Value Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Edit Package Repository Table File - VID (Visa Identifier) Table Layout. . . . . . . . . . . . 256
VID Table File Header Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . 257
VID Table Detail Record Layout. . . . . . . . . . . . . . . . . . . . . . . . . . .258
ARDEF Extract File Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Combined (ACQ/ISS ID & ARD) Extract File Layout. . . . . . . . . . . . . . . . . . . . 267
ACQ/ISS ID Extract File Layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Edit Package Value Table Extract Files Layouts. . . . . . . . . . . . . . . . . . . . . . 280
Edit Package Country Code Table. . . . . . . . . . . . . . . . . . . . . . . . . .281
Edit Package Currency Code Table. . . . . . . . . . . . . . . . . . . . . . . . . 283
Edit Package Holiday Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Edit Package Merchant Category Code Table. . . . . . . . . . . . . . . . . . . . .284
Edit Package Chargeback Reason Code Table. . . . . . . . . . . . . . . . . . . . 286
Edit Package Transaction Code Table. . . . . . . . . . . . . . . . . . . . . . . . 293
Edit Package Fee Reason Code Table. . . . . . . . . . . . . . . . . . . . . . . . 296
Edit Package Return Reason Code Table. . . . . . . . . . . . . . . . . . . . . . . 298
Edit Package Regulated Account Range Table Extract. . . . . . . . . . . . . . . . . 298
Edit Package Business Application ID (BAI) Table Extract. . . . . . . . . . . . . . . . 299
Appendix C • Summary of Edit Package Reports

Outgoing Edit Package Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Incoming Edit Package Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Edit Package On-Request Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Optional Transaction-Based Reports in Edit Package. . . . . . . . . . . . . . . . . . . 305
Index of Edit Package Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

Appendix D • Edit Package Print/Pass Defaults
BASE II Glossary

Chapter 1
BASE II Edit Package Overview
The BASE II Edit Package is software supplied by Visa for processing transaction files sent to, and
received from, a VisaNet Interchange Center (VIC). Edit Package is the interface between the
processing center’s internal payment processing system and an Extended Access Server (EAS) or
Direct Exchange (DEX). It prepares the processing center’s outgoing interchange for transmission to
the VIC. Edit Package also receives and reports on incoming interchange from Visa, preparing it for
the processing center’s Host system.
Edit Package (Release 4) includes these enhancements:
l Added support for the Visa Markup Language (VML) using a format-independent
architecture.
l Upgraded the Edit Package for Windows to a client-server architecture.
l Enhanced the Edit Package for Windows user interface.
l Added new run control options and discontinued outdated run control options.
l Replaced the Rules table file with executable modules.
l Replaced the Language table file with an expanded Repository table file.
l Added new utilities and discontinue outdated utilities.
l Improved transaction error messaging.
l Added support for Enhanced File Service Collection Only Data

BASE II Edit Package Overview
Edit Package (Release 4) is not backwards-compatible with any previous version of the Edit Package.
Release 4 will require a complete reinstallation of the Edit Package.
Note:
All acquirers, issuers, and processors converted to Edit Package (Release 4) by April 2012.
All BASE II manuals for Edit Package were completely revised for Release 4. Installation and run
control options allow processing centers to customize the Edit Package to their needs. Edit Package
(Release 4) provides additional installation options and run control options.
Edit Package (Release 4) also provides upgrades to the user interface, error messages, utilities, code
modules, and Edit Package tables.

Documentation
The following documentation is available.
l BASE II Clearing Edit Package Messages Reference Guide - Release 4
l BASE II Clearing Edit Package Reports Reference Guide - Release 4
l BASE II Clearing Interchange Formats, TC 01 to TC 49
l BASE II Clearing Interchange Formats, TC 50 to TC 92
l BASE II Clearing PC Edit Package for Windows User Guide - Release 4
l Visa Core Rules and Visa Product and Service Rules
l Visa Merchant Data Standards Manual
Note: VML is no longer supported.

Chapter 2
How BASE II Clearing Edit Package
Works
Edit Package Key Features

The Edit Package provides flexibility for installation and daily processing.
Key features for mainframe and PC platforms:
l Format-independent architecture
l Use of edit programs and value tables
l Availability of run control options
Key features for PC platforms:
l Client-server architecture
l File transfer support
l Data entry
l Batch facility
l System administration

How BASE II Clearing Edit Package Works
Format-Independent Architecture:
Release 4 software uses a common internal format for its basic core processing, validation, reporting,
and PC Edit Package for Windows data entry.
Edit Package (Release 4) supports the standard Visa published formats. Release 4 has built-in
compatibility to support processing of Visa BASE II transactions. Release 4 software includes Parser
and Builder components to support TC and VML formats.
Edit Programs and Value Tables:

Edit Package transaction validation is performed using a common internal format and business rules
defined in edit programs and value tables for both TC and VML formats. The business rules and value
tables have an effective date which supports testing of future business enhancement by setting run
control option TABLEDATE to the effective date of the release. When new business enhancements are
developed, the changes to the edit programs and repository tables can be downloaded from the VIC
to the processing center through incoming interchange or through Visa Online (VOL).
Run Control Options:

Access to most functions in the Edit Package is available through run control options. The use of run
control options allows processing centers to customize the Edit Package to their specific processing
needs. Run control options can be modified either at installation time or before each Edit Package
processing run.
Run control options allow the selection of various functions, including:
l Splitting incoming ITF or VTF files into multiple CTF or VML files.
l Setting tolerance checking limits at the run levels or at the item levels.
l Establishing duplicate batch detection settings.
l Writing on-us transactions into a separate outgoing ITF or VTF file.
Edit Package Functions

Edit Package functions are divided into Mainframe functions and PC Edit Package for Windows
functions.

Mainframe and PC Edit Package for Windows

Mainframe and PC Edit Package for Windows functions are further divided into environmental,
formatting, validation, and reporting groups.
Environmental:
These functions determine the environment in which the Edit Package is run. Through the use of run
control options, the processing center can modify how the Edit Package software runs in the
individual environments.
Formatting:
One of the functions of the Edit Package is to format CTF/VML data into ITF/VTF data during an
outgoing cycle and to format ITF/VTF data into CTF/VML data during an incoming cycle.
The processing center can control some formatting functions so that outgoing and incoming files
and transactions can be more easily processed by the center’s internal systems.
Validation:
Validation of interchange is a major function of the Edit Package. In addition to standard validation,
processing centers can select additional forms of validation, such as setting of tolerance levels at
both the run and item levels. Additional validation functions are controlled through run control
options.
Reporting:
The Edit Package also includes functions for reporting. Formatted reporting of outgoing and
incoming transactions is available. Processing centers can select which particular transaction codes
are reported.
Formats for dates, time, and numeric values can be modified according to national standards and are
available using run control options.
PC Edit Package for Windows

PC Edit Package for Windows has additional functionality related to client-server architecture, file
transfer support, data entry, batch facility, and system administration.
Client-Server Architecture:
Edit Package (Release 4) has similar functionality to previous versions of the PC EP for Windows.
However, instead of a single executable application installed on a PC, Release 4 includes separate
installed components for a user interface and server functions in a client-server architecture.

File Transfer Support:

Both TC and VML formats are supported for sending and receiving files to and from Visa, using the
following interface types:
l Direct Exchange (DEX)
l Extended Access Server (EAS)
l Secure Extended Access Server (EAS)
Data Entry:
The Data Entry component is available to processing centers whether the Edit Package runs on a
mainframe or a PC. They give processing centers the ability to key-enter original transactions that
can be validated online.
The Data Entry component’s validation logic uses the same validation rules and repository tables as
the core Edit Package.
The Data Entry component also provides a mechanism for correcting transactions rejected by the
Edit Package and transactions returned by the VIC.
Batch Facility:
The Batch Facility component is used to set up and maintain batch procedures, submit them for
immediate execution or schedule a Batch Facility job for a given date/time using the Windows
scheduler, and view completed jobs and batch job history.
The Batch Facility may be used for six Edit Package processes. These are:
l Incoming File Transfer (EAS or DEX)
l Incoming Edit Run
l Outgoing Edit Run
l Outgoing File Transfer (EAS or DEX)
l Table Extracts
l Table Reports
System Administration:
The Administrative function provides configuration tools for the following functions:
l Operator ID—Establishes operator IDs, passwords, and privileges
l BASE II CIB Setup—Set up CIBs for test and production
l DEX Setup—Identifies DEX connection to the Edit Package

l EAS Set Up—Identifies EAS connection to the Edit Package

l Batch Facility—Set up and maintain batch procedures
Note:
For more detailed information on Edit Package for Windows functionality, see BASE II
Clearing PC Edit Package for Windows (Release 4) User’s Guide.
Edit Package Processing Flow

The Edit Package has two processing phases: outgoing interchange processing and incoming
interchange processing. The processing phase is identified through a run control option
(DIRECTION).
Edit Package Outgoing Processing

The term outgoing refers to interchange sent from the client's processing center to the VIC.
Outgoing Interchange

Pre-Edit Processing:
The first part of the outgoing process is performed by software belonging to the processing center.
This is usually referred to as pre-edit processing, since it is done before processing by the Edit
Package. Pre-edit processing involves the capture, editing, and formatting of interchange data.
Transactions submitted into interchange are processed through the processing center’s pre-edit
software, which places this information into a Center Transaction File (CTF) or Visa Markup Language
file (VML). Once pre-editing is completed, the data is ready to be run through the Edit Package.
Edit Package Processing:

Running with Run Control Option of DIRECTION=OUTGOING causes the Edit Package to perform an
outgoing Edit Package run, processing each transaction found in the input CTF/VML file(s). Run
Control Option (PROFILE) is used to identify a named set of options defined in the repository table
for Outgoing processing. For example, PROFILE=OUTGOINGTC includes the run control options such
as DIRECTION=OUTGOING, file type formats required for input and output files, and the parser and
builder components that will be used for the run.
At the end of processing, the control program produces the necessary reports. Then the Edit Package
produces an Interchange Transaction File (ITF) or a VisaNet Transaction File (VTF) which is transferred
to an Extended Access Server (EAS) or Direct Exchange (DEX) where it is held until a predetermined
collection time. The transmission of the file is jointly managed by the EAS/DEX and VIC with little or
no intervention required by center personnel.
BASE II System Processing

At a predetermined time, the BASE II System at the VIC collects the interchange files from EAS or
DEX. As the interchange transactions are received by BASE II at the VIC, clearing occurs. The
transactions are validated, converted to the appropriate currencies, and totaled and sorted by
destination. Fees are then calculated. At the end of each BASE II cycle, settlement positions are
computed for all clients with either incoming or outgoing transactions.
Interchange data are protected from system failure after being accepted by the VIC. In the event of a
failure, the BASE II System can restart processing where the failure occurred. If required, interchange
files can also be rebuilt and electronically transmitted to the processing center.
Edit Package Incoming Processing

The term incoming refers to interchange coming into the client's processing center from the VIC.

Incoming Interchange
Running with Run Control Option of DIRECTION=INCOMING causes the Edit Package to perform an
incoming Edit Package run, processing each transaction found in the input ITF/VTF file(s). Run
Control Option (PROFILE) is used to identify a named set of options defined in the repository table
for Incoming processing. For example, PROFILE=INCOMINGTC includes the run control options such
as DIRECTION=INCOMING, file type formats required for input and output files, and the parser and
builder components that will be used for the run.
At the end of processing, the control program produces the necessary reports and makes the CTF/
VML(s) available for use by the processing center if there are no severe errors in the interchange file.
Incoming Edit Package files contain:
l Financial and nonfinancial interchange transactions.
l Settlement totals.
l VSS settlement reports.
l Edit Package table and code update transactions.
Note:

To ensure proper application of table and code update transactions, all incoming files must
be processed. Files must be processed in sequence by the Central Processing Date (CPD) on
which they were created to properly update the repository tables and code-related files.
Post-Edit Processing:
Post-edit software, written by center personnel or by an outside vendor, reformats and processes
incoming interchange received from the VIC. This software prepares interchange so that it can be
processed by cardholder and merchant posting programs and used for other processing center
purposes, such as fraud analysis.

Chapter 3
Installation
Edit Package installation includes installing, testing, and certifying the Edit Package.
Installation details include:
l Edit Package Coordinator—Lists the responsibilities of the Edit Package Coordinator.
l General Information—Discusses hardware and software operating system requirements for
each Edit Package platform.
l Mainframe Installation—Describes the mainframe operational requirements, beginning with
an installation checklist, followed by the mainframe installation package contents and
installation procedures.
l Certification—Describes testing requirements and procedures, and includes a certification
checklist.
The following terms are used:
l Visa Account Manager—A Visa representative who is responsible for the account.
l Edit Package Coordinator—A person responsible for the installation of the Edit Package.

BASE II Clearing Edit Package Installation
Edit Package Coordinator Role

Each installation should designate a person as the Edit Package Coordinator. The Edit Package
Coordinator is responsible for Edit Package installation, operation, and maintenance. The Coordinator
should have access to Visa Online (VOL) to download the mainframe installation package and be able
to transfer files from the installation media or PC to mainframe, link programs, modify and execute
job control statements, and establish backup and restore procedures. The Coordinator should also be
familiar with the processing center’s pre-edit and post-edit programs. At a new processing center, the
Coordinator should be a client of the task force established for planning implementation.
The Coordinator is expected to notify Visa about:
l Changes in the Edit Package’s operational status.
l Installation problems encountered at the processing center.
The Coordinator should evaluate the operational requirements of the installation procedures to
ensure that the processing center has the required hardware, sufficient memory and disk space to
accomplish the installation, and the appropriate IBM Language Environment and Class libraries when
installing. The Coordinator should contact the Visa Account Manager if the processing center does
not meet Edit Package operational requirements and special arrangements are required.
The Edit Package Coordinator should contact the Visa Account Manager if any installation problems
are encountered.
Note:
A minimum of one year of technical experience on a mainframe and PC is strongly
recommended for someone to successfully install the Edit Package.
Supported Platforms and Operating

Systems for Edit Package
Visa supplies Edit Package software that runs on the following platforms and operating systems.
Supported Platforms and Operating Systems
Platform Operating System
Mainframe Edit Package 4 will be supported on versions of z/OSs that are supported by IBM.
PC Edit Package 4 will be supported on versions that are supported by Microsoft.

Detailed information about the recommended Microsoft OS version can be found
in the BASE II Clearing PC Edit Package for Windows (Release 4) User’s Guide.

Edit Package Mainframe Installation

The mainframe installation procedures cover IBM z/OS platforms. Processing centers follow the same
basic steps for all mainframe platforms. It takes approximately 1–2 work days to install the Edit
Package, excluding testing.
Mainframe Installation Checklist
Step Description
1 Identify the Edit Package Coordinator
2 Review operational requirements
l Confirm hardware availability

l Confirm memory availability
l Consider disk space
l Run-time library levels
l Security access required
l File transfer
3 Review the installation package
l Request access to Visa Online, if necessary

l Download files from Visa Online (VOL) or request the installation CD
l Review the installation cover letter
l Confirm installation media and contents
4 Transfer installation files
l Create backup of installation files

l Print and review ReadMe file
l Determine Edit Package (Release 4) dataset name qualifiers
l Pre-allocate mainframe installation files
l Transfer installation files to mainframe
5 Install Software
l Modify sample JCL to allocate and build files and libraries

l Link the object modules to create load modules
l Customize the install job control statements
l Set install utility options
l Run the install job

Mainframe Installation Checklist
Step Description
6 Initialize system
l Run the epsetup job to initialize files

l Establish backup and restore procedures for system files
7 Verify installation
l Review initial testing plan

l Execute outgoing test run
l Execute incoming test run
l Review output files and reports
Mainframe Edit Package Operational

Requirements
Mainframe operational requirements include hardware requirements, memory estimates, disk space
considerations, run-time library standards and recommendation, and sort requirements.
Hardware Requirements:
Mainframe Edit Package Hardware Requirements
Device Function
System console Operator communications
Disk storage Direct access storage for system files
Printer: 132 print-position line; 60 lines or more per page Report printing
Run-time library IBM Language Environment libraries
Memory Estimates:
The sample generated by the mainframe install utility uses REGION=0M. If there are any installation
restrictions about using REGION=0M, the user can set the REGION parameter to a number that will
work for their Edit Package processing. Edit Package requires a minimum of REGION=512M and it
may work for most users depending on the volume of files processed and run control option used.

Disk Space Considerations:

The mainframe Edit Package requires:
l An estimated 40 megabytes for transferring all installation files to processing center storage.
l An additional estimated 120 megabytes for complete software installation and system files.
Operating System Requirements:

The mainframe installation package includes object modules that must be linked into executable
programs, repository tables file, and JCL procedures and parameters.
Edit Package (Release 4) for mainframe was developed so that users will not need their own
compilers for installation and maintenance of the software.
Support for Visa's Edit Package only extends to versions of z/OS that are currently supported by IBM;
this generally covers the most recent three (3) versions of their z/OS. While EP software may have
previously been supported on earlier versions, updates and new releases to EP will not be tested on
these older operating systems and functionality cannot be guaranteed. Installation of Edit Package
and resolution/troubleshooting of reported issues on operating systems at an earlier level cannot be
supported because among other reasons, Visa no longer uses these versions of z/OS and therefore
cannot replicate client issues or provide technical support.
Run-Time Library:
The Edit Package is built using IBM’s Language Environment and Class libraries. These IBM libraries
must be defined either in the system Link-List or in the JCL JOBLIB/STEPLIB.
Run-Time Functions
Run-time Function
CEE.SCEERUN Language Environment run-time library (see system programmer for exact
name)
CBC.SCLBDLL DLL Class Library running under z/OS
Sort Requirements:
The Edit Package mainframe program EPSORTA invokes ICETOOL (DFSORT) to do sorting of the
report work files in ACQ/ISS ID sequence and input files to EP-745 report. In the sort routine, two
datasets are created. The MVSSORT_MF_SORT_CNTL ("CTL1CNTL") and MVSSORT_MF_SORT_TOOL
("TOOLIN") that are required input to the EPSORTA routine. The TOOL dataset points to the Ddnames
to be sorted. And the CNTL contains the sort card to be used.

Edit Package Mainframe Installation Package

Overview
The mainframe installation package comprises the installation ReadMe and files.
The mainframe Edit Package (Release 4) installation package can be downloaded from Visa Online
(VOL). For Visa regions where software downloads from VOL are not supported, CD-ROMs will be
distributed only on an ad-hoc basis by submitting a request through a Visa regional client support
representative.
Endpoints must have access to VOL to obtain Edit Package (Release 4) software and updates. New
VOL subscribers can enroll by completing and submitting the online form at www.volenroll.com.
Within two business days, a unique user name and password will be received by email for access to
VOL.
Endpoints that do not have access to Edit Package will request access either on VOL or through their
Visa regional client support representative.
Access requests will be reviewed by Visa staff and upon approval, endpoints will be able to access
and download Edit Package (Release 4) software and updates. Notification by email will be received
when the VOL subscription has been registered and access to the site has been granted.
Installation ReadMe
The Edit Package installation package ReadMe file confirms the procedures described in this chapter
and includes any special instructions for the processing center. The ReadMe file is included in the Edit
Package software installation package.
Installation Files and Contents
Mainframe Installation Package
File Name Type Record Size (Bytes) Block Size Type
ReadMe.rtf Text file 132-byte fixed block ASCII
File2.object.binary File containing object 80-byte fixed block 27920 Binary

modules and control cards for
input to IEBUPDTE
File3.hashfl.binary File containing test files for 170-byte fixed block 27880 Binary
incoming ITF and outgoing
ITF files
File4.lctl.binary File containing link control for 80-byte fixed block 27920 Binary
input to IEBUPDTE
File5.jclproc.binary File containing jcl for input to 80-byte fixed block 27920 Binary
IEBUPDTE

Mainframe Installation Package
File Name Type Record Size (Bytes) Block Size Type
File6.jcl.binary JCL to build libraries for 80-byte fixed block 27920 Binary
linking object modules and
install utility
File7.media.ascii EP40 File install components 18000 byte, variable 27998 ASCII
length
Subscribe to Edit Package Release 4

Follow these steps to subscribe to Edit Package Release 4.
1. Obtain access to VOL.

2. Request access to Edit Package (Release 4).
3. Receive confirmation.
Change Management (CM) Option

Starting with the 08 July 2011 installation package, the Change Management Option is available. See
Edit Package Software Distribution and Updates (DUF) User Guide for more information.
With the CM option, the following jobs in &APPL.&BUILD.JCL and procedures in
&APPL.&BUILD.PROC are created during the install:
Job Procedure Option Purpose
EP4LODCM EPCHML01 CM Job to populate the CM Load library

(defined as $$USERLOAD1 in install
options file) with the updated load
modules; Note that initially the CM
load library does not contain any EP4
load modules; This job can be used for
testing CM install; The procedure used
can also be used for linking the object
modules after the OBJ and LCTL
modules are staged into the Endevor
or CMAN library. This job must be
executed prior to executing any CM
job.
EP4IN EP4IN DUF Incoming Job for TC formats
EP4INCM EP4INCM CM Incoming Job for TC formats
EP4INVM EP4IN DUF Incoming Job for VML formats
EP4OUT EP4OUT DUF Outgoing Job for TC formats
EP4OUTCM EP4OUT CM Outgoing Job for TC formats

Job Procedure Option Purpose
EP4OUTVM EP4OUT DUF Outgoing Job for VML formats
EP4U100 EP4U100 DUF and CM Job to initialize History files
EP4U130 EP4U130 DUF Job to process the software updates

and repository tables in TC54 format
EP4U130C EP4U130C CM Job to process the software updates

and repository tables in TC54 format
EP4U132 EP4U132 DUF Job to split the master repository into

individual repository tables
EP4U132C EP4U132C CM Job to split the master repository into

individual repository tables
EP4U140 EP4U140 DUF Job to process the TC54EXT files from

VOL
EP4U140C EP4U140C CM Job to process the TC54EXT files from

VOL
EP4U150 EP4U150 CM Job to build object and LCTL modules

from the master repository
EP4U160 EP4U160 DUF Job to execute the change

management utility (EPCHGMGT)
EP4U160C EP4U160 CM Job to execute the change

management utility (EPCHGMGT)
EP40EXT EP40EXT DUF Job to extract EP table files (VID,

ARDEF) and other on-request reports
EP40EXTC EP40EXT CM Job to extract EP table files (VID,

ARDEF) and other on-request reports
E4DUFJCD E4DUFJCD DUF Job card used for DUF Link processing
Important:
The CM Load library (defined $$USERLOAD1 in install options file) must exist. If the CM load
library does not exist, the following is an example of a JCL procedure to allocate the user
library prior to executing EP4LODCM. &APPL.&BUILD.CM.LOAD must be changed to your CM
user library name.
//STEP01 EXEC PGM=IEFBR14

//*
//LOAD DD DSN=&APPL.&BUILD.CM.LOAD,
// UNIT=RESDA,
// DISP=(MOD,DELETE,DELETE),
// SPACE=(TRK,0),
// DCB=DSORG=PS
//*

//*
//LOAD DD DSN=&APPL.&BUILD.CM.LOAD,
// UNIT=RESDA,
// DISP=(NEW,CATLG,CATLG),
// DSNTYPE=PDS,
// SPACE=(CYL,(210,15,35)),
// DCB=(RECFM=U,BLKSIZE=19069,DSORG=PO)
//*
Prepare for Edit Package Mainframe Installation

1. Create an installation package backup and store in a secure location.
2. Print and review the ReadMe file.
3. Determine Edit Package high-level node name and sub-node name to use for the installation.
Installation Job Names
Step Variable Name Example
1 &APPL Target application data set high-level node TEN

name.
2 &BUILD Target application sub-node name. BUILD001
4. Pre-allocate mainframe installation files.

The installation package consists of 6 files required to create JCL for staging the components
required to install Edit Package, Release 4. They must be sent to the mainframe and reviewed
for naming conventions and updating of local options.
The mainframe installation files are uploaded into the corresponding pre-allocated files on
your z/OS system. A sample pre-allocation JCL follows.
Note:
The &APPL variable should be changed to your application's high-level qualifier (for
example, TEN) and the &BUILD variable to your sub-node qualifier (for example,
BUILD001).
//*
//*
//OBJ DD DSN=&APPL.&BUILD.FILE2.OBJECT,
// UNIT=RESDA,
// SPACE=(TRK,0),
// DCB=DSORG=PS
//*
//HASHFL DD DSN=&APPL.&BUILD.FILE3.HASHFL,
// UNIT=RESDA,
// SPACE=(TRK,0),

// DCB=DSORG=PS
//*
//LCTL DD DSN=&APPL.&BUILD.FILE4.LCTL,
// UNIT=RESDA,
// SPACE=(TRK,0),
// DCB=DSORG=PS
//*
//JCLPROC DD DSN=&APPL.&BUILD.FILE5.JCLPROC,
// UNIT=RESDA,
// SPACE=(TRK,0),
// DCB=DSORG=PS
//*
//JCL DD DSN=&APPL.&BUILD.FILE6.JCL,
// UNIT=RESDA,
// SPACE=(TRK,0),
// DCB=DSORG=PS
//*
//MEDIA DD DSN=&APPL.&BUILD.FILE7.MEDIA,
// UNIT=RESDA,
// SPACE=(TRK,0),
// DCB=DSORG=PS
//*
//*
//OBJ DD DSN=&APPL.&BUILD.FILE2.OBJECT,
// UNIT=RESDA,
// DISP=(,CATLG,DELETE),
// SPACE=(CYL,(75,50)),
// DCB=(DSORG=PS,LRECL=80,RECFM=FB,BLKSIZE=27920)
//*
//HASHFL DD
DSN=&APPL.&BUILD.FILE3.HASHFL,
//
UNIT=RESDA,
//
DISP=(,CATLG,DELETE),
// SPACE=(CYL,
(5,5)),
//
DCB=(DSORG=PS,LRECL=170,RECFM=FB,BLKSIZE=27880)
//*
//LCTL DD
DSN=&APPL.&BUILD.FILE4.LCTL,
//
UNIT=RESDA,
//
// SPACE=(CYL,
(5,5)),
//
//*

//JCLPROC DD DSN=&APPL.&BUILD.FILE5.JCLPROC,
//
UNIT=RESDA,
//
// SPACE=(CYL,
(5,5)),
//
//*
//JCL DD
DSN=&APPL.&BUILD.FILE6.JCL,
//
UNIT=RESDA,
//
// SPACE=(CYL,
(5,1)),
//
//*
//MEDIA DD
DSN=&APPL.&BUILD.FILE7.MEDIA,
//
UNIT=RESDA,
//
// SPACE=(CYL,
(100,50)),
//
DCB=(DSORG=PS,LRECL=18000,RECFM=VB,BLKSIZE=27998)
//*

5. Transfer files from PC to mainframe.

Any standard file transfer can be used such as TCP/IP. Mainframe installation files 2 through 6
must be transferred in Binary mode and file 7 in ASCII mode.
Important:
The number of bytes shown in the example may differ from the actual size of files
transferred.
An example of an FTP session follows. Note that in this example, the application high-level
qualifier for mainframe files is TEN.
:\Documents and Settings\vluna>FTP MVS1

Connected to MVS1.Visa.com.
220-TCPFTP1 IBM FTP CS V1R9 at MVS1, 21:05:39 on 2009-09-24.
220 Connection will close if idle for more than 5 minutes.
User (MVS1.Visa.com:(none)): @VLUN
331 Send password please.
Password:
230 @VLUN is logged on. Working directory is "@VLUN.".
ftp> binary
200 Representation type is Image
ftp> put c:\ep40cd\file2.object.binary 'ten.build001.file2.object'
200 Port request OK.
125 Storing data set TEN.BUILD001.FILE2.OBJECT
250 Transfer completed successfully.
ftp: 38623360 bytes sent in 15.76Seconds 2450.10Kbytes/sec.
ftp> put c:\ep40cd\file3.hashfl.binary 'ten.build001.file3.hashfl
125 Storing data set TEN.BUILD001.FILE3.HASHFL
ftp: 508080 bytes sent in 0.48Seconds 1047.59Kbytes/sec.ftp> put c:\ep40cd\file4.lctl.binary
'ten.build001.file4.lctl'
125 Storing data set TEN.BUILD001.FILE4.LCTL
ftp: 105120 bytes sent in 0.28Seconds 374.09Kbytes/sec.ftp> put c:\ep40cd\file5.jclproc.binary
'ten.build001.file5.jclproc'
125 Storing data set TEN.BUILD001.FILE5.JCLPROC
ftp: 38000 bytes sent in 0.00Seconds 38000000.00Kbytes/sec.ftp> put c:\ep40cd\file6.jcl.binary
'ten.build001.file6.jcl'
125 Storing data set TEN.BUILD001.FILE6.JCL
ftp: 10640 bytes sent in 0.00Seconds 10640000.00Kbytes/sec.ftp> ascii
200 Representation type is Ascii NonPrint
ftp> put c:\ep40cd\file7.media.ascii 'ten.build001.file7.media'
125 Storing data set TEN.BUILD001.FILE7.MEDIA
ftp: 9961918 bytes sent in 3.52Seconds 2833.31Kbytes/sec.
ftp>
Note:
In some installations where the default is not using the standard ASCII to EBCDIC
translation table, it may be necessary to specify:
(ftp> LITERAL SITE XLATE=STANDARD)
With this specific FTP command, the MVS standard translation table for EBCDIC -
ASCII will be used. MVS data is in EBCDIC. When you choose ASCII for the FTP, it will
use the standard translation table to translate from EBCDIC to ASCII or if sending
data into MVS it will translate from ASCII to EBCDIC

Install Edit Package Software

The Edit Package (Release 4) install tasks must be performed in order and each task must end
successfully before proceeding to the next step.
The tasks must be performed in this order:
1. Modify and execute the setup job to allocate and populate libraries
2. Modify and run job to link object modules
3. Modify the Install Utility job
4. Modify the Options file
5. Execute the INSTALL job and verify output
6. Modify and run DLLBUILD job to link object modules and execute EPTBLSPT
7. Execute final setup job
Important:
A JCL syntax check must be performed prior to the submission of each job.
Modify and Execute the Edit Package Setup Job to Allocate and
Populate Libraries
This is the first task in the process for installing Edit Pakcage software. File6.jcl.binary in the
installation package contains a setup job to allocate and populate the libraries for the object
modules and install utilities.
Before executing this job, the symbolic parameters in job control statements of the sample JCL must
be changed to conform to the standard naming conventions for your target OBJECT, LOADLIB, and
PDS libraries.
Modify Install Setup shows examples for the job control statements that must be changed, when
using IBM’s ISPF editor under TSO.
Important:
Security access authorization to create files must be available.
Modify Install Setup
Step Variable Name Action
1 Update the Job card–based.
2 &APPL Target application data set high- Using IBM’s ISPF editor under TSO example:
level node name. C “&%APPL” “TEN”.
3 &BUILD Target application sub-node name. Using IBM’s ISPF editor under TSO example:
C “&BUILD” “BUILD001”.

Modify Install Setup
Step Variable Name Action
4 &UNIT Disk generic type name. (This is a RESDA Using IBM’s ISPF editor under TSO
name defined by the system example: C “&UNIT” “RESDA” (note that this
programmers of your system.) generates JCL with UNIT=RESDA).
5 &LIBTYP PDS or LIBRARY depending on what Change all references in the JCL file from
type of load libraries are used. &LIBTYP to either PDS or LIBRARY
depending on the type of load libraries used
by your system. LIBRARY indicates PDSE
type files. Using IBM’s ISPF editor under TSO
example: C “&LIBTYP” “PDS”
After the symbolic parameters have been changed to your system standards, execute the setup job in
File6.jcl.binary of the installation package.
The job in File6.jcl.binary will allocate and populate the libraries that will contain the clients used to
install mainframe Edit Package (Release 4).
Sample Install Setup Job Libraries shows an example of the libraries and their contents that will be
created from this job. The libraries shown use the examples for the symbolic parameters from
Mainframe Installation Package.
Sample Install Setup Job Libraries
Step Name Purpose
1 TEN.BUILD001.INSTALL.JCL JCL library that contains linkjob and install job
2 TEN.BUILD001.LCTL Link LCTL control cards
3 TEN.BUILD001.LOAD Load library that contains executable modules
4 TEN.BUILD001.OBJ Object library that contains object modules
Sample and Install JCL Members shows the contents of TEN.BUILD001.INSTALL.JCL.
Sample and Install JCL Members
Name Purpose
DLLBUILD Job execute EPZPLINK procedure to update the load library and
EPTBLSPT.
EBTBLSPT JCL procedure executed by INSTALL to load individual Repository tables

from the combined Repository table.
EPZPLINK JCL procedure executed by LINKJOB to allocate and create load modules
for the installation process.
INSTALL Install utility job and Execution JCL for the INSTPRC procedure and
EP4U150.

Sample and Install JCL Members
Name Purpose
EP4U150 JCL procedure to Install utility job and Execution JCL for the INSTPRC
procedure.
INSTPRC JCL procedure executed by INSTALL to install Edit Package, (Release 4).
LINKJOB Execution JCL for the EPZPLINK procedure.
OPTIONS Utility options file used by INSTALL during the installation process.
Modify and Run Job to Link Object Modules in Edit Package

This is the second task in the process of installing Edit Package software.
The LINKJOB in the &INSTALL.JCL library creates and links the load modules that will be used by the
INSTALL job.
Before executing LINKJOB, the symbolic parameters for &APPL and &BUILD in it must be changed to
the same location as the target OBJECT, LOADLIB, and PDS libraries in the previous step.
For the example above, again using IBM’s ISPD editor under TSO, these symbolic parameters would
be changed as follows:
C &APPL TEN
C &BUILD BUILD001
Processors may also consider changing following symbolic overrides in the JCL procedure EPZPLINK
that allocates the LE libraries to their shop standards:
CPREFIX='SYS1.CBC'
LEPREFIX='SYS1.CEE'
After the symbolic parameters above have been changed, LINKJOB can be submitted to execute the
JCL procedure EPZPLINK.
Important:
To be successful, all of the job steps in the JCL procedure EPZPLINK must end with a return
code value of either 0 or 4.
Modify the Install Utility Job in Edit Package

This is the third task in the process to install Edit Package software.
The install setup job creates a file (name is based on &APPL and &BUILD) ending with INSTALL.JCL.
Inside this PDS is a member-named INSTALL. The JCL must be revised so that the staging and Edit
Package files are named as required.

Modify Install Utility Job
Step Action
1 Update the JOB card based on your naming standards or conventions
2 Change all references in the JCL file for the dataset name variables. (See Section 2.4.4.1.)
Modify the Options File in Edit Package

This is the fourth task in the process for installing Edit Package software.
The install setup job creates a file (name is based on &APPL and &BUILD) ending with INSTALL.JCL.
Inside this PDS is a member-named OPTIONS.
Important:
The INSTALL options included must be reviewed and updated so that Edit Package files and
jobs are named as required.
Modify the OPTIONS file so that values for $$APPL, $$BUILD, and $$UNIT are consistent with
the high-level, sub-node qualifiers and disk names used in Section 2.4.4.1
An example of the installation options using the Example &APPL and &BUILD follows.
BROWSE TEN.BUILD001.INSTALL.JCL(OPTIONS) Line

*
* Edit Package 4 z/OS Installation
Script
*
* $$APPL defines the application dataset name identifier (max len=24
ch
* $$BUILD is an optional sub-qualificaiton to $
$APPL
$
$APPL=TEN
$
$BUILD=.BUILD001
*
* $$UNIT defines a generic DASD device used to allocate application
file
$
$UNIT=BASE2
*
* $$USERLOADn defines a fully-qualified optional set of JOBLIB lib's
(n=1-4)
$
$USERLOAD1=TEN.BUILD001.LOAD
$
$USERLOAD2=VLM.C1B2.STGLOAD
$
$USERLOAD3=VLM.C1B2.PRODLOAD
*
* $$USERPROC defines a fully-qualified JCL procedure
library
$

$USERPROC=VLM.C1B2.VQ07PROC
*
* Number of Generations maintained for Edit Package
log
$
$LOGGEN=20
*
*
* Number of Generations maintained for Edit Package
log
$
$LOGGEN=20
*
* Run Control
Options
$
$RCO_CENTRBIN=400552
$
$RCO_CENTRCODE=SECURITY
$$RCO_CENTRNAME=FIRST ANYWHERE
BANK
$
$RCO_RUNMODE=TEST
$
$RCO_COUNTRY=us
$$RCO_FILELOC=zos(dd:EPIN) win(\
\ep40)
$$RCO_ITFHASH=zos(Y)
win(N)
$
$RCO_LANGUAGE=english
$
$RCO_PORT=
$
$RCO_PROFILE=outgoingtc
*
* $$JOBCARD provides a JOBCARD image. Multiple lines
allowed
$$JOBCARD=//TENEP40 JOB (R811392,85075,VISA),'EDIT PACKAGE
4',
$$JOBCARD=//
CLASS=J,
$$JOBCARD=//
MSGCLASS=X,
$$JOBCARD=// REGION=0M
Keyword Arguments Changes for the Options File shows the keywords in the OPTIONS file for which
arguments can be updated. The keywords are presented in the order in which they appear in the
OPTIONS file.

Keyword Arguments Changes for the Options File
Step Action
1 You will find three lines that start with $$USERLOADn (n is a number) around line 19 of the install
job options. These lines define addition JOBLIB libraries. Refer to IMPORTANT note below.
2 Below the $$USERLOAD lines is a $$USERPROC line. This defines the location of an installation
procedure library. Note that the install job will also create a procedure library (based on
&APPL&BUILD.PROC). Refer to IMPORTANT note below.
3 Below $$USERPROC is the $$LOGGEN keyword. The argument defines the number of generations
established for the log Generation Data Group catalog entry. The default value of 20 can be
changed.
4 After $$LOGGEN you will find a series of lines that start with $$RCO_. These define the values that
will be associated with Run Control Options Value table. Note that lines that start with an asterisk
are comment lines. Any commented option can be made active by moving the line such that it
starts with $$RCO_.
5 Below $$RCO_ is a generic JOB card used by the install process when generating the EP4 JCL
library (based on &APPL&BUILD.JCL). Modify this based on your needs.
The job card included in the options file will be used by system to generate sample JCL for all jobs
created during the install process. The job card will be the same for all the sample jobs generated.
The job name and other information can be customized after the install is completed, if required.
Important:
User job library and user procedure library specified must exist; otherwise, JCL errors will be
encountered. If no additional procedures are required, delete them from the install options.
For the change management (CM) option, $$USERLOADn is the name of the production or
test load library that will be used to execute the Edit Package. For example, Endevor or CMAN
production load library.
For example: $$USERLOAD1=YOUR.EP4.LOAD
‘YOUR.EP4.LOAD’ must be replaced by your user load library for EP4.
For DUF automatically maintained load library, $$USERLOAD1 is the same as the install
default loadlib (&appl.&build.load).
Verify that the input file corresponds to the file7 of the installation package. Using the example
dataset qualifiers in Section 2.4.3.4 for &APPL and &BUILD, this will be TEN.BUILD001.FILE7.MEDIA
Execute the INSTALL Job and Verify Output in Edit Package

This is the fifth task in the process for installing Edit Package software. The job modified in the
previous task is run and validated for return codes in each step.
The expected return codes are shown.
-------- JOB SUMMARY STATISTICS

-PROCNAME STEPNAME PROGRAM RC
- DEFGDG IDCAMS 00

- HASHFL IDCAMS 00
-STEP01 INSTALL IEFBR14 00
-STEP02 INSTALL EP4U010 00
-STEP04 INSTALL IEBUPDTE 00
-STEP01 EP4U150 IEFBR14 00
-STEP02 EP4U150 EPTBLUPD 03
-STEP03 EP4U150 IEBUPDTE 00
-STEP04 EP4U150 IEBUPDTE 00
If any step fails (condition code greater than 4), correct the error and re-run. When re-running, it is
important that the original &APPL.&BUILD.FILE7.MEDIA from the installation package is used as
input because the INSTALL job updates this file.
The Installation Job created the following files (names assume &APPL=TEN and &BUILD=.BUILD001).

Files Created by the Installation Job
Name Type Purpose
TEN.BUILD001.JCL PDS JCL library
EPSETUP Final job used during EP4 install
EP4IN Incoming Edit Package 4 example

JCL using TC formats
EP4OUT Outgoing Edit Package 4 example

JCL using TC formats
EP4INVM Incoming Edit Package 4 example

JCL using VML format
EP4OUTVM Outgoing Edit Package 4 example

JCL using VML format
EP4U100 Edit Package 4 job initialize History

file
EP4U130 Edit Package 4 job to process table

updates (TC 54)
EP4U132 Edit Package 4 job to create

individual repository from master
repository
EP4U140 Edit Package 4 job to process

updates from VOL
EP40EXT Edit Package 4 job to generate on-

request reports and Table extracts
E4DUFJCD Edit Package job used for DUF Link

processing
TEN.BUILD001.LCTL PDS Link control library
TEN.BUILD001.PARM PDS Parameter control library

Name Type Purpose
TEN.BUILD001.PROC PDS
EPALLOC Allocate empty EP4 files
EP4IN Edit Package 4 Incoming

procedure used by EP4IN job
above
EP4OUT Edit Package 4 Outgoing

procedure used by EP4OUT job
above
EP4U100 Edit Package 4 procedure to

initialize History file

process table updates (TC 54)
EP4U132 Edit Package 4 procedure to create

individual repository from master
repository

process updates from VOL
EP40EXT Edit Package 4 procedure to

generate on-request reports and
Table extracts
EPLINK00 Is a dummy procedure in the

dynamic JCL submitted by the
internal reader
TEN.BUILD001.PROC (continued) PDS

EPLINK01 Is a procedure use to create LOAD
modules in the dynamic JCL
submitted by the internal reader if
any load modules will be built
EPLINK99 Is a procedure used to run Table

Split program and take a backup of
a newly created Master Repository
EPTBLSPT Is a procedure used to run Table

Split program which loads
individual repository files from
Master Repository during the
installation
TEN.BUILD001.REPOSIT.ARDEF.TABLE Sequential EP4 data repository Account Range Table

Name Type Purpose
TEN.BUILD001.REPOSIT.BIN.TABLE Sequential EP4 data repository VID table
TEN.BUILD001.REPOSIT.DEF.TABLE Sequential EP4 data repository definition table
TEN.BUILD001.REPOSIT.PROFILE.TABLE Sequential EP4 data repository profile table
TEN.BUILD001.REPOSIT.VALUE.TABLE Sequential EP4 data repository value table file
TEN.BUILD001.REPOSIT.CODEBASE.TABLESequential EP4 repository codebase table file
TEN.BUILD001.RULES.LOAD PDS Rule DLL load library (not currently used)
TEN.BUILD001.STAGE.JCL Sequential Staging file used during install only
TEN.BUILD001.STAGE.LCTL Sequential Staging file used during install only
TEN.BUILD001.STAGE.PARM Sequential Staging file used during install only
TEN.BUILD001.STAGE.PROC Sequential Staging file used during install only
TEN.BUILD001.TEST.OCTF Sequential Example test Outgoing Center Transaction File (input

test file to TC Outgoing run–EP4OUT)
TEN.BUILD001.TEST.OITF Sequential Example test Outgoing Interchange Transaction File

(output files from TC Outgoing run – EP4OUT; two
output files are included in this file since
SPLITCONLY=Y; first file contains financial and non-
financial transactions and second file contains the
collection-only transactions)
TEN.BUILD001.TEST.IITF Sequential Example test Incoming Interchange Transaction File

(input to TC Incoming run - EP4IN)
TEN.BUILD001.TEST.ICTF Sequential Example test Incoming Center Transaction File (output

test from TC Incoming run –EP4IN)
TEN.BUILD001.TEST.OVML Sequential Example test Outgoing VML file (input file to Outgoing
run – EP4OUTVM)
TEN.BUILD001.TEST.OVTF Sequential Example test Outgoing Visa Transaction File (output

test file from VML Outgoing run – EP4OUTVM)
TEN.BUILD001.TEST.IVTF Sequential Example test Incoming Visa Transaction File (input test
file to VML Incoming run – EP4INVM)
TEN.BUILD001.TEST.IVML Sequential Example test Incoming VML File (output file from VML
Incoming run – EP4INVM)
TEN.BUILD001.TEST.RPTOUTTC Sequential Example test Outgoing Reports (summary output

reports from TC Outgoing run – EP4OUT)
TEN.BUILD001.TEST.RPTINTC Sequential Example test Incoming Reports (output reports from

TC Incoming run – EP4IN)

Name Type Purpose
TEN.BUILD001.TEST.RPTOUTVM Sequential Example test Outgoing Reports (output reports from

VML Outgoing run – EP4OUTVM)
TEN.BUILD001.TEST.RPTINVM Sequential Example test Incoming Reports (output reports from

VML Incoming run – EP4INVM)
TEN.BUILD001.REPOSIT.TABLE GDG Combined repository table file which includes the

ARDEF, VID, CODEBASE, DEFINITIONS, PROFILE, and
VALUE repository tables
TEN.BUILD001.REPOSIT.OVERRIDE Sequential Customized run control options file – contains the

options selected during install
TEN.BUILD001.DUFLOG GDG Log created by EPTBLSPT that shows the record counts
of each of the repository tables generated from the
combined repository tables
Modify and Run DLLBUILD Job to Link Object Modules and Execute
EPTBLSPT
This is the sixth task in the process for installing Edit Package software.
The DLLBUILD in the &INSTALL.JCL library creates and links the object modules to create the rest of
the load modules.
Before executing DLLBUILD, the symbolic parameters for &APPL and &BUILD in it must be changed
to the same location as the target OBJECT, LOADLIB, and PDS libraries in the previous step.
For the example above, again using IBM’s ISPD editor under TSO, these symbolic parameters would
be changed as follows:
C &APPL TEN C &BUILD BUILD001
Processors may also consider changing following symbolic overrides in the JCL procedure EPZPLINK
that allocates the LE libraries to their shop standards:
CPREFIX='SYS1.CBC' LEPREFIX='SYS1.CEE'
After the symbolic parameters above have been changed, DLLBUILD job can be submitted to execute
the JCL procedure EPZPLINK.
The last step of the DLLBUILD runs the EPTBLSPT program which will split the master repository file
(&APPL.&BUILD.REPOSIT.TABLE) into the individual repository files.
Files Created by the DLLBUILD Job
Name Type Purpose
TEN.BUILD001.REPOSIT.ARDEF.TABLE Sequential EP4 data repository Account Range Table
TEN.BUILD001.REPOSIT.BIN.TABLE Sequential EP4 data repository VID table

Files Created by the DLLBUILD Job
Name Type Purpose
TEN.BUILD001.REPOSIT.DEF.TABLE Sequential EP4 data repository definition table
TEN.BUILD001.REPOSIT.PROFILE.TABLE Sequential EP4 data repository profile table
TEN.BUILD001.REPOSIT.VALUE.TABLE Sequential EP4 data repository value table file
TEN.BUILD001. REPOSIT.CODEBASE.TABLE Sequential EP4 repository codebase table file
Important:
To be successful, all of the job steps in the JCL procedure EPZPLINK must end with a return
code value of either 0 or 4 and EPTBLSPT must end with a RC=0.
The SYSPRINT from EPTBLSPT should show the release table. For example:
2011-11-07 22:04:38 EPTBLSPT-0135I The following release records will

be processed:
2011-11-07 22:04:38
EPTBLSPT-0135I
2011-11-07 22:04:38 EPTBLSPT-0135I 25release R20100101 20100101 M
Base Release
Nov 2010 Maintenance Release
Feb 2011 Maintenance Release
Apr 2011 Business Release
Apr 2011 Maintenance Release
Jun 2011 Maintenance Release
Jul 2011 Maintenance Release
Jul 2011 History Fix Release
Jul 2011 Batch Number Fix
2011-11-07 22:04:38 EPTBLSPT-0135I 25release R20110729 20110729 E
Jul 2011 Off Release RTN 815836
2011-11-07 22:04:38 EPTBLSPT-0135I 25release R20110901 20110901 E
Sep 2011 Maintenance Release
Oct 2011 RTN 815914 Durbin
Oct 2011 Business Release
Nov 2011 Maintenance Release

In addition, a list of all the modules for a given effective date and their status will be shown. For
example:
2011-11-07 22:04:38 EPTBLSPT-0135I

Effective
2011-11-07 22:04:38 EPTBLSPT-0135I Module Date
Status
2011-11-07 22:04:38 EPTBLSPT-0135I -------- -------- -------
--------
2011-11-07 22:04:38 EPTBLSPT-0135I EPCTFB01 20100101 FOUND
REQUIRED
EVALUATE
EVALUATE
--
All of the modules must have a status of Found.
Execute Final Setup Job in Edit Package

This is the seventh and final task in the process for installing Edit Package software.
The install job creates a file (name is based on &APPL and &BUILD) ending with .JCL. Inside this PDS
is a member-named EPSETUP. This job allocates additional files. Optionally modify the JOB card then
run this job. Validate that the three steps end with a condition code of zero. If any step fails
(condition code greater than 4), correct the error and re-run.
The final setup job will define catalog entries for the LOG file and create the following files (names
assume &APPL=TEN and &BUILD=.BUILD001).
Files Created by EPSETUP Job
Name Type Purpose
TEN.BUILD001.HISTORY Sequential EP4 run history.
TEN.BUILD001.HISTORY.BKUPA Sequential EP4 run history backup 1.
TEN.BUILD001.HISTORY.BKUPB Sequential EP4 run history backup 2.
TEN.BUILD001.RULES.IMPORT PDS Link control cards for DLLs (not

currently used).
TEN.BUILD001.RULES.LOAD PDS Load library for rules (not currently

used).
TEN.BUILD001.RULES.OBJ PDS Rules Object library (not currently

used).
TEN.BUILD001.RUN.LOG GDG Log files GDG
TEN.BUILD001.ENVINF Sequential Incoming Environmental Hold File.

Files Created by EPSETUP Job
Name Type Purpose
TEN.BUILD001.EP.CURCNV Sequential Edit Package Currency Rates File
TEN.BUILD001.LISTPCTL PDS Pre-linker Cross-Reference Output.
Verify Edit Package Installation

The installation package includes an outgoing test CTF or VML files and an incoming test ITF or VTF.
Additionally, a set of sample reports and output test files for each job are included for verifying the
expected outgoing and incoming run test results. Installation verification includes understanding the
initial test plan, executing an outgoing test run, and executing an incoming test run.
Understanding the Initial Test Plan for Edit Package

To verify that all programs, job control statements, and system files were installed correctly, the
processing center must execute an outgoing run and an incoming run using the supplied test files.
It is recommended that an outgoing run must be executed before an incoming run since this is how
the provided output sample reports and files were generated.
Note:
Visa strongly recommends that testing occurs before attempting certification.
Execute an Outgoing Run Using TC Format in Edit Package

The installation job created a sample outgoing TC job &APPL.&BUILD.JCL(EP4OUT).
Important:
The EP4OUT procedure generated from the install has allocation for the EPOUT2. When
collection-only transactions are present in the input file, EP4 will write the collection-only
transactions to EPOUT2 when the default setting for SPLITCONLY is used. If there are no
collection-only transactions in the input file, EPOUT2 will be deleted at the end of the job.
Overriding the EP4OUT procedure to set EPOUT2 to DUMMY, when there are collection-only
transactions in the input file, will generate a fatal error with a return code of 16 and with an
error message displayed on the log: For example: 2010-11-02 00:56:09 000232-E EPOUT2 DD
cannot be NULLFILE. Therefore, EPOUT2 should always be allocated and must not be set to
dummy or null file.
For more information about EP 4 Support for Collection-Only Transactions, see Edit Package
(Release 4) Member Implementation Guide.
EDIT TEN.BUILD001.JCL(EP4OUT)
//EP4OUT EXEC PROC=EP4OUT,
// APPL=TEN, * APPLICATION FILES
// PROFILE=OUTGOINGTC * PROFILE

//*
//STEP04.REPORTS DD SYSOUT=*
//STEP02.EPIN DD DSN=TEN.BUILD001.TEST.OCTF,DISP=SHR
//STEP02.TMPOPT DD *
*
* EDIT PACKAGE 4 TEMPORARY RUN OPTIONS
*
CENTRBIN=400552
CENTRCODE=SECURITY
CENTRNAME=FIRST ANYWHERE
BANK
RUNMODE=TEST

DLLPARM=RULE(TRACE=DUMP)
//*
To execute an outgoing test run for TC formats (PROFILE=OUTGOINGTC):

1. Ensure the run control options files are correct:
a. Set Job Profile to OUTGOINGTC. The default profile contains a set number of options for
processing an input CTF file and output ITF file.
b. Update the Temporary Run Control Options File to contain only the following records,
beginning in column 1:
CENTRBIN=400552 CENTRCODE=SECURITY CENTRNAME= FIRST ANYTOWN BANK
RUNMODE=TEST
Note:
Refer to Edit Package Report EP–199 for the exact Run Date and TABLEDATE in the
CCYYMMDD format for this outgoing test run. The outgoing reports are in: &APPL.
&BUILD.TEST.RPTOUTTC.
The sample EP-199 included in this package has the following information:
2011-08-31 21:30:31 000093-C Profile outgoingtc active using table date 2011-08-31
2011-08-31 21:30:31 000134-I Repository reload using run date 2011-08-31, table date
2011-08-31
2. Execute EP4OUT using the test Outgoing CTF generated by the installation job.
The job will have a return code=04.
3. Compare the test run reports to the sample outgoing reports provided in the installation
package.
There will be differences in the System Date in the header of the reports since reports always
reflect the computer System Date of the Edit Package run.
Other differences will be the time and date in the EP-199 reports and the count of non-
financial transactions. Note that the count of non-financial transactions includes the run
control options (TC 50s) used for the run. The output outgoing ITF file may be also be
different when TC 50s (EP environmental information) are compared. Also note that the
sample outgoing interchange file provided contains two sample output files (refer to 2.4.4.5)
Note:
The outgoing reports generated may differ from the sample outgoing reports
provided if rundate or tabledate was set to a value other than 31 August 2011.
Execute an Incoming Run Using TC Format in Edit Package

The installation job created a sample incoming TC job &APPL.&BUILD.JCL(EP4IN).
EDIT TEN.BUILD001.JCL(EP4IN) - 01.00

//EP4IN EXEC
PROC=EP4IN,
// APPL=TEN, * APPLICATION

FILES
// PROFILE=INCOMINGTC *
PROFILE
//*
//STEP04.REPORTS DD
SYSOUT=*
//STEP02.EPIN DD
DSN=TEN.BUILD001.TEST.IITF,DISP=SHR
//STEP02.TMPOPT DD
*
*
* EDIT PACKAGE 4 TEMPORARY RUN
OPTIONS
*
CENTRBIN=400552
CENTRCODE=SECURITY
CENTERNAME=FIRST ANYWHERE
BANK

RUNMODE=TEST
//*
To execute an incoming test run for TC formats (PROFILE=INCOMINGTC):

a. Set Job Profile to INCOMINGTC. The default profile contains a set number of options for
processing an input ITF file and output CTF file.
CENTRBIN=400552 CENTRCODE=SECURITY CENTRNAME= FIRST ANYWHERE BANK
RUNMODE=TEST
Important:
Please refer to Edit Package Report EP–299 in the Sample Reports file for the exact
TABLEDATE in the CCYYMMDD format for this incoming test run. The system derives the
system date and table effective date from the CPD file header date.
The test file provided has header of 30 August 2011. The sample EP-299 in
&APPL.&BUILD.TEST.RPTINTC has the following information:
2011-08-29
2. Execute EP4IN using incoming ITF generated by the installation job.
The job will end with a return code=05 which indicates that there are no TC 54s in the input
test file provided.
3. Compare the test run reports to the sample incoming reports provided in the installation
package.
reflect the computer system date of the Edit Package run. Other differences will be the time
and date in the EP-299 report.
Note:
The incoming reports generated may differ from the sample incoming reports
provided if tabledate was set to a value other than 29 August 2011.
Executing an Outgoing Run Using VML in Edit Package

The installation job created a sample outgoing VML job &APPL.&BUILD.JCL(EP4OUTVM).
EDIT TEN.BUILD001.JCL(EP4OUTVM)
// APPL=TEN, * APPLICATION FILES
// PROFILE=OUTGOINGVML * PROFILE
//*
//STEP04.REPORTS DD SYSOUT=*
//STEP02.EPIN DD DSN=TEN.BUILD001.TEST.OVML,DISP=SHR
//STEP02.TMPOPT DD *
*

* EDIT PACKAGE 4 TEMPORARY RUN OPTIONS

*
CENTRBIN=400552
CENTRCODE=SECURITY
CENTRNAME=FIRST ANYWHERE BANK
RUNMODE=TEST
//*
To execute an outgoing test run for VML formats (PROFILE=OUTGOINGVML):

a. Job Profile is set to OUTGOINGVML. The default profile contains a set number of options
for processing an input VML file and output VTF file.
b. Updating the Temporary Run Control Options File to contain only the following records,
RUNMODE=TEST
Note:
Refer to Edit Package Report EP–199 in the Sample Reports file for the exact Run Date
and TABLEDATE in the CCYYMMDD format for this outgoing test run. The outgoing
reports are in: &APPL.&BUILD.TEST.RPTOUTVM
The sample EP-199 included in this package has the following information:
2011-08-31 22:41:35 000093-C Profile outgoingvml active using table date 2011-08-31
2011-08-31
2. Execute EP4OUTVM using the test Outgoing VML generated by the installation job.
The job will have a return code 04.
3. Compare the test run reports to the sample outgoing reports provided in the installation
package.
reflect the computer system date of the Edit Package run.
Other differences will be the time and date in the EP-199 reports and the count of non-
financial transactions. Note that the count of non-financial transactions includes the run
control options (T162) used for the run. The output outgoing VTF file may be also be
different when T162s (EP environmental information) are compared.
Note:
The outgoing reports generated may differ from the sample outgoing reports
provided if rundate or tabledate was set to a value other than 31 August 2011.

Executing an Incoming Run Using VML in Edit Package

The installation job created a sample incoming VML job &APPL.&BUILD.JCL(EP4INVM).
EDIT TEN.BUILD001.JCL(EP4INVM) - 01.00

//EP4IN EXEC
PROC=EP4IN,
// APPL=TEN, * APPLICATION
FILES
// PROFILE=INCOMINGVML *
PROFILE
//*
//STEP04.REPORTS DD
SYSOUT=*
//STEP02.EPIN DD
DSN=TEN.BUILD001.TEST.IVTF,DISP=SHR
//STEP02.TMPOPT DD
*
*
* EDIT PACKAGE 4 TEMPORARY RUN
OPTIONS
*
CENTRBIN=400552
CENTRCODE=SECURITY
CENTERNAME=FIRST ANYWHERE
BANK

RUNMODE=TEST
//*
To execute an incoming test run for VML formats (PROFILE=INCOMINGVML):

a. Set Job Profile to INCOMINGVML. The default profile contains a set number of options
for processing an input IVTF file and output IVML file.
RUNMODE=TEST
Important:
Refer to Edit Package Report EP–299 in the Sample Reports file for the exact TABLEDATE
in the CCYYMMDD format for this incoming test run. The system derives the system date
and table effective date from the CPD file header date.
The test file provided has header of 30 August 2011. The sample EP-299 in
&APPL.&BUILD.TEST.RPTINVM has the following information:
2011-08-29
2. Execute EP4INVM using incoming VTF generated by the installation job.
The job will end with a return code=05 which indicates that there are no TC 54s in the input
test file provided.
3. Compare the test run reports to the sample incoming reports provided in the installation
package.
reflect the computer system date of the Edit Package run. Other differences will be the time
and date in the EP-299 report.
Note:
The incoming reports generated may differ from the sample incoming reports
provided if tabledate was set to a value other than 29 August 2011.

Edit Package Release 3 and Release 4

Differences
The Edit Package Release 4, Migration Implementation Guide includes sections 2 and 3 for primary
functional and system enhancements for Release 4.
Edit Package Release 3.0 and Edit Package 4 Differences
Platform Item Release 3.04 Release 4
PC and Mainframe Outgoing CTF Optional The field can be zeroes, The field can be spaces or
TC90 spaces, or the BASE II CIB the BASE II CIB for this
for this processing center. If processing center. If spaces,
zeroes or spaces, the Edit the Edit Package will insert
Package will insert the the value supplied on the
value supplied on the CENTRBIN run control
CENTRBIN run control option.
option.
PC and Mainframe Value Table Extract Record VID and ARDEF value table All value table extracts have
Length extract has a record length a record length of 140. The
of 80 bytes. Value Table length of reserved area has
extract has a record length been increased for future
of 88. use.
PC and Mainframe Table Override (TBLKEY and Refer to EP (Release 3.0) Refer to EP (Release 4)
TBLDATA) Operations Guide for Operations Guide for
Section 5.47.3, Table TBLKEY AND TBLDATA –
Overrides layout. TABLE OVERRIDE.

Edit Package Processing Related

Documentation
For implementation requirements, technical, and system processing information related to BASE II
and Edit Package (Release 4), refer to these Visa publications.
l Edit Package (Release 4) Migration Implementation Guide is intended to provide existing Edit
Package, Release 3.x acquirers, issuers, and processors with the following information
regarding Edit Package, (Release 4):
n An overview of the primary enhancements
n Implementation considerations
n Testing requirements
n Going live and Visa support information
l BASE II manuals for Edit Package (Release 4)
n BASE II Clearing PC Edit Package for Windows (Release 4) User’s Guide
n BASE II Clearing Edit Package (Release 4) Messages
n BASE II Clearing Edit Package (Release 4) Operations Guide
n BASE II Clearing Edit Package (Release 4) Reports
n BASE II Clearing Edit Package (Release 4) Run Control Options Quick Reference
l BASE II technical documentation
n BASE II Clearing: Data Codes
n BASE II Clearing: Interchange Formats, TC 01 to TC 49
n BASE II Clearing: Interchange Formats, TC 50 to TC 92
n BASE II Clearing: System Overview
n BASE II Clearing: Services
n BASE II Clearing: Transactions – Quick Reference Card
l The VCMS Testing Technical Publications
n VCMS Testing Guide—BASE II, Member Version

Edit Package Run Control Options

Customization
Your run control options should be defined under ddnname //TMPOPT.
For example, your outgoing JCL may point to the following datasets:
TEN.BUILD001.JCL(EP4OUT)
//STEP02.TMPOPT DD DSN=TEN.BUILD001.PERMOPTN,DISP=SHR // DD
DSN=TEN.BUILD001.TEMPOPTN,DISP=SHR
In this example, TEN.BUILD001.PERMOPTN dataset will contain run control option settings that don't
change on a day-to-day basis.
CENTRBIN=400552 CENTRCODE=SECURITY CENTRNAME=FIRST ANYWHERE BANK
TEN.BUILD001.TEMPOPTN dataset will contain run control option settings that may be used for
testing, re-runs etc.
RUNMODE=TEST TABLEDATE=20111014
Important:
Note that repository tables such as &APPL.&BUILD.REPOSIT.VALUE.TABLE and
&APPL.&BUILD.REPOSIT.PROFILE.TABLE contain default settings for some run control options.
Under no circumstances should these be changed because these tables can be updated
when TC54s are processed.
The run control options you specified under ddname //TMPOPT will supersede the settings
defined in the repository tables for a given run. The settings of run control options in effect
for the run are listed on the EP-199 Processing Log for Outgoing and EP-299 Processing for
Incoming.

Chapter 4
Cycle
The processes included in the outgoing BASE II Edit Package processing cycle are listed in the order
they occur.
Edit Package Outgoing Control

Program
The outgoing Edit Package is a program that calls many sub-modules. The outgoing control
program, EPZOS, calls initialization functions, as needed, at the beginning of each run then processes
each transaction found in the input files. At the end of processing, if there were no severe errors, the
control program produces the necessary reports and makes the output files (ITF or VTF) available for
staging on the Extended Access Server (EAS) or Direct Exchange (DEX).

Edit Package Outgoing Processing Cycle
EPOUT - Typical Process Flow for Outgoing Edit Package Run
The control program is started with a run-time parameter indicating the PROFILE desired. This is
defined when running under z/OS using the JCL procedures provided and the PROFILE= symbolic,
for example:


//APPL=TEN, * APPLICATION FILES HLQ
//PROFILE=OUTGOINGTC * PROFILE
Options and usage are:
OUTGOINGTC = CTF input file resulting in an ITF output file
OUTGOINGVML = VML input file resulting in a VTF output file
Edit Package Outgoing Input

Requirements
These items are required before an outgoing Edit Package run can be executed.
l An outgoing CTF or VML generated by the processing center’s pre-edit program.
l The following files, which must reside on a direct access storage device:
n Permanent and Temporary Run Control Options files
n Incoming Run Hold file
n Load library
n History file (original and backups)
n Log file
n Repository files:
- VID table
- ARDEF table
- Value table
- Definition table
- Profile
Note:
For processing centers that process multiple currencies and want to use the run tolerance
checking option, the Currency Rates File is also required.

Edit Package Outgoing System

Initialization
The following processes occur during system initialization.
1. EPZOS searches the Permanent and Temporary Run Control Options Files for the following
run control options.
BASE II CIB CENTRBIN
Center Code CENTRCODE
Center Name CENTRNAME
Table Date TABLEDATE
Run Date RUNDATE
Run Mode RUNMODE
Table Key TBLKEY
Table Data TBLDATA
Direction (incoming or outgoing) DIRECTION
Input location FILELOC
Input sequencing INPUTSEQ
Run option profile PROFILE
Note:
TABLEDATE, RUNDATE, RUNMODE, TBLKEY, TBLDATA, and INPUTSEQ run control options
are not required. If not present, default values are used.
2. EPZOS uses the information from the run control options to load the repository tables. The
TBLDATA and TBLKEY temp options are retrieved before loading the repository and are used
during the load process.

3. EPZOS validates all run control options and:

a. Sets default values for run control options, where necessary.
b. Performs a cross-validation of run control options to ensure that there are no conflicting
options in the run.
c. Lists run control options in effect for the run to the Log file.
4. EPZOS references the History File to assign run and starting batch numbers. Batch numbers
start at 1 for each processing day and are incremented by 1 for each batch processed.
Reruns—If the current outgoing Edit Package run is a rerun, EPZOS verifies that it has already
performed the run for the run date in effect and reuses the starting batch number from the
original run.
Edit Package Outgoing Files Creation

The creation of the outgoing ITF/VTF includes these processes.
1. Process Input
a. Check File Header—If there is a file header, this process verifies that it is correct. If the
file header contains a nonzero Unique File ID, EPZOS checks the History File to verify that
it is not a duplicate file.
b. Build Logical Transactions—This process reads one transaction at a time from the input
CTF and VML validates the transaction format. EPZOS verifies that all batch and file
trailers balance, that is, totals read from the records in the CTF/VML equal the sums of
accepted and rejected totals accumulated by EPZOS during processing. If duplicate batch
detection has been selected using the DUPBATCH option, EPZOS will also compare the
batch hash value or Center Batch ID against the history file values.
2. Each transaction is passed to the rule engine for validation.
See BASE II Clearing Interchange Formats or BASE II Clearing: VML Formats. Any errors
detected are passed onto the reporting process.
3. EPZOS performs optional processing including:
l Item or run tolerance checking.
l Calculating the hash value of each record, if duplicate batch checking via hashing is
selected.

4. The output process is invoked. Transactions are output to the file based on transaction status
(rejected or accepted). The format (VTF or ITF) is based on the run control option PROFILE.
Rejected Transactions—If a transaction was rejected and the processing center has selected
the SAVEREJECT run control option, the transaction is written to the Rejected Item File in the
same format as the input (CTF/VML).
Hash Totals—If the processing center uses an IBM mainframe (z/OS) and an ITF output file is
being created and run control option is ITFHASH=Y, a 2-byte hash total field is inserted in
each transaction at this time.
The Edit Package writes batch trailer to ITF/VTF files every time a batch trailer is encountered
in the input CTF/VML file. File trailers are written at the end of processing. If more than one
CTF/VML file is processed, the Edit Package will combine the files into the output ITF/VTF.
5. The reports process extracts summary and transaction-based report information into a
temporary file (WORK01) for use in creating reports.
6. EPZOS verifies that all batch and file trailers balance, that is, totals read from the records in
the CTF/VML, equal the sums of accepted and rejected totals accumulated by EPZOS during
processing.
If duplicate batch detection has been selected using the DUPBATCH option, EPZOS will also
compare the batch hash value or Center Batch ID against the history file values.
7. The Edit Package writes a batch trailer to the ITF/VTF file every time a batch trailer is
encountered in the CTF/VML file. File trailers are written to the ITF/VTF file at the end of
CTF/VML file processing. If more than one CTF/VML file is processed, the Edit Package will
combine the CTF/VML files on the output ITF/VTF file.
8. Edit Package generates a batch in the ITF/VTF that contains TC 50/T162 text transactions.
These transactions contain Edit Package incoming and outgoing environment information,
such as date of run and version and date of repository tables used during the run such as:
l VID table
l ARDEF table
l Value tables
l Repository definition
l Repository profile
l Codebase control table
There is one TC 50/T162 for each record in the Permanent and Temporary Run Control
Options file.
There is an environmental record and a record for each run control option used during the
previous incoming Edit Package run.

Edit Package Outgoing Exception,

Control, and Summary Report
Production
Producing exception, control, and summary reports includes these features.
1. In preparation for the reporting phase, the data is sorted for the following reports:
l Validation Exception Detail Report.
l Summary reports that summarize the transactions accepted for interchange.
l Optional transaction-based reports that are detail reports of the transaction information.
2. After the validation phase and sorting, EPZOS loads the repository table files needed to
generate the reports and calls the appropriate modules to format and generate the reports.
Edit Package History File Updates

If the run was successful, EPZOS updates the History File with these items.
l An outgoing batch record for each batch processed during the run.
l An outgoing file record for each file processed during the run.
l One outgoing run record.
Edit Package Outgoing Log Report

Production
During an outgoing Edit Package run, data is written to the system log. At the end of the outgoing
run, whatever data was accumulated in the Log File during the run is written to the EP-199 Log
Report.
Edit Package Outgoing Exception

Conditions
There are several types of exception conditions, including severe errors, CTF/VML errors, messages,
and other types of errors.

Edit Package Outgoing Run Severe Errors

If a severe error is detected during the outgoing Edit Package run, these actions will be taken.
l The appropriate severe error message appears in the Validation Exception Detail Report
(EP-100A) and the Log File Report (EP-199) is updated.
l An ITF/VTF is not created.
l Processing of the Edit Package continues to the end of the run, if possible. If the Reject
Message Limit (REJMSGLIM) run control option is specified, processing stops when the
percentage of the transactions processed so far exceeds the percentage specified for the
REJMSGLIM option. If the Reject ITF/VTF Limit (REJITFLIM) run control option is specified,
error reporting continues until all transactions in the input file are processed; the ITF/VTF is
not created if the percentage of transactions containing errors for the entire input file
exceeds the percentage specified on the REJITFLIM option.
CTF/VML Errors in Edit Package

If any errors are detected during the processing of the CTF/VML file, the transactions with errors are
written to the Validation Exception Detail Report (EP-100A) and are not passed to the output ITF/VTF.
If the SAVEREJECT run control option is selected, the transactions in error are written to a separate
CTF/VML reject file.
Edit Package Outgoing Messages

After each outgoing Edit Package run, the banner page of the EP-100A Validation Exception Detail
Report displays a message indicating the status of the run.

Edit Package Outgoing Run Error Types

Errors may occur during an outgoing Edit Package run.
Outgoing Edit Package Run Error Types
Type of Error Possible Causes Results
Run control option l Invalid run control option Severe error, run is aborted.
l Invalid values entered for run control option

l Conflicting run control options
Table load l Run control option CENTRBIN not in VID table Severe error, run is aborted.
l Invalid Table Key or Table Data run control

options
l Table file access errors
File header l Data does not match the BASE II CIB, Center Severe error, run is aborted.
Code, and Run Mode run control options
l Duplicate file detected
Rerun processing l Rerun was specified for a run that has not Severe error, run is aborted.
occurred
Batch trailer l Batch trailer validation failed Processing continues, but an ITF/CTF
is not created.
File trailer l File trailer validation failed An ITF/VTF is not created.
Duplicate Batch l Hash value matched to the value derived in a If DUPBATCH is set to Warning, a
previous batch warning message is displayed. The
batch is written to the ITF/VTF and
l Center ID in file trailer matched the ID in a
processing continues until the end of
previous batch
the run.
If it is set to Error, processing stops as
soon as an error is detected and an
ITF/VTF is not created.
Run Tolerance l Average of financial amount for the run is If RUNTOLER is set to Warning, a
greater than RUNCURAVG amount warning message is displayed and
the ITF/VTF is created.
If it is set to Error, an error message is
displayed and the ITF/VTF is not
created.
Repository table load l Run control option CENTRBIN not in VID table The Edit Package sets the return code
after each step of an Edit Package
run. The Outgoing Edit Package Run
options
Return Codestable lists the return
l Repository table file access errors codes for an outgoing run.

Outgoing Edit Package Run Return Codes
Return Code Explanation Results
0 No errors ITF/VTF and reports created.
2 Transaction–level warnings ITF/VTF and reports created. Transactions with warnings printed
on EP-100A Validation Exception Detail Report.
4 Transactions rejected ITF/VTF and reports created. Rejected transactions printed on

EP-100A Validation Exception Detail Report and omitted from
output ITF/VTF.
16 Severe errors ITF/VTF not created. EP-100A Validation Exception Detail Report
and EP-199 Log File Report created.
In cases where the application encounters abnormal termination
for unknown reasons, ITF/VML file(s) are created. A return code
of 16 is recorded in the EP-199 report; this means that an
inspection or cleanup is necessary. For PC, the EP-199 report can
be found at: C:\EP40\CXXXXXX\Reports\Outgoing

Files
These outgoing files are listed in the order in which they are used in the Outgoing procedure
(EP4OUT). For more information, see Edit Package File Layouts.
Outgoing Processing Files
Step Program Step Description DDname DDname Description
STEP01 IEFBR14 IBM utility used to various Refer to STEP02 for the corresponding
delete output files if ddnames.
present.
STEP02 EPZOS Outgoing Edit Run; for REPOSIT Repository Profile tables
detailed description,
refer to Chapter 3 in Edit
Package Release 4
Operations Guide.
Repository ARDEF tables
Repository VID tables
Repository Code Base
Repository Value tables
STEP02 EPZOS Outgoing Edit Run REPOSDEF Repository Definition tables

STEP02 EPZOS Outgoing Edit Run TMPOPT Center's Run Options File, Permanent and
Temporary
STEP02 EPZOS Outgoing Edit Run HSTKEY History File
STEP02 EPZOS Outgoing Edit Run HSTKEYA History File Backup A
STEP02 EPZOS Outgoing Edit Run HSTKEYB History File Backup B
STEP02 EPZOS Outgoing Edit Run CURCNV Input – Currency Rates File used when Run
Tolerance
STEP02 EPZOS Outgoing Edit Run ENVINF Input Environmental Hold File
STEP02 EPZOS Outgoing Edit Run EPOUT Output ITF or VTF for Outgoing; contains
financial and/or non-financial transactions
(except Collection-only transactions.
STEP02 EPZOS Outgoing Edit Run EPOUT2 Output ITF or VTF for Outgoing; contains
Collection-only transactions.
STEP02 EPZOS Outgoing Edit Run EPOUT02– Not currently used for Outgoing.
EPOUT25
STEP02 EPZOS Outgoing Edit Run REJTRANS Rejected Item file (TC or VML)
STEP02 EPZOS Outgoing Edit Run TRACE Trace file has information on transaction passed
to the validation program; information is
written to this file when
DLLPARM=RULE(TRACE=DUMP) is set.
STEP02 EPZOS Outgoing Edit Run EPRC Return Code File, not currently used; can be
dummied.
STEP02 EPZOS Outgoing Edit Run RETITM Not used in Outgoing.
STEP02 EPZOS Outgoing Edit Run TC33EX Not used in Outgoing.
STEP02 EPZOS Outgoing Edit Run TC54EX Not used in Outgoing.
STEP02 EPZOS Outgoing Edit Run INTMIN Mainframe sort Temp input file
STEP02 EPZOS Outgoing Edit Run INTMOUT Mainframe sort Temp output file
STEP02 EPZOS Outgoing Edit Run RPTWRK01 Report work file
STEP02 EPZOS Outgoing Edit Run RPTWRK1E Report work file
STEP02 EPZOS Outgoing Edit Run RPTWRK02 Report work file
STEP02 EPZOS Outgoing Edit Run EP745WK EP–745 work file
STEP02 EPZOS Outgoing Edit Run TOOLIN Used for mainframe sort work file (TOOLIN).
STEP02 EPZOS Outgoing Edit Run CTL1CNTL Used for mainframe sort work file (CNTL).

STEP02 EPZOS Outgoing Edit Run LOG Processing log file 1
STEP02 EPZOS Outgoing Edit Run LOG1 Processing log file 2
STEP02 EPZOS Outgoing Edit Run LOGX99 Processing log file 1
STEP02 EPZOS Outgoing Edit Run LOGX991 Processing log file 2
STEP02 EPZOS Outgoing Edit Run EP100A Validation Exception Report (Detail)
STEP02 EPZOS Outgoing Edit Run EP100B Validation Exception Report (Summary by
ACQ/ISS ID)
STEP02 EPZOS Outgoing Edit Run EP100C Validation Exception Report (Summary by
Center)
STEP02 EPZOS Outgoing Edit Run EP110B Outgoing Interchange Summary (Batch Level)
STEP02 EPZOS Outgoing Edit Run EP110C Outgoing Interchange Summary (File Level)
STEP02 EPZOS Outgoing Edit Run EP110E Outgoing Interchange Summary (Run Level)
STEP02 EPZOS Outgoing Edit Run EP110F Outgoing Interchange Summary (Final Level)
STEP02 EPZOS Outgoing Edit Run EP111C Outgoing Interchange by Currency Code (File
Level)
STEP02 EPZOS Outgoing Edit Run EP111E Outgoing Interchange by Currency Code (Run
Level)
STEP02 EPZOS Outgoing Edit Run EP120F Outgoing ITF Summary by Volume
STEP02 EPZOS Outgoing Edit Run EP705 Optional Transaction-Based Reports – Sales
Drafts
STEP02 EPZOS Outgoing Edit Run EP706 Optional Transaction-Based Reports – Credit
Vouchers
STEP02 EPZOS Outgoing Edit Run EP707 Optional Transaction-Based Reports – Cash
Disbursements
STEP02 EPZOS Outgoing Edit Run EP710 Optional Transaction-Based Reports – Fee
Collections
STEP02 EPZOS Outgoing Edit Run EP710C Optional Transaction-Based Reports –

Combined Visa and Non-Visa Fee Collections
STEP02 EPZOS Outgoing Edit Run EP710V Optional Transaction-Based Reports – Visa-only
Fee Collections
STEP02 EPZOS Outgoing Edit Run EP710N Optional Transaction-Based Reports – Non-Visa
Fee Collections
Draft Chargebacks

Voucher Chargebacks
Disbursement Chargebacks
STEP02 EPZOS Outgoing Edit Run EP720 Optional Transaction-Based Reports – Fee
Disbursements
STEP02 EPZOS Outgoing Edit Run EP720C Optional Transaction-Based Reports –

Combined Visa and Non-Visa Funds
Disbursements
STEP02 EPZOS Outgoing Edit Run EP720V Optional Transaction-Based Reports –

Combined Visa Funds Disbursement
STEP02 EPZOS Outgoing Edit Run EP720N Optional Transaction-Based Reports –

Combined Non-Visa Funds Disbursements
Draft Reversals
Voucher Reversals
Disbursement Reversals
STEP02 EPZOS Outgoing Edit Run EP730 Optional Transaction-Based Reports – ICS Input
Processing
STEP02 EPZOS Outgoing Edit Run EP731 Optional Transaction-Based Reports – ICS
Response Processing
STEP02 EPZOS Outgoing Edit Run EP732 Optional Transaction-Based Reports – Risk
Management
STEP02 EPZOS Outgoing Edit Run EP733 Optional Transaction-Based Reports –

Multipurpose Message
STEP02 EPZOS Outgoing Edit Run EP733F Optional Transaction-Based Report – Dispute
Financial Report
Draft Chargeback Reversals
Voucher Chargeback Reversals
Disbursement Chargeback Reversals
STEP02 EPZOS Outgoing Edit Run EP738 Optional Transaction-Based Reports – Copy
Request and Fulfillment Service Message

STEP02 EPZOS Outgoing Edit Run EP739 Optional Transaction-Based Reports – Copy
Fulfillment/Chargeback Documentation
Automation Services Message
STEP02 EPZOS Outgoing Edit Run EP740 Optional Transaction-Based Reports – Fraud
Advice
STEP02 EPZOS Outgoing Edit Run EP745 Optional Transaction-Based Reports – General
Delivery Report
STEP02 EPZOS Outgoing Edit Run EP746 Optional Transaction-Based Reports – Member
Settlement Data
Settlement Reports
Settlement Reports
STEP02 EPZOS Outgoing Edit Run EP748C Optional Transaction-Based Reports – BASE I
Advice—Format 2 Chip Informational Advice
STEP02 EPZOS Outgoing Edit Run EP748E Optional Transaction-Based Reports – BASE I
Advice (ISO-Enriched)
STEP02 EPZOS Outgoing Edit Run EP748S Optional Transaction-Based Reports – BASE I
Advice (Standard)
STEP02 EPZOS Outgoing Edit Run EP749 Optional Transaction-Based Report – Local
Batch Acknowledgement Report
STEP02 EPZOS Outgoing Edit Run EP750 Optional Transaction-Based Reports – Text
Message
STEP02 EPZOS Outgoing Edit Run EP752 Optional Transaction-Based Reports – Requests
for Copy
STEP02 EPZOS Outgoing Edit Run EP755 Optional Transaction-Based Reports – Regional
Card Recovery File (RCRF) Update Record
STEP02 EPZOS Outgoing Edit Run EP756 Optional Transaction-Based Reports – Currency
Conversion Rates
STEP02 EPZOS Outgoing Edit Run EP757 Optional Transaction-Based Reports – Data
Capture Advice
STEP02 EPZOS Outgoing Edit Run EP758 Optional Transaction-Based Reports – National
Settlement Advice
STEP02 EPZOS Outgoing Edit Run EP759 Optional Transaction-Based Reports – Interface
Transaction Advice
STEP02 EPZOS Outgoing Edit Run EP790 Optional Transaction-Based Reports – File
Header

STEP02 EPZOS Outgoing Edit Run EP791 Optional Transaction-Based Reports – Batch
Trailer
Trailer
Trailer
STEP02 EPZOS Outgoing Edit Run REPORTS Not currently used for Outgoing. Currently
used when EP–399 report is requested in the
&appl.&build.jcl(EP40EXT).
STEP02 EPZOS Outgoing Edit Run RPTINDEX Report work file index
STEP02 EPZOS Outgoing Edit Run TOOLMSG Sort sysout messages
STEP02 EPZOS Outgoing Edit Run DFSMSG Sort sysout messages
STEP05 IEBGENER IBM utility to copy log

files into GDG log files.
STEP05 IEBGENER IBM utility to copy log SYSUT1 Input log files
STEP05 IEBGENER IBM utility to copy log SYSUT2 Output log files (GDG)
STEP06 EP99PGM Create EP–199 and EP–

999 REPORTS AND
REPORT INDEX FILE
STEP06 EP99PGM Create EP–199 and EP– X99LOG Input log files
999 REPORTS AND
REPORT INDEX FILE
STEP06 EP99PGM Create EP–199 and EP– EP199 Processing log report file for Outgoing
999 REPORTS AND
REPORT INDEX FILE
STEP06 EP99PGM Create EP–199 and EP– EP999 Index of reports

999 REPORTS AND
REPORT INDEX FILE
STEP06 EP99PGM Create EP–199 and EP– EP999FL Work file containing report IDs and names
999 REPORTS AND used in reporting.
REPORT INDEX FILE
STEP06 EP99PGM Create EP–199 and EP– RPTINDEX File containing report IDs and names used in
999 REPORTS AND EP–999 reporting.
REPORT INDEX FILE

STEP07 IDCAMS Check if collection-only

file is empty (EPOUT2). If
it is, the condition code
returned is 1.
STEP07 IDCAMS Check if collection-only INFIL1 Accepted Collection-Only transactions (EPOUT2

file is empty (EPOUT2). If from Outgoing run).
returned is 1.
STEP07 IDCAMS Check if collection-only OUTFIL1 EPOUTMP – Temporary file that contains the TC
file is empty (EPOUT2). If 90 record of the accepted Collection-Only
it is empty the condition transactions (EPOUT2 from Outgoing run); will
code returned is 1. be empty if there are no accepted collection-
only transactions.
STEP07 IDCAMS Check if collection-only SYSIN IDCAMS input parameter file

file is empty (EPOUT2). If
returned is 1.
STEP08 IEFBR14 IBM utility to DELETE

COLLECTION FILE IF IT IS
EMPTY
STEP08 IEFBR14 IBM utility to DELETE EPOUT2 Output ITF or VTF for Outgoing – contains
COLLECTION FILE IF IT IS collection-only transactions
EMPTY
Edit Package Repository Table Files

The repository tables contain value tables including: Account Range Definition (ARDEF) Table, VID
Table, value tables, Repository Profile Table, and Repository Definition Table.
Account Range Definition (ARDEF) Table

The ARDEF Table contains all valid ARDEF entries, namely: the account prefix range, its associated
Issuing Identifier, card-number length indicator, check-digit indicator, product ID and account
funding source. The ARDEF File is used to verify account numbers received in interchange.
VID Table
A ACQ/ISS ID is a six-digit system number used by Visa to identify processing centers and clients.
The VID Table contains all valid ACQ/ISS IDs and their BASE II processing status codes. The VID Table
File is used to associate ACQ/ISS Identifiers used in interchange with their account numbers received
in interchange.

Value Tables
The repository value tables are made up of various tables used in the validation of BASE II
transactions. Examples are:
l Country Code
l Currency Code
l Merchant Category Code
l Chargeback Reason Code Table
l Fee Reason Code
l Return Reason Code
l Transaction Mapping Tables
l Software Update Control Tables
l Run Control Options
Repository Profile
The Edit Package Repository Profile Table file defines the default PROFILE parameter for Outgoing
and Incoming edit runs. The profile table defines the threads for each PROFILE parameter. The
PROFILE parameter table defines the set of run control option and its associated values for given
parameter PROFILE.
Repository Definition
The Repository Definition Table contains the internal mapping of repository tables used by Edit
Package and report layouts for VID, ARDEF, and other value tables.
Permanent and Temporary Edit Package Run

Control Options Files
These files contain permanent and temporary run control options and their associated values
specified by the processing center. These run control options are used to control the outgoing run.
For detailed information on run control options, see Run Control Options.
Edit Package Currency Conversion Rates File

(Optional)
The Currency Conversion Rates File is required only when processing in multiple currencies and using
the run tolerance checking option. It contains all valid BASE II currency codes, their effective dates,

scale factors, and conversion rates. This file is updated during incoming runs by TC 56 currency rate
update transactions.
Note:
The contents of the Visa Currency Conversion Rate file, i.e., Rate Update Records or TC 56 file,
are Confidential and may be used only by Visa and its authorized client financial institutions.
Any other use is strictly prohibited unless expressly authorized by Visa International.
Edit Package History File

The History File contains a history of batches, files, and runs for outgoing and incoming Edit Package
processing.
Edit Package Rejected Item File

The Rejected Item File, in CTF/VML or reject format, is created during outgoing Edit Package runs if
the processing center has elected to retain rejected transactions by using the SAVEREJECT run
control option. The file contains each transaction that was rejected (not written to the ITF/VTF) due to
errors detected during editing. This file is only created during runs that successfully create an ITF/VTF.
Edit Package Log File

The Log File contains messages recorded during Edit Package processing. The messages include run
control and environmental information as well as any unusual conditions warranting review.
Edit Package Incoming Run Hold File

The Incoming Run Hold File contains environmental report data and the run control option values
from the most recent incoming Edit Package run for transmission to the VIC during the next
outgoing processing. The data in this file is used to create reports used by Visa support personnel.
Edit Package Backup Files

The types of backup files are described in the following sections.
History Backup File

History Backup file serves as a backup file for the History File. There are two History Backup files: First
backup (BKUPA): It is overlaid by new History file at the end of every successful outgoing and

incoming run. This file is used to restore the History File in case of an error. Second backup (BKUPB):
It is a copy of the History file taken before the start of an outgoing and incoming run.
Edit Package Work and Sort Files

The types of work and sort files are described.
Transaction Report Work File

This file contains information to be sorted for the transaction-based reports and exception reports.
Summary Report Work File

This file contains information to be sorted for the summary reports.
EP100 Work File

This file contains information used to produce the EP–100B and EP–100C summary reports.
EP110 Work File

This file contains information used to produce the EP–110 series of reports.
Transaction Report Sort File

This file contains sorted information for use in the EP–100A Validation Exception Report and optional
transaction-based reports.
Summary Report Sort File

This file contains sorted information for use in the summary reports.
Edit Package Report Files

Each outgoing Edit Package report is written to a separate file. If data for a particular report was not
received, the file will contain a report header and a message indicating that there is not any data to
report. For additional Edit Package report information, see Summary of Edit Package Reports.

Outgoing Edit Package Processes

Controlled By Run Control Options
Certain outgoing Edit Package processes are controlled by run control options. These types of
outgoing run control options are detailed here.
With the exception of identifying the processing center, modification of run control option default
values is optional.
Types of Outgoing Run Control Options
Function Run Control Option(s) Purpose
Identify Processing Center CENTRBIN CENTRCODE Defines the processing center’s BASE II CIB,
CENTRNAME security code, and name.
Set Run Date RUNDATE Defines the Edit Package processing date,
overriding the system date.
Set Effective Date for Edit Package TABLEDATE Specifies the effective date used by the Edit
repository tables Package to establish which table entries and
rules to use during processing.
Validation Exception Report Options EXCPRPTFMT EXCPRPTSEQ Specifies the item sequence and format of the
Validation Exception reports.
Report Sequence TRANRPTSEQ Specifies the item sequence of transaction-

based and general delivery reports.
Internal Application Identifier INTERNAL Identifies Visa applications that run the Edit
Package.
Indicate File Type RUMODE Specifies whether the interchange to be

processed contains production or test data.
Set Size Limits for Batch MAXBATRECS Specifies the maximum number of TCRs or VML
records to be written to a single batch.
Set History Maintenance Parameters HISTPURGE HISTRETPD Specifies history maintenance to be performed
during incoming or outgoing run. Specifies the
number of calendar days tha run file and batch
data are retained on the Edit Package History
file.
Select Report Date, Time and DATEFORMAT DATESEP Specifies format for date, time, and numeric
Numeric Values Format NUMDECSEP values fo reports.
NUMTHOUSEP TIMESEP
Perform Rerun Processing RERUN Indicates that a rerun is to occur and defines the
Edit Package run number to be rerun.
Perform Trial Run TRIALRUN Edits an outgoing CTF or VML without creating
an outgoing ITF or VTF and without updating
the Edit Package History File.

Types of Outgoing Run Control Options
Function Run Control Option(s) Purpose
Perform Duplicate Batch Detection DUPBATCH Provides duplicate checking using a hashing
technique or the Center Batch ID on the TC 91/
T184 Batch Trailer record.
Perform Tolerance Checking ITEMCURAMT RUNTOLER Identifies, at the item and run levels, where
RUNCURAVG financial transactions exceed the tolerance limit
prior to collection and settlement by the Base II
System.
Set Error Limits REJTIFLIM REJMSGLIM Prevents creation of an ITF when defined error
limits have been exceeded.
Create Rejected Transaction File SAVEREJECT Writes transactions rejected by the outgoing
Edit Package to a separate file.
Generate Transaction-Based Reports TRNOUTPRT Indicates whether outgoing transaction-based

TRNOOUTPRT reports are to be printed.
Override Table Entries TBLKEYnn TBLDATAnn Modifies table file entries during a run.
Provide Operational ITF Header FILEIDMOD FILETYPE Specifies a single character in the File ID,
Information SOURCENAME Customer Delivery file type, and TC 90/T183
Source Name fields.
Generate Hash Totals ITFHASH Generates hash totals in positions 3–4 of the ITF
file created when using TC formats.
Outgoing Edit PackageE Processes

Controlled by Data (TC Formats)
The Duplicate File Detection outgoing Edit Package process does not require the use of run control
options.
Duplicate File Detection

This function gives processing centers the ability to check for potential file duplicates prior to
processing the CTF.
The outgoing CTF may contain a TC 90 header record. This record is used for duplicate file detection
within the same processing date. The provision of an outgoing CTF TC 90 header record is optional.
Processing centers that use this feature must generate the TC 90 header record in all pre-edit
software that creates outgoing CTFs destined for outgoing interchange.

Duplicate file detection is based on two data elements in the TC 90 header record:
l Center Processing Date—This is the processing date of the client's pre-edit system.
l File ID—This is a three-digit number that must be unique for each CTF processed by the Edit
Package for any given Center Processing Date. File IDs do not need to be in an ascending
sequence.
The outgoing Edit Package compares the combination of Center Processing Date and File ID
against the Edit Package History File. If a match is found, the Edit Package run is immediately
terminated.
Processing centers can produce a TC 90 header record and avoid duplicate detection by
applying a value of zero in the File ID field.
Note:
If multiple pre-edit systems create outgoing CTFs destined for outgoing interchange,
Visa recommends that a predefined range be allocated to each pre-edit system to
ensure uniqueness of File IDs and to avoid potential conflict.

Chapter 5
Cycle
Incoming Edit Package processing cycle processes are listed in the order they occur.
Note:
To ensure proper application of table update transactions, all incoming files must be
processed. Files must be processed in sequence by the Central Processing Date (CPD) on
which they were created to properly update the table files.
Edit Package Incoming Control

Program
The incoming control program, EPZOS, calls initialization functions, as needed, at the beginning of
each incoming run and then processes each transaction found in the input files. At the end of
processing, unless there were severe errors, the control program produces the necessary reports and
makes the CTF or VML available for use by the processing center.

Edit Package Incoming Processing Cycle
Typical Process Flow for Incoming Edit Package Run

The control program is started with a run-time parameter indicating the PROFILE desired. This is
defined when running under z/OS using the provided JCL procedures and the PROFILE= symbolic,
for example:
//EP4IN EXEC PROC=EP4IN,
//APPL=TEN, * APPLICATION FILES HLQ
//PROFILE=INCOMINGTC * PROFILE
Options and usage are:
INCOMINGTC = ITF input file resulting in a CTF output file
INCOMINGVML = VTF input file resulting in a VML output file
Edit Package Incoming Input

Requirements
Specific items are required before an incoming Edit Package run can be executed.
l An incoming ITF for VTF generated by the VisaNet Interchange Center (VIC).
l The following files which must reside on a direct access storage device:
n Permanent and Temporary Run Control Options files
n Rules Load library
n History file (original and backups)
n Log file
n Repository files:
- VID table
- ARDEF table
- Value table
- Definition table
- Profile
- Codebase
Note:
For processing centers that subscribe to the Currency Rate Delivery Service, the Currency
Conversion Rates File is required.
In addition, the processing center must have the Edit Package software itself available for execution.
The following items are required before an incoming Edit Package.

Edit Package Incoming System

Initialization
These processes occur during system initialization.
1. At the start of an incoming Edit Package run, EPZOS searches the Permanent and Temporary
Run Control Options for the following run control options:
BASE II CIB CENTRBIN
Center Code CENTRCODE
Center Name CENTRNAME
Table Date TABLEDATE
Run Date RUNDATE
Run Mode RUNMODE
Table Key TBLKEY
Table Data TBLDATA
Direction (incoming or outgoing) DIRECTION
Input location FILELOC
Input sequencing INPUTSEQ
Run option profile PROFILE
Note:
TABLEDATE, RUNDATE, RUNMODE, TBLKEY, TBLDATA, and INPUTSEQ run control options
are not required. If not present, default values are used.
2. EPZOS uses the information from the run control options listed above to load the repository
tables. The TBLDATA and TBLKEY temp options are retrieved before loading the repository
and are used during the load process.

3. Once the files and tables are loaded, EPZOS validates all run control options and:
a. Sets default values for run control options, where necessary.
b. Performs a cross-validation of run control options to ensure that there are no conflicting
options in the run.
c. Lists run control options in effect for the run to the Log file.
4. Assign Incoming Run Number
This process assigns run numbers within each processing date. The run number is established
by extracting the previous run number from the History File and adding 1 to it. The first run
of each date is set to 1.

Edit Package Incoming CTF/VML

Creation
These processes occur during system initialization.
1. Process ITF/VTF
The creation of the incoming CTF/VML includes these processes.
a. Check File Header—EPZOS compares the BASE II Unique File ID field in the ITF file
header to the History File in order to verify that the file has not been processed
previously. If the RERUN option has been used, a History File entry must exist that
matches the BASE II Unique File ID of the file currently being processed.
EPZOS also ensures that the incoming ITF/VTF file header information matches run
control options for:
l Center BASE II CIB
l Center Code
l Run Mode
b. Build Logical Transactions—This process reads one transaction at a time from the
incoming ITF/VTF and validates the transaction format.
If the processing center's computer system is IBM mainframe and the run control option
to check hash totals is on (ITFHASH=Y), hash totals are calculated and validated against
those in the records. Hash totals are then stripped from the CTF record so the record
becomes 168 bytes.
c. Validate Incoming File Trailer—This process validates the file trailer at the end of the
incoming ITF/VTF. After all input has been processed, EPZOS generates a file trailer for
the CTF/VML.
2. As transactions are processed from the incoming ITF/VTF, the incoming CTF/VML is created
for input to the processing center's post-edit program.
Returned Item File—If the processing center has selected the SAVERETURN run control
option and if there were any returned transactions in the incoming ITF/VTF, the write
transactions module writes the returned transactions to the Returned Item File.
Multiple CTF/VML Files—If the processing center specified any SPLITINFIL run control
options, the write transactions module determines to which CTF/VML subfile the transaction
should be written. If the processing center did not select SPLITINFIL run control options or if
there were transactions that were not split into a specific subfile, these transactions are
written to subfile 01.

3. EPZOS verifies that batch and file trailers balance. The transaction and TCR counts for TC
formats, in the trailers must equal the sum of the returned and accepted counts. The
monetary transaction count and the monetary amount hash totals must equal the
corresponding values for accepted transactions.
As transactions are processed from the incoming ITF/VTF, the incoming CTF/VML file is
created for input to the processing center’s post-edit program.
4. After saving an output transaction, the reports process will extract summary- and
transaction-based report information into a temporary file (RPTWRK01) for use in creating
reports.
Edit Package Incoming Exception,

Control, and Summary Report
Production
Producing exception, control, and summary reports have the elements described in the next sections.
1. After the validation phase and CTF/VML has been created, EPZOS reloads the repository
tables with the information needed to generate the reports.
2. Next, data is sorted for the following reports:
l Validation Exception Report
l Summary reports that summarize the transactions received in interchange
l Optional transaction-based reports that are detail reports of transaction information
After sorting data for these reports, EPZOS calls the appropriate modules to format and
generate the reports.

Edit Package Incoming File Updates/

Creation
During processing, the Edit Package will update/create these files.
1. Write TC 33 (Optional)
Certain optional Visa services may cause the delivery of TC 33 records in the interchange file
to write to a separate file.
Data delivered by this mechanism include: Plus Identifier tables, combined Visa/Plus routing
table, Visa Transaction Routing Service tables, Interlink Identifier tables, Visa Electron Routing
Table, Mastercard Routing, Cirrus Routing, Armed Forces Financial Network, ATM No
Surcharge Routing File, and VisaVue Solution Series Data and POS Acceptance Types Files.
The Edit Package recognizes designated TC 33 records and writes the full-length TC 33 into a
separate file. A program written by the processing center may be required to separate the
different types of data and to extract that data in the format required for the processing
center to use. (For more information regarding data content and extraction, refer to
documentation provided by Visa that applies to the services to which the processing center
subscribes.)
2. Update Currency Conversion Rates File (Optional)
If the processing center subscribes to the Currency Rate Delivery Service, this process uses TC
56 conversion rate update transactions to replace currency rate entries contained in the
Currency Conversion Rates File.
The contents of the Visa Currency Conversion Rate file (i.e., Rate Update Records or TC 56
file) are Confidential and may be used only by Visa and its authorized client financial
institutions. Any other use is strictly prohibited unless expressly authorized by Visa.
3. Update Software Control and Repository Tables
This process uses TC 54 (T261) table update transactions to update individual table entries in
the repository table. EPZOS writes the TC 54s (T261s) to a work file during CTF/VML
processing. After reporting is completed, the TC 54s (T261s) are applied to the appropriate
tables.
4. Save Environmental Run Information
EPZOS writes a record with environmental information and copies permanent and temporary
run control options to the incoming Run Hold File. This data is passed to the VIC during the
next outgoing Edit Package run. The Incoming Run Hold File is overlaid with environmental
data each time an incoming ITF/VTF is processed.
5. Update History File
If the run was successful, EPZOS updates the History File with file and run information from
the incoming Edit Package run.

Edit Package Incoming Log Report

Production
This process produces the incoming Log File Report (EP-299) from system log information.
Edit Package Incoming Exception

Conditions
There are several types of exception conditions.
Edit Package Incoming Severe Errors

If a severe error is detected during an incoming Edit Package run, the appropriate error message
appears in the Validation Exception Detail Report (EP-200A) and the Log File Report (EP-299). A
CTF/VML is not created, but processing of the Edit Package continues to the end of the run, unless
the error is encountered on the header record.
In incoming interchange processing, errors on financial transactions are severe. Non-monetary errors
generate a warning message. Any errors that indicate structural problems with the file (such as TCR
out of sequence and hashing errors (TC formats only), or file trailer errors) are severe, even if they are
not monetary.
Edit Package Incoming Messages

After each incoming Edit Package run, the banner page on the EP-200A Validation Exception Detail
Report displays a message indicating the status of the run.

Edit Package Incoming Error Types

After each incoming Edit Package run, the banner page on the EP-200A Validation Exception Detail
Report appears.
Types of Incoming Errors
Type of Error Cause Result
Run control option l Invalid run control option Severe error. Run is aborted.
l Invalid values entered for run control

option
l Conflicting run control options
Table load l Run control option Center BASE II CIB not Severe error. Run is aborted.
in VID Table
options
File header l Data does not match the Center BASE II Severe error. Run is aborted.
CIB, Center Code, and Run Mode run
control options
l Duplicate file detected when rerun was not
specified
l Rerun was specified for a run that has not
occurred
Batch trailer l Batch trailer validation failed Processing continues, but a CTF/VML is not
created.
File trailer l File trailer validation failed A CTF/VML is not created.

Edit Package Incoming Return Codes

For IBM MVS users, the Edit Package sets the return code after each job step of an incoming Edit
Package run.
Types of Incoming Return Codes
Return Process Explanation Result

Code
0 Incoming No errors or only nonmonetary EPZOS return code of 0 means that the output
processing transaction errors. CTF/VML file(s) and reports were created.
0 TC 54 TC 54 processing successful. EPTBLUPD return code of 0 (mainframe) or 1 (PC)

processing – means that TC 54 repository updates were
EPTBLUPD successfully processed. Repository updates include
VID, ARDEF, value, profile, and repository definitions.
3 TC 54 Codebase updates present and EPTBLUPD return code of 3. The TC 54s updates
processing – applied successfully to the include software updates and they were successfully
EPTBLUPD master repository. processed. For mainframe, the DLLOUT and JCLOUT
files were successfully created. For PC, the
PCDLLOUT.exe was successfully created.
4 TC 54 TC 54 informational broadcast EPTBLUPD return code of 4. The TC 54 updates

processing – from Visa. include a message or instructions from Visa. The
EPTBLUPD message will be written to the EP-299 report, e.g.,
the message may instruct the client to check the Visa
Online (VOL) EP Release 4 for Upgrade instructions
for a given effective date.
5 TC 54 TC 54 repository and software All succeeding steps pertaining to TC 54 processing

processing updates were not present in will be bypassed.
the input file.
6 TC 54 Processing of TC 54 updates EPTBLUPD return code of 6 indicates that the TC 54

processing – failed. update process failed.
EPTBLUPD
Contact Visa during normal business hours to
resolve TC 54 update problem.

Types of Incoming Return Codes

Code
8 Incoming TC 54 Sequence Error The TC 54 transactions not processed in the correct

processing sequence. Verify that input file(s) are correct and in
the right order.
Contact Visa during normal business hours to
resolve TC 54 sequence error.
16 Incoming Errors encountered. Depending on the nature of the error, output

processing CTF/VML file(s) and EP-200A and EP-299 reports
may or may not be created.
In some cases where the application encounters
abnormal termination for unknown reasons,
CTF/VML file(s) are created. A return code of 16 is
recorded in the EP-299 report; this means that an
inspection or cleanup is necessary.
For PC: EP-200A, EP-299 reports can be found at:
C:\EP40\CXXXXXX\Reports\Incoming
PC Batch Facility Log can be found at:
C:\EP40\BatchFacility\<Batch Facility Log Name>
\BF130426120652.log Format of file:
BF<yymmdd><timestamp>.log
When Incoming issues a return code of 0 for mainframe or 1 for PC, 3 or 4 for EPTBLUPD, the TC 54
updates were successfully applied to the master repository table. The master repository is split into
individual repository tables such as VID, ARDEF, value profile, definitions, and codebase by EPTBLSPT
program. Return codes from EPTBLSPT are shown.

Code
0 TC 54 All load modules are present. All load modules defined in the DLLOAD table are
processing – present in the production environment.
EPTBLSPT
2 TC 54 Missing “evaluate” modules. One or more load modules for a release with
processing – implementation type of E – (Evaluate) are missing
EPTBLSPT from the production environment.
4 TC 54 Missing “mandatory” modules. One or more load modules for a release with
processing – implementation type of M – (Mandatory) are missing
EPTBLSPT from the production environment.


Files
Edit Package files are used throughout the incoming processing cycle. Incoming Processing details
include step number, program name, step description, DDname, and DDname description.
These incoming files are listed in the order in which they are used in the Incoming procedure
(EP4IN).
Incoming Processing
STEP01 IEFBR14 IBM utility used to various Refer to STEP02 for the corresponding ddnames.
delete output files if
present.
STEP02 EPZOS Incoming Edit Run. See REPOSIT Repository Profile tables
EP Release 4 Operations
Guide for detailed
description.
Repository ARDEF tables
Repository VID tables
Repository Code Base
Repository Value tables
STEP02 EPZOS Incoming Edit Run REPOSDEF Repository Definition tables
STEP02 EPZOS Incoming Edit Run TMPOPT Center's Run Options File, Permanent and
Temporary
STEP02 EPZOS Incoming Edit Run HSTKEY History File
STEP02 EPZOS Incoming Edit Run HSTKEYA History File Backup A
STEP02 EPZOS Incoming Edit Run HSTKEYB History File Backup B
STEP02 EPZOS Incoming Edit Run CURCNV Output Currency Rates File
STEP02 EPZOS Incoming Edit Run ENVINF Output Environmental Hold File
STEP02 EPZOS Incoming Edit Run EPOUT Output ITF or VTF for Outgoing; contains financial
and/or non-financial transactions (except
collection-only transactions.
STEP02 EPZOS Incoming Edit Run EPOUT2 Not currently used.
STEP02 EPZOS Incoming Edit Run EPOUT02– Output file 02 through file 25, use when SPLITBY
EPOUT25 run control options are in effect for the run.
STEP02 EPZOS Incoming Edit Run REJTRANS Not used – Rejected Item File (TC or VML).

Incoming Processing
STEP02 EPZOS Incoming Edit Run TRACE Trace File contains information on transaction
passed to the validation program; information is
written to this file when
DLLPARM=RULE(TRACE=DUMP) is set.
STEP02 EPZOS Incoming Edit Run EPRC Return code file, not currently used, can be
dummied.
STEP02 EPZOS Incoming Edit Run RETITM Returned item file
STEP02 EPZOS Incoming Edit Run TC 33 EX Output Routing tables (TC 33s)
STEP02 EPZOS Incoming Edit Run TC 54 EX Output TC 54 Extract file
STEP02 EPZOS Incoming Edit Run INTMIN Mainframe sort Temp input file
STEP02 EPZOS Incoming Edit Run INTMOUT Mainframe sort Temp output file
STEP02 EPZOS Incoming Edit Run RPTWRK01 Report work file
STEP02 EPZOS Incoming Edit Run RPTWRK1E Report work file
STEP02 EPZOS Incoming Edit Run RPTWRK02 Report work file
STEP02 EPZOS Incoming Edit Run EP745WK EP–745 work file
STEP02 EPZOS Incoming Edit Run EP745WKS EP–745 work file
STEP02 EPZOS Incoming Edit Run TOOLIN Used for mainframe sort work file (TOOLIN)
STEP02 EPZOS Incoming Edit Run CTL1CNTL Used for mainframe sort work file (CNTL)
STEP02 EPZOS Incoming Edit Run LOG Processing log file 1
STEP02 EPZOS Incoming Edit Run LOG1 Processing log file 2
STEP02 EPZOS Incoming Edit Run LOGX99 Processing log file 1
STEP02 EPZOS Incoming Edit Run LOGX991 Processing log file 2
STEP02 EPZOS Incoming Edit Run EP100A Not used – Validation Exception Report (Detail)
STEP02 EPZOS Incoming Edit Run EP100B Not used – Validation Exception Report (Summary
by ACQ/ISS ID)
STEP02 EPZOS Incoming Edit Run EP100C Not used – Validation Exception Report (Summary
by Center)
STEP02 EPZOS Incoming Edit Run EP110B Not used – Outgoing Interchange Summary
(Batch Level)
STEP02 EPZOS Incoming Edit Run EP110C Not used – Outgoing Interchange Summary (File
Level)
STEP02 EPZOS Incoming Edit Run EP110E Not used – Outgoing Interchange Summary (Run
Level)

Incoming Processing
STEP02 EPZOS Incoming Edit Run EP110F Not used – Outgoing Interchange Summary (Final
Level)
STEP02 EPZOS Incoming Edit Run EP111C Not used – Outgoing Interchange by Currency
Code (File Level)
STEP02 EPZOS Incoming Edit Run EP111E Not used – Outgoing Interchange by Currency
Code (Run Level)
STEP02 EPZOS Incoming Edit Run EP120F Not used – Outgoing ITF Summary by Volume
STEP02 EPZOS Incoming Edit Run EP200A Incoming Validation Exception Report (Detail)
STEP02 EPZOS Incoming Edit Run EP200B Incoming Validation Exception Report (Summary
by ACQ/ISS ID)
STEP02 EPZOS Incoming Edit Run EP200C Incoming Validation Exception Report (Summary
by Center)
STEP02 EPZOS Incoming Edit Run EP204A BASE II Returned Item Report (Detail)
STEP02 EPZOS Incoming Edit Run EP204B BASE II Returned Item Report (Summary by
ACQ/ISS ID)
STEP02 EPZOS Incoming Edit Run EP204C BASE II Returned Item Report (Summary by
Center)
STEP02 EPZOS Incoming Edit Run EP206A CRS – Returned Item Report (Detail)
STEP02 EPZOS Incoming Edit Run EP206B CRS – Returned Item Report (Summary by
ACQ/ISS ID)
STEP02 EPZOS Incoming Edit Run EP206C CRS – Returned Item Report (Summary by Center)
STEP02 EPZOS Incoming Edit Run EP210B Incoming Interchange Summary (Batch Level)
STEP02 EPZOS Incoming Edit Run EP210C Incoming Interchange Summary (File Level)
STEP02 EPZOS Incoming Edit Run EP210D Incoming Interchange Summary (CPD Level)
STEP02 EPZOS Incoming Edit Run EP210E Incoming Interchange Summary (Run Level)
STEP02 EPZOS Incoming Edit Run EP210F Incoming Interchange Summary (Final Level)
STEP02 EPZOS Incoming Edit Run EP211C Incoming Interchange Summary by Currency
Code (File Level)
STEP02 EPZOS Incoming Edit Run EP211D Incoming Interchange Summary by Currency
Code (CPD Level)
STEP02 EPZOS Incoming Edit Run EP211E Incoming Interchange Summary by Currency
Code (Run Level)
STEP02 EPZOS Incoming Edit Run EP220 Collected Reconciliation Summary
STEP02 EPZOS Incoming Edit Run EP221B Collected Batch Acknowledgment

Incoming Processing
STEP02 EPZOS Incoming Edit Run EP221D Collected Batch Acknowledgment Summary (CPD
Level)
STEP02 EPZOS Incoming Edit Run EP221E Incoming Interchange Summary by Currency
Code (Run Level)
STEP02 EPZOS Incoming Edit Run EP230 Interchange Transaction File Distribution
STEP02 EPZOS Incoming Edit Run EP240V Fee Collection/Funds Disbursement Summary
(Visa only)
STEP02 EPZOS Incoming Edit Run EP240N Fee Collection/Funds Disbursement Summary
(non-Visa)
STEP02 EPZOS Incoming Edit Run EP240C Fee Collection/Funds Disbursement Summary
(Combined Visa and non-Visa)
STEP02 EPZOS Incoming Edit Run EP299 Incoming Processing Log
STEP02 EPZOS Incoming Edit Run EP701 Returned Credit
STEP02 EPZOS Incoming Edit Run EP702 Returned Debit
STEP02 EPZOS Incoming Edit Run EP703 Returned Nonfinancial
STEP02 EPZOS Incoming Edit Run EP704 Reclassification Advice
STEP02 EPZOS Incoming Edit Run EP705 Optional Transaction-Based Reports – Sales Drafts
STEP02 EPZOS Incoming Edit Run EP706 Optional Transaction-Based Reports – Credit
Vouchers
STEP02 EPZOS Incoming Edit Run EP707 Optional Transaction-Based Reports – Cash
Disbursements
STEP02 EPZOS Incoming Edit Run EP710 Optional Transaction-Based Reports – Fee
Collections
STEP02 EPZOS Incoming Edit Run EP710C Optional Transaction-Based Reports – Combined
Visa and Non-Visa Fee Collections
STEP02 EPZOS Incoming Edit Run EP710V Optional Transaction-Based Reports – Visa-only
Fee Collections
STEP02 EPZOS Incoming Edit Run EP710N Optional Transaction-Based Reports – Non-Visa
Fee Collections
STEP02 EPZOS Incoming Edit Run EP715 Optional Transaction-Based Reports – Sales Draft
Chargebacks
Voucher Chargebacks
Disbursement Chargebacks

Incoming Processing
STEP02 EPZOS Incoming Edit Run EP720 Optional Transaction-Based Reports – Fee
Disbursements
STEP02 EPZOS Incoming Edit Run EP720C Optional Transaction-Based Reports – Combined
Visa and Non-Visa Funds Disbursement
STEP02 EPZOS Incoming Edit Run EP720V Optional Transaction-Based Reports – Combined
Visa Funds Disbursements
STEP02 EPZOS Incoming Edit Run EP720N Optional Transaction-Based Reports – Combined
Non-Visa Funds Disbursements
Reversals
Voucher Reversals
Disbursement Reversals
STEP02 EPZOS Incoming Edit Run EP730 Optional Transaction-Based Reports – ICS Input
Processing
STEP02 EPZOS Incoming Edit Run EP731 Optional Transaction-Based Reports – ICS
Response Processing
STEP02 EPZOS Incoming Edit Run EP732 Optional Transaction-Based Reports – Risk
Management
STEP02 EPZOS Incoming Edit Run EP733 Optional Transaction-Based Reports –

Multipurpose Message
STEP02 EPZOS Incoming Edit Run EP733F Optional Transaction-Based Reports – Dispute
Financial Report
Chargeback Reversals
Voucher Chargeback Reversals
Disbursement Chargeback Reversals
STEP02 EPZOS Incoming Edit Run EP738 Optional Transaction-Based Reports – Copy
Request and Fulfillment Service Message
STEP02 EPZOS Incoming Edit Run EP739 Optional Transaction-Based Reports – Copy
Fulfillment/Chargeback Documentation
Automation Services Message
STEP02 EPZOS Incoming Edit Run EP740 Optional Transaction-Based Reports – Fraud
Advice

Incoming Processing
STEP02 EPZOS Incoming Edit Run EP744 Optional Transaction-Based Reports – Collection
Batch Acknowledgment
STEP02 EPZOS Incoming Edit Run EP745 Optional Transaction-Based Reports – General
Delivery Report
STEP02 EPZOS Incoming Edit Run EP746 Optional Transaction-Based Reports – Member
Settlement Data
Settlement Reports
Settlement Reports
STEP02 EPZOS Incoming Edit Run EP748C Optional Transaction-Based Reports – BASE I
Advice—Format 2 Chip Informational Advice
STEP02 EPZOS Incoming Edit Run EP748E Optional Transaction-Based Reports – BASE I
Advice (ISO-Enriched)
STEP02 EPZOS Incoming Edit Run EP748S Optional Transaction-Based Reports – BASE I
Advice (Standard)
STEP02 EPZOS Incoming Edit Run EP749 Optional Transaction-Based Reports – Local Batch
Acknowledgement Report
STEP02 EPZOS Incoming Edit Run EP750 Optional Transaction-Based Reports – Text
Message
STEP02 EPZOS Incoming Edit Run EP752 Optional Transaction-Based Reports – Requests
for Copy
STEP02 EPZOS Incoming Edit Run EP754 Optional Transaction-Based Reports – Table
Update Record
STEP02 EPZOS Incoming Edit Run EP755 Optional Transaction-Based Reports – Regional
Card Recovery File (RCRF) Update Record
STEP02 EPZOS Incoming Edit Run EP756 Optional Transaction-Based Reports – Currency
Conversion Rates
STEP02 EPZOS Incoming Edit Run EP757 Optional Transaction-Based Reports – Data
Capture Advice
STEP02 EPZOS Incoming Edit Run EP758 Optional Transaction-Based Reports – National
Settlement Advice
STEP02 EPZOS Incoming Edit Run EP759 Optional Transaction-Based Reports – Interface
Transaction Advice
STEP02 EPZOS Incoming Edit Run EP790 Optional Transaction-Based Reports – File Header
STEP02 EPZOS Incoming Edit Run EP791 Optional Transaction-Based Reports – Batch
Trailer

Incoming Processing
STEP02 EPZOS Incoming Edit Run EP792 Optional Transaction-Based Reports – File Trailer
STEP02 EPZOS Incoming Edit Run EP999 Index of Reports
STEP02 EPZOS Incoming Edit Run REPORTS Not currently used for Incoming. Currently used
when EP–399 report is requested in the
&appl.&build.jcl(EP40EXT).
STEP02 EPZOS Incoming Edit Run RPTINDEX Report work file index
STEP02 EPZOS Incoming Edit Run RPTINDX2 Report work file index
STEP02 EPZOS Incoming Edit Run TOOLMSG Sort sysout messages
STEP02 EPZOS Incoming Edit Run DFSMSG Sort sysout messages
STEP02 EPZOS Incoming Edit Run SYSUDUMP The system writes to SYSUDUMP when there is an
abnormal termination.
STEP02 EPZOS Incoming Edit Run CEEDUMP Language Environment dump report
STEP03 IDCAMS Check to see if there are INDD TC 54 Extract File

TC 54s in the input file.
STEP03 IDCAMS Check to see if there are OUTDD Dummy

TC 54s in the input file.
STEP03 IDCAMS Check to see if there are SYSIN IDCAMS control cards – repro; set return
TC 54s in the input file. code=05, if there are no TC 54s.
STEP04 EPTBLUPD Table Update program – REPOSIT Input master repository file
creates the new master
repository – creates
dynamic JCL which will
automatically link
object modules to
create load modules
and also split the
master repository to
individual repository
files.
STEP04 EPTBLUPD Table Update program – TC54EXT TC 54 Extract File

automatically link
object modules to
create load modules
and also split the
files.

Incoming Processing
STEP04 EPTBLUPD Table Update program – JOBCARDS Job cards for automatic DUF processing of TC 54s.
automatically link
object modules to
create load modules
and also split the
files.
STEP04 EPTBLUPD Table Update program – REPOSITO Temporary output master repository file.
automatically link
object modules to
create load modules
and also split the
files.
STEP04 EPTBLUPD Table Update program – JCLOUT Dynamic JCL that will be submitted automatically
creates the new master by DUF.
automatically link
object modules to
create load modules
and also split the
files.
STEP04 EPTBLUPD Table Update program – DLLOUT Link edit control cards and object code.
automatically link
object modules to
create load modules
and also split the
files.

Incoming Processing
STEP04 EPTBLUPD Table Update program – LOG DUF log file

automatically link
object modules to
create load modules
and also split the
files.
STEP05 IEBGENER IBM Utility to submit SYSUT1 JCL dynamic created in STEP04 that will create
JCL created from object and link control cards; link object modules
STEP04 (JCLOUT) via to create load modules and split master
the internal reader. repository files.
STEP05 IEBGENER IBM Utility to submit SYSUT2 Internal reader

JCL created from
STEP04 (JCLOUT) via
the internal reader.
STEP06 IEBGENER IBM utility to copy log SYSUT2 Output log file (GDG)
STEP06 IEBGENER IBM utility to copy log SYSUT1 Input log files
STEP06 IEBGENER IBM utility to copy log SYSIN Dummy file

STEP07 EP99PGM Create EP–199 and EP–

999 REPORTS AND
REPORT INDEX FILE
STEP07 EP99PGM Create EP–199 and EP– X99LOG Input log files
999 REPORTS AND
REPORT INDEX FILE
STEP07 EP99PGM Create EP–199 and EP– EP199 Dummy for incoming
999 REPORTS AND
REPORT INDEX FILE
STEP07 EP99PGM Create EP–199 and EP– EP299 Processing log report for incoming
999 REPORTS AND
REPORT INDEX FILE
STEP07 EP99PGM Create EP–199 and EP– EP999 Index of reports

999 REPORTS AND
REPORT INDEX FILE

Incoming Processing
STEP07 EP99PGM Create EP–199 and EP– EP999FL Work file containing report IDs and names used
999 REPORTS AND in reporting.
REPORT INDEX FILE
STEP07 EP99PGM Create EP–199 and EP– RPTINDEX File containing report IDs and names used in EP–
999 REPORTS AND 999 reporting
REPORT INDEX FILE
Edit Package Incoming File and Table Types
Incoming Edit Package File and Table Types
Type Description
Repository Tables
Account Range Definition (ARDEF) The ARDEF Table contains all valid ARDEF entries, namely: the account prefix
Table range, its associated Issuing Identifier, card-number length indicator, check-
digit indicator, product ID, and account funding source. The ARDEF File is
used to verify account numbers received in interchange.
VID Table A CIB is a six-digit system number used by Visa to identify processing
centers and clients. The VID Table contains all valid ACQ/ISS IDs and their
BASE II processing status codes. The VID Table is used to associate ACQ/ISS
IDs used in interchange with their account numbers received in interchange.
Value Tables The repository value tables are made up of various tables used in the
validation of BASE II transactions. Examples are:
l Country Code
l Currency Code
l Merchant Category Code
l Chargeback Reason Code Table
l Fee Reason Code
l Return Reason Code
l Transaction Mapping Tables
l Software Update Control Tables
l Run Control Options
Repository Profile The Edit Package Repository Profile table file defines the default PROFILE
parameter for Outgoing and Incoming edit runs. The profile table defines the
threads for each PROFILE parameter. The PROFILE parameter table defines
the set of run control option and its associated values for given parameter
PROFILE.

Type Description
Repository Definition The Repository definition table contains the internal mapping of repository
tables used by Edit Package and report layouts for VID, ARDEF, and other
value tables.
Repository Codebase Control Table The Codebase Control tables contain key information regarding object
modules and their effective dates. With the linker control records in the
Repository value tables, system will create load modules for a given effective
date. The system will load and execute the appropriate load modules based
on run date.
TC 54 Work File TC 54 table update transactions are written to the TC 54 Work File during ITF
processing. When ITF processing is complete, transactions from this file are
used to update the Edit Package table files.
Currency Conversion Rates File The Currency Conversion Rates File is required for the Currency Rate Delivery
(Optional) Service. It contains all valid BASE II currency codes, their effective dates, scale
factors, and conversion rates. This file is updated by TC 56 currency rate
update transactions.
The contents of the Visa Currency Conversion Rate file (i.e., Rate Update
Records or TC 56 file) are Confidential and may be used only by Visa and its
authorized client financial institutions. Any other use is strictly prohibited
unless expressly authorized by Visa.
Permanent and Temporary Run These files contain permanent and temporary run control options and their
Control Options Files associated values specified by the processing center. These run control
options are used to control the incoming run.
History File The History File contains a history of batches, files, and runs for outgoing
and incoming Edit Package processing.
Returned Item File The Returned Item File is created during incoming Edit Package runs if the
processing center has elected to separate returned transactions by using the
SAVERETURN run control option. The file will contain each transaction that
was returned by Visa as a result of BASE II editing at the VIC.
Log File The Log File contains messages recorded during Edit Package processing.
The messages include run control and environmental information as well as
any unusual conditions warranting review.
Incoming Hold File The Incoming Run Hold File contains environmental report data and the run
control option values from the most recent incoming Edit Package run for
transmission to the VIC during outgoing processing. The data in this file is
used to create reports used by Visa support personnel.
TC 33 Extract File The TC 33 Extract File contains data received from optional Visa services. This
file consists of BASE II TC 33 transactions and includes: Plus Identifier tables,
combined Visa/Plus routing table, Visa Transaction Routing tables, Interlink
Routing tables, Visa Electron Routing Table, Mastercard Routing, Cirrus
Routing, Armed Forces Financial Network, ATM No Surcharge Routing File,
VisaVue Solution Series data, and POS Acceptance Types Files.

Type Description
History Backup Files Serves as a backup file for the History File. There are two History Backup
files:
l First backup (BKUPA): It is overlaid by new History file at the end of every
successful outgoing and incoming run.
This file is used to restore the History File in case of an error.
l Second backup (BKUPB): It is a copy of the History file taken before the
start of an outgoing and incoming run.
Report Files Each Edit Package report is written to a separate file. If data for a particular
report was not received, the file will contain a report header and a message
indicating that there is no data to report. (For additional Edit Package report
information, see Summary of Edit Package Reports.)
Work and Sort Files
Transaction Report Work File This file contains information to be sorted for transaction-based reports and
exception reports.
Summary Report Work File This file contains information to be sorted for the summary reports.
Transaction Report Sort File This file contains sorted information for use in the transaction-based reports
and the EP-200A Validation Exception Report.
Summary Report Sort File This file contains sorted information for use in the summary reports.
Incoming Edit Package Processes

Controlled by Run Control Options
Certain incoming Edit Package processes are controlled by run control options. With the exception of
identifying the processing center, modification of run control option default values is optional.
Types of Incoming Run Control Options
Incoming Function Run Control Option(s) Purpose
Identify Processing Center CENTRBIN CENTRCODE Defines the processing center's BASE II CIB,
CENTRNAME name, and security code.
Verify Run Date RUNDATE Verifies the central processing date in the
ITF/VTF header when reruns are being
processed.
Set Effective Date for Edit Package TABLEDATE Specifies effective date used by the Edit
Tables Package to establish which table entries to
use during processing.

Types of Incoming Run Control Options
Incoming Function Run Control Option(s) Purpose
Validation Exception Report Options EXCPRPTFMT EXCPRPTSEQ Specifies item sequence and format of
Validation Exception Reports.
Report Format FEERPTFMT TRANRPTSEQ Specifies the format and item sequence of fee
collection, fund disbursement, transaction,
and general delivery reports.
Internal Application Identifier INTERNAL Identifies Visa applications that run the Edit
Package.
Indicate File Type RUNMODE Specifies whether the interchange to be

processed contains production or test data.
Set History Maintenance Parameters HISTPURGE HISTRETPD Specifies history maintenance to be

performed during incoming or outgoing run.
Specifies the number of calendar days that
run, file, and batch data are retained on the
Edit Package History File.
Select Report Date, Time, and DATEFORMAT DATESEP Specifies format for date, time, and numeric
Numeric Values Format NUMDECSEP NUMTHOUSEP values for reports.
TIMESEP
Perform Rerun Processing RERUN Indicates that a rerun is to occur.
Create Incoming CTF Header Record WRITEHEADR Creates a TC 90/T183 header record on all
incoming CTFs/VMLs.
Split Incoming ITF into Multiple CTFs SPLITINFIL SPLITBYARD Splits an incoming ITF/VTF into separate
SPLITBYBIN SPLITBYPID CTFs/VMLs based on account ranges, DEST
SPLITBYSET SPLITBYTC IDs, settlement flag, or transaction codes.
SPLITBYTT
Create Returned Items File SAVERETURN Writes transactions returned by the VIC on
incoming interchange to a separate file.
Pass Transactions to CTF TRNPASS TRNOPASS Controls which transactions are written to the
CTF/VML.
Generate Transaction-Based Reports TRNINPRT TRNNOINPRT Indicates whether incoming transaction-

based reports are to be printed.
Override Table File Entries TBLKEYnn TBLDATAnn Use to modify table file entries during a run.

Incoming Edit Package Process

Controlled By Data
The Duplicate File Detection incoming Edit Package process does not require the use of run control
options.
Duplicate File Detection

This function prevents the processing center from accidentally processing the same financial ITF
twice, unless a rerun is specified.
Incoming duplicate file detection is based on the BASE II Unique File ID in the ITF TC 90 header
record.
If rerun is not specified, the History File must not contain a record for the BASE II Unique File ID.

Chapter 6
The Edit Package provides extensive flexibility through the use of run control options. These options
allow processing centers to execute the Edit Package in a way suited to their individual processing
needs. A default set of options is supplied with the Edit Package software. The processing center can
update the default options at any time, either permanently or temporarily.
All run control options are validated at the beginning of each outgoing and incoming Edit Package
run. If any invalid run control options are detected, warning or error messages are written to the Log
File and the run may be discontinued.
Modification of all run control option default values is optional, with the exception of identifying the
processing center.
All run control option values used for your Edit Package runs are distributed to Visa via Edit Package-
generated TC 50/T162 environmental records. Visa uses this information for troubleshooting, since it
reflects how your Edit Package environment is set up.
See BASE II Clearing Edit Package Run Control Options Quick Reference for a summary of all Edit
Package run control options.

Types of Edit Package Run Control

Options
There are two types of run control options: permanent and temporary. Permanent and temporary run
control options are maintained in separate files. Processing centers can modify the file contents using
a general purpose line or full screen editor applicable to their operating environment.
Permanent Edit Package Run Control

Options
Permanent run control options reside on disk in the Permanent Run Control Options File. The
Permanent Run Control Options File specifies the way processing is usually performed at the
processing center. A default set of values is supplied with the Edit Package software. These default
values can be modified at any time by TC 54 Table Update transactions and should not be modified
by the user.
Permanent run control options are defined in the repository runopt table and are identified by a
keyword at the beginning of each record. Each permanent run control option is a separate record in
the Permanent Run Control Options File.
Permanent Run Control Options File Field Requirements
Field Requirements Explanation
Table name Begins in column 3 The character string “runopt” is present.
Option Keyword Begins in column 12 Keyword (lower-case) as defined in the run control options keywords.
Option Value Begins in column 33 Argument to the keyword as defined in the run control options
definition. Note that only one permanent run control option per
keyword can be specified. Any profile or temporary run control
option will replace a permanent option.
Default Values:
The Permanent Run Control Options File defines the default values. The CENTRBIN and CENTRCODE
run control options must be provided. Default run control options are set when the Edit Package
software is installed.
Default File:
Permanent Run Control Options are contained in the repository file as the runopt table. It is created
during Edit Package installation.

Permanent Run Control Options Repository File Contents
Temporary Edit Package Run Control

Options
Temporary run control options can be specified in two places. The profile file includes a profile
parameter table (optional) that associates options with a profile name. The Temporary Run Control
Options file is used to identify run specific options.
Both methods define overrides against the Permanent Run Control Options file. Options specified in
the profile parameter table are treated as Temporary Run Control Options. Any run control option
that is valid in the Permanent Run Control Option File is also valid in the Temporary Run Control
Options File. Some run control options are valid only in the Temporary Run Control Options File. The
Temporary Run Control Options file is empty when there are no overrides for the permanent run
control options.
Each temporary run control option is defined in a separate record. Temporary Run Control Options
are identified using a keyword (the option name) and an argument. The Profile Parameter table
entries and Temporary Run Control Options File use different formats.

Edit Package Profile Parameter Syntax

Each record starts with a Run Control Option keyword. Any Temporary Run Control Options will
replace the corresponding Permanent Run Control Options.
l Run Control Options start with the string “profilep” in column 1 to identify the profile
parameter table.
l The profile name that the parameter is associated with starts in column 9.
l The Run Control Option keyword starts in column 30.
l The Run Control Option argument starting in column 43.
Each record starts with a Run Control Option keyword. Any Temporary Run Control Options will
replace the corresponding Permanent Run Control Options.
Temporary Edit Package Run Control Option

Syntax
Temporary run control options must follow specific syntax rules.
These syntax rules are:
l The temporary run option file contains one command per line.
l Commands must exist between columns 1 through 71 (unless the NOSEQ keyword is
present).
l If a line starts with an asterisk (‘*’) in column one, the line is considered a comment.
l If the keyword NOSEQ is input on a line, all lines after this statement are assumed not to have
sequence numbers and the entire line is used for a run option.
l The option keyword starts in column one and is terminated with an equal sign immediately
after the keyword.
l The assigned argument starts immediately after the keyword equal sign.
l If a keyword is used more than once, the second instance will replace the first unless
otherwise indicated in the Run Control Option definition below.
l The keyword REPLACE= can be placed immediately after a Run Control Option keyword
equal sign. This syntax is used to indicate that the line defines a replacement of a previously
specified instance of the keyword.
Some Temporary Run Control Options can be identified with multiple records using the same
keyword. For example, TRNPASS= can be specified multiple times to define multiple transactions.
A Temporary Run Control Option that can be specified more than once can use the REPLACE=
keyword to indicate that any previous instance of the keyword is to be ignored. This allows the
Temporary Run Control Option file to override the profile. For example, if a profile identifies

FILELOC=dd:EPIN, a Temporary Run Control option could specify FILELOC=REPLACE=dd:EPIN01. In

this case EPIN01 is used as a DD name for the input. If the Temporary Run Control option file in this
case specifies FILELOC=dd:EPIN01, both EPIN and EPIN01 are used as input.
FILELOC=dd:EPIN
….
FILELOC=REPLACE=\\xxx\yyy\*.vml
In this example, the first FILELOC is discarded when the second is encountered. Input will include all
files with a .vml suffix in the \xxx\yyy directory (under Windows).
FILELOC=dd:EPIN
….
FILELOC=\\xxx\yyy\*.vml
In this example input includes the file(s) defined by DD EPIN and files with a .vml suffix in the \xxx
\yyy directory (under Windows).
Edit Package Run Control Options at a

Glance
Run control options allow a processing center to determine how the Edit Package environment is set
up.
Option Keyword Indicates the run control option key word
Title The name, short description, or both of the run control option
In Indicates if the option is used during the Incoming Run
Out Indicates if the option is used during the Outgoing Run
Temp Indicates if the option is valid only in the Temporary Run Control Options File

Run Control Options At a Glance
Option Keyword Title and Description In Out Temp
AUTOUPDT The automatic update option provides the Out

ability to request for updates required to
keep the processing center's repository
tables current.
Note: AUTOUPDT is one of the

new options that replaces the
EXTENSIONS option.
CENTRBIN Center BASE II CIB defines the processing In Out

center’s Bank Identification Number (CIB).
CENTRCODE Center Security Code specifies the In Out

processing centers security code.
CENTRNAME Center Name defines the centers name In Out

used on Edit Package reports.
CHARSET Character Set is used along with COUNTRY In Out

and LANG to identify a default LOCALE.
COUNTRY Identify Language-dependent tables and In Out

set default locale-specific options.
DATEFORMAT Date Format specifies how the Gregorian In Out

date is to be displayed on Edit Package
reports.
DATESEP Date Separator specifies the character used In Out

to separate Gregorian date fields.
DESTNAME Destination application name placed in Out

outgoing header records.
DIRECTION Run Direction identifies the execution as In Out

either an incoming or outgoing run.
DLLNAME Define DLLs to be loaded by Name. In Out
DLLPARM Pass a Parameter to one or more DLLs In Out

loaded at run time.
DUPBATCH Duplicate Batch Detection is used to Out

identify a possible duplicated batch.
EXCPRPTFMT Exception Report Format selection. In Out
EXCPRPTSEQ Exception Report Sequence identifies the In Out

sequence of entries on the Validation
Exception Report.
EXTRACT The EXTRACT keyword is used to define Temp

parameters creating the EP-300, 301, 302,
303 and 399 REPORTS.

FEERPTFMT Fee Transaction-Based Format (EP-710, In

720 and 240 reports).
FILEIDMOD Specify File Identification Modifier Out

character used in the unique file identifier.
FILELOC Location of input files (directory, file name, In Out Temp

DD name) to the run.
FILEOUT Identify the Output file format (VML, CTF). In Out Temp
FILETYPE Output - Specify File Type populated in the Out

header record file type field.
HISTPURGE History Purge identifies when the In Out

maintenance operations is performed.
HISTRETPD History Retention Period defines the In Out

length of time history records are retained in
number of days.
INPUTSEQ Input Sequencing option enables or In Temp

disables automatic sequencing of input files.
INTERNAL Internal Application Identifier indicates Visa In Out

internal applications using Edit Package.
ITEMCURAMT Item Currency and Amount limit definition Out

for tolerance checking.
ITFHASH ITF Hash checking enables or disables the Out

validation of the z/OS hash on each record.
LANG Identify Language-dependent tables and

set default locale-specific options.
LOCALE Locale identifier names a default system

LOCALE that can be used to supply default
country specific formats (date format,
separator’s, etc.).
MAXBATRECS Maximum number of Batch Records Out

allowed per output batch.
NETAGENT Define number of Network Agent threads In Out Temp

started when running as a service to the Edit
Package workstation.
NOSEQ The NOSEQ temporary run option indicates Temp

that the temp run option file does not
include sequence numbers and allows line
length up to 256 characters.

NUMDECSEP Number Decimal Separator specifies the In Out

character used to identify the separation of
minor units.
NUMTHOUSEP Numeric Thousands Separator specifies In Out

the character used to separate thousands
groups of digits.
OUTCHARSET Identify the Character Set used for the Out Temp
Output transaction file (ASCII or EBCDIC).
PORT TCP/IP Port number used to communicate

between a service run and the Edit Package
Workstation component.
PROFILE Configuration Profile (of run options and

thread configuration) name identifies a set
of pre-defined run control options.
REJITFLIM ITF/VTF reject limit as a percentage of Out

transactions that are in error is defined by
REJITFLIM.
REJMSGLIM Define the percentage of transactions with Out

errors allowed before terminating the run
and reporting those errors.
REPORTS Identifies Reports and report options (such In Out Temp

as archival) that are enabled/disabled.
RERUN Rerun processing option is used to identify In Out Temp

if a rerun is to occur.
RUNCURAVG Run Tolerance Amount and Currency used Out

to check a tolerance amount by currency for
a run.
RUNDATE Run Date specifies the Edit Package In Out Temp

processing date.
RUNMODE The Run Mode is identified as either TEST or In Out Temp

PROD (production).
RUNTOLER Run Tolerance checking level related to Out

RUNCURAVG is enabled or disabled.
SAVEREJECT Save Rejected transactions into a separate Out

file.
SAVERETURN Save Returned transactions into a separate In

file.
SHUTDOWN Method of Edit Service termination

(currently not used).

SOURCENAME Identify Processing Center Source Name Out

value used in output header records.
SPLITBYARD Split ITF/VTF into subfiles by account In

range.
SPLITBYBIN Split ITF/VTF by into subfiles by destination In

Identifier.
SPLITBYPID Split by ITF/VTF into subfiles by product ID. In
SPLITBYSET Split ITF/VTF into subfiles by Settlement In

Flag.
SPLITBYTC Split ITF transactions into subfiles by In

Transaction Code when transactions are in
TC format.
SPLITBYTT Split VTF transactions into subfiles by In

Transaction Code when transactions are in
VML format
SPLITINFIL The SPLITINFIL option enables split-by In

functionality and identifies the split-by
method.
SPLITCONLY Identifies Collection-Only transactions and Out

writes these transactions into a separate
Outgoing Interchange Transaction File (ITF/
VTF).
START Identify the method of Starting the service

operation used with the Edit Package
workstation (not currently used).
STOPRC Stop Processing Transaction batches after In Out Temp

receiving a return code greater than this
value.
TABLEDATE Define the Edit Package Table Effective In Out Temp

Date used when loading tables from the
repository.
TBLDATA Table Override (Data) allows Edit Package In Out Temp

table rows to be added, deleted, or replaced.
TBLKEY Table Override (Key) identifies the key to a In Out Temp

TBLDATA row to be added, deleted, or
replaced.
TIMESEP Time Separator character that separates In Out

fields of time (HH MM).

TRANRPTSEQ Transaction Report Sequence identifies the In Out

sequence of entries in the EP-700 reports
(File or ACQ/ISS ID sequence).
TRIALRUN Trial Run can be used to indicate a test run Out

that will not create an output file or update
history but perform validation.
TRNINPRT Identify Transaction codes that are included In

on Incoming Printed Reports.
TRNNOINPRT Identify Transaction codes that are Not In

included on Incoming Printed Reports.
TRNOOUTPRT Identify Transaction codes that are Not Out

included on Outgoing Printed Reports.
TRNOPASS Identify transactions excluded from output In

file on incoming run (No Pass to Output).
TRNOUTPRT Identify Transaction codes that are included Out

on Outgoing Printed Reports.
TRNPASS Identify transactions included on the output In

file of incoming run (Pass to Output).
VALERROR Identify the maximum number of validation In Out

errors reported by transaction (1 to 100).
VALIDATE Enable or disable transaction Validation In Out

edits.
WORKDIR Define a Work Directory (Windows) or In Out

dataset name prefix (z/OS) for work files
used to save transactions from client
workstations.
WRITEHEADR Activate the creation of generating header In

records on an Incoming CTF Header Record.
This information is provided for each run control option.
Format Indicates how the run control should appear in the Permanent or Temporary Run
Control Options File.
Type Indicates if the option is used during an incoming or outgoing run and if the option
can only appear in a Temporary Run Control Options File.
Value Indicates what can appear after the equal (=) sign in the Permanent or Temporary Run
Control Options File.
Default Value The value to which the run control option is preset by Visa. A valid value must be
entered if the default value is not appropriate for your processing center.

Description What the option is and how it works.
Example Shows how to use the option.
AUTOUPDT – Request Repository

Updates
AUTOUPDT allows processing centers to request for repository updates.
Format AUTOUPDT=name
Type Outgoing
Related Options None
Parameter Values Default Description

Name
name Yes Yes Automatic repository table updates is activated. The

processing center will receive the required number of delta
repository updates to bring their repository tables current.
name No The processing center will receive default number of delta

repository updates.
AUTOUPDT provides the ability to request for updates required to keep the processing center's
repository tables current.
If your repository tables are out of date, repository update transactions can be sent from Visa to
bring the tables up to date through any of the following options:
l Using the run control option AUTOUPDT
l Requesting updates through your Visa representative.
Using the run control option AUTOUPDT:
Requesting table updates automatically using the run control option AUTOUPDT includes the
following steps:
1. Client must turn on the AUTOUPDT run control option to alert Visa that they wish to use the
automatic table update feature.
2. Client must run an outgoing to provide Visa with the current status of their tables.
3. Edit Package system will determine and create the table updates required to bring client's
table up to date, based on the current version of tables at Visa and client's current table
versions.

4. Client must run an incoming to process table updates. The EP-299 Report generated must
indicate successful table update for the run.
5. Client must allocate enough space for TC 54 work files to accommodate full repository table
replacements, which may include approximately 160,000+ TC 54 records.
Example:
AUTOUPDT=Yes
BLKTRNCURAMT – Blank Transaction

Identifier Tolerance by Currency
BLKTRNCURAMT specifies all valid currencies processed by your center.
Format BLKTRNCURAMT=TC, currency, amount
Type Outgoing
Related Options BLKTRNIDTOL, FPOSTTOLER and FPOSTCURAMT

Name
TC 05 or 06 Specifies whether the edit is applicable for Purchase

Original or Credit Voucher Original transaction.
Currency Aaa Where aaa is a valid three-character alphabetic BASE II

currency code.
Note: A currency code table exists in BASE II

Clearing Data Codes to aid in converting the ISO
currency code to the alphabetic currency code.
Amount Nnn Where nnn is a 12-digit numeric amount specifying the

maximum monetary amount valid for an item, expressed as
an integer. Decimal point is implied.
Note: For clients accustomed to using

ITEMCURAMT, the check is different from
ITEMCURAMT RCO where the amount specified is a
10-digit numeric amount and no decimal point is
implied.
Once blank transaction identifier checking is activated, BLKTRNCURAMT can be used to specify all
valid BASE II currencies processed by the processing center and a threshold amount for each to be
used to determine an out of tolerance condition. Use as many BLKTRNCURAMT entries as necessary
in order to specify the currencies for tolerance checking.

Example:
BLKTRNCURAMT=05, USD, 50000
BLKTRNCURAMT=06, INR, 3000000
Test US Dollar for a maximum of 500 Dollars for Purchase Original Transactions when Transaction
Identifier field is all spaces or zeroes.
Test Indian Rupees for a maximum of 30,000 Rupees for Credit Voucher Original when Transaction
Identifier field is all spaces or zeroes.
BLKTRNIDTOLER – Blank Transaction -

Identifier Tolerance Checking
BLKTRNIDTOLER activates blank transaction identifier tolerance checking.
Format BLKTRNIDTOLER=level
Type Outgoing
Related Options BLKTRNCURAMT, FPOSTTOLER and FPOSTCURAMT

Name
N ✓ Blank Transaction ID tolerance checking will not occur.
E If the source amount exceeds the defined tolerance limit,

and if the transaction identifier is blank or zeroes, the
transaction will be rejected. Applies only to Purchase
Original and Credit Voucher Original Transactions. The error
would appear on the EP-100A Validation Exception Detail
Report.
CENTRBIN – Center BASE II CIB

CENTRBIN defines the processing center’s BASE II CIB.
Format CENTRBIN=number
Type Incoming and Outgoing
Related Options CENTRCODE and CENTRNAME


Name
Number Processing Center BASE II None Processing center’s six-digit BASE Identification Number
CIB (CIB)
The CIB must exist in the Edit Package VID table. New processing centers whose BASE II CIB is not in
the Edit Package tables must use TBLKEY and TBLDATA run control options to conduct Edit Package
testing. TBLKEY and TBLDATA entries should be removed in production systems after the center’s
BASE II CIB has been added to Edit Package tables.
This run control option has no default. Modification is required.
Example:
CENTRBIN=400001
The processing center’s BASE II CIB. Center CIB 400001 should match what is defined at the VIC.
Identify Processing Center:

The CENTRBIN (Center BASE II CIB), CENTRCODE (Center Security Code), and CENTRNAME (Center
Name) run control options are used to identify the processing center for the Edit Package and the
BASE II System.
CENTRBIN and CENTRCODE are mandatory and the values specified must be the same as those
defined with the VisaNet Interchange Center (VIC) or outgoing interchange files will be rejected by
the VIC. CENTRBIN and CENTRCODE are passed to the BASE II System on the outgoing Interchange
Transaction File (ITF) or VisaNet Transaction File (VTF).
The outgoing Edit Package run validates the CENTRBIN against the contents of the Edit Package VID
table. If the BASE II CIB is not found, that run will end.
For incoming ITFs/VTFs, the Edit Package compares the CENTRBIN and CENTRCODE provided by
BASE II to the values of these fields define by the processing center. If the values do not match, that
run will end.
CENTRCODE – Center Security Code

CENTRCODE specifies the processing center’s security code.
Format CENTRCODE=code
Related Options CENTRBIN and CENTRNAME


Name
code Valid security code None Processing center's eight-character alphanumeric Security
Code.
Contents are set at installation time. This run control option has no default. Modification is required.
Example:
CENTRCODE=EPTESTBIN
The processing center’s appropriate security code here is EPTESTBIN. Center Security Code
EPTESTBIN should match the code defined at the VIC.
CENTRNAME – Center Name

CENTRNAME defines the processing center’s name.
Format CENTRCODE=name
Related Options CENTRBIN and CENTRCODE
Note:
See CENTRBIN – Center BASE II CIB for more information on how CENTRNAME, CENTRBIN,
and CENTRCODE work with one another.

Name
name Valid center name None Processing center’s 16-character name.
The CENTRNAME name is used on Edit Package reports. The default for this run control option is all
spaces. Modification is optional.
Example:
CENTRNAME=FIRST ANYTOWN BANK
The processing center’s 16-character alphanumeric name is the argument. FIRST ANYTOWN BANK
will appear on Edit Package outgoing and incoming reports.

CHARSET – Character Set

This keyword can be used along with COUNTRY and LANG to identify the locale-specific defaults. An
alternative is to use the LOCALE keyword.
Format CHARSET=
Related Options COUNTRY, LANG and LOCALE

Name
Character set 1252, 037 None Future
The BASE II CIB must exist in the Edit Package VID table. New processing centers whose CIB is not in
the Edit Package tables must use TBLKEY and TBLDATA run control options to conduct Edit Package
testing. TBLKEY and TBLDATA entries should be removed in production systems after the center’s
BASE II CIB has been added to Edit Package tables.
Example:
CHARSET=1252
See LOCALE
COUNTRY – Country Defaults

The COUNTRY option is used along with LANG to identify the locale-specific defaults and to identify
language dependent repository tables (messages, error messages, etc.). COUNTRY names a country
from the list (below). Default locale-specific options are set based on the resulting combination. The
defaults can be replaced through the use of DATEFORMAT, DATESEP, NUMDECSEP, NUMTHOUSEP, or
TIMESEP options.
Format COUNTRY=name
Related Options LANG, DATEFORMAT, DATESEP, NUMDECSEP, NUMTHOUSEP, TIMESEP

Parameter Values Alt Default Description

Name value
Alpha Austria at Name of country that is used along with language

to identify default locale-specific attributes
(thousands separator, Date format, etc.). The
argument must be one of the valid values defined
in internal tables.
Belgium be
Brazil br
Canada ca
Denmark dk
Finland fi
France fr
Germany de
Hungary hu
Iceland is
Ireland ie
Italy it
Japan jp
Korea kr
Mexico mx
Netherlands nl
Holland nl
Norway no
Poland pl
Portugal pt
Russia ru
Slovakia sk
Spain es
Sweden se
Switzerland ch
Turkey tr


Name value
Britain gb Or GBR, UK, United Kingdom
United States us Yes Or US, USA, America
Locale-specific defaults are applied based on the identified country and language. The individual
values can be defined using DATEFORMAT, DATESEP, NUMDECSEP, NUMTHOUSEP and TIMESEP.
This run control option defaults to US (United States).
Example:
COUNTRY=US
Identify United States formatting rules.
Identify Default Format Rules Country:

The locale maintained by the host operating system is used to establish defaults for DATEFORMAT,
DATESEP, NUMDECSEP, NUMTHOUSEP, and TIMESEP. Country is used along with LANG to identify the
locale. Log message 102-I identifies the activated locale.
DATEFORMAT – Date Format

DATEFORMAT specifies how the Gregorian date is to be displayed on Edit Package reports.
Format DATEFORMAT=date
Related Options COUNTRY, DATESEP, LANG, NUMDECSEP, NUMTHOUSEP, TIMESEP

Name
date YYMMDD Specifies preference for date format used on Edit Package
Reports. The date is described as a series of numbers:
CCYYMMDD
CC = Century. The first two digits of the year (20 for 2000).
DDMMCCYY (Note: CCYY is the same as YYYY). DD = Day of month. For
example, 03 for August 3.
DDMMYY
MM = Month. For example, 08 for August.
MMDDCCYY
YY = Year. The last two digits of the year (00 for 2000).
MMDDYY
Note:

The default value is based on the system LOCALE (operating system default). The system
LOCALE can be controlled through the use of COUNTRY and LANG options.
Select Date Formatting:

Use DATEFORMAT (Date format) and DATESEP (Date separator) to select report formatting for date
variables on all Edit Package reports. A combination of the DATEFORMAT and DATESEP options can
be modified to conform to any national environment.
Example:
DATEFORMAT=YYMMDD
Report dates use a two-digit year followed by two-digit month and two-digit day of month.
DATESEP – Date Separator

DATESEP specifies the character to be used to separate the 10-character Gregorian date fields
displayed on reports.
Format DATESEP=separator
Related Options COUNTRY, DATEFORMAT, LANG, NUMDECSEP, NUMTHOUSEP, TIMESEP

Name
separator Any special character The single special character used to separate date fields
on Edit Package reports. (A blank is acceptable but
alphabetic or numeric characters such as A–Z or 0–9 are
not acceptable.)
Note:
Example:
DATESEP=.

DESTNAME – Destination Application

Name
DESTNAME defines the name of the application destined to receive an outgoing file.
Format DESTNAME=name
Type Outgoing
Note:
See CENTRBIN – Center BASE II CIB for more information on how CENTRNAME, CENTRBIN,
and CENTRCODE work together.

Name
name 12 characters BANKCARD Name placed in the header record of outgoing files.
The DESTNAME option should be used at the direction of Visa.
Example:
DESTNAME=BANKCARD
Outgoing files will place the text BANKCARD into header records (TC 90/T183 transactions).
DIRECTION – Run Outgoing or

Incoming
The DIRECTION option identifies the run as either an outgoing or incoming run.
Format DIRECTION=argument
Type Incoming, Outgoing, Utility run
Related Options


Name
Argument OUTGOING None Run is performed for outgoing files.
INCOMING Run is performed for incoming files.
REPORT Identifies a reporting run (PROFILE=EXTRACT) or utility run.
The same program is used to run an outgoing, incoming, or utility Edit Package. The DIRECTION Run
Control Option controls which mode is active.
Example:
DIRECTION=outgoing
Edit Package outgoing run is active.
DLLNAME – Name Load DLLs

The DLLNAME Run Control Option is used to name Dynamic Link Libraries used to perform parse,
rule, build, and file-manager and report tasks.
Format DLLNAME=key(logical name)
Related Options DLLPARM

Name
Key PRS or PARSER None Identify the logical name of the parser DLL. The logical name
should be one of the names identified in the dlldef
repository table. (Note: prs is an alias for parser). Format
example: DLL=prs(eparsevml).
RUL or RULE Identify the logical name of the validation rule processor
DLL. The logical name should be one of the names identified
in the dlldef repository table. (note: rul is an alias for rule).
Format example: DLL=rul(eprule).
BLD or BUILDER Identify the logical name of the output builder DLL. The
logical name should be one of the names identified in the
dlldef repository table. (note: bld is an alias for builder).
Format example: DLL=bld(epbuildvml).


Name
RPT or REPORT Identify the logical name of the report builder DLL. The
logical name should be one of the names identified in the
dlldef repository table. (note: rpt is an alias for report).
Format example: DLL=rpt(epreport).
FM or FILEMANAGER Identify the logical name of the file manager DLL. The logical
name should be one of the names identified in the dlldef
repository table. (Note: fm is an alias for file manager).
Format example: DLL=fm(epfilemgr).
This Run Control Option is used to vary the routines used to read, write and validate transaction data
through specification of the Dynamic Load Library routines based on the desired type of data to
process.
This run control option has no default.
Example:
DLLNAME=prs(eparsevml) bld(epbuildvml)
Read and write VML files.
DLLNAME Names:
Dynamic Link Libraries are defined in the repository dlldef table. A logical name is associated with the
physical name of the load element. The logical name is used as the argument to this run option.
The type of input or output is varied by changing the parser or builder DLL’s.
If multiple DLLNAME keywords are detected, the argument is appended onto the argument of the
first. The second DLLNAME may require a space as the first character of the argument. Note that the
REPLACE= keyword can be used to discard all previously encountered DLLNAME= keywords.
DLLPARM – Pass Parameter to a DLL

The DLLPARM keyword can be used to pass a parameter (or set of parameters) to a logical DLL.
Format DLLPARM=arg
Related Options


Name
See below. See sections for each None Values are dependent on the DLL. (See below.)
DLL below.
Note that the logical DLLs are identified as:
BLD or BUILDER Builder
PRS or PARSER Parser
RULE or RUL Rule processor
RPT or REPORT Reports
Example:
DLLPARM=parser(trace=dump) parser(trace=all)
Trace activity from the VML parser DLL and Blaze input.
DLLPARM Options for VML Builder

These options can be used to communicate to the VML builder by enclosing parameters within
parenthesis preceded by the word BUILDER.
Keyword Argument Description
DLLPARM=BLD(MSDOS) Create files that can be read through standard MSDOS type file
access (carriage return / line feed terminated lines). Note that
this is the default when running under windows.
DLLPARM=BLD(dd:xxx) xxx defines an output DD name.
DLLPARM=BLD(BATCHFILE) The builder will create a single file per batch (Windows only).
Used when loading a file from incoming or outgoing into the
workstation client/server environment.
Example:
DLLPARM=BLD(msdos)
Builder output files are created as MSDOS type files.

DLLPARM Options for Parser

These options can be used to communicate to the parser by enclosing parameters within parenthesis
preceded by the word PARSER.
DLLPARM=PRS(trace=all) all Write a log entry tracing each XML tag parsed. Note that
ALL is the only argument and is required.
DLLPARM=PRS(stats=size) size Count and report on minimum, maximum and average field
count and sizes per transaction.
DLLPARM=PRS(ctlrec=noerror) Errors detected on header, batch and/or trailer records are

reported but will not cause a CC=16 to be set.
DLLPARM=PRS(SINGLETRAN) Indicates transactions are validated one at a time (not in a

batch). This is used by the core server for transaction
validation.
Example:
DLLPARM=PRS(TRACE=ALL STATS=SIZE)
The VML parser will generate a log entry for each XML tag parsed and create a listing of transaction
stats at the end of the run.
DLLPARM Rule Processor Options

These options can be used with edit rules where the keyword/arguments are enclosed within
parenthesis preceded by the word RULE.
TRACE CSV Create a comma-separated-value trace file.
TRACE DUMP Create a trace file dumping input to Blaze rules.
FIELDS number Specify the number of expected fields in a trace or zero to disable field count
checking.
NOREJECT none Use this at the direction of Visa so that all transactions are treated as non-
rejects. This is used during file format conversions (CTF to VML, for example).
Example:
DLLPARM=RUL(trace=csv fields=726)
Create a comma-separated-value file and enable field-count checking looking for 726 fields.

DLLPARM Parameters
Parameters passed to the DLLs are DLL-dependent. This run control option is used to pass a string
(max size is currently 48 bytes) to a named DLL.
The syntax for the argument includes:
l DLL name immediately followed by an open parenthesis.
l The parameter value to be passed includes all characters before the close parenthesis.
l A closing parenthesis
l If a second DLLPARM keyword is detected then the argument is appended onto the
argument of the first. The second DLLPLARM may require a space as the first character of the
argument.
If multiple DLLPARM keywords are detected then the argument is appended onto the argument of
the first. The second DLLPARM may require a space as the first character of the argument. Note that
the REPLACE= keyword can be used to discard all previously encountered DLLPARM= keywords.
DUPBATCH – Duplicate Batch

Detection
DUPBATCH uses batch hashing or Center Batch ID checking methods to detect duplicate outgoing
batches.
Format DUPBATCH=level,method,days
Type Outgoing
Related Options HISTRETPD

Name
level N Disables duplicate batch checking. If N is the value used, it is not

necessary to specify the Method and Days parameters.
E Yes If an error is found, processing immediately ends and an error

message is displayed.
W If an error is found, processing continues after a warning message is

displayed.


Name
method HASH Yes Calculates a hash value for each batch stored in the Edit Package
History file.
CENTERID Performs duplicate checking against the unique values in the Batch
Center ID in the Batch Trailer record (TC 91/TT184).
days 1 to 100 5 Number of calendar days to check history. If this item is blank, a
default value will be added. For HASH, the default is to check as many
as exist in the History File. For CENTERID method, the default is one
day.
If duplicate batch checking is invoked and the Edit Package detects a duplicate batch, the option
exists to either have a warning message issued and commit the batch to the outgoing file (ITF/VTF),
or have the outgoing file rejected.
DUPBATCH selects one of two different methods to detect duplicate outgoing batches:
l HASH (Batch Hashing) detects duplicate batches using a batch hashing technique to check
against the contents of the Edit Package History File for a specified number of calendar days.
l CENTERID (Center Batch ID Checking) detects duplicate batches by checking the Center Batch
ID on the TC 91/ T184 batch trailer record.
DUPBATCH Recommendations
The HASH method is the recommended method because it is capable of detecting a greater variety
of potential processing errors. In addition, this method does not require the processing center’s
system to provide a unique TC 91/T184 Center Batch ID.
The Edit Package compares the calculated hash total to the calculated values of all batches that exist
in the History File for a specified number of days. The number of days is an optional value expressed
in calendar days. It is supplied by the processing center to determine how far back in history to check
for duplicate hash totals. If the number of day’s value is omitted, checking is done for as many
calendar days as have been saved on the History File, as specified by the HISTRETPD run control
option.
Processing centers can enhance the performance of duplicate batch checking when invoking the
HASH method by using the day’s parameter to limit the number of batches searched. If the day’s
parameter is not used, the Edit Package uses all batches in the history file up to 10,000 batches. If a
center processes 1000 batches per day, specifying 2 for the days will restrict the search to 2000
batches rather than 10,000.
CENTERID enhances processing efficiency by not calculating the hash value. To check for more than
one day of history using this method, the pre-edit software would have to create unique Center
Batch IDs across multiple processing days. Including a date in the Center Batch ID is a preferable
technique to use in order to make each ID unique.

The Center Batch ID is supplied by the processing center during pre-edit processing. It can be any
value, but it must be unique within the number of days specified by the day parameter. A batch is
considered a duplicate if the Center Batch ID exists in the History File for a previous batch within the
time period specified by the day’s parameter.
Example:
DUPBATCH=W,HASH,30
Warning messages appear on the Validation Exception Report (EP-100A) and the Log Report (EP-199)
for any batches that have an Edit Package accumulated hash total that matches a batch hash total in
the History File for the past 30 days.
DUPBATCH=E,CENTERID,10
Processing stops and an error message appears on the Validation Exception Report (EP-100A) and
the Log Report (EP-199) if a TC 91 or TT184 batch trailer record is encountered with a Batch Center ID
that matches a Center Batch ID with the History File for the past 10 days.
EXCPRPTFMT – Exception Report

Format
The EXCPRPTFMT allows you to select the exception report layout
Format EXCPRPTFMT=layout
Related Options EXCPRPTSEQ

Name
layout DUMP Yes Prints an unformatted image of the transaction.
FORMAT Prints a formatted report, showing the name of each field in the
transaction and its contents.
Validation Exception Detail Reports (EP–100A and EP–200A) list items rejected by the Edit Package.
EXCPRPTFMT allows you to select the report layout.
DUMP prints an unformatted report in the same image as the transactions. This format is similar to
the layout used in Release 3 Validation Exception reports.
FORMAT prints a formatted report to show the name of each field in the transaction and its contents.
This format is similar to the layout used in EP–204A Returned Item and formatted transaction-based
reports.

Example:
EXCPRPTFMT=DUMP
The Validation Exception Detail Report will be unformatted.
EXCPRPTFMT=FORMAT
The report will be formatted.
Validation Exception Report Options:

The default values for both EXCPRPTSEQ and EXCPRPTFMT creates a report sequenced in the order
received in the file using an unformatted ruler line display.
FORMAT versions of the report allow users to easily identify transactions that are in error without
reference to transaction layout documentation. Reports sequenced by ACQ/ISS ID will allow centers
processing for multiple ACQ/ISS IDs to route rejected item reports to those responsible for correction
and resubmission of the items.
EXCPRPTSEQ – Exception Report

Sequence
The EXCPRPTSEQ allows selection of the exception report sequence.
Format EXCPRPTFMT=seq
Related Options EXCPRPTFMT

Name
seq FILE Yes Prints rejected transactions in the input file sequence.
BIN Prints rejected transactions by ACQ/ISS ID sequence.
Validation Exception Detail Reports list items rejected by the Edit Package. EXCPRPTSEQ allows
selection of the report sequence.
FILE causes rejected items to be reported in the sequence that they occur within the file. ACQ/ISS ID
causes transactions to be reported in source identifier sequence during the outgoing run and in
destination identifier sequence during the incoming run. The reported Source/destination identifier
appears in the heading of the report and a page break will occur each time the Source/destination
identifier changes.

Example:
EXCPRPTSEQ=FILE
The Validation Exception Detail Report will be sequenced by file
EXCPRPTSEQ=BIN
The report will be sequenced by SRC/DEST IDs.
EXTRACT – Extract and Reporting

The EXTRACT keyword is used to identify a request to create an EP-300, EP-301, EP-302, EP-303, and
EP-399 report/extract.
Edit Package History File Report
Format EXTRACT=HISTORY,RUN=direction,START=ccyymmdd,END=ccyymmdd, LEVEL=lvl
Type Temporary

Name
EXTRACT HISTORY Identify the extract request.
direction IN, OUT or BOTH BOTH Incoming, Outgoing or BOTH
start Date or the word ALL ALL CCYYMMDD format date or the word ALL to select all
available history data.
end Date N/A CCYYMMDD format date or no value to indicate through

the end of the file.
level BATCH, FLIE, or RUN BATCH BATCH will print batch, file and run information. FIE will
print file and run information. RUN prints only run
information.

VID, ARDEF, and Value Extract Report
Format EXTRACT=TABLE,NAME=table-id,FUNCTION=func,START=start-range, END=end-

range
Type Temporary

Name
table-id See list VID, ARDEF, or any table identifier from the LIST
function.
function REPORT, FILE, DUMP or LIST REPORT will produce a formatted report. FILE
LIST generates a sequential file of values. DUMP creates an
unformatted report. LIST will generate a list of
available table identifiers.
start Start key This is an optional keyword specifying the starting

range for a value table. Starting Range is valid only for
VID and ARDEF tables. If starting range is omitted,
reporting at the beginning of the specified table.
end End key This is an optional keyword specifying the ending

range for a value table. End Range is valid only for VID
and ARDEF tables. If end range is omitted, reporting
continues until the end of the table.
level BATCH, FLIE, or RUN BATCH BATCH will print batch, file and run information. FIE
will print file and run information. RUN prints only run
information.
Note:
Use the TABLEDATE run control option to indicate a specific table date.
Example:
EXTRACT=TABLE,NAME=BIN,FUNCTION=FILE
Extract the entire VID table into a file.

LOG File Report
Format EXTRACT=LOG,START=ccyymmdd,END=ccyymmdd,LOGLOC=
Type Temporary

Name
EXTRACT LOG Identify the LOG report.
start Date or the word ALL ALL CCYYMMDD format date or the word ALL to select all
available log reports. If the starting date is not present,
reporting starts at the beginning of the log files. The
date is assumed to be in local time.
end Date or the word ALL CCYYMMDD format date. If ending date is not present,
reporting continues until the end of the logs. The date is
assumed to be in local time.
logloc Dsname Location (directory) and generic name used to identify

all logs. For example, if logs are in the \ep40\log
directory, \ep40\log\run.log.g* identifies log files.
Example:
EXTRACT=LOG,START=20100801,LOGLOC=\EP40\LOG\RUN.LOG.G*
List all logs starting with 01 August 2010.
Note that if this control statement exceeds 71 characters, the NOSEQ run control option must be
used before the statement.
LOGLOC Argument Syntax for z/OS

The LOGLOC keyword argument can use special symbols when running under the z/OS Operating
system. An argument name is enclosed in single quotes. A name is made up of nodes where each
node has a maximum length of 8 characters. Nodes are separated by a period. The dataset name has
a maximum length of 44 characters. The following special characters may be used to identify a
generic file.

* A single asterisk by itself indicates that either a qualifier or one or more characters within a
qualifier can occupy that position. An asterisk can precede or follow a set of characters.
** A double asterisk indicates that zero or more qualifiers can occupy that position. A double
asterisk cannot precede or follow any characters; it must be preceded or followed by either a
period or a blank.
% A single percent sign by itself indicates that exactly one alphanumeric or national character
can occupy that position.
%%... One to either percent signs can be specified in each qualifier.
Example:
EXTRACT=LOG,START=20100801,LOGLOC= 'TEN.RUN.LOG.*'
List all logs with a dataset name starting with TEN.RUN.LOG and created on or after 1 August, 2010.
LOGLOC Argument Syntax for Windows

The argument to LOGLOC used when running under the Windows Operating system includes the
following special symbols. An argument name is a fully qualified location where the data set name
may include the following special characters may be used to identify a generic file:
* An asterisk indicates that zero or more characters may be present in this position
? A question mark is used to indicate any character maybe present in this position.
FEERPTFMT – Fee Transaction-Based

Format
FEERPTFMT specifies how incoming TC 10 and TC 20 reports are to be produced.
Format FEERPTFMT=content
Type Incoming
Related Options TRNINPRT
Note:
See BASE II Clearing: Edit Package (Release 4) Reports for more information and examples of
Fee Transaction-Based Reports.


Name
content S Yes Separate reports containing Visa-originated fee transactions and non-
Visa-originated transactions are produced.
C Combined reports containing Visa-originated and non-Visa-originated

fee transactions are produced.
V Reports containing only Visa-originated fee transactions are produced.
N Reports containing only non-Visa-originated fee transactions are

produced.
FEERPTFMT is used to control the content of the TC 10, TT115, TT116, TT215, and TC 20, TT117,
TT118, TT217 Fee Collection/Funds Disbursement transaction-based reports (EP–710 and EP–720),
and summary (EP–240).
The EP–710 and EP–720 reports will not be produced unless TRNINPRT=10 and TRNINPRT=20 (or
TRNINPRT=115,116,117,118) run control options are specified.
Example:
FEERPTFMT=S
Two separate summary reports are created by the Edit Package: the non-Visa-originated Fee
Collection/Funds Disbursement Summary (EP-204N), and the Visa-originated Fee Collection/Funds
Disbursement Summary (EP-240V)
FEERPTFMT=C
TRNINPRT=10
TRNINPRT20
The EP-240C Fee Collection/Funds Disbursement, EP-710C (containing Visa and non-Visa-originated
Fee collections), and the EP720C (containing Visa and non-Visa fund disbursement) reports will be
produced.
FILEIDMOD – Specify File

Identification Modifier
FILEIDMOD specifies a character included in the unique file ID.
Format FILEIDMOD=identifier
Type Outgoing


Name
identifier P File identification modifier character is specified.
T File identification modifier character is specified for a test

run.
Blank Yes File identification modifier will be the same as the value
specified by RUNMODE.
One character A to Y 0 One alphabetic or numeric character to be included in the

to 9 BASE II Unique File ID.
FILEIDMOD is used to specify a single character included in the BASE II Unique File ID field on the TC
90 or T183 File Header Record during an outgoing run. The BASE II Unique File ID is generated by the
Edit Package for use in history processing by the EAS and BASE II. The Unique File ID is in positions
79 through 108 of the TC 90 File Header Record. The FILEIDMOD modifier character is in position 94.
For VML files the Unique File ID is the argument to X781.
If FILEIDMOD is left blank, position 94 and/or X781 will be based on the value specified in
RUNMODE. If RUNMODE=PROD (production) is used, P appears in position 94 or <X781)P</X781>;
if RUNMODE=TEST is used, T appears in position 94 or <X781)P</X781>;.
FILEIDMOD gives the processing center the ability to modify the Unique File ID so that files created
in their data center can be identified. By specifying different FILEIDMOD values for separate runs
scheduled during the processing day, files can be readily recognized by the Unique File ID modifier.
The Unique File ID generated during the outgoing run appears on Edit Package reports EP–120F, EP–
220, EP–221B, EP–221D and EP–221E. It also appears on the EAS/DEX history display and in the BASE
II history file display at Visa.
Example:
FILEIDMOD=
The RUNMODE is used to populate Unique File ID.
FILELOC – File Location

The FILELOC Run Control Option is used to identify a location of origin for input files. The argument
names a directory (windows) or a generic file name (z/OS).
Format FILELOC=data set name with while cards, data set name or DD name
Related Options INPUTSEQ, FILEOUT

Parameter Name Values Default Description
wild cards See below None A generic name can be specified that resolves to one or
more input files. The name fully qualifies the location
directory and identifies included files using wild card
characters. The wild card characters are system-dependent.
(See below.)
data set Name A fully qualified dataset name that identifies an input file.
DD name dd:name A name prefixed by a lower-case “dd:” (two ‘d’ letters

followed by a colon). When this format is used then the JCL
includes a DD statement with the name indicated in the
argument. The dataset is associated with the name in the
JCL. Note that when this format is used that the
INPUTSEQ= Run Control Option does not apply.
Input can be taken from a named file through a DD statement located in a z/OS JCL or by naming a
generic file or a windows directory.
There is no default for FILELOC and if multiple FILELOC statements are found each will be treated as a
separate input source. The REPLACE= keyword can be used to discard all previously encountered
FILELOC= keywords.
Example Windows:
INPUTSEQ=Y
FILELOC=\ep40\incoming\GC*
Sequence all files starting with GC found in the \ep40\incoming Windows directory.
Example: z/OS:
INPUTSEQ=Y
FILELOC=’TEN.BUILD004.GC**’
Sequence all files starting with TEN.BUILD004.GC.
FILELOC Argument Syntax for z/OS

The argument to FLIELOC used when running under the z/OS Operating system includes the
following special symbols. An argument name is enclosed in single quotes. A name is made up of
nodes where each node has a maximum length of 8 characters. Nodes are separated by a period. The
dataset name has a maximum length of 44 characters. The following special characters may be used
to identify a generic file.

* A single asterisk by itself indicates that either a qualifier or one or more characters within a qualifier
can occupy that position. An asterisk can precede or follow a set of characters.
** A double asterisk indicates that zero or more qualifiers can occupy that position. A double asterisk
cannot precede or follow any characters; it must be preceded or followed by either a period or a
blank.
% A single percent sign by itself indicates that exactly one alphanumeric or national character can
occupy that position.
%%... One to either percent signs can be specified in each qualifier.
FILELOC Argument Syntax for Windows

The argument to FILELOC used when running under the Windows Operating system includes the
following special symbols. An argument name is a fully qualified location where the data set name
may include the following special characters and be used to identify a generic file.
* An asterisk indicates that zero or more characters may be present in this position
? A question mark is used to indicate any character maybe present in this position.
FILEOUT – File Output Format

The FILEOUT Run Control Option is used to specify the output file format.
Format FILEOUT=format
Related Options FILELOC, DLLNAME and DLLPARM

Name
format CTF Create a TC format output
ITF Create a TC format output
TC Yes TC format output, ITF generated when running OUTGOING
VML VML variable length record file
VTF Same as VTF

The output format is used by the builder generating the output files. Builders are provided for TC,
VML and workstation formats. The DLLNAME= Run Control Option is used to indicate which builder
is routed the FILEOUT= parameter.
Example:
FILEOUT=VML
DLLNAME=BLD(epbuildvml) PRS(eparsetc)
Read a TC input file and create a VML output file.
FILETYPE – Specify File Type

The FILETYPE Run Control Option is used to populate the file header file type (TC 90 or T183).
Format FILETYPE=type
Type Outgoing
FILETYPE is used to specify the file type in the TC 90/T183 File Header Record of the outgoing
ITF/VTF for BASE II Customized Delivery processing.
FILETYPE should only be used at processing centers where Visa has requested that it be used. Visa
will provide the values. Take care in specifying values for FILETYPE because the Edit Package does not
check for valid values.
FPOSTCURAMT – Force-Post
Tolerance by Currency
FPOSTCURAMT specifies all valid currencies processed by your center.
Format FPOSTCURAMT=TC, currency, amount
Type Outgoing
Related Options FPOSTTOLER, BLKTRNIDTOL and BLKTRNCURAMT


Name
TC 05 or 06 Specifies whether the edit is applicable for Purchase

Original or Credit Voucher Original transaction.
Currency Aaa Where aaa is a valid three-character alphabetic BASE II

currency code.
Note: A currency code table exists in BASE II

Clearing Data Codes to aid in converting the ISO
currency code to the alphabetic currency code.
Amount Nnn Where nnn is a 12-digit numeric amount specifying the

maximum monetary amount valid for an item, expressed as
an integer. Decimal point is implied.
Note: For clients accustomed to using

ITEMCURAMT, the check is different from
ITEMCURAMT RCO where the amount specified is a
10-digit numeric amount and no decimal point is
implied.
Once force-post tolerance checking is activated, FPOSTCURAMT can be used to specify all valid BASE
II currencies processed by the processing center and a threshold amount for each to be used to
determine an out of tolerance condition. Use as many FPOSTCURAMT entries as necessary in order
to specify the currencies for tolerance checking.
Example:
FPOSTCURAMT=05, USD, 50000
FPOSTCURAMT=06, INR, 3000000
Test US Dollar for a maximum of 500 Dollars for Purchase Original Transactions when Authorization
Source Code is "9", "E" or "L".
Test Indian Rupees for a maximum of 30,000 Rupees for Credit Voucher Original Transactions when
Authorization Source Code is "9", "E" or "L".
FPOSTTOLER – Force-Post Tolerance

Checking
FPOSTTOLER activates force-post tolerance checking.
Format FPOSTTOLER=level
Type Outgoing
Related Options FPOSTTOLER, BLKTRNIDTOL and BLKTRNCURAMT


Name
N ✓ Force-post tolerance checking will not occur.
E If the source amount exceeds the defined tolerance limit,

and if the authorization source code of the transaction is
"9", "E", or "L" the transaction will be rejected. Applies only
to Purchase Original and Credit Voucher Original
Transactions. The error would appear on the EP-100A
Validation Exception Detail Report.
HISTPURGE – History Maintenance

Processing
HISTPURGE allows processing centers to control when History File maintenance processing occurs.
Format HISTPURGE=run
Related Options HISTRETPD

Name
run IN Yes History maintenance processing will occur during the incoming run.
OUT History maintenance processing will occur during the outgoing run.
Centers that process small outgoing files and large incoming files may take advantage of HISTPURGE
to switch maintenance processing to the outgoing run. Processors with large outgoing runs can use
IN which allows history maintenance to occur during the incoming run.
Example:
HISTPURGE=N
HISTRETPD=10
Allows history maintenance to occur during the incoming run and keep the history records for 10
days.

HISTRETPD – History Retention

Period
HISTRETPD specifies the number of days that history information is retained.
Format HISTRETPD=days
Related Options HISTPURGE

Name
days Any number 10 to 100 10 Retain History File data for a minimum of 10 days to a
maximum of 100 days.
HISTRETPD specifies the number of calendar days that run, file, and batch data (history information)
is retained on the Edit Package History File before it is deleted during purge processing. Up to 100
days of history can be retained on the History File.
Storage of history information is required by the Edit Package in order to perform duplicate file and
batch checking. It is also required for reruns of files previously processed by the Edit Package.
Increasing the retention period increases the amount of disk space required for the History Files and
may also increase processing time. The following examples illustrate the amount of disk space
required to store run, file, and batch history (based on one file per day containing one batch for both
outgoing and incoming processing):
l Default of 10 calendar days requires 6K of disk space
l Maximum of 100 calendar days requires 60K of disk space
See Edit Package File Layouts for complete details on DASD requirements for the History File.
Example:
HISTRETPD=90
Run, file, and batch history data is retained for 90 calendar days.
HISTPURGE=N
HISTRETPD=10
Allows history maintenance to occur during the incoming run and key the history records for 10
days.

INPUTSEQ – Input Sequence

This option can be used to enable or disable the automatic sequencing of incoming input files based
on file contents. The feature enables continuation files to be sequenced automatically.
Format INPUTSEQ=flag
Type Incoming
Related Options FILELOC

Name
flag Y Yes Perform automatic sequencing.
N Do not perform automatic sequencing.
If input file(s) are identified through the FILELOC run control option and not using concatenated DD
names, the INPUTSEQ option is used to enable or disable file sequencing. Files are sequenced by
date, start-batch, and end-batch number. Any files identified in the FILELOC option that refer to
concatenated files are considered a single file and are not sequenced individually.
This run control option defaults to enable (Y).
Example:
INPUTSEQ=Y
FILELOC=\ep40\incoming\GC*
Sequence all files starting with GC found in the \ep40\incoming directory.
INPUTSEQ=Y
FILELOC=dd:EPIN01
FILELOC=dd:EPIN02
Sequence the EPIN01 and EPIN02 where the physical files are named in the JCL.

INTERNAL – Internal Application

Indenter
INTERNAL identifies Visa applications that run the Edit Package.
Format INTERNAL=identifier

Name
identifier Blank Yes Processing center is not a Visa internal application.
N Where n is one alphabetic or numeric character reserved for use by Visa

internal applications.
INTERNAL is used to identify Visa internal applications to the Edit Package. Special edit rules apply to
Visa internal applications that run the Edit Package to prepare data for collection by BASE II. If the
value is left blank, this specifies that the Edit Package is being used at a client’s processing center.
Example:
INTERNAL=
Your processing center is not a Visa internal application.
ITEMCURAMT – Item Tolerance by

Currency
ITEMCURAMT specifies all valid currencies processed by your center.
Format ITEMCURAMT=currency,amount
Type Outgoing
Related Options RUNTOLER, and RUNCURAVG


Name
currency Blank Yes Item-level tolerance checking will not occur.
aaa Where aaa is a valid three-character alphabetic BASE II currency code.

Note: A currency Code table exists in BASE II Clearing and Settlement
Data Codes to aid in converting the ISO currency code to the
alphabetic currency code.
amount nnn Where nnn is a 10-digit numeric amount specifying the maximum
monetary amount valid for an item, expressed as an integer. (Any
amount of 0 through 9999999999 is acceptable).
Once item-level tolerance checking is activated, ITEMCURAMT is used to specify all valid BASE II
currencies processed by the processing center and a threshold amount for each to be used to
determine an out of tolerance condition. Use as many ITEMCURAMT entries as necessary in order to
specify the currencies for tolerance checking.
Example:
ITEMCURAMT=EUR,100000
Test Euro currencies for a max of 100,000 Euros.
ITEMTOLER – Item-Level Tolerance

Checking
ITEMTOLER activates item-level tolerance checking.
Format ITEMTOLER=level, method
Type Outgoing
Related Options ITEMCURAMT, RUNTOLER, and RUNCURAVG

Name
N Yes Item-level tolerance checking will not occur.
E If the source amount exceeds the defined tolerance limit or if the

transaction currency has not been specified, the transaction is rejected,
and the error appears on the EP–100A Validation Exception Detail
Report.

ITFHASH – ITF Data Checking

ITFHASH helps to identify where problems occurred when processing errors result in corrupted
outgoing interchange files.
Format ITFHASH=name

Name
alpha Y Yes z/OS default generates and will check hash values on each record.
N Do not check incoming file hash values and do not generate hash
values on outgoing files. This is the default when running under
Windows.
Create and check hash values.
Example:
ITFHASH=N
Ignore hash values on input and do not generate on output.
Data Checking:
The hashing allows a corrupted record to be isolated.
LANG – Language Defaults

The LANG option is used along with COUNTRY to identify the locale-specific defaults and to identify
language dependent repository tables (messages, error messages, etc.). LANG names a language
from the list (below). Default locale-specific options are set based on the resulting combination. The
defaults can be replaced through the use of DATEFORMAT, DATESEP, NUMDECSEP, NUMTHOUSEP, or
TIMESEP options.
Format LANG=name
Related Options COUNTRY, DATEFORMAT, DATESEP, NUMDECSEP, NUMTHOUSEP, TIMESEP


Name Value
name Danish da Name of language used with country name to identify

default locale-specific attributes (thousands separator,
Date format, etc.). The argument must be one of the valid
values defined in internal tables.
Dutch nl
English en Yes
Finish fi
French fr
German de
Greek el
Hungarian hu
Italian it
Japanese ja
Norwegian no
Polish pl
Portuguese pt
Russian ru
Slovak sk
Spanish es
Swedish sv
Turkish tr
Locale-specific defaults are applied based on the identified country and language. The individual
values can be defined using DATEFORMAT, DATESEP, NUMDECSEP, NUMTHOUSEP and TIMESEP.
This run control option defaults to English.
Example:
LANG=English
Identify English when setting default formatting rules.

Identify Default Format Rules Language:

The locale maintained by the host operating system is used to establish defaults for DATEFORMAT,
DATESEP, NUMDECSEP, NUMTHOUSEP, and TIMESEP. Language is used along with COUNTRY to
identify the locale. Log message 102-I identifies the activated locale.
MAXBATRECS – Number of Records in

a Batch
MAXBATRECS specifies the maximum number of CTF records included in a CTF batch or the
maximum transactions in a VML batch.
Format MAXBATRECS=count
Type Outgoing
Related Options

Name
count 100 to 3300 999 The highest number of records allowed per outgoing batch. Must
be a value between 100 and 3300 when creating a CTF/ITF.
MAXBATRECS specifies the maximum number of transaction component records (TCRs) that will be
included in a batch on the Center Transaction File (CTF) generated by the processing centers pre-edit
software. From 100 through 3300 records may be specified.
When creating VML files, MAXBATRECS specifies the maximum number of transactions included in a
batch from the centers pre-edit software.
If a batch is encountered that contains more TCRs than specified by MAXBATRECS, an error message
is generated and the run is aborted.
Note:
The TC 91/T184 Batch Trailer Record is included in the TCR count for the batch.
Processing efficiency is enhanced by using larger batches. The Edit Package does not re-batch data
when creating the ITF/VTF. To use larger batches the system which creates the CTF/VML must
generate the larger batches and MAXBATRECS must be set to match the largest possible batch.
Example:
MAXBATRECS=1000
When the above run control option is specified, the maximum number of transaction component
records (TCRs) written to a single batch on an outgoing ITF are 1,000.

MESSAGE – Write a Message on the

Log
The MESSAGE can be used to send a user message to the log. It is used by adding a MESSAGE run
option to the temporary options file.
Format MESSAGE=text

Name
alpha Any None Write a message to the log.
A one-line message (message number 122) is added to the log near the end of initialization:
No default value
Example:
MESSAGE=Boy this Edit Package 4 sure runs fast
The message is added to the log for the current run.
Message Text:
Text cannot exceed 80 characters and should include only printable characters.
NETAGENT – Network Agent Threads

NETAGENT option identifies the number of Agent threads started by the network libraries.
Format NETAGENT=number


Name
number 0 through 90 0 Define the number of execution threads available to handle

network connections from workstation(s).
The network interface handles connections from workstations by passing control to a network-agent
thread. The network-agent thread handles communication between the Edit Service and workstation.
The number of network agents available is identified by this run option.
This run control option defaults to zero.
Example:
NETAGENT=6
Run six network-agent threads.
Network Agent Threads:

The argument to the NETAGENT option depends on the number of workstations that are to be
handled by the Edit Service. A network agent is required for each workstation plus one additional
network-agent thread.
NOSEQ – No Sequence Numbers

NOSEQ is a control statement used to identify a temporary run option file that does not include
sequence numbers. It is not a run option and is not listed on the output listing.
Format NOSEQ
Type Temporary Run Control Option File

Name
None
Create and check hash values.
Example:
NOSEQ
Sequence numbers not present, use the entire input line for Temp Run Options.

NUMDECSEP – Number Decimal

Separator
NUMDECSEP specifies the decimal character.
Format NUMDECSEP=separator
Related Options COUNTRY, DATEFORMAT, DATESEP, LANG, NUMTHOUSEP, TIMESEP

Name
alphabetic or numeric characters such as A–Z or 0–9 are
not acceptable.)
Note:
Example:
NUMDECSEP=.
Decimal points on Edit Package reports are represented by a period (.) between the numbers.
Therefore, the number one and ten one-hundredths appears as 1.10.
NUMTHOUSEP – Number Thousands

Separator
NUMTHOUSEP specifies the thousands separator character.
Format NUMTHOUSEP=separator
Related Options COUNTRY, DATEFORMAT, DATESEP, LANG, NUMDECSEP, TIMESEP


Name
alphabetic or numeric characters such as A–Z or 0–9 is
not acceptable.)
Note:
Example:
NUMTHOUSEP=,
Thousands on Edit Package reports are represented by a comma (,) between the numbers. Therefore,
the number one thousand appears as 1,000.
OUTCHARSET – Outgoing Output File

Character Set
OUTCHARSET identifies the character set used when creating the output file during an outgoing run.
Format OUTCHARSET=set
Type Outgoing
Related Options

Name
set none Yes Use ASCII when running under Windows and EBCDIC when running
under z/OS.
ASCII Outgoing output is created as an ASCII file.
EBCDIC Outgoing output is created as an EBCDIC file.
Example:
OUTCHARSET=EBCDIC

Create the output file as an EBCDIC file during an outgoing run. The default would create an ASCII
file if running under Windows.
PORT – TCP/IP Port

PORT identifies the communication port used to communicate between the Edit Service and
Workstation.
Format PORT=number

Name
number 0 through 90 0 Define the number of execution threads available to handle

network connections from workstation(s).
The network interface handles connections from workstations by passing control to a network-agent
thread. The network-agent thread handles communication between the Edit Service and workstation.
The number of network agents available is identified by this run option.
Example:
PORT=49990
Communicate between Edit Package workstations and the validation service through port 49990.
Port:
When the run time option refers to a TCP/IP port, it is used by the Edit Service to listen for TCP
connections.

PROFILE – Configuration Profile

PROFILE is used to identify a named set of options defined in the repository. Options include
definitions of execution threads, DLLs to be used, and run options overrides to the permanent default
options used when a profile is invoked.
Format PROFILE=name
Profile Values Default Description

Argument
Name Any 8-character (or less) outgoingtc Name the repository profile table entry that will be used
name defined in the to initialize the Edit Package run.
repository profile table.
The PROFILE run option refers to an entry in the profile repository table.
Example:
PROFILE=outgoingtc
Run the Edit Package as an Outgoing run with CTF input file(s) creating an ITF output file.
PROFILE Parameter Set Defaults

The repository profile table associates a named set of threads with a named set of parameters. The
named set of parameters is a set of run option overrides to the permanent options. The named set of
threads identifies execution threads and associates a DLL with each thread. The following profiles are
defined by default.
Parameter Usage Description

Name
incomingtc Incoming Run Incoming Edit Package run with ITF input file creating a CTF output file.
outgoingtc Outgoing Run Outgoing Edit Package run with CTF input file creating an ITF output file.
incomingvml Incoming Run Incoming Edit Package run with VTF input file creating a VML output file.
outgoingvml Outgoing Run Outgoing Edit Package run with VML input file creating a VTF output
file.
ctf2wtf Workstation Import Workstation import of a CTF file.

Parameter Usage Description

Name
Itf2wtf Workstation Import Workstation import of an ITF file.
Vml2wtf Workstation Import Workstation import of a VML file.
_clientctl Workstaiton Core Core service that communicates with the workstation Edit Package.
_utilctl Utility Utility
REJITFLIM – ITF/VTF Error Threshold

REJITFLIM specifies the ITF/VTF maximum percentage of transactions with edit errors that are
allowed before canceling the output file.
Format REJITFLIM=percent
Type Outgoing
Related Options REJMSGLIM

Name
percent 0 to 100 100 No ITF/VTF will be created if the percentage of rejected transactions
exceeds the percentage specified for REJITFLIM.
Any valid numeric value from 0 to 100.
Zero (0)% indicates that a single error will suppress generation of the
output.
100% indicates that there is no limit and the outgoing file will be
generated, regardless of the number of transaction errors found.
REJITFLIM specifies the percentage of transaction edit errors (expressed as a percentage of total
transactions for the file) that may not be exceeded if an ITF/VTF is to be produced.
This option allows the processing center to prevent submission of an outgoing file into VisaNet when
a large percentage of the transactions on the outgoing Center Transaction File (CTF or VML) have
been rejected.
The REJITFLIM is checked after processing all transactions on the CTF. If the number of transactions in
error exceeds the REJITFLIM limit:
l Only the Validation Exception (EP–100A, EP–100B and EP–100C) and Processing Log (EP–199)
Reports are produced.
l A message is logged indicating that the REJITFLIM was exceeded.
l No outgoing ITF is created.

Note:
Since REJITFLIM is closely related to REJMSGLIM, see REJMSGLIM – Error Report Threshold for
an example.
REJMSGLIM – Error Reporting

Threshold
REJMSGLIM specifies the maximum percentage of transactions with edit errors that are allowed
before terminating the run and reporting the errors found to that point.
Format REJMSGLIM=percent
Type Outgoing
Related Options REJITFLIM

Name
percent 1 to 100 100 No further errors will be reported and processing will terminate if the
percentage of rejected transactions exceeds the percentage specified
for REJMSGLIM.
Any valid numeric value from 1 to 100.
One (1)% ensures that at least some error messages will be reported
when errors occur.
100% indicates that there is no limit and all transactions in error will be
reports.
REJMSGLIM specifies the percentage of transaction errors (expressed as a percentage of total

transactions processed so far) that may occur before generation of error messages and further
processing is terminated. The default is 100.
This option prevents the flooding of the outgoing Validation Exception Detail Report (EP–100A) with
redundant messages and avoids lengthy processing when a large number of errors occur.
To prevent exceeding the limit prematurely, the REJMSGLIM is not tested for the first 200
transactions. After that, the percentage of rejected transactions is recalculating after each transaction
from the CTF is processed. If the percentage of rejected transactions exceeds the percentage of
rejects specified by REJMSGLIM, a final error message is displayed to indicate that the limit has been
reached, and:
l Processing of remaining transactions is bypassed
l No outgoing ITF is created

l Reports generated reflect information about transactions processed up until the threshold
has been met.
l A message is logged indicating that the REJMSGLIM was exceeded
A fixed minimum of 200 transactions is set internally to prevent exceeding the limit prematurely.
Note:
This run control option is usually set to a higher value than REJITFLIM since it results in
bypassing remaining transactions which means that the outgoing ITF/VTF limit would never
be reached.
Example:
REJITFLIM=0
REJMSGLIM=1
An ITF/VTF is created only if no errors are detected.
Processing stops if 1% of the records on the input have errors.
If less than 1% of the records are in error, all reports are produced.
If 1% of the records are in error, only the EP-100A Validation Exception Detail Report is produced.
REJITFLIM=10
REJMSGLIM=100
An ITF/VTF is created only if less than 10% of the records on the input have errors.
Processing stops if 100% of the records on the input have errors.
REJITFLIM=100
REJMSGLIM=10
An ITF/VTF is created only if less than 100% of the records on the input have errors. However, a value
in the REJITFLIM higher than the REJMSGLIM is not recommended since the REJMSGLIM value takes
precedence over REJITFLIM.
Processing stops if 10% of the records on the input have errors. No output created.

REPORTS – Generate Summary

Reports
REPORT identifies summary reports that will be created.
Format REPORT=rptopt
Type Temporary, Incoming and Outgoing

Name
rptopt 100 Yes Validation Exception Report
110 Yes Outgoing Interchange Summary
111 Yes Outgoing Interchange
120 Yes Outgoing ITF Summary
199 Yes Outgoing Processing Log
200 Yes Validation Exception
204 Yes BASE-II Returned Item
206 Yes CRS Returned Item
210 Yes Incoming Interchange Summary
211 Yes Incoming Interchange
220 Yes Collected Reconciliation Summary
221 Yes Collected Batch Acknowledgments
230 Yes Interchange Transaction File Distribution
240 Yes Fee Summary Report
299 Yes Incoming Processing Log
999 Yes Index of Reports
AR(n) Yes Archive reports for n days (Currently, only supported when running
under Windows.)
Example:
REPORTS= AR(5) EP100 EP110 EP111
Create the test EP-100, EP-110 and EP-111 series of reports. Reports are archived for five days.

Summary Report Create:

The REPORTS run option is used to identify reports to be created. Note that when EP-100 is
specified, all of the EP-100 reports (A, B, C, etc.) are created
The banner page is created with the EP-100A report. If EP100 is not specified in the REPORTS run
control option, no banner page is created.
Archival:
The archival option will cause reports to be copied to an archive directory (/reports/ar) under a BASE
II CIB directory when running under windows. The format of the name: Dyymmdd.Rnnnn.Thhmmss.
Note that Archival is a Windows-only function (not supported on z/OS).
RERUN – ITF/VTF Error Threshold

RERUN indicates that a rerun is to occur.
Format RERUN=run
Type Temporary, Incoming, and Outgoing
Related Options RUNMODE and RUNDATE

Name
run blank Yes A rerun will not occur.
ALL Outgoing Only – An entire day’s outgoing processing is to be run again.
nnn Outgoing Only – Processing for the processing day will start over from
run number nnn.
Y Incoming Only – All files in the run that have been previously processed.
N Incoming Only – No files in the run have been previously processed.
If this temporary run control options is not specified, the default is for the processing run not to be
rerun.
RERUN - Outgoing Processing

The combination of the run number and the Edit Package processing date identifies the run to be
reprocessed. The run number is a three-digit numeric field previously assigned by the Edit Package

during the original run. The Edit Package verifies that the run number is present in the History File for
the processing date.
Within a given day, the outgoing Edit Package allows previous runs to be rerun. Edit Package history
data is cleared out from the point where the rerun begins based on the RUNMODE value.
Subsequent runs are treated as original runs and do not require the use of the rerun run control
option record.
When the ALL parameter is used, all outgoing history records for the Edit Package processing date in
effect are deleted from the History File without regard to RUNMODE. The beginning batch file and
run number are set to 1.
Example:
RERUN=001
Run 001, for the current system date, is reprocessed when the outgoing Edit Package is executed. If
the RUNDATE run control option is also supplied, run 001 for the specified run date is reprocessed.
RERUN - Incoming Processing

Reruns are allowed for any file that was previously processed by the Edit Package and still exists in
the History File. If the rerun flag is set to N (default) and the ITF header record matches the History
File, then the run will abort unless the file is a nonfinancial file.
If the Central Processing Date (CPD) in the ITF header record is not the current system date, then the
RUNDATE run control option must be used in order to specify the correct CPD.
Example:
RERUN=Y
RUNDATE=100801
If the above run control options are specified, incoming file for 1 August 2010 will be processed. The
file(s) used as input to the incoming Edit Package run are only processed if the header matches a
record in the History File indicating that the file was previously processed through the incoming Edit
Package.

RUNCURAVG – Run Tolerance Amount

and Currency
RUNCURAVG is used to specify a valid currency and average amount used for out of tolerance
condition.
Format RUNCURAVG=currency,amount
Type Outgoing
Related Options ITEMCURAMT and RUNTOLER
Note:
See RUNTOLER – Run Tolerance Checking for more information on how RUNTOLER and
RUNCURAMT work with one another.

Name
currency Blank Yes Run-level tolerance checking will not occur.
aaa Where aaa is a valid three-character alphabetic BASE II currency code.

NOTE: A Currency Code table exists in BASE II Clearing and Settlement
Data Codes to help convert the ISO currency code to the alphabetic
currency code.
amount nnn Where nnn is a 10-digit numeric amount specifying the maximum
monetary amount valid for an item, expressed as an integer. (Any
amount of 0 through 9999999999 is acceptable.)
Once run-level tolerance checking is activated, RUNCURAVG is used to specify a valid BASE II
currency and an average threshold amount to be used for determining an out of tolerance condition.
The default is no run-level tolerance checking will occur.
Note:
If processing interchange in multiple currencies, the Edit Package uses the BASE II currency
rates contained in the currency conversion file (CURCNV) to perform any necessary
conversions to the specified currency in the RUNCURAVG option record. If the rates are not
available in the currency conversion file, transactions with currencies other than those
specified by RUNCURAVG are not included in the calculated average. Contact your Visa
representative to subscribe to the Currency Rates Distribution Service.

RUNDATE – Run Date

REPORT defines the Edit Package processing date.
Format RUNDATE=date
Related Options TABLEDATE, RUNMODE, and RERUN

Name
date nnn Yes Outgoing Only – The Edit Package processing date to be used to create
an outgoing ITF/VML, where nnn is an eight-digit numeric field in
CCYYMMDD format.
CCYY = Four digit year, for example 2011
MM = Month between 1 and 12 (i.e. 08 = August)
DD = Day of month in the range of 1 to 31 (dependent on month).
Incoming Only – Specifies the TC 90 File Header record CPD in order to
verify that the correct file is being processed.
For outgoing runs, RUNDATE defines the Edit Package processing date overriding the system date
default. For incoming runs, RUNDATE can only be used for rerun processing. It must match the
Central Processing Date on the TC 90/T183 header record of the output being processed.
The run control option should only be used for rerun processing or testing.
Note:
The specified run date cannot be greater than the current date for production runs or more
than 44 days prior to the current date. When RUNMODE=TEST, the run date can be greater
than the current date to allow future dated testing.
If the TABLEDATE run control option is specified, it will always be used as the table effective
date. If TABLEDATE is not specified then the RUNDATE in the Temporary Run Control Options
file (or run-time parameters) will be used as the table effective date.
Example:
RUNDATE=20110801
Edit Package processing date is overridden to 1 August 2011.

RUNMODE – Run Type

RUNMODE indicates the type of data (production or test) the interchange contains.
Format RUNMODE=type
Type Temporary, Incoming, and Outgoing
Related Options RUNDATE

Name
type PROD Yes Processed ITF/VTF contains production data
TEST Processed ITF/VTF contains test data
RUNMODE indicates whether the interchange to be processed contains production or test data.
PROD—in outgoing Edit Package runs the:
l Interchange Transaction File (ITF) contains spaces in the Test Option Field of the File Header
Record (TC 90) or
l If the Test Option Field X775 of the T183 is not present in a VTF file
This allows it to be processed only by the production system at the VIC. For incoming Edit Package
runs, only ITF/VTFs with spaces in the Test Option field (or X775 not present) are accepted by the Edit
Package when RUNMODE=PROD is specified.
TEST—in outgoing Edit Package runs:
l The ITF contains the string “TEST” in the Test Option Field of the File Header Record (TC 90)
or
l The X775 Test Option Field of the T183 contains “TEST”
This allows it to be processed only by the Visa Certification Management System (VCMS) at the VIC.
For incoming Edit Package runs, only ITF/VTFs with the string “TEST” in the Test Option field are
accepted by the Edit Package.
Example:
RUNMODE=TEST
During outgoing Edit Package runs, the ITF/VTF is flagged so it is processed by the BASE II
certification system.
During incoming Edit Package runs, only ITF/VTFs marked as test are accepted.

RUNTOLER – Run Tolerance Checking

RUNTOLER activates run-level tolerance checking.
Format RUNTOLER=level
Type Outgoing
Related Options ITEMCURAMT and RUNCURAVG

Name
level N Yes Run-level tolerance checking does not occur.
E Run-level tolerance checking is activated. If an out-of-tolerance condition

is found, an error message appears on the EP-199 log and processing
stops.
W Run-level tolerance checking is activated. If an out-of-tolerance condition

is found, a warning message appears on the EP-199 log and processing
continues.
Run-level tolerance checking provides processing centers with the ability to identify daily runs where
financial transactions exceed a tolerance limit prior to the collection and settlement of the
Interchange Transaction File (ITF) by the BASE II System.
Financial tolerance limits may be set at the run-level for the outgoing ITF using the RUNCURAVG run
control option. The amount must be specified in any single valid BASE II currency and have an
average transaction amount.
When RUNTOLER is selected, the system adds the value of each monetary transaction (using USD
BUY Currency Rates supplied by Visa) to a running total. At the end of the run, the total in USD is
converted to a single currency specified in RUNCURAVG using BUY Currency Rates and the system
divides the accumulated total by the number of financial transactions to determine the average
amount of each transaction. If the average exceeds the specified threshold as specified by the
RUNCURAVG, the Edit Package either provides a warning message or rejects the outgoing ITF,
depending on the selected criteria.
The processing center can switch off run tolerance checking with RUNTOLER in the Temporary Run
Control Options File without having to delete the RUNCURAVG entry previously supplied. This allows
the processing center to turn run tolerance checking on or off without having to re-enter or delete
the valid currency and associated tolerance amount.
Example:
RUNTOLER=W
RUNCURAVG=CAD, 0000999999
Total of all financial transactions are converted to Canadian dollars.

The average transaction amount is determined and compared to the threshold of 999,999 Canadian
dollars. If the average exceeds the specified threshold of the RUNCURAVG entry, a warning message
appears on the Log Report (EP-199) and the output is created.
RUNTOLER=E
RUNCURAVG=USD, 0000999999
Total of all financial transactions are converted to U.S. dollars.
The average transaction amount is determined and compared to the threshold of 999,999 U.S.
dollars. If the average exceeds the specified threshold of the RUNCURAVG entry, a warning message
appears on the Log Report (EP-199) and the output is not created.
SAVEREJECT – Save File Rejects

SAVEREJECT writes rejected transactions to a separate file.
Format SAVEREJECT=method
Type Outgoing
Related Options SAVERETURN

Name
method T Yes Rejected transactions found during an outgoing run are written to a
separate file in transaction format.
R Rejected transactions found during an outgoing run are written to a

separate file in reject format. Reject format contains TCR 9 data.
N Rejected transactions found during an outgoing run are not written to a

separate file.
SAVEREJECT writes transactions rejected by the outgoing Edit Package to a separate file. This allows
correction of erroneous fields in the transaction without re-keying the entire transaction.
If T is used, the outgoing interchange transactions rejected by the Edit Package are saved in Center
Transaction (CTF) or VML format and contain TC 91 (or T184) batch trailer and TC 92 (or T185) file
trailer records. A TC 90 (T183) header record is also supplied, if the processing center has provided a
TC 90 (T183) header record on the original outgoing CTF/VML.
If “R” is used, then the rejected transactions are saved in Save Reject TCR 9 format. This format
contains the reject reason codes shown on the Validation Exception Detail Report (EP–100A). A
maximum of 10 reject codes can be reported for each transaction. See Edit Package File Layouts for
Edit Package TCR 9 record format.

When SAVEREJECT=N is used, the outgoing interchange transactions rejected by the Edit Package
are not saved and the rejected transactions are not in the outgoing Interchange Transaction File (ITF/
VTF). However, rejected transactions will appear on the EP–100A Validation Exception Detail Report,
whether the SAVEREJECT run control option was set to T, R, or N.
Example:
SAVEREJECT=T
Transactions rejected by the outgoing Edit Package are written to a separate file in CTF/VML format.
SAVEREJECT=R
Transactions rejected by the outgoing Edit Package are written to a separate file in Save Reject (TCR 9
data) format.
SAVERETURN – Save Returned

Transactions
SAVERETURN writes returned transactions to a separate file.
Format SAVERETURN=method
Type Incoming
Related Options SAVEREJECT

Name
method R Yes Returned transactions from the VIC are written to a separate file in the
standard CTF/VML format containing TC 01, 02, and 03 (if CTF format)
transactions. Each transaction contains TCR 9 data.
T Returned transactions from the VIC are written to a separate file in the
standard CTF/VML format containing the original transactions. The TCR
9 data is not written to the file.
N Returned transactions are not written to a separate file.
SAVERETURN writes transactions returned by the VisaNet Interchange Center (VIC) on incoming
interchange to a separate file as returned item transactions (TC 01, TC 02, or TC 03 when original is
CTF format) or as original transactions.
The separate file is in Center Transaction File (CTF) or VML format and contains batch trailer (TC 91 or
T184) and file trailer records (T92 or T185). A header record (TC 90 or T183) is also supplied, if the
processing center has switched on the WRITEHEADR run control option.

If “R” is used, the only change to the records written to the file is that the hash bytes in positions
three and four of the Interchange Transaction File (ITF) are removed. The file contains the TC 01, TC
02, and TC 03 returned item transactions when the input is CTF format. Each transaction contains a
TCR 9 data with information about the original transaction and the returned item reason codes. See
BASE II Clearing Interchange Formats, TC 01 to TC 49 and BASE II Clearing Interchange Formats, TC 50
to TC 92, for Edit Package TCR 9 returned item format.
It “T” is used, the original transaction code from the TCR 9 data or the TC 01, TC 02, and TC 03 (input
in CTF format) return item transaction is restored to positions one and two in the file created. The
TCR 9 data from the returned item transaction is not written to the file. The processing center can
process the file in an internal correction facility. To assist in the correction of returned items, returned
item reason codes for each transaction are reported on the EP–204A and EP–206A reports.
If “N” is used, returned items are not saved in a separate file. Returned items are written to the
CTF/VML based on the TRNPASS and TRNOPASS run control options. To ensure that returned items
are written to the CTF/VML when SAVERETURN=N is used, specify TRNPASS=01, TRNPASS=02, and
TRNPASS=03. If the returned items are not saved in a separate file and are not passed on to the CTF,
specify TRNINPRT=01, TRNINPRT=02, and TRNINPRT=03 to ensure that the returned items are
printed.
Note:
TRNPASS is not valid for returned items when SAVERETURN is set to R or T.
Check the TRNPASS/TRNOPASS and TRNINPRT/TRNNOINPRT run control options for all transactions
in the incoming interchange to determine if the default options are appropriate.
Example:
SAVERETURN=R
Transactions returned by the VIC on incoming interchange are written to a separate file in standard
CTF/VML format. If input is CTF then the output contains TC 01, 02 and 03 transactions.
SAVERETURN=T
Transactions returned by the VIC on incoming interchange are written to a separate file in CTF/VML
format containing original transactions.

SHUTDOWN – Service Termination

Event
The SHUTDOWN run option defines the method used by the Edit Service to identify a termination
event. This option is currently not in use.
Format SHUTDOWN=name

Name
Name oncommand oncommand Edit Service remains active until a ‘shutdown’ command is
received from a workstation.
onparseend Edit Service will terminate when the parser detects an end-of-
file.
Example:
SHUTDOWN=onparseend
Terminate the Edit Service at the end-of-file detected by the parser.
Shutdown:
The Edit Service can identify the need to terminate in one of two ways: either at the end of the input
files (batch mode) or when a workstation sends a ‘shutdown’ command.
SOURCENAME – Identify Processing

Center Source
The SOURCENAME defines the file source name value.
Format SOURCENAME=name
Type Outgoing
Related Options CENTRBIN and FILEIDMOD


Name
name aaa Blank Where aaa is a 12-character Visa-defined name that is included on the
TC 90/T183 File Header record of the outgoing ITF/VTF. This is used to
identify the file source.
SOURCENAME defines the 12–character file source name. The value used for SOURCENAME must
match values entered in VisaNet configuration tables at the VisaNet Interchange Center (VIC). Leave
SOURCENAME blank, if a value has not been specified for your center by Visa.
During the outgoing run the SOURCENAME value is moved by the Edit Package to the source name
field in the TC 90/T183 File Header record. SOURCENAME is also used by the Edit Package in
constructing the BASE II Unique File ID field in the TC 90/T183 File Header record.
If SOURCENAME is left blank, the Edit Package uses the processing center BASE II CIB value
(CENTRBIN) plus six blanks to fill in the 12–character source name field in the TC 90/T183 header
record and to construct the BASE II Unique File ID.
Example:
SOURCENAME=
The Edit Package uses the processing center BASE II CIB value entered in CENTRBIN. It also adds six
blank spaces.
SPLITBYARD – Split ITF/VTF by

Account Range
The SPLITBYARD defines a CTF/VML sub file and account ranges within that sub file.
Format SPLITBYARD=subfile,low,high
Type Incoming
Related Options SPLITBYBIN, SPLITBYSET, SPLITBYTT, SPLITBYTC, and SPLITINFIL

Name
Subfile 2 to 25 A two-digit numeric with values of 02 through 25

specifying the file subfile number.
low Start account number Starting account number from 9 to 16 digits.
high End account number Ending account number from 9 to 16 digits.

An incoming Interchange Transaction File (ITF) or Visa Markup Transaction File (VTF) may be split into
separate and distinct output files (Center Transaction Files (CTF) or VML). Up to 25 separate incoming
disk files (subfiles) may be created.
SPLITBYARD is used to define a CTF/VML subfile and to specify the account ranges to be included in
the subfile.
Requirements for this option are:
l Only one account range can be specified on each option record.
l To specify an additional account range for the same subfile, use another SPLITBYARD option
record defining the same subfile and listing the additional account range.
l Use as many SPLITBYARD records as necessary to identify all accounts to be written to
subfiles 02 through 25.
l Account ranges may not overlap.
l Any account number not specified in subfile 02 through 25 has its transactions written to
subfile 01.
l Account numbers can be from 9 to 16 digits in length.
l Any transaction that does not contain an account number or contains an account number
that is outside of a specified range is written to subfile 01.
Note:
Since SPLITBYARD is closely related to SPLITINFIL, examples are provided with SPLITINFIL
option.
SPLITBYBIN – Split ITF/VTF by

Destination Identifier
The SPLITBYBIN defines a CTF/VML subfile and destination identifiers with that subfile.
Format SPLITBYBIN=subfile,Acq/Iss ID{,ID,ID,ID}
Type Incoming
Related Options SPLITBYARD, SPLITBYSET, SPLITBYTT, SPLITBYTC, and SPLITINFIL


Name
Subfile 2 to 25 A two-digit numeric with values of 02 through 25 specifying the

file subfile number.
ID Any valid One or more valid six-digit Acq/Iss Identifier(s). When there is
ACQ/ISS ID more than one Acq/Iss Identifier, each Identifier is separated by a
comma.
Up to eight Acq/Iss IDs can be specified on each option record.
SPLITBYBIN is used to define a CTF/VML subfile and to specify the destination identifier to be
included in the subfile.
l Up to eight identifiers (IDs) can be specified on each option record.
l The destination identifier is the issuing identifier for original, re-presentment, and reversal
transactions and the acquiring identifier for chargeback and chargeback reversal transactions.
l To specify additional identifiers for the same subfile, use another SPLITBYBIN option record
defining the same subfile and listing the additional IDs.
l Use as many SPLITBYBIN records as necessary to identify all IDs to be written to subfiles 02
through 25.
l Destination Identifiers may not be specified more than once.
l Any ACQ/ISS Identifier not specified in subfile 02 through 25 has its transactions written to
subfile 01.
Note:
Since SPLITBYBIN is closely related to SPLITINFIL, examples are provided with SPLITINFIL
option.

SPLITBYPID—Split ITF/VTF by Product

ID
The SPLITBYPID defines a CTF/VML subfile and product ID within that subfile.
Format SPLITBYPID=subfile,type{,type,type,type...}
Type Incoming
Related Options SPLITBYARD, SPLITBYBIN, SPLITBYSET, SPLITBYTT, SPLITBYTC, and SPLITINFIL
Parameter Name Values Default Description

type Any valid product One or more valid one or two character length
ID product IDs.
When more than one product ID exists, they are
separated by a comma.
Up to 14 product ID types can be specified on each
option.
SPLITBYPID is used to define a CTF/VML subfile and to specify the product ID(s) to be included in the
subfile. Requirements for this option are:
l Up to 14 product IDs can be specified on each option record.
l To specify additional product ID for the same subfile, use another SPLITBYPID option record
defining the same subfile and listing the additional product IDs.
l Use as many SPLITBYPID records as necessary to identify all product IDs to be written to
l A product ID type may not be specified more than once.
l Any product ID not specified in subfile 02 through 25 has its transactions written to subfile
01.
l The product ID that should be used in SPLITBYPID processing should be product ID from
Draft TCR5 (not ARDEF product ID).
Example:
SPLITINFIL=P

SPLITBYPID=02,J1,F^,S^, S1,S2,S3
In this example if draft product is equal 'J1', 'F', 'S', 'S1', 'S2' or 'S3', these transactions will be written
to subfile 2 (EPOUT02).
Important:
Edit Package does not report all of the possible errors in the RCO at one single time. The user
should read the first error reported and then do a rerun. For example, the configured invalid
product IDs will not be reported at one single time. Instead, Edit Package flags an error on
the first invalid value.
SPLITBYSET – Split ITF/VTF by

Settlement Flag
The SPLITBYSET defines a CTF/VML subfile and settlement flags within that subfile.
Format SPLITBYSET=subfile,setlflag{,setlflag,setlfag..}
Type Incoming
Related Options SPLITBYARD, SPLITBYBIN, SPLITBYTT, SPLITBYTC, and SPLITINFIL

Name
Subfile 2 to 25 A two-digit numeric with values of 02 through 25 specifying the

file subfile number.
setlflag Any valid flag Up to five settlement flags.
SPLITBYSET is used to define a CTF/VML subfile and to specify the settlement flag to be included in
the subfile.
l Up to 5 settlement flags can be specified on each option record.
l To specify additional settlement flags for the same subfile, use another SPLITBYSET option
record defining the same subfile and listing the additional settlement flags.
l Use as many SPLITBYSET records as necessary to identify all settlement flags to be written to

l A settlement flag may not be specified more than once.

l Any settlement flag not specified in subfile 02 through 25 has its transactions written to
subfile 01.
Note:
Since SPLITBYPID is closely related to SPLITINFIL, examples are provided with SPLITINFIL
option.
SPLITBYTC – Split ITF/VTF by CTF

Transaction
The SPLITBYTC defines a CTF/VML subfile and CTF transaction within that subfile.
Format SPLITBYTC=subfile,trancode{,trancode,trancode…}
Type Incoming
Related Options SPLITBYARD, SPLITBYBIN, SPLITBYSET, SPLITBYTT, and SPLITINFIL

Name

trancode Any valid incoming CTF One or more valid two-digit transaction code(s). When
transaction code more than one transaction code exists, they are separated
by a comma.
Up to 14 transaction codes can be specified on each option
record.
An additional value can be supplied for draft data
transactions to separate originals from re-presentments: O
indicates originals and R indicates re-presentments.
SPLITBYTC is used to define a CTF/VML subfile and to specify the CTF transaction code to be
l Up to 14 CTF transaction codes can be specified on each option record.
l To specify additional CTF transaction codes for the same subfile, use another SPLITBYTC
option record defining the same subfile and listing the additional CTF transaction codes.

l Use as many SPLITBYTC records as necessary to identify all CTF transaction codes to be
written to subfiles 02 through 25.
l No CTF transaction code may be specified more than once.
l Any CTF transaction code not specified in subfile 02 through 25 has its transactions written to
subfile 01.
When specifying draft data transactions (TC 05, 06, 07, 15, 16, 17, 25, 26, 27, 35, 36, and 37) for
selection, an additional value of O (original) or R (re-presentment) can be supplied to further split
these transactions by usage code. For example, if specifying that a subfile is to contain TC 05, TC 06,
and TC 07 transactions, the processing center can specify that the subfile should only contain
originals by listing TC 05O, TC 06O, and TC 07O. All TC 05, TC 06, and TC 07 transactions that are re-
presentments will be written either to the default subfile 01 or they can be written to another subfile
by specifying another SPLITBYTC option.
With the introduction of BASE II Dispute Financial, draft transactions corresponding to Dispute
Financial can be further split by using an additional value of D. For example, if specifying that a
subfile is to contain TC 05, TC 06, and TC 07 transactions, the processing center can specify that the
subfile should only contain Dispute Financial transactions by listing TC 05D, TC 06D, and TC 07D.
Also, the splitting of TC 33 Multipurpose Message transactions is now possible into BASE II Dispute
Financial Status Advice and other TC 33 advices. The Dispute Financial Status Advice transactions can
be split with a value of V and the non-Dispute advices can be split with a value of N.
Note:
A transaction must be passed to the CTF/VML before it will appear on the subfile. Refer to
the default pass options for the specified TC to determine if the TRNPASS override is
required.
Since SPLITBYTC is closely related to SPLITINFIL, examples are provided with SPLITINFIL
option.
SPLITBYTT – Split ITF/VTF by VML

Transaction
The SPLITBYTT defines a CTF/VML subfile and VML transaction within that subfile.
Format SPLITBYTT=subfile,trancode{,trancode,trancode…}
Type Incoming
Related Options SPLITBYARD, SPLITBYBIN, SPLITBYSET, SPLITBYTC, and SPLITINFIL


Name

trancode Any valid incoming CTF One or more valid three-digit transaction code(s). When
transaction code more than one transaction code exists, they are separated
by a comma.
Up to 14 transaction codes can be specified on each
option record.
SPLITBYTT is used to define a CTF/VML subfile and to specify the VML transaction code to be
l Up to 14 VML transaction codes can be specified on each option record.
l To specify additional VML transaction codes for the same subfile, use another SPLITBYTT
option record defining the same subfile and listing the additional VML transaction codes.
l Use as many SPLITBYTT records as necessary to identify all VML transaction codes to be
written to subfiles 02 through 25.
l No VML transaction code may be specified more than once.
l Any VML transaction code not specified in subfile 02 through 25 has its transactions written
to subfile 01.
Note:
A transaction must be passed to the CTF/VML before it will appear on the subfile. Refer to
the default pass options for the specified transaction code to determine if the TRNPASS
override is required.
Since SPLITBYTT is closely related to SPLITINFIL, examples are provided with SPLITINFIL
option.

SPLITINFIL – Split ITF/VTF Into

Multiple Files
The SPLITINFIL indicates the way an ITF/VTF will be split.
Format SPLITINFIL=method
Type Incoming
Related Options SPLITBYARD, SPLITBYBIN, SPLITBYSET, SPLITBYPID, SPLITBYTT, and SPLITBYTC

Name
method N Yes Files are not split. All transactions are written to CTF/VML subfile 01.
A Splits ITF/VTF by account range
B Splits ITF/VTF by ACQ/ISS ID
P Splits ITF/VTF by product ID
S Splits ITF/VTF by settlement flag
T Splits ITF/VTF by transaction code
SPLITINFIL is used to indicate the way in which the incoming file is to be split. Before the SPLITBYARD,
SPLITBYBIN, SPLITBYPID, SPLITBYSET, SPLITBYTC or SPLITBYTT options are activated for a run.
SPLITINFIL must be turned on to a value other than N. Since only one parameter can be specified
with SPLITINFIL, for example, SPLITINFIL=A, only one SPLITBY criterion can be activated for an
incoming Edit Package run (note that SPLITBYTC and SPLITBYTT are treated as the same option).
SPLITINFIL allows the split to be changed at any time without the need to delete selection criteria
entries that have already been defined by SPLITBYARD, SPLITBYBIN, SPLITBYPID, SPLITBYSET,
SPLITBYTC or SPLITBYTT options. The edit criteria for this option are:
l If N, all incoming transactions will be written to one CTF/VTF.
l If A, data will be written to multiple CTF/VTF’s based on account ranges. SPLITBYARD must be
used to specify account ranges.
l If B, data will be written to multiple CTFs based on ACQ/ISS Identifiers. SPLITBYBIN must be
used to specify ACQ/ISS IDs.
l If P, data will be written to multiple CTFs based on product ID. SPLITBYPID must be used to
specify product ID(s).

l If S, data will be written to multiple CTFs based on settlement flags. SPLITBYSET must be used
to specify settlement flags.
l If T, data will be written to multiple CTFs based on transaction codes. SPLITBYTC must be
used to specify transaction codes.
SPLITINFIL=N Example:
SPLITINFIL=N
SPLITBYARD=2,401500000,401500999
SPLITBYBIN=02,410500
SPLITBYPID=02,J1,F^,S^,S1,S2
SPLITBYSET=02,8
SPLITBYTC=02,05
SPLITBYTT=02,102
The CTF/VTF will not be split. This example shows the SPLITINFIL=N can be used to turn off splitting
of the output without the need to delete selection criteria already defined.
SPLITINFIL=A Example:
SPLITINFIL=A
SPLITBYARD=2,401500000,401500999
SPLITBYBIN=02,410500
SPLITBYPID=02,J1,F^,S^,S1,S2
SPLITBYSET=02,8
SPLITBYTC=02,05
SPLITBYTT=02,102
Splitting of the CTF/VTF by the SPLITBYARD criterion is activated by using SPLITINFIL=A. If other
selection criterion is defined as in the first example, it does not need to be deleted.
Transactions within account range 401500000 THROUGH 401500999 ARE WRITTEN TO SUBFILE 02. Al
other transactions outside the specified range are written to the default subfile 01.
SPLITINFIL=S Example:
SPLITINFIL=S
SPLITBYSET=02,8
National Net Settlement Service transactions will be written to subfile-02. All other transactions,
including International Settlement Service transactions, will be written to subfile 1 by default.

SPLITCONLY – Write Collection-Only

Transactions Into a Separate Outgoing
File
The SPLITCONLY identifies collection-only transactions in the input file and writes these transactions
into a separate outgoing interchange file.
Format SPLITCONLY=argument
Type Outgoing
Related Options FILETYPE

Name
Argument Y Yes Identifies and writes collection-only transactions into a separate

outgoing interchange file.
N* Collection-only will not be written into a separate outgoing interchange

file.
Important:
Authorization from Visa is required to turn off SPLITCONLY.
In certain regions (e.g. CEMEA/AP), Visa has mandated that all domestic original ‘on-us’ Visa point-
of-sale (POS) transactions be submitted to VisaNet on a daily basis. Clients must submit all “on–us”
settled transactions as collection only transactions
Run control option (SPLITCONLY) has been established with a default value of Y. When
SPLITCONLY=Y and if there are collection-only transactions in the CTF or VML input file, the
following processes are activated.
SPLITCONLY - Outgoing Interchange File Split

The outgoing process will split the accepted Interchange Transactions File (ITF) or Visa Interchanges
File (VTF) into two separate files. The first output file will contain financial and non-financial
transactions excluding collection only transactions and the second output file will contain collection
only transactions. Each file will have a separate unique file id.
The collection-only split ITF file will have a different unique file ID (file name) EP currently builds the
unique file ID as nnnnnn0yyyymmddMrrff00 for ITF. For example: E/P FILE ID:
400552020091005P010100 Where: nnnnnn is CIB # 0 is a constant -- always zero yyyymmdd - run
date M - is normally equal to the run mode (P for prod) and T for Test; there are some processors
that may have multiple data centers and may opt to use the FILEIDMOD (file id modifier) run control

option which will replace the run mode rr - run number ff - file number 00 - is a constant 00 - always
zero
The collection-only file unique-file ID will be the same as the other file with the exception that file
number will be 02 and the trailing constant 00 will instead be the characters CO. The file number can
be 02 because currently for an outgoing run there is never more than one file per run. For example,
400552020091005P0102CO
Each of the two output ITF files will start with batch number 1. The Edit Package History file will be
updated with information for the two ITF files created. This will enable reconciliation of Batch
Acknowledgments (TC 44).
SPLITCONLY - CONLY File Type

File type ‘CONLY’ has been defined to identify collection-only transactions. The first output file will
contain financial and non-financial transactions excluding collection-only transactions with file type
of ‘UNDIF’ in the file header (TC 90, TCR 0, positions 74-78 and positions 109-113). The second
output file will contain collection-only transactions with file type of ‘CONLY’ in the file header (TC 90,
TCR 0, positions 74-78 and positions 109-113). In addition, the Destination Name (TC 90, TCR 0,
positions 126-137) will contain a value of BCACO.
Edit Package for Windows (Release 4) will use the file type ‘CONLY’ to populate the pull-key for
inclusion in the FTF header file that is required when sending compressed files to EAS.
SPLITCONLY - Collection-Only Reports

Collection-only transaction counts and amounts are segregated from other transactions on all
outgoing Edit Package summary reports such as the EP-110B, EP-110C, EP-110E, EP-110F and
EP-120F.
Outgoing Interchange Summary by Currency Code reports (EP-111C, EP-111E) which totals the
financial transactions types by currency codes will not include collection-only transactions.
Outgoing Validation Exception reports (EP-100A, EP-100B, EP-100C) which list transactions found in
error will include collection-only.
Incoming Batch Acknowledgment reports (EP-220, EP-221B, EP-221D, EP-221E) will support the
reporting of two outgoing files and the corresponding batch acknowledgments.

STOPRC – Stop If Return Code High

The STOPRC run option is used to control the maximum return code that will cause the Edit Package
to stop processing.
Format STOPRC=number

Name
number 0–999999 8 A value that is used to identify a maximum return code that is
accepted by the Edit Package.
If a value greater then the value identified in the SOTPRC option is detected then processing of
batches will terminate.
Example:
STOPRC=24
The Edit Package will attempt to process all batches (the maximum return code set is 16).
START – Service Initialize Event

Definition
The START run option defines the method used to start the Edit Service. This option is currently not
in use.
Format START=name

Name
Name Oncommand oncommand Edit Service will start after receiving a workstation command.
oninit Edit Service starts when the control function is started.

Example:
START=ONINIT
Start the edit service when the run is initialized.
TABLEDATE – Effective Date for Table

Values
TABLEDATE is the effective date used by the Edit Package.
Format TABLEDATE=date
Related Options RUNDATE, RUNMODE, and RETURN

Name
date nnn Yes The effective date to be used for loading Edit Package tables, where nnn
is an eight-digit numeric field in the CCYYMMDD format.
CCYY = Four digit year, for example 2011
MM = Month, as in 08 for August
DD = Day of the month, as in 01 for August 1.
TABLEDATE is the effective date used by the Edit Package to establish which table entries to use
during processing. This option forces the Edit Package to use edits that it would otherwise not select.
During outgoing runs, the default is the system date or RUNDATE, if specified. During incoming runs
the default is one day less than the CPD of the ITF/VTF header.
This run control option should only be used when testing BASE II modifications against future date
edits. The use of this option for production data may result in an increase in returned items from the
VIC.
Note:
TABLEDATE will always be used as the table effective date, but if TABLEDATE is not entered
then the RUNDATE in the Temporary Run Control Options File will be used. If neither
TABLEDATE nor RUNDATE are available, the computer system date will be used during
outgoing runs and one day before the CPD of the ITF/VTF header during incoming runs.

Example:
TABLEDATE=20110801
The Edit Package uses table effective date 20110801, which is 01 August 2011.
TBLKEY AND TBLDATA – TABLE

OVERRIDE
Note:
TBLDATA must follow TBLKEY and must be listed consecutively in the Temporary Options file
to work correctly. TBLKEY must be listed first.
TBLKEY – TABLE KEY

TBLKEY specifies the key value of a table entry in the VID, ARDEF or other table. This value must
match the TBLDATAnn entry.
Format TBLKEYnn=tablename,key
Related Options TBLDATAnn

Name
tablename Visa-specified values None One to eight character names identifying the table that
will be over written.
key Visa-specified values None Key value of the table entry in the target table.

TBLDATA – TABLE DATA

TBLDATA specifies edit table information to be used to override entries in a repository table (VID,
ARDEF, etc.). A maximum of 25 TBLDATA statements may be present. Each TBLDATAnn must have a
matching TBLKEYnn statement and the TBLKEYnn statement must precede the TBLDATAnn statement.
Format TBLDATAnn=data
Related Options TBLKEYnn

Name
Data Visa-specified values None Table information to override entries in a repository table.
The option can be used to override, delete or add entries.
VID and ARDEF Table Overrides

Table overrides are used to temporarily override one record in the Edit Package tables. These run
control options do not change the file copy of any table. They simply override the file copy of the
record that would be effective for the current run. Table overrides can be used to add, change, or
delete a table entry.
These run control options must satisfy the following criteria:
Both key and data table overrides must be specified together. They cannot be used individually.
The TBLKEYnn entry must occur before the TBLDATAnn entry.
There is a maximum of 25 pairs of TBKLEYnn/TBLDATAnn entries for an Edit Package run. The nn in
the table override keyword is used for sequencing, for example, the first in a series of 25 pairs would
be TBLKEY01/TBLDATA01.
Any table can be override with these run control options. However, Visa recommends that you only
use these run control options to override the VID and ARDEF tables. All other table overrides should
be done only with information supplied by Visa support staff.
Note:
In the following examples, the symbol ^ indicates a blank space.

Table Override Example
VID Table Override Part 1
Position Field Length Field Name Description
01–06 06 Keyword Must be TBLKEY.
Note: For the IBM PC platforms, the

keyword and equal sign are not required.
Values are entered directly into the screen.
07–08 02 Keyword Sequence Number Must be a value of 01 through 25.

This should be the sequence number of the run
control option. There is a maximum of 25 pairs of
table override run control options. This value must
match the sequence number supplied in the TBLDATA
run control option.
09 01 Keyword Delimiter Must be an equal sign (=).
10–11 02 Table Type Must be VL.
12–17 06 Table Mnemonic Must be BINTBL.
18 01 Table Delimiter Must be a comma (,).
19–24 06 ACQ/ISS ID Must be a full six-digit Acquiring/Issuing Identifier.
25–80 56 Unused Must be spaces.
01–07 07 Keyword Must be TBLDATA.


match the sequence number supplied in the TBLKEY
run control option.

11 01 Action Indicator Blank – Add or change record

D – Delete record
24–29 06 BASE II CIB Must be a full six-digit BASE II CIB that identifies the
processing center specified in columns 28–33 on the
previous TBLKEY run control option record.
30 01 Region Must be one of the following:

1 US
2 Canada
3 Europe
4 Asia-Pacific
5 Latin America and Carribean
6 CEMEA
Note: This value should represent the

region for the ACQ/ISS ID specified in
columns 28–33 on the previous TBLKEY run
control option record, not the processing
BASE II CIB.
31–32 02 Country Must be a valid two-digit country code.
33 01 VID Type Must be one of the following:

F - Full Service
I - Issuer Only
M - Merchant Only
N - Nonfinancial Only
O - On Behalf Of (OBO)
P - Processor
S - SMS Financial entity
V - Visa Internal entity
34 01 Participation Flag Blank - Not participating

A - GSA IGOTS
B - Airline
35 01 Visa Direct Blank - Not participating

Y - Participating

36 01 TIF Bypass Flag Valid values:

Y = bypass TIF
Space = do not bypass TIF
37 01 Multinational Merchant This field will contain an indicator to identify that the
Acceptance enrolled Multinational Merchant Acceptance
acquiring identifier may qualify for domestic
processing.
The valid values are:
Y = (Acquirer is participating)
Space = (Acquirer is not participating)
38 01 Domestic OCT Program This field indicates whether the Acquiring Identifier
Information Form (PIF) supports the origination of domestic OCTs other than
Money Transfer OCTs:
Y = Acquiring Identifier can originate domestic Non-
Money Transfer OCTs
Space = Acquiring Identifier cannot originate
domestic Non-Money Transfer OCTs
39 01 Cross-Border OCT Program This field indicates whether the Acquiring Identifier
Information Form (PIF) support the origination of Cross-Border OCTs other
than Money Transfer OCTs:
Y = Acquiring Identifier can originate Cross-Border
Non-Money Transfer OCTs
Space = Acquiring Identifier cannot originate Cross-
Border Non-Money Transfer OCTs
40 01 OCT GEO Blocking This field indicates type of OCT GEO Blocking:
l D – Domestic Blocking
l X – Cross-Border Blocking
l B – Block all OCT
l Space* – No Blocking (Default)

ARDEF Table Override Part 1
01–06 06 Keyword Must be TBLKEY.


match the sequence number supplied in the TBLDATA
run control option.
10–11 02 Table Type Must be VL.
12–17 06 Table Mnemonic Must be ACTRNG.
18 01 Table Delimiter Must be a comma (,).
19–27 09 High Account Number Must be the nine-digit high range of account number
prefixes assigned to the issuer.
01–07 07 Keyword Must be TBLDATA.
Note: For the PC EP platform, the keyword

and equal sign are not required. Values are
entered directly into the screen.

match the sequence number supplied in the TBLKEY
run control option.
11 01 Action Indicator Blank – Add or change record

D – Delete record
12–20 09 Low Account Range Must be the nine-digit low range of account number
prefixes assigned to the issuer.

24–29 06 Issuing Identifier Must be a full six-digit Issuing Identifier.
30 01 Check Digit Indicator 0 - No check digit validation to be performed

1 - Visa modulus-10 checking to be performed
31–32 02 Account Number Length The valid values are:
l Any specific value between 10 and 19

l 00 which means 13/16
33 01 Token Indicator Valid values:

Space = Not applicable
Y = Token Range
34 01 Reserved This field was formerly the Usage field. It will be

space-filled; it is reserved for future use.
35–40 06 BASE II CIB Must be a full six-digit BASE II CIB that identifies the
processing center for the Issuing Identifier specified
in columns 24–29 of this record.
41 01 Domain Domain
42 01 Region Visa region of Issuing Identifier
43–44 02 Country Country of Issuing Identifier.
45 01 Large-Ticket Valid values:

L = Large-Ticket
This field is formerly Issuer Commercial Card Service
Indicator (ICCSI)
46 01 Technology Indicator See supported values.
47 01 ARDEF Region ARDEF Region
48–49 02 ARDEF Country ARDEF Country
50 01 Commercial Card Level 2 Data Y - Level 2 supported

Indicator
Spaces - Level 2 not supported
51 01 Commercial Card Level 3 Y - Level 3 supported

Enhanced Data Indicator
Spaces - Level 3 not supported
52 01 Commercial Card POS Y - POS prompting required.

Prompting Indicator
Note: Y is only valid if Level 2 data is
supported.
Spaces - POS prompting not required.

53 01 VAT Evidence Indicator Commercial Card Electronic VAT Evidence Indicator
54 01 Original Credit For US issuers:

OC flag = Space, Reject OC transactions
OC flag = A, Accept OC transactions
55 01 Account-Level Processing This field was formerly the Product Type Extension
Indicator field.
Valid values:
Y = Card-Level Identification
Space = Not participating in ALP
56 01 Original Credit Money Transfer For US issuers:

MT flag = Space, Reject MT transactions
MT flag = A, Accept MT transactions
For non-US issuers:
MT flag = Space, Accept MT transactions
MT flag = N, Reject MT transactions
57 01 Original Credit Online For US issuers:

Gambling
OG flag = Space, Reject OG transactions
OG flag = A, Accept OG transactions
For non-US issuers:
OG flag = Space, Accept OG transactions
OG flag = N, Reject OG transactions
58–59 02 Product ID For a complete list of valid values, refer to BASE II

Clearing Data Codes.
60 01 Combo Card Valid values:

Y (Combo card, credit and debit)
C (Combo card, credit and prepaid)
Space (Not a combo card)
61 01 Fast Funds Valid values:

Y = Both Domestic and Cross-Border Fast Funds
C = Cross-Border
D = Domestic Fast Funds only
Space = Does not participate in Fast Funds

62 01 Travel Indicator Valid values:

Y (Travel card-capable)
Space (Not applicable)
63–64 02 B2B Program ID This field indicates Business-to-Business (B2B)

Program Identification (ID):
Valid values:
l A1 (B2B Program 1)
l Spaces (Not Specified)
65 01 Prepaid Program Indicator This field provides additional information for certain
prepaid products.
Values:
1 = Consumer program in selected markets
Spaces = Not specified
66–68 03 RRR Spaces (Reserved for future use.)

123
69 01 Account Funding Source C = Credit

D = Debit
P = Prepaid
H = Charge
R = Deferred Debit
70 01 Settlement Match B = B2B

E = B2E
71 01 Travel Account Data A = CTA Air

H = CTA Hotel
S = Central travel account (CTA) Switzerland
72 01 Account Restricted Use A = ATM


73 01 NNSS Indicator Valid values:

Y (Issuing Identifier participates in an NNSS)
Space (Issuing Identifier does not participate in an
NNSS)
Note: The NNSS indicator will not provide

information as to which NNSS the Issuing
Identifier participates in nor will it indicate if
the Issuing Identifier participates in more
than one NNSS or if a transaction will qualify
for NNSS settlement.
74–75 02 Product Subtype Valid values:

AC = Brazil Agriculture Maintenance Account/Custeio
AE = Brazil Agriculture Debit Account/Electron
AG = Brazil Agriculture
AI = Brazil Agriculture Investment Loan/Investimento
CG = Brazil Cargo
CS = Construction
DS = Distribution
EN = Large Market Enterprise
EX = Small Market Expenses
GV = Government/State Disbursement
HC = Healthcare
LP = Visa Large-Purchase Advantage (VLPA)
MA = mVISA Agent
MB = mVisa Merchant Payment
MG = Visa Mobile General
MS = Multicurrency Solution
MX = Merchant Agent and Merchant Payment
PP = Payroll
TK = Service Advantage
VA = Brazil Food or Supermarket/Alimentacao Visa
Vale
VF = Brazil Fuel/Flex Visa Vale
VM = Meal Voucher
VN = Visa Vale Food Voucher
VR = Brazil Food or Restaurant/Refeicao Visa Vale

76 01 Alternate ATM This field indicates participation in Alternate ATM

program:
Valid values:
Y = Participate
Space = Not Participate
77–80 04 N/A Reserved
TIMESEP – Time Separator

TIMESEP specifies the character to separate time fields on Edit Package reports.
Format TIMESEP=separator
Related Options COUNTRY, DATEFORMAT, DATESEP, LANG, NUMDECSEP, NUMTHOUSEP

Name
separator Any special character The single special character used to separate hours,
minutes, and seconds on Edit Package reports. (A blank is
acceptable but alphabetic or numeric characters such as
A-Z or 0-9 is not acceptable.)
Time appears on Edit Package reports in HHMMSS
format:
HH = hours
MM = minutes
SS = seconds
Note:
Example:
TIMESEP=:
Time appears on Edit Package reports as HH:MM:SS

TRANRPTSEQ – Transaction Report

Sequence
TRANRPTSEQ allows clients to print EP-700 reports in ACQ/ISS ID or File sequence.
Format TRANRPTSEQ=sequence
Related Options TRNINPRT, TRNOUTPRT, and EXCPRPTSEQ

Name
sequence FILE Yes Prints reports in file sequence.
BIN Prints reports in ACQ/ISS ID sequence.
FILE causes transactions to print in the sequence they occur within the input file. Option BIN causes
transactions to be reported in ACQ/ISS ID sequence.
By default, transaction-based reports (in the EP–700 series) show transaction detail information in the
same sequence as transactions occur in the incoming ITF/VTF or outgoing CTF/VML. By using
TRANRPTSEQ=BIN clients can cause transactions to be reported in sequence by ACQ/ISS ID. During
the outgoing run, transactions will be in source identifier sequence. During the incoming run,
transactions will be in destination identifier sequence. The ACQ/ISS ID is used for sequencing, will
appear in the header of the report and page breaks will occur between ACQ/ISS ID.
Note:
Transactions must be selected for print by default or by use of the TRNINPRT or TRNOUTPRT
before this option can work.
During incoming runs, reports received from Visa services as TC 45 General Delivery transactions will
also be sequenced according to the value of TRANRPTSEQ. The following rules apply:
l If TRANRPTSEQ=FILE, reports will be grouped in the EP745 file by service. Within service,
most reports are sequenced by ACQ/ISS ID.
l If TRANRPTSEQ=BIN, reports from multiple services will be grouped together by ACQ/ISS ID.
Example:
TRANRPTSEQ=FILE
This option prints transaction-based and general delivery reports in the same sequence as they are
received in the file.
TRANRPTSEQ=BIN
Prints transaction-based and general delivery reports in ACQ/ISS ID sequence.

TRIALRUN – Trial Run

TRIALRUN edits outgoing CTF/VML without creating ITF/VTF and updating History File.
Format TRIALRUN=trial
Type Temporary and Outgoing
Related Options RERUN

Name
trial N Yes The run is not a trial run.
Y The run is a trial run, no outgoing ITF/VTF is created, and no history is

maintained.
TRIALRUN is used to edit an outgoing Center Transaction File (CTF) without the creation of an
outgoing Interchange Transaction File (ITF) and without updating the Edit Package History File.
Processing centers may use this option to determine if input transactions pass all edits before
committing them to interchange.
All outgoing Edit Package-generated error, control, and summary reports, except the EP–120
Outgoing ITF Summary by Volume Report, are still produced.
Example:
TRIALRUN=Y
The Edit Package edits an outgoing CTF/VML. The outgoing file is not created and history is not
updated.
TRNINPRT – Print Incoming Reports

TRNINPRT provides detail reporting of selected incoming transactions.
Format TRNINPRT=trancode
Type Incoming
Related Options TRNNOINPRT, TRNPASS, TRNOPASS, TRNOUTPRT, TRNOOUTPRT, and FEERPTFMT


Name
trancode Any valid incoming None Two-digit numeric CTF transaction code, 3-digit numeric VTF
transaction code transaction code, or 4-digit message type (internal). This
defines which transaction-based reports are to be generated
during the incoming run.
Each record specifies a single transaction code to be printed. The default is the value set in the Edit
Package Transaction Table supplied by Visa.
Note:
Since TRNINPRT is closely related to TRNNOINPRT, see TRNNOINPRT – Stop Incoming Report
Printing for examples.
Print Incoming Transaction-Based Reports:

The internal Edit Package tables contain a default setting, by transaction code that determines
whether or not a transaction should be reported. The purpose of these options is to override the
system defaults, as shown in the following examples.
TC 48 (BASE I Advices)—the system default for these transactions is to print. Use of the TRNNOINPRT
option forces the Edit Package to no longer print the TC 48 transactions on incoming processing.
TC 05 (Sales Drafts)—the system default for these transactions is not to print. Use of the TRNINPRT
option will force the Edit Package to print the TC 05 transactions on incoming processing.
TC 10 and TC 20 (Fee Collection/Funds Disbursement transaction-based reports)—these reports can
be controlled by either FEERPTFMT or TRNINPRT.
TRNNOINPRT – Stop Incoming Report

Printing
TRNNOINPRT prevents a transaction from being printed during incoming runs.
Format TRNNOINPRT=trancode
Type Incoming
Related Options TRNINPRT, TRNPASS, TRNOPASS, TRNOUTPRT, TRNOOUTPRT, and FEERPTFMT


Name
Each record specifies a single transaction code not to be printed. The default is the value set in the
Edit Package Transaction Table supplied by Visa.
TRNINPRT and TRNNOINPRT run control options are not used to control printing of TC 45 or TC 47
transactions.
TC 45 General Delivery Reports and TC 47 VIC Interchange Reports automatically print.
If the processing center wants to be removed from the distribution list for the TC 45 General Delivery
Reports, contact Visa.
See Print/Pass Defaults for a complete list of valid BASE II transaction codes and print defaults.
Example:
TRNINPRT=05
TRNNOINPRT=48
Transaction-based report EP-705, which displays TC 05s for an incoming run, is printed.
Transaction-based report EP-748, which displays TC 48s for an incoming run, is not printed.
TRNOOUTPRT – Stop Outgoing

Report Printing
TRNOOUTPRT prevents transaction-based reports from being printed during outgoing runs.
Format TRNOOUTPRT=trancode
Type Outgoing
Related Options TRNOUTPRT, TRNINPRT, TRNNOINPRT, TRNPASS, and TRNOPASS

Name
trancode Any valid outgoing None Two-digit numeric CTF transaction code, 3-digit numeric VTF
during the outgoing run.

Each record specifies a single transaction code not to be printed during outgoing runs. This run
control option is only used to override the TRNOUTPRT run control option specified in the
Permanent Run Control Options File.
Note:
Since TRNOOUTPRT is closely related to TRNOUTPRT, see TRNOUTPRT – Print Outgoing
Reports for examples.
TRNOPASS – Exclude Transactions

From Output
TRNOPASS prevents specific transaction codes from being written to the CTF/VML during incoming
runs.
Format TRNOPASS=trancode
Type Incoming
Related Options TRNPASS, TRNINPRT, TRNNOINPRT, TRNOUTPRT and TRNOOUTPRT

Name
Each record specifies a single transaction code not to be passed to the CTF/VML during an incoming
run. The default is the value set in the Edit Package Transaction Table supplied by Visa.
Note:
Since TRNOPASS is closely related to TRNPASS, see TRNPASS – Include Transactions on
Output for examples.

TRNOUTPRT – Print Outgoing Reports

TRNOUTPRT prevents transaction-based reports from being printed during outgoing runs.
Format TRNOUTPRT=trancode
Type Outgoing
Related Options TRNOOUTPRT, TRNINPRT, TRNNOINPTR, TRNPASS and TRNOPASS

Name
trancode Any valid outgoing None Two-digit numeric CTF transaction code, 3-digit numeric VTF
during the outgoing run.
Each record specifies a single transaction code that is to be printed during outgoing runs. The default
is the value set in the Edit Package Transaction Table supplied by Visa.
Example:
TRNOOUTPRT=42
TRNOUTPRT=57
TRNOUTPRT=58
TRNOUTPRT=59
Transaction-based report EP-742, which displays TC 42s in an outgoing run, is not printed if the
default is to print.
Transaction-based report EP-757, 758, and 759, which display TC 57s, 58s, and 59s in an outgoing
run, are printed.
Print Outgoing Transaction-Based Reports:

The purpose of this option is to override the system default and control whether or not particular
transaction codes are to be reported. For example, the system default for transaction code TC 05
(sales drafts) is not to print. Use of the TRNOUTPRT run control option forces the Edit Package to
print the TC 05 transactions on outgoing processing.

TRNPASS – Include Transactions on

Output
TRNPASS writes specific transaction codes to the incoming CTF/VML.
Format TRNPASS=trancode
Type Incoming
Related Options TRNOPASS, TRNINPRT, TRNNOINPRT, TRNOUTPRT and TRNOOUTPRT

Name
TRNPASS causes specific transaction codes to be written to the incoming Center Transaction File
(CTF) or VML. Each record specifies a single transaction code to be passed to the CTF/VML during an
incoming run. The default is the value set in the Edit Package Transaction Table supplied by Visa.
Example:
TRNOPASS=31
TRNPASS=40
TC 31s are not written (passed) to the incoming CTF/VML.
TC 40s are written (passed) to the incoming CTF/VML.
Pass Transactions to Incoming CTF/VML:

Internal Edit Package tables contain a default setting, by transaction code, which determines whether
or not a transaction should be written to the CTF/VML. The purpose of the above options is to
override the system default, as shown in the following examples:
l TC 31 (ICS Response)—these transactions have a system default of pass. Use of the
TRNOPASS run control option forces the Edit Package not to write TC 31 transactions to the
incoming CTF/VML.
l TC 40 (Fraud Advice)—these transactions have a system default of no pass. Use of the
TRNPASS option forces the Edit Package to write TC 40 transactions to the incoming CTF.

VALERROR – Validation Errors

Reported
VALERROR is used to identify the maximum number of errors per transaction reported.
Format VALERROR=number

Name
number 1 to 1,000 10 Maximum number of errors reported for any single transaction.
Example:
VALERROR=15
This option will set reporting to list up to 15 errors per transaction.
Exceptions Reported:
During validation it is possible to identify many exception conditions. Only the first 10 are reported
(by default) but that can be adjusted up to 1,000.
VALIDATE – Validation Edits Bypass

VALIDATE can be used to bypass validation edits. If the validation edits are bypassed then the input
parsing, output file build, and reporting are still performed. Regional authorization is required to use
this run control option. Contact your regional representative for authorization and option details.
Format VALIDATE=flag

Name
Flag Y Yes Perform validation edits (default)
N Bypass validation edits (if authorized)

Example:
VALIDATE=Y
Edit Package will include normal validation edits.
WORKDIR – Work Directory

Identify a location for storing work files that are used to save data received from client workstations.
When the server is running under Windows then this defines a directory used to store data received
from client workstations. When the server is running under z/OS then this defines a dataset name
prefix.
Format WORKDIR= \suxyz\user\joeblow\epng\

Name
Workdir None Yes Perform validation edits (default)
Windows directory Server running on windows
Dataset prefix Server running on z/OS
Example:
WORK=epng.work.
Prefix work files with EPNG.WORK when running z/OS.
WRITEHEADR – Incoming Header

Record
WRITEHEADR activates creation of the header records (TC 90 or T183) on incoming CTF/VML files.
Format WRITEHEADR=choice
Type Incoming


Name
choice N Yes The header record (TC 90 or T183) is not written to the incoming
CTF/VML file.
Y The header record (TC 90 or T183) is written to the incoming CTF/VML

file.
WRITEHEADR allows processing centers to have the Edit Package create a header record on all
incoming Center Transaction Files (CTF/VML files). Processing centers can then access this
information without the need to read the ITF/VTF in their post-edit processing. The default is N.
The following data is available on the incoming CTF/VML header record:
l BASE II CIB and security code
l VisaNet Interchange Center (VIC) processing date
l VIC settlement date
l Edit Package release number
l File type
l Subfile ID number
For the layout of the TC 90 header record, refer to Header Records in the BASE II Clearing
Interchange Formats manuals. See Control Transaction Types in the BASE II Visa Markup Language
(VML) Formats manual for the layout of the T183 header record.
Example:
WRITEHEADR=Y
The Edit Package creates a header record on all incoming CTF or VML files.

Chapter 7
Support Utilities, Extract, and On-
Request Reporting
Several support utilities are provided to perform installation and updates to Edit Package files.
These modules are:
l EP4U010 — Installation Options Setup Utility
l EP4U100 — Initialize History File
l EP4U130 — Apply TC 54 Updates
l EP4U132 — Load Repository Files From Master
l EP4U140 — Apply software updates From Visa Online (VOL)

Support Utilities, Extract, and On-Request Reporting
EP4U010—Install Setup Utility

Using module EP4U010, you can initialize your control files on installation or when the files need to
be recreated.
The files to be initialized include:
l History File
l Log File
l Incoming Run Hold File
l Permanent and Temporary Run Control Options File
l Currency Conversion Rates File
l TC 33 Extract File
The program reads a DD name MEDIA as an input. The input file is formatted for this program.
Output can be to the following files:
DD Name Type Attributes
STGJCL JCL output 80-byte fixed-block output
STGPROC Procedure library 80-byte fixed-block output
STGLCTL Link control 80-byte fixed-block output
STGPARM Parameter 80-byte fixed-blocked output
REPPROF Repository Profile tables Variable, 256-byte records
REPREPOS Repository value tables Variable, 256-byte records
REPDEF Repository table definition Variable, 1,024-byte records
REPARDEF Repository ARDEF table Variable, 256-byte records
REPBIN Repository VID table Variable, 256-byte records
REPTOPTS Initial Temp Run Options Variable, 256-byte records
OCTF Test CTF 168-byte fixed-block output
OITF Test Outgoing ITF 170-byte fixed-block output
IITF Test Incoming ITF 170-byte fixed-block output
ICTF Test Incoming CTF 168-byte fixed-block output
OVML Test Outgoing VML Variable, 1024-byte record
OVTF Test Outgoing VTF Variable, 1024-byte record
IVTF Test Incoming VTF Variable, 1024-byte record

DD Name Type Attributes
IVML Test Incoming VML Variable, 1024-byte record
RPTOUTTC Outgoing sample reports using TC test file Variable, 1024-byte record
RPTOUTVM Outgoing sample reports using VML test Variable, 1024-byte record
file
RPTINTC Incoming sample reports using TC test file Variable, 1024-byte record
RPTINVM Incoming sample reports using VML test Variable, 1024-byte record
file
JCL JCL library 80-byte fixed-block
PROC Procedure Library 80-byte fixed-block
PARM Parameter Library 80-byte fixed-block
RLOAD Rules library, not currently used Blocksize 19069; Format undefined
OPTIONS Install utility options 80-byte fixed-block, INPUT
MEDIA Input File Variable, 18000-byte, INPUT
Note:
Job control statements may affect the disposition of files that have not been selected for
installation. Make sure that non-initialized files are not deleted or changed when EP4U010 is
run.
For more information regarding the mainframe install utility, see Edit Package Installation Procedures.
EP4U100—Initialize History File

This utility is used to initialize EP Release 4 History files.
EP4U130—Apply TC 54 Updates
This utility applies TC 54s software updates from an Incoming interchange file to the Edit Package
software environment. The module can be used to process an ITF or VTF that contains the full file
replacement or apply the regularly schedules updates to EP software environment.
Module EP4U130 uses the same update logic as the Incoming Edit Package (EPZOS) uses during
software maintenance processing. The module can be used to avoid re-processing the other
transactions such as financial and non-financial contained in the Incoming files.

EP4U132—Load Repository Files From

Master
This utility is used to load the individual repository files such as Codebase, VID, ARDEF, Profile, Value,
and Repository Definition files from Master Repository backup file.
The module is used to restore the repository environment if the Master Repository file is available
but some or all of the individual repository files are damaged. The Master Repository file is defined
as a generation data group (GDG) so the latest version should be used for restore procedures.
EP4U140—Apply Software Updates

From Visa Online (VOL)
This utility applies the Edit Package software updates from Visa Online (VOL).
Edit Package software updates from VOL does not have the TC54 wrapper and are different for PC or
mainframe platforms. The VOL software update package includes instructions (README) on how to
apply that VOL download files to the Edit Package software environment. Depending on those
instructions client is required to use this utility.
Edit Package Extract and On-Request

Reporting
You can print formatted reports of the contents of internal Edit Package files at any time. You can
also extract Edit Package table information into sequential files. Run control option EXTRACT can be
used to identify a request for the following reports:
Report ID Report Name
EP-300 History File Report
EP-301 VID Table
EP-302 ARDEF Table
EP-303 Value Table
EP-399 Log File Report
The run control option EXTRACT can be used to extract sequential files of VID, ARDEF, and other
value tables for use by the processing centers pre- and post-edit systems. Value tables include
Merchant Category Codes, Chargeback Reason Codes, Currency Codes, Country Codes, Holidays, Fee

Collection Reason Codes, and Returned Item Reason Codes. The value tables file extracts can be
requested using Release 3.0 Value Tables or Release 4 Value Tables table ID by defining the
appropriate table name in the EXTRACT run control option parameter.
Release 3.0 Value Tables
Release 3.0 Table ID Release 3.0 Table Description
CNTRYCD Country Code
CURRTBL Currency Code
HOLIDAY Holiday
MERCAT Merchant Category Code
REASNCD Chargeback Reason Code
TRANCD Transaction Code
FCRSNCD Fee Reason Code
RTNITEM Return Reason Code
Example:
To generate the value table file extract for country code using Release 3 table ID, specify the Release
3 table name:
EXTRACT=TABLE,NAME=CNTRYCD,FUNCTION=FILE
Release 4 Value Tables
Release 4 Table ID Release 4 Table Description
COUNTRY Country Code
CURRENCY Currency Code
HOLIDAY Holiday
MCC Merchant Category Code
CBREASON Chargeback Reason Code
TRANCD Transaction Code
FCRSNCD Fee Reason Code
RTNITEM Return Reason Code
Example:
To generate the value table file extract for country code using Release 4 table ID, specify the Release
4 table name:

EXTRACT=TABLE,NAME=COUNTRY,FUNCTION=FILE
Note:
Holiday (HOLIDAY), Transaction Value Table (TRANCD), Fee Reason Code (FCRSNCD), and
Return Item (RTNITEM) tables for both Release 3.0 and Release 4 have the same names or
table ID.
See Edit Package Run Control Options for more information on how to specify the parameters. See
Edit Package File Layouts for the file extract layouts.
Combined (ACQ/ISS ID & ARD) (EP–304) File

Extract Utility
The EP–304 utility combines the contents of the VID (EP–301) and ARDEF (EP–302) file extracts in the
Combined (ACQ/ISS ID & ARD) (EP–304) file extract. The EP–304 utility is supported in mainframe
and PC Edit Package Graphic User Interface and Batch facility.
EP–304 utility generates a file extract, there is no corresponding EP–304 report. The mainframe Edit
Package has a separate job control language (JCL), EP304EXT, to generate the Combined (ACQ/ISS ID
& ARD) EP–304 file extract. The JCL first creates the file extracts for EP–301 and EP–302, then
combines these files into the EP–304 file.
The EP–304 extract will include the following key elements.
l The file will be a sequential file in a single fixed-length record format that contains data
elements from the EP–301 and EP–302 file extracts.
l The file will use common fields from EP–301 and EP–302 like issuing identifier, BASE II CIB,
region, and country.
l The file will be sorted by application processor (CIB) and clearing entity (ACQ/ISS ID). There
will be no unique key for this file.
l The file will use the run control option, TABLEDATE, to establish which table entries to extract
during processing.
l The file will contain the ARDEF information when the clearing entity associated with the
processor is an issuer (VID types: Full Service, and Issuer), and there are account ranges for
the issuer. The file will contain no ARDEF information when the clearing entity associated with
the processor is a non-issuer (VID types: Non-financial, and Merchant).
See Edit Package File Layouts for the EP–304 file layout.

Appendix A
System Modules and Files
Edit Package System Components

The Edit Package (Release 4) software includes Repository Files, Core Modules, and EP Workstation
(client and/or server component).
Edit Package Repository Files

One of the primary changes to the system files for Edit Package (Release 4) is the addition of the
Repository files.
The Repository files contain the following information:
l BASE II ACQ/ISS ID
l BASE II ARDEFs
l Value tables
l Repository Definition

l Repository Profile
l Codebase Control Tables
Edit Package Repository File Contents

In addition to the valid BASE II ACQ/ISS IDs and ARDEFs, the Value Table Repository files contain the
value tables for merchant category codes, chargeback reason codes, currency codes, country codes,
holidays, fee collection reason codes, and returned item reason codes. Also included in the value
tables are transaction mapping tables and software update control tables.
The Edit Package Repository Profile table file defines the default PROFILE parameter for Outgoing
and Incoming edit runs. The PROFILE parameter table defines the set of run control options and its
associated values for given parameter PROFILE
The Codebase Control tables contain key information regarding object modules and their effective
dates. With the linker control records in the Repository value tables, system will create load modules
for a given effective date. The system will load and execute the appropriate load modules based on
run date.
Edit Package (Release 4), provides run control options to allow ACQ/ISS IDs, ARDEFs, and value table
extracts.
See Edit Package Layouts for more information on the Repository files and Value table extracts.
Edit Package Core Modules

The Edit Package software has many program modules. The core modules are written in C and C++.
The core modules also include the business rules used in the validation of BASE II transactions. The
business rule modules are in COBOL.
There is a common control program for outgoing and incoming Edit Package processing and which
calls other sub-modules, as needed, to:
l Process and validate transactions.
l Generate reports.
l Create output files.
Edit Package (Release 4), supports Visa BASE II-published formats i.e., Transaction Codes (TCs) and
Visa MarkUp Language (VML). Depending on the run control option profile used for the run,
appropriate modules are loaded and executed to process input files which are either in TC or VML
formats.

Core Load Modules List
Module Description
EPCTFB01 EPCTFB01 is the builder module that creates output files in TC format based on the
run control option in effect:
EPCTFB01 performs the following functions:
l Processes one logical transaction at a time.

l Creates transaction record to the CTF file for Incoming Run.
l Creates transaction record to the ITF file for Outgoing Run.
l Creates rejected transactions to the Rejected File.
l Creates return item transaction to its corresponding Return Item File.
l Split transactions into different output files according to the split by run control
options.
l Creates TC 54 transactions to a separate file.
l Create TC 33 transactions to a separate file.
l Collects counts and monetary amounts for batch and file trailer record.
l Creates TC 90 header record.
l Creates TC 91 batch trailer record.
l Creates TC 92 file trailer record.
l Updates process run , batch and file information to History file.
l Updates TC 44 transaction details to History file.
l Creates TC 50 to ITF file for Outgoing Run.
l Checks for the following run control options and issues corresponding error or
warning messages:
– ITF Error Threshold for Outgoing Run (REJITFLIM).

– Run Tolerance Amount and Currency (RUNCURAVG).
– Error Reporting Threshold (REJMSGLIM).
– Number of records in a Batch (MAXBATRECS).

Module Description
EPVMLB01 EPVMLB01 is the builder module that creates output files in VML formats based on
the run control option settings:
EPVMLB01 performs the following functions:
l Processes one logical transaction at a time.

l Creates transaction record to the VML file for Incoming Run.
l Creates transaction record to the VTF file for Outgoing Run.
l Creates rejected transactions to the Rejected File.
l Creates return item transaction to its corresponding Return Item File.
l Split transactions into different output files according to the split by run control
options.
l Create T140/T208/T209 transactions to a separate file.
l Collects counts and monetary amounts for batch and file trailer record.
l Creates T183 header record.
l Creates T184 batch trailer record.
l Creates T185 file trailer record.
l Updates process run , batch and file information to History file.
l Updates T159/T199 transaction details to History file.
l Creates T162 to VTF file for Outgoing Run.
l Checks for the following run control options and issues corresponding error or
warning messages:
– ITF Error Threshold for Outgoing Run (REJITFLIM).

– Run Tolerance Amount and Currency (RUNCURAVG).
– Error Reporting Threshold (REJMSGLIM).
EPCTFP01 EPCTFP01 is the module that parses the input Center Transaction File (CTF) into the
Edit Package internal formats. It performs the following functions:
l Parse each field and set to internal format.

l EPCTFP01 performs the following editing:
– Numeric
– Alphanumeric
– Date
– Country
– Currency
– Hex String
l EPCTFP01 also performs Header and Trailer editing to make sure the internal count
and sum matches those in the file

Module Description
EPFM001 The File Manager module performs the following functions:
l Uses runopts <threadset> definition to identify input files as either sourced from a
DD or a file name (DS).
l Creates a File-Manager-List entry for the identified file (fileref).
l The File-Manager-List entry identifies the file name characteristics used to identify
a file.
l Create an initial set of directory entries using the File-Manager-List entries as input
l Retrieves attributes of the file based on header. Note: Assumes TC or VML file type.
l Sequence directory entries by file input sequence (if requested). This allows files to
be processed in the order defined by the VIC. It is independent of input method
(JCL DD statement or file-system Dataset) Note: this method also extracts the file
header attributes
l Associate the DLL run-time with the parent thread
l Search the repository thread definitions for parser/builder files (type and location)
l Return the count of directory entries queued on the file list
EPHIST History file contains a history of batches, files and runs for Outgoing and incoming
Edit Package processing.
l Performs History Updates, including History record additions and deletions.

l Creates History backup before the start of the run and after the run is completed.
EPRPT01 Report driver module that calls sub-modules to generate summary and detail reports
for Outgoing and Incoming runs. Optionally on request transaction based reports,
various value table reports and extract files can also be generated based on run
control settings.
EPRULE Rule processing interface from C++ modules to Edit Engine COBOL interface This DLL
is loaded by CEpeditctl.
EPZOS Execution shell for running Edit Package under z/OS or Windows.

Module Description
EPVMLP01 EPVMLP01 is the module that parses the input Visa MarkUp Language (VML) into the
Edit Package internal formats. It performs the following functions:
l Parse each field and set to internal format

l Validate that the VML Tags are valid within the Transaction
l EPVMLP01 performs the following editing
– Numeric
– Alphanumeric
– Date
– Country
– Currency
– Hex String
l EPVMLP01 also performs Header and Trailer editing to make sure the internal
count and sum matches those in the file
EPTBLUPD Program EPTBLUPD updates Master Repository Table from Table update records.
Builder processes TC54 transactions from an Incoming file and writes Table update
records into a separate file (TC54EXT). EPTBLUPD maintains Master Repository file
which is a combination of all of the Repository files.
EPTBLUPD performs the following functions:
l Loads the //REPOSIT DD (Repository Old Master File) into memory

l Sorts the Old Master in memory
l Processes the //TC54EXT DD (Table update records file) one batch (delta version)
at a time
l Ignores any Delta table version that has already been applied
l For each Delta table version that has not yet been applied:
– Transforms each table update record into Master File format

– Applies (inserts/deletes/modifies) all required changes to the Old Master
Repository and create New Master Repository
l Determines if any module updates are newly added to the Master Repository and
writes the necessary update information to the //DLLOUT DD

Module Description
EPTBLSPT Program EPTBLSPT writes Master Repository table file in to individual Table files
(ARDEF, VID, CODEBASE, DEF, PROFILE & VALUE Tables).
EPTBLSPT performs the following functions:
l Loads the Master Repository (//REPOSIT DD) into memory

l Reads the Member Options (//OVERRIDE DD) and updates Master Repository
Table in memory.
l Creates the individual repository Table files:
– ••• //REPOSDEF DD ==> Definitions Table

– ••• //ARDEF DD ==> ARDEF Table
– ••• //BINTABLE DD ==> VID Table
– ••• //PROFILE DD ==> Profile Table
– ••• //VALUE DD ==> Value Table
– ••• //CODEBASE DD ==> CODEBASE Table
Edit Package Workstation

Edit Package for Windows (Release 4) has functionality similar to previous versions of the software.
However, instead of being a single executable application installed on a PC, Edit Package for
Windows (Release 4) includes separate installed components for the user interface (EP Workstation)
and server (EP Server) functions in a client-server architecture.
Edit Package Workstation Client-Server Overview

The client program usually includes a user interface and can be installed on a Windows operating
system. The server program can be installed on a server or PC workstation. A client-server application
includes a server program that is connected to one or more client programs.
EP Server
The EP Server contains the Edit Package Core to perform all basic functions such as incoming and
outgoing edit runs, and the utilities. Thus, the EP Server contains the functionality available to
mainframe Edit Package installations.
The EP Server also includes all of the files that support each BASE II CIB. These files include the new
Repository file that contains the VID and ARDEF tables, history files, permanent and temporary run
control options, and Edit Package reports.
Important:
The EP Server must be installed on either a PC with a Windows operating system supported
by Visa or a Windows Application Server 2003.

EP Workstation
An EP Workstation is the user interface for Edit Package for Windows (Release 4) that supports data
entry, outgoing and incoming processing, file transfer to DEX or EA Server, and retrieval of files from
DEX or EA Server.
Important:
The EP Workstation must be installed on PCs with a Windows operating system supported by
Visa.
Edit Package Software Updates and

Distribution
This section provides information on distribution, software installation, and updates for Edit Package
Release 4. Information on Release 3.0 software distribution and updates are provided for background
information only.
Edit Package Distribution Events

There are two distribution events: initial software release and subsequent updates.
Initial release of mainframe and PC Edit Package 4 software will be available through Visa Online
(VOL). (CD-ROMs will only be generated on an exception basis; please contact your Visa account
manager to request an exception.) The CD and VOL install files will contain the latest version of the
software.
Software updates can be included in the incoming interchange files or they can be downloaded from
Visa Online (VOL) depending on the type and volume of the updates.
Acquirers, issuers, and processors are expected to have file transfer capabilities to move the install or
update package from VOL to their Host systems. Installation instructions will cover basic command-
line TCP/IP FTP. Acquirers, issuers, and processors can choose to use other file transfer options
besides the documented FTP procedure.
Edit Package Initial Software Installation

Edit Package Release 4 for mainframe was developed so users will not need their own compilers for
installation and maintenance of the software.
Support for Visa's Edit Package only extends to versions of z/OS that are currently supported by IBM;
this generally covers the most recent three (3) versions of their z/OS. While EP software may have
previously been supported on earlier versions, updates and new releases to EP will not be tested on
these older operating systems and functionality cannot be guaranteed. Installation of Edit Package

and resolution/troubleshooting of reported issues on operating systems at an earlier level cannot be

supported because among other reasons, Visa no longer uses these versions of z/OS and therefore
cannot replicate client issues or provide technical support.
Important:
The Language Environment for z/OS must have COBOL run-time support for programs
compiled with Enterprise COBOL, Version 4, Release 2.
Edit Package Subsequent Software Updates

In addition to program updates, Edit Package 3.0 generates and distributes updates to BASE II VID
and ARDEF tables and to other value tables and business rules via TC 54.
For Edit Package Release 4, software updates will have updates to the following:
l Repository File
l Core
l EP Workstation (client and/or server component)
The Core software updates will include the business rules used in the validation of BASE II
transactions.
Important:
Software updates can be included in the incoming interchange files or they can be
downloaded through Visa Online depending on the type and volume of updates.
Once the updates are received by a processing center, they are automatically applied during an
incoming edit run. Note that updates to Edit Package software have an effective date.
Edit Package Release 4 will generate a return code of 5 to indicate that the file processed by
incoming run does not contain TC 54s.
Edit Package Release 4 will generate a return code of 6 when the software update process during the
incoming run is not successful. A return code of 6 may also be generated along with an appropriate
message in the processing log to inform acquirers and issuers that the software components
required for a successful update are available through Visa Online.
Edit Package Repository File Updates

Edit Package Release 4 updates to the new Repository are made in the same way as in previous
versions, that is, updates are sent in the TC 54 transactions that are included with incoming
interchange files. These updates are automatically applied during an incoming edit run.
Edit Package Core Updates

The Edit Package software has many program modules. The core programs which include parser,
builder and report modules are written in C and C++. The core also include the business rule

modules used in the validation of BASE II transactions which are written in COBOL. The core
programs perform basic functions such as incoming and outgoing edit runs, and reporting. The same
Core programs are used for both the mainframe Edit Package and the Edit Package for Windows.
There are three major enhancements to the Core for Edit Package Release 4. First, for the mainframe
Edit Package the Core programs for prior releases (Release 3.0) were distributed in COBOL source
code that processing centers had to compile and link. For Release 4, the Core modules for the
mainframe Edit Package will be distributed as object modules. Thus, processing centers will not need
to compile the Core object modules for the mainframe Edit Package.
The second major enhancement for Release 4 is that the updates for the Core can be distributed
within TC 54 transactions that are included with incoming interchange transactions. The TC 54
updates for the Core will contain object modules for the mainframe Edit Package and Microsoft
install files (*.msi) files for the Edit Package for Windows. During an incoming edit run, the Edit
Package will automatically install the new versions of the object modules or PC install files.
For Release 4, the third major enhancement for the Core is the addition of the Repository file. Within
the Repository file is a table that keeps track of the object and load modules that have been installed
and their effective dates. At runtime, the Repository file software control table is used to identify the
versions of the load modules which should be loaded for execution for a given run date.
Software Control Table Example
EP Workstation Updates
In legacy versions of the PC Edit Package for Windows, all of the application elements were
contained in a single Windows application. These elements included the User interface, Core
programs, and supporting files. Because it was a single application, when any changes occurred
other than the usual updates to the table files, the entire application needed to be manually
reinstalled or updated. Each update was sent on a CD-ROM that processing centers applied
individually to every installation of the application.
For (Release 4), the architecture of the Edit Package for Windows has been changed from a single
application to a two-tier client-server installation with an EP Workstation application and an EP
Server application.

This architecture has the following advantages:

l Changes to the EP Server need to be made to only one instance for each installation.
l Changes to the EP Workstations may be less frequent.
Edit Package Application

Maintenance
Edit Package application maintenance occurs for the Repository File and Software Code for
mainframe and PC.
Edit Package Repository File Maintenance

The Edit Package maintains the repository tables automatically. TC 54 Table Update transactions are
delivered by BASE II along with other interchange data. Normally, the TC 54s contain only the
changes to the tables. During the incoming Edit Package run, these changes are merged with the
copy of the repository table files to create the next version.
Actions to Keep Edit Package Repository Files Current

It is important for each processing center to keep its table files current.
The following actions should be followed to ensure that each table update is applied:
l Process incoming files in order by Central Processing Date. If files are not processed daily, the
oldest files should always be processed first. Within the same Central Processing Date, files
can be processed in any sequence.
l Make backups of the repository files after every incoming run. TC 54 Table Update
transactions can be delivered during any BASE II processing cycle.
l If it is ever necessary to restore files from backup, make sure that the most current backup is
used.
l Client may use AUTOUPDT run control option to request for automatic repository file
updates.

Out-of-Date Edit Package Repository Tables
If Edit Package tables are not kept current, the following may occur:
l Transactions containing valid data may be rejected during the outgoing run. This may include
ACQ/ISS IDs or ARDEFs flagged as invalid.
l Transactions that were successfully processed by the outgoing Edit Package may be returned
by BASE II.
A client with out-of-date tables would receive a return code of 6 during an Incoming run and a
message indicating failure of table updates will be displayed at the bottom of the EP-299 Processing
Log Report. The error message is:
3174-E TC 54 HEADER VERIFICATION ERROR: IMG = A TABLE = BBBB DATE =
CCCCCCCC VER = DDDDD
If your tables are out of date, TC 54 Table Update transactions can be sent from Visa to bring the
tables up to date through any of the following options:
l Using the run control option AUTOUPDT
l Requesting updates through your Visa representative
Using the run control option AUTOUPDT to request table updates automatically:
1. Client must turn on the AUTOUPDT run control option to alert Visa that they wish to use the
automatic table update feature.
2. Client must run an outgoing to provide Visa with the current status of their tables.
3. Edit Package system will determine and create the tables updates required to bring client's
table up to date, based on the current version of tables at Visa and client's current table
versions.
4. Client must run an incoming to process table updates. The EP-299 Report generated must
indicate successful table update for the run.
5. Client must allocate enough space for TC 54 work files to accommodate full repository table
replacements, which may include approximately 160,000+ TC 54 records.
Note:
Client must communicate to their Visa representative if there are multiple processors that
will share table updates and which processor must receive the table updates.
Requesting repository file updates through your Visa representative:

In addition to checking the EP-299 Processing Log Report for table update failure messages, you can
determine if Edit Package tables are current at your processing center by examining the EP–199
(Outgoing) or EP–299 (Incoming) Log Processing Report.
Report message 0061-I shows the effective date for the tables that were used during the run.
ACQ/ISS IDs and ARDEFs change six times a week. If the dates shown for your VID and ARDEF Tables

are more than a week in the past, the tables are not current. If you are not sure if the tables are
current, contact your Visa representative and provide Log Processing Report (EP-199).
Your Visa representative will coordinate this process. The following techniques are available:
l Receive a repository file replacement for all VID, ARDEF and Other Value table files. This
technique always makes repository files up to date. Approximately 160,000+ records are
transmitted to each center.
l Receive a repository file replacements for the ACQ/ISS IDs and ARDEFs only. This technique is
effective if VID and ARDEFs tables are out of date.
Edit Package Software Code Maintenance—

Mainframe and PC
The Edit Package software code updates may be delivered via TC 54s or made available through Visa
Online (VOL). If updates were delivered via TC 54s, the system automatically apply the updates to the
Edit Package software during an incoming run.
Edit Package Return Code of 6 During Incoming Run

If updates were made available through Visa Online, the client will receive a return code of 4 during
Incoming processing of repository file updates.
Edit Package will display the following message on EP-299 report:
If updates were made available through Visa Online, the client will receive a return code of 4 during
Incoming processing of repository file updates and Edit Package will display the following message
on EP-299 report:
3174-I April 2009 Business Enhancements effective CPD 17 April 2009 is
available on Visa Online (VOL).
A client with out-of-date software would receive a return code of 6 during an Incoming run and a
message indicating failure of table updates will be displayed at the bottom of the EP-299 Processing
Log Report. The error message is:
3174-E TC 54 HEADER VERIFICATION ERROR: IMG = A TABLE = BBBB DATE =
CCCCCCCC VER = DDDDD
VOL Processing Updates for Edit Package

A readme.txt will be included with the software updates available through VOL.
The readme.txt may include the following information:
l Description of the changes
l Effective date

l Instructions on how to apply the updates

l Any special test considerations required

Appendix B
Edit Package File Layouts
Record layout and pertinent data for each of the following Edit Package files is detailed. Note that all
the file formats defined here are IBM mainframe file definitions for fixed length EBCDIC records and
define trailing spaces for each record. Users of the Windows Edit Package will find that the Windows
records are standard ASCII format and have no trailing spaces. Each Windows record is terminated
with an ASCII carriage return/line feed character.
l Currency Conversion Rates File
l History File
l History Backup File
l Incoming Run Hold File
l Log File
l Permanent Run Control Options File
l TC 33 Extract File
l Rejected Item File
l Returned Item File
l Temporary Run Control Options File

l Edit Package Table Files

n Account Range Definition (ARDEF) File
n VID Table File
l ARDEF Extract File
l ACQ/ISS ID Extract File
l Value Table Extract Files
Note:
The formats for the file layouts can be numeric (N), alphanumeric (AN), or unpacked numeric
(UN).
Edit Package Currency Conversion

Rates File Layout
The Currency Conversion Rates File contains all valid BASE II Counter and Base currency codes, their
effective date, Buy and Sell scale factors, and Buy and Sell Conversion Rates. This file is updated by
TC 56 currency rate update transactions during Incoming Process.
Important: The contents of the Visa Currency Conversion Rate file (i.e., Rate Update Records
or TC 56 file) are Confidential and may be used only by Visa and its authorized client financial
institutions. Any other use is strictly prohibited unless expressly authorized by Visa.
Record Length:
80
Organization:
Sequential
Record Volume:
80 to 300 records depends on the number of Settlement and Non-Settlement Currencies and Cross-
Currencies that are in effect at the time of the run.
File Structure:
Contains only one record type, namely, the currency conversion rates record. There are no header or
trailer records.

Currency Conversion Rates Record Layout
Position Length Format Field Name Description
01–03 03 UN Counter Currency Code This field will contain the ISO numeric currency
code of the Counter Currency.
04–06 03 UN Base Currency Code This field will contain the ISO numeric currency
code of the Base Currency.
07–10 04 UN Effective Date The format of this field is MMDD where:
MM = 01–12
DD = 01–31
11–12 02 UN Buy Scale Factor Number of decimal places implied with the Buy
Conversion rate. For example, a scale factor of
00(zero) indicates the conversion rate is an integer
(NNNNNN) with no decimal points, while a scale
factor of 02 indicates the conversion rate has 2
decimal points (NNNN.NN).
The field must be 00 through 99.
13–18 06 UN Buy Conversion Rate Base Currency equivalent to buy one unit of
Counter Currency.
19–20 02 UN Sell Scale Factor Number of decimal places implied with the Sell
Conversion rate. For example, a scale factor of
00(zero) indicates the conversion rate is an integer
(NNNNNN) with no decimal points, while a scale
factor of 02 indicates the conversion rate has 2
decimal points (NNNN.NN).
The field must be 00 through 99.
21–26 06 UN Sell Conversion Rate Base Currency equivalent to Sell one unit of
Counter Currency.
27–31 05 AN Rate Table ID Rate Table ID

The format will be ANNNN, (a leading 1-byte
alphabetic character A-Z, followed by a 4-byte
numeric value.)
32–80 49 AN Reserved Reserved for future use; set to spaces.

Edit Package History File Layout

This file contains a history of batches, files, and runs for outgoing and incoming Edit Package
processing.
The file has five record types:
l Header Record (Record Type HH)
This record controls reorganization of the history file. The History Header record appears
once, and is the first record of the file.
l Incoming Data Run Summary Record (Record Type ID)
Run Summary Record—This incoming data record summarizes incoming run information.
There is one Run Summary Record for each incoming run.
l Incoming Data File Summary Record (Record Type IF)
File Summary Record—This incoming data record summarizes incoming file information.
There is one File Summary Record for each incoming file.
l Outgoing Data Run Summary Record (Record Type OD)
Run Summary Record—This outgoing data record summarizes outgoing run information.
There is one Run Summary Record for each outgoing run.
l Outgoing Data File Summary Record (Record Type OF)
File Summary Record—This outgoing data record summarizes outgoing file information.
There is one File Summary Record for each outgoing file.
l Outgoing Unique Batch Record (Record Type OU)
These records summarize batch information. There is one Outgoing Unique Batch record for
each outgoing batch.
Record Length and Format:

256, Variable Blocked (VB)
Organization:
Sequential
Record Volume:
The number of records is dependent on the HISTRETPD run control option, which specifies the
number of calendar days to retain history files. History retention period values can be set anywhere
between 10 through 100 days, with 10 days being the default.

File Structure:
Includes a header record and detail records. A trailer record is not associated with this file.
The header record in this table determines when the file is reorganized.
History Header (HH) Record Layout
01–02 02 AN Record Type2 HH = Header record
03–10 08 UN Processing Date2 Contains zeros.
11 01 AN Mode2 Set to spaces.
12–14 03 UN Run Number2 Contains zeros.
15–17 03 UN File Number2 Contains zeros.
18–25 08 UN Reorg Date Date that the Edit Package was last reorganized.
The history file is in CCYYMMDD format.
26–29 04 AN Status GOOD = file is not corrupted
BAD = file is corrupted
30–252 223 AN Reserved Set to spaces.
The history incoming and outgoing run summary records in this table summarize incoming and
outgoing run information.
History File Incoming and Outgoing Data Run Summary Record (ID, OD)
01–02 02 AN Record Type2 ID = Incoming Data
OD = Outgoing Data
03–10 08 UN Processing Date2 Processing date of the run in CCYYMMDD format.
Incoming = BASE II Central Processing Date
Outgoing = Edit Package Processing Date
11 01 AN Mode2 P = Production
T = Test
12–14 03 UN Run Number2 Sequential number of the run within processing

date.
15–17 03 UN File Number2 This field contains zeros for run summary records.
18–25 08 UN Run Start Date System date at the start of the run expressed in
CCYYMMDD format.

History File Incoming and Outgoing Data Run Summary Record (ID, OD)
26–31 06 UN Run Start Time System time at the start of the run expressed in
HHMMSS format.
32–37 06 UN Last ITF Batch Number The last ITF batch number used for the run.
38–43 06 UN Last Center Batch Incoming = Zeros

Number
Outgoing = The last Center Batch Number
used for the run
44–46 03 UN Last File Number The last file number used for the run.
47 01 AN Rerun Flag Space = No rerun
R = Rerun was performed
48–49 02 UN Number of Reruns 00-99 = Number of reruns performed
The history incoming and outgoing file summary records in the following table summarize incoming
and outgoing file information.
History File Incoming Data and Outgoing Data File Summary Record (Record Type IF, OF)
01–02 02 AN Record Type2 IF = Incoming Data
OF = Outgoing Data
03–10 08 UN Processing Date2 Processing date of the run in CCYYMMDD format.
Incoming = BASE II Central Processing Date
Outgoing = Edit Package Processing Date
11 01 AN Mode2 P = Production
T = Test
12–14 03 UN Run Number2 Sequential number of the run within processing

date.

15–17 03 UN File Number2 File number assigned by the Edit Package.
Incoming = ITF file numbers are assigned

sequentially starting from one for
each Edit Package run
Outgoing = CTF file numbers are assigned

sequentially starting from one for
each Edit Package processing day
18–19 02 AN Collection-Only CO = Collection-Only File

Indicator
Space = Financial and Non-Financial File
20–49 30 AN Unique File ID Assigned by Visa.
50–54 05 UN CTF Processing Date Incoming = Processing date from the ITF
header in YYDDD format
Outgoing = Processing date from the CTF

header in YYDDD format, or zeros
55–59 05 AN BASE II File Type Incoming = Assigned by Visa. Valid values:
ICRPT
= Interchange Report File
NONIC
= Non-Interchange Report
File
Spaces
= Interchange Data
Outgoing = Spaces
60–62 03 UN CTF ID Incoming = Zeros
Outgoing = Client-defined in outgoing CTF

TC 90 record (Outgoing File ID),
or zeros
63–77 15 UN File Summary Incoming = Total destination amount for

Destination Amount the file
Two-digit decimal place is implied
Outgoing = Zeros
78–86 09 UN File Summary Monetary Number of monetary transactions in the file.

Transaction Count
87–96 10 UN File Summary TCR Number of TCRs in the file.

Count

97–102 06 UN File Summary Block Number of blocks in the file.

Count
103–108 06 UN File Summary Batch Number of batches in the file.

Count
109–117 09 UN File Summary Number of transactions in the file.

Transaction Count
118–132 15 UN File Summary Source Total source amount for the file. Two-digit decimal
Amount place is implied.
133–138 06 UN File Starting Batch Starting batch number for the file.
Number
139 01 AN File Continuation Incoming C = continuation of transmission

Indicator
Outgoing = Space
140–144 05 AN BASE II Customized Customized Delivery file type from the ITF TC 90
Delivery File Type header record.
(Refer to the BASE II Clearing Interchange Formats
manuals for valid values.)
145 01 AN File Financial Flag Y = Indicates file contains financial

transactions
N = Indicates file does not contain

financial transactions
146–153 8 AN First Central Processing Incoming = Central Processing Date of the

Date first file processed during the run
Outgoing = Spaces
The history outgoing unique batch record in this table contains control data for outgoing
interchange at the batch level.
History File Outgoing Unique Batch Record (Record Type OU)
01–02 02 AN Record Type2 OU = Outgoing Unique Batch
03–32 30 AN Unique File ID2 Assigned by Visa.
33–38 06 UN ITF Batch Number2 Batch number assigned by Visa to the outgoing
ITF batch.

39 01 AN Mode2 Run Control Option UNMODE
P = Production
T = Test
40–45 06 UN CTF Batch Number CTF Batch Number from Batch Trailer and zero if it
is a Visa Batch at file level.
46 01 AN Batch Status A = Accepted by the VIC
R = Rejected by the VIC
Space = No TC 44 acknowledgment has

been received from the VIC
47–61 15 UN Batch Destination Total destination amount for the batch. Two
Amount decimal places are implied.
62–70 09 UN Batch Summary Number of monetary transactions in the batch.

Monetary Transaction
Count
71–80 10 UN Batch Summary TCR Number of TCRs in the batch.

Count
81–86 06 UN Batch Summary Block Number of blocks in the batch.

Count
87–94 08 UN Center Batch ID Center Batch ID from Batch Trailer.
95–103 09 UN Batch Transaction Count Accepted Number of transactions (TC/TT) in the

batch that excludes control records.
104–118 15 UN Batch Source Amount Computed Total source amount for the batch for
accepted transactions. Two decimal places are
implied.
119 01 AN Batch Hash Flag Space or N = Batch no hashed
Y = Batch hashed
120–151 32 AN Batch Hash Total Hash value for the batch assigned by Visa.
152 01 AN Visa-Generated Batch Y = Batch generated by Visa

Flag
N = Batch generated by user
153–154 02 AN Record Type OF = Outgoing Data
155–162 08 UN Processing Date Processing date from in CCYYMMDD format.

163 01 AN Mode P = Production
T = Test
164–166 03 UN Run Number Sequential number of the run within processing

date.
167–169 03 UN File Number Sequential number of the file within processing

date.
170–171 02 AN Collection-Only CO = Collect Only File

Indicator
Space = Financial and Non-Financial File
Edit Package History Backup File

Layout
Serves as a backup file for the History File. There are two History Back up files:
First backup (BKUPA): It is overlaid by new History file at the end of every successful outgoing and
incoming run. This file is used to restore the History File in case of an error on the keyed file.
Second backup (BKUPB): It is a copy of the History file taken before the start of an outgoing and
incoming run.
Record Length:
256 bytes, Variable Block (VB)
Organization:
Sequential
Record Volume:
The number of records is dependent on the HISTRETPD run control option, which specifies the
number of calendar days to retain history files. Values can vary from 10 to 100 days, with 10 being
the default.
File Structure:
It has the same file structure as the History file.

Edit Package Incoming Run Hold File

Layout
Contains environmental data and run control options for the most recent incoming Edit Package run.
This file will be overlaid with data each time an incoming run is processed.
Record Length:
145
Organization:
Sequential
Record Volume:
50 to 100 records
File Structure:
Includes two types of records; namely, an environment record containing environmental statistics,
and an options record containing all of the permanent and temporary options.
This file is internal to Edit Package processing and is not recommended for use by a processing
center. Record layouts for this file are therefore not provided.
Edit Package Log File Layout

Contains the contents of messages recorded during Edit Package processing. The messages include
run-time and environmental information, as well as any unusual conditions warranting review.
Record Length and Format:

1024, Variable Blocked
Organization:
Sequential
Record Volume:
A log file record is created for each run. Volume of records varies depending on what run control
options are used. For example if TRACE option is turned on for the Parser, there will be trace records
for each field and each transactions in the input file.

File Structure:
This file is internal to Edit Package processing and is not recommended for use by a processing
center. Record layouts for this file are therefore not provided.
Permanent Edit Package Run Control

Options File Layout
Contains the permanent run control options that are set initially when the Edit Package software is
installed. The initial file includes all the run control options with default settings. A processing center
can customize usage of this file by modifying the default settings.
See Run Control Options for a complete list of the run control options and their default settings.
Record Length:
80
Organization:
Sequential
Record Volume:
50 to 100 records, depending on the number of options set.
File Structure:
Includes only one record type: the permanent run control options record. There are no header or
trailer records. Each keyword is on a separate record in the permanent run control options file.

Permanent Run Control Options Record Layout
Position Length Format1 Field Name Description
Begins in Varies AN Option Keyword Contains a valid permanent run control

column 01, and option keyword, followed by an equal sign
ends with an (=).
equal (=) sign.
Begins Varies AN Option Value Contains a valid value associated with the
immediately permanent run control option; is separated
after the equal by commas (,) when more than one value is
(=) sign, and used.
ends in or
before column
80.
Begins after the Varies AN Option Description Contains two required spaces, followed by
Option Value, free-form text that a processing center can
and ends in or use for comments.
before column
80.
Edit Package TC 33 Extract File Layout

This file is only used at processing centers that subscribe to receive information from Visa that is
delivered on designated TC 33 records. Information currently delivered using this technique includes:
Information currently delivered using this technique includes:
l Plus Identifier File
l Combined Visa/Plus Routing Table
l Visa Transaction Routing tables
l Interlink Identifier tables
l Visa Electron Routing Table
l Mastercard/CIRRUS Routing Table
l CIRRUS-Only Routing Table
l AFFN Routing Table
l VisaVue Solution Series Data
l ABA File
1 UN = unpacked numeric; AN = alphanumeric.

l POS Acceptance Types files

l ATM No Surcharge Routing File
Processing centers that receive more than one type of data in this file will have to use a client-written
program to separate the information.
Record Length:
168
Organization:
Sequential
Record Volume:
Depends on the services subscribed to by your center.
File Structure:
The Edit Package writes the entire TC 33 record in CTF format to this file. See BASE II Clearing
Interchange Formats manual and to documentation for the services subscribed to by your center for
more information.
Edit Package Rejected Item File

Layout
This file is created during outgoing Edit Package runs. It will contain each transaction that is rejected
(not written to the ITF or VTF) due to errors found during editing. A processing center must use the
SAVEREJECT run control option to retain rejected transactions.
With this file, processing centers can correct and resubmit invalid transactions to the edit process
without re-keying them. Correction is done either in the processing center's pre-edit system or via
the PC Edit Package.
Record Length:
168, Fixed Blocked for TC format
18000 Variable Blocked for VML
Organization:
Sequential

Record Volume:
Depends on the number of errors found during the outgoing run.
File Structure:
The file is in a CTF/VML format including:
l A file header (if the processing center has supplied a CTF/VML file header).
l An individual rejected transactions.
l A batch trailer following each batch submitted by the processing center in which there were
errors.
l A file trailer at the end of the file.
If the SAVEREJECT run control option is used with a value of R (SAVEREJECT=R), the transaction in the
Rejected Item File will include a TCR 9 containing the validation message numbers indicating what
caused the transaction to reject.
See BASE II Clearing: Interchange Formats, TC 01 to TC 49 and BASE II Clearing: Interchange Formats,
TC 50 to TC 92 for the layout of other CTF file records.
Rejected Item File TCR 9 Record
01–02 02 AN Transaction Code BASE II transaction code.
03 01 UN Transaction Code 0, 1, or 2
Qualifier
04 01 UN Transaction 9
Component Sequence
Number
05–10 06 UN Destination Identifier BASE II Destination Identifier
11–16 06 UN Source Identifier BASE II Source Identifier
21–25 05 AN Run Date Date the transaction was processed, in

YYDDD format.
26–31 06 UN Batch Number Batch number in which the transaction was

located.
32–35 04 UN Batch Sequence Sequence number of the rejected record

within the batch.
39–50 12 UN Source Amount Source amount of the rejected transaction.

Rejected Item File TCR 9 Record
51–53 03 UN Source Currency Source currency code of the rejected

transaction.
54 01 AN Settlement Flag Settlement flag of the rejected transaction.
68–71 04 AN Validation Message 1st error Validation message number

Code 1 causing the transaction to be
rejected
72–75 04 AN Validation Message 2nd error Validation message number

rejected.
76–79 04 AN Validation Message 3rd error Validation message number

rejected.
80–83 04 AN Validation Message 4th error Validation message number

rejected.

rejected.

rejected.

rejected.
96–99 04 AN Validation message 8th error Validation message number

rejected.

rejected.

rejected.

VML Rejected Item Data
Field Name Description Format Max Node VML Tag

Length
Rejected Item Data 1 X308
Destination BASE II Destination Identifier that was N 6 2 X859

Identifier the transaction destination
Source Identifier BASE II Source Identifier that was the N 6 2 X860

transaction source
Run Date Date the transaction was processed, in AN 5 2 X942

YYDDD format
Source Batch Batch number in which the N 6 2 X45

Number transaction was located
Item Sequence Sequence number of the rejected N 4 2 X46

Number (batch) record within the batch
Source Amount Source amount of the rejected N 12 2 X5

transaction
Source Currency Source currency code of the rejected N 3 2 X4

transaction
Settlement Flag Settlement Flag of the rejected AN 1 2 X9

transaction
Rejected Reason 2 X378

Codes
Rejected Reason Validation message number causing AN 4 3 X379

Code (repeatable the transaction to be rejected
10 times)
Edit Package Returned Item File

Layout
This file, which is created during incoming Edit Package runs, contains each transaction that is
returned by Visa as a result of editing at the VIC. With this file, processing centers can correct and
resubmit returned transactions to the edit process without rekeying them.
The contents of the file depend on the SAVERETURN run control option used. The file is always
written in CTF or VML format.
For TC formats, if SAVERETURN = R, transactions retain the transaction codes returned by the VIC (TC
01, TC 02, and TC 03). The TCR 9 added by the VIC is included in the file. Processing centers using the
Edit Package Data Entry System or PC Edit Package will use this format for the Returned Item File. If

SAVERETURN=T, the transaction code from the TCR 9 is restored and the TCR 9 is not included in the
file.
For VML formats, if SAVERETURN = R, transactions retain the transaction types codes returned by the
VIC . The Returned Item Data (X50) added by the VIC is included in the file. Processing centers using
the Edit Package Data Entry System or PC Edit Package will use this format for the Returned Item File.
If SAVERETURN=T, transaction types are retained but without the attribute “return” and the Returned
Item Data (X50) is not included in the file.
Record Length:
168
Organization:
Sequential
Record Volume:
Dependent on the number of returns received during the incoming run.
File Structure:
The file is in a CTF format including:
l a file header (if the user has chosen to create file headers on incoming CTFs)
l individual returned items
l batch trailers
l a file trailer at the end of the file
See BASE II Clearing: Interchange Formats, TC 01 to TC 49 and BASE II Clearing: Interchange Formats
TC50 to TC 92 for layouts of CTF file records. The layout of the TCR 9 generated by the VIC is different
from the layout of the TCR 9 generated by the Edit Package for rejected items. See the section for TC
01, TC 02, and TC 03 for returned item TCR 9 layout.
Temporary Edit Package Run Control

Options File Layout
Contains the Edit Package temporary run control options that are set by a processing center
according to its own specific needs. The temporary run control options are used as one-time
overrides against the permanent options file.
See Edit Package Run Control Options for a complete list of the run control options and their default
settings.

Record Length:
80
Organization:
Sequential
Record Volume:
0 to 100 records, depends on the number of temporary options selected.
File Structure:
Includes only one record type, namely, the temporary run control options record. There are no
header or trailer records. Each keyword is on a separate record in the temporary run control options
file.
Temporary Run Control Options Record Layout
Begins in Varies AN Option Keyword Contains a valid run control option keyword
column 01, followed by an equal sign (=).
and ends with
an equal sign
(=).
Begins Varies AN Option Value Contains a valid value associated with the run
immediately control option, and is separated by commas
after the equal (,) when more than one value is used.
sign (=), and
ends in or
before column
80.
Begins after Varies AN Option Description Contains two required spaces, followed by
the Option free-form text that a processing center can
Value, and use for comments.
ends in or
before column
80.
Edit Package Repository Profile Table

File Layout
Edit Package Repository Profile table file defines the default PROFILE parameter for Outgoing and
Incoming edit runs. The profile table defines the threads for each PROFILE parameter. The PROFILE

parameter table defines the set of run control option and its associated values for given parameter
PROFILE.
File Structure:
Each table contains a table header record, comment records, and one or more table detail records.
The first 29 positions of any record are referred to as the common prefix. This prefix, except for the
last position (the delete indicator), is the key for the record. The last field of the key contains a table
effective date. Not only does this technique assign a unique key to each record, it also permits
multiple future and past logical images of each file to be maintained in each physical file. Remaining
portions of a record may vary from table to table and from entry to entry.
Table Records:
Table records contain values (for system data tables) unique to a file table. Each record can have
multiple occurrences depending on the number of effective dates.
Edit Package Repository Value Table

File Layout
Edit Package Repository Value table files control transaction editing and report generation.
Usage:
The files contain the following types of information:
l Transaction mapping tables
l Value tables
n Country Code
n Currency Code
n Merchant Category Code
n Chargeback Reason Code Table
n Fee Reason Code
n Return Reason Code
l Run Control options
l Software update control tables
File Structure:
Each table contains a table header record, comment records, and one or more table detail records.

The first 29 positions of any record are referred to as the common prefix. This prefix, except for the
last position (the delete indicator), is the key for the record. The last field of the key contains a table
effective date. Not only does this technique assign a unique key to each record, it also permits
multiple future and past logical images of each file to be maintained in each physical file. Remaining
portions of a record may vary from table to table and from entry to entry.
Table Records:
Table records contain values (for system data tables) unique to a file table. Each record can have
multiple occurrences depending on the number of effective dates.
Edit Package Repository Table File -

Account Range Definition (ARDEF)
Table Layout
The repository file contains the ARDEF Table where ARDEF values are defined.
Record Format and Length:

Record Format = Variable Block, maximum record length = 256
Organization:
Sequential
Record Volume:
Approximately 80,000 records
File Structure:
Includes a file header record, comment record, and multiple detail records. Each record may have
multiple occurrences with different effective dates including comment records. Character “C” in the
11th position of the file signifies Comment records. Comment records are for comment purposes
only and are used to display the name for a field or column.
See ARDEF Value Table for layouts for the various records comprising the ARDEF value table.

ARDEF File Header Record Layout

ARDEF File Header record layout details include position, length, format, field name, and description.
ARDEF File Header Record Layout
01 – 02 02 AN Table Type AA = File Header Record
03 – 10 08 AN Table Mnemonic ACTRNG (left-justified, space-filled).
11 01 AN Record Type A = Table Header Record
12 – 23 12 AN Table Key EPACRN (left-justified, space-filled).
24 – 31 08 UN Effective Date Date in CCYYMMDD format.
32 01 AN Delete Indicator Blank = Not a delete record
D = Delete record (to be deleted

after the effective date specified
in the preceding field.)
33 – 36 04 AN Filler Set to spaces.
37 – 39 03 UN Release Number 400 for Release 4
40 01 AN Separator Comma
49 01 AN Filler Set to spaces.
64 – 67 04 UN Version Number Version number of the table update.
68 – 100 33 AN Reserved Set to spaces.

ARDEF Value Table

Valid values for the ARDEF Table are specified in a value table.
ARDEF Value Table Detail Record Layout
1–2 02 AN Table Type VL = Value Table Record
3–10 08 AN Table Mnemonic ACTRNG
11 01 AN Record Type R = Detail Record
12–23 12 AN Table Key The key for the record is the high range ARDEF
value. For example, 401299999.
24–31 08 UN Effective Date Date in CCYYMMDD format.

Comment records are included in the file by
setting this field to OCMMNTnn, where nn is a
number from 00 to 99.
Format records are included in the file by setting
this field to OFRMATnn, where nn is a number
from 00 to 99. These records control the
formatting of the heading and report information.

in the preceding field)
33–44 12 AN Low Key for Range The low range ARDEF value. For example,
401200000.
45–50 06 UN Issuer Identifier Reporting Issuer Identifier. For example, 401200.
51 01 UN Check Digit Algorithm 0 = No check digit validation

performe
1 = Visa modulus 10 performed
52–53 02 UN Account Number The valid values are:

Length
54 01 AN Token Indicator Valid values:
Y = Token Range

55 01 n/a Reserved This field was formerly the Usage field. It will be
56–61 06 UN BASE II CIB Member processing CIB.
62 01 AN Domain W = Worldwide
R = Regional
N = National
D = Domestic
63 01 UN Region Visa region of issuer identifier in position 45.
64–65 02 AN Country Country of issuer identifier in position 45.
66 01 AN Large-Ticket Valid values:
L = Large-Ticket

This field is formerly Issuer Commercial Card
Service Indicator (ICCSI)
67 01 AN Technology Indicator A = Chip Card
68 01 UN ARDEF Region Account range (ARDEF) region of issuer
69–70 02 AN ARDEF Country Account range (ARDEF) country of issuer
71 1 AN Commercial Card Y = Level 2 supported

Level 2 Data Indicator
space = Level 2 not supported
72 1 AN Commercial Card Y = Level 3 supported

Level 3 Enhanced Data
Indicator space = Level 3 not supported
73 1 AN Commercial Card POS Y = POS prompting required

Prompting Indicator
Note: Y is only valid if
Level 2 data is
supported.
space = POS prompting is not required
74 1 AN Commercial Card Y = Electronic VAT evidence

Electronic VAT Evidence supported
Indicator
space = Electronic VAT evidence not
supported

75 01 AN Original Credit For US issuers:
OC flag Space = Reject OC

transactions
A = Accept OC
transactions
For Non-US issuers:
OC flag Space = Accept OC

transactions
N = Reject OC
transactions
76 01 AN Account Level This field was formerly the Product Type Extension
Processing Indicator field.
Valid values:
77 01 AN Original Credit Money For US issuers:

Transfer
MT flag Space = Reject MT
transactions
A = Accept MT
transactions
For Non-US issuers:
MT flag Space = Accept MT

transactions
N = Reject MT
transactions

78 01 AN Original Credit Online For US issuers:

Gambling
OG flag Space = Reject OG
transactions
A = Accept OG
transactions
For Non-US issuers:
OG flag Space = Accept OG

transactions
N = Reject OG
transactions
79–80 02 AN Product ID For a complete list of valid values, refer to BASE II

81 01 AN Combo Card Valid values:
Y = Combo card, credit and debit
C = Combo card, credit and prepaid
Space = Not a combo card
82 01 AN Fast Funds Valid values:
Y = Domestic and Cross-Border Fast

Funds
C = Cross-Border only
Space = Does not participate in Fast

Funds
83 01 AN Travel Indicator Valid values:
Y = Travel card-capable

84–85 02 AN B2B Program ID This field indicates Business-to-Business (B2B)

Valid values:
l Spaces (Not Specified)
86 01 AN Prepaid Program This field provides additional information for

Indicator certain prepaid products.
Valid values:
1 = Consumer program in selected

markets
87–89 03 AN RRR Spaces (Reserved for future use.)

123
90 01 AN Account Funding Source C = Credit
D = Debit
P = Prepaid
H = Charge
R = Deferred Debit
91 01 AN Settlement Match B = B2B
E = B2E
92 01 AN Travel Account Data A = CTA Air
H = CTA Hotel
S = Central travel account (CTA)

Switzerland

93 01 AN Account Restricted Use A = ATM
94 01 AN NNSS Indicator Y = Issuing Identifier participates in

an NNSS
Space = Issuing Identifier does not

participate in an NNSS
Note: The NNSS indicator will not

provide information as to which NNSS the
Issuing Identifier participates in nor will it
indicate if the Issuer Identifier participates
in more than one NNSS or if a transaction
will qualify for NNSS settlement.
95–96 02 AN Product Subtype Valid values:
AC = Brazil Agriculture Maintenance

Account/Custeio
AE = Brazil Agriculture Debit

Account/Electron
AI = Brazil Agriculture Investment

Loan/Investimento
CG = Brazil Cargo
CS = Construction
DS = Distribution
GV = Government/State
Disbursement
HC = Healthcare
LP = Visa Large-Purchase Advantage

(VLPA)
MA = mVISA Agent

MX = Merchant Agent and Merchant

Payment
PP = Payroll
VA = Brazil Food or Supermarket/

Alimentacao Visa Vale
VM = Meal Voucher
VR = Brazil Food or Restaurant/

Refeicao Visa Vale
97 01 AN Alternate ATM This field indicates participation in Alternate ATM

program:
Valid values:
Y = Participate
98 01 AN Reserved Reserved for Future Use
Edit Package Repository Table File -

VID (Visa Identifier) Table Layout
The repository file contains the VID Table which is a list of valid ACQ/ISS IDs and their BASE II
processing status codes that are used to control the accuracy of Edit Package Processing.
Record Format and Length:

Record Format = Variable Block, maximum record length = 256
Organization:
Sequential

Record Volume:
66,000 records
File Structure:
Includes a file header record, comment record and multiple detail records. Each record may have
multiple occurrences with different effective dates including comment records. Character “C” in the
11th position of the file signifies Comment records. Comment records are for comment purposes
only and are used to display the name for a field or column.
VID Table File Header Layout

VID Table file header record layout details include position, length, format, field name, and
description.
VID Table File Header Record Layout
01 – 02 02 AN Table Type AA = File Header Record
03 – 10 08 AN Table Mnemonic BINTBL (left-justified, space-filled.)
11 01 AN Record Type A = Table Header Record
12 – 23 12 AN Table Key EPBINT (left-justified, space-filled.)
24 – 31 08 UN Effective Date Date in CCYYMMDD format.
32 01 AN Delete Indicator Blank = This is not a delete record
D = This is a delete record (to be

deleted after the effective date
specified in the preceding field)
37 – 39 03 UN Release Number 400 for Release 4

VID Table File Header Record Layout
64 – 67 04 UN Version Number Version number of the table update.
68 – 100 33 AN Reserved Set to spaces.
VID Table Detail Record Layout

Valid values for the VID Table are specified in a value table. Fields in positions 31 through 77 of this
record contain the attributes that are used to do edits.
1–2 02 AN Table Type VL = Value Table Record
3–10 08 AN Table Mnemonic BINTBL
11 01 AN Record Type R = Detail Record
12–23 12 AN Table Key ACQ/ISS ID for the table key.
24–31 08 UN Effective Date Date in CCYYMMDD format.

Comment records are included in the file by
setting the field to OCMMNTnn, where nn is a
number from 00 to 09.
Format records are included in the file by setting
this field to OFRMATnn, where nn is a number
from 00 to 99. These records control the
formatting of heading and report information.

in the preceding field)

33–44 12 AN Filler Set to spaces.
45–50 06 UN BASE II CIB Processing center number.
51 01 UN Region Visa region of ACQ/ISS ID in position 12.
52–53 02 AN Country Country of ACQ/ISS ID in position 12.
54 01 AN VID Type F = Full Service
I = Issuer Only
M = Merchant Only
N = Nonfinancial
O = On Behalf Of (OBO)
P = Processor
S = SMS Financial entity
V = Visa Internal entity
55 01 AN Participation Flag Blank = Not participating
A = GSA IGOTS
B = Airline
56 01 AN Visa Direct Blank = Not participating
Y = Participating
57 01 AN TIF Bypass Flag Valid values:
Y = bypass TIF
58 01 AN Multinational Merchant This field will contain an indicator to identify that

Acceptance the enrolled Multinational Merchant Acceptance
Acquring Identifier may qualify for domestic
processing.
Valid values:
Y = Acquirer is participating
Space = Acquirer is not participating

59 01 AN Domestic OCT Program This field indicates whether the Acquiring Identifier
Information Form (PIF) supports the origination of domestic OCTs other
than Money Transfer OCTs:
Valid values:
Y = Acquirer can originate domestic

Space = Acquirer cannot originate

domestic Non-Money Transfer
OCTs
60 01 AN Cross-Border OCT This field indicates whether the Acquiring Identifier

Program Information supports the origination of Cross-Border OCTs
Form (PIF) other than Money Transfer OCTs:
Valid values:
Y = Acquirer can originate Cross-


Cross-Border Non-Money
Transfer OCTs
61 01 AN OCT GEO Blocking This field indicates type of OCT GEO Blocking:
Valid values:
D = Domestic Blocking
X = Cross-Border Blocking
B = Block all OCT
Space* = No Blocking (Default)
62–98 37 AN Reserved Set to spaces

99 01 AN Test Indicator Blank = ACQ/ISS ID is valid for

production or test
T = ACQ/ISS ID is valid only for

RUNMODE=TEST
R = Responder ID
Note: Responder IDs are present in VCMS

VID Tables only
100 01 AN OBO Indicator3 Blank = Not an OBO identifier
- = OBO identifier
! = OBO Processor
ARDEF Extract File Layout

This file is produced when the EXTRACT run control is used. It contains the Account Range Definition
(ARDEF) information used by the Edit Package. This file was designed for use in client processor
systems that need ARDEF information.
Record Length:
140
Organization:
Sequential
Record Volume:
File Structure:
This file contains one record for every ARDEF that is current on the table date in effect during the
extract process.

3 On Behalf Of indicator.

ARDEF Extract File Table Layout
1–9 09 UN High Key for Range The high range ARDEF value, for example,
401299999.
10–12 03 AN Reserved Blanks
13–21 09 UN Low Key for Range The low range ARDEF value, for example,
401200000.
25–30 06 UN Issuing Identifier Reporting Issuing Identifier, for example, 401200.
31 01 UN Check Digit Algorithm 0 = No check digit validation

performed
1 = Visa modulus 10 performed

Length
34 01 AN Token Indicator Valid values:
Y = Token Range
35 01 n/a Reserved This field was formerly the Usage field. It will be
36–41 06 UN BASE II CIB Client processing center CIB
42 01 AN Domain W = Worldwide
R = Regional
N = National
D = Domestic
43 01 UN Region Visa region of Issuing Identifier in position 25
44–45 02 AN Country Country of Issuing Identifier in position 25
46 01 AN Large-Ticket Valid values:
L = Large-Ticket
Note: This field is formerly Issuer

Commercial Card Service Indicator (ICCSI)
47 01 AN Technology Indicator A = Chip Card

48 01 N ARDEF Region Account range region of issuer
49–50 02 AN ARDEF Country Account range country of issuer
51 1 AN Commercial Card Level Y = Level 2 supported

2 Data Indicator
space = Level 2 not supported
52 1 AN Commercial Card Level Y = Level 3 supported

3 Enhanced Data
Indicator Spaces = Level 3 not supported
53 1 AN Commercial Card POS Y = POS prompting required

Prompting Indicator
Level 2 data is
supported.
space = POS prompting not required
54 1 AN VAT Evidence Commercial Card Electronic VAT Evidence Indicator
55 01 AN Original Credit For US issuers:
OC flag Space
= reject OC transactions
A = accept OC transactions
For Non-US issuers:
OC flag Space
= accept OC transactions
N = reject OC transactions
56 01 AN Account-Level This field was formerly the Product Type Extension

Processing Indicator field.
Valid values:
57 01 AN Original Credit Money For US issuers:

Transfer
MT flag Space
= reject MT transactions
A = accept MT transactions
For Non-US issuers:
MT flag Space
= Accept MT transactions
N = Reject MT transactions

58 01 AN Original Credit Online For US issuers:

Gambling
OG flag Space
= reject OG transactions
A = accept OG transactions
For Non-US issuers:
OG flag Space
= accept OG transactions
N = reject OG transactions
59–60 02 AN Product ID For a complete list of valid values, refer to BASE II

61 01 AN Combo Card Valid values:
Y = Combo card, credit and debit
C = Combo card, credit and prepaid
Space = Not a combo card
62 01 AN Fast Funds Valid values:
Y = Domestic and Cross-Border Fast

Funds
C = Cross-Border only
Space = Does not participate in Fast

Funds
63 01 AN Travel Indicator Valid values:
Y = Travel card-capable


Valid values:
l Spaces (Not specified)

Valid values:

markets
67-69 03 AN RRR Spaces (Reserved for future use.)

123
70 01 AN Account Funding Source C = Credit
D = Debit
P = Prepaid
H = Charge
R = Deferred Debit
71 01 AN Settlement Match B = B2B
E = B2E
72 01 AN Travel Account Data A = CTA Air
H = CTA Hotel

Switzerland

73 01 AN Account Restricted Use A = ATM
74 01 AN NNSS Indicator Valid values:
Y = Issuer participates in an NNSS
Space = Issuer does not participate in

NNSS
Note: The NNSS indicator will not

provide information as to which NNSS the
issuer participates in nor will it indicate if
the issuer participates in more than one
NNSS or if a transaction will qualify for
NNSS settlement.
75–76 02 AN Product Subtype AC = Brazil Agriculture Maintenance

Account/Custeio

Account/Electron

Loan/Investimento
CG = Brazil Cargo
CS = Construction
DS = Distribution
Disbursement
HC = Healthcare

(VLPA)
MA = mVISA Agent


Payment
PP = Payroll

VM = Meal Voucher

Refeicao Visa Vale

program:
Valid values:
Y = Participate
Combined (ACQ/ISS ID & ARD)

Extract File Layout
This file contains combined extract of VID and ARDEF information used by Edit Package. When the
clearing entity associated with the processor is an issuer (VID types Full Service and Issuer), EP–304F
will include the corresponding ARDEF information for the Issuing Identifier if there are account
ranges for the issuer. It will include all the account ranges for that Issuing Identifier. For non-issuers,
with VID types of N (Non-financial) and M (Merchant), there will not be any associated ARDEF
information. The file will be sorted by application processor (CIB) and clearing entity (ACQ/ISS ID).
Record Length:
240

Organization:
Sequential
Record Volume:
File Structure:
This file contains one record for every ACQ/ISS ID that is current on the table date in effect during
the extract process.
Combined ACQ/ISS ID & ARD Extract File Table Layout
01–06 06 UN ACQ/ISS ID This field will contain the 6-digit Identifier.
7–24 18 AN Reserved This field will contain all spaces.
25–30 06 UN BASE II CIB This field will contain the BASE II CIB for the
ACQ/ISS ID in position 1. This field will be the
same ID in ACQ/ISS ID field for processing.
31 01 UN Region This field will contain the Visa region of ACQ/ISS

ID in position 1.
32–33 02 AN Country This field will contain the country of ACQ/ISS ID in

position 1.
34 01 AN VID Type This field will contain the VID type of the ACQ/ISS
ID in position 1.
Valid values:
F = Full Service
I = Issuer Only
M = Merchant Only
N = Nonfinancial
P = Processor
S = SMS Financial entity
V = Visa Internal entity

35 01 AN Participation Flag This field will contain the participation flag.

Valid values:
Space = (Not Participating)
B = Airline
36 01 AN Visa Direct This field will contain the Visa Direct participation
flag.
Valid values:
Space = (Not Participating)
Y = Participating
37 01 AN TIF Bypass Flag This field will contain the TIF bypass flag.
Valid values:
Space = (Do not bypass TIF)
Y = Bypass TIF
38 01 AN Domestic OCT Program This field indicates whether the Acquirer supports
Information Form (PIF) the origination of domestic OCTs other than
Valid values:


OCTs
39 01 AN Cross-Border OCT This field indicates whether the Acquirer supports

Program Information the origination of Cross-Border OCTs other than
Form (PIF) Money Transfer OCTs:
Valid values:


Transfer OCTs

Valid values:
B = Block all OCT
79 01 AN Test Indicator This field will contain the test indicator.

Valid values:
Space = (Processor is valid TEST or

production)
T = (Processor is valid only for

RUNMODE=TEST)
R = Responder ID

VID Tables only
80 01 AN OBO Indicator This field will contain the OBO Indicator.

Valid values:
Space = (Not an OBO Identifier)
- = (OBO Identifier)
! = (OBO processor)
101–109 09 UN High Key for Range This field will contain the High Range ARDEF value.
113–121 09 UN Low Key for Range This field will contain the Low Range ARDEF value.
125–130 06 UN Issuing Identifier This field will contain the Issuing Identifier.
131 01 UN Check Digit Algorithm This field will contain the check digit algorithm.
Valid values:
0 = (No check digit validation)
1 = (Visa modulus 10 performed)


Length
134 01 AN Token Indicator This field will contain the token indicator.
Valid values:
Space = (Not applicable)
Y = (Token range)
135 01 AN Reserved This field will contain all spaces.
136–141 06 UN BASE II CIB This field will contain the client processing BASE II
CIB.
142 01 AN Domain This field will contain the domain.

Valid values:
W = (Worldwide)
R = (Regional)
N = (National)
D = (Domestic)
143 01 UN Region This field will contain the Visa region of Issuing
Identifier positions 125-130.
144–145 02 AN Country This field will contain the Country of Issuing

Identifier in positions 125-130.
146 01 AN Large-Ticket This field will contain the large-ticket indicator.

Valid values:
L = (Large-Ticket)
Note: This field is formerly the Issuer

Commercial Card Service Indicator (ICCSI)
147 01 AN Technology Indicator This field contains the technology indicator.

Valid values:
A = (Chip Card)
148 01 UN ARDEF Region This field will contain Account range (ARDEF)
region of issuer.

149–150 02 AN ARDEF Country This field will contain Account range (ARDEF)
Country of issuer.
151 01 AN Commercial Card Level This field will contain the commercial card, level 2
2 Data Indicator indicator.
Valid values:
Y = (Level 2 supported)
Space = (Level 2 not supported)
152 01 AN Commercial Card Level This field will contain the commercial card, level 3
3 Enhanced Data enhanced data indicator.
Indicator
Valid values:
Y = (Level 3 supported)
Space = (Level 3 not supported)
153 01 AN Commercial Card POS This field will contain the commercial card, POS
Prompting Indicator prompting indicator.
Valid values:
Y = (POS prompting required)

Level 2 data is
supported.
Space = (POS prompting not required)
154 01 AN Commercial Card This field will contain the Commercial Card
Electronic VAT Evidence Electronic VAT Evidence Indicator.
Indicator
Valid values:
Space = (Electronic VAT evidence not

supported)
Y = (POS prompting required)

155 01 AN Original Credit This field will contain the original credit indicator.
Valid values:
For US issuers:
Space = (reject OC transactions)
A = (accept OC transactions)
For Non-US issuers:
Space = (accept OC transactions)
N = (reject OC transactions)
156 01 AN Account Level This field will contain the account level processing
Processing (ALP) (ALP) indicator.
Indicator
Valid values:
Y = Card Level Identification
Note: This field was formerly the Product

Type Extension field.
157 01 AN Original Credit Money This field will contain the original credit money
Transfer transfer acceptance indicator.
Valid values:
For US issuers:
Space = (reject MT transactions)
A = (accept MT transactions)
For Non-US issuers:
MT flag = = accept MT transactions

Space
MT flag = = reject MT transactions

N

158 01 AN Original Credit Online This field will contain original credit online
Gambling gambling acceptance indicator.
Valid values:
For US issuers:
Space = (reject OG transactions)
A = (accept OG transactions)
For Non-US issuers:
Space = (accept OG transactions)
N = (reject OG transactions)
159–160 02 AN Product ID This field will contain the Product ID.
Note: For a complete list of valid values,

refer to BASE II Clearing Data Codes.
161 01 AN Combo Card This field will contain the combo card indicator.
Valid values:
Y = (Combo card, credt and debit)
C = (Combo card, credit and

prepaid)
Space = (Not a Combo card)
162 01 AN Fast Funds This field will contain the fast funds indicator.
Valid values:
Y = (Domestic and Cross-Border

Fast Funds)
C = (Cross-Border only)
D = (Domestic Fast Funds only)
Space = (Does not participate in Fast

Funds.
163 01 AN Travel Indicator This field will contain the travel indicator.
Valid values:
Y = (Travel card-capable)


Valid values:
l Spaces (Reserved for future use)

Valid values:

markets
167–169 03 AN RRR Spaces (Reserved for future use.)

123
170 01 AN Account Funding Source This field will contain the account funding source.
Valid values:
C = (Credit)
D = (Debit)
P = (Prepaid)
H = (Charge)
R = (Deferred Debit)
171 01 AN Settlement Match This field will contain the Settlement Match
indicator.
Valid values:
B = (B2B)
E = B2E

172 01 AN Travel Account Data This field will contain the travel account indicator.
Valid values:
A = (Centralized travel account

(CTA) Air)
H = (Centralized travel account

(CTA) Hotel)

Switzerland
173 01 AN Account Restricted Use This field will contain the account restricted use
indicator.
174 01 AN NNSS Indicator This field will contain the National Net Settlement
Service (NNSS) indicator.
Valid values:
Y = (Issuer participants in an NNSS)
Space = (Issuer does not participate in

NNSS)
175–176 02 AN Product Subtype Valid values:
AC = Brazil Agriculture Maintenance

Account/Custeio

Account/Electron

Loan/Investimento
CG = Brazil Cargo
CS = Construction
DS = Distribution
Disbursement
HC = Healthcare

MA = mVISA Agent

Payment
PP = Payroll

VM = Meal Voucher

Refeicao Visa Vale

program:
Valid values:
Y = Participate
ACQ/ISS ID Extract File Layout

This file is when the EXTRACT run control option is used. It contains the Acquiring Identifier/Issuing
Identifier information used by the Edit Package. This file was designed for use in client processor
systems that need Acquiring Identifier/Issuing Identifier information.
Record Length:
140

Organization:
Sequential
Record Volume:
File Structure:
This file contains one record for every ACQ/ISS ID that is current on the table date in effect during
the extract process.
ACQ/ISS ID Extract File Table Layout
1–6 06 UN ACQ/ISS ID Six-digit ACQ/ISS ID.
25–30 06 UN BASE II CIB BASE II CIB for ACQ/ISS ID in Position 1. This field
will be the same as ACQ/ISS ID field for processing
centers.
31 01 UN Region Visa region of ACQ/ISS ID in Position 1.
32–33 02 AN Country Country of ACQ/ISS ID in Position 1.
34 01 AN VID Type F = Full Service
I = Issuer Only
M = Merchant Only
N = Nonfinancial
P = Processor
S SMS Financial entity
V Visa Internal entity
35 01 AN Participation Flag Blank = Not participating
A = GSA IGOTS
A = Airline
36 01 AN Visa Direct Blank = Not participating
Y = Participating

37 01 AN TIF Bypass Flag Valid values:
Y = bypass TIF
38 01 AN Multinational Merchant This field will contain an indicator to identify that

Acceptance the enrolled Multinational Merchant Acceptance
acquirer may qualify for domestic processing.
Valid values:
Y = (Acquirer is participating)
Space = (Acquirer is not Participating)
39 01 AN Domestic OCT Program This field indicates whether the Acquirer supports
Information (PIF) the origination of domestic OCTs other than
Valid values:


OCTs
40 01 AN Cross-Border OCT This field indicates whether the Acquirer supports

Program Information the origination of Cross-Border OCTs other than
Form (PIF) Money Transfer OCTs:
Valid values:


Transfer OCTs
Valid values:
B = Block all OCT

79 01 AN Test Indicator Blank = BASE II CIB is valid for Test or

Production
T = BASE II CIB is valid only for

RUNMODE=TEST
R = Responder ID

VID Tables only
80 01 AN OBO Indicator Blank = Not an OBO Identifier
– = OBO Identifier
! = OBO Processor
Edit Package Value Table Extract Files

Layouts
This file is produced when EXTRACT run control is used. The file can contain the following value table
information based on parameter records used.
Record Length:
140
Organization:
Sequential
Record Volume:
10 to 550 records
File Structure:
The first eight positions indicate the type of information contained on the record. There is no header
or trailer record.

Value Table Extract Country Code Table
Table Name Release 4 Table ID
BUSINESS Application ID Table BAI
Chargeback Reason Code Table CBREASON
Country Code Table COUNTRY
Currency Code Table CURRENCY
Fee Collection Reason Code Table FEERSNCD
Holiday Table HOLIDAY
List of Tables LIST
Merchant Category Code Value Table MCC
Product ID Value Table PRODID
Product Sub Type Value Table PRODSUBT
Regulated Account Range Table REGARDEF
Release Type and Description Table RELEASE
Release Module Status Table RLSTATUS
Return Item Reason Code Table RTNITEM
Transaction Code Value Table TRANCD
Edit Package Country Code Table

Contains the values of the Edit Package Country Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
250 to 300 records
File Structure:
Includes only one record type, the Country Code table record.

Value Table Extract Country Code Table (Release 4)
01–08 08 AN Table ID COUNTRY
09–10 02 AN Country Code Country Code
33 01 UN Foreign Indicator 1 = Foreign
2 = U.S. Territory
3 = U.S.
34–36 03 UN Currency Code Default currency code for the country.
37 01 AN CPS Participation C = CPS participating country

Indicator
38 01 AN ePay Participation E = ePay participating country

Indicator
39 01 AN Reserved Set to spaces
40 01 AN Area Net Participation A = Area Net participating country

Indicator
41 01 UN Region Country Region (System Internal Use)
42 01 AN CPS/ATM ARN ACQ/ID System Internal Use

Participant
43 01 AN VCR Country Migration P = Eligible to submit VCR

Status transactions in production mode.
T = Eligible to submit VCR

transactions in test mode.
Space = Not eligible to submit VCR

transactions in production or test
mode.
44 1 AN EEA Flag Y = Country falls within European

Note: EEA is Economic Area
“European
Space = Country does not fall within
Economic Area”.
EEA

Edit Package Currency Code Table

Contains the values of the Edit Package Currency Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
200 to 250 records
File Structure:
Includes only one record type, the Currency Code table record.
Value Table Extract Currency Code Table (Release 4)
01–08 08 AN Table ID CURRENCY
09–11 03 UN Currency Code ISO numeric currency

code.
12–14 03 AN Currency Code ISO alpha currency

code.
15 01 UN Decimal Place The number of minor

Indicator units for the currency.
Edit Package Holiday Table

Contains the values of the Edit Package Holiday table in sequential format.
Record Length:
140
Organization:
Sequential

Record Volume:
65 records
File Structure:
Includes only one record type, the Holiday table record.
Value Table Extract Holiday Table
01–08 08 AN Table ID HOLIDAY
09 01 UN Usage 0 = Extended Service Module
1 = Airline Program
2 = European Central Bank calendar
10–12 03 AN Table Type If the usage field is 0, this field will contain the ISO
alpha country code.
If the usage field is 1, this field will contain AI.
If the usage field is 2, this field will contain EC.
13–17 05 UN Holiday date Julian date format YYDDD.
Edit Package Merchant Category Code Table

Contains the values of the Edit Package Merchant Category Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
500 to 550 records
File Structure:
Includes only one record type, the Merchant Category Code table record.

Value Table Extract Merchant Category Code Table (Release 3)
01–08 08 AN Table ID MERCAT
09–12 04 UN Merchant Category Four-digit numeric category code.

Code:
Highest code in the range.
High Range

Code:
Lowest code in the range.
Low Range
33 01 AN Category Valid Indicator Space valid for all drafts
0 = Not valid for any draft
D = Not valid for original drafts
34 01 AN Service Category 1 = Air/Passenger Transport
2 = Car Rental
3 = Lodging
5 = ATM
7 = Amtrak
35 01 UN Travel & Entertainment 0 = Non-T&E

(T&E) Indicator
1 = T&E
36 01 UN International Airline 0 = Non-international airline

indicator
1 = International airline
01–08 08 AN Table ID MCC

Code:
Lowest code in the range.
Low Range


Code:
Highest code in the range.
High Range
17 01 AN Category Valid Indicator Space valid for all drafts.

0 Not valid for any drafts
D Not valid for original drafts.
18 01 AN Service Category 1 = Air/Passenger Transport
2 = Car Rental
3 = Lodging
5 = ATM
7 = Amtrak
19 01 UN Travel & Entertainment 0 = Non-T&E

(T&E) Indicator
1 = T&E
20 01 UN International Airline 0 = Non-international airline

Indicator
1 = International airline
21 01 AN B2B Settlement Mach Space = not eligible
1 = Eligible
Edit Package Chargeback Reason Code Table

Contains the values of the Edit Package Chargeback Reason Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
450 to 500 records

File Structure:
Includes only one record type, the Chargeback Reason Code table record.
Value Table Extract Chargeback Reason Code Table (Release 3)
01–08 08 AN Table ID REASNCD
09–10 02 UN Chargeback Reason Two-digit numeric reason code.

Code
11 01 UN Jurisdiction Jurisdiction (formerly called Region):
1 = U.S.
(use for US domestic chargeback
reason codes only, i.e. both the
issuer and merchant are in US)
2 = International
(use by all regions for interna
tional chargeback reason codes
and domestic chargeback reason
codes not covered by jurisdiction
codes 1, 3, or 4)
3 = EU
(Effective CPD 2 October 2004,
used only for chargeback reason
code 32 for UK domestic, i.e.,
both, the issuer and merchant are
in UK )
4 = AP
code 33 for AP domestic, i.e., the
issuer and the merchant are in AP
region.)
33 01 AN Chargeback Indicator C = Valid code for chargebacks
34 01 AN Chargeback Exempt E = Code is exempt from lookup

from Lookup Indicator
35 01 AN Chargeback Minimum M = Minimum dollar amount is

Dollar Amount Indicator enforced
36 01 AN Chargeback ATM A = Code not valid for ATM

Indicator transactions

37 01 AN Chargeback Express X = Code not valid for EPS

Payment Service transactions
Indicator
38 01 AN Representment R = Valid code for representments

Indicator
39 01 AN Representment Exempt E = Code is exempt from lookup

40 01 AN Representment M = Minimum dollar amount is

Minimum Dollar enforced
Amount Indicator
41 01 AN Representment ATM A = Code not valid for ATM

42 01 AN Representment Express X = Code not valid for EPS

Indicator
43 01 AN Travel & Entertainment T = Valid code for T&E

Indicator
44 01 AN Travel & Entertainment M = Minimum dollar amount is

Amount Indicator
45 01 AN Travel & Entertainment A = Code not valid for Air/

Valid Service Indicator Passenger Transport
L Valid code for Lodging only
46 01 AN Travel & Entertainment R = Member message is required

Member Message Text
Indicator
47 01 AN Custom Payment R = Valid code for CPS transactions

Service Indicator
Space = Code not valid for CPS
transactions
48 01 AN Custom Payment P = Valid code for CPS partial

Service Partial chargebacks
Chargeback Indicator
Space = Code not valid for CPS partial
chargebacks
49 01 AN Reserved

50 01 AN Old/New Edits Flag O = Old edit rules apply
N = New edit rules apply
V = Visa Claims Resolution (VCR)

rules apply
51 01 AN Valid for draft and credit Y = Reason Code is valid

vouchers flag
52 01 AN Valid for ATM MCC Y = ATM MCC is valid
N = ATM MCC is not valid
53 01 AN Source Amount M = Apply $25 source amount limit

Minimum Edit for T&E MCC transactions
2 = Apply source amount>= $10.00

for automated fuel dispenser
transactions
3 = Apply source amount> $25
54 01 AN Documentation D = Documentation Indicator edit is

Indicator edit enforced for invalid acquirer
reference number and supporting
documentation requirement
1 = Documentation Indicator edit is

enforced for supporting
documentation
55 01 AN MOTO/ECI edit 1 = MOTO/ECI edit is enforced for

card-not-present transactions
2 = MOTO/ECI edit is enforced for

secure electronic commerce
transactions
56 01 AN Merchant Category 1 = MCC edit is enforced for card-

Code edit not-present transactions
2 = MCC edit is enforced for

telecommunication services
transactions
3 = MCC edit is enforced for certain

transactions

57 01 AN EPS edit I = EPS is not valid
01–08 08 AN Table ID CBREASON
09–10 02 UN Chargeback Reason Two-digit numeric reason code.

Code
11 01 UN Jurisdiction Jurisdiction (formerly called Region):
1 = U.S.
(use for US domestic chargeback
reason codes only, i.e. both the
issuer and merchant are in US)
2 = International
(use by all regions for interna
tional chargeback reason codes
and domestic chargeback reason
codes not covered by jurisdiction
codes 1, 3, or 4)
3 = EU
code 32 for UK domestic, i.e.,
both, the issuer and merchant are
in UK )
12 01 AN Chargeback Indicator C = Valid code for chargebacks
13 01 AN Chargeback Exempt E = Code is exempt from lookup

14 01 AN Chargeback Minimum M = Minimum dollar

Dollar Amount Indicator
15 01 AN Chargeback ATM A = Code not valid for ATM

Indicator
16 01 AN Chargeback Express X = Code not valid for EPS

Payment Service
Indicator
17 01 AN Representment R = Valid code for representments

Indicator

18 01 AN Representment Exempt E = Code is exempt from lookup

19 01 AN Representment M = Minimum dollar amount is

Amount Indicator
20 01 AN Representment ATM A = Code not valid for ATM

21 01 AN Representment Express X = Code not valid for EPS

Indicator
22 01 AN Travel & Entertainment T = Valid code for T&E

Indicator
23 01 AN Travel & Entertainment M = Minimum dollar amount is

Amount Indicator
24 01 AN Travel & Entertainment A = Code not valid for Air/

Valid Service Indicator Passenger Transport
L = Valid code for Lodging only
25 01 AN Travel & Entertainment R = Member message is required

Member Message Text
Indicator
26 01 AN Custom Payment R = Valid code for CPS transactions

Service Indicator
Space = Code not valid for CPS
transactions
27 01 AN Custom Payment P = Valid code for CPS partial

Service Partial chargebacks
Chargeback Indicator
Space = Code not valid for CPS partial
chargebacks
P
28 01 AN Reserved
29 01 AN Old/New Edits Flag O = Old edit rules apply
N = New edit rules apply
30 01 AN Valid for draft and credit Y = Reason Code is valid

vouchers Flag

31 01 AN Valid for ATM MCC Y = ATM MCC is valid
N = ATM MCC is not valid
32 01 AN Source Amount M = Apply $25 source amount limit

Minimum Edit for T&E MCC transactions
2 = Apply source amount>= $10.00

for automated fuel dispenser
transactions
3 = Apply source amount> $25
33 01 AN Documentation D = Documentation Indicator edit is

Indicator Edit enforced for invalid acquirer
reference number and supporting
documentation requirement
1 = Documentation Indicator edit is

enforced for supporting
documentation
34 01 AN MOTO/ECI Edit 1 = MOTO/ECI edit is enforced for

card-not-present transactions
2 = MOTO/ECI edit is enforced for

secure electronic commerce
transactions
35 01 AN Merchant Category 1 = MCC edit is enforced for card-

Code Edit not-present transactions
2 = MCC edit is enforced for

transactions
3 = MCC edit is enforced for certain

transactions
36 01 AN EPS edit I = EPS is not valid
37 01 AN Reserved
38–41 4 AN Canadian Minimum Used to determine Chargeback minimum amount

Amount value (Internal Use Only)

Edit Package Transaction Code Table

Contains the values of the Edit Package Transaction Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
80 to 100 records
File Structure:
Includes only one record type, the Transaction Code table record.
Value Table Extract Transaction Code Table
01–08 08 AN Table ID TRANCD
09–10 02 UN Transaction Code Two-digit numeric transaction code.
33 01 AN Outgoing Indicator 0 = Valid for outgoing transactions
34 01 AN Incoming Indicator I = Valid for incoming transactions
35 01 AN OBO Transaction B = On Behalf Of transaction

Indicator
36 01 AN Future Date Indicator D = Future date edit required
37 01 AN Original Indicator O = Original draft transaction

(TC 05, 06, 07)
38 01 AN Cash Indicator C = Cash transaction (TC 07, 17, 27,

37)
39 01 AN Reversal Indicator R = Draft reversal transaction

(TC 25, 26, 27)
40 01 AN Fee/Fund Indicator F = Fee collection or funds

disbursement transaction (TC10,
20)

41 01 AN Chargeback Indicator C = Chargeback transaction (TC15,

16, 17, 35, 36, 37)
42 01 AN Financial Indicator F = Financial transaction
Q = Quasi-financial transaction
(TC57, 59)
43 01 AN Request for Copy R = Request for Copy transaction

Indicator (TC51, 52, 53)
44 01 AN Transaction Status A = Batch acknowledgment

Indicator
B = End of batch
C = Currency file
D = Data capture
F = End of file
G = General delivery
H = File Header
I = Interface transaction advice
P = Plus Identifier
R = Report generation
T = Table update
X = Data capture
Y = Data capture
45 01 AN Returned Item Indicator R = Returned item (TC 01, 02, 03)
46 01 AN Monetary Indicator B = Monetary flag
47 01 AN Default Print Indicator 0 = Do not print transaction
1 = Print transaction
48 01 AN Default Pass Indicator 0 = Do not pass transaction
1 = Pass transaction

49 01 AN Print Valid Values 0 = Transaction not valid for print

Indicator
1 = Transaction always printed
2 = Transaction print default may

be overridden
50 01 AN Pass Valid Values 0 = Transaction not valid for pass

Indicator
1 = Transaction always passed
2 = Transaction print default may

be overridden
51 01 AN Maximum TCR Indicator 0–9 = Maximum TCRs allowed
52 01 AN Edit Type Indicator 1 = Chargeback
53 01 AN Source Identifier/ M = Valid for merchants on

Microfilm Ref. Number outgoing
Edit:Merchant Only
Indicator
54 01 AN Source Identifier/ I = Valid for issuers on outgoing

Microfilm Ref. Number
Edit:Issuer Indicator
55 01 AN Source Identifier/ N = Valid for nonfinancial Identifiers

Microfilm Ref. Number on outgoing
Edit:Nonfinancial
Indicator
56 01 AN Destination Identifier/ M = Valid for merchants on

Account Number outgoing
Edit:Merchant Only
Indicator
57 01 AN Destination Identifier/ I = Valid for issuers on outgoing

Account Number
Edit:Issuer Indicator
58 01 AN Destination Identifier/ N = Valid for nonfinancial Identifiers

Account Number on outgoing
Edit:Nonfinancial
Indicator

Edit Package Fee Reason Code Table

Contains the values of the Edit Package Fee Reason Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
50 to 100 records
File Structure:
Includes only one record type, the Fee Reason Code table record.
Value Table Extract Fee Reason Code Table (Release 3)
01–08 08 AN Table ID FCRSNCD
09–12 04 UN Fee Reason Code Four-digit numeric fee reason code.
33 01 AN State/Country Code 0 = State or country code not

Indicator allowed
1 = State or country code is

required
34 01 AN Incoming/Outgoing 0 = Valid for incoming or outgoing

Indicator
1 = Valid for incoming only
35 01 AN Account Number 0 = Account number must be valid

Indicator
1 = Account number must be zeros
36–42 07 UN Max Dollar Amount 9999999 = No limit
0000000– = Dollar limit (for example,

9999998 0010000 = 100 dollar limit)

43 01 AN Visa-Generated 0 = Non-Visa-generated
Indicator
1 = Visa-generated
44–140 97 AN Fee Reason Code Code description.

Description
01–08 08 AN Table ID FEERSNCD
09–12 04 UN Fee Reason Code Four-digit numeric fee reason code.
21–32 12 UN Max Dollar Amount 999999999999 = No limit
000000000000– = Dollar limit (for

999999999998 example, 0010000 = 100
dollar limit)
33 01 AN State/Country Code 0 = State or country code not

Indicator allowed
1 = State or country code is

required
34 01 AN Incoming/Outgoing 0 = Valid for incoming or outgoing

Indicator
1 = Valid for incoming only
35 01 AN Account Number 0 = Account number must be valid

Indicator
1 = Account number must be zeros
43 01 AN Visa-Generated 0 = Non-Visa-generated
Indicator
1 = Visa-generated
44–140 97 AN Fee Reason Code Code Description

Edit Package Return Reason Code Table

Contains the values of the Edit Package Return Reason Code table in sequential format.
Record Length:
140
Organization:
Sequential
Record Volume:
400 to 500 records
File Structure:
Includes only one record type, the Return Reason Code table record.
Value Table Extract Return Reason Code Table
01–08 08 AN Table ID RTNITEM
09–11 03 AN Return Reason Code Two-character return reason code.
33–72 40 AN Return Reason Code Description Code description.
Edit Package Regulated Account Range Table

Extract
Contains Regulated Account Range Table in sequential format.
Record Length:
140
Organization:
Sequential

Record Volume:
8000 to 10000 records
File Structure:
Includes only one record type, the Regulated Account Range table record.
Regulated Account Ranges Table
01–08 08 AN Table ID REGARDEF
09–26 18 UN Regulated ARDEF High Range Regulated ARDEF High Range
27–44 18 UN Regulated ARDEF Low Range Regulated ARDEF Low Range.
Edit Package Business Application ID (BAI) Table

Extract
Contains Business Application ID Table in sequential format
Record Length:
140
Organization:
Sequential
Record Volume:
20 to 40 records
File Structure:
Includes only one record type, the Business Application ID table record.
Business Application ID (BAI) Table
01–03 03 AN Table Name “BAI”
04 01 AN Space Space

Business Application ID (BAI) Table
05–06 02 AN BAI Value BAI Value
08–09 02 AN BAI Class BAI Class
11–50 40 AN BAI Name BAI Name/Description
51–140 90 AN Reserved Space

Appendix C
Summary of Edit Package Reports
This appendix contains a summary of all reports generated by the Edit Package.
Reports generated by the Edit Package will be identified by the prefix EP, followed by a three-digit
number. The reports are grouped in categories according to the numbering scheme shown in the
following table.
Report Numbering Scheme
Report Series Report Type
100–199 Outgoing Reports
200–299 Incoming Reports
300–399 On-Request Reports
700–799 Optional Transaction-Based Reports
999 Index of Reports
For reports that provide totals at different levels, the report ID includes an alphabetic extension to
represent the totalling levels. The extensions are as follows:
A—Transaction detail level
B—Batch/ACQ/ISS ID level

C—File/Center level
D—Central Processing Date (CPD)
E—Run Level
F—Cycle Level
A separate set of alphabetic identifiers applies to transaction-based reports, which depend on run
control options supplied. The extensions for transaction-based reports are as follows:
V—Visa-generated
N—Non-Visa-generated
C—Combined Visa-generated and non-Visa-generated
S—Standard format
E—Enriched format
Outgoing Edit Package Reports

Control reports are created after the Center Transaction File (CTF) is validated during the outgoing
process. These reports are produced automatically during an outgoing run.
Outgoing Interchange Reports
Report ID Report Title and Function
EP–100A Validation Exception:

EP–100B Displays outgoing interchange transactions rejected by the validation subsystem within the Edit
Package. The summaries are by ACQ/ISS ID and center.
EP–100C
EP–110B Outgoing Interchange Summary:

EP–110C Provides an audit trail of outgoing interchange summarized by transaction type. The transaction
summaries are by batch, file, and run. A final summary is also produced for all financial and
EP–110E
nonfinancial transactions.
EP–110F
EP–111C Outgoing Interchange by Currency:

EP–111E Provides an audit trail of outgoing interchange in situations where there are multiple currencies
or settlement types. The summaries are by file and run.
EP–120F Outgoing ITF Summary by Volume:

Provides an audit trail of outgoing interchange in situations where there are multiple output ITFs
due to volume limitations.

Outgoing Interchange Reports
EP–199 Outgoing Processing Log:

Reports all system activity during outgoing runs.
EP–999 Index of Reports:

Lists the number of pages produced for each Edit Package report ID. Should there be no report
printout, it lists the report ID and name, but the number of pages is null.
Incoming Edit Package Reports

Reports for control and reconciliation are produced during the incoming process. These reports are
produced automatically during an incoming run.
Incoming Interchange Reports
Validation Exception:
EP–200A
Displays any transaction errors that occur during incoming processing. The summaries are by
EP–200B
ACQ/ISS ID and center.
EP–200C
BASE II Returned Item:

EP–204A
Reports erroneous transactions returned by the VIC, with the exception of the Chargeback
EP–204B
Reduction Service (CRS) returned items. The reports give transaction detail, ACQ/ISS ID
EP–204C summaries, and processing center summary.
CRS—Returned Item:
EP–206A
Reports erroneous transactions returned by the VIC that are part of the Chargeback Reduction
EP–206B
Service (CRS). The summaries are by ACQ/ISS ID and processing center.
EP–206C
Incoming Interchange Summary:

EP–210B
Provides an audit trail of incoming interchange summarized by transaction type. The summaries
EP–210C
are by batch, file, CPD, and run. A final summary is also produced for all financial and
EP–210D nonfinancial transactions.
EP–210E
EP–210F
Incoming Interchange by Currency:

EP–211C
Provides an audit trail of incoming interchange in situations where there are multiple currencies
EP–211D
or settlement types. The summaries are by file, CPD, and run.
EP–211E

Incoming Interchange Reports
Collected Reconciliation Summary:

EP–220
Confirms the collection of outgoing batches from the previous cycle, indicates any batches
rejected by the VIC, and flags any discrepancies between VIC information and Edit Package
history information.
Collected Batch Acknowledgments:

EP–221B
Confirms the collection of outgoing batches from the previous cycle by reporting the details of
EP–221D
the batch acknowledgment transactions (TC 44s). The reports provide detail for batches,
EP–221E summary for the run, and CPD.
Interchange Transaction File Distribution:

EP–230
If selected by run control options, it provides an audit trail of incoming interchange after it has
been split into multiple member-requested CTFs.
Fee Summary Reports:

EP–240C
Summary of Fee Collection (Transaction Code 10) and Fund Disbursement (Transaction Code 20)
EP–240N
transactions by Fee Reason Code. Based on the FEERPTFMT run control option. Either a
EP–240V combined report or separate reports of Visa and non-Visa-generated fees are produced.
Incoming Processing Log:

EP–299
Reports all system activity during incoming runs.
Index of Reports:
EP–999
printout, it lists the report ID and name, but the number of pages is null.
Edit Package On-Request Reports

On-request reporting utilities are available to print formatted reports of the contents of internal Edit
Package files.
On-Request Reports
EP–300 History File Summary: Prints the contents of the History File .
EP–301 ACQ/ISS Validation Table: Prints the contents of the ACQ/ISS Validation table.
EP–302 Account Range Table: Prints the contents of the Account Range table .
EP–303 Rule and Value Tables: Prints the contents of the Rule and Value tables.
EP–399 Log File: Lists all system activity logged on the system log file.

Optional Transaction-Based Reports

in Edit Package
Some reports are selectively produced during incoming and outgoing Edit Package processing.
Reports are selected by specifying run control options. Unformatted reports precede the Draft Data
Transaction Reports on this list.
Returned Item Reports:

EP–701
Displays record data in TC 01, TC 02, and TC 03 transactions.
EP–702
EP–703
Reclassification Advice:
EP–704
Displays record data in TC 04 transactions.
Draft Data Transaction Reports:

EP–705
EP–706
EP–707
EP–715
EP–716
EP–717
EP–725
EP–726
EP–727
EP–735
EP–736
EP–737
EP–710C Fee Collection Reports:

EP–710N Displays record data in fee collection transactions (Transaction Code 10).
EP–710V
EP–709 Money Transfers:

EP–719 Displays record data in TC 09 and TC 19 transactions.
EP–720C Funds Disbursement Reports:

EP–720N Displays record data in funds disbursement transactions (Transaction Code 20).
EP–720V

ICS Input:
EP–730
ICS Response:
EP–731
RDMS Message or CRS Advices:

EP–733
Dispute Financial Report:

EP–733F
Copy Request Service Messages:.

EP–738
Displays record data in request for copy message transactions (Transaction Code 38).
Automated Copy Fulfillments:

EP–739
Displays record data in electronically delivered fulfillments (Transaction Code 39).
Fraud Advice:
EP–740
Displays record data in outgoing fraud advice transactions (Transaction Code 40).
Merchant File Update Record 1:

EP–742
Displays record data in the merchant file update information record 1 transactions (Transaction
Code 42).
Merchant File Update Record 2:

EP–743
Displays record data in merchant file update record 2 transactions (Transaction Code 43).
Collection Batch Acknowledgments:

EP–744
Displays record data in batch acknowledgment transactions (Transaction Code 44).
General Delivery Report Records:

EP–745
Transaction code 45s contain formatted reports from Visa service applications. The formatted
reports are written to a separate file (EP745).
Member Settlement Data:

EP–746
Displays record data in member settlement data transactions (Transaction Code 46).
Report Generation Records:

EP–747
Transaction code 47s contain formatted VIC Settlement Reports. The formatted reports are
written to a separate file (EP747).
BASE I Advices—Format 2 Chip Informational Advice:

EP–748C
Displays record data in BASE I advice file transactions (Transaction Code 48), format 2.

BASE I Advices (ISO-Enriched):

EP–748E
Displays record data in ISO-enriched BASE I advice file transactions (Transaction Code 48 in ISO-
enriched format).
BASE I Advices (Standard):

EP–748S
Displays record data in standard BASE I advice file transactions (Transaction Code 48 in standard
format).
EP–749 Local Batch Acknowledgement Report:

Text Messages:
EP–750
Displays record data in text message transactions (Transaction Code 50).
Requests for Original:

EP–751
Displays record data in request for original paper (sales draft, credit voucher, or cash advance)
transactions (Transaction Code 51).
Requests for Copy:

EP–752
Displays record data in request for copy of original paper (sales draft, credit voucher, or cash
advance) transactions (Transaction Code 52).
Confirmation Responses:
EP–753
Displays record data in confirmation of requested mailing transactions (Transaction Code 53).
Table Update Data:

EP–754
Regional Card Recovery File Records/RCRF Message:

EP–755
Displays Regional Card Recovery File (RCRF) transactions received from the VIC (Transaction
Code 55).
Currency Conversion Rates:

EP–756
Displays record data in currency conversion rate transactions (Transaction Code 56).
Data Capture Transaction Advice:

EP–757
Displays record data in data capture advice transactions (Transaction Code 57).
National Settlement Advices:

EP–758
Displays record data in National Settlement Advice transactions (Transaction Code 58).
Interface Transaction Advice:

EP–759
Displays record data in interface advice transactions (Transaction Code 59).
Tape Header:
EP–790

Batch Trailer:
EP–791
File Trailer:
EP–792
Index of Edit Package Reports

The source for information on reports for a particular run is listed.
Index of Reports
Index of Reports:
EP–999
printout, it lists the report ID and name, but the number of pages is blank.

Appendix D
Edit Package Print/Pass Defaults
BASE II transaction codes have print/pass defaults.
Print/Pass Defaults for BASE II Transaction Codes
Incoming
Transaction Financial Incoming/ Outgoing Print

Code and Type Transaction Outgoing (I/O) Default Print Default Pass Default
00: Short Block No I n/a No Print No Pass
01: Returned
Credit Yes I n/a Print No Pass
02: Returned
Debit Yes I n/a Print No Pass
03: Returned
Nonfinancial No I n/a Print No Pass
04: Reclassifi
cation Advice No I n/a Print No Pass
05: Sales Draft or

Representment Yes I/O No Print No Print Pass1
06: Credit
Voucher Yes I/O No Print No Print Pass1

Incoming

07: Cash
Disbursement Yes I/O No Print No Print Pass1
09: Money
Transfer Yes I/O No Print No Print Pass1
10: Fee Collection Yes I/O No Print No Print Pass1
15: Sales Draft

Chargeback Yes I/O No Print No Print Pass1
16: Credit
Voucher
17: Cash
Disbursement
19: Money
Transfer Yes I/O No Print No Print Pass1
20: Funds
Disbursement Yes I/O No Print No Print Pass1
25: Sales Draft

Reversal Yes I/O No Print No Print Pass1
26: Credit
Voucher Reversal Yes I/O No Print No Print Pass1
27: Cash
Disbursement
30: ICS Input No O No Print n/a n/a
31: ICS Response

Transaction File No I n/a No Print Pass
33: RDMS
Message or CRS
Advices No I n/a Print No Pass
35: Sales Draft

Chargeback

Incoming

36: Credit
Voucher
Chargeback
37: Cash
Disbursement
Chargeback
38: Copy Request

Service Message No I/O No Print No Print Pass
39: Automated
Copy Fulfillment No I/O No Print No Print Pass
40: Fraud Advice No I/O No Print Print No Pass
42: Merchant File

Update No O No Print Print No Pass
43: Merchant File

Update No O No Print Print No Pass
44: Collection
Batch Acknowl
edgment No I n/a No Print1 No Pass1
45: General
Delivery Report No I n/a n/a2 No Pass
46: Member
Settlement Data No I n/a No Print2 Pass1
47: Report
Generation No I n/a n/a2 No Pass1
48: BASE I Advice No I No Print Print No Pass
49: Local Batch

Acknowledgment No I n/a No Print n/a
50: Free Text

Message No I/O No Print Print No Pass
51: Request for

Original Paper No I/O No Print Print No Pass
52: Request for

Photocopy or
Substitute Draft No I/O No Print Print No Pass

Incoming

53: Photocopy/
Original Mailing
Confirmation No I/O No Print Print No Pass
54: Table Update

Data No I n/a No Print No Pass1
55: RCRF Update No I n/a Print No Pass
56: Currency
Conversion Rate
Update No I n/a Print No Pass
57: Data Capture

Transaction
Advice No I/O No Print No Print Pass
58: National
Settlement
Advice No I/O No Print Print Pass
59: Interface
Transaction
Advice No I/O No Print No Print Pass
90: File Header No I/O No Print No Print n/a3
91: Batch Trailer No I/O No Print No Print1 Pass1
92: File Trailer

No I/O No Print No Print1 Pass1
1The default value cannot be changed.
2These reports are produced automatically and are not applicable for the TCINPRT and TCNOINPRT run control
options.
3Thesetransactions are controlled by the WRITEHEADR run control option and are not applicable for the TCPASS
and TCNOPASS run control options.

BASE II Glossary
account funding source Identifies the source of the funds associated with the primary account for the
card.
For example, credit, debit, prepaid, and charge.
account number extension A three-position extension of the account number that allows account numbers
up to 19 digits in length.
account prefix The first nine digits of a cardholder account number.
account prefix range The set of a low-account prefix and a high-account prefix that defines the range
of cardholder account numbers used by an issuer. (A single issuer may use more
than one range.) All ranges are maintained on the ARDEF Table for cardholder
account number and Issuing Identifier validation purposes.
account restricted use Identifies whether any processing restriction exists for the account range.
acquirer A client financial institution that has agreements with merchants to accept Visa
card transactions or offers cash disbursement services to cardholders, or both.
The acquirer is responsible for:
l Accepting card transaction data from merchants and its own ATMs and bank
branches.
l Providing authorization decisions to those card-accepting locations.
l Conveying transaction information to Visa as interchange transactions.
acquirer center A BASE II processing center supporting one or more Visa acquirers. The
processing center receives transaction information from merchants and cash
dispensing locations on behalf of acquirers; processes local transactions and
sends interchange transactions to a VIC for distribution to the issuer processing
centers; and settles the value of transactions with merchants and agents and, for
interchange transactions, with other clients through the BASE II System.
Acquirer Reference Number A 23-digit identification number associated with every draft and voucher. It
consists of a Format Code, Acquiring Identifier, Capture Date, Film Locator, and
Check Digit.

administrative messages All transactions that pass information between processing centers but do not
result in debits or credits in the settlement process.
Advice File The BASE I file containing records of authorization and verification responses
generated at the VIC.
ARDEF File The permanent file for the ARDEF (Account Range Definition) Table, which is used
to control the accuracy of Edit Package processing. The table contains all valid
ARDEF entries, namely: the account prefix range, its associated Issuing Identifier,
card-number length indicator, check-digit indicator, product ID and account
funding source..
balancing and reconciliation The process of accounting for the number and amount of transactions and the
currency of each transaction in a BASE II cycle.
BASE I System See V.I.P. System.
BASE II CIB A six-digit system number used by Visa to identify the processing centers and
clients. Center Identification Blocks (CIBs) are assigned to processing centers
operated by clients, nonclient processing centers designated by clients, and the
clients that operate processing centers.
Note: The BASE II CIB of a given processing center does not necessarily appear in the cardholder account
numbers processed by that center.
BASE II processing center See processing center.
BASE II System An electronic batch transmission system primarily used for the exchange of Visa
interchange transaction data and for settlement of the value of those transactions
between acquirers and issuers. This system is also used by centers to retrieve
records from the Advice File and by Visa to settle various fees with clients.
batch A set of transaction records, terminating with a batch trailer, sent through BASE II.
batch acknowledgment A receipt confirmation generated at a VIC of each batch of outgoing transactions.
transaction These transactions are received in the center's incoming Interchange Transaction
File.
batch reject See rejected batch.
batch trailer record A record designating the end of a batch of BASE II transactions. It contains count
and monetary totals used to control the integrity of the batch's transaction data.
See also merchant batch trailer record.

Bill Payment Service A service allowing a client to accept payment from a Visa cardholder whose
account belongs to another client and to credit the issuer through BASE II. Both
the issuer and the client receiving the payment must be in the same country.
Used in Canada and Brazil.
billing currency The currency in which the issuer bills the cardholder for transactions.
card issuer processing center See issuer center.
Card Recovery Bulletin (CRB) A paper listing, published and distributed by Visa, that contains Visa account
numbers for which card pickup is required.
cardholder processing center See issuer center.
cash advance The disbursement of cash from an ATM, bank teller, or authorized merchant
based on use of a Visa or Plus card.
cashback field A nine-digit field that specifies the currency amount that is paid out when a
purchase transaction occurs.
Center Transaction File (CTF) The outgoing Center Transaction File contains interchange transactions generated
by a processing center's pre-edit program. If the format is acceptable to the Edit
Package, it is converted to an ITF and is submitted to the VIC.The incoming
Center Transaction File contains ITF data transmitted from the VIC through the
VAP to the Edit Package for processing. If there are no errors, the ITF is converted
to a CTF and used as input to the post-edit program.
central processing date (CPD) The date (based on GMT) when the ITF or report in question was generated at a
VIC.
copy/original A copy of a transaction requested from the acquirer center by the issuer center.
(Synonymous with original/photocopy.)
collection-only transactions (1) An intraprocessor transaction submitted to BASE II for collection only (not
settlement or delivery). Normal BASE II processing charges and interchange
reimbursement fees do not apply to collection-only transactions.
chargeback A sales draft or other item that has been examined by the issuer center, found to
be improper, and sent back to the acquirer center with other outgoing
interchange.
Chargeback Reduction Service A worldwide service that provides acquirers and issuers with information available
(CRS) from other VisaNet systems to reduce the number of unnecessary chargebacks
and representments and the time needed to research valid chargebacks.

chargeback reversal The cancellation of a chargeback sent in error to the acquirer center.
check digit A digit added to the end of an account number or Acquirer Reference Number
that is derived from a computation using a predetermined formula and the
preceding digits of the account number. It is used during editing processes to
validate account numbers and Acquirer Reference Numbers.
Chip Card See Integrated Circuit Card.
Chip Debit/Credit See Visa Smart Debit/Visa Smart Credit (VSDC).
clearing All of the functions required to collect a transaction from an acquirer in the
merchant's currency and deliver it to the issuer in the cardholder's currency.
Clear Only Clearing Service Only Transactions.
Coll Only Collection-only Transactions.
CPD See central processing date (CPD).
CRB See Card Recovery Bulletin (CRB).
credit voucher Sometimes referred to as credit return, it is the record of a return or price
adjustment of a purchase.
CRS See Chargeback Reduction Service (CRS).
CTF See Center Transaction File (CTF).
currency conversion rate This rate is applied by Visa International to certain transactions (original sales
drafts, representments, travel vouchers, credit vouchers, and cash disbursements)
and the reversal of such transactions.
currency of purchase See transaction currency.
currency trading cutoff The time at which currency conversion rates expire.
Custom Payment Service (CPS) A Visa payment service that minimizes chargebacks and facilitates transaction
clearing and settlement by assigning a unique identifier that stays with the
transaction throughout its life cycle.
Custom Merchant Service A service that tailors interchange reimbursement fees to specific merchant
categories.

DBA The “doing business as” name of the merchant. (The DBA name is required in all
BASE II records that include merchant ID to ensure cardholder recognition.)
Data Capture Service Merchants' use of electronic terminals at points of sale (POS) to capture sales
transaction data. Clients can receive reports on transactions that have occurred at
each merchant location.
Data Capture Advice A batch transaction that delivers data for transactions captured at merchant
locations to the acquirer center for subsequent submission to BASE II.
descriptive billing A billing method in which the cardholder receives a statement containing a
descriptive section of information identifying the card acceptor (merchant, bank
branch or business location) and the nature of each charge or credit for each
transaction posted to the account. Copies of the original paper are not returned
to the cardholder.
designated currency One of the currencies that may be chosen by a client for settlement and funds
transfer.
destination Identifier An Identifier to which a BASE II transaction message is sent.
destination currency The currency type presented to the client on incoming transactions. For most
transactions (that is, drafts), it is the billing currency. For other transactions, for
example, fee collection and chargeback, it is the settlement currency of the
destination.
DEX See Direct Exchange
Direct Exchange (DEX) Direct Exchange provides a single, secure, and extensible Internet Protocol (IP)-
based connection to the VisaNet network for all Visa USA endpoints.
documentation request See Request for Copy of transaction.
draft data transaction A BASE II financial transaction that contains data for a cardholder transaction and
results in a debit or a credit to clearing clients during the settlement process.
EA Server See Visa Extended Access Server.
Early Delivery Service Option by which transaction data is delivered to the processing center before
settlement is completed.
Edit Package The computer programs supplied by Visa International to processing centers to
validate interchange data, produce the file containing all interchange data to be
sent from the processing center to Visa, and process the file of incoming
transactions received from Visa.

Edit Package processing date The date used by the Edit Package during a specific run. This can be the
computer's system date or a date specified on the RUNDATE run control option.
electronic terminal A point-of-sale terminal, an automated teller machine, or a cash dispensing

machine used at the point of transaction to generate electronic impulses that are
captured in computer-readable form.
Extended Access Server See Visa Extended Access Server.
fee collection transaction A BASE II transaction representing a miscellaneous financial charge assessed by
one client or by Visa against another client.
File Correction Service A facility invoked at the discretion of Visa management to reverse incorrect
financial transactions submitted by a processing center. All financial transactions
in an entire file or one or more selected batches may be reversed.
File Distribution Service The receipt of files through BASE II based on an arrangement that best meets the
client's needs and processing schedules. It can distinguish and simultaneously
process interchange, nonfinancial, and settlement data. It can separate report
delivery from interchange processing.
file trailer record A record designating the end of a CTF or ITF. It contains count and monetary
totals used to control the integrity of file content. A CTF is terminated with one
file trailer record regardless of the number of volumes used to contain the data;
an ITF on tape is terminated with a file trailer record at the end of each volume, if
multiple volumes are needed.
file transfer Electronic transfer of an ITF between the PC Edit Package and the VAP.
file header record A record designating the beginning of an CTF or ITF. It contains the processing
center ID, security code, and relevant control information.
financial controls Those controls surrounding general ledger activities and procedures relating to
bank card accounting.
floor limit The maximum dollar amount for a transaction without having to obtain
authorization.
fraud advice transaction A BASE II transaction sent by a center to notify Visa of the possible fraudulent use
of a card. Sent only with outgoing interchange transactions from the issuer
center.
freeform text message See text message.

funds disbursement transaction A BASE II transaction used to transfer monetary credit from one BASE II entity to
another or to reverse a fee collection transaction.
CPS See Custom Payment Service (CPS).
History File The Edit Package file used to store the history of outgoing and incoming
processing runs, and to control reruns and assign batch numbers for multiple
daily runs.
host computer(s) The computer system used at the processing center to process BASE II
interchange or BASE I inquiries, or both, and other authorization-related
messages.
IAF See International Acquiring Fee.
ICC See Integrated Circuit Card.
ICS See Issuers' Clearinghouse Service (ICS).
ICS input/response transaction A BASE II transaction sent (input) or received (response) by a center participating
in the Issuers' Clearinghouse Service.
incoming interchange All BASE II transactions transmitted from a VIC to a processing center, or the
entire process of receiving incoming interchange transaction data from a VIC.
Integrated Circuit Card A plastic card embedded with a silicon chip that has greater storage capabilities
than a magnetic stripe allowing for more robust functionality and multiple
accounts to reside on one physical card.
interchange processing The electronic movement of transaction data between acquirers and issuers.
Interchange Reimbursement Fee A fee paid by issuers and acquirers to each other for transactions entered into
(IRF) interchange (and their reversals) to balance the cost of doing business.
interchange transaction Any transaction where the client that signed the cardholder submits transactions
through a different processing center than the client that signed the merchant.
Interchange Transaction File The outgoing Interchange Transaction File contains transactions sent to VisaNet
(ITF) by an endpoint. This file may be created by the outgoing Edit Package after the
endpoint's pre-edit processing, or it may be sent directly to VisaNet.
The incoming Interchange Transaction File contains transactions delivered to an

endpoint by VisaNet. This file may be read by the Edit Package prior to the
transaction being processed by the endpoint's post-edit processing, or it may be
directly processed by the endpoint.

interface transaction advice A notice to certain non-Visa card issuers of transactions captured by Visa
terminals at merchant locations. These notices are created by the terminal
provider and are transmitted through the BASE II System to non-Visa card issuers.
International Acquiring Fee An optional regional fee paid by the acquirer when a transaction occurs outside
(IAF) the issuer's country. It may be assessed for Sales Draft (TC 05) original and
representment, Cash Disbursement (TC 07) original and representment, TC 05 and
TC 07 reversals and their SMS Visa or Plus Network equivalent transactions.
International Airline Program A program that permits acquirers of merchants designated by Visa as
international airlines to deposit transactions outside the country where the
transactions occurred.
international airline transactions International Airline Program transactions in which the issuer and merchant are
not in the same country.
International Outgoing See International Acquiring Fees.

Interchange (IOI) fee
International Service The International Service Assessment (ISA) fee applies to international BASE II and
Assessment (ISA) SMS clearing transactions in which the issuer country is different from the
merchant country.
interregional transaction A transaction where the merchant and issuer are not in the same Visa region.
intraprocessor transaction A transaction where the acquirer and the issuer are two different clients but both
are serviced by the same processor.
intraregional transaction A transaction where the merchant and issuer are in the same Visa region but are
not in the same country.
IOI fee See International Acquiring Fees (IAF).
IRF See Interchange Reimbursement Fee (IRF).
ISA See International Service Assessment (ISA).
issuer A client financial institution that issues Visa cards. For a given transaction, the
institution that issued the card used for that transaction to the cardholder. The
issuer is responsible for maintaining the accounts of its cardholders, for providing
authorization decisions, for cardholder billing, and for settlement of transactions
its cardholders have with merchants and cash dispensing locations of other
clients. Each issuer operates or designates an issuer center to perform the
functions related to clearing and settlement of interchange transactions.

issuer center A BASE II processing center acting in support of one or more issuers. The
processing center processes completed cardholder transactions (local and
interchange) for cardholder account posting and billing. For completed
interchange transactions, the center is also responsible for receiving and
processing incoming transactions for the cardholders of the issuer or issuers.
Issuers' Clearinghouse Service A service developed to curtail the fraudulent or excessive use of credit card
(ICS) applications and the fraudulent use of credit cards. Issuers may access or update
the ICS database through BASE II.
ITF See Interchange Transaction File (ITF).
Julian date A date expressed as the day's position in a year rather than in a particular month.
The format is YDDD or YYDDD.
local airline transaction International Airline Program transactions in which the issuer and merchant are in
the same country.
media request See Request for Copy transaction.
member settlement data An incoming transaction used to transmit settlement report data in machine-
transaction readable format.
merchant batch header record The header record in a data capture advice that carries merchant batch data.
merchant batch trailer record The trailer record in a data capture advice that carries merchant batch data.
Merchant Mailing File A file at the VIC containing the names, addresses, and other pertinent
information for merchants who receive the Card Recovery Bulletin.
Merchant Mailing File The BASE II transaction used by processing centers to update the Merchant
transaction Master File. It is transmitted from acquirer centers to a VIC.
Merchant Master File A computer record of information on all merchants serviced by a center. This file
is maintained at the processing center.
merchant processing center See acquirer center.
multicurrency clearing The clearing of transactions where clients enter financial transactions into BASE II
in the currency as signed by the cardholder, and receive cleared transactions
converted to the issuer's billing currency. This results in uniform conversion rates
for all issuers for the processing day.

National Net interchange Transactions that are exchanged between processing centers whose issuers and
acquirers are located in the same country where settlement is accomplished
through a central agent bank for each country using the service. BASE II clears
the transactions and records transaction totals on National Net interchange
reports.
national settlement transaction A National Net transaction.
national transaction A transaction in which the merchant, issuer, and acquirer are all in the same
country.
net settlement amount The currency amount representing the difference between a settlement entity's
outgoing and incoming interchange for a given day plus or minus fees and
charges. May be a debit or a credit.
nonfinancial transaction A nonmonetary transaction that supports the bankcard business, for example, a
request or confirmation of a photocopy, freeform message, BASE I Advice record,
Merchant Mailing File update, data capture advice, and Issuers' Clearinghouse
Service inquiry or response.
on-us transactions Drafts, vouchers, and other items where the client that signed the merchant also
signed the cardholder, or where the client that signed the merchant and the client
that issued the card have both designated the same processing center.
optional issuer fee An optional additional currency fee that is requested by the issuer and collected
as part of the billing amount, if desired by the issuer. This fee is not included in
the settlement amount. It may be a debit or a credit.
original transaction In the BASE II System, the first presentation of a purchase, credit, or cash advance
submitted into interchange.
original/photocopy See copy/original.
outgoing interchange All BASE II transactions transmitted from a client's processing center to a VIC.
Both acquirer and issuer centers send outgoing interchange.
Plus An automatic teller machine (ATM) network to which Visa clients have access.
Plus Identifier File A file containing Plus table update records that is created through incoming Edit
Package processing for all clients subscribing to the Plus ATM system. The Plus
Table contains numbers of Plus card issuers.

post-edit program Software written and maintained by a processing center to restructure an

incoming Center Transaction File into a format acceptable for the local posting
and billing process and to apply client-unique edit criteria against the
transactions. This program is executed following the incoming Edit Package run.
pre-edit program Software written and maintained by a processing center to separate on-us items
from interchange items and to apply client-unique edit criteria against the
transactions. This program also formats outgoing interchange into the outgoing
Center Transaction File for processing by the Edit Package according to BASE II
specifications. This program is executed before the outgoing Edit Package run.
presentation See presentment.
presentment Paper (or a transaction) submitted for the first time by an acquirer to an issuer
and processed through VisaNet interchange.
processing center The entity, operated or designated by a clearing client of Visa, responsible for
processing of interchange transactions. It executes the Edit Package and the pre-
or post-edit programs, or both, and sends and receives interchange transactions
to and from a VIC. A single processing center may function as an acquirer center,
an issuer center, or both. It performs interchange transaction services for one
client or a multiple number of clients. Most BASE II processing centers are
operated by Visa clients; nonclient processing centers may be authorized to
process Visa transactions.
processing date See central processing date (CPD) or Edit Package processing date.
proof and capture The process of determining that each deposit or group of deposits balances, and
the process of recording standard information from each draft, voucher, and
transaction in a form acceptable for editing and processing.
PSIRF See Payment Service Interchange Reimbursement Fee (PSIRF).
RCRF See Regional Card Recovery File (RCRF).
Regional Card Recovery File A file of cardholder account records, created by Visa every week for international
(RCRF) users, that contains all BASE I Exception File pickup accounts coded for a given
CRB region, plus specified “Region 0” accounts listed by issuers in that CRB
region. Users receive an RCRF as part of the incoming BASE II interchange
transaction file.
reimbursement attribute A one-digit alphanumeric code designating reimbursement fees applicable to a

specific transaction.

reimbursement fee Amount paid by one client to another (usually by the acquirer to the issuer), and
can vary according to market requirements.
rejected batch An interchange batch that is not accepted by the VIC due to an error in the audit
integrity of that batch.
rejected transaction An outgoing BASE II transaction record in which the Edit Package detected an
error that affects the financial integrity of the batch. The Edit Package excludes
such transactions from outgoing interchange, that is, the transaction is not
included in the outgoing Interchange Transaction File forwarded to a VIC. (The
batch is not rejected; all valid transactions in the batch are included in the
outgoing Interchange Transaction File.)
Unless the transaction is a batch or file trailer record, the run aborts.
re-presentation See representment.
representment Paper (or a transaction) submitted by an acquirer to an issuer a second time,

following receipt of a chargeback.
Request for Copy transaction A transaction generated when an issuer requests for a copy of the original
transaction, followed by a confirmation that records the sending of the copy. Also
known as a documentation or media request.
returned transaction A cardholder transaction record in which the VIC edit function detected an error
that does not violate the financial integrity of the batch. When such an error is
detected, the transaction is included in the outgoing batch interchange totals (in
a separate category), but it is not forwarded to the issuer center. The transaction
is placed in a new BASE II transaction, with a new transaction code, and returned
to the originating center with incoming interchange. (On the incoming reports for
an originating center, the transactions appear both in outgoing and in incoming
totals.)
reversal A BASE II transaction used to negate or cancel a transaction that has been sent
through interchange in error.
settlement The actual transfer of funds from the issuing bank to the acquiring bank through
a wire transfer to a settlement account, and the total amount owed by one Visa
client to another. See also net settlement amount.
settlement currency The currency used by the BASE II System to calculate a settlement entity's daily
net settlement position.
Single Message System (SMS) See V.I.P. System.

source currency The currency type associated with the amount of a transaction entered into
interchange.
source Identifier The Identifier from which a BASE II transaction message is sent.
special airline fee A fee charged on transactions from International Airlines whenever the issuer,
acquirer, and transaction countries are not all the same. This fee is collected
instead of the IAF fee and is paid to the transaction region.
Stand-In Processor (STIP) For BASE I processing. The function operating at all VICs that provides
authorization decisions on behalf of BASE I card issuers. It acts for transactions in
amounts below the issuer limit, when the issuer center is unavailable, when a
request sent to the issuer center times out, or when a local switch requests STIP
processing.
For SMS processing. The function that makes authorization decisions for
authorization and financial requests on behalf of issuer centers. It acts only when
the issuer center is unavailable or when a request has timed out.
STIP See Stand-In Processor (STIP).
substitute draft or substitute A computer-generated version of a sales draft, including items such as account
transaction receipt number, merchant name and location, purchase date, transaction amount,
authorization code, and a description of the goods and services.
suspense A series of general ledger accounts containing drafts and vouchers and other
items that have been rejected by either the processing center's editing programs
or the Edit Package.
system log A VAP disk file that contains messages recording significant events related to
BASE II operations, including net settlement information and all operator actions
and their acknowledgments. (All valid dial terminal inquiries and responses and
the error messages generated by all VAP subsystems are also included.) When
BASE II transmission to or from the VIC completes, the log can be archived to the
center's host computer and center-designed reports may be generated.
TC 33 Extract File A file containing Routing table update records that is created through incoming
Edit Package processing for all clients subscribing to the Plus ATM system. The TC
33 Extract Table contains Plus card issuing Identifiers.
TCR See Transaction Component Record (TCR).
text message An unformatted message exchanged between processing centers, or sent by Visa,
through the BASE II System.
third-party processor See processing center.

transaction BASE II transaction. The record or records that make up a single financial,
administrative, or text message, as required for transmission between a
processing center and a VIC. BASE II transactions are identified by transaction
codes.
Cardholder transaction. The use of a card by a customer (normally assumed to be

the cardholder) to purchase goods or services from a merchant or secure cash
from an ATM or financial institution.
transaction charges Charges paid by clients to Visa for processing services. Transaction charges vary
depending on transaction type and volume.
transaction code (TC) A two-digit code that identifies a specific type of BASE II transaction.
Transaction Component Record A fixed-length record used to contain a component portion of a BASE II
(TCR) transaction. A single BASE II transaction may consist of multiple TCRs.
transaction component A single digit placed in each TCR so multiple records (TCRs) can be combined into
sequence number a single BASE II transaction.
transaction currency The currency of the purchase, as agreed to by the cardholder and the merchant.
VAP See VisaNet Access Point (VAP).
VFG See Visa File Transfer (VFG).
VIC See VisaNet Interchange Center (VIC).
VIC processing date See central processing date (CPD).
VID Table File The permanent file for VID Table, which is used to control the accuracy of Edit
Package processing. The table contains all valid Acquiring/Issuing Identifiers and
their BASE II processing status codes.
V.I.P. System An electronic data transmission system for the real-time delivery and processing
of messages related to authorization of bank, T&E, private label, and proprietary
card and check acceptance transactions. It accepts authorization requests from
acquirer and merchant authorization centers and either provides authorization
decisions or secures authorization decisions from the issuer authorization centers.
The V.I.P. System is made up of the Single Message System (SMS) and BASE I
System.
Visa Extended Access Server The Visa Extended Access Server is the next-generation gateway to Visa products
and services, replacing legacy VisaNet Access Points. The EA Server offers
improved security and a flexible platform for future updates.

Visa File Gateway (VFG) Visa File Gateway (VFG) is an interface type used to electronically transfer
interchange data and Edit Package maintenance files between your processing
center and Visa.
Visa Smart Debit/Visa Smart A payment service involving the use of chip cards and chip capable card
Credit (VSDC) acceptance devices providing a variety of features to support offline
authorization, protect against fraud, enhance cardholder verification, and provide
a platform for multifunction programs.
VisaNet Access Point (VAP) An IBM personal computer supplied by Visa, at which the VisaNet network is
accessed electronically by a processing center. A VAP is in direct communication
with a VIC. BASE II data are generally transmitted or received through a VAP.
VisaNet Copy Request and An automated service that facilitates the exchange of copy requests and their
Fulfillment Service (VCRFS) fulfillments through VisaNet.
VisaNet Interchange Center The computers and all associated peripheral devices and telecommunications
(VIC) support facilities needed for the V.I.P. System, the BASE II System, related systems
(such as CRB and CWB), and backup for these systems.
warehoused transactions Transactions received at the VIC after the settlement window closes. These
transactions are held over for next-day settlement at the new rates.

Base II Clearing Ep Release 4 Operations Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Base II Clearing Ep Release 4 Operations Guide

Uploaded by

Copyright:

Available Formats

BASE II Clearing Edit Package

Effective: 15 April 2023

Visa Supplemental Requirements

© 2010-2023 Visa. All Rights Reserved.

Chapter 2 • How BASE II Clearing Edit Package Works

Edit Package Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Mainframe and PC Edit Package for Windows. . . . . . . . . . . . . . . . . . . . . 17

PC Edit Package for Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Edit Package Processing Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

Edit Package Outgoing Processing. . . . . . . . . . . . . . . . . . . . . . . . . .19

Edit Package Incoming Processing. . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 3 • BASE II Clearing Edit Package Installation

Supported Platforms and Operating Systems for Edit Package. . . . . . . . . . . . . . . 24

Edit Package Mainframe Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Mainframe Edit Package Operational Requirements. . . . . . . . . . . . . . . . . . 26

Edit Package Mainframe Installation Package Overview. . . . . . . . . . . . . . . . . 28

Subscribe to Edit Package Release 4. . . . . . . . . . . . . . . . . . . . . . . 29

Change Management (CM) Option. . . . . . . . . . . . . . . . . . . . . . . .29

Prepare for Edit Package Mainframe Installation. . . . . . . . . . . . . . . . . . . . 31

Install Edit Package Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Modify and Run Job to Link Object Modules in Edit Package. . . . . . . . . . . . 37

Modify the Install Utility Job in Edit Package. . . . . . . . . . . . . . . . . . . .37

Modify the Options File in Edit Package. . . . . . . . . . . . . . . . . . . . . .38

Execute the INSTALL Job and Verify Output in Edit Package. . . . . . . . . . . . . 40

15 April 2023 Visa Confidential 3

Execute Final Setup Job in Edit Package. . . . . . . . . . . . . . . . . . . . . .47

Verify Edit Package Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Understanding the Initial Test Plan for Edit Package. . . . . . . . . . . . . . . . 48

Execute an Outgoing Run Using TC Format in Edit Package. . . . . . . . . . . . . 48

Execute an Incoming Run Using TC Format in Edit Package. . . . . . . . . . . . . 50

Executing an Outgoing Run Using VML in Edit Package. . . . . . . . . . . . . . . 52

Executing an Incoming Run Using VML in Edit Package. . . . . . . . . . . . . . . 54

Edit Package Release 3 and Release 4 Differences. . . . . . . . . . . . . . . . . . . . . 56

Edit Package Processing Related Documentation. . . . . . . . . . . . . . . . . . . . . 57

Edit Package Run Control Options Customization. . . . . . . . . . . . . . . . . . . . . 58

Chapter 4 • Edit Package Outgoing Processing Cycle

Edit Package Outgoing Input Requirements. . . . . . . . . . . . . . . . . . . . . . . 61

Edit Package Outgoing System Initialization. . . . . . . . . . . . . . . . . . . . . . . 62

Edit Package Outgoing Files Creation. . . . . . . . . . . . . . . . . . . . . . . . . . 63

Edit Package Outgoing Exception, Control, and Summary Report Production. . . . . . . . . 65

Edit Package History File Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Edit Package Outgoing Log Report Production. . . . . . . . . . . . . . . . . . . . . . 65

Edit Package Outgoing Exception Conditions. . . . . . . . . . . . . . . . . . . . . . . 65

Edit Package Outgoing Run Severe Errors. . . . . . . . . . . . . . . . . . . . . . .66

CTF/VML Errors in Edit Package. . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Edit Package Outgoing Messages. . . . . . . . . . . . . . . . . . . . . . . . . . 66

Edit Package Outgoing Run Error Types. . . . . . . . . . . . . . . . . . . . . . . 67

Edit Package Outgoing Processing Files. . . . . . . . . . . . . . . . . . . . . . . . . 68

Edit Package Repository Table Files. . . . . . . . . . . . . . . . . . . . . . . . . 74

Edit Package Currency Conversion Rates File (Optional). . . . . . . . . . . . . . . . .75

Edit Package History File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Edit Package Rejected Item File. . . . . . . . . . . . . . . . . . . . . . . . . . . 76

15 April 2023 Visa Confidential 4

Edit Package Log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Edit Package Incoming Run Hold File. . . . . . . . . . . . . . . . . . . . . . . . 76

Edit Package Backup Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Edit Package Work and Sort Files. . . . . . . . . . . . . . . . . . . . . . . . . . 77

Edit Package Report Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

Outgoing Edit Package Processes Controlled By Run Control Options. . . . . . . . . . . . 78

Outgoing Edit PackageE Processes Controlled by Data (TC Formats). . . . . . . . . . . . . 79

Chapter 5 • Edit Package Incoming Processing Cycle

Edit Package Incoming Input Requirements. . . . . . . . . . . . . . . . . . . . . . . 83

Edit Package Incoming System Initialization. . . . . . . . . . . . . . . . . . . . . . . 84

Edit Package Incoming CTF/VML Creation. . . . . . . . . . . . . . . . . . . . . . . . 86