Get documents about "acquirer - PAN - Nordic Card Association
Document Sample
BABS and CEKAB
Software & Parameter Download
VERSION 2.3
2007-02-15
Page: 1 of 71
Babs and CEKAB Software & Parameter Download version 2.3
CONTENT:
1 EFFECTIVE DATES ..................................................................................................................... 10
2 INTRODUCTION .......................................................................................................................... 10
2.1 THIS DOCUMENT ....................................................................................................................... 10
2.2 ARCHITECTURE OF A TMS ........................................................................................................ 10
3 OVERVIEW OF DOWNLOAD SYSTEM .................................................................................. 11
4 THE COMMON FILE FORMAT ................................................................................................ 12
4.1 ENCAPSULATION OF CONTENT................................................................................................... 12
4.2 FIELD DESCRIPTIONS ................................................................................................................. 12
5 THE TRIGGER FUNCTION ....................................................................................................... 14
6 THE CONTROL FILE .................................................................................................................. 15
6.1 GENERAL .................................................................................................................................. 15
6.2 LAYOUT OF THE CONTROL FILE ................................................................................................. 16
7 PARAMETER FILES .................................................................................................................... 17
7.1 GENERAL .................................................................................................................................. 17
7.2 THE MASPAR FILE .................................................................................................................. 19
7.2.1 Option_flgs ....................................................................................................................... 19
7.2.2 Additional parameters ...................................................................................................... 19
7.3 THE DCPAR FILE ..................................................................................................................... 20
7.3.1 Transaction descriptor ..................................................................................................... 21
7.3.2 App_Option_Flgs ............................................................................................................. 22
7.3.3 AID_Bitfield...................................................................................................................... 22
7.3.4 A RID data set .................................................................................................................. 23
7.4 THE BINPAR FILE .................................................................................................................... 24
7.4.1 The complete BINPAR-file................................................................................................ 24
7.4.2 The BINDOL entry ........................................................................................................... 25
7.4.3 A BIN row ......................................................................................................................... 25
7.4.3.1 Bitfields_1 .................................................................................................................... 27
7.4.3.2 Bitfields_2 .................................................................................................................... 27
7.4.3.3 Bitfields_3 .................................................................................................................... 27
7.4.3.4 Bitfields_4 .................................................................................................................... 27
7.4.3.5 Bitfields_5 .................................................................................................................... 28
7.4.3.6 Extra_Data_Set Only valid for integrated solutions and special environment ............. 28
7.4.3.7 Bitfield Send_Track...................................................................................................... 29
7.4.3.8 Bitfields_Unattended_Gasoline .................................................................................... 29
7.5 THE CAPUB FILE ..................................................................................................................... 30
7.5.1 The complete file............................................................................................................... 30
7.5.2 A key data set .................................................................................................................... 30
7.6 OTHER PARAMETER FILES ......................................................................................................... 31
8 APPLICATION FILES ................................................................................................................. 31
9 FETCHING THE FILES ............................................................................................................... 31
9.1 TERMINAL REQUIREMENTS ....................................................................................................... 31
9.1.1 Download SW ................................................................................................................... 31
9.1.2 TCP/IP and FTP support .................................................................................................. 32
9.1.3 Alternative protocols ........................................................................................................ 32
9.1.4 Security functions ............................................................................................................. 32
9.2 FTP DOWNLOAD SESSION .......................................................................................................... 32
9.2.1 FTP fundamentals ............................................................................................................ 32
9.2.2 Example download session ............................................................................................... 32
Page: 2 of 71
Babs and CEKAB Software & Parameter Download version 2.3
9.3 FIRST DOWNLOAD ..................................................................................................................... 33
9.4 LOADING FILES FROM OTHER SERVERS...................................................................................... 34
...................................................... APPENDIX A – RULES FOR BER-TLV DATA OBJECTS
.................................................................................................................................................................. 35
A.1. CODING OF BER-TLV DATA OBJECTS...................................................................................... 35
A.1.1. Coding of the Tag Field of BER-TLV Data Objects ......................................................... 35
A.1.2. Coding of the Length Field of BER-TLV Data Objects .................................................... 36
A.1.3. Coding of the Value field of Data Objects ........................................................................ 36
A.2. DEVIATIONS FROM THE STANDARD ........................................................................................... 36
A.2.1. Use of Tag Number ........................................................................................................... 37
A.2.2. Data Object Lists .............................................................................................................. 37
.............................................. APPENDIX B – DOWNLOAD VIA PROPRIETARY SYSTEMS
.................................................................................................................................................................. 38
B.1. SOFTWARE DOWNLOAD ............................................................................................................. 38
B.2. PARAMETER DOWNLOAD ........................................................................................................... 39
.......................................... APPENDIX C – ALTERNATIVE PPL DOWNLOAD PROTOCOL
.................................................................................................................................................................. 40
C.1. PROPERTIES OVERVIEW ............................................................................................................. 40
C.1.1. Client – server .................................................................................................................. 40
C.1.2. Binary data ....................................................................................................................... 40
C.1.3. Checksum.......................................................................................................................... 40
C.1.4. ACK/NAK ......................................................................................................................... 40
C.1.5. Block Number ................................................................................................................... 40
C.2. DETAILED DESCRIPTION ............................................................................................................ 41
C.2.1. Frame format .................................................................................................................... 41
C.2.2. File Request Message (FRQ) ............................................................................................ 41
C.2.3. Block Request Message (BRQ) ......................................................................................... 41
C.2.4. Response Message (RSP).................................................................................................. 42
C.2.5. File Confirm Message (FCM) .......................................................................................... 42
C.2.6. Terminal Processing ......................................................................................................... 43
C.2.7. Server Processing ............................................................................................................. 43
C.2.8. Timeouts ........................................................................................................................... 43
C.3. EXAMPLE FILE TRANSFER SESSION ............................................................................................ 44
C.4. PROTOCOL OPTIONS .................................................................................................................. 44
.................................. APPENDIX D – EXPLANATION OF PARAMETER USE & FORMATS
.................................................................................................................................................................. 45
D.1. FORMAT SPECIFICATIONS .......................................................................................................... 45
D.2. THE MASPAR FILE................................................................................................................... 46
D.2.1. Tag 9F34 Option flags...................................................................................................... 48
D.3. THE DCPAR FILE ...................................................................................................................... 49
D.3.1. Transaction descriptors. ................................................................................................... 51
D.3.2. App_Option_Flgs ............................................................................................................. 53
D.3.3. AID Bit field...................................................................................................................... 54
D.4. THE BINPAR FILE .................................................................................................................... 55
D.4.1. Bitfields_1 ......................................................................................................................... 57
D.4.2. Bitfields_2 ......................................................................................................................... 58
D.4.3. Bitfields_3 ......................................................................................................................... 59
D.4.4. Bitfields_4 ......................................................................................................................... 59
D.4.5. Bitfields_5 ......................................................................................................................... 60
D.4.6 Extra_Data_Set Only valid for integrated solutions and special environment ................ 61
D.4.7 Bitfield Send Track ........................................................................................................... 61
D.4.8 Bitfields_Unattended_Gasoline ........................................................................................ 62
D.5. THE CAPUB FILE ...................................................................................................................... 62
.............................................. APPENDIX E – HANDLING OF KEY DOWNLOAD TO PED:S
.................................................................................................................................................................. 63
E.1. GENERAL .................................................................................................................................. 63
Page: 3 of 71
Babs and CEKAB Software & Parameter Download version 2.3
E.2. THE INITIAL KEY FILE – SA (IKFS) CONTENT .......................................................................... 63
E.2.1. The complete file content .................................................................................................. 63
E.2.2. The Initial Key data set content ........................................................................................ 64
E.3. THE PPL KEYS FILE (PKF) CONTENT........................................................................................ 64
E.3.1. The complete file content .................................................................................................. 64
E.3.2. The PPL Key data set content........................................................................................... 64
E.4. TERMINAL PROCESSING ............................................................................................................. 65
E.4.1. The PPL-client .................................................................................................................. 65
E.4.2. The Key Files and the Control File .................................................................................. 65
E.4.3. Fetching terminal parameter files .................................................................................... 66
E.4.4. Fetching key files .............................................................................................................. 66
E.4.4.1. Fetching .................................................................................................................... 66
E.4.4.2. Additional keys ......................................................................................................... 67
E.4.4.3. Downloading of keys ................................................................................................ 67
............................................ APPENDIX F – ADDITIONAL PARAMETER FILES FOR IPOS
.................................................................................................................................................................. 68
F.1. GENERAL .................................................................................................................................. 68
F.2. THE IPOSTEXT FILE ................................................................................................................ 68
F.3. THE IPOSCONF FILE ................................................................................................................ 69
F.3.1. AID_Bitfield...................................................................................................................... 69
F.3.2. iPOS_Config_Bitfield ....................................................................................................... 71
Page: 4 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Revision History:
VERSION DATE DESCRIPTION ISSUED BY
0.4 (Draft) 2001-03-10 First Issue Robert G. Jonsson
0.5 (Draft) 2001-03-13 Minor changes Robert G. Jonsson
0.6 (Draft) 2001-09-07 Added flag for CV2 required. Robert G. Jonsson
Added flag for forced magstripe fallback allowed.
TAC: s can now be different for different RIDS in
DCPAR.
Changed tags and structure of CAPUB file.
Added example of FTP downloads processing.
0.7 (Draft) 2001-11-16 Appendix C added. Robert G. Jonsson
Added info on PAN-length.
Added counter byte in trigger.
Added bit ”Issuer country not known” in Bitfields_2
of binrow.
Added Application Terminal-ID field to Control File
record.
Added values for Handling Code in Control File
Removed TSP_Ref_Nbr from MASPAR file.
Removed methods not yet supported from security
info
0.8 (Draft) 2002-01-19 Changed IP-address/port format for all occurances Robert G. Jonsson
including in Control File.
Updated Control File example.
Added general information on length and format for
parameters.
Added information on format for many parameters.
Added IP-address/port to B24 in DCPAR file.
Put all TAC:s and default TDOL and PDOL in
"RID_data_set" in DCPAR file
Changed name of tag 91 in Bin Row.
Added information on CAPUB MAC verification
procedure.
Format for telephone numbers changed to be used
"as is", i.e. country code only included if required.
0.9 (Draft) 2002-01-22 Corrected error in tag format in DCPAR file: Robert G. Jonsson
tag 9F53 BF53 (3 occurrancies)
1.0 2002-06-11 Added minimum purchase amount in binrow Robert G. Jonsson
Added flags in binrow bitfields according to request
from Babs and CEKAB:
In Bitfields_1: Only online and handle as magstripe
In Bitfields_3:: Manual input of transaction allowed.
1.1 2002-09-17 Changed length of MAC to 8 bytes to comply with Robert G. Jonsson
current TSAM. Corrected length of BINDOL.
Added Appl_version_number in RID data set
Added reference to parameter explanation appendix.
Corrected comment to tag 84 in BINPAR file
1.2 2002-12-17 Changed tag of Appl_version_number in RID data Robert G. Jonsson
set to 9F5C to avoid conflict with secondary IP
address to B24
Included Appendix E – Handling of Key download
to PED:s
1.3 2004-01-19 Updated Appendix E (file contents) Robert G. Jonsson
Added clarifications according to list from meeting
Included Appendix D in main document
1.4 2004-01-27 Removed all references to T-SAM. Robert G. Jonsson
Updates according to audit meeting.
Updated Appendix E – file content & name setting
1.41 2004-03-30 Additional explanation handling activation date/time Börje Thörne
Page: 5 of 71
Babs and CEKAB Software & Parameter Download version 2.3
in the control file.
Deposit and withdrawal added in the transaction
descriptor.
Daily settlement removed, parameters set to RFU
(reserved for future use).
Print extra removed in bitfields_3, parameter set to
RFU.
1.5 2004-12-03 Bitfield_2; ? replaced with Y for bit 5 and bit 2. Börje Thörne
Explanation of zeroes in version date and time and
in activation date and time added.
New trigger added.
Minor changes in flowcharts.
Padding in FRQ request specified.
2.0 2005-06-23 Chapter 1, “Effective date” added. Babs and CEKAB
Chapter 4.2, header version 02 deleted.
Chapter 6.1, unknown files shall not be fetched.
Chapter 7.1, field length „ll‟ explained.
MASPAR following field modified
Appl_Environment
DCPAR following added
AID_bitfield
Parameters for random selection
Additional Data Required for a specific
RID
BINPAR following modified
Extra_data_Set_table added
BINDOL updated
*B changed, PAN length must be 12-19
(from 13-19)
BIN row following modified
Bitfields_4 added
Bitfields_5 added
Max_Amo_Refund added
Extra_Data_Set_Index added
Bitfields_3 (bit 8, 7 and 1) updated
Extra_Data_Set added
Appendix D updated with coulms for stand alone
and integrated solutions
Appedix F added for integrated solutions
2.1 2005-10-26 Chapter 7.4.3.6, corrected Tag 9F7C to BF7C Babs and CEKAB
DCPAR following changed
Added the 1.5 specification of the AID-list
Changed the new AID-list to only the
AID_Bitfield list
BINPAR following changed
Added 9F3E to the Extra Dataset
Bitfields_2, bit 4, name changed to “This is
a national card”
Chapter 9.1.2, added PASV to the commands to use
with FTP. The mode of FTP has to be agreed with
the TSP.
Chapter 5, trigger 22x explanation updated. The
value of third byte of the handling code is not
allowed to be zero.
Chapter D.3, Corrected tag 9F38 to BF38 as in the
file description.
Chapter 4.2, Protection-type 10 removed from File
Security Info and Content Security Info.
Chapter 6.2, The length of the file, specified in the
control file, is not used.
Page: 6 of 71
Babs and CEKAB Software & Parameter Download version 2.3
2.2 2006-09-07 Chapter 1, changed the effective dates. Babs and CEKAB
Chapter 4.1, key reference for unsigned files
defined.
Chapter 6.2. handling codes clarified and the field
format for terminal-ID is changed from N to AN
including to rules for justifying and padding.
Chapter 7.3, the length of the tag BF38 is changed to
80.
Chapter 7.4.1, added information about sort order of
the Prefix table.
Chapter 7.4.3.6, the length of the tag BF6F is
changed to 80.
Appendix E, editorial changes in the text, some
flowcharts deleted and modified keynames.
Appendix F, filename for the iPOSTEXT is changed
to IPOSTEXT.
Appendix F, text in F2 updated.
Appendix F, the tag numbers for the IPOSTEXT file
is corrected.
Appendix F, format of the data is added to the
IPOSTEXT description.
Appendix F, mac length changed from 4 to 8 bytes.
Appendix F, filename for the iPOSCONFIG is
changed to IPOSCONF.
Appendix F, the tag numbers for the IPOSCONF file
is corrected.
Appendix F, format of the data is added to the
IPOSCONF description.
2.3 2007-02-15 Chapter 1 Rewritten.
Chapter 4.2 The length of MAC signatures is
clarified.
Chapter 6.1 Added extra information about the
controlfile.
Chapter 7.2 Updated the description of tag 9F2A.
Chapter 7.2 Updated the description of tag 9F33.
Chapter 7.3 The tag 9F41 and 9F43 is obsoleted.
Chapter 7.3 Added tag for handling of Max Len
Store and Forward bigger than 99.
Chapter 7.3 Added tag for handling of Max Nbr
Store and Forward bigger than 99.
Chapter 7.3 Added tag for terminaltype.
Chapter 7.3.4 editorial changes of the descriptions of
the tags 9F54, 9F59 and 9F5C.
Chapter 7.4.1 Added Card Issuer Table.
Chapter 7.4.1 Added Card Type Table.
Chapter 7.4.3 Added tag Card_Issuer_Index.
Chapter 7.4.3 Added tag Card_Type_Index.
Chapter 7.4.3.6 Changed name and description for
the tag 9F3E.
Chapter 7.4.3.7 Added information about the bitfield
Send Track.
Chapter 7.5 Editorial changes of the description for
tag 9F73.
Chapter D.2 Updated the description of tag 9F2A.
Chapter D.2 Updated the description of tag 9F33.
Chapter D.3 Updated the description of tag 9F41.
Chapter D.3 Updated the description of tag 9F43.
Chapter D.3 Added tag for handling of Max Len
Store and Forward bigger than 99.
Chapter D.3 Added tag for handling of Max Nbr
Page: 7 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Store and Forward bigger than 99.
Chapter D.3 Added tag for terminaltype.
Chapter D.3 editorial changes of the descriptions of
the tags 9F54, 9F59 and 9F5C.
Chapter D.3.1 Clarification about the number of
Transaction Descriptors sent to the terminal.
Chapter D.4 Added Card Issuer Table.
Chapter D.4 Added Card Type Table.
Chapter D.4 Added tag Card_Issuer_Index.
Chapter D.4 Added tag Card_Type_Index.
Chapter D.4 changed the description for tag 9F3E
Chapter D.4.7 Added description for bitfield Send
Track.
Chapter D.5 Editorial changes of the description for
tag 9F73.
Chapter F.2 Corrected the tag numbers.
Chapter E.4.4.2 Removed the possibility to use more
than one IKFS-file.
Page: 8 of 71
Babs and CEKAB Software & Parameter Download version 2.3
GLOSSARY:
AID Application identifier – identifies an application in a smart card
APC Acquiring Processing Center – A DPC operated by an Acquirer e.g. Babs
ATM Automated Teller Machine
CA Certification authority
CA-keys Keys issued by a CA (Visa I or Europay I)
CAM Card Authentication Method
CEPS Common Electronic Purse Specifications (issued by Europay I, Visa I etc.)
CVC2/CVV2 Card Verification Value
CVM Cardholder Verification Method
DDA Dynamic Data Authentication
DPC Data Processing Center
ECR Electronic Cash Register
EFTPOS Electronic Funds Transfer at Point Of Sale
EMV Europay Mastercard Visa
EPI Europay International
ICC Integrated Circuit Card
ICS Integration Comformance Specification
IFD InterFace Device
IPC Independent Processing Center – a DPC operated by an Independent agency e.g. CEKAB
iPOS Integrated solution for card handling at point of sales
KMF Key Management Facility
MA Master Application
MAC Message Authentication Code – change protection
MOTO Mail Order, Telephone Order
MPC Merchant Processing Center – a DPC operated by a Merchant group e.g. ICA
PAN Primary Account Number
PIN Personal Identification Number
PINPAD Keyboard used by cardholder for entering PIN
PIX Product Index, part of the AID
POS Point Of Sale – e.g. "POS terminal"
RID Registered application provider identifier
RSA Rivest, Shamir, Adleman (the inventors of) a cryptographic algorithm
SAM Secure Access Module
SDA Static Data Authentication
SSP Security Service Provider
TAC Terminal Action Codes – a set of decision flags used in EMV processing
TC Transaction Certificate
TMS Terminal management system
TSP Terminal service provider
VAT Value Added Tax
Page: 9 of 71
Babs and CEKAB Software & Parameter Download version 2.3
1 Effective dates
This specification applies for both iPOS applications and stand-alone terminal
applications. Before an implementation or an update is initated the functionality shall
be agreed with Babs or/and CEKAB.
All terminal applications must be able to receive all parameters. If a tag in the
parameter files is unknown to the terminal, it must be ignored and the tag and the data
belonging to the tag must be dropped, see also Local Handling for SPDH-connected
terminals.
2 Introduction
2.1 This Document
This document is intended for terminal vendors and any organisations involved in
development or operation of systems related to download of software and parameters
into POS terminals connected to Babs or CEKAB. The document is free to use as a
guideline for other parties, but will be maintained jointly by Babs and CEKAB.
The document describes the requirements on download of parameters and software
modules in an infrastructure designed to handle the new requirements presented by
terminals that are EMV compliant and multifunctional, i.e. can handle more than one
application.
2.2 Architecture of a TMS
A Terminal Management System (TMS) in the widest possible sense, is the sum of all
systems required for deployment and administration of EFTPOS terminals, from both a
technical and a business viewpoint. This document is focused on the distribution and
maintenance of applications and parameters, leaving things like generation of invoices
for terminal hire etc. aside.
Functions may be distributed to several components, but conceptually the overall
responsibility lies with a single entity – the Terminal Service Provider (TSP).
The Terminal Service Provider is responsible for loading and keeping track of the
applications and parameters resident in the terminal. The Terminal Management
System is the tool used by the TSP to fulfil this obligation. For a particular terminal
there is only one TSP. The TSP may have to receive data to be downloaded into the
terminals from several sources.
The TSP is not a new organisation, it is a role that can be upheld by a DPC, a terminal
vendor or an Acquirer. The most likely is the organisation that "owns" the terminal,
e.g. KF, ICA or Statoil would probably act as TSP for their terminals but rely on data
received from an Acquirer for maintaining a debit/credit application.
Page: 10 of 71
Babs and CEKAB Software & Parameter Download version 2.3
3 Overview of Download System
The download system procedures and formats described in this document assumes that
the terminals can fetch complete files with a file transfer protocol capable of handling
binary data. The preferred method is FTP over TCP/IP.
TSP
TMS
Download Download APC/IPC
Server Server System
SPDH
parameter files control files
trigger
SW modules parameter files
SW modules
FTP FTP
The picture above illustrates some of the important properties of the download system:
A terminal can fetch files from a download server using FTP over TCP/IP. The
download server is a part of the TMS used by the TSP responsible for the terminal.
The terminal can also fetch files from a download server belonging to another TMS
or acquirer.
The terminal must be able to receive a trigger in the response to an on-line
transaction towards a host application. The trigger tells the terminal to fetch a
control file from a download server.
The control file tells the terminal which version of parameter files and SW modules
it is expected to use. If the version in the terminal is different from the version in
the control file, the terminal will do a download of the new parameter or SW file.
The TMS must be able to receive and deliver files from/to other operators, such as
acquirers, DPC:s, KMF:s etc. In a multi-application environment this is even more
Page: 11 of 71
Babs and CEKAB Software & Parameter Download version 2.3
important.
The components of the download system are described in more detail in the following
chapters.
4 The Common File Format
4.1 Encapsulation of content
All files start with a header that serves to identify the content and important attributes
of the file. The header is fixed format but some fields may be irrelevant for certain file
types. The standard file format is shown below. The grey areas are unchanged if the
file has to be forwarded one or more times before reaching the ultimate destination.
Header Version
File Type
File Name
Date & Time Created
Creator Id
Data Length
Sender Id
Destination Id
File security Info
Content Security Info
Variable
Length
Content
Content MAC/Signature
File MAC/Signature
4.2 Field descriptions
2N Header Version
Format:
2 N Version number of header:
standard header (as above) = '01'
6 AN File Type
Description:
This field implicitly defines the context and format of the file content. Shall not be checked by
the terminal.
Page: 12 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Format:
3 AN Unique designation of an organisation (supplied by Babs and/or CEKAB)
3 N Unique number within an organisation. (selected by the organisation)
20 AN File Name
Format:
20 AN The actual filename left justified padded with blanks.
12 N Date & Time Created
Format:
12 N Creation date/time of the complete file:YYMMDDHHMMSS
8 AN Creator Id
Format:
8 AN Identity of the creator of the file content, left justified and padded with blanks
(used as part of a key reference so name conflicts should be avoided)
10 N Data Length
Format:
10 N Length of the variable length content, right justified with leading zeroes
8 AN Sender Id
Format:
8 AN Designation of the sender
(used as part of a key reference so name conflicts should be avoided)
8 AN Destination Id
Format:
8 AN Designation of the intended receiver
6 N File Security Info
Format:
2 N Type of protection. Values:
'11' = MAC according to Recommended Cryptographic Methods ISO, triple DES with double
length keys over SHA-1 digest of part protected 8 byte file MAC. Note that 64-bit MAC
signatures is used even though SAC in the XXXX specification requires 32-bit signatures,
the reason for this is historical.
'??' = Other values reserved for future use (RFU).
'99' = none (used for initial keyloading, not to be used for files destined for a terminal). Note, no
binary zeros will be reserved for MAC/Signature.
2 N Part protected. Values:
'10' = file header (including File Security Info)
'11' = whole file
'99' = none (used for initial keyloading, not to be used for files destined for a terminal)
Page: 13 of 71
Babs and CEKAB Software & Parameter Download version 2.3
2 N Key reference. Values:
'nn' = together with Sender Id uniquely defines a key to be used for verification.
'99' = none (used for initial keyloading, not to be used for files destined for a terminal)
6 N Content Security Info
Format:
2 AN Type of protection. Values:
'11' = MAC according to Recommended Cryptographic Methods ISO, triple DES with double
length keys over SHA-1 digest of part protected 8 byte file MAC. Note that 64-bit MAC
signatures is used even though SAC in the XXXX specification requires 32-bit signatures,
the reason for this is historical.
'??' = Other values reserved for future use (RFU).
'99' = none (used for initial keyloading, not to be used for files destined for a terminal). Note, no
binary zeros will be reserved for MAC/Signature.
2 AN Part protected. Values:
'12' = content (including Content Security Info)
'99' = none (used for initial keyloading, not to be used for files destined for a terminal)
2 AN Key reference. Values:
'nn' = together with Creator Id uniquely defines a key to be used for verification.
'99' = none (used for initial keyloading, not to be used for files destined for a terminal)
5 The Trigger Function
The new SPDH specification allows a "trigger field" (Fid 9o) in the response to an
authorisation request that, if present, tells the terminal that new parameters or a new or
updated software module is available. It forces the terminal to fetch a terminal specific
control file from the TSP's download server. The control file specifies the name and
version of all files that the terminal is expected to use, and the IP-address/port of the
download server holding each file. The format of the trigger field is as follows:
VAR Trigger
Format:
3 AN Handling code – also implicitly defines length and content of the rest of the
field. Values (more values may be defined):
'11x' Fetch now, send reversal of current transaction if approved.
'12x' Fetch now, no more transactions to this host before fetch.
'13x' Fetch ASAP, reminder prompt to operator between transactions.
'21x' Fetch according to date and time in trigger.
'22x' Fetch at next occurrance of “social call time” in terminal, i.e. “social
call day” is not used.
'51x' Fetch IKFS<PED-Id> and corresponding PKF-file according to date
and time in trigger
xx AN Additional Info depending on handling code. Currently only defined for
handling code 21x and 51x in which case additional info is date and time in
the
format YYMMDDHHMMSS (xx = 12).
For the other handling codes defined above xx = 0.
Page: 14 of 71
Babs and CEKAB Software & Parameter Download version 2.3
For future handling codes requiring additional info, the maximum length of
additional info is 47 characters (xx = 47).
The third byte of the handling code (x) is a single numeric digit, incremented from 1 to
9 with wrap around every time a new trigger is set. When a trigger is received in an
authorisation response, the terminal should compare the handling code to the previous
received and saved value and only if they differ should the terminal fetch the control
file and save the new handling code. This is to avoid repeated fetch of the control file
if the terminal does several transactions before the trigger can be removed in the host
system.
Example of a trigger: ..<RS>o219020402050000<FS>..
The character string above shows subfid o of fid 9 in an SPDH response (the layout
assumes that subfid o is the last subfid in fid 9 and that other fid:s follow) and the
message to the terminal is: "fetch the control file from your TSP download server at
05:00 on april 2nd 2002".
6 The Control File
6.1 General
Fetching of the control file is initiated by one of several possible conditions:
On terminal power on when the start-up software detects that all or part of
application software and/or parameters are missing or corrupted.
During terminal operation if a trigger field is present in the response to an online
request to a particular host application.
When a certain (parameterised) time has elapsed since the last transaction towards
a particular host application.
As a result from a manual command (key sequence) on the terminal.
The control file is normally fetched from the TSP download server, the IP-address and
port number of which must be known by the terminal.
The control file lists the name and version of the application and parameter files that
are expected to be used by the terminal. Files not known by the terminal applications
shall be ignored i.e. not fetched. There is one control file per terminal, and the name of
the control file is created from the TSP Terminal-ID. It is allowed to have more then
one entry in the control file to describe what sw-files to be downloaded for a specific
terminal and its applications.
If a Debit/Credit Application consists of more than one file, the application record in
the control file will point to another control file, the DCAPP Control file.
The DCAPP Control file consists of the file records for the application files, specified
in the same way as the standard control file. The terminal shall download the
application files in the same way as the files in the standard control file.
The terminal vendor is responsible to supply the extra control file together with the
application files. The TSP shall format the DCAPP control file according to the
Common File Format specified in chapter 4, before download to the terminals.
Page: 15 of 71
Babs and CEKAB Software & Parameter Download version 2.3
The DCAPP control file shall be hosted on the same PPL-server as the standard control
file. Note that the files specified in the DC APP Control file may be hosted on another
server in the same way as parameter files in the standard Control File.
For an "empty" terminal to be installed remotely, the communication parameters and
the TSP Terminal-ID has to be loaded into the terminal manually on-site or before
delivery.
The files that are specified in the control file will not be arranged in any specific order.
6.2 Layout of the control file
The control file consists of a number of fixed size records encapsulated according to
the common file format. The layout of each record is as follows:
20 AN Filename/version
8 AN Filename, left justified padded with underscores
12 AN version, YYMMDDHHMMSS
8N Length, right justified with leading ascii zeroes (Not used).
12 N Activation date/time, YYMMDDHHMMSS
16 AN Application Terminal-ID, must be numeric. The terminal ID by which the
particular application should identify itself to the application host. For
parameter files, this field (Application Terminal-ID) can be set to the
terminal ID or spaces. The field is, left justified and padded with spaces to
its maximum length.
47 AN Handling info
2N Handling code. Values (more values may be defined):
00 = no special handling, no Close Batch required
01 = using this appl. version requires parameter reload
02 = Close Batch must be done before load
03 = do Close Batch, then total reload
04 = do total reload, no Close Batch required. Only used in
emergency situations, loss of data will occur.
..
21 AN IP-address/port dotted decimal format, ex:192.168.8.100:9999
The field is, left justified and padded with blanks to its
maximum length.
16 AN phone number including area code and possibly country code
The field is, left justified and padded with blanks to its
maximum length.
Examples: 0855666130 for a terminal in Sweden or
0046855666130 for a terminal outside Sweden
8 AN Sender ID. The field is, left justified and padded with blanks to its
maximum length.
Handling codes 01, 02 and 03 requires that the terminal is able to empty the Store &
Forward queue and send a Close Batch online.
If the version date and time is set to zeroes the current file in the terminal should be
used (no file should be fetched).
Page: 16 of 71
Babs and CEKAB Software & Parameter Download version 2.3
If the terminal receives a control file and some files have the activation date/time set to
a future date, the terminal shall store those files for activation at the specified date and
time. If a new control file is received by the terminal, before the activation date is
passed (and the specified files stored in the terminal are changed in the control file),
the stored files should be erased and the files according to the control file should be
downloaded. If the activation date and time is set to all zeroes the file should be
fetched and installed.
Terminals that can‟t save files for later activation should ignore the activation date and
time. If a new version of a file is present in the control file the terminal should fectch
and install the new file.
The phone number is intended for the case where a PSTN, GSM or ISDN connection
must be dialled before the session can be established.
Example control file:
<standard header (including File Security Info)>
<content security info>
MASTER__02040108300000000924020401090000111111111111111102192.168.8.1
00:9999 0855666130 CEKAB
MASPAR__02040108300000000924020401090000000000000000000002192.168.8.1
00:9999 0855666130 CEKAB
DCAPP___02040108300000000924020401090000111122223333444402192.168.8.1
00:9999 0855666130 CEKAB
DCPAR___02040108300000000924020401090000000000000000000002192.168.8.1
00:9999 0855666130 CEKAB
BINPAR__02040108300000000924020401090000000000000000000002192.168.8.1
00:9999 0855666130 CEKAB
CAPUB___02040108300000000924020401090000000000000000000002192.168.8.1
00:9999 0855666130 CEKAB
<content MAC/signature>
<file MAC/signature>
7 Parameter Files
7.1 General
For a multiapplication terminal it is necessary that each application can download the
parameters it requires to run in the particular environment. An application fetches the
required parameters bundled together in one or more files that follows the common file
format. The master application, which is the application running when the terminal is
idle, handles parameters that are not used directly by any other application, or are
common to all applications as part of the operating environment.
The parameter files described in this document (i.e. the files required to run an EMV
Debit/Credit application) all use a tagged format in the content part of the file. The
format used is called ASN.1 with BER encoding and is also used with chip parameters
in the interaction with the EMV chip card. The format is described in detail in ITU-T
recommendation X.690. An overview of the subset used here is also given in Appendix
A to this document.
As a consequence of the BER encoding, individual parameters and fields are not
readily accessible from the download file. Therefore it is strongly recommended that a
Page: 17 of 71
Babs and CEKAB Software & Parameter Download version 2.3
file is parsed only once (immediately after it has been downloaded and verified), and in
the process relocate the recognised objects to their internal, directly accessible storage.
Also note that the tags defined for parameters in the files described below, are only
valid in the context of parsing the files. The tag for a parameter that is also defined in
EMV, is not equal to the EMV defined tag other than by coincidence. This is because
EMV has reserved all one and two byte tags for the EMV specification itself and for
the payment systems, leaving nothing for all the non EMV related parameters. This is
not a problem however, once a parameter has been located to its internal storage, it can
be associated with its proper EMV tag where applicable.
For all parameters, the length (hex) given in the Len column indicates the maximum
length. The file may contain a parameter padded to its maximum length or just the
actual value. In any case, the L part of the TLV format always gives the actual length.
The terminal application must allocate storage for the maximum length but always use
the received L value when parsing the file.
Fields with length „var‟ indicates that the length is variable and defined in the
description of the field.
For parameters containing a binary numeric value, the bytes are always aligned in
"network byte order".
Page: 18 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.2 The MASPAR File
The MASPAR (MASter application PARameter) file contains parameters that are
independent of any payment scheme and has the following layout:
Lev Tag Len Value Description
01 BF20 80 MASPAR file The complete content as a constructed value
02 9F22 28 Merchant_Name The merchant‟s name – max 40 characters.
02 9F23 28 Merchant_adress Visiting address – max 40 characters
02 9F24 28 Merchant_City City name including zip code – max 40 characters
02 9F25 0B Organization_Nbr format: nnnnnn-nnnn
02 9F26 18 Bank_Agent_Name May be printed in the receipt header
02 9F27 04 Country_Code According to ISO 3166
02 9F28 01 Social_Call_Day Max number of days between control file polls. See
description in appendix D.
02 9F29 04 Social_Call_Time HHMM: suitable time to call TSP and fetch control file
02 9F2A 01 Dial_Type New applications shall ignore this tag. The value of the
tag shall not be used. Always set the value to “P” for
backward compability.
02 9F2B 10 Prim_Phn_Nbr_TSP Primary phone number for TSP.
02 9F2C 10 Sec_Phn_Nbr_TSP Secondary phone number for TSP.
02 9F2D 15 Prim_IP_adr_TSP Primary IP-address/port for TSP
02 9F2E 15 Sec_IP_adr_TSP Secondary IP-address/port for TSP
02 9F2F 05 Phone_Nbr_Prefix Digits required to dial through PABX or similar to PSTN
02 9F30 10 Helpdesk_Text Technical helpdesk phone number (TSP)
02 9F31 06 User_Password Password required for certain functions
02 9F32 01 Password_Flgs Bitmap describing functions that may be protected (RFU)
02 9F33 01 Appl_Environment New applications shall ignore this tag. The value of the
tag shall not be used. Always set the value to “S” for
backward compability.
02 9F34 01 Option_flags Described below
02 9F35 04 VAT_Per Default VAT percentage – 2500 means 25%
02 9F36 10 Merchant_phone_number Phone number including area code to the merchant.
Should be printed on the receipt.
01 00 00 EOC
7.2.1 Option_flgs
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Tip handling enabled Y Y
x 1 x x x x x x Coat Room handling enabled Y Y
x x 1 x x x x x Ask for ref number (e.g. table) Y Y
x x x 1 x x x x VAT display option. Note a) Y Y
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Note a) If this option is set, the terminal should always display and allow change of VAT amount.
If not set, the corresponding option in the prefix row for the card will decide.
7.2.2 Additional parameters
Parameters that may be required in the future or for particular terminal types/brands,
may be added to the MASPAR file, or can be collected in a separate parameter file,
provided that the Master Application knows the name of the new file.
Page: 19 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.3 The DCPAR File
The DCPAR (Debit/Credit PARameter) file contains parameters that are specific for a
debit/credit application and has the following layout:
Lev Tag Len Value Description Mag Chip
01 BF40 80 The DCPAR file The whole file as a constructed data object.
02 9F41 02 Max_Len_Sf This tag is only supplied for backward Y Y
compability, the tag Max_Len_SF2 shall be
used instead. Max number of transactions in
S&F (chip and magstripe). See description
in appendix D.
02 9F42 06 Max_Amo_Sf Max accumulated mag amount in S&F Y N
before terminal must go online.
02 9F43 02 Max_Nbr_Sf This tag is only supplied for backward Y N
compability, the tag Max_Nbr_SF2 shall be
used instead. Max number of mag
transactions in S&F before terminal must
go online.
02 9F8106 02 Max_Len_SF2 Max number of transactions in S&F (chip
and magstripe). See description in appendix
D.
02 9F8107 02 Max_Nbr_SF2 Max number of mag transactions in S&F
before terminal must go online.
02 9F44 05 Pan_Min_Max Format: NN:NN Min/Max number of PAN Y Y
digits handled by the terminal. Used as
(manual) entry check before prefix check
02 9F45 14 Receipt_Head_L_1 Printed on top of receipt if not empty Y Y
02 BF46 80 Trans_control_Table "Sequence of transaction descriptors" Y Y
03 9F47 03 First descriptor See description below.
03 9F47 03 Second descriptor |
| | | | |
03 9F47 03 Last descriptor |
02 00 00 EOC
02 9F48 04 Close_Batch_Time format: HHMM Y Y
02 9F49 10 Prim_Phn_Nbr_B24 The actual phone number to be dialled, Y Y
contains area number and may contain
country prefix
02 9F4A 10 Second_Phn_Nbr_B24 -"- Y Y
02 9F5A 15 Prim_IP_adr_B24 IP-address/port AN21 padded with blanks
ex:: "192.168.8.100:9999 "
02 9F5B 15 Sec_IP_adr_B24 -"-
02 9F4B 01 MAC-Scheme V = VDUKT, M = Master/Session Y Y
02 9F4C 01 App_Option_Flags See description below Y Y
02 9F4D 04 Acquirers_Ref_Nbr The aquirers customer number referencing Y Y
the agreement with the customer, packed
decimal (BCD).
02 9F4E 03 Term_Capabilities Shall be set according to the ICS for the N Y
level 2 certification for the specific
terminal. For further information see EMV
Book 4 Annex A.2.
02 9F4F 05 Add_Term_ Capabilities Shall be set according to the ICS for the N Y
level 2 certification for the specific
terminal. For further information see EMV
Book 4 Annex A.3.
02 BF50 80 AID list “Sequences of AID:s” N Y
03 9F51 var First AID 5byte RID and max 11 byte PIX
Page: 20 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Lev Tag Len Value Description Mag Chip
03 9F51 var Second AID 5byte RID and max 11 byte PIX
03 | | | |
03 9F51 var Last AID 5byte RID and max 11 byte PIX
02 00 00 EOC
02 BF3E 80 AID_BitField list "Sequence of AID_Bitfields" N Y
03 9F37 01 First AID_Bitfield To be used in conjunction with the First
AID
03 9F37 01 Second AID_Bitfield To be used in conjunction with the Second
AID
| | | |
03 9F37 01 Last AID_Bitfield To be used in conjunction with the Last
AID
02 00 00 EOC
02 BF52 80 RID_data_list “Sequence of RID_data_sets” N Y
03 BF53 80 First RID data set See description below N Y
03 00 00 EOC
03 BF53 80 Second RID data set N Y
03 00 00 EOC
03 | | | |
03 BF53 80 Last RID data set N Y
03 00 00 EOC (for last RID data set)
02 00 00 EOC (for list of RID data sets)
02 BF38 80 Parametrs for random Random Transaction Selection parameters
selection See EMV Book 3 section 10.6.2
03 9F39 01 Target_Percentage Target percentage to be used for random N Y
selection
03 9F3A 03 Threshold_Value Threshold value for biased random N Y
selection
03 9F3B 01 Max_Target_Percentage Maximum target percentage to be used for N Y
biased random selection
02 00 00 EOC
02 9F8108 02 Terminal Type This tag shall be set according to the ICS
for the level 2 certification of the specific
terminal. For further information see EMV
Book 4 Annex A1.
01 00 00 EOC (for DCPAR file)
7.3.1 Transaction descriptor
Each transaction descriptor is a 3 byte field where the first 2 byte define a transaction
type or function according to:
“PU” = Purchase
“CV” = Card Verfy
“CA” = Cash Advance
“PA” = Purchase Advice (Swedish “Efterregistrering”)
“RE” = Refund
“AD” = Adjustment
“LO” = Logon
“EX” = Electronic follow up
“CB” = Close Batch
“BE” = Balance Enquiry
“DE” = Deposit
“WI” = Withdrawal
Page: 21 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Note: All entries do not need to be present. If an entry is not present is equal to that the
transaction type is not allowed.
The third byte is a bitfield defined as follows:
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Transaction allowed Y Y
x 1 x x x x x x Swiped entry allowed Y Y
x x 1 x x x x x Manual entry allowed Y Y
x x x 1 x x x x Password protected Y Y
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Note: The bit settings reflect the acquirs restrictions on the particular transaction type. If the terminal
supports user administration, it is important that a user is not granted privileges that are in
conflict with the acquirers restrictions.
7.3.2 App_Option_Flgs
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Auto_Close_Batch Y Y
x 1 x x x x x x Auto_Close_Shift Y Y
x x 1 x x x x x Pre_Dial Y Y
x x x 1 x x x x Preprinting Y Y
x x x x 1 x x x Batch Settlement Y Y
x x x x x 0 x x RFU
x x x x x x 1 x Forced magstripe fallback allowed N Y
x x x x x x x 0 RFU
7.3.3 AID_Bitfield
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x 0 = exact match used N Y
1 = partial match used
x 1 x x x x x x 0 = Fallback to magstripe not N Y
allowed
1 = Fallback to magstripe allowed
x x 1 x x x x x 0 = Referral and voice N Y
authorisation not allowed
1 = Referral and voice
authorisation allowed
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Note: The bit settings reflect the acquirers restrictions on the particular transaction type. If the terminal
supports user administration, it is important that a user is not granted privileges that are in
conflict with the acquirers restrictions.
Page: 22 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.3.4 A RID data set
Lev Tag Len Value Description
04 9F54 05 RID Identifies card scheme to which the data set belongs
04 9F55 05 TAC bitmap denial May cause the transaction to be unconditionally denied
04 9F56 05 TAC bitmap online May cause the transaction to be forced online
04 9F57 05 TAC bitmap default Used with terminals without online capability
04 9F58 ll Default_DDOL May contain „9F3704‟, i.e. the (EMV) tag and length of
“Unpredictable Number” only
04 9F59 ll Default_TDOL Defined by the card scheme.
04 9F5C 02 Appl_version_number Defined by the card scheme.
04 BF7F ll Additional Data Required The data in the constructed data object is the RID-specific
for a specific RID tag-number the length and the data value. Max length 40
hex. See description in appendix D.
04 00 00 EOC
Page: 23 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.4 The BINPAR File
7.4.1 The complete BINPAR-file
Lev Tag Len Value Descriptiom Comment
01 A1 80 BIN-data Everything needed for prefix handling
02 82 28 BINDOL Tag and length for all fields in a prefix Data Object List á la
row EMV
02 A3 80 The actual prefix table “Sequence of prefix rows”. See Note 1
below
03 84 30 first prefix row All bytes in a prefix row – no tag or L = 29 corresponds to a
length bytes for individual fields 41 byte value field
03 84 30 second prefix row
| | | | |
03 84 30 last prefix row
02 00 00 EOC
02 B7 80 phone number table “Sequence of phone numbers for voice
authorisation”
03 98 10 first phone number phone number consisting of: 16 byte left justified
country prefix + area code + number padded with space
03 98 10 second phone number
| | | | |
03 98 10 last phone number
02 00 00 EOC
02 B9 80 Card Name Table “Sequence of card (type) names”
03 9A 10 first card name The name of a card e.g. “VISA” 16 byte left justified
padded with space
03 9A 10 second card name
| | | | |
03 9A 10 last card name
02 00 00 EOC
02 BB 80 Extra Data Set Table Sequence of extra data set
03 BC First extra data set See definition below
03 BC Second extra data set
| | | | |
03 BC Last extra data set
02 00 00 EOC
02 BF8 80 Card_Issuer_Table Sequence of Card Issuer Name
108
03 9F81 10 First Card_Issuer This data is only provided for
0A information and shall be ignored by all
terminal applications.
03 9F81 10 Second Card_ Issuer
0A
| | | | |
03 9F81 10 Last Card_ Issuer
0A
02 00 00 EOC
02 BF8 80 Card_Type_Table Sequence of Card_Types
10B
03 9F81 03 First Card_Type This data is only provided for
0C information and shall be ignored by all
terminal applications
03 9F81 03 Second Card_Type
0C
| | | | |
03 9F81 03 Last Card_Type
0C
Page: 24 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Lev Tag Len Value Descriptiom Comment
02 00 00 EOC
01 00 00 EOC
Note 1: The terminal can assume that the prefixtable is sorted
The creator of the BINPAR File must sort the prefix rows. The prefix rows shall be sorted in such way
that when the terminal matches a card against the prefix rows (when scanning the rows top down), the
first match, with right PAN_length, is the best matching prefix row for the actual card.
7.4.2 The BINDOL entry
The BINDOL entry based on the example BIN row below would be as follows:
8228850686068702880189038A018B018C018D01950196018E018F039003910392039
303970394039902
7.4.3 A BIN row
Tag Len Name Description Mag Chip
85 06 Low_prefix The lowest prefix of the range for which dependent Y Y
parameters are valid. See description in appendix D.
86 06 High_prefix Highest prefix of the range for which dependent Y Y
parameters are valid. See description in appendix D.
87 02 PAN_length Code for card number length: Y Y
*A=PAN length must be 13-16
*B=PAN length must be 12-19
14=PAN length must be 14
|
23=PAN length must be 23
88 01 Referrals_phone _index Index into table of phone numbers for voice Y Y
authorization. Value 0 gives first phone number.
89 03 Financial_Institution Short form of financial institution name, maximum Y Y
3 characters left justified, padded with space.
8A 01 Card_Name_index Index into table of names of card types (not issuing Y N
banks). Value 0 gives first card name.
8B 01 Bitfields_1 See description below Y Y
8C 01 Bitfields_2 See description below Y Y
8D 01 Bitfields_3 See description below Y Y
95 01 Bitfields_4 See description below Y Y
96 01 Bitfields_5 See description below Y Y
8E 01 Host_Ident_Nbr The host to which the card is mapped Y Y
8F 03 Mag_trans_floor_limit Maximum purchase amount when terminal is offline Y N
(magstripe transaction).
90 03 Chip_trans_floor_limit Terminal floor limit for chip transactions N Y
91 03 Max_purchase_amt Maximum purchase amount Y Y
92 03 Max_Amo_Cash_Back Max amount cash back allowed (SEK) If = 0, cash Y Y
back is not allowed.
93 03 Max_Amo_Cash_Adv Max amount cash advance/ withdrawal (SEK) Y Y
97 03 Max_Amo_Refund Max amount for Refund/Deposit (SEK) Y Y
94 03 Min_purchase_amt Minimum accepted purchase amount Y Y
99 02 Extra_Data_ Set_ Index Index in Extra_Data_Set table. 16 bit unsigned Y Y
binary number in network byte order. Value 0 gives
first index. Value FFFF denotes no extra data.
9F8 02 Card_Issuer_Index Index in Card_ Issuer table. 16 bit unsigned binary N N
10D number in network byte order. Value 0 gives first
index. Value FFFF denotes no info about Card
Issuer.
Page: 25 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Tag Len Name Description Mag Chip
9F8 02 Card_Type_Index Index in Card_Type table. 16 bit unsigned binary N N
10E number in network byte order. Value 0 gives first
index. Value FFFF denotes no Card Type.
Page: 26 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.4.3.1 Bitfields_1
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Signature allowed Y N
x 1 x x x x x x PIN allowed Y N
x x 1 x x x x x Check CDV Y N
x x x 1 x x x x Check Service Code when offline Y N
x x x x 1 x x x Check Service Code when online Y N
x x x x x 1 x x Offline handling allowed Y N
x x x x x x 1 x Only online (Maestro, Electron) Y N
x x x x x x x 1 Always handle as magstripe Y Y
7.4.3.2 Bitfields_2
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Manual entry is allowed (PAN) Y Y
x 1 x x x x x x CV2 required (manual entry) Y Y
x x 1 x x x x x Imprint of embossing is required Y Y
x x x 1 x x x x This prefix range is blocked Y Y
x x x x 1 x x x This is a national card Y Y
x x x x x 1 x x Issuer country is not known Y Y
x x x x x x 1 x Customer may select account type Y Y
x x x x x x x 1 Always prompt for VAT Y Y
7.4.3.3 Bitfields_3
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x This is a bonus card Y Y
x 1 x x x x x x This is a payment card Y Y
x x 1 x x x x x Prompt for special payment code Y Y
x x x 1 x x x x Max payment code length = 1 digit Y Y
x x x x 1 x x x Max payment code length = 2 digit Y Y
x x x x x 1 x x Max payment code length = 3 digit Y Y
x x x x x x 1 x Man input of transaction allowed Y Y
x x x x x x x 1 Forced magstripe fallback allowed Y Y
(purchase)
7.4.3.4 Bitfields_4
Allowed transactions for the BIN
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Purchase Y Y
x 1 x x x x x x Refund Y Y
x x 1 x x x x x Cash Advance Y Y
x x x 1 x x x x Balance Inquiry Y Y
x x x x 1 x x x Withdrawal Y Y
x x x x x 1 x x Deposit Y Y
x x x x x x 1 x PIN Change Y Y
x x x x x x x 0 RFU
Page: 27 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.4.3.5 Bitfields_5
Only valid for Cash advance and Withdrawal
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x Signature allowed Y N
x 1 x x x x x x PIN allowed Y N
x x 1 x x x x x Manual entry is allowed (PAN) Y Y
x x x 1 x x x x CV2 required (manual entry) Y Y
x x x x 1 x x x Imprint of embossing is required Y Y
x x x x x 1 x x Check Service Code when online Y Y
x x x x x x 1 x Forced magstripe fallback allowed Y Y
(Cash Advance, Withdrawal)
x x x x x x x 0 RFU
7.4.3.6 Extra_Data_Set Only valid for integrated solutions and special environment
The extra data table is used for integrated solutions and the content is dependent of the environment.
The following data with associated tags could be present in the extra data set.
Lev Tag Len Value Descriptiom Mag Chip
01 BC 80 Extra_Data_Set Extra data for integrated
solutions varies depending on
environment
02 9F3C 02 Bonus_Routine_ A bonus routine number assigned Y Y
Number to the card
02 9F3D 01 PIN_Algoritm_ If not present or value `”0” Y Y
Number =DUKT
> 0 = customer specific PIN
algoritm
02 9F5D 01 MAC_Algoritm_ If not present or value `”0” Y Y
Number =DUKT
> 0 = customer specific MAC
algorithm/key
02 9F5E 03 No_Auth_Amount Purchase forced approved below Y Y
this amount at merchants risc
02 9F3E 01 Send_Track Bitfield, see description below.
02 BF6F 80 Unattend_Gasoline Unattended gasoline pumps
03 9F6E 03 Auth_Amount Amount to be authorised (SEK) Y Y
03 81 03 Max_Allowed_ Max allowed purchase when Y Y
Purchase authorisation approved
03 9F7B 01 Bitfield_Unattend_ See description below Y Y
Gasoline
02 00 00 EOC
02 BF7C 80 Merchant_Category_ Specification of not allowed Y Y
Code_Restrictions MCC (exclusive) or allowed
MCC
03 BF7D 80 List_Allowed_MCC
04 83 02 First MCC Numeric 4 digits MCC Y Y
| | | | |
04 83 02 Last MCC Y Y
03 00 00 EOC
03 BF7E 80 List_Not_Allowed_
MCC
04 83 02 First MCC Numeric 4 digits MCC Y Y
| | | | |
04 83 02 Last MCC Y Y
03 00 00 EOC
02 00 00 EOC
01 00 00 EOC
Page: 28 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.4.3.7 Bitfield Send_Track
Bits in this bitfield shall not be set whitout a prior written agreement with the card issuer about the
exposure of track information.
If the BIN for the card is present in the BIN-table and this tag is set then the requested track information
shall be sent in the SR_CARD_READ message.
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
0 x x x x x x x RFU
x 0 x x x x x x RFU
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 1 x x Send track 3 Y N
x x x x x x 1 x Send track 2 Y Y
x x x x x x x 1 Send track 1 Y N
7.4.3.8 Bitfields_Unattended_Gasoline
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x X Advice required Y Y
x 1 x x x x x X Reversal of initial authorisation Y Y
required if no purchase
x x 0 x x x x X RFU
x x x 0 x x x X RFU
x x x x 0 x x X RFU
X x x x x 0 x X RFU
x x x x x x 0 X RFU
x x x x x x x 0 RFU
Page: 29 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.5 The CAPUB File
The CAPUB (Certification Authority PUBlic Key) file always contains all the CA
public keys that the terminal is required to handle. There may be up to six keys per
RID (note a).
7.5.1 The complete file
Lev Tag Len Value Description
01 BF70 80 The CAPUB content The complete file seen as a single constructed value
02 BF71 80 List of PK data sets "Sequence of CA public key data sets"
03 BF72 80 CA public key data set First key data set
03 00 00 EOC
03 BF72 80 CA public key data set Second key data set
03 00 00 EOC
| | | | |
03 BF72 80 CA public key data set Last key data set
03 00 00 EOC (for last key data set)
02 00 00 EOC (for list of key data sets)
02 9F7A 08 MAC Note b
01 00 00 EOC (for file as constructed value)
7.5.2 A key data set
Lev Tag Len Value Description
04 9F73 05 RID Identifies card scheme to which data set belongs
04 9F74 01 CA public key index Together with RID identifies this unique data set
04 9F75 01 CA Hash method Hash method used to produce the Key check sum
04 9F76 01 CA public key alg. Algorithm used to produce signature with this key
04 9F77 81var CA public key modulus Value of public key modulus, var max = 248 (= hex F8)
04 9F78 var CA public key exponent Either 3 (var = '01') or 216 + 1 (var = '03')
04 9F79 14 CA public key check Check value using SHA-1
sum
Note a: "up to six keys per RID" means that there may be up to six key data sets as defined above with
the same RID (but different CA public key index). Finding a particular key means that the
terminal must search through the key data sets stored until a key data set is found where both
the RID and the public key index matches the corresponding values obtained from the card.
Note b: Additional (DES) MAC for protection of all the key data sets. The acquirer provides this
MAC so the terminal can verify that CA public keys have not been fraudulently changed or
added after loading, which would allow counterfeit cards to be used. The test should be done
at power up and each time new software has been loaded. The test should be done as follows:
For each key data set, the terminal calculates the SHA-1 digest and compares to the SHA-1
digest provided when the file was loaded. If not equal, the CAPUB file must be reloaded.
The terminal concatenates all SHA-1 digests in the order received in the file and provides
this data and the MAC received to the security module that verifies the MAC using a secret
key shared with the acquirer. If not verified correctly, the CAPUB file must be reloaded.
Note c: Note that the tag length for tag 9F77 is always coded as 81 and the length follows in the next
byte even if the actual length is lower than 127 bytes.
Page: 30 of 71
Babs and CEKAB Software & Parameter Download version 2.3
7.6 Other parameter files
Additional applications may require their own parameter files. In order for these files
to be fetched by a terminal, the application issuer must convey the details required by
the control file layout to the terminal's TSP. The following rules apply:
The parameter file must use the common file format
The format of the content part is free to decide by the application issuer
The (8 character) name of the file must not be equal to any other file name
The content and the file must be signed (by application issuer and sender)
8 Application Files
An application file in the context of this specification is just the content part of a file
following the common file format and having a particular file type. The only
requirement is that it starts with Content Security Info as defined in this specification,
and ends with the MAC/signature implied by the Content Security Info. The structure
of the data between these mandatory fields is arbitrary, and need only make sense to
the terminal's proprietary load software.
9 Fetching the Files
9.1 Terminal Requirements
It is assumed that the terminal is capable of downloading all its application software
and required parameters from a download server. The terminal must therefore, before
delivery, as a minimum contain the following software (loaded in a secured
environment):
The operating system
A download software module capable of handling download and verification of
files conforming to the common file format.
Before download of parameter files is possible, the terminal must also know:
The TSP Terminal ID (manually entered into the terminal)
The communication parameters required to connect to the TSP PPL-server
The keys necessary to verify file and content (downloads from PPL-server).
9.1.1 Download SW
The download software module must be able to:
verify the origin and content of any file loaded into the terminal by means of
cryptographic methods and keys indicated in the file and content security
information fields.
be invoked by the operating system (if the terminal is empty) to load the control
file, and to load and start the master application defined in the control file.
be invoked by the master application to load the control file, the MASPAR file and
any application defined in the control file.
be invoked by any application (directly or indirectly) to load the control file and
any parameter file(s) defined in the control file and recognized by the application.
Page: 31 of 71
Babs and CEKAB Software & Parameter Download version 2.3
NOTE! The terminalvendor must agree with Babs and CEKAB, concerning the
communication used for PPL-handling. If ftp is used an agreement must be made
if passive or active mode shall be used.
9.1.2 TCP/IP and FTP support
It is assumed that the terminal is capable of logging in to the TSP's download server
and download files using FTP. The terminal must therefore be able to handle TCP/IP,
either directly, or via an external "terminal server" unit that may be a single port unit
for each terminal or a multi-port unit common for several terminals. In an integrated
environment, TCP/IP and FTP support might be a service provided by the ECR.
The FTP implementation need only implement a few of the (more than 30) possible
FTP commands – i.e. the USER, PASS, TYPE, PORT, RETR, CWD, STOR, PASV
and QUIT commands will probably be enough.
9.1.3 Alternative protocols
For terminals that cannot support TCP/IP or FTP, one (and only one) alternative is
provided. This protocol is specified in Appendix C to this document.
9.1.4 Security functions
The terminal must be able to verify the integrity of the received files and the contents
of the files, i.e. be able to verify security schemes defined by the "file security info"
field of the common file format header and the (same) security schemes defined by the
"content security info" field mandatory prepending the file content. These security
functions are part of the cryptographic services provided by the terminals secure
device, normally the PED.
9.2 FTP download session
9.2.1 FTP fundamentals
FTP uses two TCP/IP sessions – first a control channel is opened to port 21 on the
server (the FTP deamon). This channel requires user name and password and stays
open until closed by the client (the terminal). On the control channel, which is similar
to a telnet session, commands are sent in text format, e.g. the PORT command which
makes the server open a new session towards the terminal. The terminal port is given
in the command and the new session is used for the actual file transfer and closed
automatically as soon as the file transfer is complete Therefore, if more than one file
must be fetched, the files are fetched one at a time as shown in the following example.
9.2.2 Example download session
In the example below, a terminal fetches its control file and, based on the info
contained in the file, fetches a new parameter file. Only the commands and responses
on the control channel are shown in detail. The response to a command is a response
code and some informational text. The actual file transfer is done on the other channel
and is based on TCP.
Page: 32 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Terminal Download server
Connect and get the control file
tcpip_connect <server IP-address> <21>
220 CEKAB FTP server ready
USER <TSPID | PED-Type >
331 Password required for terminal
PASS <password>
230 User terminal logged in
TYPE I
200 Type set to I
PORT <my IP-address> <my port>
200 PORT command successful
RETR <my controlfilename>
150 Binary data connection for
<mycontrolfilename> (<IP-addr> <port>)
(780 bytes)
At this point the control file is transferred (on the other session)
226 Binary Transfer complete
Now the terminal examines the control file and decides that a new CAPUB file should be tetched
PORT <my IP-address> <port>
200 PORT command successful
RETR CAPUB___020401083000
150 Binary data connection for
CAPUB___020401083000
(<IP-address> <port>)(4000
bytes)
At this point the file CAPUB is transferred (on the other session)
226 Binary Transfer complete
QUIT
221 Goodbye
The control session is terminated
Depending on the implementation of FTP on a particular terminal, the processing
above as seen from the application could be implemented with a few library functions.
Of course, the terminal must have some meaningful error handling and the integrity of
the files must be verified before processing can proceed.
9.3 First download
A terminal may of course be installed preloaded with all (currently requested)
applications and parameters. However, for logistic purposes, it may be desirable to
install an "empty" terminal that automatically loads the required software and
parameters. In this case, the step-by-step procedure could be as in the following
example:
1. After power on, the terminal checks the loaded application list. If empty, the
terminal connects to the TSP and requests the control file.
2. The first application file listed in the control file will be the master application file.
3. The master application file is downloaded and checked for integrity. If OK the
(terminal type dependent) software load procedure is invoked.
Page: 33 of 71
Babs and CEKAB Software & Parameter Download version 2.3
4. The software load procedure will relocate the load image to the proper memory
location and start execution.
5. The started master application will check for required parameters.
6. Since the parameters are not present, the master application will invoke the
download of the master application parameter (MASPAR) file version named in
the control file.
7. The master application parameter file is downloaded and checked for integrity.
8. By now the terminal has a limited user interface and will display progress in a user
friendly format. The master application now invokes the download procedure for
the next application – probably a debit/credit application.
9. When the debit/credit application is verified and started, it will request its
parameter file(s) in the same way.
10. When all applications and their associated parameter files have been loaded,
control is returned to the master application that displays the idle prompt.
9.4 Loading files from other servers
In the multi-application environment, application software and parameter files may
have to be loaded from other download servers than the TSP download server. If for
instance a new application is to be loaded into (a subset of) the TSP's terminals, the
following scenario can be envisaged:
The new application is tested in the terminal together with the other applications it
is supposed to coexist with. These (acceptance) tests will involve the TSP, the
application developer, the acquirer and possibly other parties as well. In the end,
provided that the tests are successful, the application is approved and the approved
version is signed by the acquirer (using RSA signature or MAC).
The TSP agrees to load the application into the selected terminals and prepares the
corresponding control files with an entry for the new application. The control file
defines the file name and version, the IP address/port of the application issuers
download server, and the sender id of the application issuer.
The application issuer encapsulates the signed software in the common file format
where the "sender id" should be the same as the sender id given in the TSP's
control file. The file is signed by the application issuer (using RSA signature or
MAC).
Provided that the terminal knows the (possibly certified) public keys or secret DES
keys of the TSP, the acquirer and the application issuer (if different from the
acquirer), the terminal can now download and verify the new application with the
same security as if it was downloaded from the TSP. This is because the signatures
verify that the software is approved by the acquirer, and that the file is received
from the entity specified in the control file.
Page: 34 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Appendix A – Rules for BER-TLV Data Objects
A.1. Coding of BER-TLV Data Objects
The description below covers the subset of TLV encoding used in this document.
As defined in ISO/IEC 8825 (corresponding to ITU-T X.690), a BER-TLV data object
consists of 2 – 3 consecutive fields:
The tag field (T) consisting of one or more consecutive bytes. It codes a class, a
type, and a number. The tag field of the data objects described in this specification
is coded in one or two bytes.
The length field (L) consists of one or more consecutive bytes. It codes the length
of the following field. The length field of the data objects described in this
specification is coded in one or two bytes.
The value field (V) codes the value of the data object. If L = '00', the value field is
not present.
A BER-TLV data object belongs to one of the following two categories:
A primitive data object where the value field contains a single value for the data
object.
A constructed data object where the value field contains one or more primitive or
constructed data objects. The value field of a constructed data object is sometimes
called a template.
A.1.1. Coding of the Tag Field of BER-TLV Data Objects
The first byte of the tag field of a BER-TLV data object is coded as below:
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning
0 0 x x x x x X Universal class
0 1 x x x x x X Application class
1 0 x x x x x X Context specific class
1 1 x x x x x X Private class
x x 0 x x x x X Primitive data object
x x 1 x x x x X Constructed data object
x x x 1 1 1 1 1 See subsequent byte(s)
x x x Any other value Tag number
Subsequent bytes (if required) are coded as follows:
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning
1 x x x x x x X Another byte follows
0 x x x x x x X This is the last byte
x Any value > 0 (part of) Tag number
In this specification, the tag number is either in bit 5 – 1 of a single tag byte or in bits 7
– 1 of the second byte if two bytes are used.
Page: 35 of 71
Babs and CEKAB Software & Parameter Download version 2.3
A.1.2. Coding of the Length Field of BER-TLV Data Objects
There are two forms of length fields, definite and indefinite. Definite encoding
explicitely gives the length of the value field and must be used for primitive data
objects. The coding of the definite length field is as follows:
When bit 8 of the most significant byte of the length field is set to 0, the length
field consists of only this byte. Bits 7 to 1 of the single byte code the number of
bytes in the value field (0 to 127).
When bit 8 of the most significant byte of the length field is set to 1, the bits 7 to 1
of the most significant byte code the number of subsequent bytes in the length
field. The subsequent bytes codes an unsigned integer representing the number of
bytes in the value field.
It follows that value field lengths of up to 255 byte is coded as:
1 byte (00 to 7F) for value field lengths of 0 to 127 bytes
2 byte (8180 to 81FF) for value field lengths of 128 to 255 bytes
The indefinite form of the length field is used only for constructed data objects if the
length or number of member data objects may vary. The length field in this case
consists of a single byte with value '80'. In addition, if the indefinite form is used, the
value field must be followed by an "End of Content" indicator (EOC). The EOC is
coded as two bytes with value '00'.
A.1.3. Coding of the Value field of Data Objects
A data element is the value field (V) of a primitive BER-TLV data object. A data
element is the smallest data field that receives an identifier (a tag). A primitive data
object is structured as follows:
Tag (T) Length (L) Value (V)
The value field (one ore more bytes) is coded according to the rules implied by the tag
number encoded in the tag field.
A constructed BER-TLV data object consists of a tag, a length and a value field
composed of one or more BER-TLV data objects (each with its own tag, length and
value fields). A constructed data object is structured as follows:
Tag Length Primitive or constructed ..... Primitive or constructed
(T) (L) BER-TLV data object #1 BER-TLV data object #n
If the length field is indefinite, the last data object must be followed by an End of
Content indicator (EOC).
A.2. Deviations from the standard
This document (as well as the EMV2000 specification) uses some constructs that do
not conform to the (ITU-T X.690) standard or the intention of the standard.
Page: 36 of 71
Babs and CEKAB Software & Parameter Download version 2.3
A.2.1. Use of Tag Number
In the X.690 standard, the tag number encoded within the tag field refers to a data type
rather than identifying a specific variable. For example, if a transaction number and a
floor limit are both represented as integers, the standard encoding would assign the
same tag number to the objects. In the context of this specification they will be
assigned different tag numbers, defining both the identity and the coding of the value
of the two objects.
A.2.2. Data Object Lists
The EMV2000 specification as well as this specification allows a constructed data
object consisting of a number of primitive data objects to be represented by the
concatenation of the value fields of the member objects, i.e. without the tag and length
fields. This is provided that the corresponding tag and length fields are available to the
receiving entity as a Data Object List (DOL) consisting of the concatenation of the tag
and length fields for the member objects. This construct is used to save space in the
BINPAR file by defining the set of primitive data objects contained in a BIN row with
the BINDOL data object list.
Page: 37 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Appendix B – Download via proprietary systems
For new terminals, CEKAB and Babs will provide the download interfaces defined in
this specification. If, for some reason, the terminal cannot be made to handle these
interfaces, it may still, under certain circumstances defined below, be possible to
download software and parameters indirectly, using the terminal vendors download
system to translate between the interfaces. It is neccessary that:
The terminal can handle trigger activation of download
The interaction between terminal and terminal vendor download system can
provide the same level of security as the TSP interfaces.
B.1. Software download
On a high level, a possible indirect software download procedure could be as follows:
Seq. Terminal ?? Terminal Vendors TCP/ TSP Download System
Download System IP
1 Terminal receives
trigger
2 It is time to check
control file so terminal
indicates this by
identifying itself to
Vendors download
system
3 Vendor system requests
the control file (FTP!)
4 TSP download system
returns control file
5 Vendor system verifies
and translates control file
and responds to terminal
6 Terminal compares
version, if new:
7 Proprieatary download Proprietary download
procedure procedure
8 Session ended
Page: 38 of 71
Babs and CEKAB Software & Parameter Download version 2.3
B.2. Parameter download
On a high level, a possible indirect parameter download procedure could be as follows:
Seq. Terminal ?? Terminal Vendors TCP/ TSP Download System
Download System IP
1 Terminal receives
trigger
2 It is time to check
control file so terminal
indicates this by
identifying itself to
Vendors download
system
3 Vendor system requests
the control file (FTP!)
4 TSP download system
returns control file
5 Vendor system verifies
and translates control file
and responds to terminal
6 Terminal compares
version, if new:
7 Terminal requests
parameter file
Vendor system requests
parameter file
8 TSP download system
returns parameter file
Vendor system verifies
and translate parameter
file to proprietary format
and responds to terminal
9 Proprieatary download Proprietary download
procedure procedure
10 Session ended
Page: 39 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Appendix C – Alternative PPL Download Protocol
The protocol described below is intended for terminals that cannot handle TCP/IP and FTP. It is an
attempt to adopt useful principles from several existing protocols to obtain a reliable, efficient and
simple to implement protocol, optimized for the purpose. It has the following characteristics:
Easy to implement in the terminals and PPL-server
Can handle binary (8-bit) data
More reliable than present (POS2 based) protocols
Can handle the same files as TCP/IP and FTP
Works with PSTN modem, ISDN D-channel, ISDN B-channel and GSM.
Prevents unauthorised (write-) access to the PPL-server.
C.1. Properties overview
C.1.1. Client – server
The protocol is a client – server protocol implemented with 4 message types. Normally the terminal is
the client, and the only service provided is to fetch files from the PPL-server. If required, both the client
and server part can be implemented in both ends, in which case the PPL-server can also fetch (statistics)
files from the terminal (see "Protocol Options"). However, it is always the terminal that will establish
the connection ("dial up"), so file transfer terminal PPL-server can only be accomplished in
conjunction with a terminal initiated file transfer.
C.1.2. Binary data
The link level part of the protocol has a length field that allows the receiving end to know how many
bytes remains to be read before the complete message is received (compared to POS2 where the
receiving end must read until the ETX control character is received). In this way, any 8-bit character can
be received in the message.
C.1.3. Checksum
All frames have a 2 byte checksum (CRC-16), that provides improved protection against communication
errors compared to the POS2 LRC.
C.1.4. ACK/NAK
The protocol doesn't use single byte ACK/NAK control characters. Instead, if the client doesn't get a
response (timeout) or if the response checksum indicates error, the request is sent again using the same
blocknumber. If the server receives a request with erroneous checksum, the request is discarded and the
client will repeat the request after timeout as described above. Acknowledgement of the reception of the
complete file is implied from the FRQ or FCM message (explained below) and allows the server to be
sure about (and log if required) the outcome of the file transfer.
C.1.5. Block Number
The protocol is a dedicated file transfer protocol, and (like FTP) doesn't care about the inner structure of
the file being transferred. The file is transferred in equal sized blocks, except the last block that can be
smaller. In principle, the client can request the blocks in random order – hardly likely but the principle is
important: the client decides which block to be transferred, the server doesn't send "next block". This
allows restart at any place in the file after communication failure as well as repetition of a block having
a checksum error.
Page: 40 of 71
Babs and CEKAB Software & Parameter Download version 2.3
C.2. Detailed description
C.2.1. Frame format
<frame> = <STX> <msg len> <message> <CRC>
<STX> = hex 02
<msg len> = 2 byte integer – most significiant byte first
<message> = <msg header> <msg data>
<msg header> = see descriptions below
<msg data> = binary file data.
<CRC> = CRC-16 checksum over <msg len> and <message>
<msglen> gives the length of the message header + message data. Only the RSP message has message
data.
C.2.2. File Request Message (FRQ)
This message is sent from the client (the terminal) to request a specific block from a specific file.
Normally the first block (Block Number = 0) is requested, but in case of restart after a communication
failure, another block can be requested (the first block after the last correctly received block). The
message consists of only the FRQ header as defined below:
FRQ-header:
Msg Type 2AN
TSPID 16AN left justified and padded with blanks
Password 8AN left justified and padded with blanks
File Name 20AN left justified and padded with blanks
Block Number 4N
Msg Type can have the following values:
"A1" = File Request (FRQ), use block size 128 byte
"A2" = File Request (FRQ), use block size 256 byte
"A3" = File Request (FRQ), use block size 512 byte
"A4" = File Request (FRQ), use block size 1024 byte
For a particular media (PSTN modem, ISDN D-channel, ISDN B-channel or GSM), the same (optimal)
value is probably used. The size of the terminal's receive buffer might also influence the choice of block
size.
The "TSPID" field allows the server (if required) to log per terminal the time and outcome of file
transfers. If the file specified in the “File Name field” is a PKF or IKFS file the PED-Type is used as
TSPID.
"File Name" is the name of the file to be transferred, e.g.: CAPUB___020423182255.
"Block Number" gives the requested part of the file – for Msg Type = A3, Block Number = 0 means the
first 512 byte of the file.
C.2.3. Block Request Message (BRQ)
Sent from the client (terminal) to request additional blocks of the file (the first block is received as the
response to the FRQ message). The Block Request Message consists only of the header as below:
BRQ-header:
Msg Type 2AN
Block Number 4N
Page: 41 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Msg Type = "BB"
Block Number = 0 – 9999 (0 only if checksum error in response to FRQ).
C.2.4. Response Message (RSP)
Sent from the server as response to an FRQ or BRQ request. This is the only message that has message
data.. The header is described below:
RSP-header:
Msg Type 2AN
Block Number 4N
Resp. Flags 2N
Msg Type = "RR"
Block Number = the block number corresponding to the response message data. Should be the same
Block Number requested in the FRQ or BRQ request.
Response Flags = status code as below:
First byte (error code):
0 = No error
1 = Terminal/TSPID not found (only in response to FRQ)
2 = File not found (only in response to FRQ)
3 = Invalid block number (after end of file)
Second byte ("more" byte):
0 = this is last block, ready to disconnect
1 = more blocks remain in file
C.2.5. File Confirm Message (FCM)
Sent from the client after the last block is successfully received or if timeout or checksum error for the
same block occurred 3 times. Indicates that the client considers the file transfer ended (success or abort).
The server should respond to this message with an empty (no message data) RSP-message having
second byte of response flags set to 0 or 2. Upon receipt of the RSP message with second byte set to 0,
the client disonnects. For second byte of response flags value = 2, see "Protocol Options".
If the client after successfully receiving a file wants to fetch another file, an FRQ message is sent instead
of the FCM message. The server should consider this an implicit acknowledge of the previous file
provided that:
The last block of the previous file was sent
The File Name in the FRQ message is different from the File Name of the previous file
FCM-header
Msg Type 2AN
Proc. Flags 2N
Msg Type = "FF"
Processing Flags:
First byte (status): 0 = file transfer successful
1 = file transfer aborted
Second byte: 0 = will disconect after response
1 = see "Protocol Options"
Page: 42 of 71
Babs and CEKAB Software & Parameter Download version 2.3
C.2.6. Terminal Processing
Assuming the terminal has detected the need to fetch the Control File (see Ref [1]), the first step is to
connect to the PPL-server (dialling through PSTN, ISDN or GSM). After connect indication is received,
the processing is as follows (slightly simplified):
1. The terminal waits to receive ENQ which indicates that the PPL-server is ready to receive a request.
If no ENQ is received within timeout 1, the terminal disconnects.
2. When terminal receives ENQ it sends the FRQ message, requesting block 0 of the Control File.
3. Terminal waits for <STX> of the RSP message. Any character received before <STX> is
discarded. If no response is received within timeout 2, the FRQ message is repeated up to 3 times
(after timeout). If still no response the terminal disconnects.
4. When the response is received, the checksum is validated. If error, the FRQ message is repeated up
to 3 times. If still no valid response, the terminal disconnects.
5. The terminal saves the valid response and requests the next block with the BRQ message.
6. Terminal waits for the <STX> of the RSP message. Any character received before <STX> is
discarded. If no response is received within timeout 2, the BRQ message is repeated up to 3 times
(after timeout). If still no response, the terminal disconnects.
7. When the response is received, the checksum is validated. If error, the BRQ message is repeated up
to 3 times. If still no valid response, the terminal disconnects.
8. The terminal appends the valid response data to the received file.
9. Assuming the last block was received, the file is now available for the terminal to check for
integrity and if any updated parameter file must be fetched (not part of the protocol!).
10. If no action required, the terminal sends the FCM message and waits for response.
11. If no response or if checksum error, repeat as above. If error prevails, disconnect
12. When response is received, disconnect.
If the Control File indicates that one or more updated files must be fetched, the terminal normally needs
to disconnect anyway to perform some reconciliation transaction as a precaution before the new files are
fetched. The terminal then connects and fetches the new files as above. If more than one file is to be
fetched, the terminal doesn't send the FCM message until after the last file to be fetched.
C.2.7. Server Processing
The server waits for a terminal to connect. When a connect indication is received:
1. The server sends ENQ
2. If no request is received within timeout 3, the server sends ENQ again. If still no response, ENQ is
repeated up to 3 times (after timeout) then the server disconnects.
3. When a request is received, the checksum is validated, if error, the frame is discarded. If no valid
frame is received within timeout 4, the server disconnects.
4. A valid FRQ-request is handled by opening the requested file and sending a RSP message with the
requested block.
5. A valid BRQ message is handled by sending the requested block of the current file.
6. If a new FRQ message is received, the previous file is closed and if the requested file is different
and the last block of the previous file was sent, the previous file can be logged (if required) as
successfully fetched by the particular terminal. Then the new file is opened and the requested block
is sent in a RSP message.
7. If an FCM message is received, a RSP message is sent. If a disconnect indication or a repeated
valid FCM is not obtained within timeout 4, the server disconnects.
C.2.8. Timeouts
Timeout 1
Client waiting for ENQ after connect 20 seconds
Timeout 2
Client waiting for response 3 seconds
Timeout 3
Page: 43 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Server waiting for request after ENQ 5 seconds
Timeout 4
Server waiting for valid request any time
after response to FRQ, BRQ or FCM 10 seconds
In addition to the above, both client and server ends should apply a timeout of 2 seconds between
characters received within a frame i.e. after <STX> is received but before all bytes including <CRC>
has been read. This is to allow the protocol to resynchronise if an error occurs in the <msg len> field.
C.3. Example file transfer session
Terminal PPL-server
The terminal dials PSTN/ISDN/GSM connect indication session open
PPL-server sends ENQ
The terminal sends FRQ (file read request)
PPL-server sends RSP
The terminal sends BRQ (block request)
PPL-server sends RSP
The terminal sends BRQ (block request)
PPL-server sends RSP (last block)
The terminal sends FCM (file cfm msg)
PPL-server sends RSP
The terminal disconnects || disconnect indication session closed
C.4. Protocol options
As an option, if it turns out to be desirable to be able to fetch statistics files from the terminal, the
proposed protocol allowes this by implementing both the client and server part of the protocol in both
ends. This allows for a safe way to get files into the PPL-server since it is the PPL-server resident client
software that decides which files may be written where in the server file system.
In this case, the terminal can indicate that it has accumulated some meaningful statistics by setting the
last byte of the processing flags in the FCM to 1, meaning "I have something for you, if you want it, I
will wait for your FRQ, otherwise I will disconnect after your response".
If there is no statistics available, or if the terminal for some other reason doesn't want the file transfer to
take place at this time, it sets the same byte to 0, meaning "will disconnect after your response". When
the PPL-server responds to the FCM request and was invited to fetch a file, it can set the more byte to 2,
meaning "I would like to request a file from you", or to 0 meaning "ready to disconnect". The last value
is mandatory if the terminal declined file fetch.
Page: 44 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Appendix D – Explanation of parameter use & formats
D.1. Format specifications
The following format specifications are used in this appendix:
N: Contains a single numeric character 0 – 9 per byte, right justified, padded with ascii zero
if required.
AN: Contains a single character per byte, left justified, padded with ascii space if required.
The letters A – Ö or a – ö and the numerics 0 – 9 are allowed.
ANS: As AN but in addition some special characters like space, hyphen etc. are allowed.
BIN: Contains a binary number or bit combinations according to description.
CN/BCD Compressed numeric. Two numeric digits in the range hex '0' to '9' packed in each byte.
These data elements are left justified and padded with hex 'F'. Used in the BINPAR file
to give the upper and lower bounds for a PAN range.
ST: Special type. Used for some data elements with a structured format, e.g.
ransaction_descriptor. The format of the value is described with the actual data element.
The following notations are used for the columns:
Stand alone: stand alone terminal
Y yes, this parameter is used
N no, this parameter is not used
Integrated direct: integrated solutions including an iPOS terminal that
communicates direct to the acquirer host for authorisation
Y* yes, this parameter is used, set by the acquirer and not allowed to be changed
Y~ yes, this parameter is used, set by the acquirer and allowed to be changed at the retailers own risk
N no, this parameter is not used
NSa no, this parameter is not used, the information is normally fetched from the sales system
Integrated via: integrated solutions including an iPOS terminal that communicates via
a merchant host or a third part host to the acquirer host for authorisation.
Y* yes, this parameter is used, set by the acquirer and not allowed to be changed
Y~ yes, this parameter is used, set by the acquirer and allowed to be changed at the retailers own risk
YR yes, this parameter is used and normally set by the retailer
N no, this parameter is not used
NSa no, this parameter is not used, the information is normally fetched from the sales system
Mag: swiped or manually entered transactions
Y yes, this parameter is used
N no, this parameter is not used
Chip: chip based EMV transactions
Y yes, this parameter is used
N no, this parameter is not used
Note! For cards that are not read by the acquirer it is allowed to insert own bin rows and adjust the
parameters for transaction types for these cards.
Page: 45 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.2. The MASPAR file
Tag Max Format Value Description Stand Inte- Inte-
Length alone grated grated
(hex) direct via
9F22 28 ANS Merchant_Name The merchant‟s name – max 40 Y NSa NSa
characters.
Shall be printed on the receipts.
9F23 28 ANS Merchant_adress Visiting address – max 40 Y NSa NSa
characters
Shall be printed on the receipts.
9F24 28 ANS Merchant_City City name including zip code – Y NSa NSa
max 40 characters
Shall be printed on the receipts.
9F25 0B ANS Organization_Nbr The organisation number for the Y NSa NSa
merchant. Format: nnnnnn-nnnn.
Shall be printed on the receipts.
9F26 18 ANS Bank_Agent_ The name of the acquiring bank for Y NSa NSa
Name debit/credit application. May be
printed in the receipt header
9F27 04 AN Country_Code The country code according to ISO Y NSa NSa
3166 for the country in which the
terminal is located. Normally
Sweden = 0752.
9F28 01 N Social_Call_Day Max number of days between Y Y* YR
control file polls. Value 1-9 and is
the maximum days between
control file checks. When an
internal counter has reached this
value, a call shall be made to the
TSP to fetch the control file. The
counter is incremented each day
(at Social_Call_Time) and reset
any time a transaction response is
received from the debit/credit
application host or the Control file
is fetched.
9F29 04 N Social_Call_Time The preferred time of the day Y Y* YR
(according to Social Call Day) to
perform Social Call to the TSP for
fetching the Control file. Format
HHMM.
9F2A 01 AN Dial_Type New applications shall ignore this N N N
tag. The value of the tag shall not
be used. Always set the value to
“P” for backward compability.
9F2B 10 AN Prim_Phn_Nbr_ Primary phone number including Y Y* YR
TSP area code (and possibly country
code) for TSP.
9F2C 10 AN Sec_Phn_Nbr_TSP Secondary phone number Y Y* YR
including area code (and possibly
country code) for TSP.
9F2D 15 ANS Prim_IP_adr_TSP Primary IP-address/port for TSP. Y Y* YR
Max 21 char. i.e.
NNN.NNN.NNN.NNN:NNNNN
Example:
192.168.8.100:9999
9F2E 15 ANS Sec_IP_adr_TSP Secondary IP-address/port for Y Y* YR
TSP. Max 21 char. i.e.
NNN.NNN.NNN.NNN:NNNNN
Page: 46 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Tag Max Format Value Description Stand Inte- Inte-
Length alone grated grated
(hex) direct via
Example:
192.168.8.100:9999
9F2F 05 AN Phone_Nbr_Prefix Digits required to dial through Y Y* YR
PABX or similar to PSTN
9F30 10 ANS Helpdesk_Text Technical helpdesk phone number Y Y* YR
(TSP). Formatted as it should be
displayed on the screen
9F31 06 AN User_Password Password required for certain Y N N
functions. The functions that
requires the password for the
debet/credit application is defined
by the transaction descriptor in the
DCPAR file.
9F32 01 BIN Password_Flgs Bitmap describing additional N N N
functions that may be protected by
the password above (not yet
defined).
9F33 01 AN Appl_Environment New applications shall ignore this N N N
tag. The value of the tag shall not
be used. Always set the value to
“S” for backward compability.
9F34 01 BIN Option_flags Described below
9F35 04 N VAT_Per Default VAT percentage – 2500 Y NSA NSA
means 25%
9F36 10 ANS Merchant_phone_ Phone number to the merchant as it Y NSA NSA
number should be printed on the receipt.
Page: 47 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.2.1. Tag 9F34 Option flags
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x Tip handling enabled. The Y Y Y NSA NSA
terminal shall prompt for tip
when the transaction amount
has been entered.
x 1 x x x x x x Coat Room handling enabled Y Y Y NSA NSA
The terminal shall prompt for
Coat room fee when the
transaction amount has been
entered.
x x 1 x x x x x The terminal shall ask for ref Y Y Y NSA NSA
number (e.g. table) that is
connected to the transaction
and printed on the receipt
x x x 1 x x x x VAT display option. For each Y Y Y NSA NSA
transaction the VAT amount
shall be displayed according to
the percentage in the MASPAR
file. If not set the terminal shall
only handle VAT for the cards
that have the VAT flag set in
bitfields_2 for the actual prefix.
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Page: 48 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.3. The DCPAR file
Tag Max For- Value Description Mag Chip Stand Inte- Inte-
length mat alone grated grated
(hex) direct via
9F41 02 N Max_Len_Sf This tag is only supplied for backward N N N N N
compability, the tag Max_Len_SF2
shall be used instead.
9F42 06 N Max_ Max accumulated mag amount (SEK) Y N Y Y* Y~
Amo_Sf in S&F before terminal must go
online.
Note: When the terminal goes online,
the S&F queue is always emptied
before the actual transaction is
handled.
9F43 02 N Max_Nbr_Sf This tag is only supplied for N N N N N
backward compability, the tag
Max_Nbr_SF2 shall be used instead.
9F81 02 BIN Max_ Max number of transactions in S&F Y Y Y Y* Y~
06 Len_Sf2 (chip and magstripe) Max_Len_Sf is
the (terminal imposed) max length
of the S&F queue. In a single message
environment, this value may be tuned
to provide a useful compromise
between possible number of
consecutive offline transactions, and
the time required to empty the queue
once the terminal goes online. When
this limit is reached, the terminal
should try to go online and empty the
queue even if the current transaction is
completed offline. This parameter also
represents the maximum number of
transactions that can be lost in a single
message terminal if the terminal
breaks down and the receipts are not
available for manual recover.
Note: When the terminal goes online,
the S&F queue is always emptied
before the actual transaction is
handled.
9F81 02 BIN Max_ Max number of mag transactions in Y Y Y Y* Y~
07 Nbr_Sf2 S&F before terminal must go online.
Note: When the terminal goes online,
the S&F queue is always emptied
before the actual transaction is
handled.
9F44 05 ANS Pan_Min_ Format: NN:NN Min/Max number of Y Y Y Y* Y*
Max PAN digits handled by the terminal.
Used as (manual) entry check before
prefix check.
9F45 14 ANS Receipt_ Printed on top of re Y Y Y N N
Head_L_1 ceipt if not empty
9F47 03 ST Transaction_ Member in the transaction control Y Y Y Y* Y*
descriptor table, see description below.
9F48 04 N Close_ Format: HHMM. Y Y Y N N
Batch_ Reconcilition time, at this time each
Page: 49 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Tag Max For- Value Description Mag Chip Stand Inte- Inte-
length mat alone grated grated
(hex) direct via
Time day an automatic reconciliation should
be performed and a close batch
transaction should be sent to the host
or stored in the S&F queue if com.
fails. If not a valid time (e.g. 9999),
no automatic reconciliation is
performed and no close batch is sent.
Tag Max For- Value Description Mag Chip Stand Inte- Inte-
length mat alone grated grated
(hex) direct via
9F49 10 AN Prim_Phn_ The actual phone number to be dialled, Y Y Y Y* YR
Nbr_B24 contains area number and may contain
country prefix.
9F4A 10 AN Second_ -"- Y Y Y Y* YR
Phn_Nbr_
B24
9F5A 15 ANS Prim_IP_ Primary IP-address/port for B24. Max Y Y Y Y* YR
adr_B24 21 char. i.e.
NNN.NNN.NNN.NNN:NNNNN
Example: 192.168.8.100:9999
9F5B 15 ANS Sec_IP_adr_ -"- Y Y Y Y* YR
B24
9F4B 01 AN MAC- V = VDUKT, M = Master/Session Y Y Y Y* Y*
Scheme
9F4C 01 BIN App_ See description below Y Y N N N
Option_
Flags
9F4D 04 CN Acquirers_ The aquirers customer number Y Y Y Y* YR
Ref_Nbr referencing the agreement with the
customer.
9F4E 03 BIN Term_ Shall be set according to the ICS for N Y Y Y* Y*
Capabilities the level 2 certification for the specific
terminal. For further information see
EMV Book 4 Annex A.2.
9F4F 05 BIN Add_Term_ Shall be set according to the ICS for N Y Y Y* Y*
Capabilities the level 2 certification for the specific
terminal. For further information see
EMV Book 4 Annex A.3.
9F51 var BIN AID 5 byte RID and max. 11 bytes PIX N Y Y Y* Y*
according to EMV specification. Note:
The AID must be used in conjunction
with the AID_Bitfield in the
corresponding position.
9F37 01 BIN AID_Bitfield See description below. Note: The N Y Y Y* Y*
position of the AID_Bitfield must be
matched with the position of the AID.
9F54 05 BIN RID Identifies card scheme to which the N Y Y Y* Y*
data set belongs (tag 9F54 – 9F59)
9F55 05 BIN TAC bitmap May cause the transaction to be N Y Y Y* Y*
denial unconditionally denied. See EMV
spec.
9F56 05 BIN TAC bitmap May cause the transaction to be forced N Y Y Y* Y*
online online. See EMV spec.
9F57 05 BIN TAC bitmap Used with terminals without online N Y Y Y* Y*
default capability. See EMV spec.
9F58 var BIN Default_ May contain '9F3704', i.e. the (EMV) N Y Y Y* Y*
Page: 50 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Tag Max For- Value Description Mag Chip Stand Inte- Inte-
length mat alone grated grated
(hex) direct via
DDOL tag and length of "Unpredictable
Number" only. See EMV spec.
9F59 var BIN Default_ Defined by the card scheme. See EMV N Y Y Y* Y*
TDOL spec.
9F5C 02 BIN Appl_ Defined by the card scheme N Y Y Y* Y*
version_
number
BF7F var BIN Additional The data in the constructed data object N Y Y Y* Y*
Data is the RID-specific tag-number the
Required for length and the data value. Max length
the RID 40 hex. An example is the Transaction
Category Code defined for Mastercard
9F53 normally set to „R‟ for retailer.
E.g. BF7F049F530152.
BF38 05 BIN Parameters Random Transaction Selection N Y Y Y* Y*
for random parameters
selection See EMV Book 3 section 10.6.2
9F39 01 BIN Target_ Value 0 - 99 according to EMV N Y Y Y* Y*
Percentage
9F3A 03 BIN Threshold_V Amount below chip floor limit N Y Y Y* Y*
alue according to EMV
9F3B 01 BIN Max_ Value 0 – 99 according to EMV N Y Y Y* Y*
Target_
Percentage
9F81 02 AN Terminal This tag shall be set according to the N Y Y Y* Y*
08 Type ICS of the level 2 certification for the
specific terminal. For further
information see EMV Book 4 Annex
A1.
D.3.1. Transaction descriptors.
Each transaction descriptor is a 3 byte field where the first 2 byte define a transaction
type or function according to:
"PU" = Purchase
"CA" = Cash Advance
"PA" = Purchase Advice (Swedish "Efterregistrering")
"RE" = Refund
"AD" = Adjustment
"LO" = Logon
"EX" = Electronic follow up
"CB" = Close Batch
"BE" = Balance Enquiry
"DE" = Deposit
"WI" = Withdrawal
It is only mandatory to send Transaction Descriptors that are applicable for the
application and allowed by the acquirer.
Page: 51 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Transaction Descriptors not known to the application shall be ignored.
The third byte is a bitfield defined as follows:
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 Alone grated grated
direct via
1 x x x x x x x Transaction allowed Y Y Y Y* Y*
x 1 x x x x x x Swiped entry allowed Y Y Y Y* Y*
x x 1 x x x x x Manual entry allowed Y Y Y Y* Y*
x x x 1 x x x x Password protected. The Y Y Y NSa NSa
password used is the password
given in the MASPAR file.
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Note: The bit settings reflect the acquirers restrictions on the particular transaction type. If the terminal
supports user administration, it is important that a user is not granted privileges that are in
conflict with the acquirers restrictions.
Page: 52 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.3.2. App_Option_Flgs
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x Auto_Close_Batch. Normally Y Y Y NSa NSa
only used in restaurant
environments. If this bit is set,
all open transactions should be
automatically closed before
sending the close batch
transaction. An open
transaction is a transaction that
is only authorized and a closed
transaction is an authorized
transaction that has been
completed with an electronic
follow up transaction.
x 1 x x x x x x Auto_Close_Shift. The same Y Y Y NSa NSa
functionality as above but for
handling close of each open
shift.
x x 1 x x x x x Pre_Dial If this bit is set, the Y Y Y Y* YR
terminal dials as soon as the
host is known.
x x x 1 x x x x Preprinting If this bit is set, the Y Y Y N N
terminal prints receipt details
as soon as they are known.
x x x x 1 x x x Batch Settlement: Y Y Y N N
When the merchant performs
reconciliation in the terminal, a
close batch transaction is
created and sent to the host.
The transaction contains
consolidated data from all
transactions since the previous
close batch and the batch
number. The acquirers will pay
the merchant according to the
totals in the batch settlement
with the batch number as
reference.
x x x x x 1 x x RFU
x x x x x x 1 x Forced magstripe fallback N Y Y Y* Y~
allowed. In an attended
environment, the merchant may
force magstripe fallback, but
only if this bit is set.
x x x x x x x 0 RFU
Page: 53 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.3.3. AID Bit field
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x 0 = exact match used N Y Y Y* Y*
1 = partial match used
x 1 x x x x x x 0 = Fallback to magstripe not N Y Y Y* Y~
allowed
1 = Fallback to magstripe
allowed
Note that bit 2 in
App_Option_Flgs in DCPAR
and this bit must be set in order
to perform fallback to
magstripe on AID level.
x x 1 x x x x x 0 = Referral and voice N Y Y Y* Y*
authorisation not allowed
1 = Referral and voice
authorisation allowed
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Page: 54 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4. The BINPAR file
Tag Max For- Value Description Mag Chip Stand Inte- Inte-
Length mat alone Grated grated
(hex) direct via
82 28 BIN BINDOL Tag and length for all fields in a Y Y Y Y* Y*
prefix row. Note that the length
of the bindol may increase from
hex 20 in the future if new prefix
dependent fields are added.
85 06 CN Low_prefix The lowest prefix of the range Y Y Y Y* Y*
for which dependent parameters
are valid. See note below.
86 06 CN High_prefix Highest prefix of the range for Y Y Y Y* Y*
which dependent parameters are
valid. See note below.
87 02 ANS PAN_length Code for card number length to Y Y Y Y* Y*
which the card must conform:
*A=PAN length must
be 13-16
*B=PAN length must
be 12-19
14=PAN length must
be 14
|
23=PAN length must
be 23
88 01 BIN Referrals_ Index into table of phone Y Y Y Y* Y*
phone _index numbers (tag B7) for voice
authorization. Value 0 for 1st
number.
89 03 ANS Financial_ Short form of financial Y Y Y Y* Y*
Institution institution name, maximum 3
characters left justified, padded
with space. Used to indicate
which acquirer that handles this
card. Used in reports to split
settlements per acquirer.
8A 01 BIN Card_Name_ Index into table of names of card Y N Y Y* Y*
Index products (not issuing banks).
Value 0 for 1st card name.
8B 01 BIN Bitfields_1 See description below Y Y Y Y* Y*
8C 01 BIN Bitfields_2 See description below Y Y Y Y* Y*
8D 01 BIN Bitfields_3 See description below Y Y Y Y* Y*
95 01 BIN Bitfields_4 See description below Y Y Y Y* Y*
96 01 BIN Bitfields_5 See description below Y Y Y Y* Y*
8E 01 N Host_Ident_ The host to which the card is Y Y Y Y* YR
Nbr mapped (RFU).
8F 03 BIN Mag_trans_ Maximum purchase amount Y N Y Y~ Y~
floor_limit when terminal is offline
(magstripe transaction)
90 03 BIN Chip_trans_ Terminal floor limit for chip N Y Y Y~ Y~
floor_limit transactions i.e. the maximum
amount for which the terminal
may make an offline transaction.
91 03 BIN Max_ Maximum purchase amount for Y Y Y Y~ Y~
purchase_amt this prefix.
Page: 55 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Tag Max For- Value Description Mag Chip Stand Inte- Inte-
Length mat alone Grated grated
(hex) direct via
92 03 BIN Max_Amo_ Max amount cash back allowed Y Y Y Y~ Y~
Cash_Back (SEK) If = 0, cash back is not
allowed.
93 03 BIN Max_Amo_ Max amount cash advance (SEK) Y Y Y Y~ Y~
Cash_Adv
97 03 BIN Max_Amo_ Max amount for refund/deposit Y Y Y Y~ Y~
Refund (SEK).
94 03 BIN Min_ Minimum accepted purchase Y Y Y Y~ Y~
purchase_amt amount
99 02 BIN Extra_Data_Set_ Index into table of Extra Data Y Y N Y* Y~
Index Set. Value 0 for 1st index.
9F81 02 BIN Card Issuer_ Index into the table of Card_ N N N N Y*
0D index Issuers. Value 0 for 1st index.
9F81 02 BIN Card_Type_ Index into the table of N N N N Y*
0E Index Card_Types. Value 0 for 1st
index.
98 10 ANS Phone_nbr_ Country code + area code + Y Y Y Y* Y*
Voice_auth number
9A 10 ANS Card_Name The name of a card e.g. "VISA" Y N Y Y* Y*
BC 80 BIN Extra Data Set See extra dataset below Y Y N Y* Y~
9F81 10 ANS Card_Issuer The name of the Card_Issuer N N N N Y*
0A
9F81 3 ANS Card_Type Used by TSP:s to decide the N N N N Y*
0C Card Type. The following Card
Types are allowed:
PAC Payment Card
CRC Credit Card
DEC Debet Card
PCC Payment/Credit Card
UNC Unspecified Card
NPC National/Profiled Card
Note Maximum 12 digits coded 1 per half byte (BCD) and padded with F to the fixed length of 6 bytes.
Ex1: Low_prefix = 30 4F FF FF FF FF and High_prefix = 30 5F FF FF FF FF will match all
cards starting with 304 or 305 unless it is also matched in a range with more significiant
digits (smaller range) also starting with 304 or 305).
Ex2: Low_prefix = 30 6F FF FF FF FF and High_prefix = 30 6F FF FF FF FF will define a range
matching all cards starting with 306, i.e. 30 60 00 00 00 00 to 30 60 99 99 99 99. The high
and low prefix for a prefix row should contain the same number of significiant digits.
Page: 56 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4.1. Bitfields_1
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x Signature allowed. If conflict Y N Y Y* Y*
with SVC, the service code is
valid (PIN mandatory)
x 1 x x x x x x PIN allowed. If conflict with Y N Y Y* Y*
SVC, the service code is valid
(PIN mandatory)
x x 1 x x x x x Check CDV. Makes it possible Y N Y Y* Y*
to skip this check if e.g. the
card doesn´t follow the
standard.
x x x 1 x x x x Check Service Code when Y N Y Y* Y*
offline.
Makes it possible to disregard
service code if the terminal is
offline.
x x x x 1 x x x Check Service Code when Y N Y Y* Y*
online. Makes it possible to
disregard service code if the
terminal is online.
x x x x x 1 x x Offline handling allowed. Y N Y Y* Y*
Normally used to specify if
offline handling is allowed
when SVC position 2 = 0
(normal authorisation). If bit 5
above is not set, this bit can be
used to tell if offline handling
is allowed in conflict with the
SVC.
x x x x x x 1 x Only online (maestro, Y N Y Y* Y*
electron). If SVC position 2 = 0
(normal authorisation), this bit
can be used to force online
authorisation only.
x x x x x x x 1 Always handle as magstripe. If Y Y Y Y* Y*
SVC position 1 is 2 or 6 (chip
card), this bit can be used to
allow the card to be handled as
magstripe card.
Page: 57 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4.2. Bitfields_2
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 Alone grated grated
direct via
1 x x x x x x x Manual entry is allowed Y Y Y Y* Y*
(PAN). This bit if not set, it
overrides the card independent
bit ”Manual entry allowed” (bit
6 in transaction descriptor in
DCPAR file).
x 1 x x x x x x CV2 required (manual entry). Y Y Y Y* Y*
If this bit is set, the additional
input of the CV2 must be made
in the dialogue (in addition to
PAN and Expire date).
x x 1 x x x x x Imprint of embossing is Y Y Y Y* Y*
required (in conjunction with
manual entry as above). If this
bit is set, an imprint of the card
embossing must be made to
prove that the card was present.
x x x 1 x x x x This prefix range is blocked. Y Y Y Y* Y*
Indicates that this range of
PAN should be rejected. (”Card
not Valid”).
x x x x 1 x x x This is a national card. Used in Y N Y Y* Y*
conjunction with SVC position
1 = 5 or 6 (domestic card) to
indicate if the card is valid for
national use only.
x x x x x 1 x x Issuer country is not known. If Y N Y Y* Y*
this bit is set it overrides the bit
above and the transaction must
be sent online if SVC position
1 = 5 or 6.
x x x x x x 1 x Customer may select account Y Y Y Y* Y*
type. Used to indicate if a
dialogue for selection of
account type
(”KREDIT/KONTO”) should
be used.
x x x x x x x 1 Always prompt for VAT. If set Y Y Y Y* Y*
always prompt (and allow
change of) VAT. If not set, the
bit 5 in Option_flgs in
MASPAR file decides if this
dialogue should be shown.
Page: 58 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4.3. Bitfields_3
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x This is a bonus card Y Y Y Y~ Y~
x 1 x x x x x x This is a payment card. If bit 8 Y Y Y Y* Y*
and 7 are set it is a combined
card and the terminal normally
asks the cardholder if he/she
wants to pay with the card or
not.
x x 1 x x x x x Prompt for special payment Y Y Y Y* Y*
code. If this bit is set, a special
dialogue allows the operator to
enter a 1 to 3 digit code
according to bits 2 to 4 below
that may be associated with
payment credit length or other
similar agreements between the
card issuer and the merchant.
x x x 1 x x x x Max payment code length = 1 Y Y Y Y* Y*
digit
x x x x 1 x x x Max payment code length = 2 Y Y Y Y* Y*
digit
x x x x x 1 x x Max payment code length = 3 Y Y Y Y* Y*
digit
x x x x x x 1 x Man input of transaction Y Y Y Y* Y*
allowed. Indicates if it is
allowed to manually enter a
transaction to be debited
without any authorisation
handling in the terminal.
(”Efterregistrering”)
x x x x x x x 1 Forced magstripe fallback N Y Y Y* Y~
allowed (purchase). Note that
bit 2 in App_Option_Flgs in
DCPAR and this bit must be
set in order to perform fallback
to magstripe on BIN level.
D.4.4. Bitfields_4
Allowed transactions for the BIN
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x Purchase Y Y Y Y* Y*
x 1 x x x x x x Refund Y Y Y Y* Y*
x x 1 x x x x x Cash Advance Y Y Y Y* Y*
x x x 1 x x x x Balance Inquiry Y Y Y Y* Y*
x x x x 1 x x x Withdrawal Y Y Y Y* Y*
x x x x x 1 x x Deposit Y Y Y Y* Y*
x x x x x x 1 x Pin Change Y Y Y Y* Y*
x x x x x x x 0 RFU
Page: 59 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4.5. Bitfields_5
Only valid for Cash Advance and Withdrawal
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x Signature allowed Y Y Y Y* Y*
x 1 x x x x x x PIN allowed Y Y Y Y* Y*
x x 1 x x x x x Manual entry is allowed (PAN) Y Y Y Y* Y*
x x x 1 x x x x CV2 required (manual entry) Y Y Y Y* Y*
x x x x 1 x x x Imprint of embossing is Y Y Y Y* Y*
required
x x x x x 1 x x Check Service Code when Y N Y Y* Y*
online
x x x x x x 1 x Forced magstripe fallback N Y Y Y* Y~
allowed (Cash Advance,
Withdrawal). Note that bit 2 in
App_Option_Flgs in DCPAR
and this bit must be set in order
to perform fallback to
magstripe on BIN level.
x x x x x x x 0 RFU
Page: 60 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4.6 Extra_Data_Set Only valid for integrated solutions and special
environment
The extra data table is used for integrated solutions and the content is dependent of the environment.
The following data with associated tags could be present in the extra data set.
Tag Len Format Value Descriptiom Mag Chip Stand Inte- Inte-
Alone grated grated
direct via
9F3C 02 BIN Bonus_Routine_ A bonus routine number Y Y N Y~ Y~
Number assigned to the card
9F3D 01 BIN PIN_Algoritm_ If not present or value Y Y N Y~ Y~
Number `”0” =DUKT
> = customer specific PIN
algoritm
9F5D 01 BIN MAC_Algoritm_ If not present or value Y Y N Y~ Y~
Number `”0” =DUKT
> = customer specific
MAC algoritm/key
9F5E 03 BIN No_Auth_Amount Purchase forced approved Y Y N Y~ Y~
below this amount at
merchants risc
9F3E 01 BIN Send_Track See description below Y N N Y* Y*
9F6E 03 BIN Auth_Amount Amount to be authorised Y Y N Y* Y*
(SEK)
81 03 BIN Max_Allowed_ Max allowed purchase Y Y N Y* Y*
Purchase when authorisation
approved
9F7B 01 BIN Bitfield_Unattend_ See description below
Gasoline
83 02 CN MCC Numeric 4 digits MCC Y Y N Y* Y*
D.4.7 Bitfield Send Track
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
0 x x x x x x x RFU
x 0 x x x x x x RFU
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 1 x x Send track 3 Y N N Y* Y~
x x x x x x 1 x Send track 2 Y Y N Y* Y~
x x x x x x x 1 Send track 1 Y N N Y* Y~
Page: 61 of 71
Babs and CEKAB Software & Parameter Download version 2.3
D.4.8 Bitfields_Unattended_Gasoline
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip Stand Inte- Inte-
8 7 6 5 4 3 2 1 alone grated grated
direct via
1 x x x x x x x Advice required Y Y N Y* Y*
x 1 x x x x x x Reversal of initial authorisation Y Y N Y* Y*
required if no purchase
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
D.5. The CAPUB file
Tag Max For- Value Description Stand Inte- Inte-
length mat alone grated grated
(hex) direct via
9F73 05 BIN RID Identifies card scheme to which Y Y* Y*
data set belongs
9F74 01 BIN CA public key index Together with RID identifies this Y Y* Y*
unique data set
9F75 01 BIN CA Hash method Hash method used to produce the Y Y* Y*
Key check sum
9F76 01 BIN CA public key alg. Algorithm used to produce Y Y* Y*
signature with this key
9F77 81var BIN CA public key modulus Value of public key modulus, var Y Y* Y*
max = 248 (= hex F8)
9F78 var BIN CA public key exponent Either 3 (var = '01') or 216 + 1 (var Y Y* Y*
= '03')
9F79 14 BIN CA public key check Check value using SHA-1. Y Y* Y*
sum Calculated on concatenation of the
value fields (i.e. excluding tag and
length fields) above (except CA
Hash method and CA public key
alg.) in the given order.
9F7A 08 BIN MAC See Note below. Y Y* Y*
Note: Additional (DES) MAC for protection of all the n key data sets. The MAC is constructed by
first concatenating all the n SHA-1 checksums in the order they appear in the file, then the MAC
is calculated on this (n * 20 long) buffer. The acquirer provides this MAC so the terminal can
verify that CA public keys have not been fraudulently changed or added after loading, which
would allow counterfeit cards to be used. The test should be done at power up and each time
new software has been loaded. The test should be done as follows:
For each key data set, the terminal calculates the SHA-1 digest and compares to the SHA-1
digest provided when the file was loaded. If not equal, the CAPUB file must be reloaded.
The terminal concatenates all SHA-1 digests in the order received in the file and provides this
data and the MAC received to the terminals secure device that verifies the MAC using a secret
key shared with the acquirer. If not verified correctly, the CAPUB file must be reloaded.
Page: 62 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Appendix E – Handling of key download to PED:s
E.1. General
PIN and offline capable EMV terminals need to verify that parameter files containing
sensitive data like e.g. CA public keys are authentic. Therefore it needs to hold keys
for verification of MAC in a secure device. Application software that is to be down-
loaded to the terminal also needs to be verified in the same way. As a consequence, the
PED should, in addition to hold PIN related keys, also hold the MAC keys required for
verification of files downloaded to the terminal. The hierarchy of keys will be as
follows:
BKLK4BNK
GMKLK TIK4BNK
[KEYTYPE] [KEYTYPE] [KEYTYPE]
The initial BKLK is factory installed but is replaced when the PED is loaded with
operational keys as described below. The GMKLK and TIK4BNK are in principle
downloaded encrypted with the current BKLK4BNK, and the MAC keys (between 3
to10 keys) are encrypted with GMKLK.
Note that in some environments, the PED may contain more keys than indicated
above. The additional keys could be keys under the control of a merchant for private
cards or keys used for other applications. The principle for download of these
additional keys is described later in this appendix.
E.2. The Initial Key File – SA (IKFS) content
The IKFS file contains keys to be loaded into a new PED. The file contains both the
PED unique keys and the version of this set of keys. The file contains keys for a single
PED.
E.2.1. The complete file content
Lev Tag Len Value Description
01 BF60 80 The IKFS content The complete file seen as a single constructed value
02 9F61 0C The IKFS version Version of this file (YYMMDDHHMMSS).
02 9F62 14 PKF name Name of the PPL Keys File
02 BF63 80 List of Initial Key data sets List of a (variable) number of Initial Key data sets
03 BF64 80 Initial Key data set First Initial Key data set
03 00 00 EOC (for first Initial Key data set)
| | | | |
03 BF64 80 Initial Key data set Last Initial Key data set
03 00 00 EOC (for last Initial Key data set)
02 00 00 EOC (for list of Initial Key data sets)
01 00 00 EOC (for file as constructed value)
Page: 63 of 71
Babs and CEKAB Software & Parameter Download version 2.3
E.2.2. The Initial Key data set content
Lev Tag Len Value Description
04 9F6D 06 PED type Identifies the type of PED being the target for all data
04 9F65 var PED Id Identifies the individual PED where the key shall be
loaded. The length of the PED Id is variable up to 16
bytes. The format is according to the manufacturers
standard and as returned from the PED when the Id is
requested.
04 9F66 08 Key type An alphanumeric string padded with blanks to the full
length that identifies the type of key to be loaded, i.e.
BKLK4BNK, GMKLK, TIK4BNK etc.
04 9F67 var Key value Encrypted key value, to be loaded to PED. Variable
length binary value. The maximum length is 255 byte.
04 9F68 var KCV Check value for the key. Variable length binary value.
The maximum length is 8 bytes.
04 9F69 08 IKSN Initial key serial number (only for UKPT PIN Key).
Fixed length binary value.
E.3. The PPL Keys File (PKF) content
The PKF file contains (encrypted) keys that are the same for many (possibly all)
PEDs/terminals. It may become necessary to replace these keys during the lifetime of a
PED. Therefore, new versions of this file may have to be created (by the KMF) and
downloaded to the PED.
E.3.1. The complete file content
Lev Tag Len Value Description
01 BF6A 80 The PKF content The complete file seen as a single constructed value
02 BF6B 80 List of PPL Key data sets List of a (variable) number of PPL Key data sets
03 BF6C 80 PPL Key data set First PPL Key data set
03 00 00 EOC (for first PPL Key data set)
| | | | |
03 BF6C 80 PPL Key data set Last PPL Key data set
03 00 00 EOC (for last PPL Key data set)
02 00 00 EOC (for list of PPL Key data sets)
01 00 00 EOC (for file as constructed value)
E.3.2. The PPL Key data set content
Lev Tag Len Value Description
04 9F66 0A Key type An alphanumeric string constructed by concatenation of
<org-id> (8 ASCII characters) and <key reference> (2
ASCII digits) that identifies the type of global key to be
loaded.
04 9F67 var Key value Encrypted key value, to be loaded to PED. Variable
length binary value. Maximum length is 255 bytes.
04 9F68 var KCV Check value for the key. Variable length binary value.
The maximum length is 8 bytes.
Page: 64 of 71
Babs and CEKAB Software & Parameter Download version 2.3
E.4. Terminal processing
E.4.1. The PPL-client
In order to understand how the terminal fetches files and in particular the PKF file, it is
important to know how the "PPL-client" SW works. Implementation details may vary
between different types of terminals, but generally it has the following characteristics:
It is a global library function, accessible from all applications.
It is independent of all applications, i.e. it has no knowledge of the content of
different files, just of the structure i.e. the common file format.
It can access some global parameters like PPL terminal id
It can access the terminal‟s means of communication.
It can access cryptographic functions in a secure device in order to verify MACs
or signatures provided in the received files.
It can access the terminal display in order to report the progress of file transfer
It shall know the status of the keys loaded in the PED
It shall know which key types are required by the PED and perform the actual key
loading using the PPL
Generally, the PPL-client can be viewed as a filter that performs file transfer while at
the same time enforcing the required security functions. The syntax could be like:
int ppl_get_file (<file_name>, <file_handle>, <com_parameters>, <sec_flag>)
file_name = The name of the file to be fetched from the PPL-server
file_handle = A pointer to a memory area or a filedescriptor for an open file
where the PPL-client can store the received file
com_parameters = One or more parameters describing how the PPL-server is
accessed. Could be a pointer to a "com_struct"
sec_flag = A flag telling the PPL-client if a file and content MAC should
be present and verified. If sec_flag is TRUE but the file has no
protection or the MAC doesn‟t verify, it must be rejected. If the
sec_flag is FALSE and the received file has MAC protection, it
must also be rejected.
E.4.2. The Key Files and the Control File
The Control File is a means for the terminal to get information on which applications
and parameters it is supposed to hold. The terminal holds information on the version of
any downloadable file it is currently using. The Control File is fetched from the PPL-
server as a result of one of several events (see section 5.1 of the PPL-spec.). For each
file, the version given in the Control File is compared to the current version and if
different, the terminal initiates the fetch of the new file.
For various reasons, it is not possible or practical to use the Control File as a means to
tell the terminal to fetch a new key file. Therefore the Control File has no entries for
the key files and the terminal has to use other indications in order to know if a key file
should be fetched (described later).
Page: 65 of 71
Babs and CEKAB Software & Parameter Download version 2.3
E.4.3. Fetching terminal parameter files
The control file and the terminal parameter files and their content are always protected
by a MAC. This implies that these files cannot be fetched and verified until the PED is
operational (loaded with all its keys).
Application PPL-client com PPL-server
port
The application always calls the PPL-client with the sec_flag set to TRUE. This must
be verified for all applications to be loaded in the terminal as part of the application
acceptance test. If the file has no MAC or the MAC doesn‟t verify, it must be rejected
by the PPL-client. Provided that the PED is operational, the Application fetches the
file and moves the content fields to internal storage.
E.4.4. Fetching key files
E.4.4.1. Fetching
When a key file is to be fetched, the terminal logs on to the PPL-server as “User Id”=
<PED-type> (if FTP is used) or with the “TSPID” field in the FRQ message = <PED-
type> (if the alternative protocol is used). The <PED-type> home directory contains all
keyfiles for this type of PED. For a directly connected terminal, there is one IKFS file
for each PED, and the name of the IKFS file is constructed like:
IKFS<PED-Id>. If the PED-Id is binary, it must be converted to ASCII-charaters 0-9,
A-F. The length of the ASCII PED-Id is maximum16 bytes, if binary PED-Id is used
the length of the PED-ID is maximum 8 bytes.
To fetch PPL-keys, a new request with the “User Id”=<PED-type> (if FTP is used) or
with the “TSPID” field in the FRQ message = <PED-type> (if the alternative protocol
is used). The name of the PKF file should be extracted from the IKFS file.
For the IKFS file, the application that uses the PPL-client to fetch the file must know
the hierarchy of keys in order to decide if all the required keys are present.
PED PPL-client com PPL-server
interface incl. PED port
application load appl.
PED
The PED load application is a part of the PPL-client. The PED load application may be
different for different PED types. The keyfiles are the only files allowed to be fetched
with sec_flag set to FALSE.
Page: 66 of 71
Babs and CEKAB Software & Parameter Download version 2.3
E.4.4.2. Additional keys
Additional keys shall be downloaded using the same principle as described above.
They shall be transported in the IFKS-file described above. The PPL-client shall
contain the information how the additional keys are downloaded and processed, as well
as the key types used for the additional keys. This is further described in the document
„Babs and CEKAB Security Requirements for an EFTPOS Terminal‟.
E.4.4.3. Downloading of keys
The actual process for downloading and installation of the keys and the associated
error handling is described in the document „Babs and CEKAB Security Requirements
for an EFTPOS Terminal‟.
Page: 67 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Appendix F – Additional Parameter files for iPOS
F.1. General
The files below are only used for integrated solutions.
F.2. The IPOSTEXT file
This is an additional file for iPOS. The intention of this file is that it shall be possible
to change display messages and text messages without re-certify the application. The
vendor of an iPOS implementation shall supply a list of the default display messages
and texts messages used in the terminal. Each display message and text message must
have a unique alphanumeric identity and a maximum length.
A new display message or text message can be downloaded using the iPOSTEXT file.
Every message that shall be changed is transported in a container, change text,
followed by the identity of the message to be changed and the actual new message.
The message could be either a string containing the actual text or a vendor specific
definition of form. The terminal shall then replace the message in the terminal after the
file is downloaded.
If the new message is a display message used in connection with a clear text input at
the keyboard used for PIN entry, the new display message must be authenticated by the
terminal according to the rules in PCI PED. Therefore if the display message is used
for clear text input at the PED, a MAC-value is sent in the change text container.
Normally, one TextId post is used per display row in order to be compliant with the
iPOS specification.
The approval of a display text used for clear text input and the calculation of the MAC
shall be under control of the security administrator. The calculations of these MAC-
values are performed outside the PPL-system. The procedure is that the security center
calculates the MAC using the 4th PPL-key. The PPL-keys are protected by key-tagging
when downloaded to avoid unauthorised changes of keys.
The iPOSTEXT file shall be distributed according to the PPL concept with protections
of the content and transport to avoid unauthorised changes of texts.
Lev Tag Len Format Value Description
01 BF8101 80 IPOStext file
02 BF8102 80 Change_Text
03 9F8103 04 ANS TextId First Textid
03 9F8104 50 ANS New_Text
03 9F8105 08 BIN New_Text_Mac Optional if text is used for clear text input
02 00 00 EOC
02 BF8102 80 Change_Text
03 9F8103 04 ANS TextId Second Textid
03 9F8104 50 ANS New_Text
03 9F8105 08 BIN New_Text_Mac Optional if text is used for clear text input
02 00 00 EOC
| | | | |
02 BF8102 80 Change_Text
Page: 68 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Lev Tag Len Format Value Description
03 9F8103 04 ANS TextId Last Textid
03 9F8104 50 ANS New_Text
03 9F8105 04 BIN New_Text_Mac Optional if text is used for clear text input
02 00 00 EOC
01 00 00 EOC
F.3. The IPOSCONF file
This is an additional file for iPOS. The intention of this file is to supply the iPOS
terminal with configuration data and other data outside the BINPAR file.
The IPOSCONF file shall be distributed according to the PPL concept with protections
to avoid unauthorised changes of texts.
Lev Tag Len Format Value Description Mag Chip
01 BF8110 80 IPOSCONF file
02 BF8111 80 Bonus_AID_list "Sequence of AID:s"
03 BF8112 var AID_record First element in AID list
04 9F8113 var BIN First AID 5 byte RID and max. 11 bytes PIX N Y
04 9F8114 1 BIN AID_Bitfield See description below
03 BF8112 var AID_record Second element in AID list
04 9F8113 var BIN Second AID 5 byte RID and max. 11 bytes PIX N Y
04 9F8114 1 BIN AID_Bitfield See description below
| | | |
03 BF8112 var AID_record Last element in AID list
04 9F8113 var BIN Last AID 5 byte RID and max. 11 bytes PIX N Y
04 9F8114 1 BIN AID_Bitfield See description below
02 00 00 EOC
02 BF8115 80 CONFIG
03 9F8116 01 BIN Number _ 0 = no bonus cards Y Y
Bonus_Card_ > 0 = number of bonus cards allowed
Allowed during a purchase
03 9F8117 02 CN Default_MCC The default Merchant Category Code Y Y
03 9F8118 01 BIN iPOS_Config_ See description below Y Y
Bitfield
02 00 00 EOC
01 00 00 EOC
F.3.1. AID_Bitfield
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning Mag Chip
1 x x x x x x x 0 = exact match used N Y
1 = partial match used
x 0 x x x x x x RFU
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Note: The bit settings reflect the acquirers restrictions on the particular transaction type. If the terminal
supports user administration, it is important that a user is not granted privileges that are in
conflict with the acquirers restrictions.
Page: 69 of 71
Babs and CEKAB Software & Parameter Download version 2.3
Page: 70 of 71
Babs and CEKAB Software & Parameter Download version 2.3
F.3.2. iPOS_Config_Bitfield
Bit Bit Bit Bit Bit Bit Bit Bit Meaning Mag Chip
8 7 6 5 4 3 2 1
1 x x x x x x x 0 = Authoristion etc via SA_CI Y Y
1 = Authorisation etc direct
x 1 x x x x x x 0 = TSP connection via SA_CI Y Y
1 = TSP connection direct
x x 1 x x x x x 0 = Attended Y Y
1 = Unattended
x x x 1 x x x x 0 = If Bin not in BINPAR display “CARD NOT Y Y
VALID”
1 = If Bin not in BINPAR send card to SA_CI
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Page: 71 of 71
