NDC Emv 3.0.0 PDF

APTRA™ Advance NDC
EMV™ Integrated Circuit Card (ICC)
Reference Manual
B006‐6297‐H000
Issue 2
January 2012
Confidential and proprietary information of NCR.
Unauthorised use, reproduction and/or distribution is strictly prohibited.
Copyright and Trademark Information
The products described in this document are copyrighted works of NCR Corporation.
NCR and APTRA are trademarks of NCR Corporation.
Microsoft, Windows is a registered trademark of Microsoft Corporation in the United States and/or other countries.
IBM and OS/2 are registered trademarks of International Business Machines Corporation.
Adobe and Reader are registered trademarks of Adobe Systems Incorporated.
All other trademarks are the property of their respective owners.
This publication supports the NCR ‘EMV/CAM2 Exits for APTRA Advance NDC’ single and multi‐vendor products
for Microsoft Windows XP and Windows 7.
Disclaimer:
It is the policy of NCR Corporation to improve products as technology, components, software and firmware become
available. NCR therefore reserves the right to change specifications without prior notice.
All features, functions and operations described herein may not be marketed by NCR in all parts of the world. In some
instances, photographs are of equipment prototypes. Therefore, before using this document, consult with your NCR
representative or NCR office for information that is applicable and current.
To maintain the quality of our publications, we need your comments on the accuracy, clarity, organisation and value of
this book.
Address correspondence to:
NCR Financial Solutions Group Ltd
Information Solutions Feedback
Discovery Centre
3 Fulton Road
Dundee, Scotland
DD2 4SW
© 2012
By NCR Corporation
Duluth, Georgia, USA
All Rights Reserved
Federal Communications Commission (FCC) Radio Frequency Interference Statement
Federal Communications
Commission (FCC) Radio Frequency
Interference Statement
Note: This equipment has been tested and found to comply with
the limits for a Class A digital device, pursuant to Part 15 of the
FCC Rules. These limits are designed to provide reasonable
protection against harmful interference when the equipment is
operated in a commercial environment. This equipment
generates, uses, and can radiate radio frequency energy and, if not
installed and used in accordance with the instruction manual,
may cause harmful interference to radio communications.
Operation of this equipment in a residential area is likely to cause
harmful interference in which case the user will be required to
correct the interference at his own expense.
This digital apparatus does not exceed the Class A limits for radio
Canadian Class A Device noise emissions from digital apparatus set out in the Radio
Declaration Interference Regulations of the Canadian Department of
Communications.
Le présent appareil numérique n’émet pas de bruits
radioélectriques dépassant les limites applicables aux appareils
numériques de la classe A prescrites dans le Réglement sur le
brouillage radioélectrique édicté par le ministère des
Communications du Canada.
This equipment must be installed and used in strict accordance with
Information to User the manufacturer’s instructions. However, there is no guarantee
that interference to radio communications will not occur in a
particular commercial installation. If this equipment does cause
interference, which can be determined by turning the equipment off
and on, the user is encouraged to consult an NCR service
representative immediately.
Caution NCR Corporation is not responsible for any radio or television
interference caused by unauthorised modifications of this
equipment or the substitution or attachment of connecting cables
and equipment other than those specified by NCR. Such
unauthorised modifications, substitutions, or attachments may void
the user’s authority to operate the equipment. The correction of
interference caused by such unauthorised modifications,
substitutions, or attachments will be the responsibility of the user.
APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual iii
iv APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual
Revision Record
Date Page Description Of Change
January 1‐6, 1‐11, Added explanatory notes about the Transaction

2012 1‐12 Request EMV/CAM2 Exits Data.
4‐5 Removed a paragraph from the text about the
Transaction Request message which was
perceived as incorrect.
November 2011 Updated to support ‘EMV/CAM2 Exits for
APTRA Advance NDC’ (Release 03.00.00),
including user feedback.
1‐5 Updates to floor limit checking.
1‐6 A sub‐heading for the Brand Approval process
has been added to Host Processing.
1‐7 Add reference to configure Track 2 data using
Local Track Data Settings.
1‐8 Added information that Begin ICC Initialisation
State can be used after EMV Smart DIP Take
Card.
1‐10 Add support for ’Enable for Error’ value.
1‐13 No longer necessary to reboot the terminal to
change debug trace settings.
1‐15 Added support for disabling masking.
2‐1, State type ’T’ included as a standard state.
2‐5 Updates to Terminal Risk Management and the
Terminal Floor Limit object.
2‐6 Added support for registry values.
2‐10 Clarified that there is no track data available
during this state processing.
2‐12 Begin ICC Initialisation State ‐ updates to table
entries 2 to 4.
2‐22 The Begin ICC Application and Initialisation
State data has been defined and the maximum
state number correctly documented as 999.
APTRA Advance NDC, EMV ICC Reference Manual v

2‐xx All Next State numbers now have Base 36
Alphanumeric ranges.
2‐30 Added support for disabling terminal action
analysis using the registry.
2‐40 Added description of when re‐initialisation is
not required.
2‐41 Added three new table entries 4 to 6 and
equivalent registry settings.
2‐43 Add beeper control to EMV Smart DIP Take
Card State description.
2‐46 Added EMV Application Switch State.
4‐8 Byte 2, bit 3 amended. Bit descriptions amended.
4‐10 New value B99.
4‐11, 4‐14 The term Device Identifier Graphic has been
standardised.
4‐13 Updates to EMV Hardware error message
4‐14 Added section Errors During Chip Power‐Up
5‐17 The example for application candidate build
processing has been improved.
5‐19 Added the recommendation that full AID values
should be used.
5‐21 The last Entry Number in the table has been
updated to 0A hex to show its position in the
sequence.
5‐24 Added new sub‐section for local setting of fields
f18 to f21.
5‐25 Added new registry option for customisation
data.
5‐26, Transaction Reply fields applicable to NDC+
5‐27, 7‐14 have been removed.
5‐28 Cross‐reference to new section on Authorisation
Response Codes added
5‐31 Buffer Length field amended to have valid
length of 08, 0c or 20 hex.
User Defined Buffers and User Defined
Functions renamed as Buffer Identifiers and
Function Identifiers respectively.
5‐32 The example of non‐standard function
identifiers has been updated.
7‐7 Added new Element Names ‐ Interface Device
Serial Number and Issuer Script Results.
7‐8 Added new Element Names ‐ Terminal
Identification and Terminal Floor Limit.
vi APTRA Advance NDC, EMV ICC Reference Manual

7‐18 Description of the On‐line PIN Entered Flag
updated to say this only is set to 1 if the CVM
chosen was On‐line enciphered PIN, and CVM
processing is successful.
7‐32 A note added into completion of the EMV
transaction to GENAC 1.
7‐40 Field 11 of Offline Decline Journal Message
updated to 0D hex and example amended for the
Terminal Action Code Denial object.
7‐41, 7‐42 Registry entry ’Disable PCI Mask’ added.
7‐44, 7‐45 Extended Journal Tracing description amended
with a new level.
7‐46 Updated the description of ICC Processing
Termination.
7‐47 to Added a new section ‐ Authorisation Response
7‐49 Codes.
7‐50 to Added a new section ‐ Windows Registry
7‐52 Settings.
C‐4 Reference papers for Visa International and
MasterCard International updated.
D‐3, D‐4 startapps.vbs removed, STCONT
variants replaced by STCONT, INICONT added.
All References to the Using NDC Exits publication
have been updated to refer to the Extending the
Product publication.
All Added support for Windows 7.
All Removed references to NDC+.
June 09 ‐ Updated to support ‘EMV/CAM2 Exits for
APTRA Advance NDC’ (Release 02.02.xx),
including user feedback.
APTRA Advance NDC, EMV ICC Reference Manual vii

1‐3 Data Integrity checking now compliant with
EMV standards
1‐7 Added clause about fallback not supported in
some situations.
1‐8 Fallback ‐ add link to EMV Smart DIP Take Card
State.
1‐8, 1‐9 Update offline declined next state handling.
1‐10 Added link to Printing EMV Data Values.
1‐13 Updated Debug Log section
1‐14 Added list of objects which are not traced for
security reasons.
1‐15 Update section on debug log tracing.
Chap 2 Increase state range to 999.
2‐2 DASH generalised to Smart DIP, and
throughout.
2‐5 Transaction Request ‐ added link to offline
processing.
2‐9 Update PIN Entry Initiation State description.
2‐28 Updated Registry key for read records.
2‐32 Added link to Voice Guidance
2‐35 Update Set ICC Transaction Data State
description.
2‐39, 2‐40 Update ICC Re‐initialise State description.
2‐41 Add EMV Smart Dip Take Card State.
4‐8 Add partial CAM flags processing.
4‐13 Updated Card Reader error reporting
5‐16 Update EMV Configuration message description
5‐26, 5‐29 Add Transaction Data Objects Update Buffer.
5‐31 Add User defined buffers.
5‐32 Add note about behaviour for existing Function
Ids.
6‐2 Updated Supervisor menus
7‐10 Add section on Printing EMV Data Values.
7‐22 Add Voice Guidance tag processing.
7‐27 Add Dynamic Currency Conversion.
7‐34 Updated ICC Application Journal Error
Message.
7‐37 Updated offline Journal Processing
7‐41 Add Extended Journal Tracing.
C‐5 Updated Other Reference Documentation
‐ Simplified Revision Record by removing details
of changes prior to Release 02.01.00.
page ‐xxi In ‘What Experience Should I Have?’, added

v EPP courses, and APTRA Advance NDC,
Overview (B006‐6597). Removed CD‐ROM
Course No. 25636, as no longer available.
viii APTRA Advance NDC, EMV ICC Reference Manual

7‐36 Clarified how journal print example includes
Track 2 data.
Appendi In ‘Advance NDC Documentation’, updated
xC references to new/renamed APTRA Advance
NDC documentation.
In ‘Other Documentation’, simplified EMV 4.1
specification titles/descriptions.
Appendi In ‘U’ EMV Smart Card, added U0057 to U0059
xE and U0100 to U0105 reserved screens.
Mar 07 ‐ Updated to support ‘EMV/CAM2 Exits for
APTRA Advance NDC’ (Release 02.01.00).
Changed ‘NDC+ and APTRA Advance NDC’ to
‘APTRA Advance NDC and NDC+’ to
de‐emphasise NDC+.
Changed Europay to MasterCard, as Europay
International acquired by MasterCard
International.
Removed Easy Entry processing as no longer
supported.
Changed Terminal Action Code (TAC) ‐ Decline
to TAC ‐ Denial.
page ‐xxii Clarified abbreviations in new table.
page ‐xxi Updated pre‐requisite NCR training course

v numbers/titles. Added APTRA Advance NDC,
Multi‐Vendor Support Reference Manual.
1‐3, 5‐8, Changed Europay to MasterCard.
5‐20, 7‐4
1‐4 In ʺTerminal Action Analysisʺ, added that
TAC‐Online and TAC‐Default are set to
‘FFFFFFFFFF’.
1‐5 In ʺTerminal Risk Managementʺ, added floor
limit checking.
1‐6 Added ʺHost Processingʺ section.
1‐14 For Advance NDC, replaced ʺLogging
Mechanismʺ with new ʺTracing Mechanismsʺ
section, covering journal and Debug Log tracing.
1‐16 Added ʺEMV Checksumʺ section.
Updated registry key
2‐2 Added ʺT ‐ Card Read ‐ PIN Entry Initiation
Stateʺ to table, and amended Note on use.
APTRA Advance NDC, EMV ICC Reference Manual ix

2‐4 In ʺG ‐ Amount Check Stateʺ, simplified
description and added reason for use.
2‐5 Updated ʺI ‐ Transaction Request Stateʺ section.
2‐9 Added new ʺT ‐ Card Read ‐ PIN Entry Initiation
Stateʺ section, including flow diagram and
points for consideration.
2‐12 In ʺ+ ‐ Begin ICC Initialisation Stateʺ, updated
table entry 6.
2‐15 Updated ʺICC Initialise and Candidate List
Buildʺ overview procedure, and added
ʺCanadian List Filteringʺ sub‐section.
2‐18 Updated ʺ, ‐ Complete ICC Initialisation Stateʺ
section.
2‐22 In ʺ. ‐ Begin ICC Application Selection &
Initialisation Stateʺ, added table entry 6. In Exit
Paths Extension State, added table entry 7.
2‐29 Updated ʺICC Application Select & Initialise
Processingʺ section.
2‐31 Updated ʺ/ ‐ Complete ICC Application
Selection & Initialisation Stateʺ section.
3‐2 In ʺEnhanced Configuration Parameters Load
Messageʺ, updated option 69 values and added
bit 4.
4‐2 In ʺTerminal Application Version Informationʺ,
added NDC Interface component ‘INT’.
4‐4 In ʺTerminal Hardware Informationʺ, removed
unsupported CIM86 smart card variants 12 to
19. Added smart card variants 1F and 20.
4‐8 In ʺCAM Flagsʺ, added new ‘Transaction
declined offline’ flag.
4‐10 In ʺCommand Rejectsʺ, B95 is now Reserved.
4‐15 In ʺICC Application Solicited/ Unsolicited Error
Messageʺ, updated Note 2 on bit 1 of option 69.
5‐25 Added new ʺDefault EMV Customisation Dataʺ
section.
5‐26 In ʺTransaction Replyʺ, Note 2: and Note 3:,
added why transaction response cryptogram
and code fields are optional.
In Note 3:, added ARC value 30 30 effect.
x APTRA Advance NDC, EMV ICC Reference Manual

6‐1, 6‐2 In ʺOverviewʺ and ʺSupervisor
Menus/Functionsʺ, added that Miscellaneous
Functions option is available in APTRA
Advance NDC and NDC+.
6‐2 In supervisor function ʺ0 PRNT CMPNT VERSʺ,
updated example to ICC version 02.01.00.
Added that NDC Interface component version is
not printed.
7‐6 In ʺTerminal Specified BER‐TLV Data Objectsʺ,
added that this table lists all the automatically
populated objects.
7‐16 In ʺTerminal Verification Results (TVR)
Processingʺ, updated On‐line PIN Entered Flag
(byte 3 bit 3) and Transaction Exceeds Floor
Limit Flag (byte 4 bit 8).
7‐20 In ʺTransaction Status Information (TSI)
Processingʺ, added that Terminal Risk
Management Performed Flag is set if the
terminal floor limit is downloaded from the
host.
7‐26 In ʺExample Displayʺ, corrected example.
7‐33 In ʺError Handlingʺ, added new ʺFake ICC
Application Errorsʺ sub‐section.
7‐36 Updated ʺICC Application Journal Error
Messageʺ section.
7‐39 Added new ʺOffline Decline Journal Messageʺ
section.
Appendi Clarified ʺReading/Writing Magnetic Stripesʺ
xB and ʺImmediate Smart Card Ejectʺ processing
restrictions for DASH card reader.
Appendi In ʺAPTRA Authorʺ, removed ADE
xC documentation no longer supplied with
Advance NDC.
In ʺOther Documentationʺ, clarified EMV
specification descriptions.
Added EMVCo web page for specifications, now
available in PDF format.
CEN web site is now www.cen.eu.
APTRA Advance NDC, EMV ICC Reference Manual xi

Appendi Clarified how to create Startapps.vbs.
xD Updated silent installation with Advance NDC.
Appendi In ʺEMV Smart Card Screensʺ, added U076
xE ‘DECLINED OFFLINE’.
Glossary Updated Easy Entry application and EMV
definitions. Added CLA, Fallback, GENAC, INS,
MSB, P1 and P2 definitions.
xii APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Contents
Preface
About This Publication ......................................................................... xxi

Supported Software Releases ........................................................ xxi
Who Should Read This Publication?............................................ xxi
Abbreviations Used in This Publication.....................................xxii
What Is in This Publication?.........................................................xxii
How Should I Use This Publication? .........................................xxiii
What Experience Should I Have? ...............................................xxiv
What Else Should I Read?............................................................xxiv
Chapter 1
Introduction to ICC Processing
What Is ICC Processing? ......................................................................1‐1
ICC Processing Overview..............................................................1‐1
Standards Compliance..........................................................................1‐3
Implementation Compliance.........................................................1‐3
Functions Which are not Fully Supported ..................................1‐3
Host Processing .....................................................................................1‐6
Brand Approval ..............................................................................1‐6
PIN Entry .........................................................................................1‐6
Track 2 Data .....................................................................................1‐6
Transaction Amount.......................................................................1‐7
Account Type ..................................................................................1‐7
Fallback.............................................................................................1‐8
Application Cryptogram ‐ Offline Decline and
First GENAC Errors .....................................................................1‐9
Receipt Printing.............................................................................1‐10
Script Errors & Card Declines on
Second GENAC Command.......................................................1‐10
Zero Length Objects......................................................................1‐11
Transaction Request EMV Buffer Position................................1‐11
EMV/CAM2 Exits for APTRA Advance NDC ................................1‐13
Issuer Script Processing ...............................................................1‐13
APTRA Advance NDC, EMV ICC Reference Manual xiii

Table of Contents
Application Selection Indicator...................................................1‐13
Track 2 Data ...................................................................................1‐13
Components...................................................................................1‐14
Error Handling ..............................................................................1‐14
Tracing Mechanisms.....................................................................1‐14
EMV Checksum.............................................................................1‐16
Chapter 2
State Tables
Overview ................................................................................................2‐1
A ‐ Card Read State ...............................................................................2‐3
G ‐ Amount Check State .......................................................................2‐4
I ‐ Transaction Request State................................................................2‐5
Transaction Request Processing....................................................2‐5
T ‐ Card Read ‐ PIN Entry Initiation State .........................................2‐9
‘T’ State Flow Diagram.................................................................2‐10
+ ‐ Begin ICC Initialisation State........................................................2‐12
ICC Initialise and Candidate List Build.....................................2‐15
, ‐ Complete ICC Initialisation State .................................................2‐18
‐ ‐ Automatic Language Selection State............................................2‐20
. ‐ Begin ICC Application Selection & Initialisation State..............2‐22
FDK Template Screen Numbers Extension State .....................2‐23
Action Keys Extension State........................................................2‐24
Exit Paths Extension State............................................................2‐25
ICC Application Select & Initialise Processing .........................2‐29
/ ‐ Complete ICC Application Selection & Initialisation State ......2‐31
Exit Paths Extension State............................................................2‐32
? ‐ Set ICC Transaction Data State.....................................................2‐36
; ‐ ICC Re‐initialise State .....................................................................2‐40
z007 ‐ EMV Smart DIP Take Card State ...........................................2‐43
‘z007’ State Flow Diagram ...........................................................2‐43
z012 ‐ EMV Application Switch State ...............................................2‐46
Terminal Application Acceptable ID Entry Extension State ..2‐48
Next State Number Entry Extension State ................................2‐50
Chapter 3
Configuration Parameters
Overview ................................................................................................3‐1
Enhanced Configuration Parameters Load Message .......................3‐2
xiv APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Chapter 4
Terminal to Central Messages
Overview ................................................................................................4‐1
Terminal Application Version Information.......................................4‐2
Terminal Hardware Information ........................................................4‐4
Transaction Request Message Format ................................................4‐5
Message Format ..............................................................................4‐5
CAM Flags .......................................................................................4‐8
Solicited Status Messages ...................................................................4‐10
Command Rejects .........................................................................4‐10
Unsolicited Status Messages ..............................................................4‐11
Supervisor Keys (Unsolicited) ....................................................4‐11
SCRW/MCRW Hardware Error Reporting .....................................4‐13
Errors During Chip Power‐Up ..........................................................4‐14
ICC Application Solicited/ Unsolicited Error Message..................4‐15
Issuer Script Results and Completion Data .....................................4‐17
Chapter 5
Central to Terminal Messages
Overview ................................................................................................5‐1
Customisation Data Commands .........................................................5‐2
EMV Configuration Message...............................................................5‐4
ICC Currency Data Objects Table.................................................5‐6
ICC Transaction Data Objects Table ............................................5‐8
ICC Language Support Table......................................................5‐10
ICC Terminal Data Objects Table ...............................................5‐13
ICC Terminal Acceptable Application IDs Table.....................5‐14
Default EMV Customisation Data ....................................................5‐25
Transaction Reply................................................................................5‐26
Field bc ‐ Transaction Data Objects Update Buffer..................5‐30
Buffer Identifiers ...........................................................................5‐32
Function Identifiers ......................................................................5‐32
Interactive Transaction Response...............................................5‐33
Chapter 6
Supervisor Menus/Functions
Overview ................................................................................................6‐1
APTRA Advance NDC, EMV ICC Reference Manual xv

Table of Contents
Supervisor Menus/Functions ...............................................................6‐2
90 MISC FUNCS..............................................................................6‐2
Chapter 7
ICC Processing
Overview ................................................................................................7‐1
EMV Data Validation............................................................................7‐2
Issuer Script Processing ........................................................................7‐3
Data Object List (DOL) Processing .....................................................7‐4
BER‐TLV Data Object Processing........................................................7‐5
BER‐TLV Data Object Padding .....................................................7‐5
Terminal Specified BER‐TLV Data Objects .................................7‐6
Transaction Data Object List (TDOL) Processing ...........................7‐11
Printing EMV Data Values .................................................................7‐12
MAC Configuration ............................................................................7‐14
Terminal Verification Results (TVR) Processing.............................7‐16
Transaction Status Information (TSI) Processing............................7‐20
PIN Encryption and Verification.......................................................7‐22
ICC Application Name Display ........................................................7‐23
Example Display ...........................................................................7‐26
Voice Guidance ....................................................................................7‐27
Application Name Selection........................................................7‐27
Dynamic Currency Conversion.........................................................7‐29
Error Handling.....................................................................................7‐33
Fake ICC Application Errors .......................................................7‐33
ICC Application Journal Error Message ..........................................7‐36
Journal Print Examples ................................................................7‐38
Reserved Screens...........................................................................7‐38
Offline Decline Journal Message .......................................................7‐39
Example Journal Trace .................................................................7‐40
Default Traced Objects .................................................................7‐41
Changing Traced Objects .............................................................7‐41
Disabling Offline Decline Journal Tracing ................................7‐42
Extended Journal Tracing...................................................................7‐44
ICC Processing Termination ..............................................................7‐46
Authorisation Response Codes .........................................................7‐47
Additional Approval Response Codes ......................................7‐47
Strict Authorisation Response Code Validation.......................7‐48
Invalid Authorisation Response Codes .....................................7‐48
Windows Registry Settings ................................................................7‐50
xvi APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Appendix A
Example Configuration Data
Overview ...............................................................................................A‐1
Configuration Data ..............................................................................A‐2
State Table .......................................................................................A‐2
Financial Institution Table (FIT) ..................................................A‐4
Dispenser Currency Cassette Mapping Table ...........................A‐4
Enhanced Configuration ‐ Option Digits ...................................A‐4
Enhanced Configuration ‐ Timers ...............................................A‐4
ICC Currency Data Objects Table................................................A‐4
ICC Transaction Data Objects Table ...........................................A‐5
ICC Language Support Table.......................................................A‐5
ICC Terminal Data Objects Table ................................................A‐5
ICC Terminal Acceptable Application IDs (AIDs) Table.........A‐6
Cardholder Screens........................................................................A‐8
Appendix B
Processing Restrictions
Overview ............................................................................................... B‐1

Restrictions ............................................................................................ B‐2
BER‐TLV Field Size........................................................................ B‐2
Candidate List Size ........................................................................ B‐2
Number of Application IDs in Download.................................. B‐3
Reading/Writing Magnetic Stripes .............................................. B‐3
Smart Card Reader/Writer (SCRW) ............................................ B‐3
Communications Protocols .......................................................... B‐3
Immediate Smart Card Eject ........................................................ B‐3
Appendix C
Related Documentation
Overview ............................................................................................... C‐1

Advance NDC Documentation .......................................................... C‐2
APTRA Author............................................................................... C‐3
Other Documentation .......................................................................... C‐4
APTRA Advance NDC, EMV ICC Reference Manual xvii

Table of Contents
Appendix D
Installation
Overview ...............................................................................................D‐1
Installation Instructions .......................................................................D‐2
Development PC Installation .......................................................D‐2
Producing a Combined Aggregate..............................................D‐2
SST Installation of Combined Aggregate ...................................D‐3
Interactive Runtime SST installation...........................................D‐3
EMV Exits Control files.................................................................D‐3
Appendix E
EMV ICC Reserved Screens
Overview ............................................................................................... E‐1

‘U’ EMV Smart Card ............................................................................ E‐2
Appendix F
ISO 8859 Character Sets
Overview ................................................................................................F‐1
Advance NDC .................................................................................F‐1
Font ID Mapping Table.........................................................................F‐2
Appendix G
State Flow Diagram
Overview ...............................................................................................G‐1
State Flow Diagram ..............................................................................G‐2
State Flow Diagram ‐ Part 1..........................................................G‐2
Glossary
Glossary .................................................................................... Glossary‐1
Index
Index ................................................................................................Index‐1
xviii APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
User Feedback Form
APTRA Advance NDC, EMV ICC Reference Manual xix

Table of Contents
xx APTRA Advance NDC, EMV ICC Reference Manual

Preface
About This Publication
This publication supports multi‐vendor ‘EMV/CAM2 Exits for
Supported Software APTRA Advance NDC’ (Advance NDC Release 3.04 and above).
Releases
This publication is a reference for any APTRA Advance NDC
Who Should Read This developer who wishes to add Integrated Circuit Card (ICC) Card
Publication? Authentication Method (CAM) functionality to their Advance NDC
application.
Before using this publication, you should be familiar with using
Advance NDC, and have received the relevant EMV ICC and
Advance NDC training. For more information on training
availability, contact your local NCR representative.
You should also be familiar with the relevant third party
specifications listed in the “Other Documentation” section of
Appendix C, “Related Documentation”.
APTRA Advance NDC, EMV ICC Reference Manual xxi

Preface
The following abbreviations are used in this publication.
Abbreviations Used in
This Publication
Abbreviation Used Meaning
Advance NDC APTRA™ Advance NDC for Windows XP or
APTRA™ Advance NDC for Windows 7
NDC Advance NDC
EMV Exits EMV/CAM2 Exits for APTRA Advance NDC
ICC Integrated Circuit Card or ‘Smart Card’
CAM Card Authentication Method
EMV Europay Mastercard Visa; see the “Glossary”.
EMV is a trademark owned and registered by
EMVCo LLC.
Windows XP Microsoft® Windows® XP Professional Edition
Windows 7 Microsoft® Windows® 7 Professional
Central or the host Central NDC host computer
The publication contains the following information:
What Is in This
Publication? Chapter 1, “Introduction to ICC Processing”
Gives you an overview of the ICC processing, and the functions
performed by it. This chapter includes information recommending
the data object processing the NDC host is expected to perform.
Chapter 2, “State Tables”
Provides the function and format of the ICC related state tables,
required to use an EMV ICC with Advance NDC.
Chapter 3, “Configuration Parameters”
Provides details of the EMV ICC related configuration parameters,
for ICC configuration using Advance NDC.
Chapter 4, “Terminal to Central Messages”
Provides details of the function and format of each type of EMV ICC
related message sent from the terminal to Central.
Chapter 5, “Central to Terminal Messages”
Provides details of the function and format of each type of EMV ICC
related message sent from Central to the terminal.
xxii APTRA Advance NDC, EMV ICC Reference Manual

Preface
Chapter 6, “Supervisor Menus/Functions”
Provides you with a brief overview of the EMV ICC related
supervisor menus and functions.
Chapter 7, “ICC Processing”
Provides you with specific information on the ICC processing, and
the functions performed.
Appendix A, “Example Configuration Data”
Gives example configuration data, showing the types of data you
may include in the download to the terminal.
Appendix B, “Processing Restrictions”
Lists the EMV ICC processing restrictions, of which you should be
aware.
Appendix C, “Related Documentation”
Provides details of all related NCR documentation.
Appendix D, “Installation”
Provides brief instructions on installing the EMV/CAM2 Exits
products for Advance NDC.
Appendix E, “EMV ICC Reserved Screens”
Lists the new reserved screens introduced by the EMV/CAM2 Exits
product for Advance NDC.
Appendix F, “ISO 8859 Character Sets”
Lists the ISO 8859 character sets and font IDs supported by the
EMV/CAM2 Exits product for Advance NDC.
Appendix G, “State Flow Diagram”
Provides a diagram of the base configuration state flow.
Initially, you should read all the chapters and appendices to obtain
How Should I Use This an understanding of the EMV ICC functions which can be added to
Publication? Advance NDC.
Subsequently, use this publication as a reference for the specific
EMV ICC functions you wish to implement.
Should you have any problems using this manual, refer to the “User
Feedback Form” at the back of the manual, where you will find our
email and postal addresses. Please take the time to reply; your
comments are appreciated.
APTRA Advance NDC, EMV ICC Reference Manual xxiii

Preface
You are expected to be familiar with using the Windows XP or
What Experience Should I Windows 7 operating system and APTRA Advance NDC.
Have?
You should have completed the following NCR intranet courses:
● EMV Technical Overview (Course No. 32630)
● EMV for NDC Overview, Parts 1 and 2 (Course No. 32631)
We recommend that you then attend the ‘EMV Solution for NDC
Workshop’ (Course No. 23003).
Having completed these courses, you can then obtain APTRA
Engineer (EMV for NDC) Certification (Course No. 34226).
In addition, especially if you are going to develop Exits, you should
have work experience of either Advance NDC, or have completed
the ‘APTRA Advance NDC Implementation Workshop’ (Course
No. 28777).
To understand the use of the Encrypting PIN Pad (EPP), we
recommend you also complete ‘EPP for NDC+ and APTRA
Advance NDC’ (Course No. 23434) and ‘EPP Remote Key
Management including DAPI7 Enhanced Mode’ (Course No.
39124).
If you are a registered user, you can view details of these courses
using NCR University (NCRU) at http://www.ncru.ncr.com.
For details of other Advance NDC courses, see the APTRA Advance
NDC, Overview (B006‐6597).
You should be familiar with the APTRA Advance NDC, Reference
What Else Should I Read? Manual (B006‐6180) as this EMV ICC Reference Manual is designed to
supplement that publication.
For a multi‐vendor APTRA Advance NDC application, you should
also read the APTRA Advance NDC, Multi‐Vendor Support Reference
Manual (B006‐6344).
All the documentation related to Advance NDC, and some third
party ‘Other Documentation’ is listed and described in Appendix C,
“Related Documentation.”
xxiv APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Chapter 1
What Is ICC Processing? 1‐1
ICC Processing Overview 1‐1
Standards Compliance 1‐3
Implementation Compliance 1‐3
Functions Which are not Fully Supported 1‐3
Terminal Objects 1‐3
Offline Static / Dynamic Data Authentication 1‐3
Terminal Action Analysis 1‐4
Terminal Risk Management 1‐5
Host Processing 1‐6
Brand Approval 1‐6
PIN Entry 1‐6
Track 2 Data 1‐6
Transaction Amount 1‐7
Account Type 1‐7
Fallback 1‐8
Smart DIP Reader 1‐8
Motorised Card Reader 1‐8
Application Cryptogram ‐ Offline Decline and
First GENAC Errors 1‐9
Offline Behaviour 1‐9
Receipt Printing 1‐10
Script Errors & Card Declines on
Second GENAC Command 1‐10
Zero Length Objects 1‐11
Transaction Request EMV Buffer Position 1‐11
EMV/CAM2 Exits for APTRA Advance NDC 1‐13
Issuer Script Processing 1‐13
Application Selection Indicator 1‐13
Track 2 Data 1‐13
Track 2 Data Used During An ICC Transaction 1‐13
APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Track 2 Data To Be Sent To The Host 1‐14
Components 1‐14
Error Handling 1‐14
Tracing Mechanisms 1‐14
Debug Log Tracing 1‐14
Journal Tracing 1‐15
EMV Checksum 1‐16

A
What Is ICC Processing?
What Is ICC Processing? 1
ICC (Integrated Circuit Card) processing provides the functions to
enable the addition of ICC processing to an existing Advance NDC
terminal application.
ICC processing enables the terminal to accept ICCs and perform the
appropriate CAM (Card Authentication Method) ICC application
processing. For more details, refer to the third party specifications
listed in “Other Documentation” in Appendix C, “Related
Documentation.”
This ICC processing produces card verification information which is
supplied to Central, as described in Chapter D, “Terminal to Central
Messages.”
Central can return similar verification information to the card, as
described in Chapter E, “Central to Terminal Messages.”
CAM authentication is supported; the CAM authentication enables
the update of ICC related data.
For a list of the terms used throughout this publication and their
definitions, see the “Glossary”.
The following steps give an overview of the ICC processing for
ICC Processing Overview 1
Advance NDC, and how it can be configured. For the purpose of
this overview, it is assumed that the transaction flow indicates that
the card inserted is to be initialised as an ICC, and that the card is an
ICC.
1 When a card is inserted, the magnetic stripe is read from the
card. If track 2 from the magnetic stripe is found to contain the
ATB (Alternative Technology Byte) with a setting of ʹ2ʹ or ʹ6ʹ, the
card is processed as an ICC. For the track 2 format, see ISO 7811:
Identification Cards ‐ Recording Technique.
2 If the cardholderʹs language preference is obtained during ICC
initialisation, the cardholder information is automatically
displayed in their preferred language. Alternatively, the
cardholder can manually choose their preferred language.
3 If there is more than one ICC application available, the ICC
applications are presented to the cardholder. The cardholder
then selects the ICC application they wish to use.
APTRA Advance NDC, EMV ICC Reference Manual 1-1

What Is ICC Processing?
4 If there is only one ICC application available, this can be
configured to be automatically selected. Alternatively, the
cardholder is prompted to confirm/select the application to use.
5 If, during initialisation, the terminal determines that the ICC
application is not available or usable, the cardholder is asked to
select another ICC application.
6 If there are no more ICC applications, or the choice is being
made automatically, the transaction flow displays the
appropriate message to the cardholder.
7 If the account or product cannot be handled at the terminal, the
transaction flow informs the cardholder.
8 If the account or product can be handled, the cardholder is
asked to enter the PIN for the account or product that relates to
the ICC application.
9 The cardholder then selects a service offered by the transaction
flow. Once this is done, a transaction request is sent to Central
with the CAM data included to enable authorisation of the
transaction.
10 Central then responds to the transaction request with a
transaction reply containing CAM data.
11 Processing continues until the cardholder completes all the
services they require, or Central directs the terminal to return
the card, and ends with a controlled termination of the
transaction.
For an overview diagram of the state flow used, see Appendix G,
“State Flow Diagram”.
1-2 APTRA Advance NDC, EMV ICC Reference Manual

Standards Compliance
Standards Compliance 1
The ‘EMV/CAM2 Exits for APTRA Advance NDC’ product is
designed to be compliant with the EMV version 4.2a specifications,
and the MasterCard Paypass and Visa version 1.5.0 standards.
For more information on these specification standards, see “Other
Documentation” in Appendix C, “Related Documentation”.
The CAM ICC processing performed for Advance NDC has been
Implementation designed to maximise flexibility and performance using
Compliance 1
configurable features. However, you should be aware that certain
configurations in your terminal network may result in partial
non‐compliance with Visa and/or MasterCard requirements.
NCR recommends you seek guidance from MasterCard and Visa to
ensure that your configured options do not contravene these
requirements.
Since the CAM ICC processing performed for Advance NDC is for
Functions Which are not an online only (not offline) terminal, some aspects of the standards
Fully Supported 1
are not applicable and are therefore not supported.
To improve terminal performance, a number of areas identified in
the standards are also not supported.
The areas of the standards not supported, which NCR has discussed
as appropriate with the EMV consortium, are as follows.
Terminal Objects 1
Not all objects identified within the standards are supported. Some
objects are unsupported because they are not applicable to the ICC
processing performed.
The only objects maintained by CAM ICC are those identified in
“Terminal Specified BER‐TLV Data Objects” in Chapter 7, “ICC
Processing”. Where the content of a terminal maintained object is
expected to be dynamically updated, the support is as stated in the
appropriate processing.
Note: The terminal can be configured with additional terminal data
objects, but these must be supplied by Central.
Offline Static / Dynamic Data Authentication 1
This processing is not applicable and therefore is not supported.

This functionality is not applicable because all transactions are
online only, with no need to perform any offline data
authentication.
The implications of not performing this processing is that an
imposter ICC application is detected as not genuine by Central,
rather than by the CAM ICC processing.
Terminal Action Analysis 1
Terminal Action Analysis is performed, but ʹTerminal Action Code ‐
Defaultʹ and ʹTerminal Action Code ‐ Onlineʹ data items are not
configurable, and are both set to ‘FFFFFFFFFF’.
These data items are not configurable as the terminal is unable to
complete, or authorise, a transaction without going online. This is a
restriction of the environment of use.
The ʹTerminal Action Code ‐ Onlineʹ data item, in effect, always
takes the transaction online.
The ʹTerminal Action Code ‐ Defaultʹ data item, in effect, always
declines the transaction offline, when the transaction cannot be
completed online.
The impact of this is that the terminal does not query the ICC to
authorise transactions offline.

Terminal Risk Management 1
None of these checks are applicable to an ICC CAM online only
terminal, and are therefore most of them are not performed.
The checks not performed would involve checking exception files,
random online transactions and velocity, none of which are relevant
to an online only terminal.
The terminal will perform floor limit checking and will use a floor
limit value of zero, unless the host has downloaded a different value
for the floor limit.
By default floor limit checking will be performed irrespective of the
cardʹs application interchange profile.

Host Processing
Host Processing 1
Where applicable, the NDC host (Central) is responsible and must
cater for the following requirements:
● Brand Approval
● PIN Entry
● Track 2 Data
● Transaction Amount
● Account Type
● Fallback
● Application Cryptogram
● Receipt Printing
● Script Errors & Card Declines on Second GENAC Command
● Zero Length Objects
● Transaction Request EMV Buffer Position
The Brand Approval process validates the requirements of payment
Brand Approval 1
systems, such as Visa or Mastercard, prior to deployment. Some
tests may have terminal behaviour which depends on host
processing. As the Advance NDC terminal is host‐controlled some
tests may require specific host application behaviour.
The ICC contains information required by the terminal to make
PIN Entry 1
decisions on PIN entry. In order to use the ICC information, the
state type ‘k’ (Smart FIT Check state) is required to be used prior to
the PIN Entry state. This enables a FIT match to be found based on
the ICC information. In order to operate correctly, this state must
follow the successful completion of the
“/ ‐ Complete ICC Application Selection & Initialisation State”.
To enable the PIN to be encrypted based on the information from
the ICC instead of the magnetic stripe, the PIN Entry state must
follow the “/ ‐ Complete ICC Application Selection & Initialisation
State” and the Smart FIT Check state.
For details of the Smart FIT Check state, see the APTRA Advance
NDC, Reference Manual.
There are two possible sources of Track 2 data; the standard
Track 2 Data 1
Advance NDC Track 2 buffer field, and the CAM buffer host
requested objects field of the transaction request message.

Host Processing
By default, the standard Advance NDC transaction request Track 2
data buffer contains the magnetic Track 2 data. Assuming it has
been requested, the Track 2 equivalent data from the chip (tag 0x57)
is sent to the host in the CAM buffer, together with all the other
objects the host has requested.
There are two alternative ways the Advance NDC host can decode
the PIN buffer and pass Track 2 information to the issuer:
a Recognise that the transaction is EMV based, and instead of
using the Track 2 data in the standard Advance NDC
transaction request message, use the tag 0x57 data object in the
CAM buffer. However, this requires decoding of the CAM
buffer, and extraction and reformatting of the tag 0x57 object
into the standard Track 2 format; for example, addition of any
start/end sentinels, changing of any field separators characters,
removal of any padding ʹFʹ characters. Alternatively you can:
b Use an option in the ICC Terminal Acceptable AIDs Table to
force the Track 2 data used by the EMV transaction to be sent to
the host in the standard Advance NDC Track 2 data buffer. To
do this, set field f18 ‘Track 2 Data for Central’ to the value ‘02’.
This method should require no additional host processing. As
no magnetic Track 2 data is sent to the host fallback is not
possible in some scenarios. If a host does not support the
downloading of this field it can also be configured locally at the
terminal via the Windows Registry, see “Local setting of Track
Data settings f18,f19,f20,f21” on page 5‐24.
In order to correctly initialise the EMV Amount Authorised objects
Transaction Amount 1
(tags 9F02 and 81), Advance NDC requires the transaction amount
to be placed in either the Amount Buffer, General Purpose Buffer B
or General Purpose Buffer C, prior to the “? ‐ Set ICC Transaction
Data State”.
When the amount is selected using FDKs during a Fast Cash
transaction, it is important to use the “X ‐ FDK Information Entry
State”, as this state type automatically populates a buffer with the
transaction amount. Using any other Advance NDC state type for a
Fast Cash transaction (for example, a “Y ‐ Eight FDK Selection
Function State”) will not populate the buffer with the transaction
amount, and the EMV Amount Authorised objects will not be
correctly set. This could cause some cards or issuer hosts to refuse
the transaction.
The ‘EMV/CAM2 Exits for APTRA Advance NDC’ product
Account Type 1
supports the Account Type object (tag 5F57) defined by EMV. If this
object is required, it can be downloaded in any of the data object
download tables; most likely, the transaction objects table.

Host Processing
When the terminal attempts to perform a transaction using an ICC
Fallback 1
and an error occurs, it is possible for the acquirer host to approve
the transaction based only on the magnetic stripe information. This
approval based on the magnetic stripe is often referred to as
fallback.
When and if fallback can occur depends on the type of card reader
in the terminal, and at which EMV processing stage a failure occurs.
Smart DIP Reader 1
For a smart DIP reader, the magnetic data is only read on card
removal, and this only takes place if the chip is not found during the
card read state. Note that ‘chip not found’ can mean the card does
not have a chip, or that it has a chip which cannot be successfully
powered up.
Prior to EMV Exits release 02.02.00 fallback was not possible in cases
when the chip was successfully powered up, as the card remained
in the reader and the magnetic data is not available.
From EMV Exits release 02.02.00 the EMV Smart DIP Take Card
State supports fallback when a chip based transaction encounters an
error. The Begin ICC Initialisation State can be used after this state
to reject cards which indicate via their magnetic stripe that a chip
was present.
This allows rejection of cards without involving the host.
Motorised Card Reader 1
For a motorised card reader (MCRW) fallback can occur at any
stage, as the magnetic data can be read at any time.
Host Processing 1
In order to make the decision to allow fallback, the host must know
the nature and position of the failure during EMV processing. This
can be determined by a combination of the CAM flags in the
Transaction Request message and the opcode buffer. It is therefore
important that the state flow updates the opcode buffer uniquely
using the Pre‐set Operation Code Buffer state (state type D) when an
EMV error occurs.
For details of the Pre‐set Operation Code Buffer state, see the
APTRA Advance NDC, Reference Manual.
Table entry 8 of the “, ‐ Complete ICC Initialisation State”, and table
entry 9 of the “/ ‐ Complete ICC Application Selection &
Initialisation State” exit paths extension state, are designed to
resolve previous issues with fallback involving blocked cards and
applications.

Host Processing
In some cases, a transaction may be denied on the first Generate
Application Cryptogram ‐ Application Cryptogram (GENAC) command, but a Transaction
Offline Decline and First Request message is still sent to the host. This can occur if the
GENAC Errors 1 terminal denies the transaction after terminal action analysis
requests an Application Authentication Cryptogram (AAC), or if
the card denies the transaction after returning an AAC to the first
GENAC.
In these circumstances, the chip transaction completes offline but
the NDC environment means the terminal may pass the information
to the host and wait for it to instruct the terminal how to complete
the transaction.
For example, the required information could include screens to
display, next state number, any journal data, and so on. The
terminal does not have sufficient local information to complete this
transaction.
By going online, the terminal is simply requesting the host to
complete the NDC transaction; the transaction is already complete
according to the ICC.
The NDC host should recognise this request, and in these specific
cases should not involve the card’s issuer, but deal with the request
itself and simply close down the transaction.
The host can identify these scenarios by checking the Cryptogram
Information Data object sent by the terminal, which for an offline
decline is set to ʺ00ʺ, that is, AAC.
Additionally, if the ‘service not allowed’ bit is set in the Cryptogram
Information Data object, the same host behaviour is expected. CAM
data is not expected in the Transaction Reply.
In these scenarios, the relevant “CAM Flags” (byte 1 bit 5) will be set
to 1 to enable the host to identify the scenario.
Offline Behaviour 1
It is possible to configure the terminal to decline these transactions
without sending a message to the host, using parameters in the
transaction request state or the Windows registry.
If the offline decline next state number (table entry 2 of the 2nd
extension to the transaction request state) is non‐zero, the terminal
will proceed to the offline decline next state number.
If the offline decline next state number (table entry 2 of the 2nd
extension to the transaction request state) is zero or the extension
state is not configured, the terminal will check the registry key
\HKEY_LOCAL_MACHINE\NCR\APTRA\EMV Exits\Decline.

Host Processing
This key may contain the offline decline next state number to which
the terminal will proceed.
The registry key will be interpreted as follows:
● If there is a string value of length three which matches the
current transaction request state number, and the data is also
of length three, the terminal will use the data in this value as
the state number.
● If no value which matches the transaction request state is
under this key, then the terminal will look for a string value
ʺdefaultʺ, and if its data is length three it will be used for the
next state number. Otherwise all relevant ICC data will be
sent to the host.
● This terminal based decline can also be extended to cover
transactions which resulted in an error at the 1st Generate
Application Cryptogram command. This is controlled via
the ʺEnable for Errorʺ registry value under this Decline
key. A non‐zero value will extend the offline decline
processing to cover these error scenarios.
It is the host’s responsibility to print the cardholder’s receipt and
Receipt Printing 1
any transaction information to the journal. This means the
Application Label, Application Identifier (AID) and Amount
Authorised should be requested by the host in the Transaction
Request. In this way, the host can extract the information, format it
appropriately, and send the information back to the terminal within
the printer data field of the Transaction Reply.
To permit the host to print EMV data objects without these objects
being sent to the host, some control code sequences have been
defined. These codes are specified in Printing EMV Data Values.
If these codes are not used host processing of transaction
information is configured. The processing that the host is required
to do in formatting the receipt includes the removal of any padding
characters which may be found in the Primary Account Number
(PAN) or Track 2 Equivalent Data objects.
If the terminal requests a Transaction Certificate (TC) in the second
Script Errors & Card Generate Application Cryptogram (GENAC) command but instead
Declines on Second receives an Application Authentication Cryptogram (AAC), the
GENAC Command 1 processing continues until all issuer scripts (if any) are performed,
and only then is a solicited error message sent to the host system.
The terminal will await a new Transaction Reply without CAM
data, which should close down the transaction.
The solicited error message is a fake ICC application level error
message with CLA = 0xFF, INS = 0xFF, P1 = 0xFF, P2 = 0xFF, Lc =

Host Processing
0x00, Le = 0x00, SW1 = 0xFF and SW2 = 0xFF, containing any host
requested completion objects and any issuer script results.
However, this solicited error message is also sent to the host when
an unsolicited issuer script error message has been previously sent
to the host. When the script fails, this enables the host to complete
the transaction with a different cardholder message; for example, so
that after a failed PIN Change script the displayed message could
read ‘Sorry, your PIN could not be changed’.
In order to determine the reason behind this error, the host should
check the host completion objects, and specifically the Cryptogram
Information Data (9F27) object, to establish the cryptogram returned
by the card. In the case of a card decline on the second GENAC
command, this object will be set to AAC and the host should close
down the NDC transaction. If however, the object instead contains a
TC, the transaction has been approved and despite the script failure
the host should continue the transaction.
Alternatively, option 69 can be used to stop the terminal sending
solicited script failure errors. With bit 3 of this option set, the error
can only result from the card returning an AAC when a TC was
requested, which simplifies the host processing. However, this also
means that if a script fails no solicited error will result, and the
transaction will complete. In the above PIN Change example, this
would mean that the cardholder would be incorrectly informed that
the PIN had been changed.
Although the EMV Exits software accepts any host downloaded
Zero Length Objects 1
object with a zero length, during EMV processing it is treated as if
the object is not known. Zero length fields in the EMV buffers of the
Transaction Reply message will result in the message being rejected
unless the zero length field is in the Issuer Script field. If a script
command (tag 0x86) within the Issuer Script field of the Transaction
Reply is found to be of zero length, this is treated as an invalid
script.
The position of the EMV CAM 2 Exits for Advance NDC buffer
Transaction Request EMV (field bd) in the transaction request message was changed in the
Buffer Position 1
‘EMV/CAM2 Exits for APTRA Advance NDC’,02.02.01 release.
In prior releases, if the transaction request fields ca, cb, ce, cf, cg, ci
were present they would appear before the EMV CAM 2 Exits for
Advance NDC buffer.
As specified in the APTRA Advance NDC, Reference Manual these
fields should appear after the EMV CAM 2 Exits for Advance NDC
buffer.
Since release 02.02.01 the position of the EMV CAM 2 Exits for
Advance NDC buffer matches the APTRA Advance NDC, Reference

Host Processing
Manual and the fields specified above follow the EMV CAM 2 Exits
for Advance NDC buffer.
Providing the unique identifier at the start of a field is used to
identify the bufferʹs content then no host impact will result from this
correction.
If an alternate approach is used, for example counting field
separators, then a host may be impacted and might lead to the
wrong interpretation of the transaction request message.
For full details of the transaction request message format, see the

EMV/CAM2 Exits for APTRA Advance NDC
EMV/CAM2 Exits for APTRA
Advance NDC 1
The ‘EMV/CAM2 Exits for APTRA Advance NDC’ product includes
changes in the following areas:
● Issuer Script Processing
● Application Selection Indicator
● Track 2 Data
● used during an ICC transaction
● to send to the host
● Components
● Error Handling
● Tracing Mechanisms
● EMV Checksum.
For the latest details of the ‘EMV/CAM2 Exits for APTRA Advance
NDC’ product, see the Release Bulletin included with this product.
Invalidly formatted issuer script data is not rejected during
Issuer Script Processing 1
transaction reply validation, prior to issuer script processing.
Instead, an attempt to process each script is made until the script is
complete, an ICC level error occurs, or a formatted error is
discovered.
A formatting error will result in a fake script unsolicited error
message being sent to the host (Central). The formatted failure is
also reported in the Issuer Script Results.
The addition to the candidate list of a partial matching AID is now
Application Selection configurable for each AID. To do this, use the Application Selection
Indicator 1
Indicator field in the “ICC Terminal Acceptable Application IDs
Table” download message.
The track 2 data used by an ICC transaction and sent to the host can
Track 2 Data 1
be configured.
Track 2 Data Used During An ICC Transaction 1
You can specify the track 2 data to be used in the “ICC Terminal
Acceptable Application IDs Table” to use either:
● the track 2 equivalent data card object (tag 0x57), or
● the track 2 data obtained from the card’s magnetic stripe, or

● simulated track 2 data made up from the card ICC object
Application PAN (tag 0x5A) and Application Expiration Date
(tag 0x5F24), and the data downloaded in field f21 of the “ICC
Terminal Acceptable Application IDs Table” for the selected
AID.
Track 2 Data To Be Sent To The Host 1
You can specify the data to be sent to the host in the track 2 buffer
field of the transaction request. Either the track 2 data obtained from
the magnetic card, or the track 2 data used for the smart card
transaction can be sent.
The following components are included:
Components 1
● EMV/CAM2 NDC Kernel, which deals with the smart card
interaction
● EMV/CAM2 NDC Interface, which deals with the NDC message
interface.
The same error handling mechanism (mERRORs) is used as in
Error Handling 1
APTRA Advance NDC, instead of system escapes
(ADI_SYSTEM_ESCAPES).
For debugging/testing, tracing can be enabled to the Advance NDC
Tracing Mechanisms 1
Debug Log tool and/or the journal. Tracing should only be enabled
for debugging/testing, and not in a live SST environment.
Debug Log Tracing 1
The terminal can log three streams of data:
● Commands to and responses from the ICC
● General EMV debugging information
● CEN XFS‐level tracing
To view each of these streams in the Advance NDC Debug Log tool
you need to create a window using File | New option in the Debug
Log tool, or define them in the .ini file if the silent Debug Log tool is
being used. The windows must be named ‘EMVTrace’,
‘EMVDebug’ and ‘EMVXFS’ for each of the three streams
respectively.
Debug logging is enabled via the Windows Registry. If the registry
key \HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\EMV
EXITS\DebugLog exists and has a DWORD value ‘debugTrace’ with
a non‐zero value, all logging is enabled. To disable tracing set the
value to 0.

Enabling logging will increase the transaction times but the traces
are useful for debugging issues with specific cards, and obtaining
test evidence in any Brand Approval process.
Journal Tracing 1
Journal tracing of all EMV/CAM2 commands and responses to/from
the chip can be enabled via the Windows registry. The data will be
traced to the active journal printer(s), including Electronic Journal if
it is enabled.
Additionally all terminal‐known EMV objects can be traced to the
active journal at specific points during the transactions, during the
building of DOL objects prior to the ‘GET PROCESSING OPTIONS’
command and the first and second ‘GENERATE APPLICATION
CRYPTOGRAM’ commands.
The key in the registry to control the tracing is
HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\
EMV EXITS\dump ctrl.
To enable or subsequently disable tracing, use the Registry Editor
(regedit) to:
1 If not already present, create the dump ctrl key in the above
location (select Edit | New | Key)
2 Under this key, create the value “trace” as type DWORD (select
Edit | New | DWORD Value). Set this value to 1 to enable chip
input/output tracing, or to 0 to disable this tracing (select Edit |
Modify).
3 Under the same key, create the value “objects” as type DWORD.
Set this value to 1 to enable object store tracing, or to 0 to disable
this tracing.
4 Reset the SST for the changes to take effect.
Note: Enabling these keys will increase the transaction times, but
the traces are useful for debugging issues with specific cards, and
for obtaining any required test evidence, for example during Brand
Approval.

For security reasons the values of the following Ber‐TLV objects will
not be traced to the Journal by default. Each byte of the value field
will be replaced with ʹ*ʹ.
Tag Name Tag
Track2 Equivalent Data 57
Track1 Discretionary Data 9F1F
Track2 Discretionary Data 9F20
Application Primary Account 5A (First and last 4 characters will
Number be traced)
Application Primary Account 5F34
Number Sequence Number
Cardholder Name 5F20
Cardholder Name Extended 9F0B
International Bank Account 5F53
Number
Transaction PIN 99
Unpredictable Number 9F37
Application Expiry date 5F24
Service Code 5F30
To disable the masking of these objects the registry key
\HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\EMV
EXITS\DebugLog must exist and contain a DWORD value ‘Disable
PCI Mask’ containing a non‐zero value.
A deployed terminal should not be configured with this value
because security sensitive cardholder information will be captured
in the Electronic Journal or may be captured in the debug log files.
The terminal produces an EMV checksum covering the EMV kernel
EMV Checksum 1
software. This checksum is required by EMV and is produced using
the SHA‐1 Hash algorithm on terminal resident data, for example
component version numbers, operating system, and terminal
capabilities.
On power‐up, if the NDC configuration identifier number has a
non‐zero value, indicating that the host customisation download
information has been retained over the power fail, the EMV
checksum is printed together with the component version numbers.

If Debug Log tracing is enabled, the terminal traces the checksum to
the ‘EMVDebug’ window of the Debug Log tool just before the
terminal attempts to power‐on the chip.


Table of Contents
State Tables
Chapter 2
State Tables
Overview 2‐1
A ‐ Card Read State 2‐3
G ‐ Amount Check State 2‐4
I ‐ Transaction Request State 2‐5
Transaction Request Processing 2‐5
Processing Restrictions 2‐5
Terminal Risk Management 2‐5
CVM Processing 2‐6
Card Action Analysis 2‐7
T ‐ Card Read ‐ PIN Entry Initiation State 2‐9
‘T’ State Flow Diagram 2‐10
+ ‐ Begin ICC Initialisation State 2‐12
ICC Initialise and Candidate List Build 2‐15
Canadian List Filtering 2‐17
, ‐ Complete ICC Initialisation State 2‐18
‐ ‐ Automatic Language Selection State 2‐20
. ‐ Begin ICC Application Selection & Initialisation State 2‐22
FDK Template Screen Numbers Extension State 2‐23
Action Keys Extension State 2‐24
Exit Paths Extension State 2‐25
ICC Application Select & Initialise Processing 2‐29

Table of Contents
State Tables
Application Selection 2‐29
Processing Options 2‐29
Read Records 2‐29
Processing Restrictions 2‐29
/ ‐ Complete ICC Application Selection & Initialisation State 2‐31
Exit Paths Extension State 2‐32
? ‐ Set ICC Transaction Data State 2‐36
; ‐ ICC Re‐initialise State 2‐40
z007 ‐ EMV Smart DIP Take Card State 2‐43
‘z007’ State Flow Diagram 2‐43
z012 ‐ EMV Application Switch State 2‐46
Terminal Application Acceptable ID Entry Extension State 2‐48
Next State Number Entry Extension State 2‐50

State Tables
B
Overview
Overview 2
This chapter describes the function of each of the state table types
used for ICC Processing, and their format.
Apart from state types ‘A’, ‘G’, ‘I’ and ‘T’, these state table types are
additional to the standard state table types listed in the APTRA
Advance NDC, Reference Manual. Refer to the required reference
manual for details of state types ‘A’, ‘G’ or ‘I’.
The state table is made up of the state number, state type and table
data. Most states include a screen number and a next state number
as part of the table data. Next state numbers have a decimal upper
limit of 999, but if APTRA Advance NDC is configured to support
alphanumeric state numbers then EMV ICC processing will also
support this.
In general, where a screen is present it is displayed when the state is
entered, the terminal performs the action specified by the state type,
and the transaction flow continues from the specified next state.
The following table lists each of the state table types that control
transaction processing using ICC processing:
State Table
Description
Type
A Card Read
G Amount Check
I Transaction Request
T Card Read ‐ PIN Entry Initiation. See Note.
+ Begin ICC Initialisation
, (comma) Complete ICC Initialisation
‐ Automatic Language Selection
. (full stop) Begin ICC Application Selection & Initialisation
/ Complete ICC Application Selection & Initialisation
? Set ICC Transaction Data
; ICC Re‐initialise
z007 EMV Smart DIP Take Card State
z012 EMV ICC Application Switch State

State Tables
Overview
Note: The “T ‐ Card Read ‐ PIN Entry Initiation State” must be used
for chip functionality using a Smart Dip card reader.

State Tables
A - Card Read State
A ‐ Card Read State 2
The Card Read state performs the following actions:
● Displays the screen that you have selected to prompt the
cardholder to enter a card
● Displays the error screen that you have selected if the card
cannot be read
● Sets the Media Entry Indicator flashing while the card reader is
waiting for the cardholder to enter a card. The indicator is
switched off when the card is entered.
● Defines from the read conditions which track(s) and/or chip
data on the card will be read.
For further details of this state type, see the APTRA Advance NDC,
Reference Manual.

State Tables
G - Amount Check State
G ‐ Amount Check State 2
This state checks to see whether the cardholder has entered a whole
amount (for example, dollars only) or a non‐whole amount (for
example, dollars and cents). Two additional checks are performed:
● Whether the amount held within a specified buffer is a multiple
of an identified value.
● Whether the amount held within a specified buffer is
dispensable when taking into account the currency required,
denominations available, dispenser status and cassette status.
Note counts are ignored.
For EMV smart card processing, use the Amount Check state to
more efficiently check the entered amount, instead of submitting an
invalid value to the smart card for authorisation. Submission of an
invalid value to the card would cause an ARQC to be returned, but
the transaction would be subsequently refused as the requested
amount cannot be dispensed, and the smart card would need
re‐initialisation before requesting another amount.
Reference Manual.

State Tables
I - Transaction Request State
I ‐ Transaction Request State 2
This state sends a Transaction Request message to Central, and
executes the Transaction Reply command received from Central.
The information that is to be included in the Transaction Request
message is defined in this state table.
As part of the Advance NDC Transaction Request State, the
terminal optionally performs the CAM processing required to
generate the appropriate data for transmission in the Transaction
Request.
CAM processing is indicated by the presence of an extension state
(identified in table entry 9) which has table entry 8 (Perform EMV
CAM Processing) set to ʹ001ʹ. In order for table entry 9 in the ‘I’ state
to be an extension state, the Most Significant Bit (MSB) of table entry
8 must be set to ‘1’.
If the card declines the transaction then Table Entry 2 of the second
extension state can be used to decline the transaction without
involving the host. See “Application Cryptogram” in Chapter 1,
“Introduction to ICC Processing” and the Advance NDC reference
manual for more details.
All relevant ICC data is sent to Central in the Transaction Request
ʹSmart Card Dataʹ buffer as indicated in “Transaction Request
Message Format” in Chapter 4, “Terminal to Central Messages”.
The processing performed at this point in the transaction flow
Transaction Request consists of the following main steps.
Processing 2
Processing Restrictions 2
The processing restriction checks not already done are now
performed. This involves comparing the cardholder’s selected
transaction against the card’s Application Usage Control.
The other checks which make up the EMV Processing Restrictions
stage are performed earlier in the transaction; see “Processing
Restrictions” in “ICC Application Select & Initialise Processing”.
Terminal Risk Management 2
The terminal will automatically populate the Terminal Floor Limit
data object (tag 0X9F1B) with a value of zero. This will be
overwritten if the host downloads this object in one of the EVM
customisation download messages.

State Tables
The default population of this object can be disabled via a Windows
registry key. If under the key
Exits\TRM a DWORD value called ʺDefault Floor Limitʺ exists
with a zero value then the floor limit data object will not be setup by
the terminal.
By default and providing the floor limit object is populated,
terminal risk management will be performed irrespective of the
setting of the card’s Application Interchange Profile (AIP) object.
If the desired behaviour is for terminal risk management to be based
on the cardʹs AIP value then the
Exits\TRM\Check AIP registry value must be populated with a
non‐zero value.
CVM Processing 2
Cardholder Verification Method (CVM) processing is performed
according to standard EMVCo rules.
The terminal will only recognise and support the ʹEnciphered PIN
verified onlineʹ (0x02/0x42) and ʹFail CVM Processingʹ (0x00/0x40)
CVM codes. However, the terminal will also recognise (but not
support) the codes:
● Plain text PIN, verification performed by ICC (0x01/0x41)
● Plain text PIN, verification performed by ICC, combined with
paper based signature (0x03/0x43)
● Enciphered PIN, verification performed by ICC (0x04/0x44)
● Enciphered PIN, verification performed by ICC, combined with
paper based signature (0x05/0x45)
● Paper based signature (0x1E/0x5E)
● No CVM required (0x1F/0x5F).
As an Advance NDC terminal can only perform transactions online,
only the IAC‐Denial and TAC‐Denial objects are verified against the
Terminal Verification Results (TVR) during terminal action analysis.
The terminal will not approve a transaction offline.
If the result of comparing the Denial objects against the TVR is zero,
an Authorisation Request Cryptogram (ARQC) request to go online
is submitted by the terminal.
If the result of comparing the Denial objects against the TVR is
non‐zero, the ICC application is not usable, and the following
actions are taken:
a The offline denial journaling described in “Offline Decline
Journal Message” is performed.

State Tables
b The ‘Authorisation Response Code’ (tag 0x8A) data object is
created, set to a value of ‘Z1’ and stored.
c An ICC ‘GENERATE AC’ command is used to generate an
Application Authentication Cryptogram (AAC). This command
is submitted with command data obtained by processing the
CDOL1 data object (tag 0x8C).
Card Action Analysis 2
Card action analysis processing is performed according to standard
EMVCo rules.
If the ICC ‘GENERATE AC’ command was successful and the
response data contained the required data objects, the Cryptogram
Information Data (CID) is checked.
If the CID indicates that a Transaction Certificate (TC) was returned,
or that an Application Authentication Cryptogram (AAC) was not
returned when an AAC was requested, a fake ICC application level
error ‘Authentication Failure’ (SW1 = 0x63, SW2 = 0x00) is
generated.
If the CID indicates that an Application Authorisation Referral
(AAR) was returned, a fake ICC application level error
‘Authentication Failure’ (SW1 = 0x63, SW2 = 0x00) is also generated.
Host Processing 2
Central replies with an Interactive Transaction Response (ITR) or a
Transaction Reply. The ITR can also return CAM data prior to the
Transaction Reply.
The ITR and Transaction Reply are validated as per standard
Advance NDC. If this validation fails, a standard command reject or
specific command reject is sent. A new response with or without
CAM data, as appropriate for a rejected Central response, is
awaited.
In addition, if the host response contains CAM data in any of the
following conditions:
● no CAM data was transmitted
● CAM flags transmitted indicated an error (byte 1 bits 2, 3 & 4
and byte 2 bit 6)
● CAM data has already been received in an earlier ITR, or
● the cryptogram returned by the card indicated a decline,
then the Transaction Reply or ITR will be rejected with a specific
command reject of ʹB98ʹ. A new response, without CAM data, will
be awaited.
If any of the following events occur while the host response is being
processed:

State Tables
● issuer script processing suffered an ICC application level error
or formatting error which resulted in a script failing to complete
successfully, and the ‘Enhanced Configuration Parameters
Load’ option number ‘69’ either has no value or has a value in
which bit 3 is not set, or
● issuer script processing encountered an incorrectly formatted
script template, script command, or script identifier, and the
‘Enhanced Configuration Parameters Load’ option number ‘69’
either has no value or has a value in which bit 3 is not set, or
● the ICC ʹGENERATE ACʹ command requested a ʹTCʹ
(Transaction Certificate), but did not get a ʹTCʹ in the command
response,
then if no solicited status message has been sent to the host since
these events, a fake ICC application level error will be generated
with CLA = 0xFF, INS = 0xFF, P1 = 0xFF, P2 = 0xFF, Lc = 0x00, Le =
0x00, SW1 = 0xFF and SW2 = 0xFF. Error processing is performed,
causing the fake ICC application level error to be sent as a solicited
status message to the host. A new response, without CAM data, is
awaited.

State Tables
T - Card Read - PIN Entry Initiation State
T ‐ Card Read ‐ PIN Entry Initiation
State 2
This state must be used for chip functionality of Smart Dip readers,
for example the Smart Hardware (DASH) card reader. However, if a
Smart Dip reader is used as a DIP reader for magnetic tracks only,
the “A ‐ Card Read State” state can also be used.
The “T ‐ Card Read ‐ PIN Entry1 Initiation State” should be used as
shown in the following diagram.

State Tables
‘T’ State Flow Diagram 2
Note: If using a Smart Dip card reader, but no chip connect bit is
set, the reader will behave as a standard DIP reader.
The following points should also be considered:
● If this state is configured to look for a chip, that is the chip
connect bit is set in one or more of the read conditions, Advance
NDC will attempt to power‐on and obtain the Answer To Reset
(ATR) from the chip card. If this is successful, then the magnetic
tracks will not be read. Only if the attempt to obtain the ATR
fails will the magnetic tracks then be attempted to be read.
● If a chip is found, there will be no track 2 data available to
Advance NDC until the “/ ‐ Complete ICC Application Selection
& Initialisation State” has finished successfully and the good
exit from this state is taken. In this case, the Track 2 data will be
derived from the chip data object(s). If any other exit is taken
from this completion state, Track 2 data will not be available for
Advance NDC. To make magnetic Track 2 data available for
Advance NDC the EMV Smart DIP Take Card State must be
used.
● As there is no track data available, the checking that is done on
the Alternative Technology Byte (ATB) of the magnetic stripe in
the “+ ‐ Begin ICC Initialisation State”should be turned off (that
is, table entry 4 should be set to 000).
● Without Track 2 data, the states which require it (for example,
PIN Entry, FIT Switch, Smart FIT Check) will not operate
correctly and so should not be used until the Track 2 data is
available.
● The “+ ‐ Begin ICC Initialisation State” can now additionally
take the ‘ICC Initialisation Not Started’ exit for a Smart Dip
reader, if the Advance NDC Answer To Reset shared buffer is
found to be empty.

State Tables
● If the Smart Dip reader is present, the terminal capabilities
object (tag 9F33) will be populated with the value of 60 40 00 to
reflect that the reader is not capable of card capture.
Reference Manual.

State Tables
+ - Begin ICC Initialisation State
+ ‐ Begin ICC Initialisation State 2
The purpose of this state is to activate parallel processing to perform
the ICC application candidate list build.
In addition, automatic ICC application selection may be performed
if configured via table entry 5 ʹAutomatic ICC Application Selection
Flagʹ.
Table Number of
Contents Description
Entry Characters
1 1 State Type ‘+’
2 3 ICC Initialisation Started Next Next state to process if ICC initialisation has been
State Number started, or if table entry 4 has value 2 and the ATB
(Base 10 Range 000‐254 or value is ʹ2ʹ or ʹ6ʹ indicating a chip is present.
256‐999)
(Base 36 range 000‐254 or
256‐ZZZ)
3 3 ICC Initialisation Not Started Next state to process if ICC initialisation has not
Next State Number been started, or if table entry 4 has value 2 and the
(Base 10 Range 000‐254 or ATB value is neither ʹ2ʹ nor ʹ6ʹ, indicating a chip is
256‐999) not present.
(Base 36 range 000‐254 or ICC initialisation is not started if the ATB condition
256‐ZZZ) in table entry 4 has not been met, or the MCRW
device has a severity of ʹSuspendʹ or ʹFatalʹ.
4 3 ICC Initialisation Requirement Indicates when ICC processing should be initiated.
(Range 000‐002)
000 ‐ Always begin ICC initialisation.
001 ‐ Only begin ICC initialisation if the magnetic
stripe track 2 data has been read and contained an
ATB value of ʹ2ʹ or ʹ6ʹ.
002 ‐Don’t begin ICC initialisation. If the card has a
chip execute the state specified in table entry 2,
otherwise execute the state specified in table entry
3. Only the ATB check is performed.
5 3 Automatic ICC Application Flag to indicate if automatic ICC application
Selection Flag selection is required.
(Range 000‐001)
000 ‐ Cardholder ICC application selection or
confirmation to be performed.
001 ‐ Automatic ICC application selection to be
performed.

State Tables
Table Number of
Entry Characters
6 3 Default Application Label Flag to indicate the action to be taken if an ICC
Usage Flag application name is not provided by an ICC
(Range 000‐002) application during candidate list build processing.
See the following “ICC Initialise and Candidate
List Build” section.
000 ‐ If an ICC application name is not provided,
the corresponding default ‘Application Label’ is
used as the name. If no default label is supplied, the
application is added to the candidate list without
any name.
001 ‐ If an ICC application name is not present, the
default ‘Application Label’ is not used as the name;
the application is added to the candidate list
without any name.
002 ‐ No longer supported. Accepted only for
backward compatibility. If set to this value, the
behaviour is as option ‘001’.
7 3 Cardholder Confirmation Flag Flag to indicate the action to be taken if an ICC
(Range 000‐001) application indicates that cardholder confirmation
is required, via the ʹApplication Priority Indicatorʹ
(tag 0x87) during candidate list build processing.
000 ‐ Do not check if the ICC application requires
cardholder confirmation.
001 ‐ Check if the ICC application requires
cardholder confirmation. If cardholder
confirmation is required then the ICC application is
not added to the candidate list. If the ʹApplication
Priority Indicatorʹ data object is not provided, the
ICC application is treated as not requiring
cardholder confirmation.

State Tables
Table Number of
Entry Characters
8 3 Screen To Clear Screen Number Number of ICC application name screen, which is
(Range 000 ‐ 999) to be overwritten with a single space (0x20)
character. If no screen is to be overwritten, the table
entry is set to ʹ000ʹ.
This table entry is used to enable one PIN entry
state to be used for both magnetic stripe and ICC
transactions.
If this table entry is used, the PIN entry screen used
in the PIN entry state should include the ICC
Application Name Screen, used in table entry 4 of
the “/ ‐ Complete ICC Application Selection &
Initialisation State”. For example, ʺPlease enter
your PIN <SI>xxxʺ, where xxx is the ICC
Application Name Screen number.
The ʹxxxʹ screen content should contain the ICC
Application Name, set up by the “/ ‐ Complete ICC
Application Selection & Initialisation State”, using
the ICC Application Name Template Screen
Number, table entry 3. For example, ʺfor
******************ʺ.
Using this method, for an ICC transaction the
cardholder would be prompted with the message:
ʺPlease enter your PIN for <ICC

Application Name>ʺ
For a magnetic stripe transaction, the cardholder
would be prompted with the message:
ʺPlease enter your PINʺ
The screen number identified by this entry (in this
example ʹxxxʹ) has a single space written to it in this
Begin ICC Initialisation State. This ‘blanks’ the
screen, required when an ICC transaction is
followed by a magnetic stripe transaction, or when
a second ICC transaction fails before the card is
initiated.
9 3 Must be 000 Reserved for future extension state.
If state table entry 5 ‘Automatic ICC Application Selection Flag’ of
the Begin ICC Initialisation State is set to 000, meaning Cardholder
ICC Application Selection, the order of the EMV processing states
should be:

State Tables
Begin ICC Initialisation State
Complete ICC Initialisation State
Begin ICC Application Selection & Initialisation State
Complete ICC Application Selection & Initialisation State
If state table entry 5 of the Begin ICC Initialisation State is set to 001,
meaning Automatic ICC Application Selection, the order of the
EMV processing states should be:
Begin ICC Initialisation State
Complete ICC Application Selection & Initialisation State
In automatic selection, the middle two states in the cardholder
selection example above are not required.
If the MCRW device severity is ʹSuspendʹ or ʹFatalʹ, ICC
Initialisation is not performed. Processing proceeds to the next state
identified in table entry 3 ʹICC Initialisation Not Started Next State
Numberʹ.
If the MCRW device severity is not ʹSuspendʹ or ʹFatalʹ, then the
conditions for performing ICC initialisation, as indicated by table
entry 4 ʹICC Initialisation Requirementʹ, are checked.
If the conditions have been met, the processing identified in “ICC
Initialise and Candidate List Build” below is started in parallel with
the main NDC CAM application. Processing proceeds to the next
state identified in table entry 2 ʹICC Initialisation Started Next State
Numberʹ.
If the conditions have not been met, processing proceeds to the next
state identified in table entry 3 ʹICC Initialisation Not Started Next
State Numberʹ.
If automatic ICC application selection is required, the processing is
started in parallel and the terminal proceeds to the next state
identified in table entry 2 ‘ICC Initialisation Started Next State
Number’. The parallel processing start consists of the steps
described in “ICC Initialise and Candidate List Build” below,
followed by the automatic selection of the highest priority
application and then the processing described in the section “ICC
Application Select & Initialise Processing” on page 2‐29.
The ICC Initialise and Candidate List Build procedure is
ICC Initialise and summarised as follows.
Candidate List Build 2
After successfully powering up the ICC, the ICC is searched for ICC
applications which can be processed by the terminal, for inclusion in
a candidate list.
The ICC is searched for candidates by selecting the Primary AID
Full/Partial Value from each ICC Terminal Acceptable AIDs Table

State Tables
entry in turn, starting with entry ʹ00ʹ and finishing with entry ʹFFʹ
inclusive.
The ICC application‐related data is checked, and if it is found to be
invalid or incorrectly formatted, processing continues using the next
‘ICC Terminal Acceptable AIDs Table’ entry. If there are no more
entries to process, the search process is complete.
To improve the search performance, remaining ICC Terminal
Acceptable AIDs Table entries are selectively eliminated from the
search process, based on the Secondary AID Full/Partial Values held
in each successfully selected Primary AID Full/Partial Value entry.
The eliminated entries are those where the Primary AID value is
shorter than the shortest Secondary AID value, or if the Primary
AID value does not start with the same value as a Secondary AID
value of equal or shorter length.
The following example illustrates this procedure.
For example, if a card has three applications with Acceptable AIDs
26, 27 and 28 and the Acceptable AIDs Table contains:
Primary AID Secondary AID

value value
26 27 and 28
27
28
30
32
In this case, AID value 26 is successfully selected, so 30 and 32 are
filtered out of the list.
AID value 27 is successfully selected, so 28 is filtered out of the list
because there are no secondary entries
There are no more entries to be checked, so the candidate list
consists of values 26 and 27 only.
Note: For all three applications (AIDs 26, 27 and 28) to be accepted
and shown, the AID table entry containing Primary AID value 27
would have to include the Secondary AID value 28.
For details of the ICC Terminal Acceptable Application IDs Table,
see “ICC Terminal Acceptable Application IDs Table” in Chapter 5,
“Central to Terminal Messages”.

State Tables
Canadian List Filtering 2
If there are one or more ICC applications in the EMV candidate list,
Canadian list filtering may now be optionally performed. By
default, this processing is not performed.
Canadian list filtering is performed if the candidate list contains one
or more applications and the registry key \HKEY_LOCAL_MACHINE
\SOFTWARE\NCR\APTRA\EMV EXITS\INTERAC_CAND_List is
present, is of type DWORD, and contains a non‐zero value.
In this case, each application on the current EMV candidate list is
checked and added to either a Canadian primary or Canadian
secondary candidate list, or ignored and not added to either list. The
Canadian primary list, or secondary list if the primary list is empty,
is then used by the terminal from this point onwards.

State Tables
, - Complete ICC Initialisation State
, ‐ Complete ICC Initialisation State 2
The purpose of this state is to await completion of the parallel
processing identified in “Data Object List (DOL) Processing” in
Chapter 7, “ICC Processing”, after activation by State Type “+ ‐
Begin ICC Initialisation State”.
Table Number of
Entry Characters
1 1 State Type ‘,’
2 3 Please Wait Screen Number Optional screen to display while awaiting the
(Range 000‐999) possible completion of ICC initialisation.
If no screen is to be displayed then the table entry is
set to ʹ000ʹ.
3 3 ICC Initialisation Successful Next state number if ICC initialisation was
Next State Number successfully performed.
(Base 10 Range 000‐254 or
256‐999)
256‐ZZZ)
4 3 Card Not Smart Next State Next state number if the ICC was found not to be
Number smart.
256‐999) Note: This path could also be taken if a failure
(Base 36 range 000‐254 or condition occurs which cannot be distinguished
256‐ZZZ) from ‘IC not present on card’, for example dirty
ICC contacts.
5 3 No Usable Applications Next Next state number if ICC initialisation found no
State Number usable ICC applications for inclusion in the
(Base 10 Range 000‐254 or candidate list.
256‐999)
(Base 36 range 000‐254 or If table entry 8 is set to non‐zero, this next state
256‐ZZZ) number is only taken if none of the selected
applications were blocked.
6 3 ICC Application Level Error Next state number if ICC initialisation failed as a
Next State Number result of an ICC application level error.
256‐999) If table entry 8 is set to non‐zero, this next state
(Base 36 range 000‐254 or number is only taken if an ICC application level
256‐ZZZ) error occurred, but this error is not due to a blocked
card.

State Tables
, - Complete ICC Initialisation State
Table Number of
Entry Characters
7 3 ICC Hardware Level Error Next Next state number if ICC initialisation failed as a
State Number result of an ICC hardware level error.
256‐999)
256‐ZZZ)
8 3 No Usable Applications Next state number if there are no usable
(Fallback Forbidden) Next State applications but fallback is forbidden.
Number
(Base 10 Range 000‐254 or If this field is non‐zero, it contains the next state
256‐999) number to take if the card was blocked, or if the
(Base 36 range 000‐254 or ICC initiation found no usable ICC applications for
256‐ZZZ) inclusion in the candidate list, and one or more of
the selected applications was blocked.
If this field is zero, table entry 5 next state number
will be taken when no usable applications were
found, and table entry 6 next state number will be
taken when a blocked card is discovered.
9 3 Must be 000 Reserved.
If this state is entered when the parallel processing described in
“Data Object List (DOL) Processing” of Chapter 7, “ICC Processing”
has not been started, processing proceeds to the default close state.
If the parallel processing has been started but has not yet completed,
and table entry 2 ʹPlease Wait Screen Numberʹ has a value other
than ʹ000ʹ, the screen number identified by table entry 2 is displayed
to the cardholder. The completion of the ICC initialisation parallel
processing is awaited.
When the parallel processing completes, or if parallel processing has
already completed, the appropriate exit path in the previous table is
taken.
Note: If the Complete ICC Initialisation state is entered after
automatic ICC application has been selected in the “+ ‐ Begin ICC
Initialisation State”, then this state will exit to the default close state.

State Tables
- - Automatic Language Selection State
‐ ‐ Automatic Language Selection
State 2
Following the successful completion of State Type ʹ,ʹ (Complete ICC
Initialisation) or State Type ʹ/ʹ (Complete ICC Application Selection
& Initialisation), it may be possible to determine the language
preference of the cardholder from ICC data.
The cardholder language preference can only be determined from
the ICC data if the ʹLanguage Preferenceʹ data object (0x5F2D) is
obtained during ICC application search and selection processing.
Table Number of
Entry Characters
1 1 State Type ‘‐’
2 3 Language Match Next State Next state number if ICC language preference data
Number matches one of those supported at the terminal.
256‐999)
256‐ZZZ)
3 3 No Language Match Next State Next state number if ICC language preference data
Number did not match those supported at the terminal.
256‐999) Note: Screen base, audio base and opcode buffers
(Base 36 range 000‐254 or are unchanged.
256‐ZZZ)
4‐9 18 Must be 000 Reserved.
The languages which Central supports at the terminal are indicated
by the contents of the ICC Language Support Table; see “ICC
Language Support Table” in Chapter 5, “Central to Terminal
Messages”.
Automatic language selection cannot be performed in the following
conditions:
● The ʹLanguage Preferenceʹ data object (0x5F2D) was not
obtained from the ICC
● The ʹICC Language Support Tableʹ has not been downloaded
● ICC parallel processing has not been completed via the
execution of State Type ʹ,ʹ (Complete ICC Initialisation) or State
Type ʹ/ʹ (Complete ICC Application Selection & Initialisation).

State Tables
- - Automatic Language Selection State
If one or more of these conditions occurs, processing proceeds to the
state number identified in table entry 3 ʹNo Language Match Next
State Numberʹ.
If the ʹLanguage Preferenceʹ data object is obtained from the ICC,
automatic language selection can be performed. The ʹLanguage
Preferenceʹ data object contains up to four two‐character language
codes in priority order. Each language code is taken in turn and
compared to the language codes held in the ʹICC Language Support
Tableʹ entries.
If a language code from the ʹLanguage Preferenceʹ data object finds
a match against a language code in an ʹICC Language Support
Tableʹ entry, the opcode buffer, audio base and cardholder screen
base are set to the settings held in the ʹICC Language Support Tableʹ
entry. Processing proceeds to the state number identified in table
entry 2 ʹLanguage Match Next State Numberʹ.
If no match is found between any of the language codes in the
ʹLanguage Preferenceʹ data object and a language code in the ʹICC
Language Support Tableʹ, the opcode buffer, audio base and
cardholder screen base remain unchanged. Processing proceeds to
the state number identified in table entry 3 ʹNo Language Match
Next State Numberʹ.

State Tables
. - Begin ICC Application Selection & Initialisation State
. ‐ Begin ICC Application Selection &
Initialisation State 2
The purpose of this state is to enable the appropriate interaction
with the cardholder, to determine which ICC application is to be
used for CAM processing.
This state must be preceded by the “, ‐ Complete ICC Initialisation
State”.
To use this state with voice guidance, see Voice Guidance.
Table Number of
Entry Characters
1 1 State Type ‘.’
2 3 Cardholder Selection Screen Screen number of the cardholder screen to be used
Number as the menu screen background. This screen is only
(Range 000‐999) displayed when the ICC application to be
processed is being selected by the cardholder.
This table entry is used for the cardholder screen in
all cases, except if there is a single application to be
displayed and table entry 6 is non‐zero, in which
case table entry 6 is used instead.
3 3 FDK Template Screen Numbers State number for the extension state that identifies
Extension State Number which screen numbers hold the ICC application
(Base 10 Range 000‐254 or name templates for use against each FDK (and
256‐999) indirectly which of the FDKs are to be used).
256‐ZZZ)
4 3 Action Keys Extension State State number for the extension state that identifies
Number the FDK for each action key, and the numbers of
(Base 10 Range 000‐254 or the screens holding the text for each FDK used as
256‐999) an action key.
256‐ZZZ)

State Tables
Table Number of
Entry Characters
5 3 Exit Paths Extension State State number for the extension state that identifies
Number the next state numbers for the exit paths from this
(Base 10 Range 000‐254 or state.
256‐999)
256‐ZZZ)
6 3 Single Application Cardholder Screen number of the cardholder screen to be used
Selection Screen Number as the menu screen background when one
(Range 000‐999) application is displayed. If this entry is zero, the
screen defined in state table entry 2 is used as the
menu screen background in all cases.
FDK Template Screen
Numbers Extension State 2
Table Number Of
Entry Characters
1 1 State Type ‘Z’
2 3 FDK A ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK A.
(Range 000‐999)
A value of ʹ000ʹ indicates that this FDK is not used.
3 3 FDK B ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK B.
(Range 000‐999)
4 3 FDK C ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK C.
(Range 000‐999)
5 3 FDK D ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK D.
(Range 000‐999)
6 3 FDK F ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK F.
(Range 000‐999)

State Tables
Table Number Of
Entry Characters
7 3 FDK G ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK G.
(Range 000‐999)
8 3 FDK H ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK H.
(Range 000‐999)
9 3 FDK I ICC Application Name Screen number to use as a template for the display
Template Screen Number of the ICC application name against FDK I.
(Range 000‐999)
Action Keys Extension
State 2
Table Number Of
Entry Characters
2 3 More Applications Screen Screen number to be displayed when the FDK is
Number activated, to enable the cardholder to access the
(Range 000‐999) next screen of ICC application names.
3 3 FDK For More Applications FDK to be used to allow the cardholder to access
(Range 001‐008) the next screen of ICC application names:
008 - FDK I 001 - FDK A

007 - FDK H 002 - FDK B
006 - FDK G 003 - FDK C
005 - FDK F 004 - FDK D
4 3 Back To Start of List Screen Screen number to be displayed when the FDK is
Number activated, to enable the cardholder to return to the
(Range 000‐999) first screen of ICC application names.
5 3 FDK For Back To Start of List FDK to be used to allow the cardholder to return to
(Range 001‐008) the first screen of ICC application names:
008 - FDK I 001 - FDK A

007 - FDK H 002 - FDK B
006 - FDK G 003 - FDK C
005 - FDK F 004 - FDK D

State Tables
Exit Paths Extension State 2
Table Number Of
Entry Characters
2 3 Time Out Next State Number Next state if the cardholder does not respond in
(Base 10 Range 000‐254 or time when input is requested.
256‐999)
256‐ZZZ)
3 3 Cancel Key Next State Number Next state if the cardholder selects cancel when
(Base 10 Range 000‐254 or input is requested.
256‐999)
256‐ZZZ)
4 3 Cardholder Selected Next state number if the cardholder selects an ICC
Application Next State Number application.
256‐999)
256‐ZZZ)
5 3 Application Selected Next state number if the ICC application selection
Automatically Next State is being performed automatically, because there is
Number only one ICC application available.
256‐999)
256‐ZZZ)
6 3 No Usable Applications Next Next state number if there are no ICC applications
State Number for the cardholder to choose from.
256‐999)
256‐ZZZ)
7 3 No Usable Applications Next state number if there are no usable
(Fallback Forbidden) Next State applications, but fallback is forbidden.
Number If this field is non‐zero, it contains the next state
(Base 10 Range 000‐254 or number to take if the last application was
256‐999) successfully declined offline and fallback is not
(Base 36 range 000‐254 or allowed.
256‐ZZZ) If this field is zero, table entry 6 next state number
is taken in all cases when no usable application is
found.

State Tables
To ensure that processing can be performed successfully, the state
parameters are validated to ensure that their values are within the
ranges identified, and that at least two FDKs are available for
displaying ICC application names. If these conditions are not met,
processing proceeds to the default close state; otherwise processing
continues.
If there are no ICC applications present in the candidate list
maintained by the terminal, processing proceeds to the next state in
the ʹExit Paths Extension Stateʹ, table entry 6 ʹNo Usable
Applications Next State Numberʹ.
If option digit 69 bit 4 is not set and there is only one ICC
application present in the candidate list which does not require
cardholder confirmation, and no previous application has been
selected using this menu which was then found to be unusable, the
“ICC Application Select & Initialise Processing” processing
described in the following section is started, using the only ICC
application in the list. Processing then proceeds to the next state
identified in ʹExit Paths Extension Stateʹ table entry 5 ʹApplication
Selected Automatically Next State Numberʹ.
If option digit 69 bit 4 is set and there is only one application, the
“ICC Application Select & Initialise Processing” processing
described in the following section is started, using the only ICC
application in the list. Processing then proceeds to the next state
identified in ʹExit Paths Extension Stateʹ table entry 5 ʹApplication
Selected Automatically Next State Numberʹ.
If there is more than one ICC application present in the candidate
list, or bit 4 of option 69 is not set and either there is only one ICC
application present in the candidate list which requires cardholder
confirmation, or there is now only one ICC application present in
the candidate list and a previous application which was selected via
this menu has been found to be unusable, the ICC application(s) are
presented by name to the cardholder, to allow the cardholder to
select the ICC application to be used for processing. To present the
ICC applications to the cardholder, a menu screen is built up using
the screen number identified in table entry 2 ʹCardholder Selection
Screen Numberʹ as background. The ICC application names are
overlaid based on the appropriate template screens identified in the
ʹFDK Template Screen Numbers Extension Stateʹ.
An FDK position on the menu screen is only used to display an ICC
application name if all the following are true:
● There are sufficient ICC applications so that the FDK position is
required for display of an ICC application name
● The screen number associated with the FDK in the ʹFDK
Template Screen Numbers Extension Stateʹ is not ʹ000ʹ
● The FDK position is not being used for an ʹaction keyʹ.

State Tables
FDK positions are prioritised for use in the order I, A, H, B, G, C, F,
D, where FDK I has the highest priority and FDK D has the lowest
priority. If an FDK position is not available for use, it is eliminated
from the list without changing the precedence of the remaining FDK
positions.
If an FDK position on the menu screen is to be used to display an
ICC application name, the ICC name is overlaid onto the screen
using the template screen number indicated as mapped to the FDK
position by the ʹFDK Template Screen Numbers Extension Stateʹ.
The method used for processing the template screen is described in
“ICC Application Name Display” in Chapter 7, “ICC Processing”.
ICC applications are presented to the cardholder in priority order.
The highest priority ICC application has its name displayed against
the highest priority FDK position available.
If the candidate list contains more ICC applications than can be
presented on a single screen with the available FDKs, multiple
menu screens are used. This is achieved by using the menu screen as
a window on the candidate list. The window is moved around the
list by using action keys which are automatically introduced to the
menu.
If the displayed menu is full of ICC applications and there are more
to be displayed, the FDK identified in table entry 3 ʹFDK For More
Applicationsʹ of the ʹAction Keys Extension Stateʹ is activated, and
the screen number identified in table entry 2 ʹMore Applications
Screen Numberʹ of the same state is displayed.
If the cardholder selects the ‘FDK For More Applications’, the menu
screen is redisplayed with the next set of ICC applications from the
candidate list.
If the displayed menu does not contain the first entry from the
candidate list, the FDK identified in table entry 5 ʹFDK For Back To
Start of Listʹ of the ʹAction Keys Extension Stateʹ is activated, and the
screen number identified in table entry 4 ʹBack To Start of List
Screen Numberʹ of the same state is displayed.
If the cardholder selects the ʹFDK For Back To Start of Listʹ, the
menu screen is redisplayed with the ICC applications from the top
of the candidate list.
If the cardholder selects the ʹFDK For More Applicationsʹ, the menu
screen is redisplayed with the next set of ICC applications from the
candidate list.
If the cardholder selects an ICC application to be used from the
displayed menu screen, the ICC Application Select & Initialise
processing is started, using the selected ICC application. Processing

State Tables
proceeds to the next state identified in ʹExit Paths Extension Stateʹ
table entry 4 ʹCardholder Selected Application Next State Numberʹ.
If the cardholder does not respond to the displayed menu screen in
time, processing proceeds to the next state identified in ʹExit Paths
Extension Stateʹ table entry 2 ʹTime Out Next State Numberʹ.
If the cardholder selects cancel from a displayed menu screen,
processing proceeds to the next state identified in ʹExit Paths
Extension Stateʹ table entry 3 ʹCancel Key Next State Numberʹ.
Note: The screen base offset, used for foreign languages, is not
applied to any screen number used from the ʹFDK Screen Numbers
Extension Stateʹ.

State Tables
The ICC Application Select & Initialise processing consists of the
ICC Application Select & following main steps.
Initialise Processing 2
Application Selection 2
The ICC application from the candidate list, which the terminal or
cardholder has indicated to be used, is selected. If this fails or
returns invalid data, the application is considered unusable.
Processing Options 2
The terminal issues a Get Processing Options command according
to standard EMVCo rules.
Read Records 2
The terminal issues a set of Read Record commands and processes
each response according to standard EMVCo rules.
In addition, if the AID of the current application begins ‘A00000004’
indicating it is a MasterCard application, the ICC Track 2 equivalent
data object (tag 0x57) is checked for consistency with the ICC
Application PAN data object (tag 0x5A) and the ICC application
expiry date data object (tag 0x5F24). If the PAN object does not
match the PAN contained within the Track 2 equivalent data, or the
application expiry data object does not match the application expiry
date encoded in the ICC Track 2 equivalent data, a fake ICC
application level error ‘part of returned data may be corrupted’
(SW1 = 0x62, SW2 = 0x81) is generated.
For the purposes of this check, the location of the PAN encoded
within the ICC Track 2 equivalent data is assumed to be from the
first byte of data to the first field separator. The location of the
application expiry date encoded within the ICC Track 2 equivalent
data is assumed to be the first four characters after the first field
separator.
If this consistency check is not required, create the registry DWORD
\HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\EMV EXITS\
TRACK_CHECK_DISABLED with a non‐zero value.
Processing Restrictions 2
The processing restriction checks performed at this point are the
application version number, application expiry date and application
effective date. The other checks which make up the EMV Processing
Restrictions stage are performed later in the transaction; see
“Processing Restrictions” in “Transaction Request Processing”.

State Tables
The terminal now performs the first of two Terminal Action
Analysis checks. The IAC‐Denial and TAC‐Denial objects are
verified against the Terminal Verification Results (TVR). If the result
of this calculation is zero, the ICC Application Selection & Initialise
processing has successfully completed.
If the result of this calculation is greater than zero, the ICC
application is not usable, and the following actions are taken:
a The offline denial journaling described in “Offline Decline
Journal Message” is performed.
b The ‘Authorisation Response Code’ (tag 0x8A) data object is
created, set to a value of ‘Z1’ and stored.
c An ICC ‘GENERATE AC’ command is used to generate an
Application Authentication Cryptogram (AAC). This command
is submitted with command data obtained by processing the
CDOL1 data object (tag 0x8C).
d The ICC application is removed from the candidate list. If the
candidate list is now empty, a fake ICC application level error
‘File Not Found’ (SW1 = 0x6A, SW2 = 0x82) is generated and
processed as though it resulted from the card.
The performing of terminal action analysis at this point in the
transaction can be disabled by setting the DWORD registry value
EXITS\DISABLE EARLY TAA to a non‐zero value.
Full terminal action analysis will then be performed during the
transaction request processing.

State Tables
/ - Complete ICC Application Selection & Initialisation State
/ ‐ Complete ICC Application
Selection & Initialisation State 2
The purpose of this state is to await completion of the ICC
Application Select & Initialise processing.
If this state is entered when the ICC Application Select & Initialise
processing has not been activated, processing proceeds to the next
state identified in ʹExit Paths Extension Stateʹ table entry 8
ʹProcessing Not Performed Next State Numberʹ.
Table Number of
Entry Characters
1 1 State Type ‘/’
2 3 Please Wait Screen Number Screen to display while awaiting the possible
(Range 000‐999) completion of ICC application selection and
initialisation parallel processing.
If the screen number is set to ʹ000ʹ then no screen is
displayed.
3 3 ICC Application Name Template screen which contains the template to use
Template Screen Number to generate the display data of the screen
(Range 000‐999) containing the selected ICC application name.
If the screen number is set to ʹ000ʹ or is empty, the
ICC application name is not stored, and the screen
number referenced within table entry 4 (if not ʹ000ʹ)
is set to a single space character (0x20).

State Tables
Table Number of
Entry Characters
4 3 ICC Application Name Screen Screen in which the output of processing the
Number template screen is stored, containing the name of
(Range 000‐999) the selected ICC application.
If the screen number is set to ʹ000ʹ, the ICC
application name is not stored.
If an ICC application is not successfully selected
and initialised upon execution of this state, the
indicated screen is set to contain a single space
character (0x20).
5 3 Exit Paths Extension State State number for the extension state that identifies
Number the next state numbers for the possible exit paths
(Base 10 Range 000‐254 or from this state.
256‐999)
256‐ZZZ)
Exit Paths Extension State 2
Table Number Of
Entry Characters
2 3 ICC Application Select & Next state number if the ICC application was
Initialisation Successful Next successfully selected and initialised.
State Number
256‐999)
256‐ZZZ)
3 3 Card Not Smart Next State Next state number if the card was found not to be a
Number smart card (ICC).
256‐999) Note: This path could also be taken if a failure
(Base 36 range 000‐254 or condition occurs which cannot be distinguished
256‐ZZZ) from ‘IC not present on card’, for example dirty
ICC contacts.

State Tables
Table Number Of
Entry Characters
4 3 ICC Application Not Usable Next state number if the selected ICC application
Next State Number was found not to be usable at the terminal.
256‐999)
256‐ZZZ)
5 3 No Suitable ICC Applications Next state number if automatic ICC application
Next State Number selection and initialisation was performed, but no
(Base 10 Range 000‐254 or suitable applications were found.
256‐999)
(Base 36 range 000‐254 or This entry only applies if automatic ICC
256‐ZZZ) application selection was performed.
If table entry 9 is non‐zero, this next state number is
only taken if none of the selected applications were
blocked.
6 3 ICC Application Level Error Next state number if the ICC application selection
Next State Number and initialisation failed as a result of an ICC
(Base 10 Range 000‐254 or application level error.
256‐999)
(Base 36 range 000‐254 or If table entry 9 is non‐zero, this next state number is
256‐ZZZ) only taken if an ICC application level error
occurred, but this error is not due to a blocked card.
7 3 ICC Hardware Level Error Next Next state number if the ICC application selection
State Number and initialisation failed as a result of an ICC
(Base 10 Range 000‐254 or hardware level error.
256‐999)
256‐ZZZ)
8 3 Processing Not Performed Next Next state number if ICC application selection and
State Number initialisation is not being performed, or if this is the
(Base 10 Range 000‐254 or second time the ‘/’ state has been encountered for
256‐999) this transaction.
256‐ZZZ)
9 3 No Usable Applications If this field is non‐zero, it contains the next state
(Fallback Forbidden) Next State number to take if the card was blocked, or if the
Number ICC initiation found no usable ICC applications for
(Base 10 Range 000‐254 or inclusion in the candidate list, and one or more of
256‐999) the selected applications was blocked.
256‐ZZZ) If this field is zero, table entry 5 next state number
is taken when no usable applications were found,
and table entry 6 next state number is taken when a
blocked card is discovered.

State Tables
If the ICC application selection and initialisation parallel processing
has not completed, and table entry 2 ʹPlease Wait Screen Numberʹ
has a value other than ʹ000ʹ, the screen number identified by table
entry 2 is displayed to the cardholder for a minimum of one second.
The completion of the ICC initialisation parallel processing is
awaited.
When the ICC application selection and initialisation parallel
processing completes, or if ICC application selection and
initialisation parallel processing has already completed, the
appropriate exit path from this state is determined.
completes successfully, the ICC application name is placed in the
screen number indicated by table entry 4 ʹICC Application Name
Screen Numberʹ. Table entry 3 ʹICC Application Name Template
Screen Numberʹ is used as a template, as described in “ICC
Application Name Display” in Chapter 7, “ICC Processing”. To use
this state with voice guidance see Voice Guidance.
If there is no name available for the ICC application, the screen
number referenced within table entry 4 (if not ʹ000ʹ) is set to contain
a single space character (0x20). Processing proceeds to the next state
identified in ʹExit Paths Extension Stateʹ table entry 2 ʹICC
Application Select & Initialisation Successful Next State Numberʹ.
was activated as a result of processing State Type ʹ.ʹ (Begin ICC
Application Selection & Initialisation) but failed because the chosen
ICC application was not usable at the terminal, processing proceeds
to the next state identified in ʹExit Paths Extension Stateʹ table entry
4 ʹICC Application Not Usable Next State Numberʹ.
was activated by ICC initialisation parallel processing, but failed
because there was no ICC application suitable for use at the
terminal available and table entry 9 ‘No Usable Applications
(Fallback Forbidden) Next State Number’ is set to zero, processing
proceeds to the next state identified in ʹExit Paths Extension Stateʹ
table entry 5 ʹNo Suitable ICC Applications Next State Numberʹ.
due to a hardware error which occurred on ICC power up
(indicating that the card is not an IC card), processing proceeds to
the next state identified in ʹExit Paths Extension Stateʹ table entry 3
ʹCard Not Smart Next State Numberʹ.
did not complete successfully, due to any hardware error other than
that identified above, processing proceeds to the next state

State Tables
identified in ʹExit Paths Extension Stateʹ table entry 7 ʹICC Hardware
Level Error Next State Numberʹ.
did not complete successfully, due to the ICC returning an
unexpected status value (SW1 SW2) in an ICC command response,
or as a result of a ʹfakeʹ error resulting in processing termination and
table entry 9 ‘No Usable Applications (Fallback Forbidden) Next
State Number’ is set to zero, processing proceeds to the next state
identified in ʹExit Paths Extension Stateʹ table entry 6 ʹICC
Application Level Error Next State Numberʹ.
because there was no ICC application suitable for use at the
terminal available, and table entry 9 ‘No Usable Applications
(Fallback Forbidden) Next State Number’ is set to non‐zero,
processing proceeds to either the next state identified in table entry
5 ‘No Usable Applications Next State Number’ if no blocked
applications were discovered, or the next state identified in table
entry 9 ‘No Usable Applications (Fallback Forbidden) Next State
Number’ if one or more blocked applications were discovered.
did not complete successfully due to the ICC returning an
unexpected status value (SW1 SW2) in an ICC command response,
and table entry 9 ‘No Usable Applications (Fallback Forbidden)
Next State Number’ is set to non‐zero, processing proceeds to either
the next state identified in table entry 9 ‘No Usable Applications
(Fallback Forbidden) Next State Number’ if the error was due to the
card being blocked, or the next state identified in table entry 6 ‘ICC
Application Level Error Next State Number’ for all other errors.
Note: The screen base offset, used for foreign languages, is not
applied to the screen numbers held in table entry 3 ʹICC Application
Name Template Screen Numberʹ and table entry 4 ʹICC Application
Name Screen Numberʹ.

State Tables
? - Set ICC Transaction Data State
? ‐ Set ICC Transaction Data State 2
The purpose of this state is to selectively make transaction specific
data available, for use as part of the ICC data available for ICC
processing.
Table Number of
Entry Characters
1 1 State Type ‘?’
2 3 Next State Number Next state to which processing proceeds.
256‐999) This path is also taken if the ICC is not currently
(Base 36 range 000‐254 or powered up in the SCRW. In this case, all the other
256‐ZZZ) table entries in this state are ignored.
3 3 Currency Type Indicates the reference currency type entry for the
(Range 000‐255) ICC Currency Data Objects Table; see “ICC
Currency Data Objects Table” in Chapter 5,
The data objects mapped to the currency type entry
are made available to the EMV application.
If a value of ʹ000ʹ is used, or no mapping is found,
then no action is taken.
4 3 Transaction Type Indicates the reference transaction type value for
(Range 000‐255) the ʹICC Transaction Data Objects Tableʹ; see “ICC
Transaction Data Objects Table” in Chapter 5,
The data objects mapped to the transaction type are
made known.
If a value of ʹ000ʹ is used, or no mapping is found,
then no action is taken.

State Tables
Table Number of
Entry Characters
5 3 Amount Authorised Source Identifies the source buffer from which the Amount
(Range 000‐041) Authorised data objects (tags 0x9F02 and 0x81) are
derived, and indicates whether the amount in the
buffer requires conversion from major to minor
currency units before being placed in the Amount
Authorised data objects.
00x ‐ Do nothing (no source buffer)
01x ‐ General Purpose Buffer B
02x ‐ General Purpose Buffer C
03x ‐ Amount Buffer
04x ‐ Set Amount Authorised to 0.
Where ‘x’ means the following:
‘0’ ‐ No conversion is required
‘1’ ‐ Conversion is required
Note: Set this flag to ‘1’ (convert major to minor
currency units) only if this conversion has not
already been performed in Advance NDC (for
example, in FDK Information Entry state ‘X’). For
details of this state, see the APTRA Advance NDC,
Reference Manual.
If a conversion from major to minor currency units
is required, the value held within the ʹTransaction
Currency Exponentʹ data object (tag 0x5F36) is used
to indicate how many trailing zeroes are to be
added to the amount in the buffer when placed in
the Amount Authorised data objects.
If the ʹTransaction Currency Exponentʹ data object
(tag 0x5F36) is not available or has no value field,
no conversion is made.
Table entry 3 is processed before this table entry to
ensure the ʹTransaction Currency Exponentʹ data
object can be set, before it is required by the
conversion processing.
Note: The source buffer is not altered by this
conversion.
Amount Authorised data objects are only made
known or changed when this state is executed
within a transaction.

State Tables
Table Number of
Entry Characters
6 3 Amount Other Source Identifies the source buffer from which the
(Range 000‐041) ʹAmount Otherʹ data objects (tags 0x9F03 and
0x9F04) will be derived and indicates whether the
amount in the buffer will require conversion, from
major to minor currency units, before being placed
in the ʹAmount Otherʹ data objects.
00x ‐ Do nothing (no source buffer)
01x ‐ General Purpose Buffer B
02x ‐ General Purpose Buffer C
03x ‐ Amount Buffer
04x ‐ Set Amount Other to 0.
Where ‘x’ means the following:
‘0’ ‐ No conversion is required
‘1’ ‐ Conversion is required
Note: Set this flag to ‘1’ (convert major to minor
currency units) only if this conversion has not
already been performed in Advance NDC (for
example, in FDK Information Entry state ‘X’). For
details of this state, see the APTRA Advance NDC,
Reference Manual.
If a conversion from major to minor currency units
is required, the value held within the ʹTransaction
Currency Exponentʹ data object (tag 0x5F36) is used
to indicate how many trailing zeros are to be added
to the amount in the buffer when placed in the
ʹAmount Otherʹ data objects.
If the ʹTransaction Currency Exponentʹ data object
(tag 0x5F36) is not available, or has no value field,
then no conversion is made.
Table entry 3 is processed before this table entry to
ensure the ʹTransaction Currency Exponentʹ data
object can be set before the conversion processing
requires it.
Note: The source buffer is not altered by this
conversion.
Amount Other data objects are only made known
or changed when this state is executed within a
transaction.

State Tables
Table Number of
Entry Characters
7 3 Amount Too Large Next State Next state to which processing will proceed if the
Number amount requested is too large to fit into the
(Base 10 Range 000‐254 or Amount Authorised or Amount Other objects.
256‐999)
256‐ZZZ)
8 3 Must be 000 Reserved.
9 3 Must be 000 Reserved for future extension state.
Note: The Set ICC Transaction Data state will take the default close
exit if the amount authorised source parameter (table entry 5) is
invalid.

State Tables
; - ICC Re-initialise State
; ‐ ICC Re‐initialise State 2
The ICC Re‐initialisation state re‐initialises the current chip
application ready for the next transaction. It may be needed in two
scenarios:
● successful completion of a transaction and the cardholder
wishes to perform another transaction with the same chip
application
● the transaction cannot complete and the flow designer
wishes the cardholder to have the option to alter their
selection and try again. For example, an incorrect PIN,
insufficient funds or an undispensable amount.
In the second case the normal host behaviour is to decline the
current EMV transaction and direct the state flow to re‐initialise the
chip application before allowing the cardholder to try again. The
decline and then re‐initialisation is required because the chip
application may make the transaction decision based on the
information on the current transaction being carried out and this
could differ on the second attempt. For example in the case of
insufficient funds the transaction amount would be different for
each transaction.
Re‐initialisation of an ICC application can only be performed if the
ICC is currently in the SCRW, powered on, with an ICC application
selected, and with no parallel ICC processing currently being
performed.
If the ICC application is already in a usable state and re‐initialisation
is not required no action will be taken and the Processing Not
Performed Next State Number exit will be taken.

State Tables
Table Number of
Entry Characters
1 1 State Type ‘;’
2 3 Good Next State Number Next state to which processing proceeds if
(Base 10 Range 000‐254 or re‐initialisation of the ICC application can be
256‐999) performed.
256‐ZZZ)
3 3 Processing Not Performed Next Next state to which processing proceeds if
State Number re‐initialisation of the ICC application is not being
(Base 10 Range 000‐254 or performed.
256‐999)
256‐ZZZ)
4 3 Re‐initialisation method (000 or 000 ‐ Restart the transaction at the candidate list
001) build process.
001 ‐ Restart the transaction at the final SELECT
command.
5 3 Chip Power control (000 ‐ 003) 000 indicates default behaviour
001 forces a cold reset to be performed on the chip
002 forces a warm reset to be performed on the chip
003 means do not interrupt power to the chip.
6 3 Reset or Retain Terminal Retain or reset the terminal objects.
Objects 000 ‐ resets all EMV objects for the re‐initialised
transaction.
001 ‐ Resets all EMV objects except for the ones
EMVco defines as supplied by the terminal.
7‐9 9 Must be 000 Reserved
Note: Default behaviour is a warm start for restarting the
transaction at the candidate list build phase and no power
interruption if restarting the transaction at the final SELECT
command. A cold start means powering off the chip and then
powering it back on. A warm start means powering on a chip which
is already powered on.
If the host does not support the setting of state table entries 4 to 6 the
behaviour can also be set via the Windows Registry. The registry
entry values are identical to the state table, however the registry
settings are only used if the state table entry is set to zero.
Reinit Method (DWORD) controls where the transaction should
restart.

State Tables
chip power cycle (DWORD) controls the power‐cycle to use.

Retain Terminal Objects (DWORD) which controls if the
terminal based objects should be cleared.
The terminal will look for these three entries in one of two places in
the registry.
Either \HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\EMV
EXITS\reinitialise state\<xxx> where <xxx> is the three
character state number for the current re‐initialisation state or
EXITS\reinitialise state\default by default, if no
matching entry for the current state number can be found.
As part of the ICC Re‐initialisation state processing all EMV objects
are reset by the terminal. This is the required behaviour when after
the successful completion of one transaction, another using the
same application is offered to the cardholder.
If however the same transaction is to be repeated, for example in the
case of an incorrect PIN, the state can be configured to retain the
terminal based objects in table entry 6 or via the registry.
If re‐initialisation cannot be performed, processing proceeds to the
next state identified in table entry 3 ʹProcessing Not Performed Next
State Numberʹ.
If re‐initialisation can be performed, the processing identified by
“ICC Initialise and Candidate List Build” on page 2‐15 is started in
parallel, and is performed using the ICC application currently
selected. Automatic selection of the ICC application is handled by
the processing described in “ICC Application Select & Initialise
Processing” on page 2‐29.
The result of this parallel processing is acted upon in State Type ʹ/ʹ
(Complete ICC Application Selection & Initialisation) as
appropriate, to give the final result of the re‐initialisation
processing.
Processing then proceeds to the next state identified in table entry 2
ʹGood Next State Numberʹ.

State Tables
z007 - EMV Smart DIP Take Card State
z007 ‐ EMV Smart DIP Take Card
State 2
This state is required to support fallback to magnetic stripe for a
chip based transaction when using a Smart Dip reader. The state
prompts the cardholder to remove their card, reads the magnetic
stripe information and then performs a FIT match.
This state should be used together with state type ‘T ‐ Card Read ‐
PIN Entry Initiation State’ to provide an application flow which
supports fallback prior to the first Generate Application
Cryptogram command. Fallback is not available at the first Generate
Application Cryptogram command.
‘z007’ State Flow Diagram 2
On entry to the state a check will be made of the type of reader and
if it is not a Smart Dip reader then the ʹGood Read Next State
Numberʹ [table entry 4] will be taken.
If there is no card in the reader then the ʹTimeout, Bad Read, No FIT
Match Next State Numberʹ [table entry 8] will be taken.
Timer 72 will be started, the card reader Media Entry Exit Indicator
(MEEI) and beeper will be enabled.

State Tables
If the card is not removed before timer 72 expires then the MEEI and
beeper will be disabled and the ʹTimeout, Bad Read, No FIT Match
Next state numberʹ [table entry 8] will be taken.
If the currently selected application matches a Terminal Application
Acceptable ID, when the card is removed from the card reader the
MEEI will be disabled, the beeper will be stopped and timer 72
stopped.
The tracks that were successfully read will be checked against the 3
read conditions in turn [Table entries 5, 6 and 7]. If no read
conditions can be satisfied the ʹTimeout, Bad Read, No FIT Match
Next state numberʹ [table entry 8] will be taken. If the chip connect
bit is set in any of the read conditions it will be ignored.
If any of the read conditions can be met then a FIT match will be
performed.
If a no FIT match is found then the ʹTimeout, Bad Read, No FIT
Match Next state numberʹ [table entry 8] will be taken.
If a FIT match is found then the ʹGood Read Next State Numberʹ
[table entry 4] will be taken.
Following a successful read the Begin ICC Initialisation state with
the ICC Initialisation Requirement state entry set to 002 can be used
to branch the state flow depending on if the magnetic stripe
indicates a chip was present.
Table Number of
Entry Characters
1 1 State Type ʹzʹ Master Expansion State
2 3 007 EMV Smart Dip Take Card State
3 3 Take Card Screen Number Screen displayed requesting the cardholder to
(000‐999) remove their card.
4 3 Good Read Next State Number State number the terminal proceeds to following a
(Base 10 Range 000‐254 or good read of the card and a successful FIT match.
256‐999) This is also taken if the reader is not a Smart Dip
(Base 36 range 000‐254 or variant.
256‐ZZZ)
5 3 Read Condition1 As read conditions in the Card Read State A.

State Tables
Table Number of
Entry Characters
8 3 Timeout, Bad Read, No FIT This is the next state number if the customer does
Match Next State Number not remove their card within the time period of
(Base 10 Range 000‐254 or timer 72, or the magnetic tracks cannot be read or,
256‐999) if the tracks were read, no fit match could be found.
256‐ZZZ)
9 3 Must be 000. Reserved.

State Tables
z012 - EMV Application Switch State
z012 ‐ EMV Application Switch State 2
This state allows branching of the state flow based on the currently
selected application. It is designed to allow different terminal
behaviours for different applications. This state associates a
Terminal Application Acceptable ID entry number to a next state
number using pairs of extension states. The first extension state of a
pair contains Terminal Application Acceptable ID entry numbers.
The second extension state of a pair contains next state numbers. If a
Terminal Application Acceptable ID entry number for the current
application is found in the first extension state of a pair the
corresponding table entry of the second extension state of the pair is
used to provide the next state number.
Number of
Table Entry Contents Description
Characters
1 1 State Type ‘z’(0x7a) Master Expansion State
2 3 012 EMV ICC Application Switch State
3 3 Next State Number ‐ No Match This state will be taken if there is no match for
(Base 10 Range 000‐254 or the currently selected application index, or if
256‐999) there is no application currently selected by the
(Base 36 range 000‐254 or terminal.
256‐ZZZ)
4 3 Terminal Application Mandatory extension state containing a list of
Acceptable ID Entry Extension terminal acceptable entry numbers
1
256‐999)
256‐ZZZ)
5 3 Next State Number Entry 1 Mandatory extension state containing a list of
(Base 10 Range 000‐254 or next state numbers.
256‐999)
256‐ZZZ)
6 3 Terminal Application Optional extension state containing a list of
Acceptable ID Entry Extension terminal acceptable entry numbers.
2
256‐999)
256‐ZZZ)

State Tables
Number of
Characters
7 3 Next State Number Entry 2 Optional extension state containing a list of next
(Base 10 Range 000‐254 or state numbers.
256‐999)
256‐ZZZ)
8 3 Terminal Application Optional extension state containing a list of
Acceptable ID Entry Extension terminal acceptable entry numbers.
3
256‐999)
256‐ZZZ)
9 3 Next State Number Entry 3 Optional extension state containing a list of next
(Base 10 Range 000‐254 or state numbers.
256‐999)
256‐ZZZ)

State Tables
This extension state contains a number of Terminal Acceptable ID
Terminal Application entry numbers. The terminal will look for the number of the
Acceptable ID Entry currently selected card application in this list. Extension states of
Extension State 2 this type are referred to by table entries 4, 6 and 8 of the Master
Expansion state. There must be at least one and a maximum of three
extension state types of this kind associated with the EMV
Application Switch State.
Number of
Characters
1 1 State Type ʹZʹ Extension State for EMV ICC
Application Switch State
2 3 Terminal Application Acceptable This entry is associated with table entry 2 of
ID entry number the Next State Number Extension state and
(Range 000 to 255 contains the value used for matching
against the Terminal Application
Acceptable ID entry number of the
currently selected application.
(Range 000 to 255) contains the value used for matching

State Tables
Number of
Characters

State Tables
This extension state contains a number of Next State numbers. If the
Next State Number Entry terminal matches the currently selected card application with an
Extension State 2
entry in the Terminal Application Acceptable ID Entry Extension
State then the Next State number in the corresponding table entry in
this state will be used as the state number to branch to. Extension
states of this type are referred to by table entries 5, 7 and 9 of the
Master Expansion state. There must be at least one and a maximum
of three extension state types of this kind associated with the EMV
Application Switch State.
Number of
Characters
1 1 State Type ʹZʹ Extension State for EMV ICC
Application Switch State
2 3 Next State Number Next state number taken if the Terminal
(Base 10 Range 000‐254 or 256‐999) Application Acceptable ID entry number
(Base 36 range 000‐254 or 256‐ZZZ) for the currently selection application
matches table entry 2 of the associated
Terminal Application Acceptable ID Entry
Extension State.
Extension State.
Extension State.
Extension State.
Extension State.

State Tables
Number of
Characters
Extension State.
Extension State.
Extension State.

State Tables

Table of Contents
Chapter 3
Overview 3‐1
Enhanced Configuration Parameters Load Message 3‐2

Table of Contents

C
Overview
Overview 3
This chapter describes how to use the following to support an ICC:
● Enhanced Configuration Parameters Load Message
● CAM/EMV Extended Status option 69
● CAM/EMV ICC (Smart Card) option 70

Enhanced Configuration Parameters Load Message
Enhanced Configuration Parameters
Load Message 3
This message supports the configuration of options and timers,
including available options that are not supported in the
Configuration Parameters Load message.
For details of the format of the entire Configuration Parameters
Load or Enhanced Configuration Parameters Load Message, refer to
the APTRA Advance NDC, Reference Manual.
The options relevant to ICC use are the CAM/EMV Extended Status
option 69, and the CAM/EMV ICC (Smart Card) option 70; these are
shown below.
Number of
Field Mandatory/Optional Description
Characters
a to i Var ‐ See the APTRA Advance NDC, Reference Manual.
j 3 O Option Code. Defines the option to be exercised for the above option
number. Option number and option codes are defined below.
Option Description of Option
0 See the APTRA Advance NDC, Reference Manual.
to
68
69 CAM/EMV Extended Status option. The possible values are:
Not set/Bit 1 not set ‐ the ICC command and response data is
not included in ICC application error solicited/unsolicited
error messages. This is the default.
Bit 1 set ‐ ICC command data (field g4h/e4h) and response
data (g4j/e4j) is included in ICC application error
solicited/unsolicited error messages.
Bit 2 set ‐ Software version numbers are included.
Bit 3 set ‐ Solicited script errors are not included.
For additional information, see “ICC Application Solicited/
Unsolicited Error Message” in Chapter 4, “Terminal to Central
Messages”.

Number of
Characters
Bit 4 not set – A single application may be displayed during
cardholder application selection. See the processing described
in “Exit Paths Extension State” in “. ‐ Begin ICC Application
Selection & Initialisation State”.
Bit 4 set – A single application is never displayed for
cardholder application selection, but instead is automatically
selected by the terminal. In this case, the “. ‐ Begin ICC
Application Selection & Initialisation State” processing is
performed as in previous releases.
70 CAM/EMV ICC (Smart Card) Manipulation Flag.
This option has no effect in APTRA Advance NDC.
FS 1 See Note Field Separator.
k Var O See the APTRA Advance NDC, Reference Manual.
to
n
Note: This field separator must be present if any of the later fields
in the message are present.


Table of Contents
Chapter 4
Overview 4‐1
Terminal Application Version Information 4‐2
Terminal Hardware Information 4‐4
Transaction Request Message Format 4‐5
Message Format 4‐5
CAM Flags 4‐8
Solicited Status Messages 4‐10
Command Rejects 4‐10
Unsolicited Status Messages 4‐11
Supervisor Keys (Unsolicited) 4‐11
SCRW/MCRW Hardware Error Reporting 4‐13
Errors During Chip Power‐Up 4‐14
ICC Application Solicited/ Unsolicited Error Message 4‐15
Issuer Script Results and Completion Data 4‐17

Table of Contents

D
Overview
Overview 4
This chapter provides information on the following topics:
● Terminal Application Version Information
● Terminal Hardware Information
● Transaction Request Message Format
● Solicited Status Messages (Command Rejects)
● Unsolicited Status Messages
● SCRW/MCRW Hardware Error Reporting
● Errors During Chip Power‐Up
● ICC Application Solicited/Unsolicited Error Message
● Issuer Script Results and Completion Data.

Terminal Application Version Information
Terminal Application Version
Information 4
To enable Central to identify terminals loaded with the CAM
software, the terminal’s response to a Terminal Command message
with Command Code ‘7’ (Send Configuration Information) with or
without Command Modifier ‘5’ (Send Software ID/Send
Configuration Information) has the relevant field ‘g2’ or ‘g7’
formatted as follows:
Number of
Characters
g2/ ‐ ‐ Terminal Application Version Information ‐ see following sub‐fields:
g7
g2a/ 6 M Advance NDC Release Number. ASCII decimal value.
g7a
For example, for Advance NDC 03.01.00, this field would be ‘030100’.
GS 1 See Notes 1 & 2 Group Separator.
g2b/ 3 See Notes 1, 2 Terminal Application Component Identifier.

g7b and 3
‘INT’ ‐ NDC Interface component present.
‘ICC’ ‐ ICC Processing Core component present.
‘CAM’ ‐ CAM ICC application component present.
‘INT’ is the EMV/CAM2 Exits for APTRA Advance NDC interface
component, which links the EMV kernel components (ICC and CAM)
to Advance NDC.
g2c/ 6 See Notes 1, 2 Terminal Application Component Release Number.

g7c and 3 ASCII decimal value for release number of previous component.
For example, for ICC version 02.01.00, this field would be ʹ020100ʹ.
For CAM version 02.00.00, this field would be ʹ020000ʹ.
Note 1: These fields are repeated for each terminal application
component that is present in addition to Advance NDC. If there are
no additional terminal application components present, these fields
are omitted.
Note 2: These fields are only included if ʹEnhanced Configuration
Parameters Loadʹ option number ʹ69ʹ has a value in which bit 2 is
set.

Terminal Application Version Information
Note 3: The g7 field is only included in the message to Central if the
appropriate message mode option is set. This is not applicable to the
g2 field, which will always be present when Command Modifier ‘5’
is used. The option digit number is 6c. For details, see the APTRA
Advance NDC, Supervisor’s Guide.
For example, Advance NDC 03.01.00 with additional terminal
application components for the NDC Interface coordination
(version 02.02.00), ICC Processing Core handling (version 02.01.00)
and CAM (version 02.00.00) would result in field ʹg7ʹ / ʹg2ʹ
containing the following:
030100<GS>INT020200<GS>ICC020100<GS>CAM020000
To enable local terminal operators to identify terminals loaded with
the NDC CAM software, the version levels for the NDC software
and additional terminal application components are printed to the
journal at power up.
Note 4: If the message mode option is set, the g8 field (Software
Identifier ‘B’ and Software ID Gxxx‐xxx) will, by default, be
included in the message.

Terminal Hardware Information
Terminal Hardware Information 4
To enable Central to identify terminals configured with a Smart
Card Reader Writer (SCRW), the terminal’s response to a Terminal
Command message with Command Code ‘7’ (Send Configuration
Information) with or without Command Modifier ‘1’ (Send
Hardware Configuration/Send Configuration Information) can
indicate in field ʹg4ʹ that the SCRW is one of the following smart
card variants:
Value (Hex) Variant Description
08 Track 2 Smart Card Reader
09 Track 1/2/3 Smart Card Reader
0A 3 Track Write Smart Card Reader
1D Dip And Smart Hardware (DASH) Card Reader
1F Track 123 Smart Card Reader with MM
20 Track 3 Smart Card Reader with MM
Note: The reported variant is dependent on the installed device.
For a complete list of all the possible MCRW/SCRW variants in
APTRA Advance NDC, including the non‐smart card MCRW
values, see the APTRA Advance NDC, Reference Manual.

Transaction Request Message Format
Transaction Request Message Format 4
This section defines the format of the additional smart card ‘bd1’
data contained in the Transaction Request message. This message
will then also contain the smart card data that Central needs in
order to authorise a smart card cardholder transaction at the
terminal.
The message is sent during a cardholder transaction, either on entry
to the Transaction Request state or as part of an Interactive
Transaction message sequence.
For full details of the Transaction Request Message Format, see the
For details of the issuer script results and completion data which
can be included, see the “Issuer Script Results and Completion
Data” section.
Message Format 4
Number of
Characters
FS 1 See Note 1 Field Separator.
bd1 1 See Note 1 Buffer identifier. The value is fixed as ʹ5ʹ to indicate smart card data.
bd2 ‐ ‐ Smart card data ‐ see sub‐fields:
bd2a 3 See Note 1 Smart card data identifier.
CAM ‐ data in buffer is for CAM

Number of
Characters
bd2b 4 See Note 1 CAM Flags.
For values, see the following ‘CAM Flags’ section.
bd2c Var. See Notes 1, 2 ICC data objects requested by Central.

and 3
All the available data objects referenced in field f11 of the ICC
Terminal Acceptable Application IDs Table entry, and for which the
Full/Partial Primary Application ID Value matches the currently
selected ICC Application AID, are included in this field as individual
BER‐TLV formatted data objects. For details, see “ICC Terminal
Acceptable Application IDs Table” in Chapter 5, “Central to Terminal
Messages”.
As an example, with the following data:
Application Identifier (AID) 0x9F06

Track 2 Equivalent Data 0x57
Application PAN 0x5A
Application PAN Sequence Number 0x5F34
Cryptogram Information Data 0x9F27
Application Cryptogram 0x9F26
Issuer Application Data 0x9F10
Application Interchange Profile (AIP) 0x82
Application Transaction Counter (ATC) 0x9F36
CDOL1 0x8C
PIN Retry Count 0x9F17
This field would contain the following (actual values will vary):
ʹ9F 06 07 A0 00 00 00 08 00 01 57 12 12 34 56 78 90 12 34 56 78 90 D9 90
10 81 23 45 67 89 5A 0A 12 34 56 78 90 12 34 56 78 90 5F 34 01 00 9F 27 01
00 9F 26 08 12 34 56 78 90 12 34 56 9F 10 07 06 01 01 03 A0 00 00 82 02 7C
00 9F 36 02 01 23 8C 15 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03
9C 01 9F 37 04 9F 17 01 03ʹ

Number of
Characters
bd2d Var See Notes 1, 2, 3 Further ICC data objects requested by Central; see “ICC Transaction

and 4 Data Objects Table” in Chapter 5, “Central to Terminal Messages”.
All the available data objects referenced within Card Risk
Management Data Object List 1 (CDOL1, tag 0x8C) are included in this
field as individual BER‐TLV formatted data objects.
If a BER‐TLV data object is referenced in CDOL1, but is already
present in field bd2c, it is not repeated in this field.
As an example, if CDOL1 references the following tags (as per Visa
Cryptogram Version Number 10):
Amount, Authorised 0x9F02

Amount, Other 0x9F03
Terminal Country Code 0x9F1A
Terminal Verification Results (TVR) 0x95
Transaction Currency Code 0x5F2A
Transaction Date 0x9A
Transaction Type 0x9C
Unpredictable Number 0x9F37
Then this field would contain the following (actual values will vary):
ʹ9F 02 06 00 00 00 00 20 00 9F 03 06 00 00 00 00 00 00 9F 1A 02 08 26 95 05
80 00 04 00 00 5F 2A 02 08 26 9A 03 00 07 11 9C 01 00 9F 37 04 78 12 25
98ʹ
Note 1: These fields are only included in the Transaction Request if
all the following are true:
● The Transaction Request State identified that the optional
CAM processing was to be performed
● An attempt has been made to select a CAM ICC application
from the candidate list since the last execution of the
transaction request state
● ICC processing is not still active (that is, the appropriate
completion state has been processed).
Note 2: If no data objects are identified, none are present and
effectively this field is absent.
Note 3: If a data object held in fields ʹbd2cʹ and ʹbd2dʹ is not
available, the data object is not present.
Note 4: If CDOL1 has invalid content, as described in “Data Object
List (DOL) Processing” in Chapter 7, “ICC Processing”, no data

objects are present in field ʹbd2dʹ, effectively making this field
absent.
There are 16 available CAM flags. These are encoded as the bits in
CAM Flags 4
two bytes, and are converted to ASCII hex (four bytes) for
transmission. Each can have the value 0 or 1, with the following
meanings:
Byte Bit Value Description
1 8 ‐ Reserved.
7 ‐ Reserved.
6 0 or 1 0 ‐ Full CAM processing
1 ‐ Partial CAM processing
5 0 or 1 0 ‐ Transaction not declined offline.
1 ‐ Transaction declined offline.
4 0 or 1 0 ‐ Application data retrieval successful.
1 ‐ Application data retrieval failed.
3 0 or 1 0 ‐ Get processing options successful.
1 ‐ Get processing options failed.
2 0 or 1 0 ‐ Application selection successful.
1 ‐ Application selection failed.
1 ‐ Reserved.
2 8 0 or 1 0 ‐ Processing options Data Object List (PDOL) data valid.
1 ‐ PDOL data invalid.
7 0 or 1 0 ‐ Card risk management Data Object List 1 (CDOL1) data valid.
1 ‐ CDOL1 data invalid.
6 0 or 1 0 ‐ Generate Application Cryptogram (AC) successful.
1 ‐ Generate AC failed.
5 ‐ Reserved.
4 0 or 1 0 ‐ CAM processing not yet successfully performed.
1 ‐ CAM processing previously successfully performed.
3 1 CAM processing was initiated.
2 0 Reserved.
1 0 Reserved.
If CAM processing was previously completed successfully in a
transaction chain (for example, was completed on the first service,
prior to the second service, and within the same card insertion),
then byte 2 bit 4 indicates this.
The points of successful completion are:

a when CAM processing performs the second ICC ‘GENERATE
APPLICATION CRYPTOGRAM’ command requesting a
Transaction Certificate (TC) and obtains a TC, or
b when CAM processing performs the second ICC ‘GENERATE
APPLICATION CRYPTOGRAM’ command requesting an
Application Authorisation Cryptogram (AAC) and obtains an
AAC.
If an unexpected failure occurs during processing, the point of
failure is indicated by byte 1, bits 2 to 4 inclusive and byte 2, bit 6.
Only one of these bits can be set to 1; all others will default to 0.
These bits are independent of byte 2, bits 2 to 4 inclusive and byte 2,
bits 7 and 8.
If an attempt is made to select an application from the candidate list
and it fails, byte 1 bit 2 is set to 1.
If the PDOL is processed and is found to be invalid, due to contents
not being correct or because the concatenated value length is greater
than can be submitted to the ICC in an ICC ʹGET PROCESSING
OPTIONSʹ command, byte 2 bit 8 is set to 1.
If an application is selected and the ICC ʹGET PROCESSING
OPTIONSʹ command fails, byte 1 bit 3 is set to 1.
If the ICC ʹGET PROCESSING OPTIONSʹ command was performed
and was successful, the data returned is processed. If this processing
fails, or the data required is not obtained, byte 1 bit 4 is set to 1.
If the CDOL1 is processed and is found to be invalid due to contents
not being correct or because the concatenated value length is greater
than can be submitted to the ICC in an ICC ʹGENERATE
APPLICATION CRYPTOGRAMʹ command, byte 2 bit 7 is set to 1.
If an ICC ʹGENERATE APPLICATION CRYPTOGRAMʹ command
is submitted with CDOL1 but fails, byte 2 bit 6 is set to 1.
If an ICC ‘GENERATE APPLICATION CRYTOGRAM’ command is
submitted during ICC transaction request processing, and the card
responds with an AAC indicating a decline, then byte 1 bit 5 is set to
1. For all other scenarios, byte 1 bit 5 is set to 0.
If byte 1, bit 6 is 1 this indicates that no EMV processing has been
done after the Complete Application Selection state. The transaction
request will contain any object which is known and has been
requested by central.
This is enabled via the transaction request state and can be used to
provide Dynamic Currency Conversion.

Solicited Status Messages
Solicited Status Messages 4
CAM introduces the possibility of new values in the solicited status
messages, specifically as new command rejects.
CAM includes the following new specific command reject values:
Command Rejects 4
Value Meaning
B91 ICC Currency Data Objects Table data has invalid
data/format.
B92 ICC Transaction Data Objects Table data has invalid
data/format.
B93 ICC Language Support Table data has invalid data/format.
B94 ICC Terminal Data Objects data has invalid data/format.
B95 Reserved.
B96 Reserved.
B97 CAM data not received in Central responses when sent in
Transaction Request, or was sent but had invalid
data/format.
B98 CAM data received in Central response when not sent in
Transaction Request, or when already received in an
earlier response corresponding to the same Transaction
Request.
B99 Dispense Function id received with an EMV decline.
This reject value is not sent by default but can be enabled
using the Windows registry see “Windows Registry
Settings” on page 7‐50.
Wxx ICC Terminal Acceptable Application IDs Table data has
invalid data/format
Where ʹxxʹ is an ASCII hex value in the range ʹ00ʹ to ʹFFʹ
inclusive identifying which entry number failed.
If the entry number is not available or is out of range, ʹxxʹ
defaults to ʹFFʹ.
Note: These specific command rejects will be replaced with a
standard command reject (ʹAʹ) if specific command reject processing
has not been enabled. For the purpose of this document, it is
assumed that specific command reject processing is enabled.

Unsolicited Status Messages
Unsolicited Status Messages 4
CAM introduces the possibility of new values in the unsolicited
status messages, specifically in supervisor key messages.
This message is sent to inform Central of the functions selected by
Supervisor Keys the operator after entry to Supervisor mode.
(Unsolicited) 4
Number of
Field Content
Characters
e1 1 Device Identifier Graphic ‘R’.
e2 Var Device Status.
(4 max)
Char Code Description
If option digit 0 = ‘0’, the device status field will contain two characters:
1‐2 ‘00’ ‐ ‘98’ Key selection from Select menu.
or
If option digit 0 = ‘1’, the device status field will contain three characters:
1 ‘0’ Select menu
‘1’ Replenishment menu
‘2’ Configure menu
‘3’ Access menu
‘4’ In Service Supervisor menu (not applicable to APTRA Advance
NDC)
‘7’ Exit menu. See Note 1.
‘8’ Exit menu. See Note 1.
‘9’ Miscellaneous Functions menu.
2‐3 ‘00’ ‐ ‘98’ Menu item selected. For the permitted values for each menu, see the

APTRA Advance NDC, Supervisor’s Guide.
or
When option digit 0 = ‘2’ or ‘3’, the status field is variable length. Additional pairs of characters are added to
show the selections of the key entry sub‐menus.
If ‘2’, 4‐5 ‘00’ ‐ ‘98’ Menu selection from sub‐menu.
If ‘3’, 6‐7 ‘00’ ‐ ‘98’ Menu selection from sub‐menu of sub‐menu.

Unsolicited Status Messages
Note: 1. Menu numbers 7 and 8 are reserved for Exits designers.
You may also redefine these messages using the SUPCTR file. For
further details, see the Extending the Product publication.
Note: 2. When the ʹMISC FUNCSʹ menu is entered from the Select
menu, the unsolicited supervisor keys message has field ʹe2ʹ set to
ʹ90ʹ or ʹ090ʹ, depending on the value of message mode option digit
number 0.
Note: 3. When the ʹPRNT CMPNT VERSʹ function is selected from
the ʹMISC FUNCSʹ menu, the unsolicited supervisor keys message
has field ʹe2ʹ set to ʹ800ʹ or will not be sent, depending on the value
of message mode option digit number 0.
Note: 4. When the ʹPRNT SCRW VERSʹ function is selected from
the ʹMISC FUNCSʹ menu, the unsolicited supervisor keys message
has field ʹe2ʹ set to ʹ801ʹ or will not be sent, depending on the value
of message mode option digit number 0.
Note: 5. When a menu is longer than one screen, function ʹ99ʹ is
used to switch between the screens. No message is transmitted for
this selection (code ʹ99ʹ is not reported).

SCRW/MCRW Hardware Error Reporting
SCRW/MCRW Hardware Error
Reporting 4
When an error at the hardware/physical level occurs while
performing a SCRW command, Tcode values are reported in the
Transaction Status field (field g2/e2) of the MCRW device status
message.
The T_CODE field values which can be returned from the SCIF are:
● 08H Fatal SCIF error
● 09H SCIF warning; all commands available.
Any other T‐Code does not relate to EMV Exits.
An example of an EMV hardware error is:
12<FS>000<FS><FS>D9<FS>2<FS>817020000000<FS>0.

Errors During Chip Power-Up
Errors During Chip Power‐Up 4
The terminal attempts to power on the chip card up to three times.
Each failure will result in an unsolicited error being sent to the host.
This will have a T‐Code of 9H as shown in “SCRW/MCRW
Hardware Error Reporting” on page 4‐13.
To suppress the unsolicited error sent for each of the power‐up
errors a DWORD registry value
Exits\Power On\Disable Error must be created and set to a
non‐zero value.
The terminal can also support the sending of a T‐Code 8 error upon
repeated consecutive power‐on failures. These may indicate that
there is a problem with the card reader device.
The threshold at which this alternative error is sent is configured via
the DWORD
Exits\Power On\Consecutive Failure Threshold
registry value. The terminal counts the number of consecutive
power‐on errors there have been and when this threshold is reached
the T‐code sent will be updated to the value 8.
For each card insertion three attempts are made to power‐on the
card. An entry of 9 for this threshold would result in a t‐code 8 error
on the 4th consecutive cardholder whose card failed to power‐up.
On a successful power‐on of a card (other than in System
Application), a supervisor exit or an ATM power cycle the current
consecutive failure count will be cleared to zero.
If both keys have values set no error will be sent until the threshold
has been reached at which point a T‐Code 8 error will be sent.

ICC Application Solicited/ Unsolicited Error Message
ICC Application Solicited/
Unsolicited Error Message 4
Standard NDC solicited/unsolicited error message formats are used,
with fields g1/e1 to g5/e5 inclusive used as identified in the
following table.
For diagnostic purposes, the data transmitted is intended to help
you identify as accurately as possible the point at which the
command submitted to the ICC failed.
Note: Field g4/e4 normally contains binary values. These values
are converted to ASCII hex for transmission; for example, the single
byte value 0x9A would be transmitted as the two byte value ʹ9Aʹ.
The table below shows the message formats as they would be
transmitted by the terminal.
Number of
Characters
g1/ 1 M Device Identifier Graphic ʹcʹ (Smart card application level error)
e1
g2/ 1 M Transaction Status.
e2
Always = 1.
FS 1 M Field Separator.
g3/ 1 M Error Severity.
e3
Always = 2.
g4/ Var. M Diagnostic Status ‐ see sub‐fields:

e4
g4a/ 3 M ICC application type selected when command failed.
e4a
ʹCAMʹ ‐ CAM
ʹS&Sʹ ‐ No ICC application selected.
g4b/ Var. See Note 1 Application Identifier (AID) (tag 0x9F06).

e4b (up to 38)
AID of selected application when command failed in BER‐TLV format.
g4c/ 2 M CLA ‐ Class of instruction of command that failed.
e4c
g4d/ 2 M INS = Instruction of command that failed.
e4d

ICC Application Solicited/ Unsolicited Error Message
Number of
Characters
g4e/ 2 M P1 = Parameter 1 of command that failed.
e4e
g4f/ 2 M P2 = Parameter 2 of command that failed.
e4f
g4g/ 2 M Lc = Length of command data for command that failed.
e4g See Note 3
g4h/ Var. See Note 2 CmdData = Command data for command that failed.

e4h (2 x Lc)
g4i/ 2 M Le = Length (expected) of response data for command that failed.
e4i See Note 3
g4j/ Var. See Note 2 RspData = Response data for command that failed.

e4j (2 x Le)
g4k/ 2 M SW1 = Status word 1, indicating why command failed.
e4k
g4l/ 2 M SW2 = Status word 2, indicating why command failed.
e4l
FS ‐ ‐ Field Separator.
Not present, as field g5/e5 not used.
g5/ ‐ ‐ Not present, as not used.
e5
Note 1: This field is only present if an ICC application has been
selected from the candidate list.
Note 2: These fields are only present if enhanced configuration
option ʹ69ʹ is set, and has an option value in which bit 1 is set. If
option number ʹ69ʹ has not been set, or is set but with an option
value in which bit 1 is not set, these ICC command (g4h/e4h) and
response (g4j/e4j) data fields are not included.
Note 3: These fields will show the length of the command and
response data even if CmdData and RspData are not included.
Note 4: This error message can also be produced with invalid issuer
script results and completion data; for more information, see the
following “Issuer Script Results and Completion Data” section.

Issuer Script Results and Completion Data
Issuer Script Results and Completion
Data 4
When one or more issuer scripts are sent to the terminal, Central
will require the results of the issuer script processing to be
provided. Valid issuer scripts have been received by the terminal in
the following conditions:
● A valid ITR (Interactive Transaction Response) has been
received containing valid CAM data which included issuer
scripts. A corresponding valid Transaction Reply, with no CAM
data of its own, has also been received.
● A valid Transaction Reply has been received containing valid
CAM data, which included issuer scripts.
If one or more issuer scripts have been received by the terminal, the
issuer script processing results are sent to Central on the next
solicited status message (except for command rejects or specific
command rejects) sent in response to the Transaction Reply,
appended to the end of field ʹg4ʹ/ʹfʹ. For the message format, see the
table on the next page.
When Central requires data objects to be provided upon completion
of ICC processing for a transaction (ʹCompletion Dataʹ), this is
indicated through the settings in the ʹICC Terminal Acceptable AIDs
Tableʹ entry, whose ʹFull/Partial Primary AID Valueʹ matched the
currently selected ICC application AID. See “ICC Terminal
Acceptable Application IDs Table” in Chapter 5, “Central to
Terminal Messages”.
If available, the required data objects are provided to Central on the
next solicited status message (except for command rejects or specific
command rejects) sent in response to a valid Transaction Reply,
where valid CAM data has been received either in the Transaction
Reply or an earlier related valid ITR. If this condition is met, the
required data objects (if available) are appended to the end of field
ʹg4ʹ/ʹfʹ. For the message format, see the table on the next page.
Note: The additional data (Central required data objects and/or
issuer script results) is attached to the end of field ʹfʹ if the solicited
status message is a Ready ʹ9ʹ or ʹBʹ; otherwise, the data is attached to
the end of field ʹg4ʹ.
To ensure that Central obtains the issuer script results and required
data objects (ʹCompletion Dataʹ), the ʹLast Transaction Status
Informationʹ buffer (buffer id ʹ2ʹ) of the next Transaction Request
message sent to Central has the same data appended to it as was
sent in the solicited status message, unless another valid

Transaction Reply has been received since. The appended data
corresponds to the transaction being performed when the last valid
Transaction Reply was received by the terminal.
If a Transaction Reply has been received, but no issuer scripts have
been received, no issuer script results will be present in the Last
Transaction Status Information buffer.
The format for reporting the issuer script results is as follows:
Number of
Characters
GS 1 M Group Separator
a 3 See Note 1 Smart card data identifier.
ʹCAMʹ ‐ data is for CAM.
GS 1 See Note 2 Group Separator
b Var See Notes 3, 4 Central requested ICC data objects.

(up to 512) and 6
All available data objects whose tag is referenced in field ʹf13ʹ of the
ʹICC Terminal Acceptable AIDs Tableʹ entry, whose ʹFull/Partial
Primary AID Valueʹ matched the currently selected ICC application
AID, will be included in this field as individual BER‐TLV data objects.
See “ICC Terminal Acceptable Application IDs Table” in Chapter 5,
For example, with:
Cryptogram Information Data 0x9F27
Application Cryptogram 0x9F26
Issuer Application Data 0x9F10
Terminal Verification Results (TVR) 0x95
Transaction Status Indicator (TSI) 0x9B
Then this field would contain the following (values will vary):
ʹ9F 27 01 00 9F 26 08 12 34 56 78 90 12 34 56 9F 10 07 06 01 01 03 A0 00 00
95 05 00 00 04 00 00 9B 02 74 00ʹ
GS 1 See Note 5 Group Separator

Number of
Characters
c 1 M Result of issuer script processing.
See Note 5
ʹ0ʹ ‐ script not performed.
ʹ1ʹ ‐ script processing failed.
ʹ2ʹ ‐ script processing successful.
d 1 M Sequence number of script command.
See Note 2
ʹ0ʹ ‐ All commands successful or script not performed.
ʹ1ʹ ‐ ʹEʹ ‐ Sequence number from 1 to 14 for failed command.
ʹFʹ ‐ Sequence number of 15 or over for command that failed.
The sequence number of a command corresponds directly to its
position within a script. For example, the first command will be
assigned the sequence number ʹ1ʹ, the third ʹ3ʹ, the seventh ʹ7ʹ and so
on.
e Var. M Script Identifier (tag 0x9F18).
(1 to 14) See Note 2
Identifier (ID) of the script to which the result relates, in BER‐TLV
format.
The script identifier data object (tag 0x9F18) is optionally provided as
part of the script data. If it was not provided, a default value of
0x00000000 (length of 4) is used. This would be sent as ʹ9F 18 04 00 00
00 00ʹ.
For example:
1 If the script ID sent as part of the script was
‘9F180499999999’, the script results will have a script
identified field of ‘9F180499999999’
2 If the script ID sent as part of the script was ‘9F1800’, the
script results will have a script identified field of ‘9F1800’
3 If no script ID was sent as part of the script, the script results
will have a script identified field of ‘9F180400000000’.
Note 1: The first group separator and field ʹaʹ are omitted if the
application type for the data has already been sent in the message to
which it is being attached. For example, they would not be present
in an ʹICC Applicationʹ device status message, but would be present
in any other status message and the Transaction Request ʹLast
Transaction Status Informationʹ buffer (buffer id ʹ2ʹ).
Note 2: The second group separator is mandatory if field ʹbʹ, or
fields ʹcʹ through ʹeʹ inclusive, are present.

Note 3: If a data object is identified, but not available, then the data
object will not be present. If no data objects are identified or none
are available, then none are present and effectively field ʹbʹ will be
absent.
Note 4: Only 512 bytes of ASCII hex data (256 bytes binary) can be
transmitted. If it is found that a referenced data object will not fit
into the remaining space available, then it will not be included in the
data. Processing would continue from the next data object
referenced. The list of referenced data objects is processed
sequentially.
Note 5: Fields ʹcʹ to ʹeʹ inclusive are repeated for the number of
scripts present in the ITR or Transaction Reply CAM data, and are
configured to record the processing status of each script. If no
scripts were present, the third group separator and fields ʹcʹ through
ʹeʹ inclusive are omitted. If four scripts were present, the third group
separator is present, and fields ʹcʹ through ʹeʹ inclusive are repeated
four times.
Note 6: The values in fields ʹbʹ and ʹeʹ are normally binary, but are
converted to ASCII hex for transmission. For example, the single
byte value 0x9A would be transmitted as the two byte value ʹ9Aʹ.
The table above shows the message format as it would be
transmitted by the terminal.
Note 7: The Last Transaction Status Information buffer (buffer ID
ʹ2ʹ) is only sent in a Transaction Request if the enhanced
configuration option ʹ15ʹ is set to ʹ001ʹ, as for standard NDC.
Note 8: Issuer script results and transmission status are maintained
over power failures.

Table of Contents
Chapter 5
Overview 5‐1
Customisation Data Commands 5‐2
EMV Configuration Message 5‐4
ICC Currency Data Objects Table 5‐6
Example Data 5‐7
ICC Transaction Data Objects Table 5‐8
Example Data 5‐9
ICC Language Support Table 5‐10
Example Data 5‐11
ICC Terminal Data Objects Table 5‐13
ICC Terminal Acceptable Application IDs Table 5‐14
Simulated Track 2 Data 5‐23
Impact on Central (host) 5‐24
Local setting of Track Data settings f18,f19,f20,f21 5‐24
Default EMV Customisation Data 5‐25
Transaction Reply 5‐26
Field bc ‐ Transaction Data Objects Update Buffer 5‐30
Buffer Identifiers 5‐32
Function Identifiers 5‐32
Interactive Transaction Response 5‐33

Table of Contents

E
Overview
Overview 5
This chapter provides information on the following topics:
● Customisation Data Commands
● EMV Configuration Message
● ICC Currency Data Objects Table
● ICC Transaction Data Objects Table
● ICC Language Support Table
● ICC Terminal Data Objects
● ICC Terminal Acceptable Application IDs Table
● Transaction Reply (smart card data buffer)
● Interactive Transaction Response.

Customisation Data Commands
Customisation Data Commands 5
Central can use various Customisation Data commands to
download different types of data to the terminal. The commands are
as follows:
● State Tables Load
● Screen/Keyboard Data Load
● Configuration Parameters Load
● Enhanced Configuration Parameters Load
● FIT Data Load
● Configuration ID Number Load
● MAC Field Selection Load
● Date and Time Load
● Encryption Key Load
● Initialise EKC
● Override Reserved Screens Command
● EMV Configuration
● ICC Terminal Data Objects Table
● ICC Terminal Acceptable AIDs Table
The following table shows the message class, sub‐class and
identifier for each command.
Message Message
Identifier Command
Class Sub-Class
3 1 1 Screen/Keyboard Data Load
3 1 2 State Tables Load
3 1 3 Configuration Parameters Load
3 1 4 Reserved
3 1 5 FIT Data Load
3 1 6 Configuration ID Number Load
3 1 A Enhanced Configuration Parameters
Load
3 1 B MAC Field Selection Load
3 1 C Date and Time Load

Customisation Data Commands
Message Message
Identifier Command
Class Sub-Class
3 3 1‐9 Encryption Key Load
3 1 E Dispenser Currency Cassette
Mapping Table
3 1 F Initialise EKC
3 1 G Override Reserved Screens Command
8 1 ‐ EMV Configuration ‐
ICC Currency Data Objects Table
ICC Transaction Data Objects Table
ICC Language Support Table
ICC Terminal Data Objects Table
ICC Terminal Acceptable AIDs Table
For further details of the specific commands, except EMV
Configuration, see the APTRA Advance NDC, Reference Manual.
The EMV Configuration message format is detailed in the following
section.

EMV Configuration Message
EMV Configuration Message 5
To enable EMV ICC (Smart Card) configuration, a new message is
required for Central to terminal communications. The format of this
new message is as follows:
Number of
Field Mandatory/ Optional Description
Characters
a Var. M Header. Protocol dependent.
b 1 M Message Class. The value is fixed as ʹ8ʹ to indicate EMV configuration
data.
c 1 O Response Flag.
Included for future use and ignored by the terminal.
d 3 or 9 O Logical Unit Number (LUNO).
e 1 M Message Sub‐Class.
ʹ1ʹ ‐ ʹICC Currency Data Objects Tableʹ data.
ʹ2ʹ ‐ ʹICC Transaction Data Objects Tableʹ data.
ʹ3ʹ ‐ ʹICC Language Support Tableʹ data.
ʹ4ʹ ‐ ʹICC Terminal Data Objects Tableʹ data.
ʹ5ʹ ‐ ʹICC Terminal Acceptable AIDs Tableʹ data.
These are defined in the following sub‐sections.
f Var. M Configuration Data.
See the following sections in this chapter for each message sub‐class.
FS 1 See Note 1 Field Separator
g Var. See Note 1 Message Authentication Code (MAC) Data.
Eight digit ASCII hex value used to authenticate the message data.
h Var. M Trailer. Protocol dependent.
The ʹEMV Configuration Dataʹ message is expected at the terminal
only when the terminal is in out‐of‐service mode or supply/
supervisor mode.

If Central transmits an ʹEMV Configuration Dataʹ message and it
does not conform to the format above, or it is sent at a time when it
is not expected, the NDC CAM application will generate a standard
solicited error message. This error message will identify a standard
NDC specific command reject value appropriate to the failure
reason, or simply a ʹReady Aʹ if specific command reject processing
is not activated.
If a command reject or specific command reject is generated then the
message content will be ignored.
Note: 1. The field separator and MAC Data field are only included
if the flag settings are correct. For details, see the APTRA Advance
NDC, Supervisor’s Guide.

This table is used to define the currency types which map to
ICC Currency Data Objects BER‐TLV data objects, for use with the Set ICC Transaction Data ‘?’
Table 5
state type. For more details, see “? ‐ Set ICC Transaction Data State”
in Chapter 2, “State Tables”.
The configuration data required for this table is provided via the
EMV Configuration Message (sub‐class of ʹ1ʹ). The data is held in
field ʹfʹ of the EMV Configuration Message as follows:
Number of
Characters
f ‐ ‐ ICC Currency Data Objects Table data ‐ see sub‐fields:
f1 2 M Number of Currency Type Mapping Entries.
Two‐digit ASCII hex value in the range ʹ01ʹ to ʹFFʹ inclusive.
f2 2 See Note 1 Currency Type.
f3 Var. See Note 1 BER‐TLV Data Objects.

(000‐255)
Any BER‐TLV formatted data object may be placed in this field, but all
data objects must be held within a single Response Format 2 data
object (tag 0x77). The data is sent in ASCII hex.
This field contains the Transaction Currency Code (tag 0x5F2A) and
the Transaction Currency Exponent (tag 0x5F36) data objects.
For example:
ʹ77 09 5F 2A 02 08 26 5F 36 01 02ʹ
Where:
ʹ77ʹ ‐ ʹResponse Format 2ʹ data object tag
ʹ09ʹ ‐ ʹResponse Format 2ʹ data object length
ʹ5F 2Aʹ ‐ ʹTransaction Currency Codeʹ data object tag
ʹ02ʹ ‐ ʹTransaction Currency Codeʹ data object length
ʹ08 26ʹ ‐ ʹTransaction Currency Codeʹ data object value
ʹ5F 36ʹ ‐ ʹTransaction Currency Exponentʹ data object tag
ʹ01ʹ ‐ ʹTransaction Currency Exponentʹ data object length
ʹ02ʹ ‐ ʹTransaction Currency Exponentʹ data object value
If Central downloads ICC Currency Data Objects Table data and it
does not conform to the above format, the NDC CAM application
generates a solicited error message identifying a Specific Command
Reject (value ʹB91ʹ), and the downloaded data is ignored.
Note 1: If field ʹf1ʹ is greater than ʹ01ʹ, the fields ʹf2ʹ and ʹf3ʹ are
repeated for the number of times indicated by field ʹf1ʹ.

Note 2: The data contained within field ʹfʹ is normally in binary.
This field will be converted to ASCII hex for transmission. Therefore
the single‐byte value 0x9A would be transmitted as the two‐byte
value ʹ9Aʹ. The format description above shows the data field sizes
as it would be sent to Central.
Note 3: If a specific ʹCurrency Typeʹ is mapped to ʹBER‐TLV Data
Objectsʹ more than once within the message, then the later mapping
will be used for processing.
Example Data 5
If there are two currencies to be supported by the terminal, for
example Pounds Sterling and the Euro, the downloaded ICC
Currency Data Objects Table data would be as follows:
ʹ02 01 77 09 5F 2A 02 08 26 5F 36 01 02 02 77 09 5F 2A 02
09 78 5F 36 01 02ʹ
Spaces are included for clarity, but do not appear in the actual
message to the terminal.

This table is used to provide the means by which transaction types
ICC Transaction Data can be mapped to BER‐TLV data objects, for use with the Set ICC
Objects Table 5
Transaction Data state type ‘?’. For more details, see “? ‐ Set ICC
Transaction Data State” in Chapter 2, “State Tables”.
Number of
Characters
f ‐ ‐ ICC Transaction Data Objects Table data ‐ see sub‐fields:
f1 2 M Number of Transaction Type Mapping Entries.
f2 2 See Note 1 Transaction Type.
f3 Var. See Note 1 BER‐TLV Data Objects.

(000‐255)
data objects must be held within a single ʹResponse Format 2ʹ data
Note: Only primitive BER‐TLV data objects of a type known to the
terminal are stored for use in ICC processing.
This field contains the ʹTransaction Typeʹ (tag 0x9C) data object and
the MasterCard proprietary ʹTransaction Category Codeʹ (tag 0x9F53)
data object.
For example:
ʹ77 07 9C 01 01 9F53 01 5Aʹ
Where:
ʹ77ʹ = ʹResponse Format 2ʹ data object tag
ʹ07ʹ = ʹResponse Format 2ʹ data object length
ʹ9Cʹ = ʹTransaction Typeʹ data object tag
ʹ01ʹ = ʹTransaction Typeʹ data object length
ʹ01ʹ = ʹTransaction Typeʹ data object value
ʹ9F53ʹ = ʹTransaction Category Codeʹ data object tag
ʹ01ʹ = ʹTransaction Category Codeʹ data object length
ʹ5Aʹ = ʹTransaction Category Codeʹ data object value.
If Central downloads ICC Transaction Data Objects Table data and
it does not conform to the above format, the NDC CAM application
Reject (value ʹB92ʹ), and the downloaded data is ignored.

Note 1: If field ʹf1ʹ is greater than ʹ01ʹ, the fields ʹf2ʹ and ʹf3ʹ are
repeated for the number of times indicated by field ʹf1ʹ.
Note 2: If Specific Command Reject processing is not activated,
rejects will be reported as a standard ʹReady Aʹ reject.
Note 3: The data contained within field ʹfʹ is normally in binary.
This field will be converted to ASCII hex for transmission. Therefore
the single‐byte value 0x9A would be transmitted as the two‐byte
value ʹ9Aʹ. The format description above shows the data field sizes
as it would be sent to Central.
Note 4: If a specific ʹTransaction Typeʹ is mapped to ʹBER‐TLV Data
Objectsʹ more than once within the message, then the later mapping
will be used for processing.
Example Data 5
If there are two transaction types to be supported by the terminal,
the downloaded ʹICC Transaction Data Objects Tableʹ data would be
similar to the following:
'02 01 77 07 9C 01 01 9F 53 01 5A 02 77 07 9C 01 02 9F
53 01 5B'

This table is used to provide a mapping between the languages
ICC Language Support preferences indicated by the ICC data and those supported by the
Table 5
terminal. The table is used in the Automatic Language Selection
state type ʹ‐ʹ. For more details, see “‐ ‐ Automatic Language
Selection State” in Chapter 2, “State Tables”.
Number of
Characters
f ‐ ‐ ICC Language Support Table data ‐ see sub‐fields:
f1 2 M Number of Language Mapping Entries.
f2 2 See Note 1 Language Code.
ASCII character value in the range ʹaaʹ to ʹzzʹ inclusive (that is, lower
case alphabetic characters only, with no numerics).
The language code must be a value as defined in ISO 639:1998.
f3 3 See Note 1 Screen Base.
ASCII decimal value in the range ʹ000ʹ to ʹ999ʹ inclusive, where:
1 = 1000, 2 = 2000.....9 = 9000.
This value is used as the screen base, provided the ICC language
preference finds a match against the language code in field ʹf2ʹ.
Note: To enable larger screen groups, values 1 to 9 are now multiplied
by 1000. For example, to set the screen base to 1000, set this value to 1.

Number of
Characters
f4 3 See Note 1 Audio Base.
ASCII decimal value in the range ʹ000ʹ to ʹ007ʹ inclusive.
This value is used to set the digital audio directory base, provided the
ICC language preference finds a match against the language code in
field ʹf2ʹ.
f5 3 See Note 1 Opcode Buffer Positions.
Three different ASCII decimal values, each in the range ʹ0ʹ to ʹ7ʹ
inclusive. No duplicate values should be present (that is, ʹ001ʹ is not
acceptable).
If the ICC language preference finds a match against the language
code in field ʹf2ʹ, the three opcode buffer positions indicated in this
field are set to the corresponding values indicated in field ʹf6ʹ.
f6 3 See Note 1 Opcode Buffer Values.
Three ASCII character values, each with a value in the range ʹAʹ to ʹDʹ
or ʹFʹ to ʹIʹ inclusive, or ʹ@ʹ.
If the ICC language preference finds a match against the language
code in field ʹf2ʹ, the three opcode values indicated in this field are set
in the corresponding opcode positions indicated in field ʹf5ʹ.
If the opcode value is ʹ@ʹ, no change is made to the corresponding
opcode positions.
If Central downloads ICC Language Support Table data and it does
not conform to the above format, the NDC CAM application will
generate a solicited error message identifying a Specific Command
Reject (value ʹB93ʹ) and the downloaded data is ignored.
Note 1: If field ʹf1ʹ is greater than ʹ01ʹ, the fields ʹf2ʹ through ʹf6ʹ
inclusive are repeated for the number of times indicated by field ʹf1ʹ.
Note 2: If a specific ʹLanguage Codeʹ is mapped more than once
within the message, then the later mapping will be used for
processing.
Example Data 5
If English (en) [language 1], French (fr) [language 2], German (de)
[language 3], Italian (it) [language 4], Spanish (es) [language 5] and
Welsh (cy) [language 6] are to be supported, the data would be
similar to the following:

06 en 000 000 012 AB@ fr 100 001 012 BB@ de 200 002 012
CB@ it 300 003 012 DB@ es 400 004 012 FB@ cy 500 005 012
GB@
Depending on the language preference indicated by the ICC, the
following settings would be used during processing:
Language
Screen Audio Base
Preference Opcode Buffer Value
Base Value Value
Code
en 000 000 ABxxxxxx
fr 100 001 BBxxxxxx
de 200 002 CBxxxxxx
it 300 003 DBxxxxxx
es 400 004 FBxxxxxx
cy 500 005 GBxxxxxx
Where ʹxxxxxxʹ is the unchanged opcode buffer position.

This table is used to provide the method by which terminal‐specific
ICC Terminal Data Objects data objects are defined by Central for use with ICC processing.
Table 5
Number of
Characters
f ‐ ‐ ICC Terminal Data Objects data ‐ see sub‐fields:
f1 Var. M BER‐TLV Data Objects.
(0‐255)
data objects must be held within a single ʹResponse Format 2ʹ data
Note: Only ʹprimitiveʹ BER‐TLV data objects of a type known to the
This field contains the ʹTerminal Country Codeʹ (tag 0x9F1A) and
ʹTerminal Typeʹ (tag 0x9F35) data objects.
For example:
ʹ77 09 9F 1A 02 08 26 9F 35 01 14ʹ
Where:
ʹ9F 1Aʹ ‐ ʹTerminal Country Codeʹ data object tag
ʹ02ʹ ‐ ʹTerminal Country Codeʹ data object length
ʹ08 26ʹ ‐ ʹTerminal Country Codeʹ data object value
ʹ9F 35ʹ ‐ ʹTerminal Typeʹ data object tag
ʹ01ʹ ‐ ʹTerminal Typeʹ data object length
ʹ14ʹ ‐ ʹTerminal Typeʹ data object value
If Central downloads ICC Terminal Data Objects data and it does
not conform to the above format, the NDC CAM application
generates a solicited error message with a Specific Command Reject
(value ʹB94ʹ) and the downloaded data is ignored.
Note: The data contained within field ʹfʹ is normally in binary. This
field is converted to ASCII hex for transmission; for example, the
single‐byte value 0x9A is transmitted as the two‐byte value ʹ9Aʹ. The
format description in the previous table shows the data field sizes as
they are sent to Central.

The ICC Terminal Acceptable AIDs Table is obtained and used as
ICC Terminal Acceptable summarised in “ICC Initialise and Candidate List Build” in
Application IDs Table 5
Chapter 2, “State Tables”.
The table is made up of entries which each define an acceptable AID
(as a full or partial AID value) and a list of associated AIDs. These
entries are used selectively, based on the application found on the
ICC being processed. This makes the Terminal Acceptable AID List
processing dynamic.
EMV Configuration Message (sub‐class of ʹ5ʹ). Each table entry is
held in field ʹfʹ of the EMV Configuration Message as follows:
Number of
Characters
f ‐ ‐ ICC Terminal Acceptable AIDs Table data ‐ see sub‐fields:
f1 2 M Entry Number.
f2 2 See Note 1 Length of Full/Partial Primary AID Value.
ASCII hex value for the length of the AID.
The length of the AID must be in the range ʹ01Hʹ to ʹ10Hʹ inclusive (1 to
16 decimal inclusive).
Note: This length is also the number of ICC AID bytes that will be
checked when compared to the Full/Partial Primary AID value (field
ʹf3ʹ).
f3 Var. See Note 1 Full/Partial Primary AID Value.

(1‐32)
Binary value stored as ASCII hex.
For example, an AID of 0xA000000026 is stored as the characterised
value ʹA000000026ʹ and has length ʹ05ʹ (field ʹf2ʹ).
f4 2 See Notes 1 & 5 Length of Default Application Label.
ASCII hex value for the length of the default Application Label data
object (tag 0x50).
The length must be in the range ʹ00ʹ to ʹ10ʹ inclusive (0 to 16 decimal
inclusive). The value corresponds to the content of field ʹf5ʹ.

Number of
Characters
f5 Var. See Notes 1 & 5 Default Application Label.

(1‐16)
Default value to be used for the Application Label data object (tag
0x50).
The value is a text string of characters in the range 0x20 to 0x7E
inclusive.
The default Application Label is ʹSelf Serviceʹ, transmitted with length
ʹ0Cʹ (field ʹf4ʹ).
f6 3 See Note 1 Primary AID ICC Application Type.
ʹCAMʹ = CAM ICC application
f7 4 See Note 1 Primary AID Lowest Application Version Number.
A binary value stored as ASCII hex.
f8 4 See Note 1 Primary AID Highest Application Version Number.
A binary value stored as ASCII hex.
f9 10 See Note 1 Primary AID Terminal Action Code ‐ Denial.
Binary value stored as ASCII hex.
f10 2 See Notes 1 & 2 Number of Data Object(s) for Transaction Request.
ASCII hex value in range ʹ00ʹ through ʹFFʹ inclusive.
f11 Var. See Notes 1 & 2 Data Object(s) for Transaction Request.
ASCII hex value.
This contains the list of BER‐TLV formatted tags to be sent in the
Transaction Request (see “Transaction Request Message Format” in
Chapter 4, “Terminal to Central Messages”).
Note: No length is required for each tag value, as BER‐TLV formatted
tag values define their own length within the tag value itself.
However, in line with implementation restrictions, a tag will not be
acceptable if it is more than two bytes (four ASCII hex characters)
long.
Note: To include the PIN retry count in the transaction request,
include the tag 0x9F17 in this object list.
f12 2 See Notes 1 & 2 Number of Data Object(s) for Completion Data.

Number of
Characters
f13 Var. See Notes 1 & 2 Data Object(s) for Completion Data.
ASCII hex value.
Contains a list of BER‐TLV formatted tags that are to be sent on the
next solicited status message (except command rejects or specific
command rejects), in response to a valid Transaction Reply containing
valid CAM data. See “Issuer Script Results and Completion Data” in
Chapter 4, “Terminal to Central Messages”.
Note: No length is required for each tag value as BER‐TLV formatted
tag values define their own length within the tag value itself.
However, in line with implementation restrictions a tag will not be
acceptable if it is more than two bytes (four ASCII hex characters)
long.
f14 2 See Notes 1 & 3 Number of Secondary AIDs.
f15 2 See Notes 1 & 3 Length of Full/Partial Secondary AID Value.
ASCII hex value for the length of the AID.
The length of the AID must be in the range ʹ01ʹ to ʹ10ʹ inclusive (1 to 16
decimal inclusive).
Note: This length is also the number of ʹFull/Partial Primary AID
Valueʹ field bytes that are checked when compared to the Full/Partial
Secondary AID Value (field ʹf16ʹ).
f16 Var. See Notes 1 & 3 Full/Partial Secondary AID Value.

(1‐32)
Binary value stored as ASCII hex. For example, an AID of
0xA000000026 is stored as the characterised value ʹA000000026ʹ, and
has a length of ʹ05ʹ (field ʹf15ʹ).
f17 2 O Application Selection Indicator

Number of
Characters
(M if any 00 (Default) During the candidate list build processing, any
following fields application which is a partial match will be added to the
are present) candidate list.
Note: A partial match occurs when the AID used in the
SELECT command is shorter than the DF Name and exactly
matches for all the characters present. The DF name is
returned in the response to a SELECT command and can be
the same length or longer than the AID used in the SELECT
command.
For example, if a card contains these applications:
● A0000000001231
● A0000000001232
● A0000000004321
An AID of A00000000012, will select two applications, if the
card itself supports partial AID selection. An AID of
A000000000, will select all three.
01 During the candidate list build processing, any application
which is a full match to the candidate list is added.
Note: A full match occurs when the DF Name (tag 0x84)
returned by the ICC in response to a SELECT command
exactly matches the AID used in the SELECT command, that is
both are identical in length and contain the same characters.
f18 2 O Track 2 Data for Central
(M if any 00 (Default) Use the card’s magnetic stripe data in the track 2
following fields buffer field of the transaction request.
are present)
01 Use the card’s magnetic stripe data in the track 2 buffer field of
the transaction request, unless there is no track 2 data
available, in which case use the ICC track 2 data defined in
field f19.
02 Always place the ICC track 2 data defined in field f19 in the
track 2 buffer field.
f19 2 O Track 2 Data To Be Used During ICC Transaction
(M if any 00 (Default) Use the Track 2 Equivalent Data (tag 0x57) for all
following fields NDC processing, but if it is not supplied by the ICC, produce
are present) an ICC level fake error and terminate the ICC processing.
01 Use the Track 2 Equivalent Data (tag 0x57) for all NDC
processing, but if it is not supplied by the ICC, use the track 2
data from the magnetic card.
02 Always use the track 2 data from the magnetic card.

Number of
Characters
03 Use the Track 2 Equivalent Data (tag 0x57) for all NDC
processing, but if it is not supplied by the ICC, construct
simulated Track 2 data. For details of track 2 data simulation,
see “Simulated Track 2 Data” on page 5‐23.
04 Always construct simulated track 2 data. For details, see
“Simulated Track 2 Data” on page 5‐23.

Number of
Characters
f20 2 O (Mandatory Length Of Additional Track 2 Data in the following field (f21).

if f19 is set to 03
or 04. Range 01 to 21 (ASCII Hexadecimal).
Should be
omitted for f19 For example, ʺ21ʺ hexadecimal means 33 characters to follow.
set to 00, 01, 02)
For details of track 2 data simulation, see “Simulated Track 2 Data” on
page 5‐23.
f21 0 ‐ 33 O (M if f20 is Additional Track 2 Data

present and a
non‐zero value) The additional track 2 data to be used in the construction of the
simulated track 2 data.
Each byte of data to be used must be represented by 2 ASCII
hexadecimal characters in the range ‘30’ to ‘39’.
For example, ʺ1ʺ would be transmitted as ʺ31ʺ.
For details of track 2 data simulation, see “Simulated Track 2 Data” on
page 5‐23.
If Central downloads ICC Terminal Acceptable AIDs Table data and
it does not conform to the above format, the NDC CAM application
Reject with value ʹWxxʹ (where ʹxxʹ is the entry number identified by
field ʹf1ʹ) and the downloaded data is ignored.
Note 1: Fields ʹf1ʹ through ʹf21ʹ inclusive may be repeated as many
times as will fit within a single message within field ʹfʹ, with a
maximum total length of 256. Each iteration must be separated by a
Group Separator (GS) character.
Note 2: Fields ʹf11ʹ and ʹf13ʹ are repeated as appropriate to the
values in field ʹf10ʹ and ʹf12ʹ respectively. If field ʹf12ʹ is zero then
field ʹf13ʹ is omitted.
Note 3: Fields ʹf15ʹ and ʹf16ʹ are repeated as appropriate to the value
in field ʹf14ʹ. If field ʹf14ʹ is zero then fields ʹf15ʹ & ʹf16ʹ are omitted.
Note 4: If Specific Command Reject processing is not activated,
rejects will be reported as standard ʹReady Aʹ rejects.
Note 5: If field ʹf4ʹ is zero, field ʹf5ʹ is omitted.
Note 6: ICCs do not have to support selection of ICC applications
by partial AID / ʹDF Nameʹ value. It is advisable to use full AID
values in field ʹf3ʹ.

Note 7: If field ʹf1ʹ is sent without fields ʹf2ʹ through ʹf21ʹ, the entry
to which field ʹf1ʹ refers is deleted from the table.
Note 8: If data for a specific Entry Number is supplied more than
once within the message, the later mapping is used for processing.
For example:
00 07 A0000000080001 00 CAM 0000 0001 0070000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
01 06 A00000000201
<GS>01 07 A0000000080002 00 CAM 0000 0001 0070000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
00
<GS>02 07 A0000000070001 00 CAM 0000 0001 0070000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
02 07 A0000000031010
07 A0000000041010
<GS>03 07 A0000000031010 04 Visa CAM 0000 0001 0010000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
02 07 A0000000032010
07 A0000000033010
<GS>04 07 A0000000032010 00 CAM 0000 0001 0010000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
00
<GS>05 07 A0000000033010 00 CAM 0000 0001 0010000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
00
<GS>06 07 A0000000041010 00 CAM 0000 0001 0010000000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
02 07 A0000000046000
07 A0000000043060
<GS>07 07 A0000000046000 07 MasterCard CAM 0000 0001

5810F80000
0A 9F06575A5F349F279F269F10829F368C

05 9F279F269F10959B
00
<GS>08 07 A0000000043060 00 CAM 0000 0001 5810F80000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
00
<GS>09 07 A0000000041030 00 CAM 0000 0001 5810F80000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
00
<GS>0A 06 A00000000201 00 CAM 0000 0001 5810F80000
0A 9F06575A5F349F279F269F10829F368C
05 9F279F269F10959B
00
Where:
<GS> is a group separator.
Spaces and new lines are included for clarity, but do not appear in
the actual message to the terminal.
This example has eleven CAM ICC application Primary AIDs, all
with a version number in the range 0x0000 to 0x0001 inclusive.
All entries identify that the following are to be included in the
transaction request:
● Application Identifier (AID) (tag 0x9F06)
● Track 2 Equivalent Data (tag 0x57)
● Application PAN (tag 0x5A)
● Application PAN Sequence Number (tag 0x5F34)
● Cryptogram Information Data (tag 0x9F27)
● Application Cryptogram (tag 0x9F26)
● Issuer Application Data (tag 0x9F10)
● Application Interchange Profile (AIP) (tag 0x82)
● Application Transaction Counter (ATC) (tag 0x9F36) and
● CDOL1 (tag 0x8C) data objects.

All entries identify that the following are to be included as
Completion Data in the first solicited status message that concludes
ICC processing for a transaction:
● Cryptogram Information Data (tag 0x9F27)
● Application Cryptogram (tag 0x9F26)
● Issuer Application Data (tag 0x9F10)
● Terminal Verification Results (TVR) (tag 0x95) and
● Transaction Status Indicator (TSI) (tag 0x9B) data objects.
Entries ʹ00ʹ, ʹ02ʹ, ʹ03ʹ and ʹ06ʹ have secondary AID values.
Entries ʹ03ʹ and ʹ07ʹ have Default Application Label values.
Entries ʹ00ʹ, ʹ01ʹ and ʹ02ʹ have a ʹPrimary AID Terminal Action Code ‐
Denialʹ value indicating that a transaction should be declined offline
by the terminal when:
● Requested service is not allowed
● ICC application has expired
● ICC application is not yet effective.
Entries ʹ03ʹ, ʹ04ʹ, ʹ05ʹ and ʹ06ʹ have a ʹPrimary AID Terminal Action
Code ‐ Denialʹ value indicating that a transaction should be declined
offline by the terminal only when the requested service is not
allowed.
Entries ʹ07ʹ, ʹ08ʹ, ʹ09ʹ and ʹ0Aʹ have a ʹPrimary AID Terminal Action
Code ‐ Denialʹ value indicating that a transaction should be declined
offline by the terminal when:
● Offline static data authentication failed (not performed by
terminal).
● Card is on the terminal exception file (not performed by
terminal).
● Requested service is not allowed.
● Cardholder verification failed.
● Unrecognised CVM.
● PIN try limit exceeded.
● PIN entry required, PIN pad not present and working.
● PIN entry required, PIN pad present, PIN entered.

Simulated Track 2 Data 5
If simulated track 2 data is selected, the terminal will construct this
data from the following ICC data objects:
● Primary Account Number (0x5A),
● Application Expiry Date (0x5F24) and
● additional track 2 data downloaded in field f21 of the “ICC
Terminal Acceptable Application IDs Table”.
The simulated track two data is constructed as follows:
Primary
Application Additional
Start Account Field End
Expiry Date Track 2
Sentinel Number Separator Sentinel
(YYMM) Data
(PAN)
‘;’ From ‘=’ From From ‘?’

ICC ICC AID
object object table f21
0x5A 0x5F24 (if
present)
If the simulated track 2 buffer would result in a length greater than
40 (inclusive of the Field Separators and Sentinels), then the leftmost
39 bytes of data are used, followed by the End Sentinel.
Example If the terminal acceptable AID table download for the 5
selected application has the following values for f18 onwards:
....01030732323331373031
and the ICC application has returned the following objects:
5A 08 4916245531413011
and
5F24 03 050301
then the simulated Track 2 data used by NDC for the transaction
would be:
;4916245531413011=05032231701?
As f18 is set to 01 in this example, this would only be sent to the host
if there was no track 2 data read successfully from the card, when
the data would be placed into the track 2 buffer of the transaction
request message.

Impact on Central (host) 5
As the new “ICC Terminal Acceptable Application IDs Table” fields
f17 to f21 are optional, and all the default settings support previous
releases of EMV CAM2 Exits, there are no compatibility issues with
existing host systems.
However, if the constructed track 2 buffer is enabled by a host,
additional Financial Institution Tables (FITs) may be required to
match against the simulated track 2 data derived from the selected
ICC application.
Depending on the Track 2 Data for Central (f18) field setting, the
simulated track 2 data may not be sent to the host system. However,
the host can derive this track 2 data if it requests the inclusion of the
Primary Account Number (ICC object 0x5A) and Application
Expiry Date (0x5F24) in the CAM buffer of the transaction request
message. Using these objects and the additional track 2 information
(already supplied to the terminal by the host system), the host can
reconstruct the simulated track 2 buffer.
Local setting of Track Data settings f18,f19,f20,f21 5
When fields f18 to f21 are not supported by the host they can also be
configured using values in the Windows registry.
The terminal will look for these values under the
EXITS\TAAT\<AID VALUE> registry key. <AID VALUE> is the
hexadecimal representation of the applicationʹs AID for example
ʺA000000300ʺ.
The registry entries are String values named ʺf18ʺ,ʺf19ʺ,ʺf20ʺ and
ʺf21ʺ. The appropriate ranges for each value correspond exactly
with the field of the same name in the download message. These
values will only be read from the registry if the host has not
downloaded the value. Invalid values for these entries will be
ignored.
For the registry key <AID VALUE> to be used it must have an even
number of characters and a minimum length of 10. If the cardʹs
application AID is longer than the registry key name but the two are
identical for the number of characters of the registry key name then
the data of the registry values will be used.

Default EMV Customisation Data
Default EMV Customisation Data 5
At power‐up, the terminal checks for the presence of the default
EMV download data file ‘C:\Program Files\NCR APTRA\APTRA
ADVANCE\DATA\EMVDFLT.DAT’.
During power‐up, but prior to the normal Advance NDC download
reload, if this file is present and is formatted correctly, the data
stored in this file is loaded into the system as the default values for
the Advance NDC Option Digit number 69, and the various EMV
download data.
This file is in addition to the normal reloading of the download
following a power fail. In addition, any subsequent host downloads
of this data will replace the default entries loaded from the file.
The recommended approach to create a valid default download file
is:
1 Start with a terminal which contains no download data and no
default EMV data file
2 Send the terminal the EMV data which is required to be set as
the default
3 Send a non‐zero configuration identifier to the terminal
4 Send a ‘Go‐In‐Service’ command to the terminal
5 Copy the file ‘C:\Program Files\NCR APTRA\APTRA
ADVANCE\DATA\EMVDATA.DAT’ to the default EMV load
file name.
If the DWORD registry value
EXITS\Retain Download is present and contains a non‐zero
value the terminal will automatically create the EMVDFLT.DAT file
when a Terminal Command (Go‐in‐service), Configuration ID
Number Load message, or a customisation data message which
would reset the configuration identifier is received.

Transaction Reply
Transaction Reply 5
The Transaction Reply message remains unaltered, apart from the
addition of ‘at1’ and ‘at2’ fields immediately following field ʹx’, or
the addition of the ‘bc’ field immediately following field ʹbb ʹ. These
fields are identified below.
Note: Fields ʹat2bʹ, ʹat2cʹ, ʹat2dʹ, ‘bc2b’, ‘bc2d’, ‘bc2g’ are normally
binary values. These values are converted to ASCII hex for
transmission; for example, the single‐byte value 0x9A would be
transmitted as the two‐byte value ʹ9Aʹ. The table below shows the
data format as it would be transmitted by Central.
Number of
Characters
FS 1 See Note 1 Field Separator.
at1 1 See Note 1 Buffer Identifier. The value is fixed as ʹ5ʹ to indicate smart card data.
at2 ‐ ‐ Smart Card Data ‐ see sub‐fields:
at2a 3 See Note 1 Smart Card Data Identifier.

ʹCAMʹ ‐ Data in buffer is for CAM.

Transaction Reply
Number of
Characters
at2b See Note 2 Issuer Authentication Data (up to 36 bytes) in BER‐TLV format, as

follows:
2 M ʹ91ʹ for tag 0x91
2 M Length, in hex, of the following Issuer Authentication Data. The length
value must be in the range 0x08 (ʹ08ʹ) to 0x10 (ʹ10ʹ) inclusive.
up to 16 M Authorisation Response Cryptogram (ARPC) and any scheme
specific/proprietary Issuer Authentication Data.
at2c See Note 3 Authorisation Response Code (8 bytes) in BER‐TLV format, as follows:
2 M ʹ8Aʹ for tag 0x8A.
2 M Length, in hex, of the Authorisation Response Code (ʹ02ʹ)
4 M Authorisation Response Code value.
at2d Var. See Notes 5, 6 Issuer Script(s).

(up to 256) and 7
See Note 4 Each script is in a BER‐TLV formatted data object with a tag of 0x71 or
0x72.
Each script data object may optionally contain a script ID data object
(tag 0x9F18), but the value must not be more than four bytes.
Script commands will be held within script data objects and will be
identified with the tag value of 0x86.
Example Script Data:
'72 17 9F 18 04 12 34 56 78 86 0E 04 DA 9F 58 09 05
01 23 45 67 89 AB CD EFʹ
Where:
72 = Issuer Script Tag
17 = Length of Data
9F 18 = Script ID Tag
04 = Length of Script ID
12 34 56 78 = Script ID
86 = Issuer Script Command Template Tag
0E = Issuer Script Command Template Tag length
04 DA 9F 58 09 05 01 23 45 67 89 AB CD EF = Issuer Script Command
(PUT DATA)
Note 1: The field separator, buffer identifier and smart card data
identifier may only be omitted from the Transaction Reply or
Interactive Transaction Reply if CAM data is not expected.

Transaction Reply
Note 2: If the Issuer Authentication Data (ARPC) is not available,
for example because the Issuer connection is unavailable or the
Issuer does not respond with CAM data, this field may be omitted
to avoid subsequent rejection of the host response. If this field is not
omitted, the field separator, buffer identifier and smart card data
identifier must also be present.
Note 3: If the Authorisation Response Code is not available, for
example because the Issuer connection is unavailable or the Issuer
does not respond with CAM data, this field may be omitted to avoid
subsequent rejection of the host response; otherwise it must be
present. If this field is not omitted, the field separator, buffer
identifier and smart card data identifier must also be present.
If the Authorisation Response Code is received from the host and
has a value of ‘30 30’, the terminal requests a Transaction
Certification (Approval) from the card. If the Authorisation
Response Code is not present or is not set to ‘30 30’, an Application
Authorisation Cryptogram (Decline) is requested from the card. If
Authorisation Response Code values other than ʹ30 30ʹ need to be
treated as an Approval then these can be set via the registry. It is
possible to define Authorisation Response Codes which are to be
treated as invalid and rejected and to enable stricter checking of the
value of the Authorisation Response Code. To learn how to perform
any of these three actions see “Authorisation Response Codes” on
page 7‐47
Note 4: If more than 256 bytes are received for the issuer script, any
complete 0x71/0x72 tagged issuer scripts below this limit are
attempted. Any issuer script commands beyond or continuing
beyond this limit are not attempted and, for each, a fake unsolicited
script error is sent to Central. The failure of the first command of
each of these scripts is also reported in the Issuer Script Results.
Note 5: Issuer script(s) are optional and may be omitted. If this field
is not omitted, the field separator, buffer identifier and smart card
data identifier must also be present. For further details on Issuer
Scripts, see “Issuer Script Results and Completion Data” in
Note 6: If an Issuer Script ID (tag 0x9F18) has a value greater than
four bytes in length, this is regarded as invalid data.
Note 7: An Issuer Script Command (tag 0x86) and therefore an
Issuer Script are regarded as containing valid data only when:
● The value field of the Issuer Script Command data object (tag
0x86) is at least four bytes long (CLA, INS, P1 and P2)

Transaction Reply
● If the Lc command parameter is present, then the value field
must have at least ʹLcʹ bytes of data following the Lc command
parameter byte
● In the Lc & Le command parameters, there must be no data
following the Le command parameter.

Transaction Reply
In effect, the validation verifies that the command is in one of the
following ISO/EMV command formats:
● CLA INS P1 P2
● CLA INS P1 P2 Lc <command data> ‐ Lc can be zero
● CLA INS P1 P2 Le
● CLA INS P1 P2 Lc <command data> Le ‐ Lc can be zero
When only the Lc or Le parameter is present (second and third cases
above) it is not possible for the terminal to distinguish between
them. In this situation, validation assumes that if there are only five
bytes in the data object value field, then the fifth byte is the Le
parameter. If there are more than five bytes in the data object value
field, then the fifth byte is treated as the Lc parameter.
This buffer allows the host to update entries in the Currency and
Field bc ‐ Transaction Data Transaction data object tables and update one of the AANDC
Objects Update Buffer 5
Buffers.
In combination with the Set ICC Transaction Data state it is
intended to be used for retrying failed transactions (for example
incorrect PIN), or in combination with Dynamic Currency
Conversion.
Number of
Characters
bc1 1 M Always ʹcʹ as the buffer identifier.
bc2a 2 M Two digit ASCII hex value in the range ʹ01ʹ to ʹFFʹ inclusive,
identifying the ICC Currency Data Objects Table entry to be created or
modified. If the value is ʹ00ʹ then field bc2b will be omitted.

Transaction Reply
Number of
Characters
bc2b Variable O Any BER‐TLV formatted data object may be placed in this field, but all

up to 255. data objects must be held within a single Response Format 2 data
This field may typically contain the Transaction Currency Code (tag
0x5F2A) and the Transaction Currency Exponent (tag 0x5F36) data
objects. For example:
ʹ77 09 5F 2A 02 08 26 5F 36 01 02ʹ
Where:
ʹ5F 2Aʹ ‐ ʹTransaction Currency Codeʹ data object tag
ʹ02ʹ ‐ ʹTransaction Currency Codeʹ data object length
ʹ08 26ʹ ‐ ʹTransaction Currency Codeʹ data object value
ʹ5F 36ʹ ‐ ʹTransaction Currency Exponentʹ data object tag
ʹ01ʹ ‐ ʹTransaction Currency Exponentʹ data object length
ʹ02ʹ ‐ ʹTransaction Currency Exponentʹ data object value
bc2c 2 M Two digit ASCII hex value in the range ʹ01ʹ to ʹFFʹ inclusive,
identifying the ICC Transaction Data Objects Table entry to be created
or modified. If the value is ʹ00ʹ then field bc2d will be omitted.
bc2d Variable O Any BER‐TLV formatted data object may be placed in this field, but all

up to 255 data objects must be held within a single Response Format 2 data
This field may typically contain the ʹTransaction Typeʹ (tag 0x9C) data
object and the MasterCard proprietary ʹTransaction Category Codeʹ
(tag 0x9F53) data object. For example:
ʹ77 07 9C 01 01 9F53 01 5Aʹ
Where:
ʹ77ʹ = ʹResponse Format 2ʹ data object tag
ʹ07ʹ = ʹResponse Format 2ʹ data object length
ʹ9Cʹ = ʹTransaction Typeʹ data object tag
ʹ01ʹ = ʹTransaction Typeʹ data object length
ʹ01ʹ = ʹTransaction Typeʹ data object value
ʹ9F53ʹ = ʹTransaction Category Codeʹ data object tag
ʹ01ʹ = ʹTransaction Category Codeʹ data object length
ʹ5Aʹ = ʹTransaction Category Codeʹ data object value.

Transaction Reply
Number of
Characters
bc2e 1 M Target Buffer Identifier:
ʹ0ʹ ‐ No buffer update required.
ʹ1ʹ ‐ General Purpose Buffer B
ʹ2ʹ ‐ General Purpose Buffer C
ʹ3ʹ ‐ Amount buffer
bc2f 0 or 2 O Buffer Length.

Two digit ASCII hex value with value ʹ08ʹ, ‘0C’ or ʹ20ʹ, identifying the
length in characters of the buffer data.
If the ʹTarget Buffer Identifierʹ is ʹ0ʹ then this field is omitted.
If the ʹTarget Buffer Identifierʹ is ʹ1ʹ or ʹ2ʹ then the acceptable value of
this field will be ʹ20ʹ (32 characters).
If the ʹTarget Buffer Identifierʹ is ʹ3ʹ then the acceptable value of this
field will be ʹ08ʹ or ʹ0Cʹ (8 or 12 characters) dependent on the setting of
configuration option 01.
bc2g 0, 8, 12 or O Buffer Data.

32 If the ʹTarget Buffer Identifierʹ is ʹ0ʹ then this field is omitted, otherwise
the content of this field will overwrite the contents of the target buffer
identified. The length will be as identified by ʹBuffer Lengthʹ field bc2f.
It is intended that the data in this field, having been placed in the
target buffer, will be used in conjunction with the Set ICC Data state to
populate the ʹAmount, Authorisedʹ (tag 0x9F02 & 0x81) data objects.
To use non‐standard buffer identifiers defined by a C‐Exit or
Buffer Identifiers 5
authored update in the transaction reply with Advance NDC, you
will need to create a text file containing the buffer identifiers. The
text file must be called TrailingBufs.txt and be copied to the
C:\Program Files\NCR APTRA\Advance NDC\Config directory of
the terminal.
The file contains a character for each of the buffer identifiers being
used. For example, for buffers x, q, and T the file would simply
contain the text:
xqT
If this file contains existing buffer identifiers then any EMV Exits
validation relating to each of those buffer identifiers will be
bypassed.
To use non‐standard functions in the Transaction Reply with
Function Identifiers 5
Advance NDC, you will need to create a text file containing the
non‐standard function IDs.
The text file must be called TransFuncIds.txt and be copied to the
directory C:\Program Files\NCR APTRA\Advance NDC\Config
or c:\ssds\dll (for EMV versions prior to 02.02.00), on the
terminal.

Transaction Reply
The TransFuncIds.txt file must contain a character for each of the
function IDs being used. For example, for IDs G, H, and I the file
would simply contain the text:
GHI
This simply identifies that these non‐standard functions are being
used.A non‐standard function might check for the presence of a
specific device, for example.
If this file contains existing Function Ids then any EMV Exits
validation relating to each of those Function Ids will be bypassed.
For further details, see the ʹNew Function IDs in a Transaction
Replyʹ section under ‘Transaction Request/Reply’ in Chapter 8 of the
APTRA Advance NDC, Developerʹs Guide.
The Interactive Transaction Response also remains unaltered, with
Interactive Transaction the exception that the fields previously identified immediately
Response 5
follow field ʹjʹ.

Transaction Reply

Table of Contents
Chapter 6
Overview 6‐1
Supervisor Menus/Functions 6‐2
90 MISC FUNCS 6‐2
0 PRNT CMPNT VERS 6‐2
1 PRNT SCRW VERS 6‐3

Table of Contents

F
Overview
Overview 6
This chapter provides a brief overview of the Supervisor menus and
functions which are relevant to using an ICC with APTRA Advance
NDC. In particular, the following Supervisor functions and
sub‐functions are included:
● 90 MISC FUNCS
● 0 PRNT CMPNT VERS
● 1 PRNT SCRW VERS.
For further details of the other Supervisor menus in APTRA
Advance NDC, see the APTRA Advance NDC, Supervisor’s Guide.
The reserved screens associated with the ‘EMV/CAM2 Exits for
APTRA Advance NDC’ product are grouped as ‘U’ reserved
screens. For details of the ‘U’ reserved screens, see Appendix E,
“EMV ICC Reserved Screens”.
For details of the other Reserved Screens used in APTRA Advance
NDC, see the APTRA Advance NDC, Reference Manual.

Supervisor Menus/Functions 6
To give a local terminal operator access to information on the
ICC/CAM software components and hardware, a new supervisor
menu and supervisor functions have been introduced to APTRA
Advance NDC.
The Select menu in APTRA Advance NDC now has a Miscellaneous
Functions (ʹ90 MISC FUNCSʹ) option, which is described in the
following sub‐sections.
Note: For details of all the Advance NDC Select menu options, see
the APTRA Advance NDC, Supervisor’s Guide.
The new supervisor menu ʹMISC FUNCSʹ is accessed via function
90 MISC FUNCS 6
ʹ90ʹ (ʹMISC FUNCSʹ) on the supervisor Select menu, and displays the
following Supervisor functions:
MISC FUNCS
0 PRNT CMPNT VERS
1 PRNT SCRW VERS
SELECT FUNCTION-
When the ʹMISC FUNCSʹ menu is entered from the Select menu, the
unsolicited supervisor keys message has field ʹe2ʹ set to ʹ90ʹ or ʹ090ʹ,
depending on the value of message mode option digit number 0.
0 PRNT CMPNT VERS 6
Supervisor function ʹ0ʹ (ʹPRNT CMPNT VERSʹ) prints the smart card
processing application component versions to the journal; for
example:
COMPONENT VERSIONS
ICC 02.02.00
CAM 02.02.00
INT 02.02.00
Some versions of Advance NDC do not support printing of the
NDC Interface component version number using this supervisor
menu option.

The ʹCOMPONENT VERSIONSʹ text is obtained from reserved
screen ʹU0071ʹ.
If the print operation is unsuccessful (for example, due to a print
failure or the device not being present) the relevant error message is
displayed.
When the ʹPRNT CMPNT VERSʹ function is selected from the ʹMISC
FUNCSʹ menu, the unsolicited supervisor keys message has field
ʹe2ʹ set to ʹ800ʹ or will not be sent, depending on the value of
message mode option digit number 0.
1 PRNT SCRW VERS 6
Supervisor function ʹ1ʹ (ʹPRNT SCRW VERSʹ) prints the Smart Card
Reader/Writer (SCRW) firmware version information to the journal;
for example:
SCRW VERSION
009001621450000000
The ʹSCRW VERSIONʹ text is obtained from reserved screen ʹU0072ʹ.
If the print operation is unsuccessful (for example, due to a print
failure or the device not being present) the relevant error message is
displayed.
When the ʹPRNT SCRW VERSʹ function is selected from the ʹMISC
FUNCSʹ menu, the unsolicited supervisor keys message has field
ʹe2ʹ set to ʹ801ʹ or will not be sent, depending on the value of
message mode option digit number 0.


Table of Contents
ICC Processing
Chapter 7
ICC Processing
Overview 7‐1
EMV Data Validation 7‐2
Issuer Script Processing 7‐3
Data Object List (DOL) Processing 7‐4
BER‐TLV Data Object Processing 7‐5
BER‐TLV Data Object Padding 7‐5
Terminal Specified BER‐TLV Data Objects 7‐6
Transaction Data Object List (TDOL) Processing 7‐11
Printing EMV Data Values 7‐12
MAC Configuration 7‐14
Terminal Verification Results (TVR) Processing 7‐16
Transaction Status Information (TSI) Processing 7‐20
PIN Encryption and Verification 7‐22
ICC Application Name Display 7‐23
Example Display 7‐26

Table of Contents
ICC Processing
Voice Guidance 7‐27
Application Name Selection 7‐27
Dynamic Currency Conversion 7‐29
Error Handling 7‐33
Fake ICC Application Errors 7‐33
General Command Errors 7‐33
Specific Command Errors 7‐34
Higher Level Errors 7‐34
ICC Application Journal Error Message 7‐36
Journal Print Examples 7‐38
Reserved Screens 7‐38
Offline Decline Journal Message 7‐39
Example Journal Trace 7‐40
Default Traced Objects 7‐41
Changing Traced Objects 7‐41
Disabling Offline Decline Journal Tracing 7‐42
Extended Journal Tracing 7‐44
ICC Processing Termination 7‐46
Authorisation Response Codes 7‐47
Additional Approval Response Codes 7‐47
Strict Authorisation Response Code Validation 7‐48
Invalid Authorisation Response Codes 7‐48
Windows Registry Settings 7‐50

ICC Processing
G
Overview
Overview 7
This chapter provides an overview of the following ICC processing
functions:
● EMV Data Validation
● Issuer Script Processing
● Data Object List (DOL) Processing
● Basic Encoding Rules ‐ Tag Length Value (BER‐TLV) Data
Object Processing
● BER‐TLV Data Object Padding
● Terminal Specified BER‐TLV Data Objects
● Transaction Data Object List (TDOL) Processing
● Printing EMV Data Values
● MAC Configuration
● Terminal Verification Results (TVR) Processing
● Transaction Status Information (TSI) Processing
● PIN Encryption and Verification
● ICC Application Name Display
● Voice Guidance
● Dynamic Currency Conversion
● Error Handling
● ICC Application Journal Error Message
● Extended Journal Tracing
● ICC Processing Termination
● Authorisation Response Codes
● Windows Registry Settings.
Application ID (AID) processing is assumed to have been already
performed, as summarised in “ICC Initialise and Candidate List
Build” in Chapter 2, “State Tables”.

ICC Processing
EMV Data Validation
EMV Data Validation 7
The validation of the EMV Configuration messages is performed by
the NDC C‐Exits interface.
Each incoming message is parsed by the EMV Exits to extract and
process the EMV related data, before being passed on to NDC
Advance NDC.
If there is an error in the EMV related data in an incoming message,
the appropriate error message is generated by the EMV Exits, and
the message is rejected before being passed on to NDC.
Similarly, for each outgoing message, the EMV data is processed
and appended to by the EMV Exits.

ICC Processing
Issuer Script Processing
Issuer Script Processing 7
There are two types of issuer scripts which may be sent in the
response from Central, both of which are distinguished by their tag.
If the issuer script has a tag of 0x71, the issuer script is to be
submitted to the ICC immediately before the second GENERATE AC
command. If the issuer script has a tag of 0x72, the issuer script is to
be submitted to the ICC after the second GENERATE AC command.
If the issuer script processing is being performed before the second
GENERATE AC command, all the scripts beginning with tag 0x71
are executed sequentially as they are found in the Central response.
Similarly, each command within each script is also executed
sequentially as found.
If the issuer script processing is being performed after the second
GENERATE AC command, all the scripts beginning with tag 0x72
are executed sequentially as they are found in the Central response.
Similarly, each command within each script is also executed
sequentially as found.
Script processing results are sent to Central on the first available
solicited status message to be transmitted, following receipt of the
transaction reply currently being processed.
In the ‘EMV/CAM2 Exits for APTRA Advance NDC’ product,
invalidly formatted issuer script data is not rejected during
transaction reply validation, prior to issuer script processing.
Instead, an attempt to process each script is made until the script is
complete, an ICC level error occurs, or a formatted error is
discovered. A formatting error will result in a fake script unsolicited
error message being sent to the host (Central). The formatted failure
is also reported in the Issuer Script Results.

ICC Processing
Data Object List (DOL) Processing
Data Object List (DOL) Processing 7
All Data Object List (DOL) objects are processed in accordance with
the rules defined by the EMV standards. For the purpose of
processing objects identified by a DOL, the object type is also as
defined in the EMV standard.
In addition, the MasterCard proprietary Transaction Category Code
data object (tag 0x9F53) is defined as having the type
‘alphanumeric’ (ASCII encoded).
The DOL is validated during processing as follows:
● The object tag and object length fields must be of valid BER‐TLV
format.
● For this implementation, the object tag must not be more than
two bytes long.
● The object length field must not be more than one byte long.
● The total length of the output from processing the DOL must not
exceed 255 bytes.
If the DOL data stored (PDOL, TDOL, CDOL1 or CDOL2) has
invalid contents, the DOL output will have zero length.
The DOL output will then be submitted to the card via the
command requiring it as input.
The lack of input data to the command will cause an ICC
application error, which will be handled in the normal manner; see
“Error Handling”.

ICC Processing
BER-TLV Data Object Processing
BER‐TLV Data Object Processing 7
All object data is checked to ensure that it is in Basic Encoding Rules
‐ Tag Length Value (BER‐TLV) format as defined by the EMV
standard.
Additionally, the object tag must not be more than two bytes long.
Any data returned by a command that does not comply to the
BER‐TLV format, or exceeds the previous restrictions, results in the
fake ICC application level error ʹPart of the returned data may be
corruptedʹ (SW1 = 0x62, SW2 = 0x81) being generated to indicate
that the data is corrupt or not as expected.
ISO 7816‐4 indicates that one or more padding bytes, of the value
BER‐TLV Data Object 0xFF or 0x00, may precede or trail BER‐TLV formatted data objects.
Padding 7
This padding is to allow for data deletion and modification on the
ICC.
ISO 7816‐4 also indicates that BER‐TLV data objects cannot have a
tag starting with 0x00 or 0xFF.
Although padding is supported for BER‐TLV data obtained from
the ICC, all messages to the terminal from Central must not include
padding in BER‐TLV formatted message fields. If padding is
included in a message, an appropriate reject response will be sent to
Central.
The messages from the terminal to Central do not include any
padding in BER‐TLV formatted fields.

ICC Processing
The following table defines the Terminal Specified BER‐TLV Data
Terminal Specified Objects in alphabetical order. These are the only objects that the
BER‐TLV Data Objects 7
terminal automatically populates. All the other EMV objects are also
supported by the terminal, but must first be downloaded from the
host in one of the three object download messages.
No. of
Element Name Description Tag Value
bytes
AID Application ID as selected by the 0x9F06 5 ‐ 16 AID of application selected

terminal. in Binary Coded Decimal
(BCD).
Amount Authorised amount for the transaction 0x9F02 6 Value of transaction in

Authorised (excluding adjustments). minor currency units,
(Numeric) formatted in BCD.
Value set through State
Type ʹ?ʹ ‐ Set ICC
Transaction Data. For
details, see “? ‐ Set ICC
Transaction Data State” in
Amount Authorised amount for the transaction 0x81 4 Value of transaction in

Authorised (excluding adjustments). minor currency units, as a
(Binary) binary value.
Value set through State
Type ʹ?ʹ ‐ Set ICC
Transaction Data. For
details, see “? ‐ Set ICC
Transaction Data State” in
Application Application version supported by the 0x9F09 2 Value taken from the

Version Number terminal. ʹPrimary AID Highest
Application Version
Numberʹ field in the
selected ICC applicationʹs
corresponding ʹICC
Terminal Acceptable AID
Tableʹ entry. See “ICC
Terminal Acceptable
Application IDs Table” in
Chapter 5, “Central to

ICC Processing
No. of
bytes
Interface Device This Interface Device Serial Number is 0x9F1E 8 The ATM serial number is

Serial Number the unique identifier for the terminal. used to populate this value.
If no serial number has
been configured then this
object will not be
populated.
The serial number used is
the one displayed and
configured through the
system application.
Issuer Script The results of the processing of any 0x9F5B Var The results of processing

Results issuer scripts. the Issuer scripts. If no
issuer scripts have been
received then the object will
not be populated.
Terminal Indicates the card data input, CVM and 0x9F33 3 0x60 0x40 0x20 or 0x60 0x40

Capabilities security capabilities of the terminal. 0x00 if a Smart Dip reader is
being used.
0x60 ‐ Magnetic stripe and ICC with
contacts capabilities.
0x40 ‐ On‐line enciphered PIN is used
for CVM.
0x20 ‐ Card capture can be performed.

ICC Processing
No. of
bytes
Terminal Indicates the data input and output 0x9F40 5 0xEE (cash)/0x6E

Capabilities capabilities of the terminal. (non‐cash) 0x00 0xB0 0x53
(Additional) (receipt)/ 0x13 (no receipt)
0xEE/0x6E ‐ payment, transfer, enquiry, 0xFF
goods, services and (if cash dispenser is
present) cash transactions can be
performed on this terminal.
0x00 ‐ reserved for future use.
0xB0 ‐ terminal has numeric, command
and function keys.
0x53/0x13 ‐ data can be output to a
cardholder display and cardholder
receipt (if receipt printer present). ISO
8859 parts 9 and 10 character sets are
supported.
0xFF ‐ Character sets from ISO 8859
parts 1 to 8 inclusive are supported.
The supported ISO 8859 character sets
and their font IDs are listed in
Appendix F, “ISO 8859 Character Sets”.
Terminal A terminal identification number. 0x9F1C 8 The APTRA Advance NDC

Identification machine number is used to
populate this value.
If no machine number has
been configured then this
object will not be
populated.
The machine number used
is the one displayed and
configured through the
CONFIG menu of APTRA
Advance NDC Supervisor
mode.
Terminal Floor A default floor limit of zero will be set 0x9F1B 4 Zero

Limit by the terminal.
Terminal Status of the different functions as seen 0x95 5 See “Terminal Verification

Verification from the terminal. Results (TVR) Processing”.
Results

ICC Processing
No. of
bytes
Transaction Date Local date that the transaction was 0x9A 3 YYMMDD.

authorised.
Date from terminal clock in
BCD, taken at start of
transaction.
Transaction Counter maintained by the terminal that 0x9F41 2 Value in the range 0001 to

Sequence is incremented by one for each 9999 (decimal) inclusive,
Counter successful initialisation of an ICC encoded in BCD.
application.
The counter is cyclic, and
defaults to 0001 (decimal)
on power up.
Transaction Status of authentication transaction as 0x9B 2 See “Transaction Status

Status seen from the terminal. Information (TSI)
Information Processing”.
Transaction Time Local time that the transaction was 0x9F21 3 HHMMSS.

authorised.
Time from the terminal
clock in BCD taken at the
start of the transaction.
Unpredictable Value to provide variability and 0x9F37 4 Random number in binary.

Number uniqueness to the generation of the
application cryptogram.
Note 1: Any objects not known by the terminal (that is, not in the
list above), not retrieved from the ICC and not made known
through processing in State Type ʹ?ʹ Set ICC Transaction Data, but
referenced by a DOL, are processed following the DOL processing
rules identified in “Data Object List (DOL) Processing”.
Note 2: Terminal Verification Results (tag 0x95) and Transaction
Status Information (tag 0x9B) data objects are made known to the
terminal, with each value byte set to 0x00.
Note 3: Data object tags 0x9F06, 0x9F09, 0x9F33, 0x9F40, 0x9A,
0x9F21 and 0x9F37 are set and made known to the terminal.
Additional terminal data objects can be made known after these
data objects using ICC Terminal Data Objects. For more details, see
“ICC Terminal Data Objects Table” in Chapter 5, “Central to
Note 4: Data object tag 0x8A is made known, but only if the Issuer
Authentication Data (tag 0x91) has been provided by a response
from Central in the appropriate Transaction Reply/Interactive
Transaction Response for the transaction being processed.

ICC Processing
Note 5: Other data objects can be made known to the terminal
through the use of processing in State Type ʹ?ʹ Set ICC Transaction
Data. For more details, see “? ‐ Set ICC Transaction Data State” in

ICC Processing
Transaction Data Object List (TDOL) Processing
Transaction Data Object List (TDOL)
Processing 7
If the Transaction Certificate (TC) Hash Value (tag 0x98) data object
is requested by a DOL (principally CDOL1 or CDOL2), then
Advance NDC CAM needs to calculate the value for the data object
so that it can be output as part of the DOL data.
Processing the output of the TDOL with this algorithm provides a
checksum/signature which is 20 bytes long.
Note: If the TC Hash Value data object is referenced in TDOL, this
is regarded as invalid content for the purposes of DOL processing.
The TDOL data object is optionally returned by the ICC application
during processing. If the TDOL data object has not been obtained, a
default value for TDOL is used. The default is defined as follows:
Object Name Tag Length (bytes)
Amount Authorised 0x9F02 6
Transaction Currency Code 0x5F2A 2
Transaction Date 0x9A 3
Transaction Type 0x9C 1
Terminal Verification Results 0x95 5
Unpredictable Number 0x9F37 4

ICC Processing
Printing EMV Data Values
Printing EMV Data Values 7
To allow the host to instruct the terminal to print EMV tag values
the following EMV control sequences have been introduced. When
these are included in the printer data the terminal will replace them
with the value of the requested EMV tag. This print data applies to
the receipt, journal and statement printers.
To allow the host to have flexibility in deciding the manner in which
the values will be printed, the following system will be applied to
the interpretation of the data for the printer.
To indicate the start position where the EMV data values can be
inserted into the printer data the value ʹ&&Sʹ will be used.
To indicate the end position where the EMV data values can be
inserted into the printer data the value ʹ&&Eʹ will be used.
For the purposes of formatting the following rules will be applied:
● The tag of the value to be printed will be prefixed by the
control code ʹ&&Tʹ. For example ʹ&&T95ʹ indicates that the
Terminal Verification Results should be printed. The one
exception to this is for numeric format data where leading
zeros are required.
● Following the tag a number of wildcard characters indicate
the positions where the data will be inserted into the printer
data. For all tags, except those which represent a date or
time, the wildcard character will be an asterisk ʺ*ʺ.
● Any non‐wildcard characters will be copied into the print
data unchanged. For example if the amount was 5623 the
wildcard string of ʺ$ ****.**ʺ could be used to print an
amount, resulting in ʺ$ 56.23ʺ.
● For time values the following wildcard characters will be
used ‐ H or h for minutes, M or m for minutes, S or s for
seconds. For example if the time was 12:35:34 HH:MM/SS
will print the time as 12:35/34 or HH.MM will print the time
as 12.35
● For date values the following wildcard characters will be
used ‐ D or D for day, M or m for month, Y or y for year. For
example if the date is the 4th February 2010 ʺMM/20YYʺ will
print as ʺ02/2010ʺ.
● Following the formatting information for the tag the &&
should be used to terminate the &&T sequence. For example
ʺ&&T95 TVR ** ** ** ** **&&ʺ.

ICC Processing
Printing EMV Data Values
● If the value will not fit within the total space indicated by the
asterisks then it will be truncated from the left.
● Any asterisk characters which are unused after the value is
inserted, will be replaced by spaces (0x20).
● If a tag value is recognised but not known at the terminal
then nothing that appears between the &&T and &&
markers will be printed.
● If a tag value is defined to be type binary or var, or of
unknown type, then the value printed will be the
hexadecimal equivalent of the value. For example a
Cryptogram Information data object of value 0x40 which
means transaction certification would be printed as ʺCID 40ʺ
if the escape sequence was ʺ&&SCID &&T9F27**&&&&E
● If a tag value is defined to be type numeric, then the value
will be printed in decimal, with any leading zeros removed.
For example an amount authorised (numeric) whose value is
ʺ00 00 00 01 23 45ʺ would be printed as ʺ12345ʺ. To print the
leading zeros, insert &&0 after the &&T so &&T&&09F02&&
prints as ʺ000000012345ʺ.
● If a tag value is defined to be type alphanumeric, alphabetic
or alphanumeric special then no translation of the data will
be done.
● If a tag value is defined to be compressed numeric, then the
value will be expanded into numeric form before being
printed. This includes removal of any padding ʺFʺ characters
at the end of the value. The Track 2 equivalent data, tag 57,
will additionally be treated as if it is of type compressed
numeric.
● All other characters not between the start (&&S) and end
point (&&E) marker values will be unchanged.
● Should a formatting error occur in any of the control codes
then the conversion process will halt for the remainder of the
printer data relating to the current printer flag. All
remainder data in the current printer buffer will be left
unaltered. The conversion process will be applied to the next
printer buffer included in the transaction reply.

ICC Processing
MAC Configuration
MAC Configuration 7
To enable message authentication to be performed on the new
Transaction Request and Transaction Reply message fields and the
new messages introduced with NDC CAM, the MAC processing
has been extended to enable the MAC value calculation processing
to take account of these changes.
The standard Message Authentication Field Selection Load message
has also been extended to cover the new fields and messages.
For the Smart Card Data buffer (data ID ʹ5ʹ, fields ʹbd1ʹ and ʹbd2ʹ)
extension in the Transaction Request message, the Message
Authentication Field Selection Load message field ʹhʹ (Transaction
Request Field) has an additional flag appended at offset 46. This flag
contains a value of ʹ0ʹ if the Smart Card Data buffer is not to be used
in the MAC value calculation, or a value of ʹ1ʹ if it is to be used. For
more details, see “Transaction Request Message Format” in
For the Smart Card Data buffer (data ID ʹ5ʹ, fields ʹat1ʹ, ʹat2ʹ)
extension in the Transaction Reply message, the Message
Authentication Field Selection Load message field ʹiʹ (Transaction
Reply Field) has an additional flag appended at offset 36 for
Advance NDC. This flag contains a value of ʹ0ʹ if the Smart Card
Data buffer is not to be used in the MAC value calculation, or a
value of ʹ1ʹ if it is to be used. For more details, see “Transaction
Reply” and “Interactive Transaction Response” in Chapter 5,
For the Dispenser Currency Cassette Mapping Table message, the
Message Authentication Field Selection Load message field ʹkʹ
(Other Messages Field) has an additional flag appended at offset 3.
This flag contains a value of ʹ0ʹ if the Dispenser Currency Cassette
Mapping Table message is not to have a MAC value, or a value of ʹ1ʹ
if it is.
For details of the Dispenser Currency Cassette Mapping Table, see
the APTRA Advance NDC, Reference Manual.
For the new messages which form the new EMV Configuration
message class, an additional field ‘o’ has been added immediately

ICC Processing
MAC Configuration
following the Message Authentication Field Selection Load message
field ʹnʹ (Track 3 Field). Field ‘o’ is formatted as follows:
Number of
Characters
FS 1 O Field Separator.
Always present if field ʹoʹ is included in the message.
If ʹoʹ is not being included, this field separator is omitted.
o 5 See Notes 1 For each offset position, if the field contains ʹ0ʹ, no MAC is added to the
and 2 message indicated. If it contains ʹ1ʹ, a MAC is added to the message.
Offset Description
0 ICC Currency Data Objects Table message
1 ICC Transaction Data Objects Table message
2 ICC Language Support Table message
3 ICC Terminal Data Objects message
4 ICC Terminal Acceptable AIDs Table message
Note 1: This field may be truncated, that is, trailing characters may
be omitted. The omitted characters have the value zero.
Note 2: If this new field is included, its value is used in the
calculation of the MAC value in the Message Authentication Field
Selection Load message field ʹpʹ (previously ʹoʹ) Message
Authentication Code Data.

ICC Processing
Terminal Verification Results (TVR) Processing
Terminal Verification Results (TVR)
Processing 7
The relevant fields within the Terminal Verification Results (TVR)
data object are updated by Advance NDC (see “Terminal Specified
BER‐TLV Data Objects”), depending on the status of the ICC and
the transaction. All other fields have a fixed value. The elements of
the TVR data object are as follows:
1 8 0/1 Initial value set to 0 for PDOL processing.
Then set to 1 to indicate that off‐line data authentication was not performed.
7 0 Off‐line static data authentication has not failed.
6 0/1 ICC Data Missing/Not Missing Flag.
Initially set to 0 (ICC Data Missing) for PDOL processing.
May be set to 1 (ICC Data Not Missing) as a result of CVM processing in “I ‐ Transaction
Request State”.
5 0 Card does not appear on terminal exception file.
4 0 Off‐line dynamic data authentication has not failed.
3 0 Reserved.
2 0 Reserved.
1 0 Reserved.
2 8 0/1 ICC Application Version Out of Range Flag
If the version number returned from the Application Version Number (tag 0x9F08) data
object during ICC application processing is not within the specified range for the
matching ICC Terminal Acceptable AIDs Table entry (that is, whose Full/Partial Primary
AID Value matched the ICC AID for the ICC application being processed), this bit is set to
1.
For more details, see “ICC Terminal Acceptable Application IDs Table” in Chapter 5,
If the version number is in range, or if the Application Version Number data object was
not obtained from the ICC, or has no value field, this bit is set to 0.

ICC Processing
2 7 0/1 Application Expired Flag
If the date from the Transaction Date (tag 0x9A) data object is after the expiry date
returned from the Application Expiration Date (tag 0x5F24) data object during ICC
Application processing, this bit is set to 1.
Otherwise, if the date is not after the expiry date, or if the Application Expiration Date
data object is not available, this bit is set to 0.
Note: If either data object two‐digit year value is in the range 00 to 49, the corresponding
full year value is 2000 to 2049. However, if the data object two‐digit year value is in the
range 50 to 99, the full year value is 1950 to 1999.
6 0/1 Application Not Yet Effective Flag
If the date from the Transaction Date (tag 0x9A) data object is before the effective date
returned from the Application Effective Date (tag 0x5F25) data object during ICC
application processing, this bit is set to 1.
Otherwise, if the date is not before the effective date, or if the Application Effective Date
data object is not available, this bit is set to 0.
Note: If either data object two‐digit year value is in the range 00 to 49, the corresponding
full year value is 2000 to 2049. However, if the data object two‐digit year value is in the
range 50 to 99, the full year value is 1950 to 1999.
5 0/1 Requested Service Not Permitted Flag
Initially set to 0 (Requested Service Permitted) for PDOL processing.
May be set to 1 (Requested Service Not Permitted) as a result of AUC processing in “I ‐
Transaction Request State” or “ICC Application Select & Initialise Processing”.
4 0 This card is not new.
3 0 Reserved
2 0 Reserved
1 0 Reserved

ICC Processing
3 8 0/1 Cardholder Verification Successful Flag
Initially set to 0 (Cardholder Verification Successful) for PDOL processing.
May be set to 1 (Cardholder Verification Not Successful) as a result of CVM processing in
“I ‐ Transaction Request State”.
7 0/1 Cardholder Verification Method (CVM) Recognised Flag
Initially set to 0 (CVM Recognised) for PDOL processing.
May be set to 1 (CVM Not Recognised) as a result of CVM processing in “I ‐ Transaction
Request State”.
6 0 PIN Try Limit was not exceeded.
5 0/1 PIN Entry Required But PIN Pad Not Present/Not Working Flag
Initially set to 0 for PDOL processing.
May be set to 1 (PIN Entry Required But PIN Pad Not Present/Not Working) as a result of
CVM processing in “I ‐ Transaction Request State”.
4 0 PIN entry required, PIN Pad present and PIN was entered.
3 0/1 On‐line PIN Entered Flag
If the PIN block is being included in the Transaction Request message, and the CVM list
includes an On‐line PIN condition, this bit is set to 1. Otherwise, it is set to 0.
Note: This bit will only be set if the CVM chosen for the transaction was On‐line
enciphered PIN. If CVM processing failed or was not done then this bit will not be set.
2 0 Reserved
1 0 Reserved
4 8 0/1 Transaction Exceeds Floor Limit Flag
If floor limit checking was performed and the amount was equal to or above the floor
limit, this bit is set to 1. Otherwise, it is set to 0.
7 0 Lower consecutive off‐line limit not exceeded.
6 0 Upper consecutive off‐line limit not exceeded.
5 0 Transaction not selected randomly for on‐line processing.
4 0 Merchant did not force transaction on‐line.
3 0 Reserved
2 0 Reserved
1 0 Reserved

ICC Processing
5 8 0/1 Default TDOL Used Flag
If the TC Hash Value (tag 0x98) was requested during DOL processing and the default
value for the TDOL (tag 0x97) data object was used, this bit is set to 1. Otherwise, it is set
to 0.
7 0/1 Issuer Authentication Success/Fail Flag
If the ICC command EXTERNAL AUTHENTICATE fails, this bit is set to 1.
Otherwise, if the ICC command EXTERNAL AUTHENTICATE is successful, or is yet to
be performed, it is set to 0.
6 0/1 Script Processing Before Final Generate AC Success/Fail Flag
If any tag 0x71 issuer scripts fail (returned in a Central response to the Transaction
Request), this bit is set to 1.
Otherwise, this bit is set to 0.
5 0/1 Script Processing After Final Generate AC Success/Fail Flag
If any tag 0x72 issuer scripts fail (returned in a Central response to the Transaction
Request), this bit is set to 1.
Otherwise, this bit is set to 0.
4 0 Reserved
3 0 Reserved
2 0 Reserved
1 0 Reserved

ICC Processing
Transaction Status Information (TSI) Processing
Transaction Status Information (TSI)
Processing 7
The relevant fields within the Transaction Status Information (TSI)
data object are updated by Advance NDC (see “Terminal Specified
BER‐TLV Data Objects”), depending on the status of the ICC and
the transaction. All other fields have a fixed value. The elements of
the TSI are as follows:
1 8 0 Off‐line data authentication was not performed.
7 0/1 Cardholder Verification Performed Flag
Initially set to 0 (Cardholder Verification Not Performed) for PDOL processing.
May be set to 1 (Cardholder Verification Performed) as a result of CVM processing in “I ‐
Transaction Request State”.
6 0/1 Card Risk Management Performed Flag
If the ICC responds with an ARQC to the first GENERATE APPLICATION
CRYPTOGRAM command, this bit is set to 1 (Card Risk Management Performed).
Otherwise, this bit is set to 0 (Card Risk Management Not Performed).
5 0/1 Issuer Authentication Performed Flag
If the ICC command EXTERNAL AUTHENTICATE has been submitted to the ICC, this
bit is set to 1. Otherwise, it is set to 0.
4 0/1 Terminal Risk Management Performed Flag
If the Terminal Floor Limit is downloaded from the host, terminal risk management is
performed and this bit is set to 1. Otherwise, it is set to 0.
3 0/1 Script Processing Performed Flag
If an attempt is made to process one or more issuer scripts (tag 0x71 or tag 0x72), this bit is
set to 1. Otherwise, it is set to 0.
2 0 Reserved
1 0 Reserved
2 8 0 Reserved
7 0 Reserved
6 0 Reserved

ICC Processing
Transaction Status Information (TSI) Processing
5 0 Reserved
4 0 Reserved
3 0 Reserved
2 0 Reserved
1 0 Reserved

ICC Processing
PIN Encryption and Verification
PIN Encryption and Verification 7
For ICC applications, you should be aware of the following:
● Each ICC application present on a card may have a unique PIN
value, which may also differ from the cardholder PIN value
used if performing a magnetic stripe based transaction.
● Each ICC application present on a card may have unique track 2
equivalent data, which may also differ from the track 2 data
present on the magnetic stripe.
These facts become very important when Central is performing
cardholder PIN verification using track 2 data. This is because when
a cardholder PIN is to be sent from the terminal to Central for
verification, it is encrypted into a block. The encryption process uses
both the cardholder entered PIN and the track 2 PAN as input to
create the encrypted PIN block.
On receipt of the encrypted PIN block, Central verifies the
cardholder PIN value using the track 2 PAN.
In order to successfully verify the PIN, Central needs to be sent (or
be able to derive) the track 2 data used by the terminal to construct
the encrypted PIN block. The track 2 data used by the terminal is
configured using the “ICC Terminal Acceptable Application IDs
Table” fields f18 to f21.
The state flow downloaded to the terminal from Central must be
configured to ensure that the completion of the ICC application
selection and initialisation takes place before the point in the state
flow where the PIN is encrypted.
Note: The above processing is also relevant to PIN change
processing, where the new PIN value and new PIN confirmation
value are encrypted for transmission to Central.

ICC Processing
ICC Application Name Display
ICC Application Name Display 7
The ICC application name displayed to the cardholder is dependent
on the availability of data objects and the validity of their values, as
follows:
● If the ʹIssuer Code Table Indexʹ data object (tag 0x9F11) is
available and has a value in the range 0x01 to 0x10 (BCD)
inclusive, the ʹApplication Preferred Nameʹ data object (tag
0x9F12) is used as the ICC application name.
● If the ʹIssuer Code Table Indexʹ data object (tag 0x9F11) is
available but does not have a value, or the value is outside the
range 0x01 to 0x10 (BCD) inclusive, the ʹApplication Labelʹ data
object (tag 0x50) is used.
● If the ʹApplication Preferred Nameʹ data object (tag 0x9F12) is
not available, the ʹApplication Labelʹ data object (tag 0x50) is
used.
● If the ʹApplication Labelʹ data object (tag 0x50) is not available,
the default ʹApplication Labelʹ from the current ʹICC Terminal
Acceptable AIDs Tableʹ entry is used.
● If the ʹApplication Labelʹ data object (tag 0x50) is not available,
and the default ʹApplication Labelʹ from the current ʹICC
Terminal Acceptable AIDs Tableʹ entry is also not available, the
ICC application name is blank.
To enable Central flexibility in the way in which the ICC application
name is displayed, the following system has been applied to the
interpretation of screen data in screens holding the ICC application
name:
● To indicate the start position where the ICC application name
can be inserted into the screen data, the value ʹ&&Sʹ is used.
● To indicate the end position where the ICC application name
can be inserted into the screen data, the value ʹ&&Eʹ is used.
● The ICC application name is formatted to replace any character
positions, between the start and end point marker values, which
contain an asterisk (ʹ*ʹ) character.
For the purposes of formatting, the following rules are applied:
● If the value ʹ&&LJʹ is found after the start point, the ICC
application name is left justified within any assigned space
(marked by asterisks) following this formatting value.
● If the value ʹ&&RJʹ is found after the start point, the ICC
application name is right justified within any assigned space
(marked by asterisks) following this formatting value.

ICC Processing
● If the value ʹ&&CDʹ is found after the start point, the ICC
application name is centred within any assigned space (marked
by asterisks) following this formatting value.
● Formatting is applied within each uninterrupted string of
asterisks.
● If a formatting value (ʹ&&LJʹ, ʹ&&RJʹ or ʹ&&CDʹ) is not found
after the start point before a string of asterisks are encountered,
the formatting within the assigned space (marked by the
asterisks) defaults to being left justified, as if the value ʹ&&LJʹ
had been found.
● If the asterisk characters are grouped such that the ICC
application name has to be broken up, space characters in the
ICC application name are used where possible, but failing this
hyphenation is used.
● If the ICC application name will not fit within the total space
indicated by the asterisks, it is truncated from the right.
● Any asterisk characters which are unused after the ICC
application name is inserted are replaced by spaces (0x20).
● Any character between the start and end point marker values
which is not an asterisk (ʹ*ʹ) is unchanged.
● All characters before and after the start and end point marker
values are unchanged.
● If the value ʹ&&VGʹ is found after the start point then value of
the ʹApplication Labelʹ data object (tag 0x50) value will placed
into the screen data and the ʹ&&VGʹ removed.
In addition to the formatting, the characters in the ICC application
name are also processed.
The ICC application name is made up of characters from an ISO
8859 character set, which can potentially have binary values in the
range 0x00 to 0xFF, although a number of values are not used.
The terminal fonts can only hold characters in the binary range 0x00
to 0x7F; therefore, two fonts are required for each ISO 8859 character
set. Support is present for the character sets in ISO 8859 parts 1 to 10
inclusive.
ISO 8859 parts 1 to 10 are also supported to allow maximum use of
the ʹApplication Preferred Nameʹ data object (tag 0x9F12) as the ICC
application name, when acquiring transactions for cards that could
have been issued anywhere in the world.
The supported ISO 8859 character sets and their font IDs are listed
in Appendix F, “ISO 8859 Character Sets”.
The common characters use the font designators ʹ`ʹ (0x60, single
size) and ʹaʹ (0x61, double size).

ICC Processing
When processing asterisk ʹ*ʹ characters in the template, if the font ʹ`ʹ
or ʹaʹ (the common character set) is selected within the template, and
remains the currently selected font for the asterisk block being
processed, then the correct font for displaying language specific
characters (0x80 to 0xFF) is determined from the ʹIssuer Code Table
Indexʹ data object (tag 0x9F11) as follows:
1 If the ʹIssuer Code Table Indexʹ data object (tag 0x9F11) was
retrieved during processing, and has a value field with the first
byte containing a value in the range 0x01 to 0x10 (BCD)
inclusive, the value (converted to a normal decimal value) is
used as an offset to calculate the font identifier required.
2 If the ʹIssuer Code Table Indexʹ data object (tag 0x9F11) was not
available, did not have a value, or the value was not in the range
0x01 to 0x10 (BCD) inclusive, the offset is taken as 0x01.
3 If the currently selected font is ʹ`ʹ, the base font identifier index is
0x60.
4 If the currently selected font is ʹaʹ, the base font identifier index
is 0x61.
5 The font to be used is calculated as:
Font Identifier =
base font identifier index + (offset x 2).
6 If the currently selected font was not ʹ`ʹ or ʹaʹ, the current font is
used for all characters, and the above does not apply.
7 The individual character(s) in the range 0x80 to 0xFF are shifted
to the range 0x00 to 0x7F (by setting bit 8 to 0) and are then
displayed by switching the font to that identified by the above
processing.
8 After display of the character(s), the font is reverted back to ʹ`ʹ or
ʹaʹ as appropriate.
Note: ISO 8859 Part 8 (Latin/Hebrew) bi‐directional text
formatting is not supported, so LRM and RLM formatting
characters are ignored and nothing is displayed in their place.
The supported ISO 8859 character sets and their font IDs are listed
in Appendix F, “ISO 8859 Character Sets”.

ICC Processing
If Central requires FDK A to be used to select an ICC application
Example Display 7
name, the ICC application name may be displayed on two lines,
right justified, with an ‘arrow’ against the FDK (that is, ʹ>ʹ).
The screen data to achieve this may contain the following:
<ESC>(` &&S &&RJ <SI>E1 ********** <SI>F1 **********
<SI>F? > &&E <ESC>(1
The screen data is taken as a template and, given an ICC application
name of ʹCURRENT ACCOUNTʹ with ʹIssuer Code Table Indexʹ
data object (tag 0x9F11) value of 0x02, would be interpreted as the
following data for display on the cardholder screen:
<ESC>(` <SI>E1 ~~~CURRENT <SI>F1 ~~~ACCOUNT <SI>F? >
<ESC>(1
If the ICC application name was ʹCURRENT ACCOUNTʹ but with
an accent on the ʹEʹ, with the same ʹIssuer Code Table Indexʹ data
object (tag 0x9F11) value of 0x02, then the template would be
interpreted as the following data for display on the cardholder
screen:
<ESC>(` <SI>E1 ~~~CURR<ESC>(dL<ESC>(‘NT <SI>F1
~~~ACCOUNT <SI>F? > <ESC>(1
Where:
<SI> is ʹShift Inʹ (0x0F)
<ESC> is ʹEscapeʹ (0x1B)
'~' is a displayed space character (0x20).
Note: Other spaces are included above for clarity, but are not
actually present.

ICC Processing
Voice Guidance
Voice Guidance 7
Voice guidance in EMV Exits works the same as for Aptra Advance
NDC with the exception of audio related to the Application Label
which the card supplies.
The use of audio files to provide voice guidance is typically
required for PIN Entry and Application Selection.
In order to support dynamic application name the EMV Template
screens may use the control sequence ‘&&VG’ which will cause the
selected application name to be spoken.
The EMV template screens must be designed in conjunction with
the AANDC audio control to obtain voice guidance at the
appropriate points in the transaction.
The principle changes for updating Application Name Selection for
voice guidance are described below. The same principles also apply
for PIN Entry.
The cardholder application name selection screen is referenced by
Application Name Table Entry 2 or Table Entry 6 of the Begin ICC Initialisation and
Selection 7
Application Selection State.
The normal text display within this screen would be similar to:
● ʺ<SI>BAPlease Select Product/Accountʺ
The normal text display of the FDK template screens specified by
the FDK Extension State for Begin ICC Initialisation and
Application Selection would be similar to:
● <SI>F3&&S&&RJ************* >&&E
In addition two other screen prompts should be defined for “More
applications” or “Back to the initial screen of applications”. The
screen numbers for these are specified in the Action Keys extension
state.
The normal text display of these type of screens would be similar to:
● <SI>O:MORE >
To update this implementation to support audio, changes similar to
the following require to be made:
FDK template screens ‐ <SI>F3&&S&&RJ*************
><ESC>P000;1;<SO>ʺ111_audʺ&&VG<ESC>\&&E
More applications screen ‐ <SI>O:MORE
><ESC>P000;1;<SO>mmm_aud<ESC>\

ICC Processing
Voice Guidance
The combined text to be sent for both visual display with audio
guidance would be similar to:
<SI>BAPlease Select Product/Account<SI>F3&&S&&RJ*************
><ESC>P000;1;<SO>ʺ111_audʺ&&VG<ESC>\&&E<SI>IN&&S&&RJ
*************
>&&E<ESC>P000;1;<SO>ʺ222_audʺ&&VG<ESC>\&&E<SI>LN&&S
&&RJ*************
>&&E<ESC>P000;1;<SO>ʺ555_audʺ&&VG<ESC>\&&E<SI>ON&&
S&&RJ*************
>&&E<ESC>P000;1;<SO>ʺ666_audʺ&&VG<ESC>\&&E
The AudioGuidanceData.xml file must contain Audio Elements which
define the audioID attribute and Text sub‐element as shown:
Audio Element audioID attribute Audio Element Text sub-element
mmm_aud Press 4 for more applications
111_aud Press 1 for <PlaceHolder>
bbb_aud Press 8 to return to the start of the
applications
<The number of the background Please select the Product or
screen> Account.
<PlaceHolder/><PlaceHolder/><Pl
Note: The background screen aceHolder/><PlaceHolder/>
must be identified by its screen <PlaceHolder/><PlaceHolder/><Pl
number. The number of aceHolder/><PlaceHolder/>
<Placeholder/> sub‐elements
within the Text sub‐element must
at least equal the number of FDKs
originally enabled prior to voice
guidance.
Note: The normal mapping of FDKs to the numeric keys will be
performed by AANDC so the voice guidance given to the
cardholder needs to refer to the numeric keys rather than FDKs.

ICC Processing
Dynamic Currency Conversion
Dynamic Currency Conversion 7
The process of Dynamic Currency Conversion(DCC) supports
foreign currency transactions at the SST. This could be performed
by passing one set of currency and amount information to the chip,
and a different set of currency and amount information to the issuer.
This would cause a practical issue with the cryptogram generation
and verification.
This section explains NCR’s solution to the issue, in which the
amount requested is presented to the card issuer in the cardholder’s
native currency. The commission or exchange rate conversion fees
are applied by the SST provider (Acquirer).
The solution uses two transaction requests and replies.
The first Transaction Request is for authorisation only, using the
chip data, and is performed half way through the EMV transaction
flow. No application cryptogram is transmitted and the CAM flags
are marked to show only partial CAM data.
The Acquirer applies the currency conversion and sends back an
Interactive Transaction Response to present options to the
cardholder.
The second Transaction Request is for the converted currency
amount, and includes an application cryptogram and full CAM
data. This request is passed by the Acquirer to the Issuer.

ICC Processing
Figure 7-1
Dynamic Currency Conversion - Partial
CAM Data

ICC Processing
The solution steps for the Transaction steps are explained in the
following table.
Step Summary Detailed description
1 Normal EMV flow to Normal EMV Flow to complete
Complete Application Application selection and
Selection and Initialisation Initialisation.
2 Transaction Request with A transaction request containing
partial EMV/CAM buffer partial EMV/CAM data is sent to
the NDC host. (Acquirer)
As it is only partial EMV/CAM
data no CAM/EMV data would
be expected in the Interactive
Transaction Response.
3 ITR Response (optional) The Acquirer decides that DCC
is possible and sends an
Interactive Transaction Reply
without any CAM data to ask
the cardholder if they wish to
proceed with a DCC transaction.
If host decides that DCC is not
possible it can proceed to step 5
but would not send buffer ‘c’.
4 ITR Response (optional) The SST sends the host the
cardholderʹs response back.
If the cardholder did not want to
proceed with the transaction
then host proceeds to step 5 but
does not send buffer ‘c’.
5 Transaction reply without The Host sends the SST a
CAM data but with Buffer transaction reply without
c EMV/CAM data and supplies
the new currency/amount data
in the ‘c’ buffer.
It sends the terminal to a state
flow branch that completes by
performing GENAC processing.

ICC Processing
Step Summary Detailed description
6 Terminal updates objects The state flow proceeds to a set
based on Buffer c and ICC transaction data state to set
completes EMV up the currency and amount
transaction to GENAC 1 objects and then onto a
transaction request state set to
include the CAM Buffer.
This will cause the EMV
transaction to proceed up to the
completion of GENAC 1. The
Host must check for transaction
declines from the issuer, and for
errors.
7 Transaction reply with The terminal sends a transaction
EMV/CAM data request message with
EMV/CAM data to the NDC
host but with the new currency
and amount information.
8 Acquirer presents The acquirer presents the EMV
Transaction to Issuer based transaction to the issuer
for approval.
9 Issuer provides response Issuer responds to acquirer with
to acquirer transaction decision.
10 Transaction reply with Acquirer replies to terminal with
EMV/CAM data Transaction reply containing the
EMV response data from the
issuer.
11 Transaction Completes Terminal completes the
transaction.
This approach makes use of the following features:
● Configuration of the terminal to send a partial CAM buffer at
step 2 see “Transaction Request” in Chapter 4, “Terminal to
Central Messages”.
● The transaction data object buffer is updated with new amount
and currency information at step 5, see “Field bc ‐ Transaction
Data Objects Buffer” in Chapter 5, “Central to Terminal
Messages”.
● The Set ICC Transaction Data state is used to update the EMV
transaction objects for the new currency and amount at step 6
see “Set ICC Transaction Data” in Chapter 2, “State Tables”.

ICC Processing
Error Handling
Error Handling 7
If the error being reported is due to a hardware‐based failure,
standard NDC error processing is applied for error reporting to
Central and the journal.
Note: A reported hardware fault may not always be due to a fault
with the terminal, as the error may correspond to a terminal to ICC
interaction where the card hardware is faulty (for example, dirty
chip contacts).
When a fatal hardware fault occurs, the SCRW hardware is
re‐initialised and the card is returned to the MCRW. If the
re‐initialisation fails, error handling is performed again.
When a non‐fatal hardware fault occurs, the ICC is powered down
and returned to the MCRW.
All ICC processing errors (hardware and application errors) are
reported to Central in solicited/unsolicited status messages.
For the ICC application error message format, see “ICC Application
Solicited/ Unsolicited Error Message” in Chapter 4, “Terminal to
Central Messages”. For the journalled error format, see “ICC
Application Journal Error Message” in this chapter.
Additional ICC application data may also be sent when a solicited
device status message is sent. See “Issuer Script Results and
Completion Data” in Chapter 4, “Terminal to Central Messages”.
Fake ICC application errors can be generated in the following
Fake ICC Application circumstances.
Errors 7
General Command Errors 7
A fake ICC application error can result if:
● BER‐TLV formatting is not correct on any data returned from
the card
● mandatory objects are not returned in response to a card, unless
EMV allows the transaction to continue
● the incorrect template is returned by the card
● some returned objects, such as the Application File Locator
(AFL) data object, have illegal values or are incorrectly
formatted.
These errors contain the command and response data relating to the
command, but with the Status Words changed to 82 81, to mean
‘Part of returned data may be corrupted’.

ICC Processing
Error Handling
Specific Command Errors 7
If an attempt to power‐up the card fails a fake MCRW hardware
error is generated with Transaction/ Device Status = 0x09, Error
Severity = 0x02, MStatus = 0x54 and MData = 0x70 0x20 0x00 0x0C
0x03.
If one of the Generate Application Cryptograms (GENACs) returns
either an Application Authorisation Referral (AAR) or a cryptogram
higher than that requested, a fake error is generated containing the
command and response data relating to the command, but with the
Status Words set to 63 00 to mean ‘Authentication failure’.
Higher Level Errors 7
The following errors do not relate to any specific EMV command,
but relate to a stage in the EMV Processing.
Error During Search for Usable Applications If no usable 7
applications can be found on the card then a fake ‘File not found’
error is generated, with CLA = 0x00, INS = 0xA4, P1 = 0x04, P2 =
0x00, Lc = 0x00, Le = 0x00, SW1 = 0x6A and SW2 = 0x82.
If subsequent removal of applications from the candidate list causes
the list to become empty, the same fake ‘File not found’ error is sent.
Generic Fake Read Record Error If any of the following 7
conditions occur:
● Application Expiry/Effective Date is incorrectly formatted or an
invalid date, for example 30 February
● a mandatory object (for example, CDOL1, CDOL2, Application
PAN, Application Expiry date) is missing from the card, or has a
length of zero
● the Track 2 equivalent data object has not been returned by the
card, depending on the version of the EMV software and
configuration
● incorrect formatting of any of the following objects: Application
currency code, Application version number, CVM list,
IAC‐denial, Issuer Code table Index, Issuer Country code,
Language Preference
● the Track 2 consistency check is enabled, there is a MasterCard
AID and the ICC PAN or ICC Expiry date does not match the
encoded ICC Track 2 equivalent data
then a ‘Part of returned data may be corrupted’ fake error is
generated, with CLA = 0x00, INS = 0xB2, P1 = 0x00, P2 = 0x04, Lc =
0x00, Le = 0x00, SW1 = 0x62 and SW2 = 0x81.

ICC Processing
Error Handling
Script Processing Errors/GENAC2 Errors If any of the following 7
events occur while processing the host (Central) response:
● issuer script processing suffers an ICC application level error
which results in a script failing to complete successfully, and the
‘Enhanced Configuration Parameter Load’ option number ‘69’
either has no value or has a value in which bit 3 is not set, or
● issuer script processing encounters an incorrectly formatted
script template, command or identifier, and the ‘Enhanced
Configuration Parameter Load’ option number ‘69’ either has no
value or has a value in which bit 3 is not set, or
● the ICC ʹGENERATE ACʹ command requests a ʹTCʹ (Transaction
Certificate), but does not get a ʹTCʹ in the command response
then, if no solicited status message has been sent to the host since
these events, a fake solicited ICC application level error is generated
with CLA = 0xFF, INS = 0xFF, P1 = 0xFF, P2 = 0xFF, Lc = 0x00, Le =
0x00, SW1 = 0xFF and SW2 = 0xFF.
Error processing is performed, causing the fake ICC application
level error to be sent as a solicited status message to the host. A new
response without CAM data is awaited.

ICC Processing
ICC Application Journal Error Message
ICC Application Journal Error
Message 7
When an ICC application level error occurs, an error message is
printed to the journal in the format given in the table below. This
enables diagnostic analysis of the error that occurred.
Number of
Field Value Description
Characters
1 5 ‘SMART’ Identifier that this is a smart card error print (Reserved screen U0073).
1 0x20 ASCII space character.
2 3 ‘CAM’ or ‘S&S’ Application ID (AID) of application selected when command failed.
ʹCAMʹ ‐ CAM
ʹS&Sʹ ‐ AID not selected.
3 8 dd/mm/yy Transaction start date in day/month/year format.
4 5 hh:mm Transaction start time in hours:minutes format.
5 5 nnnn+ or nnnn Transaction Sequence Number in ASCII decimal format (nnnn).
If no Transaction Request has been sent since state number ʹ000ʹ was
processed, an ASCII plus sign (‘+’, 0x2B) is appended to the end of the
sequence number. Otherwise, an ASCII space (0x20) is appended.
1 0x0D ASCII new line.
6 Var. ASCII The PAN of the current card and application. This will be taken from

(up to 19) the ICC tag 0x5A object, or if this is not yet available, from the
magnetic track data via the FIT.
For security reasons all data is replaced by a “*” character, with the
exception of the first 4 digits and the last 4 digits.
If this field is not available, the text
'**** CARD DETAILS UNKNOWN ****' is used. This text is held in
reserved screen ʹU0074ʹ.

ICC Processing
Number of
Characters
7 Var. ASCII AID of the selected application when the command failed.

(up to 32)
32 characters of ASCII hex (16‐byte AID value).
If an AID was not selected, this field will contain the text
'**** AID NOT SELECTED ****'. This text is held in reserved
screen ʹU0075ʹ.
8 2 nn CLA = Class of instruction of the command that failed, in ASCII hex.
9 2 nn INS = Instruction of the command that failed, in ASCII hex.
10 2 nn P1 = Parameter 1 of the command that failed, in ASCII hex.
11 2 nn P2 = Parameter 2 of the command that failed, in ASCII hex.
12 2 nn Lc = Length of the command data for the command that failed, in
ASCII hex.
13 2 nn Le = Length of the expected response for the command that failed, in
ASCII hex.
14 2 nn SW1 = Status word 1 indicating why the command failed, in ASCII
hex.
15 2 nn SW2 = Status word 2 indicating why the command failed, in ASCII
hex.

ICC Processing
When a card is inserted and fails during CAM processing due to an
Journal Print Examples 7
error SW1 = 0x62, SW2 = 0x81 on a Get Processing Options
command, an error similar to the following would be printed to the
journal:
SMART CAM 01/02/07 12:00 1234+
1239***********3249
A000000000000012
80 A8 00 00 00 15 62 81
When a card is inserted and fails during ICC initialisation
processing due to an error SW1 = 0x62, SW2 = 0x81 on a SELECT
command, using an AID 5 bytes long and performed because of a
ʹBad Readʹ, an error similar to the following would be printed to the
journal:
SMART S&S 01/02/07 12:00 1234+
**** CARD DETAILS UNKNOWN ****
**** AID NOT SELECTED ****
00 A4 04 00 05 00 62 81
The reserved screens associated with the ‘EMV/CAM2 Exits for
Reserved Screens 7
APTRA Advance NDC’ product are grouped as ‘U’ reserved
screens. For details of the ‘U’ reserved screens, see Appendix E,
“EMV ICC Reserved Screens”.
For a list of the other reserved screens used by APTRA Advance
NDC see Appendix A in the APTRA Advance NDC, Reference
Manual.

ICC Processing
Offline Decline Journal Message
Offline Decline Journal Message 7
When an application is declined by either the terminal requesting or
receiving an Application Authentication Cryptogram (AAC) from
the first Generate Application Cryptogram command, the following
information is traced to the journal.
Number of
Characters
1 5 ‘SMART’ Identifier that this is a smart card error print (Reserved screen U0073).
2 3 ‘CAM’ Application ID (AID) of application selected when command failed.
Always CAM.
3 8 dd/mm/yy Transaction start date in day/month/year format.
4 5 hh:mm Transaction start time in hours:minutes format.
5 5 nnnn+ or nnnn Transaction Sequence Number in ASCII decimal format (nnnn).
If no Transaction Request has been sent since state number ʹ000ʹ was
processed, an ASCII plus sign (‘+’, 0x2B) is appended to the end of the
sequence number. Otherwise, an ASCII space (0x20) is appended.
6 Var. ASCII The PAN of the current card/application. This will be taken from the

(up to 19) ICC tag 0x5A object, or if this is not yet available, from the magnetic
track data via the FIT.
For security reasons all data will be replaced by a ʺ*ʺ character with the
exception of the first 4 and the last 4 digits.
If this field is not available then the text ʹ**** CARD DETAILS
UNKNOWN ****ʹ will be used. This text is held in reserved screen
ʹU0074ʹ
7 Var. ASCII AID of the selected application when the command failed.

(up to 32)
Up to 32 characters of ASCII hex (16‐byte AID value).

ICC Processing
Number of
Characters
8 Var. ‘DECLINED Identifies that this is a denied offline print, using text from reserved

OFFLINE’ screen ‘U0076’. If ‘U0076’ does not exist or its contents are empty, the
default string ‘DECLINED OFFLINE’ is used.
9 Var. ASCII Hex ASCII representation of EMV tag. See Notes 1, 2 and 3.
10 Var. ASCII Hex ASCII representation of object length. See Notes 1 and 2.
11 Var. ASCII Hex ASCII representation of object value. See Notes 1 and 2.
Note 1: Fields 9, 10, 11 are repeated for each data object which has
been requested to be printed, and is present in the system.
Note 2: The total length of fields 9, 10, and 11 is restricted to 40
characters. Only the first 40 characters are printed.
Note 3: For the Terminal Action Code Denial object the string
’TACD’ is printed instead.
An example offline decline journal trace is shown below.
Example Journal Trace 7
SMART CAM 01/02/07 12:00 1234+

1239**********3249
A000000000000012
DECLINED OFFLINE
5A 09 1239*************32491
5F34 01 **
95 05 80108000
9F0E 05 0050000040
TACD 05 0000000000
9B 02 0840
82 02 5C00
5F24 03 ******
9F10 07 06010A03A0B800

ICC Processing
The default objects which are printed are listed below.
Default Traced Objects 7
Object Tag
Primary Application Number ‐ See Note 1 5A
Application PAN Sequence Number ‐ See 5F34
Note 3
Terminal Verification Results 95
Issuer Action Code Denial 9F0E
Terminal Action Code Denial ‐ See Note 2 N/A
Transaction Status Indicator 9B
Application Interchange Profile 82
Application Expiry Date ‐ See Note 3 5F24
Application Effective Date 5F25
Transaction Type 9C
Application Usage Control 9F07
Amount Authorised 9F02
CVM Results 9F34
Application Cryptogram 9F26
Application Cryptogram Information Data 9F27
Application Transaction Counter 9F36
Issuer Application Data 9F10
Note 1: For security reasons, all but the first and last 4 characters
within the PAN are replaced with an asterisk ‘*’. This can be
disabled via the ʺDisable PCI Maskʺ registry value, see “Tracing
Mechanisms” on page 1‐14.
Note 2: ‘TACD 05 XXXXXXXXXX’ is printed, where XX is the value
the host downloaded in the Terminal Acceptable AID table.
Note 3: ‘For security reasons the value field will be replaced by
ʹ*ʹ.This can be disabled via the ʺDisable PCI Maskʺ registry value.
These objects can be overridden using the registry key
Changing Traced Objects 7
\HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\EMV EXITS
\Offline Decline\Tag list. The registry entry should be a
String value and contain a comma‐separated list of tags for printing.

ICC Processing
Any object which is not known by the terminal is not printed. If the
registry key is present but contains an empty string, the trace header
is printed on its own without any objects.
If the Terminal Action Code Denial object is required, the string
‘TACD’ should be used in the comma‐separated list.
If the PAN is requested, all but the first four and last four data
values are replaced with an asterisk ‘*’ for security reasons. This can
be disabled via the ʺDisable PCI Maskʺ registry value.
If the Track 2 equivalent data object is requested, all but the first
four characters at the start, and the four characters before the first
field separator, are replaced with a ‘*’ character. Should no field
separator exist, the last four characters of the data value remain
unchanged. This can be disabled via the ʺDisable PCI Maskʺ registry
value.
For security reasons the values of the following Ber‐TLV objects will
not be traced to the Journal. Each byte of the value field will be
replace with ʹ*ʹ. This can be disabled via the ʺDisable PCI Maskʺ
registry value.
Tag Name Tag
Track2 Equivalent Data 57
Track1 Discretionary Data 9F1F
Track2 Discretionary Data 9F20
Application Primary Account 5A (First and last 4 characters will
Number be traced)
Application Primary Account 5F34
Number Sequence Number
Cardholder Name 5F20
Cardholder Name Extended 9F0B
International Bank Account 5F53
Number
Transaction PIN 99
Unpredictable Number 9F37
Application Expiry date 5F24
Service Code 5F30
This tracing is enabled by default; however, it can be disabled using
Disabling Offline Decline the registry. If the registry key \HKEY_LOCAL_MACHINE\
Journal Tracing 7
SOFTWARE\NCR\APTRA\EMV EXITS\Offline Decline\

ICC Processing
Disable Print is created as a DWORD with a non‐zero value, the
offline decline journal trace will not take place.

ICC Processing
Extended Journal Tracing
Extended Journal Tracing 7
The Aptra Advance NDC Extended Journal option can be used to
trigger journalling of key events during an EMV transaction. To
learn how to set the option, see the ʺJOURNAL LEVEL Optionʺ in
the APTRA Advance NDC, Supervisor’s Guide.
The following table shows the trace messages, the reserved screen
number containing the trace data, when they will be traced, any
dynamic information traced, and at which AANDC or EMV Exits
trace level the trace will be performed. Trace level 0 means no trace
and level 4 is maximum trace. Trace level 4 is only available by
configuring the registry value
\HKEY_LOCAL_MACHINE\SOFTWARE\NCR\ADVANCE
NDC\EMVJOURNALLEVEL to value 4 and only if the AANDC level is
set to 3. For other settings the EMV Exits trace level will take effect if
it is less than the AANDC trace level, otherwise the AANDC trace
level will take effect.
Trace
Trace Screen Detail
Level
CHIP NOT U0080 Traced when no attempt 3

ATTEMPTED has been made to stage
and power‐on the chip in
the ICC Begin ICC
Initialisation state.
ATR RECEIVED T=* U0081 Traced when a valid ATR 3

has been received from
the chip. The first ʺ*ʺ in
the screen will be
replaced with either a ʹ0ʹ
or ʹ1ʹ based on the
protocol defined in the
ATR.
CANDIDATE LIST U0082 Traced once the 4

*APPS candidate list has been
successfully built. The
first ʺ*ʺ in the screen will
be replaced with the
number of usable
applications in the
candidate list.

ICC Processing
Extended Journal Tracing
Trace
Trace Screen Detail
Level
APPLICATION U0083 Traced prior to the 4

SELECTED issuance of the FINAL
XX XX XX XX XX XX SELECT command. The
XX XX AID value of the
application about to be
selected will be traced on
the following journal line.
GENAC 1 : * U0084 Traced on successful 2

completion of the 1st
Generate Application
Cryptogram command.
The first ʹ*ʹ in the screen
will be replaced with
either ʺAACʺ or ʺARQCʺ
based on the Cryptogram
returned by the
command.
APP NOT USABLE U0085 Traced when an 4

application which was
selected has been found
not to usable.
PROCESSING * U0086 Traced prior to the start 4

SCRIPT of processing the Issuer
Scripts. The first ʹ*ʹ will be
replaced with either 71 or
72 depending on the
script type. Only if a
script is received of that
type will the tracing be
performed
GENAC 2 : * U0087 Traced on successful 2

completion of the 2nd
Generate Application
Cryptogram command.
The first ʹ*ʹ in the screen
will be replaced with
either ʺAACʺ or ʺTCʺ
based on the Cryptogram
returned by the
command.

ICC Processing
ICC Processing Termination
ICC Processing Termination 7
When the NDC processing indicates that a card is to be returned to
the cardholder or captured, then if ICC initialisation processing is
being performed in parallel it is terminated at the earliest
opportunity.
Once ICC application completion processing is concluded, the card
is returned to the MCRW so that the capture/eject can be performed.
As part of this termination process the terminal may issue a
Generate Application Cryptogram (GENAC) command to complete
the transaction with the chip. This is usually required during an
EMV transaction when the terminal times out waiting for a host
response.
The terminal can be configured to send an unsolicited message
when this GENAC command has been issued. By default no
unsolicited message will be sent.
To enable the message to be sent a DWORD registry value
EXITS\Closure Reversal must be created and set to a non‐zero
value.
This unsolicited message will be formatted the same as the ʺICC
Application Solicited/ Unsolicited Error Messageʺ and contain the
GENAC commandʹs CLA, INS, P1, P2 Lc, Le fields , the good Status
words of 90 00 and, if required via option digit 69, the full command
and response data.
If completion data has been configured then this will also be
included in the message formatted the same as the ʺIssuer Script
Results and Completion Dataʺ.
This completion data will not update the completion data sent in the
Last Transaction Status Information buffer of the transaction
request. The Last Transaction Status Information buffer will always
contain the completion data of the last solicited response to the last
transaction reply.

ICC Processing
Authorisation Response Codes
Authorisation Response Codes 7
The Authorisation Response Code is sent in a Transaction Reply
message as part of the Smart Card Data buffer. The value contained
in this field determines how the terminal completes the transaction
with the card. The following sub‐sections describe the various ways
in which the terminal may be configured to process different values
of the Authorisation Response Code.
Normally only an Authorisation Response Code with a value of 30
Additional Approval 30 will result in the terminal requesting an Approval from the card
Response Codes 7
at the second generate application cryptogram command. See
“Transaction Reply” on page 5‐26.
It is possible to set additional approval Authorisation Response
Codes. These can be configured on either an application by
application basis or for all terminal acceptable applications.
To add additional approval Authorisation Response Codes for all
terminal acceptable applications the String type registry value
\HKEY_LOCAL_MACHINE\NCR\APTRA\EMV
Exits\ARC\default must exist.
To define an additional approval Authorisation Response Code for
a specific application then the AID of that application should be
used as the String type registry value name. This value will be
named in the format \HKEY_LOCAL_MACHINE\NCR\APTRA\EMV
Exits\ARC\<AID VALUE> where <AID VALUE> is the
hexadecimal representation of the Application’s AID value for
example ʺA000000300ʺ.
For the registry application specific value to be used it must have an
even number of characters and a minimum length of 10.
If the cardʹs application AID is longer than the registry value name
but the two are identical over the length of the registry value name
then the data of the registry value will be used.
Each additional approval Authorisation Response Code should be
listed as a data value of one of the registry values. The code must be
specified as a 4 digit string as it is received from the host.
Multiple values can be supplied and should be separated by a
comma, for example 5132, 6721. A single response code example is
3131.

ICC Processing
By default no validation is performed on the value contained within
Strict Authorisation the Authorisation Response Code field of the Transaction Reply
Response Code Validation 7
message. Any object value contained within the Transaction Reply
message atc2 field (see “Transaction Reply” on page 5‐26) will be
accepted and passed to the card, if the card requests it.
The terminal can be configured to send a Solicited Status
(Command Reject or B97 Specific Command Reject) message to
Transaction Reply messages that contain Authorisation Response
Code values which do not comply to the alphanumeric format.
To enable this check the DWORD registry value
\HKEY_LOCAL_MACHINE\NCR\APTRA\EMV Exits\Strict ARC
Check must exist with a non‐zero value.
Normally all Authorisation Response Code values are assumed to
Invalid Authorisation be valid and will be accepted by the terminal.
Response Codes 7
It is possible to set a list of approval Authorisation Response Codes
which are consider invalid and will result in a Solicited Status
(Command Reject or B97 Specific Command Reject) message if
received by the terminal. These can be configured on either an
application by application basis or for all terminal acceptable
applications.
To add invalid approval Authorisation Response Codes for all
terminal acceptable applications the String type registry value
\HKEY_LOCAL_MACHINE\NCR\APTRA\EMV Exits\Invalid
ARC\default must exist.
To define invalid approval Authorisation Response Code for a
specific application then the AID of that application should be used
as the String type registry value name. This value will be named in
the format \HKEY_LOCAL_MACHINE\NCR\APTRA\EMV
Exits\ARC\<AID VALUE> where <AID VALUE> is the
hexadecimal representation of the Application’s AID value for
example ʺA000000301ʺ
For the registry application specific value to be used it must have an
even number of characters and a minimum length of 10.
If the cardʹs application AID is longer than the registry value name
but the two are identical over the length of the registry value name
then the data of the registry value will be used.
Each invalid approval Authorisation Response Code should be
listed as a data value of one of the registry values. The code must be
specified as a 4 digit string as it is received from the host.

ICC Processing
Multiple values can be supplied and should be separated by a
comma, for example 5050, 6720. A single invalid response code is
3133.

ICC Processing
Windows Registry Settings
Windows Registry Settings 7
Some data fields can be configured at the terminal using the
Windows Registry. These include the Track 2 data buffer.
Table 7‐1 provides a reference for all the settings which may be
configured using the Windows Registry. All registry keys exist
within the path
\HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\EMV EXITS
Table 7-1
Key Value Value Data
Decline nnn STRING Next State Number if the current Tx

request state number matches nnn
default STRING Next State Number if the current Tx
request state is not found as a registry value
Enable for Error DWORD non‐zero ‐ enables terminal based
decline for error cases
DebugLog debugTrace DWORD non‐zero ‐ enables command and

response tracing
Disable PCI Mask DWORD non‐zero ‐ disables the masking of
security sensitive EMV objects in the logs
dump ctrl trace DWORD 0 or 1 ‐ Chip I/O
objects DWORD 0 or 1 ‐ Object Store Tracing
Offline Decline Disable Print DWORD non‐zero
Tag list STRING Comma Separated Value or ʺʺ
None TRACK_CHECK_DISABLED DWORD non‐zero

Track 2 equivalent data check is performed
None INTERAC_CAND_List DWORD non‐zero

Canadian List Filtering is performed
None DISABLE EARLY TAA DWORD non‐zero

Disables Terminal Action Analysis
TRM Default Floor Limit DWORD 0 ‐ means not set by the terminal
Check AIP DWORD non‐zero ‐ uses the card’s AIP setting
None Retain Download DWORD non‐zero ‐ enables automatic creation

of the EMVDATA.DAT file

ICC Processing
None Enable Transaction Reply Check DWORD non‐zero ‐ enables a Solicited Status

(Command Reject or Specific Command Reject
B99), see Command Rejects
None DTDOL STRING Allows the default TDOL value used

by the terminal to be overridden. Format the
data value as a hexadecimal ASCII string, for
example 9F08029F0206
Power On Disable Error DWORD non‐zero
Consecutive Failure Threshold DWORD non‐zero
reinitialise state\default Reinit method DWORD 0 or 1

when the state number See the ICC Re‐Initialise State
for the re‐initialisation
state cannot be found in
the registry
chip power cycle DWORD 0, 1, 2 or 3
See the ICC Re‐Initialise State
Retain Terminal Objects DWORD 0 ‐ disable or 1 ‐ enable
reinitialise state\<xxx> Reinit method DWORD 0 or 1

where xxx is the state See the ICC Re‐Initialise State
number for the
re‐initialisation state
chip power cycle DWORD 0, 1, 2 or 3
See the ICC Re‐Initialise State
Retain Terminal Objects DWORD 0 ‐ disable or 1 ‐ enable
TAAT/<AID value> f18 Allows the local setting of the equivalent data

where <AID value> is for EMV Customisation Message field f18 if the
the Application’s AID host has not downloaded a value
value in hexadecimal
f19 Allows the local setting of the equivalent data
for EMV Customisation Message field f19 if the
host has not downloaded a value

ICC Processing
None Strict ARC Check DWORD non‐zero ‐ enables the checking of

ARC default STRING ‐ a comma separated list of additional

4‐digit hexadecimal approval Authorisation
Response Codes. This registry value is used for
all terminal applications
<AID value> where <AID STRING ‐ a comma separated list of 4‐digit

value> is the Application’s AID hexadecimal approval Authorisation Response
value in hexadecimal Codes. This registry value is used for the
application specified by the value name, or one
which matches the value name.
Invalid ARC default STRING ‐ a comma separated list of 4‐digit

hexadecimal invalid Authorisation Response
Codes. This registry value is used for all
terminal applications
<AID value> where <AID STRING ‐ a comma separated list of 4‐digit

value> is the Application’s AID hexadecimal invalid Authorisation Response
value in hexadecimal Codes. This registry value is used for the
application specified by the value name, or one
which matches the value name.
One registry setting,
\HKEY_LOCAL_MACHINE\SOFTWARE\NCR\APTRA\Advance
NDC\EMVJOURNALLEVEL is applicable directly to Advance NDC
and works in conjunction with an Advance NDC Supervisor setting.
Its applicable range is a DWORD value 0 to 4.

Table of Contents
Appendix A
Overview A‐1
Configuration Data A‐2
State Table A‐2
Financial Institution Table (FIT) A‐4
Dispenser Currency Cassette Mapping Table A‐4
Enhanced Configuration ‐ Option Digits A‐4
Enhanced Configuration ‐ Timers A‐4
ICC Currency Data Objects Table A‐4
ICC Transaction Data Objects Table A‐5
ICC Language Support Table A‐5
ICC Terminal Data Objects Table A‐5
ICC Terminal Acceptable Application IDs (AIDs) Table A‐6
Cardholder Screens A‐8
APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual
Table of Contents
APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual
A
Overview
Overview A
This appendix provides example configuration data, showing the
types of data you may include in the download to the terminal.
The example data listed here consists of the following:
● State Table
● Financial Institution Table (FIT)
● Dispenser Currency Cassette Mapping Table
● Enhanced Configuration ‐ Option Digits
● Enhanced Configuration ‐ Timers
● ICC Terminal Data Objects Table
● ICC Terminal Acceptable Application IDs (AIDs) Table
● Cardholder Screens.
Note: The configuration data you use in your download will
invariably be different from that shown. The following example
data is provided simply to illustrate the types of data which can be
included in the download. This example configuration data does
not necessarily reflect the data used in the base configuration state
flow in Appendix G, “State Flow Diagram”.
APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual A-1
Configuration Data
Configuration Data A
State Table A
State Type 2 3 4 5 6 7 8 9
000 A 010 005 013 002 002 008 001 035
005 K 010 015 015 015 020 015 255 255
010 + 025 055 001 001 000 000 000 000
015 + 040 055 001 000 000 000 000 000
020 J 000 000 014 054 000 000 000 000
025 D 240 000 002 001 000 000 000 000
035 + 040 055 000 000 000 000 000 000
040 , 015 100 050 050 045 045 000 000
045 J 000 000 016 054 000 000 000 000
050 J 000 000 017 054 000 000 000 000
055 D 085 000 003 000 000 000 000 000
065 Y 018 110 080 240 070 111 102 075
070 Z 000 001 002 000 000 003 004 000
075 Z 000 000 100 000 000 200 300 000
080 J 000 000 019 054 000 000 000 000
085 K 240 240 240 065 255 065 255 255
100 ‐ 120 105 000 000 000 000 000 000
105 Y 018 110 080 120 070 111 102 075
110 J 000 000 020 054 000 000 000 000
120 . 021 125 130 135 000 000 000 000
125 Z 022 023 024 025 000 000 000 000
130 Z 026 004 027 005 000 000 000 000
135 Z 110 080 155 145 050 000 000 000
145 D 165 002 000 000 000 001 000 000
155 D 165 002 000 000 001 000 000 000
165 / 015 028 029 170 000 000 000 000
170 Z 200 255 180 255 045 045 000 000
180 . 030 125 130 135 000 000 000 000
200 k 000 205 000 002 002 002 001 255
205 K 220 220 220 220 020 220 255 255
220 B 031 110 080 255 235 032 245 003
230 Z 000 000 012 011 000 000 000 000
235 J 000 000 033 054 000 000 000 000
240 B 034 110 080 255 235 035 245 003
245 K 280 280 260 250 255 250 255 255
250 Y 036 110 080 295 230 023 012 000
260 Y 037 110 080 290 265 002 006 000
A-2 APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual
Configuration Data
265 Z 000 001 002 000 000 000 000 000

280 Y 038 110 080 290 285 002 014 000
285 Z 000 001 002 003 000 000 000 000
290 W 255 250 300 300 255 255 255 255
295 W 255 255 335 340 255 255 255 255
300 / 015 028 029 305 000 000 000 000
305 Z 310 310 310 310 310 310 310 000
310 ? 330 000 001 000 000 000 000 000
315 / 015 028 029 320 000 000 000 000
320 Z 325 325 325 325 325 325 325 000
325 ? 330 001 002 030 000 000 000 000
330 I 015 350 001 000 001 001 129 345
335 F 039 110 080 355 255 255 255 040
340 F 042 110 080 375 255 255 255 043
345 Z 000 000 000 000 000 000 001 000
350 J 000 000 016 054 000 000 000 000
355 G 315 360 000 000 002 001 003 000
360 F 041 110 080 355 255 255 255 040
375 G 385 380 000 000 002 002 003 000
380 F 044 110 080 375 255 255 255 043
385 / 015 028 029 390 000 000 000 000
390 Z 395 395 395 395 395 395 395 000
395 ? 330 002 002 030 000 000 000 000
400 Y 045 110 080 440 405 000 012 000
405 Z 000 000 000 000 000 000 000 000
420 Y 045 110 080 430 425 000 012 000
425 Z 000 000 000 000 000 000 000 000
430 W 255 255 460 435 255 255 255 255
435 J 000 000 047 054 000 000 000 000
440 W 000 000 445 435 255 255 255 255
445 Y 046 110 080 455 450 000 012 000
450 Z 000 000 000 000 000 000 000 000
455 W 255 255 460 120 255 255 255 255
460 ; 245 245 000 000 000 000 000 000
465 J 000 000 048 054 000 000 000 000
470 J 052 000 053 054 000 000 000 000
Configuration Data
Financial Institution Table
(FIT) A
FIT PIDDX PFIID PSTDX PAGDX PMXPN PCKLN PINPD PANDX PANLN
000 000 015255255255255 000 000 132 000 015 000 176
001 000 031255255255255 001 000 132 000 015 000 176
002 000 047255255255255 002 000 132 000 015 000 176
003 000 063255255255255 003 000 132 000 015 000 176
004 000 070255255255255 004 000 132 000 015 000 176
005 000 255255255255255 005 000 132 000 015 000 176
Dispenser Currency
Cassette Mapping Table A
CURR TYPE VALUE CURR TYPE VALUE CURR TYPE VALUE CURR TYPE VALUE
04 01 3 00005 01 4 00010 02 1 00005 02 2 00010
Enhanced Configuration ‐
Option Digits A
03 002 04 040 05 001 12 001 15 001 16 255 17 225 31 001 69 003 70 001
Enhanced Configuration ‐
Timers A
00 010 01 010 02 003 03 255 05 005 07 005 09 005
ICC Currency Data Objects
Table A
T L T L V T L V T L T L V T L V
02 01 77 09 5F2A 02 0978 5F36 01 02 02 77 09 5F2A 02 0826 5F36 01 02
Configuration Data
ICC Transaction Data
Objects Table A
T L T L V T L T L V
02 01 77 03 9C 01 01 02 77 03 9C 01 02
ICC Language Support
Table A
SCR AUD OPC OPC SCR AUD OPC OPC SCR AUD OPC OPC SCR AUD OPC OPC
04 en 000 001 012 @A@ cy 100 002 012 @B@ de 200 005 012 @C@ fr 300 006 012 @D@
ICC Terminal Data Objects
Table A
T L T L V T L V T L V
77 0E 9F1A 02 0826 9F35 01 14 9F53 02 6566
Configuration Data
ICC Terminal Acceptable
Application IDs (AIDs)
Table A
Primary AID Transaction Solicited Status

Secondary AID(s)
Request Message
Default
Min. Max. TAC No. of No. of
No. Length Value Lbl. Type Obj. Obj. Qty. Len. Value
Ver. Ver. Denial Obj. Obj.
Len.
00 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 01 06 A0000

080001 000 75A5F 00002
349F2 01
79F26
9F108
29F36
8C
01 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

080002 000 75A5F
349F2
79F26
9F108
29F36
8C
02 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 02 07 A0000

070001 000 75A5F 00003
349F2 1010
79F26
9F108 07 A0000
29F36 00004
8C 1010
03 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 02 07 A0000

031010 000 75A5F 00003
349F2 2010
79F26
9F108 07 A0000
29F36 00003
8C 3010
04 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

032010 000 75A5F
349F2
79F26
9F108
29F36
8C
05 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

033010 000 75A5F
349F2
79F26
9F108
29F36
8C
Configuration Data
Primary AID Transaction Solicited Status

Secondary AID(s)
Request Message
Default
Min. Max. TAC No. of No. of
No. Length Value Lbl. Type Obj. Obj. Qty. Len. Value
Ver. Ver. Denial Obj. Obj.
Len.
06 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 02 07 A0000

041010 000 75A5F 00004
349F2 6000
79F26
9F108 07 A0000
29F36 00004
8C 3060
07 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

046000 000 75A5F
349F2
79F26
9F108
29F36
8C
08 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

043060 000 75A5F
349F2
79F26
9F108
29F36
8C
09 07 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

041030 000 75A5F
349F2
79F26
9F108
29F36
8C
10 08 A0000000 00 CAM 0000 0001 0000000 0A 9F065 00 ‐ 00 ‐ ‐

0201 000 75A5F
349F2
79F26
9F108
29F36
8C
Configuration Data
Cardholder Screens A
000<FF>000EN<SI>ADYOU HAVE RUN OUT OF TIME<SI>CCWOULD YOU LIKE MORE TIME?<SI>F;YES ><SI>I<NO >
001<FF><SI>@D001EN<SI>GIOUT OF SERVICE
002<FF><SI>@D002EN<SI>EIDUE TO A FAULT<SI>GGUNABLE TO CONTINUE<SI>IHPLEASE TAKE CARD
010<SO>011<ESC>[100z<SO>012<ESC>[100z
011<FF>011EN<SI>EFWELCOME TO NCR BANK!<SI>GGPLEASE INSERT CARD
012<FF>012EN<SI>DKNCR BANK<SI>FDHOME OF ICC ENABLED ATMS<SI>HGPLEASE INSERT CARD
013<FF>013EN<SI>EDBAD READ – INVALID CARD!<SI>GHPLEASE TAKE CARD
014<FF>014EN<SI>ECCARD NOT ACCEPTED BY BANK!<SI>GHPLEASE TAKE CARD
015<FF>015EN<SI>EJPLEASE WAIT
016<FF>016EN<SI>EIDUE TO A FAULT<SI>GGUNABLE TO CONTINUE<SI>IHPLEASE TAKE CARD
017<FF>017EN<SI>EEUNABLE TO PROCESS CARD<SI>GHPLEASE TAKE CARD<SI>IBSEEK ASSISTANCE FROM
ISSUER!
018<FF>018EN<SI>BDPLEASE CHOOSE A LANGUAGE<SI>I@ < FRENCH<SI>I7ENGLISH ><SI>L@< GERMAN<SI>L9WELSH
>
019<FF>019EN<SI>EETRANSACTION CANCELLED<SI>GHPLEASE TAKE CARD
020<FF>020EN<SI>EKTIMED OUT!<SI>GHPLEASE TAKE CARD
021<FF>021EN<SI>BAPLEASE SELECT PRODUCT/ACCOUNT:
022<SI>FN&&S&&RJ**************** >&&E
023<SI>IN&&S&&RJ**************** >&&E
024<SI>LN&&S&&RJ**************** >&&E
025<SI>ON&&S&&RJ**************** >&&E
026<SI>O:MORE >
027<SI>O@< BACK
028&&S&&CD****************&&E
030<FF>030EN<SI>ADSORRY CANNOT ACCESS YOUR<SI>BECHOSEN PRODUCT/ACCOUNT<SI>DBPLEASE SELECT AN
ALTERNATIVE
031<FF>031EN<SI>ECPLEASE ENTER YOUR PIN FOR:<SI>GH<SO>029<SI>JN
032<FF>032EN<SI>CIPIN INCORRECT!<SI>ECPLEASE ENTER YOUR PIN FOR:<SI>GH<SO>029<SI>JN
033<FF>033EN<SI>DATOO MANY INCORRECT PIN ENTRIES<SI>GHPLEASE TAKE CARD<SI>JBSEEK ASSISTANCE
FROM ISSUER
034<FF>034EN<SI>EHPLEASE ENTER PIN<SI>JN
035<FF>035EN<SI>CIPIN INCORRECT!<SI>EHPLEASE ENTER PIN<SI>JN
036<FF>036EN<SI>ABPLEASE CHOOSE THE CURRENCY FOR<SI>CFTHIS CASH WITHDRAWAL<SI>L:EURO
><SI>O6STERLING >
037<FF>037EN<SI>CDPLEASE CHOOSE A SERVICE:<SI>I:CASH ><SI>L7BALANCE >
038<FF>038EN<SI>CDPLEASE CHOOSE A SERVICE<SI>I:CASH ><SI>L7BALANCE ><SI>N9MINI-<SI>O5STATEMENT >
039<FF>039EN<SI>DFPLEASE ENTER AMOUNT:
040<SI>IJE *****0.00
041<FF>041EN<SI>BIINVALID AMOUNT<SI>DFPLEASE ENTER AMOUNT:
042<FF>042EN<SI>DFPLEASE ENTER AMOUNT:
043<SI>IJ` *****0.00
044<FF>044EN<SI>BIINVALID AMOUNT<SI>DFPLEASE ENTER AMOUNT:
046<FF>046EN<SI>BGDO YOU WISH TO USE<SI>DDTHE SAME PRODUCT/ACCOUNT<SI>L;YES ><SI>O<NO >
047<FF>047EN<SI>EHPLEASE TAKE CARD<SI>IBTHANK YOU FOR USING NCR BANK
049<SO>050<SO>051
050<FF>050EN<SI>EHPLEASE TAKE CARD<SI>I5AND WAIT FOR YOUR CASH
051<FF>051EN<SI>EHPLEASE TAKE CASH<SI>I6AND WAIT FOR RECEIPT
052<FF>052EN<SI>EDPLEASE TAKE YOUR RECEIPT<SI>IBTHANK YOU FOR USING NCR BANK
053<FF>053EN<SI>CMSORRY!<SI>EAUNABLE TO PROVIDE YOUR RECEIPT<SI>HBTHANK YOU FOR USING NCR BANK
054<FF>054EN<SI>CMSORRY!<SI>EBYOUR CARD HAS BEEN RETAINED,<SI>GEPLEASE SEEK ASSISTANCE
100<SO>000<SI>@D100CY
101<SO>001<SI>@D101CY
102<SO>002<SI>@D102CY
114<SO>014<SI>@@114CY
115<SO>015<SI>@@115CY
116<SO>016<SI>@@116CY
117<SO>017<SI>@@117CY
119<SO>019<SI>@@119CY
120<SO>020<SI>@@120CY
121<SO>021<SI>@@121CY
126<SO>026<SI>O7CY
127<SO>027<SI>OGCY
130<SO>030<SI>@@130CY
131<SO>031<SI>@@131CY<SI>JN
Table of Contents
Appendix B
Overview B‐1
Restrictions B‐2
BER‐TLV Field Size B‐2
Candidate List Size B‐2
Number of Application IDs in Download B‐3
Reading/Writing Magnetic Stripes B‐3
Smart Card Reader/Writer (SCRW) B‐3
Communications Protocols B‐3
Immediate Smart Card Eject B‐3

Table of Contents

B
Overview
Overview B
This appendix summarises some of the restrictions you should be
aware of when performing ICC processing. These include the
following:
● Extended length of command data (Lc)
● Expected length of response data (Le)
● BER‐TLV Field Size
● Candidate List Size
● Number of Application IDs in Download
● Reading/Writing Magnetic Stripes
● Smart Card Reader/Writer (SCRW)
● Communications Protocols
● Immediate Smart Card Eject
APTRA Advance NDC, EMV ICC Reference Manual B-1

Restrictions
Restrictions B
To enable this NDC CAM implementation to be flexible enough to
be used by many financial institutions, the application has been
designed so that major hardware upgrades are not required.
Consequently, the restrictions described in the following sections
apply.
The following restrictions apply to various BER‐TLV field sizes:
BER‐TLV Field Size B
● The object tag field cannot be bigger than two bytes.
● The object length field can have any length, provided the other
restrictions are met.
● The object value field cannot be more than 255 bytes.
The ICC Initialisation task searches the ICC to find applications, in
Candidate List Size B
conjunction with the list of terminal acceptable Application IDs
(AIDs).
The resultant candidate list size is dependent on the number of
terminal acceptable AIDs in the “ICC Terminal Acceptable
Application IDs Table” in Chapter 5, “Central to Terminal
Messages”.
The more searching that the terminal has to perform to find
applications on the ICC, the greater the increase in transaction time.
B-2 APTRA Advance NDC, EMV ICC Reference Manual

Restrictions
The maximum number of Application ID (AID) values that the
Number of Application terminal can support as acceptable AIDs is 256. For more details, see
IDs in Download B
“ICC Terminal Acceptable Application IDs Table” in Chapter 5,
Note: Each of these terminal AID values may have more than one
corresponding ICC AID value during processing. This is because
the terminal AID value may be a partial AID value.
For an MCRW, but not DASH or Smart Dipcard readers, it is a
Reading/Writing Magnetic requirement that all cards that are to be used within the system have
Stripes B
a valid magnetic stripe encoded with at least a start sentinel.
The magnetic stripe must not be updated when the card is staged in
the SCRW as this will result in the terminal resetting.
The application requires an MCRW with an EMV‐type approved
Smart Card Reader/Writer SCRW unit to be installed in the terminal.
(SCRW) B
Some messages within NDC CAM, in particular the Transaction
Communications Request message, have the potential to be longer than some
Protocols B
communications protocols can handle. This depends upon the
communications protocol used, terminal configuration settings and
ICC data values.
NCR strongly advises users to check that the communications
protocol used in their terminal environment meets their
implementation needs, taking into account the terminal
configuration settings and potential ICC data values.
If ICC processing is to be performed during a transaction, state type
Immediate Smart Card ʹAʹ (Card Read) and state type ʹkʹ (Smart FIT Check state) must not
Eject B
be configured via table entry 8 (Card Return Flag) to immediately
eject the card (ʹ000ʹ).
If either of the states is configured to eject the card immediately as
part of their respective processing, the terminal will reset when ICC
processing is performed.
Although a smart dip card reader will not cause a terminal reset, the
card will still be released, preventing ICC processing completion.
APTRA Advance NDC, EMV ICC Reference Manual B-3

Restrictions
B-4 APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Appendix C
Overview C‐1
Advance NDC Documentation C‐2
APTRA Author C‐3
Other Documentation C‐4

Table of Contents

C
Overview
Overview C
This appendix identifies the related NCR and non‐NCR
documentation which this manual supplements, and which you
may find useful when developing your Advance NDC application.
The APTRA Advance NDC documentation is a combination of
on‐line help files and Adobe Portable Document Format (PDF) files.
To read the PDF documentation, you need Adobe Reader installed
on your PC. Adobe Reader can be downloaded from
http://www.adobe.com.
In general, documentation is provided with its respective product.
APTRA Advance NDC, EMV ICC Reference Manual C-1

Advance NDC Documentation
Advance NDC Documentation C
Product Title Format Description
APTRA APTRA Advance NDC, PDF Provides an introduction to Advance NDC,

Advance NDC Overview including overviews of the components
(B006‐6597) contained in the Advance NDC product,
and provided as part of the Advance NDC
Package on CD‐ROM.
APTRA Advance NDC, PDF Describes how to migrate to Advance

Developer’s Guide NDC. It also identifies the functionality
(B006‐6046) offered by Advance NDC and describes
how to enhance it.
APTRA Advance NDC, PDF Describes how to set up the terminal’s local

Supervisor’s Guide configuration parameters, and how to
(B006‐6062) replenish the terminal.
APTRA Advance NDC, PDF Provides application programmers with

Reference Manual reference information for Advance NDC,
(B006‐6180) including States, Screens, and the message
formats between Central and the terminal.
APTRA Advance NDC, PDF Describes the differences between creating

Multi‐Vendor Support an Advance NDC application that runs
Reference Manual only on NCR SSTs (single‐vendor) and one
(B006‐6344) which runs on any vendor’s SST
(multi‐vendor).
APTRA Advance NDC, PDF Describes how to extend the application

Extending the Product using exits, or by introducing new
(B006‐6926) functions.
Advance NDC Help Windows Context‐sensitive help for the Advance

Help NDC Authoring components (excluding
Application Core components).
Advance NDC Application Windows Context‐sensitive help for the Application

Core Help Help Core Authoring components.
C-2 APTRA Advance NDC, EMV ICC Reference Manual

Advance NDC Documentation
If you are unfamiliar with the APTRA Author, you may also find
APTRA Author C
the following documentation provided with Advance NDC useful:
Product Title Format Description
APTRA APTRA Author, User’s Guide PDF Describes how to install and use the

Advance NDC (B006‐6038) APTRA Author and Runtime Components
to design, develop and maintain a
self‐service application.
APTRA Author Help Windows Context‐sensitive help for the Author user

Help interface and authoring errors.
Runtime Core Help Windows Context‐sensitive help for the Runtime

Help Core Authoring components and runtime
errors, which are part of Advance Core
Self‐Service.
GUI Help Windows Context‐sensitive help for the GUI

Help Authoring components, which are part of
Advance Core Self‐Service.
Self‐Service Core Help Windows Context‐sensitive help for the Self‐Service

Help Core Authoring components, which are
part of Advance Core Self‐Service.
ActiveX Help Windows Context‐sensitive help for the ActiveX

Help Authoring components and runtime errors,
which are part of Advance Core
Self‐Service.
Basic Self‐Service Help Windows Context‐sensitive help for the Authoring

Help components provided with Advance Basic
Self‐Service.
ATM Help Windows Context‐sensitive help for the Authoring

Help components and runtime errors provided
with Advance ATM.
Special Self‐Service Help Windows Context‐sensitive help for the Authoring

Help components and runtime errors provided
with Advance Special Self‐Service.

Other Documentation
Other Documentation C
Supplier Title & Version Format Description
EMVCo Book 1 ‐ Application PDF This specification describes the minimum

Independent ICC to Terminal functionality required for ICCs and terminals
All the EMV Interface Requirement 4.2 to ensure correct operation and
specifications interoperability, independent of the
are available application to be used.
from EMVCo at
emvco.com. Book 2 ‐ Security and Key PDF This specification describes the minimum
Management 4.2 security functionality required for ICCs and
terminals to ensure correct operation and
interoperability. Additional requirements and
recommendations are provided for online
communication between ICC and issuer, and
the management of cryptographic keys at
terminal, issuer and payment system level.
Book 3 ‐ Application PDF This specification defines the terminal and ICC

Specification 4.2 procedures necessary for a payment system
transaction in an international interchange
environment.
Book 4 ‐ Cardholder, PDF This specification defines the mandatory,

Attendant, and Acquirer recommended and optional terminal
Interface Requirements 4.2 requirements necessary to support the
acceptance of ICCs in accordance with the
Application Independent ICC to Terminal
Interface Requirements (Book 1), the Security
and Key Management (Book 2) and the
Application Specification (Book 3).
Comité Extensions for Financial PDF or Provides reference information for the CEN

Européen de Services (XFS) Interface DOC XFS specifications. Available from CEN at
Normalisation Specification 2.0 www.cen.eu.
(CEN) (CWA 13449)
Visa Transaction Acceptance Paper Specifies the Visa ICC terminal functions.

International Device Guide Version 2.0
March 2011
MasterCard M/Chip Requirements 11th Paper Specifies how to successfully implement

International June 2010 MasterCard products.
National Federal Information Paper Specifies the Secure Hashing Algorithm

Institute of Processing Standards (SHA‐1).
Standards and Publication (FIPS PUB) 180‐1
Technology ‘Secure Hash Standard’.

Other Documentation
Supplier Title & Version Format Description
International ISO 7811‐1: Identification Paper Specifies the ISO standard embossing for

Standards Cards ‐ Recording Technique cards.
Organisation ‐ Part 1: Embossing
ISO 7811‐2: Identification Paper Specifies the ISO standard magnetic stripes for

Cards ‐ Recording Technique cards.
‐ Part 2: Magnetic Stripe
ISO 7811‐3: Identification Paper Specifies the ISO standard for embossed

Cards ‐ Recording Technique characters on cards.
‐ Part 3: Location of
Embossed Characters on ID‐1
Cards
ISO 7811‐4: Identification Paper Specifies the ISO standard for read only

Cards ‐ Recording Technique magnetic tracks (tracks 1 and 2) on cards.
Read‐Only Magnetic Tracks ‐
Tracks 1 and 2
ISO 7811‐5: Identification Paper Specifies the ISO standard for read/write

Cards ‐ Recording Technique magnetic tracks (track 3) on cards.
Read‐Write Magnetic Tracks ‐
Track 3
ISO 7811‐6: Identification Paper Specifies the ISO standard for the physical

Cards ‐ Part 6: Physical characteristics of cards.
Characteristics
ISO 7816‐1 to 5: Identification Paper Specifies the ISO standard for Integrated

Cards ‐ Integrated Circuit(s) Circuit Cards.
with Contacts ‐ Part 1
through Part 5

Other Documentation

Table of Contents
Installation
Appendix D
Installation
Overview D‐1
Installation Instructions D‐2
Development PC Installation D‐2
Producing a Combined Aggregate D‐2
SST Installation of Combined Aggregate D‐3
Interactive Runtime SST installation D‐3
EMV Exits Control files D‐3
Merging of the Control files D‐4

Table of Contents
Installation

Installation
D
Overview
Overview D
This appendix provides instructions on how to install the
EMV/CAM2 Exits for APTRA Advance NDC product release
03.04.00.
For EMV/CAM2 Exits products prior to this release, see the version
of this document supplied with the product.
APTRA Advance NDC, EMV ICC Reference Manual D-1

Installation
Installation Instructions
Installation Instructions D
The recommended approach is to install EMV Exits for APTRA
Advance NDC onto a development PC, along with APTRA
Advance NDC, and produce a combined EMV Exits and Advance
NDC aggregate for installation on an SST.
To install EMV Exits for Advance NDC on a runtime SST on which
Advance NDC is already present, you can carry out an interactive
SST installation directly.
To install EMV Exits for Advance NDC on a development PC, take
Development PC the following steps:
Installation D
1 Insert the EMV Exits for APTRA Advance NDC CD into the CD
drive.
2 Run the setup.exe file.
3 Follow the instructions selecting Development PC as the target
Environment.
The default path used during installation is:
C:\Program Files\NCR APTRA\MultiVendor EMV Exits for
AANDC
This folder contains sample control files which must be merged into
the standard control files provided by Advance NDC, see section
ʺMerging of the Control filesʺ. This could be done either at the
development PC, see ”Producing a Combined Aggregate”, or at the
SST, see “Interactive Runtime SST installation”.
Also installed in the ʺSSTʺ sub‐directory are the EMV Exits for
APTRA Advance NDC binaries.
To produce a combined Advance NDC and EMV Exits aggregate for
Producing a Combined installation at the SST, open the aggregate builder tool and complete
Aggregate D
the following steps:
1 Import the Advance NDC aggregate.
2 Import the EMV/CAM2 Exits for Advance NDC aggregate.
3 Create a copy of the Advance NDC aggregate and give it a new
name.
D-2 APTRA Advance NDC, EMV ICC Reference Manual

Installation
4 Include the ʺMultiVendor EMV Exits for AANDCʺ component
in the renamed Advance NDC aggregate.
5 Export the renamed aggregate.
6 Merge the Advance NDC and EMV/CAM2 Exits for Advance
NDC control files, see “Merging of the Control files”.
7 Include the merged control files in the renamed aggregate using
the custom.ini file. For more information, refer to Chapter 11,
ʺDelivering an Advance NDC Application to the SSTʺ in the
APTRA Advance NDC, Developerʹs Guide.
The recommended method of installing on a SST is to use the
SST Installation of combined aggregate as follows:
Combined Aggregate D
1 On the SST, run the combined aggregate setup.exe file.
2 Follow the instructions on the screen and select Runtime as the
target environment.
3 Confirm the path to use for installation.
4 Select Finish.
To install EMV Exits for Advance NDC on a runtime SST on which
Interactive Runtime SST Advance NDC is already present, you can follow the instructions
installation D
given in ʺDevelopment Installationʺ on page D‐2, but select Runtime
at step 3.
The EMV Exits control files are not installed on the SST. A manual
merge of the Advance NDC control files with the EMV/CAM2 Exits
for Advance NDC control files must be carried out. The
EMV/CAM2 Exits for Advance NDC control files can be obtained
from a Development PC installation of the product. See the section
ʺMerging of the Control filesʺ for instructions on carrying out the
merge operations.
For the runtime environment the default installation path is
C:\Program Files\NCR APTRA\Advance NDC\EMV Exits
The EMV Exits for Advance NDC control files are installed only by
EMV Exits Control files D
a Development PC installation.
The supplied EMV Exits control files are:
● ʺVCCONTʺ ‐ for the message interceptor definitions.
● ʺMISCONTʺ ‐ for the miscellaneous hook definitions.
APTRA Advance NDC, EMV ICC Reference Manual D-3

Installation
● ʺINICONTʺ ‐ for the various EMV Exits Start of Day hooks.
● ʺSTCONTʺ ‐ for State Table Definitions
Merging of the Control files D
The contents of the EMV Exits for Advance NDC control files must
be pasted to the end of the Advance NDC control file of the same
name using a suitable editor, for example HexEdit, SciTE,
notepad++, or Notepad.
By default Advance NDC has an empty MISCONT and VCCONT
file and so the EMV Exits control files can replace the Advance NDC
versions.
The INITCONT file is used to define the multiple Start of Day hooks
required by this version of EMV Exits. This is not present by default
with Advance NDC.
The contents of the EMV Exits STCONT control file appropriate for
the version of Advance NDC must be appended to the end of the
installed Advance NDC STCONT file.
The merged control files must be placed in ʺC:\Program Files\NCR
APTRA\Advance NDC\Configʺ.
No startapps.vbs updates are required for this version of EMV Exits.
D-4 APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Appendix E
Overview E‐1
‘U’ EMV Smart Card E‐2

Table of Contents

E
Overview
Overview E
The following table shows the default text for the reserved screens
associated with the ‘EMV/CAM2 Exits for APTRA Advance NDC’
product.
‘x’, or ‘*’ represents those positions that are edited by the terminal
before the screen is displayed or printed.
For each reserved screen, the table identifies the screen number and
the position of the text within the screen data. Text position is
calculated by the row and column positions for each screen.
For the other reserved screens used by Advance NDC, see the
appendix in the APTRA Advance NDC, Reference Manual.
APTRA Advance NDC, EMV ICC Reference Manual E-1

‘U’ EMV Smart Card
‘U’ EMV Smart Card E
The EMV Smart Card ‘U’ screens are as follows, where ‘x’
represents dynamic text on U0070, and ‘*’ represents dynamic text
on U0081 to U0087:
Table E-1 EMV Smart Card Screens

Column Position
Screen Row
Number Position 1 2 3
12345678901234567890123456789012345
U0067 1 EXTERNAL AUTHENTICATE: NO ARPC
U0068 1 EXTERNAL AUTHENTICATE: INVALID ARPC
U0069 1 SMART CARD READER NOT PRESENT
U0070 1 CARD INITIALISE ATTEMPT = x
U0071 1 COMPONENT VERSIONS
U0072 1 SCRW VERSION
U0073 1 SMART
U0074 1 **** CARD DETAILS UNKNOWN ****
U0075 1 **** AID NOT SELECTED ****
U0076 1 DECLINED OFFLINE
U0080 1 CHIP NOT ATTEMPTED
U0081 1 ATR RECEIVED T=*
U0082 1 CANDIDATE LIST *APPS
U0083 1 APPLICATION SELECTED
U0084 1 GENAC 1 : *
U0085 1 APP NOT USABLE
U0086 1 PROCESSING * SCRIPT
U0087 1 GENAC 2 : *
E-2 APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
Appendix F
Overview F‐1
Advance NDC F‐1
Font ID Mapping Table F‐2

Table of Contents

F
Overview
Overview F
This appendix lists the ISO 8859 character sets and font IDs
supported by the ‘EMV/CAM2 Exits for APTRA Advance NDC’
product.
In addition to the common characters previously provided, ISO
8859 parts 1 to 10 are also supported to enable international EMV
ICC usage. This also enables full use of the ʹApplication Preferred
Nameʹ data object (tag 0x9F12) when acquiring transactions. For
details of how the ʹApplication Preferred Nameʹ data object is used,
see “Data Object List (DOL) Processing” and “ICC Application
Name Display” in Chapter 7, “ICC Processing”.
As Advance NDC supports the ISO 8859 character sets, no
Advance NDC F
additional font files are needed.
APTRA Advance NDC, EMV ICC Reference Manual F-1

Font ID Mapping Table
Font ID Mapping Table F
The following table maps the ISO 8859 character sets to the font IDs
supported by the ‘EMV/CAM2 Exits for APTRA Advance NDC‘
product.
Font ID
ISO 8859
Font Size (decimal
Character Set
value)
Common Single ` (96)

Characters
Double a (97)
Part 1 ‐ Latin 1 Single b (98)

(West
European) Double c (99)
Part 2 ‐ Latin 2 Single d (100)

(East European)
Double e (101)
Part 3 ‐ Latin 3 Single f (102)

(South
European) Double g (103)
Part 4 ‐ Latin 4 Single h (104)

(North
European) Double i (105)
Part 5 ‐ Single j (106)

Latin/Cyrillic
Double k (107)
Part 6 ‐ Single l (108)

Latin/Arabic
Double m (109)
Part 7 ‐ Single n (110)

Latin/Greek
Double o (111)
Part 8 ‐ Single p (112)

Latin/Hebrew
Double q (113)
Part 9 ‐ Latin 5 Single r (114)

(Turkish)
Double s (115)
Part 10 ‐ Latin 6 Single t (116)

(Nordic)
Double u (117)
F-2 APTRA Advance NDC, EMV ICC Reference Manual

Table of Contents
State Flow Diagram
Appendix G
State Flow Diagram
State Flow Diagram G‐2
State Flow Diagram ‐ Part 1 G‐2
Key G‐2

Table of Contents
State Flow Diagram

State Flow Diagram
G
Overview
Overview G
This appendix includes a diagram of the base configuration state
flow.
This diagram is provided for illustration purposes only; you will
need to develop your own state flow as you require.
For an example of the configuration data you will need to define,
see Appendix A, “Example Configuration Data”.
In the following diagram, the state flow between states may be
labelled with the numbers 0 to 5 according to the type of card
inserted, as follows:
● FIT switch path 0 ‐ Banks own card, single usable application,
UK only, full function.
● FIT switch path 1 ‐ Banks own card, multiple usable application,
UK only, full function.
● FIT switch path 2 ‐ Known other bank card, potentially multiple
usable applications, potentially one, cash and balance.
● FIT switch path 3 ‐ Known other bank card, potentially multiple
usable applications, potentially one, cash only.
● FIT switch path 4 ‐ Known other bank card, targeted for card
rejection.
● FIT switch path 5 ‐ Unknown bank card, potentially multiple
usable applications, potentially one, cash only.
APTRA Advance NDC, EMV ICC Reference Manual G-1

State Flow Diagram
State Flow Diagram
State Flow Diagram G
The following diagram illustrates the base configuration state flow:
State Flow Diagram ‐
Part 1 G
Key G
Each state is represented by a rectangle which includes the state
identifier (for example, D) and state number (for example, 25).
Each state flow arrow between states is labelled (for example, T.O. =
Time Out, Cancel or values 0, 1 & 2).
Flow to/from subsequent parts of this diagram are represented by a
letter in a circle (for example, A, B, C or D).
TRESP = Transaction Response.
G-2 APTRA Advance NDC, EMV ICC Reference Manual

State Flow Diagram
State Flow Diagram
Part 2 G
APTRA Advance NDC, EMV ICC Reference Manual G-3

State Flow Diagram
State Flow Diagram
Part 3 G
G-4 APTRA Advance NDC, EMV ICC Reference Manual

Glossary
Glossary 0
AAC Application Authentication Cryptogram. An ICC application
A cryptogram produced for unsuccessful CAM transactions. See also
Cryptogram.
AAR Application Authorisation Referral.
AC Application Cryptogram. A cryptogram produced by the ICC
application. See also Cryptogram.
ADF Application Definition File. A file held in the ICC to describe
the attributes of an ICC application.
ADI Application Device Interface. The interface between the
application and a device driver.
AFL Application File Locator. A data object returned as a result of
the Get Processing Options command, which indicates a list of files
and records to be read to obtain additional data for use during CAM
processing.
AID Application Identifier. The identity or name of a specific ICC
application.
AIP Application Interchange Profile. A set of flags in the ICC
application that define which EMV features the card supports.
API Application Program Interface.
ARC Authorisation Response Code.
ARPC Authorisation Response Cryptogram. An ICC application
cryptogram produced by Central for submission to the ICC, to
prove it is a genuine host. See also Cryptogram.
ARQC Authorisation Request Cryptogram. An ICC application
cryptogram produced by the ICC application to prove to Central
that the ICC is genuine. See also Cryptogram.
ASCII American Standard Code for Information Interchange.
ATB Alternative Technology Byte. A byte in the track 2 ‘service
code’ field identifying cards using alternative technology. ICCs
(smart cards) are generally identified by a value of ‘2’ or ‘6’.
ATC Application Transaction Counter.
ATR Answer To Reset. Data provided by an ICC upon applying
power. The data contains information about how to interact with
the ICC.
AUC Application Usage Control. A set of flags in the ICC
application that define the transaction the card can perform.
APTRA Advance NDC, EMV ICC Reference Manual Glossary-1

Glossary
BCD Binary Coded Decimal.
B
BER-TLV Basic Encoding Rules ‐ Tag Length Value. A format
definition for all EMV data objects.
CAM Card Authentication Method. The method or process for
C authenticating an ICC.
CEN Comité Européen de Normalisation (European Committee for
Standardization). Responsible for the XFS interface specification.
CDOL1 Card risk management Data Object List 1. Data objects
required by the ICC when submitting the first Generate AC
command.
CDOL2 Card risk management Data Object List 2. Data objects
required by the ICC when submitting the second Generate AC
command.
CID Cryptogram Information Data.
CLA Class of instruction.
Cryptogram The result of encrypting a piece of data using a key and
a cryptographic algorithm.
CVM Cardholder Verification Method. The method by which the
ICC application verifies that a cardholder is genuine.
DASH Dip And Smart Hardware card reader.
D
DDF Directory Definition File. A file held in the ICC to describe the
attributes of an ICC directory.
DF Dedicated File. A file type used in the ICC file system.
DOL Data Object List. A list of data objects required by the ICC,
specified by the required tag and the number of bytes of the
required value.
Easy Entry application An application using a replication of magnetic

E stripe information on an ICC to facilitate payment. As this is not
compliant with the EMV specifications, this is not supported.
EMV Europay MasterCard Visa. The original consortium of
companies that introduced the EMV ICC standard functionality.
EMV is a trademark owned and registered by EMVCo, now a
consortium of American Express, JCB, MasterCard and Visa.
Glossary-2 APTRA Advance NDC, EMV ICC Reference Manual

Glossary
Fallback Payment system rules determine whether fallback to
F magnetic stripe is allowed after the failure of an ICC read
transaction. This behaviour is outside the scope of EMV.
FCI File Control Information. Information used to describe the
attributes of a file in the ICC file system.
FIID Financial Institution ID. A FIT entry field containing a partial
Financial Institution ID, which is used to match against the data on a
card.
FIT Financial Institution Table. A list configured by Central of all
acceptable card groups.
GENAC Generate Application Cryptogram. GENAC1 and GENAC2
G are the first and second GENACs respectively.
IC Integrated Circuit. The microelectronic circuit integrated into a
I semiconductor chip, such as in a smart card (ICC).
ICC Integrated Circuit Card. A card containing an integrated
circuit; also known as a smart card.
INS Instruction.
ISO International Standards Organisation.
ITR Interactive Transaction Response.
Lc Length of command data. The length of data being submitted to
L the ICC in a command.
Le Length of expected response data. The length of response data
expected to be returned by the ICC in response to a command.
MAC Message Authentication Code. A cryptographic checksum
M value used to verify that the data associated with it has not changed.
MCRW Magnetic Card Reader Writer. A device in a terminal for
accepting a card and reading the magnetic stripe on the card. See
also SCRW.
MSB Most Significant Bit.
NDC NCR Direct Connect. Supported by APTRA Advance NDC
N (for Windows XP or Windows 7).

Glossary
P1 Parameter 1.
P
P2 Parameter 2.
PAN Primary Account Number. The number of the cardholderʹs
primary account.
PDF Portable Document Format. The operating system
independent file format for Adobe® Reader® files.
PDOL Processing options Data Object List. Data objects required by
the ICC when submitting a Get Processing Options command.
PIN Personal Identification Number.
PSE Payment System Environment. The EMV‐defined root
directory in the ICC filing system.
SCIF Smart Card Interface. The interface board fitted to the MCRW
S to enable interaction with the SCRW.
SCRW Smart Card Reader Writer. The device fitted to the MCRW
providing an extension that can interact with an ICC.
SFI Short File Identifier. An abbreviated file name used to reference
a file in the ICC file system.
SHA-1 Secure Hash Algorithm‐1. A hashing algorithm used to
produce a unique secure signature from given data.
Smart Card General term for a card containing an Integrated Circuit
(IC). See IC and ICC.
SST Self Service Terminal. The terminal which the cardholder uses
for self‐service. Also known as ‘the terminal’.
SW1 Status Word 1. The first part of the response status from an
ICC command.
SW2 Status Word 2. The second part of the response status from an
ICC command.
TAA Terminal Action Analysis. The process used to determine
T whether an ICC transaction should be authorised, and if so, whether
the authorisation is performed online or offline.
TC Transaction Certificate. An ICC application cryptogram,
produced for successful CAM transactions. See also Cryptogram.
TDOL Transaction certificate Data Object List. A DOL which, when
processed, provides the input text for the SHA‐1. This algorithm
outputs the data used for the TC Hash Value data object.
TSI Transaction Status Information. The status of the transaction as
seen from the terminal.

Glossary
TVR Terminal Verification Results. The results of the verification as
seen from the terminal.
XFS eXtensions for Financial Services. Application and service
X provider interface specifications from CEN.

Glossary

Index
Index 0
Amount Check state type 2‐3
A Application IDs
Number of B‐3
Table 5‐14
Application, ICC
Name display 7‐23
Application, Terminal
Version Information 4‐2
Version Number 7‐11
APTRA Advance NDC
EMV/CAM2 Exits for 1‐13
Authorisation Response Codes 7‐47
Automatic Language Selection state type 2‐20
ICC Language Support table 5‐10
Begin ICC Application Selection & Initialisation state type 2‐22
B Begin ICC Initialisation state type 2‐12
BER‐TLV Data Object processing 7‐5
BER‐TLV field size B‐2
Buffer Identifiers 5‐32
Card Read ‐ PIN Entry Initiation state type 2‐9
C Central to terminal messages 5‐1
Character Sets, ISO 8859 F‐1
Commands
Customisation data 5‐2
Communications protocols B‐3
Complete ICC Application Selection & Initialisation state type 2‐31
Complete ICC Initialisation state type 2‐18
Completion data 4‐17
Compliance
Acceptable non‐compliance 1‐3
Implementation 1‐3
Standards 1‐3
Configuration Parameters Load message
Enhanced 3‐2
Customisation data
Commands 5‐2
Data Object List processing 7‐4
D Data Objects tables
ICC Currency 5‐6
ICC Terminal 5‐13
ICC Transaction 5‐8
Data, completion 4‐17
Development PC
APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual Index-1
Index
Installation D‐2
Diagram, state flow G‐2
Display
ICC application name 7‐23
Documentation, related C‐1
Eject, smart card
E Immediate B‐3
EMV configuration message 5‐4
EMV ICC Application Switch state type 2‐46
EMV Smart DIP Take Card state type 2‐43
EMV/CAM2 Exits for APTRA Advance NDC 1‐13
Encryption, PIN 7‐22
Enhanced Configuration Parameters Load message 3‐2
Error handling 7‐33
Error messages
ICC application journal 7‐36
Error messages, solicited/unsolicited
ICC application 4‐15
Error reporting
SCRW/MCRW hardware 4‐13
Errors
Power‐Up 4‐14
Example configuration data A‐1
Flow diagram, state G‐2
F Font designators 7‐24
Fonts, ISO 8859 F‐1
Hardware error reporting
H SCRW/MCRW 4‐13
Hardware, terminal
Information 4‐4
ICC application journal error message 7‐36
I ICC application name display 7‐23
ICC application solicited/unsolicited error message 4‐15
ICC Currency Data Objects table 5‐6
ICC Language Support table 5‐10
ICC processing 1‐1
ICC processing termination 7‐46
ICC Re‐initialise state type 2‐40
ICC Terminal Acceptable Application IDs table 5‐14
ICC Terminal Data Objects table 5‐13
ICC Transaction Data Objects table 5‐8
Installation
Development PC D‐2
Instructions D‐2
SST D‐3
Interactive Runtime SST installation D‐3
Index-2 APTRA™ Advance NDC, EMV™ Integrated Circuit Card (ICC) Reference Manual
Index
Interactive Transaction Response message 5‐33
ISO 8859 F‐1
Issuer Script processing 7‐3
Issuer Script results 4‐17
Journal ICC application error messages 7‐36
J Journal message
offline decline 7‐39
Language selection 5‐10
L
MAC Configuration 7‐13
M Magnetic stripes
Reading/writing B‐3
Merging Control Files D‐4
Message authentication code (MAC)
Configuration 7‐14
Message formats
Solicited status messages 4‐10
Transaction Request 4‐5
Messages
Central to terminal 5‐1
Interactive Transaction Response 5‐33
Terminal to Central 4‐1
Transaction Reply 5‐26
Name, ICC application
N Display 7‐23
Native mode device status information
Supervisor keys (unsolicited) 4‐11
Offline decline journal message 7‐39
O
PIN encryption and verification 7‐22
P Power‐Up
Errors 4‐14
Processing
BER‐TLV Data Object 7‐5
Data Object List 7‐4
ICC 1‐1
Issuer Script 7‐3
restrictions B‐1
Terminal Verification Results 7‐16
Transaction Data Object List 7‐11
Transaction Status Information 7‐20
Protocols, communications B‐3
Registry Settings 7‐50
R Reserved screens, EMV ICC E‐2
Index
Restrictions, processing B‐1
Results
Issuer Script 4‐17
Screens, reserved E‐2
S Script, Issuer
Processing 7‐3
Results 4‐17
Set ICC Transaction Data state type 2‐36
ICC Currency Data Objects table 5‐6
ICC Transaction Data Objects table 5‐8
Smart card eject, immediate B‐3
Smart Card Reader/Writer (SCRW) B‐3
Hardware error reporting 4‐13
Solicited status messages 4‐10
Standards compliance 1‐3
State flow diagram G‐2
State tables 2‐1
State types
Amount Check 2‐3
Automatic Language Selection 2‐20
Begin ICC Application Selection & Initialisation 2‐22
Begin ICC Initialisation 2‐12
Card Read ‐ PIN Entry Initiation 2‐9
Complete ICC Application Selection & Initialisation 2‐31
Complete ICC Initialisation 2‐18
EMV ICC Application Switch 2‐46
EMV Smart DIP Take Card 2‐43
ICC Re‐initialise 2‐40
Set ICC Transaction Data 2‐36
Transaction Request 2‐5
Status messages
Solicited 4‐10
Supervisor keys (unsolicited message) 4‐11
Supervisor menus/functions 6‐1
Terminal Application Version Information 4‐2
T Terminal Application Version Number 7‐11
Terminal hardware information 4‐4
Terminal to Central messages 4‐1
Terminal Verification Results processing 7‐16
Termination of ICC processing 7‐46
Transaction Data Object List processing 7‐11
Transaction Reply message 5‐26
Transaction Request message format 4‐5
Transaction Request state type 2‐5
Transaction Response message
Interactive 5‐33
Transaction Status Information processing 7‐20
Index
Verification, PIN 7‐22
V Version Information
Terminal Application 4‐2
Version Number
Terminal Application 7‐11
Index
User Feedback Form
Title: APTRA™ Advance NDC EMV™ Integrated Circuit Card (ICC) Reference Manual
Number: B006‐6297‐H000 Release: Issue 2 Date: January 2012
NCR welcomes your feedback on this publication. Your comments can be of great value in helping us improve
our information products.
Cut
You may send your comments to us electronically. See over for details.
Circle the numbers below that best represent your opinion of this publication.
Ease of use 5 4 3 2 1 0 5 = Excellent
4 = Good
Accuracy 5 4 3 2 1 0
3 = Adequate
Clarity 5 4 3 2 1 0 2 = Fair
1 = Poor
Completeness 5 4 3 2 1 0
Organisation 5 4 3 2 1 0 0 = Not applicable
Appearance 5 4 3 2 1 0
Examples 5 4 3 2 1 0
Illustrations 5 4 3 2 1 0
Job performance 5 4 3 2 1 0
Question resolution 5 4 3 2 1 0
Overall satisfaction 5 4 3 2 1 0
Indicate the ways you feel we could improve this publication.
❑ Improve the table of contents ❑ Add more/better quick reference aids
❑ Improve the overview/introduction ❑ Add more examples
❑ Improve the organisation ❑ Add more illustrations
❑ Improve the index ❑ Add more step‐by‐step procedures
❑ Make it less technical ❑ Add more troubleshooting information
❑ Make it more concise/brief ❑ Add more detail
Write any additional comments you may have below and on additional sheets, if necessary. Include page
numbers where applicable.
Use the following addresses to send your comments to us electronically:
E‐mail ‐ sf230067@ncr.com
Web (within firewall) ‐ http://www.dundee.ncr.com/infoprod/rcomment/newform/webform99.htm
Cut
Fold
If we may contact you concerning your comments, please fill in the information below:
Name:
Organisation:
Company:
Address:
Phone: Fax:
Thank you for your evaluation of this publication. Fold the form where indicated, tape (please do not staple),
and drop in the mail.
F 8763‐0695
Fold
Affix
Postage
Stamp
Here
NCR Financial Solutions Group Ltd

Information Solutions Feedback
Discovery Centre
3 Fulton Road
Dundee
Scotland
DD2 4SW

NDC Emv 3.0.0 PDF

Uploaded by

Document Information

Original Title

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

NDC Emv 3.0.0 PDF

Uploaded by

Copyright:

Available Formats

APTRA™ Advance NDC

Date Page Description Of Change

January 1‐6, 1‐11, Added explanatory notes about the Transaction

APTRA Advance NDC, EMV ICC Reference Manual v

vi APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual vii

page ‐xxi In ‘What Experience Should I Have?’, added

viii APTRA Advance NDC, EMV ICC Reference Manual

page ‐xxii Clarified abbreviations in new table.

page ‐xxi Updated pre‐requisite NCR training course

APTRA Advance NDC, EMV ICC Reference Manual ix

x APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual xi

xii APTRA Advance NDC, EMV ICC Reference Manual

About This Publication ......................................................................... xxi

APTRA Advance NDC, EMV ICC Reference Manual xiii

xiv APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual xv

xvi APTRA Advance NDC, EMV ICC Reference Manual

Overview ............................................................................................... B‐1

Overview ............................................................................................... C‐1

APTRA Advance NDC, EMV ICC Reference Manual xvii

Overview ............................................................................................... E‐1

xviii APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual xix

xx APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual xxi

xxii APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual xxiii

xxiv APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual

What Is ICC Processing?

APTRA Advance NDC, EMV ICC Reference Manual 1-1

1-2 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-3

1-4 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-5

1-6 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-7

1-8 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-9

1-10 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-11

1-12 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-13

1-14 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-15

Tag Name Tag

1-16 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 1-17

1-18 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 2-1

2-2 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 2-3

2-4 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 2-5

2-6 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 2-7

2-8 APTRA Advance NDC, EMV ICC Reference Manual

APTRA Advance NDC, EMV ICC Reference Manual 2-9