# Presentation: 372356

## Contactless Fare Media System StandardPart 2: Contactless Fare Media Data Format and Interface Standard

**Tomas Oliva**

**Using Standards to Make **
**“****Smart” Choices**
**Talking Technology and Transportation (T3)**
- May 17, 2006

## UTFS Elements of Standardization

- PART 3 – Regional Central System Interface Specification

- PART 4 – System Security Planning and Implementation Guideline

**PART 2 – Contactless Fare Media Data Format and Interface** **Standard**

**Notes:**
At this time, there are five planned parts to the standard.

Part 1 – Introduction and overview (under development)
Part 2 – Contactless Fare Media Data Format and Interface Standard (final stages of balloting)
Part 3 – Central System Interface Specification (under development)
Part 4 – System Security Planning and Implementation Guideline (final stages of balloting)
Part 5 – Standard testing and certification (not started)

Note: In Part 3 of the Standard, the specification for the Regional Central System and depot computer interface does not exist. However, Part 3 primarily focuses on the structure and format of the data going to and from the RCC, not necessarily where it comes from.

This presentation is about Part 2 of the Standard.

## General Scope of the Part 2 Standard

**Applies to contactless card-based fare collection systems**
**Requires a Proximity Integrated Circuit Card (PICC) with a Card Operating System, compliant with ISO/IEC14443:2-4, with a minimum of 2KB of useable memory**
**Provides a specification for components of the data architecture to be used on the card**
**Uses existing standards and common practices where possible**

**Notes:**
General Scope of the Standard

Applies to contactless card -based fare collection system and currently requires the use of a card compliant with ISO/IEC14443:2-4. 

The standard does not (technically speaking) define the data architecture.  It does define the components of a data architecture – that is, it defines the data objects, the contents (data elements) and rules for use and updating of the data.  The specific architecture (number of files and how data is allocated among those files) is left up to the implementer.

## General Purpose of the Part 2 Standard

- Define a common set of data objects that enable compliant PICCs and Card Interface Devices (CID) to be used interchangeably with each other within a system
- Enable multiple transit agencies within a region to accept each others fare media
- Provide a set of data objects and associated software logic that, once developed, can be applied to other projects/systems

**Notes:**
General Purpose of the Standard

Define a common set of data objects that enable compliant PICCs and Card Interface Devices (CID) to be used interchangeably with each other within a system.
Enable multiple transit agencies within a region to accept each others fare media.
Provide a set of data objects and associated software logic that, once developed, can be applied to other projects/systems.

## Objectives of the Part 2 Standard

**Accommodate most known fare products and related services currently used in the US**
**Base card data components on open standards to enable open sourcing from multiple vendors**
**Ensure that new interface device technologies can be adopted within the core application infrastructure**

**Notes:**
The primary objectives in developing the Standard for the PICC and Proximity Coupling Device (PCD)/CID of the transit application are the following:

Ensure the PICC data architecture structure is flexible enough to accommodate the numerous fare products of an agency or of a region or both.
Ensure the PICC data structure and processing is based upon open standards whenever possible or applicable, enabling open sourcing of components from multiple vendors
Ensure transit application participants can adopt new interface device technologies within the core application infrastructure

## Advantages of Adoption

**Interoperability**
**Transit agencies can accept other agencies smart cards.**
**Agency systems can be procured at different times.**
**Reduced Cost**
**Reduced need for customization and **
**	****re-engineering.**
**Transit agencies can purchase equipment from multiple vendors (competitive procurement).**
**Potential to share costs through common operations.**

**Notes:**
Advantages of Adoption

Interoperability
Transit agencies can accept other agencies smart cards.
Agency systems can be procured at different times.
Reduced Cost
Reduced need for customization and re-engineering.
Transit agencies can purchase equipment from multiple vendors (competitive procurement).
Potential to share costs through common operations.

## Use of the Part 2 Standard

**The Standard is not sufficient to build a functioning system or to achieve interoperability; ****for example, agencies must also define:**
**PICC file structure** (Standard provides an example only)
**PICC data definition mapping** (need to make choices)
**List of fare products that will be accepted and processed by the system**
**Security is outside the scope of the Standard, although the data architecture does provide for the implementation of security schemes. **

**Notes:**
Following the Standard is not sufficient to build a functioning system or to achieve interoperability. In order to accomplish interoperability the components and processing mechanisms on the PICC must be specifically defined by the agencies participating in a regional transit card program, if they are not defined in the Standard.  These components and processing mechanisms include:

PICC File Structure
A mandatory PICC file structure is not defined in this Standard, however, Section 3.0 FILE STRUCTURE provides a suggested file structure implementation method.

PICC Data Definition Mapping
Specific PICC data objects and data elements are defined in Section 2.0 FF PICC DATA DEFINITION MAPPING  

PICC Memory Requirements
The quantity of electronic memory storage available from the PICC.  Section 1.1 (Transit PICC File Structure) defines the minimum PICC memory requirements.  Section 2.0 FF PICC DATA DEFINITION MAPPING defines the size of the data elements of each object and can therefore be used to calculate the minimum FF PICC memory requirements for any given system complying with this Standard. 

PICC APDU Command Set
The specific instructions that the PICC will recognize and be able to process.   Section 1.1 Transit PICC File Structure defines the minimum required standard command set. 

PICC and PCD/CID APDU Command Sequence
A required command sequence is not defined in this Standard. 

PCD/CID Order of Operations
A required logical sequence of the PICC processing is not defined in this Standard.

Note that security is outside the scope of the Standard, although the data architecture does provide for the implementation of security schemes. Part 4 of the Standard covers security, but that is only an informative reference, rather than standard.

## Mechanism for Adoption & Use

**Achieve consensus for UTFS adoption among participating agencies.**
**Define business rules for regional program participation (including ownership, governance, regional fare products, fee and revenue sharing).**
**Identify distinct messages and implementation approach to be used within the region.**

**Notes:**
Mechanism for Adoption and Use

Achieve consensus for UTFS adoption among participating agencies.
Define business rules for regional program participation (including ownership, governance, regional fare products, fee and revenue sharing).
Identify distinct messages and implementation approach to be used within the region.

KEY ELEMENTS OF FOCUS
AREAS OF COMPLEXITY
CAUTIONARY POINTS
CRITICAL ELEMENTS

## Key Terms in the Standards

**Following from ISO standards:**
**PICC: ****Proximity Integrated Circuit Card**
**PCD: Proximity Coupling Device **
**CID: Card Interface Device**

**Notes:**
Terms used in the standard (following from ISO standards):
- PICC: Proximity Integrated Circuit Card
- PCD: Proximity Coupling Device 
- CID: Card Interface Device
PLEASE DEFINE EACH.

## Card-Reader Transaction Overview

**Notes:**
Initiate communications with PICC.
Identify what’s on the PICC and where it is located (DIO). 
Identify PICC holder.
Determine if PICC is valid (including a check of the hotlist, autoload if appropriate, identify all the products on the PICC (PIO). 
Carry out transaction on the highest priority fare product (if a payment transaction) or add value.
Record transaction (where, when, what, etc.).

Once a transaction between a PICC and CID is completed, a transaction record is stored in theCID and then forwarded to the Regional Clearinghouse (Part 3 of the Standard) by way of the fare collection system.

## General Description

**The basic data architecture is built on a set of**** ****objects made up of**** ****a defined set of elements.**
**Each core object is 16 bytes in length.**
**Standard makes provisions for additional data through extensions to the core objects, which are also no longer that 16 bytes.**

**Notes:**

Each object is no larger than 16 bytes.
Objects may at times require more data that 16 bytes (128 bits). The Standard makes provisions for additional data through extensions to the core object.
Object can be grouped into a single file on the card.  

## Object Definition Format

**Objects are defined in a consistent format to assist in interpretation.**
**Each object is specified in its own section of the standard.**
**Object specification: **
**Includes a summary explanation of the object’s function, and a table listing the elements that are part of the object, along with heir size, potential values, position, and a description. **
**Concludes with a user’s information subsection that provides additional details about the elements that are part of the object.**

**Notes:**
Object definition format

Objects are defined in a consistent format to assist in interpretation.
Each object is specified in its own section of the standard.
Object specifications include a summary explanation of the object’s function, a table listing the elements that are part of the object, their size, potential values, position and a description. The object specification concludes with a user’s information subsection, which provides additional details about the elements that are part of the object.

## Core Objects

**Notes:**
The core objects that make up the card data structure are as follows:

1.      Directory Index Object  (DIO) - Mandatory
2.      Transit Application Profile Object  (TAPO) - Mandatory
3.      PICC Holder Profile Object (PHPO) – Mandatory, but extension is not.
4.      Product Index Object (PIO) - Mandatory
5.      Product Object, (i.e. transit purse (T-Purse), stored value, account linked or pass) – at least one is required (CLARIFY WHICH ONES ARE OPTIONAL AND WHICH MANDATORY).
6.      Add & Deduct Value History Object (A&DVO) – Optional (If have this set of objects, need two or more because there is a requirement for tear proofing).
7.      Transaction History Object  (THO) – Mandatory
8.      Extension Objects – One PIO extension is required.

Each object contains multiple data elements that define specific attributes to provide flexibility and comprehensive functionality within a card electronic transit application environment.

## Directory Index Object (DIO)

**Contains pointers that identify the location (file) in which most other data objects are stored**
**For each file, provides:**
**ID of the file**
**Size of the file**
**Type of file**
**Ownership (if applicable) of the file**
**A card normally contains only one DIO**
**Enables AFC system to quickly locate other data objects, while enabling the contents of data files to be flexible and dynamic**

**Notes:**
Directory Index Object

A card normally contains only one DIO.
Contains pointers that identify the location (file) in which most other data objects are stored.
Enables AFC system to quickly locate other data objects while enabling the contents of data files to be flexible and dynamic.

Provides the following information about each file on the card:
		ID of the file,
		Size of the file (from this, can calculate how many objects there are in the file. Need to look into the PIO to know what objects are in the file),
		Type of file,
		Ownership (if applicable) of the file (some files are owned by everybody).

## Transit Application Profile Object (TAPO)

**The TAPO is a required core object that identifies the PICC’s origin, issuer,**** ****and general capabilities/limitations required by the transit application.****  **
**The TAPO is encoded or configured at the PICC pre-issuance stage or the PICC initialization stage.**
**The PICC contains only one TAPO.**
**Sample elements:**** Country ID, Region ID, Issuer ID, Transit application expiry date, PICC Manufacturer ID, Issuing CID ID**

**Notes:**
Transit Application Profile Object

The TAPO is a required core object that identifies the PICC’s origin, issuer, general capabilities and limitations required by the transit application.
Sample elements:
Country ID, Region ID, Issuer ID, Transit application expiry date, PICC Manufacturer ID, Issuing CID ID.

The TAPO is encoded or configured at the PICC pre-issuance stage or the PICC initialization stage.
The PICC contains only one TAPO.

## PICC Holder Profile Objects (PHPO)

**The PHPO identifies the transit patron’s profile relative to their personal preferences for transit fare products and services**
- 	**The PICC contains only one PHPO. **
**An optional PHPO extension must be utilized for secret or private profile protection.**
**Sample elements:**** Fare class code, birth date of patron, language preference, start and end of profile, and associated discount**

**Notes:**
PICC Holder Profile Object

The PHPO identifies the transit patron’s profile relative to their personal preferences for transit fare products and services. 
The PICC contains only one PHPO. 
An optional PHPO extension must be utilized for secret or private profile protection.

Sample elements:
    Fare class code, birth date of patron, language preference, start and end of profile and associated discount.

## Add/Deduct Value History Objects (A&DVO)

**The A&DVO will record up to eight of the most recent add or Autoload (Unload) value transactions from the T-purse and/or stored value products.**
**The A&DVO is an optional object, although if used, at least 2 are required.**
**Sample elements:**** Payment type (cash, credit, recurring load, etc.), transaction date and time, value added or deducted, location where transaction took place.**

**Notes:**
The A&DVO is an optional history log.  The A&DVO applies only to stored value (T-purse) loads and unloads (no transactions).

Used to cover the possibility that the last add value transaction drops off the THO log (due to maximum number of transactions held in memory are exceeded). This saves the add value transaction in another place.

Implementation of this log capability provides for immediate patron feedback when a Customer Service Representative (CSR), is presented with the patron’s PICC to identify transaction activity. The CSR can read this history log (If the PICC is functional) to inform the patron of their recent activities in the case of a transaction dispute. 

## Transaction History Objects (THO)

**The THO contains up to 16 of the most recent transactions, after which the oldest transaction is overwritten.**
**Allows for up to 16 transaction types to be defined.**
**The THO is a required core object.**
**Sample elements:**** Fare product used, agency where PICC was used, is the transaction linked to the previous transaction (i.e. transfer rules), transaction value.  **

**Notes:**
Transaction History Objects

The THO contains up to sixteen of the most recent transactions after which the oldest transaction is overwritten.
Allows for up to 16 transaction types to be defined.
The THO is a required core object.

Sample elements:
    Fare product used, agency where PICC was used, is the transaction linked to the previous transaction (i.e. transfer rules), transaction value. 

## Transaction Types

**0 = Reserved **
**1 = Load**
**2 = Product Blocked **
**3 = Product Un-Blocked **
**4 = Validation or Deduction**
**5 = Validation or Deduction Date and Time Override **
**6 = Reserved**
**7 = Configuration Change**

**8   = Previous Transaction  Undone**
**9   = Reserved**
**10 = Reserved**
**11 = Negative List Status    Change**
**12 = Unload**
**13 = Reserved**
**14 = Reserved**
**15 = Out of Region T-Purse Use**

**Notes:**
There are 16 possible transaction types available through the THO.

0 = Reserved 
1 = Load
2 = Product Blocked 
3 = Product Un-Blocked 
4 = Validation or Deduction
5 = Validation or Deduction date and time Override 
6 = Reserved
7 = Configuration Change
8   = Previous transaction  Undone
9   = Reserved
10 = Reserved
11 = Negative List Status    Change
12 = Unload
13 = Reserved
14 = Reserved
15 = Out of Region T-Purse Use

## Product Index Object (PIO)

**A mandatory index of the transit fare products (defined by Product Objects) on a specific PICC application.**
**Provides summary details of the transit fare products currently stored on the PICC.**
**Enables AFC system to quickly identify products that might be applied to the current fare payment.**
**PICC contains only one PIO and one PIO extension but can have two additional extensions, if required.**
**Sample elements:****  PICC transaction sequence number (maximum of 127 transactions are tracked), fare product used in last transaction, product type codes.**

**Notes:**
Product Index Object

A mandatory index of the transit fare products (defined by Product Objects) on a specific PICC application.

Provides summary details of the transit fare products currently stored on the PICC.

Enables AFC system to quickly identify products that might be applied to the current fare payment.

PICC contains only one PIO and one PIO extension but can have two additional extensions, if required. Normally have to or 4 PIOs as need at least two copies for tear-proofing. 

Points to the last THO and add value logs.

Provides negative list status.

Sample elements:
PICC transaction sequence number (maximum of 127 transactions are tracked), fare product used in last transaction, product type codes.

WHAT IS THE RELATIONSHIP TO THO WHICH RETAINS 16 TRANSACTIONS. HOW DOES THAT WORK?

## Available Product Objects

**The Standard accommodates any fare products that are time-, prepaid ride/trip-, value-, or reward-based, and those with linked (e.g. bankcard) accounts.**
**A given fare product is represented by a single Product Object with or without object extensions. **
**There are 256 distinct Product Types available to each Agency (253 pass types, one stored value, one account linked and one AutoValue-based product).**
**Each Agency defines the Fare Product Type Codes, and the rules for use of those products.**

**Notes:**
There are 256 distinct Product Types available to each Agency (253 pass types, one stored value (or purse type), one account linked and one AutoValue based product type).

WHY IS THIS. WHY ONLY ONE OF THE STORED VALUE, ETC.

## Pass and Transfer Product Objects (P&TPO)

**Contains the required information or functionality and data representing either a pass or transfer product.**
**P&TPO is a core object required by the standard.**
**Sample elements:****  Whether the user has subscribed to Autoload, pass or transfer expiry date and time, number of remaining trips or rides, where the product is valid (i.e., specific zone)**

**Notes:**
Pass and Transfer Product Objects

Contains the required information or functionality and data representing either a pass or transfer product.
P&TPO is a core object required by the standard.

Sample elements:
    Whether the user has subscribed to Autoload, pass or transfer expiry date and time, number of remaining trips or rides, where the product is valid (i.e. specific zone).

## Stored Value and T-Purse Product Objects (SV&TPPO)

**Stored value objects are agency-specific.**
**The T-Purse is the regional stored value fare product, usually stored in local currency ($US).**
**When the PICC is initialized, SV&TPPO are usually set at 0.**
**Autoload feature can be enabled.**
**There can only be one instance of a T-Purse on a PICC.**
**Sample elements:**** Frequency of autoload, autoload threshold (trigger), autoload amount**

**Notes:**
Stored Value and T-Purse Product Objects

Stored value objects are agency specific.
The T-Purse is the regional stored value fare product, usually stored in local currency ($US).
When the PICC is initialized, SV&TPPO are usually set at 0.
Autoload feature can be enabled.
There can only be one instance of a T-Purse on a PICC.

Sample elements:
    Frequency of autoload, autoload threshold (trigger), autoload amount.

## Account Linked Product Object (ALPO)

**Used to define a fare product that is tied (“linked”) to a host-based account, such as a credit or debit card**
**Acts like a T-Purse product, except does not require pre-funding**
**There can be only one instance of an Account Linked product on a PICC**
**Sample elements:****  Accumulated value used in a particular day, definition of time period for which a transaction limit applies, time period start, number of transactions performed during time limit.**

**Notes:**
Account Linked Product Object

Used to define a fare product that is tied (“linked”) to a host-based account such as a credit or debit card.
Acts like a T-Purse product, except does not require pre-funding.
There can be only one instance of an Account Linked product on a PICC.

Sample elements:
   Accumulated value used in a particular day, definition of time period for which a transaction limit applies, time period start, number of transactions performed during time limit.

## Account Linked Reference Object (ALRO)

**The ALRO is an object containing the Account Linked Product reference information (e.g., bankcard number) that requires secure access.  **
**The ALRO object must occupy a dedicated file on the PICC with a separate security write key.**
**Sample elements:**** Daily limit of payments that can be performed “on account”, bankcard information from which payment is made, bankcard expiry date. **

**Notes:**
Account Linked Reference Object

The ALRO is an object containing the Account Linked Product reference information (e.g., bankcard number) that requires secure access.  
The ALRO object must occupy a dedicated file on the PICC with a separate security write key.

Sample elements:
   Daily limit of payments that can be performed “on account”, bankcard information from which payment is made, bankcard expiry date. 

## Autovalue Product Object (APO)

**Implemented when an agency or regional operator wants to provide incentives (rewards) for frequent use or bulk fare purchases.**
**Sample elements:  Type of autovalue product, accumulation of value units today, accumulation of value units this week, last week, 2 weeks ago, and 3 weeks ago. **

**Notes:**
Autovalue Product Object

Implemented when an agency or regional operator wants to provide incentives (rewards) for frequent use or bulk fare purchases.

Sample elements:
Type of autovalue product, accumulation of value units today, accumulation of value units this week, last week, 2 weeks ago and 3 weeks ago (provides for more granularity that this week, this month, etc.). 

## Evolution of the Standard

**Add provision for use of PICC products that don’t meet all of the requirements (Limited Use PICCs)**
**Develop an Implementation Guide**
**Develop Certification and Testing requirements**

**Notes:**
Standard Evolution

Add provision for use of PICC products that don’t meet all of the requirements (Limited Use PICCs).
Develop an Implementation Guide.
Develop Certification and Testing requirements.

## Review Points

**Comprehensive description of objects and their elements accommodating a broad range of fare collection related transactions.**
**Users have significant flexibility in selecting how to use the objects.**
**While the Standard does provide PICC specifications, the focus is on data formats and a standardized communication protocol with the CID. This opens up future possibilities for the implementation of other electronic form factors such as key fobs, mobile telephones fitted with contactless chips, etc.**

**Notes:**
Review Points

Comprehensive description of objects and their elements accommodating a broad range of fare collection related transactions.
Users have significant flexibility in selecting how to use the objects.
While the Standard does provide PICC specifications, the focus is on data formats and a standardized communication protocol with the CID. This opens up future possibilities for the implementation of other electronic form factors such as key fobs, mobile telephones fitted with contactless chips, etc.

## More Information

**Martin Schroeder, P.E., APTA**
_**[mschroeder](mailto:mschroeder@apta.com)**__**[@](mailto:mschroeder@apta.com)**__**[apta](mailto:mschroeder@apta.com)**__**[.com](mailto:mschroeder@apta.com)**_** **
**202-496-4885**