National Academies Press: OpenBook

Smartcard Interoperability Issues for the Transit Industry (2006)

Chapter: Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs

« Previous: Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems
Page 28
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 28
Page 29
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 29
Page 30
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 30
Page 31
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 31
Page 32
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 32
Page 33
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 33
Page 34
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 34
Page 35
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 35
Page 36
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 36
Page 37
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 37
Page 38
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 38
Page 39
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 39
Page 40
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 40
Page 41
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 41
Page 42
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 42
Page 43
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 43
Page 44
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 44
Page 45
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 45
Page 46
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 46
Page 47
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 47
Page 48
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 48
Page 49
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 49
Page 50
Suggested Citation:"Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs." 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 50

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.

This chapter compares the interoperability of programs currently implemented or under development. The research identified similarities and differences in the system features, the data exchange, and the policies for selected peer agencies, and begins to establish benchmarks and best practices for developing interoperable smartcard systems for transit. Establishing the benchmarks and identifying best practices is based on conducting a detailed survey of agencies that have implemented or are in the early stages of implementing a regional smartcard fare payment system. Most agencies surveyed are U.S. and Canadian transit operators, because the legislation under which U.S. and Canadian transit agencies operate limits the com- mercial opportunities for innovative business arrangements such as establishing corporations and issuing shares for participation in a business similar to those in Singapore, Hong Kong, or Europe. Fully implemented regional smartcard fare payment systems in Asia and Europe have been oper- ating longer than any in the United States and Canada. Because the international projects con- tinue to serve as benchmarks throughout the world, they have also been included in the survey. The research focused on identifying the information exchanged between participating agen- cies. The survey data are intended to provide a benchmark for comparing the data elements crit- ical to achieving fare payment interoperability. These critical elements are identified in Chapter 4. Key policies affecting interoperability are also part of the survey, because establishing policies that tie agencies participating in an interoperable fare payment system together is equally impor- tant to technology decisions. Moreover, the findings and current trends both within and outside the transit industry are compared. Particularly, adding non-transit services (or becoming inter- operable with non-transit services) affects the data elements to be exchanged. The primary sources of information were transit agency personnel and project managers who have or have had direct project involvement. Secondary sources of information consisted of a lit- erature review (particularly websites and project documentation). The research team’s direct involvement through engagements with the planning, design, and implementation of many of the systems served to substantiate the information provided by primary and secondary sources. The regional (interoperable) fare payment systems reviewed in this chapter are • SmarTrip—Greater Washington, DC, Metropolitan Area, Maryland, Northern Virginia (www.wmata.com/riding/smartrip.cfm) • TransLink—San Francisco Bay Area (www.mtc.ca.gov/projects/translink/translnk.htm) • Chicago Card—Chicago, IL (www.chicago-card.com) • Central Puget Sound Regional Fare Coordination (RFC) Project—Seattle, WA (http:// transit.metrokc.gov/prog/smartcard/smartcard.html) • Go-To Card—St. Paul-Minneapolis, MN (www.mvta.com/tafsinformation.html) 28 C H A P T E R 3 Findings of Peer Review of Interoperable Smartcard Programs

• Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES)— Central Florida (http://www.pbsj.com/what/Core/ITS/projects/ORANGES/) • Go Ventura—Ventura County, CA (www.goventura.org) • Transit Access Pass (TAP)—Los Angeles County, CA (www.mta.net) • Compass—San Diego County, CA (sdcommute.com) • EZ-Link—Singapore (www.ezlink.com.sg/index.html) • Octopus—Hong Kong (www.octopuscards.com/eng/customer/apply.jsp) • Oyster—London (tube.tfl.gov.uk/content/ticketsoyster/asp) This chapter is organized as follows: • Section 3.1 presents an overview of the above programs with respect to their smartcard, reader, and hardware design. It also discusses their business policies and related data elements. • Section 3.2 identifies the commonalities in the information shared among agencies partici- pating in the listed interoperable programs. • Section 3.3 discusses current trends and new developments being considered or pursued within the smartcard programs, including – Payment for parking, bridges, and highway tolls; – Applications for financial institutions and retail; and – Expanded security and biometrics features. 3.1 Survey of Interoperable Agencies Surveys were conducted to gather current data on the following elements of each interopera- ble system: • Physical Elements—Physical characteristics of the cards and communication protocols; • Data Elements—“Essential” and “optional” data elements required for financial settlement between participating operators; and • Security Elements—Security architectures and the security devices used. For data gathering purposes, the security element information was included in the data ele- ments portion of the survey. The physical-layer results of the survey are presented in Table 7. The data-layer results of the survey are presented in Table 8. The optional data results of the survey are presented in Table 9. 3.1.1 SmarTrip In May 1999, the Washington Metropolitan Area Transit Authority (WMATA) introduced the SmarTrip card based on Cubic Transportation Systems’ (CTS) proprietary Go CARD tech- nology. WMATA has issued approximately well over 1 million SmarTrip cards for Metrorail, Metrobus, and station parking fare payment. Cardholders add value to their SmarTrip cards at Metrorail vendors or at Metrobus fareboxes. Metrorail vendors also vend magnetic tickets for non-SmarTrip cardholding customers; these tickets can only be used in the rail system. An implementation that will expand the SmarTrip functionality to surrounding transit providers is under way. Additional smartcard-enabled equipment, including vending devices, fareboxes, and readers will be deployed in support of the regional program. An integral feature of the SmarTrip program will be the implementation of the Regional Customer Service Center (RCSC). The RCSC will provide services to all SmarTrip participants and operators in the DC, Maryland, and Northern Virginia regions. The RCSC will consist of the customer service center, Findings of Peer Review of Interoperable Smartcard Programs 29

30 Sm artcard Interoperability Issues for the Transit Industry Table 7. Survey results: physical layer. Physical-Layer Features W a s h i n g t o n , D C , S m a r T r i p S a n F r a n c i s c o , T r a n s L i n k 1 0 C h i c a g o , C h i c a g o C a r d S e a t t l e , R F C 1 0 M i n n e a p o l i s , G o - T o C a r d C e n t r a l F l o r i d a , O R A N G E S V e n t u r a C o u n t y , G o V e n t u r a L A C o u n t y , T A P 1 0 S a n D i e g o , C o m p a s s 1 0 L o n d o n , O y s t e r H o n g K o n g , O c t o p u s S i n g a p o r e , E Z - L i n k No11. Is the card ISO 14443 compliant? No 5 No6 No7 No No22. Is the reader ISO 14443 compliant? No No 8 3. Does the reader modulate between Types A and B? No2 No No NoNo No4. Is the command set ISO 7816 compliant? 9 No4 No No No NoNoNoNo N/A If yes, which APDUs do you use and how many? N/ADNADNA DNA N/A DNA N/A DNA DNA DNA DNADNA PROFelicaPROPRO PRO N/ADNAPRO PROPRO DNA PROIf no, what do you use? DES3 DES5. List the type of card security used. 3DES3DESPRO PROPRO3DESPRO PRON/APRO Notes: 1Currently, Cubic’s Go CARD is used, which is not compliant, but they are taking steps toward using a compliant card. 2The current reader for rail (Cubic’s Go CARD reader) is not compliant, but they are procuring a system of buses that will use Cubic’s Tri-Reader, which is compliant and would modulate between Types A and B. 3The card security is a variation of 3DES. 4The cards are not compliant, but the system could be compliant if compliant cards are used. 5The card type is Mifare Type A, which is compliant for Parts 1 and 2, but not fully compliant for Part 4. 6The most commonly used card (Cubic’s Go CARD) is not compliant. 7Compliant with Part 1 only. 8Compliant with Part 2, Type B only. 9As allowed by ISO 7816, a subset of APDU commands has been implemented. 10Full project rollout has not ocurred. Listed information is “as planned.” Key = Yes DNA = Does Not Apply PRO = Proprietary N/A = Not Available DES = Data Encryption Standard 3DES = Triple DES

Findings of Peer Review of Interoperable Sm artcard Program s 31 7 Data-Layer Features W a s h i n g t o n , D C , S m a r T r i p S a n F r a n c i s c o , T r a n s L i n k C h i c a g o , C h i c a g o C a r d S e a t t l e , R F C M i n n e a p o l i s , G o - T o C a r d C e n t r a l F l o r i d a , O R A N G E S V e n t u r a C o u n t y , G o V e n t u r a L A C o u n t y , T A P S a n D i e g o , C o m p a s s L o n d o n , O y s t e r H o n g K o n g , O c t o p u s S i n g a p o r e , E Z - L i n k 1. What types of cardholder data are exchanged? -Card ID # -Card Issuer ID # No -Patron Profile Code (Age/Disability) No -Patron Language No No N/A No No No No No No No No N/A No 2. Do you have product data? -Fare Product ID # 3 3 3 3 N/A -Fare Product Validity Period 3. Do you collect journey data? -Agency ID # N/A -Date/time of specific transaction -Entry/exit location of patron No 4. Do you process and send configuration/mgt. data? -Autoload No No -Hotlist -Others? 1, 4 2 1, 4 No No 5 No No No No 4 5a. What types of security algorithms do you use? 3DES DES DES 3DES 3DES 3DES N/A 3DES 3DES 3DES DES 3DES 5b. How many key sets? One N/A N/A One One Two 6 N/A One One One N/A One Notes: 1The ability to block products 2Hot list goes to aging list if the card is not used in 2 months 3This number is based on a set of data elements that when complete forms a unique number 4Device hotlist 5Remote loads, configuration data to buses, future data (such as fare change) 6One key set for the smartcard and second key set for the transponder. 7Entry or Exit (not both) captured depending on agency implementation Key = Yes PRO = Proprietary N/A = Not Available DES = Data Encryption Standard 3DES = Triple DES Table 8. Survey results: data layer.

32 Sm artcard Interoperability Issues for the Transit Industry Table 9. Survey results: optional data. Optional Data Results W a s h i n g t o n , D C , S m a r T r i p S a n F r a n c i s c o , T r a n s L i n k C h i c a g o , C h i c a g o C a r d S e a t t l e , R F C M i n n e a p o l i s , G o - T o C a r d C e n t r a l F l o r i d a , O R A N G E S V e n t u r a C o u n t y , G o V e n t u r a L A C o u n t y , T A P S a n D i e g o , C o m p a s s L o n d o n , O y s t e r H o n g K o n g , O c t o p u s S i n g a p o r e , E Z - L i n k 1. Are the following data types exchanged? -Pretax/employer-based transit benefits No 3 No UC UC No N/A No -Pretax/employer-based parking benefits Yes No No No No No No No No No No 3 No UC N/A No No -Bridge/highway tolls No No 3 No No No No -Loyalty programs Yes 3 4 No No N/A No -Multiple purses UC No 3 No No UC No No -Universities No 3 No UC No No Nil No No No No No No -Retail No 3 No No No No No No Future 2. What other data are exchanged that might be unique? Nil 1 2 8 Nil 5 6 UC Nil 7 Nil Notes: 1Transaction/purse sequence numbers serve to identify gaps in data 2The back-end system does not carry any value so the server will charge the patron’s account, and when the threshold goes below 10 dollars, an email is sent to the patron. Also, there is a bonus program that provides 1 dollar back for every 10 dollars spent on the card. 3For this system, all these data types could be exchanged; however, to date they have not been used 4Members of the field operation test are provided incentives to participate in the form of discounts 5A smartcard transponder can be used to pay for parking or bus fare 6Automatic passenger counting 7Access to recreational facilities; access to gated communities 8Non-fare counting data (e.g., wheel lift and bike rack use) Key = Yes N/A = Not Available UC = Under Consideration

POS devices and network, walk-in centers, and WMATA’s data network concentrator. ERG Group received the contract award in July 2003 to install and implement the RCSC. CTS also received a contract in July 2003 to supply POS devices and the data network concentrator and to make upgrades to existing systems to support the regional program. CTS and ERG are working with WMATA to integrate their respective systems. Upon full implementation, the SmarTrip program will include the following regional bus and rail participants: • WMATA Metrorail-heavy rail; • Maryland Transit Administration (MTA)-light rail; • Virginia Railway Express (VRE)-commuter rail; • MARC-commuter rail; • Baltimore Metro—rail; • Annapolis Transit—bus; • Arlington Regional Transit (ART)—bus; • MTA Bus; • WMATA Metro Bus; • Corridor Transit Corporation—bus; • Fairfax City CUE—bus; • Alexandria DASH—bus; • Fairfax Connector—bus; • Frederick Transit—bus; • Harford County Transportation Services—bus; • Howard County Transit—bus; • Loudoun County Transit—bus; • Potomac and Rappahannock Transportation Commission (PRTC)/OmniRide—bus; • Montgomery County Ride On—bus; and • Prince George County-TheBus. 3.1.1.1 Fare Policies The following fare policies and customer features define the SmarTrip program: • Card Fee—$5 card purchase fee; • Fare Products—Bus and rail fares, parking; • Fare Categories—Full fare, senior/disabled, peak, off-peak, distance; and • Other Features—Balance protection/fare replacement, negative balance. 3.1.1.2 Transit Benefit Program As of September 2000, SmarTrip cardholders could receive direct deposited transit benefits on their SmarTrip cards using the SmartBenefits program. In the Washington region, employers may participate with Metrochek, a fare card voucher program provided as an employee benefit by more than 2,500 public and private employers. In the past, employers were burdened with hav- ing to distribute paper Metrochek fare cards and vouchers. The SmartBenefits program allows employers to access a secure website where the benefit is transferred electronically to the employee’s SmarTrip card. SmarTrip cardholders then claim their transit benefits from specific WMATA rail ticket vending machines (TVMs) located in each station. 3.1.1.3 Loyalty Program With WMATA’s planned Fair Fares loyalty program, cardholders will pay the lowest possible fare based on their card usage. This allows a cardholder to receive the benefit of an unlimited ride pass without having to actually purchase the pass. A counter on the card will log the rides, and if Findings of Peer Review of Interoperable Smartcard Programs 33

the cardholder takes the required number of rides in a day, the card is subsequently treated as an unlimited-use day pass. This feature is similar for weekly, bimonthly, and monthly passes. 3.1.2 TransLink The Metropolitan Transportation Commission (MTC) and San Francisco Bay Area transit agencies are implementing TransLink, a regional fare payment system for public transit in the Bay Area. TransLink cardholders can use a single smartcard for bus, train, light rail line, and ferry services provided by multiple operators throughout the Bay Area. In May 1999, MTC awarded a DBOM contract to Motorola/ERG. In addition to the TransLink cards, ERG will supply the following devices: • Add-value machines (AVMs); • Handheld card readers (HCRs); • Smartcard interface devices (CIDs) for vehicles and platforms; • Wireless data transmission system (for zone-based fares and data transfer); • Ticket office terminals (TOTs); • Retail POS devices; and • Central system networking and related equipment. ERG is providing a full range of cardholder customer services and financial clearing and set- tlement among agency participants. Customer services include a live operator help desk, 24-hour automated customer service, registration for autoload and balance protection, and card distri- bution services. The TransLink card is an ISO 14443 Type B smartcard containing both contact and contact- less interfaces. TransLink cardholders place their card within range of a CID on board a vehicle or at a station platform. The CID automatically deducts the correct fare, calculating transfers and appropriate senior, disabled, and youth discounts. The contact interface is used at AVMs to load e-cash value or transit fare products to the card. A planned on-street parking meter payment implementation will also use the contact interface. A 6-month pilot program (TransLink Phase I) was successfully conducted in 2002 with six transit operators implementing TransLink on their systems. The Phase I pilot served as a demon- stration and test period and included the following transit agencies: • Alameda County Transit (AC Transit)-bus; • San Francisco Bay Area Rapid Transit District (BART)-heavy rail; • Caltrain-commuter rail; • Golden Gate Transit (GGT)-ferry and bus; • San Francisco Municipal Railway (Muni)-light rail; and • Santa Clara Valley Transportation Authority (VTA)-bus and light rail. Phase I also included the integration of BART’s legacy faregates with TransLink CIDs. Although the formal evaluation period is complete, the pilot system continues to operate in the interim between Phase I and Phase II. The Phase II rollout will expand TransLink service throughout the original six operators’ sys- tems and also expand the capabilities to other transit operators in the region. Included in the expanded Phase II BART service is the integration of TransLink functionality with BART’s recently installed CTS faregates. To achieve this level of integration, ERG is providing CTS with an API. The API provides the TransLink business rules to the CTS faregate reader software that will be used when a TransLink card is presented to the reader. A similar integration of BART,VTA, and Caltrain TVMs is also planned. 34 Smartcard Interoperability Issues for the Transit Industry

Transit agency board decisions culminating in September 2003 have affirmed Phase II, or full regional deployment of TransLink. GGT and AC Transit will be the first agencies to offer full operational availability to their patrons in mid 2006, followed by BART and Muni in late 2006. TransLink will become available on the remaining 16 operators in 2007 and 2008. 3.1.2.1 Fare Policies The following fare policies and customer features define the TransLink Program: • Card Fee—Phase I Demonstration-free. Phase II—$5 card deposit proposed; • Fare Products—Multiple transit products, including e-cash, passes, and transit ride products (electronic ticket-books), inter-operator transfers; • Fare Categories—Adult, youth, and senior/disabled; and • Other Features—Balance protection, autoload, and negative balance. 3.1.2.2 Transit Benefits Program Employees of participating employers can elect to have their transit benefits loaded directly onto their TransLink card via autoload. 3.1.2.3 Loyalty Program No loyalty programs are planned. 3.1.3 Chicago Card As part of an effort to make fare payment easier, more reliable, and flexible, the Chicago Transit Authority (CTA) in August 2000 conducted a 6-month smartcard-based fare payment pilot pro- gram. CTA’s pilot, designed to test the feasibility of smartcard technology and to gauge customer acceptance, involved the distribution of 3,500 contactless smartcards used at designated sites and rail stations. CTA’s existing fare collection system, purchased from CTS in 1997, was already con- figured for smartcards. In addition, CTA integrated the farebox, manufactured by GFI Genfare, with the bus farecard machine (BFM). The CTS BFM processes both magnetic tickets and smartcards. In September 2001, following a successful pilot, CTA awarded a contract to CTS to increase the card base to 300,000 over a 3-year period. In late 2002, CTA announced the systemwide launch of the Chicago Card, a stored-value smartcard that can be used as fare payment on CTA bus and rail vehicles and Pace buses. The devices used for their system include • Turnstile faregates, • Transit card vending machines, and • Fareboxes. Customers may add value to their Chicago Card only at TVMs at CTA rail stations and some offsite locations such as grocery stores and currency exchanges. Registration and balance pro- tection of the Chicago Card is available to customers. In January 2004, CTA launched Chicago Card Plus, an account-based smartcard program that supports stored-value and 30-day passes. An added feature and requirement of the Chicago Card Plus is the automatic reloading capability that allows customers to charge their credit card for a user-determined amount each time the account balance falls below the $10 threshold. Chicago Card Plus customers can also direct their transit benefits to their card accounts. Chicago Card Plus customers cannot add value to cards at TVMs. Orders for Chicago Card and Chicago Card Plus are accepted on line, by phone, by mail, or in person at CTA headquarters. Both the Chicago Card and Chicago Card Plus provide pass-back privileges, which allow up to seven customers to board the same bus or enter the same rail station using one card. A full fare or Findings of Peer Review of Interoperable Smartcard Programs 35

transfer, as appropriate, is deducted from the Chicago Card or Chicago Card Plus account each time the card is presented to the reader. Customers with a 30-day pass also enjoy pass-back privileges and can pay for additional riders using a single Chicago Card Plus card under certain conditions. The first rider travels under the 30-day pass while pay-per-ride charges apply to the additional riders. The Chicago Card and Chicago Card Plus are based on the proprietary contactless GO-CARD format developed by CTS. 3.1.3.1 Fare Policies The following fare policies and customer features define the Chicago Card and Chicago Card Plus program: • Card Fee—$5 purchase and replacement fee; • Fare Products—Chicago Card-stored-value only; Chicago Card Plus-account-based pay-per- ride, 30-day pass; • Fare Categories—Full fare only (reduced farecard for seniors is planned); and • Other Features—Fare replacement/balance protection, automatic account replenishment (Chicago Card Plus only), negative balance (Chicago Card only), Internet loads and card man- agement (Chicago Card Plus only). 3.1.3.2 Transit Benefits Program Participants of the Regional Transportation Authority (RTA)/CTA Transit Benefit Program can have their pretax benefit automatically applied to their Chicago Card Plus account. The employer establishes an online account linked to their employee accounts and submits the pre- tax payroll deduction for posting directly to the account. 3.1.3.3 Loyalty Program Both Chicago Card and Chicago Card Plus users receive a 10-percent bonus each time their accounts are reloaded with $10 or more. 3.1.4 Central Puget Sound Regional Fare Coordination (RFC) Project Seven transportation agencies supporting approximately 130 million annual boardings are col- laborating to plan and implement a smartcard-based regional fare payment system that enables customers to use one farecard on multiple systems throughout the four-county Central Puget Sound area. The Central Puget Sound RFC Project will consolidate hundreds of existing fare media onto one smartcard to streamline the management of fare transactions and facilitate cross- jurisdictional and multi-modal trip-making in the Puget Sound region. The smartcard system will replace all current fare media. In the future, fares will be paid only via smartcard or physical cash. ERG was awarded a contract in April 2003 to design, implement, and provide operational support service for the regional smartcard-based fare collection system. Participating agencies include • King County Metro Transit-bus; • Community Transit-bus; • Kitsap Transit-bus and passenger ferry; • Pierce Transit-bus; • Everett Transit-bus; • Washington State Ferries-ferry; and • Sound Transit-commuter rail, express bus, and light rail (under construction). The RFC Project, which plans to use both reusable and disposable Mifare ISO 14443 Type A contactless smartcards, is scheduled for revenue beta testing in 2006 and full revenue operation in 2007 and will include the following devices: 36 Smartcard Interoperability Issues for the Transit Industry

• TVMs; • Customer service terminal (CST); • Fare transaction processor (FTP) on-board, handheld portable, and standalone; • Central data collection system; and • Driver display unit (DDU). Customers will be able to load value to their RFC card at TVMs, customer service offices, and retail outlets, or by mail, phone, or autoload, and via the Internet. In addition to transit fare pay- ment, the RFC Project is considering opportunities to use the card for parking payment and tran- sit employee identification and building access. 3.1.4.1 Fare Policies The following fare policies and customer features define the RFC program: • Card Fee—Planned: no fee during conversion period, card fee (e.g., $3 to $4) after the intro- ductory period concludes; • Fare Products—E-cash, fixed-period passes, and transit ride products (electronic ticket- books), intra/inter-operator transfers; • Fare Categories—Planned: Adult, youth, senior/disabled, and operator employee; and • Other Features—Planned: Balance protection/fare replacement, autoload, and Internet sales. 3.1.4.2 Transit Benefit Program A transit benefit program is planned that will allow cardholders to load pre-tax and employer- sponsored transit benefits to their RFC cards. 3.1.4.3 Loyalty Benefits Program A “frequent rider” program to reward riders with free rides is being considered. 3.1.5 Go-To Card Metro Transit, which serves the Minneapolis/St. Paul area, is developing the Go-To Card, a smartcard-based fare payment system. The goal of the Go-To Card project is to modernize an aging fare collection system and to speed passenger boarding. In January 2002, Metro Tran- sit awarded a contract to CTS to implement the Go-To Card system in the seven-county Minneapolis/St. Paul metropolitan region. The card will be accepted on the Twin Cities bus and the Hiawatha light-rail line. During December 2003 and the first half of 2004, Metro Transit per- formed hardware and software testing. Full public rollout has been scheduled for early 2006. The equipment procured includes rail and bus validators, TVMs, and a central system. The ticket machines for this system are unique in that they are programmed with four languages— English, Spanish, Hmong, and Somali. TVMs vend magnetic-stripe tickets and add value to smartcards. Cardholders can also load value to their Go-To Card at ticket stores, participating retail locations, and via an interactive voice response (IVR) system. Internet loads are also planned. The Go-To Card system uses a MiFare ISO 14443 Type A smartcard that will be integrated into the following equipment: • TVMs, • Platform and onboard card validators, • Handheld read/write devices, • Retail POS terminals, and • Central system. Findings of Peer Review of Interoperable Smartcard Programs 37

3.1.5.1 Fare Policies The following fare policies and customer features define the Go-To Card program: • Card Fee—$5 initiation fee (waived in first 90 days if card is registered); • Fare Products—e-cash, 31-day pass, 10-ride book (schools only); • Fare Categories—Adult, reduced (youth and senior), and mobility; and • Other Features—Balance protection/fare replacement, reverse autoload if attempts to collect autoload fail. 3.1.5.2 Transit Benefits Program Metro Transit plans to integrate the Metropass employer-sponsored transit benefit program. 3.1.5.3 Loyalty Benefits Program Metro Transit has no loyalty benefit programs available. 3.1.6 Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES) ORANGES is the first project in the nation that involves toll payment, transit fare payment, and parking payment via a single smartcard, and processing all transactions through a single source. The program is also unique in that it combines the capability for both stored-value pay- ment from the card and account-based payment such as those used in traditional electronic toll collection applications. In the toll application, participants have a choice of using a transponder in which the inserted card enables drive-through automatic toll payment, using a “touch-and- go” process to pay with their cards directly at devices in non-express lanes. The ORANGES project began in April 2001; it had been selected through a competitive grant process administered by the FTA. A 1-year field operational test (FOT) with 1,000 volunteers started in August 2003 and concluded in July 2004. An evaluation report was completed in 2004. The participating agencies include • Orlando-Orange County Expressway Authority (OOCEA), • Central Florida Regional Transportation Authority (LYNX), and • City of Orlando Parking Bureau. These agencies are using equipment and systems supplied by Ascom Transport Systems, Efkon, Jafa Technologies, and McGann Software Systems. Transend International (formally Touch Tech- nologies, Inc.) acted as systems integrator providing and operating the clearinghouse system. Cards are supplied by Gemplus. During the testing phase, the smartcard could only be used at select locations, including • SR 408 East-West Expressway-Holland East toll plaza; • LYNX Bus-Lines 13 and 15; and • City of Orlando Parking Bureau-three garages (Central Boulevard, Library, and Market Street). Each agency issued their own cards from a common stock; however, other agencies’ cards were accepted by all through the use of the common e-cash purse. Interoperability between agencies was achieved by sourcing all the technology from the single vendor team. 3.1.6.1 Fare Policies The following fare policies and customer features define the ORANGES program: • Card Fee—FOT-free. Phase II-$5 card deposit proposed; • Fare Products—e-cash for tolls and parking, 7-day and 30-day transit passes; 38 Smartcard Interoperability Issues for the Transit Industry

• Fare Categories—Adult, student, and senior/disabled; and • Other Features—Balance protection, auto replenishment/auto renewal, toll account number for account-based payment. 3.1.6.2 Transit Benefits Program None are available. 3.1.6.3 Loyalty Programs Discounts were provided as incentives for volunteers to participate. These discounts included a 15-percent discount for the LYNX transit customers, a 50-percent discount off hourly and daily parking fees for customers using specific garage parking, and a free EPASS transponder for the Expressway Authority smartcard transponder users. 3.1.7 Go Ventura The Ventura County Transportation Commission (VCTC) awarded a contract to ERG Group in May 2000 for its regional smartcard program Go Ventura. Installations began in July 2001 with full project rollout achieved in January 2002. The Go Ventura regional smartcard system has been in service since January 2002 and is accepted on all six of the County’s bus operators: • South Coast Area Transit (SCAT)-bus; • Simi Valley Transit-bus; • Thousand Oaks Transit-bus; • Camarillo Area Transit (CAT)-bus; • Moorpark Transit-bus; and • VISTA (Intercity Service). The Go Ventura program uses ISO 14443 Type B contact and contactless smartcards, where the contact mode is used to load value to cards at the sales office terminals and the contactless mode is used to deduct fares boarding the buses. Cardholders can load value to their card on board buses (except Simi Valley Transit and SCAT), via the Internet, at sales outlets, by phone, or by mailing a check to the customer service center. The Go Ventura system also allows Cal State University Channel Islands (CSUCI) to brand and provide smartcards usable for unlimited trips throughout the County bus system. Along with smartcard usage statistics, the system incorporates automatic passenger counting and provides sophisticated statistical analysis of system use. Go Ventura cards are issued to social services clients from various agencies within Ventura County. The system is scheduled to be upgraded next year following 5 full years of successful service. 3.1.7.1 Fare Policies The following fare policies and customer features define the Go Ventura program: • Card Fee—No charge. $5 for card replacement; • Fare Products—e-cash, monthly passes; • Fare Categories—Full fare, student, and senior/disabled; and • Other Features—Balance protection/fare replacement. 3.1.7.2 Transit Benefits Program None are available. 3.1.7.3 Loyalty Programs Cardholders receive a 10-percent discount for using their e-cash to board the system. Findings of Peer Review of Interoperable Smartcard Programs 39

3.1.8 Transit Access Pass (TAP) The Los Angeles County Metropolitan Transportation Authority (Metro) along with nine other municipal operators is introducing the TAP program. TAP is a smartcard-based regional fare payment system for multi-modal, public transit in the Los Angeles area. The TAP program will use two different smartcards. The proprietary contactless Go CARD supplied by CTS will be used for general public fare sales, while an ISO 14443 Type A MiFare card integrated with an HID access module will be used as the transit employee card. The HID portion of the card provides access to Metro building doors, stairwells, and elevators, while the Mifare portion interfaces with fare collection equipment to provide validation at fareboxes on buses or at validators at rail stations. In March 2002, Metro awarded the TAP contract to CTS with responsibility for supplying: • TVMs; • Standalone validators (SAVs) for platforms and stations; • Handheld validators (HHVs) for inspection; • POS devices; • Fareboxes; and • A central data collection system (CDCS) As a subcontractor to CTS, GFI will provide bus fareboxes with integrated smartcard readers as well as revenue equipment. There will also be more than 800 third-party supplier locations throughout Los Angeles County equipped with POS terminals that will allow customers to pur- chase and add value to their cards. The program is in the system-testing stage, with the central computer installed and supporting more than 200 fareboxes on buses at one of Metro’s operating divisions. TAP will be gradually introduced across Metro’s fleet of more than 2,500 buses and four rail lines following the successful pilot test at the first division. TAP will also be installed on the Metro Orange Line, a dedicated right-of-way bus rapid transit line under construction in the San Fernando Valley. Municipal operators will follow with TAP equipment installation in 2005. Although several other municipal operators are finalizing their plans to participate, these are among the confirmed TAP participants: • Metro-bus, light rail, heavy rail; • Foothill Transit-bus; • Montebello Municipal Bus Lines; • Torrance Transit-bus; • Santa Clarita Transit-bus; • Antelope Valley Transit-bus; • Culver City Bus; • Norwalk Transit-bus; • Long Beach Transit-bus; and • Los Angeles Department of Transportation (LADOT)-bus. Metrolink, the commuter rail system connecting Los Angeles County with five neighboring counties, is also undergoing fare collection system upgrades to prepare for interfaces to TAP. 3.1.8.1 Fare Policies The following fare policies and customer features define the TAP program: • Card Fee—Fee amount undecided; • Fare Products—Planned-Multiple transit products including e-cash, passes, and transit ride products (electronic ticket-books); 40 Smartcard Interoperability Issues for the Transit Industry

• Fare Categories—Adult, student, senior/disabled/Medicare, and operator employee; and • Other Features—Balance protection, autoload, secure access. 3.1.8.2 Transit Benefits Program Employer and county programs are under consideration. The employer program has been scheduled to become operational in the first quarter of 2005. 3.1.8.3 Loyalty Program A fair fares or best fare loyalty program is under consideration. 3.1.9 Compass The San Diego Association of Governments (SANDAG), teamed with eight San Diego-area transit operators, is leading the implementation of a smartcard-based fare payment system for the San Diego Region (SDR). The Compass card will be used as fare payment by bus, light rail, and commuter rail customers on the following systems: • North County Transit District (NCTD); • San Diego Transit Corporation (SDTC); • San Diego Trolley, Inc. (SDTI); • Chula Vista Transit (CVT); • County Transit Systems; • Direct Access to Regional Transit (DART); • National City Transit (NCT); and • MTS Contract Services South Bay. The vision for the project is the result of regional goals that the transit agencies set out to achieve beginning in year 2000, which were to • Simplify the use of transit, • Remove “barriers” to using transit, • Deliver improved passenger amenities, • Unify the procurement of AFC equipment, and • Automate San Diego’s existing manual revenue collection processes. After considering various technologies and approaches, SDR agreed that a regional fare pay- ment system based on smartcard technology would allow them to achieve their new directives, including to • Simplify transit fare payment for customers, • Improve and enhance agency revenue data collection, and • Provide regional clearing and settlement. In September 2002, the Metropolitan Transportation Development Board (MTDB) awarded two separate contracts for the AFC system. (Compass management responsibility has since been transferred to SANDAG.) One contract is with GFI Genfare for bus fareboxes and revenue equip- ment. The second is with Cubic Transportation Systems (CTS) for the smartcard and back office systems, including • TVMs; • Handheld card readers (HCRs); • Onboard and platform CIDs; • Ticket office terminals (TOTs); Findings of Peer Review of Interoperable Smartcard Programs 41

• Card issuance machines (CIMs); and • The central system (NextFare). As part of their parallel contracts, CTS and GFI integrated their onboard systems and interfaced the GFI farebox to a new CTS driver-control unit (DCU). The CTS smartcard reader resides in the GFI Odyssey farebox or stands beside existing fareboxes that will remain on some contracted sub- urban operators. The entire system is designed to communicate over the NCTD/MTS-provided network, which includes fiber-optic lines to each station and between operator sites. The program is being implemented in two phases. Phase I is 95-percent complete as of Novem- ber 2004 and includes the deployment of bus DCUs, fareboxes, and a limited function central system. Phase II includes the deployment of the remaining system components (i.e., DCUs and smartcard reader kits for contracted bus agencies, commuter rail and trolley equipment, HCRs, full customer services, and smartcards). Phase II is in the final design review phase. The Com- pass system will be operated entirely by following full system deployment. The Compass system will use an ISO 14443 Type A Mifare contactless smartcard capable of supporting expanded functionality beyond transit applications. As such, SDR is con- sidering commercial opportunities for the Compass card such as on-street metered parking, use in coffee houses, and several opportunities at the new downtown Petco baseball park. For now, however, SDR is focused on achieving the goal of a transit-application deployment in 2005. 3.1.9.1 Fare Policies The following fare policies and customer features define the Compass program: • Card Fee—Fee amount undecided ($5 being considered); • Fare Products—Monthly passes initially, then multiple transit products, including e-cash, passes, ticket books, and day passes; • Fare Categories—Adult, youth, senior/disabled, and operator employee; and • Other Features—Balance protection/fare replacement and autoload. Internet enrollment and fare product purchases (future capability). 3.1.9.2 Transit Benefits Programs None are available. 3.1.9.3 Loyalty Programs None are available. 3.1.10 Octopus In 1994, Creative Star Ltd. (now called Octopus Cards Ltd. or OCL) was established to over- see the development and implementation of a smartcard system for transit fare payment. OCL is a joint venture among six major transport operators in the Hong Kong region. After a 3-year test and trial period, OCL launched the Octopus smartcard program. The Octopus card, a stored- value smartcard based on Sony’s Felica card technology, is accepted on virtually all of Hong Kong’s transportation systems, including rail, ferries, buses, coach (shuttle) services, taxis, and tramways. The Octopus card may also be used to pay for parking at garages and car parks and on-street metered parking. The Octopus card is the first and largest multipurpose, contactless smartcard-based payment system in the world with nearly 11 million cards in circulation used in over 8.3 million daily transactions totaling HK$56.7 million. More than 95-percent of the pop- ulation aged 16 to 65 uses an Octopus card. 42 Smartcard Interoperability Issues for the Transit Industry

In April 2000, the Hong Monetary Authority authorized OCL as a deposit-taking company. The authorization allows the Octopus card to be used for non-transit payment. Payment at 7-Eleven convenience stores, the first non-transport-related application, was introduced in Octo- ber 2000. The Octopus card can now be used for payment at fast food restaurants, supermarkets, self-service kiosks and vending machines, conferences and exhibitions, recreational facilities, schools, theaters, and telephones, and for access control. The equipment used in the Octopus system includes • Multipurpose octopus processor (MOP); • MiniMOP; • Parking access and payment system; • The Octopus central computer; • Faregates; • POS devices; and • A central clearing center. 3.1.10.1 Fare Policies The following fare policies and customer features define the Octopus program: • Card Fee—HK$50 deposit, HK$7 card-refund handling fee, HK$20 bank switching fee; • Fare Products—Multiple transit products including e-cash, passes and transit ride products (electronic ticket-books), inter-operator transfers; • Fare Categories—Adult, children, senior, and student; and • Other Features—Balance protection, autoload, and negative balance. Alternatives such as Nokia phone covers, watches, and key chains are available in place of the standard card media. 3.1.10.2 Transit Benefits Programs None are available. 3.1.10.3 Loyalty Programs In 2002, Octopus launched loyalty programs in connection with retail applications. Discounts with retail participants and transit operators vary widely. 3.1.11 EZ-Link Following on the heels of Hong Kong’s Octopus card, EZ-Link is Singapore’s smart-card-based transit and non-transit payment system. The EZ-Link card is a contactless smartcard that supports stored value and ticket products, including period passes. Visitor EZ-Link cards are available and provide access to tourist attractions in addition to supporting public transit payment. The EZ-Link card is accepted on all mass rapid transit (MRT), light rail transit (LRT), and buses, as well as at non- transit participants, such as movie theaters, schools, libraries, and bowling centers. There are more than 5 million cards in circulation today with more than 4 million daily financial transactions. EZ-Link Pte. Ltd. (EZL), a subsidiary of the Land Transport Authority [Land and Transport Authority of Singapore (LTA)], was formed in January 2002 and is responsible for selling, dis- tributing, and managing EZ-Link cards as well as clearing and settling the card transactions gen- erated in transit and non-transit applications. EZL appointed Transit Link Pte. Ltd. as the agent to manage the day-to-day use of EZ-Link cards on public transportation. Transit Link is a consortium composed of SBS Transit Ltd., Sin- gapore MRT Ltd. (SMRT), and Trans-Island Bus Services, Ltd. (Tibs). Transit Link sells and dis- tributes EZ-Link cards, as well as provides customer service to cardholders. Findings of Peer Review of Interoperable Smartcard Programs 43

The EZ-Link card is based on Sony’s Felica card technology. Devices used in the systems include onboard validators, faregates, ticket offices, AVMs, and general ticketing machine (GTMs). The GTM provides written and video instructions available in English, Malay, Man- darin, and Tamil, but no audio instructions. 3.1.11.1 Fare Policies The following fare policies and customer features define the EZ-Link Program: • Card Fee—$5 (S) card deposit; • Fare Products—e-cash, passes, park-and-ride tickets; • Fare Categories—Adult, children, senior, and student; and • Other Features—Autoload/auto top-up. 3.1.11.2 Transit Benefits Programs None are available. 3.1.11.3 Loyalty Programs EZ-Link offers both transit and non-transit loyalty programs, including incentives on auto top-up transactions and fast food purchases. Up to 15 loyalty programs can be supported on each card, while the EZ-Link back office can accommodate up to 225 separate loyalty programs. 3.1.12 Oyster The Prestige Project was conceived to improve revenue collection and information manage- ment about journey patterns across the London Transport, now Transport for London (TfL) net- work. On the London Underground, the amount of ticketless travel, estimated to be approximately £45 million annually, needed to be reduced. The solution was to install faregates throughout the system and use smartcard technology to expedite the throughput of passengers. On the bus network, there was need for common ticketing and accounting across a deregulated market of different bus operators and for ensuring a fair apportionment of revenue on “net”con- tracts. Smartcard technology also offered the opportunity to adopt the “cash-less bus” resulting in faster boarding and reduced potential for fraud. In 1998, a 17-year contract was awarded to TranSys—a consortium of companies composed of Electronic Data Systems, Ltd (EDS), Cubic Transportation Systems (CTS), International Comput- ers Limited (ICL), and WS Atkins—to design, develop, deliver, and maintain a transit fare payment smartcard system for the London region. Oyster was introduced in a trial program that began November 2002 with 80,000 ISO Type A MiFare smartcards used by the London Underground and bus employees. In June 2003, a phased rollout began when monthly and annual season pass hold- ers could obtain an Oyster card. In January 2004, Oyster was expanded to include stored value (Pre- Pay) on the London Underground and Docklands Light Railway (DLR). As of October 2004, more than 2.1 million Oyster cards have been issued for fare payment on the following transit providers: • London Underground (The Tube)-255 stations; • London Bus-8,000 buses; • Tramlink light rail; • DLR; and • National Rail-28 stations. The five transit modes combined serve more than 8.5 million passengers a day. The Oyster- enabled equipment installed throughout the London region includes • Faregates, • Onboard validators, 44 Smartcard Interoperability Issues for the Transit Industry

• HCRs, • Ticket machines, • Ticket office machines, and • Back office and central system equipment. Oyster’s plans include expanding beyond transit by adding an open e-purse to the card and moving outside London by integrating with other railways in the United Kingdom. 3.1.12.1 Fare Policies The following fare policies and customer features define the Oyster program: • Card Fee—£3 for pre-pay, 7-day, and bus passes, all others free; • Fare Products—e-cash, passes; • Fare Categories—Adult, senior/disabled freedom pass, employee; and • Other Features—Balance protection, station-specified recharge, and Internet loads. In addition to TVMs and ticket offices, Oyster cardholders can add value to their card via tele- phone and Internet and at participating retail outlets. 3.1.12.2 Transit Benefits Programs A voucher program provides an Oyster card to employees of employers who participate in the program. The employer covers the cost of the Oyster card. The employer is then reimbursed through interest-free employee payroll deductions. 3.1.12.3 Loyalty Programs A loyalty program was launched that deducts 2003 adult single fares for trips taken in 2004 on the Tube and DLR. Plans include “Pre Pay Capping,” which will establish a maximum amount a traveler pays on any one day. 3.2 Findings The single commonality for all regional fare payment systems implemented is the proprietary nature of the design. Most contactless smartcards issued are proprietary (i.e., either Sony Felica card in Asia or CTS Go CARD in The United States and Canada). All of the interfaces to the back office system are considered proprietary. The security architecture is unique to each supplier. The lack of open specifications is the primary barrier to interoperability and the use of a transit pay- ment card for non-transit applications across the world. Suppliers continue to refuse to publish the interface documentation necessary to allow broad participation in an interoperable smart- card system. The only way interoperability has been achieved is by forcing the use of a single smartcard fare payment system supplier across a region. 3.2.1 Commonalities and Differences Critical information necessary to achieve transit fare payment interoperability may be grouped into the following elements: • Physical Elements-Mechanical and electro-physical characteristics of the contactless smartcard; • Data Elements-Minimum information stored on the card that allows fare calculations to be conducted; • Application Elements-Transit-specific data elements that facilitate transit operator-specific data needs for special services or reporting; Findings of Peer Review of Interoperable Smartcard Programs 45

• Security Elements-Methodology used to secure the data on the card from unauthorized access and manipulation; and • Optional Data Elements-Information required to increase the utility of the card for other uses than fare payment. The findings of the survey are discussed within the context of the interoperability elements. In order to achieve interoperability, all five elements have to be defined and complied with by all participants in a smartcard system. This rule applies to both transit and non-transit participants. 3.2.1.1 Physical Elements To achieve physical interoperability, a common set of physical characteristics for the smart- card needs to be defined, particularly if physical manipulation is required, such as insertion into a slot or automatic dispensing. The most common physical specification is conformance to ISO 14443 Part 1 contactless interface standard. Though not fully ISO 14443 Type A or Type B com- pliant, virtually all projects profiled use ISO 14443 Part 1 conforming cards. 3.2.1.2 Data Elements Tables 7, 8, and 9 make clear that, with few exceptions, the agencies profiled exchange the fol- lowing data: • Card ID number, • Card issuer identification, • Patron profile code, • Fare product ID number, • Fare product validity period, • Agency identification, • Date and time of specific transaction, • Entry and/or exit location of patron, • Hotlist number, and • Transaction value. The exceptions result from the level of functionality required by the fare payment system, whether the card includes a stored-value purse or just passes. These data are the minimum required to process inter- and intra-agency fare payment transactions. The data elements accom- modate existing fare structures and transfer agreements through the use of a common fare media—the contactless smartcard. 3.2.1.3 Application Elements A standard “application elements” definition for transit does not exist today in a published specification available to the public. Although interoperability exists within smartcard imple- mentations, the application is proprietary and specific to the region’s implementation. As an example, although the CTA Chicago Card application and the WMATA SmarTrip application use the Go CARD platform, the SmarTrip application is not supported within the CTA system, nor is the Chicago Card application supported within the WMATA system. Similarly, although the San Francisco TransLink application and the Go Ventura application use the MV5000 series plat- form, the two applications are not interchangeable. Therefore, despite interoperability within specific regional implementations, there is no non-proprietary, open standard application defi- nition that provides interoperability across a single supplier. However, applications such as SmarTrip, TransLink, and Chicago Card have integrated their employee benefits program with their card technology and therefore exchange of such data between operators is possible. The data exchange of these benefits is at the discretion of the transit properties. Other agencies, such as in San Diego and Los Angeles, are considering this 46 Smartcard Interoperability Issues for the Transit Industry

capability for future implementation. This integration is not fully automated and usually requires manual input by the employer or smartcard system operator. 3.2.1.4 Security Elements The security architecture varies across each implementation. The research found that most projects use either a variation of the Data Encryption Standard (DES) or a variation of the Triple Data Encryption Standard (3DES) as a cryptographic algorithm within their card and device tier. To achieve interoperability, at a minimum, the cryptographic security algorithms used for communication between the card and reader will need to be defined. In addition to the algorithms, the use of symmetric cryptography will require the exchange of key data to achieve interoperability. In general, each region has unique keys for accessing the data on its cards. To achieve higher order interoperability, a mechanism needs to be established that allows cards with keys from dif- ferent regions to be accessed in a single system. Key management is one of the most significant barriers to higher order interoperability because of the unique way each supplier handles secu- rity keys. All systems may use the same key. However, if the single key is compromised, then all keys need to be exchanged, which is time consuming and costly. 3.2.1.5 Optional Data Elements The survey indicates that the use of optional data elements for increasing the utility of the card beyond transit fare payment is not typically available. The most common uses beyond transit fare payment include • Identification for access control (e.g., to agency facilities or university campus services); • Transit and non-transit loyalty programs; • Bridge and highway toll payment; • Non-transit retail payment; and • Parking payment. The approach to implementing optional card features varies widely and will be affected by the systems and equipment design of the participants. Most specifications require the system sup- plier to be able to add these capabilities in the future. Because of the card design, at a minimum, the cards will need to be exchanged if the capability was not demonstrated during the design review. Moreover, if the transaction data need to be transferred to or through the transit central clearinghouse, costly software modifications will likely be required. 3.2.2 Current Trends and New Developments A trend for interoperable smartcard programs is using the stored-value purse for non-transit payments, such as payment for parking and bridges and highway tolls. Since the inception of transit smartcard programs, it has been envisioned that the transit card will be used with finan- cial institutions, for retail payment, and/or for secure access control. European and Asian transit smartcard systems are more mature than U.S. and Canadian sys- tems. Since U.S. and Canadian programs are only now beginning to be rolled out, the use of the card is limited to transit. However, the vision of most U.S. and Canadian agencies is to expand the utility of the card with other applications. The following two sections summarize the current trends and new developments in Asia and The United States and Canada. Given that Oyster only recently rolled out and where prolifera- tion beyond transport payment has not started, the discussion on the United States and Canada contained in Section 3.4 would apply. Findings of Peer Review of Interoperable Smartcard Programs 47

3.3 Asian Contactless Smartcard Trends 3.3.1 Octopus Several programs already have integrated non-transit applications into their functionality. The Octopus card is accepted extensively throughout Hong Kong at more than 200 different non- transit locations. Currently, the Octopus card can be used at the following types of non-transit locations: • Parking lots and garages; • Secure access facilities; • Retail stores (e.g, fast food chains, convenience stores, supermarkets, personal care stores, bakeries); • Self services (e.g., vending machines, photo booths, pay phones, photocopiers); • Movie theaters; • Recreational facilities (e.g., swimming pools, race tracks, amusement parks); and • Schools (e.g., food service). Additionally, the Octopus card can be used to control access to residential properties, offices, schools, and parking lots. 3.3.2 EZ-Link Similar to the Octopus card, the EZ-Link card in Singapore is accepted for payment by non- transit merchants such as hotels, fast food restaurants (e.g., McDonald’s), cafes, cinemas, school food services, libraries, and a bowling alley. The EZ-Link card can even be used to enable Muslims to contribute their annual alms, or zakat, through their EZ-Link cards during Ramadan. 3.3.3 Finding These programs use the capabilities of the transit application and the settlement functional- ity of the central system. Non-transit participants and merchants are treated the same as a tran- sit agency, from the perspective of transaction processing. 3.4 U.S. and Canadian Contactless Smartcard Trends 3.4.1 TransLink As the full rollout of TransLink progresses, the City of San Francisco has decided to expand the use of the TransLink card with the Department of Parking and Traffic (DPT) for payment at parking meters. The city recently purchased 25,000 new meters designed to accept smartcards. Development work to enable the meters to accept the TransLink card and include DPT as a par- ticipant in clearing and settlement is well under way with a planned demonstration program to begin in mid-2005. 3.4.2 SmarTrip Customers of Washington’s Metrorail may use their SmarTrip card to pay for parking at sta- tion parking facilities. WMATA is conducting pilots with financial institutions where the Smar- Trip chip is embedded in an ATM card. There is no direct connection between the debit card information and the data stored on the SmarTrip chip. 48 Smartcard Interoperability Issues for the Transit Industry

3.4.3 ORANGES In addition to fare payment for transit services, participants in Central Florida’s ORANGES project may use their smartcard to pay for downtown parking at two garages and for expressway tolls. The smartcard has a stored-value purse and the capabilities to store toll account data and prepaid multi-day bus passes. To facilitate toll payment, select participants were provided with a smartcard-enabled transponder that eliminated the need to stop at the tollbooth. 3.5 Summary As these programs demonstrate, there is no clear technical or business model for creating interoperability across multiple industries. Each opportunity uses the unique characteristics of each system. The information to be exchanged with the interoperable partners is developed as the project matures. Defining the information for non-transit opportunities is beyond the scope of this study and needs to be developed to address the specific needs of the participants. How- ever, the core information required for interoperability across multiple transit agencies can be effectively used beyond transit to non-transit participants. Transit smartcard projects are still in the early stages of development, particularly in the United States and Canada. Interoperability is still viewed primarily as a regional issue. Issues associated with interoperability beyond fare payment, though explored, have not been at the forefront when developing smartcard fare payment systems. This situation is attributable to the high cost of developing a system with the capabilities to be used for more than fare payment. Another factor contributing to this situation is the current competitive environment. Suppliers use technology to protect their market position. Even the most prominent programs in Asia have not achieved large-scale market penetration beyond transit fare payment as evident by the small average retail transaction amount of less than US$10. As a result of the challenges experienced by the global community of transit agencies, signifi- cant standards development efforts are under way—including in the United States and Canada, Europe, and Australia. Table 10 gives the names and contact information for the people interviewed for each of the systems profiled. Findings of Peer Review of Interoperable Smartcard Programs 49

50 Smartcard Interoperability Issues for the Transit Industry Location Washington, DC SmarTrip San Francisco Jennifer Cheng Program Manager Project Manager 510-817-3252 510-817-3251 Chicago Card Chung Chung Tam Representative 312-255-1818 ext. 5709 Seattle Margaret Walker Project Manager Supplier 206-684-1562 905-890-2794 ext. 222 Minneapolis Card Mike Tensfeldt Jim Alexander Supplier Project Manager 858-810-1308 612-349-7467 Central Florida ORANGES Tom Delaney LYNX Project Manager Project Consultant 407-254-6071 407-647-7275 ext. 4121 Ventura County, CA Go Ventura Steve DeGeorge ext. 103 Los Angeles County, CA TAP San Diego Towle Brian Monk Project Manager Supplier 619-557-4502 858-614-4481 Hong Kong London Brian Monk Client Bus. Mgr. Supplier 44 020 7918 6019 858-614-4481 Singapore ext. 222 Project TransLink Chicago RFCS Go-To Compass Octopus Oyster EZ-Link Contact Name Doug Deckert Scott Rodda Candace Carlson Doug Jamison Jane Matsumoto James Drieisbach- Joseph Lee Richard Thomas Margaret Walker Supplier Supplier Project Manager Project Manager Client Project Manager Contact Title Telephone Number 202-962-2457 805-642-1591 213-922-3045 416-495-3339 905-890-2794 Table 10. Interviewees for each system.

Next: Chapter 4 - Findings of Key Information to be Exchanged Between Agencies »
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!