EMV — Banking and Retail
NBX — A&L Application Interface Specification (AIS)
FUJ00003486
FUJ00003486
RoLe NAME AREA OF I SIGNATURE Date
RESPONSIBILITY
Authors Rex Dixon on behalf I Business
of Post Office Ltd Architecture
Product
Deployment
Technical
Architecture
DA Sign-off David Gray Design
(Peer Reviewer) Authority
Programme Beverley Dunn Project
Director Delivery
Alliance & lan Antrobus
Leicester Sign-
off
Fujitsu Gill Jackson
Services Sign-
off
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV — Banking and Retail
Interface Specificati
Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
1 Document Control
1.1 Document Information
Horizon Release No:
$75
Document Title:
EMV Banking and Retail: NBX — A&L Application Interface Specification
Document Type:
Application Interface Specification
Abstract: This document details the application interface between the Horizon
domain and Alliance and Leicester, including the interface to the ICC
Document Status: Approved
Originator & David Gray
Department:
Design Authority
Contributors:
Post Office
Distribution:
Design Authority - David Gray
POL Document Control — Post Office Programme Office
Supplier Distribution:
A&L: Mark Clarke
Fujitsu Services: Gill Jackson
Client Distribution:
N/A
Table 1: Document Information
1.2 Document History
Version Date Reason for Issue I Associated
I we /cT
0.1 8 Dec 2003 First working draft. Based on document
produced by IBM entitled “NBE — Alliance
and Leicester AIS version 2.0 dated
10/01/2003
0.2 28 Jan 2004 Second working draft. Based on NBX-LINK
AIS version 0.5 as agreed with A&L at
meeting 21/01/2004
0.3 12 Feb 2004 Updated following joint review on 11 Feb
2004
04 4 Mar 2004 Updated following responses from A&L
0.5 7 Apr 2004 Updated following teleconference 17/03 and
subsequent clarifications
1.0 12 May 2004 — Updated following meeting 28/4/04 and
teleconference 12/05/04
1.1 16 Aug 2004 Updated with latest agreed changes
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0 Page 2 of 48
NBX - A&L Application
Interface Specification
Project:
Doc Ref:
COMMERCIAL IN CONFIDENCE
FUJ00003486
FUJ00003486
EMV — Banking and Retail
NB/IFS/026
1.2 22 Sep 2004 —_ Updated following formal review
2.0 17 Sep 2004 __ Issued for Sign-off (based on version 1.1)
3.0 5 Oct 2004 Issued for Sign-off (based on version 1.2
apart from two names)
3.41 26 May 2005 ~—- Updated for minor corrections discovered
during testing prior to initial release at
Horizon release S75
3.2 4 Aug 2005 Minor changes as a result of review:
some names removed,
copyright statement updated
4.0 15 Aug 2005 Issued for Sign-off
Table 2: Document History
1.3 Change Process
Any changes to this issued version of this document will be made, controlled and distributed by: -
Elaine Hollingworth-Clarké
1.4 Review Details
Review
Comments by :
Review
Comments to :
Rex Dixon, Fujitsu Services
Mandatory Review Authority
Name
Post Office Ltd
Beverley Dunn, David Gray
Fujitsu Services Ltd
Analysis & Solution Specification
Allan Hodgkinson
DU Design Authority
Andy Kennedy
DU Design Team Designer
Rex Dixon
Test Design
Peter J. Robinson
Alliance and Leicester
Mark Clarke, Steve Green, Neil Scott
Optional Review / Issued for Information
Post Office Ltd
Bob Booth, Marc Reardon, Jason Crellin
Fujitsu Services Ltd
Release Manager
Bill Reynolds
DU Design
Mark Jarosz, Alex Robinson
DU Development Team Leader
Peter Ambrose
Alliance and Leicester
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0
Page 3 of 48
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification .
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
1.5 Changes in this Version
Version Changes
4.0 Gill Jackson added as signatory for Fujitsu Services
3.2 Removed certain reviewer names as requested.
3.1 Sections 4.1.2, 4.2.1.2, 4.2.2.2, 4.2.3.2, 4.2.4.2, 4.2.5.2 and 4.2.6.2 —
Application PAN Sequence Number (bitmap ref. 023): clarified that it is required
for manually entered transactions only when the card's issue number has been
captured. [FS Peak 110188, 110679]
Sections 4.1.2 and 4.2.1.2 - Authorisation Data (bitmap ref. 123): removed from
0100 message. [POL Incident 1153; FS Peak 108959]
Section 4.1.2 — Point of Service Data (bitmap ref. 061), subfield 2 (Cardholder
authentication capability): added value 0 (No electronic authentication) for
deposits. [POL Incident 1212; FS Peak 110150]
Section 4.2.4.2 (Balance Enquiry Response) — Clarified that, for a decline, the
length of this field must be set to ‘000’. [POL Incident 1196]
Section 4.2.7.2 (Reversal Request) — Added a note that NBX does not include
any of the Optional fields.
Table 3: Changes in this Version
1.6 Key Contacts
Name Position Phone Number
Jason Crellin Solutions Architect, Post Office Ltd H I
Mark Clarke Senior Manager, Retail Bank, A&L
Rex Dixon Design, Fujitsu Services
Table 4: Key Contacts
1.7 Associated Documents
Created on 15/08/2005 Version 4.0 Page 4 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification .
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Reference Version I Date Title Source
NB/IFS/029 NBX — A&L Technical Interface Post Office
Specification
p. NB/OLA/O03 Horizon — A&L Operational Level
Agreement
NB/IFS/030 NBX — FI Reconciliation and
Settlement File Format AlS
Ht. LISS 2004-1 LINK Switch Service Interchange LINK
Vsn 1.1 Standard (LIS5)
SU/PLA/016 0.3 NB Volume Model Comparisons Post Office
NB/IFS/034 NBX — A&L Mapping Post Office
y. 1.2 LISS — Deposits “What's New” LINK
Vsn 5.6 I Jan 2002 I LINK Switch Service Interchange LINK
Standard (LIS5 Security Standard)
Table 5: Associated Documents
Unless a specific version is referred to above, reference should be made to the current approved versions
of the documents.
Created on 15/08/2005 Version 4.0 Page 5 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification .
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Table of Contents
1 DOCUMENT CONTROL 2
441 Document Information 2
1.2 Document History 2
1.3 Change Process 3
1.4 Review Details 3
1.5 Changes in this Version 4
1.6 Key Contacts 4
17 Associated Documents 5
2 INTRODUCTION 8
21 Purpose 8
2.2 Scope 8
2.3 Structure 8
24 Terms and Abbreviations 8
3 OVERVIEW OF THE INTERFACE 9
3.41 Data Description 9
3.2 Derivation and Use of Data 11
3.3 Non Computer Data 13
4 DATAITEMS 14
41 Data Item List 14
4.41 General Message Element Definitions and Abbreviations 14
4.1.2 Messages Data Elements 16
4.2 Data Interpretations 27
4.2.1 [R3] - Balance Enquiry 28
4.2.2 [R3] - Financial Transaction Request - Withdrawal 29
4.2.3 [{R3] - Financial Transaction Request - Deposit 31
4.2.4 [A1] - Balance Enquiry Response 33
4.2.5 [A1] - Financial Transaction Request Response - Withdrawal 34
4.26 [A1] - Financial Transaction Request Response - Deposit 35,
4.2.7 [E1] - Reversal Request 36
4.2.8 [E2] - Reversal Request Response 38
4.2.9 Administration Advice (0620) 39
4.2.10 Network Management Messages (0800 / 0810) 40
4.2.11 Reconciliation and Settlement 41
Created on 15/08/2005 Version 4.0 Page 6 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV — Banking and Retail
& Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
5 TRANSFER STRUCTURE 42
541 Transfer Grouping 42
5.2 Transfer Structure 42
5.3 Record Structure 43
54 Sequences 43
5.5 Data Volumes 43
5.6 Data Authentication 43
5.7 Data Dictionary 43
6 SECURITY OF TRANSMITTED DATA 44
6.1 Protected Data 44
6.2 Encryption and Decryption Methods 44
6.3 Session Establishment 44
64 Key Management 44
7 OPERATIONAL PROCEDURES 46
71 Processing Cycles 46
7.2 Transfer Initiation 46
7.3 Security Procedures 46
74 Fallback Procedures 46
75 Downgrade Transactions 47
76 Control 47
8 APPENDIXA 48
Created on 15/08/2005 Version 4.0 Page 7 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application — Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
2 Introduction
2.1 Purpose
The purpose of this document is:
1. To specify the interface between the NBX and Alliance & Leicester (A&L) using the LINK [LISS]
standard as the basis for development (Ref. [4]).
2. To provide the development teams with sufficient detail to develop the NBX - A&L interface.
3. To provide a consistent communications vehicle amongst the development teams that have
responsibility for developing the various components comprising the application.
2.2 Scope
This document applies to the interface between the NBX and A&L only. It includes only those financial
transaction messages and network messages sufficient to support the financial products being delivered by
Post Office Limited via the A&L systems.
This AIS is concerned only with the application messages exchanged over the interface between NBX and
A&L. The technical interface between the NBX and A&L will be specified in a Technical Interface
Specification (Ref. [1]). There are a number of other key points, which must be borne in mind when reading
this document:
1. Alliance and Leicester use the BASE24 system to support its card-based ATM transactions.
2. The BASE24 system in conjunction with the NBX will base this interface on the LINK Switch Service
Interchange Standard (Ref. [4])
3. The A&L interface does not support PIN change or “Withdraw Limit” transactions.
2.3 Structure
Section 3 contains a high level overview of the NBX — A&L interface and its context.
Section 4 contains a detailed description of the messages to be exchanged, and the derivation and use of the
exchanged data items. All data items exchanged are specified in LINK Switch Service Interchange Standard
(LISS) documentation (Ref. [4]).
Section 5 contains details of the data transfer.
Section 6 contains details of security of the exchanged data items. This section identifies the security needed
for each data item (e.g. encryption) and details of the method to be used.
Section 7 contains any relevant details of operational procedures relating to the interface.
2.4 Terms and Abbreviations
No Entries
Created on 15/08/2005 Version 4.0 Page 8 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interfé Ss ificati
ni face Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
3 Overview of the Interface
3.1 Data Description
The following messages are exchanged over the NBX - A&L interface:
NBX Description Direction
Message Id
[R3] Authorisation / Financial Transaction Request: NBX > A&L
« balance enquiry (0100)
e withdrawal (0200)
* deposit (0200)
Note that there is no separate message to A&L for withdrawal
with balance. A&L control the return of balance information.
[A1] Authorisation / Financial Transaction Request Response: A&L > NBX
e balance enquiry response (0110)
* withdrawal response (0210)
« deposit response (0210)
Each of the above will have a response code that indicates
approve or decline with reason and any required action (e.g.
card retention).
{E1] Reversal Request: NBX > A&l
e Acquirer Reversal Advice (0420)
e Acquirer Reversal Advice Repeat (0421)
The NBX has a configurable maximum number of retries for
this message of 9999, although this is usually set to between
3 and 5. The message is then logged as undeliverable and
will require a manually entered command to remove the
rogue message from the store and forward queue.
(E2] Reversal Advice Response (0430) A&L > NBX
0620 Administration Advice (0620) NBX > A&L
Administration Advice messages (0620) are sent to/from NBX OR
in order to initiate investigation of a problem by either A&L or
Post Office Ltd AaL ~~ -NBX
Created on 15/08/2005 Version 4.0 Page 9 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interfé Ss ificati
ni face Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
0800 Network/Key Management Request (0800): NBX > A&L
e Handshake (Echo test) A&L > NBX
e Logon / Logoff (Sign on / Sign off) Actual flows are
documented in section
¢ End of Day (Cutover) 4.2.10.
e Key Change
e« Key Change Request
Note A&L do not support Online Verification
At end of day, NBX to act as master and send 0800 to A&L.
NBX must keep sending this until End of Day response
message 0810 received from A&L.
0810 Network/Key Management Request Response (0810) A&L > NBX
NBX > A&l
Reconciliation I A Reconciliation file is sent at end of day by NBX to A&L. This I NBX > A&L
and provides a record for all A&L transactions for settlement day,
Settlement for which the NBX has [R3] and [A1] messages and totals of all
financial transactions for that settlement day. (A&L will need to
compare this file against their daily transactions to agree
transactions for the day. The method of reconciliation of
settlement differences between A&L and Post Office is outside
the scope of this document.
A&L will ONLY reconcile and settle based on the
Reconciliation File Format — (Ref. [3]).
Created on 15/08/2005 Version 4.0 Page 10 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV — Banking and Retail
Interface Specificati
Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
3.2 Derivation and Use of Data
The messages listed above are generally exchanged as a result of a transaction initiated either by a clerk ata
Post Office outlet or by A&L. The NBX acts as a message router, filtering messages based on business rules
and transforming received messages into the appropriate format for forwarding to the next system in the
message sequence.
The following table shows the derivation and use of each banking transaction message exchanged between
the NBX and A&L in terms of the received message that causes each NBX - A&L message to be exchanged,
and the transmitted message resulting from the NBX - A&L message exchange. The shaded columns indicate
the systems and connecting interface addressed by this AIS.
Message Sequence
Horizon Horizon NBX A&l
Outlet Campus
[Ri] > [R2] > 0100/0200
{R3] >
< [A3] < [A2] 0110/0210
<{At]
[Co] > [C2] > 0420/0421
(E1)>
0430
< [E2]
The messages exchanged over this interface relating to end of day, reconciliation and settlement are initiated
by NBX, and are neither derived from received messages nor used to generate onward messages.
Security key exchange messages are initiated by A&L and acknowledged by NBX. The business processes
with respect to these messages are addressed in the Operational Procedures Manual, (Ref.[2]). The following
table shows the derivation and use of each security message exchanged between A&L and the NBX.
Created on 15/08/2005 Version 4.0 Page 11 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
& Interface Specification De .
loc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Message Sequence
Horizon Horizon NBX ASL
Outlet Campus
eC 0800 (Logon
061)
0810 >
< 0800 (Key
Change -
Acquirer zone
code 161)
0810 ie
0800 (Logon >
074)
€ 0810
< 0800 (Key
Change —
Acquirer zone
code 161)
0810 >
Se 0800 (Key
Change -
Acquirer zone
code 161)
0810 laa
0800 (Key >
Change
Request -
Acquirer
zone 181)
i 0810
2 0800 (Key
Change -
Acquirer zone
code 161)
0810 >
If NBX requires a working key change it sends an 0800 Change Key Request message to A&L. A&L sends an
0810 response to the Change Key Request message followed by an 0800 Key Change message containing
the new working key. A&L may initiate a change of working key by sending an 0800 Key Change message.
Either the NBX or A&L can log on. The table above shows the sequence of events when either of these
happen. A&L will send a Key Change message when it has received a Logon response from the NBX or once
it has sent the Logon response to a Logon message received from the NBX. If the NBX does not receive the
Key Change message within a reasonable period (10 seconds), it will send a Key Change Request message to
A&L. Upon receipt of this message, A&L can either initiate the key change or reject it with a response code
indicating key exchange in progress.
Other 0800 messages may be initiated by either A&L or NBX (with the exception of the 0800/261 End of Day
(Cutover) message, which is NBX-initiated), and are acknowledged by an 0810 response from the other side.
The use of Handshakes is described in the NBX — A&L Technical Interface Specification (Ref. [1]),
All 0100 and 0200 messages generated by NBX prior to NBX sending the 0810 approved Key Change
response will have used the current AWK to encrypt the PIN Block. As soon as the 0810 approved Key
Created on 15/08/2005 Version 4.0 Page 12 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application — Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Change response is transmitted, the new AWK becomes active at NBX so that all messages generated after it
use the new AWK to encrypt the PIN Block.
In the event that the Key Check Value received by NBX (with the AWK in the 0800/161 Key Change message)
does not match the one created when testing the new AWK, NBX will return an 0810 denied response. Under
these circumstances the new AWK will NOT be implemented and any subsequent transactions will continue to
have the PIN Block encrypted using the current AWK.
In order to prevent race conditions, NBX will not accept a new AWK if the previous AWK was established less
than a configurable period earlier (e.g. 1 minute) within a session.
A&L sets a flag during key change that is cleared when the key change is concluded.
3.3 Non Computer Data
All data being transported across this interface is originated/received from a connected computer system or
from reference data (supplied by the Post Office Limited RDS or held internally within the NBX).
Created on 15/08/2005 Version 4.0 Page 13 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
4 Data Items
4.1 Data Item List
4.1.1 General Message Element Definitions and Abbreviations
The following section summarises the list of Message Elements for each group of transactions, together with
which message(s) they are present in. Each message is classified and identified using the RAC (Request /
Authorise / Confirm) model. Each message element references the corresponding LISS Standard bitmap
position (Ref. [4]).
The abbreviations used to describe the format of each data element (DE) and Data Sub-elements are shown
in the following table:
Notation IExplanation
a Alphabetic characters only (upper case)
in Numeric Digits only
Is Special characters
lan Alphabetic or Numeric characters (upper case)
as [Alphabetic or Special characters (upper case)
ins Numeric or Special characters
ans Alphabetic, Numeric or Special characters only (upper case)
DBD Da
MM. Month
had Year
hh Hour
mm Minutes
Iss Seconds
LL Length of variable field that follows represented using two characters
LLL Length of variable field that follows represented using three characters
VAR Variable length field
3 Fixed length field (e.g. 3 characters in this example)
10 Variable length field (e.g. up to a maximum of 10 characters in this example). LL orI
LLL to indicate the actual length of the field will prefix all variable length fields.
Where the field length has been specifically defined this has been included.
h Hexadecimal representation of the data
iz Tracks 2 and 3 data, as defined by ISO 7811 and ISO 7813
The Field Size column gives the number of characters (octets) required for the data item, as shown in the
table below.
Abbreviation I Description
3 Fixed Length field. Numeric fixed length fields are right justified and zero
padded. Fixed length string fields are left justified and space padded
70 Variable length field (up to a maximum of 10 characters in this example).
The Source column indicates the system or user originating the data.
The “Description” column contains a brief description of the field, as used in the messages defined in this AIS
together with any additional comments.
The “Required” column indicates whether the field is Mandatory or Conditional for the messages defined in this
AIS. For conditional fields, the field description should indicate under what circumstances the data for the field
should be populated or omitted from the message.
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV ~ Banking and Retail
Interface Specification
COMMERCIAL IN CONFIDENCE
Doc Ref: NB/IFS/026
Code
Meaning
The element is mandatory for this message. On messages sent to BASE24, ifa
mandatory element is not present in a message, the message is rejected and
returned to NBX.
On messages sent by BASE24, a mandatory data element is always present. If
BASE24 does not have the appropriate information for the element, BASE24 fills
the field with zeros or spaces or sets the length indicator to zero.
The element is conditional for this message, and the condition to be applied is
stated in the Conditions column. It should be noted that the receiving system
may not be able to assess whether the condition has been met, in which case it
must be able to interpret the presence or non-presence of the element according
to appropriate business rules.
On messages sent to BASE24, a conditional data element must be present if
BASE24 requires the conditional element for processing. If it is not present, the
message is rejected and returned to NBX.
On messages sent by BASE24, a conditional element is only included if it is
required for the particular type of message being sent. If the element contains
spaces, it is not sent. If the element contains data and the data is valid, BASE24
includes the element in the message.
Optional_- See Message Definitions for rules
Notes:
e Fixed length numeric fields are unpacked, right justified and zero filled.
e Fixed length alphanumeric fields are left justified and space filled.
« All messages between the NBX and A&L will be encoded in ASCII format (English character set,
CCSID = 437),
Created on 15/08/2005 Version 4.0
© Post Office™ 2004-2005
Page 15 of 48
4.1.2 Messages Data Elements
The Data Elements exchanged within messages over this interface are listed below. The Primary Bit Map data element is mandatory in every LISS
message and is not shown. The Secondary Bit Map is required if any of data elements 65 through 128 are included in the message, otherwise it is not
used. The Tertiary Bit Map is required if any of data elements 129 through 192 are included in the message (e.g. ICC fields).
In the following table, rows/columns are sometimes shaded in grey. This indicates that the field is not required and may not be populated in messages
from NBX to A&L. The NBX will log any such fields received from A&L but will not process them further.
A&LData Elements [Bitmap] Format I Field I Source INotes Required
Ref. Size
IR3] I (R3]I [A1] I [1] I [1] I [E2] }0620] 0800] 0810)
0100]0200]0110} 0210} 0420 }0430
10424
Account Identification 1 102 I ans 28 I Issuer INBX does not pass Account Identification 1 field to the counter mi MoM
LLVAR systems
[For a withdrawal, holds the account number from which the
funds are withdrawn; for a balance enquiry itis the account
number for which the balances are provided. It is not used for a
ldeposit transaction. ]
Acquiring Institution 019 I on 3 Not appropriate to messages passed on this interface
ICountry Code
Acquiring Institution 032 n 11 I NBX from ICode identifying the Acquirer (Post Office Limited). Set to mi u{[u{[mM]omu f[M
Identification Code LLvaR Ref Data 2200040000 preceded by a length indicator of 10.
Additional Amounts 054 I an I.. 120 Bank Identifies account balance value (included if provided by bank) Mic
LLLVAR
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV ~ Banking and Retail
Interface Specification
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
lAdditional Response Data I 044 I ans I..25
LLVAR
Bank
Not appropriate to messages passed on this interface
[On original interface, this was used for incoming 0210
messages, this element is used for account balance information
lon withdrawals as well as balance enquiries. Maximum of 2
balances passed: Ledger Balance, Available Balance (includes,
[Shadow Balance, Remaining Overdraft Balance etc.). It is the
total Available Balance on the account; not the daily card limit for
the card, less any previously withdrawn amount for the day.
The format of the field:
Digit 1-2 = 25 (field length indicator LL)
Digit 3 set to:
1 = Ledger balance present only
2 = Available balance present only
'3 = Both balances present; use ledger balance if only one
ican be used
}4 = Both balances present; use available balance if only one can
be used
When digit 3 is set to 3 or 4 then the NBX will always send both
balances to Horizon if both are present, including zero balances.
Digits 04~15 Ledger Balance
Digits 16-27 Available Balance.
If a negative amount is to be expressed, the leftmost byte will
contain a minus sign (-); otherwise, it will contain a zero. I
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0 Page 17 of 48
FUJ00003486
FUJ00003486
NBX-A&L Application Project:
Interface Specification
EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
IAdvice / Reversal Reason
Code
060
an
LLLVAR
NBX
Used in NBX interface for advice, reversal and ICC transactions.
Required for advice, reversal and ICC transactions.
Used in request messages from ICC capable terminals to
indicate Status of Last Chip Read attempted and to provide
ICryptogram Information Data
Magnetic stripe cards
Reversal Requests (0420/0421 messages):
Bytes 1-2 are set to 80
Bytes 3-4 give a reason for the reversal.
Remaining bytes are not transmitted
ICC cards
[R3] Requests (0100/0200 messages).
Bytes1-2 are set to 30
Byte 3 is Status of Last Chip Attempt
Bytes 4-5 is Cryptogram Information Data
Fallback [R3] Requests (0100/0200 messages):
Bytes1-2 are set to 30
Byte 3 is Status of Last Chip Attempt (value 2)
Bytes 4-5 is Cryptogram Information Data (value CO)
Reversal Requests (0420/0421 messages)
Bytes 1-2 are set to BO
Bytes 3-4 give a reason for the reversal
Byte 5 is Status of Last Chip Attempt
Bytes 6-7 is Cryptogram Information Data
ISee Appendix A for Reversal Reasons
JAmount, Cardholder Billing
006
Not appropriate to messages passed on this interface — foreign
transactions not supported by NBX
Amount, Transaction
004
Clerk at
Outlet
Decimal amount in smallest unit of the specified currency (ie.
GBP pence or EUR cents)
Not required for balance enquiry
Amount, Transaction Fee
028
an
Post Office will not apply Acquirer charges (format annnnnnnn)
Amount, Transaction
Processing Fee
030
an
Bank
Issuer charge (format annnnnnnn).
Note : No fee data will be passed on the interchange.
Application interchange
Profile (AIP)
138
Icc
From ICC, indicating capability to support specific functions
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0 Page 18 of 48
FUJ00003486
FUJ00003486
NBX-A&L Application Project:
Interface Specification
EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
[Application PAN Sequence I 023 I 3 I Clerkat identifies and differentiates cards with the same PAN
Number Outlet
Required for ICC transactions, or ifthe card's issue number has
been manually entered
/Acquirer decision as to whether sent in the reversal message
(0420/0421) - copied from original transaction. Required in 0430
if present in 0420/0421
lApplication Transaction I 137 I h 4 ICCA sequence number (counter) calculated by the ICC and passed
ICounter (ATC) to the terminal application.
[Acquirer decision as to whether sent in the reversal message
(0420/21) - copied from original transaction, Required in 0430 if
present in 0420/0421
[Authorisation Data 123 I ans I ..255 I Clerk at ISub-Fields 1-13, 15, 16 and 17 do not apply
Outlet
LLLVAR MNS" ISub-Field 14 is used in PIN failure notification messages to
inform bank of cause of script processing fallure on ICC. Format
lof sub field is h.. 12
ISub-Field 18 Bilateral Discretionary Data must contain Start Date
lof card where one exists and the card details have been manually
entered.
Format of Sub-Field 18 is: ans ..99
JAuthorisation Identification I 038 I an 6 Bank [Not required for NBX transactions - POS Transactions Only
Response
lAuthorisation Response I 121 I ans I ..255 Not required for NBX transactions - used for Cheque Clearance
Data Date.
LLLVAR
This could be returned by an issuer to state when cheque funds
will clear. NBX must be able to accept this, but wil log only.
[authorising Agent 113 I on 11 I Bank _ [institution approving or dectining the transaction
Institution Id Cod
institution Id Code LLLVAR
Bit Map Secondary oor I oh 16 I NBX from indicates presence of data elements in a message in range 065
system {to 128. This data element may be omitted if no elements in range
1065 to 128 are contained in message
Bit Map Tertiary oss I ih 16 I NBX from [Required for ICC based transactions (i.e. data elements in range
system I129 to 192)
Icard Acceptor Identification] 042 I ans I 15 I NBX from INBX will populate with the Post Office short name from reference
Code system Idata, left justified and space filled
Created on 15/08/2005 Version 4.0 Page 19 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application Project:
Interface Specification
EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Icard Acceptor Name / 043 I ans 40 I NBX from IFirst 40 characters of outlet address in format: M
Location Ref Data 01.23 first 23 chars of Name and Address
( first 23 chars of ADDRESS 1 from POL RDS)
124-38 first 15 chars of City
( first 15 chars of ADDRESS 4 from POL RDS)
139-40 GB
This field may be sent in mixed case to A&L by the NBX (except
GB, which must be in upper case)
ICard Acceptor Terminal 041 I ans 8 Outlet fromIComprises 6 digit outlet id (group_id) + 2 digit terminal id M
Identification system I(node_id)
IConversion Rate, 010 I on 8 Not required - foreign currency transactions are not supported by
ICardholder Billing NBX.
ICryptogram (ARQC) 136 I oh 16 ICC IComputed by ICC for on-line application °
ICryptogram Amount 147 n 12 ICC _ I Transaction amount used by ICC in generating cryptogram °
ICryptogram Currency CodeI 148 I n 3 ICC Contains transaction currency code used by ICC in generating °
[cryptogram for an ICC transaction
ICryptogram Transaction I 144 n 2 ICC Contains transaction type used by ICC in generating the °
Type Icryptogram for an ICC transaction
ICurrency Code, Cardholder I 051 I an 3 Not required - foreign currency transactions are not supported by
Billing NBX
ICurrency Code, 049 I an 3 Clerk at IOnly 826 (GBP) will be accepted initially. NBX will translate GBP M
Transaction outlet Icode received from Counters to 826 (using ISO 4217 standard)
for A&L.
Date, Expiration o14 I yyum I 4 Clerk at IMay be required where the card data is manually entered, c
Outlet _ determined by the reference data at the counter
Date, Local Transaction 013 I MMDD I 4 [Outlet fromIAs printed on receipt, transaction request date in Local Time M
System
Date, Settlement 015 I mm0p I 4 I NBX, then INBX sets in request to Acquirer’s settlement date. M
ASL I nat sets in response to A&L settlement date
The reversal message will contain the original, NBX set
Settlement Date.
File Name 101 I ans 17 Not appropriate to messages passed on this interface.
File Update Code o91 I an 1 Not appropriate to messages passed on this interface.
Created on 15/08/2005 Version 4.0 Page 20 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV - Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Forwarding Institution 033 I on ae Not required, since NBX is an Acquirer only
Identification Code
LLVAR
Info Text 124 I ans I ..255 I Sender IContains up to the first 255 bytes of the message rejected by the M
Isender (either NBX or A&L)
LLLVAR
Issuer Application Data 134 h 64 ICC IUnique ICC related card data for card scheme cle °
LLVAR
issuer Authentication Data I 139 I h 32 I Issuer A value computed by the Issuer to allow the ICC to authenticate c}c
the issuer returning the response. Comprises two sub-fields
LLVAR
I Sub-field 1 - ARPC (format h16) - must be included in a
response to a message where the ARQC has been verified
successfully by the Issuer
= Sub-field 2 - Optional Data (format .. h16)
Issuer Script 142 h .255 I Issuer IContains commands for transmission to ICC from Issuer o}o
LLLVAR
Issuer Trace Id 126 I ans 6 Issuer IIssuer specified transaction identifier. Note: The field is FIXED mi mM] mM [M
length 6 but with the var field header ie LLLnnnnnn
LLLVAR
Merchant Type 018 I on 4 Not required for NBX transactions - POS Transactions Only
Message Authentication 064 I oh 16 Not currently supported over this interface
ICode, Primary
Message Authentication 128] h 16 Not appropriate to messages passed on this interface.
ICode, Secondary
Message Security Code 096 I an 8 Sender IPassword to network management requests (see Horizon — A&L c
JOLA (Ref. [2])
Network Management 125 I ans 60 I Sender IAdditional information required for key change and key c
Information Verification
LLLVAR
= Positions 01-32 - 32 byte working key
™ Positions 33-36 - check value (4 bytes)
™ Positions 37-38 - check value padding (zeroes)
™ Positions 39-60 - Spaces (optional)
Created on 15/08/2005 Version 4.0 Page 21 of 48
© Post Office™ 2004-2005
NBX-A&L Application Project:
Interface Specification
EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Network Management
Information Codes
070
A&L/
NBX
‘See Section 4.2.10 for values
IOriginal Data Elements
090
NBX
Identifies an original transaction being reversed.
101-04 Original Transaction Type 0200
The remaining characters are zero filled
PIN Data
052
Outlet from.
customer
[Customer PIN Entered by customer & encrypted using ISO 9564-
1 Format 0 as defined in ANSI X9.8. Not supplied for verification
by signature or deposit transactions (as no PIN authentication of
ithe customer is undertaken)
Point of Service Condition
Code
025
Outlet
Initially to be set by NBX (from Ref Data) to 54 (Non ICC Capable
Branch ATM). 55 will be used to indicate ICC Capable Branch
IATM when chip read support added.
Point of Service Data
061
NBX
ISubfield 1 will be set to:
8 —Mag. stripe & key entry (counter not ICC enabled)
9—Mag. stripe, ICC & key entry (counter ICC enabled)
ISubfield 2 will be set to:
1-PIN,
0 -No electronic authentication (assumed for deposit)
ISubfield 3 will be set to 1 — capture
Subfield 4 will be set to 1 — On premises of card acceptor,
lattended,
[Subfields 5 and 6 will be set to 01 — Cardholder present, card
present,
ISubfield 7 will be set to: 2—Magnetic stripe, 5 - ICC, 6 -
Manual Entry
ISubfield 8 will be set to 1 — PIN, 0 - No PIN (if deposit
transaction)
ISubfield 9 will be set to 3 (Authorising agent = issuer)
ISubfield 10 = 1 (none) or 3 (ICC)
ISubfield 11 = 0 (unknown — mixed print & display capability, over
time)
ISubfield 12 = C (pin capture length is up to 12 - h/w capability,
usage is likely to be 4 digits only)
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0 Page 22 of 48
FUJ00003486
FUJ00003486
NBX-A&L Application Project:
Interface Specification
EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
FUJ00003486
FUJ00003486
Point of Service Entry Mode
022
Outlet
Digits 1-2 will be’
101 (Manual entry)
105 (ICC)
190 (Mag Stripe, Track 2 read and fully transmitted, includes
downgraded ICC cards)
Digit 3 will be:
1 (PIN entry capability)
[2 (No PIN entry capability) — used for deposit
Point of Service PIN
ICapture Code
026
Not appropriate to messages passed on this interface - POS
Transactions Only
Primary Account Number
002
LLVAR
Outlet from.
card/Clerk
at Outlet
Read from ICC for an ICC transaction, read from Track 2 data if
[card swiped, entered by the clerk when card details manually
lentered
[Identifies particular card, customer account or relationship]
Processing Code
003
NBX
NBX will set digits 1 and 2 to
101 for Withdrawal
[31 for Balance Enquiry
21 for cash deposit
Digits 3 to 6 will be set to zero (default), All 6 digits passed by
NBX and A&L.
Replacement Amounts
095,
an
42
Not required - partial reversals not supported by NBX
[A&L - Not passed by NBX to BASE24. A transaction is either
lapproved for the full amount requested or is declined (ie. zero
lapproved). A reversal will, therefore, be for the full amount
requested (and not a part of it)]
Response Code
039
an
[Code indicating transaction step outcome. Source dependent on
transaction type.
The LISS Response codes will be used
* systems Trace Audit Number [011] Time Local Transaction [012], Retrieval Reference Number [037] and Card Acceptor Terminal Identification [041] uniquely identify a transaction when combined.
Version 4.0 Page 23 of 48
Created on 15/08/2005
© Post Office™ 2004-2005
NBX-A&L Application Project:
Interface Specification
EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Retrieval Reference 037 I an 12 NBX Additional transaction identifier, assigned by NBX. It MUST be I M I M M
Number! unique for a terminal ID, at least within 1 business day.
Additional transaction identifier, assigned by NBX, as follows:
Digits 01-04 set to Julian date (YDDD)
Digits 05-06 set to 00
Digits 07-12 set to a 6 digit cycling number generated at each
counter
ISystems Trace Audit on n 6 NBX _ ITransaction identifier, assigned by NBX within the request, and I M I M M
Number included in all subsequent messages relating to that transaction
((A1] response and [E1] / [2] reversal messages.
Terminal Capability Profile I 130 I h 6 Outlet IRequired for ICC transactions - indicates card data input, CVM I Cc I C °
jand security capabilities of terminal
Terminal Country Code 145] on 3 Outlet ICountry Code (ISO value) of terminal carrying out ICC c}c °
transaction — value = 826
{Terminal Serial Number 133 I an 8 Outlet [Unique and permanent identification number of chip terminal °
Terminal Transaction Date I 146 I n 6 Outlet IContains transaction date in format YYMMDD used by ICC in °
igenerating the cryptogram for ICC transaction
Terminal Verification 131 h 10 Outlet Status of different ICC functions as seen from terminal cic °
Results (TVR)
Time, Local Transaction I 012 n 6 I Outlet fromIAs printed on receipt, transaction request time in Local Time in I M I M M
System Iformat hhmmss.
Track 2 Data 03s I z 37 I Outlet fromI Track 2 image. cle c
LLVAR card
Transmission Date and 007 n 10 I Sender IDate and time of transmission of the message (not carried MIM M
Time orward from previous message). format MMDD hhmmss. The
time base used in the message varies dependant on sender.
NBX - sets as GMT (DST)
A&L — Sets as UTC
This data is therefore not carried forward from previous
messages.
Unpredictable Number 132 I fh 8 I Generated IValue providing variability and uniqueness to generation of the I C I C °
by terminal Iapplication cryptogram for an ICC transaction.
* systems Trace Audit Number [011] Time Local Transaction [012], Retrieval Reference Number [037] and Card Acceptor Terminal Identification [041] uniquely identify a transaction when combined.
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0 Page 24 of 48
FUJ00003486
FUJ00003486
FUJ00003486
FUJ00003486
NBX-A&L Application Project: EMV — Banking and Retail
Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Created on 15/08/2005 Version 4.0 Page 25 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
4.2 Data Interpretations
This section contains the definition of each message type to be sent over this interface. The Message
Element column lists those elements required for the message according to LISS, and relates to the list in
Section 4.1. However, rows are sometimes shaded in grey. This indicates that the specific message will not
include this data element in this interface.
The Required column in the message definition tables within this section contain the following codes:
Code Meaning
M The element is mandatory for this message
Cc The element is conditional for this message, and the condition to be applied is
stated in the Conditions column. If the condition is true, the element must be
present in the message, otherwise the element must not be present in the
message. It should be noted that the receiving system may not be able to
assess whether the condition has been met, in which case it must be able to
interpret the presence or non-presence of the element according to appropriate
business rules.
fe} Optional (see Message Definitions below for specific rules)
The Conditions column lists the conditions for inclusion of a conditional message element; inclusion of the
element may depend on details of the transaction type, or simply whether the data is available to the sending
system.
The message definitions given in the sections below do not include primary bitmaps. Primary, secondary and
tertiary bitmaps will be used as required.
It is essential that developers of this interface also refer to the NBX A&L Mapping document, (Ref. [6]) for
further details of data derivation and use.
Some fields on response messages from A&L are simply copies of fields from the request message. Where
this is the case these fields are indicated with the text ‘Echoed’ in the Notes column. Where fields are copied
from internal NBX fields to messages by the NBX these fields are indicated with the text ‘Copied’.
FUJ00003486
FUJ00003486
‘ NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification
i Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.1 [R3] - Balance Enquiry
4.2.1.1 Overview
This message is sent by the NBX to A&L. The message requests a balance enquiry transaction.
The [R3] Balance Enquiry message maps to the following A&L message:
e 0100 - Balance Enquiry
4.2.1.2 Message Definition
Message Element LISS Bitmap I Required I Notes / Conditions
Reference
Bit Map Secondary 001 c
Primary Account Number 002 M
Processing Code 003 M 310000 for Balance Enquiry
‘Amount, Cardholder Billing 006 Not required
‘Transmission Date and Time 007 M
Conversion Rate, Cardholder Billing 010 Not required
Systems Trace Audit Number on M
Time, Local Transaction 012 M
Date, Local Transaction 013 M
Date, Expiration 014 c Required for manually key entered balance enquiry
transaction
Date, Settlement 015 M ‘Acquirer's settlement date
Point of Service Entry Mode 022 M Please refer to section 4.1.2 for values
‘Application PAN Sequence Number 023 c Required for ICC transactions, or if the card's
issue number has been manually entered
Point of Service Condition Code 025 M Please refer to section 4.1.2. for contents of the
field
‘Aequiring Institution Identification 032 M
ode
Forwarding Institution Identification 033 Not required
ode
Track 2 Data 035 c Will not be present where card details manually
entered.
Retrieval Reference Number 037 M Please refer to section 4.1.2. for contents of the
field
Card Acceptor Terminal Identification 041 M
Card Acceptor Name / Location 043 M
Currency Code, Transaction 049 M
Currency Code, Cardholder Billing 051 Not required
PIN Data 052 Cc Required if PIN used
Advice / Reversal Reason Code 060 c Required for ICC transactions
Point of Service Data 061 M Please refer to section 4.1.2 for values
Message Authentication Code 064 Not to be sent to A&L for this implementation.
Bit Map Tertiary 065 c Required for ICC transactions
‘Terminal Capability Profile 130 Cc Required for ICC transactions
‘Terminal Verification Results 131 c Required for ICC transactions
Unpredictable Number 132 Cc Required for ICC transactions
‘Terminal Serial Number 133, ° Optional for ICC transaction - to be inserted if
available
Issuer Application Data 134 c Required for ICC transactions
Cryptogram (ARQC) 136 c Required for ICC transactions
Application Transaction Counter 137 Cc Required for ICC transactions
Application Interchange Profile 138 c Required for ICC transactions
Cryptogram Transaction Type 144 c Required for ICC transactions
Terminal Country Code 145 Cc Req'd for ICC transactions — see section 4.1.2 for
value
‘Terminal Transaction Date 146 Cc Required for ICC transactions
Cryptogram Amount 147 c Required for ICC transactions
Cryptogram Currency Code 148 Cc Required for ICC transactions
Message Authentication Code 192. Not required in this implementation
Created on 15/08/2005 Version 4.0 Page 27 of 48
© Post Office™ 2004-2005
NBX - A&L Application
Interface Specification
Project:
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
FUJ00003486
FUJ00003486
EMV ~ Banking and Retail
4.2.2 [R3] - Financial Transaction Request - Withdrawal
4.2.2.1 Overview
This message is sent by the NBX to A&L. The message requests a withdrawal transaction.
The [R3] Financial Transaction Request message maps to the following A&L message:
e 0200 - Financial Transaction Request.
4.2.2.2 Message Definition
Message Element LISS Bitmap I Required I Notes / Conditions
Reference
Bit Map Secondary 001 c Required for ICC transactions
Primary Account Number 002 M
Processing Code 003 M 010000 for Financial Transaction
‘Amount, Transaction 004 M
‘Amount, Cardholder Billing 006 Not required
Transmission Date and Time 007 M
Conversion Rate, Cardholder Billing 010 Not required
Systems Trace Audit Number O11 M
Time, Local Transaction 012 M
Date, Local Transaction 013 M
Date, Expiration 014 Cc Required for manually key entered withdrawal
transaction
Date, Settlement Oe M ‘Acquirer's settlement date
Point of Service Entry Mode 022 M Please refer to section 4.1.2 for values.
Application PAN Sequence 023, Cc Required for ICC transactions, or if the card's
issue number has been manually entered
Point of Service Condition Code 025 M Please refer to section 4.1.2 for contents of the
field
‘Amount, Transaction Fee: 028 Not required - acquirer charge will not be used
‘Acquiring Institution Identification 032 M
Code
Forwarding Institution Identification 033 Not required,
Code
Track 2 Data 035 Cc Will not be present where card details manually
entered.
Retrieval Reference Number 037 M Please refer to section 4.1.2. for contents of the
field
Card Acceptor Terminal Identification 4 M
Card Acceptor Identification Code 042 M
Card Acceptor Name / Location 043 M
Currency Code, Transaction 049 M
Currency Code, Cardholder Billing 054 Not required
PIN Data 052 Cc Required if PIN used
‘Advice / Reversal Reason Code 060 Cc Required for ICC and fallback transactions
Point of Service Data 061 M Please refer to section 4.1.2 for values
Message Authentication Code 064 Not to be sent to A&L for this implementation.
Bit Map Tertiary 065 c Required for ICC transactions
‘Authorisation Data 123 c Sub Field 18 contains start date of card ifit exists
and card details are manually entered
Terminal Capability Profile 130 c Required for ICC transactions
Terminal Verification Results 134 c Required for ICC transactions
Unpredictable Number 132 Cc Required for ICC transactions
Terminal Serial Number 133 io) Optional for ICC transaction
issuer Application Data 134 c Required for ICC transactions
Cryptogram (ARQC) 136 Cc Required for ICC transactions
Application Transaction Counter 137 c Required for ICC transactions
Application Interchange Profile 138 c Required for ICC transactions
Cryptogram Transaction Type 144 c Required for ICC transactions
Terminal Country Code 145 Cc Req'd for ICC transactions — see section 4.1.2 for
value
Created on 15/08/2005 Version 4.0
© Post Office™ 2004-2005
Page 28 of 48
NBX - A&L Application
Interface Specification
FUJ00003486
FUJ00003486
Project: EMV ~ Banking and Retail
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
‘Terminal Transaction Date 146 Cc Required for ICC transactions
Cryptogram Amount 147 Cc Required for ICC transactions
Cryptogram Currency Code 148 c Required for ICC transactions
Message Authentication Code 192 Not required in this implementation
Created on 15/08/2005 Version 4.0
© Post Office™ 2004-2005
Page 29 of 48
FUJ00003486
FUJ00003486
NBX-A&L Application — Project: EMV ~ Banking and Retail
Interface Specification
i Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.3 [R3] - Financial Transaction Request - Deposit
4.2.3.1 Overview
This message is sent by the NBX to A&L. The message details a cash deposit request. Cheque
deposits and mixed deposits, ie cash and cheques in one transaction, will not be supported on this
interface.
The [R3] Financial Transaction Request message maps to the following A&L message:
e 0200 - Financial Transaction Request
4.2.3.2 Message Definition
Message Element LISS Bitmap I Required I Notes/ Conditions
Reference
Bit Map Secondary 001 Cc Required for ICC transactions
Primary Account Number (002 M
Processing Code 003 M 210000 for cash deposit
‘Amount, Transaction 004 M
‘Amount, Cardholder Billing 006 Not required
‘Transmission Date and Time 007 M
Conversion Rate, Cardholder Billing (010 Not required
Systems Trace Audit Number O11 M
Time, Local Transaction 012 M
Date, Local Transaction 013 M
Date, Expiration 014 c Required for manually key entered deposit
transaction
Date, Settlement 015 M ‘Acquirer's settlement date
Point of Service Entry Mode 022 M Please refer to section 4.1.2 for values
‘Application PAN Sequence Number 023 c Required for ICC transactions, or if the card's
issue number has been manually entered
Point of Service Condition Code 025 M Please refer to section 4.1.2 for contents of the
field
‘Amount, Transaction Fee 028 Not required - acquirer charge will not be used
‘Acquiring Institution Identification 032 M
Code
Forwarding Institution Identification 033 Not required.
ode
Track 2 Data 035 c Will not be present where card details manually
entered.
Retrieval Reference Number 037 M Please refer to section 4.1.2 for contents of the
field
Card Acceptor Terminal Identification 041 M
Card Acceptor Identification Code 042 M
Card Acceptor Name / Location 043 M
Currency Code, Transaction 049 M
Currency Code, Cardholder Billing 051 Not required
PIN Data 052 Not required for deposit transactions
‘Advice / Reversal Reason Code 060 c Required for ICC transactions and fallback
transactions
Point of Service Data 061 M Please refer to section 4.1.2 for values
Message Authentication Code 064 Not to be sent fo A&L for this implementation.
Bit Map Tertiary 065 c Required for ICC transactions
Authorisation Data 123 Cc Sub Field 18 contains start date of card if it exists
and card details are manually entered
‘Terminal Capability Profile 130 Cc Required for ICC transactions
Terminal Verification Results 131 Cc Required for ICC transactions
Unpredictable Number 132 c Required for ICC transactions
Terminal Serial Number 133 ) Optional for ICC transaction — to be inserted if
available
Issuer Application Data 134 Cc Required for ICC transactions
Cryptogram (ARQC) 136 Cc Required for ICC transactions
Application Transaction Counter 137 Cc Required for ICC transactions
Created on 15/08/2005 Version 4.0 Page 30 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification
i Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
‘Application Interchange Profile 138 Cc Required for ICC transactions
Cryptogram Transaction Type 144 Cc Required for ICC transactions
Terminal Country Code 145 Cc Req'd for ICC transactions — see section 4.4.2 for
value
‘Terminal Transaction Date 146 c Required for ICC transactions
Cryptogram Amount 147 c Required for ICC transactions
Cryptogram Currency Code 148 c Required for ICC transactions
Message Authentication Code 192 Not required in this implementation
Created on 15/08/2005 Version 4.0 Page 31 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
‘ NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification
i Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.4 [A1] - Balance Enquiry Response
4.2.4.1 Overview
This message is sent by A&L to the NBX. The message contains a balance enquiry response.
The [A1] Balance Enquiry Response message maps to the following A&L messages:
e 0110 - Balance Enquiry Response
4.2.4.2 Message Definition
Message Element TiSS Bitmap I Required I Notes/ Conditions
Reference
Bit Map Secondary 001 M
Primary Account Number 002 M Echoed from the request message
Processing Code (003 M Echoed from the request message
‘Amount, Cardholder Billing 006 Not required
‘Transmission Date and Time 007 M
‘Conversion Rate, Cardholder Billing 010 Not required
Systems Trace Audit Number 11 M Echoed from the request message
Time, Local Transaction 012 M Echoed from the request message
Date, Local Transaction 013 M Echoed from the request message
Date, Settlement 015 M ‘A&L settlement date
Application PAN Sequence 023 Cc Echoed from the request message if present
Acquiring Institution Identification 032 M Echoed from the request message
Code
Forwarding Institution Identification 033 Not required because not in request.
ode
Retrieval Reference Number 037 M Echoed from the request message
Response Code 039 M
Card Acceptor Terminal Identifier 041 M Echoed from the request message
Currency Code, Transaction 049 M Echoed from the request message
Currency Code, Cardholder Billing 051 Not required
‘Additional Amounts 054 M For a decline, the length of this field must be set to
‘000"
Bit Map Tertiary 065 Cc Required for ICC transactions
‘Account Identification 1 102 M NBX does not pass this field to the counter
systems
Authorising Agent Institution Id Code 113, M
Issuer Trace Id 126 M
Message Authentication Code 128 Not fo be Sent to A&L for this implementation.
Application Transaction Counter 137 c Required for ICC transactions
Issuer Authentication Data 139 c Required for ICC transactions (omitted if cannot
be generated)
Issuer Script 142 ° Atlssuer's discretion
Message Authentication Code 192, Not required in this implementation
Created on 15/08/2005 Version 4.0 Page 32 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.5 [A1] - Financial Transaction Request Response - Withdrawal
4.2.5.1 Overview
This message is sent by A&L to the NBX. The message contains a withdrawal request response .
The [A1] Financial Transaction Request Response message maps to the following A&L message:
e 0210 - Financial Transaction Request Response.
Note that A&L will never return a partial authorisation.
4.2.5.2 Message Definition
Message Element USS Bitmap I Required I Notes/ Conditions
Reference
Bit Map Secondary 001 M
Primary Account Number (002 M Echoed from the request message
Processing Code 003 M Echoed from the request message
‘Amount, Transaction 004 M Echoed from the request message
‘Amount, Cardholder Billing 006 Not required
‘Transmission Date and Time 007 M
Conversion Rate, Cardholder Billing O10 Not required
Systems Trace Audit Number on M Echoed from the request message
Time, Local Transaction 012 M Echoed from the request message
Date, Local Transaction 013 M Echoed from the request message
Date, Settlement 015 M ‘A&L settlement date
Application PAN Sequence 023 Cc Echoed from the request message if present
‘Amount, Transaction Processing Fee 030 Cc Field will not be returned by A&L in an A&L denied
transaction.
‘Acquiring Institution Identification 032 M Echoed from the request message
Code
Forwarding Institution Identification 033 Not required because not in request.
ode
Retrieval Reference Number 037 M Echoed from the request message
Response Code 039 M
Card Acceptor Terminal Identifier 041 M Echoed from the request message
Currency Code, Transaction 049 M Echoed from the request message
Currency Code, Cardholder Billing 051 Not required
‘Additional Amounts, 054 Cc Required if available from issuer
Bit Map Tertiary 065 Cc Required for ICC transactions
‘Account Identification 1 102 M NBX does not pass this field to the counter
systems
Authorising Agent Institution Id Code 113, M
Authorisation Response Data 124 Not required in NBX implementation
Issuer Trace Id 126 M
Message Authentication Code 128 Not to be Sent to A&L for this implementation.
Application Transaction Counter 137 Cc Required for ICC transactions
Issuer Authentication Data 139 Cc Required for ICC transactions (omitted if cannot
be generated)
Issuer Script 142 ° At Issuer's discretion
Message Authentication Code 192 Not required in this implementation
Created on 15/08/2005 Version 4.0 Page 33 of 48
© Post Office™ 2004-2005
NBX - A&L Application
Interface Specification
Project:
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
FUJ00003486
FUJ00003486
EMV ~ Banking and Retail
4.2.6 [A1] - Financial Transaction Request Response - Deposit
4.2.6.1 Overview
This message is sent by A&L to the NBX. The message contains a deposit request response.
The [A1] Financial Transaction Request Response message maps to the following A&L message:
e 0210 - Financial Transaction Request Response.
Note that A&L will never return a partial authorisation.
4.2.6.2 Message Definition
Message Element Bitmap Required I Notes/ Conditions
Reference
Bit Map Secondary 001 M
Primary Account Number 002 M Echoed from the request message
Processing Code 003 M Echoed from the request message
‘Amount, Transaction 004 M Echoed from the request message
‘Amount, Cardholder Billing 006 Not required
Transmission Date and Time 007 M
Conversion Rate, Cardholder Billing O10 Not required
Systems Trace Audit Number on M Echoed from the request message
Time, Local Transaction 012 M Echoed from the request message
Date, Local Transaction 013 M Echoed from the request message
Date, Settlement 015 M A&L settlement date
Application PAN Sequence 023 Cc Echoed from the request message if present
‘Amount, Transaction Processing Fee 030 Cc Field will not be returned by A&L ina A&L denied
transaction.
‘Acquiring Institution Identification 032 M Echoed from the request message
‘ode
Forwarding Institution Identification 033 Not required because not in request,
ode
Retrieval Reference Number 037 M Echoed from the request message
Response Code 039 M
Card Acceptor Terminal Identifier O41 M Echoed from the request message
Curreney Code, Transaction 049 M Echoed from the request message
Currency Code, Cardholder Billing 051 Not required
‘Additional Amounts, 054 Cc Required if available from issuer
Bit Map Tertiary 065, Cc Required for ICC transactions
‘Account Identification 1 102 M Not used by NBX
‘Authorising Agent Institution Id Code 113 M
‘Authorisation Response Data 724 Not used in the NBX implementation
Issuer Trace Id 126 M
Message Authentication Code 128 Not to be Sent to A&L for this implementation.
Application Transaction Counter 137 Cc Required for ICC transactions
Issuer Authentication Data 139 c Required for ICC transactions (omitted if cannot
be generated)
Issuer Script 142 ° At Issuer's discretion
Message Authentication Code 192 Not required in this implementation
Created on 15/08/2005 Version 4.0
© Post Office™ 2004-2005
Page 34 of 48
FUJ00003486
FUJ00003486
NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.7 [E1] - Reversal Request
4.2.7.1 Overview
This message is sent by the NBX to A&L when a financial transaction that has been processed by the
issuer needs to be reversed.
The [E1] message maps to the following A&L messages:
e 0420 - Reversal Request
e 0421 - Reversal Repeat.
A Reversal Request [E1] can only be generated when the [A1] message to be reversed can be mapped
against a [R3] request.
Reversal Requests may be sent up to a (configurable) period, initially set to 5 days, after the original
transaction to which it refers.
Note that partial reversals are not supported over this interface.
4.2.7.2 Message Definition
Message Element Bitmap Required] Notes / Conditions
Reference
Bit Map Secondary 001 M
Primary Account Number (002 M
Processing Code (003 M Copied from the [Ai]
‘Amount, Transaction 004 M
‘Amount, Cardholder Billing (006 Not required
‘Transmission Date and Time 007 M
Conversion Rate, Cardholder Billing 10 Not required
Systems Trace Audit Number O11 M
Time, Local Transaction 012 M
Date, Local Transaction 013 M
Date, Expiration 014 c Required if present on original transaction. Copied
from original transaction
Date, Settlement 015 M Copied from the [R3]
Merchant type 018 Not required
‘Acquiring Institution Country Code 019 Not required
Point of Service Entry Mode 022 M
Application PAN Sequence Number 023 Cc Required if present on original transaction
Point of Service Condition Code 025 M
‘Amount, Transaction Fee 028 Not required - acquirer charge will not be used
‘Acauiring Institution Identification 032 M
Code
Forwarding institution Identification 033 Not required
ode
Track 2 Data 035 Cc Required if present on original transaction
Retrieval Reference Number 037 M
‘Authorisation identification Response 038 Not required
Response Code 039 M Copied from the [A1]
Card Acceptor Terminal Identifier 041 M
Card Acceptor Identification Code 042 M
Card Acceptor Name / Location 043 M
Currency Code, Transaction 049 M
Currency Code, Cardholder Billing 051 Not required
‘Advice / Reversal Reason Code 060 M
Point of Service Data 061 M
Bit Map Tertiary 065 c Required for ICC transactions if any of the optional
fields included
Original Data Elements 090 M
Replacement Amounts 095 Not required
Created on 15/08/2005 Version 4.0 Page 35 of 48
© Post Office™ 2004-2005
NBX - A&L Application
Interface Specification
Project:
Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
FUJ00003486
FUJ00003486
EMV — Banking and Retail
‘Account Identification 4 102 M Copied from original transaction. Space filled if no
data is available
‘Authorisation Response Data Zi Not used in the NBX implementation
‘Authorisation Data 123 c Required if present on original transaction
Issuer Trace Id 126 M
Terminal Capability Profile 130 ° Optional for ICC transactions. Copied from original
transaction
Terminal Verification Results 73 (o) Optional for ICC transactions.
This should contain the latest TVR which may be
different to that in the original request. If the latest
TVR is unavailable, the value in the original
request should be used
Unpredictable Number 132 ° Optional for ICC transactions. Copied from original
transaction
Terminal Serial Number 133 Optional for ICC transactions. Copied from original
transaction
Issuer Application Data TH Optional for ICC transactions.
This should contain the latest [AD which may be
different to that in the original request. If the latest
IAD is unavailable, the value in the original request
should be used
Cryptogram (ARQC) 136 ° Optional for ICC transactions.
This should contain the ARQC from the 2 Gen
‘AC command or if unavailable, the ARQC from the
4% Gen. AC command
Application Transaction Counter 137 ° Optional for ICC transactions. Copied from original
transaction
‘Application Interchange Profile 738 ) Optional for ICC transactions. Copied from original
transaction
Cryptogram Transaction Type 144 [o) Optional for ICC transactions. Copied from original
transaction
Terminal Country Code 145 ) Optional for ICC transactions. Copied from original
transaction
Terminal Transaction Date 146 ° Optional for ICC transactions. Copied from original
transaction
Cryptogram Amount 147 ° Optional for ICC transactions. Copied from original
transaction
Cryptogram Currency Code 148 ) Optional for ICC transactions. Copied from original
transaction
Message Authentication Code 792 Not required in this implementation
Note: NBX does not include any of the Optional fields.
Created on 15/08/2005
© Post Office™ 2004-2005
Version 4.0
Page 36 of 48
FUJ00003486
FUJ00003486
‘ NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification
i Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.8 [E2] - Reversal Request Response
4.2.8.1 Overview
This message is sent by A&L to the NBX in response to a reversal request from the NBX.
The [E2] message maps to the A&L message 0430.
4.2.8.2 Message Definition
Message Element TiSS Bitmap I Required I Notes / Conditions
Reference
Bit Map Secondary 001 M
Processing Code 003 M Echoed from the 042x message.
‘Amount, Transaction 004 M Echoed from the 042x message.
Transmission Date and Time 007 M Echoed from the 042x message.
Systems Trace Audit Number on M Echoed from the 042x message.
Time, Local Transaction 012 M Echoed from the 042x message.
Date, Local Transaction 013 M Echoed from the 042x message.
Date, Settlement 015 M Echoed from the 042x message.
Application PAN Sequence 023 Cc Required if present on original transaction
‘Acquiring Institution Identification 032 M Echoed from the 042x message.
‘ode
Forwarding Institution Identification 033 Not required
ode
Retrieval Reference Number 037 M Echoed from the 042x message.
Response Code 039) M
Currency Code, Transaction 049 M Echoed from the 042x message.
Bit Map Tertiary 065 c Required for ICC transactions
Original Data Elements 090 M Echoed from the 042x message.
Replacement Amounts 095 Not required
Authorisation Response Data 124 Not required
‘Authorisation Data 123 Not required
Issuer Trace Id 126 M Echoed from the 042x message.
‘Application Transaction Counter 137 Cc Required for ICC transactions if present in
reversal request. Copied from request
Cryptogram Transaction Type 144 () Optional for ICC transactions. Copied from original
transaction
Message Authentication Code 122 Not required in this implementation
Created on 15/08/2005 Version 4.0 Page 37 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application — Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.9 Administration Advice (0620)
4.2.9.1 Overview
Administration advice messages are sent to/from A&L in order to initiate investigation of a problem by
either A&L or the NBX.
The Administration advice message maps to LISS message 0620.
4.2.9.2 Message Definition
Message Element LISS Bitmap I Required I Notes/ Conditions
Reference
Bit Map Secondary 001 M
Transmission Date and Time 007 M
Systems Trace Audit Number O11 M
Network Management information 070 M Set to be 900
Code
Info Text 724 M
Created on 15/08/2005 Version 4.0 Page 38 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV — Banking and Retail
Interface Specificati
Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.2.10 Network Management Messages (0800 / 0810)
The following Network Management Messages will be exchanged between A&L and the NBX:
e 0800 - Network Management Request Message
* 0810 - Network Management Response Message
They are used for the following purposes (followed by associated Network Management Information Code) and
the designation of NBX/A&L denotes which party may initiate the particular message:
Message Type NMIC Initiator
Log On 061 AL
Log On al NBX
Log Off 062 AL
Log Off 072 NBX
Key Change 161 AL
Key Change Request 181 NBX
Online Key Verification 199 ‘A&L (Note — not used by A&L)
End of Day (Cutover) 271 NBX
Handshake 361 AL
Handshake 371 NBX
The usage, sequence and inter-relation between these and other messages is defined in the body of the
document “LINK Switch Service Interchange Standard (LIS5)” (Ref. [4] and in Appendix C1 of the “LISS
Security Standard” section of that document under Network Management Option 2, (Ref. [8]).
4.2.10.1 Network Management Request (0800)
Message Element TiSS Bitmap I Required I Notes/ Conditions
Reference
Bit Map Secondary 001 M
Transmission Date and Time 007 M
Systems Trace Audit Number O11 M Set for this transaction — a new STAN is used when a
(0800 message is repeated
Network Management information 070 M Values will depend on message purpose, as described
Code above.
Message Security Code 096 c Required for key change, key verification, logon and
logoft
Network Management Information 125 Cc Required for key change and key verification
Note: The 0800 End of Day message is sent to A&L based on a timed event at 20:00. An 0810 Message
response is mandated with a zero response code. This message is to be repeated for a limited number of
times and to a timed interval to be specified in configurable parameters. When the repeat number is
exceeded then operational procedures are to be followed.
4.2.10.2 Network Management Request Response (0810)
Message Element LISS Bitmap I Required I Notes/ Conditions
Reference
Bit Map Secondary 001 M
Transmission Date and Time 007 M
Systems Trace Audit Number on M Echoed from the 0800
Response Code 039) M
Network Management Information 070 M This is echoed from the 0800 received message.
Code
Created on 15/08/2005 Version 4.0 Page 39 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV — Banking and Retail
Interface Specificati
Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
4.1.11 Reconciliation and Settlement
4.1.1.1 Overview
A Reconciliation Report is sent to A&L each day, providing a record per A&L transaction for that
Settlement day. The file transfer mechanism and conditions of transfer are described in the NBX — A&L
Technical Interface Specification, (Ref. [1]), and the Reconciliation File Format (Ref. [3]).
Created on 15/08/2005 Version 4.0 Page 40 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application — Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
5 Transfer Structure
5.1 Transfer Grouping
The following figure shows the end to end message sequences, using the RACE (Request / Authorise /
Confirm / Exception) model, for all application messages between the NBX and A&L.
_. ASL enn
‘a fa iN
i os t oa oaks
~ oe [Ez] [os20 1 eal REC
y¥ I] [4
\ v a
"7" NBX ~
Horizon ‘sso -
Counter Systems DRS
Figure 1 - A&L Message Flows in the Network Banking Environment
An 0620 message may be issued by the NBX in response to all messages from A&L (for simplicity, only some
such flows are shown on the diagram).
Reversals (0420/0421 messages) are not sent from NBX to A&L unless and until an approved response (0210
message) has been received from A&L. Repeat reversals (0421) are only sent in the event that the prior 0420
(or 0421) reversal messages have not had a response processed at the NBX.
Created on 15/08/2005 Version 4.0 Page 41 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application — Project: EMV ~ Banking and Retail
Interface Specification
P Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
NBX will use the new settlement date without waiting for a response from A&L. A&L may receive authorisation
requests with the previous settlement date after it has received the End of Day Cutover, because of
parallelism.
The interface should be resilient to the transfer of duplicate messages; in practice, however, this should only
happen after failure and recovery of either end of the interface.
A&L will not validate transmission date and time in messages against the date and time that messages are
received.
The interface details are also described in the NBX — A&L Technical Interface Specification (Ref. [1])
5.2 Transfer Structure
The messages defined in this AIS will be exchanged in accordance with Section 3 of the LINK Switch Service
Interchange Standard (LIS5), (Ref. [4]), which describes the use of Message Type Identifier, Bit Map and Data
Elements in the message structure. Note that the messages exchanged over this interface use the third bit
map for the ICC data elements.
Messages for one transaction may be interleaved with messages for any other transaction.
5.3 Record Structure
The record structure for the messages defined in this AIS is as described in the LISS Interchange Standard,
(Ref. [4]). The details are not repeated here.
The record structure for the Reconciliation File passed over this interface is described in NBX-A&L
Reconciliation File Format (Ref. [3]). The details are not repeated here.
5.4 Sequences
Figure 1 above (see Section 5.1) shows the end to end message sequences of all the messages supported by
this AIS, from the PO Outlet to the issuing financial institution.
Further detail relating specifically to the NBX — A&L connection can be found in the NBX — A&L Technical
Interface Specification (Ref. [1]). The interface must be resilient to the disconnection or loss of any part of the
total network banking environment for short or extended periods.
5.5 Data Volumes
Data rates and volumes over this interface are addressed through the document NB Volume Model
Comparisons [Ref. [5]).
5.6 Data Authentication
For this implementation, Message Authentication Codes (MACs) will not be included in the messages sent
between the NBX and A&L.
5.7 Data Dictionary
The Data Elements used on this interface are defined and described within section 4.1.2
Created on 15/08/2005 Version 4.0 Page 42 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
‘ NBX — A&L Application Project: EMV ~ Banking and Retail
Interface Specification Doc Ref: NB/IFS/026
COMMERCIAL IN CONFIDENCE
Created on 15/08/2005 Version 4.0 Page 43 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX - A&L Application Project: EMV — Banking and Retail
Interface Specification Doc Ref:
COMMERCIAL IN CONFIDENCE
6 Security of Transmitted Data
The security standards for the A&L-NBX interface are described in the NBX — A&L Technical Interface
Specification (Ref. [1]).
6.1 Protected Data
PIN blocks that pass across the interface from NBX to A&L are encrypted under an Acquirer Working Key
(AWk). This key is used in the A&L — NBX shared security zone. PIN Block encryption is translated from
internal keys to protection under this shared key using a hardware encryption module. The PIN blocks are
never rendered in clear outside the hardware module.
Acquirer Working Keys are exchanged electronically under a Acquirer Zone Master Key (AZMK) shared
between Fujitsu Services and A&L. The AZMK is generated and owned by Fujitsu Services. The AWK is
owned and generated by A&L.
6.2 Encryption and Decryption Methods
PIN Block and Acquirer Working Key transmission is protected by Triple DES double length keys, 112bit plus
key check data.
6.3 Session Establishment
Session Establishment can be initiated by A&L or NBX. Initial Logon messages exchanges are followed by
transmission by A&L to NBX of a new AWK (with a key check value) protected by encryption under the shared
current AZMK.
NBX verifies the key and acknowledges it to A&L. All PIN Block data is protected by this AWK until the
session ends or the AWK is renewed.
6.4 Key Management
Key ownership is described in the NBX — A&L Technical Interface Specification (Ref. [1]). A&L - NBX Acquirer
Zone Management Keys are managed by the Horizon Key Management Application (KMA) with manual
processes.
According to local manual processes the NBX staff will:
e Generate three new AZMK components
«Transfer the AZMK components onto secure stationery
e Key components will contain
* Akey identifier (visible)
e Akey generation date (visible)
e Acomponent number (visible)
e 32 hex characters in eight groups of four characters — component plus check data (hidden)
e Provide a Key Check value
e Load the keys into the Horizon KMA
FUJ00003486
FUJ00003486
NBX-A&L Application —_ Project: EMV ~ Banking and Retail
Interface Specification Doc Ref:
COMMERCIAL IN CONFIDENCE
The Horizon KMA:
e Activates keys for use by Horizon Agents, which manage the TCP/IP connections to A&L.
Key component documents must be stored and transported separately and securely (see the Operational
Level Agreement (Ref. [2])). .
The A&L — NBX AZMK is renewed every six months by this manual procedure. The AZMK, having been
produced as described above, is securely transported, manually, to A&L. This is followed by the manual
promotion of the AZMK, where the Next AZMK becomes the Current AZMK. It is recommended that after
promotion of the keys, an A&L Operator issue a command to drive an AWK Key change request sequence, in
order to test that the verified AZMK has been promoted by both parties.
A&L requires more than one Processor Interface (PI) to support the transaction throughput for the NBX. For
this configuration each PI will be configured to support one TCP/IP socket connection. A logical session will
be initiated by a logon, and data for that session will flow over the socket connection belonging to that PI (see
Ref. [6] for further details). Each PI generates an A&L-NBX Acquirer Working Key (AWK) which it sends to
NBX for validation. This AWK, if validated by the NBX, is used between NBX and the PI that generated it.
Logical sessions for a different PI will use the AWK generated by that PI. All A&L Pls will protect their AWK in
transit to NBX by encryption using the same AZMK, during its six months of currency.
The AWKs are changed under the following conditions.
«Every 24 hours where the session remains active (an AWK may be changed at a set (configurable) clock
time and will remain valid until it is changed)
e At-session initiation by either party
* Onreceipt by A&L of a 6" consecutive invalid PIN block on a session (note that Fujitsu Services is not
required to track invalid PIN blocks)
e When an A&L operator requests a key change (NBX can request a key change in theory but in practice
NBX will force a Log off / Log on).
Load balancing between the Pls will be performed by the NBX ensuring that the appropriate AWK for the PI is
used for PIN block translation.
It has been agreed that:
e A&L support the use of the current and previous AWK
e NBX can start using new AWK received from A&L for encryption as soon as it is received
e« NBX and A&L must be able to carry on normal business, including ability to accept new AWK keys, while
AZMK is being changed
« There may be a short outage at the FI (typically up to 90 seconds) while the manual process for changing
the AZMK is under way.
Created on 15/08/2005 Version 4.0 Page 45 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application —_ Project: EMV ~ Banking and Retail
Interface Specification Doc Ref:
COMMERCIAL IN CONFIDENCE
7 Operational Procedures
7.1 Processing Cycles
This interface relates to online message exchange to support real time financial transactions, and to the daily
transmission from NBX of the Reconciliation and Settlement file.
Timed out (“Stale”) messages are logged and discarded before transmission or on receipt, as appropriate.
Please refer to section 7.4 for details of which message types can be discarded (i.e. non “Must deliver”
messages).
“Must deliver” messages are retransmitted at parameter intervals until delivery is successful, as described in
the NBX Operational Procedures Manual, (Ref. [2]).
In this section a transaction, which is referred to as discarded, must be logged after receipt, prior to being
discarded.
7.2 Transfer Initiation
All transfers defined in this AIS are automatic.
7.3 Security Procedures
Manual Procedures are required to support the above key management protocol, as described in Section 6.
They will need to be agreed between the A&L operator and the NBX operator for inclusion / reference in the
Operational Level Agreement (OLA) between them.
Two key components shall be sent to nominated key component holders in Alliance and Leicester, a third will
be carried to A&L by an NBX key component holder who will be responsible for entering it into the key
management system.
The A&L and NBX key management system must not require that the financial transaction processing system
be taken off line to install AZMK components and to activate the new AZMK. Access to the Key Management
System, its security hardware and associated commands must be restricted to the key manager.
7.4 Fallback Procedures
Fallback procedures are described in the NBX — A&L Technical Interface Specification, (Ref. [1]).
Each system is responsible for its own recovery after failure. Restoration of the interface and the disposal of
stale messages (other than “must deliver” messages) is expected to be automatic. 0100 [R3], 0200 [R3], 0110
[A1], 0210 [A1], 0620 and 0800 Network Management messages awaiting transmission at the time of failure
can safely be discarded, as the integrity of the transaction is protected by timeouts.
Failures which impact non-transient (or "must-deliver") messages, require recovery actions to ensure their
eventual delivery. In the case of messages from A&L to the NBX, A&L will retain such messages and they will
be resent once a connection is found to be re-established (by means of periodic handshakes). In the case of
messages from the NBX to A&L, the NBX will continue to retain messages and A&L will resume the fetching of
such messages as soon as connections are re-established.
Created on 15/08/2005 Version 4.0 Page 46 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application —_ Project: EMV ~ Banking and Retail
Interface Specification Doc Ref:
COMMERCIAL IN CONFIDENCE
The only messages categorised as “must deliver” are Network Management (0800) and Reversal Request
(0420/0421) messages - see Section 6 of the LINK Switch Service Interchange Standard (LISS), (Ref. [4]).
Sign On, Sign Off, Key Change and Key Change Request 0800 messages are “must deliver” but do not have
to survive across processes when moving from active to standby sites.
Handshake 0800 messages are sent every few minutes anyway (which is sufficient).
End of Day 0800 and Reversal Request 0420/0421 messages are “must deliver” messages and do have to
survive when moving from active to standby sites.
Please note that there may be manual operational re-alignment required should messages that were thought
to have been delivered turn out to have been lost.
7.5 Downgrade Transactions
A ‘Downgrade’ transaction is one where an IC Card has been used at an ICC enabled terminal, but the card
issuer has advised, via POL reference data (dependent upon IIN), that the card must not be processed as ICC.
The on-line message will be formatted as a standard magnetic stripe transaction.
Nothing, apart from the Track 2 Service Code in the on-line LISS Message sent to A&L, will indicate that an IC
Card was used.
Note that in the case of a Downgrade transaction, data must not be used from the IC, but that normal
procedures must be followed as for magnetic stripe cards.
7.6 Control
The interface must be resilient to duplicate messages, which may occur after recovery of any element in the
system, but are not otherwise expected to occur.
Lost or discarded messages are handled by timeout processing at every stage of the “RA” message sequence,
to ensure that incomplete transactions are declined if unauthorised or reversed if authorised.
The NBX will log events affecting this interface (e.g. response indicating receipt by A&L of an invalid PIN
block) to an Event Log. These events will be managed by Tivoli for escalation to the relevant Help Desk, as
appropriate to the code associated with the event.
Created on 15/08/2005 Version 4.0 Page 47 of 48
© Post Office™ 2004-2005
FUJ00003486
FUJ00003486
NBX-A&L Application —_ Project: EMV ~ Banking and Retail
Interface Specification Doc Ref:
COMMERCIAL IN CONFIDENCE
8 Appendix A
The document NBX-A&L Mapping (Ref. [6]) contains the complete mapping from Horizon to/from the NBX
to/from A&L .
END OF DOCUMENT
Created on 15/08/2005 Version 4.0 Page 48 of 48
© Post Office™ 2004-2005