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.