Tài liệu Tiêu chuẩn kỹ thuật của thẻ chứng minh nhân dân điện tử của Thailand doc

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

THAILAND Smart Card Standard Application

Requirements Version 1.0

Thailand Smart Card Working Group

01 April 1999 Released Number: 1.1

Thailand Smart Card Standard Application Requirements

INDEX

1 Introduction 4

1.1 Smart card Scheme Overview 4

1.1.1 Scope 4

1.1.2 Scheme Structure 5

1.2 Smart card Requirements 8

1.2.1 Compliance Requirements 8

1.2.2 Data Elements and Files 9

1.2.3 Standard Commands 10

1.3 Terminal Requirements 11

1.3.1 Terminal Types 11

1.3.2 Terminal Capabilities 11

1.4 Application Requirements 12

1.4.1 Application Scope 12

1.4.2 Application Selection 13

1.4.3 Transaction Processing 13

1.4.4 Data Integrity 15

1.4.5 Year 2000 Support 15

1.5 Network Requirements 16

1.6 Settlement and Clearing Requirements 17

2 Security Requirements 18

2.1 Smart cards Delivery 18

2.2 Symmetric Key Management 18

2.2.1 Symmetric Key Generation 18

2.2.2 Key Distribution 19

2.2.3 Key Loading Process 19

2.3 Asymmetric Key Management 19

2.3.1 Public Key Pairs Generation 19

2.3.2 Certification Authority 20

2.4 Card Personalization 20

2.4.1 Chip Personalization 20

2.4.2 Magnetic Stripe Encoding and Embossing 21

2.5 Post Personalization 21

2.5.1 Files Access Conditions 21

2.5.2 Files And Application Locking 22

2.5.3 Secret Code Protection 22

2.6 Cryptographic Security Requirements 22

2.6.1 Temporary Session Key Generation 22

2.6.2 Card Authentication 22

2.6.3 Cardholder Authentication 23

2.6.3 Secure Messaging 23

3 ID Card Application 24

3.1 Functional Requirements 24

3.2 Application Owner 25

3.3 Data Requirements 25

3.4 Card Surface Requirements 26

3.5 Security Requirements 27

3.6 Application Transactions 27

4 Credit/Debit Card Application 28

4.1 Functional Requirements 28

4.2 Application Owner 28

4.3 Data Requirements 28

4.4 Card Surface Requirements 29

4.5 Security Requirements 29

4.6 Application Transactions 30

5 Electronic Purse Application 31

5.1 Functional Requirements 31

5.2 Application Owner 32

5.3 Data Requirements 32

5.3 Card Surface Requirements 33

5.4 Security Requirements 33

5.5 Application Transaction 34

6 Loyalty Application 36

6.1 Functional Requirements 36

6.2 Application Owner 36

6.3 Data Requirements 37

6.4 Card Surface Requirements 38

6.5 Security Requirements 38

6.6 Application Transaction 38

7 Pilot Project 41

7.1 Producing specifications 41

7.2 Developing prototypes and conducting test 41

7.3 Building system facilities and network 41

7.4 Conducting pilot run 41

7.5 Rolling out as commercial 42

7.6 Refining and evaluating achievement 42

7.7 Ongoing operations for open-end 42

Appendix A - Terminal Types 44

Appendix B - BER-TLV Data Object 45

B.1 Coding of BER-TLV Data Objects 45

B.1.1 Coding of the Tag Field of BER-TLV Data Objects 45

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

B.1.3 Coding of the Value Field of Data Objects 46

Appendix C – Transaction Message Format 48

C.1 Credit Card Transaction Message Formats 49

C.2 Debit Card Transaction Message Formats 59

C.3 Electronic Purse Transaction Message Format 68

C.4 Loyalty Program Transaction Message Formats 73

Appendix D - Normative References 78

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 Provider

Figure 1 : Open Smart Card Scheme Participants

(OHFWURQLF 9DOXH

Smart Card Scheme Relationships

Cardholder

Merchant / Service provider

Merchant / Service provider

Acquirer Issuer

Fund Pool

Clearing House

Scheme Provider

Value 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:

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 Commands1.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

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

• 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

• 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

‘2010X’ Debit Card (No PIN)

‘3010X’ ATM/Debit Card (With PIN)

‘6010X’ Electronic Purse

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

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 :

transaction

limit threshold value

the calculated transaction target percent

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 applications Private Specific Keys – specify for private used by application providers or card issuers Value Added Keys – specify added-on keys used by other related applications

Administrative 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

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 Messaging

The 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 Messaging

The 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

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

4 Personalization Equipment Identifier 8 numeric char 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:

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

D2 5 Tax ID 10 numeric char 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 number

3) Name and Surname

4) Name Prefix or Title

5) Services Department (in case of government employee)

6) Birth Date

7) Registered Address

8) Picture

9) Signature

10) Card Issued Date

11) Card Expiration Date

12) Blood Group

13) Driving License Number

14) Type of Driving License

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

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 access

The 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 access

Off-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 access

The 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

4.1 Functional Requirements

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

• 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)

4.4 Card Surface Requirements

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

4.5 Security Requirements

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

1) To validate that the card is authentic

2) To ensure that off-line authorization is authentic

3) 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 )

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

5.1 Functional Requirements

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

5.2 Application Owner

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:

4 Personalization Equipment Identifier 8 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:

C9 var Thumbprints Bit map image 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

5.3 Card Surface Requirements

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 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

name-• 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

5.4 Security Requirements

The electronic purse applications should support three main security objectives:

1) To validate that the card is authentic

2) To ensure that off-line authorization is authentic

3) 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 allowed

The 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 key

The 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 value

The 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 control

The 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 purse

The 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 recovery

The 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 account

The 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 inquiry

The 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 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

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

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

6.2 Application Owner

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

6.3 Data Requirements

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

4 Personalization Equipment Identifier 8 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:

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

6.4 Card Surface Requirements

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 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

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 format, self-selected 4 - 6 digit number as their “PIN Code”

free-• 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 forwarded

to 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 only

be 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, then

2 the division (Tot.Sales / Divide.Amt) is evaluated (and rounded down), and

3 the first 2 expressions are multiplied (and rounded down), and finally

4 the result is multiplied by Point.Rate which is selected from the conversion parameters table