National Academies Press: OpenBook

Smartcard Interoperability Issues for the Transit Industry (2006)

Chapter: Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems

« Previous: Chapter 1 - Introduction
Page 14
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 14
Page 15
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 15
Page 16
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 16
Page 17
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 17
Page 18
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 18
Page 19
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 19
Page 20
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 20
Page 21
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 21
Page 22
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 22
Page 23
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 23
Page 24
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 24
Page 25
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 25
Page 26
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 26
Page 27
Suggested Citation:"Chapter 2 - Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 27

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.

As the interoperability model shows, the first step toward creating an interoperable smartcard payment system is to identify the institutional requirements of the participants. Fare payment interoperability, regardless of technology used (e.g., smartcard, paper-based, or magnetic stripe) requires significant planning and cooperation among the participating agencies. In the transit industry, agencies have traditionally operated autonomously. Each agency’s organizational cul- tures, policies, procedures, and fare-collection equipment are different. Transit agencies considering implementing an interoperable smartcard fare payment system must address numerous institutional and technological issues that may create barriers to imple- mentation. This chapter focuses on the key institutional issues that have presented themselves during the implementation of recent U.S. and Canadian transit-based interoperable smartcard projects. This chapter also discusses strategies to overcome these barriers. The institutional issues have been categorized as follows: • Management and Organizational Issues—Organizational cultures of the participating agen- cies and their effects on management decision-making processes; • Financial Management Issues—The need to ensure that each participant does not lose rev- enue through participation; • Patron Impact Issues—Maximizing the use of the smartcard fare payment system by transit patrons (riders); • Equipment Design Issues—Ensuring equipment interoperability as an aspect of system design; and • Transit Industry Issues—Impeding the progress of dealing with the behavior of traditional sys- tem suppliers. Institutional requirements are formally documented in a policy statement. The policy state- ment becomes the reference for making decisions related to a smartcard project. 2.1 Management and Organizational Issues One of the most significant challenges to interoperable smartcard fare payment system imple- mentation is how the existing organizational cultures affect the participating transit agencies. Creating an interoperable fare payment system requires participating transit agencies to work together. Transit agencies that may have had limited or no previous interaction must work closely with one another for program direction and control. Key management and organizational issues that need to be addressed on the road to inter- operability include 14 C H A P T E R 2 Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems

• Establishing a governing body or project sponsor, • Identifying and mitigating operational differences, • Establishing a framework for program funding, • Creating a rollout schedule, and • Developing a contracting strategy. 2.1.1 Establishing a Governing Body or Project Sponsor One of the primary challenges of implementing an interoperable fare payment system in a multi-agency environment is encouraging agencies to work together for the overall good of the region and riding public. In many areas of the United States and Canada, transit agencies work autonomously toward accommodating the needs of their patrons. As a result, agencies become accustomed to controlling all decisions. Operational decisions are made that preclude the shar- ing of resources and limit effective cooperation with peer agencies. One of the first steps in implementing any regional fare payment system is to establish a gov- ernance structure, which will identify the institutional oversight structure and define the following: • Items under regional control, • Documentation of the governing structure, and • Participant representation. The governing body oversees the common elements of the interoperable fare payment system, which may include third-party services. Table 4 lists the different types of governing bodies. Par- ticipation in a governing body may require an agency to cede complete control over the common elements of the interoperable system. Even agencies that have an excellent working relationship may find adapting to a common governing body challenging. The planning and implementation of a smartcard-based interoperable fare payment project is a long and often difficult process. Once the governing body is established, a project sponsor needs to emerge to direct the effort and provide leadership for the participants. It is critical that the full commitment and support of the member agencies are obtained and that a clear management Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 15 Table 4. Overview of different types of governing bodies. Approach How It Works Where Used Corporation with Privately Held Shares Private, For-Profit Corporation • Shareholders include private transit and public operators • No majority shareholder • Not all participants are shareholders • Hong Kong Single Operator Owner Owner Agency Makes Decisions • Contract specifies requirements and obligations • London Joint Powers Authority (JPA) Independent Legal Entity • Created under powers of existing public entities • Composed of public entities • Singapore Memorandum of Understanding (MOU) No New Organization • Specifies decision making and participation • Contractually created governance structure • Los Angeles • Seattle • San Francisco • San Diego • Washington, DC

structure is in place before starting planning and design. The three most common types of proj- ect sponsorship are lead agency, regional planning organization, and management committee. 2.1.1.1 Lead Agency Delegating project management to one lead agency may be an option in a region where a regional transportation planning organization does not exist or where one agency has the criti- cal mass for establishing a system for meeting its own needs cost-effectively. The system imple- mented by the lead agency is used by the other participants. All participants share the cost of common services, but pay separately for any additional capabilities to meet their specific needs. A lead agency’s responsibilities are similar to those of the regional planning organization. In gen- eral, a project often benefits from a shorter design and implementation schedule when a lead agency is responsible; this can result in cost savings. The challenge for the lead agency is estab- lishing the agreements with the participating agencies. 2.1.1.2 Regional Planning Organization The project may also be managed by a regional transportation planning organization. A regional planning organization’s responsibilities are similar to those of a lead agency and man- agement committee. For this option, the regional planning organization solicits each member agency for input on agency-specific issues before making design decisions. The project often ben- efits from a shorter design and implementation schedule—this can result in cost savings; how- ever, the specific needs of participating agencies may be overlooked or not fully addressed in the interest of moving the project forward. 2.1.1.3 Management Committee Regions that lack a lead agency or a regional planning organization to champion the inter- operable fare payment project may elect to form a management committee to oversee the project. Each of the participating agencies is represented on the management committee. Each of the member agencies on a management committee can actively participate in project decisions. The management committee must be established early in the project life cycle in order to avoid spending valuable time and resources revisiting early project decisions. Management committee responsibilities may include critical functions such as • Preparing a governance plan—A governance plan documents the rules and bylaws by which the interoperable project operates, including areas such as dispute resolution and decision- making regarding new service offerings and addressing member agencies that leave or join the program; • Identifying the type of integrator contract—This includes identifying the types of services pro- cured or addressed in house and who will act as the contract administrator; • Assigning member roles and responsibilities—This includes how and when design reviews are completed and obligations regarding attendance at project meetings; • Drafting interagency agreements—This addresses subjects such as project cost allocations and information-sharing arrangements; and • Developing technical direction—This includes adherence to established standards and adop- tion of system features. A management committee structure requires special consideration of the contracting strat- egy. Given that contracting relationships must be formed between two legal entities, the man- agement committee may need to assign a lead agency or a regional planning organization as the contract owner for the project. Based on the surveys conducted for this project, governance issues are being resolved for most of the projects. Most projects proceed without first establishing the governing body. Projects 16 Smartcard Interoperability Issues for the Transit Industry

(including those in New York; Washington, DC; Atlanta; and Los Angeles) start with a lead agency implementing a new AFC system to meet their immediate needs and then expand the use of the new AFC technology to other agencies in the region. 2.1.2 Identifying and Mitigating Operational Differences Another challenge agencies face during the implementation of an interoperable fare pay- ment system is the differences in the way the participating agencies conduct business. For example, many of the largest agencies have extensive internal capabilities, including technical and operational resources to support most, if not all of their design, operational, and mainte- nance needs. The trend to consider outsourcing to fulfill these same needs is increasing. Agen- cies that have extensive in-house resources tend to prioritize more control over their operations; thus, those agencies tend to avoid outsourcing. The different organizational oper- ations philosophies of the agencies must be examined, and compromises must be considered to achieve interoperability. There are two primary dimensions for implementing the system-related service functions of an interoperable system: • Centralized—One entity performs all the functions. • Decentralized—Each participating entity is responsible for performing its own functions according to established business rules. The project sponsor must decide between a centralized or decentralized approach and must also decide whether the services are delivered using in-house or outsourced resources. The oper- ational philosophies of the participating agencies will determine the approach used for per- forming card-system-related functions. Table 5 summarizes the key characteristics of the centralized and decentralized approach. When choosing the delivery and service approaches, the following factors must be considered: • A function should be centralized when it is more relevant for the patron to experience a con- sistent level of service across all participating agencies. Centralization of functions creates increased efficiencies. • A function should be decentralized when it is more relevant to an individual agency’s operations. • A function is a candidate for outsourcing when – The function performance levels are easily quantifiable and measurable. – The function requires particular technical or skill-based expertise not available within an agency. Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 17 Delivery Approach In-House Outsourced Hybrid Centralized One agency performs the services for all other agencies A selected third party performs the functions for all agencies N/A Service Systems Approach Decentralized Each agency performs the functions for itself Each agency selects a third party to perform its functions Some agencies select a third party while some agencies perform the functions themselves Table 5. System service approach.

– The function may need to scale up or down, depending on demand or utilization levels. – There is potential for the provider to share the service across multiple projects. Table 6 identifies the primary card service functions that need to be addressed in an inter- operable smartcard-based fare payment system. For many implementations, a mix of centralized and decentralized approaches will be the most beneficial. By adopting this hybrid approach, a region can take advantage of existing capabilities and maintain individual agency culture while also maintaining consistency of service across the region. 2.1.3 Establishing a Framework for Program Funding Interoperable fare payment systems require a substantial capital investment for required equipment and systems. Funding for a project of this magnitude will likely come from multiple sources because of multiple agencies’ participation. The challenge with multi-jurisdictional funding is to arrive at an equitable formula that each of the participating agencies can endorse. Project funding requirements need to be determined early in the project life cycle to pro- vide adequate time to meet the requirements for securing the funding. Member agencies also need to evaluate the benefits derived from the capital investment. The cost-benefit analysis helps to identify expensive features that do not create value. However, regional systems need to be sufficiently flexible to scale as the participating agencies needs change and grow more sophisticated. 18 Smartcard Interoperability Issues for the Transit Industry Table 6. Primary card service functions. Function Card Management stock and management of patron account systems Distribution Management to merchants, employers, and other institutions Security Management including key and secure access module (SAM) management, fraud management, negative list management, application blocking, system access and controls Patron Services participating in the regional system, cardholders who use the regional smartcard, and retail/distributor merchants providing third-party services Financial Management movement processes and services, funds pool management services, revenue collection activities, general accounting for the smart card program, financial reporting services for the smartcards, and auditing services for the smartcard program Infrastructure Systems and Operations Management Includes management of the systems interface, network, application software, configuration control, device management, upgrades, and disaster recovery Program Management including brand management, regional program administration, policy shifts, and non-financial reporting Involves managing card inventory and deployment Includes providing support to the transit agencies Includes: clearing and settlement services, funds Includes management of all system security, Includes issuance and fulfillment of all smartcard Includes management of the regional program, Description

Development of the business case is critical in defining the funding strategy. The business case identifies the estimated capital and operating costs for the project and possible future expansion of the system. At a minimum, the business case consists of the following parts: • Estimated capital cost of the system; • Existing operating costs; • Operating and maintenance costs after system implementation; • Schedule for implementation; • Risk factors; • Initial operational cost (start of revenue service); and • Regional/management/lead agency oversight, administration, and management. Identifying specific funding sources for the interoperable fare payment project starts when the preparation of a business case is completed. The completion of the business case provides the basis for determining the relationship of capital investment balanced against long-term operat- ing costs. Once the specific sources of funding have been identified, funding agreements between the participating agencies need to be created. The inter-agency funding agreement establishes the level of capital investment and operating funding for which each participating agency is respon- sible. A commonly used strategy for allocating costs is to have each agency responsible for the deployment of its respective interoperable system components and to share operating costs based on use of the shared system components. Several formulas exist for distributing the operating costs among the member agencies. Existing projects have based these formulas on actual trans- action volume, transaction dollars processed, or a combination of both. 2.1.4 Creating a Rollout Schedule An overall project rollout schedule must be developed that details milestones for design, equipment production, testing, and implementation of the interoperable fare payment system across the participants. The rollout schedule is a critical component of operating cost. Because transaction processing and shared service, such as operating a call center, is a transaction-based business, the higher the volume, the lower the cost per transaction or call, respectively. The guid- ing principles to consider when developing the rollout schedule include • Realistic milestones reflective of actual experience, • Ability to fit within contractors’ capabilities, • Ability to be supported by the participating agencies, • Customer reaction and acceptance to change, and • Schedule changes in response to changing customer needs. System rollout can follow one of two approaches: • Phased—Different agencies and functionalities are brought on line at different times. This approach is the most common because the disruption caused by patrons having to learn a new behavior is isolated to a specific area and thus is less resource-intensive to manage. • Full Rollout—All agencies and equipment are brought on line at the same time. This approach requires extensive testing and careful preparation to successfully launch. In addition, signifi- cant resources are required to manage the first days of operation. The phased approach is typically adopted when the procurement is split among multiple sup- plier contracts. Risks associated with a phased approach include the possibility for patron con- fusion when the system works for limited agencies or has limited capabilities. Additionally, a phased approach needs to consider agencies that share existing fare products such as a period Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 19

pass. The rollout of these agencies will need to occur simultaneously to avoid affecting patrons who use the common fare product. Although it is more “patron friendly,” a full system rollout is more likely to disrupt operation for the agencies. Project resources must be spread over a wider range and are less able to focus on those areas that may experience issues such as high degrees of confusion and lack of patron education. Additionally, unlike a phased approach, a full rollout does not afford the benefit of “lessons learned” from the earlier implementations. Figure 8 identifies potential rollout strategies and the progression of each strategy. Other issues that will affect the scheduling of the interoperable project include • Availability of staffing resources, • Availability of financial resources, • Agency operations, and • Patron education and orientation 2.1.5 Developing a Contracting Strategy Participating agencies need to determine and agree on how the equipment and services will be procured. The main contracting challenge is deciding whether to procure the equipment and ser- vices under a single contract or through multiple contracts. Each approach has challenges that must 20 Smartcard Interoperability Issues for the Transit Industry Figure 8. Rollout dimensions. “Capability First” (e.g., TransLink, Octopus®, EZ-Link) “Big Bang” Limited Full Limited Full Card Capabilities Customer Participation Rollout Strategy and Progression “Limited Limited” (e.g., Oyster, LACMTA) “Participant First” (e.g., SmarTrip®) Participant Phase-In nI- e s a hP yti li ba pa C Limited Limited– Project rollout occurs with limited participation and less-than-full-system functionality Capability First– Project rollout captures nearly all of the planned system functionality but is limited to a subset of planned participants Participant First– Project rollout builds participant base on a system with only core functionality and capabilities Big Bang – Project rollout captures nearly all of the planned system functionality and includes all planned participants nI- e s a hP yti li ba pa C nI- e s a hP yti li ba pa C nI- e s a hP yti li ba pa C

be overcome, and the selection of the approach will depend on factors such as an agency’s appetite for integration risk, the availability of technical and project management resources, and the level of equipment and services to be procured. The most common contracting strategies are single procurement and contract, multiple procurements and contracts, and contract type selection. 2.1.5.1 Single Procurement and Contract Procuring all equipment and services under a single contract transfers most of the integration and interoperability risk (faregates, fareboxes, ticket vending machines (TVMs), card readers, and back-office systems) to the contractor. The contracting agencies have a single point of responsibility for lack of performance. The single procurement approach can accommodate a more aggressive rollout schedule because the schedules of multiple procurements and contrac- tors do not have to be coordinated. However, the single procurement approach may be less com- petitive because of the limited number of suppliers for highly specialized equipment (e.g., the farebox). Therefore, the procurement will result in fewer bids. 2.1.5.2 Multiple Procurements and Contracts By choosing to procure the equipment and services separately, agencies are likely rewarded with more competitive procurements and lower costs for “best-in-class” elements of the system. How- ever, the risk of integrating the services and equipment supplied under separate contracts will be borne by the contracting agencies. Another variant of the multiple procurements approach is to contract with a systems integrator to take responsibility for pulling separate pieces together and ensuring interoperability. While a systems integrator may be better equipped to deal with techni- cal and programmatic issues than the contracting agencies, this approach may also result in a higher cost than self-selected teams because each supplier must factor in a fee for technical and management issues caused by the systems integrator during the contract’s execution. In either case, the integration of multi-vendor equipment will result in higher overall system cost initially because of the increased software development and testing that result from the task of integration. 2.1.5.3 Contract Type Selection The type of contract structure must also be decided. The contract structure is driven by the types of services that the participating agencies can support and their current way of doing busi- ness. For example, if the member agencies decide to outsource clearing and settlement, patron support, and card management, a design-build-operate-and-maintain (DBOM) contracting structure may be advantageous because the contractor will design the system so that operating costs are balanced against the selection and cost of equipment components. If, on the other hand, the member agencies decide that these services will be supported in house, design-build con- tracting may be a better alternative. The challenge is to choose a type of contracting that takes advantage of existing in-house resources with minimal overlap. 2.1.5.4 Other Management Strategies To help address contracting issues related to interoperability, most U.S. and Canadian deploy- ments have retained the services of consultants specializing in transit and electronic payments. As an outside party with best practices developed over multiple projects, experts can assist the participating agencies with overall program strategy, document preparation, procurement assis- tance, and critical decision making throughout design and implementation. Using outside expertise can also serve to moderate the partisanship that can develop among the participating agencies and between suppliers. The outside expert provides an objective view based on best practices from other industries. Using the services and expertise of outside consultants will add initial cost to the project, but has proven to lower integration risk. Lowering integration risk pre- vents contractors from taking control of critical parts of an interoperable fare payment system and using this control to generate supernormal profits during the program’s life cycle. Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 21

2.2 Financial Management Issues Financial integrity is the highest priority for any agency participating in an interoperable fare payment system. This section discusses the key financial management decisions and issues that must be addressed, including • Transaction clearing and settlement, • Funds pool management, and • Financial exposure risk associated with advanced features. 2.2.1 Transaction Clearing and Settlement In a fare payment program where multiple operators are selling fare value accepted by more than one operator, transaction clearing and settlement allows each agency to be reimbursed for the services provided, regardless of where the fare product is purchased. Again, the challenge is obtaining agreement from all participating agencies on an approach to transaction clearing and settlement. As presented in Section 2.1.2, clearing and settlement can be accomplished applying either a centralized or decentralized model. 2.2.1.1 Centralized Clearing and Settlement In a centralized clearinghouse, all transaction information (purchases and fare payments) is transmitted to a central system where the net settlement position for each operator is calculated, usually by using settlement software. Differences in sales versus usage will determine whether a given member agency is owed or owes money. The centralized model can be performed in house by one of the member agencies or outsourced to a third party. 2.2.1.2 Decentralized Clearing and Settlement In a decentralized clearinghouse, the member agencies establish financial relationships with each other to enable the movement of funds. The decentralized model often takes advan- tage of existing infrastructure, but, because of multiple points of aggregation, effort is often duplicated. In both centralized and decentralized models, the frequency at which settlement occurs must be decided by the participating agencies. In a high-transaction environment where large amounts of money are involved, settlement is usually performed daily. However, in an environment where transaction volume is relatively low or where an agency’s existing procedures have revenue col- lection performed at intervals of multiple days, the increased cost of daily settlement may not be warranted. 2.2.1.3 Clearing and Settlement Strategies The finance departments of the participating agencies must be intimately involved in the project to address financial management decisions. Ideally, a separate finance committee— consisting of financial professionals supported by technical experts from each agency—should be formed. This type of organization is necessary given the responsibility of having to make deci- sions that affect the movement and management of funds within interoperable fare payment sys- tems. The finance committee would decide whether clearing and settlement should be centralized or decentralized. 2.2.2 Funds Pool Management The funds pool is created as a result of revenue collected (card loads) but not yet used in the system. The funds pool may be in a central account managed on behalf of the participants or it 22 Smartcard Interoperability Issues for the Transit Industry

may be a “virtual” funds pool where each agency holds its own share of the total amount. Exam- ples of how the money within the funds pool can be used are • Periodic movement of funds between member agencies to compensate for fare payments, pur- chases, or loads by one participant’s cardholders on another participant’s system; • Periodic payment of transit services used by cardholders; and • Coverage of charge-backs for transactions that should not have been posted. Revenue is generated by investing the funds pool float (i.e., interest earned on unallocated funds) contained within the funds pool. The member agencies must decide how the float should be invested [e.g., certificates of deposits (CDs) or money markets] so that the money can grow in a low-risk manner, or alternatively, how the funds may be used to meet the working capital needs of the agencies. It can be a challenge for the member agencies to agree how to allocate the float. 2.2.2.1 Funds Pool Float Strategies Regional programs that have followed a central clearinghouse model have developed float allo- cation formulas to arrive at how revenue from e-cash sales within the funds pool float is distrib- uted among the participating agencies. The formulas are typically tied to the amount of electronic purse (or transit-specific purse) loads that occur on equipment at a given agency. Responsibility for negotiating the float allocation formula is usually assigned to the finance committee. 2.2.3 Financial Exposure and Risk Associated with Advanced Features Smartcard technology allows for features not supported by other fare payment technologies, including • Autoload—The automatic loading of fare value once a specified threshold is reached; and • Balance Protection—Value replacement insurance if a card is lost or stolen. Although beneficial to both the patron and agency, these features represent a potential risk for the member agencies. The challenge for participating agencies is agreeing on a common way of managing the risk of added functionality. 2.2.3.1 Autoload The autoload feature involves linking a smartcard to a debit or credit account that automati- cally adds funds from the account to the smartcard when a predetermined value threshold is reached. Depending on how the feature is implemented, autoload can result in a situation where a card has been loaded with additional value before receiving bank authorization to debit the linked account. The autoload feature can be implemented following one of two models. In a post-funded autoload model, the card is loaded with additional funds once it reaches a predetermined threshold, and the funds are then subsequently obtained from the linked account. In a pre-funded autoload model, when the card balance falls below a predetermined threshold, a load request is initiated, the funds are obtained, and the card is loaded with the additional value on the next entry to the system. An additional pre-funded autoload type is a directed autoload, where the patron requests a load of the card for a given value and the funds are approved in advance of an autoload issuance. 2.2.3.2 Balance Protection The balance protection feature replaces the value that was on the card when it becomes lost, stolen, or damaged. The balance protection can also leave the member agencies at risk of losing fare revenue. If a card with balance protection is lost or stolen, the risk of the card being used Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 23

before being “hot listed” (or negative listed) needs to be covered. Agencies must be comfortable that these liabilities present acceptable risks. 2.2.3.3 Strategies for Overcoming Risk Factors The risk of adopting features such as autoload and balance protection can be further defined by developing cost models that quantify these features in terms of cost versus economic benefit. Both of these features are as much an agency benefit as a patron benefit. For example, patrons who under- stand that balance protection can alleviate the concern of losing a card’s stored value are more likely to embrace the fare payment system. This may, in turn, increase transaction volume and shift more fare collection to electronic media and away from cash, thus resulting in cost savings. A similar case may be made for autoload, whereby the adoption of the feature lowers the use of traditional vending equipment, resulting in lower maintenance and cash-handling costs. The risk of autoload to the participating agencies may be further mitigated through the adoption of the pre-funded model. However, the pre-funded autoload transaction is a more complicated and less patron-convenient transaction given that it may be a two-step process. 2.3 Patron Impact Issues The rollout of an interoperable smartcard-based fare payment system introduces technologies and policies that are likely to be new and unfamiliar to the transit patron. The business case for the fare payment system depends heavily on the level of acceptance by the patrons. For these rea- sons, the implementation needs to consider three key areas affecting the patron: • Technology, • New processes, and • Convenience. 2.3.1 Technology Most transit ridership has not been exposed to smartcard technology, which is a new medium for payment. Patrons already familiar with magnetic media and stored value of pass products will find the conversion less of an inconvenience. When introducing a new fare payment system, resistance to change must be anticipated and mitigation measures must be implemented. World- wide experience has proven that transit users embrace contactless smartcard technology because of its ease of use. A few riders are hesitant to use the card because of concerns about privacy resulting from a lack of understanding of how the data are used. Additionally, features such as autoload, which benefit both the cardholder and the participating agencies, require educating the ridership on the benefits provided. 2.3.2 New Processes Depending on the type of service model implemented, cardholders who require assistance with their cards may be required to call a separate service center and not the transit agency. Although this approach can provide an efficient and consistent level of service across a region for card-related issues, it can create confusion for cardholders. The decentralized customer service approach often minimizes this confusion to the cardholder because the patron would continue to call the agency. However, an agency would probably have to increase customer service staffing levels. A compromise of these approaches may lie in having the cardholder call the agency directly and then having the agency forward the call to a central service center. This would allow for a centralized customer service and maintain the convenience of agency contact for the cardholder. 24 Smartcard Interoperability Issues for the Transit Industry

2.3.3 Convenience Based on the experience in San Francisco and Washington, DC, patrons in other regions will most likely embrace a regional interoperable system once they understand the increased con- venience this type of fare payment system offers. The challenges of the new technology and process are minimized once riders gain an increased understanding of its use. Other changes, such as a business decision to allow the balance on a card to go negative in either value or rides, will, at the beginning, contribute to cardholder confusion. 2.3.4 Strategies for Overcoming Patron Impacts Global experience indicates that transit riders quickly see the benefits of switching from cash or magnetic and paper fare media to contactless smartcards. However, to make the transition less disruptive, transit systems must either develop and implement a comprehensive patron educa- tion and marketing program to ease the transition to the interoperable smartcard system or adopt a slow, gradual rollout approach similar to SmarTrip. A comprehensive education program is ongoing and provides accurate information. Examples of education materials used include • Fact sheets, bulletins, newsletters, and websites; • Public meetings hosted by the transit agencies; • Presentations to targeted groups; • Advertisements on vehicles, radio, or television; • Direct mailings; • Local publications; • Clear and simple instructions placed on the card; and • Supplemental staff at high-traffic locations as customer service ambassadors. Transit systems may consider offering cardholder benefits, such as loyalty programs, to increase smartcard penetration. A loyalty program is a promotional program in which benefits, such as discounted fares, are credited to a cardholder’s card for using the system. Interoperable systems can significantly increase card use by restricting the purchase of certain fare products only to the smartcard. For example, one of the agencies in San Francisco’s TransLink plans to restrict its monthly pass purchases to TransLink cardholders only. This concept can also be applied to the issuance and acceptance of transfers. 2.4 Equipment Design Issues One of the primary challenges posed by existing equipment designs is to find a way to procure interoperable equipment from multiple vendors in a competitive manner. The goal is to build a fare payment system that conforms to open standards or specifications, uses existing infrastruc- ture, offers flexibility to scale, and adds functionality as needs develop. Thus, open standards and specifications will enable the participating agencies to add equipment and functionality com- petitively and use the open platform to establish new opportunities for partnerships with non- transit applications. A secondary challenge for the member agencies is to determine the degree to which legacy sys- tems are either upgraded and integrated into the new interoperable fare payment system or replaced with new equipment. The cost to replace may be less than the cost of upgrading and integrating legacy systems. The age of legacy systems and their incumbent technology are key factors in the cost of upgrade. Each agency’s legacy equipment will need to be reviewed to determine whether it can Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 25

be upgraded to the new technology and industry standards of the interoperable system. A useful tool to help determine the best approach is the preparation of a comprehensive value analysis. The value analysis balances the life cycle cost to acquire and maintain the new equipment against the cost to upgrade and maintain the legacy equipment for the useful life of the fare payment sys- tem. In addition to the capital cost of new equipment and normal operating and maintenance cost, key components of the value analysis need to include • Useful service life of equipment and systems, • Life expectancy of the equipment, • Cost of spares or replacement devices, • Residual value of legacy equipment, • Expected reliability, and • Operational improvements and customer convenience. 2.5 Transit Industry Issues This section discusses the issues that exist within the transit industry that may impede efforts to adopt a common smartcard specification. Chapter 3 identifies the components and informa- tion that need to be exchanged to achieve interoperability. A smartcard specification needs to define items such as data elements, objects, API, and an APDU command set for an interopera- ble fare payment system. The issues for discussion are categorized as follows: • Business justification, • Supplier behavior, and • Supplier compliance with available standards. 2.5.1 Business Justification One of the primary goals of interoperability is to provide transit agencies with the ability to multi-source their equipment procurements. The ability to access multiple suppliers for equip- ment and system purchases increases competition in the market place, usually resulting in lower pricing. However, in today’s market, many smartcard-based fare payment implementations are based on proprietary system architectures that do not conform to common interface protocols. This situation may inhibit any attempt to implement regional interoperability among transit providers.Furthermore, the challenge and the cost of adopting an agreed-on standard after a pro- prietary system development may be prohibitive and may even prevent post-deployment regional-interoperability efforts. Another goal of interoperability is to provide the transit patron with a seamless means to pay for travel across multiple transit systems. This goal has already been achieved at regional levels using systems and equipment incorporating varying degrees of proprietary design. For a standard to be relevant, it needs to be universally adopted by the institutions that it ben- efits. Without a critical mass supporting a standard or specification, the standard or specifi- cation becomes ineffective. The strong business case for compliance does not materialize in the initial stages of adoption. However, as adoption progresses, economies of scale begin to materialize. 2.5.2 Supplier Behavior Proprietary solutions are used to create barriers to entry and lock transit agencies into long- term contracts. Standards and common open specifications can remove the barriers created by proprietary technologies, thus allowing transit agencies more choice and making interoperable 26 Smartcard Interoperability Issues for the Transit Industry

fare payment systems possible. Proprietary solutions were developed long before standardization discussions began. Once proprietary technology hurdles have been removed as a barrier to market entry, suppli- ers need new ways to distinguish themselves from competitors. Frequently, suppliers may attempt to accomplish this by lowering price, providing better service, adding features, or improving the reliability of their equipment and systems. From the supplier perspective, loss of pricing power is clearly undesirable. Therefore, attempts to impose a common standard or specification on the equipment suppliers probably will be resisted. 2.5.3 Supplier Compliance with Available Standards Even with a clear business case, other incentives may be necessary to achieve universal accept- ance of a standard. One strategy would be to link standard conformance to capital-funding grant approval. In this scenario, FTA funds for smartcard implementations could only be available for projects that agree to conform to a common standard. However, this strategy can only be applied to new projects. Such an approach would require the governance of a large body of funding such as the FTA. A slightly different approach to this strategy, one that focuses on rewarding an adopt- ing agency versus imposing a penalty, is to make special funding available to agencies that elect to adopt the standard. Findings of Institutional Requirements for Interoperable Smartcard Fare Payment Systems 27

Next: Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs »
Smartcard Interoperability Issues for the Transit Industry Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

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

  1. ×

    Welcome to OpenBook!

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

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

    No Thanks Take a Tour »
  2. ×

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

    « Back Next »
  3. ×

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

    « Back Next »
  4. ×

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

    « Back Next »
  5. ×

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

    « Back Next »
  6. ×

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

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

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

    « Back Next »
Stay Connected!