Evolution of the Electronic Purse:

Case Studies of Thailand

and Hong Kong

By

Mr.Kitti Pluktadachai

A Project of the Six-Credit Course

TM 6900 Master Project

Submitted in Partial Fulfillment of the

Requirements for the Degree of
Master of Science
in Telecommunications Management
Assumption University

December 2004
 THE ASSUMPTION UNIVERSITY LIBRARY
/UJ1 2.-:tO
[!)--rlD M /9 /~ ?-l

Evolution of the Electronic Purse:

Case Studies of Thailand

and Hong Kong

By

Mr.Kitti Pluktadachai

A Project of the Six-Credit Course

TM 6900 Master Project

Submitted in Partial Fulfillment of the

Requirements for the Degree of
Master of Science
in Telecommunications Management
Assumption University

December 2004
 Project Title: Evolution of the Electronic Purse: Case Studies of
Thailand and Hong Kong

Name: Mr.Kitti Pluktadachai

Project Advisor: Dr.Sudhiporn Patumtaewapibal

Academic Year: 2004

The Faculty of Engineering, Assumption University had approved this final

report of the six credit course, TM 6900 Master Project, submitted in partial

fulfillment of the requirements for the degree of Master of Science in

Telecommunications Management.

Approval Committee :

(Dr.Sudhiporn Patumtaewapibal) (Asst. Prof. Dr. Kitti phan Techaki ttiroj)

Chairman / Advisor Member

(Assoc.Prof.Dr.Kobchai Dejhan)

MUA Representative

December 2004
BLANK PAGE

-2-
 ABSTRACT

The emergence of information technology makes our daily life easier. We

have changed from a room full of millions pieces of paper to storing all the data in the

hard disk of the size of a palm. The time we spend on searching data shrinks from

several months in the past to a few seconds today. The emergence of smart card

technology is also the same. We have moved from not willing to conduct the business

transaction on the cyber world, which is full of viruses and spies to the trust in

e-commerce. There are many things we have not dreamed about but become possible,

for example, using the credit card for the low value transaction, which is now

commonplace and easy in the electronic purse (e-purse) application world. This report

shows you about a better life and the safe world of the Internet and the real world by

using the electronics money.

The objective of this report is to introduce the reader to the characteristics of

the electronic payment, of which e-purse is a part. This paper also presents the

technology, security, and the standards related to the application of e-purse through

the Thai and international case studies. This paper contain case studies both contact

type and contactless e-purse application. However, not only is technology presented,

but the reader will also learn about the business aspects that lead to a success of

e-purse service. The legal knowledge related to e-purse is also important.

In the year 2005, the Thai people will use the smart card technology as their

ID cards. Smart cards also show the possibility of being extended to being e-purse for

some municipal transactions such as copy a residence registration through a multi-

purpose machine offered by the government sector. In addition, e-purse projects of the

private sectors will enhance the convenience of the cardholders such as they can buy

merchandise from 1,720 branches of 7-eleven through the e-purse.

-3-
 ACKNOWLEDGEMENTS

The Author would like to express my gratitude to all my colleagues at the

research and development department of TOT Corp, particularly, Mr. Sittiwach

Buasri for the suggestions on the writing and correcting, and also special thank to my

friends at ABAC. I also thank my bosses at TOT Corp for the morale support and the

support on the information about the case of e-purse in Thailand, which makes my

master project completely.

This report can not be completed without the knowledge from my professors

and teachers since I was young until now. The Author would like to express a special

thank to my advisor, Dr. Sudhiporn Pathumtaewapibal, Dean of School of

Engineering, ABAC, who got me recognize the benefits of the e-purse, and helped

mentoring me in my writing so that my work is informative and useful for me and the

readers. Another person I would like to thank is Dr. Kittiphan Techakittiroj, who is an

expert in smart card technology, and also gave me the advice when I had a problem.

My educational life would not be possible if there were a lack of vision of

education of my mom, who also encourages and supports into the process of life-long

education.

Mr.Kitti Pluktadachai

December 2004

-4-
 Table of Contents

Abstract……………………………………………………………..…………………3

Acknowledgements………………………………………..…………………………..4

Table of Contents……………………………………………………………..……….5

List of Figures……………………………………………….………………………...8

List of Tables……………………………………………………………….………...10

Chapter 1: Introduction………………………………………………………………11

1.1 Electronic Payment Basic………………………………………………...11

1.2 Thailand and Information Age………………………………………...…15

1.3 Objectives………………...……..…………………….………………….17

1.4 Scope of the Study…..……………..………………….………………….18

Chapter 2: E-Purse technologies ………………………………….…………………20

2.1 Introduction …………………………………….……….……………….20

2.2 The milestones of E-Purse based on smart card ……………….………...22

2.3 Smart Card Component……..……………………………………………25

2.4 Smart Card Specifications...……………………………………………...28

2.5 Classes of security based on Smart Card ………………………………..28

2.6 Smart Card Standards based on E-Purse Application………..…………..30

2.6.1 EN 1546 Standard………………………………………………….32

2.6.2 Common Electronic Purse Specification (CEPS) Standard………..34

2.6.3 EMV Standard……………………………………………………...43

2.7 Cryptology ……………………………………………………………….46

2.7.1 Symmetric Cryptographic Algorithms…..…………………………48

2.7.2 Asymmetric Cryptographic Algorithms...………………………….49

2.8 Conclusion………………………………………………………………..55

-5-
Chapter 3: Octopus Case Study………………………………………………………56

3.1 Introduction………………………. ……………………………………..56

3.2 Operation………………………………………………..………………..58

3.2.1 Reloading………….……………………….………….…………...59

3.2.2 Refund procedure………………………………….….……………60

3.2.3 Reporting Lost Cards………………………….….………..………61

3.2.4 Sale Locations……………………………………………………...61

3.2.5 Checking the amount remaining on the Octopus card……………..62

3.2.6 Tourist Services……………………………………………………62

3.3 Technology……………………….……………………….……………...63

3.4 Key Statistics……….…………….……………………….……………...65

3.5 The Hong Kong Monetary Authority (HKMA) Policy…………………..66

3.6 Conclusion………………………………………………………………..66

Chapter 4: Thailand Case Study..…………………………………….…..…………..68

4.1 Introduction……………...………………………………...……………..68

4.2 Case Study of Micro Cash Card.………………………..………………..68

4.2.1 Operation…………….………………………...…………………...68

4.2.2 Micro Cash Card Scheme..…………………………………………71

4.2.3 Key Statistics………...……………………………………………..71

4.3 Case Study of TOT Card…...………………………...…………………..73

4.3.1 Overview of TOT Card………………………..…………………...74

4.3.2 Operation…………………………………………………………...75

4.3.3 Technology…………………………………………………………77

4.3.4 Key Statistics……………………………………………………….84

4.4 Bank OF Thailand (BOT) Policy……….………….…………………….84

-6-
 4.5 Conclusion………………..………………………..……………………..84

Chapter 5: Conclusions and Recommendations….…………………..………………86

5.1 Conclusions..……………………...……………………….……………..86

5.2 Recommendations..….…………………………………….……………..88

References……………………………………………………………………………89

Appendix A: Review of Smart Card Technology

Appendix B: THAILAND Smart Card Standard Application Requirements

Version 1.0, Thailand Smart Card Working Group

Appendix C: Authorization of the issue of multi-purpose stored value cards,

The Hong Kong Monetary Authority (HKMA)

Appendix D: Policy Guidelines on Supervision of Electronic Money Services,

BANK OF THAILAND (BOT)

-7-
 List of Figures

Figure 1.1: Mobile Network for Mobile Payment……………………………………12

Figure 1.2: Revenue from payment services by type in 2003………………………..13

Figure 1.3: The number and growth rate of the credit cards in Thailand ……………14

Figure 1.4: Electronic-Purse System…………………………………………………17

Figure 2.1: Smart Card Applications…………………………………………………21

Figure 2.2: Contact Card Reader……………………………………………………..25

Figure 2.3: SAM Module…………………………………………………………….25

Figure 2.4: Terminal (Payphone and Balance Reader)………………………………26

Figure 2.5: PINpad…………………………………………………………………...27

Figure 2.6: Automated Teller Machine………………………………………………27

Figure 2.7: Public Telephone Services and Network requirement…………………...28

Figure 2.8: Components and connections of electronic purse system……………….33

Figure 2.9: The basic process of EN 1546 electronic purse transaction……………..34

Figure 2.10: Contact Location and Dimensions as defined in EMV Book 1………...42

Figure 2.11: POS Device Functional Components…………………………………..42

Figure 2.12: Layout of Contacts……………………………………………………...45

Figure 2.13: Principle of a symmetric cryptographic algorithm…………………….47

Figure 2.14: Classification chart for cryptographic techniques in Smart Cards……..48

Figure 2.15: Symmetric cryptosystem: sender and recipient share the same key…...48

Figure 2.16: Block cipher design used by DES……………………………………...50

Figure 2.17: Asymmetric cryptosystem……………………………………………...51

Figure 2.18: Encryption and decryption example with the RSA algorithm…………53

Figure 2.19: Certification Authority…………………………………………………54

-8-
 List of Figures

Figure 3.1: Card Types and Price…………………………………………………….58

Figure 3.2: How to use Octopus……………………………………………………...59

Figure 3.3: Where to use Octopus……………………………………………………59

Figure 3.4: Automatic Add-Value Service (AAVS)…………………………………60

Figure 3.5: Contactless Operation……………………………………………………63

Figure 3.6: The wristwatch module designed by Sony………………………………64

Figure 3.7: Octopus watches, Octo-phone, HP watch key chains……………………65

Figure 3.8: System Layout…………………………………………………………...66

Figure 4.1: Micro Cash Card Scheme………………………………………………..71

Figure 4.2: Micro Cash Card Total Sale Volume…………………………………….71

Figure 4.3: Total Loading and Payment Volume…………………………………….72

Figure 4.4 TOT Card and Public Telephone…………………………………………75

Figure 4.5: TOT Card Payphone System…………………………………………….78

Figure 4.6: Payphone Management System………………………………………….79

Figure 4.7: Clearing System Architecture……………………………………………79

Figure 4.8: System Architecture……………………………………………………...80

Figure 4.9: TOT Card for visually impaired…………………………………………81

Figure 4.10: Secure Application Module (SAM)…………………………………….82

Figure 4.11: Multi-Operator System (TOT Card)……………………………………83

Figure 4.12: TOT Card Architecture...……………………………………………….83

-9-
 List of Tables

Table 2.1: Some examples of smart card specification………………………………29

Table 2.2: mapping among Common Criteria, TCSEC, and ITSEC………………...30

Table 2.3: Specific commands for electronic purses as defined in EN 1546………...33

Table 2.4: Classes of Operation……………………………………………………...44

Table 4.1: Micro Cash Card Service Provider……………………………………….69

- 10 -
 Chapter 1: Introduction

1.1 Electronic Payment Basic

An electronic payment, or “e-payment,” is the means for transferring the fund

from a payer to the payee through the use of an electronic payment instrument. An

electronic payment instrument is an instrument where the forms of payment are

represented electronically, and the ownership of the means of payment is changed by

means of electronic. An electronic payment instrument, as defined by the paper of

Bank Of Thailand (BOT) policy towards e-payment1 including: mobile payments,

Internet payments, and card payments.

Most mobile payments follow a simple model where the customer (the payer)

first identifies to the merchant by providing his or her telephone number or by calling

the merchant. The merchant then forwards the payment and the customer information

to the payment service provider. The service provider then presents the payment

information to the payer for confirmation and upon confirmation (e.g. with a PIN

number) records the transaction. The communication between the customer and the

payment provider and/or merchant can take place through phone calls or short

messages services (SMS). The paid amount is collected by direct debit from the

payer’s account and credited to the beneficiary’s account of the merchant.

The mobile payment requires hardware, software and networks. The major

components of mobile device consist of mobile phones, attachable keyboard, and

personal digital assistants (PDAs). The software required for the mobile devices

includes an operating system and the application software. Simbian, Microsoft, or

PalmOS are some operating systems for mobile devices. Some application software is

Sim Tools Kit (STK) or Java application.

1
http://www.cdg.co.th/cdg36years/html/Slizes/MR2/MR25.pdf

- 11 -
 The major components of mobile networks are shown in Figure 1.1. The

reader can study further in the mobile textbook for more details.

PSTN

MSC/VLR GMSC
ISDN

BSC SMS-SC

BT Internet
Intranet
Mobile
PSPDN

Figure 1.1: Mobile Network for Mobile Payment

Internet payment can play a role in the electronic commerce (e-commerce),

since most e-commerce transactions are carried out over the Internet, and cover all

types of business. E-commerce transactions can be carried out in various forms such

as business-to-business (B2B), collaborative commerce (c-commerce), business-to-

consumer (B2C), consumer-to-business (C2B), consumer-to-consumer (C2C), and

government-to-citizens (G2C). A major issue about the Internet payment is the lack of

standard and sufficiently secure protocol for payment across open networks. There are

many secure protocols currently in use for the Internet payment, such as Secure

Socket Layer (SSL), Secure Electronic Transaction (SET), 3D-SET, 3D-Secure and

UCAF/SPA. Since the differences in strategies among the card schemes have resulted

in the development of alternative standard solutions, 3D-SET is offered by both

MasterCard and Visa as an upgrade to SET implementations. Visa offer 3D-Secure,

while MasterCard offers UCAF/SPA (Universal Cardholder Authentication

Field/Secure Payment Application). 3D-Secure provides the issuer with a piece of

evidence of authentication of a cardholder. UCAF/SPA works with the cardholder in a

- 12 -
different approach. UCAF/SPA requires the cardholder to have some devices for

authentication. The essential difference between 3D-Secure and UCAF/SPA is that

3D-Secure minimizes the impact on the cardholders, while UCAF/SPA minimizes the

impact on the merchants. ATM cards, credit cards, debit cards, and store value cards

are some card-based payment instruments. Figure 1.2 shows that ATM and credit

cards payment services were among the top revenue generators in the year 2003.

Figure 1.2: Revenue from payment services by type in 2003 1

Credit cards (referred to as pay-later card products) are typically used for

higher value or infrequent payments, and are often used in the fashion outlets, and

electrical and department stores, as well as more recently for paying utility bills.

Based on the figures in 1999 from Visa International and MasterCard International, an

average credit card carried out around 20 transactions per annum at an average value

of US$90. The number and growth rate of the credit cards in Thailand is shown in

Figure 1.3. Debit cards (referred to as pay-now card products) are typically used for

medium value or regular payments, and are often used in supermarkets, gas stations,

and food stores. This type of card is popular amongst the people who are unable to

- 13 -
acquire a credit card. An average debit card carries out around 45 transactions per

annum at an average value of US$50.

Figure 1.3: The number and growth rate of the credit cards in Thailand 1

Stored value cards or electronic purse (referred to as pay-before card

products) are typically used for lower value or fast payments, and are used often on

payphones, vending machines, transit system, and convenient outlets, as well as in a

closed environments such as on campus or in a food court. The average transaction is

between US$3 and US$10, with around 20 to 40 transactions carried out per annum

per card.

Despite a variety of e-payment instruments as discussed above, this paper will

explore only the stored value cards or electronic purse, since there are many evidences

in Thailand that suggest a high growth of e-purse application, among which are:

- The 30 million TOT Cards2 that TOT Corp called for a bid to produce in the

year 2002
2
Kasem Boonkhantinat, “A Cost-Benefit Analysis of the Smart Card Reader/Writer
Producing Project A Case Study of Intel Card Industries Co., Ltd.”, 2002

- 14 -
 - The national smart ID cards for the Thai people. 12 million will be issued by

October 2004, which may boost the use of e-commerce and may be upgraded

to a reloadable type of e-purse application in the future.

- The cooperation among CP Seven-Eleven, True Corp, KTC, Krung Thai

Bank, GSB Bank, Bank of Ayudhya, Siam City Bank, Sahawiriya OA,

Loxley and Visa are looking to provide e-purse application at the 1,720

branches of 7-eleven in the end of 2004.

1.2 Thailand and Information Age

Nowadays, Thailand has fully entered the Information Age. A piece of

evidence that reinforces such statement is the establishment of the Ministry of

Information and Communication Technology (MICT) to supervise the policy related

to the information technology. Another evidence is the privatization of the Telephone

Organization of Thailand, which is now under the new name TOT Corporation Public

Company Limited (TOT Corp). In the year 2004, all the telecommunication

regulating duties will be in the hand of the National Telecommunications Commission

(NTC). It can be seen that there has been a rapid change in the technology and

regulation. In addition, the convergence of the telecommunication and financial

worlds is going to be a reality in the near future, which will lead to the development

of the e-commerce.

The economic crisis that struck Thailand in the year 1997 slowed down the

development of the e-commerce in the country. At that time, many projects were short

of investment funds, some even stopped the service, among which was Micro Cash

Card by Bangkok Payment Technology Co., Ltd (BPT). The Project would have

allowed the people to pay for goods and services, such as movie ticket, restaurant, or

bus, by the Micro Cash Card. The Micro Cash Card was launched in the end of 1996,

- 15 -
and came to an end in 2002, with 50,000 cards sold. However, the Thai people will

start to have the electronic citizen ID card in the year 2004. This new national ID card

(smart card) is issued by the Department of Provincial Administration, Ministry of

Interior, which may be favorable for the transaction conducting in the future. The

smart card will play a major role in the use of information technology, as Thai citizens

will be more accustomed to this technology, which helps accelerating the growth of

e-commerce.

Electronic-Purse (E-Purse) card is a type of service available on the smart card.

E-Purse card is useful in buying or selling products or services that are low in

transaction values. The applications may include buying goods in a convenient store.

Normally, the convenient store must calculate and count the change, and make

sure the change is correct, which sometimes requires double or even triple rechecks.

The problem arising is the delay in customer service, besides carrying cash is at risk

of being robbed. Therefore, the use of the cash card will solve most of the problems

quite dramatically, in addition to a faster service given to the customers. Another

benefit of the e-purse is that the store can launch the marketing promotion campaign

to strengthen the loyalty of the customer more easily. Instead of giving a stamp or

coupon, the premium can be credited back directly into the smart card. In addition, the

e-purse can be helpful in recording the customers’ names onto the database in order to

offer some sale promotions such as discount, etc.

The players in the e-purse system consist of the card issuer, cardholder, store

or vendor, and the financial institution. The interrelationship among those players in

terms of cash and e-purse is shown in Figure 1.4. In Thailand, the e-purse available

now is both the disposable and reloadable types. The public telephone services (TOT

Card) serviced by TOT Corp, which has been used successful so far of disposable

- 16 -
type. Currently, TOT Corp has installed over 100,000 TOT card along the nationwide.

Consequently, the outstanding of some e-purse application has been overview

above, led to study the development of the evolution of e-purse in Thailand in this

report, regarding the technology overview, security and standard related to e-purse.

Some cases related to the e-purse service in Thailand and Hong Kong are mentioned

and analyzed for the obstacles and the success factors of the e-purse services.

Figure 1.4: Electronic-Purse System

1.3 Objectives

• To study the characteristics of the e-payment systems

• To study the technology, encryption, and standards relevant to the e-purse

• To study the case of Hong Kong, which employs the contactless smart card

• To study the situation in Thailand, which employs the contacted smart card

• To analyze the obstacles and the success factors of the e-purse services

- 17 -
1.4 Scope of the Study

Chapter 2 presents the history and technology of the e-purse including

symmetric and asymmetric encryption. The standards that will be mentioned in

Chapter 2 are the physical specification of the card in connection with the

International Standard Organization (ISO) and EN 1546 standard of the Comité

Européen de Normalisation (CEN). CEN was founded by the European Commission

in 1990 to set up the European standard for multi-sector e-purse system. CEPS

(Common Electronic Purse Specifications) standard developed by CEPSCO, LLC was

published in 2000. EMV standard was developed in collaboration between EuroPay

MasterCard and VISA. The standard EMV 2000 Version 4.0 was published around

the end of 2000. While the standard EMV Version 4.1 was published on May 2004,

which allowed for the maximum benefits from using the smart card applications.

Chapter 3 explores the case study of e-purse application in Hong Kong,

including the technology, services, locations that offer card services and loading from

Octopus Cards Limited, and the government’s policy.

Chapter 4 presents some real cases of e-purse uses such as Micro Cash Card

from BPT Company, which was used at the EGV movie theaters, Black Canyon

restaurants, Dok Ya book stores, Micro Bus, and St. Francis-Xavier School. Another

case in Thailand is the payphone card (TOT Card) from TOT Corp, which is a success

story as evidenced by the total sale of card in 2003 about 400 million baht and many

chipcard payphone units were installed nationwide. Thailand Smart Card Standard

that will be mentioned in appendix B for the reader who wish to attend. This Chapter

ends with a review of the policy of electronic money services was issued by Bank Of

Thailand in the year 2004.

- 18 -
 Chapter 5 summarizes the factors that leads to success and failure, and

mentions some obstacles to the services, which are drawn from the studied cases for

both disposable and reloadable types, including some comments for further

development of e-purse application.

Appendix A presents a variety of smart cards, smart card application, smart

card operating system including some e-purse application with java program, and

smart card status based on e-purse application.

Appendix B concerns with the committee established in 1998 to develop the

Thai national standard and the standard itself (called Thailand Smart Card Standard

Application Requirement Version 1.0), which was published in 1999.

Appendix C reviews the authorization of the issue of multi-purpose stored

value cards by the Hong Kong Monetary Authority (HKMA) in relation to the

regulation and supervision of banking business and the business of taking deposits.

Appendix D presents the policy guidelines on supervision of electronic money

services in which BANK OF THAILAND (BOT) has been using as the supervising

policy on e-purse services since February 10, 2004.

- 19 -
 Chapter 2: E-Purse Technologies

2.1 Introduction

With the advent of the cashless society in the modern world, the use of cash

and coins as the payment instruments is diminishing. Such electronic money can take

many forms, and has been endowed with a wide and misleading vocabulary including

stored value and e-purse. This misconception has led a number of financial

institutions to develop the smart card-based products that perform stored-value

functions, ranging from the simple throw-away, disposable cards such as payphone

cards, to reloadable e-purse cards designed for low-value transactions conducted on a

variety of outlets over the networks.

Electronic money (e-money) is a currency system where the electronic value is

purchased by the consumer, and refers to a whole range of electronic payment

methods including e-cash, credit (pay later), debit (pay now), and the newest product

dedicated to electronic payment, namely, electronic-purse (pay before). Electronic

purse (e-purse) is a small and portable device that contains the e-money, similar to a

real-world purse or wallet that contains the real money. E-purse can be of either

disposable or re-loadable type. The best medium for the e-purse is the smartcard.

A smartcard can be programmed to be a payment medium for services and

goods. In effect, a smartcard can become an “e-purse,“ being capable of paying for

everything from fast food to road toll charges. This scenario is already seen in Hong

Kong, where Octopus cards can be used at car parks, photobooths, vending machines,

public swimming pools, and recreational centers. Many retailers and food outlets take

the Octopus card. Moreover, the microchip in the smartcard does not have to sit on

the well-familiar flat, rectangular plastic substrate. The chip can also be built into a

- 20 -
watch or jewelry, as express in Chapter 3. Even the smartcard that many people are

carrying the SIM card on a mobile phone can take on the function of e-purse

application. Sometime in 2004, the Thai citizens in the southern region will be using

the national smart ID card, which has 32 Kb of memory for data storage and security

with the user's digitized fingerprints for biometric identification.

The winning model of Smart Card design contest,

organized by the ministry of ICT, in 2004

Figure 2.1: Smart Card Applications

This chapter provides the prerequisite for the E-Purse system based on smart

card. First, a historical milestone about the e-purse starting from the first patent of

smart card in 1970 until the regulation of EMV standard in some continents is

reviewed. Second, the technology for smart card is reviewed, which lays down the

knowledge on the card technology, such as smart card components, smart card

specification, and class of security. Finally, more technical aspects of the standard and

security of the electronic purse application are discussed. A variety of smart cards,

smart card operating system, smart card application, smart card status based on

e-purse application, which are the basic knowledge, will be explained in appendix A.

- 21 -
2.2 The milestones of E-Purse based on smart card

The roots of the current day smartcard can be traced back to the US in the

early 1950s when Diners Club produced the first all-plastic card to be used for

payment applications. The synthetic material PVC was used, which allowed for

longer-lasting cards than previously conventional paper-based cards.

In 1970 a Japanese inventor, Kunitaka Arimura, filed the first patent for what

is now called a smart card. His patent was restricted to Japan and the technical aspects

of the invention only. The Japanese cards are manufactured under an Arimura’s

license.

Between 1974 and 1976 in France, Roland Moreno successfully patented

several functional aspects of the smart card and sold licenses to Bull and the others.

However, the great breakthrough was achieved in 1984, when the French PTT (postal

and telecommunications services) successfully carried out a field trial of smart cards

for the telephone. In this field trial, the smart cards immediately proved to meet all

expectations with regard to protection against tampering and high reliability.

In September 1992, Danmont Stored Value Card (SVC) system began its

operation in Denmark, allowing consumers to use an SVC in place of cash and other

payment vehicles in the participating merchant locations. This piloting of the SVC

system was one of many systems around the world that began to emerge.

The important milestone of the future worldwide use of the smart card for

financial transactions is the completion of the EMV specification, which is the

product from the joint effort among Europay, MasterCard, and Visa. The first version

of this specification was published in 1994.

- 22 -
 Even in the USA, where smart cards systems have so far hardly taken root, a

smart card purse system was tried out by Visa during the 1996 Olympic Summer

Games in Atlanta.

In Thailand, Micro Cash Card project was launched by BPT Co., Ltd. in 1996,

and the chip card public payphone that was developed by Telephone Organization of

Thailand for use with the TOT Card was launched in 1998.

The Common Electronic Purse Specifications (CEPS) defines the

requirements of the components if the implementation of a globally interoperable

electronic purse program is to be done, while maintaining a full accountability and

auditability. CEPS, which were made available in March 1999, outlines the overall

system security, certification, and migration. CEPS have paved the way for the

creation of an open, de facto, and global electronic purse standard.

Thailand’s Smart Card Working Group was formed in April 1999, by the

commencement of the National Electronics and Computer Technology Center

(NECTEC), to develop the smart card standard application requirements for Thailand.

The primary purpose of these smart card standard requirements is to ensure the

interoperability between the products from different manufacturers and application

vendors.

EMV 4.0 or EMV 2000 was published in December 2000 to clarify and

enhance the original specifications, as well as adding some new guidelines for recent

developments such as low-voltage smart cards and cards with faster chip clock speed.

In 2003, the Royal Thai Cabinet approved of the introduction of the smartcard

citizen ID system. The Bureau of Registration Administration will issue the national

ID cards to the 61 million Thai citizens.

- 23 -
 To accelerate the adoption of the EMV specifications, a number of mandates

have been issued by various card associations. In addition, card associations in most

regions are offering significant financial incentives, such as reductions of standard

interchange rate to retailers that upgrade their terminals to accommodate the chip

cards.

For instance, in the Asia-Pacific region, Visa now requires that all new stand-

alone POS terminals and ATMs be EMV-compliant. Liability for fraud losses, which

could be prevented under EMV guidelines, will be shifted to the acquiring banks.

Visa EU, which guides financial institutions in Western Europe, has declared

that all new smart card payment devices be EMV-compliant by January 1, 2005. The

acquiring banks not supporting EMV transactions could be subjected to financial

penalties after that time. Visa CEMEA, which oversees Central and Eastern Europe,

the Middle East, and Africa has also mandated that all new chip card terminals and

card readers be EMV-compliant. Starting January 1, 2006, the financial liability for

losses due to fraud in the CEMEA region will be shifted from the card issuers to the

banks that have not implemented EMV. Visa International estimated that more than

70 million Visa EMV smart cards will have been issued by the end of 2002.

In addition, MasterCard has set a variety of conversion deadlines for various

regions of the world after which any bank that issues the smart cards or acquires

transactions will assume a full financial liability for fraud or other losses that could

have been avoided by using an EMV compliant smart card solution.3

_____________________________________________
3
http://www.verifone.com/pdf/EMV_white_paper.pdf

“EMV: Global Framework for Smart Card Payments-2003”

- 24 -
2.3 Smart Card Component

Contacts Card Reader

The card reader for a standard contact card consists of six to eight sliding or

landing contacts. The major drawbacks of the sliding type are the scratch on the card

when the card is inserted into the card reader and the wrong feeding voltages to the

other contacts while removing the card. Landing contacts are preferred, since the

contacts only require a small area for landing their contact onto the card. (Figure 2.2)

Figure 2.2: Contact Card Reader Figure 2.3: SAM Module

Security Module

To ensure the security of the whole system, a roof hole can not be allowed at

any points. So, the keys must be stored securely within a security application module

(SAM) to prevent the criminal crack of the keys. The other benefit of having the

security module is in authentication. When the card is inserted into the terminal, the

authentication process between the terminal and card is initiated to verify each other,

as shown in Figure 2.3.

- 25 -
Terminal

The card reader will be integrated into the terminal to perform several

functions. For example, public telephone service requires the payphone terminal to

accept the card, while the balance reader is used to serve the customers at a

department store.

Figure 2.4: Terminal (Payphone and Balance Reader)

PINpad

A PINpad is a small handheld terminal consisting of a keypad, display, and a

card reader. The clients have to present their PIN to verify the cardholder via a

PINpad terminal. The PIN must be encrypted when transmitted from the PINpad

terminal to the card to avoid pin duplication. (Figure 2.5)

- 26 -
 Figure 2.5: PINpad Figure 2.6: Automated Teller Machine

Automated Teller Machine (ATM)

The current automated teller machine (ATM) which uses the magnetic stripe

card will be migrated to using the smart card in the future to conform with the EMV

standard. In general, all ATMs are motorized to prevent a fraud due to the natural

low-security of the magnetic stripe card itself. During the introductory phase of the

e-purse application, ATM will be used for loading the electronic money from a bank

account and charging onto the smart card. (Figure 2.6)

Network

Smart card applications require several parts to be engaged such as the

management system and trusted third parties. The management system is engaged

right from the start of the smart card project up to the launch of the cards and finally

to system maintenance. For example, the key management system is used for

personalizing, and the payphone management system is used in payphone

maintenance. Clearing-house is a form of the trusted third parties in public telephone

services used for clearing the revenues to each payphone operator. (Figure 2.7)

- 27 -
 Figure 2.7: Public Telephone Services and Network requirement

2.4: Smart Card specifications

Table 2.1 shows some smart card specifications for some examples of

different applications. Some applications require 8-bit CPU with dual interface, such

as ticketing and payment, while some applications require 32-bit RISC for multi

application with Java Card.

2.5: Classes of security based on Smart Card 4

There is a group of standard that grade security products and systems or target

of evaluation (TOE) according to the level of security they aim to provide and set a

mechanism for testing products against their stated aims. The outstanding classes of

security based on smart card consisted of:

• The Trusted Computer System Evaluation Criteria (TCSEC), used in

the United States;

• The Information Technology Security Evaluation and Certification

scheme (ITSEC), used in Europe.

___________________________________________________
4
Smart Card Security and Applications 2nd Edition, MIKE HENDRY

- 28 -
 Crypto Other

Manufacturer Card Application Processor Memory Function Security

Telephone 221-Bit Eurochip Decrement-

SIEMENS SLE4436 (TOT Card) 8-bit EEPROM Functions Only counter

COMP128, ITSEC E4;

Cyblerflex GSM SIM 8-bit 8KB A5/1 (GSM Java Card

Schlumberger
SIM Card Phase2 E2Prom Algorithm) Authentication

Dual – 64 KB ROM 3DES Co- Multiple

MiFare Interface for 8-bit 2.3 KB RAM Processors; Sensor &

Philips Prox Ticketing & 16 KB 32-bit for Security

Payment (E2Prom) RSA, DSS Barriers;

128KB ROM Crypto for Active security

V-way32 Multiapplica- 32-bit 3 KB RAM RSA, Circuits, DPA

NEC tion JavaCard RISC 32 KB DSA, Shield

E2Prom DSS

Java On-chip clock

ST Micro- SmartJ Multiapplica- 32-bit 8-128 KB bytecode Generation,

Electronics tion JavaCard RISC E2Prom And public- DPA

Key Protection, etc.

Table 2.1: Some examples of smart card specification 4

The two standard are comparable but not identical. TCSEC grades products

from D (the lowest level) to A1 (the highest) according to the level of security. Under

ITSEC, product and their documentation are assessed by a commercial licensed

evaluation facility (CLEF) using criteria form correctness and effectiveness; they are

given a rating from E0 (inadequate assurance) to E6 (the highest level). For rating of

E4 and above, formal models and design process must be used. Both ITSEC and

TCSEC are now being superseded by the Common Criteria for IT Security

Evaluation, also published as ISO 15408. The development of the Common Criteria

- 29 -
(CC) was a joint project involving security organizations in the United States, Canada,

France, Germany, the Netherlands, and the United Kingdom, as well as the

International Organization for Standardization (ISO). The CC use a combination of

evaluation assurance levels (EAL) and strength of functions (SF), which can be

mapped onto ITSEC or TCSEC (Table 2.2), and exact mapping do not exist. A set of

protection profiles for a smart card IC has been developed by the main European chip

manufactures (see www.eurosmart.com) by using the CC. This protection profile

covers two main features: the integrity and confidentiality of the data on the card and

the security-enabling features, especially memory management.

Common European
US TCSEC
Criteria ITSEC
- D: Minimal Protection E0
EAL 1 - -
EAL 2 C1: Discretionary Security Protection E1
EAL 3 C2: Controlled Access Protection E2
EAL 4 B1: Labeled Security Protection E3
EAL 5 B2: Structured Protection E4
EAL 6 B3: Security Domains E5
EAL 7 A1: Verified Design E6

Table 2.2: mapping among Common Criteria, TCSEC, and ITSEC 5

2.6: Smart Card Standards based on E-Purse Application

In this chapter will be mentioned only EN 1546, CEPS, and EMV standards in

more detailed about e-purse application. Moreover, it is necessary to give the

overview of smart card standards to the reader for further study about smart card

beside this project.

5
http://www.commoncriteriaportal.org

- 30 -
The standards based on smart card that the reader should know is:

• ISO 7816: This set of standard is a logical development from ISO 7810-7813,

which covers magnetic-stripe cards used in banking and financial applications.

ISO 7816 defines a contact card containing a microprocessor that can be used

as a direct replacement for a bank card.

• EN 1546 (Identification card systems): Intersector electronic purse.

A development from EN726 and EN 1038, but with banking industry as well

as telecommunications industry involvement.

• CEPS: Common Electronic Purse Specifications: A set of business

requirements, technical and commercial specification covering interoperability

of purse cards. This standard is issued and maintained by CEPSCo LLC.

(www.cepsco.com)

• EMV: Europay, MasterCard, and Visa integrated circuit card specification for

payment systems. The EMV standards define the content, structure and

programming of chip-based payment card. The EMV specification is now

owned and maintained by EMVCo. (www.emvco.com)

• ETSI: The European Telecommunications Standards Institute has been

responsible for a set of standards that covers smart cards for use in public and

cellular telephone systems.

• PC/SC and OCF: These specifications have been developed to enable PC

Programmers to access data on smart cards within PC operating systems.

___________________________________________________
6
Smart Card Handbook 2nd Edition, W.Rankl & W.Effing 2000

- 31 -
2.6.1 EN 1546 Standard 6

The European Commission decided in 1990 to produce a European Standard

for a multi-sector electronic purse system. The CEN EN 1546 standard for electronic

purse systems is titled ‘Inter-sector Electronic Purse’ and consists of four parts. The

first part, ‘Concept and structure’, this document defines and explains all the logical

components and their interconnections. The second part, uses the basic concept in

the first part to explain the security architecture for both the overall system and its

individual components. The third part, ‘Data elements and interchanges’, contains

the descriptions and definitions of the data elements needed for the e-purse system.

The final part describes the state machines and the states of the devices used.

The EN 1546 standard regard to actual implementation as a framework rather

than a detailed specification. So, it possible for two different systems to be compliant

with EN 1546 standard but mutually incompatible, such as the different cryptographic

algorithms between two systems.

There are five participants for the basic structure of an inter-sector electronic

purse (IEP) system according to EN 1546 standard, as shown in Figure 2.8. The

purse provider has the overall responsibility for the system. The purse holder is the

purse user or cardholder who makes payments by using their e-purse application in

the card to receive goods or services. The service provider provides goods or

services that are accepted by the cardholder. While the acquirer responsible for

setting up and managing the data links between the purse issuer and the service

providers. Finally, the load agent is the counterpart to the service provider, since the

load agent can re-load the e-purse in exchange for a payment. These five participants

may not require real persons or companies, but real technical components are

allocated to each of them, distributed according to their security.

- 32 -
Figure 2.8: Components and connections of electronic purse system according to
EN1546. The components with a single outline are not secure, while those with a
double outline are secure.

Commands

There are eight different commands in essence, of which three belong to the

ISO/IEC 7816-4 standard: SELECT FILE, READ BINARY AND READ RECORD.

These are used to select the e-purse application, and subsequently to read various data

from the purse files as necessary. All purse commands directly access data elements

in the purse files for both reading and writing. EN 1546 defines the command listed in

Table 2.3 and specifies their internal functions in detail.

Table 2.3: Specific commands for electronic purses as defined in EN 1546

- 33 -
Cryptographic algorithms

The entire security of the system is based on a cryptographic algorithm. The

messages exchanges between the components all have an appended signature, so that

manipulation can be detected. The symmetric DES algorithm is currently used and the

standard allows asymmetric algorithms such as RSA for authentication in the system.

Processes

The standard does not concern about files, commands and states; it also

describes and explains the related processes; such as loading, paying, canceling a

payment, or converting currencies. Each process consists of three phases. In the first

phase, initialization of the participating components. The second phase provides the

actual execution of the function involved. The third phase, which is optional, is used

to confirm the previous actions, as depicted in Figure 2.9.

Figure 2.9: The basic process of EN 1546 electronic purse transaction (phase 1 and 2)

2.6.2 Common Electronic Purse Specification (CEPS) Standard 7

The Common Electronic Purse Specifications (CEPS) define requirements for

all components needed by an organization to implement a globally interoperable

electronic purse program, while maintaining full accountability and auditability.

CEPS, which were made available in March of 1999, outline overall system security,

- 34 -
certification and migration. Interoperability is an essential feature of a payment card

and will help bolster electronic purse card usage. The proliferation of electronic purse

programs has resulted in many non-interoperable, proprietary systems. The need for

scaleable solutions, international usage and cost-effective ways of implementing

programs has highlighted the importance of a globally interoperable set of electronic

purse specifications.

CEPS requires compatibility with the EMV (Europay MasterCard Visa)

specifications for smart cards and defines the requirements for an interoperable card

application, the card-to-terminal interface, the terminal application for point-of-sale

and load transactions, data elements, and recommended message formats for

transaction processing. CEPS also provides functional requirements for electronic

purse scheme participants and uses public key cryptography for enhanced security.

CEPS builds on the EMV foundation by extending global interoperability to

electronic purse schemes worldwide and is committed to its global proliferation.

In October 1999 the CEPSCO, LLC was officially incorporated. It is

responsible for managing and licensing the specifications, determining certification

requirements, establishing a CEPS approval authority, promoting CEPS as a

worldwide open electronic purse standard, and establishing working groups to

integrate enhancements. The shareholders of CEPSCO include CEPSCO Española

A.I.E., EURO Kartensysteme, Europay International and Visa International. In July

2000, Groupement des Cartes Bancaires and Proton World International joined

CEPSCO, LLC. CEPS, a comprehensive set of specifications that enables domestic

and international interoperability for electronic purse programs worldwide:

7
http://www.cepsco.com

- 35 -
 - Functional Requirement available in September of 1999

- Business Requirement available in March of 2000

- Technical Specification available update in March of 2001

Functional Requirement

The functional requirement document is structured to explain the functionality

needed for an interoperable e-purse product and to define the requirements to offer

and operate such a product throughout the world. In this paper will mention about

roles and responsibilities, security requirements, and POS transaction requirements

especial POS device to guiding the reader about functional requirement document.

Roles and responsibilities define a specific functional requirements for each

of the following participants (scheme provider, certification authority, card issuer,

fund issuer, card holder, load acquirer, merchant, merchant acquirer and processor) in

a CEP transaction. All of the participants are required to conform to the CEP

specifications. Some of the participant functions may make the reader get confuse, in

this paper just review some participants for the reader to better understanding.

The merchant acquirer is the entity responsible for establishing a business

relationship with one or more common electronic purse scheme providers to process

POS transactions, and settle POS transactions. The merchant acquirer is the

organization responsible for the provision and distribution of Purchase Secure

Application Modules (PSAMs) that interact with terminals for conducting

transactions at the point of sale. The merchant acquirer is responsible for making

necessary system changes, developing marketing plans, and managing merchant

relationships. The merchant acquirer is the organization that collects transactions from

POS devices for delivery to one or more card issuers. Merchant acquirers are

responsible for paying merchants for electronic purse transaction values and must be

- 36 -
able to effect settlement for POS transactions that have occurred at their merchant

sites. Although transactions may flow directly from a merchant acquirer to a card

issuer, sometimes the transactions must be processed by a processor to connecting

the merchant acquirer and the card issuer and between the load acquirer and the card

issuer.

Security requirements are the essence part that the reader should reviews,

this paper will brief an overview of key and security mechanisms. The CEP security

system must satisfy the following requirements:

• The card issuer must be able to verify that genuine cards, produced by

or on behalf of the card issuer, performed all of the transactions

received.

• The merchant acquirer must be able to verify that POS devices under

control of the merchant acquirer conducted all POS transactions

received.

• The merchant acquirer must be able to ensure that purchase

transactions have not been canceled without the merchant acquirer

receiving the cancellation transaction information.

Key and security mechanisms will mentioned about authentication method,

either on-line or offline CEPS transaction. On-line authentication must take place

between the card issuer and the CEP card for load, unload, and currency exchange

transactions. The card issuer and the CEP card share a secret key to generate and

verify MACs. Off-line authentication must take place between a PSAM in the POS

device and the CEP card for purchase and cancel last purchase transactions. The card

and the PSAM must use a public key algorithm for mutual authentication and session

- 37 -
key exchange, as no permanent shared secret key may exist between the CEP card and

the PSAM. RSA is the public key algorithm chosen for CEPS.

The Point of Sale or Point of Service (POS) device must contain at least a

card acceptance device (CAD) and secure hardware for storing and processing data

used to authenticate processing. This secure hardware is called a Purchase Secure

Application Module (PSAM). The PSAM must contain at least the CA public RSA

key, the PSAM’s private RSA key and optionally the certificates that the POS device

uses to perform mutual authentication with the CEP card.

Business Requirement

The objective of this document is to define the business requirements for an

open, common, interoperable electronic purse environment. It is the source for the

functional requirements and technical specifications. The functional requirements

document will follow publication of these business requirements and will include

more details of the product and systems functionality. In this paper will explores

about security requirement, card requirement and POS requirement to brief the basic

concept for the reader study further in the standard.

Security requirements for the common specification must allow the product

to be capable of existing within a multi-applications environment, compatible with

other certified applications. Authentication is Two-way, or mutual, authentication,

where the card authenticates the terminal and the terminal authenticates the card for

each transaction, must be performed for off-line transactions. However, cryptography

for increased security and convenience, asymmetric cryptography must be used as the

authentication security for off-line transactions. Using asymmetric cryptography will

enable the exchange of authenticated messages and secret data without exchanging

the secrets needed for performing authentication. Symmetric key cryptography is

- 38 -
used for online transactions and to protect the integrity of data by generating message

authentication codes (MAC).

Card requirements for the Common Electronic Purse Specifications will

enable cardholders to use the electronic purse card domestically and internationally in

a similar manner. However, an Issuer may choose to limit the use of a CEPS based

product, or the use of a function, to a given country or region. The following are the

card application requirements:

• Must be able to be authenticated at a load device by the Issuer and POS

terminal by the PSAM.

• Must require a form of cardholder identification for electronic value

load from accounts in both a proprietary environment and a shared

network environment unless loading from cash.

• Must support on-line PIN verification.

• Must support at least one type of off-line PIN verification (encrypted

or plaintext), as defined by the issuer.

• Must support purchase reversal transactions.

Types of Cards

• The Common Electronic Purse Specifications must be supported on

single application cards and on multi-application cards.

• The Common Electronic Purse Specifications will not be supported on

disposable cards.

POS requirement concerns about the consumers must be able to use their

cards in a similar manner at any purchase terminal. Purchase and purchase reversal,

incremental purchase, and cancel last purchase transactions must be processed off-line.

- 39 -
In this paper will focus about the terminal requirements, purchase reversal

transactions and cancel last purchase transactions.

Terminal Requirements

• Terminals must have safe memory (non-volatile or battery-backed).

• Terminals must be EMV compatible.

• Terminals must contain a PSAM, which must support a unique PSAM

identifier.

Purchase Reversal Transactions

A purchase transaction may occasionally not be fully completed. One cause

might be a communications interruption. Another example is that of a vending

machine which accepts an amount for purchase and decrements the purse, but then

determines that the requested item is out of stock. The vending machine would use a

purchase reversal transaction to restore value to the card.

• A purchase reversal transaction is considered to be one and the same

transaction with the original purchase transaction that it is reversing.

• A purchase reversal transaction must be accomplished prior to the

card being removed from the terminal.

Cancel Last Purchase Transaction

A customer or merchant may notice that the amount of sale was incorrectly

keyed after the customer has removed his or her card from the terminal. Or, the

customer may wish to return merchandise to the merchant. A cancel last purchase

transaction increments the card’s balance to accommodate this. Support of cancel last

purchase is optional for merchants and issuers. Cancel last purchase transactions may

be used only within the limits listed below:

- 40 -
 • Cancel last purchase must be performed at the same terminal on which

the purchase transaction was performed.

• Cards that support cancel last purchase transactions must allow only

the last transaction on the card’s log to be reversed.

• Cancel last purchase transactions must be for the same amount as the

last transaction logged on the card.

• Cancel last purchase transactions must be performed prior to sending

purchase transactions in for settlement.

Technical Specification

Technical specification is a refinement of the CEP business requirements and

the CEP functional requirements. The purpose of the technical specifications is to

provide the specifications necessary to achieve interoperability between the entities

and components of a Common Electronic Purse (CEP) system. This paper provides

the minimum technical specifications about CEP card and POS device. The Common

Electronic Purse (CEP) application must be implemented only in cards that comply

with EMV Book 1, as shown in Figure 2.10. The CEP card must support

transmission protocol either T=0 or T=1 as described in EMV.

POS Devices may operate in both attended and unattended environments. In

an attended environment, a third party, for example, a clerk at a cash register in a

store, enters data for the CEP transaction. In an unattended environment, for example,

a vending machine, or a home computer, the CEP transaction is automated for the

cardholder. The POS device has a collection interface to the merchant acquirer using

agreed upon message formats and communications protocols.

- 41 -
 Figure 2.10: Contact Location and Dimensions as defined in EMV Book 1

The minimum data transmitted is included in these specifications. Figure 2.11

illustrates the functional components of a CEP POS device.

Figure 2.11: POS Device Functional Components

- 42 -
2.6.3 EMV Standard

The most important specification in smart card payment system is the EMV

specification, named after its originators Europay, MasterCard and Visa. It describes a

set of requirements to ensure interoperability between chip cards and terminal on a

global basis, regardless of financial institution, location or manufacturer. Europay,

MasterCard and Visa started work on what was to become the EMV specification in

1993, and the first version “EMV 96” was released in June 1996. These three

international card payment associations saw that chip-based credit and debit cards

could provide a solution to the problems of counterfeit payment cards and credit card

fraud, as well as providing real multiple application opportunities for financial

institutions. Other international and national credit card associations have now also

accepted EMV as the global standard for smart bank payment cards.

MasterCard and Visa have now set dates for migration to EMV including

proposed dates for liability shift deadlines. Merchants or acquiring banks not

supporting EMV transactions could be subject to financial penalties at that time. This

is already creating a catalyst for migration to a widespread chip acceptance

infrastructure, and has so far resulted in over 100 million EMV chip cards being

issued in 28 countries around the world.

In May 1998, Europay, MasterCard and Visa published EMV 3.1.1, which

defines the specifications for smart card-based debit and credit transactions. These

specifications provide a reliable global framework for the growth of smart card

payment applications. In addition, EMV-based smart cards offer a solid foundation

for a broad selection of payment-related and nonpayment applications such as stored

value, e-purse, and loyalty. Over time, these value-added applications promise to

deliver greater financial benefits in new revenues than the savings available from the

- 43 -
reduction in fraud. The EMV specifications focus on the interactions between smart

cards or chip cards and payment terminals. The specifications are designed to apply to

a variety of terminals and devices, such as bank automated teller machines (ATMs),

POS terminals, and PCs. EMV specifications cover elements such as general physical

characteristics of terminals, the terminal card interface, transaction processing, data

management, and of course data security requirements. In 1999, the three card

associations founded EMVCo as an independent organization that will continue to

manage and enhance the EMV specifications as technology advances and the

implementation of chip card programs becomes more prevalent. EMV 4.0 or EMV

2000 published in December 2000 clarifies and enhances the original specifications,

as well as adding new guidelines for recent developments such as low-voltage smart

cards and cards with faster chip clock speeds for improved response times. Three

classes of operation are defined based on the nominal supply voltage applied to the

ICC. These are defined in Table 2.4 below. The ICC shall support class A and may

optionally support one or more additional consecutive classes. The ICC shall operate

correctly on any supply voltage lying within the range(s) specified for the class(es) it

supports.

Table 2.4: Classes of Operation 8

8
http://www.emvco.com

- 44 -
 The newly released EMV 4.1 has been available since May 2004 and consists

of four books. Book 1, Application Independent ICC to Terminal Interface

Requirements, which describes the minimum functionality required for the integrated

circuit cards (ICCs) and the terminals to ensure correct operation and interoperability

and independence of the application being used. The main part of Book 1 covers the

electromechanical characteristics, logical interface, and transmission protocols, such

as contact locations and dimension as shown in Figure 2.10, or the layout of the

contacts relative to embossing and/or magnetic stripe as shown in Figure 2.12. While

the other parts describe files, commands, and application selection. Book2, Security

and Key Management, describes a minimal security functionality required for

integrated the circuit cards (ICCs) and terminals to ensure correct operation and

interoperability. Additional requirements are provided with respect to the on-line

communication between ICC and the issuer, and the management of cryptographic

keys at the terminal, issuer, and payment system level.

Figure 2.12: Layout of Contacts

Book 3, Application Specification, defines the terminal and integrated circuit

card (ICC) procedures necessary for effecting a payment system transaction in an

international interchange environment. The main part of Book 3 covers data elements

and commands, and debit and credit application specification.

- 45 -
 Book 4, Cardholder, Attendant, and Acquirer Interface Requirements for

Payment Systems, defines the mandatory, recommended, and optional terminal

requirements necessary to support the acceptance of integrated circuit cards (ICCs) in

accordance with the other documents of the Integrated Circuit Card Specifications for

Payment Systems. The main part of Book 4 covers software architecture, cardholder,

attendant, and acquirer interface. The Integrated Circuit Card Specifications for

Payment Systems are available on http://www.emvco.com:

o Book 1: Application Independent ICC to Terminal Interface Requirements

o Book 2: Security and Key Management

o Book 3: Application Specification

o Book 4: Cardholder, Attendant, and Acquirer Interface Requirements

2.7 Cryptology

The discipline of cryptology consists of cryptography and cryptoanalysis.

Cryptography is the essence of encrypting and decrypting data. Cryptoanalysis is

concerned about how to break existing cryptographic systems. The mainly objectives

of cryptography are confidentiality, integrity, authenticity of messages, and non-

repudiation of messages. Confidentiality is that only the recipient can decrypt its

contents. Integrity means that the sender and receiver can assurance of the messages

has not been changed during transmission and storage. Authenticity means that the

recipient can verify the received data has not been changed during transfer the

message from the intended sender. Non-repudiation, can be used for verified the

sender who send a message to the recipient, that the message cannot be repudiated.

There are three types of data in encryption technology. Plaintext is the

original or unencrypted data, while encrypted data is referred to as ciphertext. Key is

used for encrypt or decrypt data. In general, the algorithms that are used in smart

- 46 -
cards are block-oriented, which means that fixed lengths both plaintext and

ciphertext.

Figure 2.13: Principle of a symmetric cryptographic algorithm

Cryptographic algorithms are divided into two types: symmetric and

asymmetric. Symmetric algorithms use the same key for back and forth plaintext and

ciphertext. On the other hand, asymmetric algorithms use different keys for

encryption and decryption the plaintext and ciphertext, respectively. A term that

mostly related with cryptographic algorithms is the magnitude of the key length.

There are a several methods of attack for breaking the key of a cryptographic

algorithm. If the attacker knows plaintext and ciphertext, the secret key can be

identified by trial and error. Brute force attack is the method to find out the key by

employing a powerful processor to try all possible keys. In general, on average half of

the possible keys must be require before find out the correct key. So, a longer key will

be employ to avoid the attacker. The length of possible keys that effect to how hard to

break a cryptographic algorithm. A large key space is one of several criteria for a

secure cryptographic algorithm that should be tradeoff with the specific application.

Modern cryptographic algorithms are as a rule based on Kerckhoff’s principle, such

as Data Encryption Standard (DES). This principle mainly focused on the secrecy of

the key rather than secrecy of the cryptographic algorithm. So, many textbooks can

disclosure the essentially of DES algorithm. In this report will be focused on a

symmetric algorithm that specific on Data Encryption Standard (DES) and

asymmetric algorithm that particularly in RSA algorithm, as shown in Figure 2.14.

- 47 -
 Figure 2.14: Classification chart for cryptographic techniques in Smart Cards

2.7.1 Symmetric Cryptographic Algorithms

Symmetric cryptographic algorithms are based on the principle of performing

encryption and decryption using the same secret key, as shown in Figure 2.15. The

best known and most widely used is DES (Data Encryption Standard).

Figure 2.15: Symmetric cryptosystem: sender and recipient share the same key.

___________________________________________________
9
Cryptography and Secure Communications, Man Young Rhee 1994

- 48 -
Data Encryption Standard 9

There are two important principles for a good encryption algorithm

incorporated into the design of the DES. These are principles of confusion and

diffusion, as first proposed by C. Shannon. The confusion principle states that the

statistics of the ciphertext should affect the statistics of the plaintext, the attacker

cannot take the benefit from them. The diffusion principle, states that each bit of the

plaintext and the key should affect from many bits of the ciphertext. The characteristic

of DES is ciphertext still the same length as plaintext. The block size of plaintext and

key are 64 bits or 8 bytes. The key contains eight parity bits, so the key space is 256.

This means that there are approximately 7.2 x 1016 possible keys. Presently, DES with

the key space (56 bits) has become not suitable for encryption, since the innovation of

the computer age. Keys for encryption can find out in a few hours. So, the solution is

expanding the keys to 128 bits that also called triple-DES that will be explained

further. The DES algorithm based on LUCIFER designed by Horst Feistel was

developed by IBM under the leadership of W.L. Tuchman in 1972. This algorithm

approved by the National Bureau of Standards (NBS) after assessment of DES

strength by the National Security Agency (NSA), became effective as a Federal

Standard in 1977. Figure 2.16 shows the flowchart of the DES algorithm. The

plaintext block X is first transposed under an initial permutation IP. After passing

through 16 rounds of substitution and transposition, before get the ciphertext Y, as

shown in Figure 2.16. The deciphering process is still the same as encryption except

that the keys are used in reverse order.

2.7.2 Asymmetric Cryptographic Algorithms

In 1976, Whitfield Diffie and Martin E. Hellman described the possibility of

developing an encryption algorithm based on two different keys, public and private

- 49 -
keys. While public key used for encrypt the plaintext to the ciphertext and private key

to get the plaintext back (Figure 2.17). In this paper, reviewed the RSA algorithm for

Figure 2.16: Block cipher design used by DES 9

the example of Asymmetric cryptographic algorithms. Since RSA will be employed in

Thai Smart Cards specification for the first 12 millions cards auction in 2004.

- 50 -
Figure 2.17: Asymmetric cryptosystem: Case 1, the sender uses his/her private key
and the recipient decrypts with the sender’s public key. Case 2, sender uses the
recipient’s Public key and the recipient decrypts the message with his/her private key.

The RSA algorithm 6

In 1977, Ronald Rivest, Adi Shamir, and Leonard Adleman was developed the

RSA algorithm that based on asymmetric encryption algorithm. The security of the

RSA system is based on the hard problem of factoring a large integer. The two keys

are generated from the two large prime numbers.

The encryption and decryption processes can be expressed mathematically as follows:

Encryption: y = x e mod n Decryption: x = y d mod n

Where x = clear text or plaintext y = encoded text or ciphertext

- 51 -
 e = public key d = private key

n = public modulus = p.q

p,q = secret prime numbers

To encrypt the data following the RSA algorithm, the block of plaintext must

be padded to the appropriate block size according to the length of the key used.

Encryption is performed by exponentiation of the plaintext followed by a modulo

operation. The result of this process is the ciphertext. The decryption process is

analogous to the encryption process that will get the plaintext back The RAM

capacity of smart cards would not be adequate for performing exponential operations

on large numbers, as required in the context of encryption and decryption. The

numbers grow very large before being subjected to the modulo operation. For this

reason, ‘modular’ exponentiation is employed, which means that the intermediate

result of the calculation never exceeds the value of the modulus. If the value of x2

mod n must be calculated, the expression (x.x) mod n is not evaluated directly, since

the intermediate result (x.x) would be unnecessarily large before being reduced by the

modulo calculation. Instead, the expression ((x mod n).(x mod n)) mod n is evaluated,

which yields the same mathematical result. Public and private keys may have

different lengths, private key should be as large as possible to increasing a security.

While the public key may require a few number, since the time required to verify a

digital signature can be reduced. However, one of the strengths of the RSA algorithm

is that it is not limited to a particular key length, in contrast to the DES. To increase

the security, longer key can be used without any change to the algorithm. Although

the RSA algorithm is scaleable, but the computation time and the required memory

space must be considered to be secure with the appropriate smart card.

- 52 -
 The generation of keys for the RSA algorithm takes place according to a

simple process. The following is a small work-through example:

1. First, select two prime numbers p and q : p = 3; q = 11

2. Next, calculate the public modulus: n= p.q = 3 x 11 = 33

3. Calculate the temporary variable z for use

during key generation: z = (p-1) x (q-1) = 20

4. Calculate a public key e which satisfies the

condition e < z and gcd (z,e) = 1

since there are several number of gcd (z,e) = 1

that meet these conditions, select one of them: e=7

5. Calculate a private key d that satisfies

the condition (d.e) mod z = 1; (3x7)mod 20 = 1 d = 3

The computation of the keys represent the public key is 7 and the private key is 3. By

using the RSA algorithm for encryption and decryption, as illustrated in the following

numeric example:

1. Use the number ‘4’ as the plaintext x (x<n): x = 4 ; (n= p.q =33, e=7)

2. Encrypt the plaintext: y = x e mod n y = 47 mod 33 = 16

3. The result of the ciphertext: y = 16; (n=p.q=33, d=3)

4. Decrypt the ciphertext: x = y d mod n x = 163 mod 33 = 4

5. The result of the plaintext: x=4

n = p.q = 3x11 = 33 ; z = (p-1).(q-1) = 20

Plaintext Plaintext
X=4 Encrypt ciphertext Decrypt X=4
Y = 16
Public Key e = 7 Private Key d = 3

Figure 2.18: Encryption and decryption example with the RSA algorithm

- 53 -
Certification Authority 4

A certification authority (CA) is a trusted computer system that is able to

testify to the identity and authenticity of one or more of the parties in a transaction.

Often this is the owner of the scheme. Certification can be an on-line or off-line

process; either the entity presents its ID together with a certificate from the CA or it

presents its ID and the other party seeks certification on-line from the CA. The

process may be mutual; each party require authentication of the other, such as card

and terminal. While two parties do not know each other in advance, they may use a

CA as a trust third party to confirm each other’s identity (Figure 2.19). The CA may

also act as a central repository or distribution center for public key. To guard against

incorrect public keys being published or errors being introduced, public keys may be

signed by the CA, using its secret key. They can then be decrypted using its public

key, which is assumed to be available to all. In case of CEPS specification, which

describes the functional requirements, the certification authority providers must be

able to generate public and private key pair; receive regional or issuers’ and merchant

acquirers’ public key data through scheme provider for certification; and deliver the

Figure 2.19: Certification Authority

- 54 -
certificates to region, issuer, and merchant acquirers. During the implementation, the

identification of certification authorities must be determined, however, the PSAM

must be able to contain multiple CA public keys, regional certificates (when they are

used), and acquirer certificates for each active CA public key. The number to be

stored must be decided by the scheme provider during the implementation.

2.8 Conclusion

This chapter facilitated the reader in brushing up the basic knowledge, and

talked about some drawbacks of the magnetic stripe card and how to harmonize the

smart card into the E-Purse applications in appendix A. Since the infrastructure for

magnetic stripe cards has been installed worldwide, to allow both types of technology

to coexist, i.e. magnetic and smart card; the essential elements of smart card

technologies, i.e., types of smart card, smart card operating system, and standard and

security must be studied. Moreover, before moving further onto the Hong Kong case

study in Chapter 3, the reader is recommended to review the electronic purse

technology presented in this Chapter for a better understanding about the technical

aspects of the smart card components, the essence standards, and the cryptology of the

electronic purse.

- 55 -
 Chapter 3: Octopus Case Study 10

3.1 Introduction

History

In 1979, MTR Corporation Limited (Mass Transit Railway) was established

and a fully automatic fare collection system was launched. The payment system

consisted of recirculated magnetic plastic cards used as single journey tickets and

stored value tickets.

In 1984, The Kowloon-Canton Railway Corporation (KCRC) adopted the

same magnetic cards rechristened such that passengers could use Common Stored

Value Tickets (CSVT) on both railways.

In 1989, The CSVT system was further extended to Kowloon Motor Bus

(KMB) feeder buses and Citybus. The CSVT was also adopted for small scale non-

transport applications, such as payments at photobooths and for fast food vouchers.

These attempts received very positive public acceptance and much interest from

operators, opening a diverse range of small value payment applications.

In 1993, The MTR took the lead in reviewing its fare collection technology.

Although well accepted by the public, the CSVT had reached the limits of its

development capabilities. Contactless smartcard technology was subsequently

recognized as the most appropriate platform for future systems.

In 1994, Creative Star Limited (renamed as Octopus Cards Limited in

January 2002) was established to oversee the development and implementation of the

contactless smartcard. It is a joint venture of five major public transport operators: the

MTR, KCRC, KMB, Citybus and the Hong Kong and Yaumati Ferry.

10
http://www.octopuscard.com

- 56 -
 In September 1997, the Octopus smartcard system was launched, allowing

commuters to travel across six public transport modes using one single card, and

eliminating the hassles of finding exact change for individual journeys.

In April 2000, Octopus Cards Limited was authorized as a Deposit Taking

Company by the Hong Kong Monetary Authority (HKMA) so that the use of its

card could be expanded to a wider base of different applications. The first non-

transport related application was payment at 7-Eleven convenience store and was

launched in October 2000.

In 2001, a new shareholders' agreement was signed in January and the shares

of Hong Kong and Yaumati Ferry was transferred to New World First Bus Limited

and New World First Ferry Services Limited. Under the new shareholder's agreement,

Octopus Cards Limited was also transformed from its previous non-profit making

status to a profit making one.

Vision

Octopus Hong Kong Expertise Creates Export Opportunities

Mission

To make life easier for customers by applying innovative ideas through secure and

robust technology.

Core Values

Create a trusting and encouraging environment for customers, staff and shareholders

whereby we can communicate, collaborate, share and support each other as equal

partners. Continuously innovate, seek better ways to conduct business and create new

opportunities. Strive to delight customers whenever they encounter Octopus.

- 57 -
Overview

The Octopus card (the "Card") is issued by Octopus Cards Limited (the "Card

Company") which is responsible for the operation and maintenance of the payment

system (the "Card System") in which the value stored in the Card can be used as

payment for certain services and/or goods provided or supplied by the persons or

companies participating in the Card System from time to time (the "Service

Providers"). There are different types of Octopus cards for adults, students, children

and the elderly, as shown in Figure 3.1. Student means any person aged between 12-

25 enrolled in a full-time course in a recognized local institute and fulfils the

conditions stipulated by transportation companies. Children must be aged between of

3-11. The maximum value that can be stored on an Octopus card is HK$1,000. The

octopus card is valid for 3 years from the last add-value date and can be reactivated

when it is reloaded again.

Figure 3.1: Card Types and Price

3.2 Operation 10

Because Octopus cards are contactless, a visitor to Hong Kong will find it

strange to see people tapping their wallets, handbags, backpacks or jackets on the

octopus readers. The card can be read through common materials such as cotton or

leather, for up to a few centimeters away from the reader as shown in Figure 3.2.

- 58 -
 Octopus can be used in virtually all of Hong Kong's transportation systems.

It is also available in over 253 other organizations including carparks, fast food chains,

cake, bakery, and convenience stores, supermarkets, personal care stores, vending

machines, photobooths, cinemas, leisure facilities and schools. (Figure 3.3) Just look

for the octopus sign and enjoy the convenience of "wave and go" payment.

Figure 3.2: How to use Octopus Figure 3.3: Where to use Octopus

3.2.1 Reloading

The Octopus cardholder can re-loading the card at any designated transport

service counter, add-value machines, and any retail outlet accepting Octopus for

payment, such as 7-Eleven convenience stores. While Automatic Add-Value Service

(AAVS), an exclusive privilege for personalized Octopus cardholders saves the

cardholder from running out of value on their card and also from having to reload it

manually. If the cardholders have a credit card, savings, current or integrated account

at one of the participating banks, the cardholders can add funds to their personalized

Octopus card through AAVS, as shown in Figure 3.4.

With AAVS, HK$250 will be automatically added to their personalized

Octopus card when the remaining value is insufficient to complete a transaction. The

same amount will be deducted from their designated bank account or credit card

account and every AAVS transaction will be clearly shown on their bank or credit

card statement.

- 59 -
 Figure 3.4: Automatic Add-Value Service (AAVS)

3.2.2 Refund procedure

The Octopus cardholder can return an Octopus card at any customer service

centre at MTR, KCR Light Rail, New World First Ferry piers, or ticket office of KCR

East Rail. Octopus card consists of anonymous octopus card and personalized octopus

card. For anonymous octopus card with remaining value is less than HK$500, the

Octopus cardholder can get the immediate refund of the deposit and the remaining

value stored on the card. While a card with HK$500 or more remaining will be

returned to Octopus Cards limited for refund processing. The refund cheque will be

sent to the customer by mail on the fifth day after the application. However, cards

damaged through serious delamination, bending, tapping or graffiti can be returned to

Octopus Cards Limited for refund processing. A card cost of $30 will be levied for the

damaged card. The refund cheque will be sent to the customer by mail on the fifth day

after the application.

- 60 -
 For a personalized Octopus card, the card will be returned to Octopus Cards

Limited for refund processing. If the Personalized Octopus card is returned within 5

years from the date of issue, $30 from the deposit will be levied to cover the card cost.

The refund cheque will be sent to the customer by mail on the seventh day after the

application.

3.2.3 Reporting Lost Cards

There is an added security for using Personalized Octopus cards, cardholders

can report the loss and the lost card will be blocked from further use within 24 hours.

Cardholder is only required to bear the loss arising during the first 24 hours after the

loss report. Since, for personalized Octopus card using Automatic Add-Value Service,

cardholder has to bear the value added to the card within 24 hours after the loss report.

Each personalized Octopus card can be automatically reloaded with $250 once a day.

As the 24-hour period starts at the time when the lost card report is made,

whether leaving a message on our hotline system or by fax/ email, cardholder should

report the loss of their personalized Octopus card immediately to minimize their

possible loss. A lost card administration charge of $50 (includes HK$30 card cost and

lost card administration charge $20) will be levied. To report a lost card, the

cardholder should provide their name, HKID number and telephone number to the

Octopus hotline via email, fax, or telephone.

3.2.4 Sale Locations

The Cardholders can purchase the Octopus cards at the following locations:

• MTR Customer Service Centres

• Airport Express Customer Service Centres

• KCR East Rail Ticket Offices

• KCR West Rail Ticket Offices

- 61 -
 • KCR Light Rail Customer Services Centres

• KMB Customer Service Centre (Sha Tin Central Bus Terminus)

• New World First Ferry Octopus Service Centres

(Piers of outlying island routes, Central Pier 5or 6)

• New World First Bus Customer Service Centre

(Admiralty (East) Bus Terminal)

• CityBus Customer Service Centre (Centre - Exchange Square)

The above sales locations can also assist with malfunctioning cards or change

the language displayed on the Octopus reader to English or Chinese (except Citybus).

3.2.5 Checking the amount remaining on the Octopus card

Every time the Octopus cardholders use their card, the transaction amount and

the remaining value will be shown on an Octopus reader or on a printed receipt. You

can also check the remaining value and the date, amount and service provider of the

last transaction on Octopus enquiry machines at MTR, Airport Express, KCR East

Rail and KCR Light Rail stations.

3.2.6 Tourist Services

Tourists will find Octopus cards indispensable for getting around Hong Kong's

sights and shops. You won't need to buy individual tickets for different modes of

transport and because retail outlets accept payment through Octopus cards, you won't

need to carry coin either. When the tourist is arriving at Hong Kong, they can

purchase an Octopus card at any Octopus sales locations. And before leaving from

Hong Kong, the tourists may return the card to any of our customer service centres at

MTR, KCR Light Rail, New World First Ferry Pier or ticket office of KCR East Rail

refunded the balance and deposit amounts. However, if the tourist need to keep the

Octopus card as a souvenir of their stay in Hong Kong. Their card will be valid for

- 62 -
3 years from its last add value date. Thus the tourist can use it again during their next

visit to Hong Kong.

3.3 Technology 11

The Octopus card manufactured by Sony uses contactless IC card technology

so that users need only hold the card close to the reader/writer. A physical contact is

not required. The Sony’s 13.56 MHz Felica contactless IC card is used in Octopus

with over 12 million units delivered to Hong Kong. Contactless operation of Felica

technology is shown in Figure 3.5. There is no need to take the card out of the wallet

or handbag. The card contains an IC and an antenna, but has no battery to ensure

maintenance-free durability. The card is activated by low-power electromagnetic

signals received from the reader/writer. In addition to being so simple the card can be

tucked inside the wallet, Octopus also comes in various forms to match with the other

trendy gadgets.

Octopus Card

Figure 3.5: Contactless Operation

11
http://www.sony.net/Products/felica/index.html

- 63 -
 Octopus cards come in different shapes, such as in forms of card, watch, and

mobile. The Octopus watch has the CPU embedded in a plastic wristwatch, as shown

in Figure 3.6, showing the wristwatch module designed by Sony. To use, the users can

simply wave their arm over the sensor. (Figure 3.7)

RC-S936
Contactless
IC Module

Figure 3.6: The wristwatch module designed by Sony 11

The Octopus watch contains a mini-silicon chip, which makes the watch both

a fully functioning anonymous Octopus card and a timepiece. The Octopus watch

does not carry any deposit, but it contains a stored value and can be reloaded any

time. The Millennium watches were launched in December 1999 and the student

watches were launched in August 2000.

Nokia also produced an Octo-phone, which had the smartcard chip in the

Xpress-on cover of a Nokia 3300 series mobile phone, as shown in Figure 3.7. A new

Xpress-on cover that transforms the Nokia 3310 and 3330 mobile phones into an m-

commerce device was launched on 26 March 2002. The specially-designed mobile

phone cover comprises a full-function adult Octopus card with no initial stored value

or deposit. Customers can use the payment function after adding value to the Octopus

card at ticket offices or customer service centers of MTR and KCR, 7-Eleven and

Circle K convenience stores, Maxim's fast food and cake shops.

- 64 -
 Hewlett Packard launched Octopus watch key chains (Figure 3.7) with

timepiece function in June 2002 as a premium for its summer promotion. Each watch

key chain functions as an adult Octopus card without deposit value.

Figure 3.7: Octopus watches, Octo-phone, HP watch key chains

Transactions between the card and the reader/writer, including reading and

writing of data, are possible by bringing the card close to the reader/writer, as shown

in Figure 3.8. The Reader/Writer consists of a control board, an antenna board and a

cable connecting both circuit boards. The Reader/Writer exchanges data with the IC

card after receiving instructions from the controller. The communication distance

between the Reader /Writer and the IC card will depend on the antenna size.

The control board incorporates ASIC (Application Specific IC) which

contains an encryption engine and an encoding/decoding circuit as well as a 32-bit

CPU needed for data processing and communications.

3.4 Key Statistics 10 (last update: October 2004)

• Over 11 million Octopus Cards are in circulation

• Average daily transaction value of Octopus is HK$60 million

• over 8.6 million daily usage transactions

• 19 Banks offer Automatic Added-Value Service (AAVS)

- 65 -
 Figure 3.8: System Layout

• Over 296 outlets accept Octopus, covering applications in public transport, car

parks, retail services (supermarkets, convenience stores, fast food, cake shops,

personal care stores), self-service (vending machines/ kiosks, photo booths,

photocopiers), recreational facilities, schools and access control

3.5 The Hong Kong Monetary Authority (HKMA) Policy 12

Since Octopus Cards Limited was authorized to be a deposit-taking company

by the Hong Kong Monetary Authority (HKMA), this paper reviews the authorization

of the Issue of Multi-purpose Stored Value Cards to help the reader get a better

understanding when studying Octopus in more details, as shown in appendix C.

3.6 CONCLUSION

Octopus is an electronic payment system using contactless smart card from

Sony FeliCa, trademarked as "Octopus Card". Octopus card is taken by 253 different

organisations including public transportation, parking, retail outlets, self-service

outlets, conferences and exhibitions, recreational facilities, school campuses and

access control. Each Octopus card has a built-in microchip which stores money

12
http://www.info.gov.hk/hkma/eng/public/

- 66 -
electronically and also has the other application. Users simply wave their Octopus

cards over an Octopus reader which will automatically deduct the correct amount

from the card.

In many countries, different transportation systems develop their own card

systems, giving rise to compatibility problems and restricting their popularity.

However in Hong Kong, Octopus card is a joint venture of the major transport

operators in Hong Kong, and cover almost all the transportation services in Hong

Kong, from rail to ferry, which leads to the success of the product. In some Asian

countries such as Malaysia and Thailand, smartcards are the government projects and

the cards have another function as the identification cards. This mixed use may give

rise to the privacy problems, and may lead to forbidding an integration of national ID

card with the electronic purse applications.

Since the Octopus card is a clear evidence of compliance with the HKMA

policy as in the Clause mentioned in the appendix C, “10.26 For the purposes of

principle (b), the maximum amount that can be stored on an exempt card should

normally be HK$1,000 or less.” The Octopus card also provides varieties of services

that allow the Octopus cardholders to use their cards widely in Hong Kong, including

a master administrated from Octopus Card Limited as mentioned in this Chapter. The

best policy and administration from Octopus Card Limited resulted in almost 100% of

the Hong Kong population trusts in the Octopus card and are willing to use the card

all over the administrative region. However, the limitation of an incremental purchase

still exists with smart card contactless technology. For instance, the public telephone

application required an incremental purchase process to deduct the amount of money

may be get the trouble with smart card contactless technology.

- 67 -
 Chapter 4: Thailand Case Study

4.1 Introduction

This Chapter studies the cases of Micro Cash Card Project, which is a contact-

type, reloadable on microprocessor card e-purse application; and the disposable

contact-type memory TOT Card by TOT Corp. The reader will be provided with the

application of smart card in the e-purse application, both single- and multi-

applications. At the end of this Chapter, the reader will learn about the Policy

Guidelines in Supervision of e-money Services issued by the Bank of Thailand to

enforce on the commercial banks that want to offer e-purse services. These Guidelines

have become in effect on 10 February 2004, and will influence the e-purse service

providers both in technical and business perspectives.

4.2 Case Study of Micro Cash Card

Smart card has been introduced in Thailand for the commercial and retailing

purposes. The card is used for storing the personal information and bonuses, which

implies that the card is used as a memory card. In November of 1996, a company

named Bangkok Payment Technology or BPT; which is a joint venture of Bangkok

Motor Equipment Co., Ltd., Pro-line (Thailand) Co., Ltd., Thai Danu Bank (merged

their operations with Thai Military Bank in the year 2004), and The Data Processing

Co., Ltd.; launched the Micro Cash service, which is an complete e-purse smartcard

service. There were more than 1,000 points of sale, making Micro Cash the largest

e-purse network in the region. In addition, the market also responded highly, as

20,000 customers had purchased the cards just after being launched for 3 months.

4.2.1 Operation

Micro Cash Card is a contact-type smart card. Therefore the users are required

to insert the card into the card reader in order to conduct a transaction like buying

- 68 -
goods and services at the service location or to reload the electronic money into the

card at the loading location. Both service and loading locations are marked with the

Micro Cash Card sign as shown in Table 4.1.

Loading Selling Service

Service Providers Points Points Points
BPT Co.,Ltd. 1 1 -
Thai Danu Bank 26 55 -
EGV Cineplus Entertainment 55 13 72
World Media Shop 18 26 -
MicroBus Information Points - 13 -
MicroBus - - 1,000
Mail Box etc. - - 1
Black Canyon - - 6
Suan Siam 3 3 11
Dok Ya Book Store - 11 4
TA Shop - 8 -
Mister Postman 9 9 -
Total 112 139 1,094

Table 4.1: Micro Cash Card Service Provider

BPT also developed the card service into an open system to be ready for and

expansion into some other work systems and services. For example,

Micro Bus

BPT installed the Micro Cash system with the automatic ticketing capability

on the micro buses. The developer team developed the Micro Cash for

payment of the fixed fare (25 baht flat rate at that time). The system was

installed on 1,000 buses, and made lives of the customers easier. In addition,

the management of micro bus can monitor the daily data more effectively.

- 69 -
EGV Movie Theaters

At that time, BPT installed the Micro Cash terminals in the EGV theaters. The

card was used in place of cash to pay the ticket fees. Some of the first

terminals were installed at Bang Kae and SEACON Square branches. The

service was also expanded to ETN Movie Theater, a theater in the EGV Group.

There were 20,000 clients, and 80 pay and refill points.

Black Canyon Restaurant

Micro Cash cardholders could use the card to pay for food and drinks at 20

branches of Black Canyon that took the card.

Dok Ya Book Store

BPT installed the 30 pay points to receive the payments of books and the other

items in Dok Ya Book Stores.

Educational Institution

St.Francis-Xavier School used Micro Cash as the ID card for its students,

teachers, and staff. The card was used to pay for food and stationery sold on

the school premises. 1,700 cards were issued, to be used at the 6 pay points.

Before the Micro Cash era, coupons had been used as the payment means in

place of cash. The school management wanted to shift to Micro Cash in order

to relieve some burden in controlling the food sellers, to reduce the students

and teachers’ cash risk, and to cut down the cost of coupon printing.

Some Stores in Siam Square area

BPT installed 20 Micro Cash pay points in many stores in Siam Square area.

ESSO Gas Station

Micro Cash was used to pay the gas price in ESSO and merchandise prices in

Tiger Marts. 30 units were installed in ESSO stations.

- 70 -
4.2.2 Micro Cash Card Scheme

The parties involved in Micro Cash Card are cardholders, service providers,

and electronic purse operators who will reconcile the revenues for each service

providers, as shown in Figure 4.1.

Electronic
Money

BPT Traditional Money

Electronic Purse
Operator
Service Load
Points
Money Flow
Service
Providers

Figure 4.1: Micro Cash Card Scheme

4.2.3 Key Statistics

The summary of Micro Cash sales since its launch in November 1996 to April

1997 is shown in Figure 4.2.

CARD
35,000
29,177
30,000
26,111
25,000
21,169
20,000

15,000
10,529
10,000
4,044
5,000
1,566
0
Nov-96 Dec-96 Jan-97 Feb-97 Mar-97 Apr-97
Figure 4.2: Micro Cash Card Total Sale Volume

- 71 -
 The amounts of Micro Cash card loading since its launch in November 1996

to March 1997 are shown in Figure 4.3. And also the volumes of goods and services

payment through Micro Cash cards since its launch in November 1996 to March 1997

are shown in Figure 4.3.

Mar-97 7,557,492
7,876,594

Feb-97 6,536,473

7,634,711
Jan-97 2,121,359

2,897,436
Dec-96 669,580

1,623,075
128,817
Nov-96
300,000 Loading Payment
Baht
0 1,000,000 2,000,000 3,000,000 4,000,000 5,000,000 6,000,000 7,000,000 8,000,000 9,000,000

Figure 4.3: Total Loading and Payment Volume

This report asks to omit the technological aspect of the Micro Cash Card since

the Card is now no longer in service, therefore it is difficult to collect the fact about

the technology. However, the commercial aspect about how the business was

conducted and the outlets, banks that took the Card for the payment and reloading will

be discussed to present a picture about an e-purse application business in Thailand in

the past.

In conclusion, 1,300 units of payment and refill terminals were installed. Most

of the terminals were installed in the Bangkok and surrounding areas, except for EGV,

which also installed in the EGV’s Sri Racha branch. The total number of cards

manufactured and sold since the launch until the end of the service in the year 2002

amounted to 50,000 cards.

- 72 -
4.3 Case Study of TOT Card

History 13

Telephone has become a form of infrastructure capable of transmitting sound

and pictures from one location to another, which is the basis of the information age.

In Thailand, Telephone first came to Thailand in 1881 for use in a limited

service. Since that time, telephone service in Thailand expanded, but it was not until

1954 that Telephone Organization of Thailand (TOT) was established.

The technology of the telephone in Thailand also evolved continuously: from

the cross bar system in 1959 to the stored control program in 1983.

For the payphone services, 100 coin operated public telephone booths were

installed in 1979 in Bangkok, followed by the second long distance telephone service

connecting Bangkok to Pattaya.

In 1998, the TOT Card Public Telephone Service was launched in

December in Bangkok and some other areas. The service was scheduled to launch at

the time of the 13th Asian Games.

In 2002, TOT changed its status from a state enterprise under the control of

Transport and Communication Ministry to a public company under the new name

TOT Corporation Public Company Limited (TOT Corp).

Vision

We strive to become a leading integrated communications company in South East

Asia and the market leader in Thailand by fostering our foundation of strong

corporate governance and by offering the best customer satisfaction.

13
http://www.tot.co.th

- 73 -
Mission

• Deliver world class communications solutions using advanced technology

with flexible, responsive working style and thus be our customers' first choice

• Support the narrowing of Digital Divide for the country development

• Contribute to the development of the Thai society and preservation of the

environment

• Provide appropriate returns to shareholders

• Explore international growth opportunities through partnerships and alliances

4.3.1 Overview of TOT Card

For TOT Corp, administering public telephone service is a mandate.

Nowadays, three types of payphones are used by TOT, they are coin box, TOT card

phone, and the combination of card and coin. This paper will focus only on the case of

TOT card phone system that is developed by TOT Research and Development

Department. More than 70,000 units of the payphones that are the product from the

TOT Research and Development Department were installed all over Thailand.

One feature of the payphone developed by TOT is exclusive requirement to be

used with the TOT card. TOT card employs the smart card technology in offering an

e-purse application of disposable type. When the value in the card is depleted, the

cardholder can choose to throw the card away or collect as souvenir. This chapter will

cover the operation, technology, and some key statistics.

- 74 -
 Display

Handset

Card
TOT Card Reader

Figure 4.4: TOT Card and Public Telephone

4.3.2 Operation

To use the TOT card, the user just insert the TOT card into the card reader slot.

When the handset is lifted up, the payphone will authenticate the card. After the card

is authenticated, the payphone will read the remaining value on the card and report the

amount on the display. Then, the cardholder can start making a phone call (Figure

4.4). After the call is connected and the circuit is established, the telephone exchange

will generate the charging signal back to the payphone. This charging signal tells the

payphone to reduce the amount of money in the TOT card for 1 unit. After the caller

hangs up, the payphone will record the total amount of charge and record the TOT

card serial number onto the payphone.

The history of the payphone uses during a day and some of the individual

payment transactions are recorded into the memory of the payphone. At the end of the

day or at any prescribed time, the PMS (payphone management system) collects these

individual payment transactions and total transaction from the payphone. Both types

of transactions are generated and certified by the payphone SAM (PSAM) using

triple-DES based MAC code. Daily balances are accumulated in the PSAM counter,

- 75 -
and the total transaction is generated when the PMS collects the individual payment

transactions. In case of payphone malfunctioning, the payphone technician can be

transmitted to solve the problem by reviewing the fault report sent by the PMS.

PMS transmits the collected transaction files from the payphone to the

dispatcher. Dispatcher pre-processes the files from all the payphones under the control

of a PMS before transferring the transaction files to the clearing-house for settling

purpose This activity can occurs on a weekly or monthly basis as prescribed.

Locations of Installation

Cardholders can purchase the TOT cards at the following locations:

• TOT Customer Service and TOT Shops

• Convenient Stores, such as 7-eleven

• Department Stores and Retail Shops

• Dealers

• Any locations having TOT Card sign

Where to use the TOT Card

The following places take the TOT cards:

• All over the country. Since TOT Card consumes much lower

power than the coin phone, due to fact that payphone does not need

a mechanical part, therefore TOT Card payphone can be installed

in a remote area. Another good thing about the payphone is that

there is no need to send the coin collectors to each payphone since

all the money-related matters are done electronically.

• At some tourist attractions such as on a high mountain. In this case,

the payphone will be connected to the network via wireless local

loop (WLL) or satellite.

- 76 -
 • Another technique of connecting to the network is using the

cellular coverage. TOT payphone uses its existing NMT 470Mhz

cells as the means for connecting the payphone to the network.

• TOT card payphone system also benefits for the visually-impaired

people quite greatly. If these people are to use the coin phones,

they will have some difficulties with the different sizes of coins. A

screen reader is installed to help the visually-impaired people in

reading the remaining value in the card as well as the number being

entered.

4.3.3 Technology

TOT Card Payphone System consists of the key management system for

generating a key into the Secure Application Module (SAM) and some data to be

stored in the TOT cards. The clearing-house will reconcile the revenues to the

respective public phone operators. Another function of the clearing-house is to

provide the blacklist data, for example, if a card is stolen. Payphone management

system is used for managing the TOT card payphone units, such as to evaluate

revenue generation efficiency of the installed location. A SAM is equipped inside the

payphone unit to authenticate the TOT card and facilitate the dispatching of the

revenues to the concessionaires.

This paper presents only the operations of the TOT Card payphone system, as

shown in Figure 4.5. This paper does not cover about the generation of the key and

card data files. The system itself has three parts:

• Back End (PMS and Dispatcher)

• Clearing House

• Front End (TOT Card, SAM, and the Card)

- 77 -
 Clearing House Back End Front End
Payphone Management Card Phone CARDS
System (PMS)

SAM

Concentrator & Dispatcher

Security Access
Module (SAM)

Figure 4.5: TOT Card Payphone System

Back End

Payphone management system is the system that monitors and analyzes

revenues and faults to the payphone. The data will be summarized and reported to the

appropriate personnel so that the problems can be corrected fast. The remote data

transfer capability enables the technician to remotely test the public telephone in order

to find out its operational condition or problem before really going out to fix the

problem. The payphone management system is composed of the computer hardware,

software, a database system, and the interfacing devices for connecting to the public

payphones. (Figure 4.6)

Dispatcher can be located at the center and one dispatcher can work with

many PMS units, or even across the provinces (Figure 4.7). There may be several

PMS systems, each of which may have several dispatchers. Dispatcher pre-processes

the files from all the payphones under the control of a PMS before transferring the

- 78 -
 Dispatcher

Payphone Management System (PMS)

Figure 4.6: Payphone Management System

transaction files to the clearing-house for settling. The blacklisted cards are also

reported from the clearing-house to all the relevant payphone via the respective PMS

units.

Clearing

Purchase Dispatcher Dispatcher

concentrator

PMS PMS PMS

Group of Payphone
Figure 4.7: Clearing System Architecture

- 79 -
Clearing House

Clearing-house receives the dispatch files from dispatchers either via modem

or leased line for settlement process and distributes the negative files or the blacklist

to the payphones via the dispatcher and PMS, as shown in Figure 4.8. In general, TOT

uses the leased line to connect from the dispatcher to the clearing-house, while the

TOT’s concessionaires like to use modem to save their costs.

Chipcard Purchase Concentrator Clearing

LAN
Tel PMS line Dispatcher Leased
line
Files
Files Files
PSAM CSA
PPSAM

Figure 4.8: System Architecture

Front End

The front end of the TOT Card payphone system consists of the TOT Card,

SAM, and the card. TOT Card public payphone is developed by TOT Corp in

compilation with the international standard ISO 7816, for using with the contact

disposable-type smart card in electronic purse application. The security system for

verifying the correctness of the card is implemented according to ITSEC Criteria

Level E4. The high-level security protection system for verifying the data in the card

is an active operation, which follows the international standard DES (Data Encryption

Standard). The features of the TOT card are as following:

• R&D by TOT Corp.

• compilation with ISO 7816

• ITSEC Level E4 security

- 80 -
 • Triple-DES data encryption

• Use anti-line tapping to prevent unauthorized use

• support for the visually-impaired or blind persons

Anti-line tapping

Anti-line tapping unit is used for preventing unauthorized telephone line

tapping. The unit consists of two parts: the part at the telephone exchange, and the

another part at the public payphone. These two parts will talk and verify the encrypted

data between each other all the time. If the encrypted data is verified incorrect,

telephone use is not permitted.

TOT Card for visually impaired

A screen reader module can be built into the TOT card payphone unit

developed by TOT Corp to read aloud the remaining in the TOT card and the

destination number entered by the user. This feature can help the people who have

some visual difficulties. (See Figure 4.9)

Figure 4.9: TOT Card for visually impaired

- 81 -
Secure Application Module (SAM)

SAM is basically a type of smart card that is used for verifying the TOT card

and storing the operational data of the payphone (Figure 4.10). SAM is comparable to

the cash box of the coin box payphone, and needs to have the following features and

capabilities:

• Physically and logically secure smart card component

• Store secret keys and algorithms

• SAM secures all terminals, transaction records and transfers of

electronic money

• Every money-transferring terminal must have a SAM.

• Compliance to standards

• High security (ITSEC Level E4)

• Open specifications for multiple purchase device vendors

ID-000 PLCC-52

Figure 4.10: Secure Application Module (SAM)

Both types of SAMs have almost identical features. The only difference is

where to use. ID-000 is more appropriate to use indoor with no vibration, while

PLCC-52 can be used outdoor inside the TOT card payphone and can withstand the

vibration. Another important function of SAM is to allow for multiple service

concessionaires (Figure 4.11). In this case, the clearing-house will reconcile the

balance by looking at the service provider ID in the PSAM to know to whom the

revenue should go.

- 82 -
 PSAM has the
operator identifier
(Service Provider ID)

Disposable cards with

common secret keys
Clearing
system

Figure 4.11: Multi-Operator System (TOT Card)

TOT Cards

The TOT cards are sold in different values. Inside a card is equipped with the

following: (Figure 4.12)

• 221 bit EEPROM and 16 bit mask-PROM

• Counter with up to 33352 (Five Stage Abacus, 21064 units guaranteed)

• Supply voltage 5V, and supply current < 5 mA

• Data retained 10 years minimum

• Contact configuration and serial interface according to ISO 7816

Figure 4.12: TOT card Architecture

- 83 -
4.3.4 Key Statistics

• More than 100,000 chip card payphones has been installed along

nationwide.

• Five sets for the visually-impaired have been installed in Bangkok area,

3 in Nonthaburi, and 1 in Nakornpathom.

• In 2003, the total sales of the TOT Cards hit about 400 Million baht.

4.4 Bank OF Thailand (BOT) Policy 14

Policy Guidelines on Supervision of Electronic Money Services is the policy

that governs e-money services of the commercial banks. The text of the Guidelines is

as shown in appendix D.

4.5 Conclusion

The case study of Bangkok Payment Technology (BPT) was a case of Micro

Cash Card, which was of contact type with a microprocessor and allowed the

cardholder to reload the amount onto the card. Micro Cash was a type of multi-

application e-purse in that the users could use the card for various payments such as

on the bus or buying goods. The Micro Cash project came in service in November

1996, but was unfortunate to come to the end in 2002, due to the economic crisis that

struck our country in 1997, with 50,000 cards totally sold.

The case of TOT Card was a case of a card being used with the public

payphones of TOT Corp. Since TOT Card was of contact type memory card and not

reloadable. However, despite the disposable feature, this card was so useful for the

public payphone system, as mentioned already in this Chapter; therefore TOT Card is

still in service. The sales volume of the card in the year 2003 amounted to 400 million

baht. However, when taking the operation costs, both in terms of the public telephone
14
http://www.bot.or.th

- 84 -
set price and the face value of the TOT Card, the cost per card is still obviously high,

meaning low profit margin. The sustainability of the service is possible because TOT

Corp is still a state enterprise. It is expected that after the liberalization of

telecommunication in Thailand, TOT Card must switch to being a microprocessor

type, which is reloadable, to save the operation cost, and is extendable to offering

multi-application e-purse services for the best benefits of the cardholders and TOT’s

business partners. However, the reader also can study Thailand Smart Card Standard

Application Requirements that provide e-purse guideline, as shown in appendix B.15

In comparison between HKMA Policy mentioned in appendix C and BOT

Policy in appendix D, Thailand’s e-purse policy requires that commercial banks that

want to offer e-purse services apply for permission from the Bank of Thailand. The

criteria the Bank of Thailand uses must not hamper the development of technology

and e-purse of the country, in order to maintain Thailand’s competitiveness against

the other countries. This policy results in some vague issues, such as no maximum

value in the card is specified, as opposed to HKMA which stipulated clearly that the

amount in the card must not exceed HK$1,000. But the issues that may have an

adverse effect to the financial stability of the country will be stipulated clearly, such

as, “Transfer of money between customer to customer without going through the

service provider’s data system is prohibited,” in order to suppress money laundering.

In addition, the Thai supervision scheme does not allow for multiple-currency

transactions, as stipulated, “The electronic money can only be issued in Thai Baht and

be used in Thailand only” in which BOT has been using as the supervising policy on

e-purse services since February 10, 2004.

15
Thailand Smart Card Standard Application Requirements, Thailand Smart Card
Working Group, 1999.

- 85 -
 Chapter 5: Conclusions and Recommendations

5.1 Conclusions

This report focuses on the study of e-purse application to present to the reader

through studying the cases of Thailand and the Octopus card in Hong Kong, in the

aspects of technology and policy related to e-purse in each country. This report is

divided into 3 sections. The first section described the meaning of electronic payment,

of which card-based payment is a major factor, which includes credit card, debit card,

and e-purse application; and mentioned about the rationale and background of the

e-purse study, which is the inspiration from many large-scale projects that will happen

in Thailand soon.

One of the projects include the national ID smart card, which can be applied to

other domestic e-purse services such as public transportation, bill and service payment,

municipal services, especially, the e-purse project that is the joint effort between CP

7-eleven and many banks in Thailand. Under this scheme, the cardholder can use the

e-purse in the 1,720 7-eleven stores nationwide. This project will start with the

500,000 “Smile Members”, the cardholders who are the member of 7-eleven.

The second section laid down some basic knowledge to reader on the

components that are crucial to giving e-purse application service, including some

relevant standards such as EN1546, and the encryption method for protecting the

safety of the system. This section explained about symmetric and asymmetric

cryptography.

The last section explained about the cases in Thailand and in some other

countries. The intention of this report is to give an overview of the basic e-purse

application service to the reader in terms of service schemes, technology, policy, and

laws in Thailand and Hong Kong.

- 86 -
 The case study of Octopus Card in chapter 3 demonstrated that Octopus Card

Limited has indeed a good management and policy that are in conjunction with the

law. An example to illustrate this fact is the limitation of the reloaded amount not

more than HK$1,000, as required by the law that governs the use of e-purse in Hong

Kong. In addition, the company has the policy to offer the best satisfaction of its

customers. For instance, the company chooses the contactless technology for the

convenience of the users in conducting transactions and the system will reload an

amount into card automatically if the cardholder has an account with a bank.

One trademark of the Octopus Card is that the cardholders can buy a variety of

merchandise and services with the Octopus Card all over the administrative region,

whether it is transportation or convenient stores. The public information from the

company in October 2004 showed that there are currently 11 million cards being used,

which generates more than 300 million baht from the cardholder transactions each day.

The case study of e-purse application in Thailand in chapter 4 talked about the

Micro Cash Card, which is a contact-type microprocessor reloadable e-purse card.

Chapter 4 also talked about the TOT Card project, which is a contact-type memory

disposable e-purse card. The reader will find that the Micro Cash Card service

administered by Bangkok Payment Technology (BPT) is a multi-application service,

i.e., linking with various merchandise and service providers. There were more than

50,000 cardholders, generating the revenues from the transactions within its 5 months

(November 1996-March 1997) of service of 7,500,000 baht. The project itself came to

a close due to the economic crisis that struck Thailand in 1997.

The TOT project by TOT Corp is the card service for telephone only (single

application). The service started in the year 1998. At that time, the mobile service was

not so widespread, and the coverage was not good; therefore the people had to rely on

- 87 -
public payphone. TOT Corp therefore developed the public phone system by

incorporating the smart card technology to solve the problems of the coin phone such

as the coin stuck in the set or coin box stealing. However, since the TOT card is a

single application cad, which means high cost per card, it is hard to find an investment

partner. Therefore TOT card is losing the popularity. This problem was doubled by

the popularity of the mobile phones, which outdo with the interesting promotions,

features, and designs, in addition to the coverage. The role of payphones was then

reduced.

5.2 Recommendations

This report points out that it is necessary to study in technology, standard, and

policy contexts of the e-money or e-purse of each country. Since such the contexts are

ever-changing such as the emerging of optical card technology. The reader is

recommended to follow all aspects related to e-purse application on smart card. The

success factors of the Octopus Card and the obstacles to the development of e-purse

application in Thailand are indicate that a successful e-purse company must

emphasize the maximum benefits to the customers and there must be a strategic

partner for the e-purse to gain an acceptance from the users, which in turn, attracts

more strategic partners to join and results is a sustainable business.

Since cooperation among partners is the basic fundamental of the electronic

purse application deployment. Partners need to agree on how to develop and

concentrate services, including cost and revenue sharing on the same card for the

share cardholder. Consequently, it is necessary for further work to study in business

aspect that extracts valuable information from merchants and cardholders.

- 88 -
 References

[1] http://www.cdg.co.th/cdg36years/html/Slizes/MR2/MR25.pdf

[2] Kasem Boonkhantinat, “A Cost-Benefit Analysis of the Smart Card Reader/

Writer Producing Project A Case Study of Intel Card Industries Co., Ltd.”, 2002.,

Kasetsart University

[3] http://www.verifone.com/pdf/EMV_white_paper.pdf

“EMV: Global Framework for Smart Card Payments-2003”

[4] Smart Card Security and Applications 2nd Edition, MIKE HENDRY, 2001.

[5] http://www.commoncriteriaportal.org

[6] Smart Card Handbook 2nd Edition, W.Rankl & W.Effing 2000.

[7] http://www.cepsco.com

[8] http://www.emvco.com

[9] Cryptography and Secure Communications, Man Young Rhee 1994.

[10] http://www.octopuscard.com

[11] http://www.sony.net/Products/felica/index.html

[12] http://www.info.gov.hk/hkma

[13] http://www.tot.co.th

[14] http://www.bot.or.th

[15] Thailand Smart Card Standard Application Requirements,

Thailand Smart Card Working Group, 1999.

[16] Smart Cards, Jose Luis Zoreda, Jose Manuel Oton 1994.

[17] Realizing the Smart Card Promise Smart Card Driven Opportunities Across

Information-based Service Business, Booz Allen Hamilton Inc.

- 89 -
 Appendix A

Review of Smart Card Technology

 Appendix B

THAILAND Smart Card Standard Application

Requirements Version 1.0,

Thailand Smart Card Working Group

 Appendix C

Authorization of the issue of

multi-purpose stored value cards,

The Hong Kong Monetary Authority (HKMA)

 Appendix D

Policy Guidelines on Supervision of

Electronic Money Services,

BANK OF THAILAND (BOT)

APPENDIX
 (สําเนา)

10 กุมภาพันธ 2547

เรียน ผูจัดการ
ธนาคารพาณิชยทุกธนาคาร

ที่ ธปท.สนส. (11) ว. 378/2547 เรือ่ ง แนวนโยบายการกํากับดูแลการใหบริการ

เงินอิเล็กทรอนิกส (Electronic Money)

1. เหตุผลในการออกหนังสือเวียน

ปจจุบนั ไดมกี ารริเริม่ การใหบริการเงินอิเล็กทรอนิกส (Electronic Money) เพือ่ ให

ผูใชบริการสามารถนําเงินอิเล็กทรอนิกสดังกลาวไปใชซื้อสินคาหรือบริการตางๆได ซึ่งบริการเงิน
อิเล็กทรอนิกสดังกลาวนี้ เปนบริการที่มีแพรหลายในตางประเทศ

ธนาคารแหงประเทศไทยไดเล็งเห็นประโยชนของธุรกิจเงินอิเล็กทรอนิกสดังกลาว
ในประเทศไทย เชน ประโยชนตอ การพัฒนาเทคโนโลยี การเพิ่มประสิทธิภาพและความสะดวกในการ
ใหบริการทางการเงินแกประชาชน เปนตน จึงไดพิจารณาถึงความเสี่ยงและแนวทางกํากับการใหบริการ
เงินอิเล็กทรอนิกสในเบือ้ งตน เพื่อซักซอมความเขาใจและใหธนาคารพาณิชยใชเปนแนวทางในการ
พัฒนาการใหบริการเงินอิเล็กทรอนิกสที่สอดคลองกับการพัฒนาอยางมีเสถียรภาพของระบบการเงิน
ระบบสถาบันการเงิน และระบบการชําระเงิน

2. เนือ้ หา

2.1 คุณลักษณะของเงินอิเล็กทรอนิกส
เงินอิเล็กทรอนิกส หรือทีอ่ าจเรียกเปนอยางอืน่ เชน Multipurpose Stored Value
Card, E-purse, E-Wallet หรือ Smart Card เปนตน มีลักษณะที่สําคัญ 3 ประการ ดังนี้
1) ผูบ ริโภคชําระเงินลวงหนาใหผอู อกเงินอิเล็กทรอนิกส (pre-paid)
2) มูลคาเงินที่ชําระลวงหนาถูกบันทึกในสื่ออิเล็กทรอนิกสตางๆ (stored value) เชน
บัตรพลาสติก หรือสือ่ คอมพิวเตอรอน่ื
3) ผูบริโภคสามารถนําไปใชซื้อสินคาหรือบริการตางๆ ไดจากรานคาทีผ่ อู อก
เงินอิเล็กทรอนิกสกาํ หนด (multi purpose)

สนสว10-กส35501-25470211ด
กส355 วันที่ 10 ก.พ. 2547
 2

2.2 ความเสีย่ งและผลกระทบของเงินอิเล็กทรอนิกส

การใชเงินอิเล็กทรอนิกสในระบบเศรษฐกิจอาจมีความเสี่ยงและมีผลกระทบตอ
ระบบการเงิน ระบบสถาบันการเงิน และระบบการชําระเงินได ซึ่งธนาคารแหงประเทศไทยอาจกําหนด
แนวทางการกํากับเพื่อควบคุมความเสี่ยงและผลกระทบที่อาจเกิดขึ้นไดดังตอไปนี้

2.2.1 ผลกระทบตอระบบการเงิน
ผลกระทบจากการใชเงินอิเล็กทรอนิกสทดแทนเงินทีอ่ อกโดยภาครัฐมี
ผลกระทบตอความสามารถในการควบคุมเงินเฟอและการรักษาเสถียรภาพทางเศรษฐกิจของธนาคาร
กลางผาน 2 ชองทาง ไดแก
- ตัวทวีฐานเงิน (money multiplier) ทีอ่ าจเพิม่ ขึน้ เนือ่ งจากความจําเปนใน
การใชธนบัตรเปนสื่อกลางในการชําระเงินลดลง
- ปริมาณเงินที่อาจเพิ่มขึ้นจากการนับรวมเงินอิเล็กทรอนิกสซึ่งเปนสื่อกลาง
ในการชําระเงินเขาไปในนิยามของปริมาณเงินและการที่ผูใหบริการนําเงินที่รับลวงหนา (float) ไปทํา
ธุรกรรมตอ
แนวทางการกํากับ
- ติดตามและควบคุมปริมาณเงินอิเล็กทรอนิกสในระบบอยางใกลชิด
- กําหนดสัดสวนการดํารงเงินสดสํารองตอเงินอิเล็กทรอนิกส (หากจําเปน)

2.2.2 ผลกระทบตอระบบสถาบันการเงินและระบบการชําระเงิน
1) ความเสี่ยงดานสภาพคลอง จากการที่ผูออกเงินอิเล็กทรอนิกสไมสามารถ
ชําระเงินไดเมือ่ มีการเรียกเก็บเงิน เนื่องจากการใชเงินอยางผิดวัตถุประสงค หรือมีการบริหารเงินทีไ่ มมี
ประสิทธิภาพ เปนตน
ผลกระทบ
- รายไดและความสามารถในการชําระเงินของผูที่เกี่ยวของรายอื่น เชน
สถาบันการเงินอืน่ ทีร่ ว มโครงการ หรือรานคา
- การสูญเสียเงินของผูบ ริโภคทีไ่ ดจา ยเงินลวงหนาใหแกผอู อกเงิน
อิเล็กทรอนิกส
- ความเชือ่ มัน่ ของผูบ ริโภคทีม่ ตี อ ระบบ
แนวทางการกํากับ
- ธนาคารพาณิชยผูใหบริการตองมีระบบการบริหารความเสี่ยงที่เหมาะสม
- ธนาคารแหงประเทศไทยอาจกําหนดเงือ่ นไขการบริหารเงินทีร่ บั ลวงหนา
(float) ไดหากจําเปน

สนสว10-กส35501-25470211ด
 3

2) ความเสี่ยงดานปฏิบัติการ จากความบกพรองของการดําเนินการ
การรักษาความปลอดภัยของระบบ ตลอดจนการฉอโกงของผูใ หบริการหรือรวมใหบริการ
ผลกระทบ
- ความถูกตองของขอมูล และการรักษาความลับของขอมูล
- ความตอเนือ่ งในการใหบริการ
- ความนาเชื่อถือของระบบการชําระเงินและระบบสถาบันการเงิน
แนวทางการกํากับ
- ธนาคารพาณิชยตองปฏิบัติตามแนวปฏิบัติที่ธนาคารแหงประเทศไทย
กําหนด เชน แนวปฏิบัติในการรักษาความปลอดภัยการใหบริการการเงินทางอิเล็กทรอนิกส และ
แนวปฏิบัติในการใชบริการดานงานเทคโนโลยีสารสนเทศจากผูใหบริการรายอื่น เปนตน
- สงเสริมใหผูใหบริการเลือกใชเทคโนโลยีที่เปนมาตรฐานสากล
- กําหนดใหธนาคารพาณิชยปฏิบัติตามหลักธรรมาภิบาล

2.2.3 ผลกระทบอื่นๆ
1) การคุม ครองผูบ ริโภค
เนือ่ งจากธุรกิจการใหบริการเงินอิเล็กทรอนิกสเปนธุรกิจทีผ่ บู ริโภคตอง
จายเงินลวงหนาเพื่อแลกกับเงินอิเล็กทรอนิกส การคุม ครองผูบ ริโภคจึงมีความสําคัญมาก โดยการให
บริการดังกลาวควรพิจารณาถึง
- ขอบเขตความรับผิดชอบของผูอ อกเงินอิเล็กทรอนิกส รานคา และผูบ ริโภค
กรณีเกิดความเสียหายทั้งจากการฉอโกง ความผิดพลาด บัตรสูญหาย (กรณีบันทึกมูลคาเงินลงบนบัตร)
เปนตน
- คาธรรมเนียมในการใชบริการ
- เงื่อนไขการคืนเงินใหแกลูกคา
แนวทางการกํากับ
- ธนาคารพาณิชยที่จะใหบริการเงินอิเล็กทรอนิกสตองยึดหลักธรรมาภิบาล
ในการประกอบธุรกิจ
- มีการใหความรูและชี้แจงขอมูลรายละเอียดการใหบริการและความเสี่ยงที่
อาจเกิดขึน้ แกผบู ริโภคและผูท เ่ี กีย่ วของอยางชัดเจนและโปรงใส

2) การฟอกเงิน เนือ่ งจากการใหบริการเงินอิเล็กทรอนิกสในบางรูปแบบ

อาจเอือ้ ตอการฟอกเงินได เชน ระบบทีม่ กี ารโอนเงินไดระหวางลูกคาโดยไมตอ งผานระบบของผูใ ห
บริการ เปนตน

สนสว10-กส35501-25470211ด
 4

แนวทางการกํากับ
- ไมอนุญาตใหมกี ารโอนเงินระหวางลูกคาโดยไมผา นระบบขอมูลของ
ผูใหบริการ
- ระบบทีใ่ หบริการตองสามารถตรวจสอบรายการยอนหลังได
- กําหนดมูลคาสูงสุดของเงินอิเล็กทรอนิกสที่สามารถใชได
- เงินอิเล็กทรอนิกสที่ออกตองเปนเงินบาทและใชในประเทศไทยเทานั้น

3. ขอบเขตการถือปฏิบัติ

ธนาคารพาณิชยที่ประสงคจะใหบริการเงินอิเล็กทรอนิกสดังกลาวขางตน ตองขอ
อนุญาตจากธนาคารแหงประเทศไทยตามมาตรา 9 ทวิ แหงพระราชบัญญัตธิ นาคารพาณิชย พ.ศ.2505
และที่แกไขเพิ่มเติม โดยในการพิจารณาอนุญาต ธนาคารแหงประเทศไทยจะพิจารณาถึงผลกระทบ
และความเสี่ยงที่อาจเกิดขึ้นตามที่กลาว พรอมทั้งพิจารณาถึงความสามารถและความนาเชื่อถือของ
ผูอ น่ื ทีร่ ว มใหบริการดวย อยางไรก็ตาม การพิจารณาอนุญาตของธนาคารแหงประเทศไทยจะคํานึงถึง
การไมปดกั้นพัฒนาการของเทคโนโลยีและธุรกิจ เพื่อมิใหประเทศสูญเสียความสามารถในการแขงขัน

4. วันเริ่มตนการถือปฏิบัติ

ใหถือปฏิบัติตามแนวนโยบายการกํากับดูแลการใหบริการเงินอิเล็กทรอนิกสตั้งแต
บัดนีเ้ ปนตนไป

จึงเรียนมาเพือ่ โปรดทราบและถือปฏิบตั ิ

ขอแสดงความนับถือ

(ม.ร.ว. ปรีดิยาธร เทวกุล)

ผูวาการ
ฝายกลยุทธสถาบันการเงิน
โทร. 0-2283-6938, 0-2283-6939
หมายเหตุ [ ] ธนาคารจะจัดใหมกี ารประชุมชีแ้ จงในวันที…
่ …………ณ…………..
[ X ] ไมมกี ารจัดประชุมชีแ้ จง

สนสว10-กส35501-25470211ด
 Table of Contents (Appendix A)

Table of Contents (Appendix A)………………………………………………………1

A.1 Technology of the Card….……………………………………..…………………2

A.2 Types of Smart Cards……………………………..…..…………………………..7

A.3 Smart Card Application…………………………………………………..……...14

A.3.1 Security and Authentication…………………………………………...15

A.3.2 Electronic payment Applications…………………………………...…15

A.3.3 Transportation Applications………………...……..………………….16

A.3.4 Telecommunication Applications………………….………………….16

A.3.5 Loyalty Applications……………..……………..….………………….17

A.4 Overcoming the barriers to entry multi-application smart cards………………...17

A.5 The strategic implications for multi-application smart cards…..………………..18

A.6 Smart Cards Operating Systems…………………….…………………………...20

A.7 Smart Card Status based on E-Purse Application…………………….…………31

1
A.1 Technology of the Card

The basic card technology for automatic reading or human operating is the

smart card (see Figure A.1), and magnetic stripe, as shown in Figure A.2. A half-inch

wide 12.7 mm stripe of magnetic tape is attached to the card substrate. Initially, each

individual magnetic particle is placed along the stripe. In the unencoded state, each

particle may be magnetized either from left to right or from right to left, so there is no

overall polarization. In some cases, the total replacement of the magnetic card by the

smart card is not possible to be done overnight, due to the existing magnetic

infrastructure, which is not fully ready to support the newcomer. In this case, the

magnetic component on a card still needs to coexist with the chip section, for

example, the National ID Card that may uses the magnetic stripe to load the money

from the bank and uses the chip section for payment, as shown in the figure below.

Figure A.1: Smart Card Figure A.2: Magnetic Stripe Card

Magnetic-stripe Cards

The magnetic stripe are read by pulling it across a read head automatically or

wipe card via a magnetic card reader by hand. Part 2,4 and 5 of ISO standard 7811

specify the properties of the magnetic stripe, the coding technique and the locations

on the magnetic cards. The magnetic stripe consists of three tracks. Tracks 1 and 2 are

specified to be read-only tracks, as shown in Figure A.3. Additional data can be read

and written on track 3, such as the last transaction data in the case of a credit card.

2
 Figure A.3: Location of magnetic strip on an ID-1 card

Table A.1: Standard features of the three tracks on a magnetic-stripe card

The main disadvantage of the magnetic stripe card is that the original data can be

modified. Consequently, the criminal can acquired the valid card data and easy to use

duplicated cards in unattended terminals without having to forge their card surface.

Coercivity

The physical magnitude that measures the magnetic field required for

magnetizing any given material is called coercivity. It can be directly obtained by

measuring the width of the hysteresis loop, as shown in Figure A.4.

Figure A.4: Magnetization saturation and intrinsic coercivity

3
Magnetic Stripe Encoding

A binary 0s and 1s are not associated to opposite magnetizations, but depend

on magnetization changes. When two contiguous domains have opposite

magnetizations, a sudden polarity reversal occurs on the intermediate border. This is

called flux reversal. Figure A.5 shows the magnetic stripe encoding system produces

flux reversals between every pair of contiguous bits.

Figure A.5: Encoding magnetic stripes with an F/2F system

The difference between binary 0s and 1s is that 0s keep their orientation along their

full length, while 1s have another flux reversal in the middle. Therefore, 0s are made

of single domains while 1s are made of two domains each. It easily follows from the

above that this two frequency encoding system for magnetic stripes, called F/2F,

relies on accurate measurements of bit lengths, since length is the only difference

between a binary 1 and two binary 0s.

Magnetic Stripe Reading

The variations in the magnetic field are produced by the flux reversals

between consecutive bits and the intermediate flux reversal of binary 1s. Every flux

reversal induces a current in the coil, its sign being imposed by the magnetic domain

orientation at both sides, as shown in Figure A.6.

4
 Figure A.6: Reading F/2F-encoded magnetic stripes.

Since the electric signals are not produced by the magnetic domains themselves, but

by their variations. It becomes clear why schemes F/2F are used for encoding

magnetic stripes, since the reliability of the system is limited by the drawbacks of the

encoder, reader, and stripe and bit length deviations. In the reading process a magnetic

stripe card reader is impaired by inadequate magnetization inside the card. The use of

over saturating magnetic fields is not recommended, since the magnetization of the

zones decreases when the external encoding magnetic field is too high. The reason is

that the field is so strong that it alters the previous and subsequent stripe areas.

Another potential problem comes from accidental stripe erasures produces by

magnetic fields or electric devices and partial erasures change the original data.

High-Coercivity Cards

The magnetic field required for magnetizing or erasing a stripe depends on the

material coercivity. Coercivity specifications depend on material’s manufacturers.

The traditional gamma ferric oxide stripes are encoded at 300 oersteds (Oe) that also

can erase by magnetic fields. The obvious advantage of high-coercivity (HiCo)

materials is an enhanced magnetic immunity; that is, the magnetic damage from

accidental exposure to magnetic fields is greatly reduced. These materials, such as

barium ferrite, require magnetic fields ranging from 2,000 to 4,000 Oe or more. The

5
standard for HiCo encoding, ISO 7811-6, has been introduced but it not widely used,

since it difficult to change the equipment, such as EPOS.

Fraud in Financial Magnetic Stripe Cards 16

More than one billion magnetic stripe cards have been issued worldwide in the

last decade. This widely accepted “plastic money,” however, has also produced new

kinds of crime, mostly derived from security pitfalls of the magnetic media. The

following paragraphs describe the primary methods of magnetic stripe card fraud.

• Theft. A magnetic cards may be stolen and used in ATMs or EPOSs. Many

cardholders change their original PINs, with the numbers that easy to

memorialize, such as birthdays. In worse case, some users write down their

PINs for remember purpose. If the wallet or purse was stolen, the thieves may

find out the PIN in a few minutes.

• Counterfeit. Fraudulent cards may be produced by reading the original card

and encoding onto the other cards. PINs may be searched for with multiple

copies of the legal card.

• Buffering. To avoid reaching the card limit in ATM cash withdrawal, the

original data may be read and store onto the other cards and reproduced when

the card is depleted.

• Skimming. The original encoded data have been modify, to increase the cards

credit limit, while even white card copies may be used in many unattended

terminal.

As we understand the drawbacks of the magnetic stripe cards. It is

representing that anyone who has some technical skills can easy to read and

modify the magnetic stripes by using standard electronic equipment.

6
Enhancing security using complementary technologies

Several techniques can be applied to improve the security of magnetic stripe

cards. Which will be represents below:

• Watermark tape: A thin stripe of magnetic tape is mounted to the top of the

card, on the same side as but above the magnetic tape. The watermark tape is

read by special readers, which can be fitted to ATMs or EPOS. It contains a

security code that is unique to every card, the code that generated also

contained in the magnetic stripe. If the stripe and watermark do not

correspond, the card is decided to be counterfeit.

• Holomagnetics: By using a machine that can read hologram in the position of

the visual hologram. The special reader is suitable for read at the specific

location, it could be used for protecting ATMs but not point-of-sale readers.

• Card signatures: Small variations along the magnetic tape can be measured by

specially equipped card readers. A “signature” made from these variations is

stored, in encrypted form, on the standard tracks. These systems should detect

not only counterfeit cards, but also unauthorized attempts to alter the data.

A.2 Types of Smart Cards

The Smart Card characteristic is an integrated circuit embedded in the card

consists of the transmission, storage and processing of data. Data transfer via the

contacts on the surface of the card or radiated via radio frequency (RF). The Smart

Card has more advantage point than magnetic stripe cards, such as high maximum

storage capacity or more security to access the card. For example, Smart Card

application Thai citizens will be using Java-based Smart Card, which support 32Kb of

___________________________________________________
16
Smart Cards, Jose Luis Zoreda, Jose Manuel Oton 1994

7
memory for data storage and security the national ID cards with the user's digitized

fingerprints for biometric identification in 2004. Moreover, other advantages of the

smart card are its long life and high reliability when compared with the magnetic

stripe cards. The fundamental characteristics and functions of smart cards generally

followed by ISO 7816 standards. Smart Cards can be divided into three groups by:

• Function: Memory Cards and Microprocessor Cards

• Access Mechanism: Contact or Contactless

• Physical Characteristic: Shape and Size

Memory Cards

The data required for the application are stored in the Electrically Erasable

Programmable Read-Only Memory (EEPROM). The terminal can easily access the

memory via the security logic to read or write data. However, there are memory cards

with more complex security logic, such as public telephone cards that established in

Thailand consists of the authentication unit to prevent fraud, as shown in FigureA.7.

TOT Card, issued by TOT Corp.

including authentication unit

Figure A.7: The model and structure of memory card with Authentication Unit

8
Microprocessor Cards

The key component of the integrated circuit that embedded in a smart cards

consists of memory, protected memory, coprocessors and microprocessor to perform

in a microprocessor cards manner, as shown in Figure A.8. Nowadays, semiconductor

manufacturers designed ICs for smart cards by using low-power CMOS technology,

chips operating voltage down to 1.5 V and below are being research.

Figure A.8: Architecture of a contact-type microprocessor card with a coprocessor

Microprocessor

Most current microprocessors are 8-bit, usually based on Motorola 6805 or

Intel 8051 architectures, and with clock speeds up to 5 MHz, such as SLE4436 chip

designed for public telephone card based on CPU 6805. Thirty Two-bit processors

are employed in the newest chips, particularly in security applications. For example,

the national ID cards employed 32-bit CPU and 32 Kbytes of memory.

Memory

Memory is the essential factor in the design of a smart card based on

application, which means that more application require more memory. The memory is

divided into the type of semiconductor memory:

9
 • Read-only Memory (ROM) is used for storing the fixed program of the

card, also called mask ROM. The mask ROM contains the chip’s

operating system that identical for all the chips of a production state.

• Programmable read-only memory (PROM) is used for loading a cards’

serial numbers or other fixed value, such as manufacturer code.

• Flash memory is used for storing additional applications for launch

their services in the future.

• EEPROM is the chips’ non-volatile memory. Data and program can be

read and modify within the EEPROM. Two important parameters for

the life and reliability of smart cards are the number of write cycle and

data retention period. For example, the EEPROM can accept 100,000

cycles and 10 years data retention.

• Random access memory (RAM) is used for temporary working

storage, such as the variable in running state. Data in RAM is lost

when the power is removed.

• Ferro-electric RAM (FERAM or FRAM) is starting to be used in

Smart Cards. It will be used in place of EEPROM, since their

advantage point in the higher speed and lower-power consumption.

Disadvantage of FRAM is a proprietary technology, but it has produces

by several companies.

Coprocessors

Smart Cards chips that are designed for in security applications, such as the

national ID cards require coprocessors to operate cryptographic functions. Data

Encryption Standard (DES) or Rivest, Shamir and Adleman (RSA) are cryptographic

10
functions that integrated coprocessors to perform security applications in Crypto or

PKI cards.

Contactless Smart Cards

Nowadays, we have to migrate a magnetic stripe cards with contact Smart

Cards, principally in financial application to comply EMV Standard. Contact Smart

Cards will interface with the outside world through a set of six to eight contacts, as

defined in ISO 7816 part 1 or in the European Telecommunication Standards Institute

(ETSI). The reliability of contact Smart Cards type has been growing steadily, due to

a number of million of contact-type Smart Cards distributed around the world.

However, contact Smart Cards also has a weakness point from the physical part of a

contact and card accepted device or terminal. The method for loading a contact Smart

Cards requires a few minute too. To overcome these problems, some smart card

applications employ contactless cards to provide services, such as transportation or

access-control. A contactless card dimensions are usually the same as ISO cards,

except thickness, which varies from 0.76 mm to about 3 mm. A Contactless Smart

Cards will communicate with the reader via radio frequency technology by using an

antenna wound that embedded inside the cards, as shown in Figure A.9. Power source

will be acquired from a battery or the general collected by an antenna. Most of the

cards’ manufacturer designs a contactless Smart Card operated by an antenna.

A coil antenna is built into the thickness of the card, either around it circumference or

with a many turns around the chip itself, within the size of the contactless Smart

Cards. The generally used frequencies are 125 kHz and 13.56 MHz for communicates

by modulating the RF signal, using one of the standard modulation types. A

modulation technique consists of amplitude modulation (AM), Amplitude shift keying

(ASK), frequency modulation (FM), frequency shift keying (FSK), binary phase shift

11
keying (BPSK). Card designers try to use the modulation techniques that require a

low power, such as code division multiple access (CDMA), but chip also acquire

Figure A.9: Typical architecture of a microprocessor card with contactless interface

more power consumption for today. Typical power requirements drive contactless

microprocessor cards require 5-8 mW, while approximately 1.5 mW for small

protected memory cards. With the lower frequency, the distance from the contactless

Smart Cards to the card accepted device antenna can be up to 1m, while the higher

frequency the distance closer to 20 cm. The maximum data transfer rate, rely on

frequency that up to 100 Kbps for the 13.56 MHz cards.

Combi and Hybrid Cards

There are two types of combine contact-contactless smart cards, namely the

hybrid card and the combi card. Both cards have contact and contactless parts

embedded together in the plastic card. However, in the hybrid card, the contact IC

chip and contactless chip are separate modules. No electrical connections have been

included for communications between the two chips. These two modules can be

considered as separate but co-existing chips on the same card. While in the combi

12
card, the contact and contactless chips could communicate between themselves, thus

giving the combi card the capability to talk with external environment via either the

contact or contactless method (Figure A.10).

The advantage of a combi card is that it is cheaper than a hybrid card. A

hybrid card has a different meaning based on refers to a card with two different card

technologies or a card has two chips, each with contact and contactless interface.

Figure A.10: Typical architecture of a Combi Cards

A hybrid card in terms of different card technology, such as magnetic stripe

and Smart Cards by using the magnetic stripe for loading electronic money from

ATM and recording into a Smart Cards for e-purse application. Finally, a Hybrid card

in terms of a card have two independent microcircuits, contact and contactless

embedded inside the card. This hybrid card is a most secure, since no share memory

and microprocessor but more costly than a combi card.

13
Physical Characteristic of Smart Cards based on shape and size

Generally, we remind Smart Cards in a credit-card size, but smart-card

technology is used in several applications where different in shapes and sizes. Some

applications require a smart card module, such as security application modules

(SAMs) or subscriber identity modules (SIMs) in global system for mobile

communication (GSM), as shown in Figure A.11.

Figure A.11: Smart Card in others form, SAM or SIM

While, some smart card applications built into key-shaped devices. Smart keys

usually requires a microprocessor, such become popular in pay TV for descrambling

the TV signal. Moreover, the other smart cards applications built their shape into

watches or jewelry, for example transportation services in Hong Kong, as review in

chapter 3. Many of these proprietary devices gain security from their unique design,

since uneconomic to reproduce or counterfeit and may get attention from the user.

A.3 Smart Card Application

The convergence of internet and smart cards are now more widely accepted in

the fruitful of electronic commerce. Moreover, it has also been widely used as an

identity card. For instance, in Thailand, some of Thai citizens will be using the

national ID cards (Smart Card) by 2004. This national ID card can be used for identify

the nationality of the cardholder as well as the electronic payment application.

Medical record can also be stored in the social security card, responsibility by social

security office, Ministry of Labour that will be partitioning in the national ID card.

For example, the critical information of the patient can be retrieved, such as blood

14
group. The smart card has also been used in transportation such as the Octopus card in

Hong Kong to replace of the old magnetic stripe card. With the advantage of smart

card technology, many secure data such as the computer login name and password can

also be kept secure in their smart card and will be helpful for fast access.

In this Appendix, we shall briefly describe some current applications of smart

cards that require different access card technology, such as contact, contactless or dual

interface (combi or hybrid card). These applications can be classified into 5 main

categories: Security and Authentication, Electronic Payment, Transportation,

Telecommunications, and Loyalty program.

A.3.1 Security and Authentication

The national identification card (smart card) is one of the examples of security

and authentication application. The national ID card of Thais’ citizens is a hybrid card

technology, contact-type smart card and incorporated with magnetic stripe card. The

magnetic stripe card side is may also require for loading electronic money from bank

account and stored on their smart card. However, the national ID card will have

personal data stored on the card, such as the cardholder’s name, ID number, date of

issue, date of expiry and date of birth. On the other hand, some of information will not

display on it, such as blood group or address, since it may misunderstanding or

misplace from the cardholder, as shown in Figure A.1 and Figure A.2.

A.3.2 Electronic payment Applications

The Electronic Purse is one of examples of the electronic payment application

can be used for small purchases or low value transaction without necessarily requiring

the authorization of a PIN. In general the contact smart card is credited from the

cardholder’s bank account or cash at the bank or shop any time. However, the

magnetic stripe card can also be hybrid with contact smart card for loading

15
electronic money from ATM or bank account and stored on their smart card. When it

is used to purchase goods or services, electronic value is deducted from the card and

transferred to the retailer’s account. Widespread adoption of electronic cash will

reduce the costs to produces notes and coins and retailers in managing cash.

A.3.3 Transportation Applications

The contactless smart card can act as electronic money for car drivers who

would need to pay a fee before being able to use an expressway, the cardholders will

get discount 5 percent from the Expressway and rapid transit authority of Thailand. It

would then contain a balance that can be increased at payment stations, and is also

decreased every time for each use. Moreover, the contactless smart card can apply to

electronic ID for car park or access control, which nowadays has been installed at the

department store around Thailand.

A.3.4 Telecommunication Applications

Telecommunication is one of the largest markets for smart card applications.

In 1998, payphone cards that employ smart card technology were introduce to

Thailand market. Over 50 million of the smart cards (TOT Card) are issued as

payphone cards in 2003 and will continue be the largest market in Thailand’s smart

card. Since 1988, smart card has become an essential component in cellular phone

systems. Network data, subscriber’s information and all mobile networks critical data

are kept inside the card. With this card, subscribers could make calls from any

portable telephone. Moreover, through the IC card, any calls through the mobile

phone could be encrypted, and thus ensure privacy. In the future by using smart card

could support more value-added services, such as mobile-commerce (M-Commerce).

16
A.3.5 Loyalty Applications

Loyalty program is another important application of smart cards in the daily

life application. The preferred customer status together with detailed information on

shopping habits is stored and processed on the smart card. With this information,

merchants could derive better shopping or tailor-made personalized customer

shopping profiles. In addition, some shops like 7-eleven can issues loyalty program by

using smart card instead of stamp, which give benefits for the cardholder.

A.4 Overcoming the barriers to entry multi-application smart cards 17

In order to realize the benefits of multi-application smart cards, the next step

for service providers is to develop joint programs to host multiple applications on the

same card and co-invest in smart card infrastructures. In this section will briefly about

two common issues must be resolved before exploit multi-application. Firstly, Who

owns the card or who is the risk taker for providing the infrastructure? Secondly, Who

owns the relationship with the cardholder? With the relationship between the card

ownership and cardholder are the service provider in single application. While, multi-

application smart cards, the card issuer is the gatekeeper (or “real-estate” owner), but

it is the applications stored on the smart card that link the cardholder with the service

provider (who does not necessarily have to be the card issuer). Success in the

deployment of multi-application cards is related to the creation of partnerships to

provide different services on a shared platform through cooperate between R&D and

marketing programs. The information-based service providers who want to use smart

cards to expand their service offering must establish a network of technology partners

to put together the required diverse capabilities along the smart card manufacturing

value chain, as shown in Figure A.12.

17
 Figure A.12: The smart card manufacturing value chain

Cooperation is the theme song of the smart card evolution that not rivalry

among partners. Service providers at the “Value-Added Services” end of the value

chain must agree on R&D efforts and cooperate on rules to regulate the partners.

Therefore, real change will not come from technological developments but from the

positive interaction among information-based service providers, such as banks,

telecom operators, interactive media producers, and government. Partners need to

agree on how to develop and concentrate services, including the revenue sharing on

the same card for the shared customer. Customers’ loyalty will remain to those partner

networks that offer the widest range of every-day life services on a single smart card.

A.5 The strategic implications for multi-application smart cards 17

For the cardholders, the benefit of smart cards is clearly the integration of

several applications on a single smart card, such as transportation services and e-purse

applications with the convenient store. The smart card business value chain is clearly

extending upstream and downstream beyond the traditional core activities of

acquiring, settling, processing, and issuing, as shown in Figure A.13.

___________________________________________________
17
Realizing the Smart Card Promise Smart Card Driven Opportunities Across

Information-based Service Business, Booz Allen Hamilton Inc.

18
 Figure A.13: The smart card business value chain

The upstream value for the customer is derived from the shift to new products.

Only those players who master adapting technology or who can partner with

technology providers will succeed in developing new products. The downstream

value is driven by the multiple services offered on a single card that reach the

customer through several channels, such as Prepaid smart cards that can buy Orient

Thai Airlines flights and other services will be sold at convenience stores found

throughout Thailand such as 7-11, Family Mart and Watsons in the near future. In this

way, the customer can be “accompanied” in everyday-life activity. The long-term

smart card business potential, revenue opportunities, are extremely high. The players

along the value chain will not be competing for customers, but will be cooperating for

service provisions. They will focus on increasing the number and span of services that

can be added to the cards. The winning business strategy is based on engaging card

users by maximizing use of the entire set of card services, which in turn will lock in

the customer. If users recognize the added value of the service provider alliance,

cannibalization and churn to other smart card providers is less likely to occur.

Eventually, the card will become such a necessary part of daily activities.

19
 Cross-business partnerships as the critical element that will enable a positive

business case for multi-application chip cards through complementary services,

information, and transactions. On the other hand, cross-business partnerships may

ruin the project that cooperates among partnerships. Consequently, partnership

models have to be realized both commercial agreements (leading to new product

developments) and strategic alliances (to offer new services) in a solid manner, as

shown in Figure A.14.

Figure A.14: Partnership Path

A.6 Smart Card Operating Systems

Memory Organization

Having selected the smart card, developers have to design the data structures

to be used on the card, since the limited memory space. The three different types of

memory in Smart Card microprocessors consists of ROM, RAM and EEPROM, have

completely different properties. The smart card operating system is stored in ROM

and it is programmed all at once, but in the future may the operating system can be

replaced after distributed to the customer. ROM can be protected by error detection

20
codes (EDCs), since it is possible for error will occurred in the ROM. RAM only

retains its content while power is applied to the Smart Card. RAM can be erased with

unlimited times and also working at full speed of the processor. The advantage of

EEPROM is still retains data without power. The drawbacks of EEPROM are limited

lifetime, require a few milliseconds for writing and erase times, and page structure. In

general, RAM is divided into the registers, the stack pointers, general variables,

workspace for cryptographic algorithm and the I/O buffer, as shown in Figure A.15.

Figure A.15: Partitioning example of a 256-byte RAM

The partitioning of the EEPROM is divided into fabrication data, operating

system, application program, file region and free memory as shown in Figure A.16.

A fabrication data consists of semiconductor manufacturer, production facility,

coordinate on the wafer, chip type, etc.

Figure A.16: An example of how the EEPROM is partitioned

21
 The table and operating system pointers are loaded into the EEPROM to

combine with the ROM programs for complete smart card operating system purpose.

This operating system is protected by an error detection code (EDC). The application

program is provided when the application-specific command or algorithms that should

not be located in the ROM, since require a vast memory in the ROM area. The file

structures for a Smart Card partitioning in a file region, which are supports multiple

applications divided into master file (MF), dedicated file (DF), and elementary file

(EF) regions. Finally, there is an optional free memory region assigned to individual

application in the file region.

Smart Card Files

In general, the structure of Smart Card file systems complied with ISO/IEC

7816-4 standard. There are two categories of files for file Smart Cards, dedicated file

(DF) and elementary file (EF). Dedicated files (DFs) acts as a directory files manner

and supervised by master file (MF), refers to the root directory (Figure A.17). The

elementary files can be divided into working EF and internal EF. All application data

that acquired from the terminal are located in the working EF. The data contains in the

working EF are not used by the operating system. While, data for the execution of an

application, secret key or program code are stored in the internal EF. Access to the

internal EF is only performed by the operating system.

22
 Figure A.17: Smart Card File Structure

File names

Presently, the files for smart card operating system addressed by logical name,

rather than a direct physical address. The physical address will be used in memory

cards, since this technique save a memory space.

Figure A.18: File names according to ISO/IEC 7816-4

The File Identifier (FID)

The file system in the ISO-7816-4 is one of the important components in the

smart card. Files are referenced by a file identifier (FID), which is two bytes long.

The FID of the MF is ‘3F00’, while the logical file name ‘FFFF’ is reserved for future

23
use. There are also other FIDs that are reserved by the ISO and other standard, as

shown in Table A.2.6

Smart Card OS (Card-Side)

The smart card companies have been developing their own applications using

several proprietary systems. The emergence of the Java card, refers to Smart Card

operating systems with downloadable program code. Mondex has also introduced

their multi-applications operating system, MULTOS. Moreover, Microsoft has also

joined the embedded OS environment. Finally, Open Platform was originally designs

by Visa. There are many powerful card OS in the market, but we would concentrate

on these four card OSs because their outstanding characteristic.

Table A.2: FIDs that are reserved by the most important Smart Card standards 6

24
Java Card

In 1990, a development group at Sun began to develop a new programming

language. The objective was to create a hardware-independent, secure and modern

language that could be used for microcontroller in consumer product, such as toasters.

Finally, Sun launched Java in 1995. A Java compiler will be compiled Java source

code into bytecode and provided with certain additional information, is called a class

file. Class files are executed when the Java virtual machine has been loaded. One or

more class file constitute an ‘applet’, which contains a complete Smart Card

application and has its own application identifier (AID). In the context of Java for

Smart Cards, applets are sometimes called ‘cardlets’. The further development of Java

is ‘just-in-time’ (JIT) compilers, which translate the Java bytecode into the machine

language of the processor (Figure A.19). Because of this programming concept, Java

offers a perfect solution to both the development environment and security matters for

the smart card operating system. Card manufacturers have joined the race and

produced their own Java cards. With the use of Java Card, users could develop their

own smart card programs also known as Java cardlets in Java and download on card.

Figure A.19: Data flow diagram of Java including JIT compiler 6

25
Basic knowledge of Java Card

The Java card was originally designed to support multiple applications. It not

only accommodates multiple applications, but also ensures each application is

protected in the card from the other applications (Figure A.20).

Figure A.20: Java Card internal structure.

So data and variables in one application are not accessible by other applications on the

same card. Many application developers have already started to use Java cards in their

development, such as Java development tools of a mobile simulator device, Figure

A.21. The Java card aims to be a fast, object-oriented, easy-to-program smart card

with more programming function, cryptographic library, and may have an co-

processors.

Advantages of Java Card

Java card programming allows card-side program development and the card-

side logic circuit is no longer restricted to assembly language. Thousands of Java

programmers can now enter into the smart card development market. As a

consequence, card-side development will pick up speed.

Using the Java byte code compiled in any Java development environment, any

Java program can be loaded into the card when required. Figure A.22 represents how

it is easy for loaded java program and executed on the mobile device after simulation.

26
 Figure A.21: Java development tools of a mobile simulator device

On the other hand, whenever the code is not needed, it could be removed from

the card. Consequently, allows the smart card program to be deployed almost

anywhere.

Figure A.22: E-Purse Application with Java Program, Library Services

27
Mondex MULTOS OS

Besides the Java Card, Mondex has derived a similar smart card architecture

for multi-function purposes called the MULTi-application Operating System

(MULTOS). The MULTOS is another new interpreter-based operating system. It is

developed and supported by MasterCard and MONDEX. Similar to the Java card, the

core of the MULTOS operating system is an interpreter that allows the applications to

be developed independently of the underlying card hardware. With the MULTOS API

(card-side application interface on the MULTOS card), applications written with

MULTOS API would be write-once-run-anywhere over any MULTOS platform.

Using the firewalls, MULTOS is able to provide application in the highest security.

Therefore, MULTOS could be considered as an extremely secure. The internal card

structure of MULTOS is similar to the Java Card, as depicted in Figure A.23.

Figure A.23: MULTOS Card internal structure.

MULTOS uses a dedicated programming language called MULTOS Executable

Language (MEL) which is a simple virtual processor language. Application

developers could write the code in the high level language C and then translate the

code with the help of a tool into the interpreter language MEL. The code can then be

downloaded onto the card.

28
Advantages of MULTOS

The MULTOS smart card OS is also developed as a multi-application OS.

Same as the Java Card, it could accept one or more application codes written in a

high-level language. However, because it was initially developed by financial

institutes as an electronic purse, the security of the card OS was an important design

issue. After Mondex and Sun Microsystems make an agreement, Java cardlets will be

accepted on both types of smart card system. For this reason, Java cardlets will likely

become the future smart card programming standard.

Microsoft Windows in Smart card

The idea of Microsoft Smart card OS is similar to the OS mentioned above.

The main objective is to provide a new smart card development environment that

accepts multi-applications using languages familiar to the software developer rather

than assembly languages. Even though Microsoft Smart card OS shares the same

criteria as MULTOS and Java card, Microsoft Corporation believes that there is a

niche for their card OS. One of the main obstacles for the MULTOS and Java

platforms to be widely accepted is cost. For this reason, Microsoft Corporation aimed

at delivering smart cards at a more attractive price in simpler card and more extensive

card with security features. Because Microsoft’s smart card standard has just been

announced, the basic structure of the card has not been confirmed. It is believed that

the operating system would be a variation of Windows CE. It should be compliant

with ISO 7816-4, EMV and the SET standard.

Advantages of using Microsoft Smart card OS

An advantage of this card OS is this will be a low-cost smart card as promised

by Microsoft. More importantly, this card will become an extension of the PC

29
environment, in terms of both development tools and connectivity. Therefore,

development and usage of the card and host-side application would be more closely

linked. The software development tools for the card OS is based on commonly used

development tools including Visual Basic and Visual C++, so a large number of

software developers could put their technical skills of PC applications development to

smart card development.

Table A.3: Multi-application operating systems compared 4

Open Platform

Open Platform was first introduced by Visa (as the Visa Open Platform) and is

now run by a consortium called Global Platform, which includes telecommunication

companies and technology companies as well as Visa and other banking associations.

Open Platform takes the Java Card concept further, and adds some of the extra

features, in particular control of the personalization process and of application loading

and unloading.

Advantages of Open Platform

Open Platform is not as prescriptive as Multos, and issuer can determine their

own levels of control. It can be harmonized with Windows for Smart Cards as well as

with Java Card.

30
Card OS future

There are now four multi-function smart card operating systems in addition to

a number of proprietary and less commonly known smart card operating systems. The

four card operating systems would probably occupy different segments of the smart

card market. The simple Microsoft smart card OS would probably be dominating the

low-cost home card market. It could be used in future for quick and simple card

applications. While the MULTOS card should be more widely accepted in financial

and electronic purse related applications. Because of its highly secure internal

structure, the MULTOS card would also be selected for security related applications.

In the MULTOS card model, the Virtual Machines and Operating system would all be

based on MULTOS while in the Java Card model, only a Java Card JVM would have

to be implemented on the proprietary card OS. In other words, a card manufacturer

can produce its own Java card by building their Java Virtual Machine or licensing a

JVM from Sun Microsystems directly. However, card vendors would not be able to

produce a MULTOS card unless they are given the MULTOS specification.

Therefore it is likely that the Java Card and also including Global Platform

would be much more widely accepted. In conclusion, the Smart Card operating

systems with downloadable program code will create a new industry for smart card

application development outside of the card vendor sector. This is because it is now

possible to load programs after the card has been manufactured.

A.7 Smart Card Status based on E-Purse Application

Most European countries, and many others around the world, have at least

trailed an electronic purse scheme. Banks in some countries, such as Thai Danu Bank

in Thailand, launch micro cash card products with BPT Company and their partners to

the clients for reloadable purse application. While disposable purse application also

31
called TOT Card, public telephone has been installed around Thailand. Both

disposable and reloadable contact-type purse applications will be explained further in

chapter 4, case study of electronic purse in Thailand. Most current schemes around

the world licensed designs by these companies:

• Visa Cash is electronic purse products operate by VISA. There are two main

types of Visa Cash cards: disposable and reloadable purse applications.

• Proton cards were originally developed in Belgium, but are now used in over

20 countries. Proton World has demonstrated a CEPS application.

• Mondex was described in Multos OS. The Mondex scheme allows card-to-

card or Purse-to-Purse transactions. This feature of Mondex has been

criticized by some bankers tend to prohibit in some country. For example in

Thailand purse-to-purse transfer are not allowed, as presented in appendix D.

Since purse-to-purse it does not allow checking and audit of every transaction

that led to money laundering.

• Mifare cards are contactless, and are primarily used in public transportation.

32
 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 Version 1.0 Page 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

Thailand Smart Card Standard Application Version 1.0 Page 2

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

Thailand Smart Card Standard Application Version 1.0 Page 3

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

Thailand Smart Card Standard Application Version 1.0 Page 4

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

2) Card Holder
3) Service Provider or Merchant
4) Card Issuer
5) Value Issuer
6) Value Acquirer
7) 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.

Smart Card Scheme Relationships

Fund
Pool
Scheme
Issuer
Issuer Provider Acquirer
Acquirer

Value
ValueIssuer
Issuer
Clearing
ClearingHouse
House

Merchant
Merchant
/ /Service
Service
Cardholder
Cardholder provider
provider
(OHFWURQLF
9DOXH

Figure 1 : Open Smart Card Scheme Participants

Thailand Smart Card Standard Application Version 1.0 Page 5

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

Thailand Smart Card Standard Application Version 1.0 Page 6

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

Thailand Smart Card Standard Application Version 1.0 Page 7

 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.

Thailand Smart Card Standard Application Version 1.0 Page 8

 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.

Thailand Smart Card Standard Application Version 1.0 Page 9

 MF

DF DF EF EF EF

EF EF EF EF

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.

Thailand Smart Card Standard Application Version 1.0 Page 10

 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.

Thailand Smart Card Standard Application Version 1.0 Page 11

 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.

Thailand Smart Card Standard Application Version 1.0 Page 12

• 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

Thailand Smart Card Standard Application Version 1.0 Page 13

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.

Thailand Smart Card Standard Application Version 1.0 Page 14

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

Thailand Smart Card Standard Application Version 1.0 Page 15

 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

Thailand Smart Card Standard Application Version 1.0 Page 16

 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 be
authenticated by chip-based credit/debit card authentication service and be cleared and settled
under chip-based credit/debit operating rules.

Thailand Smart Card Standard Application Version 1.0 Page 17

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:

Thailand Smart Card Standard Application Version 1.0 Page 18

 • 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

Thailand Smart Card Standard Application Version 1.0 Page 19

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.

Thailand Smart Card Standard Application Version 1.0 Page 20

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.

Thailand Smart Card Standard Application Version 1.0 Page 21

 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

Thailand Smart Card Standard Application Version 1.0 Page 22

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.

Thailand Smart Card Standard Application Version 1.0 Page 23

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.

Thailand Smart Card Standard Application Version 1.0 Page 24

 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 Interior
2) Civil Service Commission, Ministry of Interior
3) Department of Land Transport, Ministry of Transport and Communications
4) Revenue Department, Ministry of Finance
5) 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 Presence

E1 8 Card Serial Number (CSN) 16 numeric char M
2 Issuer Code 4 numeric char M
2 Manufacturer Code 4 numeric char M
2 Card Type 4 numeric char M
1 Card Version 1 Character M
1 Derivation Key Index 1 Character M
4 Personalization Equipment Identifier 8 numeric char M
4 Personalization Date YYYYMMDD M
4 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 Presence

C1 1 Card Type 1 Alpha num. M
(e.g.1=citizen,2=civil,3=Driv)
C2 var. Name-Surname ‘;’ Name-Prefix/title 80 Characters M
C3 var. Organization Abbreviate 5-20 Characters O
C4 var. Registered Address 60 Characters M
C5 var. Current Address 60 Characters O
C6 var. Telephone no. 10 Alpha num. O
C7 var. Picture Bit map image O
C8 var. Signature Bit map image O
C9 var. Thumbprints Bit map image O
CA 4 Birth date YYYYMMDD M
CB var. Birth place 15 Characters M
CD 1 Marriage status 1 Characters M
CE 1 Gender 1 Characters M
CF 2 Blood Group 2 Characters M
D0 7 National ID number 13 numeric char M
D1 4 Driving License 8 numeric char C1

Thailand Smart Card Standard Application Version 1.0 Page 25

 D2 5 Tax ID 10 numeric char O
D3 5 Welfare ID 10 numeric char O
D4 var. Issued place 15 Characters M
D5 4 Issued Date YYYYMMDD M
D6 4 Expiration Date YYYYMMDD M
D7 3 Type of Driving License 3 Characters C1
D8 5 Class of Vehicle 5 Characters C1
D9 5 Penalty Status 5 Characters C1
DA 2 Accumulated Driving Points 2 numeric char C1
DB 4 Updated Points Date YYYYMMDD C1
DC 4 Unpaid penalty issued by police 8 numeric char C1
DD Var. Personal/Contact Person Information 80 Characters O
DE 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 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
15) Type of Vehicle
16) Tax ID
17) 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

Thailand Smart Card Standard Application Version 1.0 Page 26

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

Thailand Smart Card Standard Application Version 1.0 Page 27

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

4.2. Application Owner

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.

4.3. Data Requirements

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)

Thailand Smart Card Standard Application Version 1.0 Page 28

 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

Thailand Smart Card Standard Application Version 1.0 Page 29

 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.

Thailand Smart Card Standard Application Version 1.0 Page 30

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

Thailand Smart Card Standard Application Version 1.0 Page 31

 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:

Tag Length Value Format Presence

E1 8 Card Serial Number (CSN) 16 numeric char M
2 Issuer Code 4 numeric char M
2 Manufacturer Code 4 numeric char M
2 Card Type 4 numeric char M
1 Card Version 1 Character M
1 Derivation Key Index 1 Character M
4 Personalization Equipment Identifier 8 numeric char M
4 Personalization Date YYYYMMDD M
4 Application Expiration Date YYYYMMDD 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 Presence

5A 8 Primary Account Number (PAN) 16 numeric char M
9F08 2 Application Version Number 3 numeric char M
9F3B 2 Application Reference Currency 3 numeric char M
9F59 1 Consecutive Transaction Limit 8 binary bits M
9F54 6 Cumulative total trans. amount limit 12 numeric char M
9F13 2 Last online application trans. counter 16 binary bits M
9F23 1 Maximum Consecutive Offline Limit 8 binary bits M
C1 1 Card Type (1=A/C , 2=Anonymous) 1 Alpha num. O
C2 Var. Name-Surname ‘;’ Name-Prefix/title 80 Characters O
C3 var. Organization/ Company name 5-20 Characters O
C4 var. Registered Address 60 Characters O
C5 var. Current Address 60 Characters O
C6 var. Telephone no. 10 Alpha num. O
C7 var. Picture Bit map image O
C8 var. Signature Bit map image O

Thailand Smart Card Standard Application Version 1.0 Page 32

 C9 var. Thumbprints Bit map image O
CA 4 Birth date YYYYMMDD O
CB var. Birth place 15 Characters O
CD 1 Marriage status 1 Characters O
CE 1 Gender 1 Characters O
CF 2 Blood Group 2 Characters O
D0 7 National ID number 13 numeric char O
D2 5 Tax ID 10 numeric char O
D3 5 Welfare ID 10 numeric char O
D4 var. Issued place 15 Characters O
D5 4 Issued Date YYYYMMDD M
D6 4 Expiration Date YYYYMMDD M
D9 1 Card Status 1 Character M
DD Var. Personal/Contact Person Information 80 Characters O
DE 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.

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

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

Thailand Smart Card Standard Application Version 1.0 Page 33

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.

Thailand Smart Card Standard Application Version 1.0 Page 34

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.

Thailand Smart Card Standard Application Version 1.0 Page 35

6. Loyalty Application

6.1. Functional Requirements

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.

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.

Thailand Smart Card Standard Application Version 1.0 Page 36

 6.3. Data Requirements

The smart card reference information is defined in a constructed data object as shown in table 6:
Tag Length Value Format Presence
E1 8 Card Serial Number (CSN) 16 numeric char M
2 Issuer Code 4 numeric char M
2 Manufacturer Code 4 numeric char M
2 Card Type 4 numeric char M
1 Card Version 1 Character M
1 Derivation Key Index 1 Character M
4 Personalization Equipment Identifier 8 numeric char M
4 Personalization Date YYYYMMDD M
4 Application Expiration Date YYYYMMDD 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 Presence
5A 8 Primary Account Number (PAN) 16 numeric char M
9F08 2 Application Version Number 3 numeric char M
9F3B 2 Application Reference Currency 3 numeric char M
9F59 1 Consecutive Transaction Limit 8 binary bits M
9F54 6 Cumulative total trans. amount limit 12 numeric char M
9F13 2 Last online application trans. counter 16 binary bits M
9F23 1 Maximum Consecutive Offline Limit 8 binary bits M
C1 1 Card Type 1 Alpha num. O
C2 var. Name-Surname ‘;’ Name-Prefix/title 80 Characters O
C3 var. Organization/ Company name 5-20 Characters O
C4 var. Registered Address 60 Characters O
C5 var. Current Address 60 Characters O
C6 var. Telephone no. 10 Alpha num. O
C7 var. Picture Bit map image O
C8 var. Signature Bit map image O
C9 var. Thumbprints Bit map image O
CA 4 Birth date YYYYMMDD O
CB var. Birth place 15 Characters O
CD 1 Marriage status 1 Characters O
CE 1 Gender 1 Characters O
CF 2 Blood Group 2 Characters O
D0 7 National ID number 13 numeric char O
D2 5 Tax ID 10 numeric char O
D3 5 Welfare ID 10 numeric char O
D4 var. Issued place 15 Characters O
D5 4 Issued Date YYYYMMDD M
D6 4 Expiration Date YYYYMMDD M
D9 1 Card Status 1 Character M
DD Var. Personal/Contact Person Information 80 Characters O
DE Var. Allergies & long-term illness 80 Characters O

Thailand Smart Card Standard Application Version 1.0 Page 37

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

6.5. Security Requirements

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.

Thailand Smart Card Standard Application Version 1.0 Page 38

2) Points Issue

Points issue transactions shall be conducted off-line between the card acceptance terminals and
smart cards. The card acceptance terminals capture sales transaction value and calculate given
points 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 be
undertaken 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 processed
off-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 threshold
and 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.

Thailand Smart Card Standard Application Version 1.0 Page 39

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.

Thailand Smart Card Standard Application Version 1.0 Page 40

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

Thailand Smart Card Standard Application Version 1.0 Page 41

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.

Thailand Smart Card Standard Application Version 1.0 Page 42

 This page is left blank intentionally.

Thailand Smart Card Standard Application Version 1.0 Page 43

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/Govt Merchant Card Holder

Institution
Attended
Online only 11 21 -
Offline with online capability 12 22 -
Offline only 13 23 -
Unattended
Online only 14 24 34
Offline with online capability 15 25 35
Offline only 16 26 36

Table D-1: Terminal Types

Thailand Smart Card Standard Application Version 1.0 Page 44

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’).

Thailand Smart Card Standard Application Version 1.0 Page 45

Table B-2: Tag Field Structure (Subsequent Bytes) BER-TLV
The 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 Length(byte) Value

(T) (L) (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 Length(byte) Primitive BER-TLV … Primitive BER-TLV

(T) (L) Data object number 1 Data object number n

Thailand Smart Card Standard Application Version 1.0 Page 46

 Table B-4: Constructed BER-TLV Data Object

Thailand Smart Card Standard Application Version 1.0 Page 47

Appendix C – Transaction Message Format

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

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 Conditional field, where xx is:
01 The primary Account number is included when the transaction is entered
manually via the keyboard.
02 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.
03 For on-line transactions when the account number is read from the magnetic
stripe reader track I and or track II will be included.
04 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.
05 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.

Thailand Smart Card Standard Application Version 1.0 Page 48

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

Message Type ID n 4 0100 0110
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 If manual card entry allowed
03 Processing Code n 6 30A00X 30A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 If manual entry of expiry
date is allowed
22 POS Entry Mode n 3 C03 “050”=Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 49

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0220 0230
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M
03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra control
bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M Time transact was approved
13 Date, local transaction n 4 M Date transact was approved
14 Date, expiration n 4 O If available from origin.trans
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M Req.RRW is from origin resp
M Resp RRW updat RRW for
transaction in terminal batch
38 Auth. ID Response an 6 M
39 Response Code an 2 M M From original transaction
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 50

Sales

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 Manual card entry,if allowed
03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Manual entry of expiry date ,
if allowed
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 51

Refund

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 Manual card entry,if allowed
03 Processing Code n 6 20A00X 20A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Manual entry of expiry date ,
if allowed
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 52

Adjust

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

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0220 0230
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M
03 Processing Code n 6 22A00X 22A00X Adjust of Credit Transaction
A-acct. select, X extra ctl bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M Time transact was approved
13 Date, local transaction n 4 M Date transact was approved
14 Date, expiration n 4 O If available from origin.trans
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M Req.RRW is from origin resp
M Resp RRW updat RRW for
transaction in terminal batch
38 Auth. ID Response an 6 M
39 Response Code an 2 M M From original transaction
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
60 Original Amount ans….999 M Contains original amount
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 53

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M
03 Processing Code n 6 22A00X 22A00X Void of Credit Transaction
A-acct. select, X extra ctl bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 O If available from origin.trans
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M Req.RRW is from origin resp
M Resp RRW updat RRW for
transaction in terminal batch
38 Auth. ID Response an 6 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 54

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 is undertaken. 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. Comments

Message Type ID n 4 0220 0230
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M
03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra ctl bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M Time transact was approved
13 Date, local transaction n 4 M Date transact was approved
14 Date, expiration n 4 O If available from origin.trans
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M From original transaction
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 55

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0400 0410
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 Manual card entry,if allowed
03 Processing Code n 6 M M Same as the transaction
being reversed
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Manual entry of expiry date ,
if allowed
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M Will always be “00”
41 Terminal I.D. ans 8 M M
42 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 ans 6 If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 56

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0320 0330
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M From original transaction
03 Processing Code n 6 M M Same as original transaction
04 Amount Transaction n 12 M From original transaction
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M M
13 Date, local transaction n 4 M M
14 Date, expiration n 4 O If original transaction had
22 POS Entry Mode n 3 M From original transaction
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M M From original transaction
38 Auth. ID Response an 6 O
39 Response Code an 2 M M From original transaction
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
60 Original Data ans ...999 O Message type, System trace
from original transaction
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 O If Inv./ECR Ref.# is selected
for this Card Defn. table
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 57

Settlement

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0500 0510
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M
03 Processing Code n 6 92000X 92000X For Initial Settlement request
96000X 96000x After b a t c h u p l o a d , i f
requested by host response
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
37 Retrieval Ref Number an 12 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
60 Batch Number ans 6 M Batch number of settle batch
62 Response Text ans …40 O May contain 2 lines of 20char
text for display and/or print
63 Batch Totals ans …90 M See Private field definitions
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

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 - 999
Capture card sale Amount an 12 12 $$$$$$$$$$cc
Capture card refund count an 3 3 000 - 999
Capture card refund Amount an 12 12 $$$$$$$$$$cc
Debit card Sale Count an 3 3 000 - 999
Debit card Sale Amount an 12 12 $$$$$$$$$$cc
Debit card Refund Count an 3 3 000 - 999
Debit card refund Amount an 12 12 $$$$$$$$$$cc
Authorise Card Sale Count an 3 3 000 - 999
Authorise Card Sale Amount an 12 12 $$$$$$$$$$cc
Authorise Card Refund Count an 3 3 000 - 999
Aut h o r i s e C a r d R ef u nd an 12 12 $$$$$$$$$$cc
Amount

Thailand Smart Card Standard Application Version 1.0 Page 58

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

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0800 0810
Bit Map b 64 M M
03 Processing Code n 6 92000X 92000X X- Extra Control Bit = 0
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
39 Response Code an 2 M M From original transaction
41 Terminal I.D. ans 8 M M
62 Logon Data ans 6 O See note below

Notes :

Field Name Attribute Byte Content

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

PIN Working Key b 64 8 PIN working key encryption under
terminal master key
MAC Working Key B 64 8 MAC working encrypted under terminal
master key

Thailand Smart Card Standard Application Version 1.0 Page 59

Balance Inquiry

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0100 0110
Bit Map b 64 M M
03 Processing Code n 6 31A00X 31A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M M
13 Date, local transaction n 4 M M
15 Date, settlement n 4
22 POS Entry Mode n 3 M ‘051’= Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 M
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
52 PIN Data b 64 O DES algorithm
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 If Inv./ECR Ref.# is selected
for this Card Defn. table
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 60

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

Message Type ID n 4 0100 0110
Bit Map b 64 M M
03 Processing Code n 6 30A00X 30A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
15 Date, settlement n 4
22 POS Entry Mode n 3 M ‘051’=Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 M
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
52 PIN Data b 64 O DES algorithm
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 61

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.

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra control
bit
04 Amount Transaction n 12 M M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
15 Date, Settlement n 4
22 POS Entry Mode n 3 M ‘051’= Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M Req.RRW is from origin resp
M Resp RRW updat RRW for
transaction in terminal batch
38 Auth. ID Response an 6 O
39 Response Code an 2 M From original transaction
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
52 PIN Data b 64 O DES algorithm
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 62

Debit Sales

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
03 Processing Code n 6 02A00X 02A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
15 Date, Settlement n 4
22 POS Entry Mode n 3 M ‘051’= Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 M
37 Retrieval Ref Number an 12 M M
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
52 PIN Data b 64 O DES algorithm
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 63

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
03 Processing Code n 6 02A00X 02A00X Void of Debit Transaction
A-acct. select, X extra ctl bit
04 Amount Transaction n 12 M M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
15 Date, Settlement n 4
22 POS Entry Mode n 3 M ‘051’=Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z 37 M
37 Retrieval Ref Number an 12 M Req.RRW is from origin resp
M Resp RRW updat RRW for
transaction in terminal batch
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
52 PIN Data b 64 O DES algorithm
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 64

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0400 0410
Bit Map b 64 M M
03 Processing Code n 6 M M Same as the transaction
being reversed
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
15 Date, Settlement n 4
22 POS Entry Mode n 3 M ‘051’= Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 M
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 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 ans 6 If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans ..256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 65

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0320 0330
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M From original transaction
03 Processing Code n 6 M M Same as original transaction
04 Amount Transaction n 12 M From original transaction
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M M
13 Date, local transaction n 4 M M
14 Date, expiration n 4 M From original transaction
22 POS Entry Mode n 3 M From original transaction
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
37 Retrieval Ref Number an 12 M M From original transaction
38 Auth. ID Response an 6 M M
39 Response Code an 2 M M From original transaction
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
60 Original Data ans ...999 M See note below
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 O If Inv./ECR Ref.# is selected
for this Card Defn. table
63 IC Card Information ans …256 O O
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Note :

Field Name Attribute Byte Content

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

Message Type an 4 4 Message Type from original transaction
System Trace No. an 6 6 System Trace from original transaction
Retrieval Ref. Number an 12 12 Retr. Ref. No. from original transaction

Thailand Smart Card Standard Application Version 1.0 Page 66

Settlement

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0500 0510
Bit Map b 64 M M
02 Primary Acc. Number n ..19 M
03 Processing Code n 6 92000X 92000X For Initial Settlement request
96000X 96000X After b a t c h u p l o a d , i f
requested by host response
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
37 Retrieval Ref Number an 12 M
39 Response Code an 2 M From original transaction
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
60 Batch Number ans 6 M Batch number of settle batch
62 Response Text ans …40 O May contain 2 lines of 20char
text for display and/or print
63 Batch Totals ans …90 M See Private field definitions
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

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 – 999
Capture card sale Amount an 12 12 $$$$$$$$$$cc
Capture card refund count an 3 3 000 – 999
Capture card refund Amount an 12 12 $$$$$$$$$$cc
Debit card Sale Count an 3 3 000 – 999
Debit card Sale Amount an 12 12 $$$$$$$$$$cc
Debit card Refund Count an 3 3 000 – 999
Debit card refund Amount an 12 12 $$$$$$$$$$cc
Authorise Card Sale Count an 3 3 000 - 999
Authorise Card Sale Amount an 12 12 $$$$$$$$$$cc
Authorise Card Refund Count an 3 3 000 - 999
Aut h o r i s e C a r d R ef u nd an 12 12 $$$$$$$$$$cc
Amount

Thailand Smart Card Standard Application Version 1.0 Page 67

C.3. Electronic Purse Transaction Message Format

Purse Reloading

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
02 Primary Acct Number n 19 C01 Manual key in, if allowed
03 Processing Code n 6 00A00X 00A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Manual key in, if allowed
22 POS Entry Mode n 3 M ‘051’=Smart Card with PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C03
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID field
in Card definition table entry
52 PIN Data b 64 O DES Algorithm
61 Product Codes ans 8 O If product codes are selected
for this card Defn. table
62 Invoice/ECR Reference ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 E-purse Information an 999 M M Private field definitions
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 68

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0400 0410
Bit Map b 64 M M
02 Primary Acc. Number n ..19 O From original transaction
03 Processing Code n 6 M M Same as the transaction
being reversed
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Manual entry of expiry date ,
if allowed
22 POS Entry Mode n 3 C03 “051”= Smart Card with
PIN
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M Will always be “00”
41 Terminal I.D. ans 8 M M
42 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 ans 6 If Inv./ECR Ref.# is selected
for this Card Defn. table
63 E-purse Information ans ..256 O O Private field definition
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 69

Purse Transfer to Account

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0200 0210
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 Manual card entry,if allowed
03 Processing Code n 6 20A00X 20A00X A-acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Manual entry of expiry date ,
if allowed
22 POS Entry Mode n 3 C03 “050”= Smart Card
24 Network Int’l. ID n 3 M M From NII field entry in card
definition table entry
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 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 ans 6 M If Inv./ECR Ref.# is selected
for this Card Defn. table
63 E-purse Information ans ..256 M M Private field definitions
64 Message Authentication b 64 O O If MACs are selected in his
Code Card Defn. table entry

Thailand Smart Card Standard Application Version 1.0 Page 70

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0220 0230
Bit Map b 64 M M
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 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Should be absent for
Smartcard read
22 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 00
35 Track 2 Data z ..37 C02 Should be absent for
Smartcard read
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M Will always be “00”
41 Terminal I.D. ans 8 M M
42 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 ans O If Invoice/ECR Ref. # is
6 selected for this Card
Defn. table
63 E-purse Information ans 256 M M Private field definition
64 Message Authentication b 64 O O If MACs are selected in
code his Card Defn. table
entry

Thailand Smart Card Standard Application Version 1.0 Page 71

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0500 0510
Bit Map b 64 M M
03 Processing Code n 6 92000X 92000X Initial Settl. Request
96000X 96000X After batch upload, if
req. by host in response
to initia l settlement
request
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
24 Network Int’l. ID n 3 M M From NII field entry in
card definition table
entry
37 Retrieval Ref. Number an 12 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID
field 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 rate
63 Points Batch Totals ans 128 M Points batch Totals
63 Response Text ans 40 O May contain up to two
lines of 20 chars. Of text
for display and/or print
64 Message Authentication b 64 O O If MACs are selected in
Code his Card Defn. table
entry

Thailand Smart Card Standard Application Version 1.0 Page 72

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0220 0230
Bit Map b 64 M M
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 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Should be absent for
Smartcard read
22 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 00
35 Track 2 Data z ..37 C02 Should be absent for
Smartcard read
37 Retrieval Ref Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M Will always be “00”
41 Terminal I.D. ans 8 M M
42 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 ans O If Invoice/ECR Ref. # is
6 selected for this Card
Defn. table
63 Points Information ans 256 M M
64 Message Authentication b 64 O O If MACs are selected in
Code his Card Defn. table
entry

Thailand Smart Card Standard Application Version 1.0 Page 73

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0220 0230
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 Should be present for
Smartcard read
03 Processing Code n 6 02A00X 02A00X Void transaction
A - acct. select, X extra
control bit
04 Amount Transaction n 12 M
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Should be absent for
Smartcard read
22 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 00
35 Track 2 Data z ..37 C02 Should be absent for
Smartcard read
37 Retrieval Ref. Number an 12 M
38 Auth. ID Response an 6 M
39 Response Code an 2 M Will always be “00”
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID
field in Card definition
table entry
61 Product Codes ans O If product codes are
8 selected for this card
Defn. table
62 Invoice/ECR Reference ans O If Invoice/ECR Ref. # is
6 selected for this Card
Defn. table
63 Points Information ans 256 M M
64 Message Authentication b 64 O O If MACs are selected in
Code his Card Defn. table
entry

Thailand Smart Card Standard Application Version 1.0 Page 74

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0600 0610
Bit Map b 64 M M
02 Primary Acc. Number n ..19 C01 Should be present for
Smartcard read
03 Processing Code n 6 38A00X 38A00X X extra control bit
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
14 Date, expiration n 4 C01 Should be absent for
Smartcard read
22 POS Entry Mode n 3 051 “051” = Smartcard (pin
entry)
24 Network Int’l. ID n 3 M M From NII field entry in
card definition table
25 POS Condition Code n 2 00
35 Track 2 Data z ..37 C02 Should be absent for
Smartcard read
37 Retrieval Ref.Number an 12 M
38 Auth. ID Response an 6 O
39 Response Code an 2 O M Response code of Card
adjustment result
00 - Successful
51 - Decline
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor ID
field in Card definition
table entry
63 Card Update ans 256 M O Ca r d A d j u s t m e n t
Information
64 Message Authentication b 64 O O If MACs are selected in
Code his Card Defn. table
entry

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.

Thailand Smart Card Standard Application Version 1.0 Page 75

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.

Bit Field Name Attribute Req. Rsp. Comments

Message Type ID n 4 0500 0510
Bit Map b 64 M M
03 Processing Code n 6 92000X 92000X Initial Settle Request
96000X 96000X After batch upload, if
req. b y h o s t i n
response to initial
settlement request
11 System Trace Number n 6 M M
12 Time, local Transaction n 6 M
13 Date, local transaction n 4 M
24 Network Int’l. ID n 3 M M From NII field entry
in card definition table
entry
37 Retrieval Ref. Number an 12 M
39 Response Code an 2 M
41 Terminal I.D. ans 8 M M
42 Card Acc. I.D. ans 15 M From Card acceptor
ID f ield in Car d
definition table entry
60 Batch Number ans 6 M Bat c h n u mb er of
batch being settled
62 Points Issuance Rate ans 128 O New points Issue rate
63 Points Batch Totals ans 128 M Points batch Totals
63 Response Text ans 40 O May contain up to
two lines of 20 chars.
Of text for display
and/or print
64 Message Authentication b 64 O O If MACs are selected
Code in his Card Defn.
table entry

Thailand Smart Card Standard Application Version 1.0 Page 76

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 Points
3. Card Update Response: Associated with Host points
4. Batch Totals: Associated with Settlement request

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 - 999
Capture card sale Amount an 12 12 $$$$$$$$$$cc
Capture card refund count an 3 3 000 - 999
Capture card refund Amount an 12 12 $$$$$$$$$$cc
Debit card Sale Count an 3 3 000 - 999
Debit card Sale Amount an 12 12 $$$$$$$$$$cc
Debit card Refund Count an 3 3 000 - 999
Debit card refund Amount an 12 12 $$$$$$$$$$cc
Authorize Card Sale Count an 3 3 000 - 999
Authorize Card Sale Amount an 12 12 $$$$$$$$$$cc
Authorize Card Refund Count an 3 3 000 - 999
Aut h o r ize C a r d R ef u nd an 12 12 $$$$$$$$$$cc
Amount

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.

Thailand Smart Card Standard Application Version 1.0 Page 77

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 Systems
Version 3.1.1

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

EMV: May 31, 1998 Integrated Circuit Card Application Specification for
Payment 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 Application
Specification for Debit and Credit Version 1.0

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

Principles and techniques

ISO 9564-2:1991 Banking – PIN management and security – Approved

algorithms for PIN encipherment

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

IEC 512-2:1979 Specifications for electromechanical components for

electromechanical equipment - Part 2: Contact resistance
tests, 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: Location

of 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

Thailand Smart Card Standard Application Version 1.0 Page 78

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 half
duplex block transmission protocol

ISO/IEC 7816-3:1994 Identification cards - Integrated circuit(s) cards with contacts

- Part 3, Amendment 2: Protocol type selection (Draft
International 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 for
application 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 -Part

1: DEA

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

cipher algorithm

ISO/IEC 8825:1990 Information technology - Open systems interconnection –

Specification of basic encoding rules for abstract syntax
notation one (ASN.1)

ISO 8583:1987 Bank card originated messages - Interchange message

specifications - Content for financial transactions

ISO 8583:1993 Financial transaction card originated messages - Interchange

message specifications

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

character 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

Thailand Smart Card Standard Application Version 1.0 Page 79

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

cipher 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 Version 1.0 Page 80

 CHAPTER 10

AUTHORIZATION OF
THE ISSUE OF MULTI-PURPOSE STORED VALUE CARDS

10.1 The legal framework for the authorization of MPC schemes is contained in the
Banking (Amendment) Ordinance 1997 which came into full operation on 15
May 1997. This chapter describes the principles and criteria which the MA
will use in exercising his powers under the Ordinance for the authorization of
MPC schemes. In general, the purpose of the legislation is to provide that
only authorized institutions which have been approved by the MA may issue
MPCs. However, certain types of MPCs may be exempted from this
requirement.

10.2 Because the market of stored value cards is still evolving, the MA considers it
appropriate to set out relatively broad principles and criteria at this stage
which will be further refined in the light of future developments. These
principles and criteria will be applied to individual cases taking account of the
special features of individual schemes.

The legal framework

10.3 In section 2 of the Ordinance, a “multi-purpose card” is defined as a card on

which data may be stored in electronic, magnetic or optical form and for or in
relation to which a person pays a sum of money to the issuer of the card
(directly or indirectly) in exchange for:

(a) the storage of the value of that money, in whole or in part on the card; and

(b) an undertaking by the issuer (express or implied) that the issuer or a third
party will, on production of the card, supply goods and services (which
may include money).

10.4 A “single-purpose card” is one where the goods and services (which in this
case shall not include money) are provided only by the issuer of the card (and
not by a third party). The issue of single-purpose cards does not require
approval under the Ordinance.

10.5 In addition to the issuer of a card, the Ordinance also introduces the concept of
a “facilitator” who is defined in section 2(11) as a person who facilitates the
issue of a MPC by the provision to the issuer of valuable consideration the
value of which determines, whether in whole or in part, the extent to which the
issuer may provide the undertaking referred to in (b) in paragraph 10.3 above.
This definition would cover any person who provides value to an issuer of a
MPC which determines the extent to which the issuer can provide its
customers with electronic value. An “originator” who creates electronic value
and sells it to other banks for storage on cards issued by them would fall
within this category (which is similar to a note-issuing bank that prints bank
 notes and sells these to other banks for distribution to their customers).
However, a person who provides ancillary services which assist the issuer of a
MPC, such as advertising, payment collection services or electronic data
network facilities, will generally not be considered to be acting as a facilitator
for the purposes of the Ordinance. Persons who are uncertain as to whether
they may fall within the scope of the definition of facilitator are advised to
consult the MA.

10.6 Under section 14A(1), no person shall issue or facilitate the issue of a MPC
except an authorized institution which has been approved to do so under
section 16(3A)(a).

10.7 Licensed banks are deemed to be approved to issue or facilitate the issue of
MPCs. They need not therefore apply formally for approval though they
would be expected to discuss in advance with the MA any plans to issue a
MPC.

10.8 In addition, a special purpose vehicle whose principal business is or will be the
issuing or facilitating the issue of MPCs may apply under section 15(3) for
authorization as a DTC in order to be approved to conduct that business. This
provision means that non-banks may apply for approval through this route.
The MA envisages that two main types of entity would apply:

(a) service providers which wish to issue MPCs for the main purpose of
charging for the services they provide; and

(b) originators of electronic value who facilitate the issue of MPCs by

other persons.

10.9 The MA has the power under section 16(9) to impose conditions on the issue
of MPCs, including on the management of the money paid to the issuer of the
card and whose value is stored on the card (“the float”). In addition, the MA
can impose a requirement on an authorized institution to cease issuing or
facilitating the issue of MPCs. Such conditions can be applied to all
issuers/facilitators, including licensed banks.

10.10 Under section 2(14)(d), the MA may declare a stored value card, or a class of
cards, not to be a “multi-purpose card” for the purposes of the Ordinance.
This power may be used to exempt certain types of card from the approval
requirements described above. Any exemption would however be subject to
conditions set by the MA.

Principles and criteria for authorization

10.11 In applying the legal framework set out in the Ordinance, the MA will seek to
achieve the following objectives:

(a) to maintain the stability of the payment system (and thus of the
financial system as a whole); and
 (b) subject to the above, not to stifle developments which would promote
competition and innovation.

10.12 In keeping with the first objective, and bearing in mind that direct access to
the payment system in Hong Kong is confined to licensed banks, it is intended
that only licensed banks should have the ability to issue MPCs which are
unrestricted in terms of the goods and services which they can be used to
purchase. Such cards have “generally accepted purchasing power” and are
thus a close approximation to money. In keeping with the second objective,
however, it is intended that non-bank issuers should have the opportunity to
apply for approval to issue MPCs which are more limited in scope.

The authorization of non-banks

10.13 The MA will normally adopt the following principles in considering

applications for authorization and approval by non-bank issuers of MPCs:

(a) such cards should have a core use which is related to the business of
the owners of the vehicle which issues the card;

(b) there may however be a number of ancillary or incidental usages which

are intended to increase the convenience for card-holders. Such uses
will be subject to the approval of the MA in advance. The card may not
be used for other purposes without the consent of the MA;

(c) the card issuer will be expected to justify, and present an acceptable
business case for, the ancillary or incidental uses of the card; and

(d) the ancillary or incidental uses should not overwhelm the core use.
The issuer would be required to demonstrate that the other uses would
not exceed the core use in terms of the aggregate value of transactions.

10.14 In the case of non-banks, the actual entity to be authorized to issue or facilitate
the issue of MPCs would have to be a special purpose vehicle whose principal
business is the issue of MPCs (or facilitating such issue). This is necessary to
provide an identifiable balance sheet to which the capital adequacy and other
provisions of the Ordinance can be applied. It will also help to segregate the
assets backing the issue of the cards and reduce the possibility that other
creditors will have a claim on such assets.

10.15 A special purpose vehicle applying to be authorized as a DTC will be required

to meet the authorization criteria set out in the Seventh Schedule to the
Ordinance. These would include adequate financial resources, fitness and
propriety of management and controllers, adequate systems of controls, etc.
Applicants should therefore study Chapter 4 of the Guide on authorization
criteria.
10.16 The normal supervisory and statutory provisions which apply to DTCs will
apply to such special purpose vehicles except that money which is paid to an
issuer in return for storing its value on a MPC will not be subject to the
restriction on the minimum size and maturity of deposits which apply to DTCs.
It will be a condition of authorization that the vehicle will not engage in other
types of deposit-taking or lending business (although some purely incidental
taking of deposits may be allowed). The normal criterion that a DTC should be
at least 50% owned by a bank will not apply.

10.17 In considering applications for authorization, the MA will also have regard to
the following areas relating to the MPC scheme:

(a) the soundness of the scheme;

(b) the arrangements for management of the float; and

(c) the business plan.

The soundness of the scheme

10.18 In determining whether a scheme is sound, the MA would need to be satisfied

about features such as the following:

(a) the purpose of the scheme, including the range of uses;

(b) the security features, including the design of the microchip and the
encryption technology, any limit on the amount that can be stored on
the card and limits on transaction value;

(c) the risk management and internal control procedures, including those
relating to the creation and transfer of value, the issuance of cards and
the detection of fraud;

(d) contingency plans to deal with disaster recovery and compromise of

the scheme, e.g. as a result of fraud;

(e) the terms and conditions of the scheme, including the rights,
obligations and liabilities of the various parties involved (for example
arising from lost or stolen cards or from counterfeit value);

(f) the clearing and settlement arrangements; and

(g) the audit trail for transactions made with the card.
The arrangements for management of the float

10.19 An applicant must satisfy the MA that it has adequate risk management
policies and procedures for the management of the float to ensure that there
will be sufficient funds for the redemption of outstanding stored value. In
general, the MA will wish to be satisfied that the float will be managed in a
professional manner and that applicants have the requisite competence and
expertise in this area.

10.20 Applicants will be required to discuss with the MA their policies for float
management. Such policies should clearly describe how the liquidity
requirements for the scheme are determined and how the float will be
managed and invested to meet such requirements. The MA will need to be
satisfied that the types of investment which the issuer proposes to make are
appropriate having regard to the nature and liquidity needs of the scheme. The
various types of risk to which the float is exposed (e.g. credit, liquidity, market
risk) should be clearly identified along with the policies and procedures for
managing these risks.

The business plan

10.21 Prospective issuers should discuss their business plans with the MA in
advance. In reviewing the business plan of prospective issuers, the MA will
need to be satisfied that the scheme will be operated prudently and with
competence, and in a manner which will not affect the stability of the payment
system.

10.22 The business plan of prospective issuers should normally cover a 3-year time
horizon. It should include statistical information about the expected number
of cards to be issued, the average value expected to be stored on the cards, the
value of the float, the proposed range of uses of the card and the expected
annual value of transactions split between core and non-core uses.

10.23 Although licensed banks are not required to seek the approval of the MA to
issue MPCs, those which intend to do so should discuss their plans with the
MA in advance. This is to enable the MA to evaluate whether the proposed
MPC scheme is sound and will be managed prudently. In doing so, the MA
will have regard to the matters set out in paragraphs 10.17 to 10.22 above.

Principles and criteria for exemption

10.24 Non-bank entities which wish to issue MPCs will normally follow the
authorization and approval route described above. However, the legislation
provides for the MA to grant exemption from the approval process to certain
types of MPC. In general, it is envisaged that exemption would be granted
only where the risk to the payment system and to cardholders from a particular
card is considered to be slight and where it is considered unnecessary to
require the issuer to be authorized. In this connection, consideration would be
given to the extent to which the card in question fell technically within the
 definition of “multi-purpose card” but simply replaced an existing non-
regulated payment instrument such as travelers’ cheques.

10.25 In considering applications for exemption, the MA will apply the following
principles:

(a) applicants should:

(i) possess substantial financial strength (either in their own right

or as a result of parental support);

(ii) be in reputable ownership; and

(iii) be able to demonstrate technical competence to be able to

operate a card scheme in a safe and sound manner.

(b) there should be a limit to the risk of cardholders, for example by

limiting the maximum amount that can be stored on each card; and

(c) the card can only be used within a distinct and limited geographical
area, such as a university campus, and the number of cards that will be
issued is thus relatively small; or

(d) there is a more limited range of ancillary and incidental uses than with
“authorized” cards and a more direct connection between those uses
and the core use of the card.

10.26 For the purposes of principle (b), the maximum amount that can be stored on
an exempt card should normally be HK$1,000 or less. For the purposes of
criterion (d), the related ancillary and incidental uses are not expected to
exceed 15% of the aggregate value of transactions. These amounts will be
subject to variation from time to time.

10.27 In considering applications for exemption, the MA will require information

similar to that described in paragraphs 10.17 to 10.22 above. The MA will also
require issuers to submit information relating to their financial strength and
ownership structure. Any exemption granted by the MA may be subject to
conditions. The MA will exercise this power to require issuers of exempt
cards to provide it with statistical information on a regular basis, including
details of the number of cards issued, the aggregate amount of stored value,
the average amount of stored value per card, the number of transactions, and
the value of transactions split between core and non-core uses. Issuers may
also be required to include a warning in the application form or in other
materials relating to an exempt card, in a manner acceptable to the MA, that
the issuer is not subject to the on-going supervision of the MA. The MA will
reserve the right to withdraw an exemption or to vary the conditions attaching
to it. Normally, the MA will only withdraw an exemption if the issuer no
longer meets any of the criteria for granting an exemption as set out in
paragraphs 10.24 to 10.26 or breaches any of the conditions attached to the
exemption.
Application procedures

10.28 The general procedures for applications for authorization are set out in
Chapter 8 of the Guide. Applicants who wish to apply to be authorized for the
purpose of issuing a MPC should consult with the MA on the extent to which
Chapter 8 will be applicable to them and on the additional information which
the MA will require in relation to the card scheme. Prospective card issuers
who wish to apply for an exemption under section 2(14)(d) of the Ordinance
should also consult with the MA in advance. Annex 3 sets out the information
which is required to be submitted with an application for authorization or
exemption. Enquiries may be directed the Banking Development Department
of the HKMA.
 Unofficial Translation prepared by Baker & McKenzie
and with the courtesy of The Foreign Banks' Association
This translation is for the convenience of those unfamiliar with the Thai
language. Please refer to the Thai text for the official version.
------------------------------------------------------------------------

BANK OF THAILAND

10 February 2004

To Manager

All commercial banks

No. ThorPorThor. SorNorSor. (11) Wor. 378/2547 Re: Policy

Guidelines on Supervision of Electronic Money Services

1. Rationale

At present, there are some initiatives on offering electronic money services to

customers in order to purchase goods and services. The electronic money services are
also widely available in many countries.

The Bank of Thailand has anticipated benefits of the electronic money

business in Thailand, for example, benefits to technology development, and increase
of financial service efficiency and convenience to the public. Thus the Bank of
Thailand has considered its risk and developed these preliminary guidelines to ensure
that the commercial banks understand and use them as a basis to develop the
electronic money services that are consistent with the stable development of the
financial system, the financial institution system, and the payment system.

2. Contents

2.1 Characteristics of the electronic money

Electronic money, or known otherwise as Multipurpose Stored Value

Card, E-Purse, E-Wallet, or Smart Card, features three major characteristics as
follows.

1) Pre-paid - Consumers pay money in advance to electronic money

issuer
2) Stored Value - Amount of the advanced payment is stored in an
electronic media such as plastic card or other computer media
3) Multipurpose - Consumers may use the money paid in advance to
purchase goods or services from retailers determined by electronic money issuers.

BOT Notification No. 378-2547 (10-02-04) Page 1 of 1

 2.2 Risks and effects of the electronic money

The use of electronic money in the economy may pose certain risks
and effects to the financial system, the financial institution system, and the payment
system, to which the Bank of Thailand may determine policy guidelines to control
such risks and possible effects as follows:

2.2.1 Effects on the financial system

The use of electronics money in lieu of money issued by the

state may affect the central bank’s ability to control inflation and maintain economic
stability via two channels; namely,
- a money multiplier, which may increase due to a declining
demand in using banknote as a payment medium
- a money supply, which may increase due to an inclusion of
electronic money, which is one of the payment mediums, into the definition of money
supply, and the fact that the electronic money issuers use the money received in
advance in subsequent transactions.

Supervision guidelines

- Closely monitor and control the amount of electronic money

in circulation
- Require a reserve on the electronic money (if necessary)

2.2.2 Effects on the financial institution system and the payment

system

1) Liquidity risk: occurs when the electronic money issuers fail

to make payment at a time the collection is due as a result of mismanagement or
inefficient liquidity management.

Effects
- Income and payment ability of other relevant players such
as other financial institutions participating in the project or participating retailers
- Loss of money of consumers who have already made
advanced payment to electronic money issuers
- Consumer’s confidence in the system

Supervision guidelines
- Commercial banks offering the service must put in place an
appropriate risk management system
- The Bank of Thailand may determine certain conditions
governing the management of advanced money received (float), if necessary.

2) Operational risk: occurs when there is a deficiency in the

operation and the security system, as well as fraud of service providers or joint service
providers.

BOT Notification No. 378-2547 (10-02-04) Page 2 of 2

 Effects
- Information integrity and confidentiality
- Continuity in the service offering
- Credibility of the payment system and the financial
institution system
Supervision guidelines
- Commercial banks are to comply with guidelines
determined by the Bank of Thailand. For example, Guideline for Security of
Electronic Services and Practicing Guidelines for IT Outsourcing.
- Encourage and support the service providers to choose the
technology that meets international standard
- Require commercial banks to comply with the principles of
good governance

2.2.3 Other effects

1) Consumer protection
Since the electronic money services require consumers to pay
money in advance in exchange for the electronic money, consumer protection
therefore is paramount. To offer the service, one should take into consideration the
following:
- Scope of responsibilities of electronic money issuers,
retailers, and consumers in case of fraud, error, or loss of card
- Service fees
- Refund policies

Supervision guidelines
- Commercial banks offering electronic money services must
comply with the principles of corporate governance
- Transparent disclosure of the information on the services
and possible risks to the consumers and other relevant parties

2) Money laundering: certain forms of the electronic money

service may facilitate money laundering activities. For example, a system that allows
money to be transferred between customers without having to go through the service
provider’s system.

Supervision guidelines
- Transfer of money between customer to customer without
going through the service provider’s data system is prohibited
- The system must be able to trace back to the previous
transactions
- Limit the maximum amount of electronic money allowed
for use
- The electronic money can only be issued in Thai Baht and
be used in Thailand only

BOT Notification No. 378-2547 (10-02-04) Page 3 of 3

3. Scope of implementation

Commercial banks wishing to offer the electronic money services as

mentioned above must seek the Bank of Thailand’s permission in accordance with
Section 9 bis of the Commercial Banking Act, B.E 2505 and the amended. To grant
permission, the Bank of Thailand may take into consideration the possible effects and
risks that may incur, as well as the ability and credibility of other parties jointly
offering the service. However, in granting permission, the Bank of Thailand will
consider not to stifle the development of technology and business so that the country
will not lose its competitiveness in the market.

4. Effective date

These policy guidelines shall be complied from now on.

Please be informed and comply herewith.

Yours sincerely,

(M.R. Pridiyathorn Devakula)

Governor

Financial Institutions Strategy Department

Tel 0-2283-6938, 0-2283-6939

Note [ ] The Bank of Thailand will arrange a clarification meeting on__, at .

[x] No clarification meeting will be arranged.

BOT Notification No. 378-2547 (10-02-04) Page 4 of 4