Thailand Smart Card Standard Application Version 1.0 Page 1
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 2
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

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

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

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

• 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 8
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 :

Read and write access to ROM prohibited.
•
Low voltage detection.
•
Low frequency detection.
Thailand Smart Card Standard Application Version 1.0 Page 9
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:

EF EF EF EF
Thailand Smart Card Standard Application Version 1.0 Page 11
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.
•

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
•

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

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)

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

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

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

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

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

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

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
(e.g.1=citizen,2=civil,3=Driv)
1 Alpha num. M
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