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.
44 Among full-featured ABFS already deployed by agencies are at Ventra (CTA, PACE, Metra) and Transport for London (TfL). Several agencies are developing an account-based system, including GOPass (DART), SEPTA Key Program (SEPTA), and Hop Fastpass (TriMet). Moreover, mobile tick- eting solutions (see Figure 2), which have boomed in the last two years, are built on an account-based back office. Even smart card systems are using customer account management systems to provide balance and card protection and online payment services through account registration (WMATA, PRESTO, CLIPPER, and LA TAP, among others). ABFS is one type of architecture associated with the multi agency EFPS; the other architecture is card-based. This chapter describes ABFS, the dif- ferences between card- and account-based architectures, and key characteristics and benefits of the ABFS. It also details the Ventra program, one of the first open payment/account-based fare systems in the United States. HISTORICAL OVERVIEW Since 1996, the smart card, or card with a chip and antenna, was touted as the next major fare technol- ogy for transit (Fleishman 1996). However, there have been fewer than 27 regional transit smart card programs rollouts, and fewer than 40 overall, in the United States (âSmart card,â Wikipedia n.d.). Before 1999, the major new technology platform for fare payment was the plastic card with a magnetic stripe like the New York City Transit MetroCard, deployed in 1996. WMATA rolled out the first smart card-based fare systems in 1999. When the card is tapped against a card reader, the reader validates the credentials, calculates the fare, and processes the payment by deducting pre-stored funds from the card providing access to transit services. As described by SCA in 2011: âA card-based fare collection system requires that the payment media and card reader make the decision to approve or deny the fare payment transaction (including determining the fare).â Although the card-based model was described in several publications between 1996 and 2003 (TCRP Reports 10, 32, and 94) as providing significant beneficial âimpacts on customers and agenciesâ (Multisystems Inc. et al. 2003), the number of multiagency deployments in the United States since 2003 has only increased from 17 to 27. This is in sharp contrast to its adoption throughout the rest of the world (âSmart cards,â Wikipedia n.d.), where whole countries in Europe and Asia and provinces in Canada are using smart cards in their public transport systems. In 2004, the Chicago Card Plus (CCP) by CTA was introduced with an account-based architecture. The account-based architecture was defined by (SCA 2011) as a: transit fare collection system architecture that uses the back office system to apply relevant business rules, determine the fare, and settle the transaction. The terminal reads information stored on fare payment media and sends it to a back office over a network. The back office determines whether the card is valid and returns an âapprove or denyâ signal that enables the terminal to open the gate or to signal the rider and the bus operator on whether to allow passage. CTA implemented a customer account management system for its CCP in order to support transit benefits that were stored in the back office; and to protect registered media and the value associated with it. The model was augmented in 2006 by a successful open payment account-based demonstration chapter six ACCOUNT-BASED FARE PAYMENT SYSTEMS
45 project implemented at selected subway stations by NYCT with MasterCard and Citigroup. In 2010, the demonstration was expanded to include select NYCT bus routes, select PATH stations, and NJ Transit bus lines. Users registered their contactless bank cards and used them in the system, generating more than 200,000 transactions during the demonstration. Although not a multiagency deployment, UTA deployed a fully operational open payment fare system (Farepay card) in 2010, with a third party managing customer accounts. TYPES OF ACCOUNT-BASED SYSTEMS Although transit patrons may not see significant differences between the two types of systems, there are fundamental differences between card- and account-based systems. Table 11 contrasts the differences between these two architectures. Multiple implementation approaches can be applied to ABFS. A typology framework for the different types of fare systems was described in TCRP Report 177. The authors grouped the systems by four sets of design characteristics or attributes, each with two alternative approaches as shown in Figure 19. The four design attributes include system scope, design and technology, fare system architecture, and payment architecture. System scope defines whether the system supports one or more agencies and modes. Design and technology describes whether the system applied open and standard design principles, such as adherence to published specifications or technical standards. Fare system architecture identifies whether the system uses a card-based or account-based architecture; and payments architecture describes whether the payment media is openâstandard and industry-based, such as bank cardsâor closed, using branded and proprietary cards which can only be used within the system. Using this typology, when the system scope is fixed on multiple agencies and the fare system archi- tecture is fixed on an account-based version, four variations occur: â¢ Open design technology and payment architecture; â¢ Closed design technology and payment architecture; â¢ Open design technology and closed payment architecture; and â¢ Closed design technology and open payment architecture. The types of ABFS currently being designed and deployed fall into the open or standards-based design and technology area: These types of systems are typically called âopen architectureâ by the information technology industry because they rely on standard technologies and open interfaces to communicate. Several agencies are initially deploying closed payment architectures, anticipating extending their systems to an open format at a later time, as indicated by several request for proposals such as those from HART, TriMet, DART, and more (2014â2016). The closed payment architectures rely on payment methods such as stored value, tickets, or pass products that can only be used for transit. Open payment architectures allow bank-issued contactless media and mobile wallets. An open design and technology system can also allow for other credentials to be used. However, the instrument and reader may still be closed technology. These three types of ABFS are discussed in the following sections. Open Design/Technology and Payment ArchitectureâOpen and Mobile Payments An open payment system uses the same type of reader as those used in retail locations. The payment system uses banking standards and requires connectivity to a bank network to authenticate, vali- date, and authorize payment. Typically, an open payment system uses a contactless bank card based on MasterCard PayPass, Visa PayWave, American Express ExpressPay, or Discover Zip formats. Mobile payment is similar to bank card payments except the card message format is emulated using NFC. Mobile payments can also support Apple Pay, Samsung Pay, Android Pay, PayPal, or other emerging mobile wallet specifications. However, open and mobile payment systems do not
46 Function/Characteristics Card-Based System Account-Based System Fare Media Ã® Closed system Ã® Agency manages its own media Ã® Security and data formats are proprietary Ã® Closed or open system Ã® Bank media (credit/debit/prepaid) may be accepted (use of ISO 8583) Ã® Expandable to mobile and other media/instruments that conform to banking standards Purchase and provision of fare product Ã® Autoload/reload Ã® Fare products purchased anywhere Ã® Provisioned to card only at point of sale or reader device; (provisioning through a reader is complex) Ã® Fare products may be purchased and posted to the account immediately. Ã® Media/credentials used to access account must be registered in the account database. Register fare media Ã® Card/value replacement Ã® Fare media must be registered for card replacement. Ã® Card value is not immediately available; all transactions must be processed prior to calculation. Ã® Hotlists must be downloaded for fraud protection (for lost/stolen cards). Ã® All fare media are automatically registered in the back office (including media used by âanonymousâ patrons). Ã® Media, not registered by a user, are assigned an âanonymousâ account. Processing Fares Ã® Card and reader process fares Ã® Typical transactions about 200 ms Ã® Fares and discounts are processed in the back office. Ã® Typical transactions/authorizations about 500 ms to 700 ms (as specified by most RFPs). View transactions/travel history Ã® Transaction and travel history available only after several days Ã® Transaction and travel history are available immediately. Impacts with integrating transit and non- traditional partners Ã® Locked in to agency vendor technology Ã® Open architecture using account open interfaces Ã® Integrates with emerging mobile wallets, fops, watches without changes Change and update fare policies/charges/benefits Ã® Requires remote uploads and tests at equipment Ã® Back-office processing is available immediately or when scheduled. Settlement time with Ã® Settlement waits until fare system Ã® All transactions settled with partner partners devices (readers/vending/POS) report. organizations every day or preset schedule. Technology needs Ã® Technologies depend on deployed card readers and media. Ã® Online connectivity that enables reliable, real-time, or near-real time communications. Ã® Bank card security (PCI) must be implemented throughout the system. Ã® Customer media can change as long as long as reader communicates through open interfaces. Source: Survey data, format native Word table. TABLE 11 DIFFERENCES BETWEEN CARD AND ACCOUNT BASED FARE SYSTEMS
47 automatically mean a fare payment system is account-based. UTA deployed an open payment sys- tem, but does not run the customer account back office. Open Design/Technology and Closed Payment ArchitectureâMobile Ticketing A mobile ticketing system requires a user to register a device and payment method to purchase and provision a âticketâ or pass to his/her mobile device. The user must activate an electronic ticket or virtual secure token to gain access. The ticket may use one of many technologies including bar code, QR code, or animated visualization (ISO/IEC 18004 InformationâAutomatic identification and data capture techniquesâQR Code barcode symbology specification), but may adopt proprietary designs for flash passes (e.g., visual animation). Open Design/Technology and Closed Payment ArchitectureâUse of Other Credentials The key feature about an account-based system is that it is not tied to a specific customer-facing tech- nology. As defined by TCRP Report 177, âan âopen paymentâ transit fare payment system is designed to accept any form of compatible payment media. This could include payment media issued directly by the transit agency, by a financial institution, or by any third party.â As expanded by several publications (SCA 2011; Wallischeck et al. 2015), student cards, wearables that support Bluetooth low energy wire- less communications (e.g., watches, key fobs), chip-based government and work-issued identification, and personal biometrics are all potential credentials that can be registered and used as a secure token to access a back-office transportation account. Functions such as âchecking inâ (used by Facebook and other social media outlets) or passive recognition technologies such as license plate recognition and passive parking sensors are replac- ing readers where users must stop and pay for services. Now there are emerging strategies to track Bluetooth-enabled devices to passively monitor âbe-inâ (when a patron is on a bus) and âbe-outâ (when the patron leaves the bus). CASE ExAMPLE: VENTRA PROgRAMâAN ACCOUNT-BASED/OPEN PAYMENT FARE SYSTEM The Ventra Program, initiated in November 2011 and inaugurated in August and September of 2013, incorporated an account-based architecture which supports both closed and open payment archi- tectures. The program established a back office, set up a retail network, installed Ventra readers/ validators in all the buses, retrofitted existing turnstiles with Ventra readers/validators, and modified turnstile communications to handle real-time transactions. The medium adopted is the MasterCard PayPass, a standard issue prepaid card. The participating agencies include CTA, PACE, and Metra. Metra joined the payment system in November 2015 when the mobile Ventra app was deployed (Figure 20). FIGURE 19 Typology framework for transit fare payment system (Source: Wallischeck 2015).
48 Motivation for Developing an Account-Based System There were three major reasons that CTA chose an account-based open payment model. As described on the Ventra webâs Frequently Asked Questions section (Featured Questions 2016): âThe CTA and Pace are transitioning to Ventra for several reasons: â¢ Ventra is a step toward achieving a universal fare payment system in Chicago and the surround- ing suburbs, where transit riders will be able to use one card or mobile phone to pay for rides on all regional public transit systems. â¢ Ventra is a modern fare payment system that will meet the needs of transit riders now, and for years to come, by providing customers with convenient new payment options, including contact- less bankcards, and, eventually, compatible mobile phones. â¢ The existing CTA and Pace fare payment system is nearly 20 years old. It is very costly to repair and maintain, and it does not provide any long-term benefits.â Future âproofing,â or the ability to adopt to new payment methods such as mobile payment, was a significant reason for adopting this approach. Additional factors included the flexibility, scalability, and innovation that come with an open architecture, open standard, back office-based system. These factors include the ability to change/update fare policy and products immediately; add partners such as shared use mobility services by configuring existing functions; and extend payment instruments, such a mobile ticketing app, without major system changes. Ventraâs Deployment Challenges Moving from a card-based system to an account-based system is a fundamental change for the governance organization, organization partners, and customers. Although account-based systems are now prevalent, from airline clubs to payment accounts (e.g., PayPal, Amazon), users are still adapting to new payment methods and experiences. Although Ventra was not the first demonstration FIGURE 20 Ventra Mobile App function page (Source: screen shot of Ventra App).
49 or deployment of an open payment/account-based system, it was the largest. Ventra staff and users were not prepared for the changes. On the surface, the Ventra card was similar to the Chicago Card, its card-based system; customers tapped their contactless smart card on a reader. With Ventra, however, customers did not anticipate the underlying changes: a delay in transaction processing at the reader, the ability to use either a pass or stored values to access service, and viewing a charge on their account as a credit guarantee for distance-based fares. As the Ventra project manager put it, âHow do you prepare your customer to fundamentally change when nothing [appears to] change?â (M. Gwinn, Ventra Program Manager, personal communication, Feb. 2016). Software Issues Software âglitchesâ were an additional issue (Hilkevitch 2013). Information technology consultants the Standish Group Chaos Report (2014) track complex software projects over time. The Standish Group has found that the majority of complex software-based projects, 53%, are delayed or over budget. Furthermore, almost a third, more than 31%, are cancelled. These statistics show that Ventra was not atypical for the industry. Ventra initiated rollout after less than two years of devel- opment and took an additional year or two to resolve its problems. In comparison, card-systems with similar complexity experienced comparable deployment trials: for example, Clipper took approximately 10 years (C. Kuester, Director of Metropolitan Transportation Commission, personal communication, Feb. 2016); and ORCA took 6 years from notice to proceed to its go-live date (Murray 2015). When fixing the software, changes and updates took a larger than expected role during the deploy- ment. Ventra needed to deal with the configuration control procedures, including tracking the back- office software versions and ensuring that the software updates were consistent throughout the system. Customer Service Impacts Complaints about the system were well publicized both in the press and on social media, as evidenced by the dozens of local newspaper and blog posts between September 2013 and January 2014. During the initial transition period, patrons overwhelmed the customer service center; and the subsequent long wait times to handle customer complaints added to transition challenges. Among customer complaints were problems with wrong charges or incorrect stored value being posted to customer accounts, cards ordered not being delivered in a timely manner, issues with transit benefit transfers, and more. The biggest areas of concern involved the technology performance that drove customer experience. An example described by the project manager involved customersâ being charged multiple times for a ride. One reason was the time delay between the customer tap and reader validation: Because transaction validation at terminals were slow, customers would tap more than once, assuming the validator did not read their card the first time. They would then be charged for each tap. To address this issue, Ventra added an interim screen to the reader, which showed a âProcessingâ message before the âGo/Stopâ messages; and a constraint was added to the turnstile operations that required the arm to make a full turn before allowing a second payment. Another issue for bus customers involved the amount of time they needed to hold the card against the reader to actuate a payment. This issue was resolved by changing the language used to perform the transaction. Customers were advised to âtouch belowâ (versus âtap belowâ) the validators to urge customers to hold their card against the reader longer. Additionally, Ventra installed stickers on all the validators showing the proper positioning of a card against the reader. The Ventra team made assumptions about customer adoption that required changes as well. For example, it assumed that customers would move to the new Ventra (plastic) card, so although it planned for single use tickets, it did not plan for bulk sales to non-profit groups. Instead, market demand drove them to add bulk sales of paper tickets.
50 Transition Approach Originally, the region planned to transition from the CC/CCP in September 2013. Planning required that the entire systemâbuses, subway, and fare vending machinesâwould go live all at once. Most of the user groupsâregular riders, students, special rider classesâwould be transitioned together as well. This represented the classical âbig bangâ approach described in chapter five. The need to transition in August was driven by studentsâ needing their passes before the start of the academic year. Even with a pilot, the transition did not go as planned. As a consequence of the initial challenges, the full transition to Ventra was postponed. Instead, the Ventra team used methodical and incremental improvements to resolve problems, delaying the final transition until March 2014. The final transition occurred over several months starting from May 2014, when Ventra stopped selling the legacy card; in June it turned off the equipment that provisioned and reloaded fare products to the CC/CCP cards; and finally in July 2014, the old system was decommissioned, marking a full transition to Ventra. Integration Approach with Regional Partners Ventra is an integrated payment system for CTA, PACE, and Metra. The CTA and PACE systems were deployed together, and Metra was integrated with the deployment of the mobile app. Although PACE and CTA charge different fares and promote different fare policies, the integration went smoothly once the customer facing difficulties were resolved. Metra was challenging because new fare poli- cies and business rules needed to be added to the back office. Though expectations for implementing innovative fare integration strategies are anticipated, the region has not yet taken advantages of the capabilities. For example, there are few transfer benefits or regional passes that support the seamless transfer between Ventra partners. The regional reconciliation and settlement of revenues uses the model that was adopted for the CP/CCP passes. Credit card transactions made for Metra tickets are settled by Metra bank. PACE âpay per useâ transactions and settlement are applied on the same day. A pay per use transaction is a debit from the Ventra stored value or a contactless credit card transaction. Ventra Achievements and Successes Despite media criticism of what program manager Gwinn admits was a ârough rollout,â Ventra methodically addressed each problem and is now fully operational with little current criticism. The open payment architecture has enabled the use of new and emerging payment apps developed by handset suppliers such as Apple Pay and Samsung Pay. These mobile wallets work seamlessly with the Ventra reader/validator. As Gwinn stated, âMobile wallets were compatible with Ventra from day one.â Perhaps the most important achievement described by Gwinn is its account-based architecture, even more so than the open payment architecture. The account-based architecture enabled the seamless integration of the mobile ticketing app that is used by Metra. The back office provides scalability to extend its partnerships with other organizations, such as shared-use mobility providers and a retail network. Gwinn foresees the possibility that the Ventra card or app may eventually be accepted by other transit agencies in a pay as you go (credit card) or pay for use (debit stored value) transaction. Ventra Mobile Application The program integrated the mobile ticket app and Metra in the fourth quarter of 2015. The app went through extensive testing prior to its release. According to the Ventra team, the key to its success was addressing all the issues and problems prior to its release. After less than six months, Gwinn reported, the mobile app had more than 360,000 downloads. The benefits of the mobile app extend beyond
51 commuter rail customers buying and displaying tickets; because up-to-date stored value balances, travel history, and payment transactions are provided through the mobile app, bus riders may be the major beneficiaries of the system. Because cards do not display the balance in a stored value account, the mobile app offers riders up-to-the-minute access to their most recent transactions and products. As shown in Figure 20, the Ventra mobile app not only supports Metra virtual tickets, Ventra cards sales, and value lookup, it also includes real-time tracking information, wayfinding, trip planning, help, and commendation and complaints requests. Additional functions are expected over the next few years. Ventra Experience Moving Forward According to program manager Gwinn, the âshift to an account-based [fare system], even if trau- matic and painful, is worth it. The possibility for interregional and interagency coordination, even across regions is exciting.â Lessons learned from the Ventra experience include: â¢ Transition each user group separately. The deployment approach left no room to fix incremental issues with the software. Had Ventra implemented smaller user groups, it could have contained and addressed the issues with smaller communities. These communities could then help others during the subsequent stages. â¢ âTest, test, testâ before you deploy. Ventra learned this lesson and applied it to the deployment of the Ventra mobile ticketing app. Many regional fare systems have deployed this approach before deployment. This lesson is perhaps the most critical to ensure public acceptance. â¢ Increase outreach efforts. No matter how many outreach efforts are deployed, expected customer behaviors may not reflect actual customer behavior. To that end, Ventra learned that outreach efforts need to be applied early in the program to anticipate and learn from customer behavior as early in the process as possible. â¢ Extend the transition phase and decommissioning deadlines. Ventra experience shows that wait- ing until customers are comfortable with the new system, and glitches and issues are resolved before decommissioning the old system, makes for a smoother decommissioning process. Ventra implemented these lessons in the Ventra mobile app deployment, and received very few complaints and much praise (Ventra Google Play app page). As a stable system, Ventra staff now anticipates that it is poised to integrate other mobility options without significant challenges. NON-TRADITIONAL PARTNERS PARTICIPATINg IN COMMON ELECTRONIC PAYMENT SYSTEM There is a growing interest in creating a seamless, interoperable mobility landscape by linking and even integrating non-traditional mobility options such as bikeshare and rideshare services with transit. According to the U.S.DOT, as described in USDOT Beyond Traffic 2045 study, one of the next genera- tion transportation strategic goals is to create options for âseamless intermodal travelâroutes, sched- ules, payment systems, and traveler informationâ (Beyond Traffic 2016). Although there is a growing interest, the results from this survey indicate that many agencies plan to partner, but few have the capability to integrate their payment systems with non-traditional transportation network providers. The regional systems that have integrated their transit media with parking or complementary para- transit usually are administered under the same institutional structure; that is, county, authority, or agency. However, there is a growing interest in the integration. For example, several agencies, including Pinellas Suncoast Transit Authority (PSTA), have agreed to subsidize taxicabs and transportation network companies such as Uber and LYFT in a program called âDirect Connectâ to provide service in underserved areas (McMorris 2016). Bikeshare efforts are ready to launch in Portland (Andersen 2016), Los Angeles (Sotero 2015), Salt Lake City (T. Weisenberger, Volpe, personal communication, Jan. 2016), and Toronto (Simcoe 2016). The integration of fare payment services with other transportation modes and public and private partners is called âpayment conver- gence.â As described by TCRP Report 177, âOne of the objectives of convergence is to integrate route planning, ticketing, payment, and travel across all modes of transportationâ (Wallischeck et al. 2015).
52 The following section examines the concept of payment convergence and emerging strategies and models, with case examples of pilots and deployments. Transportation Service Payment Convergence A transportation convergent payment system, in theory, would enable a traveler to pay for all trans- portation services, irrespective of mode, using the same account. In the near future, a traveler could use a traveler account to pay for many types of servicesâpaying from one account for driving on a dynamically priced road, recharging an electric vehicle, parking at a transit station, catching a bus or train, or hailing, reserving, and sharing a mobility on-demand service to get to his/her destination. With the single account, travelers will then have seamless options to travel using the most convenient, effective transportation choice. This concept is described in the ISO Common Transportation Service Account Framework document, which includes at least the following modes (ISO 21724-1 Common Transport Services Account) â¢ Mobility service provider (which provides reservations, account management and trip planning in a one-stop app) â¢ Railâsubway and metro services â¢ Railâcommuter and inter-city train services â¢ Roadâcharging station for electric vehicles â¢ Roadâlong distance bus (commuter and inter-city) â¢ Roadâparking, shared-use mobility services (bicycle and car-sharing services) â¢ Roadâpublic transport services (fixed route bus service) â¢ Roadâtaxi and ridesourcing (ride hailing) â¢ Roadâtolled infrastructure (including high occupancy/tolling) â¢ Seaâferry. The list includes an information service provider who can present mode choices, plan (multimode) trips, reserve services, and provision payments. In building any seamless payment system, the TCRP Report 177 lists four goals for modal integration through payment convergence. The goals reflect not only customer benefits, but also transportation management and revenue goals: â¢ Integration of travel planning and ticketing across multiple, modes, through a single mobile application; â¢ Demand management, by incentivizing travel through pricing, rewards or credits, social nudges and competition; â¢ Increasing agency revenue through increased ridership; and â¢ Improving customer service and enhancing the customer experience. In addition to increasing revenue through ridership, transit may reduce costs and improve efficiency by partnering with private mobility providers to cover underserved areas, non-productive, or low- ridership routes such as connector, late night service, and some paratransit services (C. Roberts, former director at UTA, personal communication, March 2016). Integration Trends with Non-Traditional Partners Transit agencies often begin integrating modes by offering a single payment instrument that may be used on modes owned or operated by their agency such as parking (WMATA using SmarTrip) or paratransit (Minneapolis, CapMetro Austin). Some agencies, by using bank-issued media, can also integrate retail payment with transit; for example, the Ventra card, because it is a MasterCard PayPass instrument, links to stored value that can be used for either transit fare or retail sales. Several regions have implemented payment integration between transit and non-traditional transit modes to support demand management options. For example, Metro ExpressLanes (www.metro expresslanes.net) offers tolling credits for taking transit (see the case example describing LA TAP and Metro ExpressLanes Transit Rewards Program).
53 The first example demonstrating the integration of car-sharing service with a transit fare card was implemented by the CTA and IGO car-sharing service. Details of this integration are described in the case example describing Chicago Card and IGO later in this chapter. A first level of integration strategy is to display and link an alternative mobility service through a website or mobile app, with no formal benefit or common payment offered. For example, GO (gotransit.com) provides a selection of alternative options on its website (www.gotransit.com/public/ en/travelling/leaveyourcard.aspx); DARTâs mobile ticketing app includes a Connect2CAR function (see Figure 21). With DART, a customer can use DARTâs mobile ticketing app to select a ride- sourcing or car-sharing service. DART is currently in discussion with other taxi and shared-use mobility providers to add them to this function. Although there is no formal agreement or integration with the agencyâs payment system, the link goes directly to the service providerâs selection page and not to the appâs landing page. DARTâs approach to the next level of integration is described in the case example of DART and Mobility Service Integration Approach later in this chapter. As mentioned in the introduction, several bike-sharing systems are in the process of integrating with transit payment systems. The integration may require shared technologies such as the Toronto bikeshare organization. According to Metro News, Toronto Bikeshare is changing its locking tech- nology to enable integration with the Presto Card (Simcoe 2016). LA Metro, directed by its board, plans to integrate LA TAP with regional bikeshare services in mid-2016 (D. Sutton, C. Stevens, and R. OâHara, LA TAP staff, personal communication, Mar. 2016). Next-generation integration may come from third-party information service providers such as Ride Scout, Xerox, and Transit App. For example, Xerox developed a âwhite labelâ trip planning FIGURE 21 DARTâs GoPass function that links user to Transportation Network Companies (Source: GoPass App screen shot).
54 mobile application that provides door-to-door trip planning to users. The app enables users to generate options for transportation services based on several criteria, including a favored provider or mode (see Figure 22). Moreover, an instance of the application, the Go LA app, allows a customer to tailor his/her trip plan using preferences such as âsooner, cheaper, greenerâ (Sklar 2016). Although cost information is provided, the application falls short of reservations and payment integration for a multiagency EFPS (Figure 23). Non-Traditional Partner Case Examples The non-traditional partner case examples examine approaches and technologies used to integrate multimodal transport services, as well as their benefits, challenges, and lessons learned. There are many agencies that are initiating integration, but few who have actually implemented and deployed interoperable services. From the small sample available, the overriding common feature is the strong FIGURE 22 Go LA app, a third party developer app, provides door to door trip planning mobility options (Source: GO LA screen shot). FIGURE 23 Metro ExpressLanes Transit Rewards Program (Courtesy : Metroâs website: url: https://www.metroexpresslanes.net/ en/about/transit.shtml).
55 link and synchronization of customer account information; and at least one of the partners has a customer account management system. Although a transit agency may not benefit directly from the integration, it may benefit in other ways: Community service, traveler convenience through options, and agency cost efficiencies are a few elements reported by the partners in the examples. Case Example: Chicago Card and IGO (Car-Sharing) CTAâs Chicago Card Plus (CCP), later replaced with the Ventra Card, was used with the IGO car sharing service in the late 2000s. The CCP system was set up as an account-based fare system. Passes, stored value, and transit benefits were stored in the back office. When a CCP user registered for a CCP account, he/she was also offered an IGO subscription. For subscribers, additional information was requested: driverâs license, address, phone, etc. After customers were accepted to the program, they were sent a special CCP card to gain entry to the IGO vehicles. The CCP/IGO program consisted of integrating the two organizationâs back offices. Although the software applications were separate, the websites were seamless and invisible to the user, so CCP/IGO users could log onto their CCP account to reserve a car. The fare card used for CCP was incompatible with the technology implemented by IGO. The solution to this problem was to affix a RFID sticker to the cards distributed to patrons who opted for the car-sharing services. The project was suspended after IGO was sold and CTA began deployment of the Ventra Card (in 2009 to 2014). This system was the first integration of shared use vehicles within a transit setting. The project manager attributed the success to the account-based nature of the CCP, which enabled the seamless integration of multiple partners. Case Example: LA TAP and Metro ExpressLanes Transit Rewards Program âUsing their registered TAP card, transit riders can earn a $5 toll credit by taking 32 one-way trips during peak hours along the I-110 Harbor Transitway or I-10 El Monte Buswayâ (METRO Transit Benefit Program page). Metro ExpressLanes initiated a benefits program in 2010 that rewards drivers who frequently choose a transit alternative. Drivers are granted stored value in their ExpressLanes account if they show, through use of their LA TAP card, that they take transit instead of driving. ExpressLanes drivers must register and opt in to the service to participate in the program. The card is verified by LA TAP as being in good standing before a driver is accepted into the program. Then the ExpressLanes Transit Rewards Program receives transit travel histories based on TAP cardholder use on specific transit lines that operate along the corridor. The program takes a simple technical, low-budget approach to transferring TAP information to ExpressLanes; A filtered transaction file of the selected TAP cards in the program is uploaded to a secure site, consumed, and analyzed by the ExpressLanes account man- agement system. All the data is collected, stored, and processed in the back office account system. The ExpressLanes account management system applies the benefits to the userâs account, so the credit is applied to the stored value balance of the userâs tolling account. Case Example: DART and Mobility Service Integration Approach DART is in the process of deploying a fully integrated open architecture, open payment system similar to the Ventra program. The open architecture approach will enable the integration of multiple non-traditional on-demand and shared use mobility operators. This case example describes DARTâs process in integrating these partners, assumptions, and pilots to understand the scalability and customer experience of the deployment.
56 Initial Linking Approach In its current mobile app, DART has a page that links to âConnect2CAR.â As seen in Figure 21, when a user selects a link, the related app reservation page is displayed (if loaded onto the userâs mobile device). The relationship between DART and the vendor is informal, no contract is involved; there are no implications, representations or recommendations of the organization. As described by David Leinenger, DART CFO, the relationship is âcareful and casualâ (D. Leininger, chief financial officer of DART, personal communication, March 2016). No formal vetting is done, but the organization must be reputable. Inclusion of this page is considered a community service. Integration Approach Integration of partners relies on the fare system to support an open architecture, open payment framework. The integrated system will offer a mobile trip planning option where travelers may plan door-to-door trips in a one-stop environment. A service operated by RideScout will aggregate mobility operators into a single mobile trip-planning tool for regional travelers. This one-stop shop will provide planning, reservations, payment, and access credentials to the traveler in one app. A customer will not need to go to each mobility serviceâs application to pay for their services; all the transactions will occur using DARTâs mobile payment services app. The fare system development team includes three vendors who are developing the fare payment, mobile ticketing, and traveler information services. Information is exchanged through open applica- tion programming interfaces (APIs). All financial transactions will be processed by the fare payment system; however, there may be a separate billing/settlement organization. The traveler information service provider will integrate ride-hailing services, shared use mobility operators, and other services to plan, reserve, pay, coordinate, and push real-time information to DART app users. Among the issues anticipated with integrating include: â¢ PrivacyâDART is in the process of aligning the personal information privacy policies of all the partner organizations so that they are consistent and similarly applied. â¢ Legal liabilityâWith integration, the relationship between DART and its non-traditional partners becomes formal; a contract or agreement will need to be established. To this end, DART anticipates that it will monitor and request adoption of policies and procedures similar to any internal mobility service, including driver background checks, minimum service reliability performance, etc. â¢ Billing and settlementâAgreement on charging, billing, and remittance services are needed as the services become more integrated, particularly if benefits and discounts are offered by partner organizations. For example, one of the fare products would provide âfirst/last mileâ travel on a hailing service (e.g., Uber, LYFT, or taxi) within a specified area when a traveler buys a one-day pass. Questions concerning revenue allocation have yet to be addressed. In addition to the current mobility operators included on the Connect2Cars page, DART is in discussion on integration issues with other shared-use mobility providers including bike-sharing and electric bike-sharing (e-bike-sharing) services. Anticipated BenefitsâAssumption Validation Approach Because its service is based on an open architecture with open APIs, DART anticipates that adding services will not impact the current system. DART will determine how flexible, modular, and interoperable the system can be as it adds new services and integrates payment structures, all the while maintaining a satisfied customer experience. For example, DART anticipates that it will achieve cost efficiencies by extending its fare products to cover certain types of rides and riders. Many external ride-hailing trips that will be serviced by the day pass cover last mile trips within a certain region; these specialized services may cost less than 20% of what it would cost DART to provide the same trip. Several pilots will be initiated in the DART system during the rollout of the system. These pilots will test the agencyâs assumptions, realized costs, and benefits; fare integration and elasticity; and questions regarding the following: â¢ Scaling servicesâWhat is involved in adding or changing services, adding or extending fare/ tariff structures, and adding new mobility providers. This may not only cover how to present
57 the choices to the customer, but it may address the technology level: Does the system include enough processing and storage resources to add new providers? â¢ Integration complexityâAlthough similar to scaling services, the integration complexity drills down to a detailed level of the open architecture. Can the APIs support different tariffs and product types, service parameters (e.g., dropoff/pickup locations, access credentials), requests for service and payments, and exchange among operators of personal information that protects privacy? â¢ Customer friendlyâAs a system becomes more complex and the choices increase, will the system be user-friendly? The Uber app showed that simpler is better when it comes to making choices on travel. What are the criteria for making and ensuring that the fare system remains customer-friendly? Full deployment is expected in the second quarter of 2017.