thailand smart card standard application requirementss3.amazonaws.com/zanran_storage/... ·...

Thailand Smart Card Standard A pplication V ersion 1.0

THAILAND

Smart Card Standard Application

Requirements

Version 1.0

Thailand Smart Card Working Group01 April 1999

Released Number: 1.1


Thailand Smart Card Standard Application RequirementsINDEX

1. Introduction ...........................................................................................................................41.1. Smart card Scheme Overview..........................................................................................4

1.1.1. Scope .......................................................................................................................41.1.2. Scheme Structure......................................................................................................5

1.2. Smart card Requirements.................................................................................................81.2.1. Compliance Requirements.........................................................................................81.2.2. Data Elements and Files............................................................................................91.2.3. Standard Commands...............................................................................................10

1.3. Terminal Requirements..................................................................................................111.3.1. Terminal Types ......................................................................................................111.3.2. Terminal Capabilities..............................................................................................11

1.4. Application Requirements..............................................................................................121.4.1. Application Scope...................................................................................................121.4.2. Application Selection.............................................................................................131.4.3. Transaction Processing ...........................................................................................131.4.4. Data Integrity .........................................................................................................151.4.5. Year 2000 Support.................................................................................................15

1.5. Network Requirements ..................................................................................................161.6. Settlement and Clearing Requirements ...........................................................................17

2. Security Requirements.........................................................................................................182.1. Smart cards Delivery.....................................................................................................182.2. Symmetric Key Management .........................................................................................18

2.2.1. Symmetric Key Generation .....................................................................................182.2.2. Key Distribution.....................................................................................................192.2.3. Key Loading Process ..............................................................................................19

2.3. Asymmetric Key Management .......................................................................................192.3.1. Public Key Pairs Generation ...................................................................................192.3.2. Certification Authority............................................................................................20

2.4. Card Personalization .....................................................................................................202.4.1. Chip Personalization...............................................................................................202.4.2. Magnetic Stripe Encoding and Embossing...............................................................21

2.5. Post Personalization ......................................................................................................212.5.1. Files Access Conditions..........................................................................................212.5.2. Files And Application Locking................................................................................222.5.3. Secret Code Protection............................................................................................22

2.6. Cryptographic Security Requirements............................................................................222.6.1. Temporary Session Key Generation ........................................................................222.6.2. Card Authentication................................................................................................222.6.3. Cardholder Authentication....................................................................................232.6.3. Secure Messaging...................................................................................................23

3. ID Card Application.............................................................................................................243.1. Functional Requirements ..............................................................................................243.2. Application Owner ........................................................................................................253.3. Data Requirements ........................................................................................................253.4. Card Surface Requirements ...........................................................................................263.5. Security Requirements...................................................................................................273.6. Application Transactions...............................................................................................27


4. Credit/Debit Card Application..............................................................................................284.1. Functional Requirements ..............................................................................................284.2. Application Owner ........................................................................................................284.3. Data Requirements ........................................................................................................284.4. Card Surface Requirements ...........................................................................................294.5. Security Requirements...................................................................................................294.6. Application Transactions...............................................................................................30

5. Electronic Purse Application ................................................................................................315.1. Functional Requirements ...............................................................................................315.2. Application Owner ........................................................................................................325.3 Data Requirements .........................................................................................................325.3. Card Surface Requirements ...........................................................................................335.4. Security Requirements...................................................................................................335.5. Application Transaction ................................................................................................34

6. Loyalty Application..............................................................................................................366.1. Functional Requirements ...............................................................................................366.2. Application Owner ........................................................................................................366.3. Data Requirements ........................................................................................................376.4. Card Surface Requirements ...........................................................................................386.5. Security Requirements...................................................................................................386.6. Application Transaction ................................................................................................38

7. Pilot Project .........................................................................................................................417.1. Producing specifications ................................................................................................417.2. Developing prototypes and conducting test.....................................................................417.3. Building system facilities and network...........................................................................417.4. Conducting pilot run......................................................................................................417.5. Rolling out as commercial .............................................................................................427.6. Refining and evaluating achievement..............................................................................427.7. Ongoing operations for open-end...................................................................................42

Appendix A - Terminal Types ..................................................................................................44Appendix B - BER-TLV Data Object .......................................................................................45

B.1. Coding of BER-TLV Data Objects..............................................................................45B.1.1 Coding of the Tag Field of BER-TLV Data Objects...............................................45B.1.2 Coding of the Length Field of BER-TLV Data Objects ..........................................46B.1.3 Coding of the Value Field of Data Objects.............................................................46

Appendix C – Transaction Message Format .............................................................................48C.1. Credit Card Transaction Message Formats..................................................................49C.2. Debit Card Transaction Message Formats...................................................................59C.3. Electronic Purse Transaction Message Format ...........................................................68C.4. Loyalty Program Transaction Message Formats ..........................................................73

Appendix D - Normative References.........................................................................................78


1. Introduction

1.1. Smart card Scheme Overview

1.1.1. Scope

Form a past decade smart cards are widespread popular solution in many parts of the world. A group of international card associations has developed the open standard smart card specifications for payment application and more applications in the future.

The Thailand smart card working group was formed by the commencement of National Electronics and Computer Technology Center (NECTEC) to develop the smart card standard application requirements for Thailand. The primary purpose of Thailand smart card standard requirements is to ensure interoperability between products from different manufacturers and application venders. The standard requirements shall pave a way for all smart card players to build up a same application scheme and a same network that allow all parties sharing their benefits out of their terminals and networks. However the requirement is not mandated the interoperability between others different commercial applications.

This requirement specification has objectives as following:• Ensure a common framework for all smart card application providers• Provide sufficient flexibility to accommodate interoperability of products from

different manufacturers• Address industry-specific business practices• Offer opportunities to expand smart card markets and to leverage existing terminals,

network and IT infrastructure

The scope of functions is opened for one or more card applications to be co-exist on the same multi purpose smart card. The following are applications that are referenced in this specification:

1) ID Card Application

2) Credit/Debit Card Application

3) Electronic Purse Application

4) Loyalty Card Application

There are key words expressed in these standards that tell you what is mandatory and what is optional. WILL or SHALL or SHOULD are mandatory while MAY is an optional term.

The Thailand smart card working group is responsible to develop the preliminary standard application requirements for multi-purpose smart card. The smart card Scheme Provider or the application provider whose propose to implement the national standard smart card scheme should submit the technical details specification to the Thailand smart card committee before the implementation shall be commenced.

The Thailand smart card working group reserves the right to amend or delete any part of this requirements specification or any document forming part of this specification in the future without


prior notice in order to have effect to the change of international standards, technologies, government policies or to correct any error, ambiguity that may arise.

1.1.2. Scheme Structure

An open multi-purpose smart card scheme consists of the following seven participants:

1) Smart card Scheme Provider2) Card Holder3) Service Provider or Merchant4) Card Issuer5) Value Issuer6) Value Acquirer7) Clearing House

A single entity may perform functions for two or more roles of the smart card scheme participants.In non-financial smart card schemes such as ID card, the application may perform fewer functions and fewer participants than that is shown in the figure 1. However there is no limited if more functions of other scheme applications shall be co-exist on the same multi-purpose card.

Figure 1 : Open Smart Card Scheme Participants

(OHFWURQLF

9DOXH

Smart Card Scheme Relationships

CardholderCardholder

Merchant/ Serviceprovider

Merchant/ Serviceprovider

AcquirerAcquirerIssuerIssuer

FundPool

Clearing House Clearing House

SchemeProvider

Value IssuerValue Issuer


1) Smart Card Scheme Provider

The smart card scheme providers play a key role because they establish the smart card application scheme and guarantee the security and the valuable information contained within the system. The identifying characteristics of a smart card scheme provider are:

• Develop the specifications, rules and conditions• Establish security procedures and keys management• Grant membership (certifies, authorizes and monitors)• Guarantees the trust of information or electronic value in the smart card system

2) Card Holder

Card holders are consumers or people who use smart cards for storing information, identifying themselves or exchanging electronic value in cards with products and services from joining scheme participants. Cardholder activity can be off-line or on-line, traceable or anonymous depending on the function mechanisms used to implement a smart card application scheme.The identifying characteristics of cardholder are:

• Valid to carry a card (certified by Card Issuer)• Abide by rules and condition of the card scheme• May or may not associate with institutions ownership• May have relationship with other scheme participants• May willing to keep money/points as electronic value in the smart card

3) Service Provider or Merchant

Service providers or merchants exchange their information, products and services with the information and/or electronic value stored in cardholder’s smart cards. Service providers and merchants can be any individual establishments, e.g. municipal governments, telephone companies, transportation companies, retail merchants, fast food restaurants, convenience stores, vending machine etc. Smart card acceptance terminals are specially designed devices to meet functionality and purpose of usage applications. Such as, the payment acceptance terminal can transfer electronic value from cardholder’s smart card to store in a terminal. The identifying characteristics of service provider or merchant are:

• Trusted and certified by Scheme Provider or Value Acquirer to access value in cards• Abide by rules and conditions of the smart card scheme• May or may not associate with institutions ownership• May accept cards from multiple issuers and• May have relationship with more than one scheme acquirers• May collected value with fund pools of Card Issuers through a Value Acquirer

4) Card Issuer

Card issuers are participants granted by the smart card scheme provider to personalize, distribute the smart cards and operate the smart card system. The identifying characteristics of a Card Issuer are:

• Authorized and quarantined by the scheme provider• Personalize and distribute cards to card holders• May incorporate additional functions in the card• May co-issue/later join with other scheme participants• Response to manage a database and/or a fund pool


5) Value Issuer

Value issuers are related with financial or commercial requirements. Value issuers are responsible for loading electronic value into smart cards. The value recharging function is performed through a special reload terminal ( or specially equipped ATM), which has a certain high degree of reliability and security. The identifying characteristics of value issuer are:

• Authorized and certified by the Card Issuer• Load and update electronic value to the card• Perform only online by a trusted device and under a secured environment• May operate the device to accept bank notes or transfer value from bank account

6) Value Acquirer

Value acquirers are related with financial or commercial requirements. Value acquirers are responsible for accepting electronic value from service provider and merchants and exchanging it for a credit to their deposit account. As concentrators, Value Acquirers collect service providers and merchant smart card transactions and forward them to the clearing house. Depending on the scheme operating regulations, Value acquirers may forward all of the details transaction data or just summary totals to the clearing house. The identifying characteristics of Value Acquirer are:

• Authorized and certified by the scheme provider• Response to collect electronic value from merchant/service providers• Provide devices, terminal, network and manage black lists• Manage terminals and verify collected transactions• May forward all transactions to be exchanged at clearing house• May accept for more than one card issuers or more than one scheme participants

7) Clearing House

The clearing house are related with financial and commercial requirements. The clearing house accommodate financial reconciliation system for fund transferring from Card Issuers to Value Acquirers. The amount transferred is equal to the accumulated electronic value collected by the Value Acquirers from Merchants and Service Providers and submitted to the clearing house. The identifying characteristics of clearing house are:

• Authorized and certified by the scheme provider• Receive transactions batches from value acquirers• Response to reconcile and accommodate transferring funds from card issuers to value

acquirers• May forward all details transactions from value acquirers to card issuers• Usually operate by a scheme provider or its sub-contractor


1.2. Smart card Requirements

1.2.1. Compliance Requirements

All smart cards shall comply with the following international standards:

- ISO 7816 Part 1 : Physical characteristics- ISO 7816 Part 2 : IC contacts- ISO 7816 Part 3 : Electronic signals and transmission protocols- ISO 7816 Part 4 : Industry commands for interchange- ISO 7816 part 5 : Numbering system and registration procedure for

application identifiers- EMV ICC Specification Part 1 : Electromechanical characteristics, logical

interface, and transmission protocol- EMV ICC Specification Part 3 : Application selection- All relevant sections of ISO 10373 : Test methods

The followings are additional requirements for cards to be used for financial transactions :

- EMV ICC Specification Part 2 : Data elements and commands- EMV ICC Specification Part 4: Security aspects- ISO 7811 Part 1 : Recording technique – Embossing- ISO 7811 Part 2 : Recording technique – Magnetic stripe- ISO 7811 Part 3 : Recording technique – Location of embossed characters- ISO 7811 Part 4 : Recording technique – Location of magnetic read only

tracks -Tracks 1and2- ISO 7811 Part 5 : Recording technique – Location of read-write magnetic

track – Track 3- ISO 7812 Identification cards: Numbering System and Registration

Procedure for Issuer Identifiers (1987)- ISO 7813 Identification cards: Magnetic stripe encoding

Further more, smart cards may comply with the following international standards:

- ISO 639 : Codes for the representation of names- ISO 3166 : Codes for the representation of languages and countries- ISO 4217 : Codes for the representation of currencies

The physical mechanism of smart card should include the following hardware security features:

• A fuse that disables access to the EEPROM manufacturing test mode.• A unique and unalterable serial number for each card to avoid cloning.• Power On reset for power supplies outside a specific range.• Diversified system key to protect the card during manufacturing and transportation to

the card issuer.• Read and write access to EEPROM controlled by ROM software and issuer

application• Read and write access to ROM prohibited.• Low voltage detection.• Low frequency detection.


1.2.2. Data Elements and Files

An application in the smart card includes a set of data information. These data information may be accessible to the terminal after a successful application selection. A data element is the smallest unit of data information in the smart card that may be identified by a name, a format, and a coding.

1.2.2.1 Data Objects

Referring to the data object defining in EMV specification, a data object is formed in tag, length, value format (TLV). A tag, coding in hexadecimal number, uniquely identifies a data object within the environment of an application. The length is the number of byte of the data object. The value is content of the data object. A data object may consist either of a data element or of one or more data objects. A data object that encapsulates a data element is called a primitive data object. A data object that encapsulates more than one data elements is called a constructed data object.

The mapping of data objects into records is left to the smart card application designed during the pilot project. The detail description of which data elements are to be used shall be comprised in the smart card application specification that will be submitted by the pilot issuers.

Note: The data objects in TLV format is mandated for debit/credit application in order to be in line with EMV ICC specification. Other application's data objects to be found in this document are presented in TLV form. However, the implementation of TLV for applications, such as ID card, electronic purse and loyalty program are optional, the issuers may redefine data records in fixed format for a reason to save the smart card memory space.

1.2.2.2 Files

The file structure, referencing method and level of security is based on the purpose of the file. The layout of the data files accessible from the smart card are left to the discretion of the pilot issuers except for the directory files described on the following:

The smart card should support the file organization that complies with the basic file organizations as defined in ISO/IEC 7816-4, which has two types of file categories:

• Dedicated file (DF)• Elementary file (EF)

The data structure for an elementary file allows four options:• Linear Fixed• Linear variable• Cyclic• Transparent

Master File(MF) is a dedicated file which is the root of the file structure as shown in figure 2.


Figure 2 : smart card File and Data structure

The application selection of the standard applications should conform to the EMV ICC specification, the path to the set of applications in the smart card is gotten by selecting the Payment System Environment (PSE). See more in section 1.4.3.the application selection. Other applications conforming to ISO/IEC 7816-4 but not conforming to the EMV specification may also be present in the smart card as individual proprietary application.

1.2.3. Standard Commands

1.2.3.1 Message Structure

The terminal and the card shall implement the physical data link, and transport layers as defined in ISO 7816 part 2 and 3. The command messages to be communicated between the terminal and the card should conform to the standard transmission protocol as defined in ISO 7816 part 3 and the standard instruction byte is defined in ISO/IEC 7816-4.

The application protocol of the command message that sent from the terminal and the response message that returned by the card to the terminal shall be Application Protocol Data Units (APDU). The structure of the APDU command-response and command codes is defined in ISO 7816 part 3, part 4 and EMV ICC specification. All other commands may be defined as extended requirements by specific applications such as electronic purse and loyalty program.

MF

DF DF EF EF EF

EF EF EF EF


1.3. Terminal Requirements

1.3.1. Terminal Types

In order to leverage capabilities and limitations of different kind of terminals in the market. The terminal requirements are more restricted to functionality, security and capability of terminal that meet with one or more functions of application than to mandate with all functions. The broad types of multi purposed terminals should be defined following to the EMV ICC terminal specification for payment system - Part 1 terminal types and capabilities. See more details of Terminal Types in Appendix A.

1.3.2. Terminal Capabilities

Terminal type and terminal capability are pre-requisite decision criteria for determining the purpose of use and the functionality of each terminal. Smart card acquirers or venders who want to certify each kind of terminals with a standard smart card scheme should declare terminal capabilities in accordance with the EMV ICC terminal specification for payment system - Part 1 terminal types and capabilities. The capabilities of each terminal type need to be declared as follows:

• General physical characteristics – describes all details of hardware specification, device components and hardware interfaces.

• Software architecture – describes operating system architecture, data management and system operation.

• Card data input capability – describes all the methods supported by the terminal for entering the information from the card into the terminal.

• Cardholder Verification Method (CVM) capability - describes all the methods supported by the terminal for verifying the identity of the cardholder at the terminal.

• Security capability – describes all the methods supported by the terminal for authenticating the card at the terminal and whether or not the terminal has the ability to capture a card.

• Transaction type capability - describes all the types of transactions supported by the terminal.

• Terminal data input capability - describes all the method supported by the terminal for entering transaction-related data into the terminal.

• Terminal data output capability – describes the ability of the terminal to print or display messages.

All terminal types suppose to provide adequate operation security. The terminal shall be constructed in such a way that:• Card Definition Table, Terminal Definition Table, Product Definition Table and other

parameters are initialized in the terminal before the terminal ready in its operational state.• Terminal initialized parameters are set up in the terminal at the moment of installation.• All terminal parameters cannot be modified unintentionally or by unauthorized access.


1.4. Application Requirements

Application requirements address necessary functions to ensure that all smart cards can perform the set of common core functions in terminals. The common core functions for multiple smart card applications should be incorporated in the same way as functions and transaction processing flows declared in EMV ICC Application Specification Version 3.1.1, Visa ICC Specification Version 1.3.1 and Mastercard ICC Application Specification for Debit and Credit on Chip Version 1.0. Application functions unique to individual application and those functions not needed of interchange is left to discretion of application issuer to fulfill specific requirements that not effect the interoperability.

1.4.1. Application Scope

The smart card applications referred in this document are means to support a number of current government and financial applications, such as:

• National ID - besides a visual identification, an electronic identification opens access to government facilities and public networks

• Taxation - enhances information on ID card to support personal taxation and duty payment• Welfare - enhances functionality to serve people getting welfare services• Driving License – enhances functionality to ID card, including a record of outstanding traffic

violations to control enforcement• Medical – includes basic personal medical information to support diagnosis and treatment in

emergency and general care situations• Debit – payment application provided by financial institution that is internationally accepted• Credit – payment application provided by financial institutions that is internationally

accepted• Electronic Purse – a stored-value application that can be either anonymous or account linked• Loyalty – a value added application for the debit, credit, electronic purse or even cash

application to enhance sales activity and give benefit to cardholders

The smart card scheme provider who wants to implement a pilot program shall use this document as guidelines for developing a standard application specification. The full detail specification shall be submitted to Thailand smart card committee before the pilot project will be commenced.

The detail specifications are supposed to meet the following commitments:• Openness – specifications shall incorporate open standards that allow future participants

without incurring high development cost.• Upgradability – specifications should allow for future flexibility to provide all government

applications and payment applications on the same card, if required. Specification should also accommodate installation of terminals that can run more than one application, if required.

• Inter-operability – specifications shall be sufficiently detailed to ensure that different components (cards, acceptance terminals, etc.) developed by different venders will work together seamlessly.

• Security – a well security designed specification and cryptographic procedures shall be incorporated to ensure that the security of the system is protected and preserved the privacy of the cardholder.

• Expandability – specifications shall allow for additional government or private applications to be easily accommodated at a later date.


• Upward compatibility – hardware and software requirements shall be upgradable to ensure upward compatibility with evolving international standards.

1.4.2. Application Selection

Application selection is always the first application function needed to perform. This application process shall be conformed to procedures defined in Part III of the EMV ICC Specification for Payment Systems.

The domestic smart card scheme providers or card issuers shall get a Registered Application Provider Identifier (RID) of 5 bytes that are uniquely assigned conforming to ISO/IEC 7816-5 from the Thailand standard smart card committee. The foreign or the international smart card scheme provider that want to launch their program in Thailand may report their reserved RID to the Thailand standard smart card committee for the acknowledgement.

A Proprietary Application Identifier Extension (PIX) of any 0-11 byte value can be assigned by the application provider to identify each of different applications. The following example: PIX is defined in 4 digits application ID and additional one or two digit is used to identify an individual released version of application as shown in table 1.

PIX Card Type‘0010X’ ID Card‘1010X’ Credit Card‘2010X’ Debit Card (No PIN)‘3010X’ ATM/Debit Card (With PIN)‘6010X’ Electronic Purse‘9010X’ Loyalty

Note : X is a number used to identify application released version, other applications that are not declared in the above table shall get the PIX number from Thailand smart card committee at later.

Table 1 : Application PIX assignments

The set of information that resides in smart card to support multiple applications shall be defined in an application definition file (ADF). Referring to a Part III of the EMV ICC Specification for Payment Systems, the ADF given the name ‘1PAY.SYS.DDF01’ shall be selected by the terminal using a select-by-name command.

The terminal shall determine which applications are available to support by a smart card. The terminal should select the highest priority application, which terminal is eligible to process according to Application Priority Indicator designated by the issuer as a default application. To offer the cardholder the ability to select an application or confirm the selection, the terminal may list applications that supported by both card and terminal in priority sequence according to the card’s Application Priority Indicator if terminal support display screen and can offer the ability to confirm a selection.

1.4.3. Transaction Processing

After application selection has taken place, the terminal shall perform transaction processing following to application function requirements. The transaction processing may be unique to individual smart card application, the detail processing is left to discretion of the application provider for a pilot program. The EMV ICC specification for payment system has given


guidelines to support the financial transactions on following paragraph. The more or less processed may be defined for suitable. There is also no restricted for other transaction types that may have differ processes to perform each individual application functions

• Initial application processing – the first function terminal will perform after application selection

• Read application data – terminal shall read the files and related records depending on the application function needed to perform from smart card

• Data authentication – terminal shall design a sequence criteria for data authentication• Processing restrictions – terminal shall determine the processing restrictions according to

the application being performed• Cardholder verification – terminal may perform cardholder verification which a cardholder

is requested to enter PIN according to the cardholder verification rules• Terminal risk management – terminal risk management may be performed according to

conditions and rules defined for each transaction scheme, such as the following checking :- Velocity checking (Optional)

- if number of times exceed limited for offline transaction

- Floor limit checking (Optional)- if number of accumulated amounts exceed a

limit threshold value.- Random transaction selection (Optional)

- if random number is less than or equal to the calculated transaction target percent.

- Blacklist checking (Optional)- if card’s PAN is found in the black list PAN

table• Terminal action analysis – this function may be performed after terminal risk management

and cardholder has completed entering transaction data, terminal will make decision to reject the transaction, complete it online or complete it offline based on terminal verification results.

• Card action analysis – this function may be performed to let smart card making a decision for approve the transaction offline, complete the transaction online, request a referral or reject the transaction.

• Online processing – the terminal may generate online transaction message sending to host and receive transaction response back from host.

• Script processing – Script processing may be provided to allow functions that may differ to each card manufacturers and are outside the scope of this specification.

• Completion – this function shall be a last function to be done before transaction processing is completed.


1.4.4. Data Integrity

When an exceptional event occurs during normal transaction processing, such as sudden card withdrawal from the terminal’s card reader, sudden power supply micro-failure, etc., card exception procedures shall be implemented to protect the integrity of the application and related data.

Strict integrity shall be ensured for the application software program, its data file structure, its security management parameters, and its static data elements (in other words, those data elements that are initialized during personalization and are not allowed to be updated after card issuance). This implies the information shall not be lost nor modified in case of exceptional events.

Protection shall be ensured for the application data integrity. The protection mechanisms should be consistent when applied to all application data elements sharing the same memory cell.

1.4.5. Year 2000 Support

The smart card application software and hardware should ensure their support for the Year 2000. The terminal vender should test the smart card acceptance terminal with the application software to certify that the product is Year 2000 compliant.

A determination criteria of the application dates for Year 2000, in the four digit year format, year should support Year 2000 for both A.C.(After Christ Era) and B.E.(Budda Era). For example, February24, 2000 is expressed as 20000224 in YYYYMMDD format for A.C. and 25430224 in YYYYMMDD format for B.E. To support the year 2000 of the one- or two-digit year format, the international credit card association has currently specified the format of the specific date-related data element, the two-digit year that less than 50 are presumed Year 2000. For the last example, February24, 2000 is expressed as 0002 in YYMM format, 000224, in YYMMDD format, and 0055 in YDDD format. It is recommended that one- or two-digit year format is just implied for A.C.(After Christ Era).


1.5. Network Requirements

The network and communication infrastructure should meet the following requirements :• The network and communication equipment comply with present industrial standards• The network is constructed on a flexible and scaleable architecture that can support

present and future network technologies• The system should provide high reliability and high availability to ensure minimum

failure of service. The system should provide alternate communication channels or back up network channels to maintain availability of service during the normal channel is occupied or out of service

• The network system should support all relevant existing and future network protocols for host systems, on-line terminals and off-line terminals. Protocols that are currently employed in financial and business network are ASYNC, BISYNC, X.25, SNA/SDLC, SNA/X.25, SDLC, APPN and TCP/IP

• The network system should support data transmission through different networks and through use of high-speed data file transfer

• The network system should support data switching of varying criteria parameters and in financial application, the system may need to support data reformat according to data format defined by each network processors

• The network system should provide real time network management facility capable of monitoring links and devices, reporting errors and statistical data


1.6. Settlement and Clearing Requirements

The transaction settlement and clearing system is required for financial and payment transaction processing. The settlement and clearing service should support the following requirements:

• The system shall be highly reliable and support 24 hour operations seven days a week• The hardware and software components shall be scalable and upgradable to meet

future processing requirement• All transaction messages shall be based on ISO 8583 standard format• The system can receive and store messages from other acquiring hosts or direct from

terminals• The system provides all functional capabilities to process all types of transactions• The system can authenticate, record and validate all received transactions• The system can perform transaction reconciliation and generate net clearing position

at pre-set cut-off time• The system supports batch data information interchange to and from the member host

processors• The system allows inquiry of member clearing position for participating members• The system provides all aspects of security and privacy controls required for the

system• The system provides all necessary operational reports, management reports and audit

trial

For international chip-based credit/debit card support, the settlement and clearing system should comply with international chip-based credit/debit data and network processing requirements such as requirements by VisaNet and Mastercard Banknet. The credit/debit transaction shall beauthenticated by chip-based credit/debit card authentication service and be cleared and settled under chip-based credit/debit operating rules.


2. Security Requirements

This part addresses the secured procedures for smart cards delivery, key management and card personalization of the smart card production life cycle to provide trace ability related to those entities that can impact the future reliability or authenticity of the smart card.

Security is an important element in a smart card application. Smart card must sufficiently provide security at pre-personalization level and post-personalization level.

2.1. Smart cards Delivery

The smart card manufacturer shall manage secure transportation of card from the card factory to the card issuer premises for personalization. Each smart card shall be initialized with a unique personalization key so that even when the personalization key for a particular card is compromised, the rest of the smart cards are not affected. Furthermore, the use of temporary key derived personalization key and card random number enhances the security of the smart card.

The unique personalization key can be derived from a master key through some unique data pre-initialized into each smart card. The unique personalization key shall be delivered to the card issuer in secure protection, e.g. stored in a Batch Key Card with Personal Identification Number (PIN) protection.

2.2. Symmetric Key Management

The key management system should be set up to allow the smart card Issuers to generate, store, transport and distribute all keys in a secure and controllable manner for a symmetric-key based smart card application. There may be different classes of keys that are defined in a system to allow key partitioning of the following key space:

Shared Keys – allow all participants to use a same key for sharing their applicationsPrivate Specific Keys – specify for private used by application providers or card issuersValue Added Keys – specify added-on keys used by other related applicationsAdministrative Keys – specify for system maintenance or system administration purpose

The symmetric key management shall be comprised with the following sub-processes:

2.2.1. Symmetric Key Generation

In the smart card production life cycle, Master key generation is a part to be given a highest level of security considerations in the card issuance process. Secret keys, which protect access to the smart card for each of applications, shall be generated and injected into the cards before and during the issuance process.

Symmetric-Key generation is a process to generate all related Master key components, which are required for one or more applications in the smart card system. Each individual keys generated should be stored securely in separated keys cards. Symmetric-key generation should provide the following security aspects:


• The hardware/software should be stored and kept in secured places• The hardware/software access should be controlled by an access PIN control or any

biometrics authentication techniques• The key generation should be done in a secured room environment• The Master keys are generated from secrets input by high level authorized holders

and uses an algorithm to generate keys in a single pass, non parts or results of keys generated will be kept in computer or in any medium. These keys shall be loaded into the key cards, which address a different key space. This in turn shall allow the support for multiple issuer and multiple application cards system

• The reading of the keys from these key cards is possible only upon successful presentation of PINs or any biometrics authentication techniques

2.2.2. Key Distribution

The master key cards shall be kept securely by high level authorized holders. The key cards shall never be distributed to anyone directly but should be transferred to the relevant key injection cards for injecting into the final target environment. The target systems that will receive the keys may be the terminals, the host security modules, the card production system and other related systems. In the multiple smart card schemes environment, a proper management procedure should be built to manage keys combining and key distributing under secured environment for supporting multiple smart card issuers and acquirers.

To prevent exposure of the keys, the injection cards should be able to establish an end-to-end cryptographic link with their target system. The keys should be transported to terminal in encrypted form. Beside that injection cards usage may be limited by number of cards/terminals that can be personalized.

2.2.3. Key Loading Process

The key loading process may unique to each of target system. The card issuer and card acquirer shall conduct a proper operation procedure to make sure that all keys are loaded under a secured environment and well protected from security breech. The keys inside injection cards should be erased or destroyed after completed loading process or else the cards must be kept in a strong secured place for the next keys loading process.

2.3. Asymmetric Key Management

For smart cards that will use for credit/debit card transaction should also be required to comply with international credit/debit card key management and cryptographic requirements referring in EMV ICC specification for Payment Systems. The smart card issuer shall use key management procedures and cryptographic services supporting by the appropriate Certification Authority.

2.3.1. Public Key Pairs Generation

The credit/debit application is required public key cryptographic services. The use of static and dynamic data authentication had defined in the EMV ICC specification for Payment System that


the Issuer Public Key Certificates, smart card Public Key Certificates, card issuer public key pairs, smart card key pairs, and brand issuer public key pairs be generated and managed.

2.3.2. Certification Authority

The use of public key pair requires the implementation of a Certification Authority. The Certification Authority provides public key cryptographic services for the initialization and support of smart card data authentication. The Certification Authority should function in a secure environment to ensure the security and integrity of all processes, keys, and related data. The cryptographic services provided by the Certification Authority are:

• Generation of all public key pairs• Distribution of the public key to acquirers• Generation of Issuer Public Key Certificates• Perform all key management processes required to support the generation of Issuer

Public Key Certificates• Administration of a Certificate Revocation List function for revoked Issuer Public

Key Certificates

2.4. Card Personalization

The card personalization may support batch card process that can handle for a small production volume or a mass production volume. The card production input data contains records of cardholder specific information, issuer specific information, application specific information and other card specific information. Graphical personalization, embossing, overlay, etc. can be included as part of the card personalization process depending on the requirements of the respective personalization modules.

Card personalization system may include the following modules:• Chip personalization• Magnetic strip encoding• Card embossing and Topping• Indent printing• Card laminating

The following briefly describes card personalization requirements for chip personalization, magnetic stripe encoding and embossing.

2.4.1. Chip Personalization

The chip personalization is a process to write data into the chip volatile memory. Beside the data the Master Keys in keys injection cards is diversified and loaded into the smart card. The personalization may comprise a combination series of software and hardware process steps. The hardware can be any card production equipment completed with the required personalization modules, e.g. Electrical personalization module for chip personalization, printer module for graphical/text printing on card surface and/or embossing module for card embossing, etc. The certain system details are unique to each supplier.


The fact that each smart card manufacturer uses the proprietary smart card operating system, a different command set and proprietary memory structuring techniques. The individual smart card personalization system may be required to handle each special personalization command set. Smart card suppliers shall cooperate with smart card personalization equipment suppliers to ensure personalization process is well established. After completed the first personalization, some of the special smart card personalization commands set may be disabled or some of the re-personalization protection keys may be established to prevent unauthorized and improper usage that may impact smart card security and functionality. The restrictions of operation procedures and cryptography techniques may be considered depending on the security requirements of each smart card issuer.

In multi-application environments, the card issuer may need to develop re-issuance strategies to ensure satisfaction of smart card security, functionality, and reliability requirements for the multi-application, multi-function, and application data sharing environments.

2.4.2. Magnetic Stripe Encoding and Embossing

Smart cards for financial transactions may comply with current international card operating regulations concerning visual personalization requirements. Smart cards for financial transactions may have a magnetic stripe and embossing.

If the card is a multi-application card, the issuer shall select a default PAN to be encoded on the magnetic stripe and embossed on the card. The default PAN encoded and embossed is identical to that associated with the application with the highest priority for that card, as indicated by the Application Priority Indicator. The cardholder data embossed on the card (PAN, expiration date) shall be the same as the cardholder data encoded on the magnetic stripe.

2.5. Post Personalization

Post personalization security is very important as the cards are fielded. Smart card shall support security features to protect the cardholder, card issuer, system operator, etc. from illegitimate access the smart card.

2.5.1. Files Access Conditions

Each file in the smart card shall have its own set of dedicated file access conditions. This set of access conditions defines the level of protection granted to a file (such as read, write, etc.).During card access, the smart card shall determine if access should be allowed to a file by checking against the access conditions stored for each file.

Possible access conditions may provide as following:• One or more secret code numbers that should be used to access the file for each access

type (create, read, write or update).• A cryptographic key may be used for secure messaging with the file. Secure messaging is

a cryptographic process that secures data transmission with smart card.


2.5.2. Files And Application Locking

To ensure that further access will be strictly disallowed to sensitive data area like secret keys and secret codes, smart card should be able to bar all access to such data area once the secret keys and secret codes and personalized. No even when the personalization key is presented.

Furthermore, in the case of multi-issuer where personalization key are usually shared, smart card should be able to lock the access of any particular application in the card belonging to one issuer that will not be able to interfere with the other.

2.5.3. Secret Code Protection

Smart card should be able to protect access to all files stored in the card with secret code. The access conditions consists of presenting a secret code successfully to the card; it could be:

• a PIN code entered by the card holder or by any biometrics authentication techniques• a secret code diversified by the terminal using a Master Secret Code

The PIN or personal biometrics allows the cardholder to authenticate by himself. Moreover, the secret code may be presented enciphered to allow the terminal authentication by the card.

2.6. Cryptographic Security Requirements

Smart card may include a series of commands used to implement cryptographic session key, cryptographic authentication, a certificate/signature generation, secure messaging, etc. The command sets from different card manufacturers may vary but most cards can support the same functionality of cryptographic mechanisms. The following addresses general cryptographic requirements for the smart card security aspects:

2.6.1. Temporary Session Key Generation

To avoid any replay attack on the card/terminal, the card should be able to establish a unique dialogue session with the terminal on each new transaction. To ensure that the session establishment is unique, the smart card should support a random generator. Based on the generation of random number, a unique temporary key can be established for every transaction.

Once a temporary key has been generated, the cryptographic security features can be used as following:

• verification of administration command transmission using secure messaging• Transaction dedicated security using cryptographic certificates

2.6.2. Card Authentication

Card authentication is required before card access by terminals to be allowed. The authentication shall be performed by the terminal to authenticate the card and may based on symmetric key techniques or asymmetric key techniques depending on each smart card applications. This is to ensure that the card is a genuine card before any transaction is allowed to carry out. Furthermore, authentication should be performed in such a way that reflective attack by unauthorized terminals


and illegal cardholder will be denied. The card authentication may be a complement of the following data authentication techniques:

• Secret code data authentication - symmetric key technique• Static data authentication - asymmetric key technique• Dynamic data authentication - asymmetric key technique

2.6.3. Cardholder Authentication

Cardholder authentication is performed by the cardholder to ensure that the terminal and cardholder that is performing the transaction are legitimate entities. In typical, this can be done through ciphered presentation of secret PIN.

There are some biometrics authentication techniques, which are more efficient and more accurate than using of PIN such as eyes retina verification techniques, fingerprint verification techniques, etc. The cardholder authentication using personal biometrics is optional. The PIN verification is a minimum requirement.

The restriction for secret PIN authentication is as following:• The terminal should cipher the PIN before presenting to smart card. The cardholder PIN shall

not be captured or leak out of the terminal• The smart card should be able to decipher and verify the secret PIN internally.• If a pre-defined number of incorrect presentation of the secret PIN is being done, the smart

card will disallow any further access to the card until the card is unlocked.

2.6.3. Secure Messaging

The principle objective of secure messaging is to ensure data confidentiality, message integrity and issuer authentication. Secure messaging is process that allows data to be exchanged and to prevent the transmission from being corrupted of being intercepted by a third party. The secure messaging format should be conformed to ISO 7816-4.

Smart card may apply secure messaging on two purposes:

1) Secret Key / Secret Code Secure MessagingThe card and the terminal establish an end-to-end communication channel. Keys and data interchange between card and terminal will be ciphered using the temporary session key.

2) Data Secure MessagingThe card and the terminal establish an end-to-end communication channel. Card or terminal may use the temporary session key to calculate a cryptographic checksum for the data transmission. The cryptographic checksum value will be counter checked the integrity of the data transmitted at the other end.


3. ID Card Application

3.1. Functional Requirements

Thai citizens will get an ID card when they are full 15 years old. Thai citizens whose are qualified and passed the driving test can hold a driving license. And when people work, they need to have Tax ID and welfare ID. All of government's ID cards carry a same identity information of the cardholder. This section describes preliminary requirements to combine all government ID information into a single ID card. The card can append the information of other government's ID card at later stages. For example, when a man get a driving license card, a card also has medical information, ID card information and it can be used as an ID card. When this man get Tax ID and Welfare ID, the Tax ID and Welfare ID information are updated into his card. The fact that only data information can be updated to IC chip card but it does not allow any information to be reprinted on the card surface. However, the next re-issuance of driving license card after the present card expired shall present the Tax ID and Welfare ID on the new card surface.

The details functional requirements of the ID applications are based on certain requirement of the current government's ID cards such as citizen ID card, civil ID card, Tax ID card, Driving License, etc.

The objective to integrate all government ID applications with multi-purpose smart card are as following:

• To improve the security of the current government's ID cards through smart card and biometrics technology

• To standardize data inter-change between all government ID applications and government IT infrastructure for sharing of computer resources and network resources

• To serve as an access key that uses the ID number to provide secured access to other applications or other systems

The card applications that should support in the ID card application are as following:• National ID – visual card surface can identify a person as well as stored individual

data information that can be used and shared with other government applications. The ID card will also serve as access key to government public facilities and private applications that do not required dedicated cards.

• Taxation – adding basic Tax information on ID card, a card can represent for Tax ID card with the revenue department application.

• Welfare - adding related welfare information on ID card, a card can get health care and other services from government and related hospital.

• Driving License – with separate issued by transport department, a card is included information for ID card, taxation and welfare for referring identical to ID card. Driving license card includes application to control and enforcement of traffic violation and penalty payment.

• Medical – application contains basic medical information to improve diagnosis and treatment in emergency and general care situations.


3.2. Application Owner

The government organizations that currently own, issue and utilize type of ID cards are as following:

1) Registration Processing Center Administration Bureau, Ministry of Interior2) Civil Service Commission, Ministry of Interior3) Department of Land Transport, Ministry of Transport and Communications4) Revenue Department, Ministry of Finance5) Traffic Police Bureau, Highway Police Bureau, Provincial Police Bureau,

Information Center

3.3. Data Requirements

The mandate smart card reference information is defined in a constructed data object as shown in table 2:

Tag Length Value Format PresenceE1 8 Card Serial Number (CSN) 16 numeric char M

2 Issuer Code 4 numeric char M2 Manufacturer Code 4 numeric char M2 Card Type 4 numeric char M1 Card Version 1 Character M1 Derivation Key Index 1 Character M4 Personalization Equipment Identifier 8 numeric char M4 Personalization Date YYYYMMDD M4 Application Expiration Date YYYYMMDD M

Table 2 : Common smart card Constructed Data Object

The data elements for ID card application are defined in TLV format as shown in the table 3:

Tag Length Value Format PresenceC1 1 Card Type

(e.g.1=citizen,2=civil,3=Driv)1 Alpha num. M

C2 var. Name-Surname ‘;’ Name-Prefix/title 80 Characters MC3 var. Organization Abbreviate 5-20 Characters OC4 var. Registered Address 60 Characters MC5 var. Current Address 60 Characters OC6 var. Telephone no. 10 Alpha num. OC7 var. Picture Bit map image OC8 var. Signature Bit map image OC9 var. Thumbprints Bit map image OCA 4 Birth date YYYYMMDD MCB var. Birth place 15 Characters MCD 1 Marriage status 1 Characters MCE 1 Gender 1 Characters MCF 2 Blood Group 2 Characters MD0 7 National ID number 13 numeric char MD1 4 Driving License 8 numeric char C1


D2 5 Tax ID 10 numeric char OD3 5 Welfare ID 10 numeric char OD4 var. Issued place 15 Characters MD5 4 Issued Date YYYYMMDD MD6 4 Expiration Date YYYYMMDD MD7 3 Type of Driving License 3 Characters C1D8 5 Class of Vehicle 5 Characters C1D9 5 Penalty Status 5 Characters C1DA 2 Accumulated Driving Points 2 numeric char C1DB 4 Updated Points Date YYYYMMDD C1DC 4 Unpaid penalty issued by police 8 numeric char C1DD Var. Personal/Contact Person Information 80 Characters ODE Var. Allergies & long-term illness 80 Characters O

Note: C1 means to mandate presence of fields that card is used as driving license

Table 3 : ID Application Primitive Data Objects

Further more primitive data objects and constructed data objects may be redefined to meet each specific ID card application in the future. ( See Appendix B: TLV format definition ).

The layout of the data files accessible from the smart card is also left to the discretion of the issuer organizations to meet with all each specific requirements.

3.4. Card Surface Requirements

The new blank smart card shall come on pre-printed with text messages and graphic designed on the background surface that identify different types of ID cards. The card design and card layout shall be specified by the card issuer institutions. The design shall also accommodate data that may be printed on each side of the card surfaces as specified on the following:

1) Name of the card ( e.g. National ID, Driving License )2) National ID number3) Name and Surname4) Name Prefix or Title5) Services Department (in case of government employee)6) Birth Date7) Registered Address8) Picture9) Signature10) Card Issued Date11) Card Expiration Date12) Blood Group13) Driving License Number14) Type of Driving License15) Type of Vehicle16) Tax ID17) Welfare ID

The issuer organization will be responsible to put any necessary additional overlays, holograms and/or laminations of the institution logos by which would enhance the security or durability of


the card. No additional surface printing on a national ID card will be required after the card is issued.

3.5. Security Requirements

An enough security mechanisms shall be provided to ensure the security of data manipulation and the data integrity of ID card. The data privacy of citizens using the ID application is preserved, an access to national ID application should only be at the consent of the cardholder and by government enforcement. The related government's application may access a personal ID information but restricted the information update only to the ID's owner organization.

The cryptographic security for the smart card should provide secure data management function that manages data sensitive applications like ID card, driving license, civil ID card, student card etc. By providing the ability for the smart card to perform data integrity check during data communication shall ensure that the information is not tampered in the communication channel between the smart card and the reading device.

3.6. Application Transactions

The ID card issuance system has primary functions as following:• To capture and verify information against government central database and other

application owner databases• To issue new ID cards, replace lost, stolen or defective of ID cards• To replace or update ID cards due to change of citizenship status and other

information• To provide general information services, read or update card holder information• To renew individual ID card or card applications

The national ID application shall be inter-operable with communication protocols, network and infrastructure requirements defined for all government network infrastructure.

ID cards can be used at different places for different purposes, the present of card is possible in 3 different ways:

1. Visual accessThe visual identification is used to observe the name, address, ID number and photo printed on the surface of the card. Officer may use surface photo for quick verification. Surface information may be used to confirm person’s identity.

2. Off-line accessOff-line smart card readers will be used to access ID information in the chip when more detailed data of the cardholder is required or when the cardholder is needed to be authenticated, the biometrics data in smart card may be used to validate a person. In addition, cards can be utilized for door gate access or for any other access control system.

3. On-line accessThe ID card may be used for on-line access when the name and/or ID number is used as an access key to trigger the system. More steps of personal authentication can be included such as presenting of PIN, biometrics fingerprint authentication, etc. for entering a high security system.


4. Credit/Debit Card Application


The credit cards and debit cards have been based on the magnetic strip technology for a long times. The magnetic strip technology is simple, non-durable, no-security and easy to be duplicated. The international credit card associations including Europay, Mastercard International, Visa International, has co-developed the EMV ICC Specification for Payment System. Visa International and Mastercard International also released more complementary documents such as the Visa ICC Specification and Mastercard ICC Application Specification. All those specifications were developed for member banks wishing to enhance credit/debit cards and other value-added applications on the smart card.

This section addresses the credit/debit application for smart card, which is explicitly conformed to all EMV, Visa and MasterCard specifications mentioned on the above paragraph. Certain EMV compliance for smart card program is necessary to ensure worldwide acceptance of all credit/debit cards and transactions, protecting bank investment by ensuring the compatibility with long-term global standards, and ensuring an orderly migration to the smart card technology.

The credit/debit card application for smart card should meet the following objectives:• To utilize an existing infrastructure that shall support additional smart card products, services

and facilities.• To ensure global interoperability• To support coexistence of smart card application and current magnetic stripe application• To ensure global cross-acceptance and coexistence of other smart card applications• To support transactions using message formats identical to those for current magnetic stripe

transactions• To support Certification Authority functions and all key management processes required to

support the generation of Issuer Public Key Certificate and administration of Issuer Public Key Certificate Revocation


Banks or financial institutions whose authorize to issue credit cards, debit cards and ATM cards. The new credit/debit cards shall have both IC chip and magnetic strip on a card.


The data requirements shall conform to the data requirements set out for the international credit/debit smart card specification as following:• EMV ICC Specification for Payment System Version 3.1.1 (May 31, 1998)• EMV ICC Application Specification for Payment System Version 3.1.1 (May 31,1998)• Visa ICC Specification Version 1.3.1 (May 31, 1998)• Mastercard ICC Application Specification for Debit and Credit on Chip Version 1.0 (October

17,1997)



The card surface shall comply with the marks and specifications requirements of the international credit associations. The card surface data shall provide as following:

1) The front of card surface should show credit/debit card number, name-surname and cardholder picture if applied. The additional necessary graphic hologram and/or lamination to enhance security and durability of the card.

2) The back of card surface should have magnetic stripe and signature panel stripe. In addition, on the back of card should print address and service contact telephone number.


The debit and credit applications should support three main security objectives:

1) To validate that the card is authentic2) To ensure that off-line authorization is authentic3) To ensure that settlement transaction data are authentic

The implementation of security and risk management shall conform to EMV security architecture. Debit and credit applications shall be internationally accepted and support both EMV compliance application and the existing magnetic stripe applications. The existing magnetic stripe terminals should be able to incorporate smart card reader and accept chip-based credit and debit card applications.

The credit/debit application for smart card shall comply with EMV requirements on the following security aspects:

• Static data authentication - allows ability for terminal to authenticate smart card• Dynamic data authentication - allows ability to cross authenticate for both terminal

and smart card• Secure messaging – ensures data confidentiality, message integrity and issuer

authentication.• Generation of application cryptograms - ensures transaction integrity and transaction

authentication• Cryptographic security to support the smart card credit/debit application – ensures

the security and integrity of all processes, keys and related data


4.6. Application Transactions

Debit and credit application process shall support both dual and single message processing requirements. In dual message processing, the authorization message is followed by an offline clearing message. In single message processing, the transaction message is used for both authorization and clearing.

The following types of transactions are generally supported by member banks in Thailand :• Sales ( purchase of goods and services )• Balance inquiries• Reversals• Voids• Adjustments• Pre-authorizes• Confirmations• Off-line Sales

Note: Above transaction message formats are described in Appendix C.1-2.

As described in section 1.4.3: Transaction Processing, the credit and debit transaction processing should be conformed to the transaction processing declared in EMV ICC specification for payment system. All less of transactions such as cash disbursement, cashback, account transfers, refunds, administrative message, etc., may be implemented in a full version if required. Other proprietary functions may be added to the terminal and smart card as long as meeting the application requirements and not effect with the inter-operability of transaction processing.


5. Electronic Purse Application


Electronic purse is another alternative payment card containing electronic cash, which the cardholder can use to purchase goods and services as a substitute for coins and bank notes. The electronic purse eliminates cash handling costs and security risks by providing a secure, convenient, and fast off-line value transfer mechanism.

The Thailand standard electronic purse shall support 2 kind of cards:

1) Bank account linked card – has at least one bank account linked with purse for reloading purpose

2) Anonymous card – has no bank account tied with purse, the cardholder should reloading value to card by using debit card, credit card or by cash if allowed with special reloading terminals

The electronic purse application should meet the following requirements:• To support coexistence of other smart card applications• To support transactions using message formats compatible with an existing payment

network• To support secured card transaction processes and all key management processes

required to support the generation of card issuance, administration of keys in terminal and card life cycle

The following are features that should be found in electronic purse card acceptance terminal:• All terminal types should support the end-to-end communication and cross authentication

between the card and the SAM• The reloading terminal can determines the maximum load limit with current purse balance

on the card and shall require the cardholder to enter a debit PIN for a cross validation• The reloading terminal shall authenticate the value issuer by sending authentication

message to the value issuer and validate the response of credit cryptogram before allowing electronic purse value to be loaded on the card

• The terminal could check card validity, card status and limited threshold of each card• The terminal can check card risk management and permit cardholder to enter a PIN• The terminal should allow confirmation of the cardholder’s purchase or other transactions

decision• The terminal can be linked to cash registers or computerized point of sale in which there

is no manual entry of data required• The collected transactions are stamped the date, time, terminal and purse transaction

information• The terminal can display the customer’s current purse balance and a new balance after a

transaction is completed• The terminal can automatic settlement of all purchase transactions to a central computer

system, the merchant card may represent incase the terminal can't support online communication

• The terminal can print sale slip to inform customer of purse balances, purchasing and reloading made



Business organizations can issue electronic purse card and assign certain number of value issuers and merchants to accept their electronic purse cards. The electronic purse card may support multiple applications such as ID card, credit/debit card, loyalty program, etc. The card may have both IC chip and magnetic strip on a single card.

The card issuer should provide the following information periodically to cardholders:• Card user manual, liability, terms and conditions• List of card acceptance merchants• News and updated information of addition/revocation merchants, change of location

and telephone numbers.

5.3 Data Requirements

The smart card reference information is defined in a constructed data object as shown in table 4:

Tag Length Value Format PresenceE1 8 Card Serial Number (CSN) 16 numeric char M


Table 4 : Common Application Constructed Data Object

The data elements for electronic purse application are defined in TLV format as shown in table 5:

Tag Length Value Format Presence5A 8 Primary Account Number (PAN) 16 numeric char M

9F08 2 Application Version Number 3 numeric char M9F3B 2 Application Reference Currency 3 numeric char M9F59 1 Consecutive Transaction Limit 8 binary bits M9F54 6 Cumulative total trans. amount limit 12 numeric char M9F13 2 Last online application trans. counter 16 binary bits M9F23 1 Maximum Consecutive Offline Limit 8 binary bits MC1 1 Card Type (1=A/C , 2=Anonymous) 1 Alpha num. OC2 Var. Name-Surname ‘;’ Name-Prefix/title 80 Characters OC3 var. Organization/ Company name 5-20 Characters OC4 var. Registered Address 60 Characters OC5 var. Current Address 60 Characters OC6 var. Telephone no. 10 Alpha num. OC7 var. Picture Bit map image OC8 var. Signature Bit map image O


C9 var. Thumbprints Bit map image OCA 4 Birth date YYYYMMDD OCB var. Birth place 15 Characters OCD 1 Marriage status 1 Characters OCE 1 Gender 1 Characters OCF 2 Blood Group 2 Characters OD0 7 National ID number 13 numeric char OD2 5 Tax ID 10 numeric char OD3 5 Welfare ID 10 numeric char OD4 var. Issued place 15 Characters OD5 4 Issued Date YYYYMMDD MD6 4 Expiration Date YYYYMMDD MD9 1 Card Status 1 Character MDD Var. Personal/Contact Person Information 80 Characters ODE Var. Allergies & long-term illness 80 Characters O

Table 5 : Electronic Purse Application Primitive Data Objects

The primitive data objects and constructed data objects may be redefined to meet with electronic purse application that shall be implemented for a pilot program. (See more in Appendix B : BER-TLV format definition).

The electronic purse balance should be separately stored in a purse file which be able to set parameters to enhance integrity and security to purse file such as; maximum limit of purse balance, upper limit of purse debit transaction without PIN and the related secret key file that stored cardholder PIN data. Transaction log file should be able to store last 10 transaction records. The layout of the data files and data objects accessible from the smart card is left to the discretion of the issuer.


The card surface may comply with the marks and specifications requirements of the international card associations. The card information shall provide as following:• The front of card surface should show card number and expiry date. Presenting of name-

surname and cardholder picture on card surface are not mandated. The additional necessary graphic hologram and/or lamination to enhance security and durability of the card are optional

• The back of card surface may have magnetic stripe and signature panel stripe. On the back of card should print address and service contact telephone number of card issuer


The electronic purse applications should support three main security objectives:

1) To validate that the card is authentic2) To ensure that off-line authorization is authentic3) To ensure that settlement transaction data are authentic


The electronic purse's smart card should be able to support a highly secure payment transaction. Smart card may offer the typical symmetric electronic purse, i.e. it uses symmetric keys for access and control, or offer the more sophisticate technology. The purse should provide a mechanism to generate transaction certificates for purse credit, debit and electronic signature. The implementation of security and risk management is left to discretion of the pilot program.

The electronic purse should provide the following mechanisms to ensure security and integrity of the smart card:

• Configurable maximum purse balance allowedThe maximum balance register in the purse stores the maximum balance that the purse can hold. Any attempt to initialize or top-up the purse with an amount more than this will be rejected.

• Dedicate credit keyThe purse should be able to designate any specific credit key for the purse. The credit certificate for crediting the purse will have to be generated by this credit key.

• Configurable maximum free debit valueThe maximum free debit value indicates the maximum value that can be debited from the purse when the debit access control condition need not be fulfilled. If this value is set to zero, the debit access control condition need not be fulfilled for all debits.

• Configurable purse debit and read balance access controlThe purse should implement backup mechanism to ensure that the integrity of the balance amount in the purse is can be check at all times.

• Ensure integrity of balance amount in the purseThe purse should implement mechanism to ensure that the integrity of the balance amount in the purse is can be check at all times.

• Purse backup mechanism for error recoveryThe purse should implement backup mechanism so that the previous value can be

restored after an incorrect purse updates.

5.5. Application Transaction

The following types of transactions shall be supported by the electronic purse application:

1) Offline sales ( purchase of goods and services )The card acceptance terminals capture sales transaction amount and debit that amount from purse in the smart card. The purse should be able to securely perform an off-line debit transaction. If PIN is presented, it should be satisfied before a debit can take place. After a debit transaction, the purse should be able to generate a debit certificate to the terminal for checking.

2) Purse reload ( Online credit )The purse should be able to securely perform and on-line credit transaction. PIN or secret code presentation before a credit transaction may be required to withdraw money from cardholder's bank account at the bank debit host. As on-line operation, the credit process should provide highest security mechanism to ensure data authenticity and data integrity. After a credit transaction, the purse should be able to generate a credit certificate to the terminal for checking.


3) Purse transfer to accountThe purse should be able to securely perform an off-line debit transaction from purse and should perform on-line credit transaction to host bank account. If PIN is presented, it should be satisfied before a debit can take place. After a debit transaction, the purse should be able to generate a debit certificate to the terminal for checking.

4) Balance inquiryThe purse should be able to support inquiry on the purse balance. Moreover, the purse should be able to issue purse balance certificate so that the terminal can check the authentic of the balance returned by the purse.

5) Cardholder PIN changeThe customer may be offered at certain locations the capability to change their PIN code. In case the cardholder had forgot their code, the appropriate identification procedures at the Customer Service Point should be employed to control this activity.

6) Print Card Data

The terminal may has capability to print data held on the card. The information may include detail of last ‘n’ transactions, available balance, etc.

7) Transaction Settlement

The electronic purse transactions that are accumulated in the terminals should be uploaded and settled before closed shift at end of the day. This process should comply with current settlement process, and loyalty data should format to fit within ISO 8583 standard message.

Note: Detail transaction message formats are described in Appendix C.3.

More of transaction types such as card registration (first usage), cash reload, cash disbursement, void, refunds, administrative message, etc., may be implemented on enhancement to smart card application. Other proprietary functions may be added to the terminal and smart card as long as meeting the application requirements and not effect with the inter-operability of transaction processing.


6. Loyalty Application


The smart card electronic loyalty program can help retailers to attract new business, new customer and retain their current customer base at a lowest cost. These programs take advantage of smart card to keep track of customer purchases with bank credit, debit or electronic purse cards. In return for their continuing patronage, customers are rewarded with discounts, free items, bonus points or other incentives. The loyalty card may include within a same smart card for credit, debit or electronic purse, which the card will be accrued its points values during the purchasing is taken place.

The following are features that should be found in loyalty card acceptance terminal:• Allocate points calculation based on total sales amount and gain amount per point or

allocate different points factors for different days, times, dates, products, product categories, customer types, locations.

• Redeem points automatically from predetermined lists of rewards for certain products.• Password controls to avoid fraudulent allocation and redeeming of points.• Transaction data is collected by reading an information in smart card, but not limit for

swiping a magnetic stripe or bar-coded through the loyalty card acceptance terminal.• The terminal could be linked to cash registers or computerized point of sale in which there

is no manual entry of data required.• The system automatically stamps the date, time and location of every sale.• When customers respond to promotions, device operator can key the promotion identifiers

to get into each promotion application.• The terminal can display the customer’s current points balance and a new points to be

update.• Automatics upload communications of all purchase transactions to a central computer

system.• The terminal can print sale slip to inform customer of points balances, rewards achieved

and redemption’s made.


Any business organizations can issue their loyalty cards and provide numbers of points redemption agents and points issue merchants to accept their loyalty cards. The loyalty program may support multiple schemes, points can be given by multiple issuers and can be redeemed by multiple agents. In general, loyalty cards are often incorporated within other application cards such as credit/debit card, electronic purse card, etc.

The card issuer should provide the following information periodically to cardholders:• "Loyalty" program scheme, descriptions of scopes, services and participants• Details of points conversion schemes, details of benefits and list of redemption gifts• Declare terms and conditions of each programs, starting and ending of program dates,

program scheme and redemption period, card and points expiry date• News and update information of addition/revocation merchants, changes of location

and telephone numbers.



The smart card reference information is defined in a constructed data object as shown in table 6:Tag Length Value Format PresenceE1 8 Card Serial Number (CSN) 16 numeric char M


Table 6 : Common smart card Constructed Data Object

The data elements for loyalty application are defined in BER-TLV format as shown in table 7:Tag Length Value Format Presence5A 8 Primary Account Number (PAN) 16 numeric char M

9F08 2 Application Version Number 3 numeric char M9F3B 2 Application Reference Currency 3 numeric char M9F59 1 Consecutive Transaction Limit 8 binary bits M9F54 6 Cumulative total trans. amount limit 12 numeric char M9F13 2 Last online application trans. counter 16 binary bits M9F23 1 Maximum Consecutive Offline Limit 8 binary bits MC1 1 Card Type 1 Alpha num. OC2 var. Name-Surname ‘;’ Name-Prefix/title 80 Characters OC3 var. Organization/ Company name 5-20 Characters OC4 var. Registered Address 60 Characters OC5 var. Current Address 60 Characters OC6 var. Telephone no. 10 Alpha num. OC7 var. Picture Bit map image OC8 var. Signature Bit map image OC9 var. Thumbprints Bit map image OCA 4 Birth date YYYYMMDD OCB var. Birth place 15 Characters OCD 1 Marriage status 1 Characters OCE 1 Gender 1 Characters OCF 2 Blood Group 2 Characters OD0 7 National ID number 13 numeric char OD2 5 Tax ID 10 numeric char OD3 5 Welfare ID 10 numeric char OD4 var. Issued place 15 Characters OD5 4 Issued Date YYYYMMDD MD6 4 Expiration Date YYYYMMDD MD9 1 Card Status 1 Character MDD Var. Personal/Contact Person Information 80 Characters ODE Var. Allergies & long-term illness 80 Characters O


Table 7 : Loyalty Application Primitive Data Objects

The primitive data objects and constructed data objects may be redefined to meet with loyalty application that shall be determined by each issuer. (See Appendix B : TLV format definition).

For security reason, the points balance should be separately stored in purse file(s). Transaction log file should be set up to store last 10 transactions. The layout of the data files and data objects accessible from the smart card is left to the discretion of the issuer.


The card surface may comply with the marks and specifications requirements of the international card associations. The card information shall provide as following:• The front of card surface should show card number and expiry date. Presenting of name-

surname and cardholder picture on the card surface are not mandated. The additional necessary graphic hologram and/or lamination to enhance security and durability of the card is optional.

• The back of card surface may have magnetic stripe and signature panel stripe. On the back of card should print address and service contact telephone number of card issuer.


The loyalty program on smart card gains benefit of the lowest transaction cost since the loyalty transactions are processed off-line so it is needed to assure that all points balance of loyalty programs are processed and stored under a highest security. In appearance, most of smart cards those comply with EMV requirement have provided high security mechanisms for payment application. The loyalty program is normally incorporated with the payment applications, so the security requirements for loyalty program may facilitate the same security mechanisms that provided for the debit/credit payment application or the electronic purse payment application. The detail requirement specification is left to discretion of application provider of a pilot program.

6.6. Application Transaction

The followings are transactions that should support for Loyalty application.

1) Card Issuance / Card First Usage

In case of the first card issuance or card first usage, the following application features may need to be supported:

• Print a variable, Host-loaded Welcome/Marketing message on the receipt• Prompt for cardholder to setup the customer’s PIN code. Cardholders can enter a free-

format, self-selected 4 - 6 digit number as their “PIN Code”• Issue any free points offered as part of a promotion to new cardholders. These points will

be stored in the terminal as host-loaded data, and may have a zero value.• Capture and send to the host as part of the transaction record the first transaction

indicator, to enable host tracking of the cards issued at each location.


2) Points Issue

Points issue transactions shall be conducted off-line between the card acceptance terminals andsmart cards. The card acceptance terminals capture sales transaction value and calculate givenpoints by the terminal application. The points are added to the card and at settlement forwardedto the host.

3) Points Issue Void

Reversal of points issue transaction is mainly to cover operational problems etc. This can only beundertaken within the same settlement period and terminal as the initial transaction.

4) Points Redemption

This transaction occurs when cardholder want to spend collected bonus points in card for a reward item. Redemption reward is depended on the redemption value and the availability of the required number of points in the card. The redemption transaction may allow being processedoff-line or online according to conditions and policy of each loyalty program scheme. In addition, the present of cardholder PIN may be applied to validate a cardholder and some limited thresholdand risk management may be applied to reduce fraud.

5) Points Redemption Void

Void of points redemption transaction is mainly to cover operational problems etc. This can onlybe undertaken within the same settlement period and terminal as the initial transaction

6) Host Points

In order to support multiple points issuers, the points that maintain and load into to the cardholder’s account may come from multiple sources, the capability to load points from the host into card is optional according to application scheme requirement.

7) Cardholder PIN Code Change

The customer may be offered at certain locations the capability to change their PIN code. In case the cardholder had forgot their code, the appropriate identification procedures at the Customer Service Point should be employed to control this activity.

8) Print Card Data

The terminal should has capability to print data held on the card. The information may include detail of last ‘n’ transactions, available points, etc.

9) Transaction Settlement

The loyalty transactions that are accumulated in the terminals should be uploaded and settled before closed shift at end of the day. This process should comply with current settlement process, and loyalty data should format to fit within ISO 8583 standard message.

Note: Detail transaction message formats are described in Appendix C.4.


Points Conversion Requirements

The points conversion table parameters shall be down loaded into the terminal, and each location can implement a differ points conversion rate as may be required. The point conversion table parameters should support multiple criteria conditions and multiple rates for different product categories. The card acceptance terminal may share devices with bank cards payment and retail applications. The interoperability requirement of multiple loyalty schemes should come out with a simple calculation of the points conversion algorithm. To support this requirement, the context of a simple Points Issue formula is shown in the following equation and calculation sequence:

The formula: Point = ((Tot.Sales – Min.Amt) >= 0) * (Tot.Sales / Divider.Amt) * Point.Rate

This formula works if 3 conditions are met:

a) the expression: (Tot.Sales – Min.Amt) >= 0 returns 1 if TRUE, and 0 if FALSE; and:

b) the calculation result is always rounded down to the nearest integer; and:c) Min.Amt >= Divider.Amt

The order of calculation is important, thus:

1. the conditional expression ((Tot.Sales – Min.Amt) >= 0) is evaluated first, then2. the division (Tot.Sales / Divide.Amt) is evaluated (and rounded down), and3. the first 2 expressions are multiplied (and rounded down), and finally4. the result is multiplied by Point.Rate which is selected from the conversion parameters

table.


7. Pilot Project

Some initiated members in the smart card standard consortium will be involved in the implementation of a smart card pilot project. The scope of project may cover only some of applications that are interested by pilot participating members. Pilot project participants including software venders and hardware venders shall be responsible to develop and rollout during each stages of the project on the following deployments:

7.1. Producing specifications

The pilot application vender is responsible for translating the requirements provide in this specification to a comprehensive set of functional and technical specifications for the standard smart card system. This should include details specifications for the smart card, card acceptance terminals and IT infrastructure. All details specifications should be comply with mandatory requirements specified in this document.

7.2. Developing prototypes and conducting test

The pilot application provider will be responsible for developing a prototype of the smart card standard application on at least one type of acceptance terminal. The pilot application provider will also be responsible for developing the IT infrastructure for supporting the test system.

The pilot project participants will certify that the specifications and the prototype meet the requirements of the application owners and the standard smart card application requirements. Small scale, closed environment test shall be conducted to evaluate the technical aspects of each individual application functions and on combination of multi-applications. The test shall prove the reliability and stability of each system, including application software, acceptance terminals, network, settlement and clearing system, other back-end infrastructure and security. The pilot project owners will determine a suitable size and locations for the closed environment test.

7.3. Building system facilities and network

The pilot application provider will also be responsible for building the IT infrastructure for supporting the production system. The infrastructure is including key management system, card personalization system, settlement and clearing system, concentrator system, acceptance terminals, network and communication facilities.

Implementing of multi card issuers, multi-application developer and further certification for more card acceptance devices (such as public-telephone, vending machines etc.) may be included in order to ensure that all relevant components of all the system are inter-operable and meet the standard smart card specifications.

7.4. Conducting pilot run

Before full roll out of the standard smart card application, smart cards shall be rolled out to a confined area for trial pilot run and refine all operation aspects such as security procedures, card


issuance process, card acceptance terminal functions, data capture, settlement and clearing. The project owners will determine number of cards to be issued, service locations and number of acceptance terminals for trial pilot run in the confined environment.

7.5. Rolling out as commercial

A large scale commercial pilot of standard electronic purse and loyalty program shall be roll out to stimulate consumer attraction and to meet scale of economy. Some substantial public-education, advertisements and promotions are needed to educate and encourage consumer to use electronic purse. The electronic purse is designed to replace the usage of cash and coin for daily payment of people. The beginning target population is for public-telephone and retailing which may include loyalty program as an incentive.

7.6. Refining and evaluating achievement

All implementing locations will be tracked their operational and transactional performance. All problem cases and its resolutions will be recorded for further studying and evaluating. The refinement of card issuance, distribution strategy, communication strategy, clearing and settlement operations shall get improvement whilst the commercial pilot is implementing. The commercial pilot will be evaluated by project owners and the smart card standard committee.

7.7. Ongoing operations for open-end

National roll out of smart card system is expected to take place within one year after the initial commercial roll out have been completed its refinement and evaluation period. The free opens for more banks and businesses to be able to join the national roll out of card issuance, card applications, card acceptance devices and IT infrastructures.


This page is left blank intentionally.


Appendix A - Terminal Types

This part addresses broad types of multi purposed terminals in following to the EMV ICC terminal specification for payment system - Part 1 terminal types and capabilities.Terminal types are categorized in table D-1 below:

Environment Financial/GovtInstitution

Merchant Card Holder

Attended Online only Offline with online capability Offline only

111213

212223

---

Unattended Online only Offline with online capability Offline only

141516

242526

343536

Table D-1: Terminal Types


Appendix B - BER-TLV Data Object

The following is a definition of BER-TLV data object format as defined in ISO/IEC 8825 and EMV specification

B.1. Coding of BER-TLV Data Objects

A BER-TLV data object consists of 2-3 consecutive fields:• The tag field (T) consists of one or more consecutive bytes. It codes a class, a type, and a

number (see Table B-1). The tag field of the data objects described in this specification is coded on 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 on one, two, or three 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 data element for financial transaction

interchange.• 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 called a template.

The coding of BER-TLV data object field is defined as follows.

B.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 according to Table B-1:

Table B-1: Tag Field Structure (First Byte) BER-TLV

According to ISO/IEC 8825, Table B-2 defines the coding rules of the subsequent bytes of a BER-TLV tag when tag numbers >31 are used (that is, bits b5 - b1 of the first byte equal ‘11111’).


Table B-2: Tag Field Structure (Subsequent Bytes) BER-TLVThe coding of the tag field of a BER-TLV data object is according to the following rules:• The following application class templates defined in ISO/IEC 7816 apply: ‘61’ and ‘6F.’• The following range of application class templates is defined in Part II: ‘70’ to ‘7F’. The

meaning is then specific to the context of an application according to this specification. Tags ‘78’, ‘79’, ‘7D’, and ‘7E’ are defined in ISO/IEC 7816-6 and are not used in this specification.

• The application class data objects defined in ISO/IEC 7816 and described in Part II are used according to the ISO/IEC 7816 definition.

• Context-specific class data objects are defined in the context of this specification or in the context of the template in which they appear.

• The coding of primitive context-specific class data objects in the ranges ‘80’ to ‘9E’ and ‘9F00’ to ‘9F4F’ is reserved for this specification.

• The coding of primitive context-specific class data objects in the range ‘9F50’ to ‘9F7F’ is reserved for the payment systems.

• The coding of primitive and constructed private class data objects is left to the discretion of the issuer.

B.1.2 Coding of the Length Field of BER-TLV Data Objects

When bit b8 of the most significant byte of the length field is set to 0, the length field consists of only one byte. Bits b7 to b1 code the number of bytes of the value field. The length field is within the range 1 to 127.

When bit b8 of the most significant byte of the length field is set to 1, the subsequent bits b7 to b1 of the most significant byte code the number of subsequent bytes in the length field. The subsequent bytes code an integer representing the number of bytes in the value field. For example, three bytes are necessary to express up to 65,535 bytes in the value field.

B.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 according to Table B-3:

Tag(T)

Length(byte)(L)

Value(V)

Table B-3: Primitive BER-TLV Data Object (Data Element)

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. A record in an AEF governed by this specification is a constructed BER-TLV data object. A constructed data object is structured as in Table B-4:

Tag(T)

Length(byte)(L)

Primitive BER-TLVData object number 1

… Primitive BER-TLVData object number n


Table B-4: Constructed BER-TLV Data Object


Appendix C – Transaction Message Format

The followings are standard message formats that shall be used for online transactions and onlinetransaction uploading of credit/debit transactions, electronic purse transactions and loyaltytransactions.

Legend for Message Formats

1) Data Attributes

Attribute Definition A Alpha characters (a-z, A-Z). Each data element represents 1 byte. An Alpha-numeric characters (1-9, a-z, A-Z).

Each data element represents 1 byte. ans Alpha-numeric and special characters (All characters).

Each data element represents 1 byte. b Binary data. Each data element represents 1 bit (8 data elements = byte). n Numeric Data. Each data element represents 1 nibble.

(2 data elements = 1 byte) z Track 2 data, as read from the magnetic strip. Each data element represents

1 nibble (2 data elements = 1 byte)

2) Data Field

Field Definition M Mandatory O Optional Cxx 01

02

03

04

05

Conditional field, where xx is:The primary Account number is included when the transaction is entered manually via the keyboard.The expiration date field will be included if the Card number was entered manually, and the card processing options are set to accept a date, expiration to be entered.For on-line transactions when the account number is read from the magnetic stripe reader track I and or track II will be included.Terminal only stores the primary account number and expiration date from track read. Any transactions processed other than an online transaction, will include the PAN and expiry date.The first two digits of the POS entry mode will be set to ‘02’ if the card is read by the card reader, ‘01’ if the card number is entered by the keyboard, and ‘05’ if the card is read by the Smartcard reader. The last digit indicates the PIN entry capability of the terminal ‘1’ if has PIN entry capability and ‘2’ if not. This information is additional transaction detail, not to be used to determine which field to use for the Card number.


C.1. Credit Card Transaction Message Formats

The followings are list of online transactions support by terminal for credit card transaction. Each transaction is listed showing the fields for that transaction as sent from the terminal, and the fields expected in the response to be sent from the host.

Pre Authorization

The Pre-Authorization transaction is normally restricted to use in automated gas station, etc.This transaction occurs on-line, and this message can be sent from the terminal to the Host at any time during the day. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next.

Bit Field Name Attribute Req. Rsp. CommentsMessage Type ID n 4 0100 0110Bit Map b 64 M M

02 Primary Acc. Number n ..19 C01 If manual card entry allowed03 Processing Code n 6 30A00X 30A00X A-acct. select, X extra

control bit04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 If manual entry of expiry

date is allowed22 POS Entry Mode n 3 C03 “050”=Smart Card24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 C0237 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry61 Product Codes ans 8 O If product codes are selected

for this card Defn. table62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected

for this Card Defn. table64 Message Authentication

Codeb 64 O O If MACs are selected in his

Card Defn. table entry


Sales Completion

The Sales Completion transaction is used to complete a Pre-Authorize transaction when the exact amount is known or following a voice referral, and subsequent voice approval.

This transaction occurs off-line, and this advice message can be sent from the terminal to the Host at any time during the day before a close batch/settlement transaction is undertaken. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next.


02 Primary Acc. Number n ..19 M03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra control

bit04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M Time transact was approved13 Date, local transaction n 4 M Date transact was approved14 Date, expiration n 4 O If available from origin.trans22 POS Entry Mode n 3 C03 “050”= Smart Card24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0037 Retrieval Ref Number an 12 M

MReq.RRW is from origin respResp RRW updat RRW for transaction in terminal batch

38 Auth. ID Response an 6 M39 Response Code an 2 M M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field



for this Card Defn. table63 IC Card Information ans ..256 O O64 Message Authentication




Sales


02 Primary Acc. Number n ..19 C01 Manual card entry,if allowed03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra

control bit04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 Manual entry of expiry date ,

if allowed22 POS Entry Mode n 3 C03 “050”= Smart Card24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 C0237 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 O39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Refund












Adjust

The Adjust transaction is used to notify the host that there has been a change to the amount of a previous transaction.



02 Primary Acc. Number n ..19 M03 Processing Code n 6 22A00X 22A00X Adjust of Credit Transaction

A-acct. select, X extra ctl bit04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M Time transact was approved13 Date, local transaction n 4 M Date transact was approved14 Date, expiration n 4 O If available from origin.trans22 POS Entry Mode n 3 C03 “050”= Smart Card24 Network Int’l. ID n 3 M M From NII field entry in card



38 Auth. ID Response an 6 M39 Response Code an 2 M M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry60 Original Amount ans….999 M Contains original amount61 Product Codes ans 8 O If product codes are selected






Void

The Void transaction is used to inform the host that a transaction previously performed at the terminal has been cancelled.

This transaction occurs on-line, and this message can be sent from the terminal to the Host at any time during the day before a close batch/settlement transaction is undertaken. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next.


02 Primary Acc. Number n ..19 M03 Processing Code n 6 22A00X 22A00X Void of Credit Transaction

A-acct. select, X extra ctl bit04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 O If available from origin.trans22 POS Entry Mode n 3 C03 “050”= Smart Card24 Network Int’l. ID n 3 M M From NII field entry in card



38 Auth. ID Response an 6 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Offline Sales



02 Primary Acc. Number n ..19 M03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra ctl bit04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M Time transact was approved13 Date, local transaction n 4 M Date transact was approved14 Date, expiration n 4 O If available from origin.trans22 POS Entry Mode n 3 C03 “050”= Smart Card24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0037 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Reversal

This reversal request is sent from the terminal to the Host when the Host does not acknowledge or reject the previous transaction request until the transaction time-out period expired. This reversal request is sent persistently until the terminal receives a valid response to this reversal. Reversals will only be sent for on-line transaction messages. The reversal format is identical to the original request/advice being reversed, except for the substitution of 0400 for the message type ID.


02 Primary Acc. Number n ..19 C01 Manual card entry,if allowed03 Processing Code n 6 M M Same as the transaction

being reversed04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 Manual entry of expiry date ,


definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 C0237 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 O39 Response Code an 2 M Will always be “00”41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field


for this card Defn. table62 Invoice/ECR Reference ans 6 If Inv./ECR Ref.# is selected





Batch Upload

The batch upload format is identical to the original request/advice transaction, except for the substitution of 0320 for the message type ID.


02 Primary Acc. Number n ..19 M From original transaction03 Processing Code n 6 M M Same as original transaction04 Amount Transaction n 12 M From original transaction11 System Trace Number n 6 M M12 Time, local Transaction n 6 M M13 Date, local transaction n 4 M M14 Date, expiration n 4 O If original transaction had22 POS Entry Mode n 3 M From original transaction24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0037 Retrieval Ref Number an 12 M M From original transaction38 Auth. ID Response an 6 O39 Response Code an 2 M M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry60 Original Data ans ...999 O Message type, System trace

from original transaction61 Product Codes ans 8 O If product codes are selected

for this card Defn. table62 Invoice/ECR Reference ans 6 O If Inv./ECR Ref.# is selected





Settlement


02 Primary Acc. Number n ..19 M03 Processing Code n 6 92000X

96000X92000X96000x

For Initial Settlement requestAfter b a t ch up loa d, i f requested by host response

11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry37 Retrieval Ref Number an 12 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry60 Batch Number ans 6 M Batch number of settle batch62 Response Text ans …40 O May contain 2 lines of 20char

text for display and/or print63 Batch Totals ans …90 M See Private field definitions64 Message Authentication



Private Field 63: Batch Totals Request

This is the definition of field 63 batch totals in the close batch/settlement request.

Field Name Attribute Byte Content

Length Attribute n 3 2 0hhh - BCD Length of data to follow

Capture card sale Count an 3 3 000 - 999Capture card sale Amount an 12 12 $$$$$$$$$$ccCapture card refund count an 3 3 000 - 999Capture card refund Amount an 12 12 $$$$$$$$$$ccDebit card Sale Count an 3 3 000 - 999Debit card Sale Amount an 12 12 $$$$$$$$$$ccDebit card Refund Count an 3 3 000 - 999Debit card refund Amount an 12 12 $$$$$$$$$$ccAuthorise Card Sale Count an 3 3 000 - 999Authorise Card Sale Amount an 12 12 $$$$$$$$$$ccAuthorise Card Refund Count an 3 3 000 - 999Author ise Card Refund Amount

an 12 12 $$$$$$$$$$cc


C.2. Debit Card Transaction Message Formats

The followings are list of online transactions support by terminal for debit card transaction. Each transaction is listed showing the fields for that transaction as sent from the terminal, and the fields expected in the response to be sent from the host.

Logon


03 Processing Code n 6 92000X 92000X X- Extra Control Bit = 011 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry39 Response Code an 2 M M From original transaction41 Terminal I.D. ans 8 M M62 Logon Data ans 6 O See note below

Notes :


Length Attribute n 3 2 0hhh - BCD Length of data to followPIN Working Key b 64 8 PIN working key encryption under

terminal master keyMAC Working Key B 64 8 MAC working encrypted under terminal

master key


Balance Inquiry


03 Processing Code n 6 31A00X 31A00X A-acct. select, X extra control bit

04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M M13 Date, local transaction n 4 M M15 Date, settlement n 422 POS Entry Mode n 3 M ‘051’= Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 M37 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry52 PIN Data b 64 O DES algorithm61 Product Codes ans 8 O If product codes are selected






Pre Authorization

The Pre-Authorization transaction is normally restricted to use in automated gas station, etc.This transaction occurs on-line, and this message can be sent from the terminal to the Host at any time during the day. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next.



04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M15 Date, settlement n 422 POS Entry Mode n 3 M ‘051’=Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 M37 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Pre-Auth Completion

The Sales Completion transaction is used to complete a Pre-Authorize transaction when the exact amount is known or following a voice referral, and subsequent voice approval.




04 Amount Transaction n 12 M M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M15 Date, Settlement n 422 POS Entry Mode n 3 M ‘051’= Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card



38 Auth. ID Response an 6 O39 Response Code an 2 M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Debit Sales



04 Amount Transaction n 12 M M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M15 Date, Settlement n 422 POS Entry Mode n 3 M ‘051’= Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 M37 Retrieval Ref Number an 12 M M38 Auth. ID Response an 6 O39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Void

The Void transaction is used to inform the host that a transaction previously performed at the terminal has been cancelled.



03 Processing Code n 6 02A00X 02A00X Void of Debit TransactionA-acct. select, X extra ctl bit

04 Amount Transaction n 12 M M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M15 Date, Settlement n 422 POS Entry Mode n 3 M ‘051’=Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z 37 M37 Retrieval Ref Number an 12 M


38 Auth. ID Response an 6 O39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Reversal



03 Processing Code n 6 M M Same as the transaction being reversed

04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M15 Date, Settlement n 422 POS Entry Mode n 3 M ‘051’= Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 M37 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 O39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field







Batch Upload

The batch upload format is identical to the original request/advice transaction, except for the substitution of 0320 for the message type ID.


02 Primary Acc. Number n ..19 M From original transaction03 Processing Code n 6 M M Same as original transaction04 Amount Transaction n 12 M From original transaction11 System Trace Number n 6 M M12 Time, local Transaction n 6 M M13 Date, local transaction n 4 M M14 Date, expiration n 4 M From original transaction22 POS Entry Mode n 3 M From original transaction24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0037 Retrieval Ref Number an 12 M M From original transaction38 Auth. ID Response an 6 M M39 Response Code an 2 M M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry60 Original Data ans ...999 M See note below61 Product Codes ans 8 O If product codes are selected

for this card Defn. table62 Invoice/ECR Reference ans 6 O If Inv./ECR Ref.# is selected

for this Card Defn. table63 IC Card Information ans …256 O O64 Message Authentication



Note :


Length Attribute n 3 2 0hhh – BCD Length of data to followMessage Type an 4 4 Message Type from original transactionSystem Trace No. an 6 6 System Trace from original transactionRetrieval Ref. Number an 12 12 Retr. Ref. No. from original transaction


Settlement


02 Primary Acc. Number n ..19 M03 Processing Code n 6 92000X

96000X92000X96000X

For Initial Settlement requestAfter b a t ch up loa d, i f requested by host response

11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry37 Retrieval Ref Number an 12 M39 Response Code an 2 M From original transaction41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field

in Card definition table entry60 Batch Number ans 6 M Batch number of settle batch62 Response Text ans …40 O May contain 2 lines of 20char

text for display and/or print63 Batch Totals ans …90 M See Private field definitions64 Message Authentication






Length Attribute n 3 2 0hhh – BCD Length of data to follow

Capture card sale Count an 3 3 000 – 999Capture card sale Amount an 12 12 $$$$$$$$$$ccCapture card refund count an 3 3 000 – 999Capture card refund Amount an 12 12 $$$$$$$$$$ccDebit card Sale Count an 3 3 000 – 999Debit card Sale Amount an 12 12 $$$$$$$$$$ccDebit card Refund Count an 3 3 000 – 999Debit card refund Amount an 12 12 $$$$$$$$$$ccAuthorise Card Sale Count an 3 3 000 - 999Authorise Card Sale Amount an 12 12 $$$$$$$$$$ccAuthorise Card Refund Count an 3 3 000 - 999Author ise Card Refund Amount

an 12 12 $$$$$$$$$$cc


C.3. Electronic Purse Transaction Message Format

Purse Reloading


02 Primary Acct Number n 19 C01 Manual key in, if allowed03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra

control bit04 Amount Transaction n 12 M M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 Manual key in, if allowed22 POS Entry Mode n 3 M ‘051’=Smart Card with PIN24 Network Int’l. ID n 3 M M From NII field entry in card


in Card definition table entry52 PIN Data b 64 O DES Algorithm61 Product Codes ans 8 O If product codes are selected


for this Card Defn. table63 E-purse Information an 999 M M Private field definitions64 Message Authentication




Reversal



02 Primary Acc. Number n ..19 O From original transaction03 Processing Code n 6 M M Same as the transaction

being reversed04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 Manual entry of expiry date ,

if allowed22 POS Entry Mode n 3 C03 “051”= Smart Card with

PIN24 Network Int’l. ID n 3 M M From NII field entry in card

definition table entry25 POS Condition Code n 2 0035 Track 2 Data z ..37 C0237 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 O39 Response Code an 2 M Will always be “00”41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID field



for this Card Defn. table63 E-purse Information ans ..256 O O Private field definition64 Message Authentication




Purse Transfer to Account








for this Card Defn. table63 E-purse Information ans ..256 M M Private field definitions64 Message Authentication




Offline Sales

This transaction occurs off-line, and this advice message can be sent from the terminal to the Host at any time during the day before a close batch/settlement transaction. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next.


02 Primary Acc. Number n ..19 C01 Should be present for Smartcard read

03 Processing Code n 6 00A00X 00A00X A - acct. select, X extra control bit

04 Amount Transaction n 12 M11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 Should be absent for

Smartcard read22 POS Entry Mode n 3 C03 “051” = Smartcard (pin

entry)24 Network Int’l. ID n 3 M M From NII field entry in

card definition table entry

25 POS Condition Code n 2 0035 Track 2 Data z ..37 C02 Should be absent for

Smartcard read37 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M Will always be “00”41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID

field in Card definition table entry

61 Product Codes ans 8 O If product codes are selected for this card Defn. table

62 Invoice/ECR Reference ans6

O If Invoice/ECR Ref. # is selected for this Card Defn. table

63 E-purse Information ans 256 M M Private field definition64 Message Authentication

codeb 64 O O If MACs are selected in

his Card Defn. table entry


Close Batch/Settlement

This request message can be sent from the terminal to Host after any outstanding off-line completed transactions have been advised to the Host. The request can be sent any number of times during the day. If the terminal times out waiting for the response from the Host, then the terminal should retry the request next. If the response from the Host indicates an out of balance condition then the terminal should proceed with a batch upload.


03 Processing Code n 6 92000X96000X

92000X96000X

Initial Settl. RequestAfter batch upload, if req. by host in response to init ia l sett lement request

11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M24 Network Int’l. ID n 3 M M From NII field entry in


37 Retrieval Ref. Number an 12 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID


60 Batch Number ans 6 M Batch number of batch being settled

62 Points Issuance Rate ans 128 O New points Issue rate63 Points Batch Totals ans 128 M Points batch Totals63 Response Text ans 40 O May contain up to two

lines of 20 chars. Of text for display and/or print

64 Message Authentication Code

b 64 O O If MACs are selected in his Card Defn. table entry


C.4. Loyalty Program Transaction Message Formats

Points Issue/Redemption

This transaction occurs off-line, and this advice message can be sent from the terminal to the Host at any time during the day before a close batch/settlement transaction. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next. All off-line points issue/redemption transactions must be sent to the host before a close batch/settlement transaction is undertaken.



03 Processing Code n 6 00A00X 00A00X A - acct. select, X extra control bit






Smartcard read37 Retrieval Ref Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M Will always be “00”41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID


61 Product Codes ans 8 O If product codes are selected for this card Defn. table



63 Points Information ans 256 M M64 Message Authentication

Codeb 64 O O If MACs are selected in



Adjust (Void) Points Issue/Redemption

This transaction occurs off-line, and this advice message can be sent from the terminal to the Host at any time during the day before a close batch/settlement transaction. If the terminal times out waiting for an acknowledgment from the Host, the terminal should send a Reversal message next. All adjust (void) transactions must be sent to the host before a close batch/settlement transaction is undertaken.



03 Processing Code n 6 02A00X 02A00X Void transactionA - acct. select, X extra control bit






Smartcard read37 Retrieval Ref. Number an 12 M38 Auth. ID Response an 6 M39 Response Code an 2 M Will always be “00”41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID


61 Product Codes ans8

O If product codes are selected for this card Defn. table



63 Points Information ans 256 M M64 Message Authentication

Codeb 64 O O If MACs are selected in



Reversal

This reversal request is sent from the terminal to the Host when the Host does not acknowledge or reject the previous Points Issue/Redemption or Adjustment (Void) advice. This reversal request is repeated until the terminal receives a response to this reversal. The reversal format is identical to the original request/advice being reversed, except for the substitution of 0400 for the message type ID, and that field 63 is optional.

Host points

This request message can be sent from the terminal to the Host at any time during the day. If the terminal timesout waiting for an acknowledgment from the Host, the terminal should not send a Reversal message as this is not to be treated as a financial transaction by the terminal.



03 Processing Code n 6 38A00X 38A00X X extra control bit11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M14 Date, expiration n 4 C01 Should be absent for

Smartcard read22 POS Entry Mode n 3 051 “051” = Smartcard (pin


card definition table25 POS Condition Code n 2 0035 Track 2 Data z ..37 C02 Should be absent for

Smartcard read37 Retrieval Ref.Number an 12 M38 Auth. ID Response an 6 O39 Response Code an 2 O M Response code of Card

adjustment result00 - Successful51 - Decline

41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor ID


63 Card Update ans 256 M O Ca r d A d j u s t m e n t Information



If the Host responds with a 00 approval response code, then the card should be updated. A decline response of 51 indicates that the Card should not be updated.


Close Batch/Settlement

This request message can be sent from the terminal to Host after any outstanding off-line completed transactions have been advised to the Host. The request can be sent any number of times during the day. If the terminal times out waiting for the response from the Host, then the terminal should retry the request next. If the response from the Host indicates an out of balance condition then the terminal should proceed with a batch upload.


03 Processing Code n 6 92000X96000X

92000X96000X

Initial Settle RequestAfter batch upload, if req. b y h o s t i n response to initial settlement request

11 System Trace Number n 6 M M12 Time, local Transaction n 6 M13 Date, local transaction n 4 M24 Network Int’l. ID n 3 M M From NII field entry

in card definition table entry

37 Retrieval Ref. Number an 12 M39 Response Code an 2 M41 Terminal I.D. ans 8 M M42 Card Acc. I.D. ans 15 M From Card acceptor

ID f ield in Card definition table entry

60 Batch Number ans 6 M Batch number of batch being settled

62 Points Issuance Rate ans 128 O New points Issue rate63 Points Batch Totals ans 128 M Points batch Totals63 Response Text ans 40 O May contain up to

two lines of 20 chars. Of text for display and/or print




Field 63 Message Format

This field is defined depending on the message type:

1. Point Information request: Associated with Points Issue/redeem and Void and associated Batch upload

2. Card Update Request: Associated with Host Points3. Card Update Response: Associated with Host points4. Batch Totals: Associated with Settlement request




Length Attribute n 3 2 0hhh - BCD Length of data to follow

Capture card sale Count an 3 3 000 - 999Capture card sale Amount an 12 12 $$$$$$$$$$ccCapture card refund count an 3 3 000 - 999Capture card refund Amount an 12 12 $$$$$$$$$$ccDebit card Sale Count an 3 3 000 - 999Debit card Sale Amount an 12 12 $$$$$$$$$$ccDebit card Refund Count an 3 3 000 - 999Debit card refund Amount an 12 12 $$$$$$$$$$ccAuthorize Card Sale Count an 3 3 000 - 999Authorize Card Sale Amount an 12 12 $$$$$$$$$$ccAuthorize Card Refund Count an 3 3 000 - 999Author ize Card Refund Amount

an 12 12 $$$$$$$$$$cc

The terminal accumulates the counts and amounts of off-line sale points issue/redeem and adjust/voids transactions.

Off-line sale counts and amounts (not points) will be accumulated under the capture cards sale counts and amounts.

Adjust (void) sale counts and amounts (not points) will be accumulated under the capture cards refund counts and amounts.

For points issued transactions the amount should reflect the purchase amount and not the points. This applies for both the sale and void transactions. For points redeemed transactions the amount should be the transaction amount, however this will be zero. This applies to both sale and void transactions.


Appendix D - Normative References

The following standards contain provisions that can be used for extensive reference of smart card, magnetic stripe and financial transaction standards:

EMV: May 31, 1998 Integrated Circuit Card Specification for Payment SystemsVersion 3.1.1

EMV: May 31, 1998 Integrated Circuit Card Terminal Specification for PaymentSystems Version 3.1.1

EMV: May 31, 1998 Integrated Circuit Card Application Specification forPayment Systems Version 3.1.1

Visa ICC: May 31, 1998 Visa Integrated Circuit Card Specification Version 1.3.1

Mastercard ICC: Oct 17, 1997 Mastercard Integrated Circuit Card ApplicationSpecification for Debit and Credit Version 1.0

ISO 9564-1:1991 Banking – PIN management and security – PIN protectionPrinciples and techniques

ISO 9564-2:1991 Banking – PIN management and security – Approvedalgorithms for PIN encipherment

ISO 13491:1995 Banking – Secure cryptographic devices (retail)

IEC 512-2:1979 Specifications for electromechanical components forelectromechanical equipment - Part 2: Contact resistancetests, insulation tests, and voltage stress tests

ISO 639:1988 Codes for the representation of names and languages

ISO 3166:1993 Codes for the representation of names of countries

ISO 4217:1995 Codes for the representation of currencies and funds

ISO 4909:1987 Bank cards – Magnetic stripe data contents for track 3

ISO/IEC 7811-1:1995 Identification cards - Recording technique - Part 1: Embossing

ISO/IEC 7811-3:1995 Identification cards - Recording technique - Part 3: Locationof embossed characters on ID-1 cards

ISO/IEC 7813:1995 Identification cards - Financial transaction cards

ISO/IEC DIS 7816-1:1998 Identification cards - Integrated circuit(s) cards with contacts- Part 1: Physical characteristics

ISO/IEC DIS 7816-2:1998 Identification cards - Integrated circuit(s) cards with contacts- Part 2: Dimensions and location of contacts


ISO/IEC 7816-3:1989 Identification cards - Integrated circuit(s) cards with contacts- Part 3: Electronic signals and transmission protocols

ISO/IEC 7816-3:1992 Identification cards - Integrated circuit(s) cards with contacts- Part 3, Amendment 1: Protocol type T=1,asynchronous halfduplex block transmission protocol

ISO/IEC 7816-3:1994 Identification cards - Integrated circuit(s) cards with contacts- Part 3, Amendment 2: Protocol type selection (DraftInternational Standard)

ISO/IEC 7816-4:1995 Identification cards - Integrated circuit(s) cards with contacts- Part 4, Inter-industry commands for interchange

ISO/IEC 7816-5:1994 Identification cards - Integrated circuit(s) cards with contacts- Part 5: Numbering system and registration procedure forapplication identifiers

ISO/IEC 7816-6:1996 Identification cards - Integrated circuit(s) cards with contacts- Part 6: Inter-industry data elements

ISO/IEC 10373:1993 Identification cards - Test methods

ISO 8731-1:1987 Banking - Approved algorithms for message authentication -Part1: DEA

ISO 8372:1987 Information processing - Modes of operation for a 64-bit blockcipher algorithm

ISO/IEC 8825:1990 Information technology - Open systems interconnection –Specification of basic encoding rules for abstract syntaxnotation one (ASN.1)

ISO 8583:1987 Bank card originated messages - Interchange messagespecifications - Content for financial transactions

ISO 8583:1993 Financial transaction card originated messages - Interchangemessage specifications

ISO 8859:1987 Information processing - 8-bit single-byte coded graphiccharacter sets

ISO/IEC 9796-2:1997 Information technology - Security techniques- Digital signature scheme

giving message recovery- Part 2: Mechanism using a

hash function

ISO/IEC 9797:1994 Information technology - Security techniques


- Data integrity mechanism using a cryptographic check function employing a block cipher algorithm

ISO/IEC 10116: 1997 Information technology - Modes of operation of an n-bit blockcipher algorithm

ISO/IEC 10118-3:1998 Information technology - Security techniques- Hash functions- Part 3: Dedicated hash functions

FIPS Pub 180-1:1995 Secure Hash Standard

thailand smart card standard application requirementss3.amazonaws.com/zanran_storage/... ·...

Documents