Future Fare System: Concept of Operations

March 2020

Table of Contents

1. Executive Summary ...... 6

2. Introduction ...... 7 2.1 Project Description ...... 7 2.2 Participating Stakeholders ...... 8 2.3 Project Goals ...... 9

3. Current Fare Payment System ...... 9 3.1 Current Fare Technology ...... 9 3.1.1 On‐Board Bus Technology ...... 9 3.1.2 Rail/Station Technology ...... 10 3.1.3 Fare Distribution Technology ...... 11 3.1.4 Back Office and Support Systems ...... 12 3.2 Current Fare Operations ...... 13 3.2.1 Program Management ...... 13 3.2.2 Customer Service ...... 13 3.2.3 Maintenance ...... 14 3.2.4 Cash Collection ...... 14 3.2.5 Finance and Accounting ...... 14 3.2.6 Back Office Operations ...... 15 3.3 Current Fare Structure ...... 15 3.3.1 Fare Media ...... 16 3.3.2 Fare Pricing and Products ...... 17 3.3.3 Additional Fare Policies ...... 24

4. New Fare Payment System ...... 25 4.1 System Needs ...... 25 4.2 Electronic Fare Media ...... 25 4.3 System Architecture ...... 26 4.3.1 Open Architecture ...... 26 4.3.2 Account‐Based System ...... 26 4.3.3 Real‐Time Communications ...... 27 4.3.4 Closed‐Loop Payment Options ...... 27 4.3.5 Open Payment Support ...... 27 4.3.6 Virtual Transit Card ...... 28 4.4 System components ...... 28 4.4.1 Onboard Equipment ...... 28 4.4.2 Rail Equipment ...... 29 4.4.3 Fare Distribution Devices ...... 31 4.4.4 Retail Network ...... 32 4.4.5 Websites ...... 32 4.4.6 Mobile Applications ...... 33 4.4.7 Back Office Systems ...... 34 4.5 Existing System Interface ...... 38 4.5.1 CAD/AVL Interface ...... 38

4.6 System Security ...... 39 4.6.1 PCI Compliance ...... 39 4.6.2 Physical and Logical Security ...... 39 4.6.3 Key Management ...... 39 4.7 Redundancy and Disaster Recovery ...... 40 4.8 System Hosting ...... 40

5. Future Fare Policy ...... 40 5.1 Fare Payment Options ...... 40 5.2 Fare Media ...... 40 5.2.1 Agency Issued Media ...... 41 5.2.2 Third‐Party Media ...... 41 5.3 Supported Fare Rules ...... 41 5.3.1 Fare Structure ...... 41 5.3.2 Fare Pricing ...... 41 5.3.3 Fare Products ...... 42 5.3.4 Additional Fare Policies ...... 43 5.4 Special Programs ...... 43 5.4.1 Institutional Programs ...... 43 5.4.2 Social Service Programs ...... 43 5.4.3 Paratransit ...... 43

6. Future Fare System Operations ...... 44 6.1 Operating Responsibilities ...... 44 6.1.1 Program Management ...... 44 6.1.2 Financial Management ...... 44 6.1.3 System and Network Hosting ...... 44 6.1.4 Back Office Operations ...... 44 6.1.5 System Monitoring ...... 44 6.1.6 Device Maintenance ...... 44 6.1.7 Revenue Servicing ...... 45 6.1.8 In‐Person Customer Service ...... 45 6.1.9 Customer Call Center ...... 45 6.1.10 Special Program Management ...... 45 6.1.11 Retail Network Management ...... 45 6.1.12 Marketing and Communications ...... 45 6.2 Operations Approach ...... 45 6.2.1 In‐House Centralized Functions ...... 46 6.2.2 Third‐PartyParty Functions ...... 47

7. Appendix A: Estimated Equipment Quantities ...... 49

Glossary & Acronyms

The following acronyms and abbreviations may appear in this document: ABP – Account Based Processor ACH – Automated Clearing House ADA – Americans with Disabilities Act ADAAG – ADA Accessibility Guidelines AFC – Automated Fare Collection AMPS – Account Management and Processing System ANSI – American National Standards Institute APCs – Automated Passenger Counter API – Application Programming Interface AR – Accounts Receivable CAD/AVL – Computer‐aided Dispatch/Automatic Vehicle Location system CCTV – Closed‐Circuit Television CDMA – Code Division Multiple Access COTS – Commercial‐off‐the‐Shelf equipment CPOS – Compact Point of Sale CRM – Customer Relationship Management system CSC – Card Security Code CST – Customer Service sales Terminal CPU – Currency Processing Unit DBMS – Database Management System EDP – Electronic Data Processing EFT – Electric Funds Transfer EMI – Electromagnetic Interference EMV – Europay, MasterCard, Visa GSM – Global System for Mobile communications HHU – Handheld Unit IBM‐ International Business Machines Corporation – A technology company IIN – Issuer Identification Number iOS – Operating System for Apple products IVR – Interactive Voice Response system IP – Internet Protocol ISO – International Standards Organization LCD – Liquid Crystal Display MARC‐ Maryland Rail Commuter MDOT – Maryland Department of Transportation MDT – Mobile Data Terminal

MIL‐STD – U.S. Military Standard MTA –Maryland Transit Administration NEC – National Electric Code NFC – Near Field Communication NFPA – National Fire Protection Association ODBC ‐‐ Open Database Connectivity OEM – Original Equipment Manufacturer PA‐DSS – Payment Application Data Security Standard PAN – Primary Account Number PCI‐DSS – Payment Card Industry – Data Security Standard PDU – Portable Data Units PII – Personally Identifiable Information POS – Point of Sale system RFI – Radio Frequency Interference RST – Retail Sales Terminals SAM – Secure Access Modules SAP ‐ Systems, Applications & Products in Data Processing – A software company SAV – Stand‐alone Validator SCADA – Supervisory and Data Control system SI – System Integrator SKU – Stock Keeping Unit SoGR – State of Good Repair SQL – Structured Query Language SSL – Secure Socket Layer TDEA – Triple Data Encryption Algorithm TTY ‐‐ Teletypewriter TVM – Ticket Vending Machine UL – Underwriter Laboratories USB – Universal Serial Bus VPN – Virtual Private Network WMATA – Washington Metropolitan Area Transit Authority

Future Fare System Study: Concept of Operations

1. Executive Summary This document summarizes the current state of fare collection at the Maryland Department of Transportation, Maryland Transportation Administration (MTA) and identifies a high‐level technical and operational framework for the future fare collection environment. Central to this Concept of Operations (ConOps) is the replacement of the MTA CharmCard system with a next‐generation electronic fare collection system. In line with similar projects underway and implemented, both across the U.S. and around the world, the core design of this new electronic fare collection system will be account‐based and built on an open architecture.

An account‐based design means that all fare value loaded by customers is stored in a back office account and that back office performs all fare calculation and updates of the account when the customer initiates a fare payment transaction. This allows fare media (e.g., CharmCards) to serve only as account identifiers, which opens the door to acceptance of a wide variety of media types (e.g., school and employee IDs), as well as open payments (i.e., credit/debit card acceptance for the payment of fares on‐board buses and at fare gates/rail stations).

Open architecture is a contractual agreement that provides the agency access to the technical details of how the various components of the system interface with each other. This enables agency control over which equipment, external systems, and partners are integrated into the electronic fare collection system, without the need to return to (or contract with) the original system vendor.

In addition to an account‐based and open architecture design, the electronic fare system will include the following new components/systems:

 Simplified bus fareboxes  Real‐time (i.e., cellular) communications on all vehicles  Fare validators (i.e., contactless readers) on bus and at light rail stations (stand‐alone that are no longer integrated with bus fareboxes  Metro fare gates – improved fare evasion deterrence  Metro Ticket Vending Machines (TVMs)  Customer Service Terminals (Point of Sale)  Expanded retail network – integrated into retailers’ Point of Sale systems  Customer and institutional sales websites  Customer mobile app – supporting fare payment and account management  Account‐based back office  Customer Relationship Management (CRM) and Interactive Voice Response (IVR) systems  Financial Management System – General Ledger and Accounts Receivable systems  Fare system Monitoring, Maintenance, and Inventory Management systems

The new fare collection technology will also enable the MTA to adopt new fare policies according to its requirements and preferences. The system is being designed to support both the acceptance of open payments (i.e., contactless credit/debit acceptance) and fare capping, allowing customers to use Pay‐As‐ You‐Go (PAYG) fare payment (i.e., stored value or open payments) to “earn a pass” based on reaching a spending threshold over a set period of time (e.g., day or month).

6 | Page

Future Fare System Study: Concept of Operations

2. Introduction In 2009, the MTA launched a new, card‐based electronic fare payment system, CharmCard. With fare collection components now reaching end‐of‐life, the MTA assembled a project Working Committee to review the current fare collection system and help inform the design of a future system, scheduled to launch in 2023. Through this process, the Working Committee has been engaged to evaluate strategies that will improve customer convenience and agency operations. The purpose of this report is to provide a description of the planned fare collection system, including project goals, system architecture, components, fare policy and operations. These concepts will be described primarily at a functional level and will help in developing the technical specifications for the procurement of the new system. 2.1 Project Description The core objectives of this project are to implement a next‐generation, multimodal fare collection system that drives customer adoption, reduces fare collection costs and fare evasion, increases revenue, and improves existing fare collection operations. The existing public transit system consists of fixed route bus service, Metro subway, light rail, the MARC train commuter rail, and paratransit service. Today, operators accept a wide variety of fares including cash, magnetic stripe tickets and passes, contactless CharmCards, CharmPass mobile tickets, and tokens. The implementation of a next generation, account‐based electronic fare collection system is required to meet future needs and address the issues with the aging fare collection equipment. Replacing the current mix of outdated fare collection systems used by the MTA with modern technology will enable seamless passenger travel between all modes and reduce, or eliminate, visually validated fares to improve operations. MTA operates the CityLink, LocalLink, and Express BusLink bus services; RailLink light rail service; SubwayLink metro service; and MobilityLink Paratransit services, including the management of the Call‐ a‐Ride system.  CityLink, Local Link and Express BusLink has a total fleet size of 744 buses and provides approximately 76 million annual fixed route trips.  SubwayLink has a total fleet size of 50 linked train cars with 14 stations providing approximately 12 million trips annually.  RailLink service has a total fleet size of 53 linked train cars with 33 stations providing approximately 7 million rides annually.  Commuter Bus Baltimore and Commuter Bus Washington, D.C. support approximately 400,000 and 4 million annual trips, respectively. While the MARC Train commuter rail service is not part of this Concept of Operations planning, the service includes 42 stations and 135 train cars, with nearly 9 million trips annually. Paratransit service provides approximately 1 million MobilityLink trips annually and over 600,000 call‐a‐ride trips annually via taxis and sedan companies. The MTA owns and operates 13 cutaway vehicles for MobilityLink. They utilize two vendors, Transit and TransDev, to operate and maintain the other 503 smaller MobilityLink vehicles.

7 | Page

Future Fare System Study: Concept of Operations

2.2 Participating Stakeholders Due to the far‐reaching nature and complexity of this project, the MTA has assembled a comprehensive team of cross‐functional stakeholders involved in fare collection technology, finance, policy, operations, and maintenance. While some of the current fare collection system operations, such as call center support and the SmartBenefits program administration, are managed by the Washington Metropolitan Area Transit Authority (WMATA) in Washington, D.C., the MTA intends to oversee these functions in the future. Furthermore, integration with other local transit authorities and third‐party partners is envisioned in the future, although the initial launch of the new system will be focused on MTA services. Table 1 below provides the full list of MTA departments that are working collaboratively to design the new system.

Table 1: MTA Stakeholders

Working Committee

Communications & Marketing Customer & Community Relations Engineering Equal Opportunity & Compliance Fare Collection ‐ Services, Systems, Maintenance, Transit Store, Revenue Control Finance & Accounting Information Technology InReach Local Transit & Support Marketing/Communications/Web Development MTA Police Office of Innovation Performance Management Planning & Programing Procurement Radio/Electronics Maintenance Service Development System Engineering Transit Operations ‐ MARC, Commuter Bus, Local Bus, Metro, Light Rail, Mobility

8 | Page

Future Fare System Study: Concept of Operations

2.3 Project Goals To guide the development of the new fare system, the Working Committee developed business objectives and success criteria (“Project Goals”) to drive the design of the future fare collection system. Together, these project goals are being used to define a framework for key project elements, including fare technology, policy, system procurement, and system operations, and serve as a starting point for the system design. As the system design advances, these goals will support decision‐making and evaluation of technical alternatives to ensure alignment of the final product with the initial business objectives.

Figure 1: Working Committee Business Objectives

Business Objectives Success Criteria

Replace obsolete fare infrastructure • Replace the Automated Fare Collection system • Minimize upfront capital required • Target a “future-proof” design Drive adoption by improving customer access • Make CharmCards available through TVMs and experience • Greatly expand retail distribution network and introduce mobile payments • Provide better access for Limited English Proficient (LEP) and limited-mobility customers • Offer new, more flexible payment options • Design for the needs of low-income, transit-dependent customers Reduce costs to collect • Eliminate fareboxes and the use of cash • Eliminate magnetic tickets • Implement fare policies to shift customers to low-cost channels Reduce fare collection impacts on transit • Improve boarding speeds and on-time performance operations • Eliminate fareboxes and the use of cash • Eliminate magnetic tickets Leverage data to improve business operations • Improve data collection, reporting and system operation • Better (real-time) communications with customers Increase fare revenue • Improve fare enforcement • Deploy more reliable equipment • Increase ridership 3. Current Fare Payment System This section provides an overview of the MTA’s existing fare payment system, including on‐board and station technology, fare media, sales channels, back office systems, and fare inspection tools. 3.1 Current Fare Technology

3.1.1 On‐Board Bus Technology The MTA operates three types of local fixed‐route bus service, CityLink, LocalLink, and Express BusLink. CityLink service offers select high‐frequency routes and 24‐hour bus service. The LocalLink buses serve local neighborhood streets between the CityLink routes with a lower frequency. The Express BusLink service offers limited‐stop bus trips between certain suburban areas and various downtown locations in the Baltimore area. The MTA also oversees the management of a fourth bus service, the Commuter bus; however, these vehicles are operated by third‐parties and do NOT have any onboard electronic fare collection equipment.

9 | Page

Future Fare System Study: Concept of Operations

3.1.1.1 Fareboxes All local/express buses (i.e., CityLink, LocalLink, and Express BusLink) have Genfare Odyssey fareboxes, which currently accept cash, tokens, magstripe media, and CharmCards for fare payment. Users can purchase a one‐way trip or 1‐Day Pass via the farebox; however, the fareboxes do not support the disbursement of change, so riders are expected to have exact fare. A magnetic stripe card is dispensed for the purchase of a 1‐Day Pass. CharmCard stored value and certain passes can also be loaded using cash on the farebox; however, the MTA has stated that this load process is negatively impacting boarding times. The fareboxes have reached end‐of‐life, and are experiencing issues more frequently as they continue to age. Magnetic stripe trim units are responsible for processing, reading and validating magnetic stripe tickets and often fail and require parts. Additionally, the internal Kontron boards, which support on‐ board integration between the farebox and CharmCard system, are no longer manufactured by the vendor. Only a few years of stock of spare boards remains in MTA’s inventory, with limited possibilities of acquiring more units. Fareboxes are revenue serviced and have data probed daily, when busses return to the yard. Summary data is captured via an Infrared (IR) probe, while detailed data is sent over an antiquated Proxim wireless network, which require a clear line of sight to transfer data. Manual Portable Data Units (PDUs) can be used in the event of a data transfer issue or failure. On the SubwayLink system, customers paying with tokens use in‐station standalone fareboxes to pay their fare and use a printed receipt to show the Station Manager who can manually release the gates. Like the on‐bus units, these fareboxes have significant reliability issues. However, unlike their on‐bus counterparts, the metro fareboxes can only be probed manually, using a Portable Data Unit (PDU), causing an additional burden on operations. These PDUs are failing and replacement parts are no longer produced. Manual probing is also not consistently scheduled, which leads to sporadically capturing the data.

3.1.1.2 Other Onboard Technology The farebox is the primary piece of AFC equipment on the bus today. Other onboard systems include an MG90 router, Automatic Passenger Counters (APCs), CAD/AVL system, CCTV, and driver control units. The MTA is working on a single sign‐on project, including new cellular communications and geolocation services, called Bus USA. The functionality of this system is currently under review.

3.1.2 Rail/Station Technology The MTA operates the Light RailLink light rail service and the SubwayLink metro system. The MTA also oversees the management of the MARC commuter trains; however, these vehicles are operated by third‐parties and do NOT have any on‐board electronic fare collection equipment.

3.1.2.1 Fare Gates Cubic‐provided faregates are utilized for fare payment on the agency’s Metro SubwayLink metro system. The gates accept magnetic stripe media and CharmCards as payment. Riders must present their fare media to the faregate to enter and exit the platform. When a reduced fare is read by the gate, a light indicator is triggered, signaling to an attendant or inspector to validate that the rider qualifies for the reduced fare.

10 | Page

Future Fare System Study: Concept of Operations

Like the fareboxes, the faregate internal computer boards are no longer sold by the supplier, causing concerns that the agency will have a parts shortage in the future. Maintenance reports have indicated mechanical issues with the gates, including magnetic stripe acceptance issues and the faregate barriers losing their resistance, enabling riders to bypass the gates by simply pushing through them.

3.1.2.2 Handheld Units (HHU) These handheld units are used by fare inspectors to validate CharmCards and SmarTrip Fares. These units only indicate whether or not the rider’s smartcard was used to pay a fare. Citations are issued using a separate unit.

3.1.3 Fare Distribution Technology

3.1.3.1 Ticket Vending Machines (TVMs) TVMs are available at light rail and metro stations throughout the MTA system. They allow users to purchase one‐way tickets, pass products, and perform CharmCard loads for both stored value and passes. Certain reduced fare products are also available for sale at the TVMs, often leading to customers purchasing (inadvertently or intentionally) a product for which they are not eligible. The TVMs are 14+ years old and have various reliability issues. Coin handling systems often jam, and the machines have no automatic monitoring. Maintenance teams must rely on patrons and staff to report issues with the units. While a limited supply of parts is still available for the machines, failure rates and the maintenance required continues to increase. Most TVMs accept both credit and cash, although there are currently six credit card‐only machines deployed in the system at high‐volume locations. None of the machines accept debit cards or support Address Verification Services (AVS). While TVM credit card transactions are currently processed through WMATA’s payment gateway, the MTA is moving payment processing to either be through Cubic or one of MTA’s existing payment processors. For cash transactions, change is issued in coins, including dollar coins. Since Light RailLink is a proof‐of‐payment system and no fareboxes are present, TVMs have embedded smart card readers for CharmCard validation, which need to be tapped before boarding the train. TVMs can also be used to purchase paper tickets/passes and perform CharmCard reloads. However, they do not issue new or replacement CharmCards.

3.1.3.2 Compact Point of Sale (CPOS) Devices CharmCards and certain pass products are offered via select retail locations. These locations are often independent stores (not affiliated or franchised with a national retailer) and have high turnover. For stores selling CharmCards, the CPOS device is used to perform all card sales and loads. Magnetic stripe passes are often sold as well. Bulk orders are typically sold via the phone or in‐person at the agency’s transit store. Bulk order sales are tracked manually by the MTA. The MTA transit stores offer all the agency’s products, including the CharmCard. Like the retail stores, all CharmCard sales and loads are performed using the CPOS devices. The MTA does not have a high‐speed encoding machine for CharmCards.

3.1.3.3 Websites The MTA’s CharmCard and Pass Store websites are the primary channels used for online sales of CharmCards and certain paper pass products, respectively. All online CharmCard transactions are

11 | Page

Future Fare System Study: Concept of Operations

processed through WMATA’s payment processor until the MTA shifts to either a Cubic or MTA‐ controlled payment gateway.

3.1.4 Back Office and Support Systems

3.1.4.1 NextFare Central System The MTA is currently utilizing a Cubic NextFare version 4.x back office system to support their CharmCard solution; however, as part of their State of Good Repair (SoGR) initiative, the back‐office is currently being upgraded to NextFare version 7.

3.1.4.2 Data Warehouse The CharmCard data warehouse is currently hosted by WMATA. As part of the MTA’s SoGR initiative, Cubic is building a data warehouse that is independent of the WMATA SmarTrip system.

3.1.4.3 Reporting The following fare collection reporting systems are in use today or will be in place with NextFare7:  SAP Edge  Crystal Reports  Hummingbird (may be replaced with SAP)

3.1.4.4 Maintenance and Monitoring Systems IBM’s Maximo for Utilities is used for the agency‐wide maintenance management system. There is no integration with the current fare system. Automated system monitoring does not exist today and so all maintenance records are handled via manual processes.

3.1.4.5 CRM Systems A state‐owned CRM system is currently used. There is no integration with the current fare collection system and the CharmCard calls are currently managed by the WMATA call center.

3.1.4.6 Financial System All fare revenue is manually recorded in the State of Maryland’s Financial Management Information System (FMIS). There is currently no integration between the fare system and FMIS

3.1.4.7 Card Inventory System A card inventory system does not exist today, thus all card inventory is handled via manual processes.

3.1.4.8 Cash Processing Units (CPUs) CPUs are used to count the physical currency that comes into the agency’s money room. These units do not send over automated reports of their counts and do not integrate with the fare collection system. Manually recorded numbers are taken from the machine and sent over to accounting for reconciliation and reporting.

3.1.4.9 Payment Service Providers The MTA uses a variety of payment services providers today to support the processing of credit cards:  Vantiv –– TVM, CPOS and CharmCard website sales via WMATA

12 | Page

Future Fare System Study: Concept of Operations

 Stripe – Online mail‐order pass sales  Bank of America ‐ The transit store  Braintree ‐ CharmPass mobile app via moovel 3.2 Current Fare Operations

3.2.1 Program Management

3.2.1.1 CharmCard The current CharmCard system is a card‐based fare collection system provided by Cubic that was originally developed to support WMATA’s SmarTrip program. Online sales, credit card processing, customer service, data warehousing, and reporting are all currently managed by WMATA. The MTA manages its own tariff tables and is responsible for CharmCard distribution. As part of an ongoing SoGR initiative, MTA is looking to bring those functions in‐house.

3.2.1.2 CharmPass The MTA’s mobile ticketing application, CharmPass, provides riders with the option to purchase CityLink, LocalLink, Express BusLink, Light RailLink, Metro SubwayLink, MARC Train, and Commuter Bus passes from their mobile device. CharmPass is a moovel developed and hosted flashpass mobile ticketing application that generates visually‐inspected mobile tickets. CharmPass is available on the Android and iOS app stores. Key metrics are provided to the MTA via an online dashboard. In early 2020, moovel announced that they are exiting the mobile app market. Support for existing moovel solutions will continue through 2021.

3.2.1.3 Institutional Programs The MTA supports several institutional programs, including programs for Baltimore city schools, various social services, post‐secondary schools, state employees, law enforcement/firefighters, and private employers. Social services often purchase tokens to distribute to their clients, while employers and post‐ secondary schools typically purchase paper passes. The MTA’s CharmCard institutional partners are currently limited to select student programs. Certain programs like the state employee program, the law enforcement/firefighter program, and the public university employee program, all provide free rides to those that qualify and do not currently require any fare media. The SmarTrip SmartBenefit program, managed by WMATA, is currently supported as part of employer programs. This program supports employer direct subsidy or allows employees to purchase pre‐tax transit benefits via a payroll deduction. The CharmPass system also supports institutional sales by leveraging the moovel FareShare solution, which allows an institution to upload a spreadsheet with product selections and participant emails. FareShare then automatically distributes the ticket to the user via an emailed link.

3.2.2 Customer Service

3.2.2.1 Call Centers The MTA operates two separate customer service lines, one for paratransit reservations, and one for all other customer service inquiries. Neither of these call centers is equipped to handle CharmCard issues. All CharmCard requests, including card sales and reloads, are handled via a separate SmarTrip 1‐800

13 | Page

Future Fare System Study: Concept of Operations

number administered by WMATA. Daily CharmCard call center reports are provided to the MTA. All inquiries for CharmPass are handled by the mobile ticketing vendor, moovel.

3.2.2.2 Transit Stores The MTA‐owned transit store supports CharmCard sales and reloads via the CPOS. No CharmCard customer service functions are supported through the transit store.

3.2.3 Maintenance The MTA leverages the IBM Maximo system for maintenance ticket creation and management. This system has no integration with the CharmCard AFC solution and provides no automatic monitoring of any of the agency’s fare collection components. Fareboxes, TVMs, and faregates all rely on customers or agency staff to manually report issues.

3.2.4 Cash Collection The MTA collects cash deposited in their fare collection devices. Revenue is removed, vaulted, and sent to the MTA money room to be counted and sorted daily. Once processed by the counting machines, a money room employee records the numbers reported by the unit and sends the information over to the accounting department.

3.2.5 Finance and Accounting The reconciliation and accounting processes at the MTA are largely manual. All revenue is recognized upon sale, but reconciliation and reporting method vary by sales channel/payment type.

3.2.5.1 Cash Sales  Cash totals are provided to the accounting department daily. Farebox and TVM sales are each recorded as their own line item, with no breakout by mode, fare type, product type, etc.  Cash from transit store sales are reconciled daily by counting down the cashiers’ drawers and tickets sold. A spreadsheet is used each day to record what’s sold and by fare type and mode.  Cash from mail‐orders and bulk sales are tracked separately from the transit store. These items are reported to accounting daily by fare type and mode.

3.2.5.2 Credit Sales Reconciliation processes vary by sales channel, as many of the sales channels use different payment processors, each delivering slightly different merchant activity reports. Credit transactions are not broken out by mode or fare type.

3.2.5.3 CharmCard Sales and Usage CharmCard stored value revenue is recorded upon sale. Revenue is broken out by mode and reconciled on a monthly basis using a WMATA provided reconciliation report.

3.2.5.4 CharmPass Sales Revenue from the CharmPass is received monthly and broken out by mode via a report provided by Braintree (the payment processor for moovel).

14 | Page

Future Fare System Study: Concept of Operations

3.2.6 Back Office Operations

3.2.6.1 CharmCard CharmCard is currently part of the WMATA SmarTrip system and primarily managed by WMATA. Online sales, credit card processing, customer service, data warehousing, and reporting/reconciliation are all managed by WMATA. The MTA manages its own tariff tables and is responsible for CharmCard distribution. A dual set of security keys are currently used for the CharmCard and SmartTrip systems. These keys enable interoperability between the two systems, allowing riders to use either the CharmCard or SmarTrip card on either system. When the SoGR project currently underway is complete, the CharmCard back office operations tasks will be transferred over to the MTA or Cubic, as the SmarTrip and CharmCard systems will no longer be interoperable.

3.2.6.2 CharmPass The CharmPass mobile application is hosted by moovel and managed via the agency using an online dashboard. 3.3 Current Fare Structure The MTA currently operates fixed‐route local and express bus service (LocalLink, CityLink and Express BusLink), light rail service (RailLink), metro service (SubwayLink), and paratransit service (MobilityLink). The MTA also oversees the operation of a commuter rail service (MARC) and commuter bus service, operated by various third‐party operators. Roughly 91 million trips were taken using the system in 2019. Current fare options vary by transit mode, but can include paper tickets/coupons, magnetic stripe media, cash, tokens, contactless CharmCards, and mobile tickets (CharmPass).

Table 2: Current Fare System Statistics as of 2019

Key Metrics Statistic Total Vehicles 1221 Annual Bus Ridership 67,612,158 (includes commuter buses) Annual Metro Ridership 7,275,335 Annual Light Rail Ridership 6,966,072 Annual MARC Train Ridership 9,190,885 Operating Budget FY 2020 $921M Fare Media Options Paper tickets/coupons, magstripe media, cash, tokens, CharmCards, mobile tickets (CharmPass). CharmCard AFC System Launch 2009

15 | Page

Future Fare System Study: Concept of Operations

3.3.1 Fare Media The MTA accepts various forms of fare media and payment. The media accepted is dependent on the mode of transit being utilized.

Table 3: Current Fare Media Accepted by Modal Modal Payment accepted Bus (CityLink, LocalLink, and Cash, tokens, magstripe media, CharmCard, Express BusLink) CharmPass, and select paper pass/coupons Commuter Bus Cash, Paper tickets/passes, CharmPass SubwayLink Metro Cash (is taken at standalone fareboxes if paying with pennies), tokens, magstripe media, CharmCard, CharmPass, and select paper pass/coupons RailLink Light Rail Paper Tickets, CharmCard, CharmPass, and select paper pass/coupons MARC Train Cash, Paper tickets/passes, CharmPass MobilityLink Cash and Vouchers/Tickets

The figure below shows the current fare system and how sales data are reconciled.

16 | Page

Future Fare System Study: Concept of Operations

Figure 2: Current Fare System Diagram

3.3.2 Fare Pricing and Products Available fare products and pricing vary by rider category. Rider categories are listed in the table below.

Table 4: Current Rider Categories

Rider Category ID Qualification Full Fare N/A Any person age 7‐64 Student Select students enrolled in participating Baltimore schools Student Transit ID (grades K‐12) Any person age 6 and under rides free with a fare‐paying Child N/A customer or MTA employee/MTA pensioner. Discount does not apply to those on reduced fare tickets.

17 | Page

Future Fare System Study: Concept of Operations

Rider Category ID Qualification

Any Senior: Any person age 65 and over qualifies for reduced fare government‐ passes and cash fare. Must have government‐issued identification issued ID validating age. Senior/Disability showing DOB or Medicare ID Disabled: Any person that has completed and been approved via MTA Disability the MTA disability certification process qualifies for reduced fare Photo ID Card passes and cash fare.

Any person certified as paratransit eligible via the MTA MTA Mobility qualification process is eligible for a paid ride on MTA’s Mobility ID MobilityLink and free fare on local fixed‐route service with MTA Mobility issued ID. MTA Mobility Visitors that are certified as paratransit eligible in any other Visitors Form transit system may be eligible for MTA’s Mobility services. Mobility Visitors and a copy of Permission to ride must be granted by the Mobility Certification the visitor’s Office after the visitor’s home transit agency has submitted photo ID. confirmation of the visitor’s certification One person may ride free of charge for both MobilityLink services Personal Care and all local fixed‐route services as long as the mobility rider the N/A Attendant (PCA) PCA is traveling with has “PCA Yes” printed on their Mobility ID card MTA Smart ID All employees of the MTA are allowed to ride all MTA services MTA Employees card free of charge. MTA contractors issued an MTA contractor ID with an orange MTA issued MTA Contractors board are permitted to ride local services fare‐free, when the ride contractor ID is related directly to their MTA job assignment. MTA issued MTA Retirees All MTA retirees are allowed to ride local services fare‐free ID Permanent state administrative division employees and state university employees are allowed to ride, MTA Light Rail, Metro, and all fixed route bus services (including the Baltimore State of Valid State ID commuter bus routes) fare‐free. Not valid for free rides on the Maryland Active card MARC train. Employees *Members of the Senate of Maryland and the Maryland House of Delegates are granted free riding privileges on MTA Local Services only. University University All permanent University System of Maryland employees that System of badge WITH have successfully applied for and received their silver hologram Maryland silver transit sticker are allowed to ride Baltimore Link (including Permanent hologram express service, SubwayLink, RailLink, and routes 210 and 215 on Employees transit sticker the commuter bus)

18 | Page

Future Fare System Study: Concept of Operations

Rider Category ID Qualification All Baltimore City, Baltimore County, Anne Arundel County (including Annapolis), and Maryland State Police officers are Police ID or permitted to ride local transit services free of charge. To access Police Officers Badge *if not free MARC/Commuter bus services the officer must enroll in the in uniform Law Enforcement On‐Board program (LEP) via email and provide monthly reports. All paid firefighters of the Baltimore City, Baltimore County, Anne Must be in Arundel County, Howard County, and Harford County Fire Firefighter full uniform Departments are permitted to ride local services free of charge if in full uniform. Maryland Must be in All officers from the Maryland Division of Correction are Division of full uniform permitted to ride local services free of charge Correction All parking control agents assigned to the Department of Public Parking Control Must be in Works may ride local services free of charge if they are in full Agents full uniform uniform and actively performing their job responsibilities. United States Carrying a United States Postal Service (USPS) letter carriers are allowed to Postal Service regulation ride local services free of charge when carrying their regulation Letter Carriers USPS mailbag USPS mailbag. Downtown Downtown Employees of the Downtown Partnership group are allowed to Partnership Partnership ride local MTA services free of charge. Photo ID Card

A special ID or application/registration process is required to receive a reduced fare.

All MTA local services have a flat fare structure for single‐trip fares, with the exception of the Call‐a‐Ride mobility service, which is based on distance. MARC and commuter bus fares are zone‐based, with pricing being dependent on the boarding zone and the number of zones traveled. Fare pricing and fare products available for each service are listed below. Pricing and availability vary by rider category.

19 | Page

Future Fare System Study: Concept of Operations

Table 5: Current Fare Structure Local

Data retrieved from MTA’s 2019 Fare Policy version 3.0

Table 6: Current Fare Structure Mobility*

Data retrieved from MTA’s 2019 Fare Policy version 3.0

20 | Page

Future Fare System Study: Concept of Operations

Table 7: Current Fare Structure Commuter Bus

Table 8: Current Fare Structure Conversion Table for Multi‐Ride Tickets MARC Trains

21 | Page

Future Fare System Study: Concept of Operations

Table 9: Current Fare Structure West Virginia Conversion Table for Multi‐Ride Tickets MARC Trains

Table 10: Current Fare Structure Penn Line MARC Trains

22 | Page

Future Fare System Study: Concept of Operations

Table 11: Current Fare Structure Camden Line MARC Trains

Table 12: Current Fare Structure Brunswick Line MARC Train

3.3.2.1 Free Products The MTA offers several complimentary fare products. Products include:  Regular Continuation Pass: If a vehicle breaks down, customers are given a regular continuation pass if needed to continue their journeys.

23 | Page

Future Fare System Study: Concept of Operations

 Emergency Passes: Are issued during an unexpected event. Passes are assigned to bus operators and metro station attendants, and are issued as needed.

 BWI Coupons: Are valid for one‐way trips on light rail or MARC trains between BWI airport and Baltimore, MD or Washington, D.C.

 VIP Day Passes: These tickets are issued for special events and are valid for unlimited travel on the Local Bus, SubwayLink, and RailLink for the day stamped.

3.3.3 Additional Fare Policies Under the current fare policy, transfers are only offered for certain fare media types and fare categories. Customers paying for their fare via CharmCard and CharmPass are eligible for free unlimited 90‐minute transfers across Local Bus, SubwayLink, and RailLink. Students traveling on a per‐trip student fare are also eligible for a transfer, if connecting between Local Bus, SubwayLink, and RailLink. Transfers are issued via a magstripe Student Continuation Pass (valid for 90 minutes) by the bus operator or metro station attendant.

24 | Page

Future Fare System Study: Concept of Operations

Baltimore City Public students who have CharmCards are allowed four (4) free trips per school day. Each trip allows for 120‐minutes of unlimited transfers on Local Bus, SubwayLink, and RailLink. 4. New Fare Payment System 4.1 System Needs Stored value with fare capping offers a With nearly all existing fare collection system flexible and convenient alternative to cash, components nearing or at end‐of‐life, the need for a while driving customer loyalty by providing full system replacement is imminent and provides an the best fare. opportunity to implement a modern fare collection system that includes policy and system feature  An electronic equivalent of cash is stored enhancements. The customer’s ability to reload fares in a customer’s transit account via modern sales channels such as online, via a  Each “tap” deducts the appropriate fare mobile app, or through an expanded network of for the trip being taken, and caps the retail stores, instead of on vehicles, can significantly customer at the best fare. reduce fare collection impacts on operations and  “Passback” restrictions prevent a second reduce the cost of fare collection. tap from accidentally deducting another Existing non‐electronic fare products will need to be fare transitioned to electronic fare media to eliminate the  Balance protection (if the card is lost or need to maintain legacy fare options in parallel with stolen) can be offered with card the future system. registration A few of the advantages of shifting existing paper  Card registration can enable other products to electronic fare media include: benefits, such as the automatic reloading of value (i.e., autoload)  Reduction of cash transactions, helping to increase operational efficiency and reduce cash handling costs  Ability to reload media via multiple channels, including web and mobile  Ability to enforce transfer policies electronically to reduce fraud 4.2 Electronic Fare Media The new fare payment system will introduce new ways that customers can pay their fares while eliminating several existing forms of media. Currently, the wide variety of media options, including cash, tokens, magnetic stripe tickets, CharmCards and CharmPasses requires many forms of fare validation, including tapping a card reader, swiping a magnetic reader, inserting cash and tokens into fareboxes, and visually displaying a smartphone ticket. This diverse range of payment options drives significant complexity for customers, as well as for MTA operations to validate and inspect the fare media. In addition to the next‐generation of smartcards, the MTA intends to introduce new forms of fare media, such as limited‐use media, open payments, and virtual cards on mobile devices. While the determination of the specific fare media to be supported is still under review, it is expected that the new fare media will reduce fare evasion by requiring electronic validation.

25 | Page

Future Fare System Study: Concept of Operations

4.3 System Architecture The design of the new electronic fare system considers the project goals, and agency needs discussed to date. Workshops were held with the Working Committee to agree on a system architecture that will most effectively meet those needs.

4.3.1 Open Architecture The system will be designed and implemented using an open architecture approach. This approach is intended to provide flexibility as technology and agency needs change in the future. This requirement will cover key system functions, including:  Fare distribution (i.e., sales)  Fare payment  Fare inspection  Transit account management  Customer account management  Device management  Financial management  Onboard integration The open architecture will encompass all fare media and devices deployed within the system and include all fare media formats, transaction formats, security protocols, and communications necessary to support critical system functions. The selected System Integrator (SI) will publish detailed specifications for all fare media and transaction formats used within the system. System interfaces will be based on Application Programming Interfaces (APIs) developed by the SI during design and implementation of the new system. The SI will publish full API specifications that document the process for sending messages over these interfaces, and all messages that the interfaces support, including message description, format, and timing requirements. As part of the system implementation and testing, the SI will be required to demonstrate the use of the APIs. Any changes to the APIs during implementation will result in the specifications being updated by the SI. Following implementation, the APIs and related specifications will become the property of, or fully licensed to, the agency. The agency will retain the right to use and distribute the specifications without further approval or license from the SI.

4.3.2 Account‐Based System The new fare payment system will utilize an account‐based architecture for the processing and validation of fare payments. The SI will design and implement a back office account‐based transaction processor that manages transit accounts, calculates fare payments based on established business rules, and processes all transactions (e.g., sales and usage) as required. All fare value loaded by customers will be stored in the account‐based backend. The system will allow fare payment using agency‐issued contactless media. Each media type will be capable of serving as a credential to identify a transit account during the loading of value, or when payment is attempted at a point of entry (e.g., via an onboard validator or at rail stations).

26 | Page

Future Fare System Study: Concept of Operations

4.3.3 Real‐Time Communications All validation and sales devices deployed within the system will be equipped with a real‐time communications interface to the account‐based back office. This interface will support:  Loading of fare value at distribution devices  Fare payment validation onboard buses and at rail stations (with real‐time fare calculation)  Distribution of hotlists to minimize risk in offline scenarios  Real‐time monitoring of device and system performance The real‐time communications at rail stations will be provided via a high‐speed connection to the MTAs fiber backbone. For buses, real‐time communications will rely on the cellular network. To facilitate this, mobile data routers that support multiple cellular technologies will be installed on board vehicles if not already present.

4.3.4 Closed‐Loop Payment Options The new electronic fare collection system will support fare payment using agency‐issued closed‐loop fare media. Closed‐loop media is designed to support agency fare payment only, whereby the stored value or fare products loaded are accepted as a form of payment by the participating transit agencies, yet is not accepted as a form of payment at non‐transit merchants. The system will launch with an account‐based back office that supports real‐time fare calculation, account management, and the loading of value to accounts associated with the closed‐loop media. Customers will be able to purchase closed‐loop fare media and value at TVMs, retailers, online, and through all the other distribution channels. Limited‐use media will support the population of customers that ride the MTA infrequently. This may include customers that receive limited‐duration fare instruments from social service agencies or for special events, such as sporting events or conventions. Common forms of limited‐use media include contactless paper or PVC Smart Tickets that are tapped at contactless readers for validation, or paper tickets with QR codes (QR Code Tickets) that are scanned by barcode readers for validation. The limited‐ use fare media options to be supported by the new electronic fare collection system have yet to be determined.

4.3.5 Open Payment Support Supporting open payments enables customers to tap and pay using contactless bank cards as they board a bus or enter the rail system. Open payments are intended to allow riders to pay fares directly using a contactless bank card, rather than purchasing transit‐specific fare media and value. Whether the customer uses a physical contactless bank card, or a bank card loaded into a digital wallet, such as Apple Pay, Google Pay or Samsung Pay, the experience is seamless, and no card issuance is required by the MTA. It is MTA’s direction that the system be designed to support open payments with the option to turn the feature on at their discretion. The specified account‐based architecture and real‐time communications are required to support this feature. The other major design consideration is compliance with banking security standards, such as Payment Card Industry Data Security Standard (PCI‐DSS) and Payment Application Data Security Standard (PA‐DSS). The entire system will be designed based on the security

27 | Page

Future Fare System Study: Concept of Operations

principles described in the latest version of these standards, and will use PCI‐certified components where necessary.

4.3.6 Virtual Transit Card Virtual transit cards are a newer mobile device technology, enabling customers to procure a digital form of closed‐loop media on their mobile devices. This digital media can use Near Field Communication (NFC) based technology, with the virtual card stored in a mobile wallet (e.g., Apple Pay or Google Pay) and tapped for payment, or use a QR code displayed on a customer’s mobile device that can be validated with a barcode reader. The type of virtual transit card to be supported by the new electronic fare collection system has yet to be determined.

4.4 System components

4.4.1 Onboard Equipment

4.4.1.1 Bus Validators Validation devices are customer‐facing equipment used to validate fare media and accept fare payment. The SI will provide on‐board validators that will be installed as separate devices near existing bus fareboxes for convenience and accessibility. Coin and cash payments will continue to be accepted using fareboxes. There will be no integration between the farebox and the new onboard validators aside from single sign‐on. There is a desire to integrate the validators and the existing Computer Aided Dispatch/Automatic Vehicle Location (CAD/AVL) system (see Section 4.10.1) to capture geolocation information within the fare transaction data. The bus validators deployed within the system will include a contactless smartcard reader that supports reading and writing to all ISO‐14443 Type A and B compliant card formats (e.g., the entire MIFARE product line) and NFC‐compliant devices. The validators may have a built‐in barcode scanner for the validation of QR codes. The readers will be able to be updated via firmware to support new card formats in the future. The validators will be certified as PCI‐compliant to support the acceptance of open payments in the future, if desired. Payment validation and the deduction of account value will occur when fare media is tapped on a payment validator. For both authorized and denied transactions, the validator will provide visual and audible feedback, including information on the fare charged and remaining account balance. The visual

28 | Page

Future Fare System Study: Concept of Operations

and audible feedback may be configured to identify different rider classes, especially for reduced fare payments that are heavily discounted. The devices will support single and multiple validator configurations onboard vehicles. Onboard validators will be easily removed and replaced by authorized maintenance personnel. Swapped devices will automatically be programmed with their new location (e.g., vehicle number) and have their assigned location captured by the system monitoring application.

4.4.1.2 Fareboxes The SI will provide new fareboxes to collect coin and cash payments. There is a desire to procure a simplified farebox, which is no longer integrated with the electronic fare system (aside from single sign‐ on), and reduce the amount of cash accepted on‐board. Means for reducing cash and expediting boarding include eliminating the ability to reload electronic value on‐board, and possibly reducing or eliminating the limited‐use media available for purchase onboard. The specific farebox features, and fare media and products available for purchase at the farebox, have yet to be determined.

4.4.1.3 Operator Display Units The SI will provide an operator display unit (ODU) for each vehicle to display fare payment results directly to the bus operator. For both authorized and denied transactions, the ODU will provide visual and audible feedback, which may include information on the fare charged, as well as indication of rider category associated with the transit account being used for payment. The information displayed on the ODU will be configurable and may be different from the information displayed on the bus validator. The location and size of the ODUs installation will be carefully considered to ensure maximum efficiency for operators, while minimizing maintenance issues.

4.4.1.4 Mobile Data Routers The bus validators will connect directly to the account‐based transaction processor via a cellular connection. The cellular connection will be supported through an SI‐provided mobile data router installed on the vehicles. The mobile data router will connect to the validators via Ethernet, and include a modular interface that can support 3G and 4G data connections on all major U.S. carriers, with 5G support desirable. The mobile data router will also include 802.11 Wi‐Fi communications to enable integration with other systems, and the exchange of non‐critical data at bus yards and other locations. If cellular communications are already available on‐board vehicles, the fare system may share these communications with other on‐board systems, such as CAD/AVL. Regardless of whether this is new or existing equipment, the router must have the ability to prioritize communications at both the device and message level. 4.5 Rail Equipment

4.5.1 Faregates All metro stations will have an array of bi‐directional faregates installed at each entrance to separate the paid and unpaid areas of the station. The SI will be responsible for delivering faregates in both standard and ADA‐compliant configurations, and will ensure that the gates minimal footprint and maximum throughput is either maintained or enhanced. The provided faregates will comply with ADA accessibility requirements and adhere to NFPA 130 emergency exit safety provisions.

29 | Page

Future Fare System Study: Concept of Operations

The faregates will have PCI‐certified, ISO‐14443 compliant contactless smartcard readers installed on both the entry (unpaid) and exit (paid) sides. Customers will tap their contactless fare media on the entry reader to initiate fare payment. Tapping on exit may be used to gather additional ridership information that is otherwise not available in a single‐tap configuration. MTA will decide whether to require exit tapping during design review. Payment validation and the deduction of account value will occur when fare media is tapped on a payment validator. For both authorized and denied transactions, the validator will provide visual and audible feedback, including information on the fare charged and remaining account balance. The visual and audible feedback may be configured to identify different rider classes, especially for reduced fare payments that are heavily discounted. The faregates will include a full color customer display and provide visual and audible feedback on payment acceptance or denial, including information on the fare charged and remaining account balance. Fare payment acceptance will be accompanied by the opening of the faregate. In order to facilitate fare enforcement, the faregates will employ indication lights or symbols that can be configured to signal when payment is accepted for certain fare products or rider classes. These indicators will be positioned to limit the visibility by other customers, such as facing the paid side or angled to allow visibility from a particular position. The indication lights will be configurable to correspond to reduced fare type (senior, youth, etc.) without expressly indicating the type of fare being accepted. The system will allow for override control of each faregate and array locally by station personnel, and from a centralized command center via integration with the Supervisory and Data Control (SCADA) system. Remote control will include direct and pre‐scheduled configuration of the gate direction, release, and customer display. Commands will include, but are not limited to, open, lock, switch direction, reboot, and shutdown. Control will also allow for configuration of the visual and audio feedback provided through any interfaces incorporated into the faregate. The faregates will clearly indicate to customers the enabled direction of travel and the faregate aisle associated with each validator. MTA has evaluated several faregate types, including tripod turnstiles, bi‐parting leaf, paddle, and sliding panel gates. They prefer a design that provides an unobstructed aisle, and minimizes the opportunity for “gate jumping” and customer confusion. Based on these requirements, paddle faregates are the current preference. The paddles are typically tall and have limited space below to discourage fare evaders. The paddles can be made from a transparent or translucent material to allow customers to see oncoming traffic.

4.5.2 Stand‐Alone Validators All light rail stations will be equipped with a series of Stand‐Alone Validators (SAVs). The SAVs will function the same as the bus validators, and may even be the same equipment, but ruggedized for the outdoor environment and configured for independent operation. The SAVs will include PCI‐certified, ISO‐14443 compliant contactless smartcard readers. Customers will tap their contactless fare media on before boarding a vehicle to initiate fare payment. Tapping on exit may be used to gather additional ridership information that is otherwise not available in a single‐tap configuration. The MTA does not intend to require or support exit tapping during design review. The SAVs will connect directly to the account‐based transaction processor via a hardwired connection and use the SI‐provided APIs for fare payment validation. At light rail platforms that may require

30 | Page

Future Fare System Study: Concept of Operations

communications infrastructure improvements, cellular and/or Wi‐Fi connectivity may be explored. Payment validation and the deduction of account value will occur when fare media is tapped on a payment validator. For both authorized and denied transactions, the validator will provide visual and audible feedback, including information on the fare charged and remaining account balance. The visual and audible feedback may be configured to identify different rider classes, especially for reduced fare payments that are heavily discounted. 4.6 Fare Distribution Devices Distribution devices are the devices used to sell fare media and value to customers. As with validation devices, they will include contactless smartcard readers in order to read the fare media and access the associated transit account. Distribution devices include TVMs, customer service terminals, and retail sales devices. These devices support a comprehensive fare distribution network that is an integral part of the fare collection system.

4.6.1 Ticket Vending Machines The SI will be required to provide self‐service TVMs that distribute contactless smartcard fare media and allow customers to add stored value and fare products to their existing transit accounts. The TVMs will distribute extended‐use and/or limited‐use fare media, and will accept bills and coins, as well as credit and debit cards for payment. The TVMs will use Ethernet communications, and maintain an online connection to the account‐based transaction processor to perform all fare media and value sales using the SI‐provided APIs. The TVMs will be installed in all metro and light rail stations. The TVMs will have modular components and be designed to minimize equipment, installation, and maintenance costs. They will make use of COTS components wherever possible, and comply with industry security and banking standards. The TVMs will be weatherproof, resistant to vandalism, and rugged enough to withstand the outdoor environment and frequent customer usage. An audible, and perhaps visual, alarm will be triggered at the TVM during an intrusion or high‐impact vandalism.

4.6.2 Customer Service Terminals The in‐person transit store and the Reduced Fare Certification Office will supplement the TVMs, primarily for services that require eligibility verification, such as the issuance of reduced fare media. For the transit store, the SI will provide Customer Service Terminals (CSTs) that support the following services:  Perform fare media and value sales  Enable the automatic reloading of value (i.e., autoload)  Perform troubleshooting of fare‐related issues, accessing account balances, transaction history, and customer information  Perform customer service functions such as balance transfers, refunds, and adjustments  Replace lost/stolen/damaged cards  Close or suspend accounts

31 | Page

Future Fare System Study: Concept of Operations

For the Reduced Fare Certification Office, the SI will provide Customer Service Terminals (CSTs) that support the following services:  Issue personalized fare media for reduced fare customers, including capture and printing of a customer photo  Register adult and reduced fare transit accounts

The CSTs will use Ethernet communications to maintain an online connection to the account‐based transaction processor and customer database, and use the SI‐provided APIs to perform all functions. Since reduced‐fare media will be produced onsite at some locations, fare media production equipment such as cameras, card printers, and card encoders will need to be provided as part of the CST. The terminals will be delivered in as compact a configuration as possible. If the CST functionality can be provided through a web‐based interface, using standard PC peripherals, this approach is preferred.

4.6.3 Retail Network Retail locations are intended to serve as a primary channel for issuance of new fare media and the loading of value to closed‐loop transit accounts. The MTA intends to partner with a gift card network or similar retail cash digitization service provider to greatly expand the existing retail network. For retailers who are part of a retail load network, the sale and loading of fare media will be integrated with the retailers existing Point‐of‐Sale (POS) system. Retail partners who are not part of a load network will be provided with a stand‐alone retail sales device, to be supplied by the SI, which is similar in configuration to a stand‐beside point‐of‐sale credit card terminal. This retail device will enable retailers to sell closed‐loop media and load all available fare products to transit accounts at the request of the customer. The retail sales device will support both wired and wireless communications via Ethernet, 802.11 Wi‐Fi, and cellular connectivity. The retail sales device will maintain an online connection to the account‐based transaction processor to perform all fare media and value sales using the SI‐provided APIs. All payments, including those for cash and credit/debit sales, will be processed through the retailers’ existing point‐of‐ sale systems. A unique Stock Keeping Unit (SKU) sheet may be developed to allow retailers to track transit sales independently. 4.7 Websites

4.7.1 Customer Website The SI will deploy a customer‐facing public website that provides a secure, convenient, and comprehensive portal for transit and customer account management. The website will be the primary means of account management and loading value for many customers, and will interface directly with the account‐based transaction processor and customer database using the SI‐provided APIs. Using the customer website, customers will have the ability to:  Order new fare media  Register a transit account  View transit account balance and transaction history

32 | Page

Future Fare System Study: Concept of Operations

 Reload stored value and pass products  Setup autoload to automatically replenish account value  Report a lost/stolen/damaged card for replacement  Submit customer service inquiries  Request a refund or adjustment  Close a transit account  Support a process to verify customers identities, primarily seniors, enabling remote acceptance of eligibility documentation and issuance of reduced fares The customer website will include a mobile‐optimized version that provides all features in a mobile‐ friendly format. The mobile version will be usable on all mobile platforms. When accessing the customer website using one of these devices, customers will automatically be redirected to the mobile‐optimized version.

4.7.2 Institutional Website In addition to the customer website, the SI will deploy an institutional web portal for the online management of transit accounts associated with institutional programs. This institutional web portal will provide institutional program administrators from employers, schools, social service agencies, and other affiliates the ability to place orders for closed‐loop fare media and manage the transit accounts associated with their institution, including the addition and removal of accounts, and the loading of value. Access and configuration of the institutional web portal for each participant will be controlled by the MTA. The website will be customizable, and allow for the configuration of available products, ordering windows, and billing processes to support a wide variety of institutional programs, including the management of pre‐tax transit and parking benefits by employers. Any value loaded using pre‐tax dollars will be segregated within the transit account, including the segregation of value purchased using pre‐tax transit funds and pre‐tax parking funds. The institutional website will enable employers to subsidize part or all of a stored value or pass purchase made by their employees through the customer website. An integration with SmartBenefits, or the design and development of a similar program, may be required. 4.8 Mobile Applications

4.8.1 Fare Inspection The SI will be required to provide handheld fare inspection devices that allows fare enforcement personnel to inspect the closed‐ and open‐loop, account‐based electronic fare media. The inspection devices will have a real‐time communication interface to the account‐based transaction processor via cellular connectivity. NFC‐enabled mobile phones with an SI‐developed mobile fare inspection application are the preferred solution due to their COTS availability and compact size. However, specific device choice will be driven by requirements such as form factor, ruggedness, battery life, and ease of future hardware and software upgrades. A primary requirement is a device that performs well and supports a high volume of fare inspections as quickly as possible.

33 | Page

Future Fare System Study: Concept of Operations

Enforcement rules for inspection devices will be created and managed at the account‐based transaction processor. Validity periods, transfer rules, and fare violations will be clearly defined and presented on the inspection device display to minimize confusion for inspectors and customers. All inspections will be performed using the SI‐provided APIs and will generate transactions for audit and traceability purposes.

4.8.2 Fare Validation While still under consideration, the SI may be required to develop a mobile payment validator application that supports the collection of fares using an NFC‐equipped handset. The mobile payment validator application may be used to collect fares for during special events. The phone would use a cellular connection to the account‐based transaction processor, and the SI‐provided APIs, to process fare payments the same as the other payment validators. The payment validator application may be combined with the fare inspection application or kept separate. If combined, the available functions will be determined based on user login. Users with full access will be able to switch between fare inspection and validation functions. 4.9 Back Office Systems

4.9.1 Customer Relationship Management System The SI will deploy a Customer Relationship Management (CRM) system that allows for the central management of all customer data and tracking of customer service incidents, including creation, escalation, and resolution. The CRM system will store all customer personal information for registered transit accounts and payment information for accounts that are setup for the automatic reloading of value. The CRM system will be fully compliant with PCI‐DSS, in addition to all agency policies regarding the handling of customer Personally Identifiable Information (PII). A web‐based, COTS CRM tool is preferred and will provide customer service staff access to all relevant information needed to assist transit customers and allow access to all records that define an individual customer’s participation in the program. The CRM tool will allow for the viewing and creation of customer service incidents. Customer service staff will be able to manually create incidents when responding to customer service issues over the web or phone. Customer service incidents will also be created automatically based on customer‐initiated actions performed through the website or Interactive Voice Response (IVR) system. Customer service incidents will be linked to a specific transit account, as well as customer information when the account is registered. The CRM tool will connect to the account‐based transaction processor and customer database through the use of the SI‐provided APIs and serve as the primary interface for customer service staff to view and update transit and customer accounts. The CRM tool will enable customer service staff to perform the following functions:  Issue new media (i.e., create a new transit account)  Register a transit account (i.e., create or update a customer account)  View transit account balance and transaction history  Perform fare media and value sales  Enable the automatic reloading of value (i.e., autoload)

34 | Page

Future Fare System Study: Concept of Operations

 Modify a transit account balance as part of a balance transfer, refund, or adjustment  Modify customer account (i.e., registration) data  Modify transit and customer account attributes associated with participation in institutional programs  Initiate replacement of a lost/stolen/damaged card  Close or suspend a transit account All actions resulting in a change in the balance or status of a transit or customer account will be recorded in the CRM system. Access to the system will require two‐factor authentication and allowed functions will be restricted based on centrally defined user‐access privileges.

4.9.2 Interactive Voice Response System An Interactive Voice Response (IVR) system will be provided to support call center operations. The IVR will provide customers calling the call center automated customer support functions and answers to frequently asked questions. The IVR system will enable customer customers to perform the following functions:  Hear transit account balance and transaction history  Purchase fare value (with a saved funding source)  Initiate replacement of a lost/stolen/damaged card  Close or suspend a transit account For issues that cannot be resolved through the automated options, the IVR system will redirect the customer to an appropriate customer service agent.

4.9.3 System Monitoring Application The SI will deploy a system monitoring application that allows for real‐time monitoring of all system devices at least down to the component level and ideally the modular level. It will also include remote control of certain device functions through the issuance of appropriate commands. A web‐based system monitoring tool will allow for the real‐time viewing of device status, events and alarms, and the issuance of device commands. The system monitoring tool will also be used to remotely update component configuration, software, and firmware as needed. The system monitoring application will generate automatic email and text message alerts based on configurable parameters. All agency departments with a business need for system monitoring will have access to the system monitoring tool through a password‐controlled interface. The displayed information and allowed functions will be restricted based on centrally defined user‐access privileges.

4.9.4 Financial Management System The SI will deploy a Commercial‐Off‐The‐Shelf (COTS) financial management system that maintains a general ledger of all financial activity within the new fare payment system. The financial management system will be fully auditable and support end‐to‐end tracking and reconciliation of all fare revenue as it is generated, maintained in deferred revenue accounts, and recognized. The general ledger package will generate standard accounting reports and serve as a sub‐ledger to the MTA’s enterprise financial

35 | Page

Future Fare System Study: Concept of Operations

system. Additionally, the financial management system will include an Accounts Receivable (AR) module that supports the creation of receivables within the general ledger, and the automated generation of invoices associated with fare media and value sales conducted through institutional programs. The creation of receivables and automatic generation of invoices will streamline the process for the MTA and institutions (i.e., employers or social service agencies) by capturing the receivable when the institution places a website order for smart cards or adds products or value (i.e., employees or clients), and will auto‐generate an invoice payable from the institution to the MTA for the smart cards, products or value purchased.

4.9.5 Data Warehouse All data generated by the fare payment system shall be copied into a central data warehouse. The data warehouse will collect data from the account‐based transaction processor, CRM system, system monitoring application, financial management system, and other sources to provide a central source for agency reporting. The data warehouse will not be used by the SI to support any other system functions. The database will be built using an enterprise‐level, Open Database Connectivity (ODBC) compliant Database Management System (DBMS), and follow open standards that allow querying by standard Structure Query Language (SQL) tools and interfaces with other databases. Data captured in the warehouse will include at a minimum:  Fare payment transactions, including all usage information associated with each transaction  Fare distribution transactions from all sales channels, including Ticket Vending Machines (TVMs), in‐person sales locations, the retail vendor network, and call center and internet sales  Transactions generated by the CRM system affecting account value or status, such as credits, refunds, and adjustments  Customer service incidents created within the CRM system  Device events, alarms, and status information captured by the system monitoring application  Accounting entries generated by the financial management system  Analytics data to support fraud detection and prevention Agency privacy policies for the handling of customer PII will be enforced by eliminating the storage of sensitive data where appropriate. No bank card data will be stored within the data warehouse. The agencies will own all system data, including the data contained in the data warehouse. As part of implementation, the SI will deliver a full data dictionary for the data warehouse. All departments having a business need for this data will have read‐level access to the data warehouse through a secure connection. This interface will provide the ability to query the database directly, export data in a variety of formats, and establish a connection to a third‐party reporting tool for use in custom reporting. Access to the data warehouse will be password‐controlled with the viewable data and allowed functions restricted based on centrally defined user‐access privileges.

4.9.6 Reporting Tool The SI will deploy a web‐based reporting tool that interfaces to the data warehouse for the generation of canned and custom reports. The reporting tool will allow for the viewing, running and scheduling of predefined reports, as well as for the creation of custom reports by end users. All personnel having a business need for such reporting will have access to the reporting tool through a password‐controlled

36 | Page

Future Fare System Study: Concept of Operations

web interface, with the option of having reports delivered directly via email. The displayed information and allowed functions will be restricted based on centrally defined user‐access privileges. The SI will be responsible for developing an appropriate set of canned reports to be defined during system design, including but not limited to:  Ridership reports  Sales reports  Financial clearing and settlement reports  Device and system performance reports  Customer service reports  Exception reports The SI will be responsible for developing additional canned reports following system implementation. These reports will be restricted to a specified number and requested within a predefined period following launch of the system. Also, the SI will provide the ability to easily create custom reports from the data that is generated by the fare system, and the ability to query the data directly, using the provided reporting tool. In addition to the SI‐provided reporting tools, MTA will have the ability to connect any data reporting and analytics tools to the data warehouse. If managed by a third‐party, the third‐party will direct and unfettered access to use the data warehouse per MTA’s discretion.

4.9.7 Fare Media Inventory System The SI will deploy a fare media inventory system that enables the agencies to track all serialized media that is procured and issued within the system. The system will track media inventory at the individual card level from delivery by the manufacturer to distribution to institutions, retailers, in‐person customer service centers, and individual customers. The media inventory system will interface with the CRM system and institutional website to provide an accurate accounting of media at all locations as orders are placed and fulfilled.

4.9.8 Test Systems The SI will be responsible for providing multiple test environments to support separate development, testing, staging and pre‐production activities. A minimum of two testing environments will be provided: testing and staging. The testing environment will provide the agency with the ability to perform test transactions using test data as needed. The staging environment will be a full replica of the production system, which will allow the agency to verify an update before releasing it into production. Optionally, a development environment may be desired, which would allow third‐party integrators to develop/integrate to the fare collection system without disrupting current testing.

37 | Page

Future Fare System Study: Concept of Operations

Figure 3: Preliminary System Diagram

4.10 Existing System Interface

4.10.1 CAD/AVL Interface In support of the ongoing Bus USA project, the SI will enable integration of the new on‐board fare equipment with the Trapeze CAD/AVL system. This integration will support single sign‐on and the capture of geolocation information (e.g., GPS coordinates and Stop ID) from the CAD/AVL system, so that this data can be appended to all fare transactions. The CAD/AVL integration may be accomplished using SI‐ or Trapeze‐provided APIs. Integration with the existing Bus USA mobile router is being considered by the MTA to support the real‐time communications for the next generation fare collection system.

38 | Page

Future Fare System Study: Concept of Operations

4.11 System Security

4.11.1 PCI Compliance Any part of the system used to capture, transmit, store, or process bank card data will be fully compliant with the latest version of PCI‐DSS, and the Europay MasterCard Visa (EMV) processing standard, in order to maintain security in the handling of the customer’s bank card information, and lower the risks and processing fees assumed by the agencies under their merchant services agreements. The SI will be responsible for demonstrating, as part of their system design and at public launch, that all applicable hardware and software is PCI and EMV compliant, and for providing appropriate PCI and EMV testing and certification of the system. The SI will be required to maintain PCI‐DSS compliance throughout the contract term. In general, the approach to compliance will include the practice of avoiding the storage of PII and bank card data whenever possible, and only storing or transmitting this data in an encrypted form. Tokenization will also be used wherever possible, meaning that communications between the central system and payment processor will not use the full card number after the first transaction has been authorized. Tokenization will allow for refunds and tracking of chargebacks without having to store the card number.

4.11.2 Physical and Logical Security In addition to PCI‐DSS compliance, the system will be secured using appropriate levels of hardware and software security. Given the sensitive nature of the data being transmitted, a high level of security is required. Security measures will include:  Encryption of all PII data  Use of Virtual Private Network (VPN) connections for all communication where practicable  Firewalls around all system‐specific servers with outbound establishment of communications  Restricted physical and virtual access to back office systems  Protection against physical tampering with devices The SI will be required to propose a device management plan with best practices in distribution, controlled use, inventory management, and replacement of the validators.

4.11.3 Key Management The format of the contactless media will use industry standard data encryption with electronic security keys. The SI will provide offline key management processes and tools that ensure keys are managed in a reliable manner, including recovery processes if keys are compromised. The SI will be required to propose a security architecture and key management plan for the management, distribution, controlled use, revocation, and replacement of security keys. The security architecture and key management plan may incorporate a variety of approaches, inclusive of multiple security domains, embedded device secure elements, and server‐based security.

39 | Page

Future Fare System Study: Concept of Operations

4.12 Redundancy and Disaster Recovery The fare system will be built using a back office that the SI will host, operate, and maintain in the cloud. The deployment will support a high availability, active‐active, load‐balanced configuration with instantaneous failover to ensure ongoing operations and no data loss in the event of a failure or power outage. The SI will be responsible for delivering a disaster recovery plan that allows for the efficient operation and recovery of critical systems in the event of a major outage. The system will also support offline operation of the field devices to perform specific functions, as deemed reasonable by the MTA. The SI will be responsible for installing and testing all redundant systems and disaster recovery procedures as part of the system implementation, as well as all alerts and alarms. 4.13 System Hosting The SI will deploy the system in the cloud, preferably at a Tier 3 data center or higher, and will be responsible for all back office hosting services, deployment, operations, administration and maintenance. The SI will provide a robust operations plan that includes a staffing and communications plan, system monitoring plan, incident handling plan, change management plan, security and access control plan, reporting and audit plan, and third‐party integration plan. 5. Future Fare Policy The supported fare policies are designed to create a unified, interoperable fare system for riders using fixed‐route buses (LocalLink, CityLink, and Express BusLink), metro services (SubwayLink), light rail (RailLink), and paratransit services (MobilityLink). Commuter bus service, commuter rail service (MARC), and call‐a‐ride services are currently out of scope, however, will likely be icluded in future integrations. 5.1 Fare Payment Options With the implementation of the new fare system, the MTA will accept agency‐issued extended‐use smartcards and electronically validated virtual cards issued via an agency‐branded mobile application. Both fare payment options should be linked to closed‐loop transit accounts. Customers will be able to use the agency‐issued cards and virtual cards to pay fares onboard buses, onboard MobilityLink vehicles, at faregates, and at light rail stations. Customers will also be able to use cash to pay fares on‐board buses and MobilityLink vehicles. Cash will be able to be used to purchase and reload fare media at 3rd party retailers, at the in‐person transit store, and at TVMs. Credit and debit cards will be accepted at TVMs, and for purchase/reload of fare media at the in‐person transit store, 3rd party retailers, via the call center, on the web, and through the mobile application. The fare system will be built on a closed‐loop foundation but shall have the ability for the agency to enable/disable open‐payments in the future at the discretion of the agency. 5.2 Fare Media In addition to accepting cash, virtual cards, and smartcards issued by the transit agency the system shall support the ability for third‐party cards to be linked to a closed‐loop transit account (e.g., an institutional account manager able to link their participants’ ID cards to a closed‐loop transit account), similar to the mobile app Fare Share Program at the MTA. The system shall also allow for the acceptance of electronically validating limited‐use (LU) media; however, specifications for this fare media type have not been fully defined yet.

40 | Page

Future Fare System Study: Concept of Operations

5.2.1 Agency Issued Media Agency‐issued fare media will be limited to:  Contactless extended‐use ISO‐14443 compliant smartcards that are linked to closed‐loop transit accounts and used to pay fares using stored value and/or fare products.  Electronically validating limited‐use (LU) media  Agency branded closed‐loop virtual cards (NFC‐ or QR Code‐based)

5.2.2 Third‐Party Media The system will support the linking of third‐party media to closed‐loop transit accounts, such as student IDs, State of Maryland employee IDs, MTA employee IDs, and other security badges. The SI will deliver a fare media application and/or format specification to support the integration of such media if it is desired in the future. 5.3 Supported Fare Rules

5.3.1 Fare Structure All fixed‐route buses (LocalLink, CityLink, and Express BusLink), metro services (SubwayLink), light rail (RailLink), and paratransit services (MobilityLink) fares will continue to be based on a flat fare structure. MARC and Commuter bus fares will continue be zone‐based, and call‐a‐ride fares will continue to be distance‐based, but neither will be included in the initial implementation. The system tariff will support flat fares, distance‐based fares, and time‐based transfers. All fares will be deducted from stored value or pass products. Customers will be expected to tap‐on at all boardings, including transfer points. Fares will include incentives to use smartcards/virtual cards, such as transfer privileges, balance protection, fare capping with accumulators, and possibly other loyalty programs and promotions with local businesses. Specific incentive policies will be determined prior to procurement.

5.3.2 Fare Pricing Fare pricing is expected to follow the MTA’s published Fare Policy document. Except for free time‐based transfers and fare capping, the agency does not plan on providing base‐fare discounts other than those already listed in the MTA’s Fare Policy document. The MTA anticipates a user‐friendly, agency‐ configurable tariff engine.

5.3.3 Base Fare For all local MTA services (excluding the call‐a‐ride service) the base fare will be the price paid for a one‐ way Adult ride using stored value. For the Commuter buses, the base fare will be based on the zone in which the passenger intends to board.

5.3.4 Reduced Fares Reduced fares will continue to be available to customers who qualify by virtue of age or disability. Granting and validation of reduced fare eligibility will be supported primarily by the electronic fare payment system. Customers eligible for reduced fares will be required to obtain personalized reduced

41 | Page

Future Fare System Study: Concept of Operations

fare media linked to a registered transit account that identifies the holder as eligible for a reduced fare. Any reduced fare higher than a single trip ticket will be required to be paid using a smartcard/virtual card, either using stored value or using a reduced fare pass loaded to the associated account.

5.3.5 Service‐Based Fares The fare system will be designed to support different fares for different services, such as a premium charge for express bus trips. An upgrade fare (or upcharge) will be supported for riders transferring between services. Customers would automatically have upcharges deducted from stored value when boarding the new service.

5.3.3 Fare Products Fare products will include stored value, calendar passes, rolling passes, and institutional fare products, such as those available to employers, universities, and social service agencies. These products will be available only on the electronic media.

5.3.4 Stored Value The implementation of the fare system will support closed‐loop transit accounts. Customers will be able to load stored value into a transit account and pay individual fares by tapping or possibly scanning an agency‐issued card/virtual card linked to that account at fare validators prior to or upon boarding a transit vehicle. Customers paying fares using stored value will be eligible for free transfers and other benefits, including fare capping.

5.3.5 Calendar Passes The system will support calendar‐based passes that are valid for travel on certain services over a specified calendar period (e.g., day, week, month). These account‐based prepaid electronic calendar passes will be available to both full fare and reduced fare customers, and will be designed to support both service‐ and mode‐specific usage. MTA would like to reduce the number of prepaid calendar passes offered to the public and replace them with calendar‐based fare capping allowing users to earn calendar passes while paying fares on a Pay‐As‐ You‐Go (PAYG) basis. Fare capping is described in more detail in Section 5.4.2.

5.3.6 Rolling Passes The system will support rolling passes that are valid for unlimited rides valid for travel on certain services for a defined period from first use. These account‐based prepaid electronic rolling passes will be available to both full fare and reduced fare customers, and will be designed to support both service‐ and mode‐specific usage.

5.3.7 Institutional Fare Products The MTA may offer account‐based fare products, such as annual and term‐based passes, specifically to participants of institutional programs. Institutional fare products will be defined during system design and will not be available to the general public. Institutions will load value to participants’ accounts using the institutional website (see Section 4.7.2).

42 | Page

Future Fare System Study: Concept of Operations

5.4 Additional Fare Policies

5.4.1 Transfers In the future, transfer privileges will be managed electronically. Fare pricing will allow transfer credits for boardings that occur within a specified time of tapping/scanning fare media at a fare validator. Service‐based or location‐based fares will require that customers transferring to routes or services with higher fares be charged an upgrade fare equal to the difference between the applicable fares. The transfer period (e.g., the time period during which a boarding is eligible for a transfer) and rules regarding allowable connecting trips will be configurable and managed electronically.

5.4.2 Fare Capping The system will support fare capping, which allows a customer to earn a calendar pass after reaching a spending threshold (i.e., fare cap) for PAYG (i.e., stored value or open payment) fares paid over a defined calendar period. The MTA wishes to support day, week, month fare capping for both Adult and Reduced Fare customers. Fare capping will be configurable by service and mode, with each fare category, service/mode, and capping period combination having unique fare accumulators to track spend, and unique accumulation rules based on the services used. 5.5 Special Programs

5.5.1 Institutional Programs The agencies will work with employers, colleges, and universities to transition existing institutional programs to the new fare system. Participating institutions will be responsible for administering and managing participants’ transit accounts under these programs, including adding value or products to accounts and updating accounts as participants enter or leave the program. Account management will occur through the Institutional Website (see Section 4.7.2).

5.5.2 Social Service Programs The agencies will work with social service organizations to provide agency‐issued extended‐use and limited‐use media to the beneficiaries of desired social service programs. Participating organizations will be responsible for distributing media, and as necessary, administering and managing participants’ transit accounts under these programs, including adding value to accounts and updating accounts as a participant’s eligibility changes. Account management will occur through the Institutional Website (see Section 4.7.2).

5.5.3 Paratransit Fare payment using agency‐issued smartcards will be accepted in the future on MobilityLink paratransit services. These smartcards will act both as a fare payment media and an MTA‐issued MobilityLink ID. The fare media issued to ADA‐eligible customers will be linked to transit accounts that will be charged the appropriate fare at the time a ride is taken. Paratransit riders will also utilize their agency‐issued card to access fixed‐route services. MobilityLink customers will tap their cards on fixed‐route vehicles but will not be charged a fare, per MTA policy.

43 | Page

Future Fare System Study: Concept of Operations

6. Future Fare System Operations 6.1 Operating Responsibilities The fare system will require many ongoing activities to support system operations. This section describes the operational services that are envisioned. These services may be performed by in‐house staff, existing partners, or as a third‐party service The anticipated approach to operations is described in the Operations Approach (see Section 6.2).

6.1.1 Program Management The system will require central program management. The program manager will be responsible for overseeing general operation of the system and managing all contracts for shared services.

6.1.2 Financial Management The new fare system will generate revenue that may need to be divided among any participating LOTS based on use of the system by customers. As such, the system will require the management of fare revenues and distribution of those funds to the LOTS, based on established agreements. Financial management may also include holding the merchant services agreements for the processing of bank cards, investment of funds, and system‐wide reconciliation.

6.1.3 System and Network Hosting The account‐based architecture planned for the system will require reliable, secure, and continuous communications between the frontend devices and the back office. Fiber and cellular networks will support these needs. The system will also require the cloud‐hosting of the back office systems in an active‐active, load‐balanced configuration to ensure ongoing operations in the event of a failure or power outage at one site.

6.1.4 Back Office Operations The system will require support for daily back office operations, including ensuring the timely and accurate processing of transactions, overseeing operation of the back office support systems (e.g., CRM and financial management systems), supporting the testing and deployment of software releases, and maintaining the appropriate system configurations. Fare structure changes and associated business rules will be managed and modified by the agencies through a back office web interface.

6.1.5 System Monitoring The system will require real‐time monitoring of network, back office and device performance via the system monitoring application to support system maintenance.

6.1.6 Device Maintenance The system will require the maintenance and repair of devices in and out of the field. Maintenance activities will include both planned preventive maintenance and as‐needed repair.

44 | Page

Future Fare System Study: Concept of Operations

6.1.7 Revenue Servicing The system will require the collection of cash and replacement of consumables, including receipt paper and fare media, for unattended distribution devices (e.g., TVMs). The cash will also need to be processed (i.e., counted and packaged) for deposit in the bank.

6.1.8 In‐Person Customer Service The system will require in‐person customer service centers to validate reduced fare customers, issue personalized reduced fare media, sell fare media and value, and respond to customer service inquiries. In‐person customer service staff will use the SI‐provided Customer Service Terminals to perform all required functions.

6.1.9 Customer Call Center The system will require running a customer call center to respond to customer inquiries and conduct sales over the phone. Customer service representatives will use the SI‐provided CRM system as the primary interface for sales and customer account management.

6.1.10 Special Program Management The system will require the oversight of the institutional programs and other transit partners. The management of partner programs is crucial since a significant amount of transit riders may belong to institutional programs such as those for employers, schools, or other government agencies. Management will involve recruiting new partners as well as support of existing partners based on established contracts, including ensuring timely and accurate fulfillment of orders. This management will occur using the unified Institutional Website that can be accessed by program administrators.

6.1.11 Retail Network Management The system will require the establishment of a robust sales network of retail outlets across the region. This will be the primary channel for many customers to purchase fare media and reload fare value, especially for customers who may not have access to credit/debit cards, mobile phones, or the internet. The retail network management will include contract management for all retail network partners, support for recruitment of new retail locations, and coordination of training, fulfillment of media orders, and retail sales device troubleshooting and maintenance for existing partners.

6.1.12 Marketing and Communications The fare system will require an update to the existing brand, or the development of a new brand, as implementation nears completion, including marketing, promotions, and public outreach to new and existing customers to help ensure a successful program launch. Continued customer communications following launch is also critical to project success. 6.2 Operations Approach The operations approach describes which parties will be responsible for performing the operating functions described in the prior section. Responsibilities will be split between the MTA and third‐party service providers. The table below provides a high‐level overview of the operations approach.

45 | Page

Future Fare System Study: Concept of Operations

Table 13: Future Fare System Operations Approach Table In‐House Centralized In‐House Distributed Third‐Party Program Management Back Office Operations Financial Management System Hosting In‐Person Customer Service Retail Network Management Marketing and Communications Mobile Application Bus Equipment Maintenance TVM and Faregate Maintenace Revenue Servicing Special Program Management Call Center Operations

6.2.1 In‐House Centralized Functions The MTA will be responsible for the core functions supporting management of the new system. Where appropriate, functions will be assigned to specific departments within the organization.

6.2.2 Program Management The MTA will identify and/or establish a Program Management Office (PMO) to oversee the general operation of the system. The PMO will also manage the third‐party service contracts and serve as a central point of contact for the vendors providing those services.

6.2.3 Financial Management The MTA Finance Department will manage the revenue generated by the system. Responsibilities will include revenue accounting, reconciliation of all funds entering and leaving the system, and the settlement of funds to all program participants based on established agreements.

6.2.4 In‐Person Customer Service The Transit Store at 6 Saint Paul Street is currently being used to service eligible reduced fare customers, issue reduced fare IDs, sell fare media, and resolve customer service issues. Under the new system, the Transit Store will continue to provide these services at the current location. Paper media will be replaced with electronic fare media and value, and personalized electronic media will be issued in place of the existing IDs for reduced fare customers. All functions performed by the Transit Store customer service staff will be supported by the SI‐provided Customer Service Terminal which will also enable Transit Store agents to perform customer service functions associated with electronic fare media, as desired.

46 | Page

Future Fare System Study: Concept of Operations

6.2.5 Marketing and Communications Marketing and communication support for the new fare system will be handled internally by the MTA marketing and communications department.

6.2.5.1 Bus Equipment Maintenance The MTA currently maintains all of the electronic equipment installed on their vehicles. With the introduction of the new fare system, MTA will also maintain the onboard validators and mobile routers that are installed. The MTA will perform field (i.e., first‐line) repair of the equipment. Field repair will be performed as a “pop‐and‐swap” to replace defective equipment. It is assumed no shop‐level (i.e., second‐line) repair will be required for the onboard equipment. Defective equipment will be returned to the SI or manufacturer for replacement. MTA will use the SI‐provided system monitoring application for real‐time monitoring of device status. If and when the LOTS sign‐on to utilize the new fare system, the LOTS may be responsible for the maintenance of their on‐board bus equipment.

6.2.5.2 TVM and Faregate Maintenance The MTA will be responsible for performing maintenance on TVMs and faregates installed at rail stations, or other locations to support bus operations. The MTA will be responsible for both field (i.e., first‐line) and some shop (second‐line) repair of the equipment components, while some components may be serviced by third‐parties. MTA will use the system monitoring application to monitor device status and take appropriate maintenance actions.

6.2.5.3 Revenue Servicing The MTA will be responsible for performing revenue servicing of the TVMs, including the collection of cash and the replacement of consumables (e.g., receipt paper and fare media). The MTA will also collect cash from the Transit Store, and be responsible for all cash processing, including counting, reconciliation, and deposit.

6.2.5.4 Special Program Management The MTA currently manages institutional programs for employers, schools, and government agencies, and will continue to support these programs when they are transitioned to the new fare system. The MTA will be responsible for overseeing institutional customer support and expanding program participation where possible. The management of institutional programs, including the management of individual participants and the ordering of fare media and value, will largely be the responsibility of the institutions and will occur via the Institutional Website.

6.2.5.5 Call Center Operations WMATA currently operates a call center to answer customer inquiries and resolve fare issues related to the CharmCard. MTA intends to transition the call center operations in‐house as part of the ongoing SoGR project and this will continue under the new fare system. MTA customer service staff will use the SI‐provided CRM system to view and modify transit and customer accounts and perform fare media and value sales.

6.2.6 Third‐Party Functions Some technical system operations functions will be included in the third‐party service provider’s scope of work. In some cases, the services may be performed by the SI and procured as part of the core

47 | Page

Future Fare System Study: Concept of Operations

system. In other cases, the services will be procured under a separate procurement and may be performed by another supplier.

6.2.6.1 Back Office Operations The SI will be responsible for back office operations for a defined operating period following system launch. During the operating period, the SI will monitor system performance and health, ensure timely and accurate processing of transactions, oversee operation of the back office support systems (e.g., CRM and financial management systems) and websites, support testing and deployment of new software releases, and maintain up‐to‐date system patching and configuration.

6.2.6.2 System Hosting System hosting will be supported by the SI under the management of MTA. The SI will be responsible for all system infrastructure and central communications supporting the new system.

6.2.6.3 Retail Network Management Management of the retail network will be supported by an external vendor. The retail network manager, under contract with MTA, will oversee the relationship with retail partners as they all transition to the distribution of electronic fare media and value. The retail manager will be responsible for recruiting and training retailers to be part of the integrated retail network, as well as supporting the retail sales devices for those retailers that aren’t part of the integrated network. The retail manager will also be responsible for distributing the electronic fare media for sale by the retail partners.

6.2.6.4 Mobile Application The MTA will retain a third‐party supplier, either through the SI or a separate procurement, to provide the mobile application for the new fare system. The mobile application vendor will be responsible for working with the SI to ensure proper integration with the back office and long‐term support for the mobile application.

48 | Page

Future Fare System Study: Concept of Operations

7. Appendix A: Estimated Equipment Quantities Item Qty Spares Total TVMs at MARC stations 84 10% 93 Fareboxes for buses 830 10% 913 Portable Data Unit 20 10% 22 Pole Mounted Validators for buses 830 10% 913 Receiver/Vaults for deposits 8 10% 9 TVMs at Metro Stations 87 10% 96 Gates at Metro Stations 171 10% 189 Validators at Metro Stations 171 10% 189 Station computers and networks 14 10% 16 Station agent equipment such as CPOS 14 10% 16 TVMs at Light Rail Stations 87 10% 96 Onboard Paratransit validators 508 10% 559 Handheld Inspection Units 50 10% 55 Maintenance shop test beds (golden chassis, 2 of all eqt) 2 10% 3 Fare Cards Until System Acceptance 500,000 N/A 500,000

49 | Page