Concept of Operations - Future Fare System: March 2020 - BidNet
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 commuter bus routes) fare‐free. Not valid for free rides on the
Valid State ID
Maryland Active MARC train.
card
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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eFuture 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 | P a g eYou can also read
