National Academies Press: OpenBook

Smartcard Interoperability Issues for the Transit Industry (2006)

Chapter: Chapter 1 - Introduction

« Previous: Summary
Page 3
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 3
Page 4
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 4
Page 5
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 5
Page 6
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 6
Page 7
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 7
Page 8
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 8
Page 9
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 9
Page 10
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 10
Page 11
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 11
Page 12
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 12
Page 13
Suggested Citation:"Chapter 1 - Introduction." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 13

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

The overall objective of TCRP Project A-26 was twofold. First, the task was to identify the key information that must be exchanged between transit agencies to achieve fare payment interoperability. Second, once the information was identified, the task was to develop a prototype for a proposed public-domain application programming interface (API) and uniform application protocol data unit (APDU) that demonstrates “proof of concept” for Type A and Type B smartcards that comply with International Organization for Standardization (ISO). The report synthesizes primary research. The key activity consisted of surveying regions implementing a regionally interoperable fare payment system using smartcards. Moreover, the report references, as required, the experience gained during the implementation of interoperable fare payment system projects in locations such as New York; Washington, DC; San Francisco; Chicago; and Los Angeles. The structure for this report is as follows: • Chapter 1 identifies the key institutional issues that may present barriers to implementing an interoperable transit fare payment program. The research focuses on identifying institutional issues found during the implementation of projects reviewed as part of this report. The insti- tutional issues are organized as follows: – Management and organizational issues, – Financial management issues, – Patron impact issues, – Equipment design issues, and – Transit industry issues. • Chapter 2 discusses the results of the formal survey conducted to identify commonalities and differences in the information exchanged between agencies. • Chapter 3 identifies the data elements and information exchanged that are critical for imple- menting smartcard interoperability. • Chapter 4 delineates the necessary information flows as follows: – Information flows that define the requirements for developing the API and APDU, – Information that needs to reside on the card, and – Data flows between each level in the system architecture. • Chapter 5 examines critical data management issues and policies. • Chapter 6 provides a set of functions needed for a standard public-domain API that may be used in developing a uniform APDU. • Chapter 7 discusses the development of a prototype for a proposed public domain API that demonstrates a “proof of concept” for ISO 14443 Type A and Type B compliant cards. • Chapter 8 documents the results of the development effort. 3 C H A P T E R 1 Introduction

1.1 Interoperability Defined For this research project, TRB defines interoperability as “the ability of different agencies to coordinate and share information so that passengers can travel in a seamless fashion.”Travel may occur on public transit, on a toll road or toll bridge; it may include the use of a parking facility. Travel in a seamless fashion is primarily driven by these factors: • Coordination of transfer points; • Schedule coordination; • Simplified and coordinated tariff structures; • Transfer facilities design; • Consistent passenger processes and operational procedures, – Boarding, – Fare payment, and – Fare inspection; • Common interoperable fare media; and • Convenience in obtaining fare or payment media. As the previous list of factors indicates, fare payment interoperability is only one factor that affects seamless travel. Contactless technologies’ implementation for fare payment, both long and short range, is accelerating across the transportation industry. The capabilities of contactless technologies provide opportunities to allow regional payment coordination across multiple transportation modes. These capabilities also provide an opportunity to pay for products and services beyond transportation. 1.2 Elements of Fare Payment Interoperability Fare payment interoperability does not necessarily require the use of a smartcard. Figure 1 illustrates the following high-level components to achieving interoperability: • A manual system relies on human interaction such as visual inspection • An automated system relies on technology—usually using fare media such as a contactless smartcard to validate interoperability This research project focused on the automated system using the contactless smartcard as the fare medium. The information and data flows required to achieve smartcard interoperability also applies to other media such as magnetic stripe tickets or radio frequency identification (RFID) tags. The physical medium used for seamless payment is a medium that carries data. The most common is magnetic stripe media; however, a solid-state, silicon-chip-based data carrier, such as the contactless smartcard, is emerging as the preferred technology. The first step in building an interoperable system is to organize the participants into a formal group. A Participation Agreement binds the participants to follow a set of common rules, also referred to as policies or business rules. At a minimum, the rules must provide the following: • Technology requirements that include systems and fare media and • Transaction processing that defines the data to be transferred for processing and when (how often) that occurs. These rules may also define other business-related aspects such as • Branding (how the product is to be identified in the market); • Customer service processes and procedures; • Sharing of expenses and payment for services; 4 Smartcard Interoperability Issues for the Transit Industry

• Items controlled by participants; • Dispute resolution; and • Legal framework. The Participation Agreement drives the information requirements for institutional interop- erability. Chapter 1 discusses the issues associated with institutional interoperability in detail. The next step is to define the technical information required to achieve interoperability. The business rules articulated in the Participation Agreement define the information to be exchanged by the interoperable smartcard system. At a minimum, the card-to-reader data for- mat and the data format for transferring the transaction records to a central clearinghouse need to be defined. The minimum requirements for implementing an interoperable smartcard system can be accomplished by using one of the following approaches: 1. Procuring the technology from a single supplier, similar to Washington, DC, with the EZ Pass Interagency Group (IAG) 2. Developing an interface specification that defines the requirements with which each partici- pant’s supplier has to comply, similar to what is done in the financial services or telecommu- nications industries 1.3 Interoperability Across Regions Most regional systems implemented across the United States and Canada use a single sup- plier for a specific region. Each system has unique characteristics and features. To achieve intra- regional interoperability, the business rules and technology need to be synchronized. Figure 2 illustrates the process for analyzing and identifying gaps in the business rule and technology for a specific group of regions. Each time a new region is added, the entire process needs to be repeated. The primary factor for intra-regional interoperability is the cost of making the nec- essary systems modifications. The most difficult situation to manage is where two competing Introduction 5 Visual Ticket Inspection isual Ticket Inspection Collect Paper Media ollect aper edia Participant Agreements articipant gree ents Manual Systemanual yste Single Source – Reliant on one supplier – Supplier has $ power – Little incentive to innovate ingle ource – eliant on one supplier – upplier has $ po er – Little incentive to innovate All Agencies Procure Equipment From One Supplier ll gencies rocure quip ent ro ne upplier Automatic Fare Collection System uto atic are ollection yste All Agencies Adopt A Common Data Format ll gencies dopt o on ata or at Multi-Sourcing – Increased competition – Product improvements – Greater flexibility in participation ulti- ourcing – Increased co petition – roduct i prove ents – reater flexibility in participation Is the System Inter- Is the yste Inter- operable? No Is the System Proprietary? Yes standard Standard or Figure 1. Interoperability model.

suppliers have to work together to accomplish inter- and intra-regional interoperability, par- ticularly when there is a significant generation gap in the technologies employed. 1.4 Interoperability Beyond Transit The financial services industry anticipates two types of interoperability opportunities with transportation participants: • “Real Estate” Sharing on the Card—There are two models. In each model participants do not interact. In one model, an ATM or credit card embeds a chip containing the transportation application. In the other, an ATM or credit card has the transit application resident with the credit and debit card data on the same chip. Table 1 shows the relationship of a shared-chip architecture. • Card Functionality Sharing—This occurs when the transit application can be used to pay for services beyond transportation or a non-transit payment product can be used to pay for a ride. Table 2 shows the relationship of a shared application structure. The interoperability elements discussed in this report also apply to interoperability with non- transportation participants. An agreement between the participants must first be established. Once an agreement is established, the interoperable technology solution can be identified and a clear set of business rules developed that, at a minimum, define the following: • Technology requirements, • Processes for system operation, 6 Smartcard Interoperability Issues for the Transit Industry Figure 2. Intra-regional interoperability analysis. Multi-Applications Security Identification Card Characteristics Shared Value Purse Transit Products Trip Data Pe rs on al Id en tif ica tio n (e. g., D riv er s Li ce ns e) Ba nk C ar d D ig ita l S ig na tu re St or ed V al ue (e .g. , Co ffe e Ho us e) M er ch an t L oy al ty Po in ts Tr an si t Ap pl ica tio n Transit Benefits Purse (Pre-Tax $) Table 1. Shared-chip architecture. System Region A t i Identify Incompati- bilities I tif I ti- iliti Analyze Cost of Modification l t f ifi ti System Region B t i System 1 RegionN t 1 i N Identify Incompati- bilities I tif I ti- iliti Gap Analysis Gap Analysis Identify Incompati- bilities Analyze Complete Cost of odification Identify Incompati- bilities Gap Analysis ap Analysis

• Procedures for exchanging data, and • Processes for clearing transactions. The primary reason interoperability has not proliferated beyond transit is the proprietary nature of fare payment systems. Proprietary point of sale (POS) terminals purchased from an automatic fare collection (AFC) supplier for a retail application cost too much for a small mer- chant to acquire (i.e., approximately $1,200 to over $5,000 per unit). 1.5 Evolution of Interoperability with Open Payment Systems Now that financial institutions are implementing contactless payment products, a baseline architecture may be used to begin developing an interoperability strategy for transit with open payment systems. Given the recent activities associated with the financial institutions migrat- ing their credit and debit card product offerings to contactless smartcards, the following sce- narios for interoperability begin to emerge: • Acceptance of contactless bank cards on buses and at faregates, • Two or more transit entities arrange to accept each others’ closed stored-value payment prod- ucts, and • Acceptance of multiple-payment-enabled devices. To determine the interoperability requirements with an open payment system, the charac- teristics of the existing transit payment architecture need to be identified. Currently, all fare collection systems combine payment with the fare calculation into a single application, and payment is embedded in every layer of the system. This type of architecture substantially increases fare system complexity, and allows equipment suppliers to control the application software. Figure 3 illustrates a current conceptual fare payment system architecture. 1.5.1 Acceptance of Contactless Bank Cards As contactless credit cards proliferate, transit agencies become increasingly attractive cus- tomers for financial institutions. The most likely relationship that will emerge between the finan- cial institutions and transit agencies is similar to a merchant in the retail space. Under this type of relationship, transit agencies accept a bankcard for transit fare payment and pay a transaction processing fee to the financial institutions. The key issue is that the bankcard data structure is not designed for conducting fare calculations. Therefore, two baseline system architecture configu- rations emerge for using a bankcard to pay a fare: • Transit and credit card applications both reside on the same chip or • The credit card application only resides on a contactless chip. Introduction 7 Transit Application Functions Id en tif ica tio n Ca rd Ch ar ac te ris tic s Sh ar ed V al ue Pu rs e Tr an si t P ro du ct s Tr ip D at a Tr an si t B en ef its Pu rs e (P re- Ta x $ ) Table 2. Shared application structure.

The transit application residing with a credit card application on the same chip has been the vision for smartcards since the early 1990s. Though technically feasible, the institutional barriers still make this configuration economically infeasible. However, using a contactless credit card prod- uct for fare payment is technically feasible in a cost-effective manner if some of the institutional constraints can be modified. The architecture for this configuration is illustrated in Figure 4. 8 Smartcard Interoperability Issues for the Transit Industry Payment Sales and payment data Ridership and payment data Figure 3. Current conceptual fare payment system architecture. Payment Payment Sales and payment data Ridership data Payment data Figure 4. Disaggregation of payment from ridership and fare calculation.

The primary characteristic of this architecture is the disaggregation of payment from the rid- ership information. Similar to a retail transaction where the cash register calculates the sale, the faregate or farebox conducts the sale. The amount of the sale is transmitted to a POS terminal that processes the card payment. The terminal notifies the cash register when the payment is completed. At this point in the transit world, the faregate opens or the appropriate signal acti- vates or a message displays on the farebox. The application of business rules to provide fare cal- culation could be accomplished by central server equipment at the agency or region as an offline process at an end-of-day period. Once calculated, an aggregate transaction could be sent to a bank representing a cardholder’s transit costs for that day. The disaggregation of payment from the ridership information collection is an intermediate step in the evolution to open interoperability for fare payment. The key challenge for making this configuration a reality is the cooperation of the supplier community. As subsequently discussed in the Financial Services Industry Interoperability Issues section of this document, the supplier community for the financial services industry has developed readers that can accommodate mul- tiple contactless payment products. If transit adopts this model, most of the data interoperabil- ity concerns discussed in this document are alleviated by moving from a data-rich stored-value transit application to the simple recording of a bankcard presentation. 1.5.2 Multiple Closed Stored-Value Payment Products Closed stored-value products are becoming an increasingly attractive means to create loyal customer relationships. In the retail environment, coffee shops such as Starbucks and Peet’s issue closed-account-based stored-value cards. Sports venues are also beginning to recognize the ben- efits of a contactless stored-value payment media. Two parts are required to create interoper- ability between disparate closed stored-value systems: • The need to read participants’ cards or payment media and • Agreement on how settlement will occur. First, each participant must have a reader that can read the respective cards. The readers must be able to generate a transaction record with sufficient payment data, including time and date, purchase amount, and transaction location. Second, no complex transaction processing system is needed to conduct settlement between two disparate stored-value payment systems. If two closed stored-value payment system operators agree to accept each other’s media and the read- ers can read each payment medium, settlement may occur by using the data collected by each system, as long as the participants trust the integrity of the transaction data generated. This type of arrangement is a referred to as a “trust model,” because it requires participants to trust the integrity of the transaction data. The trust model can create interoperability with less technical complexity and can work with most technologies or different combinations of technologies. The trust model may be used by two or more participants. The transportation council of the Smart Card Alliance has a project under way that would establish a trust model for use in clearing transactions between multiple- party closed-payment systems. 1.5.3 Multiple Payment-Enabled Devices There are two configurations of payment-enabled devices: • Transit-enabled contactless chips embedded into devices and • Devices with transit application (software) that communicates with the reader in a non-ISO- 14443-compliant mode (e.g., Bluetooth, 802.11, or infra-red). Introduction 9

The most common payment-enabled device is a key fob with the same contactless chip as a smartcard (e.g., the ExxonMobil Speedpass device). Contactless smartcard chips have also been embedded in mobile phone covers or even into a designated slot in the mobile phone. The pri- mary difference between a contactless smartcard and a key fob or mobile phone cover is the form. Therefore, when a transit-enabled contactless chip is embedded in, for example, a mobile phone cover, interoperability is the same as for transit-issued contactless smartcards, as long as the same contactless chips are used. Interoperability between devices that have a transit-payment application or a non-transit- payment application that may be used to pay a fare on a bus or at a faregate using a non-ISO-14443 interface will have to be established on an individual basis. The financial services community has evaluated different wireless interfaces for payment and established interface specifications that are available on the Visa website. 1.5.4 Financial Services Industry Interoperability Issues The financial services industry is in the early stages of rolling out contactless payment prod- ucts. The only standard that financial institutions have agreed to use for contactless payment is ISO 14443. MasterCard and Visa’s payment applications started out differently. The MasterCard application used a separate account number on the card linked to the cardholder credit card account in the back-office system (similar to the ExxonMobil Speedpass architecture).Visa, how- ever, encodes a magnetic stripe image in the contactless chip memory. The card associations are beginning to agree on a common specification for contactless payment. The terminal suppliers are providing POS devices that can read and process all contactless payment products. Terminal suppliers have started developing the necessary middleware (software) to provide merchants with maximum flexibility to choose which contactless payment products to accept. 1.6 Hypothetical Examples—Interoperability Between WMATA and TransLink To determine what information must be exchanged between systems to create interoperabil- ity, two real-world systems were selected for the following hypothetical examples: • Using a TransLink Card from the San Francisco Bay Area Region to pay for riding a Washing- ton Metropolitan Area Transit Authority (WMATA) bus or train in Washington, DC; and • Loading value on a SmarTrip card from Washington, DC, in San Francisco to pay a fare to ride a train or bus. The first element of interoperability that must exist is the capability of the readers of each par- ticipant to read and write to cards. For this discussion, the process of reading and writing to the cards is addressed by ISO 14443. The second element is the data to be exchanged between the card and the reader. Such data may also be designated as the transit application. The third ele- ment is the transfer of transaction data from the devices (e.g., faregates and add-value machines) to the central processing host. The fourth element is the exchange of transaction data between the participating entities to allow settlement for value loads or uses of the card in the respective systems. Table 3 shows the minimum information required across a typical AFC system, such as those represented in this case study. The tiers presented in the table begin with the data source for the data input, the card, and end with the data output used to generate the documentation for clear- ing between WMATA and TransLink, the back-office system. 10 Smartcard Interoperability Issues for the Transit Industry

To identify the minimum information required to allow financial settlement between two or more participating entities, which may include a non-transit merchant, the following examples have been developed for each distinct process: • Information to be exchanged for payment only, NO card loads; • Information to be exchanged for loading value, NO payment transactions; and • Process used to determine settlement position by a participant, the aggregation of payments and loads. 1.6.1 Information to Be Exchanged for Payment Figure 5 identifies the minimum information to be exchanged between each element of a fare payment system—from the inception of the transaction between the card and reader, through Introduction 11 * Encoded on card for distance-based fare structures Card Number Card Value $ Card Type Time Date Location* (Terminal Number) Fare Value $ Trans- action Number Card √ √ √ √∗ √∗ √∗ Payment Device Entry √ √ √ Exit √ √ √ √ √ √ √ √ Load Device √ √ √ √ √ √ √ √ Back Office √ √ √ √ √ √ √ Table 3. Information required at each AFC system tier. Trans # Card # Date & Time Fare $ WMATA Terminal # Entry Exit ATA M W metsyS Transaction Data TransLink Transactions Time Date Location deri uqeR n oita mr of nI Time Date Location (terminal number) Fare $ Card type Card number sk naB WMATA Central Processor TransLink Central Processor Settlement File TransLink Card WMATA Bank MTC Bank $ ATA M W metsyS deri uqeR n oita mr of nI sk naB Figure 5. Using TransLink Card to pay at WMATA.

12 Smartcard Interoperability Issues for the Transit Industry Trans # Card # Date & Time Load Value $ WMATA Terminal # k niLs narT met syS WMATA Load Transactions d eri uqeR n oit a mr of nI Time Date Location (terminal number) Load Value $ Card type Card number sk naB TransLink Central Processor WMATA Central Processor Settlement File SmarTrip Card TransLink Bank WMATA Bank $ k niLs narT met syS d eri uqeR n oit a mr of nI sk naB Figure 6. Loading value to the WMATA Card at a TransLink load device. Figure 7. Process for net settlement position. Net Payment Transactions t y t r s cti s WMATA Activities With TransLink Cards TransLink Net Load Transactions t r s cti s Net Settlement Processing t ttl t r c ssi TransLink Payment to WMATA r s i k y t t WMATA Payment to TransLink y t t r s i k TransLink Bank WMATA Bank $ $ (Negative) Positive Activities With ink Cards ink

transfer of funds to the agency bank. This hypothetical example isolates the logic and dataflow to payment transactions only; no loads take place. The payment transactions are also aggregated before transfer between the participants. 1.6.2 Information to Be Exchanged for Loading Value Figure 6 identifies the minimum information to be exchanged between each element of the load network—from the inception of the transaction between the card and reader through transfer of funds to the agency bank. This hypothetical example isolates the logic and dataflow to loading value only; no payment transactions take place. The load transactions are also aggre- gated before transfer between the participants. 1.6.3 Process for Determining the Net-Settlement Position Once an agreement has been established between agencies to accept each others’ smartcards for payment, a methodology needs to be set up to allow the “net-settlement”position to be deter- mined. (The net-settlement position is defined as the result of when the net-payment transac- tions are balanced against the net-load transactions for a specific agency before the information is transferred between participants.) Net settlement processing does not necessarily need to be conducted by a central computer system. If participants can agree, a spreadsheet using data collected by the fare system is suffi- cient to determine how much one participant owes the other. Figure 7 illustrates the logic for determining the net-settlement position before transferring funds between participating agencies’ banks. Introduction 13

Next: Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems »
Smartcard Interoperability Issues for the Transit Industry Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB Transit Cooperative Research Program (TCRP) Report 115: Smartcard Interoperability Issues for the Transit Industry explores interoperability; identifies information needed by public agencies to implement smartcard payment systems interoperability; examines the necessary information flows; and outlines a set of functions needed for a standard public domain application programming interface (API) that may be used in the development of a uniform application protocol data unit (APDU). The report also includes a prototype for an API and an APDU that demonstrates this “proof of concept” for International Organization for Standardization-compliant Type A and Type B cards.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!