ISO/IEC 15693-3:2026

Cards and security devices for personal identification — Contactless vicinity objects — Part 3: Anticollision and transmission protocol

This document specifies: protocols and commands; other parameters required to initialize communications between a vicinity integrated circuit card and a vicinity coupling device; methods to detect and communicate with one card among several cards ("anticollision"); optional means to ease and speed up the selection of one among several cards based on application criteria. This document does not preclude the addition of other existing card standards on the vicinity integrated circuit card (VICC), such as ISO/IEC 7816-6 or others listed in this document.

Cartes et dispositifs de sécurité pour l'identification personnelle — Objets sans contact de voisinage — Partie 3: Anticollision et protocole de transmission

General Information

• Status: Published
• Publication Date: 06-May-2026
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Drafting Committee: ISO/IEC JTC 1/SC 17/WG 8 - Integrated circuit cards without contacts
• Current Stage: 6060 - International Standard published
• Start Date: 07-May-2026
• Due Date: 04-Sep-2027
• Completion Date: 07-May-2026

Relations

• Revises: ISO/IEC 15693-3:2019 - Cards and security devices for personal identification — Contactless vicinity objects — Part 3: Anticollision and transmission protocol
• Effective Date: 07-Sep-2024

Overview

ISO/IEC 15693-3:2026 is an international standard published by ISO and IEC that defines protocols and commands for communication between contactless vicinity integrated circuit cards (VICCs) and vicinity coupling devices (VCDs). This standard forms Part 3 of the ISO/IEC 15693 series for cards and security devices for personal identification, focusing specifically on anticollision procedures and transmission protocol for contactless identification cards designed for longer-range operation compared to proximity cards.

The main purpose of ISO/IEC 15693-3:2026 is to enable reliable, efficient communication with and selection of a specific card from among several present in the reader’s field. It includes detailed definitions of command types, data formats, security frameworks, card memory organization, and error handling. The standard also supports the integration of other card standards, such as ISO/IEC 7816-6, for interindustry data interchange.

Key Topics

• Anticollision Algorithms: Mechanisms to detect and communicate with one unique card among multiple VICCs in the reader’s field, preventing communication conflicts and ensuring accurate identification.
• Transmission Protocol: Bit-oriented, frame-based protocol detailing request and response formatting, including flags, command codes, data, and CRC.
• Initialization and Modes: Procedures for initializing communications and mechanisms for addressed, non-addressed, and select modes, allowing targeted operation with individual or groups of cards.
• Data Elements: Structure and use of key card identifiers, including unique identifier (UID), application family identifier (AFI), data storage format identifier (DSFID), and cyclic redundancy check (CRC) for data integrity.
• Security Framework: Optional features facilitating card and device authentication, secure messaging, and compatibility with cryptographic suites defined in the ISO/IEC 29167 series.
• Card Memory Organization: Guidelines for addressing and organizing card memory blocks, including lock status and security flags.

Applications

ISO/IEC 15693-3:2026 is widely applied in environments that require contactless identification technology at extended read distances. Key applications include:

• Access Control: Used in building, facility, and event access systems for efficient and secure personal identification.
• Library and Asset Management: Streamlines inventory management, check-in/check-out, and tracking of books or other assets using contactless cards or tags.
• Public Transportation: Supports mass transit, fare collection, and ticketing systems where rapid processing of multiple cards in proximity is essential.
• Healthcare and Medical Records: Ensures quick, contactless identification of patients and control of medical inventory in busy environments.
• Industrial Automation and Logistics: Identification and tracking of items, parts, or shipments in warehouses and manufacturing facilities.
• Retail and Loyalty Programs: Enables customer identification, membership verification, and usage of loyalty cards at checkout points.

The anticollision protocol and flexible, secure transmission make this standard suitable for deployments with high card densities and varied application requirements.

Related Standards

For full interoperability and to address various aspects of contactless identification, ISO/IEC 15693-3:2026 references and complements a range of standards, including:

• ISO/IEC 15693-1 and 15693-2: Define physical and air interface characteristics for vicinity cards.
• ISO/IEC 7816-6: Specifies interindustry data elements for integrated circuit cards.
• ISO/IEC 13239: Relates to high-level data link control and CRC calculation procedures.
• ISO/IEC 15418: Defines application identifiers and maintenance for automatic identification.
• ISO/IEC 29167 series: Provides cryptographic mechanisms for enhanced card security.

Organizations deploying contactless identification solutions are encouraged to consider the full ISO/IEC 15693 series and referenced standards for optimum system performance and compatibility.

Keywords: ISO/IEC 15693-3:2026, contactless vicinity cards, anticollision protocol, transmission protocol, VICC, VCD, card security standard, RFID standards, access control, personal identification, ISO standards for RFID.

Standards Content (Sample)

International
Standard
ISO/IEC 15693-3
Fourth edition
Cards and security devices
2026-05
for personal identification —
Contactless vicinity objects —
Part 3:
Anticollision and transmission
protocol
Cartes et dispositifs de sécurité pour l'identification
personnelle — Objets sans contact de voisinage —
Partie 3: Anticollision et protocole de transmission
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Symbols and abbreviated terms .2
4 Definition of data elements . 3
4.1 UID .3
4.2 AFI . .3
4.3 DSFID . .5
4.4 CRC .5
4.5 Security framework .6
5 VICC memory organization . 6
6 Block security status . 6
7 Overall protocol description . 7
7.1 Protocol concept.7
7.2 Modes .8
7.2.1 General .8
7.2.2 Addressed mode .8
7.2.3 Non-addressed mode .8
7.2.4 Select mode .8
7.3 Request format .9
7.3.1 General .9
7.3.2 Request flags .9
7.4 Response format .10
7.4.1 General .10
7.4.2 Response flags .10
7.4.3 Response error code .11
7.4.4 In-process reply response formats . 12
7.4.5 Waiting time extension request formats . 13
7.5 VICC states . 13
7.5.1 General . 13
7.5.2 Power-off state .14
7.5.3 Ready state .14
7.5.4 Quiet state .14
7.5.5 Selected state .14
7.5.6 Selected Secure state . . 15
8 Anticollision . 16
8.1 General .16
8.2 Request parameters . .16
8.3 Request processing by the VICC .16
8.4 Explanation of an anticollision sequence .18
9 Timing specifications .20
9.1 General . 20
9.2 VICC waiting time before transmitting its response after reception of an EOF from the
VCD . 20
9.3 VICC modulation ignore time after reception of an EOF from the VCD . 20
9.4 VCD waiting time before sending a subsequent request . 20
9.5 VCD waiting time before switching to the next slot during an inventory process .21
9.5.1 General .21

© ISO/IEC 2026 – All rights reserved
iii
9.5.2 When the VCD has started to receive one or more VICC responses .21
9.5.3 When the VCD has received no VICC response .21
9.6 VICC waiting time before transmitting a response for Write alike commands. . 22
9.7 Security timeout as used in the CS . 22
9.8 VICC replies as used in CS or extended functionalities . 22
9.8.1 General . 22
9.8.2 Immediate VICC reply . 22
9.8.3 In-process reply . 23
9.9 Waiting time extension reply . 25
10 Commands .26
10.1 Command types . 26
10.1.1 General . 26
10.1.2 Mandatory . 26
10.1.3 Optional . 26
10.1.4 Custom . 26
10.1.5 Proprietary . 26
10.2 Command codes . . 26
10.3 Mandatory commands . 28
10.3.1 Inventory . 28
10.3.2 Stay quiet . 28
10.4 Optional commands . 29
10.4.1 Read single block . 29
10.4.2 Write single block . 30
10.4.3 Lock block . 30
10.4.4 Read multiple blocks .31
10.4.5 Write multiple blocks .32
10.4.6 Select . 33
10.4.7 Reset to ready . 33
10.4.8 Write AFI . 34
10.4.9 Lock AFI . . 35
10.4.10 Write DSFID command . 35
10.4.11 Lock DSFID . . . 36
10.4.12 Get system information . 36
10.4.13 Get multiple block security status . 38
10.4.14 Fast read multiple blocks . 39
10.4.15 Extended read single block . 40
10.4.16 Extended write single block .41
10.4.17 Extended lock block .42
10.4.18 Extended read multiple block .43
10.4.19 Extended write multiple blocks . 44
10.4.20 Extended get multiple block security status .45
10.4.21 Fast extended read multiple blocks . 46
10.4.22 Authenticate .47
10.4.23 KeyUpdate . 48
10.4.24 Challenge . 49
10.4.25 ReadBuffer . 50
10.4.26 Extended get system information .51
10.5 Custom commands . 55
10.6 Proprietary commands . 55
11 Secured Communication.55
11.1 General . 55
11.2 AuthComm . 56
11.3 SecureComm . . 56
Annex A (informative) VCD pseudo-code for anticollision .58
Annex B (informative) Cyclic redundancy check (CRC) .59
Annex C (informative) Examples of crypto command sequence .62

© ISO/IEC 2026 – All rights reserved
iv
Annex D (normative) List of legacy commands .65
Bibliography .66

© ISO/IEC 2026 – All rights reserved
v
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and security devices for personal identification.
This fourth edition cancels and replaces the third edition (ISO/IEC 15693-3:2019), which has been technically
revised.
The main changes are as follows:
— extended IC manufacturer code.
A list of all parts in the ISO/IEC 15693 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
vi
Introduction
The ISO/IEC 15693 series describes the parameters for identification cards as defined in ISO/IEC 7810 and
the use of such cards for international interchange.
This document describes the anticollision and transmission protocols.
This document does not preclude the incorporation of other standard technologies on the card.
Contactless card International Standards cover a variety of types as embodied in the ISO/IEC 10536 series
(close-coupled cards), the ISO/IEC 14443 series (proximity cards) and the ISO/IEC 15693 series (vicinity
cards). These are intended for operation when very near, nearby and at a longer distance from associated
coupling devices, respectively.

© ISO/IEC 2026 – All rights reserved
vii
International Standard ISO/IEC 15693-3:2026(en)
Cards and security devices for personal identification —
Contactless vicinity objects —
Part 3:
Anticollision and transmission protocol
1 Scope
This document specifies:
— protocols and commands;
— other parameters required to initialize communications between a vicinity integrated circuit card and a
vicinity coupling device;
— methods to detect and communicate with one card among several cards ("anticollision");
— optional means to ease and speed up the selection of one among several cards based on application
criteria.
This document does not preclude the addition of other existing card standards on the vicinity integrated
circuit card (VICC), such as ISO/IEC 7816-6 or others listed in this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 7816-6:2023, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for
interchange
ISO/IEC 13239, Information technology — Telecommunications and information exchange between systems —
High-level data link control (HDLC) procedures
ISO/IEC 15418, Information technology — Automatic identification and data capture techniques — GS1
Application Identifiers and ASC MH10 Data Identifiers and maintenance
ISO/IEC 15693-1, Cards and security devices for personal identification — Contactless vicinity objects — Part 1:
Physical characteristics
ISO/IEC 15693-2, Cards and security devices for personal identification — Contactless vicinity objects — Part 2:
Air interface and initialization
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 15693-1, ISO/IEC 15693-2 and
the following apply.
© ISO/IEC 2026 – All rights reserved
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1.1
anticollision loop
algorithm used to prepare for and handle a dialogue between a vicinity coupling device and one or more
vicinity integrated circuit cards from several in its energizing field
3.1.2
byte
string that consists of 8 bits of data designated b1 to b8, from the most significant bit (MSB, b8) to the least
significant bit (LSB, b1)
3.1.3
payload
part of the message data which conveys information relating to the use of the security commands defined in
this document
Note 1 to entry: The message data is defined in the ISO/IEC 29167 series.
3.1.4
ResponseBuffer
vicinity integrated circuit card memory area where the result of a cryptographic operation is stored and can
be retrieved using a ReadBuffer command
3.1.5
Write alike
command or request resulting in a non-volatile change to the contents of the vicinity integrated circuit card
memory
3.2 Symbols and abbreviated terms
f frequency of operating field (carrier frequency)
c
AFI application family identifier
CRC cyclic redundancy check
CS Cryptographic Suite
CSI Cryptographic Suite Identifier
DSFID data storage format identifier
EOF end of frame
IC_Mfg IC manufacturer code defined in ISO/IEC 7816-6
LSB least significant bit
LSByte least significant byte
MSB most significant bit
MSByte most significant byte
RFU reserved for future use
© ISO/IEC 2026 – All rights reserved
SOF start of frame
UID unique identifier
VCD vicinity coupling device
VICC vicinity integrated circuit card
4 Definition of data elements
4.1 UID
The VICCs are uniquely identified by a 64 bits UID. This is used for addressing each VICC uniquely and
individually, during the anticollision loop and for one-to-one exchange between a VCD and a VICC.
The UID shall be set permanently by the IC manufacturer in accordance with Table 1.
Table 1 — UID format
MSB LSB
64 57 56 N+1 N 1
'E0' IC_Mfg IC manufacturer serial number
The UID comprises:
— the MSByte (bits 64 – 57) which shall be 'E0';
— the IC_Mfg (bits 56 – ‘N+1’) which shall be the identifier as specified in ISO/IEC 7816-6:2023, 7.2, where
N = 56 – L, and L is length in bits of IC_Mfg;
— a unique serial number (bits N – 1) assigned by the IC manufacturer.
4.2 AFI
The AFI represents the type of application targeted by the VCD and is used to extract from all the VICCs
present only the VICCs meeting the required application criteria.
It may be programmed and locked by the respective commands.
The AFI is coded on one byte, which constitutes 2 nibbles of 4 bits each.
The most significant nibble of the AFI is used to code one specific or all application families, as defined in
Table 2.
The least significant nibble of the AFI is used to code one specific or all application sub-families. Sub-family
codes different from 0 are proprietary.
Table 2 — AFI coding
AFI most AFI least
Meaning
significant significant Examples/comments
VICCs respond from
nibble nibble
‘0’ ‘0’ All families and subfamilies No applicative preselection
X '0' All sub-families of family X Wide applicative preselection
th
X Y Only the Y sub-family of family X
‘0’ Y Proprietary sub-family Y only
‘1' ‘0’, Y Transport Mass transit, bus, airline
NOTE X = ‘1’ to ‘F’, Y = ‘1’ to ‘F’.

© ISO/IEC 2026 – All rights reserved
TTabablele 2 2 ((ccoonnttiinnueuedd))
AFI most AFI least
Meaning
significant significant Examples/comments
VICCs respond from
nibble nibble
'2' ‘0’, Y Financial IEP, banking, retail
'3' ‘0’, Y Identification Access control
'4' ‘0’, Y Telecommunication Public telephony, GSM
‘5’ ‘0’, Y Medical
'6' ‘0’, Y Multimedia Internet services
'7' ‘0’, Y Gaming
'8' ‘0’, Y Data storage Portable files
'9' ‘0’, Y EAN-UCC system for Application Iden-
tifiers
'A' ‘0’, Y Data Identifiers as defined in ISO/
IEC 15418
'B' ‘0’, Y UPU (Universal Postal Union)
'C' ‘0’, Y IATA (International Air Transport Asso-
ciation)
'D' ‘0’, Y RFU
'E' ‘0’, Y RFU
‘F’ ‘0’, Y RFU
NOTE X = ‘1’ to ‘F’, Y = ‘1’ to ‘F’.
The support of the AFI by the VICC is optional.
If the AFI is not supported by the VICC and if the AFI_flag is set, the VICC shall not answer whatever the AFI
value is in the request.
If the AFI is supported by the VICC, it shall answer according to the matching rules described in Table 2.
Figure 1 shows the VICC decision tree for the AFI.

© ISO/IEC 2026 – All rights reserved
NOTE "Answer" means that the VICC answers to the Inventory request.
Figure 1 — VICC decision tree for the AFI
4.3 DSFID
The DSFID indicates how the data is structured in the VICC memory.
It may be programmed and locked by the respective commands. It is coded on one byte. It allows for instant
knowledge on the logical organisation of the data.
If its programming is not supported by the VICC, the VICC shall respond with the value zero ('00').
4.4 CRC
The CRC shall be calculated in accordance with ISO/IEC 13239.
The initial register content shall be all ones: 'FFFF'.
For examples, refer to Annex B.
The two bytes CRC are appended to each request and each response, within each frame, before the EOF. The
CRC is calculated on all the bytes after the SOF up to but not including the CRC field.
Upon reception of a request from the VCD, the VICC shall verify that the CRC value is valid. If it is invalid, it
shall discard the frame and shall not answer (modulate).

© ISO/IEC 2026 – All rights reserved
Upon reception of a response from the VICC, it is recommended that the VCD verifies that the CRC value is
valid. If it is invalid, actions to be performed are left to the responsibility of the VCD designer.
The CRC is transmitted least significant byte first (see Table 3).
Each byte is transmitted least significant bit first.
Table 3 — CRC bits and bytes transmission rules
LSByte MSByte
LSB MSB LSB MSB
CRC 16 (8 bits) CRC 16 (8 bits)
↑ first transmitted bit of the CRC
NOTE The probability that CRC 16 detects an error depends on the frame length and bit error rate. With a bit
error rate of 1E-4 the maximum frame length is less than 512 bytes.
4.5 Security framework
The security framework provides an interface to the crypto suites defined in the ISO/IEC 29167 series.
Crypto suites are identified by an 8-bit CSI defined in ISO/IEC 29167-1.
The security framework includes optional security features such as VICC or VCD Authentication, Mutual
Authentication, key update or secure messaging.
5 VICC memory organization
The commands specified in this document assume that the physical memory is organized in blocks (or
pages) of fixed size.
— Up to 65 536 blocks can be addressed.
— The block size can be of up to 256 bits.
— This leads to a maximum memory capacity of up to 2 MBytes (16 MBits).
The commands described in this document allow the access (read and write) by block(s). There is no implicit
or explicit restriction regarding other access method, e.g. by byte or by logical object in future revision(s) of
this document or in custom commands.
6 Block security status
The block security status is sent back by the VICC as a parameter in the response to a VCD request as
specified in Clause 10 (e.g. Read single block). It is currently coded on one byte but may be coded in 2, 4 and
8 as defined in future revisions of this document (see Table 4).
It is an element of the protocol. There is no implicit or explicit assumption that the 8 bits are actually
implemented in the physical memory structure of the VICC.

© ISO/IEC 2026 – All rights reserved
Table 4 — Block security status
Bit Flag name Value Description
0 Not locked
b1 Lock_flag
1 Locked
b2 to b5 Proprietary X Not defined in this document
Unless otherwise specified in future
revisions of this document
b6
See warning for legacy commands listed
in Annex D.
Unless otherwise specified in future
revisions of this document
b7
See warning for legacy commands listed
in Annex D.
Unless otherwise specified in future
revisions of this document
b8
See warning for legacy commands listed
in Annex D.
Only present if specified in future re-
b9 to b16 RFU visions of this document and the block
security status length_flag is set to (0,1)b
Only present if specified in future revi-
b9 to b32 RFU sions of this document and the block se-
curity status length_flag is set to (1, 0)b
Only present if specified in future revi-
b9 to b64 RFU sions of this document and the block se-
curity status length_flag is set to (1, 1)b
7 Overall protocol description
7.1 Protocol concept
The transmission protocol (or protocol) defines the mechanism to exchange instructions and data between
the VCD and the VICC, in both directions.
It is based on the concept of "VCD talks first".
This means that any VICC shall not start transmitting (i.e. modulating according to ISO/IEC 15693-2) unless
it has received and properly decoded an instruction sent by the VCD.
a) The protocol is based on an exchange of:
— a request from the VCD to the VICC;
— a response from the VICC(s) to the VCD.
The conditions under which the VICC sends a response are defined in Clause 10.
b) Each request and each response are contained in a frame. The frame delimiters (SOF, EOF) shall be
implemented as specified in ISO/IEC 15693-2. The maximum frame length is 8 192 bytes.
c) Each request consists of the following fields:
— flags;
— command code;
— mandatory and optional parameters fields, depending on the command;

© ISO/IEC 2026 – All rights reserved
— application data fields;
— CRC.
d) Each response consists of the following fields:
— flags;
— mandatory and optional parameters fields, depending on the command;
— application data fields;
— CRC.
e) The protocol is bit-oriented. The number of bits transmitted in a frame is a multiple of eight (8), i.e. an
integer number of bytes.
f) A single-byte field is transmitted LSB first.
g) A multiple-byte field is transmitted LSByte first, each byte is transmitted LSB first.
h) The setting of the flags indicates the presence of the optional fields. When the flag is set (to one), the
field is present. When the flag is reset (to zero), the field is absent.
i) RFU flags shall be set to zero (0).
VICC or VCD receiving RFU bits set incorrectly shall disregard the command or response except for
commands listed in Annex D. The VICC may respond with an error code.
7.2 Modes
7.2.1 General
The term mode refers to the mechanism to specify in a request the set of VICCs that shall answer to the
request.
7.2.2 Addressed mode
When the Address_flag is set to 1 (Addressed mode), the request shall contain the UID of the addressed VICC.
Any VICC receiving a request with the Address_flag set to 1 shall compare the received unique ID (address)
to its own ID.
If it matches, it shall execute it (if possible) and return a response to the VCD as specified by the command
description.
If it does not match, it shall remain silent.
7.2.3 Non-addressed mode
When the Address_flag is set to 0 (Non-addressed mode), the request shall not contain a unique ID.
Any VICC receiving a request with the Address_flag set to 0 shall execute it (if possible) and shall return a
response to the VCD as specified by the command description.
7.2.4 Select mode
When the Select_flag is set to 1 (Select mode), the request shall not contain a VICC unique ID.
The VICC in the Selected state or Selected Secure state receiving a request with the Select_flag set to 1 shall
execute it (if possible) and shall return a response to the VCD as specified by the command description.

© ISO/IEC 2026 – All rights reserved
Only the VICC in the Selected state or Selected Secure state shall answer to a request having the Select flag
set to 1.
7.3 Request format
7.3.1 General
The request consists of the following fields (see Figure 2):
— flags;
— command code (see Clause 10);
— parameters and data fields;
— CRC (see 4.4).
Figure 2 — General request format
7.3.2 Request flags
In a request, the field "flags" specifies the actions to be performed by the VICC and whether corresponding
fields are present or not. Table 5 to Table 7 show the Request flags definition.
It consists of eight bits.
Table 5 — Request flags 1 to 4 definition
Bit Flag name Value Description
0 A single sub-carrier frequency shall be used by the VICC.
b1 Sub-carrier_flag
1 Two sub-carriers shall be used by the VICC.
Low data rate shall be used unless specified otherwise in the defini-
tion of the command.
b2 Data_rate_flag
High data rate shall be used unless specified otherwise in the defini-
tion of the command.
0 The meaning for flags 5 to 8 is according to Table 6.
b3 Inventory_flag
1 The meaning for flags 5 to 8 is according to Table 7.
0 No protocol format extension.
Protocol format is extended.
Protocol
b4
— See warning for legacy commands listed in Annex D;
Extension_flag
— Reserved for future use for all other commands.
NOTE 1 Sub-carrier_flag refers to the VICC-to-VCD communication as specified in ISO/IEC 15693-2.
NOTE 2 Data_rate_flag refers to the VICC-to-VCD communication as specified in ISO/IEC 15693-2.

© ISO/IEC 2026 – All rights reserved
Table 6 — Request flags 5 to 8 definition when Inventory_flag is not set
Bit Flag name Value Description
The request shall be executed by any VICC according to the setting of
Address_flag.
b5 Select_flag
The request shall be executed only by the VICC in Selected state. The
1 Address_flag shall be set to 0 and the UID field shall not be included
in the request.
The request is not addressed. The UID field is not included. It shall be
executed by any VICC.
b6 Address_flag
The request is addressed. The UID field is included. It shall be exe-
1 cuted only by the VICC whose UID matches the UID specified in the
request.
The meaning is defined by the command description. It shall be set
to 0 if not otherwise defined by the command.
b7 Option_flag
1 The meaning is defined by the command description.
0 Unless otherwise specified in the command definition.
b8
1 See warning for legacy commands listed in Annex D.
Table 7 — Request flags 5 to 8 definition when Inventory_flag is set
Bit Flag name Value Description
0 AFI field is not present.
b5 AFI_flag
1 AFI field is present.
0 16 slots.
b6 Nb_slots_flag
1 1 slot.
The meaning is defined by the command description. It shall be set
to 0 if not otherwise defined by the command.
b7 Option_flag
1 The meaning is defined by the command description.
0 Unless otherwise specified in the command definition.
b8
1 See warning for legacy commands listed in Annex D.
7.4 Response format
7.4.1 General
The response consists of the following fields (see Figure 3):
— flags;
— one or more parameter fields;
— data;
— CRC (see 4.4).
Figure 3 — General response format
7.4.2 Response flags
The eight bit response flags field indicates how actions have been performed by the VICC a
...