Table of Contents - APTAStandards.com

SMART CARD STANDARDS
AND SPECIFICATIONS
RESEARCH
American Public Transportation
Association (APTA)
Version 1.2
San Francisco
March 2005
This report is confidential and intended solely for the use and
information of the company to whom it is addressed.

Table of Contents
1.0 INTRODUCTION....................................................................................................... 4
1.1 OBJECTIVES ............................................................................................................... 4
1.1.1 APTA Objective...................................................................................................... 4
1.1.2 Objectives of the Analysis....................................................................................... 6
1.2 APTA EFFORTS TO DATE ...................................................................................... 8
2.0 METHODOLOGY ..................................................................................................... 8
3.0 PROJECT SCREENING CRITERIA ...................................................................... 9
4.0 ANALYSIS OF STANDARDS AND SPECIFICATIONS.................................... 12
4.1 ISO/IEC 8583............................................................................................................ 13
4.1.1 Description of the Standard.................................................................................. 13
4.1.2 Applicability to UTFS Effort ................................................................................ 14
4.1.3 Common Message Structure ................................................................................ 14
4.1.4 Message Types ...................................................................................................... 16
4.1.5 Data Elements....................................................................................................... 18
4.1.6 Message Sequences ............................................................................................... 19
4.1.7 Security Requirements.......................................................................................... 20
4.1.8 Timing & Routing ................................................................................................ 20
4.1.9 Usability................................................................................................................ 22
4.2 INTEGRATED TRANSPORT SMARTCARD ORGANIZATION (ITSO)........ 23
4.2.1 Description of the Specification ............................................................................ 23
4.2.2 Applicability to UTFS Effort ................................................................................ 24
4.2.3 Common Message Structure ............................................................................... 24
4.2.4 Message Types ...................................................................................................... 25
4.2.5 Data Elements....................................................................................................... 29
4.2.6 Message Sequences ............................................................................................... 30
4.2.7 Security Requirements.......................................................................................... 30
4.2.8 Timing & Routing ................................................................................................ 30
4.2.9 Usability................................................................................................................ 30
4.3 OPEN FINANCIAL EXCHANGE (OFX) ............................................................. 31
4.3.1 Description of the Specification ............................................................................ 31
4.3.2 Applicability to UTFS Effort ................................................................................ 32
4.3.3 Common Message Structure ................................................................................ 33
4.3.4 Message Types ..................................................................................................... 34
4.3.5 Data Elements....................................................................................................... 36
4.3.6 Message Sequences ............................................................................................... 38
4.3.7 Security Requirements.......................................................................................... 38
4.3.8 Timing & Routing ................................................................................................ 39
4.3.9 Usability................................................................................................................ 39
4.4 VENDING EQUIPMENT INTERFACE (VEI) ..................................................... 40
4.4.1 Description of the Specification ............................................................................ 40
4.4.2 Applicability to UTFS Effort ................................................................................ 40
4.4.3 Common Message Structure ................................................................................ 41
4.4.4 Message Types ...................................................................................................... 42
4.4.5 Data Elements....................................................................................................... 44
4.4.6 Message Sequences ............................................................................................... 44

4.4.7 Security Requirements.......................................................................................... 45
4.4.8 Timing & Routing ................................................................................................ 45
4.4.9 Usability................................................................................................................ 45
4.5 CEN TC278 – INTEROPERABLE PUBLIC TRANSPORT FARE
MANAGEMENT SYSTEM ARCHITECTURE (IFMSA) .................................... 46
4.5.1 Description of the Standard.................................................................................. 46
4.5.2 Applicability to UTFS Effort ................................................................................ 46
4.5.3 Common Message Structure ................................................................................ 47
4.5.4 Message Types ...................................................................................................... 47
4.5.5 Data Elements....................................................................................................... 48
4.5.6 Message Sequences ............................................................................................... 48
4.5.7 Security Requirements.......................................................................................... 48
4.5.8 Timing & Routing ................................................................................................ 48
4.5.9 Usability................................................................................................................ 48
4.6 CUBIC TRANSPORTATION SYSTEM (CTS) CID EDGE INTERFACES ....... 48
4.6.1 Description of the Specification ............................................................................ 48
4.6.2 Applicability to UTFS Effort ................................................................................ 48
4.6.3 Common Message Structure ............................................................................... 48
4.6.4 Message Types ...................................................................................................... 49
4.6.5 Data Elements....................................................................................................... 50
4.6.6 Message Sequences ............................................................................................... 50
4.6.7 Security Requirements.......................................................................................... 50
4.6.8 Timing and Routing ............................................................................................. 51
4.6.9 Usability................................................................................................................ 51
4.7 TRANSLINK ® ........................................................................................................... 51
4.7.1 Description of the Specification ............................................................................ 51
4.7.2 Applicability to UTFS Effort ................................................................................ 52
4.7.3 Common Message Structure ................................................................................ 52
4.7.4 Message Types ...................................................................................................... 52
4.7.5 Data Elements....................................................................................................... 56
4.7.6 Message Sequences ............................................................................................... 56
4.7.7 Security Requirements.......................................................................................... 56
4.7.8 Timing and Routing ............................................................................................. 57
4.7.9 Usability................................................................................................................ 58
4.8 ERG APTA SPECIFICATIONS .............................................................................. 58
4.8.1 Description of the Specification ............................................................................ 58
4.8.2 Applicability to UTFS Effort ................................................................................ 58
4.8.3 Common Message Structure ................................................................................ 59
4.8.3.1 APTA System Header............................................................................................ 59
4.8.3.2 APTA System Common Header ............................................................................ 60
4.8.3.3 Variant Data .......................................................................................................... 61
4.8.4 Message Types ...................................................................................................... 61
4.8.5 Data Elements....................................................................................................... 65
4.8.6 Message Sequences ............................................................................................... 65
4.8.7 Security Requirements.......................................................................................... 65
4.8.8 Timing and Routing ............................................................................................. 65
4.8.9 Usability................................................................................................................ 65

4.9 REGIONAL INTEROPERABILITY STANDARD (RIS) PART 4....................... 66
4.9.1 Description of the Standard.................................................................................. 66
4.9.2 Applicability to UTFS Effort ................................................................................ 66
4.9.3 Common Message Structure ................................................................................ 67
4.9.3.1 PART 1 ............................................................................................................. 67
4.9.3.2 PART 2 ............................................................................................................. 67
4.9.3.3 PART 3 ............................................................................................................. 67
4.9.3.4 PART 4 ............................................................................................................. 68
4.9.4 Message Types ...................................................................................................... 68
4.8.6 Data Elements....................................................................................................... 74
4.8.7 Message Sequences ............................................................................................... 74
4.8.8 Security Requirements.......................................................................................... 74
4.8.9 Timing and Routing ............................................................................................. 74
4.8.9 Usability................................................................................................................ 74
5.0 FINDINGS................................................................................................................. 75
5.1 SUMMARY ............................................................................................................... 77
APPENDIX A RESEARCH CONTACTS ............................................................................. 80
APPENDIX B COMPLETED CRITERIA FORMS ............................................................ 83
VENDING EQUIPMENT INTERFACE (VEI) VERSION 1.2 ........................................ 83
ITSO ..................................................................................................................................... 84
ISO/IEC 8583........................................................................................................................ 85
CID EDGE INTERFACES ................................................................................................... 86
TRANSLINK ® ....................................................................................................................... 87
ERG APTA ............................................................................................................................ 88
RIS PART 4............................................................................................................................ 89
APPENDIX C DATA ELEMENTS........................................................................................ 90
VENDING EQUIPMENT INTERFACE (VEI) VERSION 1.2 ........................................ 90
ITSO DATA ELEMENTS .................................................................................................... 91
ISO/IEC 8583 DATA ELEMENTS..................................................................................... 95
CID EDGE INTERFACES DATA ELEMENTS................................................................ 97
TRANSLINK......................................................................................................................... 99
ERG APTA .......................................................................................................................... 102
RIS PART 4 ......................................................................................................................... 105
Appendix D RIS PART 4 RCH-To-RCH Messages........................................................ 106

Document History
Revision Reason For Issue Date
0.1 Initial Draft June 1, 2004
1.0 Final Draft July 30, 2004
1.1 Inclusion of RIS Part 4 and ERG December 15,
APTA-000 review and analysis 2004
1.2 Clarified scope of WP4 March, 2005
Page 1

Acronym List
ACCTRQ Activation Request Aggregate
APTA American Public Transportation Association
ASCII American Standard Code for Information Interchange
ASL Agent Session Layer
ATIP Australian Transport Interoperability Protocol
ATL Agent Transport Layer
CEN European Committee for Standardization
CEPS Common Electronic Purse Specification
CID Card Interface Device
CSC Contactless Smart Card
DAC Data Authentication Code
EFT Electronic Financial Transaction
EMV Europay Mastercard Visa
GSC-IS Government Smart Card Interoperability Standard
HOPS Host Operator or Processing System (ITSO)
HTML Hyper Text Mark Up Language
ICC Integrated Circuit Card
IFMSA Interoperable Public Transport Fare Management System
IOPTA Interoperable PT Applications for Smart Cards
IPE ITSO Product Entities
ISAM ITSO Specific SAM Module
ISO/IEC International Organization for
Standardization/International Electrotechnical Commission
ITSO Integrated Transport Smartcard Organization
MAC Message Authentication Code
MTC Metropolitan Transportation Commission
NIST National Institute of Standards and Technology
NTTWG National Ticketing and Tolling Workgroup
OFX Open Financial Exchange
OSI Open System Interconnection
PANY/NJ Port Authority of New York and New Jersey
PICC Proximity Integrated Circuit Card
POS Point of Sale
POST Point of Service Terminal
RCH Regional Clearing House
RIS Regional Interoperability Standard
SGML Standard Generalized Mark Up Language
SSL Secure Socket Layer
SV Stored Value
TCP/IP Transmission Control Protocol/Internet Protocol
TLV Tag Length Value
TVM Ticket Vending Machine
Page 2

Acronym List
UTFS Universal Transit Farecard Standards
VDV Verband Deutscher Verkehsunternehmen
VEI Vending Equipment Interface
WMATA Washington Metropolitan Area Transit Authority
XML eXtensible Markup Language
Page 3

1.0 INTRODUCTION
A growing trend in North America and abroad is a move towards regional fare
payment systems. Regional programs involve multiple transit systems linked by a
common fare payment instrument, most commonly a smart card. Open standards and
interoperability between different vendor equipment within an electronic fare payment
system have become highly desirable, and in some instances, necessary.
Interoperability is defined in this report as follows:
1. The ability of fare payment devices to exchange data with other vendor devices
within a single fare collection payment system
2. The ability for independently implemented multiple fare payment systems to be
operable with each other regardless of the underlying technology of the each
system
Transit agencies deploying smart card technology have very few industry standards to
facilitate interoperability and reduce their reliance on proprietary technology. Agencies
locked into proprietary technology have fewer procurement options and limited ability
to participate in regional systems. Moving forward, individual transit agency devices
and computer systems must be interoperable, and preferably based on open standards.
Today, transit agencies participating in regional programs, absent of industry wide
standards, have encountered difficulties such as the following:
• New systems
- Increased coordination required between participating agencies before
equipment procurements
- No independent source to compare different proprietary approaches
between competing vendors
- Less competitive initial marketplace
• Existing systems
- Post implementation equipment options are constrained
- Reduced ability to collaborate with non-transit industry partners due to
proprietary interfaces
- Few options for replacing non-performing vendors in mid-stream
1.1 Objectives
1.1.1 APTA Objective
The American Public Transportation Association (APTA) standards activity, through
the work of the Universal Transit Farecard Standards (UTFS) Program, defines interface
standards and best practices for use at transit systems throughout the United States that
provide uniform guidelines for system interoperability. The program aims to produce
standards and recommended practices to help transit systems deploying smart card
Page 4

technology to achieve interoperability with peer transit systems, and interoperability
between systems provided by different vendors. WP4 focuses primarily on producing
standards and guidelines to achieve the following objectives:
• Interoperability between a single transit system’s fare payment devices, and a
central system as illustrated in Exhibit 1.1-1.
• Interoperability (possibly limited) between two regional central systems as
illustrated in 1.1-2
These objectives support APTA’s goal of increasing interoperability among smart card
based transit systems in the U.S. This will benefit all transit systems by increasing
competition among vendors when expanding or upgrading their systems and
facilitating a staged regional rollout approach. The typical regional payment system
has four tiers of devices and computer systems:
• Regional Central System – Consolidates and processes transactions and
establishes settlement positions between agencies
• Headquarters Computer/Operator Central Tier – Utilized by participating
agencies to collect transactions for internal auditing and reporting and/or
control agency specific functionality. This tier is optional, as some agencies pass
data straight from the station/depot computer tier to the central system. In
addition, some systems will include an “audit computer” to audit the data in the
central system instead of a headquarter computer system.
• Station/Depot Computer Tier – Deployed in stations or bus depots to collect
usage data from fare payment devices and download configuration data to
devices from the Headquarters Computer/Operator Central Tier. This tier is
optional, as some agencies have opted to pass data straight from the Device Tier
to the Headquarters Computer/Operator Central Tier.
• Device Tier – Deployed on vehicles or at stations and other points where the
patron’s card interfaces with the system
The system tiers and related interfaces explained in this section are illustrated in
Exhibits 1.1-1 and 1.1-2.
Page 5

Regional System
Interface
Operator System
Interface
Station
Computer
Operator CID Interface Device
Interface
Exhibit 1.1-1 Regional Smart Card System Interface
Operator Central
System
Station
Computer
Faregate POS
TVM TVM
Terminal
Regional Central
System
Operator Central
System
Depot
Computer
Farebox
Smart Card
Validator
TVM
Operator Central
System
Smart Card
Validator
Rail Operator Bus Operator Bus Operator
Regional Central
System
Operator
Network
Exhibit 1.1-2 Regional Peer to Peer System Interface
Operator
Network
1.1.2 Objectives of the Analysis
Operator Central
System
Regional Peer-to-Peer
Interface
Page 6
Operator
Network
Operator
Network
Regional Central
System
Operator Central
System
Depot
Computer

This report encompasse s the review and analysis
of existing smart card interoperability
standards and smart card related specifications. The terms “Standard” and
“Specification” have been used per the document
titles as defined by their issuing
organizations.
The d ocuments listed in Exhibit 1.1-3 below were
reviewed in this effort.
Exhibit 1.1-3 Documents Reviewed
for This Report
Document Issuer Title Comments
Smart Card Industry Specifications
Innovatron-RATP-SNCF Calypso Smart card ticketing application
RKF RKF Specification for interoperable electronic
ticketing system
VDV VDV German public transit specification
ITSO ITSO Interoperable Transit Smart Card
Specification
IOPTA IOPTA Interoperable
Public Transit Application
SNCF Intercode Interoperable French ticketing
specification
OFX OFX Non-smart card XML specification
EMVCO EMV Interoperable contact smart card
specification for credit/debit cards
Global Platform Global Platform Multi application smart card platform for
financial institutions
NIST GSC-IS U.S. government smart card specification
CEPS
Smart Card Standards
CEPS Interoperable e-purse specification
CEN CEN TC278/IFM Interoperable fare management system
for public transit fare collection system
ISO/IEC ISO/IEC 8583 Message type and structure for financial
data exchange between banks and
financial institutions.
ISO/IEC ISO/IEC 14443 Contactless smart card standards
ISO/IEC ISO/IEC 7816
Contact-based smart card standards
NTTWG
Vendor Specifications
ATIP Australian, transit
ticketing and tolling
standard
Agent Systems VEI Control and monitoring of networked
equipment
Cubic CID Edge
Interfaces Message type and structures for device to
Central System data exchange
Mark IV EZ-Pass Message
Back office transaction and clearing and
Specifications
settlement messages
ERG APTA WG4 Transaction Device to Higher Level Computer Data
Definitions Elements/Messaging Specifications
Smart Card Project Specific Specifications
Washington
®
SmartTrip
Back office transaction exchange
Metropolitan Area Interoperability
Regional including clearing and settlement
Transit Authority
(WMATA)
Specification (SIRS)
Page 7

Document Issuer Title Comments
Metropolitan
®
TransLink Data and Transaction and data types for back office
Transportation
Messaging Format
messaging between CID and the higher
Commission
(MTC) Specification
tier
Port
Authority New Regional Interoperability RIS scope is defined to detail card, card to
York/New
Jersey Specification (RIS) Part 4 CID and agency Central Computer (ACC)
( PANY/NJ)
to Regional Clearing House (RCH)
specifications
OCTOPUS Documentation Relevant to Back-office clearing and settlement
the UTFS Effort
messaging
1.2 APTA Efforts
To Date
As a preliminary activity to the development of WP4 interface specifications, the UTFS
Financial Management Committee Systems Workpackage 4 developed the Interface
Specification Functional Description document that describes the following interfaces
in
detail:
• Regional System Interface
• Operator System Interface
• Operator to Operator Interface
Additionally, the Functional Description document defines the
functionality that must
be present for each interface in order to be deemed “compliant” by the future APTA
standards. The document also provides a framework to evaluate the required
functionality by the following criteria:
• Messages
• Data structures
• Commands
2.0 METHODOLOGY
For this research effort Booz Allen employed a methodology that first included an
identification
of relevant smart card standards and specifications (transit and nontransit).
The next step
in the methodology was to apply screening criteria to each of the
documents in order to determine their relevancy to the UTFS effort. The documents
that fulfilled the project screening criteria became candidates for detailed analysis.
The
methodology is illustrated in Exhibit 2-1.
Page 8

Identify S m art Card
Indust ry S ta ndards &
Sp ecif ica tions
Exhibit 2-1 Selection Methodology
Apply Project
Screening Criteria
Does it Meet
all the
Criteria?
Yes
Detailed An alysis
(Section 3.0) (Section 4.0)
Not Applicable to the
UTFS Effort
No
Relevant but Unable to
Obtain Permission
(Exhibit 3-1) (Exhibit 3-2)
Could Not Obtain –
Can’t Ascertain
Relevance
(Exhibit 3-2)
Booz Allen began this research effort by identifying a candidate pool of standards and
specifications that address smart card or electronic payment transactions. We selected
the documentation based on the following factors:
• Our work on various smart card implementations in North America,
Europe and
Asia/Australia
• Our relationships with vendors in the
smart card community
• Our knowledge of smart card or messaging specifications introduced in other
industries (e.g. financial, electronic toll collection) that may have applicability
to the
UTFS
effort
In addition, APTA, through its work in UTFS Workpackages, identified several
standards and specifications for analysis.
3.0 PROJECT SCREENING CRITERIA Two preliminary criteria were established to evaluate
each standard and specification in
order to identify those that qualified for further analysis.
• Relevance of the standard or specification to the UTFS efforts
- Tiers the standard or specification
is targeted to match WP4 focus (see
Exhibits 3.1-1 and 3.1-2)
• Availability for use by APTA
- Timeline for acquisition of the documentation
- Willingness of the issuing agency to share documentation with APTA
- Requirements for use (licensing fee or contractual agreements)
The
first criterion was applied to each of the standards or specifications; if the document
failed,
it was deemed not applicable to the UTFS effort. If the standard or specification
passed
the first criteria, the second was applied. If it failed the second criteria it fell into
one
of the categories in Exhibit 3-2. The disposition for each of the standards and
specifications is documented in the discussion and exhibits of this section.
Page 9

Exhibit 3-1 lists the standards or specifications that did not meet the initial project
screening criteria, and were determined not applicable to the UTFS, based on their card
level interoperability foc us.
Exhibit 3-1 Not Applicable to APTA’s Efforts
Title
Sm art Card Specifications
Description of Non-Applicability
Calypso Card architecture and device-to-card interface
specification
RKF Card architecture and device-to-card interface
specification
Intercode Card architecture and device-to-card interface
specification
VDV (Interoperability Standard In
Card architecture and device-to-card interface
Germany)
Smart Card Specifications (non-Transit)
specification
EMV (Europay MasterCard Visa) Card architecture and device-to-card interface
specification
Global Platform Smart card multi-application card platform
CEPS (Common Electronic Purse
Specification)
Card based universal purse application specification
GSC-IS (Government Smart Card
Card architecture and device-to-card interface
Interoperability Standard)
specification
Exhibit 3-2 illustrates the standards or specifications that are deemed relevant to the
UTFS effort by passing the first project screening criteria. However, attempts to contact
project sponsoring organizations to obtain the necessary documentation were either
unsuccessful (as of December, 2004) or permission for APTA’s use was not granted.
Therefore, these documents failed the second screening criteria.
Exhibit 3-2: Documentation That Failed Second Criteria
Document Issuer Title Comments
Smart Card Standards
NTTWG ATIP Standard is incomplete
Smart Card Specifications
IOPTA IOPTA Unable to obtain, Relevance is unknown
Smart Card Project Specific Specifications
Octopus OCTOPUS No Response from the Issuer
At the time of the release of this report, explicit authorization is still being worked on
and has not been worked out for the inclusion of the SmartTrip® Interoperability
Regional Specification (SIRS).
Page 10

The standards and specifications that passed the two initial screening criteria qualified
for further analysis. The results of the analysis are presented in Section 4.0.
Page 11

4.0 ANALYSIS OF STANDARDS AND SPECIFICATIONS
Each of the standards and specifications in this section were analyzed for their
adherence to the criteria outlined in Section 3.0 and their overall relevance to the
UTFS
effort.
The information presented in this section was obtained through various
including:
channels
• Discussions with transit operator personnel, smart card equipment
vendors and
project managers
• A review of public information (web sites and project documents)
• Booz Allen’s
direct involvement through engagements with the planning, design
and implementation of many of the regional fare payment systems.
Exhibit
4-1 illustrates the documentation that met the entire project screening criteria
explained in Section 3, and are included in the analysis presented in this section.
Exhibit 4-1 Documentation That Met All Criteria
Document Issuer
Smart Card Standards
Title Comments
European Committee for
Standardization (CEN)
Smart Card Specifications
CEN TC278/IFM
Analyzed in detail
ITSO Integrated Transport
Smartcard
Organization (ITSO)
Analyzed in detail
Smart Card Standards (non-Transit)
International Standards
Organization (ISO/IEC)
ISO/IEC 8583 Analyzed in detail
Smart Card Specifications (non-Transit)
OFX
Vendor Specifications
Open Financial
Exchange (OFX)
Analyzed in detail
Agent Systems Vending Equipment
Interface (VEI)
Analyzed in detail
Cubic CID Edge Interfaces Analyzed in detail
ERG APTA WG4
Transaction Definitions
Analyzed in detail
Smart Card Project Specific Specifications
Metropolitan
Transportation
Commission (MTC)
®
TransLink
Analyzed in detail
Port Authority New Regional
Analyzed in detail
York/New Jersey Interoperability
(PANY/NJ)
Specification (RIS)
Part 4
Page 12

These standards and specifications were subjected to detailed analysis in order to assess
their level of applicability to UTFS WP4 efforts. The established criteria for the level of
applicability were developed based on the input from the APTA Financial Committee’s
Interface
Specification Functional Description and Booz Allen’s experience in
implementing regional fare payment systems.
The criteria included:
• Common Message Structure that is supported by all data exchange
• Message Types that are applicable to UTFS WP4 proposed messages
• Data Elements that are specific to the transit industry
• Message Sequences that support an organized flow of data
• Security Requirements to allow for the protection of sensitive transit data and the
fiscal integrity of the larger payments scheme implemented for all participant in a
region
• Timing and Routing that dictates the operational requirements of the system
• Usability of the standard or specification by APTA
The following sections include the detailed analysis for each of the standards
and
specifications listed in the Exhibit 4-1.
4.1 ISO/IEC 8583
4.1.1 Description of the Standard
ISO/IEC
8583 is designed as an interface standard enabling messages to be exchanged
between systems that employ different application specifications. This standard offers
application designers freedom from overall design
constraints because messages can be
converted
to the format of this interface for international interchange to take place.
This international standard uses a concept called bitmap, whereby each data element is
assigned a pos ition indicator in a control field (or bitma p). A “1” in the assigned
position indicates the presence of a data element in a specific message, and a “0” in the
assigned
position, indicates the absence of a data element. This will allow application
designers to choose variable length data elements and messages, and the flexibility to
utilize data element types that are best suited for a specific application.
The standard is designed to
accommodate real-time “request-response,” and batch and
file
transfer type information exchange. It can also be utilized for both peer-to-peer and
centralized settlement schemes due to its flexible design.
ISO/IEC 8583 specifies a well-defined message structure, and message format and
content.
It is widely used in the financial industry, particularly in the handling of all
credit and debit card transactions among financial institutions and merchants around
the world.
Page 13

Though the majority of the messages and related data elements have been designed for
financial transaction interchange, they share some commonalities with public transit
electronic fare payment transactions.
4.1.2 Applicability to UTFS Effort
ISO/IEC 8583 lacks transit industry specific data elements and message types that need
to be defined by APTA. The addition of this new information requires their submission
to ISO/IEC, the international standards body that controls and maintains the changes to
the standard. The timeline for an effort such as this is largely unknown, but estimated
to be lengthy. For all the benefits offered, this standard may serve as a model for
UTFS
WP4 efforts.
Of all the standards and specifications analyzed, ISO/IEC 8583 is the most established
and widely implemented standard throughout the world. Financial data exchange
of
all magnetic stripe based credit card transactions follows this standard. Following the
advancements in the card technologies, ISO/IEC 8583 has been updated to
accommodate mostly contact based smart card transactions. Its financial industry focus
led
to the presence of a variety of clearing and settlement transactions exchanged
between entities. Though it is mostly used for on-line real time “request-response”
type
transactions, the standard provides details for batch
and file transfer mechanisms.
4.1.3 Common Message Structure
ISO/IEC 8583 provides a common message structure, which defines three main sections
for
each message as illustrated in Exhibit 4.1-1.
Exhibit 4.1-1 Common Message Structure
Message Type Message Bitmap(s) Data Elements
Message type consists of two elements, a version number and a message type identifier.
The version number is allocated to indicate the version of the ISO/IEC 8583 standard
followed by the interchange. The message type identifier is a three digit numeric field
identifying the following:
• Message class
• Message function
• Transaction originator
Message class identifies whether it is a financial, administrative, or network
management type of a message. Message function specifies if it is a request, response,
notification or advice. The transaction originator digit identifies the originator of the
message (e.g., issuer or acquirer).
Page 14

Although there is no “one-to-one” relationship between UTFS defined
message types
and
ISO/IEC 8583 defined message classes, this standard provides a flexible model, or
foundation
to further define transit industry related data elements in its body.
The
second element in the message structure defines whether it contains one or two
bitmaps.
A “1” in the bitmap indicates the presence of the corresponding data element
in the message. Each bitmap has 64 bits, thus two bitmaps can provide the total of 128
data
elements, as defined by the standard. The first (primary) bitmap is mandatory and
represents
the most frequently used data elements. The presence of the secondary
bitmap is signified by a “1” in bit 01 of the primary bitmap.
Bitmaps provide the application providers with the flexibility of choosing among a
greater pool of data elements for varying industry segments, however, they tend to
add
extra
overhead to the transaction speeds, especially in real-time data processing
environments. The effects of this overhead may not be as significant for backend,
processing environments such as clearing and settlement or reporting that are not as
time sensitive as card to reader transactions.
Messages are constructed using the message bit map as an index of present data
elements. There are three types of data elements:
• Primitive data element
• Constructed data element
• Composite data element
Primitive data elements represent a single piece of information, whereas the constructed
data element consists of a fixed number of sub-elements, all of which must be present.
Composite data element consists of a large number of sub-elements. Most of these sub-
elements fall into industry related categories such as auto rental data, or airline data. In
order to define these categories, the concept of a “dataset” has been introduced. All
the
sub elements in
a composite data element are divided into a certain number of datasets,
each
of which relates to an industry and contain a dataset identifier. The structure of a
dataset is based on the message structure explained in this standard. There is also a
provision
for identifying sub-elements using the TLV data encoding method as an
alternative to using a second level bitmap. Each composite data element can therefore
contain a variable number of different datasets and can include both TLV and bitmap
formats as illustrated in Exhibit 4.1-2.
Page 15

Dataset
Identifier
4.1.4
Message Types
Exhibit 4.1-2 Composite Data Element
Dataset
Length
The standard provides the following general message classes, some of which can
be
applied
to back end transaction types for public transit as defined by UTFS WP4.
• Authorization Messages
• Verification Messages
• Financial Presentment Messages
• Financial Accumulation Presentment
• File action messages
• Reversal Message Class
• Chargeback message class
• Reconciliation message class
• Administrative message class
• Error messages
• Fee collection messages
• Network Management messages
• Key management messages
The following sections addresses the relevance and application of the messages to the
message types defined by the UTFS WP4 in
the Interface Specification Functional
Description.
4.1.4.1 Transaction
Data
Composite Data Element
Dataset Sub Optional TLV
Bitmap(s)
Element Sub Elements
The MTI 240, Financial Presentment Notification Messages have been designed to
communicate the financial data for an approved transaction amount for billing or
posting purposes. This
message type can be applied to Fare Card Usage and Add Value
Transaction types defined by UTFS. The message has 37 optional and mandatory data
elements. (See Appendix C for a full list of data elements in this message)
In addition to its standard financial transaction message types, this standard allocates
further
sub-classification for an electronic purse transaction type within the financial
presentment message class.
Page 16

4.1.4.2 Card Management Data
The standard provides MTI 800 series network management message class to control
the following types of network management activity:
• System condition management, which is used to establish and report system
availability and to give instructions
pertaining to message handling during
periods of system unavailability
• System security management, which is used to control security aspects of the
interchange system
such as key and password management and security alerts.
These messages may be used as part of a security procedure, e.g., automatic
periodic key changes
• System accounting management, which is used to identify the end of a
reconciliation period. These messages may be used as part of
a reconciliation
process
• System audit controls management, which is used to test integrity of interchange
links and/or used as a part of an integrity check or failure recovery scheme
• Batch and file transfer header and trailer control management, which is used
to
denote the start and/or end of batch or file transfer
File Action Instruction/Notification Messages (362/340) can be utilized to inform the
receiver of a file action to be completed. The sender can periodically specify
that the
receiver
acknowledge the receipt of the most recently sent group of instruction
messages. The Da ta Record data element present in these
message classes is utilized for
the
actual transfer of data and may or may not be based on the message types identified
in this standard. Data Record data element is variable length and its structure and the
content can be specified by the parties involved in the exchange. This allows parties
in
the transmission to further define the requirements of the Data Record data element,
allowing the File Action Instruction/Notification messages to be utilized for Card
Management transactions as proposed by the WP4. The types of file actions that are
defined by the standard
are listed below:
• Add record
• Change record
• Delete record
• Replace record
• Inquiry
• Replace file
• Add file
• Delete File
• Card administration
• Reserved for private
use
Page 17

4.1.4.3 System and Device Data
The system and device data related messages are not addressed by this standard.
However, the MTI 300 series File Action message class (including 362/340), as
explained in the previous section, provides some flexibility to achieve the functionality
similar to what is proposed by the Interface Specification Functional Description. The
File Action messages
are used to:
• Add, change,
delete or replace a file or record
• Inquire into a file
• Perform card administration (such as reporting lost or stolen cards)
Therefore
this message class can be utilized for Negative List, Hotlist, CID Parameter
update
and Application Update messages proposed by the WG4.
4.1.4.4 Event Data
Similar
to the schema in the System and Device Data section, there is no specific
coverage for this message type in this standard. The MTI 300 series File Action Message
class (including 362/340)
can also be utilized to carry event data in the Data Record
data element of the message.
Further definition of the structure, format and content of
this
data element would be required for the event data transmission.
4.1.4.5
Peer to Peer Clearing & Settlement
The ISO/IEC 8583 provides support for bo th peer-to-peer and central system based
clearing and settlement schemes. The reconciliation message class supports the
exchange of data between
two institutions to reach agreement on financial totals. The
calculation of the Amount Net Reconciliation data element is achieved by netting
the
debit and credit amounts in the reconciliation message. The standard
defines two types
of reconciliation:
• Checkpoint reconciliation
• Final reconciliation
Checkpoint reconciliation period is defined by the Reconciliation Indicator field in the
message. A final reconciliation period is ident ified with the Date Reconciliation field
and contains any number of checkpoint reconciliation periods. The Reconciliation
Data
Primary
of 12 parts contains all the individual values needed to calculate the net
reconciliation in the Amount Net Reconciliation data element.
4.1.5 Data Elements
Bit 55 is the Integrated Circuit Card (ICC) data element and is a special form of
composite data element used to transmit ICC related data. If the data is in accordance
Page 18

with ISO/IEC 7816-6, there is no requirement for a dataset identifier or dataset bitmap
as these functions are covered by the ISO/IEC 7816-6 TLV coding structures. The result
is that the dataset identifier is replaced by the “T” element, the dataset length object
by
the “L” element, and the sub elements by the “V” element. Data that is not compliant
with the ISO/IEC 7816-6 can still be submitted in this
field as long as it follows the
standard composite data element structure as defined by the standard as illustrated in
Exhibit 4.1-3.
Exhibit 4.1-3 Standard Composite Data Element Structure
Dataset
Identifier
Field 55 ICC Related Data
Dataset
Length
Dataset
Bitmaps
Sub
Element
Exhibit 4.1-4 contains a sample application of the ICC field with the transit industry
related data elements.
Exhibit 4.1-4 Sample Structure of Field 55
Field 55 ICC Data
Name Value Description
Dataset Identifier 71 Fare Transaction
Dataset Length 512 Total length of the sub-elements present
Dataset Bitmap 0110000001100000 Indicates the following fields that are present
Sub-elements
Transit Application Profile Object
Product Index Object
Pass and Transfer Object
Transaction History Object
Dataset Identifier 43 Load Value Transaction
Dataset Length 384 Total length of the sub-elements present
Dataset Bitmap 0001010000100000 Indicates the following fields that are present
Sub-elements
Stored Value (SV) Product Object
Add Value Transaction History Object
Transaction History Object
4.1.6 Message Sequences
The standard provides detailed sequences for message exchange and routing rules.
Typically messages consist of a “request-response” pair that is initiated by either card
issuers or acquirers, as illustrated in Exhibit 4.1-5. There are provisions for message
repetitions when original request message is not responded. Additionally, the standard
Page 19

defines instruction, notification and advice message types for unique operating
conditions. “Request-Response” message pairs were originally intended for exchange
between an operator central system and a regional central system. However,
depending on the system architecture, the message pairs can be configured for
exchange between two operator central systems.
Operator Central
System
4.1.7 Security Requirements
Exhibit 4.1-5 Request Response Pair
Regional Central
System
Request/Response Request/Response
Request/Response
Operator Central
System
The standard mandates th e last bit position within any message bit map to be reserved
for
the Message Authentication Code (MAC) data element to validate
the source and
the
text of the message between the sender and the receiver. The standard also makes
reference to ISO/IEC 9807 (Banking and Related Financial Services) for message
authentication.
4.1.8 Timing & Routing
ISO Standard 8583 defines two alternative information exchange schemes including
examples to accommodate transfer of data, in a batch or a file transfer format, in
addition to the standard real-time “request-response” messages. These alternative
approaches can be especially beneficial in a back-end information exchange, where a
real time transfer of data to the higher tier or the central system is not as critical. These
two alternatives provide a viable foundation for information exchange between both
intra
agency system components and different central systems that operate on a peer-topeer
basis. Therefore these exchange schemes are applicable to the UTFS efforts.
ISO/IEC 8583 describes a file transfer process that is designed to allow transfer of larger
volumes of data in the minimum number of messages. The file transfer consists of
submission of a group of file action messages (300 series), where the total number of
Page 20

these messages constitutes a file. The File Name data element in the message indicates
the name of the file to be updated
at the receiver’s location. The Data Record data
element
in each one of these messages contains data from a number of business
transactions. The data contained in the Data Record data element may, or may not be
based on the message types identified
in this standard. The structure of this data
element
is left to the parties involved in the exchange. A file transfer is initiated with a
network message set (804/814), followed by a series of file action (340)
messages and
ended with another network message, as illustrated
in Exhibit 4.1-6.
Device
Or
Station/Depot
Computer
Exhibit 4.1-6 File Transfer Process
804
814
340
340
350
804
814
N times
File
Operator Central
System
or
Regional Central
System
Batch transfer allows transaction details to be sent as a series of notification, or
instruction messages with an optional reconciliation transaction. The Batch Transfer
does not require a response message for every message sent. Control is maintained by
the use of notification, or instruction acknowledgement messages, which may be sent
periodically within the transmission of a batch. There are no specific message types
needed to support the Batch Transfer. It is achieved
by the use of the existing message
types provided
by the standard.
The batch transfer is initiated by an 804/814 network management messages that define
transfer related control data such as number of messages contained in the batch. In the
example flow illustrated in Exhibit 4.1-7, a series of Financial Presentment Notification
Messages (240) are used in the batch transfer.
Page 21

ACQUIRER
4.1.9 Usability
Exhibit 4.1-7 Batch Transfer Process
804
814
240
240
250
804
814
N times
BATCH
ISSUER
ISO 8583 is a standard developed in ISO Technical Committee #68, which is represented
by the Accredited Standards Committee X9, Inc., also referred to as ASC X9, in the US.
Due to the organizational structure of ISO, APTA can pursue its adoption efforts by
becoming
a member of X9.
The following fee schedule is based on the membership level and effective the fiscal
year of September 1 – August 31:
Category A – Board Membership and Full Privileges $8,000
Category B - Voting Privileges $4,750
Category C - Limited Voting $2,500
Category D – Non Voting $1,150
Category E -- Workgroup Only $ 400
Membership applications are usually processed in 24-48 hours. There is no cost
involved in obtaining (or adapting to transit) the standard for membership categories A,
B and C. However, the members can only distribute the standard within their own
organization. Members can request changes to the standard and the length of the change process
depends upon urgency of the
change. Typically, the review and approval process takes
somewhere between three months to a year, based on the type of changes to the
standard,
which are reviewed every 5-6 years.
The
use of the standard by non-members is subject to royalties, which are based on the
amount of information extracted from the standard. The process of using
the standard
for non-members involves a written request identifying the parts of the standard
intended
for use.
Page 22

Phone
interviews and/or email correspondence were used to obtain this information,
and
it is accurate as of July 2004. However, if APTA is interested in using any parts of
the standard, formal negotiations are necessary.
4.2 Integrated Transport Smartcard Organization (ITSO)
4.2.1 Description of the Specification
The
International Ticketing Smart Card Organization (ITSO) was founded in 1998 as
collaboration between various UK Passenger Transport Authorities
addressing the lack
of
suitable standards for interoperable smart card ticketing. ITSO was formed to build
and maintain a specification for secure end-to-end interoperable ticketing transactions,
utilizing relevant ISO/IEC and emerging
European Committee for Standardization
(CE N ) standards.
The ITSO set of specifications is advisory and not
binding. They aim to provide a
platform and the toolbox for the provision of interoperable contactless smart card
public
transport ticketing and related services in the UK. The specification is divided
into ten parts to cover the various entities involved
in a typical fare payment system:
• Part 0 – Concept and Content
• Part 1 – General Reference
• Part 2 – Customer Media Data and Customer Media Architecture
• Part 3 – Terminals
• Part 4 – Host Operator
or Processing System (HOPS)
• Part 5 – Customer Media Data
Record Definitions
• Part 6 – Message Data
• Part 7 – ITSO Security Subsystem
• Part 8 – ITSO Specific SAM Module (ISAM) Detailed Operation
• Part 9 – Communications
• Part 10 – Customer Media Definitions
The emphasis of this analysis is on the Parts 4, 5 and 6 due to the scope of this project
and the objectives of the WP4. The back office messages are designed to allow
flexibility
for adopting the specification for either peer-to-peer, or central system
clearing and settlement operations.
ITSO has deliberately opted to minimize data storage space requirements in order to
allow organizations the most flexibility. This is especially critical where the data
storage space is at a premium, such as in a bus driver controller module. To achieve
this, data fields
mainly have fixed sequences and lengths, freeing them from the
requirements
of a TLV type of encoding such as the one defined in ANS.1 specification.
However, the specification still allows the use of TLV coding in number of ways at
several levels when desired.
Page 23

4.2.2 Applicability to UTFS Effort
The ITSO specifications are very applicable to the UTFS WP4 efforts for the following
reasons: • Detailed coverage for all the components involved in a fare collection system
• Transit industry
specific messages and data elements
• Smart card oriented architecture
• Availablity to APTA
• Easily adaptable by APTA
Despite its advantages, ITSO does have some disadvantages:
• ITSO has not been implemented in a public transit environment
• ITSO defines Security Access
Module (ISAM) currently provided through a
single vendor
• No support for clearing and settlement messages
• Adoption of specification may cause impact on other APTA Workpackage efforts
4.2.3 Common Message Structure
ITSO
uses the ISO/IEC/ENV 14904 model for the data messages described in the
specification. Message Header:
The ITSO message header (including the frame header) contains:
• Message sender identification
• Message recipient identification
• Unique message
identifier
• Starting and ending
sequence numbers
• Stored Value
deductions and additions
• Message Authentication
Code (MA
Message Body and Transaction Data Blocks:
The message body consists of ITSO Transaction Data Blocks, each of which includes the
following data elements:
• Sequence Number
• Date and time stamp
• Data, or transaction record
• MAC Certificate based on the first three fields of the data block
Page 24

The ITSO message body consists of individual transaction blocks,
each one representing
a single business transaction, or device event as illustrated in Exhibit 4.2-1.
Message Header Message Frame
ITSO Message Header
Exhibit 4.2-1 ITSO Message
Structure
Frame Header Message Body
Seq Time Stamp Data MAC
Transaction
Data
Blocks
Message Code Count of Destinations Destinations Data Content
The
data portion of the
transaction data blocks is dependent upon the message type and
c an be configured to send to multiple
destinations. This provision allows flexibility to
separate “on-us” and “not on-us” transactions at the card reader level, and route them
to their respective destinations if desired. Individual transaction data blocks
can
transmit
multiple transactions, essentially acting as a file or batch transfer
of
information.
Listed below are the parts of the Data or the transaction record component of the
transaction
data block:
• Message Code
• Count of destinations
• Destinations
• Data content
The actual data elements are contained within
the data content component of the
tr ansaction record.
4.2.4 Message Types
The ITSO specification provides the data flows and processes for card issuer, product
owner, and retailer and transit service provider.
The specification provides for data to
be directed to any of the following entities:
• A single entity (HOPS)
Page 25

• A number of entities
• Proprietary scheme data
transmission systems
Every message consists of 12 standard fields with a total of 34 bytes and a set of
additional fields based on the type of message. Listed below are the main ITSO
message types:
• ITSO Shell
• IPE Administration
• Card Issue Records
• ITSO ID
• Stored Value
• Charge to account
• Loyalty
• Predefined ticket and journey ticket
• Refund
• Journey Record
• Exception
• Miscellaneous
4.2.4.1 Transaction
Data
Stored value use and load transactions are treated different than the non-stored value
load transactions. In general, pass and ticket-book loads are treated as new product
creations and require addition of product type specific data to the message. The ITSO
product ty pes are illustrated
in Exhibit 4.2-2.
Page 26

Exhibit 4.2-2 Product Types
Type Code IPE (Product) Title
0 Private Entry within ITSO Directory
16 ITSO ID
2 Stored Value
3 Loyalty Type 1
4 Charge to Account
17 Loyalty Type 2
22 Pre-defined Ticket (Area Based)
6 Pre-defined ticket with days selection and action list capability
23 Pre-defined specif ic journey ticket
7 Pre-defined specif ic journey ticket with multi-ride and action list capability
24 Pre-defined specific journey ticket including reservation and restrictions
8 Pre-defined specific journey
ticket including reservation
and restrictions
with action list capability
25 Travel related Voucher
9 Travel related Vouc her with multi-use and
action list capability
26 Open system tolling
10 Open system tolling with multi-use and action list capability
In non-stored value product usage and loads, the messages are structured
in the
following sequence:
• Common data (required)
• Stored Use data (Present when the product supports free transfers)
• Product Specific Data (presence dependent on product type)
Product specific data includes the following additional elements to the 53-byte long
common data that is required in the message as described
in Exhibit 4.2-3.
Exhibit 4.2-3 Product Specific Data
Product Type Additional Bytes
6,22 37 and 2 Variable Length fields
7,23 59
8, 24 57 and 2 variable length fields
9, 25 34
10,26 26
4.2.4.2 Card Management Data
The ITSO Shell is the ITSO application with a file structure, directory entries and a
security schema loaded onto the smart card platform. The ITSO Shell transactions fall
into one of the following four groups:
• Creating an ITSO Shell
• Activating an ITSO Shell
Page 27

•
Create/amend ITSO ID
• Deleting an ITSO Shell
The Creating ITSO Shell message would be the equivalent of an initialization message,
while Activating ITSO Shell is the equivalent of an issuing transaction. The
Create/Amend ITSO ID message is designed to transmit cardholder specific data (see
Appendix C) and would represent both the Registration and Personalization messages
of UTFS. The Interoperability List Transaction is intended to exchange operating
parameters between the host and the CID. Even though the specification allows the
definition of implementation specific parameter types, the following list contains the
currently set-up parameter tables:
• Card Type
Parameters
• Peak Times
• Public Holidays
• Transfers
• Rebates
• Loyalty Rules
• Currency
• Zone Table Reference
• Zone Table Bitmap
• Sale Price
• Format Version Code parameters
• Change Instructions
4.2.4.3 System and Device Data
HOPS
to POST Configuration messages are designed to update or change the main
devic e and application related parameters between a central system and a CID as
illustrated
in Exhibit 4.2-4.
Exhibit 4.2-4 HOPS to POST Configuration Messages
Capability Values
Location 0=Not Used
1=Fixed
2= mobile
or RFU
Security 0= Not Used
1=Not tamper proof,
2=Tamper Proof,
3= Tamper proof and no radiation
Communication 0= Not Used
1= Offline,
2=permanently online
3= dial out capability,
4=dial in/polled capability
Page 28

Capability Values
or RFU
Product Priority Selection Prioritization according to a table
Message Security 0=Not Used
1=Messages Saved after
Transmission
2= Messages Not Saved after
Transmission
RFU
Printing Capability 0=Not Used
1=Receipt Printer Available
RFU
Cardholder Display 0=Not Used
1=Display Facing Cardholder
RFU
Maximum Purse Value 0=Not Used
1=Cannot Modify
2=Can modify
IPE Priority Selection 0=Not Used
1=Prioritization According to
parameter table
2= Prioritization According to
customer stated preference
RFU
The device level commands are intended for very high-level device configuration
settings and not for low-level device hardware status data, or parameter update.
4.2.4.4 Event Data
ITSO
does not define any device level message types.
4.2.4.5 Peer to Peer Clearing & Settlement
Since
the clearing and reimbursement arrangements may vary dramatically between
schemes, ITSO does not define financial settlement between entities. Settlement is
beyond the scope of this specification.
4.2.5 Data Elements
The specification provides a wide variety of data elements that represent most product
types and entities offered in Europe and North America. ITSO includes 34 fixed length
standard data elements (fields) that are present in every message, and supplemented
with transaction specific data based on the message type. The fields that are not utilized
by a particular implementation should be “0” filled and presented in messages where
required. This may create messages with lengths up to 100 bytes per message.
Page 29

4.2.6 Message Sequences
The structure of data within messages is designed to support error-free transmission in
that steps are taken to ensure that system is able to determine that losses may have
occurred or data otherwise corrupted. A positive mechanism of acknowledgement is
used to guarantee error-free transmission. The recipient of the message will return
a
positive or negative acknowledgement of the message to the sender. If the sender
receives positive acknowledgement, the original message may
be deleted, or it will be
retained for re-transmission. Each data block includes a certificate to validate its
contents as well as to sequence the data block within a set of data blocks. A header
block, containing relevant summary information, precedes each set of data blocks in all
messages. Data blocks holding different types of data may be mixed without restriction
in messages.
4.2.7 Security Requirements
The end-to-end “loss-less” transmission objective led to a design solution involving an
ITSO specific SAM module (ISAM). All the components that are involved in the
processing of data within the system (such as card reader devices and central systems)
are required to carry ISAMs accredited by ITSO. Individual transaction and batch
headers are also required to contain MAC fields. Each transmitted record/data block
has a certificate associated with it. The certificate is an ISAM generated MAC of the
transmission
block data. All records transmitted must be sequence numbered.
4.2.8 Timing & Routing
ITSO provides the following minimum suggested performance
levels in processing
back office transactions:
• 98% of data should be received by the owner of data and processed against the
IPA by 5:00 am on the day after the POST activity for that item
• Remaining data should be received and processed within the following 24 hours
Each
HOPS must perform the following actions between midnight and 5:00 am:
• Poll and collect batches from any POSTs directly under its control
• Distribute not on-us transactions
- Receive on-us transactions from other
HOPS
- Process the data
4.2.9 Usability
The ITSO specification requires that a central body provide the core facilities of Security
Management (provision of keys), Compliance Management, Certification Service and
Registrar (to register the schemes and products for provision of security keys. ITSO has
Page 30

opted to contract these services out in the UK and offered the Request For Proposals
for
these activities to be made available to APTA without charge if needed. ITSO
representatives from UK offered two alternative scenarios for adoption of the
specification.
• APTA is allowed to use and modify the current ITSO specification in any way
they desire to come up with their own specification based on ITSO. No licensing
or memberships fees are required. Only the specification documents on the
Internet will be available in this option, therefore APTA will have to 'reverse
engineer' the SIM card Secure Application Module and the security key
management service, if needed
• A subset of ITSO can be formed in the US, which APTA can manage. There
is no
cost involved in this option. A USA implementation of ITSO under the APTA
name would constitute a separate security domain and therefore all the keys
would be different. APTA can therefore set its own rules. The ITSO rules will be
made available to APTA to implement at will. APTA does not need to use the
ITSO official name or logo.
Setting up an APTA equivalent to ITSO can be done as soon as their membership
groups are defined and the membership is elected. This process can take approximately
three months. Putting in place the (few) full-time people, the contracts and the
processes raises the time estimate to at least six months. The current suppliers to ITSO
(ecebs for the ISAMs, Integri for Certifcation and Royal Bank of Scotland for Security
Key Management) would all be willing to supply the sub-contract services at a fee, if
necessary.
4.3
Open Financial Exchange (OFX)
4.3.1 Description of the Specification
Open Financial Exchange is a specification for the electronic exchange of financial
data
between financial institutions, businesses and consumers via the Internet. Created by
CheckFree,
Intuit and Microsoft in early 1997, Open Financial Exchange supports a
wide range of financial
activities, including consumer and small business banking,
consumer and small business bill payment, bill presentment and investments tracking
(including stocks,
bonds, mutual funds, and 401(k) account details). Since the 2000
release of the Version
2.0, OFX has become XML 1.0 compliant and has added 1098,
1099 and W2 tax form
download capabilities. Open Financial Exchange (OFX) is a
broad-based
framework
for exchanging financial data and instructions between
customers and their financial institutions. It is based on open standards for data
formatting (such as XML), connectivity (TCP/IP), and security (SSL). It defines the
request and response messages used by each financial service as well as the common
framework and infrastructure to support the communication of those messages.
Page 31

eXtensible Markup Language (XML) is a standard for the communication
of
information in a text format that is structured, well formed and validated against a
model (schema). XML grew out of Standard Generalized Mark Up Language
(SGML), a
presentation-oriented language designed to display information
in printed and
electronic form in a wide variety of formats. Hyper Text Mark Up Language (HTML),
the language of web browsers, is another cousin of XML. XML focuses on data
structures and document formatting. The data can be validated for both structure and
content, to whatever extent desired by the schema designer.
OFX is based on XML, a “tagged” protocol, where each aggregate and data element has
a name. The data is presented as a serial string, where
each aggregate, or data element
is preceded by a “” and followed by a ““. Naming of tags
within an XML schema is completely up to the user, as is their organization
and
structure.
The entire message strings can be encrypted or compressed, or individual
aggregates can be encrypted. All that is required is that both the sender and the
receiver operate the same schema to define the contents
of the messages. This makes
communication among different computer architectures
very simple, since they only
have to agree on a character representation (normally ASCII) and a schema. Binary,
Boolean, decimal and bitwise data are all represented as character data during
transmission. Attributes can further define a tag’s values
by permitting defaults and
mandating content or enumerations of acceptable
values. For example, a “rideroute”
aggregate might consi st of a bus id, a route id and a direction
as illustrated in Exhibit
4.3-1.
Exhibit 4.3-1 Example Rideroute Aggregate
1456
2671
inbound
In order to communicate among a number of parties or organizations, schemas are
being standardized within many industries and groups with common needs. One such
schema that defines tags attributes and aggregates for the financial community is OFX.
The
Open Financial Exchange specification is publicly available for implementation by
any financial institution or vendor. As of September 2003, over 2400 banks and
brokerages, as well as major payroll processing companies support OFX. The latest
version of OFX as of July 2004 is version 2.0.1.
4.3.2 Applicability to UTFS Effort
Althou gh a well-defined and widely implemented specification, OFX, in its current
form, does not provide schemas that are applicable to the efforts of the UTFS.
However, it certainly serves as a viable model for the development of a similar transit
industry standard based on XML. Even though XML is admittedly bulky, it should
Page 32

e given careful consideration for adoption as the basis for development of an
interchan ge specification for transit. This will require
significant efforts to define
common elements and aggregates of the transit industry specific data elements in XML.
Secondly, it requires definition of the APTA proposed message types
as XML schemas.
XML is widely accepted, and replacing a variety
of fixed and variable format messages
in other industries. With the rapid emergence of fast and efficient
XML parsers,
interface software development is minimized. XML parsers that create and breakdown
XML messages and convert them to and from
internal formats are widely available.
Microsoft is s trongly supporting XML throughout their software products, which
encourages even wider familiarity and adoption of the standard.
Tags theoretically add
bulk to data transmission, however,
this is becoming
less significant in practice with the
advent of faster and cheaper communication networks. Also, schemas are traditionally
more complicated than message layouts but are more powerful, describing
the
requirements, and enumerations of values in a consistent, and standard manner.
Extensibility is critical when designing a message protocol. A consistent problem with
fixed and vari able format messaging is that new needs are often difficult to
accommodate.
XML is easier to extend to new device and message needs.
4.3.3 Common Message Structure
Basic OFX data consists of a declaration and an OFX data block. The standard XML
declaration must come first, which includes an option to specify the version of XML
being used, and options to show such things as the encoding declaration and the
standalone status of the document as illustrated in Exhibit 4.3-2.
Exhibit 4.3-2 Processing Instructions
The OFX declaration must come next in the file with the following attributes as
described in the following list and Exhibit 4.3-3.
• OFXHEADER
• VERSION
• SECURITY
• OLDFILEUID
• NEWFILEUID
Page 33

Exhibit
4.3-3 OFX XML Declaration Attributes
The OFX data block
includes a Sign-on message and optional additional messages. A
message is the unit of work in OFX. It refers
to a request
and response pair, and the
status codes as sociated with the response. For example, the message to download a
bank statement consists of the request and the response . OFX
uses several common message types to perform specific functions,
which comply with
the naming conventions illustrated in Exhibit 4.3-4:
Exhibit 4.3-4 OFX Naming Conventions
Function Type
ADD
Format
Request
Response
MODIFY
Request
Response
DELETE
Request
Response
CANCEL
Request
Response
4.3.4 Message Types
OFX
schemas would be the equivalent of different messages as defined in the UTFS
WP4 Interface Specification Functional
Description. Currently, there are no publicly
shared
transit industry schemas. However, some of the financial industry related
schemas offer simila rities to the proposed message types and may be utilized by the
UTFS.
Currently, the OFX provides over 40 financial industry related schemas none of
which are directly applicable to UTFS.
Since OFX does not offer any transit industry specific schemas,
each APTA proposed
message
type needs to be defined as a schema in XML. The applicability of XML
schemas is illustrated in the examples provided in the following sections. The process
of
specifying an interchange begins with an agreement about the minimum data that
needs to be exchanged. The following Farecard Usage Transaction and Add Value
Transaction
examples are based on data elements provided for illustrative purposes.
• The Farecard Usage Transaction data elements might include:
- Card Number
- Agency providing service
- Route ID
Page 34

- Transaction date and time
- Transaction sequence number on card
- Fare amount
- Remaining balance in purse
• Value add transaction data elements might include:
- Card Number
- Agency providing value add
- Machine or
terminal ID
- Transaction sequence nu mber on terminal
- Value add date and time
- Payment method indicator (credit card, debit card, cash)
- Value add amount
- Transaction sequence numb er on card
- New balance
in purse
• Settlement transaction at end of day ( one side settles
to other via bank transfer)
Data elements might include:
- Count of rides A cards in B
- Value of rides
A cards in B
- Count of rides B cards in A
- Value of rides B cards in A
- Count of value adds for A cards in B
- Sum of value adds for A cards in B
- Count of value adds for B cards in A
- Sum of value
adds for B cards in A
- Net settlement money transferred (credit or debit)
- Batch
start date and time
- Batch end date and time
Each of the potential messages is the n modeled in XML, giving each tag an aggregate an
appropriate name that can be used across arbitrary regional boundaries.
A very small batch of transactions (two + a control total) might
look like the example
provided in Exhibit 4.3-5.
Page 35

Exhibit 4.3-5 Example Transaction Batch
6847102847615489
S F Muni
1265
Sequence=”23643” TimeStamp=”04/23/04 16:23:06”
Type=”Credit”
10.00
Sequence=”1021” PurseAfter=”10.75”
6847102847615489
S F Muni
2102
Sequence=”4343” TimeStamp=”04/23/04 16:27:42”
1.50
Sequence=”1022” PurseAfter=”9.25”
< BatchControl>
Count=”1” Total=”10.00”
Count=”1”
Total=”1.50”
< NetAmount>8.50CR
4.3.4.2 Card Management Data
OFX does not specify card management data.
4.3.4.3 System and Device Data
OFX does not specify system and device data.
4.3.4.4 Event Data
OFX does not specify event data.
4.3.4.5 Peer to Peer Clearing & Settlement
OFX does not specify peer-to-peer clearing and settlement data.
4.3.4.5 Additional Messages Offered
Not applicable to OFX.
4.3.5 Data Elements
Data elements fall into two main categories in OFX, “Elements” and “Aggregates”. An
element is data bounded by a leading start tag and a trailing end tag. An OFX element
must contain data and may not contain other elements. This is different than the more
generic definition of an element in XML. An aggregate is a collection of elements
and/or other aggregates. The enrollment request aggregate can be utilized to transmit
Page 36

cardholder related data as in the case of Registration and Personalization messages as
proposed by WP4. The structure of the ENROLLRQ aggregate is described in Exhibit
4.3-6.
Exhibit 4.3-6 ENROLLQ Description
Tag Description
Enrollment request Aggregate
First Name
Middle Name
Last Name
Address Line 1
Address Line 2
Address Line 3
City
State or Province
Postal Code
3-letter Country Code
Daytime Phone
Evening Phone
E-mail
Actual User ID if known
ID Used for tax purposes
Mother’s maiden name or other
Date of birth
Service activation request aggregates are utilized to start, modify, or terminate a service
for
an account by sending service activation requests. These requests can be utilized to
represent CID/card parameter and application update messages in UTFS. The
description of the activation request aggregate in OFX is illustrated in
Exhibit 4.3-7.
Exhibit 4.3-7 Activation Request Aggregate (ACCTRQ)
Tag Description
Account Service Request Aggregate
Service Addition Aggregate
Service Change Aggregate
Service deletion Aggregate
Service to be added/changed/deleted
Page 37

For example, the element could be further defined to represent some of the
transit industry related services as follows:
• CARDSRV= Card services (e.g. Autoload, Balance Protection)
• CIDPRMT= Device Parameter Services (e.g. Display and Audio Configuration)
• CIDAPPL = Transit Application Services (e.g. Business end-of-day)
Each Service aggregate above needs to be further defined
for structure and content for
the
sub-services available underneath them. Exhibit 4.3-8 below provides an example of
possible elements in the card services (CARDSRV) aggregate.
Exhibit 4.3-8 CARDSV Aggregate Elements
TYPE = “Threshold” THRESHVAL= “10.00” LOADAMNT=”20.0 0”
4.3.6 Message Sequences
OFX is a client-server system where an end-user uses a client application to
communicate with a server at a financial institution. The form of communication is
requests
from the client to the server and responses from the server back to the client.
One or more requests can be batched in a single file.
4.3.7 Security Requirements
The main goals of OFX security are privacy, authentication and integrity. OFX utilizes
encryption to maintain privacy, certificates to identify and authenticate servers, and a
cryptographic hash to assist integrity verification. With OFX, security is applied at two
different levels in the message exchange process, channel level and application level.
The
channel level security refers to the lower level security that is implemented in the
communication layer, whereas the application level security is independent of the
underlying communication protocol and aimed at protecting the data at the user level,
just like password protecting word-processing documents. Exhibit 4.3-9 illustrates how
these two level security schemes are applied.
Page 38

CLIENT
Exhibit 4.3-9 OFX Security Schemes
The password is encrypted by both the client
application and the Secure Socket Layer
(SSL)
protocol. The web server removes the SSL encryption and forwards the
encrypted password and the plaintext OFX data. The channel level
security is sufficient
for most transit related messages, provided that
the network architecture is adequately
secure. However, the application level password encryption can allow a higher level of
security when desired.
4.3.8 Timing & Routing
OFX does not provide any timing and routing requirements.
4.3.9 Usability
SSL ENCRYPTION
OFX DATA
OFX DATA
WEB
OFX
SERVER SERVER
Encrypted Encrypted
Password Password
The OFX board maintains
the OFX specification with members from a wide industry
base. Membership to OFX is free and the process required
for joining the organization,
depending on the work group, typically involves an informal request. There are no
royalties for adapting the specification
to transit. Furthermore, OFX does not require
any fees for
making changes and/or additions to the specification
for members.
Typically,
it takes about six months to process and finalize a change, such as adding 10
new data
elements (aggregates). The process
is estimated to take somewhere between
9-12 months to add a new scheme such
as transit fare collection. This process assumes
the design and development work is completed by APTA. This data was obtained
through phone interviews and/or email correspondence.
The information is accurate
as of July 2004. If APTA is interested in
using any parts of the specification, formal
notification and/or negotiations are necessary.
Page 39

4.4 Vending Equipment Interface (VEI)
4.4.1 Description of the Specification
The Vending Equipment Interface (VE I) specification was developed by Agent Systems
of Texas to provide a common interface that allows managed data exchange between
central
c omputing systems and vending equipment. This interface was developed
for
use
between any type of vending
equipment
and central computing environment and is
operating system and manufacturer independent.
The development of VEI came about as
a natural response to the trend towards
automation
in vending equipment.
Market segments that have
interest in this interface
include,
mass transit, parking
and merchandise
vending. There is an increasing need
for
encapsulation of Electronic Financial
Transaction (EFT) data in a secure manner.
Along with the commands
and event data that are normally exchanged between
vending
equipment
and a managing server, VEI offers a vehicle for EFT data handling.
The VEI specification permits the development and deployment of an integrated
network of
vending equipment and managing servers using an open standard free of
proprietary
restrictions. As VEI is adopted by industry, the possibility of procuring offthe-shelf
vending equipment
and pre-written server software applications that have a
compatible
messaging format increases dramatically.
4.4.2 Applicability to UTFS Effort
As it stands
today, VEI requires considerable amount of work by the WP4 to be
modeled
for the UTFS efforts. Additional data elements would need to be added to
t his protocol specification in order to fully support the UTFS
WP4 proposed
requirements
and it lacks an industry wide implementation
base. However, there is
an inhere nt mechanism built into the
specification, which involves submission and
acceptanc e of proposed changes by the issuer, Agent Systems.
The VEI protocol can serve
as a messaging protocol between servers of different
organizations (i.e. local and regional entities); however, it is not
the optimal solution.
Unfortunately,
the use of VEI can be costly, as each service that must be re-programmed
by the application developer
requires layering of services. The mechanisms in VEI used
to preserve data integrity and sequencing are very useful, however, they
are redundant
to those in an underlying transport protocol such as TCP/IP. This amounts to
additional overhead in each
frame and provides no real advantage when running on
top
of a reliable network protocol. This overhead is likely to have little influence on
transaction times, as most transaction decisions (e.g. accept or reject card) are made
locally between the device and the card. The biggest cost inherent with the use of VEI
is
the level of effort in developing and testing the protocol. Because of the complexity
of
additional layers, an inordinate amount of time is required to fully test and deploy a
VEI solution, when compared to XML or another simple strategy. This disadvantage
Page 40

may well be eliminated if, and when, off the shelf VEI parsers or server
applications
become
available.
4.4.3 Common Message Structure
T he VEI protocol is similar to the OSI model, with a well-defined dialog sequence
in the
application layer.
Each message that is a component of a dialog adheres to a standard format. A message
always
contains a message header, followed by the body of the message (see Exhibit
4.4-1). The body of the message differs for each
of the six dialogs explained in the
following
sections. An initial message sent is referred to
as the request message. A
request message can have a response message returned. Also, an acknowledgement
message can follow a response message.
Exhibit 4.4-1 VEI Message Structure
Data Link Header Transport Header Session Header
Message Header:
Protocol Headers Exhibit 4.4-2 further describes the message header.
Message Header Message
File Transfer Direction File Name
File Attributes
Exhibit 4.4-2 Message Header
Field # Field Name Description
1 Message Identifier This field specifies uniquely the dialog class and the service
2 Message Type This field specifies the part of the
dialog that this message
constitutes. For example, request,
response, or
acknowledgment
3 Message Sequence Number For the first request
message of a dialog, its value is always
one. For
the first response to a request, its value is echoed
back. For acknowledgments,
its value is always echoed
back. For subsequent requests or responses, its value
increments on each message
4 Dialog Sequence Number A number that the requester increments after each dialog
(set of messages), but the responder and acknowledger
only echo back
5 Message length Number of bytes in the message, including the header,
records and field separators
6 Sender’s Device ID A unique number within a system that identifies the device
Page 41

Field # Field Name Description
that is sending the message. This may be used for return
routing through a gateway
7 Receiver’s Device ID A unique number within a system that identifies the
device. This may be used for routing through a gateway.
When messages are used in a broadcast (instead of a
device-to-device connection), this field is empty
8 Routing Information The type of this field is unspecified. It shall be used to
further direct intermediate sites how to deliver the message
to its final destination. An example
usage would be the
channel number of a device in a multi-drop
connection
9 Version The Vending Equipment Interface
Specification Version.
The value shall be “1.1"
10 Response Needed Needed True if the sender
expects a response or
acknowledgment. False if not. Always false for broadcasts
Message
Body:
The message body consists of three or four fields depending on the type of the dialogue
being utilized. The details of the message body are further evaluated in the following
sections.
4.4.4 Message Types
VEI
defines six dialog classes with several services provided by each. A dialog class
is a
grouping of functionally similar services, which are fulfilled by sending and receiving a
set
of messages. The table in Exhibit 4.4-3 describes the six
dialog classes offered by
VEI.
Exhibit 4.4-3 Dialog Classes
Dialogue Description
Condition A particular circumstance or situation at a device
Variable Access Access, by name, data items that are resident on the device
Log Files Historic record of events and other archived information that can be used to
determine a sequence of events at the device
File Management Allows remote access to file systems
Transaction Support use
of credit/debit cards as a payment medium at the vending
equipment
Program Execution Action or set of actions to be carried out by the device
4.4.4.1 Transaction Data
Condition dialogues are best suited for Transaction Data messages proposed by WP4.
A condition dialogue is used to report a particular circumstance, or a situation at a
device, such as an intrusion alarm, a component failure, or a sale of a product.
Accompanying attributes might include for example the time of day, the value of
products
sold, or the method of payment. The structure of the condition dialogue is
contained
in Exhibit 4.4-4.
Page 42

Exhibit 4.4-4 Condition Dialogue Structure
Field Description of Field/Attributes
1 Message Header
2 Condition Attributes
3 Additional Attributes
By incorporating the relevant Additional Attributes (Full list of attributes can be found
in Chapter 17 of the specification), the conditional dialogue can be configured to
accommodate the Farecard Usage and Add Value Transactions as proposed by WP4.
4.4.4.2 Card Management Data
Variable access dialogue can be utilized for Financial Audit Data and Negative List
messages. Variable access dialogues are related to accessing, by name, data items that
are resident on the device. A variable is a data item that can assume any one of a set of
values. The Variable Access dialogue structure is illustrated in Exhibit 4.4-5.
Exhibit 4.4-5 Variable
Access Dialogue Structure
Field Description of Field/Attributes
1 Message Header
2 List of Variable Names
3 Variable Value List
By adding the relevant Variables indicated in the field three of the message (Full list of
variables
can be found in Chapter 17 of the specification), the Variable dialogue can be
configured to accommodate the Negative List and Financial Audit Data messages as
proposed by WP4.
File management dialogues allow remote access to file systems on the devices and are
structured as illustrated in Exhibit 4.4-6.
Exhibit 4.4-6 File Management Dialogue Structure
Field Description of Field/Attributes
1 Message Header
2 File Transfer Direction
3 File Name
4 File Attributes
The File Management dialogue can be formatted to accommodate certain WP4 Card
Management Data and System and Device Data messages (Appendix B). This can be
achieved by incorporating the appropriate File Attributes (Full list of attributes can be
found in Chapter 17 of the specification) into the dialogue.
Page 43

4.4.4.3 System and Device Data
Most of the system and device data messages can be represented with the Condition,
Variable and the File Management Dialogues as explained in the previous sections.
However,
Program Execution Dialogue is the most suitable for Device Command
messages. A Program Execution is an action or set of actions to be carried out by the
CID. The format of this dialogue is illustrated in Exhibit 4.4-7.
Exhibit 4.4-7 Program Execution Dialogue
Field Description of Field/Attributes
1 Message Header
2 Program Needing Input
3 Program Producing Output
4 Program Name
5 Parameter List
Program Name is the same format as the File Name explained in the previous section.
The Parameter List consists of parameters that are unspecified and in ASCII Text
forma t.
4.4.4.4 Event Data
The event data messages are represented by Condition Dialogues (Appendix B).
4.4.4.5 Peer to Peer Clearing & Settlement
The VEI does not define any clearing and settlement related messages.
4. 4.5 Data Elements
Wh ile V EI was not designed with smart cards in mind, it is a flexible protocol and can
be extended to include smart card related data elements. It is also possible to define
implementation
specific data types within the protocol when used within a closed
system; although the greatest benefit is obtained by using VEI in its standard identifiers.
4.4.6 Message Sequences
The VEI provides a simple structure of dialogue exchanges between a requester and a
responder. A dialog consists of a request message, a response message( s) and
sometimes
an acknowledgement of the response(s). A request message with or without
data may require a response at the discretion of the requester. A response message that
contains data may require an acknowledgement, at the discretion of the responder.
However,
some responses contain no data and act as acknowledgements. In this case
no
separate acknowledgement message is required.
Page 44

4.4.7 Security Requirements
The Message Sequences and Data Integrity requirements
from the Applicability Matrix
are
supported natively within VEI via the Agent Transport Layer (ATL). The transport
layer is entrusted with end-to-end data integrity achieved by retransmitting of lost
blocks and discarding duplicated blocks. This layer is also in charge of sequence
control to ensure that the higher levels of the protocol receive packets in the
exact order
in which they were sent. The ATL achieves this integrity and sequencing by assigning a
sequence number to each block and acknowledging
blocks by sequence number at the
message
level.
The
Authentication and Encryption requirements from the Applicability Matrix are
supported by VEI via the Agent Session Layer (ASL). The session layer handles
identification,
authentication and optional compression and encryption of messages.
Any time a connection is established, it must successfully
exchange the identification
and
authentication messages before normal communication can continue. If messages
are sent without the identification/authentication,
the receiver must disconnect, and
optionally
attempt to reconnect.
4.4.8 Timing & Routing
VEI
leaves timing and routing of the messages to the discretion of implementing
organization.
4.4.9 Usability
The VEI specification is available for public use without any patent
and copyright
requirements.
Based on a phone interview with Agent Systems, APTA can take any, or
all parts of it for its individual use. However, if APTA desires to adapt the VEI
specification
in its entirety and request for changes and additions, these modifications
will be handled by Agent Systems for a consulting fee.
This data was obtained through
phone
interviews and/or email correspondence. The information is accurate as of July
2004. If APTA is interested in using any part of the specification,
formal notification
and/or
negotiations are necessary.
Page 45

4.5 CEN TC278 – Interoperable Public Transport Fare Management System
Architecture (IFMSA)
4.5.1 Description of the Standard
CEN TC278 provides the basis for the development of a multi-operator/multi-modal
interoperable
Public Transport Fare Management System (IFM). The IFM system
provides a reference functional architecture for electronic fare payment systems and
identifies
requirements that are relevant to ensure interoperability between the entities
in the system.
The IFM system addresses all the functions involved in the fare management
process
including:
• Management of application(s)
• Management of products
• Security management
• Customer management
• Inspection/enforcement
• Reporting and monitoring
When
completed, this standard will comprise several parts; currently only Part 1 is
available in draft format. Part 1 describes the following main elements:
• Identification of the different functional entities in relation to the overall fare
management system
• Definition of a generic model of IFM system describing the logical and
functional architecture and the interfaces within the system and with other IFM
systems
• Use cases describing the interactions and data flows between the entities
• Definition of the security requirements
4.5.2 Applicability
to UTFS Effort
Although IFM provides a well-defined
model for the management of an interoperable
transit fare collection system, it is an incomplete draft as of today. In its current
form,
IFM is a high level document and does not include the
level of detail that APTA is
looking for and therefore is not applicable to APTA’s scope of work.
On a higher level, this document is useful in defining the components and entities
involved in an electronic fare payment system as illustrated in Exhibit 4.5-1.
Page 46

Application
Retailer Product
Retailer
Custome
r
Exhibit 4.5-1 IFM Components
Product
Owner
Customer
Service
Applic Application ation
Owner
Collection
&
Forwarding
Service
Operator
Security
Manager
Registrar
Roles and responsibi lities of each entity and the flow of
information between entities
have clearly been defined on a summary level. Lower level details of the interfaces
between entities are to be addressed by upcoming parts
of the standard.
4.5.3 Common Message Structure
IFM does not specify common message structure in its current form.
4.5.4 Message Types
IFM
does not specify message types in its current form.
4.5.4.1 Transaction Data
IFM does not specify transaction data in its current form.
4.5.4.2
Card Management Data
IFM does not specify card management data in its current form.
4.5.4.3 System
and Device Data
IFM does not specify system and device data in its current form.
4.5.4.4 Event Data
IFM
does not specify event data in its current form.
Page 47

4.5.4.5 Peer to Peer Clearing & Settlement
IFM does not specify peer-to-peer clearing and settlement in its current form.
4.5.5 Data Elements
IFM does not specify data elements in its current form.
4.5.6 Message Sequences
IFM
does not specify message sequences in its current form.
4.5.7 Security Requirements
IFM
does not specify security requirements in its current form.
4.5.8 Timing & Routing
IFM
does not specify timing and routing in its current form.
4.5.9 Usability
IFM is not usable
by APTA in its current form.
4.6 Cubic Transportation System (CTS) CID EDGE
INTERFACES
4.6.1 Description of the Specification
This document is based on CTS's suggestions for future RIS based “CID to Back End”
System
protocols and not meant to represent any of Cubic's existing implementations.
Data elements defined by the Edge Interfaces are based on RIS Part 03 v1.1 data formats
and still subject to change by APTA UTFS WG1.
4.6.2 Applicability to UTFS Effort
CID
Edge Interfaces defined messages are directly applicable to the WP4’s efforts
since messages have been based on transit industry related smart
card data. However,
this
specification lacks real life implementation. The document’s compliance with the
UTFS Workpackage 1 defined card data structure would simplify the additional work
necessary
by WP4.
4.6.3 Common Message Structure
CID Edge Interfaces’ message structure consists of a header followed by individual sub-
groups
and a MAC. The description and structure of the header is illustrated in Exhibit
4.6-1.
Page 48

Exhibit 4.6-1 CID Edge Interface Message Header Structure
Sequence Name Data Type Range Description
1 Header
[..]
1.1 Transtype
1.2 date-time DATETIM
E
1.3 Normalorenhanced
1.4
Transstatus
UBYTE 0=Reserved
1=PICC Initialized
2=PICC Issued
3=PICC Negative
Listed/Disabled
4=Value Product
Add/Deduct
5=Pass Product Load
6= Pass Product
Remove
7=Product/ s
Validation/Use
UBYTE 0 - Normal Transaction
1 - Data Enhancement
Transaction
UBYTE 0=Normal
1=Not confirmed by
PICC
Type of Transaction:
1-Transmitted on PICC Initialization
2-Transmitted on PICC Issue
3-Transmitted on PICC Negative
Listing
4-Transmitted on Value add, deduct,
or Autoload/Auto-unload
5-Transmitted on Product Load or
Autoload
6-Transmitted on Product un-load or
Auto-unload
7-Transmitted on Product/s [Pass
&/or SV/Purse] Validations & Uses
Device’s Date and Time of this
transaction. Seconds since Jan 1 1970
Indicates a Data Enhancement
transaction.
This contains the
transmission of the PICC’s previous
Transaction Details
Status of the transaction. This field can
be used to identify whether the write
to the card was confirmed or not.
Optional - not available for an
Enhancement Transaction
The body of a message consists of a series of sub-groups. Each sub-group contains
individual data elements with similar functional characteristics such as the CID Details
and the Location Details as listed in Appendix C.
4.6.4 Message Types
CID Edge Interfaces currently defines the following six message types that can serve
a model for device to backend data exchange:
• PiccUse
• PiccPurseLoad
• PiccPassLoad
• PiccInitialize
• PiccNegativeList
• PiccAutoLoadUnloadList
Page 49
as

4.6.4.1 Transaction Data
The PiccUse message consists of 10 sub-groups to represent the Farecard Usage
Transaction as proposed by WP4. Both the PiccPurseLoad, and the PiccPassLoad
messages are equivalent of the Add Value Transaction Data message.
4.6.4.2 Card Management Data
The PiccInitialize message is designed to exchange data related to card issuance and
initialization,
and would be comparable to the Initialization and Issuance message types
as proposed by WP4. Both PiccNegativeList and PiccAutoLoadUnloadList messages
would be the equivalents of Negative List and Action List message types respectively.
4.6.4.3 System and Device Data
This
specification does not define any system and device data category messages.
4.6.4.4 Event Data
The CID Edge Interfaces does not define any event data category messages.
4.6.4.5 Peer to Peer
Clearing & Settlement
The CID Edge Interf aces does not define any clearing and settlement data category
messages.
4.6.4.6 Additional Mes sages Offered
The
CID Edge Interfaces does not define any additional messages.
4.6.5 Data Elements
Most messages consist of constructed type data elements called sub-groups. Each subgroup
includes one or more individual data elements. The type and format of the data
elements follow those defined in the RIS Part 03 v1.1 data formats.
4.6.6 Message Sequences
The CID Edge Interfaces does not define message sequences.
4.6.7 Security Requirements
The CID Edge Interfaces defines MAC to be appended to the end of every message and
ensures the integrity of the message between a sender and a recipient.
Page 50

4.6.8 Timing and Routing
The CID Edge Interfaces does not define timing or routing requirements.
4.6.9 Usability
CID Edge Interfaces is under development by CTS. APTA can openly
review the CID
Edge Interface documentation and make changes, or use it as a model, without any cost
and intellectual property rights. Since the CID Edge Interfaces is not a living
specification or standard, there is no managing body or organization.
Therefore, there
is no change process, cost, or timeline other than the one APTA would like to undertake
at its own discretion. This data was collected in phone interviews and/or email
correspondence. The data is accurate as of July 2004. If APTA is interested in using any
parts of the documentation, formal notification should take place.
.7 TRANSLINK ®
4
4.7.1 Description of the Specification
The Metropolitan Transportation Commission (MTC) and several San Francisco Bay
Area transit agencies are currently implementing TransLink
t rail, commuter rail and ferry services
rovided by multiple operators throughout the Bay Area.
®, a regional fare collection
program for public transit in the Bay Area. TransLink ® cardholders can use a single
smart card to utilize bus, heavy rail, ligh
p
The contractor, ERG Group, is providing a full range of cardholder customer services
and financial clearing and settlement among participants. Customer services include
a
live
operator help desk, 24-hour automated customer service, registration for Autoload
and balance protection and card distribution services.
The TransLink ® card is an ISO 14443 Type B smart
card containing both contact and
contac tless interfaces. TransLink ® cardholders place their card within range of a card
interfa ce device (CID) onboard a vehicle or at
a station platform. The CID automatically
deducts the correct fare, calculating transfers and
appropriate senior, disabled and
you th discounts.
The TransLink ers dedicated to
®
® Fare Payment System (FPS) consists of separate ti
specific processing tasks required by the TransLink scheme. When a patron uses a
smart card at any TransLink ® device, usage data (UD) is created and uploaded through
the TransLink ® network to the central system.
There are four major tiers within the TransLink stem:
® cility (TCF)
m (HCS)
® Sy
• TransLink Central Fa
• Headquarters Computer Syste
• TransLink ® Data Server (TDS)
Page 51

• Front-end devices
4.7.2 Applicability to UTFS Effort
TransLink
modate the unique fare and business
le structures of at least 26 participating transit agencies. It currently supports majority
of the fare t t the US public transit industry. Of all the
ocuments analyzed, this specification is the only one that is based on an actual
d
® is the first smart card based regional transit fare payment system in the
United States. The system is designed to accom
ru
produc ypes that are available in
d
implementation. There is a one to one match between most of the TransLink UD an
WP 4 message types.
ERG stated that the APTA-000 specifications analyzed in the Section 4.9 of this
document will supercede the Phase I TransLink document analyzed below, and
represent
the foundation of the Translink Phase II messages.
4.7.3 Common Message Structure
The TransLink ® message structure consists of a header followed by a UD record, which
contains the tr ansaction specific usage data as illustrated
in Figure 4.7-1. The structure
is designed to allow bat ch transmission of multiple card transactions or event data
under a sin gle header. The UD record consists of 18 sub fields, which include both
financial and non-financial transaction data and support VEI data structures by
utilizing VEI log file dialogs.
Header
Version
Header
Header
Length
Card
SN
Transaction
Sequence
Batch
Sequence
Contract
ID
Operator
ID
Exhibit 4.7-1 TransLink ® Usage Data Records
Header UD RECORD
Contract
SN
4.7.4 Message Types
Security
Module
ID
Contract
Sequence
#
Device
ID
Contract
Sync
#
Payment
Method
Key UD UD
Version
NO
Transaction
Qualifier
MAC Header
Version
Amount
Operator
ID
Sequence
#
Date
and
Time
Location Balance
UD
Type
Last
Add
Value
Summary
The TransL ink transactions fall into one of the following six UD types:
®
• Fare Transaction
• Add Value Transaction
• Card Management Events
• Device Events
• Audit Register Snapshots
UD
Sub-
Type
Card
Sync
No
UD
Version
Each UD type is further divided into subtypes within them as listed in Appendix B.
Page 52
Fare
Category
Usage
Data
Destination
Location
MAC
MAC

4.7.4.1 Transaction Data
The “Fare Transaction” UD record is generated by card reader devices and can be
considered the equivalent of the “Farecard Usage Transaction” as proposed by the
WG4. Different subtypes of the Fare Transaction record are defined as follows:
• Single-tag fare payment, ride destination unknown
• Dual-tag entry transaction,
maximum fare deducted (purse debit)
• Dual-tag exit transaction,
fare adjustment (purse rebate)
• Dual-tag entry transaction, no fare deduction
• Dual-tag exit transaction, fare payment
• Single-tag fare payment, known ride destination
Two record subtypes are defined for a single-tag system. One subtype is generated
when
the reader does not know the destination, and the other subtype is generated
when the reader device obtains the destination location from either the driver console
or the patron.
Using
a card in a dual-tag system results in two Fare Transaction UD records being
genera ted. A dual-tag entry transaction (maximum fare deducted) record is generated
at the start of a ride on an open two-tag system, with a matching dual-tag exit
transaction (fare adjustment) record being generated at then end of the ride. Similarly, a
dual-tag entry transaction (no fare deduction) record will be generated at the start of a
ride on a closed-barrier two-tag system, matched by a dual-tag exit transaction (fare
payment) record at the end of the ride.
An “Add Value Transaction” UD record, the equivalent of WG4 proposed Add Value
Transaction Data message, is generated by all devices that add value to TransLink
cards. The following record subtypes reflect the variances in the payment method:
• Cash payment at a Ticket Office Terminal (TOT) or Add Value Machine (AVM)
• Check payment at a TOT
• Credit card payment at a TOT or AVM
• Debit card payment at a TOT or AVM
• Periodic Autoload at a reader device
• ThresholdAutoload at a reader device
• Remote re-load at a reader device
• Remote load of a new pass or ride book at a reader device
Tra L udit register snapshots. Audit
gisters are non-resettable counters and accumulators used within the TransLink ®
ns ink
it
® also provides a separate message type for a
re
system to give an independent method of verifying UD completeness. Different aud
register snapshot subtypes are defined as follows:
• CID audit registers
Page 53

• Driver console audit registers
• Distribution device audit registers
CID audit registers specifies the audit registers maintained by all the CID devices
and
other devices that use the TransLink r
mote loading of value onto the card. The driver console audit registers and the
console
® card for payment, or support autoloading o
re
distribution device audit registers specify the registers maintained by driver
devices and distribution devices respectively.
4.7.4.2 Card Management Data
® offers card management event UD records (Type 3) that are generated in
sponse to an exception or a specific event occurred on a TransLink ® card. There is a
one-to-on be e WG4 proposed message
pes. TransLink ® TransLink
re
e match tween the TransLink
also offers additional card management event messages as listed in
® messages and th
ty
Exhibit 4.7-2.
Exhibit 4.7-2: TransLink ® Additional Card Management Messages
Sub Type Description
1 Product block/unblock
2 Product block/unblock
3 Card block/unblock at Ticket Office Terminal (TOT)
4 Card block via hotlist
5 Card Validation failure
6 Card communication failure
7 Business rules rejected transaction
8 Reserved
9 Autoload failed
10 Not used
11 Autoload enabled/disabled
12 Fare Category Changed
13 Card Issue
14 Card Registration
15 Card de-registration
16 Balance protection
17 Card Retention
18 Pass-back condition cleared
19 Overstay Condition cleared
20 EFT Transaction Reversal
Page 54

4.7.4.3 System and Device Data
The data that customizes TransLink e in
le
re
® device software operation to support the devic
a specific operational context is referred to as “Configuration Data” (CD). The CD
includes all software components that are transferred to the device as downloadab
files including device application software executable images and parameters. There a
three main types of CD:
• Common CD
• Device specific CD
• Operator specific CD
Common CD contains data elements that apply to all TransLink devices for all
perators in the system such as system parameters and hotlists. System parameters
a
®
o
have potentially different values for different operators. All devices supporting
particular operator will be loaded with the same system parameters.
Device specific CD depends as much on a devices internal software design, as on the
external
functional requirements it supports. A sample of the device specific CD
payloads is as follows:
• TOT, AVM, DC, HCR and CID parameters
• Action List
• Contracts
• Transfers
• Calendar
• Fare Patterns
• Fare Code Matrix
• Fare Table
• Max Fare Table
• Routes
• Zone Table
• UI Resources
4.7.4.4 Event Data
TransLink ® system generates device event UD records in response to non-card related
device actions and changes of state. Event data messages consist of three subtypes:
• Subtype 1 – Simple event with no additional information
• Subtype 5 – Device event with status information
• Subtype 16 – Device event with additional data
Subtype 1 is designed to report only the event code together with the standard UD
record header in order to specify the event. Device simple events are usually non-
Page 55

emergency routine activities (e.g. start of business day, end of business day, operator
logged-on, device access door opened), that will serve as the diary for device actions.
Subtype 5, device event with status, conveys more information about an event in the
device. The event code is supplemented with a status field, as well as the standard
UD
record header fields. This type of message is used to report information on
configuration
errors, with the additional status field providing type of the error.
The
device event with data messages, Subtype 16, has a variable amount of
accompanying data. In addition to specifying the underlying event, this UD record
provides additional details. For
example, where “valid maintenance card presented” is
a device event code, “Card Serial Number” would be the additional event data that is
sent in the UD. The interpretation of the data is specific to a particular event being
reported.
4.7.4.5 Peer-to-Peer Clearing and Settlement
TransLink ® does not provide any messages for peer-to-peer clearing. The system is
designed and implemented based on a regional settlement approach.
4.7.4.6 Additional Messages Offered
TransLink ® does not define any additional messages.
4.7.5 Data Elements
Listed below are the standard data types used to represent TransLink
tion data:
® card data, usage
data and configura
• ASCII
• Bitmap
• Binary
TransLink
lements is provided in Appendix C)
® data elements cover a majority of the data elements supported by the UTFS
Workpackage 1. (A full list of data e
4.7.6 Message Sequences
Not part of the documents reviewed.
4.7.7 Security Requirements
To achieve high data integrity both parties involved in a communication session
authenticate each other through three-pass authentication scheme using MAC.
Page 56

Following the authentication process a session
key is generated for each transmission.
All data transfers are also encrypted against eavesdropping.
4.7.8 Timing
and Routing
The TransLink ® system architecture i l structure with the TransLink ®
Central System (TCS) at the top. The T d to all platforms at the next tier
rough Headquarter Computer Systems (HCS). An HCS has connections to, and
anages many TransLink ® s a hierarchica
CS is connecte
th
m
Data Servers (TDS). The TDS manages one or more Card
Interface Devices (CID)
or Distribution Devices (AVM).
Each node at a tier in the system communicates to all subordinate nodes and has a
single connection to the next higher tier. This requires all transactions in the TransLin
Fare Payment System (FPS) to be transported through each processing tier before
arriving at the TCS. The processing requirements of each level
determine what
transactions
are filtered and formatted into database structures.
All messages
must be forwarded to a higher
level until they reach the TCS. For
example, a message generated at a device is submitted
to the TDS then forwarded to the
HCS. The HCS then has the responsibility for sending
its transactions to the TCS.
provides four different date definitions in operation cycle as follows:
TransLink ®
• Operating
Date
• Business
Date
• Reconciliation Date
• Settlement
Date
T he current operating date is a date tha t may be different from the current calendar
date. For example, the current cal endar date may already be 18 February
2004, at 1:00
am, but the current operating date is still 17 February 2004 because the operating
date
changes eve ry day at 3:00 am.
The transaction business date is generated by a device, and added to the transaction
at
the TDS level. It is the current operating date of the device or TDS acquiring the device
UD. Typically, business dates reflect the operational business date of a transit
operator—the
period of their normal daily business hours. For example, if a transit
oper ator operates from 6:00 am to 2:00
am, (their business day), the business date
changeover will occur at 2:00 am. This allows the system to generate operational reports
that reflect transaction/passenger loads tied to their operational schedules. The
business date usually is applied at the devices or the TDS because these nodes typically
operate offline. The business date is typically incremented during the
transit operator
end-of-day
process.
The reconciliation date is added to the transaction
at the transit operator level. It is the
current operating date on the transit
operator’s central system. This date is used to
Page 57
k ®

econcile between the Central Clearinghouse (CCH), acquirer, and the transit operator
systems. This date stamp is applied when the transaction is received by the TCS and
used for re conciliation. This allows for more direct reconciliation between
the TCS and
the CCH/I ssuer than would be possible
with the business date.
The settlement date is added
to the transaction at the CCH. It is the current
operating
date on the CCH system. This is the date used to perform daily CCH financial
operations related to distribution of funds.
4.7.9 Usability
As of the production date of this report, no response
has been received from the
owners’ of this specification.
4.8 ERG APTA SPECIFICATIONS
4.8.1 Description of the Specification
ERG APTA Sepcifications consist of 3 documents which are based on the evolution of
the TransLink rk in Hong Kong, Rome, Las Vegas
and Singa
device central
® specification and ERG’s similar wo
pore. These documents provide information
on message specifications from
level to regional system.
The first document, APTA-001 , “Device to Higher Level Computer Data Elements/Messaging
Specifications”, provides the APTA WG4 equivalent transaction definitions. The second
document, APTA-002 “APTA Base Types Recommendation”,
defines data types for the
message content and compliments
the APTA-001. The third document, APTA-003
APTA T ransaction and CD Security,
defines the requirement for the "security"
mechanisms to be implemente d in the message exchange between the devices and the
backend systems.
The ERG Business Model is based on the principle that there exists a contract between
system s participants and the regional scheme manager. The contact represents a
registration to the scheme and regulates rights, business rules and obligations of the
respective participants. The transit operators, as participants, accept fare payment from
valid cards of the scheme at face value and clear
and settle the transaction data through
the regional central
clearinghouse.
4.8.2 Applicability to UTFS
Effort
ERG APTA specifications have been based on ERG’s implementations of smart card
based fare collection systems around the world. The specifications provide a wide
variety of data elements designed to encompass the most fare product types offered
in
the transit industry. Though th e documents do not support the “System and Device
Page 58

Data” transaction messages proposed by the WP4, the “Transaction Data” and the
“Card Management Data” equivalent messages are applicable to APTA UTFS efforts.
4.8.3 Common Message Structure
The ERG APTA-0001 proposed message layout consists of two parts as illustrated
in
Exhibit 4.8-1:
Exhibit 4.8-1
APTA Header Variant Data
APTA System Header APTA System Common Header
Both APTA System Header and the APTA System Common Header make up the
header of the message. The body of the message, called “Variant Data”, is made of
a
series of data structures, each containing individual data elements. Exhibit 4.8-2
provides a list of data structures used in all the messages.
4.8.3.1 APTA System Header
Exhibit 4.8-2 Data Structures
HEADER VARIANT DATA SCOPE
{SysHdr_t} ALL messages
{SysComHdr_t} ALL messages-
{SysFinDetails_t} or {SysFinDetails2_t}
ALL messages with CbTxnPurpose = “F”
{SysSecurityHdr_t}
ALL messages requiring a secured payload
{SysPiccCom_t}
Messages with picc details
{SysApplicationCom_t}
Messages with application details
{SysProductCom_t} Messages with product details
{SysPiccHolderCom_t}
Messages with piccHolder details
{DevPurseCommonHdr_t} Transactions involving a purse product
{DevPassCommonHdr_t} Transactions involving a pass product
{DevMultirideCommonHdr_t} Transactions involving a multiride product
{DevJourneyHdr_t} Transactions journey data involving a any product
{DevPurseJourneyHdr_t} Transactions with journey data involving a purse product
{DevPassJourneyHdr_t} Transactions with journey data involving a pass product
{DevMultirideJourneyHdr_t} Transactions with journey data involving a multiride product
{DevPurseLavHdr_t} Transactions with last add value data involving a purse product
{DevPassLavHdr_t} Transactions with last add value data involving a pass product
{DevMultirideLavHdr_t} Transactions with last add value data involving a multiride product
This
header contains system related information required to enable validations and
reporting
to be performed on the transactions and is present in every message. Exhibit
4.8-2
lists the data elements contained in the APTA System Header:
Page 59

4.8-3 APTA System
Header
Field Name Description
SettlementDate Current
settlement date of the system.
ReconciliationDate Agency operation date
Hostname Host
name of the Site Computer that
receives
transaction from the Picc Device
AcquirerId The Unique ID of the Acquirer involved in
the transaction.
4.8.3.2 APTA System Common Header
This
is the common header structu re that immediately follows the System Header in
every UD message. UD is defined as “Usage Data” in the context of the ERG
specifications.
Exhibit 4.8-4 APTA System Common Header
Field Name Description
formatVersion Format version (ie structure) of the usage data
payload. This field is updated every time a new
structure definition is released.
The formatVersion of this APTA Data Definition
is: 0x000001
txnDateTime The time (in seconds) at which the UD record is
generated. Format is Unix Time_t (UTC 0) i.e. 0 =
1/1/1970,
00:00:00 UTC.
BusinessDate The Business Date on which this UD record was
generated
sourceParticipantId The Unique ID of the Operator associated with
the Picc device on which the UD transaction
is
generated.
DeviceId A unique number
assigned to each device
SamId The numeric identification of the Security Access
Module (SAM) used in the transaction. This field
is 0 if no sam was involved.
This field should be used to identify the source
device of the transaction since it is
the SAM that
MACs the transaction. A mapping between
SamId and deviceId could be maintained
by
Page 60

Field Name Description
reading the SamId and DeviceId data arriving in
the header.
Udsn UD sequence number. The UDSN will reset back
to 0 when it increments past 0xFFFFFFFF.
Transac tion Status Indicates if the UD transaction is a normal
or test
transaction. Test transactions are ignored.
UdTyp e Main UD group that defines the type of
transaction.
UdSubtype Sub UD groups within UD.
4.8.3.3 Variant Data
Variant
Data consist of a group of selected data structures to form the body of a
message. The message type determines the kind and quantity of data structures to exist
in a message.
For example a “Product Purse Use” Message contains the following data
structures
from the Exhibit 4.8-2:
• SysComHdr_t
• SysPiccCom_t
• SysApplicationCom_t • DevUdPurseCommonHdr_t
• SysFinDetails_t
• DevUdPurseLavHdr_t • SysSecurityHdr_t 4.8.4 Message Types
As in the TransLink system, ERG specifications break transaction data into types and
subtypes to provide the system with a unique level of message identification.
Messages fall into one of the following
seven main transaction types (UdType), as
illustrated
in Exhibit 4.8-5. Each transaction group contains further message types
(UDSubType)
within them.
Page 61

Exhibit 4.8-5 Transaction Groups
Group UdType Description
Picc 1 Picc transactions- transactions related
to Picc
ad justments such as issue, unblock
Application 2 Application transactions- transactions
related to
Application adjustment such as create, delete, block,
unblock
Product 3 Product transactions- transactions
related to fare
processing, autoloads, add values, actionlists, product
usage
Other 4 Other transactions
Audit registers 5 Audit registers
Events 6 Event records
Project Specific Txns 7 Project specific transactions. Use of the UDSubType
values must be non-overlapping across projects.
The “Audit Registers”, “Events”, “Project Specific Transactions”
and the “Other”
transactions are deemed optional and beyond the scope of this specification. The
messages that fall into these transaction groups depend
on the requirements of the
specific operator/scheme manager.
All messages have a purpose field, which allows transactions of the same purpose to be
processed
via different paths from transactions of another purpose. They also allow
grouping for reporting purposes. Exhibit 4.8-6 provides a list of the purpose codes
supported by the specification.
4.8-6 Transaction Purposes
Transaction Description
Purpose
code
M Maintenance Transactions
F Financial Transactions which affect the
Master Database
B Blocking Transactions
S Miscellaneous Transactions
U Non Financial Usage Transactions
4.8.4.1
Transaction Data
The
Product Transaction Group (UD Type=3) messages, listed in exhibit 4.8-7, are ERG
equivalent to the “Farecard Usage Transaction” messages as proposed by the WG4.
Each message in every transaction group is assigned a unique sub-type ID based on the
fare product used and the entry/exit condition of the journey.
Page 62

4.8-7 Product Transactions Usage Messages
UdSubType MESSAGE
8 TXN_PRODUCT_PURSE_USE
31 TXN_PRODUCT_PURSE_USE_JOURNEY
32 TXN_PRODUCT_PASS_USE_JOURNEY
33 TXN_PRODUCT_MULTIRIDE_USE_JOURNEY
34 TXN_PRODUCT_PURSE_REBATE_ON_EXIT
35 TXN_PRODUCT_PURSE_USE_ON_ENTRY
41 TXN_PRODUCT_PASS_USE_ON_ENTRY
36 TXN_PRODUCT_MULTIRIDE_USE_ON_ENTRY
37 TXN_PRODUCT_PURSE_USE_ON_EXIT
38 TXN_PRODUCT_PASS_USE_ON_EXIT
39 TXN_PRODUCT_MULTIRIDE_USE_ON_EXIT
40 TXN_PRODUCT_SURCHARGE_REBATE_ON_EXIT
The following Product Transaction Group messages, listed on exhibit 4.8-8, are
equivalent to the “Add Value Transaction” messages as proposed by the WG4.
ERG specifications do not offer any messages that are equivalent of “Financial Audit
Data”.
Exhibit 4.8-8 Product Transactions Add Value Messages
UdSubType Description
1 TXN_PRODUCT_PURSE_ADD
2 TXN_PRODUCT_PASS_ADD
3 TXN_PRODUCT_MULTIRIDE_ADD
9 TXN_PRODUCT_PURSE_ADD_REVERSE
10 TXN_PRODUCT_PASS_ADD_REVERSE
11 TXN_PRODUCT_MULTIRIDE_ADD_REVERSE
4.8.4.2 Card Management Data
The “PICC related transactions” group offers fourteen messages that are generated in
response
to an exception or a specific event occurred on a card. Ten of these messages
are listed in Exhibit 4.8-9, and have direct equivalents in the WP4 proposed Card
Management Data messages:
Page 63

UdSubType Title
Exhibit 4.8-9 Picc Transaction Messages
Description
1 TXN_PICC_INITIALISE PICC initialization of reinitialization
2 TXN_PICC_ISSUE Issue of personalized or
anonymous card.
3 TXN_PICC_PERSONALISE Personalization of the card.
4 TXN_PICC_PERSONALISE_UP Personalization details are
DATE
amended.
5 TXN_PICC_BLOCK CID blocks a PICC from usage
due to hotlisting or failure to
meet other validity processing
rules such as expiry. Or as part
of the initialization/issuing
process.
6 TXN_PICC_UNBLOCK CID unblocks a previously
blocked PICC.
7 TXN_PICC_KEYS_UPDATE CID upgrades the security keys
on a PICC to a later version.
12 TXN_PICC_ACTIONLIST Actionlist performed on a PICC.
13 TXN_PICC_UNACTIONLIST Un-actionlist a PICC.
14 TXN_PICC_RANGE_ACTIONLI
ST_UPDATE
A new PICC range actionlist is
generated.
The “ Application
Transactions” group offers messages intended for the creation and
management of a transit application on the card. The following are the message types
offered
by the specification:
• Create
• Delete
• Block
• Unblock
• Replace
The ERG APTA specifications do not provide any messages for CID in the “Card
Parameter Update” category.
4.8.4.3 System and Device Data
This specification does not define any System and Device Data category messages.
4.8.4.4 Event Data
This specification does not define any Event Data category messages.
Page 64

4.8.4.5 Peer-to-Peer Clearing and Settlement
ERG APTA Specifications have been developed for the regional system settlement
approach but some of the messages could be conceivably used for a peer-peer
settlement
model.
4.8.4.6 Additional Messages
Offered
The following additional messages are offered by the ERG specifications and intended
for card/product activities conducted by customer service personnel.
• Product and e-cash refund
• Product replacement
• Bad Debt settlement
• Issuing reversal
4.8.5 Data Elements
The ERG APTA specifications
cover the data elements supported by the UTFS
Workpackage 1 and are listed in Appendix C. The APTA-002 specification provides the
type definitions for the data elements used in conjunction with the APTA-001
specification.
4.8.6 Message Sequences
The
ERG APTA Specifications do not define message sequences.
4.8.7
Security Requirements
ERG’s approach to message security is to protect each transaction with a MAC,
ensuring that the content and source of the transaction can be validated. This
MAC is
applied
over a subset of the complete message structure.
4.8.8 Timing and Routing
The ERG APTA Specification s do not define Timing and Routing requirements.
4.8.9 Usability
ERG
provided the specification in its entirety for APTA to use within their APTA UTFS
WP 4 efforts at no cost. It
may be openly reviewed and changed if necessary. However,
ERG prefers that it be not used piecemeal. In case APTA prefers to adapt the
specification in its entirety and submit changes to it, ERG is willing to offer their
internal change process to maintain the central control of the document in return for a
fee based on time and materials.
Page 65

4.9 REGIONAL INTEROPERABILITY STANDARD (RIS) PART 4
4.9.1 Description of the Standard
RIS, the smart card based Regional Interoperability Standard for Electronic Transit Fare
Payments, has been developed for Port Authority of New York and New Jersey
(PANY/NJ), and currently consists of four parts. Part-1 is the User Guide and provides
an overview of the RIS system approach. Part-2 of the RIS establishes the physical and
electrical
requirements for a Proximity Integrated Circuit Card (PICC) and a Card
Interface Device (CID). Part-3 addresses the data structure of a PICC at a technical
specification level of detail. RIS Part 4 defines standards for the exchange of messages
between the Regional Clearing House (RCH) and other computer systems required to
interface to it. Other computer systems include transit agency fare collection systems,
card
reload agent payment systems, transit benefits operators’ transaction processing
systems, and card issuers’ card management systems.
The message protocols and formats defined and standardized in RIS Part 4 cover the
following exchange of data:
• All messages originating from
the RCH for management and accounting of all
cards under its control.
• Receipt of all issuance and fare payment-related transactional
data generated
within or for the benefit of a regional
program for smart card-based electronic
fare payments.
• Settlement of transactions between multiple RCHs
for instances where a PICC
from one region is used to perform a fare payment-related transaction in a
different
region.
RIS Part 4 messages are primarily designed to transmit card data objects defined in RIS
Part 3 and provide flexibility for transmitting
four additional non-RIS Part 3 objects.
4.9.2 Applicability to UTFS Effort
Overall RIS Part 4 is a well-documented standard that is applicable to WP 4 efforts.
The
standard provides a conceptual fare system model where functions and responsibilities
of a regional clearinghouse and system participants are defined. The establishment of
this model is a crucial prerequisite to the WP 4 standard development effort. Following
are
the key advantages of the standard.
• Direct support
for WP1 card data structure due to its compliance with RIS Part 3
• Availability for APTA WP4 to adapt
RIS Part 4 defines the requirements for messages to and from the RCH(s). Although the
RIS Part 4 can be applied to messages generated by CIDs, in its current form, the
Page 66

standard does not mandate the compliance of transactions originating from Tier 1
devices. Following are some of the disadvantages of RIS Part 4.
• Limited support for data elements (objects) not compliant with WP1 data formats
• In a draft form and not implemented
4.9.3 Com mon Message
Structure
RIS messages consist of four
parts as shown in Exhibit 4.8-1. The total message length
varies based on the number of objects included in Part
3 of the message. Each
individual mes sage is iden tified by the “Message Identifier” and contains
the message
specific mandatory and optional data objects as designated by the object
map. The
details of these messages have been described in the following sections. 4.9.3.1 PART 1
Exhibit 4.9-1 RIS Message Structure
T he Part 1 consists of fixed number of fields within each message category described in
Section
4.9.4.
The “Message Identifier” determines type
of the message such as “Product Activation”
or
“Use of Stored Value”.
4.9.3.2 PART 2
The
Part 2 includes message authentication data represented by the
“AuthenticationDataGroup”. This group contains the data elements that will be
required by the receiver to authenticate the message or series of messages.
4.9.3.3
PART 3
Exhibit
4.9-9
AuthenticationDataGroup
MessageAuthCode
MACKeyID
AlgorithmID, optional
MACHashID, optional
This part contains the standard RIS object map and the objects required to be included
in a specific transaction. The purpose of the object map is similar to the “bitmap” in
ISO/IEC
8583, as explained in section 4.1.1. The Object Map is an 8 Byte, (64 Bit) binary
Page 67

it map where each bit represents the presence or absence
of a specific RIS Data Object.
E ach “1” in the object map indicates the presence of
the corresponding object in the
message,
and each “0” indicates the absence of the object. Any additional
object may be
adde d to the message simply by marking the Object bit map and
placing the objects in
the correct sequence in part 3 of the message. There are four extra
bits that are reserved
for implementer definition in the object bitmap. These
extra bits can be utilized to send
implementation
specific objects or data elements that are not necessarily compliant with
RIS Part 3.
4.9.3.4 PART 4
Part 4 contains transaction specific data elements that
are unique to the type of the
message such as the cardholder personal information in a “PICC Registration” message.
4.9.4 Message Types
R IS Part 4 provides the following six main
message categories with unique individual
messages within the each
category.
• CID Transaction
Messages
• PICC Scheme Control
Messages
• Interface to Transit Benefits Processors
• Interface to Other Clearing houses
• ISO 8583 Interchange message specifications
• ACH – Automated Clearing house messages
4.9.4.1 CID Transaction
Messages
CID Transaction messages include the following
three categories of transactions that are
based on the CID to PICC interactions:
• PICC Initialization messages include such card activities as initialization,
issuance, registration, card inquiry, and limited use card initialization
• Load and Unload messages include all direct load and autoload activities
performed on the card
• Fare payment (Usage) messages document in- and out-of-region card use for all
common fare product types available in the US.
The Part 1 of the CID Transaction Messages contains twelve
data elements as illustrated
in Exhibit 4.9-2.
Page 68

Item
Number
Exhibit 4.9-2 Part 1 Fields
Data Element Name Exhibit
1.1 MessageIdentifier
1.2 MessageVersion
1.3 MessageRevision
1.4 LocationDataGroup (GRP) 4.8-3
1.5 VehicleDataGroup (GRP) 4.8-4
1.6 EquipmentDataGroup (GRP) 4.8-5
1.7 PICCDataGroup (GRP) 4.8-6
1.8 TransactionDatetime
1.9 EmployeeDataGroup (GRP)* 4.8-7
1.10 PostDateTime
1.11 ApplicationCertCode
1.12 ActionEventDataGroup (GRP) 4.8-8
The location data group describes different characteristics of the location a transaction
occurred as listed in Exhibit 4.9-3.
Exhibit 4.9-3
LocationDataGroup
CountryID
RegionID
AgencyID
LocationID
LocationIDDestination (Optional)
LocationIDSubArea (Optional)
Exhibit 4.9 -4 lists the data elements of the “Vehicle Data Group”
which provides the
details of the transit vehicle where the transaction took place.
Exhibit 4.9-4
VehicleDataGroup
VehicleID (Optional)
RouteID (Optional)
ZoneID (Optional)
ZoneIDDestination (Optional)
RunID (Optional)
Direction-code (Optional)
“ Equipment Data Group”, shown in Exhibit 4.9-5, contains the data elements that
describe
the device that performed the transaction.
Page 69

Exhibit 4.9-5
EquipmentDataGroup
DeviceID
DeviceTransactionSeq (Optional)
CIDID
CIDTransactionSeq
“PICCDataGroup” contains the data elements that describe the characteristic of the
card used in the transaction, Exhibit 4.9-6.
Exhibit 4.9-6
PICCDataGroup
PICCSerialNumber
PICCDataStatusAsRead
PICCDataStatusAsWritten
PICCKeySetID
PICCTransactionSeq
PICCTransitApplicationStatus (Optional)
PICCPurseSVUse (Optional)
The
“ EmployeeDataGroup”
comprises the data elements displayed in Exhibit
4.9-7, and
identifies
the employee who is logged on to the device at the time
of the transaction.
Exhibit 4.9-7
EmployeeDataGroup
EmployeeID
EmployeeType
EmployeePICCID (Optional)
The “ActionEventDataGroup” group contains the data elements that are used to
document the current
state of action event directives as listed in Exhibit
4.9-8
Exhibit 4.9-8
ActionEventDataGroup
ActionEventIDAsRead
ActionEventIDAsWritten
ActionEventMapAsRead
ActionEventMapAsWritten
Page 70

4.9.4.2 PICC Scheme Control Messages
The RIS Part 4 defines
a central control body that is responsible for the administration
and the governance of the fare collection scheme. The following are the message
categories that are issued by the “control body” in order to distribute the
implementation
specific application parameters:
• Action List
• Negative List
• Fare Policy Framework
• Key Management
4.9.4.3 Interface to Transit Benefits Processors
The
messages in this category are used by Third Party Transit Benefits Administrators
to communicate benefit load instructions
and action confirmations to the party who
manages the action list administration. The Action List Administration facility returns
confirmations when the Action List directives are fulfilled. For example, a C101 benefit
load request message originating from the Transit Benefits Processor, is responded with
a C10 2 Benefit load Confirmation
message from the Regional Clearing House or Action
List Administrator
4.9.4.4 Interface to Other Clearing houses (RCH-to-RCH)
This category of messages are used between
clearing houses, when a card from a certain
region is used in another region belonging to a different RCH, to notify each other of
the activity associated with that card. The messages exchanged
are a subset of those
defined
for a single RCH, and listed in Appendix D.
4.9.4.5 ISO 8583 Interchange message specifications
The RIS Part 4 supports the ISO/IEC 8583 messages for all credit/debit card processing
related transactions between the RCH and the third party financial transaction
acquirers.
4.9.4.6 ACH – Automated Clearing house messages
The
specification supports the ACH messages as defined by the Electronic Payments
Associatio n (NACHA) for message exchanges between the RCH and the third party
Automated Clearing Houses (ACH).
Page 71

4.9.5.1 Transaction Data
The Exhibits 4.9-10 and 4.9-11 provide the RIS Part 4 defined CID Transaction messages
that are comparable to “Farecard Usage Transaction Messages” and “Add Value
Transaction
Data “ as proposed by the WP4 functional document.
Message
Identifier
4.9-10 Farecard Usage Transaction Messages
Description
A401 Use of Regional T-Purse
A402 Use of Regional Pass Product with or without a step-up fare
A403 Use of Agency Specific Product product with or without a step-up fare
A405 Use of Agency Stored Value Product
A406 Use of Special Limited Use Value PICC
A407 Use of Special Limited Use Product PICC
A408 Transfer on Special Limited Use Product PICC
A409 Transfer with or without a step-up fare
A411 Product Activation (First use of rolling product)
A412 Use of Account Linked Product
A414 Use of Regional T-purse on an Out of Region PICC
A415 Use/travel on an Autovalue Product
A419 Use of Stored Value from Multiple SV Sources
4.9-11 Add Value Transaction Data
Message Description
Identifier
A201 Load of Regional T-Purse
A202 Load of Regional Pass Product
A203 Load of Agency Pass Product
A204 Load of Agency Stored Value Product
A205 Load of Account Linked Product
A206 Load of Value to a Special Limited Use PICC
A207 Load of Product to a Special Limited Use PICC
A208 Load Product and Value to a Special Limited Use PICC
A209 Load of Out of Region T-Purse
RIS Part 4 does not offer any messages that are equivalent of “Financial Audit Data”
4.8.5.2 Card Management Data
The following RIS Part 4 messages have direct equivalents in the Card Management
Message
category of the WP4 proposed message types.
• Initialization
• Issuing
Page 72

• Registration
• Negative List
• Action List
• Card Parameter Update
• Key Change
The actionlist messages supported by RIS Part 4 are as follows:
• Set-up and withdrawal (cancellation) of card autoload events
• Set-up and withdrawal (cancellation) of card autovalue events,
• Unloading of products and e-purses
• Block and unblock of the card and the individual products
RIS Part 4 also supports the following key management messages:
• Load PICC Access Key-Set • Load
MAC Key-Set
• Load DAC Key-Set
• Control Key-Set
4.8.5.3 System and Device Data
RIS Part 4 does not support any System and Device data messages
4.8.5.4 Event Data
RIS Part 4 does not support any Event data messages
4.8.5.5
Peer-to-Peer Clearing and Settlement
Although the standard is designed to support a central/regional clearing and
settlement scheme, some of the messages can be applied to a peer-to-peer clearing and
settlement model. The “End of Day Position” and the “End of Day Transaction Receipt”
messages provide summaries of previously forwarded transactions for the period
specified in the message in order to perform a high level reconciliation of the financial
data.
RCH-to-RCH message set can also be adapted by a peer-to-peer system, each peer
central system acting as a single RCH.
4.8.5.6 Additional Messages Offered
RIS Part 4 provides “Fare Policy Framework” messages to transmit transit scheme
related parameters such as products Ids, Agency IDs and “rider profile
codes” to the
scheme participant s.
Page 73

The “Transit Benefi t Messages”, explained in section 4.8.4.3, are another
set of
additional messages offered by the standard.
4.8.6 Data Elements
RIS Part 4 supports all the objects and data elements defined in RIS Part 3. The objects
are 16 bytes and contain data elements of varying lengths. RIS Part 4 utilizes these exact
objects
in their “as read” and “as written” status. “As read” refers to the state of the
object when it is first read from the PICC at the start of a PICC/CID transaction.
Subsequently,
“as written” refers to the state of the object when it is written to the PICC
as a result of the transaction sequence. The ‘as read’ and ‘as written’ status of the
product objects are placed together with other data elements to form the message
structure that is sent from the CID through the agency
computer systems to the RCH.
4.8.7 Message Sequences
Act ion list messages originating from the RCH are responded with confirmation
messages with separate message identifiers by AFC devices when the action directive is
successfully implemented. For example, when a RCH sends the message A715, “Block
a Product”, devices respond with an A416 message, “Product Blocked”, when the action
succeeded.
The standard does not define any other message sequences.
4.8.8 Security Requirements
RIS Part 4 supports transmission level data integrity through the use of MACs
appended to every message. The MAC provides the
RCH with the ability to validate the
authenticity
of transaction messages after they have been forwarded from a CID. The
authenticity c heck is achieved through the secret keys stored only in CIDs and the RCH.
4.8.9 Timing and Routing
RIS Part 4 does not define any timing requirements.
4.8.9 Usability
The information provided in RIS
Part 4 is offered free of charge and can be incorporated
within
UTFS WP4’s efforts in order to facilitate the standardization of the interface
between PICC’s host device and a Regional Clearing House (RCH). The Port Authority
prohibits the licensing or charging of fees for use and development
of any portion of
this Regional Interoperability Standard for Electronic Transit Fare Payments.
Page 74

5.0 FINDINGS
This section presents the findings resulting from the analysis of the standards and
specifications contained in this report effort. The five
standards and specifications
illustrated
in Figure 5-1 were reviewed and analyzed in accordance with the
methodology and the techn ical criteria presented in Sections 2.0 and 3.0. Moreover, five
additional criteria, as illustrated in Exhibits 5-1 and 5-2, were used to evaluate these
standards and specifications in terms
of their general usability and relevance to the
UTFS effort. Both the exhibits provide a qualitative measure of the analysis
results.
Exhibit
5-1
Standard/ Technical UTFS Adoption
UTFS
Adoption UTFS Effort
Specification
ISO/IEC 8583
Compliance
4
Costs
1
Time
1
Required
1
ITSO 3 4
4 3
VEI 3 N/A
N/A 2
OFX 1 4 1 0
CID Edge
Interfaces
1 4 4
1
TransLink® 4 N/A N/A 4
ERG APTA-000 3 4 4 3
RIS PART 4 3 4 4 3
N/A – Cost and adoption time were not able to be obtained during phone interview
Legend
4 More Favorable 0 Less Favorable
Each of the sponsoring organizations for the respective standard or specification was
contacted to discuss the process for obtaining permission to use the documentation.
The results of those conversations were factored into the findings in this section.
•
The following categories have been established as measuring criteria:
Technical Compliance is measured in terms of how the standard or specification
complies with the detailed analysis criteria in Section 4.0. The following criteria has
been established and measured in quantities relative to other
standards/specifications analyzed:
o Definition of message structure
o Number of message types matching with that of WG 4
Approximately >90% match – Very Favorable
Approximately 75% match – Favorable
Approximately 50% match – Somewhat favorable
Page 75

Approximately 25% match – Less Favorable
o Estimated number of data elements associated with each message
o Definition of security level
o Other characteristics (e.g. operation, timing and message routing
parameters defined)
• UTFS Adoption Cost reflects the additional cost that may be required by APTA to
adopt the standard or specification, such as membership dues and application fees.
This category does not represent the actual labor cost of implementation.
o 0-$1000 – Very Favorable
o $1001- $5,000 Favorable
o $5,000 – $10,000 Somewhat Favorable
o $10,000 and up – Less Favorable
• UTFS Adoption Time represents an estimate of
the time required to implement the
UTFS changes in the relevant standard or specification, or to derive a UTFS
derivative of the standard. Therefore it reflects the time necessary to navigate the
approval process. This does not include the time APTA spends developing the
changes to the specification:
o 0-3 Months – Very Favorable
o 6-9 Months – Favorable
o 9-12 Months – Somewhat Favorable
o 13 Months and up – Less Favorable
• UTFS Effort Required aims to represent an estimate of the time and effort WP4 will
require to adopt the standard or specification:
o Approximate number of additional messages or message types that WP 4
needs to define and add to the standard
o Estimated number of new data elements or fields that WP 4 needs to
define and add to the standard
o Approximate number of matching messages that needs to be further
defined
The following three additional weighting criteria were established to evaluate the
standards and specifications:
• Smart Card Based represents the degree the standards or the specifications can
accommodate smart card data types and structure
• Widely Implemented shows the degree the standard or specification is in use
• Relevance to Transit represents the level of relevancy of the standard or
specification to the transit industry. (Determined by the number of transit industry
related data elements and message types supported).
Page 76

Exhibit 5-2 illustrates the relevance to the WP4 efforts and the viability of using the
standard or specification for a transit application.
Exhibit 5-2
Standard/ Smart Card Widely Relevance to
Specification
ISO/IEC 8583
Based
2
Implemented
4
Transit
1
ITSO
5.1 SUMMARY
4 0 4
VEI 2 1 4
OFX 0 4 1
CID Edge
Interfaces
4 0 4
TransLink® 4 1 4
ERG APTA-000 4 3 4
RIS PART 4 4 0 4
Legend
4 More Favorable 0 Less Favorable
Based on the analysis, ITSO, RIS PART 4 and ERG APTA Specifications are more
favorable to adopt and more relevant to WP4 than all the other standards or
specifications evaluated. Therefore, these three specifications are the best candidates for
further analysis.
That said, the other standards and specifications have some applicability to the UTFS
efforts in various areas. The remainder of this section highlights these areas. ISO/IEC
8583 standard’s batch/file transfer mechanisms and the OFX’s general schema structure
should also be considered for reference in APTA’s future standard or specification
development. Although scored very favorable on both “Technical Compliance” and
“UTFS Effort Required” categories, TransLink did not qualify for a ranking on the other
two categories due to lack of response from ERG Transit Systems as yet.
According to Figure 5-1, the ISO/IEC 8583 scored favorable only on the Technical
Compliance category. This standard has been determined to be less favorable in terms
of usability, based on the time, cost and effort required to adapt it to WP4 purposes.
However, this standard could serve as an effective model for WP4, due specifically to
its extended focus on the definition of batch and file transfer mechanisms.
Although it has not been implemented, the ITSO specification is one of the
specifications that scored as the most favorable in almost all categories per Exhibits 5-1
Page 77

and 5-2. The lack of existing implementation
was the only drawback for this
specification, resulting in a less favorable rating
in the “Widely Implemented” category.
Overall, ITSO is highly applicable to the UTFS.
Although VEI scored as favorably in the technical compliance category, it did not
receive any scoring on the UTFS Adoption Costs
and Adoption Time. This is because
there is no definitive fee structure,
or change request schedule that could be identified
by the Agent Systems point of contact.
If APTA were interested in pursuing VEI,
detailed
discussions with Agent Systems
to determine these elements would be
necessary. This specification scored as somewhat favorable in the UTFS Effort Required
category, for the following reasons:
• The level of effort required further defining and
mapping
all t he matching VEI
dialogues to
WP4
proposed
exact
message
types
• The
estimated number
of additional
data
elements
that need to be defined for
smart card related transaction processing
Compared to Exhibit 5-1, the VEI scored better in terms of relevance per Exhibit 5-2.
OFX did not score as favorably because it lacks relevance to the transit industry. This
adversely affects its score in all the other categories as well, and therefore, is the least
applicable to UTFS efforts. It is gaining rapid acceptance in other industries (e.g.
Financial) and support from major vendors such as Microsoft. APTA should consider
this specification as it matures and becomes more widely adopted.
Although incomplete, the CID Edge Interfaces scored very favorably in terms of
Adoption Costs and Adoption Time. This specification is a viable candidate for a model
for WP4 efforts, due to its reliance on Workpackage 1 smart card data formats, and the
relatively low adoption cost to UTFS. Its low score on Technical Compliance reflected
adversely on the Level of UTFS Effort Required
in implementing this specification.
CID
Edge Interfaces
also scored very favorable on two of the three categories in Exhibit 5-2.
Despite its low scores on Technical Compliance
and UTFS Effort Required, WP4 should
consider
using this draft specification.
TransLink is the most favorable specification in terms of technical compliance. It fulfills
most of the criteria established in this category
by
providing a match for all the message
types proposed by the WP4. Its compliance with
the technical criteria also reduces the
time required for APTA to adopt this specification
because of the relatively smaller
number of changes that need to be undertaken.
Due to its regional and smart card based
focus, TransLink also scored the highest in Exhibit 5-2. If APTA will be allowed to
adopt this specification, TransLink should certainly
be considered for WP4 efforts.
ERG APTA specifications scored very favorably in all categories
of the criteria. Its
support for relatively fewer number of WP4 proposed messages resulted in a
“Favorable” ranking in both the Technical Complian ce and the Level of UTFS Effort
Page 78

Required. This set of specifications provides
one of the highest level of applicability in
terms of both
Exhibits 5-1 and 5-2.
Together with ITSO and ERG APTA specifications,
RIS Part 4 scored as one of the three
highest standards
analyzed
in Exhibit 5-1. Due to its relatively short history it lacks
industry acceptance and real life implementation as reflected in Exhibit 5-2. This
standard is a strong candidate
for WP4 to consider. However, it should be expanded to
allow the flexibility to support
non-WP1 defined card data structures as well.
Due to their exclusive focus on the North American transit industry, RIS PART 4 and
the ERG APTA specifications are preferred candidates for further analysis by WP4.
Page 79

APPENDIX A RESEARCH CONTACTS
Project/Specification/Standard Sponsoring
Organization/POC
Email Address
Smart Card Project Implementation Contacts
TransLink ® MTC – Russell Driver rdriver@mtc.ca.gov Russell Driver
Metropolitan Transportation Commission
Lake Merritt Plaza
1999 HarrISO/IECn
Street
Oakland, CA 94612
WMATA – SIRS v0.6
WMATA – Douglas ddeckert@wmata.com Douglas D. Deckert
Specifications
Deckert
WMATA
600 Fifth St., N.W.
Washington, D.C. 20001-2693
OCTOPUS OCTOPUS octopusuk@btinternet.com Brian Chambers
International Operations Director
Octopus Cards Ltd
P.O. Box 2993
BA3 5JT Radstock
Smart Card Standards/Specifications
Calypso RATP – Michel
Michel.Barjansky@ratp.fr Michel Barjansky
Barjansky
RATP/SIT/ISV
Immeuble Central IV
1, avenue Montaigne
93160.Noisy le Grand
France.
ITSO ITSO- Jeremy Acklam Jeremy Acklam
Deputy Chairman of the Integrated Transport
Smartcard Organisation
Virgin Trains
Euston Station (West Wing)
NWI 2 DS London
VEI N/A vei@agentsystems.com Agent Systems
RKF Stockholm Lokaltrafik bjorn.holmberg@sl.se Bjorn Holmberg
AB Storstockholms Lokaltrafik
S-120 80 Stockholm, Sweden
Page 80

Project/Specification/Standard Sponsoring
Organization/POC
Email Address VDV VDV- Till Ackermann N/A Till Ackermann
Fachbereichsleiter
Volswirthschaft
Verband
Deutscher Verkehrsunternehmen (VDV)
Kamekestrasse, 37-39
50672 Koeln, Germany
Intercode SNCF gilles.de-chanterac@sncf.fr Gilles de Chanterec
President of the Commiss ion of
Normalization
Information System Policies Manager
SNCF Direction du transport public
209/211, Rue de Bercy-Tour Paris-Lyon
75585 Paris, France ATIP Transport
Ticketing R ichard.Parker@doi .vic.gov .au Richard Parker
Authority
Transport Ticketing Authority General
Mana ger,
Operations Level 16,
589 Collins
Street Melbourne, 3000
Smart Card System Vendor Specifications
Back office message
Scheidt & Bachmann lbucci@scheidt-bachmann-
Lisa Bucci
specifications
usa.com
Scheidt & Bachmann, USA
31 North Avenue
Burlington, MA 01803
Back office message
ERG – Michael Nash mnash@erggroup.com Michael Nash
specifications
ERG Transit Systems USA, Inc.
1800 Sutter Street, Suite 900
Concord, CA 94520
CID Edge Interfaces Cubic brian.monk@cubic.com Brian Monk
Cubic Transportation
Systems
5650 Kearny
Mesa
Road
San Diego, CA 92111
ERG APTA Specification ERG mlaezza@erggroup.com Michael Laezza
ERG Transit Systems
905-890-2794 ext 224
Back office message Thales geraud.najman@thales- Geraud Najman and Ian Woodroofe
Page 81

Project/Specification/Standard Sponsoring
Organization/POC
Email Address
specifications transportservices.com
ian.woodroofe@thales
transportservices.com
Back Office Message
ASCOM sanford.weinberg@ascom.com Sanford Weinberg
Specifications
Ascom Transport
Systems, Inc.
68 Veronica
Avenue
Unit
10
Somer set, NJ 08873
Page 82

APPENDIX B COMPLETED CRITERIA FORMS
VENDING EQUIPMENT INTERFACE ( VEI) VERSION
1.2
Criteria
Transaction Data
Message Type Data Element(s)
Farecard Usage Transaction Condition Dialog _CAA048
Add Value Transaction Data Condition Dialog _CAA010
Financial Audit Data
Card Management Data
Variable Access Dialog Acct.*
Initialization Condition Dialog _CAA031
_CAA032
_CAA033
Issuing Condition Dialog _CAA025
_CAA031
_CAA032
_CAA033
Registration Condition Dialog _CAA043
_CAA045
_CAA046
_CAA068
Personalization
Condition Dialog _CAA043
_CAA045
_CAA046
_CAA068
Negative List Variable Access Dialog Sysconf.bl[]
Action List NA
Transit Application Updates File Management Dialog Transfer Request
Card Parameter Update File Management Dialog Transfer Request
Key Load File Management Dialog Transfer Request
Key Change
System and Device Data
Variable Access Dialog sysconf.sa.sversion
Device Status Request Conditional Dialog RecConditionAttributes
Device Command Program Execution Dialog RecParamterList
Device Data File Management Dialog Transfer Block
Event Data Conditional Dialog RecConditionAttributes
Equipment Status Data Conditional Dialog RecConditionAttributes
Peer
to Peer Clearing and
Settlement
NA
Not on-us transactions NA
Clearing and Settlement reporting Log File Dialog Upload Log
Page 83

ITSO
Criteria
Transaction Data
Message Type Data Element(s)
Farecard Usage Transaction Stored Value Usage(0100 and 0110), Journey Record (0209)
Add Value Transaction Data Stored Value Load(0100 through 010A), First Use of Stored Value
(0106) , Create or Amend Ticket IPE (0207,208), Create/Ammend
IPE,
Initialize/Amend Auto-Renew (0304)
Financial Audit Data
Card Management Data
NA
Initialization Create ITSO Shell
Issuing Activate ITSO Shell
Registration Create or Amend ITSO ID
Personalization Create or Amend ITSO ID
Negative List POST Configuration (Hotlist)
Action List POST Configuration (Actionlist)
Transit Application Updates Interoperability
List Transaction
Card Parameter Update Interoperability
List Transaction
Key Load Not Disclosed
Key Change
System and Device Data
Not Disclosed
Device Status Request POST Configuration (Capability List 1 and 2)
Device Command POST Configuration (Capability List 1 and 2)
Device Data Interoperability List Transaction
Event Data POST Configuration (Capability List 1 and 2)
Equipment Status Data POST Configuration (Capability List 1 and 2)
Peer to Peer Clearing and
Settlement
NA
Not on-us transactions NA
Clearing and Settlement reporting
Additional Messages
NA
Stored value transaction cancellation (0107, 0117)
Full/Partial Refund for a purchased ticket (0108, 0118, 010D)
Add/Delete Loyalty Scheme (020B, 0202)
Loyalty add points and redemption (0203, 0204)
Transaction cancellation (0300)
Deposit Received or Refunded (0302, 0303)
Exception (0400, 0405)
Page 84

ISO/IEC 8583
Criteria
Transaction Data
Message Type Data Element(s)
Farecard Usage Transaction Financial Presentment Notification Message 240
Add Value Transaction Data Financial Presentment Notification Message 240
Financial Audit Data
Card Management Data
Network Management Messages 804/814
Initialization File Action Instruction/Notification Message 362/340
Issuing File Action Instruction/Notification Message 362/340
Registration File Action Instruction/Notification Message 362/340
Personalization File Action Instruction/Notification Message 362/340
Negative List File Action Instruction/Notification Message 362/340
Action List File Action Instruction/Notification Message 362/340
Transit Application Updates File Action Instruction/Notification Message 362/340
Card Parameter Update File Action Instruction/Notification Message 362/340
Key Load Network Management Messages 824/834
Key Change
System and Device Data
Network Management Messages 824/834
Device Status Request File Action Instruction/Notification Message 362/340
Device Command File Action Instruction/Notification Message 362/340
Device Data File Action Instruction/Notification Message 362/340
Event Data File Action Instruction/Notification Message 362/340
Equipment Status Data File Action Instruction/Notification Message 362/340
Not on-us transactions Reconciliation Advice Message 520/530
Clearing and Settlement reporting Reconciliation
Notification Message 540/550
Page 85

CID EDGE INTERFACES
Criteria Message Type Data Element(s)
Transaction Data
Farecard Usage Transaction PiccUse
Add Value Transaction Data PiccPurseLoad, PiccPassLoad
Financial Audit Data NA
Card Management Data
Initialization PiccInitialize
Issuing PiccInitialize
Registration NA
Personalization NA
Negative List PiccNegativeList
Action List PiccAutoLoadUnloadList
Transit Application Updates NA
Card Parameter Update NA
Key Load NA
Key Change
System and Device Data
NA
Device Status Request NA
Device Command NA
Device Data NA
Event Data NA
Equipment Status Data NA
Peer to Peer Clearing and
Settlement
NA
Not on-us transactions NA
Clearing and Settlement reporting NA
Page 86

TRANSLINK ®
Criteria
Transaction Data
Message Type Data Element(s)
Farecard Usage Transaction UD Type=1, Sub Type=1,2,3,4,5 or 6
Add Value Transaction Data UD Type=2, Sub type=1,2,3,4,5,6,7
or 8
Financial Audit Data
Card Management Data
UD Type=5, Sub Type=1,2 or 3
Initialization UD Type=3, Sub Type=13
Issuing UD Type=3, Sub Type=13
Registration UD Type=3, Sub Type=14 or 15
Personalization UD Type=3, Sub Type= 14 or 15
Negative List UD Type=3, Sub Type=4 - Hotlist CD Payload
Action List UD Type=3, Sub Type=10
Transit Application Updates Service Parameters CD Payload
Card Parameter Update UD Type=3, Sub Type=1,2,3,11,12,16,17,18,19,20
Key Load Device Specific CD Payload
Key Change
System and Device Data
Device Specific CD Payload
Device Status Request System Parameters CD Payload
Device Command System Parameters CD Payload
Device Data UD Type=6, Sub Type=1, 5 or 16
Event Data UD Type=6, Sub Type=1, 5 or 16
Equipment Status Data UD Type=6,
Sub Type=1, 5 or 16
Peer to Peer Clearing and
Settlement
NA
Not on-us transactions NA
Clearing and Settlement reporting Undisclosed
Page 87

ERG APTA
Criteria
Transaction Data
Message Type Data Element(s)
Farecard Usage Transaction UD Type=3,
Sub Type=8,31,32,33,34,35,36,37,38,39,40,41
Add Value Transaction Data UD Type=3, Sub Type=1,2,3,9,10,11
Financial Audit Data
Card Management Data
NA
Initialization UD Type=1, Sub Type=1
Issuing UD Type=1, Sub Type=2
Registration UD Type=1, Sub Type=3
Personalization
UD Type=1, Sub Type=3
Negative List UD Type=1, Sub Type=5,6
Action List UD Type=1, Sub Type=12,13,14
Transit Application Updates NA
Card Parameter Update NA
Key Load UD Type=1, Sub Type= 7
Key Change
System and Device Data
UD Type=1, Sub Type=7
Device Status Request NA
Device Command NA
Device Data NA
Event Data NA
Equipment Status Data NA
Peer to Peer Clearing and
Settlement
NA
Not on-us transactions NA
Clearing and Settlement reporting NA
Page 88

RIS PART 4
Criteria
Transaction Data
Message Type Data Element(s)
Farecard Usage Transaction A401, A402, A403, A405,
A406, A407, A408, A409, A412, A414,
A415,
A416, A417, A418, A419
Add Value Transaction Data T-Purse Load (A201), Regional
Pass Load (A202)
Load of Account
Linked Product (A205)
Financial Audit Data
Card Management Data
NA
Initialization PICC Initialization
(A101, A105)
Issuing PICC Issuance
(A102)
Registration PICC Registration (A103)
Personalization PICC Registration (A103)
Negative List Negative
List B110
Action List Stored
Value Autoload (A210), Block Product (A715)
Unblock Product (A716), Setup/Cancel
Product (A718, A719, A720,
A721, A722)
Transit Application Updates NA
Card Parameter Update Directed PICC Data Change (A717)
Key Load Load PICC
Access Key-Set (B130, B131, B132)
Key Change
System and Device Data
Control Key-Set B133
Device Status Request NA
Device Command NA
Device Data NA
Event Data NA
Equipment Status Data NA
Peer to Peer Clearing and
Settlement
NA
Not on-us transactions RCH-to-RCH Messages
Clearing and Settlement reporting End of Day
Position (A501), (A502)
Page 89

APPENDIX C DATA ELEMENTS
VENDING EQUIPMENT INTERFACE (VEI) VERSION
1.2
Data Element(s)/Action Description
Conditional Dialog
_CAA010 Item value transacted (added / subtracted)
_CAA025 Original issuing machine number
_CAA031 Number of items sold
_CAA032 Item type
_CAA033 Serial number of item
_CAA043 Issuing agency ID
_CAA045 Rider category ID
_CAA046 Rider category
name
_CAA048 Usage record
_CAA068 User name
Variable Dialog
acct.* All variables dealing with sales counts
sysconf.bl[] Blacklist structure
sysconf.sa.sversion Software version of I-th sub-assembly
Log File Dialog
Upload Log To retrieve a range of records
from the log file
File Management Dialog
Transfer Request Request permission to begin sending or receiving a file
Transfer Block To send a file to the receiver
Data Types
RecParamterList Count of items
in list (N)
Parameter
RecConditionAttributes Date and Time
Condition ID
Condition Status
Condition Priority
Condition Severity
Condition Enabled
Condition Incident
Date and Time
last became active
Date and Time last became active
Overall device
status is dependent on this Condition status
Overall device
status
Additional Attributes
List
Page 90

ITSO DATA ELEMENTS
Message Type Data Element(s)
Standard Fields
Record Format Revision
SAMID
ITSOCardReferenceNumber
CardFormatVersion
KeyStrategyVersion
KeyVersion
TransactionDate
TransactionTime
TransactionInformation
IPEID
IPEIssuerID
StaffID
Create and/or Activate ITSO Shell
DepositAmount
DepositAmountCurrencyCode
MethodOfPayment
VATSalesTax
Delete ITSO Shell
DepositRefundAmount
DepsoitAmountCurrencyCodre
Create or Amend IPE
Expiry Date
Remove Data
Create or Amend ITSO ID
Amount
AmountCurrencyCode
HolderTitle
HolderName
HolderAddres
HolderPostalCode
HolderPhoneDay
HolderPhoneHome
HolderEmail
Expiry Date
PassbackTime
CustomerProfile
IDFlags
DateOfBirth
PersonID
Language
SecondaryHolderID
PhotoID
EntitlementExpiryDate
DepositAmount
DepositCurrencyCode
MethodOfPayment
VATSalesTax
UserDefined
Page 91

ITSO DATA ELEMENTS
Message Type Data Element(s)
Stored Value or CTA usage
Value
IPEAmount
ValueCurrencyCode
POSTAmount
PosTAmountCurrencyCode
ActionSequenceNumber
PurseIssuer
ValueATPAFlags
Stored Value
Load
Value
IPEAmount
ValueCurrencyCode
POSTAmount
PosTAmountCurrencyCode
ActionSequenceNumber
PurseIssuer
ValueATPAFlags
Initialize Auto
Top-Up
PurseIssuer
CurrencyCode
AutoTopUpAmount
AutoTopUpThreshold
BankName
BankACNumber
BankCardExpiryDate
BankCardStartDate
BankCardIssueNumber
Initialize or Ammend Auto Renew
Auto-RenewAmount
Auto-RenewThreshold
AutoRenewValue
BankName
BankACNumber
Expiry Date
StartDate
IssueNumber
First Use Of Stored Value
PurseIssuer
AutoTopUpThreshold
TopUpAmount
MaxValue
ValueCurrencyCode
StartDate
EndDate
DepositAmount
DepositCurrencyCode
Stored Value Transaction Cancellation
Value
Page 92

ITSO DATA ELEMENTS
Message Type Data Element(s)
IPEAmount
ValueCurrencyCode
POSTAmount
POSTAmountCurrencyCode
ActionSequenceNumber
PurseIssuer
Refund for a Purchased Ticket
IPEValue
IPEAmount
IPECurrencyCode
POSTAmount
PosTAmountCurrencyCode
ActionSequenceNumber
Transaction Cancellation
AmountPaid
NormalPrice
CurrencyCode
StoredUsesRefunded
StoredUses
TicketNumber
AmountPaid
Create or Ammend Ticket
IPE
ISAMID
ISAM S#
AmountPaid
NormalPrice
CurrencyCode
IPEFormatRevision
ActionSequenceNumber
RemoveDate
TransactionFlags
RecordSubType
PassbackTime
CountRidesJourneys
Mode
MaxTransfers
TimeLimit
Expiry Date
IssuerID
PassFlags
TicketType
TypeNumber
IssueDate
IssueTime
Class
ExpiryTime
ValidityStartDate
PromotionCode
ValidOnDayTypeCode
Page 93

ITSO DATA ELEMENTS
Message Type Data Element(s)
PartySizeAdult
PartySizeChild
PartySizeConcession
FarePaid
FarePaidCurrencyCode
FarePaidMethodOfPayment
FarePaidVATSalesTax
UserDefined
ValidFrom
ValidTo
NumberOfPasses
TYP6Flags
Journey Record
AmountPaid
NormalPrice
CurrencyCode
RemainingUses
EntryExitType
EntryExit
Deposit Received or Refunded
DepositAmount
DepositAmountCurrency
Exception
ExceptionType
POSTType
Result
Capability List 1
CapabilityListIdentifier
CapabilityListAction
Location
Security
UnHotProtectionNumberOfDays
Communication
MessageSecurity
PrintingCapability
CardholderDisplay
MaxPurseValue
IPEPrioritySelection
Hotlist
HotlistIdentifier
HotlistAction
HotType
Action
CardDisposition
CRNStart
CRNEnd
StartISAMIDOfIPECreator
EndISAMIDOfIPECreator
StartISAMSequenceNumberIPECreator
Page 94

ITSO DATA ELEMENTS
Message Type Data Element(s)
EndISAMSequenceNumberIPECreator
IPETYP
IPEPTYP
IIN
IssuerID
CardIssuerID
Action List
ActionListIdentifier
ActionToTake
CRN
CreditCardNumber
IPETYP
IPEPTYP
IINL
IPEIssuerOID
TicketNumber
ActionSequenceNumber
VariableData
ISO/IEC 8583 DATA ELEMENTS
Message Type Data Element(s)
Financial Presentment Notification
Message 240
Primary Account Number
Processing Code
Amount Transaction
Amount Reconciliation
Date and Time Transmission
Conversion Rate Reconcilation
Conversion Rate Cardholder Billing
System Trace Audit Number
Date and Time Local Transaction
Date Effective
Date Expiration
Date Conversion
Date Capture
Transaction Life Cycle Identification Data
Point of Service Data Code
Card Sequence Number
Function Code
Message Reason Code
Merchant Category Code
Date Reconciliation
Reconciliation Indicator
Amounts Original
Acquiring Institution Identification Code
Forwarding Institution Identification Code
Track 2 Data
Track 3 Data
Page 95

Approval Code
Action Code
Service Code
Card Acceptor Terminal Identification
Card Acceptor Identification Code
Card Acceptor Name/Location
Track 1 Data
Amounts Fees
Authorizing Agent Institution Identification Code
Batch/File Transfer Message Control
Receiving Institution Identification Code
Network Management Message
Date and Time Transmission
System Trace Audit Number
Date and Time Local Transaction
Function Code
Message Reason Code
Date Reconciliation
Reconciliation Indicator
Forwarding Institution Identification Code
Batch/File Transfer Control Data
File Transfer Description Data
Transaction Destination Institution Identification Code
Transaction Originator Institution Identification Code
Receiving Institution Identification Code
File Action Instruction/Notification
Message
System Trace Audit Number
Date and Time Local Transaction
Function Code
Message Reason Code
Forwarding Institution Identification Code
Action Code
Batch/File Transfer Message Control
Batch/File Transfer Control Data
File Transfer Description Data
Data Record
Transaction Destination Institution Identification Code
Transaction Originator Institution Identification Code
Receiving Institution Identification Code
File Name
Reconciliation Advice Message 520/530
Primary Account Number
Date and Time Transmission
System Trace Audit Number
Date and Time Local Transaction
Transaction Life Cycle Identification Data
Function Code
Date Reconciliation
Reconciliation Indicator
Acquiring Institution Identification Code
Forwarding Institution Identification Code
Reconciliation Data Primary
Page 96

Amount Net Reconciliation
Receiving Institution Identification Code
Reconciliation Fee Amounts Credit
Reconciliation Fee Amounts Debit
CID EDGE INTERFACES DATA ELEMENTS
Message Type Data Element(s)
PiccInitialize
header [..]
location-details [..]
cid-details [..]
device-details [..]
employee-details[..]
picc-replaced
picc-details [..]
ris-picc-profiles [..]
ris-picc-product-index […]
ris-picc-transaction-history [..]
message-authenticate [..]
PiccUse Message
header [..]
location-details [..]
cid details [..]
dev-details [..]
employee-details[..]
picc-details [..]
ris-picc-profiles [..]
ris-picc-product-index [..]
ris-picc-transaction-history [..]
ris-pass-product [..]
ris-sv-purse-list[..]
message-authenticate [..]
PiccPurseLoad Message
header [..]
location-details [..]
cid details [..]
device-details [..]
employee-details[..]
picc-trade-in list[..]
picc-details [..]
ris-picc-profiles [..]
ris-picc-product-index [..]
ris-picc-transaction-history [..]
ris-sv-purse [..]
message-authenticate [..]
PiccPassLoad Message
header [..]
location-details [..]
cid details [..]
dev-details [..]
employee-details[..]
Page 97

picc-trade-in-list[..]
picc-details [..]
ris-picc-profiles [..]
ris-picc-product-index [..]
ris-picc-transaction-history [..]
ris-pass-product [..]
ris-pass-product [..]
ris-sv-purse-list[..]
message-authenticate [..]
PiccNegativeList Message
id
picc-issuer
start-date
expire-date
hotlist-groups[..]
first-picc-id
last- picc-id
list-action
entries[…]
message-authenticate [..]
PiccAutolodUnloadList Message
id
picc-Issuer
start-date
expire-date
autoload-list [..]
picc-id
picc-event-id
load-unload-action
agency-id
picc-class
prod-type
loc-value-encoding
loc-value
prod-expiry-date
autoload-threshold
autoload-recurrence
message-authenticate [..]
Page 98

TRANSLINK
Message Type Data Element(s)
UD Record - Fare Transaction
Card S/N
Card Transaction Sequence Number
Contrcat ID
Contrcat S/N
Transaction Qualifier
Fare Category
Fare Payment Method
Transaction Amount
Last Operator
Transaction Location
Destination Location
Purse Balance
Card Synchronization Number
Contract Sequence Number
Contract Synchronization Number
Last Add Value Summary
UD Authentication Code
UD Record - Add Value Transaction
Card Serial #
Transaction Sequence #
Contract ID
Contract S/N
Transaction Qualifier
Card Syn. Number
Value Added
Transaction Amount
Current Stored Value
Device ID
EFT System Trace Audit #
EFT Response
EFT Authorization ID
Last Add Value Summary
Block/unblock event data elements
card SN
Transaction Sequence #
Card Syn. Number
Card Status (ud type=3 sub-type 3 or 4 only)
hotlist serial number
Contract ID
Contract S/N
ontract Sequence number
Contract SYNC number
Contract Flags
Contract status
Contract expiry date
Transaction qualifier
Failed transaction event data elements
card s/n
Page 99

card status
failure reason
Business rule exception event
card SN
Contract ID
Contract S/N (sub-type 9 only)
failure reason
Purse Balance (sub-type 7 only)
fare category
failure reason
Autoload enable/disable
card s/n
Contract ID
Contract Flags
enabled autoload flags
disabled autoload flags
Card issue event
card s/n
card type
Card Syn. Number
card contracts limit
issuer ID
card expiry date
fare category
transaction amount
deposit value
Card registration event
card s/n
date of birth
name
address
telephone number 1
telephone number 2
e-mail address
Balance protection event
card s/n
amount of transaction
card retention event
card s/n
receipt number
retention reason
CID Audit register snapshot data elements
batch sequence number
ud sequence number
fares debit counter
fares purse debit accumulator
fares credit counter
fares purse credit accumulator
autoload purse counter
autoload purse accumulator
remote load purse counter
remote load purse accumulator
Page 100

Autoload non-purse counter
remote load non-purse counter
Distribution device Audit Register snapshot data elements
batch sequence
number
ud sequence number
Purse add value counter, cash payments
Purse add value Value, cash payments
Purse add value counter, EFT payments
Purse add value
Value, EFT payments
Non-purse add value counter (own products cash payments)
Non-purse add value value
(own products cash payments)
Non-purse add value counter (other products cash payments)
Non-purse add value value (other products cash payments)
Non-purse add value
counter (own products EFT payments)
Non-purse add value value (own products EFT payments)
Non-purse add value counter (other products EFT payments)
Non-purse add value value (other products EFT payments)
Card issued
counter, cash payments
Card issued value, cash payments
Card issued counter, EFT payments
Card issued Value, cash payments
Card issued
counter, other means
Card issued value, other means
Balance protection
counter, cash payments
Balance protection value,
cash payments
Balance protection counter, EFT payments
Balance protection value, EFT payments
Other fare media counter, cash payments
Other fare media
value, cash payments
Other fare media counter, EFT payments
Other fare media value, EFT payments
Page 101

ERG APTA
Message Type Data Element(s)
UD Record - Fare Transaction
Card S/N
Card Transaction Sequence Number
Contrcat ID
Contrcat S/N
Transaction Qualifier
Fare Category
Fare Payment Method
Transaction Amount
Last Operator
Transaction Location
Destination Location
Purse Balance
Card Synchronization Number
Contract Sequence Number
Contract Synchronization Number
Last Add Value Summary
UD Authentication Code
UD Record - Add Value Transaction
Card Serial #
Transaction Sequence #
Contract ID
Contract S/N
Transaction Qualifier
Card Syn. Number
Value Added
Transaction Amount
Current Stored Value
Device ID
EFT System Trace Audit #
EFT Response
EFT Authorization ID
Last Add Value Summary
Block/unblock event data elements
card SN
Transaction Sequence #
Card Syn. Number
Card Status (ud type=3 sub-type 3 or 4 only)
hotlist serial number
Contract ID
Contract S/N
ontract Sequence number
Contract SYNC number
Contract Flags
Contract status
Contract expiry date
Transaction qualifier
Failed transaction event data elements
card s/n
Page 102

card status
failure reason
Business rule exception event
card SN
Contract ID
Contract S/N (sub-type 9 only)
failure reason
Purse Balance (sub-type 7 only)
fare category
failure reason
Autoload enable/disable
card s/n
Contract ID
Contract Flags
enabled autoload flags
disabled autoload flags
Card issue event
card s/n
card type
Card Syn. Number
card contracts limit
issuer ID
card expiry date
fare category
transaction amount
deposit value
Card registration event
card s/n
date of birth
name
address
telephone number 1
telephone number 2
e-mail address
Balance protection event
card s/n
amount of transaction
card retention event
card s/n
receipt number
retention reason
CID Audit register snapshot data elements
batch sequence number
ud sequence number
fares debit counter
fares purse debit accumulator
fares credit counter
fares purse credit accumulator
autoload purse counter
autoload purse accumulator
remote load purse counter
remote load purse accumulator
Page 103

Autoload non-purse counter
remote load non-purse counter
Distribution device Audit Register snapshot data elements
batch sequence number
ud sequence
number
Purse add value counter, cash payments
Purse add value Value, cash payments
Purse add value counter, EFT payments
Purse add value Value, EFT payments
Non-purse add value counter (own products cash payments)
Non-purse add value value (own products cash payments)
Non-purse add value counter (other products cash payment s)
Non-purse add value value (other products cash payments)
Non-purse add value counter (own products EFT payments)
Non-purse add value value (own products EFT payments)
Non-purse add value counter (other products EFT payment s)
Non-purse add value value (other products EFT payments)
Card issued counter, cash payments
Card issued value, cash payments
Card issued counter, EFT payments
Card issued Value, cash payments
Card issued counter, other means
Card issued value, other means
Balance protection counter, cash payments
Balance protection value, cash payments
Balance protection counter, EFT payments
Balance protection value, EFT payments
Other fare media counter, cash payments
Other fare media value, cash payments
Other fare media counter, EFT payments
Other fare media value, EFT payments
Page 104

RIS PART 4: FOR A LIST OF DATA OBJECTS AND ELEMENTS SEE THE RIS
STANDARD DOCUMENTATION
Page 105

Appendix D RIS PART 4 RCH-To-RCH Messages
Message Required Optional
A201 – Regional T-Purse Loaded X
A209 - Out of Region T-Purse Loaded X
A250 – Regional T-Purse Unloaded X
A401 – Use of Regional T-purse X
A410 – Attempted use of a Negative listed PICC X
A412 - Use of Account Linked Product X
A413 – Rejected Transaction X
A414 – Use of Regional T-purse on an Out of Region PICC. X
A501 – End of Day Position X
A502 – End of Day Transaction Receipt X
B110 – Negative List Header X
B111 - Negative List Directive X
B112 – Negative List Authentication X
B120 – Fare Policy Framework – Header X
B121 – Fare Policy Framework – Regional Profile Codes X
B122 – Fare Policy Framework – Regional Product IDs X
B123 – Fare Policy Framework – Regional Agency IDs X
B124 – Fare Policy Framework – Authentication Entry X
Page 106