APPENDIX 1

MDOT MTA Electronic Collection Scope of Work

AGY-21-008-IT APPENDIX 1

Acronyms & Glossary

2FA– Two-Factor Authentication ABP – Account-Based Processor ABT– Account Based Ticketing ACH – Automated Clearing House ADA – Americans with Disabilities Act AES –Advanced Encryption Standard ADAAG – ADA Accessibility Guidelines AFC – Automated Fare Collection AJAX – Asynchronous JavaScript and XML AMPS – Account Management and Processing System ANSI – American National Standards Institute APC – Automated Passenger Counter API – Application Programming Interface AR – Accounts Receivable ASCII–American Standard Code for Information Interchange ATC–Air Traffic Control ATP – Account-Based Transaction Processor AUT–Application Under Test AVS – Address Verification System BCPU –Bank Card Processing Unit BHU— Bill Handling Unit BO Ops—Back-Office Operations BOD – Operator Display CAC – Common Access Card CAD/AVL – Computer‐aided Dispatch/Automatic Vehicle Location system CAT6 –Category 6 Cable CCTV – Closed‐Circuit Television CDA – Combined Data Authentication CDMA – Code Division Multiple Access CDR – Conceptual Design Review CDRL – Contract Data Requirements List CEC – California Energy Commission CHU – Coin Handling Unit CIPURSE – An open security standard for transit fare collection systems CMS – Content Management System 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 DDA – Dynamic Data Authentication DESFIRE – Data Encryption Standard Fast, Innovative, Reliable and Secure DUO – Cisco Duo Security

AGY-21-008-IT APPENDIX 1

EDP – Electronic Data Processing E2E – End-to-End ECR – Engineering Change Requests EFT – Electronic Funds Transfer EMI – Electromagnetic Interference EMV – Europay, MasterCard, Visa ESN – Electronic Serial Number ETL – Extract, Transform and Load EU – Extended Use FACI – First Article Configuration Inspection FAT – Factory Acceptance Test FCC – Federal Communications Commission FDR – Final Design Review FIT – Field Integration Test FMI – Field Modification Instructions fPan – funding Payment Account Number FPV – Fare Payment Validation FRB – Failure Review Board FUT – Functional Unit Testing GFCI – Ground Fault Circuit Interrupter GL – General Ledger GSM – Global System for Mobile communications HHU – Handheld Unit HTML – Hypertext Markup Language HTTPS – Hypertext Transfer Protocol Secure I/O – Input/Output IaaS– Infrastructure as a Service IBM‐ International Business Machines Corporation – A technology company ICD – Interface Control Documentation IEC – International Electrotechnical Commission IIN – Issuer Identification Number INCITS – International Committee for Information Technology Standard iOS – Operating System for Apple products IRS – Internal Revenue Service IVR – Interactive Voice Response system IP – Internet Protocol ISO – International Standards Organization KPI – Key Performance Indicators LCD – Liquid Crystal Display LLRU – Lowest Level Replacement Unit LU – Limited Use MARC‐ Maryland Area Regional Commuter MDM – Mobile Device Management MDOT – Maryland Department of Transportation MDT – Mobile Data Terminal MED – Media Encoder/Dispenser MIFARE – A NXP owned series of chips used in contactless smart cards MIL – Master Issues List

AGY-21-008-IT APPENDIX 1

MIL‐STD – U.S. Military Standard MIMS – Media Inventory Management System MS – Microsoft MTA –Maryland Transit Administration MTT – Mass Transit Transaction MVP – Minimum Viable Product NEC – National Electric Code NFC – Near Field Communication NFPA – National Fire Protection Association NTP – Notice to Proceed NVM – Non-Volatile Memory ODA – Offline Data Authentication ODBC ‐‐ Open Database Connectivity OEM – Original Equipment Manufacturer P2PE – Point-to-Point Encryption PA – Payment Account PA‐DSS – Payment Application Data Security Standard PAN – Primary Account Number PAR – Payment Account Reference PAT – Production Acceptance Test PCI‐DSS – Payment Card Industry – Data Security Standard PDR – Preliminary Design Review PDU – Protocol Data Unit PII – Personally Identifiable Information PIV – Personal Identity Verification POS – Point of Sale system PM – Preventative Maintenance PM – Project Manager PMP – Project Management Professional QA – Quality Assurance QC – Quality Control QR – Quick Response QSA – Qualified Security Assessor RAM – Random Access Memory RFI – Radio Frequency Interference RMS – Revenue Management System SAE – Society of Automotive Engineers SAM – Secure Access Module SAP ‐ System Analysis and Program Development – A software company SAT – System Acceptance Test SBC – Single Board Computer SAV – Stand‐alone Validator SCADA – Supervisory Control and Data Acquisition SED – Smartcard Encoder/Dispenser SI – System Integrator SIT – System Integration Test SKU – Stock Keeping Unit SMA – System Monitoring Appliance

AGY-21-008-IT APPENDIX 1

SMA – Software Maintenance Agreement Smart MX – Brand of secure controller platforms owned by NXP SMMA – System Monitoring and Management Application SNMP3 – Simple Network Management Protocol version 3 SoGR – State of Good Repair SQL – Structured Query Language SSD – Solid State Drive SSL – Secure Socket Layer sTVM – simple Ticket Vending Machine TDEA – Triple Data Encryption Algorithm TLS – Layer Security TTY ‐‐ Teletypewriter TVM – Ticket Vending Machine UI – User Interface UID – Unique Identification Number UL – Underwriter Laboratories UPS – Uninterruptible Power Supply USB – Universal Serial Bus UX – User Experience VDC – Voltage Direct Current VPN – Virtual Private Network WMATA – Washington Metropolitan Area Transit Authority XGA – Extended Graphics Array

AGY-21-008-IT APPENDIX 1

Table of Contents

1. Introduction ...... 1 1.1 Project Stakeholders ...... 1 1.2 Project Timeline ...... 2 1.2.1 Phased Delivery Approach ...... 2 1.2.2 Transition Approach ...... 6 1.2.3 Operations Approach ...... 7 1.3 Technical Specification Format ...... 8 2. Future System Overview ...... 9 3. Project Management Requirements ...... 11 3.1 Project Manager and Lead Engineer ...... 11 3.2 Project Meetings ...... 12 3.2.1 Project Kickoff Meeting ...... 12 3.2.2 Progress Review Meetings ...... 12 3.2.3 Weekly Project Coordination Meetings ...... 14 3.3 Project Management Plan ...... 14 3.3.1 General Requirements ...... 14 3.3.2 Master Program Schedule ...... 15 3.3.3 Scope Management ...... 16 3.3.4 Cost Management ...... 16 3.3.5 Risk Management ...... 17 3.3.6 Transition and Change Management ...... 17 3.3.7 Safety Assurance ...... 18 3.3.8 Quality Assurance and Control ...... 18 3.3.9 Subcontractor Management...... 20 3.3.10 Communications Management and Document Control ...... 21 3.3.11 Master Issues List ...... 21 3.4 Change Control ...... 22 3.4.1 Change Control Process ...... 22 3.4.2 Hardware and Software Versioning ...... 23 3.4.3 Component Identification ...... 24 3.5 Required Submittals ...... 25 4. Common Design Requirements ...... 26

AGY-21-008-IT APPENDIX 1

4.1 Service-Proven Design ...... 26 4.2 Nonproprietary Technology ...... 27 4.3 Supply and Availability ...... 28 4.4 Materials and Workmanship ...... 28 4.5 Software Design Principles ...... 29 4.6 Maintainability and Serviceability ...... 30 4.7 Operating Environment ...... 32 4.7.1 Shock and Vibration ...... 32 4.7.2 Climate Conditions ...... 33 4.7.3 Electrical ...... 36 4.8 Licensing and Data Ownership ...... 39 4.9 ADA Compliance...... 40 4.10 Code and Regulation Compliance ...... 40 4.11 Required Submittals ...... 41 5. System Architecture Requirements ...... 42 5.1 Account-Based System ...... 43 5.2 Real-Time Communications ...... 43 5.3 Open Architecture ...... 44 5.3.1 System Interfaces and APIs ...... 44 5.3.2 Transaction Formats ...... 56 5.4 Open Payment Acceptance ...... 57 5.4.1 General Requirements ...... 57 5.4.2 Supported Formats ...... 58 5.4.3 Payment Security ...... 58 5.4.4 Online Payment Validation ...... 59 5.4.5 Offline Payment Validation ...... 60 5.4.6 Payment Authorization ...... 61 5.4.7 Payment Tokenization ...... 62 5.4.8 Payment Aggregation and Debt Recovery ...... 62 5.5 Fare Media ...... 63 5.5.1 General Requirements ...... 63 5.5.2 Physical Characteristics ...... 64 5.5.3 Fare Media Format ...... 65 5.5.4 Transit Payment Application ...... 65 5.5.5 Security ...... 66

AGY-21-008-IT APPENDIX 1

5.5.6 Third-Party Media ...... 67 5.5.7 Initial Fare Media Supply ...... 67 5.6 Risk Mitigation Techniques ...... 68 5.7 Payment Processing ...... 69 5.8 System Security ...... 71 5.9 Back-office Hosting and Architecture ...... 72 5.9.1 Cloud-Hosted Environment ...... 72 5.9.2 Production Back-office Architecture ...... 73 5.9.3 Non-Production Back-office Instances ...... 75 5.9.4 Disaster Recovery ...... 76 5.10 Required Submittals ...... 76 6. Fare Structure Requirements ...... 77 6.1 General Requirements ...... 78 6.2 Fare Pricing ...... 78 6.3 Fare Products ...... 79 6.4 Transfers ...... 81 6.5 Fare Capping ...... 81 6.6 Fare Distribution and Management ...... 82 6.6.1 Fare Media and Product Sales ...... 82 6.6.2 Account Registration ...... 83 6.6.3 Autoload ...... 84 6.6.4 Special Fare Programs ...... 85 6.7 Fraud Detection ...... 87 6.8 Configuration Management ...... 88 6.9 Required Submittals ...... 89 7. Fare Equipment Requirements ...... 89 7.1 Common Equipment Requirements ...... 89 7.1.1 General Requirements ...... 89 7.1.2 Hardware ...... 90 7.1.3 Software ...... 91 7.1.4 Configuration ...... 92 7.2 Fare Payment Validator ...... 93 7.2.1 General Requirements ...... 93 7.2.2 Hardware ...... 94 7.2.3 Software ...... 99

AGY-21-008-IT APPENDIX 1

7.2.4 Operations ...... 102 7.3 Bus Operator Display ...... 104 7.4 Faregates ...... 106 7.4.1 General Requirements ...... 106 7.4.2 Hardware ...... 107 7.4.3 Software ...... 114 7.4.4 Operations ...... 117 7.5 Rail Station Agent Console ...... 122 7.5.1 Hardware ...... 122 7.5.2 Communications ...... 123 7.5.3 Operation ...... 123 7.6 Full-Service Ticket Vending Machine (PRICED OPTION) ...... 124 7.6.1 General Requirements ...... 124 7.6.2 Hardware ...... 126 7.6.3 Software ...... 143 7.6.4 Operations ...... 146 7.7 Simple Ticket Vending Machine (PRICED OPTION) ...... 152 7.7.1 General Requirements ...... 152 7.7.2 Hardware ...... 154 7.7.3 Software ...... 168 7.7.4 Operations ...... 171 7.8 Customer Service Point of Sale ...... 177 7.8.1 General Requirements ...... 177 7.8.2 Hardware ...... 180 7.8.3 Software ...... 185 7.8.4 Operations ...... 190 7.9 Mobile Fare Inspection ...... 195 7.9.1 General Requirements ...... 196 7.9.2 Hardware ...... 197 7.9.3 Mobile Fare Inspection Application ...... 198 7.10 Required Submittals ...... 200 8. Back-office Requirements ...... 201 8.1 General Requirements ...... 202 8.2 Account-Based Transaction Processor ...... 202 8.2.1 General Requirements ...... 203

AGY-21-008-IT APPENDIX 1

8.2.2 Fare Distribution ...... 204 8.2.3 Fare Payment ...... 204 8.2.4 Fare Inspection ...... 206 8.3 Customer Relationship Management System ...... 207 8.3.1 General Requirements ...... 207 8.3.2 Customer Database ...... 208 8.3.3 CRM Tool ...... 209 8.3.4 Customer Service Records ...... 211 8.4 System Monitoring Application ...... 212 8.4.1 General Requirements ...... 212 8.4.2 Device and System Monitoring ...... 212 8.4.3 Device Management ...... 214 8.5 Media Inventory Management System ...... 214 8.6 Revenue Management System ...... 215 8.6.1 General Requirements ...... 215 8.6.2 General Ledger ...... 216 8.6.3 Accounts Receivable ...... 217 8.6.4 Funds Settlement ...... 218 8.6.5 Financial Reporting ...... 219 8.7 Data Warehouse ...... 219 8.8 Reporting System ...... 221 8.9 Required Submittals ...... 223 9. Customer Application Requirements ...... 224 9.1 Customer Application Design ...... 224 9.1.1 Design Criteria ...... 224 9.1.2 Payment Processing ...... 225 9.2 Customer Website ...... 226 9.2.1 General Requirements ...... 226 9.2.2 Fare Media Purchase and Registration ...... 227 9.2.3 Fare Product Purchases ...... 228 9.2.4 Account Status and Transaction History ...... 229 9.2.5 Customer Service ...... 229 9.3 Institutional Website ...... 230 9.3.1 General Requirements ...... 230 9.3.2 Registration ...... 232

AGY-21-008-IT APPENDIX 1

9.3.3 Adding and Deleting Participants ...... 233 9.3.4 Placing Orders ...... 233 9.3.5 Payment ...... 234 9.4 Fare Payment and Account Management Mobile Application (PRICED OPTION) ...... 235 9.4.1 General Requirements ...... 235 9.4.2 User Interface ...... 236 9.4.3 Digital Fare Media ...... 239 9.5 IVR ...... 241 9.5.1 General Requirements ...... 241 9.5.2 IVR Functions ...... 241 9.6 Required Submittals ...... 243 10. On-Board System Integration Requirements ...... 243 10.1 CAD/AVL Integration ...... 243 10.2 Mobile Data Routers Integration ...... 244 10.3 Required Submittals ...... 245 11. Design Review Requirements ...... 245 11.1 General Requirements ...... 245 11.2 Conceptual Design Review ...... 247 11.3 Preliminary Design Review ...... 248 11.4 Final Design Review ...... 249 11.5 Required Submittals ...... 251 12. Testing Requirements ...... 251 12.1 General Requirements ...... 258 12.2 Test Documentation ...... 259 12.2.1 Inspection and Test Plan ...... 259 12.2.2 Inspection and Test Procedures ...... 260 12.2.3 Inspection and Test Reports ...... 261 12.2.4 Test Waivers ...... 262 12.3 Agency Test Facility ...... 263 12.4 Factory Testing ...... 265 12.4.1 First Article Configuration Inspection ...... 265 12.4.2 Factory Acceptance Test ...... 265 12.4.3 Production Acceptance Test ...... 267 12.5 Integration Testing ...... 268 12.5.1 Functional Unit Testing ...... 268

AGY-21-008-IT APPENDIX 1

12.5.2 System Integration Test ...... 270 12.5.3 Field Integration Test ...... 272 12.6 Acceptance Testing ...... 275 12.6.1 Pilot ...... 275 12.6.2 System Acceptance Test ...... 276 12.6.3 Final Project Acceptance ...... 277 12.7 Required Submittals ...... 278 13. Training Requirements ...... 279 13.1 General Requirements ...... 279 13.2 Training Plan ...... 281 13.3 Training Materials ...... 281 13.4 Training Courses ...... 282 13.5 Manuals ...... 285 13.5.1 Manual Content and Format ...... 285 13.5.2 Required Manuals ...... 287 13.6 Required Submittals ...... 288 14. Installation Requirements ...... 288 14.1 General Requirements ...... 289 14.2 Installation Plan ...... 291 14.3 Site Surveys ...... 292 14.4 Prototype Installations ...... 292 14.5 Onsite Work Requirements ...... 293 14.6 Installation Procedures ...... 293 14.7 Shop and As-Built Drawings ...... 294 14.8 Required Submittals ...... 295 15. System Operations Requirements ...... 295 15.1 Warranty ...... 298 15.2 Software Maintenance Agreement ...... 301 15.3 Back-Office Operations Requirements ...... 302 15.4 Software Maintenance Requirements ...... 304 15.4.1 General Requirements ...... 304 15.4.2 Communication, Response, and Resolution ...... 306 15.4.3 Software Change Management ...... 307 15.4.4 Software Enhancements ...... 307 15.5 Equipment Repair and Replacement ...... 307

AGY-21-008-IT APPENDIX 1

15.6 Required Submittals ...... 308 16. System Performance Requirements ...... 309 16.1 Key Performance Indicators ...... 309 16.1.1 Equipment ...... 309 16.1.2 Back-office ...... 311 16.1.3 Operations ...... 313 16.2 Performance Monitoring ...... 314 16.2.1 General Requirements ...... 314 16.2.2 Failure Review Board ...... 315 16.2.3 Failure Definition ...... 316 16.3 Performance Reporting ...... 318 16.4 Credit Assessment ...... 319 16.5 Required Submittals ...... 320

AGY-21-008-IT

APPENDIX 1

1. Introduction It is the intention of the Maryland Transit Administration (MTA), to engage an experienced and qualified Design/Build vendor, or System Integrator (SI), to develop and install a multimodal account-based automated fare collection system (“Fare Collection System”) and support the MTA with a methodical transition from their current card-based AFC system, CharmCard. These Technical Specifications describe and define the equipment and services that are required for the design, manufacture, fabrication, testing, installation, and acceptance of the new Fare Collection System.

1.1 Project 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 project 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, Finance & Accounting Maintenance, Transit Store, Revenue Control

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, , Mobility

AGY-21-008-IT 1 | Page

APPENDIX 1

1.2 Project Timeline

In 2009, the MTA launched a card-based electronic fare payment system, named CharmCard. After eleven (11) years of service, the system is quickly reaching end-of-life making the need for a new AFC solution imminent. Since most of the original CharmCard system’s components are no longer manufactured and are becoming increasingly harder to procure, the new fare payment system must be operational by mid-2023.

1.2.1 Phased Delivery Approach

To meet this timeline, the MTA desires a schedule that staggers the launch of various system features into different Phases. This strategy aims to provide the MTA with a working system that lowers overall project risk by allowing the agency and SI to focus their attention on the delivery of a “minimum viable product” (MVP). The MVP is defined as the minimum amount of system equipment and system features that the vendor could deliver to provide a functioning product by mid-2023. After the delivery of the minimum viable product, additional components and features will be delivered over the next three (3) years. The delivery schedule is divided into 3 Phases. The 3 Phases are as follows:

• Phase 1 MVP • Phase 2 Open Payments and Exercised Options • Phase 3 Full Implementation

Each of these 3 Phases will be a staggered deployment with each Phase containing its own full deployment cycle consisting of notice to proceed, kickoff, design review, implementation, testing, and operations covering the functionality unique to that Phase. The functionality for each project Phase is described in detail in these specifications and summarized in the corresponding sub-sections below. The image below provides a high-level overview of the delivery schedule for the three, overlapping Phases.

AGY-21-008-IT 2 | Page APPENDIX 1

High-Level Phased Schedule

Description 2021 2022 2023 2024 2025 2026 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 PHASE 1 "MVP" Phase 1 Design Reviews /Development Phase 1 Testing/Implementation Phase 1 Standard Warranty (minimum 1yr.) PHASE 2 "Open Payments and Exercised Options" Phase 2 Design Reviews/Development Phase 2 Testing/Implementation** Phase 2 Standard Warranty (minimum 1yr.)** PHASE 3 "Full Implementation" Phase 3 Design Reviews/Development Phase 3 Testing

Stars denote the start of operation for each Phase

**If the TVM option is not exercised the Testing/Implementation task will be shortened to start at the end of Design/Development and the Warranty task will be completely removed (see the Phase 2 timeline for more details)

Also, note that Warranty is no included for Phase 3 as no hardware is expected to be delivered

AGY-21-008-IT 3 | Page

APPENDIX 1

1.2.1.1 Phase 1 MVP

Phase 1 “MVP” will develop and deploy the following core system(s), equipment, and functions:

• Account-based back-office and all software sub-components • Bus Validators • Bus Operator Displays • CAD/AVL Integration • Mobile Data Router Integration • Platform Validators • Faregates • Rail Station Agent Consoles • Customer Service Terminals • Fare Capping • Consumer Website • IVR • Mobile Fare Inspection Devices • Test Lab • Test Environments Phase 1 will support the deployment of the new bus and rail fare collection equipment along with the core back-office systems into the production environment and will include public users with real money, both cash and payment cards. Phase 1 design reviews will include conceptual, preliminary, and final designs specific to the MVP solution. Following final design approval, the manufacturing of bus and rail components may begin, which will initiate a multi-stage testing program for the back-office systems and the bus and rail equipment (see Section 12). Following the completion of factory and integration testing, a successful pilot will commence to verify that the system meets performance requirements in advance of the Final Acceptance for the project.

Phase 1 Pilot acceptance will designate the start of revenue service for the bus and rail systems, and the start of the system operations Phase. Equipment warranty terms will last at least one (1) year from the start of revenue service. The start of revenue service and system operations will also designate the Software Maintenance Agreement (SMA) and back-office operations agreement related to Phase 1. Throughout the operations Phase, the back-office will be operated by the SI under the back-office operations agreement described in section 15.

Description 2021 2022 2023 2024 2025 2026 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 PHASE 1 "MVP Phase 1 Design Reviews/Development Phase 1 Testing Factory Testing Integration Testing Acceptance Testing Phase 1 Implementation Production/Manufacturing Installation Phase 1 Standard Warranty (minimum 1yr.)

AGY-21-008-IT 4 | Page

APPENDIX 1

1.2.1.2 Phase 2 Open Payments and Exercised Options

Phase 2 “Open Payments and Exercised Options” will develop and deploy the following equipment and features to the existing Phase 1 functionality:

• Open Payments • TVMs* If option exercised • Contactless Mobile Application* If option exercised Phase 2 “Open Payments and Exercised Options” will enhance the system deployed in Phase 1, adding open payment functionality and any exercised options. Such as the deployment of new TVMs and an account management and contactless (e.g., virtual card) application. Phase 2 will include conceptual, preliminary, and final design reviews and documentation to update the submittals provided from Phase 1 with any updated or new content. TVM manufacturing and the development of the mobile application may begin after final design acceptance by the agency. Multi-stage testing including Factory Acceptance, Integration, and, Pilot/Beta testing for all components and functions delivered as part of Phase 2 (see Section 12) will be performed. Each testing stage may include Regression testing for select Phase 1 items that may have been impacted due to the Phase 2 delivery. The Phase 2 Pilot/Beta acceptance will verify that the Phase 1 and Phase 2 system meet all performance requirements.

Pilot/Beta acceptance for Phase 2 will designate the start of revenue service for the TVMs and the contactless mobile application. This will also include the ability for customers with contactless bank cards to tap and pay on equipment delivered with Phase 1. Equipment delivered for Phase 2 (e.g., TVMs) warranty terms will last at least one (1) year after the final TVM has been installed and approved by the agency. The Phase 2 Software Maintenance Agreement (SMA) will go into effect after successfully completing Phase 2 Pilot testing. Phase 2 SMA will enhance the Phase 1 SMA to include open payments and any exercised option delivered as part of Phase 2. The mobile application will be operated by the SI under the SMA and back-office operations agreements.

Description 2021 2022 2023 2024 2025 2026 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 PHASE 2 "Open payments and Exercised Options" Phase 2 Design Reviews/Development Phase 2 Testing Factory Testing* Integration Testing Acceptance Testing Phase 2 Implementation* Production/Manufacturing Installation Phase 2 Standard Warranty (minimum 1yr.)*

*Task would be omitted if the TVM option is not exercised. Testing would then start with Integration Testing following the completion of Design/Development. Implementation and Warranty tasks would be omitted as well.

AGY-21-008-IT 5 | Page

APPENDIX 1

1.2.1.3 Phase 3 Full Implementation

Phase 3 “Full Implementation” will deliver all remaining components of the system to enhance the equipment and features deployed during Phase 1 and Phase 2. This includes:

• Institutional Website An institutional website will be developed and deployed to support various employer and social service programs. Design reviews and testing for Phase 3 may overlap with Phase 2, but will likely include separate conceptual, preliminary, and final designs from previous Phases. The SI is welcome to suggest a timeframe that would consolidate the submission of the two Phases’ design documentation, however, the Phase 2 schedule must prevail. Following final design approval, the development of the institutional website, and a multi-stage testing program for the website will be conducted. Testing for Phase 3 may also require regression testing for Phase 1 and Phase 2 items that may have been impacted to accommodate the Phase 3 delivery. Testing for all components and functions delivered as part of Phase 3 (see Section 12) will be performed. Following the completion of Factory and Integration testing, and a successful Pilot, a Final System Acceptance Test will verify that the entire system (including all elements delivered in Phase 1 and Phase 2) meets all performance requirements in advance of the Final Acceptance for the project.

Approval of Final System Acceptance will designate the start of revenue service for the institutional website. Any equipment or hardware components delivered for the institutional website will have a warranty term of at least one (1) year from the completion of the last equipment installation, however, it is not anticipated that new hardware components will be needed to deploy the institutional website and an equipment warranty may not be needed. The Phase 3 SMA and back-office operations agreements will provide the necessary coverage. The start of revenue service and system operations will also designate the Software Maintenance Agreement (SMA) and back-office operations agreement related to Phase. Throughout the operations Phase, the Institutional Website will be operated by the SI under the back-office operations agreement.

Description 2021 2022 2023 2024 2025 2026 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 PHASE 3 "Full Implementation" Phase 3 Design Reviews/Development Phase 3 Testing Integration Testing Acceptance Testing

Please note Factory Testing and Implementation tasks were removed from this table due to no equipment being delivered in this Phase.

1.2.2 Transition Approach

The project timeline described in section 1.2.1: Phased Delivery Approach, requires a strategic transition plan that accounts for the Phased delivery and minimizes impact to the customer. Therefore, the MTA anticipates operating the legacy CharmCard and the new, SI-provided AFC solution in parallel during each Phase. The SI will work collaboratively with the agency to detail a transition plan that gradually limits the functions for the legacy system while increasing the features and functionality of the new system.

AGY-21-008-IT 6 | Page

APPENDIX 1

At a high-level, the MTA will begin limiting the ability for customers to purchase legacy fare media shortly following the start of operations for Phase 1, delivery of the core system. At that time, only new system fare media will be sold at transit stores. When the new TVMs begin operation in Phase 2, the MTA will limit customer options for reloading legacy media, allowing the SI to decommission and dispose of legacy TVMs as they install the new SI-provided TVMs (if the option is exercised). However, acceptance of the legacy cards will continue system-wide during a “spend down” period allowing customers to use any remaining value and products loaded to their account. Currently, MTA light rail station TVMs also serve as legacy validators. The SI will work closely with the MTA to identify a plan that allows the SI to replace light rail TVMs during Phase 2 while still allowing customers to tap legacy CharmCards.

Shortly following Pilot acceptance for Phase 2, the MTA will stop accepting all legacy CharmCards, effectively sunsetting all legacy fare collection equipment and systems. The implementation of this process is tied to the implementation of Phases 1 and 2 as summarized in the table below. The timing between the spend down, decommissioning/disposing of remaining legacy faregates and the installation of the remaining SI-provided faregates will be closely coordinated between the MTA and the SI.

Action Stage Limit legacy CharmCard (fare media) issuance Coordinated with Phase 1 Pilot Limit legacy CharmCard reloading Coordinated with TVM installs at rail stations for Phase 2: Open Payments and Exercised Options No longer accept Legacy CharmCards on Coordinated with the completion of TVM system installs and start of revenue service for Phase 2: Open Payments and Exercised Options

1.2.3 Operations Approach

The SI will provide a warranty that covers the components and modifications of the core system delivered at each applicable Phase for a minimum of one (1) year. A twelve (12) year software maintenance agreement (SMA) and back-office operations agreement will be provided for Phase 1, the core back-office systems, and will remain in effect for the duration of the contract. Coverage at each Phase will meet the requirements in section 15: System Operations Requirements. The image below represents a generic staggering of the implementation of the warranty, SMA, and back-office operations agreements. The image shows the required minimum one-year warranty duration for illustration purposes.

AGY-21-008-IT 7 | Page

APPENDIX 1

The Phase 2 and Phase 3 SMA and back-office operations agreements will be added to the core (Phase 1) agreements and will only include the new components delivered with each Phase. The durations for the Phase’s agreements will correlate to the remaining duration of the core Phase 1 SMA and back- office operating agreements. The incremental update for each Phase to the core (e.g., Phase 1) SMA and back-office agreement is represented by the Phase 2 and 3 SMA and back-office operations agreement items in the bid sheet. The SI will provide the Phase 2 and Phase 3 incremental increase that will be added to the Phase 1 SMA and back-office operation agreements in 2023 dollars. An escalation factor is included to provide the MTA and SI with implementation flexibility that is independent of the high-level schedule provided in section 1.2.1: Phased Delivery Approach.

Faregates present a small anomaly in that only a subset of the faregates will be installed during Phase 1. The MTA anticipates that the remaining faregates will be installed during Phase 2 as the legacy system is cutover to the new system. This would mean that the system warranties for the uninstalled faregates would start in Phase 2.

1.3 Technical Specification Format The SI shall provide services as defined in these Technical Specifications and shall exercise independent and professional judgment in performing the services under this Agreement. Services provided by the SI will comply with all applicable MTA manuals, procedures, and memorandums in effect at the time of execution of the Agreement unless otherwise directed in writing by the MTA. Such manuals, procedures, and memorandums will be provided by the MTA.

The requirements in these specifications are functional and intended to describe the behavior or performance of the system, with details specified, as necessary. The requirements are organized in a table format, and divided into the following sections:

• Introduction: Project background and description of the current system • Future System Overview: Brief description of the new AFC system • Project Management: Requirements for project management plan and processes • Common Design Requirements: General hardware and software requirements that apply to the entire system • System Architecture: Core system design principles and requirements • Fare Structure: Fare policies, pricing, products, and distribution that the system needs to support • Equipment: Requirements for SI-provided fare distribution, payment, and inspection devices

AGY-21-008-IT 8 | Page

APPENDIX 1

• Back-office: Requirements for SI-provided central back-office system and support systems • Customer Applications: Requirements for SI-provided websites, mobile application, and Interactive Voice Response system • Legacy System Integration: Requirements for the integration of the new AFC system with existing MTA systems • Design Reviews: Requirements for the execution of the Design Phase of the project • Testing: Requirements for detailed testing of the system, broken down into Phases • Installation: Requirements for site preparation and system installation • Training: Requirements for staff training and associated materials • System Operations: Requirements for all system operating responsibilities following Final Acceptance • Performance Measurement: Description of performance requirements to be measured during acceptance testing and throughout system operations Each requirement is individually numbered for easy identification and organization. Furthermore, each requirement has a corresponding Contract Data Requirements List (CDRL) number that identifies which SI-delivered document should contain the requested information or describe how the provided system will meet the associated requirement. A single CDRL may encompass many requirements. A CDRL table is included at the end of each major section that summarizes the CDRLs to be provided and the design Phases in which they must be delivered. 2. Future System Overview With nearly all the MTA’s existing fare collection system components nearing or at end-of-life, the need for a full system replacement is imminent and provides an opportunity to implement a modern fare collection system that includes policy and system customer enhancements.

The core objectives of this project are to deploy a next-generation, multimodal fare collection system that drives customer adoption, reduces fare collection costs and , increases revenue, and improves existing fare collection operations. The existing in-scope public transit system consists of fixed- route bus service, Metro subway, light rail, and service. A potential future expansion of the new fare collection system may include MARC and Commuter Bus. Today, operators accept a wide variety of 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 the MTA’s 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 between all modes and reduce, or eliminate, visually validated fares to improve operations.

At a minimum, the MTA expects their new electronic fare collection system’s characteristics to include, but not limited to:

• Account-based • Designed and implemented using an open architecture (encompassing all fare media, applications, and devices deployed within the system and include all fare media formats,

AGY-21-008-IT 9 | Page

APPENDIX 1

transaction formats, security protocols, and communications necessary to support critical system functions) • Support fare policy features for the MTA and their regional partners, including flat fares, distance-based fares, zone-based fares, time-based transfers, and fare capping. • Leverage real-time fare calculation, and real-time communication interfaces that support: o Immediate use of fare value loaded through all fare distribution channels o Fare payment validation onboard and at rail stations (with real-time fare calculation and customer information) o Real-time distribution of hotlists to minimize risk in offline scenarios o Real-time monitoring of device and system performance • Support both closed-loop and open-loop payment options • Be PCI-compliant and support other required physical and logical security measures • Support both agency-issued and third party-issued fare media • Integrate with existing systems and programs (farebox, CAD/AVL, SmartBenefits, etc.) • Provide an SI managed cloud-hosted high availability (e.g., active-active, multi-site, load- balanced) back-office solution, which uses Commercial-Off-The-Shelf (COTS) software where appropriate, and includes the following components: o COTS Customer Relationship Management (CRM) system o Tariff management o System Monitoring Application (SMA) o COTS Financial Management System (FMS) o Data Warehouse o Web-based reporting tool o Fare media inventory system o Test systems • Provide an IVR solution that will interface with the agency’s existing call center equipment • Provide SI managed and cloud-hosted and websites for both individual and institutional customers • Provide a fare inspection solution that supports the inspection of both closed-loop and open- loop payments • Provide all fare equipment needed to operate the new system, including but not limited to: o Rail Faregates (Metro) o Rail Station Operator Consoles o Stand-Alone Validators o Fare Inspection Devices o Bus Operator Display Units o Bus Validators o Ticket Vending Machines (Option) o Customer Service Terminal/Point of Sales (POS) Devices o Test Lab o Initial batch of extended-use media o Initial batch of limited-use media For the MTA’s Future Fare System (FFS) policy, technology, and operations vision, please reference the ConOps.

AGY-21-008-IT 10 | Page

APPENDIX 1

3. Project Management Requirements 3.1 Project Manager and Lead Engineer Assigned Req # Requirement CDRL

3.1-1 The SI shall designate responsible and experienced individuals to serve as CDRL 3-1 the PM and Lead Engineer for the entire term of the contract. Both the PM and Lead Engineer will maintain close collaboration throughout the project lifecycle. 3.1-2 The PM shall be fluent in English and possess at least five (5) years of CDRL 3-1 demonstrable, recent, and extensive experience managing electronic payment system projects of similar size and scope as the Baltimore project, and that includes multiple points of integration with third-party systems and devices. The PM will have a project management certification, such as Project Management Professional (PMP) or equivalent. 3.1-3 The Lead Engineer shall be fluent in English and possess at least five (5) CDRL 3-1 years demonstrable, recent, and extensive experience serving in a lead technical role on electronic payment system projects of similar size and scope as the Baltimore project, and that include multiple points of integration with third-party systems and devices. 3.1-4 The designated PM and Lead Engineer must be two different individuals, CDRL 3-1 both shall be subject to agency review and approval. 3.1-5 The Lead Engineer shall be located in the Baltimore area to provide daily CDRL 3-1 onsite support beginning no later than 30 calendar days following Notice to Proceed (NTP) and continuing through Final Acceptance. 3.1-6 The PM shall be located in Baltimore and/or be onsite no less than two (2) CDRL 3-1 weeks per month to provide daily onsite management support Notice-to- proceed (NTP) and continuing through Final Acceptance. 3.1-7 SI staff consistency is important and key SI staff, including the PM and Lead CDRL 3-1 Engineer, shall be assigned to this project throughout its duration unless contractually released. 3.1-8 Removal or replacement of the PM or Lead Engineer by the SI will require CDRL 3-1 prior approval by the agency. The SI’s request to remove or replace the PM or Lead Engineer must be made in writing and include the reason for removal or replacement. 3.1-9 In the event that any key SI staff (Project Manager, Lead Engineer, Safety CDRL 3-1 Engineer, or Quality Engineer) is found unacceptable by the agency, or needs to be replaced for any reason, the SI shall provide a replacement candidate within 30 calendar days. Replacement candidates will be subject to agency approval

AGY-21-008-IT 11 | Page

APPENDIX 1

3.2 Project Meetings The SI shall participate in regular project coordination and status meetings throughout the life of the project. Meeting topics may range from general project status updates to key discussions and decision- making.

3.2.1 Project Kickoff Meeting

The purpose of the project kickoff meeting is to allow all parties to understand the scope and schedule of the project and to confirm expectations and responsibilities.

Assigned Req # Requirement CDRL 3.2.1-1 No later than 21 calendar days following NTP, the SI shall participate in a CDRL 3-1 project kickoff meeting to be held at the agency’s office. A virtual meeting may be used in lieu of an in-person meeting at the discretion of the MTA. Zoom is not an allowable technology for any teleconference meetings held with the agency. 3.2.2-1 After the initial project kickoff meeting, the SI should hold additional CDRL 3-1 project Phase kickoff meetings for each subsequent project Phase (Phase 2 and Phase 3) no later than 21 calendar days following the notice to proceed for each of the applicable project Phases. These meetings are to be held at the agency’s office. A virtual meeting may be used in lieu of an in-person meeting at the discretion of the MTA. Zoom is not an allowable technology for any teleconference meetings held with the agency. 3.2.3-2 The SI shall work with the agency to assemble an agenda for the meeting CDRL 3-1 that covers the following topics at a minimum: • Introductions of key agency and SI points of contact • Review of project roles and responsibilities • Review of SI’s scope of work • Presentation of the draft project baseline schedule

3.2.2 Progress Review Meetings

Assigned Req # Requirement CDRL 3.2.2-1 Progress reviews will be held at agency facilities on a monthly basis, at a CDRL 3-1 minimum. Live video or teleconference meetings on a more frequent basis will occur as required. 3.2.2-2 The SI shall prepare and submit an agenda at least five (5) business days CDRL 3-1 prior to all progress review meetings for review and approval by the agency.

AGY-21-008-IT 12 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.2.2-3 The topics to be discussed and reviewed will include, but are not limited CDRL 3-1 to: • Minutes of the prior progress review meeting • Updated master program schedule • Updated CDRLs • Updated CDRL submittal list and schedule • Updated action item log • Updated issues list • Progress since the last meeting • Issues arising since the last meeting, including design status, fabrication problems, product delivery problems, schedule slippages, and problems arising from proposed changes and other circumstances which affect the progress of the work • Sequence of critical work and schedule of manufacturing using the master program schedule and monthly progress reports • Engineering, manufacturing, and quality control summary • Contract budget, milestone payment, and invoice status and schedule • Any needed corrective measures to maintain the project schedule • Assessment, review, and update of the safety assurance program • Assessment, review, and update of the risk management plan and risk register • Any other issues related to the project The discussion topics may vary depending on project needs and priorities. The agency may introduce new topics not listed here. 3.2.2-4 The SI shall prepare and submit to the agency a monthly progress report CDRL 3-1 that addresses the following topics and serves as the agenda for the progress review meeting: • Review and status of actions from previous meetings • Updated master program schedule showing progress against the baseline schedule • Status of all current key activities, upcoming activities, issues, and corrective actions • Update of all identified project risks and the actions taken towards mitigating those risks, and an updated risk register • Updated CDRL list indicating the current status of each CDRL The progress report may vary depending on project needs and priorities. The agency may request other items not listed here. 3.2.2-5 The SI shall be responsible for documenting minutes for all monthly CDRL 3-1 progress review meetings and submitting those minutes for agency review within three (3) business days following each meeting.

AGY-21-008-IT 13 | Page

APPENDIX 1

3.2.3 Weekly Project Coordination Meetings

The purpose of weekly project coordination meetings is to provide a standing forum for items and topics to be discussed, and decisions that need to be made which cannot be held until monthly progress reviews. Other ad-hoc meetings may also be necessary to facilitate project delivery.

Assigned Req # Requirement CDRL 3.2.3-1 The SI shall prepare and submit an agenda and project status report at CDRL 3-1 least two (2) business days prior to all weekly coordination meetings for review and approval by the agency. The status report must include a timeline of activities, and deliverables completed since the last meeting, deliverables that will be completed in the next calendar month, and a detailed explanation and mitigations for any deliverables that are delayed. 3.2.3-2 The SI’s Lead Engineer will be present during all weekly coordination CDRL 3-1 meetings. The SI’s PM and other designated staff may participate remotely in weekly project coordination meetings as required. 3.2.3-3 The SI’s Lead Engineer, PM, and other designated staff shall participate as CDRL 3-1 required in other ad-hoc meetings to facilitate project coordination and decision making. 3.2.3-4 The SI shall be responsible for documenting minutes for each weekly CDRL 3-1 coordination and ad-hoc meeting and submitting those minutes for agency review within three (3) business days following each meeting.

3.3 Project Management Plan The SI shall submit a comprehensive project management plan that details project organization, including schedule, risk, safety, quality, and change management, and all other aspects of the project specified in this section.

3.3.1 General Requirements

Req # Requirement Assigned CDRL 3.3.1-1 A Project Management Plan (PMP) will be submitted CDRL 3-1 no later than 21 calendar days following NTP and will be subject to the agency’s review and approval. This plan will be updated to incorporate each Phase’s unique requirements no later than 21 calendar days following the notice to proceed for the applicable Phase.

AGY-21-008-IT 14 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 3.3.1-2 The PMP will include but is not limited to the following CDRL 3-1 elements: • Organization chart identifying key project personnel and contact information • Master program schedule, identifying key program milestones and activities • Schedule for all project design and manufacturing elements that require agency approval • Project meeting schedule • Methodology to control program schedule, scope, cost, and risk • Project risk management processes and risk register, including identified project risks and actions required to mitigate them • Transition and change management processes and procedures • Safety processes and procedures • Quality assurance processes and procedures to ensure that the requirements of the contract are being met • Subcontractor management and communications • Document and Master Issues List (MIL) control processes and procedures, including version and traceability controls • Configuration management processes and procedures for all submittals and subsequent revisions Additional elements of a PMP may be proposed or requested, but the PMP will meet the requirements in this section at a minimum.

3.3.2 Master Program Schedule

Assigned Req # Requirement CDRL 3.3.2-1 The master program schedule will identify all program activities, CDRL 3-1 deliverables, and key milestones (including those owned by the MTA and third-party vendors), with expected and actual completion dates. 3.3.2-2 The master program schedule will be cost-loaded and developed using CDRL 3-1 Microsoft Project.

AGY-21-008-IT 15 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.3.2-3 The SI will work with the MTA to determine acceptable delivery/review CDRL 3-1 timeframes for all MTA owned deliverables/activities within the master program schedule. All proposed times will be subject to review and approval by the agency. 3.3.2-4 The listing of activities in the master program schedule will be insufficient CDRL 3-1 granularity and detail to identify all predecessor and dependent activities, including the activities of other entities that impact the SI’s delivery of the system. 3.3.2-5 The master program schedule approved by the agency will become the CDRL 3-1 baseline schedule, against which subsequent schedule updates will show performance. 3.3.2-6 The master program schedule will designate intermediate program CDRL 3-1 milestones and target dates to track ongoing performance. 3.3.2-7 The SI shall update the master program schedule on a monthly or more CDRL 3-1 frequent basis and submit the updated schedules for agency review and approval.

3.3.3 Scope Management

Assigned Req # Requirement CDRL 3.3.3-1 As part of the PMP, the SI will provide a scope management plan that will CDRL 3-1 guide how project scope will be defined, documented, verified, managed, and controlled by the project management team. This plan will include: • Scope definition: A process to prepare detailed project scope statements based on the preliminary project scope • Creation of a Work Breakdown Structure (WBS): A process that establishes how the WBS will be maintained and approved • Scope Verification: How formal verification and acceptance of the completed project deliverables will be obtained • Scope Control: A process to control changes to project scope directly linked to integrated change control (see Section 3.4.1)

3.3.4 Cost Management

Assigned Req # Requirement CDRL 3.3.4-1 As part of the PMP, the SI will include a cost management plan that clearly CDRL 3-1 defines how the costs of the project will be managed throughout the project lifecycle.

AGY-21-008-IT 16 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.3.4-2 The cost management plan will set the format and standards by which the CDRL 3-1 project costs are measured, reported, and controlled. It will identify who is responsible for managing costs and who has the authority to approve changes to the project or its budget. 3.3.4-3 The cost management plan will also specify how cost performance is CDRL 3-1 quantitatively measured and detail cost report formats, frequency, and to whom they are presented.

3.3.5 Risk Management

The PMP will include a risk management plan that describes the processes that the SI shall follow to identify and manage potential risks that threaten to increase project costs, lengthen the project schedule, or compromise project performance.

Assigned Req # Requirement CDRL 3.3.5-1 As part of the PMP, the SI will include a risk management plan that will CDRL 3-1 address risk planning, risk identification, risk analysis, and risk control, and will be reviewed and updated on a monthly basis, or as requested by the agency. 3.3.5-2 The processes that the SI shall follow for mitigating risk from the project CDRL 3-1 will be identified, along with the processes for identifying, evaluating, and reporting (i.e., to the agency) future risks. 3.3.5-3 The processes for developing and implementing corrective action plans to CDRL 3-1 lessen the impact an unexpected event has on the project will be identified, as will the process for returning the project to steady-state. 3.3.5-4 The SI shall maintain a comprehensive program risk register comprised of CDRL 3-1 data fields including, but not limited to: Risk Title, Risk Statement, Risk Owner, Risk Status, Risk Consequence, Probability Score, Impact Score, Initial Risk Rating, Current Risk Rating, Mitigation Approach, Mitigation Status, and Due Date. Regular updates to the risk register will occur as part of scheduled project meetings.

3.3.6 Transition and Change Management

Assigned Req # Requirement CDRL 3.3.6-1 The SI shall include a transition and change management section as part of CDRL 3-1 the PMP for review and approval by the agency. 3.3.6-2 The SI shall detail a transition plan from current operations to the new CDRL 3-1 system for the agency, as well as for external stakeholders and the public.

AGY-21-008-IT 17 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.3.6-3 The transition and change management section will document critical CDRL 3-1 changes to program stakeholders, as well as change management and risk mitigation procedures. 3.3.6-4 The transition management section will document the transition process, CDRL 3-1 including any additional, temporary, or special equipment and/or staffing requirements.

3.3.7 Safety Assurance

Assigned Req # Requirement CDRL 3.3.7-1 The SI shall include a safety assurance section as part of the PMP that CDRL 3-1 identifies all safety processes and procedures for review and approval by the agency. 3.3.7-2 The safety assurance section will identify and document safety risks, CDRL 3-1 owners, and mitigation plans throughout the project, and will be reviewed and updated on a monthly basis, or as requested by the agency. 3.3.7-3 The SI shall designate an experienced Safety Engineer to be responsible for CDRL 3-1 safety assurance over the entire term of the contract. The designated Safety Engineer will be subject to agency approval. 3.3.7-4 The Safety Engineer shall document, review, and approve all system safety CDRL 3-1 analyses to ensure that all hazards are adequately identified, and their impact is eliminated or controlled. 3.3.7-5 The Safety Engineer will verify that all SI staff is trained in agency-required CDRL 3-1 safety policies and procedures and that those procedures are followed to the satisfaction of the agency.

3.3.8 Quality Assurance and Control

As part of the PMP, the SI shall establish, implement, and maintain an effective Quality Assurance (QA) program to manage, control, and document the work performed, and ensure that it complies with the requirements of the contract.

Assigned Req # Requirement CDRL 3.3.8-1 As part of the project management plan, the SI shall establish, implement, CDRL 3-1 and maintain a QA program governing the work performed by the SI, as well as all subcontractors.

AGY-21-008-IT 18 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.3.8-2 The QA program will describe the overall quality policies and CDRL 3-1 responsibilities that will ensure the quality of work performed for each Phase of the project. 3.3.8-3 The QA program will contain a collection of all forms to be used for the CDRL 3-1 documentation of quality control activities, which ensure compliance of materials, processes, personnel, and products with the applicable specifications. 3.3.8-4 The QA program will include written descriptions of quality assurance and CDRL 3-1 control policies and procedures, including the procedures that the SI shall follow to ensure that controls and detailed documentation are maintained throughout software development and configuration changes. 3.3.8-5 The QA program will at minimum include procedures for the following CDRL 3-1 activities: • Surveillance overall work, including by subcontractors, to ensure compliance with all contract requirements • Verification of compliance, including audit; discrepancy identification, notification, and control; and corrective action • Evaluation and assessment of subcontractors’ QA programs • Provision of technical documentation, drawings, specifications, handbooks, manuals, data flow diagrams, and other technical publications for the new system and supplied equipment • Design control and version management for changes to documents, drawings, data, and specifications • System software development (consistent with IEEE Standard 730 or equivalent ISO 9001 standards for software quality assurance) • Equipment handling, inventory, storage, and delivery • Factory inspection and testing • System integration testing • Installation testing • Defect management, including explanations, on how defects will be identified, categorized, reported on, tracked, approved/rejected, and closed out • Calibration/verification of measuring equipment • System configuration management • Qualification and certification for all personnel performing work under the contract 3.3.8-6 The SI shall use the defined quality assurance procedures as an integral CDRL 3-1 part of its design development and review process. 3.3.8-7 The SI shall identify design variances from contract requirements and CDRL 3-1 document and report variances to the agency before equipment procurement, fabrication, or installation.

AGY-21-008-IT 19 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.3.8-8 The QA program will define methods of designing for, achieving, and CDRL 3-1 maintaining quality. If damage, defect, error, or inaccuracy is found in any provided equipment or work, the agency shall have the right to reject or require corrective action to bring the work into compliance with the contract requirements. The SI shall bear all costs incurred in correcting rejected equipment or work. 3.3.8-9 The SI shall designate an experienced Quality Engineer responsible for CDRL 3-1 quality assurance over the entire term of the contract. The designated Quality Engineer will be subject to agency approval. 3.3.8-10 The SI shall not commence the performance of any design or CDRL 3-1 manufacturing work until the agency has approved the QA program.

3.3.9 Subcontractor Management

Assigned Req # Requirement CDRL 3.3.9-1 The program management plan will include a subcontractor management CDRL 3-1 section outlining all activities to be performed by subcontractors, and procedures for organizing and communicating with subcontractors. 3.3.9-2 The SI shall provide all necessary plans, specifications, and instructions to CDRL 3-1 its subcontractors and suppliers to enable them to properly perform their work. 3.3.9-3 The SI shall ensure that subcontractors or suppliers are informed of all CDRL 3-1 applicable requirements in this specification and that appropriate engineering and project management tools are utilized for coordination and communication. 3.3.9-4 The SI shall have all subcontractors and suppliers available when required CDRL 3-1 for meetings, testing, and resolution of design deficiencies, production problems, and similar situations. During all Phases of the project, the agency will have access to all subcontractors. 3.3.9-5 The subcontractor management section will include activities to be CDRL 3-1 performed by Disadvantaged Business Enterprises (DBEs), and other recognized subcontractor categories, as defined by the U.S. Department of Transportation. It will identify the contract revenues to be allocated to such firms, and the means of encouraging, tracking, and controlling DBE participation throughout the project. 3.3.9-6 The subcontractor management section will include procedures and CDRL 3-1 processes to be followed for the replacement of any subcontractors throughout the duration of the contract.

AGY-21-008-IT 20 | Page

APPENDIX 1

3.3.10 Communications Management and Document Control

Assigned Req # Requirement CDRL 3.3.10-1 The PMP will outline who is responsible to deliver and respond to various CDRL 3-1 communications, who receives which communications, and how and when communications will be delivered. 3.3.10-2 The SI will ensure that stakeholder communication needs are understood. CDRL 3-1 This includes determining what communication products will be exchanged throughout the project (e.g., status updates, meeting minutes, reports, deliverables, etc.). 3.3.10-3 The SI shall store and maintain all program documents, manuals, meeting CDRL 3-1 materials, submittals, and correspondence in an editable electronic form with an agency-provided document control system, ProjectWise, to provide robust and secure document control, as per the terms of the contract. ProjectWise will be set up with appropriate access configuration within 30 days of NTP. 3.3.10-4 Program documents will be categorized and numbered within the CDRL 3-1 document control system according to an established document control scheme.

3.3.11 Master Issues List

Assigned Req # Requirement CDRL 3.3.11-1 The SI shall maintain an electronic Master Issues List (MIL) for the ongoing CDRL 3-1 tracking and management of project issues and action items. 3.3.11-2 MIL items will be identified and updated at design review meetings, weekly CDRL 3-1 project coordination meetings, monthly progress review meetings, and on an ad-hoc basis. 3.3.11-3 The MIL should track the following attributes for each entry at a minimum: CDRL 3-1 • Item number • Date opened • Requesting party • Description • Required action • Assigned party • Status (open/closed/in progress/deferred/etc.) • Date closed Other attributes may be required by the agency. No action items will be assigned to the agency without the agency’s knowledge and consent.

AGY-21-008-IT 21 | Page

APPENDIX 1

3.4 Change Control Throughout the contract, the SI shall implement and maintain a change control process that encompasses the entire system, including all SI and subcontractor, supplied equipment, and software. To maximize the efficiency of the design process, the SI and agency will mutually agree upon a date for design freeze, after which the change control process will go into effect. The date will be chosen to reflect a point in time when the design of the system is substantially complete.

The SI and subcontractors will not be required to submit every in-process change to the agency for review and approval prior to the design freeze date. This does not, however, relieve the SI and subcontractors from meeting any other submittal requirements in these specifications.

3.4.1 Change Control Process

Assigned Req # Requirement CDRL 3.4.1-1 The SI’s change control process and procedures will be documented in a CDRL 3-2 change control plan and will include provisions for agency review and approval of all changes. 3.4.1-2 Hardware and software changes, and updates to approved documents, CDRL 3-2 drawings, and data, will be controlled through Engineering Change Requests (ECRs). 3.4.1-3 ECRs will include documentation describing the reasons for and effects of CDRL 3-2 the change and will be submitted to the agency for review and approval. 3.4.1-4 Accompanying each ECR for proposed software changes will be CDRL 3-2 comprehensive software release notes containing the following information at a minimum: • A description of the change • Affected equipment and modules • List of the software modules updated by the release, including file names, version numbers, sizes, and checksums • List of all defects corrected, including references to agency correspondence where applicable • List of all new features included • List of all features to be tested • Copies of all applicable test procedures • Complete installation instructions, including steps to verify proper installation and to uninstall the updates, if necessary • Complete build instructions • List of software tools used • Back-out procedures if the software fails to update Other software release note elements may be requested by the agency.

AGY-21-008-IT 22 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.4.1-5 Upon approval of the ECR, the SI will install the proposed software change CDRL 3-2 in the agency test facility to undergo verification of new features and fixes, as well as regression testing. Upon successful verification, the agency shall authorize the SI to deploy the software change according to an approved deployment plan. 3.4.1-6 Following equipment installation, approved ECRs will generate Field CDRL 3-2 Modification Instructions (FMI) that describe the process to update installed equipment and systems. FMIs will require agency review and approval prior to implementation. 3.4.1-7 An FMI will include the following at a minimum: CDRL 3-2 • Cover sheet o Unique FMI number o Title of FMI o Equipment/systems affected, including spare parts (quantity, model, serial number) o Implementation location o Signoff provisions for implementation • Procedure o Step-by-step implementation process o Inspection procedure o Testing procedure • Supporting documentation o Underlying ECR(s) o Affected documents and drawings, including any change to manuals and catalogs The SI shall be responsible for all FMIs, even if the FMI is not performed directly by the SI. The SI will approve subcontractor FMIs before submitting them to the agency. 3.4.1-8 The SI will be responsible for maintaining an engineering change status CDRL 3-2 report that lists all changes, their submittal/approval status, implementation status, and expected/actual completion dates.

3.4.2 Hardware and Software Versioning

Assigned Req # Requirement CDRL 3.4.2-1 Throughout the performance of this Contract, the SI shall adhere to the CDRL 3-2 hardware and software quality and version control procedures submitted and approved as part of the QA program described in Section 3.3.8. The version identifiers for all provided hardware and software will be unique.

AGY-21-008-IT 23 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.4.2-2 After completing an approved hardware update, the SI shall submit an CDRL 3-2 updated listing of the serial numbers and versions of the affected hardware components in an agency approved format. This listing will include the date the revision was applied to each item. 3.4.2-3 Throughout the hardware warranty period (see Section 15.1), the SI shall CDRL 3-2 maintain accurate records of the versions of all serialized components, including all spare parts in inventory and shall track all equipment taken from spares so that it can be replaced by SI.

3.4.3 Component Identification

The SI shall develop and submit for agency review and approval an equipment identification and labeling plan that identifies how the deployed fare system will comply with the requirements in this section.

Assigned Req # Requirement CDRL 3.4.3-1 All equipment will be permanently identified with a manufacturer or CDRL 3-2 supplier name, part number, and serial number. 3.4.3-2 The SI shall assign unique serial numbers to equipment and modules, CDRL 3-2 enabling tracking of components for maintenance, repair, and warranty, and to provide sufficient identification to analyze failures. 3.4.3-3 The serial numbering scheme and format will be submitted for agency CDRL 3-2 review and approval. Where possible, serial numbers for like components will be sequential. 3.4.3-4 Serial numbers will be engraved on metal labels that are riveted in place or CDRL 3-2 attached by another approved permanent method. 3.4.3-5 Labels will be placed in areas where they are likely to avoid wear and CDRL 3-2 fading. The location of the serial number labels will be chosen for readability without disassembly of equipment or components. 3.4.3-6 The visible serial number will match the Electronic Serial Number (ESN) in CDRL 3-2 all instances where an ESN is assigned to a device.

AGY-21-008-IT 24 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 3.4.3-7 At a minimum, the following equipment will have serial numbers applied: CDRL 3-2 • Bus Validators • Driver Displays • Ticket Vending Machines (and all major internal components/modules) (if the option is exercised) • Faregates (and all major internal components/modules) • Station Agency Terminal Equipment • Platform Validators • Customer Service Terminals • Mobile Fare Inspection Devices • Back-office Hardware • Test Environment Devices and Back-office Hardware Within 30 calendar days following each Phase’s Final Design Review (FDR) approval, the SI shall furnish a list of the items that will be serialized for agency review and approval. 3.4.3-8 Serial numbers of all components will be presented to the agency in the CDRL 3-2 form of an MS Excel spreadsheet included with the shipment of all equipment and modules.

3.5 Required Submittals

Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 3-1 Project Management Plan Initial delivery expected at Phase 1 kickoff + 21 Calendar Days, with continuous updates throughout the project. Appropriate section updates are expected 21 calendar days after each subsequent Phases’ kickoff to address the current Phase’s requirements CDRL 3-2 Change Control Plan X X Will be updated for each Phase’s PDR and FDR

AGY-21-008-IT 25 | Page

APPENDIX 1

4. Common Design Requirements 4.1 Service-Proven Design Req # Requirement Assigned CDRL 4.1-1 Software and hardware provided under this Contract will be designed to CDRL 4-1 provide a minimum useful life of 12 years. 4.1-2 The agency prefers a service-proven system design. As service-proven, or CDRL 4-1 derived from a service-proven design, the system design will meet all of the following criteria: • Has been deployed and met system acceptance requirements at a minimum of one (1) transit agency with a gated rail system, an open proof-of-payment system, and vending machines • Has been deployed and met system acceptance at a minimum of one (1) transit agency with a bus vehicle fleet • Has been deployed and successfully integrated frontend equipment with a back-office system at a minimum of one (1) transit agency • Has been deployed and achieved a level of reliability, accuracy, and availability consistent with the performance requirements in these specifications at a minimum of one (1) transit agency 4.1-3 Proposed Fare Payment Validators and associated onboard equipment CDRL 4-1 will be nearly identical in design and construction to a model deployed and in revenue service (i.e., in use and passed system acceptance) at a minimum of one (1) transit agency. 4.1-4 Proposed Ticket Vending Machines (TVMs) will be nearly identical in CDRL 4-1 design and construction to a model deployed and in revenue service (e.g., in use and passed system acceptance) at a minimum of one (1) transit agency. 4.1-5 Proposed Customer Service Terminals (CSTs) will be nearly identical in CDRL 4-1 design and construction to a model deployed and in revenue service (i.e., in use and passed system acceptance) at a minimum of one (1) transit agency. 4.1-6 Proposed mobile fare inspection devices will be nearly identical in design CDRL 4-1 and construction to a model deployed and in revenue service (e.g., in use and passed system acceptance) at a minimum of one (1) transit agency. 4.1-7 To establish a design as service-proven, the SI shall submit specific details CDRL 4-1 of the design’s application history, certified by current users of the equipment.

AGY-21-008-IT 26 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.1-8 The SI may offer, for approval, a design that is largely unchanged from a CDRL 4-1 service-proven design, but which varies slightly in design or manufacture to meet the requirements of these specifications, including newer generations of service-proven equipment. The SI shall show, in detail, what has been changed and why such changes will not adversely affect operation or maintenance in the planned environment.

4.2 Nonproprietary Technology Assigned Req # Requirement CDRL 4.2-1 At the time of delivery, equipment, and all associated components and CDRL 4-1 software will contain no non-standard, prototype, obsolete, or discontinued products. Any hardware or software components that have an end-of-life within this project timeline must include replacement plans to be executed at the SI’s cost. 4.2-2 Software applications and devices will be built using commercial-off-the- CDRL 4-1 shelf (COTS) components where possible, and custom software and hardware modules only if necessary. 4.2-3 The system will be designed using open interface standards for software CDRL 4-1 design, communications protocols, fare media, and other relevant design components. 4.2-4 Smartcard media will be available for competitive purchase from multiple CDRL 4-1 U.S. sources. The SI shall provide the specifications and associated documentation necessary to support the future procurement of smartcard media from third parties that allow for competition. 4.2-5 The system will have a modular design for all relevant components. These CDRL 4-1 modules will support field replacement to return a device to service in minimal time in the event of a failure. The system will also permit upgrades and configuration changes without requiring component replacement or redesign. 4.2-6 All devices, components, parts, modules, assemblies, and subassemblies CDRL 4-1 provided will be fully interchangeable among those of the same type without the need to make adjustments for proper compatibility. 4.2-7 The system will be designed so that incorporating technology upgrades CDRL 4-1 may be done with no or minimal redesign of components, modules, and software, or other work.

AGY-21-008-IT 27 | Page

APPENDIX 1

4.3 Supply and Availability Assigned Req # Requirement CDRL 4.3-1 The SI shall furnish equipment and materials from the manufacturers CDRL 4-1 identified in the SI’s submittals, unless otherwise approved. 4.3-2 If it is found that approved sources do not furnish a uniform product, or if CDRL 4-1 the product from such source proves unacceptable per the requirements in these specifications, the SI shall, at no additional expense to the agency, take any and all steps necessary to furnish acceptable materials. 4.3-3 The SI shall select and supply devices, components, parts, modules, CDRL 4-1 assemblies, and subassemblies, as well as software and other essential elements of the system, based on projected availability and long-term original equipment manufacturer (OEM) support commensurate with the required useful life of the system. 4.3-4 All devices, components, parts, modules, assemblies, and subassemblies CDRL 4-1 will be available for purchase for a minimum of 12 years from Final Acceptance. 4.3-5 If any vital device, component, part, module, assembly, or subassembly, CDRL 4-1 or support for OEM software, is being discontinued or obsoleted by the SI or OEM, the SI shall notify the agency a minimum of 90 calendar days prior to last available date of purchase or support. 4.3-6 The SI shall work with the agency to find or develop a suitable CDRL 4-1 replacement for any device, component, part, module, assembly, subassembly, or software that is obsoleted by the SI or OEM. If the SI chooses to obsolete any SI-provided equipment or software within 12 years from Final Acceptance, all hardware and software development costs necessary to support a replacement will be borne by the SI.

4.4 Materials and Workmanship Assigned Req # Requirement CDRL 4.4-1 All components of the system will be constructed of the highest quality CDRL 4-1 materials suitable for production-level use in the intended environment over the required useful life of the system. The SI shall use only new components conforming to the requirements of these specifications and approved by the agency. This does not preclude the use of recycled materials in the manufacture of new components.

AGY-21-008-IT 28 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 4.4-2 The SI shall be responsible for all materials and workmanship. It is the SI’s CDRL 4-1 responsibility to design, select, and apply all materials necessary to meet the requirements of these specifications. If alternate materials are offered following selection, it is the responsibility of the SI to demonstrate that the alternate materials are equivalent to the proposed materials, and to obtain agency approval for the substitution prior to any implementation. 4.4-3 All system provided equipment will be free from safety hazards and will CDRL 4-1 be designed to comply with relevant Underwriter’s Laboratory (UL) Standards. All interior and exterior surfaces shall be free from sharp edges, protrusions, exposed wires, or other hazards.

4.5 Software Design Principles Assigned Req # Requirement CDRL 4.5-1 The SI shall supply all necessary software applications and shall design CDRL 4-1 and configure all device and back-office software applications for optimal system performance. The SI shall install all software that is necessary for system operation and to successfully meet the operational and performance requirements in these specifications. 4.5-2 System software will incorporate the following design elements at a CDRL 4-1 minimum: • Be developed using a non-proprietary, hardware architecture- independent programming language • Compiled with a commercially available compiler and commented in English • Include provisions for setting and verifying date and time, with automatic adjustments for leap year • Be fully integrated with the operating system to support all required functions of the applications in both a networked and a stand-alone environment • Not utilize or employ hard coding of configuration parameter values, except where expressly permitted • Be fully debugged, documented, and include all approved revisions introduced up to the time of Final Acceptance • Be portable to other software platforms or languages where possible • Utilize object-oriented programming or equivalent programming methodology that encourages software reuse and minimizes development time

AGY-21-008-IT 29 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 4.5-3 System software will incorporate the following controls at a minimum: CDRL 4-1 • Allow for the distribution of software modifications to all system devices from the back-office without field intervention or component replacement • Be fully version-controlled, with the ability to revert to a previous software version or fork • Support audit of activity to show when and what changes were made from version to version • Be designed using best practices that allow for OS and database patches and upgrades to be applied with minimal testing 4.5-4 System software will incorporate the following diagnostic capabilities at a CDRL 4-1 minimum: • Sample all input conditions at rates sufficient to detect and remedy all unsafe or damaging conditions in the shortest possible time • Perform self-diagnostic routines and respond promptly and predictably to detected faults • Respond predictably when powering up or recovering from power interruptions • Permit thorough interrogation of all input, output, and internal conditions by external diagnostic equipment • Provide error codes that contain easily understood explanatory text and include the manner in which the error can be corrected 4.5-5 Software upgrades will be centrally managed and fully tested prior to CDRL 4-1 installation. The system shall be able to roll-back to previous software versions without adversely impacting operations. 4.5-6 All third-party software will be at the latest commercial release at the CDRL 4-1 time of the applicable Phase’s FDR. If a release candidate is pending, the agency will review and approve the version that will be deployed.

4.6 Maintainability and Serviceability Assigned Req # Requirement CDRL 4.6-1 System equipment will provide reliable operation over its design life and CDRL 4-2 will be designed to require minimal scheduled and unscheduled maintenance.

AGY-21-008-IT 30 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 4.6-2 The interior of the system equipment will be designed to allow easy and CDRL 4-2 safe access. Adequate space will be available to insert keys; grasp, lift, and turn internal components; and remove and replace components, connections, and consumables. As appropriate, guides, rails, tracks, handles, and captive fasteners will be provided to facilitate module installation and removal. 4.6-3 Any component or module that must be lifted (except for cash containers CDRL 4-2 when full) will not weigh more than 20 pounds. Any exceptions to this weight limitation will be subject to agency approval. 4.6-4 For ease of service and replacement, all electrical connections between CDRL 4-2 components and subassemblies will be established by means of connectors that allow rapid removal of a component or subassembly. Plug-in connectors will be equipped with strain relief to prevent damage to cables and connectors. 4.6-5 Components requiring frequent adjustment or maintenance will be CDRL 4-2 conveniently located and designed to facilitate access and adjustment utilizing tool-free techniques wherever possible. The replacement of field devices or components will be quick and secure. 4.6-6 Automatic diagnostic test routines (and equipment if necessary) will be CDRL 4-2 included to aid in troubleshooting malfunctions. These test routines will provide the ability to isolate defects down to the LLRU. 4.6-7 All devices will have clear labels and symbols that at a minimum indicate CDRL 4-2 safety warnings, servicing steps, and wiring connections. 4.6-8 No more than one person will be required to perform corrective CDRL 4-2 maintenance on an individual piece of equipment. 4.6-9 The SI shall provide documentation during PDR that defines: CDRL 4-2 • Preventative Maintenance (PM) frequency for all system devices based upon time and transactions • A list of all PM tasks to be performed, including a brief description of the work, and any parts, materials or other components required • Time required to complete each defined PM task • Which PM tasks require tools to complete, and which can be performed as “fingertip maintenance”

AGY-21-008-IT 31 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 4.6-10 The time for entry into a device, removal and replacement of the device CDRL 4-2 or a device module, and restoration of the device to an operating condition will take no longer than the following: • Bus Validator/Driver Display– Seven (7) minutes • TVM – 20 minutes • Faregate – 20 minutes • CST – 15 minutes • RST – Five (5) minutes • Mobile Devices – Five (5) minutes During PDR, the SI shall provide documentation that clearly defines remedial maintenance tasks that can and cannot be completed onsite within these time parameters.

4.7 Operating Environment

4.7.1 Shock and Vibration

Req # Requirement Assigned CDRL 4.7.1-1 Onboard equipment, including bus validators and driver displays, will be CDRL 4-3 designed, built, and installed for the harsh, high shock and vibration operating environment in which the system components will be installed. Operation of the fare collection equipment in this environment will not in any way impair equipment performance throughout the required useful life of the system. 4.7.1-2 All system components will be designed to withstand structure-borne CDRL 4-3 stresses and vibrations caused by the motion of buses and trains, daily customer use, passing of trains or other vehicles, and emergency braking of fully loaded trains. 4.7.1-3 All system components, including all interior-mounted components and CDRL 4-3 assemblies, will resist horizontal shocks of up to 6 g (where “g” is the earth’s gravitational constant, or 9.81 meters per second squared) and up to 1.2 g in the vertical axis for a duration of up to 12 milliseconds (ms) without permanent deformation or failure.

AGY-21-008-IT 32 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.7.1-4 There will be no failure of mounts or decrease in operational CDRL 4-3 performance of any system components under conditions simulated by a sinusoidal sweep vibration test at a sweep rate of one-half octave per minute, from 5 Hz to 200 Hz to 5 Hz, at a peak vibratory acceleration of 0.25 g for a minimum of 50 cycles when applied to each of the three axes and repeated continuously for five (5) complete cycles. If any assembly or component is a source of vibration, measures will be taken to dampen the vibration. Efforts will be taken to critically dampen any resonant frequencies that may exist in the mounted structures. 4.7.1-5 All system components and mounts will be sufficiently constructed to CDRL 4-3 comply with local codes regarding stability of structures and contents in earthquakes, high velocity wind (up to 60 miles per hour), and other natural phenomenon. 4.7.1-6 Onboard equipment, including bus validators, driver displays and mobile CDRL 4-3 fare inspection devices, will pass the following shock and vibration tests: • IEC 60068-2-27 • IEC 60068-2-64 4.7.1-7 Rail equipment, including platform validators, TVMs, rail station operator CDRL 4-3 console, and faregates, will pass the shock and vibration tests specified in the ERTMS/ETCS Environmental Requirements (e.g., EEIG 97s0655).

4.7.2 Climate Conditions

4.7.2.1 Onboard Equipment

Req # Requirement Assigned CDRL 4.7.2.1-1 Onboard equipment, including bus validators, driver displays, and mobile CDRL 4-3 fare inspection devices, will be protected to prevent degradation in performance from exposure to moisture or dust raised by inclement weather or interior cleaning. Operation of the fare collection equipment in this environment will not in any way impair equipment performance throughout the required useful life of the system.

AGY-21-008-IT 33 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.7.2.1-2 The onboard equipment provided by the SI will be able to operate and CDRL 4-3 not suffer any degradation in performance under the following environmental conditions: • Storage temperature: -22° to +150°F • Operating temperature: -15°F to 140°F ambient • Thermal shock: Up to 50 degrees F in 1-hour, non-condensing • Relative humidity: 5-100%, non-condensing • Airborne dust: up to 180 micrograms per cubic meter, with iron and salt particles • Sunlight: direct sunlight, radiation loading of up to 789J/sec/m2 • Inclination: 0° to 20° off vertical • Rainfall: 10 inches over 12 hours • Water/solvents: IEC529 to level IP65 or equivalent • Other operational conditions: water spray, industrial cleaning solvents, and mud on system components from cleaning vehicle floors and walls 4.7.2.1-3 The onboard equipment will be designed to be resistant to liquid ingress CDRL 4-3 caused by driving atomization cleaning, rain, snow, or by splashed water or cleaning chemicals, such as would occur during routine equipment and vehicle cleaning. 4.7.2.1-4 The onboard equipment will be tested and certified to operate under the CDRL 4-3 environmental conditions specified in Society of Automotive Engineers (SAE) J1455 and all standards contained therein. 4.7.2.1-5 The onboard equipment will meet the following flammability CDRL 4-3 requirements: • UL 94 V-O • UL HB 4.7.2.1-6 Means will be provided to detect failure of any cooling device and CDRL 4-3 provide for a controlled shutdown of the system components and generation of a maintenance event. 4.7.2.1-7 The onboard equipment will be either immune to or protected from the CDRL 4-3 damaging effects of visible spectrum and ultraviolet radiation. Internal components that may be either damaged or affected operationally when exposed to direct sunlight will be protected from exposure during maintenance activities without requiring specific action by maintenance personnel.

AGY-21-008-IT 34 | Page

APPENDIX 1

4.7.2.2 Rail station Equipment

Req # Requirement Assigned CDRL 4.7.2.2-1 Rail equipment, including platform validators, TVMs, rail station CDRL 4-3 operator console, and faregates, will be designed to be installed in an open-air station environment with steel dust and heat conditions described in this section. Operation of the fare collection equipment in this environment will not in any way impair equipment performance throughout the required useful life of the system. 4.7.2.2-2 The rail equipment provided by the SI will tolerate the environment in CDRL 4-3 which it is installed and stored. The equipment will be able to operate and not suffer any degradation in performance under the following environmental conditions: • Storage temperature: 0° to +140°F • Operating temperature: -22°F to 150°F ambient • Thermal shock: Up to 30°F in 1-hour, non-condensing • Relative humidity: 5-100%, non-condensing • Airborne dust: up to 180 micrograms per cubic meter, with iron and salt particles • Sunlight: direct sunlight, radiation loading of up to 3MJ/hr/m2 • Platform Inclination: 0° to 10° off vertical • Rainfall: 10 inches over 12 hours • Water/solvents: IEC529 to level IP34 or equivalent • Other operational conditions: water spray, industrial cleaning solvents, and mud on system components from cleaning station floors and walls 4.7.2.2-3 The rail equipment will be designed to be resistant to liquid ingress CDRL 4-3 caused by atomization cleaning, rain, snow, or by splashed water or cleaning chemicals, such as would occur during routine equipment and platform cleaning. 4.7.2.2-4 TVMs will be subject to incidental moisture from customers and cleaning CDRL 4-3 through coin, bill, and ticket slots, and other openings and enclosure joints, and will be designed for proper operation under such conditions. All exposed surfaces, including push buttons, the display screen, and coin and bill components shall be unaffected by detergents and cleaning solvents. Means will be provided to expel moisture from the devices to ensure continued, reliable operation. 4.7.2.2-5 Means will be provided to detect failure of any cooling device and CDRL 4-3 provide for a controlled shutdown of the system components and generation of a maintenance event.

AGY-21-008-IT 35 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.7.2.2-6 The rail equipment will be either immune to or protected from the CDRL 4-3 damaging effects of visible spectrum and ultraviolet radiation. Internal components that may be either damaged or affected operationally when exposed to direct sunlight will be protected from exposure during maintenance activities without requiring specific action by maintenance personnel.

4.7.2.3 Office and Retail Equipment

Req # Requirement Assigned CDRL 4.7.2.3-1 Customer Service Terminals (CSTs) will be designed to be installed in CDRL 4-3 agency facilities and retail locations (e.g., typical office and store settings). Operation of the equipment in this environment will not in any way impair equipment performance throughout the required useful life of the system. 4.7.2.3-2 Means will be provided to detect failure of any cooling device and CDRL 4-3 provide for a controlled shutdown of the system components and generation of a maintenance event.

4.7.3 Electrical

4.7.3.1 Power and Voltage Requirements

Req # Requirement Assigned CDRL 4.7.3.1-1 The SI shall design, supply, install, test, and commission all internal CDRL 4-3 system components necessary to provide the required electrical power to the SI-supplied equipment. 4.7.3.1-2 Electrical power will be obtained from existing power sources and will CDRL 4-3 be filtered, transformed, converted, battery-stored, and distributed by the SI as required, including all necessary connections and terminations. 4.7.3.1-3 Primary power will be provided by the agency at equipment installation CDRL 4-3 locations and may not be clean or isolated at the voltage levels required by the SI-supplied equipment. Any necessary conditioning of the primary power, or addition of line interface filters or power supplies, will be the responsibility of the SI, and to the greatest extent possible, will be performed within the equipment enclosures. 4.7.3.1-4 All system components operating off of line voltage will be designed to CDRL 4-3 operate with a plus or minus 10% fluctuation in voltage without any damage or interruption.

AGY-21-008-IT 36 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.7.3.1-5 Rail equipment, including TVMs and faregates, will be capable of normal CDRL 4-3 operating under the following conditions: • Source power of 120 VAC (+/-10%), single Phase, 3-wire, 60 Hz (+/-1%) • Micro cuts in the power supply of up to 15 ms, with a recurrence of 100 ms • The following voltage excursions: o Sag: -15% o Surge: 15% o Transient Impulse: 75 volts o Common Mode Noise: 5 volts 4.7.3.1-6 In the event of a loss of electrical power, the rail equipment will CDRL 4-3 complete any transaction in process, retain all data, and shutdown in an orderly manner. The equipment will return to full operational status after a power failure without manual intervention or adversely affecting the integrity of stored data. 4.7.3.1-7 Onboard equipment, including bus validators and driver displays will be CDRL 4-3 designed to operate reliably from a vehicle’s direct current power source, which will be either 12 volts or 24 volts of direct current (VDC). 4.7.3.1-8 The onboard equipment will be protected against damage or data loss CDRL 4-3 under the following conditions: • Voltage fluctuations • Reverse polarity of the input voltage • Temporary voltage variations (0 to 50 V) • Over-current draw • Stray currents 4.7.3.1-9 The onboard equipment power supply will include adequate filters and CDRL 4-3 components to regulate the bus-supplied voltage and render it devoid of power spikes and noise. Provisions will include elimination of power fluctuations caused by fluorescent lights, coach alternators, air conditioning units, radio communication units, and other systems characteristic of a bus environment. 4.7.3.1-10 Adequate protection against transient power surges on the bus will be CDRL 4-3 incorporated to the extent necessary to prevent damage to the electronic components of the onboard equipment. 4.7.3.1-11 Power sensing will be incorporated into onboard equipment power CDRL 4-3 supplies to cause the devices to switch off automatically if the supply voltage increases or decreases to levels beyond the voltage tolerance. 4.7.3.1-12 All system components will retain any information stored in non-volatile CDRL 4-3 memory under any conditions of the supplied power.

AGY-21-008-IT 37 | Page

APPENDIX 1

4.7.3.2 Electrical Noise Requirements

Req # Requirement Assigned CDRL 4.7.3.2-1 The SI shall ensure system equipment will operate without being CDRL 4-3 affected by or causing electromagnetic interference (EMI). 4.7.3.2-2 All system components will include protection against external EMI and CDRL 4-3 Radio Frequency Interference (RFI) emissions, as well as internal conductive or inductive emissions. 4.7.3.2-3 All system components will conform to the following requirements: CDRL 4-3 • FCC Part 15, Subpart B Class A (Conducted emissions), pertaining to conducted susceptibility • FCC Part 15, Subpart B Class A (Radiated emissions), pertaining to radiated susceptibility 4.7.3.2-4 Equipment will not emit measurable EMI or RFI that produces harmful CDRL 4-3 interference with any other onboard or station devices or systems, including GPS and magnetic compass readings, and will comply with the following standards: • IEC 1000-4-6 (EN61000-4-6) pertaining to conducted susceptibility • IEC 6100-4-3 (EN61000-4-3) pertaining to radiated susceptibility • IEC 6100-4-2 (EN 6100-4-2) pertaining to electrostatic discharge 4.7.3.2-5 Operation of the equipment will not be affected by the electromagnetic CDRL 4-3 fields generated by traction power (overhead catenary or third rail) at distances as close as 20 feet, or by local high voltage power distribution lines at distances as close as 50 feet. 4.7.3.2-6 Operation of the rail equipment, including platform validators, TVMs, CDRL 4-3 rail station operator console, and faregates, will not be adversely affected by the operation of other station equipment, such as lighting and communications equipment, within close proximity. 4.7.3.2-7 Onboard equipment, including bus validators and driver displays, will be CDRL 4-3 unaffected by interference from fluorescent lights, coach alternators, air conditioning units, radio communication units, and other systems characteristic of a bus environment. 4.7.3.2-8 Equipment communications will not interfere or be impacted by the use CDRL 4-3 of established frequencies, including but not limited to: • Audio frequencies for overlay track circuits, highway crossing approach and island circuits, and electrical lock circuits • Audio frequency code overlay for Air Traffic Control (ATC) systems • Signal power • Cab signals

AGY-21-008-IT 38 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.7.3.2-9 The SI shall certify the electromagnetic compatibility of system CDRL 4-3 components to be furnished. The SI shall provide the results of interaction analysis and testing of each system component with regard to frequency distribution, amplitude, and harmonic content for review and approval during design review.

4.7.3.3 Grounding

Req # Requirement Assigned CDRL 4.7.3.3-1 All equipment enclosures, chassis, assemblies, panels, switch boxes, and CDRL 4-3 terminal boxes will be grounded. Protective grounding will be provided to ensure that exposed metal on all system components is connected to a common ground point. 4.7.3.3-2 The SI shall meet safety requirements for the grounding that conforms CDRL 4-3 to the National Electric Code (NEC) and UL, SAE, and local codes where applicable. 4.7.3.3-3 The SI shall provide certification that all system components furnished CDRL 4-3 have been tested to meet applicable UL criteria. Documentation citing UL certification or acceptable test results will be provided for review and approval during design review. 4.7.3.3-4 System equipment will be equipped with Ground Fault Circuit CDRL 4-3 Interrupter (GFCI) circuit breakers, which include a “push to test” button, visible indication of a tripped condition, and ability to detect an earth leakage current of approximately 5 milliamperes in accordance with UL 1053 and California Energy Commission (CEC) standards.

4.8 Licensing and Data Ownership Req # Requirement Assigned CDRL 4.8-1 The agency will own all data generated by the equipment, systems, and CDRL 4-4 software delivered under this Contract. The agency will be able to freely access and distribute all data free of charge. The agency will retain ownership of all data in perpetuity with no restrictions or additional cost. 4.8-2 All documentation described in these specifications will become the CDRL 4-4 property of the agency or provided under a perpetual license to enable internal use and distribution to third parties at no additional cost. 4.8-3 All system and software interfaces will be defined and documented and CDRL 4-4 will be provided to the agency under a perpetual license to enable internal use and distribution to third parties at no additional cost.

AGY-21-008-IT 39 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 4.8-4 All open architecture APIs, open source code, libraries, and Intellectual CDRL 4-4 Property (IP), including data exchange formats and algorithms, will be provided to the agency under a perpetual license to enable internal use and distribution to third-parties at no additional cost.

4.9 ADA Compliance Req # Requirement Assigned CDRL 4.9-1 All equipment, software, and customer interfaces will be in compliance CDRL 4-5 with Americans with Disabilities Act (ADA) standards to maximize ease of use. The system equipment will comply with the most recent version of the ADA Accessibility Guidelines (ADAAG) at the time of Final Acceptance. 4.9-2 The SI shall submit for review and approval at PDR, documentation with CDRL 4-5 descriptions and drawings of how each customer-facing device and system will achieve ADA compliance.

4.10 Code and Regulation Compliance The SI shall design the system to be compliant with relevant standards, laws, and regulations to ensure that the system:

• Presents no safety hazards for customers and agency employees • Will withstand the rigors of the environments in which the equipment will be installed, and the public use to which it will be subjected • Provides for the secure storage and transmittal of data • Is designed using state-of-the-art methods to maximize quality • Satisfies federal, state, and other requirements for ergonomics and usability The list of applicable codes, laws, ordinances, statutes, standards, rules, and regulations will include, but is not be limited to, the items below. The latest revisions in effect at the time of Final Acceptance will apply.

• Americans with Disabilities Act (ADA) • Americans with Disabilities Act Accessibility Guidelines (ADAAG) • Advanced Encryption Standard • ANSI X9.24, Financial Services Retail Key Management • European Norm EN55022, Emissions standards for CE marking • European Norm EN55024, Immunity standards for CE marking • FCC Part 15 Class B – Radio Frequency Devices • FIPS 140-2 • IEEE 802.11 b/g/n standard for wireless data communications • IEEE 802.11i standard for wireless data network security

AGY-21-008-IT 40 | Page

APPENDIX 1

• International Electrotechnical Commission Standard 529 (IEC529) • ISO/IEC 7810, Identification Cards – Physical Characteristics • ISO 9001 • ISO/IEC-8583 – Financial transaction card originated messages • ISO/IEC 14443 Parts 1 through 4 – Contactless Smart Card Standard • ISO/IEC 18092 / ECMA-340, Near Field Communication Interface and Protocol-1 • ISO/IEC 21481 / ECMA-352, Near Field Communication Interface and Protocol-2 • National Electrical Code (NFPA 70) • National Electrical Manufacturers Association Publication 250-2003 • National Electrical Safety Code (ANSI C2) • National Fire Protection Association (NFPA) 130 • NCITS 322-2002, American National Standard for Information Technology – Card Durability Test Methods • Occupational Safety and Health Administration (OSHA) • Payment Card Industry Data Security Standards (PCI-DSS) • Payment Card Industry Payment Application Data Security Standards (PA-DSS) • Society of Automotive Engineers SAE J1113-13 Electrostatic Discharge • Society of Automotive Engineers SAE J1455 Vibration and Shock • UL Standard 60950, “Information Technology Equipment – Safety” • World Wide Web Consortium, Mobile Web Application Best Practices • Web Content Accessibility Guidelines WCAG 2.0 In the case of conflict between the provisions of codes, laws, ordinances, statutes, standards, rules, and regulations, the more stringent requirement will apply.

4.11 Required Submittals Submittal Description Submittal Due No. CDR PDR FDR Other CDRL 4-1 System Hardware and Software X An updated version of this Design Plan document will be delivered for each project Phase’s CDR CDRL 4-2 Maintenance Plan X X An updated version of this document will be delivered for each project Phase’s PDR an FDR review CDRL 4-3 Environmental Compliance Plan X X X An updated version of this document will be delivered for each project Phase’s design review CDRL 4-4 Software and Documentation X X X An updated version of this Licensing Plan document will be delivered for each project Phase’s design review

AGY-21-008-IT 41 | Page

APPENDIX 1

Submittal Description Submittal Due No. CDR PDR FDR Other CDRL 4-5 ADA Compliance Plan X X An updated version of this document will be delivered for each project Phase’s PDR an FDR review

5. System Architecture Requirements The new Baltimore fare collection system will be an open architecture, account-based system with key system interfaces built using Application Programming Interfaces (APIs) published by the SI and fully owned or licensed by the agency. Exhibit 5-1 shows a conceptual system architecture. Account-Based System

Exhibit 5-1 Proposed System Arc

AGY-21-008-IT 42 | Page

APPENDIX 1

5.1 Account-Based System Req # Requirement Assigned CDRL 5.1-1 The SI shall design, develop, and implement an account-based electronic CDRL 5-1 fare collection system. 5.1-2 An account-based back-office supporting the system will manage closed- CDRL 5-1 loop transit accounts that store fare value loaded by customers and enable use of that value for the payment of transit fares and transit- related services. 5.1-3 The account-based back-office will process all transactions generated by CDRL 5-1 the system devices, including loading transit accounts upon request from fare distribution devices, and performing fare calculation and account balance updates at the time of fare payment. All fare processing and updating of accounts will be performed in real-time. 5.1-4 Transit accounts will be accessed by the customer when loading value or CDRL 5-1 paying fares through the use of agency- and third party-issued contactless fare media (e.g., smartcards). 5.1-5 The fare media will serve as a token for accessing transit accounts, and no CDRL 5-1 data will be written to the media when loading or using fare value, with the exception of data required to support risk mitigation techniques (see Section 5.6). 5.1-6 The system will be sized such that the total number of possible accounts, CDRL 5-1 and total concurrent use of accounts, will at a minimum support 200% of the current and anticipated ridership figures presented in the RFP’s Appendix of these specifications.

5.2 Real-Time Communications Req # Requirement Assigned CDRL 5.2-1 All fare distribution and payment devices deployed as part of the system CDRL 5-1 will be equipped with real-time communications to the back-office. 5.2-2 The communication interfaces will support the real-time loading of fare CDRL 5-1 value through all distribution channels, processing of closed-loop fare payments onboard vehicles and at rail stations, and fare inspection by agency staff. 5.2-3 The lowest-latency network connections possible will be employed, using CDRL 5-1 hardwired, cellular and Wi-Fi connections, as appropriate for each device.

AGY-21-008-IT 43 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.2-4 All hardwired network connections, with the exception of those CDRL 5-1 connecting equipment onboard vehicles, will be provided by the agency, and supported by a fiber backbone. The SI shall identify all communication requirements at bus and rail sites, including a description of all networking equipment necessary to connect the SI devices to the agency-provided fiber backbone. 5.2-5 Any devices using cellular communications will operate on a 4G/LTE data CDRL 5-1 network (or faster) where available. The agency will contract directly with the cellular carriers for cellular data service. 5.2-6 The system will support the offline operation of field devices to perform CDRL 5-1 essential functions where appropriate. In offline operation, devices shall operate according to defined business rules, and transmit stored transaction information as soon as communications are reestablished.

5.3 Open Architecture The system will be designed and implemented using an open architecture approach to provide flexibility as technology and agency needs change. The open architecture will apply to all fare media, system interfaces, and transaction formats used for the management, distribution, payment, and inspection of fares. There is a strong preference for the use of open source and cloud-based infrastructure and applications.

5.3.1 System Interfaces and APIs

The SI shall develop, publish specifications for, and implement the use of APIs to support all critical system functions and interfaces between system components. The API specifications will include all API calls, data formats, and communication and security protocols used to support the system interfaces. The specifications will become the property of the agency or provided under an unrestricted, royalty- free license. Additional APIs, beyond those described in this section, may be required if needed to support required system functionality.

5.3.1.1 General Requirements

Req # Requirement Assigned CDRL 5.3.1.1-1 The SI shall develop Hypertext Transfer Protocol Secure (HTTPS) based CDRL 5-2 functional (e.g., not device- or system-specific) APIs that support core system functions and enable access to those functions for any device or system that requires use of them. Devices and systems may make use of more than one API to support required functionality. 5.3.1.1-2 Each API will be developed using modern architecture and formats (e.g., CDRL 5-2 REST/JSON). The specific architecture and format to be used will be identified and agreed upon during design review.

AGY-21-008-IT 44 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.1-3 The SI shall implement strong security features to prevent fraudulent use CDRL 5-2 of the APIs and authenticate all users based on industry-accepted best practices. 5.3.1.1-4 The SI shall publish full API specifications that document all API calls and CDRL 5-2 the process for making those calls, including: • Detailed call descriptions • Use cases • Call structure • Data elements and format • Error handling • Timing requirements • Use of required security protocols • Sample code 5.3.1.1-5 The SI shall be responsible for providing the following APIs at a minimum: CDRL 5-2 • Fare Distribution API • Fare Payment API • Fare Inspection API • Transit Account Management API • Customer Account Management API • Device Management API • CAD/AVL Integration API Alternative categorization of APIs may be permitted, as long as the functional requirements are met. 5.3.1.1-6 The SI shall demonstrate use of the APIs as part of system implementation CDRL 5-2 and testing. The SI shall perform API-specific testing, which will be witnessed and validated by agency representatives prior to Final Acceptance. Any changes to the APIs as a result of testing will result in the API specifications being updated by the SI. 5.3.1.1-7 The SI shall take the lead role in working collaboratively with third parties CDRL 5-2 to use and adapt the APIs in order to integrate legacy systems as necessary to support the requirements in these specifications. 5.3.1.1-8 The full range of APIs provided by the SI will support all interfaces within CDRL 5-2 the fare collection system and is not limited to the specific APIs described in this section. Any additional APIs that are required will be identified during design review. The SI shall provide Interface Control Documentation (ICD) for each system interface that describes the interface and APIs used to support it. 5.3.1.1-9 The APIs and ICDs will be fully owned by or licensed to the agency with CDRL 5-2 the right to use and distribute the specifications without further approval, license, or payment.

AGY-21-008-IT 45 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.1-10 The SI shall update the API and ICD specifications as necessary throughout CDRL 5-2 the warranty and SMA terms (see Section 15).

5.3.1.2 Fare Distribution API

The fare distribution API will support the sale of fare media and fare products offered through all fare distribution channels.

Req # Requirement Assigned CDRL 5.3.1.2-1 The fare distribution API will support the sale of all available fare media CDRL 5-2 and fare products, and will be utilized by all fare distribution devices and systems, including but not limited to: • Ticket Vending Machines • Customer Service Terminals • Customer Relationship Management System • Customer and Institutional Websites • Interactive Voice Response System • Potential 3rd party agency partners 5.3.1.2-2 The fare distribution API will support the following functionality at a CDRL 5-2 minimum: • Retrieval of available fare media and fare products, and associated pricing • Sale of all fare media types, and creation or activation of an associated transit account • Sale of all available fare products (e.g., stored value and passes), and update of an associated transit account 5.3.1.2-3 The fare media and products available for sale, and the associated pricing, CDRL 5-2 will be configured and maintained in the back-office. The fare media API will return this information upon request from a fare distribution device/system. The results provided will be configurable to be specific to the sales channel, device/system location, or individual device/system making the API call. 5.3.1.2-4 The fare distribution API will include API calls for the passing of data CDRL 5-2 between the fare distribution devices/systems and the back-office to initiate a sale transaction, which will result in the creation, activation, or updating of a closed-loop transit account.

AGY-21-008-IT 46 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.2-5 Unique fare media and/or transit account identifiers will be securely CDRL 5-2 captured by the distribution devices/systems and passed to the back-office to create or activate a new transit account (e.g., in support of new media issuance), or initiate the loading of value to an existing transit account. All fare media and product sales will be processed by the back-office in real- time to enable immediate use by the customer. 5.3.1.2-6 The fare distribution API will support the generation of sale and payment CDRL 5-2 transactions within the back-office by capturing all information required to appropriately record the sale, including at a minimum: • Date/time • Agency • Sales channel ID • Device/system ID • Device/system location • Fare media ID • Transit account token • Product(s) sold • Payment amount(s) • Payment type(s) The fare payment API will support the sale of multiple products (e.g., fare media and value) in a single transaction with a single payment, and the use of multiple payments (e.g., split payments) in a single sales transaction. 5.3.1.2-7 The fare distribution API will return a confirmation of the actions taken by CDRL 5-2 the back-office to complete a sale. If the sale was unsuccessful, a denial and associated reason code will be provided. All response types and error handling will be described in detail in the fare distribution API specification.

5.3.1.3 Fare Payment API

The fare payment API will support the processing fare payments by all fare payment devices.

Req # Requirement Assigned CDRL 5.3.1.3-1 The fare payment API will support the processing of closed-loop fare CDRL 5-2 payments across all agency and modes using all supported fare media and fare products, and will be utilized by all fare payment devices, including but not limited to: • Bus Validators • Platform Validators • Faregates

AGY-21-008-IT 47 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.3-2 The fare payment API will include API calls for the passing of data between CDRL 5-2 the fare payment devices and back-office to initiate a fare payment transaction, which will result in a fare calculation being performed and processing of a payment against a closed-loop transit account. 5.3.1.3-3 Unique fare media and/or transit account identifiers will be securely CDRL 5-2 captured by the fare payment devices and passed to the back-office to perform a fare payment. All fare payment processing will be performed by the back-office in real-time. 5.3.1.3-4 The fare payment API will support the generation of fare payment CDRL 5-2 transactions within the back-office by capturing all information required to calculate and appropriately record the payment, including at a minimum: • Date/time • Agency • Vehicle/station ID • Operator ID (bus and mobile only) • Device ID • Stop ID (bus and mobile only) • Geolocation information (bus and mobile only) • Pattern (bus and mobile only) • Block (bus and mobile only) • Route (bus and mobile only) • Run (bus and mobile only) • Direction/platform • Fare media ID • Transit account token • Other data encoded to the media (e.g., rider classification) • Authorization mode (e.g., online, or offline) 5.3.1.3-5 The fare payment API will support the passing of a pre-calculated fare to CDRL 5-2 support programs such as bike share, where third-party devices or systems will calculate the amount due. The back-office will process pre- calculated fare transactions based on the fare structure configured for the associated mode or participant (see Section 6).

AGY-21-008-IT 48 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.3-6 The fare payment API will return a confirmation of the actions taken by CDRL 5-2 the back-office to complete a payment and account status information, including at a minimum: • Payment status (e.g., success or failure) • Account rider classification • Fare product used • Fare charged • Remaining balance • Transfer time remaining If the payment was unsuccessful, an associated reason code will be provided. All response types and error handling will be described in detail in the fare payment API specification.

5.3.1.4 Fare Inspection API

The transit account management API will support the querying and management of fare-related data maintained within closed-loop transit accounts.

Req # Requirement Assigned CDRL 5.3.1.4-1 The fare inspection API will query closed-loop transit accounts to support CDRL 5-2 the inspection of fares paid across all agency and modes using all supported fare media and fare products will be utilized by the mobile fare inspection devices. 5.3.1.4-2 The fare inspection API will include API calls for passing data between CDRL 5-2 the mobile fare inspection application and back-office to initiate a fare inspection transaction, which will result in confirmation or denial of payment made using a closed-loop transit account. 5.3.1.4-3 Unique fare media and/or transit account identifiers will be securely CDRL 5-2 captured by the mobile fare inspection devices and passed to the back- office to perform a fare inspection. The back-office will query transit account ride history and use agency-defined business rules to determine fare payment status in real-time.

AGY-21-008-IT 49 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.4-4 All fare inspections will result in a recorded transaction. The fare CDRL 5-2 payment API will support the generation of transactions by capturing all information required to determine the status of a fare payment and appropriately record the inspection, including at a minimum: • Date/time • Agency • Vehicle/station ID • Device ID • Stop ID • Geolocation information • Pattern (bus inspection only) • Block (bus inspection only) • Route (bus inspection only) • Run (bus inspection only) • Direction/platform • Fare media ID • Transit account token • Other data encoded to the media (e.g., rider classification) 5.3.1.4-5 The fare payment API will return fare payment status information, CDRL 5-2 including at a minimum: • Payment status (e.g., valid, or invalid) • Account rider classification • Fare product used (if valid tap is found) • Fare charged (if valid tap is found) • Transfer time remaining (if valid tap is found) • Account balance • Fare payment transaction history If the payment is determined to be invalid, an associated reason code will be provided (e.g., no tap, blocked card). All response types and error handling will be described in detail in the fare inspection API specification.

5.3.1.5 Transit Account Management API

The transit account management API will support the querying and management of fare-related data maintained within closed-loop transit accounts.

AGY-21-008-IT 50 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.5-1 The transit account management API will support the querying and CDRL 5-2 management of data maintained within back-office transit accounts, and will be utilized by all devices and systems that require access to those functions, including but not limited to: • Ticket Vending Machines • Customer Service Terminals • Customer Relationship Management System • Customer and Institutional Websites • Interactive Voice Response System Not all devices/systems will require or be granted access to all transit account management API functions. 5.3.1.5-2 The transit account management API will support the following CDRL 5-2 functionality at a minimum: • Query transit account status (e.g., associated rider classification, active/inactive, blocked/unblocked) • Query fare payment transaction history • Query sales transaction history • Query adjustment transaction history • Enable fare product for autoload (requires funding source in customer account) • Generation of fare payment reversal (e.g., cancellation) • Generation of sales reversal (e.g., refund) • Generation of an account adjustment (e.g., credit or debit) • Transfer of balance between two accounts • Block/unblock card, account, or individual fare product • Lost, stolen, or damaged card replacement (e.g., associate new card with existing account) • Generation of an opt-out refund (e.g., close account and issue refund) 5.3.1.5-3 The transit account management API will include API calls for the passing CDRL 5-2 of data between the devices/systems and the back-office to perform all functions. 5.3.1.5-4 The transit account management API will allow devices/systems to query CDRL 5-2 a transit account status and return the sales, fare payment, and adjustment transactions that were conducted over a specified timeframe, or a specified number of past transactions. 5.3.1.5-5 The transit account management API will allow devices/systems to setup CDRL 5-2 autoload for an existing fare product. Enabling autoload will require a valid funding source to be stored in an associated customer account, and may be performed using the customer account management API instead (see Section 5.3.1.6).

AGY-21-008-IT 51 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.5-6 The transit account management API will allow authorized personnel to CDRL 5-2 perform adjustment, reversal, transfer, and refund transactions to modify transit account balances. 5.3.1.5-7 The transit account management API will allow authorized personnel to CDRL 5-2 generate blocking (and unblocking) and replacement transactions to close or prevent use of transit accounts, fare media, and fare products. 5.3.1.5-8 Unique fare media and/or transit account identifiers will be securely CDRL 5-2 captured by the devices/systems and passed to the back-office to perform all functions. The back-office will perform all functions in real- time. 5.3.1.5-9 The transit account management API will capture all required information CDRL 5-2 to generate a detailed transaction within the back-office for all functions performed, including at a minimum: • Date/time • Agency • Sales/customer service channel ID • Device/system ID • Device/system location • Operator/administrator ID • Fare media ID • Transit account token • Details of action performed 5.3.1.5-10 The transit account management API will return a confirmation of the CDRL 5-2 actions taken by the back-office. If any action was unsuccessful, a denial and associated reason code will be provided. All response types and error handling will be described in detail in the transit account management API specification.

5.3.1.6 Customer Account Management API

The customer account management API will support the querying and management of individual and intuitional customer data maintained within the customer database.

AGY-21-008-IT 52 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.6-1 The customer account management API will support the querying and CDRL 5-2 management of data maintained within the customer database (see Section 8.3.2), and will be utilized by all devices and systems that require access to those functions, including but not limited to: • Customer Service Terminals • Customer Relationship Management System • Customer and Institutional Websites • Interactive Voice Response System Not all devices/systems will require or be granted access to all customer account management API functions. 5.3.1.6-2 The customer account management API will support the following CDRL 5-2 functionality at a minimum: • Create new individual customer account • Create new institutional customer account • Query customer account status and data • Modify customer account data • Register (e.g., link) a transit account to an individual or institutional customer account • Unregister (e.g., unlink) a transit account from an individual or institutional customer account • Add a funding source to an individual or institutional customer account • Close an individual or institutional customer account 5.3.1.6-3 The customer account management API will include API calls for the CDRL 5-2 passing of data between the devices/systems and the back-office to perform all functions. 5.3.1.6-4 The API will allow devices/systems to create individual and institutional CDRL 5-2 customer accounts within the customer database, and associate or disassociate existing transit accounts with those customer accounts. 5.3.1.6-5 The customer account management API will allow devices/systems to CDRL 5-2 query and modify all individual and institutional customer account data, including but not limited to name, address, date of birth, phone number, e-mail address, institution and administrator contact information, username, password, security questions/answers, account access PIN, and funding sources.

AGY-21-008-IT 53 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.6-6 The API will support the individual and bulk import of data for CDRL 5-2 institutional customers and customers applying for a reduced fare classification, including scans of applications and supporting documentation, eligibility parameters, and card personalization information, such as a customer photograph, to be stored in the customer database. 5.3.1.6-7 The customer account management API will allow authorized personnel CDRL 5-2 to close customer accounts. Closing of a customer account will not affect the associated transit accounts. 5.3.1.6-8 The customer account management API will capture all required CDRL 5-2 information to generate a detailed transaction within the back-office for all functions performed, including at a minimum: • Date/time • Agency • Sales/customer service channel ID • Device/system ID • Device/system location • Operator/administrator ID • Fare media ID (if associated with a customer account) • Transit account token (if associated with a customer account) • Customer account number • Customer account data • Details of action performed 5.3.1.6-9 The customer account management API will return a confirmation of the CDRL 5-2 actions taken by the back-office. If any action was unsuccessful, a denial and associated reason code will be provided. All response types and error handling will be described in detail in the customer account management API specification.

5.3.1.7 Device Management API

The device management APIs will support the monitoring and management of all devices deployed within the system.

AGY-21-008-IT 54 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.7-1 The device management API will support the reporting of device events CDRL 5-2 and alarms, and the distribution of new software, configuration parameters, and positive and negative list updates as required, and will be utilized by all devices deployed within the system, including but not limited to: • Bus Validators • Platform Validators • Driver Displays • Ticket Vending Machines • Faregates • Customer Service Terminals • Mobile Fare Inspection Devices

5.3.1.7-2 The device management API will support the passing of data between the CDRL 5-2 devices and the System Monitoring and Management Application (see Section 8.4) to enable the monitoring of system performance in real-time. The device events and alarms reported via device management the API will provide enough detail to support proactive device maintenance at the module-level, and support accurate reporting on all system performance requirements (see Section 16). 5.3.1.7-3 The device management API will support the passing of data between the CDRL 5-2 System Monitoring and Management Application and devices to enable remote control and issuance of all commands supported for each device type. All commands will be able to be issued and executed in real-time. 5.3.1.7-4 The device management API will support the real-time distribution of CDRL 5-2 device software and configuration parameter updates. Device configuration will include real-time updates to any positive and negative lists maintained locally at the devices. Updates will be distributed on an increment-basis so that only updates since that last timestamp/version received by an individual device are transmitted. 5.3.1.7-5 A universal device management API will be created and used wherever CDRL 5-2 possible; however, the SI may create device-specific device management APIs or calls, as necessary.

5.3.1.8 CAD/AVL Integration API

The CAD/AVL integration API will support the integration of the bus validators with the existing Computer-Aided Dispatch/Automated Vehicle Location system onboard vehicles. The SI shall be fully responsible for the integration of these systems as part of the fare system implementation (see Section 10.1.1).

AGY-21-008-IT 55 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.1.8-1 The CAD/AVL integration API will be utilized by the bus validators to CDRL 5-2 exchange information with the CAD/AVL system and support single sign- on and the capture of geo-location information. 5.3.1.8-2 The CAD/AVL integration API will support the capture of operator login CDRL 5-2 and route data from CAD/AVL system, including but not limited to: • Operator ID • Pattern • Block • Route • Run • Direction The bus validator will append this information to all fare payment transactions generated by the device. 5.3.1.8-3 The CAD/AVL integration API will support the capture of geo-location data CDRL 5-2 from CAD/AVL system geo-location data, including but not limited to: • Raw GPS coordinates • Stop ID The bus validator will append this information to all fare payment transactions generated by the device. 5.3.1.8-4 The CAD/AVL integration API will be designed such that it is vendor CDRL 5-2 agnostic; however, the SI will partner with MTA’s existing CAD/AVL supplier, Trapeze and ensure all system-specific requirements are met.

5.3.2 Transaction Formats

Req # Requirement Assigned CDRL 5.3.2-1 The SI shall publish specifications for all transactions generated and used CDRL 5-3 within the system that are not already covered by the required APIs. 5.3.2-2 Transaction specifications will include detailed descriptions of the CDRL 5-3 transaction structure, data elements, and data formats, and identify all devices and systems that generate and consume the described transactions. 5.3.2-3 Transaction formats will be based on published standards wherever CDRL 5-3 possible, including those used to interface with commercial software packages, such as the SI-provided CRM, revenue management, and reporting systems.

AGY-21-008-IT 56 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.3.2-4 The transaction formats shall be fully owned by or licensed in perpetuity CDRL 5-3 to the agency, including the right to distribute the specifications to third parties without further approval, license, or payment.

5.4 Open Payment Acceptance

5.4.1 General Requirements

Req # Requirement Assigned CDRL(s) 5.4.1-1 The system will be designed to accept contactless open payments (i.e., CDRL 5-4 contactless EMV bank cards and equivalents in mobile wallets) for the payment of fares at all points where fare payment is accepted, including at validators installed on-board vehicles and on station platforms, and at contactless readers installed in subway faregates. 5.4.1-2 The SI shall be responsible for end-to-end processing of open payments CDRL 5-4 transactions, including: • Card handling – Capture of card data, generation of an encrypted EMV payload, and Offline Data Authentication (ODA), as applicable to the card being accepted • Risk management – Card validity checks and check against a system-maintained hotlist, which may be augmented using information from third-party service providers • Payment validation – Card tokenization, transit account maintenance, fare calculation and issuance of a validation (i.e., acceptance or denial) response • Transaction authorization – Bank authorization using a real-time communications interface to MTA’s bank card processor • Settlement reconciliation – Automated transaction-level reconciliation of settled bank card transactions, including automated clearing of settled transactions and write-off of non- settled transactions, per agency-defined rules 5.4.1-3 The provided solution will be fully compliant with the latest version of the CDRL 5-4 Visa Mass Transit Transaction (MTT) model for the acceptance of open payments published at the time of system launch, including all rules related to transaction processing, aggregation, and debt recovery. The provided solution will also be fully compliant with the latest version of any similar specifications issued by other card brands at the time of system launch. 5.4.1-4 The provided solution will be fully compliant will all Payment Card Industry CDRL 5-4 (PCI) standards published at the time of system launch.

AGY-21-008-IT 57 | Page

APPENDIX 1

5.4.2 Supported Formats

Req # Requirement Assigned CDRL(s) 5.4.2-1 Open payments will be accepted using Europay Mastercard, Visa (EMV) CDRL 5-4 contactless bank card standards and protocols. Acceptance of legacy (non- EMV) open payment contactless card formats is not required. 5.4.2-2 The system will support payment using any EMV-compliant bank card, CDRL 5-4 including those associated will all major U.S. (e.g., Visa, Mastercard, American Express, and Discover) and international (e.g., China UnionPay and JCB) card brands. 5.4.2-3 The system will support all contactless open payment methods that CDRL 5-4 comply with EVM standards, including NFC (ISO 18092)-enabled phones with a mobile wallet application, including but not limited to , , , and LG Pay. 5.4.2-4 The SI shall be responsible for ensuring compliance with all requirements CDRL 5-4 associated with EMV payment acceptance in the United States, including support for Dynamic Data Authentication (DDA) and Combined Data Authentication (CDA) forms of ODA.

5.4.3 Payment Security

Req # Requirement Assigned CDRL(s) 5.4.3-1 The SI shall be responsible for ensuring that all applicable equipment and CDRL 5-4 software used to process open payment transactions is certified as compliant with the latest version of PCI Payment Application Data Security Standard (PA-DSS) published at the time of system launch. 5.4.3-2 The SI shall be responsible for ensuring that the provided system, as a CDRL 5-4 whole, is certified as compliant with the latest version of the Payment Card Industry Data Security Standard (PCI DSS) published at the time of system launch. 5.4.3-3 The SI shall make use of a Point-to-Point Encryption (P2PE) or End-to-End CDRL 5-4 (E2E) encryption solution for the transmittal of payment data, which prevents any agency access to data decryption keys, is PCI-compliant, and effectively removes any agency networks used to transit the encrypted data from PCI scope. 5.4.3-4 The SI shall employ a third-party PCI Qualified Security Assessor (QSA) to CDRL 5-4 certify the provided system and its components are fully PCI-compliant as deployed in the production environment. The agency may additionally choose to have its own PCI QSA evaluate and certify the system as well.

AGY-21-008-IT 58 | Page

APPENDIX 1

5.4.4 Online Payment Validation

Req # Requirement Assigned CDRL(s) 5.4.4-1 Payment validators will be equipped with a real-time communications CDRL 5-4 interface to the ATP, which will serve as the system of record (i.e. primary source) for determining acceptance or denial of an open payment. The ATP will also make a determination whether to submit an open payment transaction, once accepted, to the payment processor for authorization. 5.4.4-2 Following initiation of an open payment transaction, validators will send a CDRL 5-4 validation request to the ATP. The validation request will include the encrypted EMV payload, along with any data required by the ATP to securely identify the Payment Account (PA) being used within the system. 5.4.4-3 The ATP will make the determination to accept or deny an open payment CDRL 5-4 based on the status of the PA recorded within the system. The status of a PA, and a record of its use within the system, will be maintained within a transit account, equivalent to those associated with closed-loop media. 5.4.4-4 If the ATP cannot find a transit account associated with the AP being used CDRL 5-4 for payment (e.g., first-time used), a new transit account will be created, and the payment will be accepted. 5.4.4-5 The ATP will be designed to provide a validation response (i.e., acceptance CDRL 5-4 or denial) to validators within a configurable timeout, initially set to 500 milliseconds. 5.4.4-6 An ATP validation response indicating acceptance of an open payment, CDRL 5-4 like that for a closed-loop payment, will include additional information on the fare being paid. The validation response will include at a minimum: • Indication of acceptance • Fare amount charged • Transfer status • Transfer time remaining In the event that fare product association, or support for fare capping, is enabled for open payment media, the fare product or fare cap (once earned) used for payment will also be returned in the validation response. 5.4.4-7 An ATP validation response indicating denial of an open payment, like that CDRL 5-4 for a closed-loop payment, will include additional information. The validation response will include at a minimum: • Indication of denial • Code identifying reason for denial Open payment denial reason codes will be defined during design review.

AGY-21-008-IT 59 | Page

APPENDIX 1

5.4.5 Offline Payment Validation

Req # Requirement Assigned CDRL(s) 5.4.5-1 In parallel or immediately upon sending a validation request to the ATP, CDRL 5-4 payment validators will perform a series of local validation checks on the open payment card being presented for payment. These checks will include at a minimum: • EMV card validity checks • Card expiry status • Offline Data Authentication (as supported by the card) • Check against a locally maintained hotlist 5.4.5-2 Any failure of the local validation checks related to card validity, including CDRL 5-4 card expiration, will result in immediate denial of the payment by the validator, without waiting for an ATP response. 5.4.5-3 If the open payment card being presented passes the local validation CDRL 5-4 checks related to card validity, validators will wait for an ATP response until the response timeout is reached. 5.4.5-4 Any failure of the local validation checks related to the status of the PA CDRL 5-4 within the system, including the presence of the card on the validator hotlist, will result in the pending offline validation status being set to deny. If all local validation checks pass, the pending offline validation status will be set to accept. 5.4.5-5 If an ATP response is not received within the response timeout, the CDRL 5-4 pending offline validation status will be used. 5.4.5-6 When an offline validation result is used, regardless of payment CDRL 5-4 acceptance or denial, validators will send a new validation request to the ATP, indicating that an offline result was used for the payment, and identifying the offline response given. Validators will continue to send this request until it is acknowledged by the ATP. 5.4.5-7 If an offline validation result matches the (i.e., online) result determined CDRL 5-4 by the ATP, the use of an offline result will be recorded for reporting purposes, but no other action is required. 5.4.5-8 If the offline validation result was to deny the payment, while the (i.e., CDRL 5-4 online) result determined by the ATP was to accept the payment, the transaction will be flagged as an exception within the transit account, and identified as such for customer service staff when viewing the PA transaction history. These exceptions will also be used to populate exception reports as required during design review.

AGY-21-008-IT 60 | Page

APPENDIX 1

Req # Requirement Assigned CDRL(s) 5.4.5-9 If the offline validation result was to accept the payment, while the (i.e., CDRL 5-4 online) result determined by the ATP was to deny the payment, payment processor authorization may still be attempted (as defined by card association and internal risk management rules); however, an authorization decline or decision not to attempt authorization will result in a negative balance against the PA being recorded, per the requirements in Section 5.4.6.

5.4.6 Payment Authorization

Req # Requirement Assigned CDRL(s) 5.4.6-1 Per card association and internal risk management rules, to be defined CDRL 5-4 during design review, the ATP will, when required, request payment authorization from the payment processor in parallel with the internal fare validation processing. 5.4.6-2 While payment processor authorization is not required nor anticipated to CDRL 5-4 be provided within the ATP validation response timeout, the system will designed such that if, in the future, an authorization response is received within the timeout period, the PA status will be updated in real-time, and reflected in the validation response from the ATP. 5.4.6-3 A payment authorization decline against a PA, or determination that CDRL 5-4 payment authorization is not possible, will result in any unpaid fares being recorded as a negative balance within the transit account associated with the PA. 5.4.6-4 Recording of a negative balance in a transit account associated with a PA, CDRL 5-4 like those associated with closed-loop media, will result in the payment media tied to the account being added to a hotlist maintained by the ATP, and distributed to all fare validators for use in offline payment validation (see Section 5.4.5). 5.4.6-5 The SI shall provide various channels for customers to “correct” a negative CDRL 5-4 balance, by requesting a re-authorization of the amount due using the same PA against which the negative balance is recorded. At a minimum, this functionality will be provided through the following channels: • IVR (Call Center/Self-Service) • CRM (Call Center) • CST (In-Person Customer Service) • Customer Website (Self-Service) In addition to the channels above, any other means to rectify a blocked card, which are required by the Visa MTT model or similar guidance issued by the other card brands, will be supported.

AGY-21-008-IT 61 | Page

APPENDIX 1

5.4.7 Payment Tokenization

Req # Requirement Assigned CDRL(s) 5.4.7-1 All payment data captured and used by the system will be tokenized in a CDRL 5-4 secure manner, which removes the tokenized data, and the systems and networks that handle only the tokenized data, are outside of PCI scope. 5.4.7-2 Separate payment tokens may be used for internal fare validation CDRL 5-4 processing and for authorization with the payment processor. 5.4.7-3 Tokenization of payment data may be performed internally within the CDRL 5-4 system by the SI, or by the payment processor, as defined in technical approach proposed by the SI. 5.4.7-4 Regardless of whether tokenization is performed internally or by the CDRL 5-4 payment processor, the SI shall ensure that all tokens used for payment authorization will be generated using either a unique Payment Account Reference (PAR), or the funding Payment Account Number (fPAN) associated with card being used for payment, such that a one-to-one ratio between the PA and token is maintained, regardless of how many PA- associated cards are presented. 5.4.7-5 If a card which has not previously been seen by the system is found to be CDRL 5-4 associated with a known PA following tokenization, the system will support the merging of the new and existing transit accounts, including any recalculation of fares and revision to the risk management associated with the PA.

5.4.8 Payment Aggregation and Debt Recovery

Req # Requirement Assigned CDRL(s) 5.4.8-1 The system will support the aggregation of fare payments made using the CDRL 5-4 same PA over a defined period of time in order to reduce payment processing fees. 5.4.8-2 The system will support automated and manually triggered debt recovery CDRL 5-4 processes, which attempt to recovery lost fare revenue due to declined payment authorizations. 5.4.8-3 Payment aggregation and debt recovery processes will be compliant with, CDRL 5-4 and support full range of functionality described in, the latest version of the Visa Mass Transit Transaction (MTT) and any similar specifications published by other card brands at the time of system launch. 5.4.8-4 The system will accommodate scenarios where the aggregation and debt CDRL 5-4 recovery rules vary by card brand or issuer, using Issuer Identification Number (IIN) to determine the card type.

AGY-21-008-IT 62 | Page

APPENDIX 1

Req # Requirement Assigned CDRL(s) 5.4.8-5 All key values used to define the payment aggregation and debt recovery CDRL 5-4 processes with be designed as configurable parameters within the system that can be set by the agency. Universally and individually for each recognized IIN, these configurable parameters will include, at a minimum • Payment aggregation on/off • Payment aggregation value limit • Payment aggregation time limit • Payment pre-authorization on/off • Payment pre-authorization amount • Automated debt recovery on/off • Automated debt recovery period • Automated debt recovery frequency • Tap-driven debt recovery on/off

5.5 Fare Media

5.5.1 General Requirements

Req # Requirement Assigned CDRL 5.5.1-1 Fare media provided as part of the system will meet all applicable CDRL 5-5 common design requirements in Section 4 in addition to the requirements in this section. 5.5.1-2 Agency-issued fare media will be in the form of ISO-14443 compliant CDRL 5-5 contactless smartcards. 5.5.1-3 All sales channels and fare distribution devices will issue extended-use CDRL 5-5 (EU) smartcards. The system will also support limited-use (LU) smartcards, which may be used to support tourist markets and special fare programs (see Section 6.6.4), and issued through sales channels such as retail merchants and the institutional website. Rider classifications and fare products associated with each media type will be based on fare structure configuration (see Section 6). 5.5.1-4 All fare media (e.g., EU and LU) will be designed for use in an account- CDRL 5-5 based system and serve as a token for accessing transit closed-loop transit accounts maintained within the back-office. No data will be written to the media when loading or using fare value, with the exception of data required to support risk mitigation techniques (see Section 5.6). 5.5.1-5 Each transit account will only be linked to one (1) active piece of fare CDRL 5-5 media at a time. The system will support fare media replacement in the event that a card is lost, stolen, or damaged, which will link a new piece of fare media to an existing account and block use of the old fare media.

AGY-21-008-IT 63 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.5.1-6 Fare media will be produced based on branding developed by the agency CDRL 5-5 and a card design developed jointly with the SI. Fare media will also be produced with one or both sides left blank for custom printing following manufacture. 5.5.1-7 In addition to the contactless interface, fare media may be produced with CDRL 5-5 barcodes or magnetic stripes to allow interaction with third-party systems outside the scope of the new fare system. If required, the format and data content of any barcodes or magnetic stripes will be defined during design review. 5.5.1-8 The SI shall design, develop, and ensure manufacture and delivery of all CDRL 5-5 fare media required for successful deployment of the new fare system. The SI shall deliver all graphics files and related materials required for the manufacture of the cards to the agency review and approval no less than 120 days prior to the start of card production.

5.5.2 Physical Characteristics

Req # Requirement Assigned CDRL 5.5.2-1 All contactless fare media will comply with ISO/IEC 14443-1 for physical CDRL 5-5 characteristics and ISO/IEC 7810 ID1 for physical dimensions. Thickness and other physical characteristics not defined by these standards will be finalized during design reviews. 5.5.2-2 Extended-use fare media will be constructed of appropriate durable CDRL 5-5 materials for a minimum useful life of 10 years. The media will comply with the most recent versions of ISO/IEC 10373 and ANSI INCITS 322 for durability. 5.5.2-3 Limited-use fare media will be constructed of appropriate durable CDRL 5-5 materials for a minimum useful life of one (1) year. The media will comply with the most recent versions of ISO/IEC 10373 and ANSI INCITS 322 for durability. 5.5.2-4 The fare media will have read/write performance of not less than 200,000 CDRL 5-5 read/write cycles. 5.5.2-5 All fare media will include an etched, unique non-sequential serial number CDRL 5-5 for the purposes of traceability that is separate from the encoded token and smartcard Unique Identification Number (UID). 5.5.2-6 The fare media will be printed using a four-color process, front and back, CDRL 5-5 and support edge to edge printing. 5.5.2-7 All pre-printed graphics will be protected by a clear coat that covers the CDRL 5-5 entire surface of the card.

AGY-21-008-IT 64 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.5.2-8 Prior to commencing full production, and within 30 calendar days of CDRL 5-5 approved graphic designs, the SI shall supply at least 20 proof samples of each media type for review and approval by the agency.

5.5.3 Fare Media Format

Req # Requirement Assigned CDRL 5.5.3-1 The fare media will use a MIFARE format with an account-based transit CDRL 5-5 payment application developed by the SI (see Section 5.5.4). An alternative fare media format, such as an open payment format, ISO/IEC 24747, or CIPURSE, may be proposed by the SI so long as it meets all of the requirements in these specifications. 5.5.3-2 The fare media format will support a minimum of a 7-byte smartcard UID. CDRL 5-5 5.5.3-3 The fare media format will support strong cryptography, such as TDEA, CDRL 5-5 Advanced Encryption Standard (AES) and RSA to protect access to and modification of all data encoded to the media (see Section 5.5.5). 5.5.3-4 If possible, the same fare media format will be used for both the EU and CDRL 5-5 LU media.

5.5.4 Transit Payment Application

Req # Requirement Assigned CDRL 5.5.4-1 The fare media will use a MIFARE-compatible transit payment application, CDRL 5-6 developed by the SI, to support account-based closed-loop fare payments in both single- and multi-application smartcard environments. 5.5.4-2 The transit payment application will be compatible with all modern CDRL 5-6 MIFARE formats, including but not limited to: Ultralight C, MIFARE Plus, DESFire, and SmartMX. The specific platform to be used for the agency- issued fare media will be proposed by the SI and approved during design review. 5.5.4-3 The transit application will support the secure storage of a unique token CDRL 5-6 used to access a transit account maintained within the back-office. The secure token will not be the smartcard UID or transit account number used within the back office and will not be printed on the media or otherwise accessible using a non-system device. 5.5.4-4 The transit application will support the encoding of additional data at the CDRL 5-6 time of manufacture and use to support risk mitigation techniques (see Section 5.6).

AGY-21-008-IT 65 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.5.4-5 If possible, the same transit payment application will be used for both the CDRL 5-6 EU and LU media. 5.5.4-6 The SI shall publish bit-level specifications for all transit payment CDRL 5-6 applications across all supported card formats within the system, including information on all security protocols necessary to access and encoded data on the media. The application specifications will be subject to agency review and approval during design review. 5.5.4-7 The SI-developed transit payment applications will be fully owned by or CDRL 5-6 licensed to the agency, including the right to distribute specifications to third-parties for media production and to support multi-application smartcard implementations without further approval, license, or payment.

5.5.5 Security

Req # Requirement Assigned CDRL 5.5.5-1 All provided fare media will use strong cryptography to control both read CDRL 5-6 and write access to all data encoded on the media. 5.5.5-2 The SI shall provide cryptographic key management services and tools. Key CDRL 5-6 management in this context includes but is not limited to: • Key generation: Derived key generation for each manufactured card, including card manager key sets, as well as multiple application-related key sets (may include both encryption and authentication keys) • Key storage: Secure storage and retention of card and application key sets. • Key updates: Ability to update, or roll, all cryptographic keys used within system • Key sharing: Secure sharing of application key sets with third parties for use in multi-application environments 5.5.5-3 The SI shall use the highest possible security in generating, storing CDRL 5-6 deploying, and transmitting cryptographic keys. The SI shall submit a cryptographic key management plan for agency review and approval during design review. 5.5.5-4 If the fare system design requires the card manufacturer to encode the CDRL 5-6 cryptographic keys to the fare media, the cryptographic key management plan shall identify at least three (3) trusted card manufacturers with appropriate security mechanisms in place to ensure that the cryptographic keys remain safe and secure.

AGY-21-008-IT 66 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.5.5-5 The SI shall provide detailed specifications for the generation and CDRL 5-6 management of all cryptographic keys used within the system. The key generation algorithms will be fully owned by or licensed to the agency, including the right to distribute specifications to third parties for media production and to support multi-application smartcard implementations without further approval, license, or payment.

5.5.6 Third-Party Media

Req # Requirement Assigned CDRL 5.5.6-1 The fare system will support the acceptance of third-party issued media CDRL 5-5 that uses the SI-provided transit payment application in a multi- application environment. Compatible third-party media may include but is not limited to: • State and local government employee IDs • Transit employee and contractor IDs • Corporate employee IDs • School and college IDs • Social service program cards • PIV and CAC cards issued as identification to military and federal employees 5.5.6-2 If the agency chooses to utilize the transit payment application for third- CDRL 5-5 party media, the media will be supported without any additional development to the SI-supplied devices and systems. 5.5.6-3 For launch, the SI shall be responsible for the integration of the MTA’s CDRL 5-5 employee IDs using the provided transit payment application in a multi- application MIFARE environment. The MTA’s Information Technology Department will work with the SI to support the integration, including memory allocation on the card and any required key sharing. 5.5.6-4 All third-party media accepted within the system will be associated with a CDRL 5-5 closed-loop transit account registered with the same personalization information on the ID. The rules associated with registration and use of third-party media will be defined during design review.

5.5.7 Initial Fare Media Supply

Req # Requirement Assigned CDRL 5.5.7-1 The SI shall provide the initial supply of fare media to support the first six CDRL 5-5 (6) months of operation following system launch.

AGY-21-008-IT 67 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.5.7-2 The initial fare media supply will be compromised of several media types, CDRL 5-5 including but not limited to: • Extended-use full fare smartcards (with graphics) • Extended-use full fare smartcards (blank) • Extended-use reduced fare smartcards (with graphics/non- personalized) • Extended-use reduced fare smartcards (personalized) • Limited-use smartcards (with graphics) • Custom printed smartcards for special programs 5.5.7-3 Pricing for various fare media types will be provided as part of the SI’s CDRL 5-5 proposal. Fare media pricing will be updated prior to purchase of the initial supply to account for market adjustments. 5.5.7-4 The estimated quantity of extended use (EU) cards to be provided is CDRL 5-5 200,000. The estimated quantity of limited use (LU) cards to be provided is 3,500,000. The SI shall work with the agency staff during design review to determine the necessary quantities and varieties of fare media to ensure the successful launch of all standard and special fare programs. 5.5.7-5 Delivery of fare media may occur at once or in installments as deemed CDRL 5-5 appropriate by the agency. All fare media inventory will be tracked and updated by the SI within the Media Inventory Management System (see Section 8.5). 5.5.7-6 All supplied fare media will undergo a comprehensive QA process prior to CDRL 5-5 delivery to ensure adherence to all required performance standards and certifications. Media that fails to meet these requirements will be replaced by the SI at their own expense.

5.6 Risk Mitigation Techniques The account-based architecture depends on reliable and responsive communication between every field device and the back-office. To account for intermittent or unreliable communications, the system will support risk mitigation techniques used to limit fraud, provide accurate and timely account information, and control risk, as necessary.

AGY-21-008-IT 68 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.6-1 The system will support the limited writing of data to closed-loop fare CDRL 5-7 media for the purposes of fraud mitigation, displaying accurate and timely account information, and risk management. The information written to the fare media may include: • Recent transaction information (e.g., transaction timestamps) • Transit account balance information (e.g., low balance/load indicators) • Transit account status information (e.g., rider classification, institutional program, or blocking indicators) Data to be written to the media will be determined during design review and subject to agency approval. 5.6-2 Any data written to the closed-loop fare media will be used to supplement CDRL 5-7 back-office account data and will be limited in nature. The data will be able to be interpreted by the devices with minimal or no business rules logic (e.g., knowledge of fare polices and products). 5.6-3 Data will be able to be written to the closed-loop fare media at time of CDRL 5-7 manufacture, loading, and use. All data shall be secured for both reading and writing using strong cryptography (see Section 5.5.5). 5.6-4 The system will support the distribution of positive and negative lists to be CDRL 5-7 maintained locally at the devices and used for fare validation and inspection. Positive and negative lists will be managed within the back- office and distributed to the devices via the device management API (see Section 5.3.1.7). 5.6-5 If used, positive and negative list updates will be distributed devices to no CDRL 5-7 less than every five (5) minutes and include version control to ensure timely and accurate synchronization. 5.6-6 Any and all processes governing the use of risk mitigation techniques will CDRL 5-7 be fully documented in the software specifications for the devices and may be shared to enable the same functionality on third-party devices.

5.7 Payment Processing Req # Requirement Assigned CDRL 5.7-1 The SI shall be responsible for the processing of payments for sales CDRL 5-8 through all fare distribution channels except for the retail partner network. If the mobile application option in this contract is not exercised and the application is provided by a different vendor, the SI will not be responsible for the processing of payments through that sales channel as well.

AGY-21-008-IT 69 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.7-2 All devices and systems that process electronic payments, including credit CDRL 5-8 cards and debit cards will interface with the agency’s processor for the processing of those payments. 5.7-3 Devices and systems requiring an interface to the payment processor CDRL 5-8 include, but are not limited to: • Ticket Vending Machines • Customer Service Terminals • Customer Relationship Management System • Customer and Institutional Websites • Interactive Voice Response System • Mobile application The system will be able to support an interface between the account- based transaction processor and payment processor to enable the processing of open payments if accepted in the future. 5.7-4 The interface to the payment processor may be built using a central, SI- CDRL 5-8 provided payment application to which all devices and systems processing payments connect or built on an individual device- and system-level. 5.7-5 If a central payment application is used, the SI shall provide a payment CDRL 5-8 processing API, including all required security protocols, to process payments through the payment application and to allow third-party devices to process payments. 5.7-6 The system will use tokenization for all funding sources stored within the CDRL 5-8 system (see Section 8.3.2). The SI shall make of use a third-party tokenization service so that no payment data, encrypted or otherwise, is stored within the system. 5.7-7 All devices and systems accepting bank cards for payment will be certified CDRL 5-8 as compliant with the Europay MasterCard Visa (EMV) standards in effect at the time of Final Acceptance, and capable of being certified to newer versions via software upgrades. All devices and systems will default to EMV processing, including the use of offline data authentication (e.g., CDA and DDA), and fall back to non-EMV processing only when it is not supported by the card being used for payment or method of acceptance. 5.7-8 All devices and systems accepting payments will support split payments, or CDRL 5-8 the use of up to three (3) funding sources to complete payment for a single sale, including use of multiple credit/debit cards, transit benefit cards, vouchers, and cash.

AGY-21-008-IT 70 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.7-9 All devices and systems accepting payments will support configurable CDRL 5-8 minimum and maximum payment amounts. The minimum and maximum amounts will be able to be independently set by distribution channel, payment type including by credit/debit card type (e.g., Visa, MasterCard, American Express, and Discover), and device status (i.e. online vs. offline. 5.7-10 All devices and systems accepting debit cards for payment will be able to CDRL 5-8 identify pre-tax benefit cards issued by the government and pre-tax benefit providers based on the Issuer Identification Number (IIN). Stored value and passes loaded using these cards will be identified as such and segregated within the transit account to ensure compliance with all applicable IRS regulations. 5.7-11 The system will maintain payment records to support the auditing of all CDRL 5-8 payments processed and to support payment dispute and chargeback resolution. 5.7-12 The SI shall be fully responsible for acquiring all required bank CDRL 5-8 certifications, including PCI and EMV certifications, for the interfaces to the payment processor and the system as a whole.

5.8 System Security Req # Requirement Assigned CDRL 5.8-1 The SI shall be responsible for ensuring that the system as delivered is compliant with all CDRL 5-9 applicable PCI standards at the time of Final Acceptance, and with all agency, state, and local policies for the handling of Personally Identifiable Information (PII). 5.8-2 All equipment provided or purchased by the SI that will capture, store, transmit, or process CDRL 5-9 bank card data will be certified, by the OEM or SI, as compliant with all applicable PCI standards at the time of Final Acceptance. 5.8-3 The approach to system security will include avoiding the storage of bank card data and PII CDRL 5-9 on field devices and only storing and transmitting such data in a tokenized or encrypted form. 5.8-4 The connection between the frontend devices and back-office will be over an IP network. CDRL 5-9 Where required, the connections will be secured using Transport Layer Security (TLS 1.2) and strong encryption, such as TDEA or AES. All data sent via the internet will be TLS- encrypted using the HTTPS protocol. 5.8-5 All payment data will be secured from the point when it is captured to when it is received CDRL 5-9 by the processor. When communications are over public networks, Virtual Private Networks (VPNs) will be used to increase security. 5.8-6 Firewalls will be established around all virtualized servers, in addition to the use of other CDRL 5-9 traffic filtering security measures where required.

AGY-21-008-IT 71 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.8-7 Physical and logical access to system components that contain PII and/or financial data will CDRL 5-9 be restricted. Physical and logical security will be sufficient for compliance with the PCI standards in effect at the time of Final Acceptance. 5.8-8 Logical access to all supplied systems will require two-factor authentication and be CDRL 5-9 centrally managed using an SI-provided managed user authentication and access control platform based on a vendor-neutral, industry standard protocol, such as Duo. 5.8-9 The SI shall be responsible for providing a PCI compliance plan during design review, and CDRL 5-9 for obtaining certification for the entire system. The SI shall employ a Qualified Security Assessor (QSA) who has been certified by the PCI Security Standards Council as being qualified to assess compliance to the PCI DSS Standard and shall be responsible for conducting all testing required to achieve certification prior to Final Acceptance. 5.8- System security features will be maintained and security issues will be addressed as they CDRL 5-9 10 arise throughout the terms of the warranty and SMA (see Section 15). Operating system updates, software patches, bug fixes, and system enhancements to address identified security issues will be provided. 5.8- Security-sensitive information will be submitted separately, in accordance with procedures CDRL 5-9 11 to be jointly developed between the SI and the agency. Security-sensitive information will include: • Information that would allow an individual to create, duplicate, skim or counterfeit fare media • Information that would allow an individual to overcome security features or interlocks intended to prevent access to sensitive information • Information that would allow an individual to divert revenue, whether electronic or cash revenue, from the system 5.8.12 The SI shall be responsible for ensuring that the system as delivered is compliant with all CDRL 5-9 applicable MDOT security standards as outlined in the latest MDOT Security Manual at the time of each Phase’s Final Acceptance. Today’s current standards can be referenced at https://doit.maryland.gov/Documents/Maryland%20IT%20Security%20Manual%20v1.2.pdf

5.9 Back-office Hosting and Architecture

5.9.1 Cloud-Hosted Environment

Req # Requirement Assigned CDRL 5.9.1-1 Hosting of the back-office will use a public cloud hosting service that CDRL 5-10 provides an Infrastructure as a Service (IaaS) virtual private cloud environment that is provisioned, configured, and managed by the SI over the life of the contract.

AGY-21-008-IT 72 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.9.1-2 The cloud hosting service will deliver a High Availability architecture with CDRL 5-10 built-in redundancy at the physical, logical, and network layers, and guarantee availability (i.e., up time) of at least 99.99% for the virtual private cloud environment. 5.9.1-3 The cloud hosting service will support both static and dynamic resource CDRL 5-10 allocation with the ability to assign a base allocation of compute, memory, and storage resources, and scale dynamically as processing load increases. 5.9.1-4 The cloud hosting service will enable the selection multiple geographic CDRL 5-10 zones within the continental United States for the hosting locations for the physical hardware supporting the virtual private cloud environment. 5.9.1-5 The cloud hosting service will have all physical hardware supporting the CDRL 5-10 virtual private cloud environment at sites meeting the standards of a Tier 3 (or better) data center, as defined by the Uptime Institute. 5.9.1-6 The SI shall be responsible for all back-office operations, monitoring, and CDRL 5-10 maintenance under the back-office operations agreement (see Section 15.3).

5.9.2 Production Back-office Architecture

Req # Requirement Assigned CDRL 5.9.2-1 In addition to the redundancy built-into the virtual private cloud CDRL 5-10 environment, the SI shall design the virtualized system to have full redundancy of the provisioned servers, applications, and databases. 5.9.2-2 The SI shall provision two separate, identical, and fully functional instances CDRL 5-10 of the production back-office within the virtual private cloud environment. 5.9.2-3 Both production back-office instances will be configured to take advantage CDRL 5-10 of dynamic resource allocation, with each having a base allocation of compute, memory and storage resources capable of handling 200% of the anticipated peak processing load when bus, rail, and metro services are in full operation and capable of dynamically scaling to support up to 400% of the anticipated peak processing load without reconfiguration.

AGY-21-008-IT 73 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.9.2-4 Each production back-office instance will include all customer-facing and CDRL 5-10 operation-critical systems, including but not limited to: • Account-Based Transaction Processor • Customer Relationship Management System • System Monitoring and Management Application • Media Inventory Management System • Revenue Management System • Data Warehouse • Reporting System • Web Servers (e.g., supporting customer and institutional websites) 5.9.2-5 Each production back-office instance will include all servers, applications, CDRL 5-10 and databases necessary to independently support the functionality of each back-office component. 5.9.2-6 The SI shall configure each production back-office instance to be CDRL 5-10 supported within the virtual private cloud environment by physical hardware located in different geographic zones within the continental United States. 5.9.2-7 The two production back-office instances will process transactions in CDRL 5-10 parallel in an active-active, load-balanced configuration to optimize system performance and ensure that if one instance fails, or goes into a degraded mode, the second instance will automatically take over processing of all transactions with no downtime. 5.9.2-8 All transaction data will be 100% protected against loss. Each identical and CDRL 5-10 independent production back-office instance will be equipped with the means necessary to mirror data across redundant database instances in real-time (i.e., simultaneous writes). Database redundancy may be handled differently from server and application redundancy, with both production back-office instances accessing the same database with failover to an active (i.e., hot) backup in the event of a failure. 5.9.2-9 This production back-office architecture will support the performance of CDRL 5-10 rolling software upgrades across the two instances with no downtime. 5.9.2-10 The SI shall provide redundant data (i.e., internet) connections to the CDRL 5-10 cloud infrastructure as appropriate for the physical devices and systems being provided 5.9.2-11 The SI shall propose a logical architecture that meets all production back- CDRL 5-10 office architecture requirements for agency review and approval at design review.

AGY-21-008-IT 74 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 5.9.2-12 The automated failover between production back-office instances will be CDRL 5-10 exercised in multiple failover scenarios during system integration testing to demonstrate no data loss or significant degradation in system performance prior to Final System Acceptance.

5.9.3 Non-Production Back-office Instances

Req # Requirement Assigned CDRL 5.9.3-1 In addition to the production back-office instances, the SI shall provide CDRL 5-10 three additional back-office instances (development, test, and staging) for use solely by the MTA and their partners. Any non-production back-office instances required by the SI for their development and support of the system will be separate from those provided for use by the MTA. 5.9.3-2 The non-production back-office instances will have all components CDRL 5-10 (servers, applications, and databases) and configuration necessary to mirror the production back-office instances without the required redundancy of the production back-office. 5.9.3-3 The non-production back-office instances will leverage dynamic resource CDRL 5-10 allocation with the ability to scale to the full resource allocation of the production back-office instances. The base resource allocation for each non-production back-office instance will be agreed to during design review. 5.9.3-4 The SI shall be responsible for supporting and managing the configuration CDRL 5-10 of all non-production back-office instances under the Back-office Operations Agreement (see Section 15.3). 5.9.3-5 The SI shall ensure that the staging back-office instance always mirrors the CDRL 5-10 current configuration and software of the production environment. The development and test back-office instances will be updated to the configuration and software in development, under test, or currently in the production environment at the direction of the MTA. 5.9.3-6 Any of the frontend equipment and systems provided by the SI, including CDRL 5-10 those in the agency test facility (see Section 12.3), as well as those in the field (i.e., production environment) will be capable of being configured to point to one of the non-production back-office instances at the direction of the MTA.

AGY-21-008-IT 75 | Page

APPENDIX 1

5.9.4 Disaster Recovery

Assigned Req # Requirement CDRL 5.9.4-1 The SI shall provide a high availability system that offers maximum CDRL 5-11 protection against data loss and system failure. Means will be provided in the system design to ensure a complete recovery from the loss of any system components at any point during operation. 5.9.4-2 The SI shall develop and submit a disaster recovery plan that describes CDRL 5-11 data backup and recovery, and ensures minimal data loss in the event of a catastrophic event or system failure that impacts the cloud-hosted environment. 5.9.4-3 The disaster recovery plan will contain detailed procedures to be followed CDRL 5-11 to restore the system to full operation following a disaster or failover event, including the complete resynchronization of data across production system instances. 5.9.4-4 The SI shall provide an evaluation of the types of disasters that may impact CDRL 5-11 system operations and detail the steps to be taken to recover from such disasters. 5.9.4-5 SI shall identify the resources (e.g., people, systems, communications, etc.) CDRL 5-11 that must be committed to implement the disaster recovery plan. 5.9.4-6 SI shall train agency staff in all procedures to restore system operations. CDRL 5-11

5.10 Required Submittals Submittal Description Submittal Due No. CDR PDR FDR Other CDRL 5-1 System Architecture Design X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 5-2 System Interface and API X X Required for Phase 1 with Specifications possible updates needed for subsequent Phases CDRL 5-3 Transaction Format X X Will be delivered for each Specifications project Phase’s FDR CDRL 5-4 Open Payment Architecture X X X Required for Phase 2 with possible updates needed for subsequent Phases CDRL 5-5 Fare Media Specifications X X Required for Phase 1 with possible updates needed for subsequent Phases

AGY-21-008-IT 76 | Page

APPENDIX 1

Submittal Description Submittal Due No. CDR PDR FDR Other CDRL 5-6 Cryptographic Key Management X X Required for Phase 1 with Plan possible updates needed for subsequent Phases CDRL 5-7 Transaction Processing Risk X X X Required for Phase 1 with Mitigation Design possible updates needed for subsequent Phases CDRL 5-8 Payment Processing Design X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 5-9 PCI Compliance Plan X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 5-10 Back-office Hosting and X X X Required for Phase 1 with Architecture possible updates needed for subsequent Phases CDRL 5-11 Disaster Recovery Plan X X Required for Phase 1 with possible updates needed for subsequent Phases

6. Fare Structure Requirements The fare payment system will be able to support a variety of fare structure configurations at system launch and in the future. Fare structure includes the supported fare policies, fare media, fare products, and distribution channels through which customers purchase fare media and products. The fare structure will be configurable by the agency and SI and designed to create a simple, unified system that enables interoperability across current and future transit modes without additional development. At a minimum, the fare policies in Exhibit 6-1 will be supported, along with the detailed fare structure configuration requirements in this section.

Exhibit 6-1 Supported Fare Policies Flat Fares Fare Structure Distance- (Point-to-Point) Based Fares Zone-Based Fares Rider Classification-Based Fares Mode-Based Fares (e.g., Bus/Rail) Service Type-Based Fares (e.g., Local/Express) Fare Pricing Location-Based Fares Day- and Time-Based Fares (Peak/Off-Peak) Discount Pricing Stored Value Fare Products Calendar-Based Passes

AGY-21-008-IT 77 | Page

APPENDIX 1

Rolling Passes (Time-Based) Trip-Based Passes Fare Incentives (Bonus Rides) Transfers Interagency Mode-Specific (e.g., Bus-to-Bus, Rail-to-Rail) Intermodal (e.g., Bus-to-Rail, Rail-to-Bus)

Upgrade Transfers (e.g., Local to Express)

6.1 General Requirements Req # Requirement Assigned CDRL 6.1-1 The SI shall design, develop, and implement a fare engine, and the CDRL 6-1 configurable fare sets, business rules, and transaction processing necessary to support the current fare structure and all of the fare structure configuration requirements in the section. 6.1-2 The SI shall work with the agency during design review to develop and CDRL 6-1 submit a preliminary business rules document that describes the fare structure configuration to be deployed at launch. The final fare structure configuration will be defined and documented no later than 120 calendar days before the start of integration testing for the applicable part of the system.

6.2 Fare Pricing Req # Requirement Assigned CDRL 6.2-1 The fare system will support single-tap (or “flat”), distance-based (point- CDRL 6-1 to-point), and zone-based fare pricing that is fully configurable based on the following parameters at a minimum: • Rider classification • Mode • Service type • Location • Day and time • Discounts These fare pricing parameters will also govern the acceptance or denial of fare products being used for payment (see Section 6.3) and the granting of transfers (see Section 6.4).

AGY-21-008-IT 78 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.2-2 The default fare set will be associated with transit accounts that have an CDRL 6-1 Adult rider classification. Additional rider classifications will be able to be defined and associated with unique fare sets, including but not limited to Child, Youth, Student, College, Senior, Disabled, Paratransit, Local, and Visitor. Rider classifications will be able to be modified manually or automatically based on customer date of birth or the granting of a temporary classification with a configurable end date. 6.2-3 Fare pricing will be able to be configured based on the mode being CDRL 6-1 traveled. The agency will be able to add new modes, transit agencies, and system participants (e.g., parking and bike share) with unique fare pricing as needed and without additional development. 6.2-4 The fare system will support premium pricing for certain types of service CDRL 6-1 (e.g., express bus or rail service). Service-based fare pricing will be able to be configured for a single route or group of routes. 6.2-5 The fare system will support location-based fares, or the ability to price CDRL 6-1 fares based on the location of payment (e.g., rail at the or bus at specific stop locations). Location-based fare pricing will be able to be configured based on the station location programmed into the rail devices, or the geo-location information captured from the CAD/AVL system onboard vehicles. 6.2-6 The fare system will support fare pricing based on the time of day and day CDRL 6-1 of the week (e.g., peak, and off-peak fares). Peak/off-peak fare pricing will be able to be configured for specific fare classifications, modes, and service types, and put into effect at all times or on a scheduled basis (e.g., every weekday). 6.2-7 The fare system will support the offering of discounted fares on a CDRL 6-1 temporary and permanent basis, up to and including the offering of free fares. Discounted fare pricing will be able to be configured for specific fare media types, rider classifications, modes, service types, and routes, and put into effect indefinitely or for a defined period (e.g., from June 5 to June 7).

6.3 Fare Products Req # Requirement Assigned CDRL 6.3-1 The fare system will support stored value, which will serve as an electronic CDRL 6-1 cash-equivalent, and will be accepted for payment across all modes and services. When stored value is used for payment, the system will deduct the correct fare at each boarding or entry in real-time from the account, based on the fare pricing configuration described in Section 6.2.

AGY-21-008-IT 79 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.3-2 The fare system will support calendar passes that are valid for unlimited CDRL 6-1 rides during a pre-defined calendar period. Calendar passes will be configurable to be valid for any calendar period from one (1) day to two (2) years, including periods that are bounded by specific dates (e.g., valid from Aug. 16 through May 14). 6.3-3 The fare system will support rolling passes that are valid for unlimited CDRL 6-1 rides for a pre-defined period starting at pass activation, which may occur upon sale or first use. Rolling passes will be configurable to be valid for a continuous duration from 30 minutes to two (2) years (e.g., valid for 24 hours from first use), or bounded by a service period (e.g., valid from first use through the end of the service day). 6.3-4 The fare system will support trip-based passes that are valid for a pre- CDRL 6-1 defined number of trips. Trip-based passes will be able to be configured to be valid for anywhere from one (1) to 100 trips, and to include transfer privileges or not (see Section 6.4). 6.3-5 The acceptance or denial of pass products for use on a particular mode or CDRL 6-1 service will be able to be configured based on all of the fare pricing parameters described in Section 6.2. Pass product will be able to be configured as mode-specific (e.g., valid for bus only) or joint passes (e.g., valid for bus and rail). 6.3-6 All pass products will be able to be configured with a grace period which CDRL 6-1 extends the validity for a set period of time (e.g., 30 minutes) or a number of rides (e.g., one ride). 6.3-7 Transit accounts will be able to contain multiple fare products CDRL 6-1 simultaneously (e.g., stored value and a pass product). One transit account will be able to support up to 10 unique fare products, including active and multiple inactive instances of the same product. Order precedent rules, to be defined during design review, will determine which fare products are used first and under which scenarios. 6.3-8 Pass products will be able to be configured to grant a partial credit CDRL 6-1 towards a fare for a premium service. In this scenario, the remainder of the fare, or “upgrade fare,” will be deducted from stored value. If the customer does not have enough stored value in their account to cover the upgraded fare, the ride will be denied. 6.3-9 The fare system will support fare incentives based on bonus rides. Ride CDRL 6-1 bonuses will be able to be configured to grant a free number of rides after a certain number of rides have been paid for using stored value or a trip- based pass (e.g., ride 10 times, get one free).

AGY-21-008-IT 80 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.3-10 The fare system will support the assessment of a configurable dormancy CDRL 6-1 fee against stored value balances following a period of transit account inactivity. The assessment of dormancy fees will be defined during design review and will comply with all applicable state and federal regulations.

6.4 Transfers Req # Requirement Assigned CDRL 6.4-1 The fare system will support the granting of a transfer fare credit for a CDRL 6-1 boarding (e.g., fare payment) that occurs within a defined time period of another. The transfer period (e.g., the time during which a boarding is eligible for a transfer) will be configurable. 6.4-2 Transfers will be supported for customers that pay fares using stored value CDRL 6-1 and trip-based pass products. 6.4-3 The granting of a transfer fare credit, the credit amount, and transfer CDRL 6-1 validity will be able to be configured based on all of the fare pricing parameters described in Section 6.2. Transfers will be able to be configured as mode-specific (e.g., valid for bus-to-bus only) or intermodal and will be designed to prevent round-tripping. 6.4-4 Transfers will be able to be configured to grant a partial credit towards a CDRL 6-1 fare for a premium service. In this scenario, the remainder of the fare, or “upgrade fare,” will be deducted from stored value. If the customer does not have enough stored value in their account to cover the upgraded fare, the ride will be denied.

6.5 Fare Capping Req # Requirement Assigned CDRL 6.5-1 The fare system will support fare capping based on configurable calendar CDRL 6-1 periods (i.e., “capping periods”) When a spending threshold (i.e., “fare cap”) is reached, a customer will be entitled to free or discounted rides on configured services for the remainder of the capping period. 6.5-2 For each combination of a rider classification, calendar period, and service CDRL 6-1 type for which fare capping will be used to confer a benefit (i.e., each calendar-based pass being replaced), a unique fare cap will be configured, and a unique record of spending (i.e., “fare accumulator”) will be maintained for each customer. There will be no limit on the number of concurrent fare caps supported by the system.

AGY-21-008-IT 81 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.5-3 For any fare paid on a service, the agency shall be able to configure unique CDRL 6-1 accumulation rules associated with each of the fare caps providing a benefit on that service. These rules will support the accumulation of either the full or a partial amount of the fare paid by the customer, independent of whether the amount paid is the full fare for the service or discounted due to transfer, upgrade, or the reaching of a fare cap. 6.5-4 For each fare cap, the agency shall be able to configure the services for CDRL 6-1 which a benefit is provided, including providing free or discounted rides on for the remainder of the capping period. When a discount is provided, an “upgrade fare” will still need to be paid by the customer. Based on the configured rules, the upgrade fare may be accumulated towards a higher tier (e.g., free ride or longer duration) fare cap for the same service. 6.5-5 At the end of a capping period fare accumulators for any fare cap CDRL 6-1 associated with that period will be reset for all customers.

6.6 Fare Distribution and Management

6.6.1 Fare Media and Product Sales

Req # Requirement Assigned CDRL 6.6.1-1 The extended-use (EU) fare media will be associated with closed-loop CDRL 6-1 transit accounts that will be able to be loaded with all of the fare product types described in Section 6.3. If the agency chooses to issue limited-use (LU) fare media in the future (see Section 5.5), the associated transit accounts will be able to be loaded with all of the same fare product types. 6.6.1-2 The fare system will support a one-time charge, or “card fee,” for issuance CDRL 6-1 of new fare media. This card fee will be able to be configured based on the fare media type, rider classification, and distribution channel, and may be set to zero for specific fare media types or for sales through specific channels. 6.6.1-3 The fare system will support replacement card fees, which will be able to CDRL 6-1 be configured based on fare media type and replacement thresholds (e.g., the first replacement is free and each successive replacement associated with the same account is $5). 6.6.1-4 The ability to load a particular fare product to a transit account will be CDRL 6-1 configurable based on the fare media type and rider classification associated with the account.

AGY-21-008-IT 82 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.6.1-5 The loading of stored value will be restricted based on configurable CDRL 6-1 parameters, including the minimum and maximum amount that can be loaded in a single transaction, and the maximum amount that a transit account can contain.

6.6.2 Account Registration

Req # Requirement Assigned CDRL 6.6.2-1 Adult customers will have the option of registering a transit account or CDRL 6-1 remaining anonymous. All transit accounts with a reduced fare rider classification will require registration. 6.6.2-2 A registered transit account will be associated with an individual and/or CDRL 6-1 institutional customer account maintained within the CRM system customer database (see Section 8.3.2). 6.6.2-3 Customer data maintained in an individual customer account will include CDRL 6-1 at a minimum: • Name • Address • Phone number • E-mail address • Username • Password • IVR system PIN • Security questions and answers 6.6.2-4 Customer data maintained in an institutional customer account will CDRL 6-1 include at a minimum: • Institution Name • Administrator Name • Address • Phone number • E-mail address • Administrator Username • Administrator Password • Security questions and answers • All configuration parameters governing the institution’s participation in a special fare program (see Section 6.6.4).

AGY-21-008-IT 83 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.6.2-5 Individual and institutional customers will have the option of providing CDRL 6-1 payment information to be stored by the system and available for future one time purchases or for the recurring loading of value (see Section 6.6.3). A customer will be able to store a maximum of three (3) funding sources. 6.6.2-6 Customer account creation and transit account registration will be able to CDRL 6-1 be performed using the websites (see Section 9), Customer Service Terminal (see Section 7.7), and through the call center via the CRM system (see Section 8.3). 6.6.2-7 The system will allow a customer account to be created without CDRL 6-1 associating (e.g., registering) a transit account, and will allow multiple transit accounts to be registered to the same customer account for consolidated transit account management through all customer service channels. 6.6.2-8 Transit accounts will be able to be associated with both individual and CDRL 6-1 institutional customer accounts and will be able to be registered to both an individual and institutional customer at the same time. 6.6.2-9 Minimal card personalization information (e.g., customer/card name, rider CDRL 6-1 classification, and DOB) may also be stored securely in the transit account, and/or on the media, to support fare processing and allow for the individual tracking of fare media registered to the same customer.

6.6.3 Autoload

Req # Requirement Assigned CDRL 6.6.3-1 Customers and agency staff will have the ability to set up fare products CDRL 6-1 (e.g., stored value and passes) for autoload, or to automatically reload based on time or value thresholds. The SI shall enable this functionality through the Customer Service Terminal (see Section 7.7), CRM system (see Section 8.3), and customer and institutional websites (see Section 9). 6.6.3-2 Enabling autoload will require that the associated transit account be CDRL 6-1 registered and that an accepted funding source, such as a credit or debit card, or transit benefit allocation, is linked to the customer account. 6.6.3-3 A customer will be able to have two (2) funding sources associated with an CDRL 6-1 autoload, a primary funding source, and a secondary funding source, and may split payment between them, or use the secondary funding source as a backup in the event that the primary fails.

AGY-21-008-IT 84 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.6.3-4 The autoload feature will support both threshold-based triggers (i.e., CDRL 6-1 reloading when the stored value balance, remaining trip balance, or remaining validity period falls below a configurable threshold), and calendar-based triggers (i.e., reloading on a configurable date every month). 6.6.3-5 All parameters governing threshold and calendar-based autoloads will be CDRL 6-1 fully configurable by the customer and agency staff, including the enabling or disabling of an autoload, threshold value (e.g., trigger), funding source, and fare product and/or amount to be loaded. Final configuration parameters will be defined during design review. 6.6.3-6 The account-based nature of the fare system will allow for autoload CDRL 6-1 payment authorization to occur prior to the loading of any value, and immediate use of the value by the customer once the load occurs. If payment authorization fails, the autoload will be automatically disabled.

6.6.4 Special Fare Programs

Req # Requirement Assigned CDRL 6.6.4-1 The fare system will support special fare programs, or institutional CDRL 6-1 programs, with a unique fare distribution channel, fare products, and business rules. 6.6.4-2 The fare system will support the current range of special fare programs CDRL 6-1 offered by MTA, and future programs, including but not limited to: • Paratransit (e.g., MobilityLINK) program • Locally Operated Transit Service partners • U-Pass and other college programs • Department of Education (DOE) and other schools’ (K-12) programs • Corporate and employer programs • Government and military programs • Social service agency programs • Local attraction and tourist programs • Partner programs supporting transit-related services, including parking, bike share, and tourist transportation (e.g., trolleys) Special fare programs and their associated fare media, fare products, and business rules will be defined during design review.

AGY-21-008-IT 85 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.6.4-3 The fare system will support the printing of personalized special fare CDRL 6-1 program media using the Customer Service Terminal (see Section 7.7), and in the future, may accept media issued by third-parties (see Section 5.5.6), including but not limited to: • Reduced fare cards (youth, senior, disabled, etc.) • Paratransit cards • Employee IDs • College and school IDs • Military IDs • Temporary tourist cards Rider classifications associated with unique fare pricing (see Section 6.3) will be supported for special fare programs and media. 6.6.4-4 Fare products offered through special fare programs will be distributed CDRL 6-1 through the institutional website (see Section 9.3), and will not be available to the general public, with the exception of stored value. 6.6.4-5 At a minimum, the following configuration parameters will be supported CDRL 6-1 to govern an institution’s participation in special fare programs: • Program type (e.g., direct load, post-bill, or media order-only) • Available fare media • Available fare products • Fare media and product pricing • Fare media and product ordering windows • Payment type (e.g., prepay or invoice) • Payment terms The special fare program configuration parameters will be set by the agency during the registration of an institutional customer and will be stored in the institutional customer account (see Section 9.3). 6.6.4-6 Special fare programs will include post-bill programs where the institution CDRL 6-1 is invoiced based on the participants’ actual usage of the system. For these programs, the participants’ transit accounts will be loaded with an unlimited-ride pass, and the system will calculate the amount due on a monthly basis using pass ridership data and an agency-defined formula. 6.6.4-7 Special fare programs will include fare sales using pre-tax transit benefits CDRL 6-1 funds. Stored value and passes loaded through transit benefit programs will be identified as such and segregated within the transit account to ensure compliance with all applicable IRS regulations. 6.6.4-8 Special fare programs will include the bulk sale of fare media. If the agency CDRL 6-1 chooses to support limited-use media in the future, bulk sales will include LU media where the associated transit accounts are pre-loaded with value.

AGY-21-008-IT 86 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.6.4-9 The SI shall support the migration of data from any existing databases used CDRL 6-1 for the administration of special fare programs, including data on qualified schools, employers, government agencies, and social service agencies.

6.7 Fraud Detection Req # Requirement Assigned CDRL 6.7-1 The fare system will support fraud prevention policies, including the ability CDRL 6-2 to automatically identify suspect usage patterns based on sales and ridership data, and block the use of fare media, transit accounts, and fare products based on configurable fraud rules. 6.7-2 The fare system will support agency-configurable velocity checks, and CDRL 6-2 other fraud prevention measures, that identify excessive or potentially fraudulent use of stolen or compromised fare media. 6.7-3 The fare system will support the setting of a configurable upper limit of CDRL 6-2 rides for unlimited ride passes (e.g., 50 rides for a one-day pass) that will generate an automated alert within the system, and optionally block the fare media or product, when the limit is reached. 6.7-4 The fare system will detect and generate an automated alert for potential CDRL 6-2 fraudulent duplication of fare media if the same card or account is used for payment in two geographically separated locations within a configurable period of time. 6.7-5 For transit accounts with stored value, the system will support the CDRL 6-2 configuration of a “floor limit,” or value below which the account balance is not allowed to fall (so long as the device generating a fare payment is online). The floor limit may be configured to be a zero or negative balance. Transit accounts with balances at or below the floor limit will be able to be automatically blocked by the system. 6.7-6 The fare system will support configurable rules to prevent the sharing of CDRL 6-2 fare media and accidental payments through “passback protection,” or a configurable time period in which a card will not be accepted for payment at a device after an initial tap. Passback protection will be able to be configured by fare media type, fare product, and rider classification, and will be able to be enforced at the bus, rail station, and individual device level. 6.7-7 The fare system will support the placing of fare media and transit accounts CDRL 6-2 into “observation mode”, which will generate an automated alert when the fare media or account is used. This may be used by fare enforcement staff to monitor known stolen or compromised fare media or transit accounts.

AGY-21-008-IT 87 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.7-8 The blocking of fare media, transit accounts, and individual fare products CDRL 6-2 will be able to be performed automatically and manually, and on an individual and bulk basis (e.g., if a known batch of cards was lost, the entire batch may be blocked). 6.7-9 Additional fraud prevention policies may be defined during design review. CDRL 6-2

6.8 Configuration Management Req # Requirement Assigned CDRL 6.8-1 The system will include fare configuration management tools to support CDRL 6-3 fare distribution, payment, and inspection processing by the Account- Based Transaction Processor (see Section 8.2) and associated devices. 6.8-2 The configuration of fare sets, including all fare tables, fare rules, and CDRL 6-3 other parameters necessary to support the fare structure configuration described in this section, will be accessible and modifiable using the SI- provided tools. 6.8-3 The system will be able to manage, store, and deploy an active fare set and CDRL 6-3 at least two (2) pending fare sets. An active fare set will become effective immediately upon publication. Pending fare sets will be able to be activated manually or automatically based on a future activation date configured within the tools. 6.8-4 The configuration of the fare products available for sale and fare product CDRL 6-3 pricing with be accessible and modifiable using the SI-provided tools. Available fare products and pricing will be able to be configured by sales channel, location, and individual device. 6.8-5 To the extent that any fare product availability and pricing information is CDRL 6-3 maintained locally at the devices, the system will publish this information for distribution. Devices that are not in communication at the time of distribution will receive updates as soon as communications are reestablished. 6.8-6 The system will publish fare media positive and negative lists generated CDRL 6-3 and used by the account-based transaction processor, and distributed to devices, to support the risk mitigation techniques discussed in Section 5.6. Positive and negative list updates will be published no less than every five (5) minutes and include version control to ensure timely and accurate synchronization. 6.8-7 All configuration parameters distributed to the devices, including positive CDRL 6-3 and negative list updates, will be distributed using the SI-provided device management API (see Section 5.3.1.7).

AGY-21-008-IT 88 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 6.8-8 All fare structure configuration described in this section will be able to be CDRL 6-3 performed by the agency, as well as by the SI during implementation and throughout the warranty and software maintenance agreement terms (see Section 15).

6.9 Required Submittals Submittal Description Submittal Due No. CDR PDR FDR Other CDRL 6-1 Business Rules X X Required for all Phases CDRL 6-2 Fraud Detection Design X X X Required for all Phases CDRL 6-3 Fare Configuration Management X X X Required for all Phases Design

7. Fare Equipment Requirements 7.1 Common Equipment Requirements

7.1.1 General Requirements

Req # Requirement Assigned CDRL 7.1.1-1 All customer-facing equipment will be designed to adhere to the aesthetic CDRL 7-1 standards of the agency, with consistent cross-platform branding. The SI shall submit designs for review and approval during design review. Final equipment design, including interface display, lettering, lights, colors, color contrast to aid visually impaired, tactile feedback, brightness, graphics, animation, screen savers, surface texture, component size and height, and hardware will be subject to agency approval. 7.1.1-2 All customer-facing equipment shall provide a coherent customer CDRL 7-1 experience, with a similar look and feel across bus and station validators, TVMs, and faregates. Agency and designated representatives will participate in an industrial design review with the SI to define the customer experience for both hardware and software. 7.1.1-3 System equipment displays (including the entire surface of the display for CDRL 7-1 the TVM), graphics, signage, and all other instructions, labels, and information contained on the equipment will be visually readable within all common positions from a customer point of view.

AGY-21-008-IT 89 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.1.1-4 System equipment will provide customers with displays, graphics, signage, CDRL 7-1 controls, and mechanisms that are simple to use, easy to understand, and conveniently located. By following instructions given on and by the equipment, an inexperienced user shall be able to understand all transaction processes and results. All such user interfaces will be user- friendly; that is, safe, predictable, simple to use, and in accordance with other applicable human engineering principles. 7.1.1-5 System equipment will accommodate the broad range of customers that CDRL 7-1 use public transportation. The range of customers paying fares will include commuters, infrequent riders (including tourists), children, the elderly, customers with impaired vision, customers in wheelchairs, customers with limited communications skills, including the illiterate, and customers who are hearing impaired.

7.1.2 Hardware

Req # Requirement Assigned CDRL 7.1.2-1 Fare equipment will satisfy all applicable common hardware design CDRL 7-1 requirements specified in Section 4 including: • Service-proven design • Nonproprietary technology • Supply and availability • Materials and workmanship • Maintainability and serviceability • Operating environment • ADA compliance • Code and regulation compliance 7.1.2-2 Equipment components will be designed, built, and installed for the harsh CDRL 7-1 operating environment specified in Section 4.7 7.1.2-3 All equipment will meet the applicable hardware security requirements in CDRL 7-1 Section 5.8.

AGY-21-008-IT 90 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.1.2-4 All equipment that reads fare media for the purpose of fare distribution or CDRL 7-1 validation will include a contactless reader that supports all common ISO- 14443 (Type A and B), ISO-18092 (NFC), and closed-loop (e.g., the entire MIFARE product line) media formats, in addition to all open payment contactless standards, including but not limited to: • VISA payWave® • MasterCard PayPass® • American Express ExpressPay® • Discover Zip® • Contactless EMV (e.g., Google Pay/Apple Pay) 7.1.2-5 A metal identification label inscribed with the equipment serial number CDRL 7-1 will be permanently attached to the outside of each piece of equipment. 7.1.2-6 All equipment design, including dimensions, mounting options, and CDRL 7-1 installation placement will be subject to review and approval by the agency.

7.1.3 Software

Req # Requirement Assigned CDRL 7.1.3-1 Equipment software will employ software that satisfies the common CDRL 7-1 design requirements in Section 4, including: • Nonproprietary technology • Software design principles • Licensing and ownership • ADA compliance • Code and regulation compliance The agency has a strong preference for service-proven hardware. 7.1.3-2 All equipment will meet the applicable software security requirements in CDRL 7-1 Section 5.8. 7.1.3-3 All equipment will employ a current or recent version of a COTS operating CDRL 7-1 system. The operating system will be capable of performing all tasks necessary to support the equipment and its applications, including the ability to multitask, manage memory, maintain performance without degradation, and communicate with the back-office in real-time. 7.1.3-4 All equipment will maintain local transaction records in non-volatile CDRL 7-1 memory in the event that communications to the back-office are unavailable. Local records will not be deleted until they have been confirmed as received and recorded by the back-office.

AGY-21-008-IT 91 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.1.3-5 The design of the system will provide a mechanism to recover transactions CDRL 7-1 or other data stored on faulty equipment that has not been transmitted to the back-office. 7.1.3-6 All customer-facing system equipment will incorporate a test mode. In this CDRL 7-1 mode, the equipment will have full functionality and process only test media. Test transactions shall be segregated in reporting from revenue service transactions.

7.1.4 Configuration

Req # Requirement Assigned CDRL 7.1.4-1 All equipment will be remotely monitored, configured, and managed CDRL 7-1 through the SMMA (see Section 8.4) using the device management API (see Section 5.3.1.7). Equipment software and configuration updates, including all positive and negative lists, will be managed through this system. 7.1.4-2 All equipment will receive date/time, fare table, configuration, and list CDRL 7-1 updates from the back-office at startup and as necessary. Additionally, equipment will automatically synchronize with the back-office throughout the day using Network Time Protocol and other means to update configuration and list data. 7.1.4-3 All equipment will be able to receive multiple account lists from the back- CDRL 7-1 office including, but not limited to, positive and negative lists. These lists will help improve passenger dwell time and mitigate risks from offline operation. All local lists will be updated based on changes since the last update at a configurable interval of no less than every five (5) minutes. 7.1.4-4 The equipment software and applications will accommodate Baltimore’s CDRL 7-1 existing fare structure and potential fare policies described in Section 6. 7.1.4-5 All equipment will include the flexibility to ensure that future Baltimore CDRL 7-1 fare policy will be satisfied without software modifications. All fare policy modifications will be through fare table and other configuration changes, downloadable from the back-office. 7.1.4-6 The back-office and, as needed, the equipment will be capable of CDRL 7-1 supporting at least three (3) fare tables (one current and two future), which includes all fare and configuration data required to sell and validate fare products. 7.1.4-7 Fare tables will be individually and dynamically configurable for specific CDRL 7-1 pieces of equipment and by location or station. Such configurability may be automatically or manually set.

AGY-21-008-IT 92 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.1.4-8 Equipment will receive configuration and software updates when available CDRL 7-1 from the back-office. The equipment will not commence updating software until it has received and verified the complete update. If any updates require a reboot, they will occur during non-operating hours, unless specifically approved by authorized service staff. 7.1.4-9 Each update will have a unique version number and include an activation CDRL 7-1 date and time if applicable. Updates will be able to be downloaded and applied at that activation time or activated immediately after download and verification are confirmed. 7.1.4-10 The download process will not interrupt normal equipment operations, or CDRL 7-1 cause data or file corruption if communication is lost. The process will recover from such loss and complete the download without issue.

7.2 Fare Payment Validator

7.2.1 General Requirements

Req # Requirement Assigned CDRL 7.2.1-1 If the Fare Payment Validator (FPV) is purchased from a third-party, the SI CDRL 7-2 shall deliver the latest generation device manufactured by the OEM. If a newer generation device is released following design review, but prior to device procurement, the agency shall have the option to upgrade to the newer device. 7.2.1-2 FPVs will accept all the fare media specified in Section 5.5 including the CDRL 7-2 following fare media at a minimum: • Agency-issued extended-use media • Agency-issued limited-use media • Third party-issued media 7.2.1-3 FPVs will be PCI- and EMV-certified for the acceptance of bank-issued CDRL 7-2 contactless credit and debit cards using all common formats based on the latest version of the standard at the time of Final Acceptance. FPVs will be capable of re-certification with newer versions of the PCI and EMV standards via software upgrades, as necessary. 7.2.1-4 FPV software design will allow for accepted media formats, including user- CDRL 7-2 defined formats, to be enabled and disabled via configurable parameters. 7.2.1-5 The readers will be able to be updated via firmware to support new card CDRL 7-2 formats in the future.

AGY-21-008-IT 93 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.1-6 FPVs will support a minimum of two (2) Secure Access Modules (SAMs) to CDRL 7-2 facilitate acceptance of multiple fare media formats and the replacement of security keys, should a compromise occur. 7.2.1-7 FPVs will have at least three (3) spare universal serial bus (USB) to CDRL 7-2 support removable memory, Secure Access Modules (SAMs), or future connection of ancillary devices, such as a barcode reader. 7.2.1-8 FPVs will include sufficient embedded storage to hold at least 30 days of CDRL 7-2 fare payment transactions, and all risk mitigation lists (see Section 5.6) as determined necessary during design review. 7.2.1-9 FPVs will support expandable storage in a common, commercially available CDRL 7-2 format (e.g., USB drive, compact flash, secure digital, etc.) that can be quickly and easily swapped or expanded without modification to the rest of the device components. 7.2.1-10 An alternate means of downloading data from the FPV shall be provided CDRL 7-2 for instances where there is a failure of the wired or wireless communication.

7.2.2 Hardware

7.2.2.1 Enclosure

Req # Requirement Assigned CDRL 7.2.2.1-1 The FPV will be as simple and compact as possible while providing the CDRL 7-2 required functionality in this section. 7.2.2.1-2 FPVs will be rugged and function under extended severe environmental CDRL 7-2 conditions including: direct sunlight, moisture, dust/grit/sand, humidity, electrical storms, exposure to an urban environment, and the range of elevations and altitudes in the operating region (see Section 4.7). 7.2.2.1-3 The FPV housing will be resistant to corrosion, abrasion, scratching, CDRL 7-2 impacts, and vandalism, and withstand standard bus cleaning and disinfectant materials. Validator housing color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and peeling. 7.2.2.1-4 All FPV corners will be rounded, and there will be no exposed bolt heads, CDRL 7-2 nuts, sharp edges, or cracks on outside surfaces. The FPV display will be flush mounted in the housing. 7.2.2.1-5 Covers on the validator housing for accessing modules and subassemblies CDRL 7-2 will be secured with mechanical locks and keys that are not readily duplicated nor readily available to the public, and uniquely serialized and stamped “Do Not Duplicate.”

AGY-21-008-IT 94 | Page

APPENDIX 1

7.2.2.2 Bus Installation and Mounting

Req # Requirement Assigned CDRL 7.2.2.2-1 The FPV will be installed on each bus such that the reader will be in CDRL 7-2 proximity to the front and/or back door, and will be positioned so that a customer may easily present fare media for payment upon boarding the bus. 7.2.2.2-2 All required mounting hardware and brackets for each bus type will be CDRL 7-2 provided by the SI. 7.2.2.2-3 The FPV and components will be securely mounted using steel hardware in CDRL 7-2 a location and manner that is safe for customers and operators. 7.2.2.2-4 When installed, the FPV will not obstruct the operator’s view out the CDRL 7-2 vehicle windows and will not cause glare on the windshield during bright sun conditions or at night with the vehicle interior lights off. 7.2.2.2-5 The FPV will be designed and mounted so that it can be adjusted for CDRL 7-2 optimal operating and viewing angle while minimizing sun glare and not causing window screen glare impacting safe bus operations. After adjusting, the mounting hardware will not allow the FPV to shake or become loose as a result of shock and vibration encountered during normal bus operation. The mounting adjustments will not require special tools. 7.2.2.2-6 Mounting will not interfere with the maintenance of other onboard bus CDRL 7-2 systems and components. 7.2.2.2-7 FPV design and mounting will be compliant with all applicable ADA CDRL 7-2 requirements and will be approved by agency ADA compliance officers. 7.2.2.2-8 All FPV components, cabling, installation methods, and mounting will be CDRL 7-2 prototyped on each bus type and subject to written approval by the agency before installation.

7.2.2.3 Rail Station Installation and Mounting

Req # Requirement Assigned CDRL 7.2.2.3-1 The FPV will be positioned so that a customer may easily present fare CDRL 7-2 media for payment on the platform. 7.2.2.3-2 All required mounting hardware, stainless steel masts, and brackets will be CDRL 7-2 provided by the SI. 7.2.2.3-3 The FPV and components will be securely mounted using stainless steel CDRL 7-2 hardware in a location and manner that is safe for customers and maintenance personnel.

AGY-21-008-IT 95 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.2.3-4 When installed, the FPV will not obstruct access to the station platform CDRL 7-2 and vehicle(s). 7.2.2.3-5 The FPV will be designed and mounted so that it can be adjusted for CDRL 7-2 optimal operating and viewing angle while minimizing sun glare. After adjusting, the mounting hardware will not allow the FPV to shake or become loose as a result of shock and vibration encountered during normal rail operation. The mounting adjustments will not require special tools. 7.2.2.3-6 FPV design and mounting will be compliant with all applicable ADA CDRL 7-2 requirements and will be approved by agency ADA compliance officers. 7.2.2.3-7 All FPV components, cabling, installation methods, and mounting will be CDRL 7-2 prototyped and subject to written approval by the agency before installation. 7.2.2.3-8 Each light rail station stainless steel mast will be designed to support up to CDRL 7-2 two (2) FPVs on each side of the mast, and if any power or communication equipment inside the mast requires maintenance, a secure access door must be incorporated. 7.2.2.3-9 Each mast must include a waterproof, vandal-proof sign-holder and sign CDRL7-2 affixed to the mast to support the display of basic, printed customer information (e.g., branding, how-to information, etc.). Final design will be determined during design review.

7.2.2.4 Power

Req # Requirement Assigned CDRL 7.2.2.4-1 For bus installation, the FPV will receive 12 or 24 VDC power through a CDRL 7-2 circuit breaker assigned specifically to the FPV. External converters or power conditioners may be used with agency approval. 7.2.2.4-2 When bus power is turned off, the FPV will remain powered for a CDRL 7-2 configurable time to allow completion of transmission of any and all data files, transaction records, and fare tables.

7.2.2.5 Bus validator Communications

Req # Requirement Assigned CDRL 7.2.2.5-1 The FPV will communicate with the back-office through the existing mobile CDRL 7-2 data router

AGY-21-008-IT 96 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.2.5-2 The FPV will include an Ethernet that enables connection to a mobile CDRL 7-2 data router and other devices, as necessary. 7.2.2.5-3 It's preferred that the FPV will have an embedded modular cellular modem CDRL 7-2 that supports communication over 4G/LTE (or faster) data networks on all major US carriers. The cellular modem may be used when a mobile data router is not available. 7.2.2.5-4 It's preferred that the FPV will have an embedded Wi-Fi (802.11 ac or CDRL 7-2 better) communications module to enable communication over Wi-Fi networks, including the sharing of data with other onboard systems, and download of larger lists and software updates. The Wi-Fi communications module may be used in instances where a mobile data router is not available. 7.2.2.5-5 If additional communications components are required, all such CDRL 7-2 components will be mounted in a secure and sturdy enclosure, with the location and function approved by the agency.

7.2.2.6 Rail Station Validator Communications

Req # Requirement Assigned CDRL 7.2.2.6-1 The FPV will communicate with the back-office through a hardwired CDRL 7-2 connection at stations and platforms for power and data communications. 7.2.2.6-2 At stations where hardwired communications are not feasible, the MTA CDRL 7-2 may explore the use of an embedded modular cellular modem that supports communication over 4G/5G data networks on all major US carriers. 7.2.2.6-3 At stations where a hardwired connection is not feasible, the FPV will have CDRL 7-2 an embedded Wi-Fi (802.11 ac or better) communications module to enable communication over Wi-Fi networks. 7.2.2.6-4 If additional communications components are required, all such CDRL 7-2 components will be mounted in a secure and sturdy enclosure, with the location and function approved by the agency.

7.2.2.7 Customer Interface

Req # Requirement Assigned CDRL 7.2.2.7-1 A customer-facing contactless smartcard reader will be installed in the FPV CDRL 7-2 to read, write to, and validate contactless media presented by customers.

AGY-21-008-IT 97 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.2.7-2 FPVs will include full-color displays that support adjustable brightness, CDRL 7-2 contrast, and refresh rate that can be easily read under any combination of ambient lighting, including direct sunlight and night-time operation. 7.2.2.7-3 FPV color displays may be separate from or integrated with the contactless CDRL 7-2 reader. In either case, the tap area will be easily identified and reachable by customers. 7.2.2.7-4 The display will be clearly visible in all forms of ambient light on the bus CDRL 7-2 and at stations and viewable at a minimum angle of 45 degrees from the display. 7.2.2.7-5 The FPV display will be capable of partial or full video or animation. The CDRL 7-2 animations may be used to indicate fare feedback, relevant customer action, or other general information. Video or animation files will be able to be updated remotely or installed via removable memory by maintenance staff. Supported video types will be agreed upon during design review (e.g., JPG, GIF, PNG, MP4, etc.) 7.2.2.7-6 FPVs will include at least three (3) multicolor light-emitting diode (LED) CDRL 7-2 indicator lights that can be configured to provide feedback on payment and device status. 7.2.2.7-7 FPVs will include an audio interface and speakers for customizable audio CDRL 7-2 feedback, including varying tones and full speech. Audio feedback types will be able to be configured and updated remotely. 7.2.2.7-8 FPVs will support customizable visual and audible feedback for a variety of CDRL 7-2 different rider classes, authorized transactions, denied transactions, fares charged, and general account information and statuses. Customizations will be finalized during design review. 7.2.2.7-9 The decibel levels of the tones will be programmable locally and remotely, CDRL 7-2 and the emitted tones will be capable of being distinguished up to eight (8) feet away.

7.2.2.8 Fare Payment Validator Barcode Reader

Req # Requirement Assigned CDRL 7.2.2.8-1 The SI will provide a 2D barcode reader to enable the validation of QR (or CDRL 7-2 Aztek) codes. The barcode reader may be integrated with or separate from the FPV.

AGY-21-008-IT 98 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.2.8-2 The barcode reader will be optimized for scanning QR codes from mobile CDRL 7-2 screens and will accommodate a wide range of mobile device screen sizes and QR code sizes, environmental factors (e.g., sun glare, phone screen protectors, and usability factors (e.g., scanning QR code at angles ranging from 0 to 45 degrees). 7.2.2.8-3 The barcode reader will be able to accommodate real-world environmental CDRL 7-2 factors such as different scanning angles at varying distances from the reader and shall be designed to maximize usability without customer education. 7.4.2.1-7 The barcode reader will have a LED aimer and a minimum 752x480 pixel CDRL 7-2 sensor. 7.4.2.1-7 The MTA prefers a forward or upward facing mirrored configuration with a CDRL 7-2 scan range between 0” (flush) and 6” from the barcode reader.

7.2.3 Software

7.2.3.1 Transaction Records

Req # Requirement Assigned CDRL 7.2.3.1-1 FPVs will generate, store, and transmit a discrete data record for each CDRL 7-3 transaction and/or validation performed.

AGY-21-008-IT 99 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.3.1-2 Each transaction record will be unique and will include the following CDRL 7-3 information, at a minimum: • Date and time • Device ID • Vehicle ID • Operator ID • ID • Geo-location information (GPS data) • Route number • Run number • Block number • Media type • Card/account number • Fare category (e.g., full fare, reduced fare) • Action performed • Fare instrument or product used (where applicable) • Transaction value (where applicable) • Transaction result (e.g., success, failure) • Transaction ID Transaction records details will be finalized during design review. 7.2.3.1-3 FPVs will maintain local data records in non-volatile memory in the event CDRL 7-3 that communications to the back-office systems are unavailable. The local records will only be removed when verification of database storage of each record is received from the back-office. 7.2.3.1-4 Any offline payment validation will be recorded as such as part of the CDRL 7-3 transaction data so that offline transactions can be easily identified and tracked. 7.2.3.1-5 Errors with transactions and validations for card reads and barcode scans CDRL 7-3 will create a data record.

7.2.3.2 Audit Registers

Req # Requirement Assigned CDRL 7.2.3.2-1 All FPVs will provide audit register counts for purposes of data tracking and CDRL 7-3 analysis. The audit registers will store counts of specific events in non- volatile memory and will not be able to be modified or erased.

AGY-21-008-IT 100 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.3.2-2 The audit registers will maintain counts of the following events as CDRL 7-3 applicable: • Total validation counts • Rider class counts • Count of approved transactions • Count of denied transactions • Count of read failures • Fare products validated (where applicable) • Fare value deducted (where applicable) Final audit register events will be determined during design reviews. 7.2.3.2-3 Audit register records will be transmitted to the back-office at the end of CDRL 7-3 service day for reconciliation or based on a configurable time period.

7.2.3.3 Events and Alerts

Req # Requirement Assigned CDRL 7.2.3.3-1 FPVs will provide real-time status of device events and alerts reported CDRL 7-3 though the SMMA (see Section 8.4). The FPV will also maintain local event and alert logs in the event that communications to the back-office are unavailable. 7.2.3.3-2 In addition to transmitting real-time events and alerts, the FPV will CDRL 7-3 transmit periodic “heartbeat” messages that confirm communication with the back-office and basic status. The “heartbeat” frequency will be adjustable.

AGY-21-008-IT 101 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.3.3-3 At a minimum, the FPV will generate, store, and forward to the back-office CDRL 7-3 an event record for each of the following events with their corresponding date/time: • Power on • Power off • Operator login and logout • Route changed • Fare set or service level changed • Back-office communications failed/restored • Maintenance parameter changed • New fare table received/activated • New software received/activated • New configuration data received/activated • New list received/activated • Anti-virus definitions and security updates downloaded • Internal clock reset • FPV clock error • Data memory near full/full • FPV “heartbeat” check Final event records will be determined during design review. 7.2.3.3-4 The FPV will have the capacity to store a minimum of three (3) months of CDRL 7-3 local event and alert data.

7.2.4 Operations

Req # Requirement Assigned CDRL 7.2.4-1 Upon power-up, the FPV will be operational and ready for revenue service CDRL 7-3 within one (1) minute. It will remain operational until a configurable time after power off, subject to normal operating conditions. 7.2.4-2 The FPV will require a valid login to function. Login information will be CDRL 7-3 automatically pulled from the CAD/AVL system by default. If login information is not available from the CAD/AVL system, the bus operator will be able to present an employee ID card to the reader to initiate a default login. 7.2.4-3 After successful login, the FPV will automatically and continuously poll for CDRL 7-3 all supported media formats. 7.2.4-4 The FPV will support an anti-collision algorithm to ensure that payment is CDRL 7-3 only accepted from a single piece of media when multiple valid pieces of media are presented.

AGY-21-008-IT 102 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.4-5 The FPV will be equipped with real-time communication to the ATP (see CDRL 7-3 Section 8.2) for the processing of fare payments using the SI-provided fare payment API (see Section 5.3.1.3). 7.2.4-6 Prior to transmitting a fare payment transaction to the ATP, the FPV will CDRL 7-3 perform local fare media validity checks, including checks against any locally maintained positive and negative lists, as deemed necessary for security and the efficient processing of transactions. 7.2.4-7 The transaction result from the ATP will include: CDRL 7-3 • Validation result • Fare product used • Fare amount charged • Balance remaining • Fare product expiration date • Fare product remaining rides or days • Rider class • Transfer time remaining • Low balance warning (threshold to be configurable) • Time-based pass expiration warning (threshold to be configurable) Displayed results will be determined during design review. Results will be configurable, set by downloadable configuration parameters from the back-office. 7.2.4-8 The FPV will have ADA-compliant visual and audible indicators that provide CDRL 7-3 distinctive messages for approval or denial of all fare media validations and validator status. All validator visual and audio output will be fully configurable and subject to agency review and approval during design review. 7.2.4-9 Fare validation results will be displayed to the operator through the CDRL 7-3 integrated driver display (see Section 7.3). The operator may be shown additional fare payment details that are not shown to the customer. 7.2.4-10 FPVs will provide a payment result within 500 milliseconds of valid fare CDRL 7-3 media being presented for all fare payment types. 7.2.4-11 FPVs will be able to accept fare payments in an offline mode and CDRL 7-3 accommodate scenarios where a full authorization cannot be received within the required timeframe. In these scenarios, risk mitigation strategies will be employed to limit exposure for declined payments (see Section 5.6). 7.2.4-12 FPVs will not explicitly indicate to the customer or operator when they are CDRL 7-3 operating in offline mode. 7.2.4-13 All transactions generated in an offline mode will be sent to the ATP CDRL 7-3 immediately upon the restoration of communications.

AGY-21-008-IT 103 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.2.4-14 FPVs will display maintenance screens for troubleshooting and CDRL 7-3 configuration purposes by authorized staff. The method and operator interface used to perform maintenance functions will be determined during design review. 7.2.4-15 If a failure is detected that causes the FPV to cease functioning or cause CDRL 7-3 transactions to fail, the FPV will go out of service and provide visual indication of the device status. The detected failure will be recorded as an event record. 7.2.4-16 Prior to powering down, FPVs will transmit all recorded event records and CDRL 7-3 perform all necessary steps to retain the integrity of all stored data. If network connectivity is unavailable, the FPV will store the data and transmit when connectivity is available.

7.3 Bus Operator Display Req # Requirement Assigned CDRL 7.3-1 A Bus Operator Display (BOD) will be provided which will interface with the CDRL 7-4 onboard FPV and display fare validation results to the bus operator. The BOD will be connected to the FPV but will not be required for the FPV to function. 7.3-2 The BOD will be as simple and compact as possible while providing the CDRL 7-4 required functionality in this section. 7.3-3 The BOD will display fare payment results transmitted from the FPV, CDRL 7-4 including but not limited to: • Validation results • Fare amount charged • Fare balance remaining • Fare product used • Rider class • Transfer time remaining • Low balance warning (threshold to be configurable) • Time-based pass expiration warning (threshold to be configurable) • Card/account status (e.g. blocked and reason) • The operator may be shown additional fare payment details that are not shown to the customer. 7.3-4 The BOD will include at least four (4) buttons to perform functions in the CDRL 7-4 future if needed

AGY-21-008-IT 104 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.3-5 The BOD communication interfaces will conform to open communication CDRL 7-4 standards, including: • EIA-232/422 • RS-435 • J1708/1587 • 10/100 Base-T wired Ethernet • Bluetooth • USB The communication interface to be used will be determined during design review and must ensure adequate support for all BOD capabilities. 7.3-6 Communications utilized in the exchange of data between the BOD, the CDRL 7-4 FPV, and other onboard systems will be fully documented and the property of the agency. 7.3-7 The BOD enclosure and components shall be made of a material suitable to CDRL 7-4 the service under the full range of the specified bus environmental and operating conditions (see Section 4.7). 7.3-8 BOD housing will be resistant to corrosion, abrasion, scratching, impacts, CDRL 7-4 and vandalism, and withstand standard bus cleaning materials. BOD housing color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and peeling. The device will follow all common design requirements in Section 4. 7.3-9 All required mounting hardware and brackets for each bus type will be CDRL 7-4 provided by the SI. 7.3-10 The BOD will be installed in a position to allow bus operators to observe CDRL 7-4 fare transactions without interfering with other bus controls or indicators. The BOD will in no way obstruct the bus operator’s view. 7.3-11 The BOD will be designed and mounted so that it can be quickly adjusted CDRL 7-4 by the bus operator for an optimal viewing angle. After adjusting, the mounting hardware will not allow the BOD to shake or become loose as a result of shock and vibration encountered during normal bus operation. 7.3-12 Final BOD specifications and performance requirements will be presented CDRL 7-4 for agency review and approval during design reviews.

AGY-21-008-IT 105 | Page

APPENDIX 1

7.4 Faregates

7.4.1 General Requirements

Req # Requirement Assigned CDRL 7.4.1-1 The faregates will be bi-directional, and support customers passing CDRL 7-5 through from either the paid or unpaid side. The faregates will be able to be configured for single-direction use or to only allow entry in one direction. The faregate direction will be able to be automatically configured per faregate or array based on day and time or manually adjusted via remote command. 7.4.1-2 The faregates will have contactless smartcard readers and 2d barcode CDRL 7-5 scanners installed on both the entry (unpaid) and exit (paid) sides (see Section 7.4.2.1). The entry readers will be used to validate entry into the system and generate a flat fare payment transaction. The exit readers may be enabled to collect additional ridership information upon exit, or to support distance-based fares in the future (see Section 7.4.4.5). 7.4.1-3 A customer display (see Section 7.4.2.5) and audio output will be provided CDRL 7-5 for both the entry (unpaid) and exit (paid) sides. When valid fare media is presented, the faregate barriers will open, accompanied by a visual and audible indication. If a customer does not have a valid fare, the barriers will remain closed, a rejection tone will sound, and the reason displayed. 7.4.1-4 Fare barriers will be the paddle type (or agency accepted equivalent), CDRL 7-5 which provide a fully unobstructed path upon opening and do not hinder bicycles, strollers, or other large packages (see Section 7.4.2.3). 7.4.1-5 The faregates will employ indicator lamps or symbols that can be CDRL 7-5 configured to signal when payments are accepted for certain fare products or rider classes (see Section 7.4.2.6). 7.4.1-6 The faregate will communicate with the back-office through a secure CDRL 7-5 communications interface using the SI-provided APIs (see Section 5.3.1) to send and receive and data including but not limited to: • Transaction information • Event status and alerts • Time synchronization information • Positive/negative lists • Configuration parameters • Remote commands or status inquiries The list of exchanged information will be finalized during design review.

AGY-21-008-IT 106 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.1-7 Faregates will have remote control capabilities to allow for override control CDRL 7-5 of each faregate or array to set direction, customer display, and other operations (see Section 7.4.4.1). Override control events will be logged and transmitted to the back-office. 7.4.1-8 The faregate will provide a throughput of at least 25 customers per minute, CDRL 7-5 including media validation, updating the display, and opening the barrier. 7.4.1-9 The faregates will support reliable operation in the Baltimore environment, CDRL 7-5 including, direct sunlight, high humidity, and moisture, as well as withstand standard station cleaning materials.

7.4.2 Hardware

7.4.2.1 Smartcard and Barcode Readers

Req # Requirement Assigned CDRL 7.4.2.1-1 Customer-facing contactless smartcard readers will be installed in the CDRL 7-5 faregate to read and validate contactless media. Readers will be installed on both entry and exit sides of the faregate. 7.4.2.1-2 Faregate readers will be PCI- and EMV-certified for the acceptance of CDRL 7-5 bank-issued contactless credit and debit cards using all common formats based on the latest version of the standard at the time of Final Acceptance. FPVs will be capable of re-certification with newer versions of the PCI and EMV standards via software upgrades, as necessary. 7.4.2.1-3 Faregate readers will support a minimum of two (2) Secure Access CDRL 7-5 Modules (SAMs) to facilitate acceptance of multiple fare media formats and the replacement of security keys, should a compromise occur. 7.4.2.1-4 Faregates will be equipped with a built-in 2D barcode reader to enable CDRL 7-5 the validation of QR (or Aztec) codes. The barcode reader may be integrated with or separate from the FPV. 7.4.2.1-5 The barcode reader will be optimized for scanning QR codes from mobile CDRL 7-5 screens and will be able to accommodate a wide range of mobile device screen sizes and QR code sizes. 7.4.2.1-6 The barcode reader will be able to accommodate real-world CDRL 7-5 environmental factors such as different scanning angles at varying distances from the scanner in both natural and artificial lighting conditions.

AGY-21-008-IT 107 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.2.1-7 The barcode reader will be able to accommodate real-world CDRL 7-5 environmental factors such as different scanning angles at varying distances from the reader and shall be designed to maximize usability without customer education. 7.4.2.1-8 The barcode reader will have a LED aimer and a minimum 752x480 pixel CDRL 7-5 sensor. 7.4.2.1-9 The MTA prefers a forward or upward facing mirrored configuration with CDRL 7-5 a scan range between 0” (flush) and 6” from the barcode reader.

7.4.2.2 Enclosure

Req # Requirement Assigned CDRL 7.4.2.2-1 Faregate cabinets will be self-standing, sturdy enclosures that contain the CDRL 7-5 contactless reader, customer display, and electromechanical components that deploy the sliding panel (or accepted equivalent) system. 7.4.2.2-2 Faregate cabinet types will be installed in an array to form customer CDRL 7-5 aisles. Cabinet positioning will accommodate standard aisle-width (at least 24 inches), or ADA-width (at least 36 inches). 7.4.2.2-3 All faregate components, including the smartcard reader, display, CDRL 7-5 indicator lamps, fare barrier position, and aisle width, will meet all applicable ADA requirements. 7.4.2.2-4 Faregate cabinets will be constructed from stainless steel without any CDRL 7-5 visible fasteners. The cabinet finish and corners will be rounded to avoid sharp edges, corners, or protrusions that may cause injury to customers. 7.4.2.2-5 Faregate cabinets will be rugged and function under harsh environmental CDRL 7-5 conditions including: direct sunlight, moisture, dust/grit/sand, humidity, snow and ice, electrical storms, exposure to an urban environment, and the range of elevations and altitudes in the operating region (see Section 4.7) for operating environment requirements). 7.4.2.2-6 Faregate cabinets will be resistant to corrosion, abrasion, scratching, CDRL 7-5 impacts, and vandalism, and withstand industry standard cleaning materials. Cabinet color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and peeling. 7.4.2.2-7 Covers on the cabinet housing for accessing modules and subassemblies CDRL 7-5 will be secured with mechanical locks and keys that are not readily duplicated, nor readily available to the public, and uniquely serialized and stamped “Do Not Duplicate.” 7.4.2.2-8 Certain faregate cabinets will not be required to house all internal CDRL 7-5 electronics or customer displays, such as end cabinets on each array.

AGY-21-008-IT 108 | Page

APPENDIX 1

7.4.2.3 Fare Barriers

Req # Requirement Assigned CDRL 7.4.2.3-1 MTA has evaluated several faregate types, including tripod turnstiles, bi‐ CDRL 7-5 parting leaf, paddle, and sliding panel gates, and prefer a design that provides an unobstructed aisle, and minimizes the opportunity for “gate jumping” and customer confusion. Paddle faregates are the current preference. Acceptable equivalents may include swinging panel or bi- parting leaf designs. 7.4.2.3-2 The paddle design (or MTA approved equivalent) will include two (2) CDRL 7-5 panels that protrude from the console on either side of the aisle and retract into the console upon opening. The panels will obstruct most of the aisle when closed and will be made from a transparent or translucent material to allow customers to see oncoming traffic. 7.4.2.3-3 When in the open position, the panels will provide an unobstructed aisle CDRL 7-5 and adequate clearance for customers with bicycles, strollers, luggage, and other large packages. 7.4.2.3-4 Upon read of valid fare media, fare barriers will remain in the open CDRL 7-5 position for a configurable minimum time. Sensors in the aisle (see Section 7.4.2.4) will detect the passage of the customer, and only close when the customer has completely exited the aisle. 7.4.2.3-5 The opening and closing speed of the faregate barriers will be configurable CDRL 7-5 per faregate aisle and array, and the barriers will immediately retract upon a configurable amount of resistance. 7.4.2.3-6 Fare barrier materials will be flame retardant and comply with all CDRL 7-5 applicable fire, life, and safety regulations. 7.4.2.3-7 The faregate will detect if a fare barrier is being forced open. If the barrier CDRL 7-5 is forced open beyond one (1) inch, an alarm will sound as long as the barrier is being forced open. An alarm event will also be reported to the back-office in real-time.

7.4.2.4 Aisle Sensors

Req # Requirement Assigned CDRL 7.4.2.4-1 Faregate aisle sensors will be embedded in each aisle to detect the CDRL 7-5 movement of customers or objects through the aisle. The sensors will also determine whether there is an obstruction on the other side of the barrier before it is opened, and a customer is allowed to pass. 7.4.2.4-2 The sensors will not be immediately apparent and employ infrared or CDRL 7-5 equivalent technology that does not emit visible light.

AGY-21-008-IT 109 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.2.4-3 There will be at least two (2) aisle sensors on each side of the fare barrier CDRL 7-5 to detect the direction of travel. Sensors may be in pairs (e.g., upper, and lower) to detect larger objects and prevent misreads or intentional blockage of one sensor. 7.4.2.4-4 Aisle sensors may receive light signals from the LEDs on the opposing side CDRL 7-5 of the aisle. If this technique is used, sensors will not be easily misaligned under normal use, and indicate a maintenance event if malfunctioning. 7.4.2.4-5 Each sensor/LED pair will be mounted such that adjustments will allow the CDRL 7-5 pairs to be aligned if necessary. 7.4.2.4-6 Aisle sensors will operate in a pulse-width modulation mode or other CDRL 7-5 technique that effectively filters out ambient light sources. 7.4.2.4-7 Aisle sensors will be positioned and programmed to prevent potential CDRL 7-5 fraud from customers intentionally blocking sensors to open fare barriers. 7.4.2.4-8 Aisle sensors will prevent the passage of customers from the opposite CDRL 7-5 direction through an opened barrier.

7.4.2.5 Faregate Display

Req # Requirement Assigned CDRL 7.4.2.5-1 The faregates will include a full-color customer displays that provide visual CDRL 7-5 feedback on payment acceptance or denial along with relevant account information. 7.4.2.5-2 Faregate displays will be installed on both entry and exit sides. Each display CDRL 7-5 will be independently programmable, such that messages and graphics on the entry side can operate independently from the exit side. 7.4.2.5-3 Faregate displays will be color, trans-reflective backlit flat panel displays CDRL 7-5 with a high-intensity backlight (>1000 nits), and at least 750:1 contrast ratio. 7.4.2.5-4 The display screen will provide a resolution of no less than 600 by 800 CDRL 7-5 pixels, and at least 65,000 colors (RGB 16 bit) per pixel. 7.4.2.5-5 The faregate displays will support adjustable brightness, contrast, and CDRL 7-5 refresh rate that can be easily read under any combination of ambient lighting, including direct sunlight and night-time operation.

AGY-21-008-IT 110 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.2.5-6 The faregate displays will be capable of partial or full video or animation. CDRL 7-5 The animations may be used to indicate fare feedback, relevant customer action, or other general information. Video or animation files will be able to be updated remotely or installed via removable memory by maintenance staff. Supported video types will be agreed upon during design review (e.g., JPG, GIF, PNG, MP4, etc.)

7.4.2.6 Indicator Lamps

Req # Requirement Assigned CDRL 7.4.2.6-1 Indicator lamps will be used to indicate if particular rider classes or fare CDRL 7-5 products are read by the faregate. Indicator lamps are primarily intended for fare enforcement purposes but may also be used to indicate special operational modes (emergency mode, free entry, or no entry). 7.4.2.6-2 The lamps may be a series of high-intensity light-emitting diodes (LEDs) or CDRL 7-5 use other lighted symbols. They will be capable of displaying at least 16 unique colors or patterns to indicate different results. 7.4.2.6-3 The indicator lamps will not expressly indicate the rider class or type of CDRL 7-5 fare being accepted. Colors, lighting sequences, or symbols may be coded to certain results. 7.4.2.6-4 The indicator lamps will be programmable to activate based on any rider CDRL 7-5 class, fare product, or operational mode. They will be able to be configured per faregate or array. 7.4.2.6-5 The indicator lamps will be positioned to allow visibility from both the paid CDRL 7-5 and unpaid sides of the faregate.

7.4.2.7 Audio

Req # Requirement Assigned CDRL 7.4.2.7-1 Faregates will include an audio interface and speakers for customizable CDRL 7-5 audio feedback on both entry and exit sides, including varying tones and full speech. Audio feedback types will be able to be configured and updated remotely. 7.4.2.7-2 The decibel levels of the tones will be programmable locally and remotely, CDRL 7-5 and the emitted tones will be capable of being distinguished up to eight (8) feet away.

AGY-21-008-IT 111 | Page

APPENDIX 1

7.4.2.8 Single-Board Computer

Req # Requirement Assigned CDRL 7.4.2.8-1 Certain faregate cabinets will house a Single-Board Computer (SBC) to CDRL 7-5 control the operation of all faregate functions. The SBC will drive the faregate display and fare barrier and respond with minimal perceptible delay to customer input. 7.4.2.8-2 Certain faregate cabinets (such as end cabinets without customer displays) CDRL 7-5 may not require SBCs. 7.4.2.8-3 The SBC will be equipped with all necessary components, including but not CDRL 7-5 limited to CPU, RAM, I/O, NVM, removable SSD, and software capable of performing all functions specified herein. 7.4.2.8-4 The SBC memory shall maintain all data records and maintenance CDRL 7-5 information upon loss of power and/or unexpected reboot. 7.4.2.8-5 Faregates will have at least three (3) spare USB ports to support removable CDRL 7-5 memory, SAMs, or future connection of ancillary devices, such as a barcode reader.

7.4.2.9 Communications

Req # Requirement Assigned CDRL 7.4.2.9-1 The faregate will communicate with the back-office through a secure CDRL 7-5 communications interface to send and receive and data. 7.4.2.9-2 All communications between the faregate and back office will be via a CDRL 7-5 hardwired connection. The SI will be responsible for removing and replacing all existing Ethernet cabling runs from the communication cabinets in each to the installed location of the equipment with new CAT6 or better rodent resistant or armored cabling. The SI shall be responsible for all network hardware (e.g., network switches) necessary to connect the equipment at the installed locations. 7.4.2.9-3 At least one faregate cabinet in each array (e.g., the end cabinet) will be CDRL 7-5 capable of housing a network switch to enable all devices in one area to be connected through a single connection to the station communications room, and limit the number of Ethernet runs required to each installation location. 7.4.2.9-4 Each faregate array shall incorporate a SCADA interface that controls all CDRL 7-5 the faregates in that array. The SCADA signals may be daisy-chained from other devices or fed directly from a station input.

AGY-21-008-IT 112 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.2.9-5 The SCADA interface may be tied to local station controllers, emergency CDRL 7-5 management control panels, or remote-control systems to initiate emergency mode or other SCADA conditions. The gates will remain in emergency mode or other SCADA condition until the SCADA signal is closed or deactivated. 7.4.2.9-6 The SCADA control signals will supersede any other control signals, CDRL 7-5 including those from the SMMA (see Section 8.4). For example, if the SCADA signal initiates emergency mode and an “enter revenue service” signal is sent from the SMMA, the faregate will remain in emergency mode.

7.4.2.10 Power Supply

Req # Requirement Assigned CDRL 7.4.2.10-1 Each faregate will be equipped with a modular, filtered power supply CDRL 7-5 which will be connected to the incoming grounded electrical service. The power supply will be connected to the incoming electrical service and deliver all of the necessary operating voltages for the machine. Voltages internal to the faregate will not exceed 125 V. 7.4.2.10-2 A power switch will turn the power supply on or off and will be separate CDRL 7-5 from the main circuit breaker that removes all power to the faregate. There will be no safety risks to maintenance personnel with the machine power turned off. 7.4.2.10-3 A GFCI duplex convenience outlet will be installed within the interior of CDRL 7-5 each faregate cabinet. This outlet will be protected by a separate circuit breaker internal to the machine enclosure and will be grounded. 7.4.2.10-4 Appropriate warning labels will be provided on or near any components or CDRL 7-5 cables that may have hazardous voltages present. 7.4.2.10-5 If the faregate loses power or malfunctions such that power is unavailable, CDRL 7-5 the fare barriers shall automatically open and remain open during power loss. Upon restoration of power, the faregate may automatically resume operations, or enter into emergency mode if agency policy dictates so. The faregate behavior after resuming from power loss shall be configurable. 7.4.2.10-6 The faregate will be equipped with a battery supplemental power supply. CDRL 7-5 This battery power supply will be used in the event the incoming voltage falls below the reliable machine operating voltage or in the event of loss of AC power to the machine.

AGY-21-008-IT 113 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.2.10-7 Once primary power is restored, the backup battery will be recharged. CDRL 7-5 Battery life will be rated at four (4) years or 500 discharge and charge cycles.

7.4.3 Software

7.4.3.1 Transaction Records

Req # Requirement Assigned CDRL 7.4.3.1-1 Faregates will generate, store, and transmit a discrete data record for each CDRL 7-6 transaction and/or validation performed. 7.4.3.1-2 Each transaction record will be unique and will include the following CDRL 7-6 information, at a minimum: • Date and time • Device ID • Station ID • Media type • Card/account number • Fare category (e.g., full fare, reduced fare) • Action performed • Fare instrument or product used (where applicable) • Transaction value (where applicable) • Transaction result (e.g., success, failure) • Transaction ID Transaction records details will be finalized during design review. 7.4.3.1-3 Faregates will maintain local data records in non-volatile memory in the CDRL 7-6 event that communications to the back-office systems are unavailable. The local records will only be removed when verification of database storage of each record is received from the back-office. 7.4.3.1-4 Any offline payment validation will be recorded as such as part of the CDRL 7-6 transaction data so that offline transactions can be easily identified and tracked. 7.4.3.1-5 The faregates will be capable of being connected to and controlled CDRL 7-6 remotely via the provided Rail Station Agency Console (See section 7.5).

AGY-21-008-IT 114 | Page

APPENDIX 1

7.4.3.2 Audit Registers

Req # Requirement Assigned CDRL 7.4.3.2-1 All faregates will provide audit register counts for data tracking and CDRL 7-6 analysis. The audit registers will store counts of specific events in non- volatile memory and will not be able to be modified or erased. 7.4.3.2-2 The audit registers will maintain counts of each event below as applicable. CDRL 7-6 At a minimum, the faregate will generate, store, and transmit each of the following events with date/time stamp: • Total validation counts • Rider class counts • Count of approved transactions • Count of denied transactions • Count of read failures • Fare products validated (where applicable) • Fare value deducted (where applicable) Final audit register events will be determined during design review. 7.4.3.2-3 Audit register records will be transmitted to the back-office at the end of CDRL 7-6 service day for reconciliation, or upon a configurable time period. 7.4.3.2-4 Errors with transactions and validations for all barcode scans will create a CDRL 7-6 data record.

7.4.3.3 Events and Alerts

Req # Requirement Assigned CDRL 7.4.3.3-1 Faregates will provide real-time status of device events and alerts. The CDRL 7-6 faregates will also maintain local event and alert logs in the event that communications to the back-office are unavailable. 7.4.3.3-2 In addition to transmitting real-time events and alerts, the faregates will CDRL 7-6 transmit periodic “heartbeat” messages that confirm communication with back-office and basic status. The “heartbeat” frequency will be adjustable per faregate.

AGY-21-008-IT 115 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.3.3-3 At a minimum, the faregate will generate, store, and forward to the back- CDRL 7-6 office an event record for each of the following events with their corresponding date/time: • Power on • Power off • Reboot • Back-office communications failed/restored • Maintenance parameter changed • New fare table received/activated • New software received/activated • New configuration data received/activated • New list received/activated • Anti-virus definitions and security updates downloaded • Internal clock reset • Clock error • Data memory near full/full • Low battery • Barrier failure • Barrier forced open • Barrier aisle sensor blocked • Unauthorized access (intrusion alarm sounded) • Operating mode changed • Emergency mode • Maintenance mode • Gate direction set • Faregate “heartbeat” check Final event records will be determined during design review. 7.4.3.3-4 The faregate will have the capacity to locally store a minimum of one (1) CDRL 7-6 year of event and alarm data.

AGY-21-008-IT 116 | Page

APPENDIX 1

7.4.4 Operations

7.4.4.1 Remote Operation

Req # Requirement Assigned CDRL 7.4.4.1-1 Faregates will support remote operation in both direct and pre-scheduled CDRL 7-6 modes. Remote control will include the following commands, at a minimum: • Change from bi-directional to single direction mode • Change faregate direction when in single direction mode • Release one (1) faregate or array to open • Lock one (1) faregate or array to close • Change faregate display • Reboot faregate • Set faregate into a specific operating mode (see below) Final list of remote commands will be determined during design review. 7.4.4.1-2 The faregates will support the following operating modes, at a minimum: CDRL 7-6 • Enter revenue mode • Exit revenue mode (out of service) • Open for one (1) entry • Open for unlimited entries • Emergency mode (all barriers open) Operating modes may be applied to a single faregate or array. The final list of operating modes will be determined during design reviews. 7.4.4.1-3 Remote control will also allow for the configuration of the visual and audio CDRL 7-6 feedback provided through all interfaces incorporated into the faregate. Interfaces include the faregate display, speaker, and indicator lamps. 7.4.4.1-4 Faregate control will be enabled via integration with the SCADA system CDRL 7-6 being put in place as part of the new rail system and through the SMMA (see Section 8.4). 7.4.4.1-5 Faregate connectivity to the SCADA system shall have a configurable delay CDRL 7-6 that can be adjusted for 0 to 45 seconds to allow the alarm to be deactivated from the Station Terminal in the event there is a false alarm.

7.4.4.2 Revenue Mode

Req # Requirement Assigned CDRL 7.4.4.2-1 Faregates will boot into revenue mode by default, and can receive remote CDRL 7-6 commands to enter revenue operation (see Section 7.4.4.1.

AGY-21-008-IT 117 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.4.2-2 In revenue mode, an idle faregate will operate with these parameters: CDRL 7-6 • Entry side reader: active • Entry side display: “Enter” • Barrier action: closed • Exit side reader: inactive • Exit side display: “Exit” Final idle behavior and messaging will be determined during design review. 7.4.4.2-3 Upon a valid payment, the faregate will operate with these parameters: CDRL 7-6 • Entry side reader: inactive (unless banking is enabled, see Section 7.4.4.3) • Entry side display: “Go” (see below for all displayed information) • Barrier action: open • Exit side reader: inactive • Exit side display: “Wait” After the customer completes passage the faregate will return to idle condition. 7.4.4.2-4 Upon an invalid payment attempt, the faregate will operate with these CDRL 7-6 parameters: • Entry side reader: active • Entry side display: “Stop”, with corresponding reason • Barrier action: closed • Exit side reader: inactive • Exit side display: “Wait” The faregate will return to idle condition waiting for a valid tap. 7.4.4.2-5 The faregates will support an anti-collision algorithm to ensure that CDRL 7-6 payment is only accepted from a single piece of media when multiple valid pieces of media are presented. 7.4.4.2-6 The faregates will be equipped with real-time communication to the ATP CDRL 7-6 (see Section 8.2) for the processing of fare payments using the SI-provided fare payment API (see Section 5.3.1.3). 7.4.4.2-7 Prior to transmitting a fare payment transaction to the ATP, the faregate CDRL 7-6 will perform local fare media validity checks, including checks against any locally maintained positive and negative lists, as deemed necessary for security and the efficient processing of transactions.

AGY-21-008-IT 118 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.4.2-8 The transaction result from the ATP will include: CDRL 7-6 • Validation result • Fare product used • Fare amount charged • Balance remaining • Fare product expiration date • Fare product remaining rides or days • Rider class • Transfer time remaining • Low balance warning (threshold to be configurable) • Time-based pass expiration warning (threshold to be configurable) Displayed results will be determined during design review. Results will be configurable, set by downloadable configuration parameters from the back-office. 7.4.4.2-9 The faregate will have ADA-compliant visual and audible indicators that CDRL 7-6 provide distinctive messages for approval or denial of all fare media validations and validator status. All validator visual and audio output will be fully configurable and subject to agency review and approval during design review. 7.4.4.2-10 The faregates will provide a payment result within 500 milliseconds of CDRL 7-6 valid fare media being presented for all fare payment types. 7.4.4.2-11 The faregates will be able to accept fare payments in an offline mode and CDRL 7-6 accommodate scenarios where a full authorization cannot be received within the required timeframe. In these scenarios, risk mitigation strategies will be employed to limit exposure for declined payments (see Section 5.6). 7.4.4.2-12 The faregates will not explicitly indicate to the customer when they are CDRL 7-6 operating in offline mode. 7.4.4.2-13 All transactions generated in an offline mode will be sent to the ATP CDRL 7-6 immediately upon the restoration of communications. 7.4.4.2-14 On a valid entry, the faregate barriers will close once the sensors detect CDRL 7-6 the customer passing through the aisle or a configurable time-out has passed, whichever occurs first. 7.4.4.2-15 If the exit readers are disabled, the fare barriers shall open if the outer CDRL 7-6 aisle sensor detects an exit. The sensor will be positioned such that customers on the entry side cannot easily reach over the barrier and open the fare barrier by activating the exit sensor. 7.4.4.2-16 The barriers shall not close if aisle sensors remain blocked. If the aisle CDRL 7-6 sensors remain blocked for a configurable period of time, an audible alert will sound.

AGY-21-008-IT 119 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.4.4.2-17 If a programmed fare product or rider class is validated, the faregate indicator lamps will light according to the fare table. See Section 7.4.2.6 for indicator lamp requirements.

7.4.4.3 Free Entry Mode

Req # Requirement Assigned CDRL 7.4.4.3-1 Under special circumstances, authorized staff may remotely set individual CDRL 7-6 faregates or arrays into free-entry mode through the System Monitoring and Management Application (see Section 8.4) or SCADA interface. This mode will not be enabled by default and may be set for one (1) entry or unlimited entries (until revenue mode is reset). 7.4.4.3-2 In free entry mode, an idle faregate will operate with these parameters: CDRL 7-6 • Entry side reader: active • Entry side display: “Enter” • Barrier action: open • Exit side reader: inactive • Exit side display: “Exit” Final idle behavior and messaging will be determined during design review. 7.4.4.3-3 Upon a valid read, the faregate will operate with these parameters: CDRL 7-6 • Entry side reader: inactive (unless banking is enabled, see Section 7.4.4.2) • Entry side display: “Go” (see Section 7.4.4.2 for all displayed information) • Barrier action: open • Exit side reader: inactive • Exit side display: “Wait” After the customer completes passage the faregate will return to idle condition. 7.4.4.3-4 Free-entry mode will have active entry readers for data collection CDRL 7-6 purposes, including but not limited to date and time, but tapping will not be required since fare barriers will be open. 7.4.4.3-5 If faregates lose power, they will enter into free-entry mode while battery CDRL 7-6 power lasts. When battery power is exhausted, the fare barriers will remain open.

AGY-21-008-IT 120 | Page

APPENDIX 1

7.4.4.4 Emergency Mode

Req # Requirement Assigned CDRL 7.4.4.4-1 Faregates or faregate arrays may receive a remote emergency command CDRL 7-6 through the SCADA interface, or through local station controllers (e.g. emergency management control panels or fire key switch at gate arrays). 7.4.4.4-2 In emergency mode, the faregate will operate with these parameters: CDRL 7-6 • Entry side reader: inactive • Entry side display: “STOP” • Barrier action: open • Exit side reader: inactive Exit side display: “EXIT” 7.4.4.4-3 Faregates will remain in emergency mode until the SCADA signal is closed CDRL 7-6 or the local switch is returned to normal revenue mode. Remote control commands from the SMMA (see Section 8.4) will not override the SCADA interface. 7.4.4.4-4 A reboot of the faregate shall not take the gate out of emergency mode CDRL 7-6 while the SCADA or other emergency signal is active. 7.4.4.4-5 Upon power loss or malfunction, the faregate barriers will automatically CDRL 7-6 open. The barriers will not require any power to open and will remain open based on the design of the fare barriers.

7.4.4.5 Ride Banking

Req # Requirement Assigned CDRL 7.4.4.5-1 Faregates will support ride banking as a configurable feature. Ride banking CDRL 7-6 parameters will be able to be set per faregate or array. 7.4.4.5-2 Ride banking will allow valid taps to be accumulated without a CDRL 7-6 corresponding barrier opening and closing between each tap. Each valid tap will correspond to a fare being paid and an entry banked. The faregate will reduce the number of banked rides as each entry occurs. Once the last banked ride is used, the barrier will close and the faregate will return to idle state. 7.4.4.5-3 A configurable ride banking counter will allow a maximum number of rides CDRL 7-6 to be banked. The bank counter will reset when it reaches zero, or after a configurable time-out period, whichever occurs first.

AGY-21-008-IT 121 | Page

APPENDIX 1

7.4.4.6 Dual Tap Support

Req # Requirement Assigned CDRL 7.4.4.6-1 The faregates shall support dual tap operation for the purpose of additional CDRL 7-6 data collection, or to support distance-based fares in the future. 7.4.4.6-2 In dual tap mode, exit readers will be active a tap will be required to exit. CDRL 7-6 7.4.4.6-3 In dual tap mode, an idle faregate will operate with these parameters: CDRL 7-6 • Entry side reader: active • Entry side display: “Enter” • Barrier action: closed • Exit side reader: active • Exit side display: “Exit” Final idle behavior and messaging will be determined during design review. 7.4.4.6-4 In dual tap mode, the faregate operation on exit will be similar to the CDRL 7-6 revenue mode on entry (see Section 7.4.4.2). 7.4.4.6-5 Faregates may be configured for dual tap operation per station or gate CDRL 7-6 array (i.e., one station may require an exit tap to open the fare barriers, and another station may not)

7.5 Rail Station Agent Console 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.

7.5.1 Hardware

Req # Requirement Assigned CDRL 7.5.1-1 The Rail Station Agent Console will include a touchscreen display with no CDRL 7-7 less than XGA resolution. 7.5.1-2 The touchscreen will provide suitable touch sensitivity and resolution to CDRL 7-7 satisfy selection and input requirements. 7.5.1-3 The Console will include integrated 10BaseT Ethernet or a cellular CDRL 7-7 broadband modem to satisfy the requirements of the configuration. 7.5.1-4 If possible, there is a preference for the Console to be delivered as a web- CDRL 7-7 based application to allow the MTA to use existing PCs.

AGY-21-008-IT 122 | Page

APPENDIX 1

7.5.2 Communications

Req # Requirement Assigned CDRL 7.5.2-1 The Console will communicate with the back-office via a secure Internet CDRL 7-7 connection to send and receive information, event and status information, clock synchronization information, and configuration parameters. This will be possible both automatically at scheduled times and manually by authorized users. 7.5.2-2 All communications between the back-office and the Console will be via a CDRL 7-7 direct Ethernet connection. 7.5.2-3 Console communication with the back-office will be able to be initiated CDRL 7-7 manually at any time without affecting the automated procedures. 7.5.2-4 If the Console has missed a scheduled communication with the back-office, CDRL 7-7 upon restoration of communications, the Console will automatically initiate communications.

7.5.3 Operation

Req # Requirement Assigned CDRL 7.5.3-1 The SI provided Rail Station Agent Console will be capable of remotely CDRL 7-7 managing and operating faregates individually and by array, station mezzanine, and multiple selectable station mezzanines. 7.5.3-2 The Rail Station Agent Console will be able to put faregates and ticket CDRL 7-7 vending machines in and out of revenue service. 7.5.3-3 The Console will provide controls to adjust the brightness of the customer CDRL 7-7 display background lighting on faregates and ticket vending machines. 7.5.3-4 Remote control of faregates will include direct and pre‐scheduled CDRL 7-7 configuration of the gate direction, release, and customer display. Commands will include, but are not limited to: • Open • Lock • Switch direction • Reboot and • Shutdown. 7.5.3-5 Remote control will allow configuration of the visual and audio feedback of CDRL 7-7 the faregate, including selectable options to turn on and off faregate audible alarms and adjust alarm volume. 7.5.3-6 The Console will be able to manage and distribute configuration controls to CDRL 7-7 faregates.

AGY-21-008-IT 123 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.5.3-7 The Console will support user roles with different permissions and CDRL 7-7 functionality. User roles will be set in the backend system and enforced regardless of the Console that Station Agents log into. 7.5.3-8 Authorized users will be able to deactivate faregate alarms from the CDRL 7-7 Console. Error events that trigger the alarms will be captured and reported in the backend system. 7.5.3-9 Faregate status and directional configuration status will be displayed on the CDRL 7-7 station agent consoles. 7.5.3-10 The Console will provide selectable options to turn on and off faregate CDRL 7-7 concession fare light indicators. 7.5.3-11 The Console will include a fare card reader to read fare media data and CDRL 7-7 display card type, balance, entry/exit transaction configuration, and valid fare products

7.6 Full-Service Ticket Vending Machine (PRICED OPTION) The Ticket Vending Machine (TVM) is envisioned to be a simple, low-cost, low-complexity machine that allows first-time and regular riders to purchase and reload extended-use fare media. This simple TVM is expected to reduce the capital costs, maintenance activities, and customer complexity associated with traditional transit TVMs. To this end, one reusable contactless media type will be issued. The Agency would prefer the flexibility to enable and disable features or components of the TVM, as necessary.

7.6.1 General Requirements

Req # Requirement Assigned CDRL 7.6.1-1 The TVM will be designed as a simple, low-maintenance, and low- CDRL 7-12 complexity machine in a cost-saving design that provides the functionality specified herein and the common design requirements in Section 4.

AGY-21-008-IT 124 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.1-2 The TVM will be designed to accommodate first-time or occasional users, as CDRL 7-12 well as regular riders who need to reload their accounts. At a minimum, these functions will be supported: • Purchase one or more new smartcards (associated with a new transit account) with and without value • Load stored value or fare product(s) to an existing account • Review account balance and history • Accept U.S. coins and bills • Accept authorized magnetic strip, contact, and contactless bank cards, including Apple Pay, Google Pay, and Samsung Pay • Return deposited cash if a transaction is canceled • Print and issue receipts • Display instructions and notices • Provide audio output of messages and instructions, configurable by the user at the TVM • Contain required intrusion alarm system with audible alarm at TVM location • Communicate over a network to send and receive transaction data in real-time A full list of transactions and detailed process flows will be determined during design reviews. 7.6.1-3 The TVM will be modular and have the ability to replace, activate, or de- CDRL 7-12 activate the hardware components listed in Section 7.6.2 individually. The modules and components will be easily serviced as specified in Section 4.6 7.6.1-4 If a component or function is enabled/disabled, the TVM will automatically CDRL 7-12 adjust its display, operation, and maintenance status according to the active components. 7.6.1-5 The TVM will be able to accept credit and debit cards and cash/coin for CDRL 7-12 payment. 7.6.1-6 The TVM will issue change by default. Change should be issued via dollar CDRL 7-12 coins, quarters, dimes, and nickels. 7.6.1-7 One type of fare media will be issued by default, the extended-use CDRL 7-12 contactless media specified in Section 5.5.2. Alternate media types may be configured for issuance in the future if it does not have an impact on the simple design of the machine.

AGY-21-008-IT 125 | Page

APPENDIX 1

7.6.2 Hardware

7.6.2.1 Enclosure

Req # Requirement Assigned CDRL 7.6.2.1-1 The overall dimensions of the TVM enclosure will not exceed 80 inches CDRL 7-12 high, 40 inches wide, and 30 inches deep. The agency prefers a simple design without excess size or features that may contribute to increased costs. 7.6.2.1-2 The design of the TVM enclosure will permit installation as stand-alone CDRL 7-12 units, side-by-side units, back-to-back units, and in recessed areas. 7.6.2.1-3 TVM cabinets will be constructed from stainless steel without any visible CDRL 7-12 fasteners. The enclosure finish and corners will be rounded to avoid sharp edges, corners, or protrusions that may cause injury to customers. 7.6.2.1-4 TVM enclosures will be rugged and function under harsh environmental CDRL 7-12 conditions including: direct sunlight, moisture, dust/grit/sand, humidity, electrical storms, exposure to an urban environment, and the range of elevations and altitudes in the operating region (see Section 4.7). 7.6.2.1-5 TVM enclosures will be resistant to corrosion, abrasion, scratching, impacts, CDRL 7-12 and vandalism, and withstand standard cleaning materials. Color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and peeling. 7.6.2.1-6 The cabinet will be constructed to provide the highest protection against CDRL 7-12 vandalism and burglary. Reinforcement will be provided at the locations (screen, door hinges, access ports, etc.) where there is a higher possibility of vandalism. 7.6.2.1-7 The TVM mounting pedestal and any external features (such as button CDRL 7-12 panels, rain shields, and light fixtures) will be weatherized, robust, and vandal resistant. 7.6.2.1-8 While all outer doors are secured, the machine will remain operational and CDRL 7-12 undamaged after experiencing any impact resulting in a concentrated load of 400 pounds per one (1) square inch on any part of the enclosure. 7.6.2.1-9 The TVM cabinet and mounting hardware will accommodate variations in CDRL 7-12 station and sidewalk construction. Mounting pedestals will be sized according to need, and specifics will be provided by the agency during design review. All installed TVMs must comply with ADA requirements, including but not limited to the distance (minimum and maximum height) of user functions while at any MTA platform grade.

AGY-21-008-IT 126 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.1-10 The TVM cabinet will provide controlled levels of access to the interior of CDRL 7-12 the equipment for maintenance personnel, revenue servicing personnel, and cash processing personnel, as defined by the agency. Locks must be secured locks, programmable to more than one key. CyberLocks (#CLT-T6H) and CyberKey (#CK-IR7) will be used from Crest Lock Co., Inc. for all light rail and Metro station TVMs. 7.6.2.1-11 The enclosure will accommodate signage, markings, and other instructional CDRL 7-12 materials produced by the agency. 7.6.2.1-12 As necessary, blanking plates will be provided for installation over any outer CDRL 7-12 door openings resulting from the removal of an external component or module. All such blanking plates will be easily secured and will provide security against intrusion and vandalism. 7.6.2.1-13 The TVM enclosure and pedestal design will be submitted to the agency for CDRL 7-12 review and approval.

7.6.2.2 Display

Req # Requirement Assigned CDRL 7.6.2.2-1 The TVM will include a customer display screen bearing simple and easy to CDRL 7-12 read instructions which sequentially instruct the customer how to perform available functions. 7.6.2.2-2 The display screen will consist of a color, trans-reflective backlit flat panel CDRL 7-12 display that is clearly viewable in daytime and nighttime conditions. 7.6.2.2-3 The display screen will measure at least 10 inches diagonally. CDRL 7-12 7.6.2.2-4 The display screen will provide a resolution of no less than 1024 by 768 CDRL 7-12 pixels, and at least 65,000 colors (RGB 16 bit) per pixel. 7.6.2.2-5 The display screen will produce a minimum of 1,000 nits brightness with at CDRL 7-12 least a 750:1 contrast ratio, and provide a level of visibility sufficient to allow all displayed instructions to be read easily by the customer under all ambient light conditions, including direct sunlight, and without the need for any additional peripheral light source or shading device. 7.6.2.2-6 The display screen will display characters and symbols compliant with all CDRL 7-12 ADA requirements. 7.6.2.2-7 The visibility and usability of the display will be unaffected by precipitation, CDRL 7-12 temperature, sunlight, and other environmental conditions typical of the Baltimore operating region.

AGY-21-008-IT 127 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.2-8 The display will be protected to be resistant to scratches and other normal CDRL 7-12 wear. Coatings or other materials applied to the outer surface of the display’s protective shield will withstand normal customer use, industry- standard station cleaning materials, and be easily replaced if necessary. 7.6.2.2-9 The display screen will be easily replaceable from within the TVM interior CDRL 7-12 and require minimal maintenance effort. 7.6.2.2-10 All portions of the display screen will be visible and not obstructed by any CDRL 7-12 portion of the TVM door, mounting bezels, or other external elements. 7.6.2.2-11 The display screen will be installed close enough to the TVM surface to CDRL 7-12 avoid any parallax effect, or the apparent shift of screen objects relative to customer touches or button placement.

7.6.2.3 Bill Handling Unit

Req # Requirement Assigned CDRL 7.6.2.3-1 The TVM Bill Handling Unit (BHU) will accept paper currency and include a CDRL 7-12 bill validator, escrow module, and bill vault. 7.6.2.3-2 The bill validator will be capable of accepting all variations of $1, $2, $5, CDRL 7-12 $10, $20, $50, and $100 bills in circulation at the time of Final Acceptance. 7.6.2.3-3 As the U.S. Treasury releases new designs of bills, the bill validator will be CDRL 7-12 capable of being programmed to accept the new designs while continuing to accept the current designs. 7.6.2.3-4 The bill validator will be equipped with a protective shutter to ensure that CDRL 7-12 foreign matter does not enter the BHU while the machine is not accepting bills. 7.6.2.3-5 The bill validator will remain closed until a transaction is selected for which CDRL 7-12 cash payments are available. The shutter will automatically open once the payment due has been displayed. 7.6.2.3-6 The bill validator will be able to accept bills inserted in any of the four CDRL 7-12 possible lengthwise orientations. 7.6.2.3-7 The bill validator will accept one bill at a time and will determine the CDRL 7-12 denomination and validity of the currency. 7.6.2.3-8 The bill validator will determine the denomination and validity of both sides CDRL 7-12 of a document by dimension checks and pattern and color recognition.

AGY-21-008-IT 128 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.3-9 The bill validator will meet the following acceptance rates: CDRL 7-12 • At least 98% of valid bills are accepted upon initial insertion. • At least 99% of valid bills are accepted in no more than two insertion attempts. 7.6.2.3-10 The bill validator will identify valid acceptable bills with at least 99.999% CDRL 7-12 accuracy. 7.6.2.3-11 The bill acceptor may reject bills with excessive physical defects. CDRL 7-12 7.6.2.3-12 The bill validator will be able to detect counterfeit bills, including copies CDRL 7-12 made in either single or double-sided printing on an electronic copier and those made with color printers. 7.6.2.3-13 If the bill validator deems the inserted document to be invalid, the CDRL 7-12 document will be returned and gripped so that the TVM retains a hold on the item. 7.6.2.3-14 The bill validator will be designed to reject or expel pieces of paper or other CDRL 7-12 foreign material that can be introduced into the bill insertion slot. 7.6.2.3-15 The bill validator will be secured via a high-security lock and will be CDRL 7-12 separately removable for servicing. 7.6.2.3-16 Upon acceptance of each inserted bill, the bill validator will forward the bill CDRL 7-12 to an escrow to be stored temporarily until completion or cancellation of the transaction. 7.6.2.3-17 The bill escrow module will have the capacity to store a minimum of 10 CDRL 7-12 bills. 7.6.2.3-18 When the bill escrow is full, or a configurable limit of inserted bills per CDRL 7-12 transaction is reached, the bill validator will cease accepting bills. 7.6.2.3-19 If the customer cancels the transaction or the TVM aborts the transaction, CDRL 7-12 the BHU will return from escrow the bills inserted for the transaction. If the bill return is jammed (e.g., a foreign object is placed in it), the TVM will have a configurable parameter to either escrow the bill or place the TVM out of service. 7.6.2.3-20 When a transaction is completed, all bills in the bill escrow module will be CDRL 7-12 transported to the bill vault for retention. Using sensors or other means, the machine will confirm the passage of all bills to the bill vault; failure to detect a bill being deposited into the bill vault will be considered a jam, and the machine will cease accepting bills and display an appropriate message to customers. 7.6.2.3-21 The BHU will be equipped with a removable bill vault. The bill vault will CDRL 7-12 have a capacity of no less than 500 stacked bills in street condition and weigh no more than 50 pounds when full.

AGY-21-008-IT 129 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.3-22 The bill vault will be constructed of sturdy and tamper-proof material and CDRL 7-12 will withstand normal handling and regular removal and replacement without deformation that would in any way interfere with the insertion and removal process. 7.6.2.3-23 It will not be possible to open the bill vault while installed in the BHU, nor CDRL 7-12 will it be possible to install an open or unlocked bill vault into the BHU. When properly installed in the BHU, it will not be possible to access bills in the bill vault without damaging the vault in an obvious manner. 7.6.2.3-24 The bill vault will remain secure when removed from the TVM. Access to CDRL 7-12 the bill vault will be granted only with keys available to revenue staff. 7.6.2.3-25 The bill vault will have handles placed to avoid injury and provide adequate CDRL 7-12 hand clearance for easy insertion, removal, and carrying. 7.6.2.3-26 Each bill vault will include a printed and electronically encoded serial CDRL 7-12 number. The serial number will be read by the TVM for reporting upon bill vault insertion and removal.

7.6.2.4 Coin Handling Unit

Req # Requirement Assigned CDRL 7.6.2.4-1 TVMs will be equipped with a Coin Handling Unit (CHU) including, but not CDRL 7-12 limited to, a coin acceptor/verifier, a coin escrow module, and a coin vault. 7.6.2.4-2 The coin acceptor/verifier will accept all variations of nickels, dimes, CDRL 7-12 quarters, and dollar coins in circulation at the time of Final Acceptance. 7.6.2.4-3 As the U.S. Treasury releases new designs of coins, the coin CDRL 7-12 acceptor/verifier will be capable of being programmed to accept the new designs while continuing to accept the current designs. 7.6.2.4-4 The coin acceptor will contain a coin insertion slot that will be sized to limit CDRL 7-12 the dimensions of inserted material to the largest coin accepted. To minimize jams, the coin slot will also be sized to prevent the simultaneous insertion of two coins. 7.6.2.4-5 The coin insertion slot will be equipped with a protective shutter to ensure CDRL 7-12 that foreign matter does not enter the CHU while the machine is not accepting coins. 7.6.2.4-6 The coin insertion slot will remain closed until a transaction is selected for CDRL 7-12 which cash payments are available. The shutter will automatically open once the payment due has been displayed.

AGY-21-008-IT 130 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.4-7 The geometry of the coin path and other provisions of the coin acceptor will CDRL 7-12 prevent the retrieval of coins by fishing such as with wire or attached thread. 7.6.2.4-8 The coin acceptor/verifier will determine the denomination and validity of CDRL 7-12 coin types and identify invalid or counterfeit objects (“slugs”). 7.6.2.4-9 The coin acceptor/verifier will meet the following acceptance rates: CDRL 7-12 • At least 98% of valid coins are accepted upon initial insertion. • At least 99% of valid coins are accepted in no more than two insertion attempts. All known counterfeit coins, common slugs, foreign coins, and coins of denominations not accepted by the machine are rejected upon every insertion. 7.6.2.4-10 The coin acceptor/verifier will identify valid acceptable coins with at least CDRL 7-12 99.99% accuracy. 7.6.2.4-11 The coin acceptor/verifier will reject and return to a coin return bin CDRL 7-12 unverified, counterfeit, excessively bent, and foreign coins, as well as slugs and other foreign objects. 7.6.2.4-12 The coin acceptor/verifier will be key locked into the machine and will be CDRL 7-12 removable for service and replacement. 7.6.2.4-13 Upon acceptance of each inserted coin, the CHU will forward the coin to an CDRL 7-12 escrow to be stored temporarily until completion or cancellation of the transaction. 7.6.2.4-14 The coin escrow module will have the capacity to store a minimum of 20 CDRL 7-12 coins. 7.6.2.4-15 When the coin escrow is full, or a configurable limit of inserted coins per CDRL 7-12 transaction is reached, the CHU will cease accepting coins, and display a configurable warning message on the screen. 7.6.2.4-16 If the customer cancels the transaction or the TVM aborts the transaction, CDRL 7-12 and the CHU will return from escrow coins inserted for the transaction. 7.6.2.4-17 When a transaction is completed, all coins in the coin escrow module will CDRL 7-12 be transported to the coin vault for retention. Using several sensors or other means, the machine will confirm the passage of all coins to the coin vault; failure to detect a coin being deposited into the coin vault will be considered a jam, and the machine will cease accepting coins and display an appropriate message to customers. Multiple sensors throughout the coin acceptance shoot are required to identify jams. 7.6.2.4-18 Each TVM will be equipped with a removable coin vault that has a capacity CDRL 7-12 of at least 300 cubic inches and weighs no more than 50 pounds when full.

AGY-21-008-IT 131 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.4-19 The coin vault will withstand regular removal, replacement, and normal CDRL 7-12 handling without deformation or in any way interfering with the insertion and removal process. 7.6.2.4-20 It will not be possible to open the coin vault while installed in the machine, CDRL 7-12 nor will it be possible to install an open or unlocked coin vault into the machine. When properly installed in the machine, it will not be possible to access coins in the coin vault without damaging the vault in an obvious manner. 7.6.2.4-21 The coin vault will be self-locking and self-closing so that when removed CDRL 7-12 from the machine, it cannot be opened other than through an authorized process. Any coin vault will remain secure when removed from the TVM. Access to the coin vault will be granted only with keys available to revenue staff. 7.6.2.4-22 The coin vault will have a handle or handles placed to avoid injury, which CDRL 7-12 provides adequate hand clearance for easy insertion, removal, and carrying. 7.6.2.4-23 Each coin vault will include a printed and electronically encoded serial CDRL 7-12 number, and a set of serialized keys. The serial number will be read by the TVM for reporting upon coin vault insertion and removal.

7.6.2.5 Bank Card Processing Unit

Req # Requirement Assigned CDRL 7.6.2.5-1 The TVM will be PCI- and EMV-certified for the acceptance of bank-issued CDRL 7-12 credit and debit cards using all common formats based on the latest version of the standard at the time of Final Acceptance. TVMs will be capable of re- certification with newer versions of the PCI and EMV standards via software upgrades, as necessary. 7.6.2.5-2 The TVM will include a Bank Card Processing Unit (BCPU) to process bank CDRL 7-12 cards (credit and debit), including Apple Pay, Google Pay, and Samsung Pay, for the payment for fare products and media. 7.6.2.5-3 The BCPU will include: CDRL 7-12 • Magnetic stripe reader • Contactless bank card reader • Contact (or chip) bank card reader PCI- and ADA-compliant Personal Identification Number (PIN) pad

AGY-21-008-IT 132 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.5-4 The magnetic stripe and contact bank card reader will be combined to CDRL 7-12 accept and process standard-size cards with ISO/IEC 7811 magnetic data stripes and all EMV-complaint contact (chip and PIN) cards, with a configurable parameter to process debit and credit cards or to process all payment cards as credit. 7.6.2.5-5 The magnetic stripe/contact bank card reader will consist of a push/pull CDRL 7-12 (insert/remove) card reader such that the bank card is not captured completely by the reader. Sensors will detect the insertion and removal of cards from the reader unit. 7.6.2.5-6 The magnetic stripe/contact bank card reader card slot will be sealed so CDRL 7-12 that no liquids introduced into the slot enter the interior of the machine. 7.6.2.5-7 The contactless bank card reader will read and support all open payment CDRL 7-12 contactless standards, including but not limited to: • VISA payWave® • MasterCard PayPass® • American Express ExpressPay® • Discover Zip® • Contactless EMV (e.g., Apple Pay, Google Pay) 7.6.2.5-8 The contactless bankcard reader will be separate and apart from the CDRL 7-12 customer-facing smartcard reader (see Section 7.6.2.9) used to process load transactions. Both readers will be clearly identified to avoid confusion. 7.6.2.5-9 The BCPU will include a secure bank card PIN keypad. The PIN Pad will be CDRL 7-12 vandal resistant, weather-resistant, and not be removable from outside and be easily replaceable. It will have a life expectancy of 5 million cycles. 7.6.2.5-10 The layout of the keys on the PIN keypad will be similar to those of CDRL 7-12 touchtone telephones, and the central “5” key will have a raised dot or other identifying tactile feature to aid the visually impaired, in compliance with all applicable ADA requirements. The pin pad will be easily accessible to ensure users with dexterity issues or that require two hands to operate the pin pad have the space to do so. 7.6.2.5-11 The PIN keypad will employ encryption as required in accordance with CDRL 7-12 banking requirements. The SI shall supply all PIN keypads with production encryption keys injected in a secure, PCI-compliant manner. 7.6.2.5-12 The PIN keypad will be capable of operating in both an encrypting and non- CDRL 7-12 encrypting or “clear” mode so that it can be used for data entry and customer selection by the visually impaired. 7.6.2.5-13 The PIN keypad will support PIN entry when magnetic stripe debit cards are CDRL 7-12 used, and whenever EMV-enabled cards are used, and transaction procedures dictate. The PIN keypad may also be used to enter ZIP codes to satisfy address verification requirements, as a configurable parameter.

AGY-21-008-IT 133 | Page

APPENDIX 1

7.6.2.6 Smartcard Encoder/Dispenser

Req # Requirement Assigned CDRL 7.6.2.6-1 The TVM will incorporate an internal ISO/IEC 14443 contactless smartcard CDRL 7-12 reader/encoder that will be used to encode and issue contactless media stored in the TVM. This is in addition to the external contactless smartcard reader/encoder used by customers to process load transactions (see Section7.6.2.9). 7.6.2.6-2 The smartcard reader/encoder will be integrated with a media dispensing CDRL 7-12 unit that will issue the extended-use fare media specified in Section 5.5.2 and together comprise a Smartcard Encoder/Dispenser (SED). 7.6.2.6-3 The SED will utilize removable cassettes to store the contactless media card CDRL 7-12 stock. The cassettes will securely hold cards and enable service staff to replenish or exchanging cassettes quickly and securely and will include a serialized key set. 7.6.2.6-4 In total the installed cassettes will have a capacity of no less than 500 cards. CDRL 7-12 7.6.2.6-5 The SED will dispense cards into a media dispense tray or slot no more than CDRL 7-12 three (3) seconds after commencing the encode/dispense process. 7.6.2.6-6 Prior to dispensing a new card, the SED will confirm that the card is CDRL 7-12 functioning properly. If the SED cannot read the UID or verify the data is encoded correctly, the module will capture the card in a card reject bin and attempt to encode/dispense another card. 7.6.2.6-7 The card reject bin will have a capacity of no less than 10 cards and will CDRL 7-12 send rejected card information to the back-office for tracking and inventory. 7.6.2.6-8 If the SED fails to issue a card after a configurable number of attempts CDRL 7-12 (initially set to three [3]), the TVM will disable the SED module and send a maintenance alert.

7.6.2.7 Barcode Reader

Req # Requirement Assigned CDRL 7.6.2.7-1 The TVM will incorporate a 2D barcode reader to enable the loading of CDRL 7-12 value and products using a QR (or Aztek) codes that will access the customer’s transit account using the SI provided APIs. 7.6.2.7-2 The barcode reader will be optimized for scanning QR codes from mobile CDRL 7-12 screens and will accommodate a wide range of mobile device screen sizes and QR code sizes, environmental factors (e.g., sun glare, phone screen protectors, and usability factors (e.g., scanning QR code at angles ranging from 0 to 45 degrees).

AGY-21-008-IT 134 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.7-3 The barcode reader will be able to accommodate real-world environmental CDRL 7-12 factors such as different scanning angles at varying distances from the reader and shall be designed to maximize usability without customer education. 7.6.2.7-7 The barcode reader will have a LED aimer and a minimum 752x480 pixel CDRL 7-12 sensor. 7.6.2.7-7 The MTA prefers a forward or upward facing mirrored configuration with a CDRL 7-12 scan range between 0” (flush) and 6” from the barcode reader. 7.6.2.7-8 Errors with transactions and validations for all barcode scans will create a CDRL 7-12 data record.

7.6.2.8 Receipt Printer

Req # Requirement Assigned CDRL 7.6.2.8-1 The TVM will be equipped to print and issue receipts for fare transactions CDRL 7-12 and audit tickets for maintenance activities. Receipts will be printed on separate receipt stock using a thermal receipt printer. 7.6.2.8-2 The receipt printer will issue receipts and audit tickets from paper-based CDRL 7-12 roll stock that is commercially available in the U.S. Receipt stock will follow applicable standards for service and replacement.

7.6.2.8-3 The receipt printer will be able to print all alphanumeric characters in both CDRL 7-12 upper and lower case and all ASCII characters. Printed characters will be produced with a minimum height of 0.12 inches and a maximum height of up to 1 inch. 7.6.2.8-4 The receipt printer will utilize a thermal print head that provides no less CDRL 7-12 than 100 dots per inch of resolution. 7.6.2.8-5 Thermal print heads will produce no fewer than 250,000 receipts without CDRL 7-12 misprinted pixels due to wear or electronic failure. 7.6.2.8-6 The receipt printer will be equipped with a cutting mechanism to cut CDRL 7-12 individual receipts from the roll supply. Each cutter will perform at least 1 million cuts without requiring replacement or sharpening. The cutter shall be designed such that no adjustment of the cutting edges will be required.

AGY-21-008-IT 135 | Page

APPENDIX 1

7.6.2.9 Customer Interface

Req # Requirement Assigned CDRL 7.6.2.9-1 In addition to the display and other modules described in this section, CDRL 7-12 several elements on the front of the TVM will comprise the customer interface including, but not limited to: • Contactless smartcard reader • Physical pushbuttons • Audio interface • Headphone jack • Media dispense tray/slot • Instructional graphics and text • Information sign Final TVM configurations will be determined during design review. 7.6.2.9-2 A customer-facing contactless smartcard reader compliant with both Type CDRL 7-12 A and B variants of the ISO/IEC 14443 standard will be installed in the TVM to perform the following functions at a minimum: • Read contactless media to bring TVM out of idle state • Load fare products or value • Check account balance and history The reader will also have write capabilities as per risk mitigation strategies defined in Section 5.6. 7.6.2.9-3 The reader will be in “read mode” while the TVM is in the idle state (to CDRL 7-12 allow initiation of the interface via a contactless read), and during those portions of transactions where reading a contactless card is necessary. 7.6.2.9-4 The contactless reader will be separate and apart from the contactless CDRL 7-12 bank card reader that is part of the BCPU (see Section 7.6.2.5). Both readers will be clearly identified to avoid confusion. 7.6.2.9-5 In order to provide customer selection functionality, pushbuttons will be CDRL 7-12 present and following these characteristics: • Made of stainless steel, hardened aluminum, or other agency- approved hardened and weather-resistant material • Have tactile movement when pressed • Be accompanied by an audible tone when pressed • Provide less than 8 ounces of resistance when pressed • Be protected against vandalism, including impact from customers • Be liquid-proof and sealed from outside moisture • Not be removable from the outside • Compliant with all applicable ADA guidelines

AGY-21-008-IT 136 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.9-6 The TVM will include an audio interface and internally mounted vandal- CDRL 7-12 resistant speaker to provide configurable audio tones and voice annunciation. 7.6.2.9-7 TVM audio volume will be remotely and field adjustable for each TVM and CDRL 7-12 will be audible in all station environments. 7.6.2.9-8 The TVM will provide a standard jack for headphone use in addition to the CDRL 7-12 internally mounted speaker. Whenever headphones are plugged into the jack, the external speaker will be disabled, and all tones and messages will be directed to the headphone jack. 7.6.2.9-9 The TVM will include a media dispense tray or bin that will safely hold CDRL 7-12 dispensed media and receipts. 7.6.2.9-10 The media dispense tray will be recessed and may be covered with a clear CDRL 7-12 polycarbonate spring-loaded or weighted door. The dispense tray and its door will be robust, scratch-resistant, visually prominent, and resistant to intrusion from the outside. 7.6.2.9-11 The media dispense tray will be designed to drain any liquids that enter. CDRL 7-12 7.6.2.9-12 TVM instructional graphics and text will be modular and able to be CDRL 7-12 changed to match different TVM configurations, if applicable. All text will be agency-configurable, including support for up to five (5) foreign languages. 7.6.2.9-13 Instructional graphics will include diagrams that clearly depict proper CDRL 7-12 insertion orientation of bills and bank cards into their respective slots.

7.6.2.9-14 The design of instructions and graphics will minimize glare and other CDRL 7-12 effects of sunlight and ambient lighting. 7.6.2.9-15 TVM instruction text will include raised lettering and braille instructions in CDRL 7-12 conformance with ADA requirements. 7.6.2.9-16 Conceptual designs of the TVM instructions and related graphics will be CDRL 7-12 submitted during design review for agency review and approval. 7.6.2.9-17 The TVM will incorporate a removable information signage holder in a CDRL 7-12 prominent position to display printed information, including but not limited to: • Fare pricing and information • Agency contact information • Service announcements 7.6.2.9-18 The information signage holder will be suitable for use in an outdoor CDRL 7-12 environment, securely mounted, and may supplement information on the customer display.

AGY-21-008-IT 137 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.9-19 The agency will be responsible for the design and production of the CDRL 7-12 signage to be placed in the information signage holder. 7.6.2.9-20 The TVM front panel will include a convex “fisheye” mirror, which will CDRL 7-12 enable a customer using the TVM to see behind them.

7.6.2.10 Locks

Req # Requirement Assigned CDRL 7.6.2.10-1 The TVM outer door lock will utilize an electronic high-security lock such as CDRL 7-12 Cyber Lock® or agency-approved equivalent. 7.6.2.10-2 The keyways for all high-security keys will be registered to the agency, and CDRL 7-12 replacements shall be available only to authorized personnel, or their authorized representative. All keys will be serialized for inventory and control purposes.

7.6.2.10-3 Sensors will detect the status of the outer door lock. The TVM door shall CDRL 7-12 be considered open and unsecure if the outer door lock is not in the fully locked position. 7.6.2.10-4 All security locks will capture and hold the key whenever the lock is open. CDRL 7-12

7.6.2.11 Alarms

Req # Requirement Assigned CDRL 7.6.2.11-1 Each TVM will be equipped with an alarm unit that will have the ability to CDRL 7-12 monitor machine security conditions and provide alerts to the back-office in real-time. If the TVM does not have power or is disabled for any reason, the alarm unit will continue to operate independently and monitor the machine for security breaches and impacts. 7.6.2.11-2 The alarm unit will be disarmed through an authorized entry and will be CDRL 7-12 triggered by an unauthorized entry. Each time an alarm event is detected, the event record with date and time will be stored and transmitted to the back-office.

7.6.2.11-3 Adjustable sensors will detect direct physical impacts to the TVM CDRL 7-12 enclosure, breakage of the customer display, and attempts at unauthorized or forced entry. The alarm unit will activate the siren as soon as the impact sensor is triggered. The siren will shut off and re-arm after an adjustable time period unless continued impacts or attempts at intrusion are detected.

AGY-21-008-IT 138 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.11-4 Access to the interior of the TVM for maintenance and servicing using an CDRL 7-12 authorized key will disable the alarm while service is being performed. If authorized TVM access is not followed, the intrusion alarm will be activated and the TVM will record and transmit a security event. 7.6.2.11-5 A security and alarm process for TVM access will be submitted for review CDRL 7-12 and approval by the agency.

AGY-21-008-IT 139 | Page

APPENDIX 1

7.6.2.12 Communications

Req # Requirement Assigned CDRL 7.6.2.12-1 The TVM will communicate real-time with the back-office through a secure CDRL 7-12 communications interface to send and receive data including but not limited to: • Transaction information • Event (alarm and maintenance) status alerts, including but not limited to: o Hard drive failures o Low battery and battery failures o Overheating o Door malfunctions o All revenue component malfunctions o UPS failures o Out of service events o Number of swipe payment card transactions (for life cycle maintenance) o Number of bill note transactions (for life cycle maintenance) o Payment card acceptance failures including reason codes (e.g., insufficient funds) o Payment card reader failures o Bill note component failures o Bill vault component failures o Communication failures o Smartcard Encoder/Dispenser (SED) failures • Time synchronization information • Positive/negative lists • Configuration parameters • Remote commands or status inquiries • TVM identifier (unique name or number) • Station/platform name The list of communications information, including events and the name of the events that need to be sent to the back-office, will be finalized during design reviews. All information will be exportable from the back-office to CSV and PDF file formats. A web-based dashboard will be available to maintenance personnel to identify maintenance issues by TVM, using simple graphical displays, as well as the ability to easily drill down to detailed failures by TVM. The dashboard will be displayed on PC screens and at least two (2) large, flat-panel monitors (not less than 50” displays).

AGY-21-008-IT 140 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.12-2 All communications between the TVMs and back office will be via a CDRL 7-12 hardwired connection. The SI will be responsible for removing and replacing all existing Ethernet cabling runs from the communication cabinets in each metro station to the installed location of the equipment with new CAT6 or better rodent resistant or armored cabling. The SI shall be responsible for all network hardware (e.g., network switches) necessary to connect the equipment at the installed locations. 7.6.2.12-3 If required for PCI certification, a second Ethernet port will be provided to CDRL 7-12 transmit payment data separate from other transaction data. 7.6.2.12-4 The TVM cabinets will be capable of housing a network switch to enable all CDRL 7-12 devices in one area to be connected through a single connection to the station communications room and limit the number of Ethernet runs required to each installation location. 7.6.2.12-5 The capability to add a modular cellular modem will be possible if CDRL 7-12 requested by the agency at locations that do not have a hardwired network connection. 7.6.2.12-6 Each TVM will incorporate a Supervisory Control and Data Acquisition CDRL 7-12 (SCADA) interface. The SCADA signals may be daisy-chained from other devices or fed directly from a station input. 7.6.2.12-7 The TVM SCADA interface may be tied to local station controllers, CDRL 7-12 emergency management control panels, or remote-control systems to initiate emergency mode or other SCADA conditions. The TVMs will remain in emergency mode or other SCADA condition until the SCADA signal is closed or deactivated. 7.6.2.12-8 The SCADA control signals will supersede any other control signals, CDRL 7-12 including those from the System Monitoring and Management Application (see Section 8.4). For example, if the SCADA signal initiates emergency mode and an “enter revenue service” signal is sent from the SMMA, the TVM will remain in emergency mode.

AGY-21-008-IT 141 | Page

APPENDIX 1

7.6.2.13 Power Supply

Req # Requirement Assigned CDRL 7.6.2.13-1 The TVM will be equipped with a modular, filtered power supply which will CDRL 7-12 be connected to the incoming grounded electrical service. The power supply will be connected to the incoming electrical service (120 V) and deliver all of the necessary operating voltages for the machine. Voltages internal to the TVM will not exceed 125 V. Before using the existing electrical wiring, the SI will be required to first verify wiring integrity. To complete this the SI will: 1. Perform visual checks 2. Run cable insulation resistance tests 3. Run termination resistance tests. Results should be submitted in a test report for MTA review. 7.6.2.13-2 A power switch will turn the power supply on or off and will be separate CDRL 7-12 from the main circuit breaker that removes all power to the TVM. There will be no safety risks to maintenance personnel with the machine power turned off. 7.6.2.13-3 A GFCI duplex convenience outlet will be installed within the interior of CDRL 7-12 each cabinet. This outlet will be protected by a separate circuit breaker internal to the machine enclosure and will be grounded. 7.6.2.13-4 Appropriate warning labels will be provided on or near any components or CDRL 7-12 cables that may have hazardous voltages present. 7.6.2.13-5 If the TVM shuts down due to loss of power, upon restoration of power the CDRL 7-12 TVM will automatically resume operations. 7.6.2.13-6 The TVM will be equipped with a supplemental battery power supply. This CDRL 7-12 battery power supply will be used to allow a controlled shut down in the event the incoming voltage falls below the reliable machine operating voltage or in the event of loss of alternating current (AC) power to the machine. Once primary power is restored, the backup battery will be recharged. 7.6.2.13-7 The supplemental battery will be rated at four (4) years or 500 discharge CDRL 7-12 and charge cycles.

AGY-21-008-IT 142 | Page

APPENDIX 1

7.6.3 Software

7.6.3.1 Transaction Records

Req # Requirement Assigned CDRL 7.6.3.1-1 TVMs will generate, store, and transmit a discrete data record for each CDRL 7-13 transaction performed. 7.6.3.1-2 Each transaction record will be unique and will include the following information, at a minimum: • Date and time • Device ID • Station/Location ID • Card/account number • Transaction type (e.g., card sale, value load, account inquiry) • Cards sold (where applicable) • Stored value or fare products loaded (where applicable) • Fare category (e.g., full fare, reduced fare) • Transaction value (where applicable) • Payment type and amount • Transaction result (e.g., success, failure) • Transaction ID Transaction records details will be finalized during design review. 7.6.3.1-3 TVMs will maintain local data records in non-volatile memory in the event CDRL 7-13 that communications to the back-office systems are unavailable. The local records will only be removed when verification of database storage of each record is received from the back-office.

7.6.3.1-4 Any offline transactions will be recorded as such as part of the transaction CDRL 7-13 data so that offline transactions can be easily identified and tracked. Once communications are online, all offline transactions and events will be immediately sent to the back-office for processing.

7.6.3.2 Audit Registers

Req # Requirement Assigned CDRL 7.6.3.2-1 All TVMs will provide audit register counts for purposes of data tracking CDRL 7-13 and analysis. The audit registers will store counts of specific events, including access logs of maintenance personnel logging into the TVM, in non-volatile memory, and will not be able to be modified or erased.

AGY-21-008-IT 143 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.3.2-2 The audit registers will maintain counts and value of the following events CDRL 7-13 as applicable: • New fare media issued • Fare product sold • Stored value loaded • Account inquiries • Cash transaction, by amount and denomination • Credit Card transactions, by amount • Debit Card transactions, by amount • Count of approved and denied transactions • Count of read failures Final audit register events will be determined during design reviews. 7.6.3.2-3 Audit register records will be transmitted to the back-office at the end of CDRL 7-13 service day for reconciliation or based on a configurable time period.

7.6.3.3 Events and Alarms

Req # Requirement Assigned CDRL 7.6.3.3-1 TVMs will provide real-time status of device events and alarms through CDRL 7-13 the SMMA (see Section 8.4). The TVM will also maintain local event and alarm logs in the event that communications to the back-office are unavailable. 7.6.3.3-2 In addition to transmitting real-time events and alarms, the TVM will CDRL 7-13 transmit periodic “heartbeat” messages that confirm communication with back-office and basic status. The “heartbeat” frequency will be adjustable by TVM.

AGY-21-008-IT 144 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.3.3-3 The TVM will generate, store, and transmit alert information for relevant events, including but not limited to: • Power on • Power off • Reboot • Back-office communications failed/restored • Maintenance parameter changed • New fare table received/activated • New software received/activated • New configuration data received/activated • New list received/activated • Anti-virus definitions and security updates downloaded • Internal clock reset • TVM clock error • Data memory near full/full • Low battery • Failed bank card authorization request • Defective media captured in reject bin • Maintenance technician log in and logout • Maintenance parameter changed • Revenue service technician log in and logout • Bill vault removed/installed • Coin vault removed/installed • TVM “heartbeat” check Final events and alerts will be determined during design reviews. 7.6.3.3-4 The TVM will detect when the bill vault is near-full and full, and record and CDRL 7-13 transmit an event record. The determination of a nearly empty condition will be adjustable by the agency for each TVM. 7.6.3.3-5 The BHU will cease to accept bills and indicate a “no bills accepted” CDRL 7-13 message on the display when the bill vault becomes full. 7.6.3.3-6 The BHU will automatically reset all appropriate counters when the bill CDRL 7-13 vault is removed and/or replaced. 7.6.3.3-7 The coin acceptor will not accept coins once the vault has reached 90% CDRL 7-13 capacity or configurable amount. 7.6.3.3-8 The SED will monitor the contents of the card stock and transmit an event CDRL 7-13 to the back-office when the inventory is below a configurable threshold, and when the inventory is empty. 7.6.3.3-9 Whenever an alarm siren or condition is active, the TVM will go out of CDRL 7-13 service. When the alarm condition ends, the TVM will perform self- diagnostics, and resume normal operations.

AGY-21-008-IT 145 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.3.3-10 Events will be considered alarm conditions of varying severity. The CDRL 7-13 assigned priority of all alarms will be configurable by the agency. 7.6.3.3-11 For each alarm event, a corresponding event to clear the alarm will be CDRL 7-13 transmitted by the TVM as soon as the alarm condition is no longer present. Alarm conditions may be cleared either automatically by the TVM or manually by service staff. 7.6.3.3-12 The TVM will have the capacity to locally store a minimum of one (1) year CDRL 7-13 of event and alarm data.

7.6.4 Operations

7.6.4.1 Voice Annunciation

Req # Requirement Assigned CDRL 7.6.4.1-1 When the headphone jack is used, a voice annunciation system with CDRL 7-13 adjustable volume will provide context-sensitive voice messages, in audio form, conveying information shown on the device display to meet all ADA requirements. 7.6.4.1-2 Each voice annunciation message will occur as close as possible to the CDRL 7-13 event or change in transaction status as possible and be as brief as possible to convey the necessary information. 7.6.4.1-3 The voice annunciation will support multiple languages in concert with the CDRL 7-13 multi-lingual capabilities in Section 7.6.4.2. Required languages will be finalized by the agency during design review.

7.6.4.2 Multi-Lingual Capabilities

Req # Requirement Assigned CDRL 7.6.4.2-1 The TVM will include a selection button to change the display and the CDRL 7-13 voice annunciation language between English and up to five (5) other available languages. 7.6.4.2-2 The MTA will provide text translations to the SI for recording. The SI shall CDRL 7-13 hire a third-party to provide audio recordings of all translations. Audio translations will be submitted for agency review and approval. 7.6.4.2-3 English will be the default language while the TVM is in idle mode and the CDRL 7-13 TVM will return to English after a transaction is completed or canceled.

AGY-21-008-IT 146 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.4.2-4 The alternate language button will be active at all times and available on CDRL 7-13 all screens while the TVM is in service. Pressing an alternate language button at any time will cause the display and audio messages to the selected language. 7.6.4.2-5 Supported languages required for translations and audio recordings will be CDRL 7-13 provided by the agency during design review.

7.6.4.3 Customer Operations

Req # Requirement Assigned CDRL 7.6.4.3-1 The TVM will provide the following core functions to support customer CDRL 7-13 operations: • Sell one or more new cards in a single transaction where the associated transit accounts are initialized only (no value) or are loaded with value • Load stored value and all available fare products to previously issued cards (e.g., transit accounts) Query the back-office to retrieve the balance and transaction history for existing transit accounts 7.6.4.3-2 The operating status, configuration, and active fare table for each TVM will CDRL 7-13 determine the available options. Only options that are enabled will be shown to the customer. 7.6.4.3-3 For all transactions, the TVM will display a progression of screens to the CDRL 7-13 customer that will be easy to understand and intuitive. 7.6.4.3-4 All information presented by the TVM will be capable of being modified by CDRL 7-13 authorized agency staff. Modifications will be able to be made remotely or by removable storage media. 7.6.4.3-5 A detailed customer operations document, including screen, flows CDRL 7-13 depicting “snapshots” of each screen layout arranged as a logical flow chart will be provided during design review for agency review and approval. 7.6.4.3-6 Each TVM will be ready to respond to customer input when in the idle CDRL 7-13 condition. Input may be a button press or touching fare media to the contactless reader.

AGY-21-008-IT 147 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.4.3-7 The TVM “home” or starting screen, will include the following options at a CDRL 7-13 minimum: • Purchase a new card or cards • Reload an existing card • Check card balance • “Express” purchase of a card with one (1) ride (configurable) Screen flows and functions will be finalized during design review. 7.6.4.3-8 The TVM will have clear instructions to indicate the steps a customer must CDRL 7-13 follow to perform any transaction. The sequence of steps will be clearly indicated by the use of graphics and text. Wherever possible, universal graphics and symbols will be used that can be understood without having to read the displayed text. 7.6.4.3-9 The TVM will emit distinctive audio tones to provide feedback each time a CDRL 7-13 button is pressed. 7.6.4.3-10 English-speaking customers will be able to purchase a new card (with CDRL 7-13 stored value or a pass) or load value to an existing card in a maximum of three (3) screens. 7.6.4.3-11 For new card purchase transactions, the SED will read and/or encode cards CDRL 7-13 as necessary to capture account numbers and initialize the media. The TVM will send the card data to the back-office, along with all relevant fare purchase and payment information, to create and load the associated transit accounts, and generate sales transactions. 7.6.4.3-12 For card reload transactions, the external contactless reader will read (and, CDRL 7-13 if necessary, for risk mitigation, encode data to) the customer’s card. The TVM will send the card data to the back-office, along with all relevant fare purchase and payment information, to load the associated account, and generate a sales transaction. 7.6.4.3-13 For balance check transactions, the external contactless reader will read CDRL 7-13 the customer’s card. The TVM will send the card data to the back-office to retrieve the associated balance and transaction history information. 7.6.4.3-14 All transactions will be individually recorded, stored, and transmitted to CDRL 7-13 the back-office by the TVM using the SI-provided APIs (see Section 5.3.1). 7.6.4.3-15 All transactions will initiate communication with the ATP (see Section 8.2) CDRL 7-13 to query or modify transit accounts associated with the fare media in real- time. If communications with the back-office are unavailable, the TVM will enter a limited or “degraded” mode. Degraded functionality will be defined during design reviews.

AGY-21-008-IT 148 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.4.3-16 In offline mode, the TVM will be able to take cash payments to sell single CDRL 7-13 rides or other limited fare products, in order to provide a means for customers to enter gated rail stations. The details of which products will be sold in offline mode, and the risk mitigations strategies to be employed (such as writing to the media), will be determined during design review. 7.6.4.3-17 If the TVM loses communications with the back-office, upon restoration, CDRL 7-13 the TVM will automatically initiate communications and send any data generated in offline mode. 7.6.4.3-18 When payment is required, the TVM will automatically detect what form of CDRL 7-13 payment the customer has inserted. Customers will not have to choose whether the transaction will be by cash or bank card. 7.6.4.3-19 When paying by cash, the TVM will permit the customer to deposit coins CDRL 7-13 and bills in any sequence. 7.6.4.3-20 Prior to authorizing a bank card transaction, the TVM will prompt the CDRL 7-13 customer to choose whether the purchase is a credit or debit transaction. For debit transactions, the TVM will prompt for PIN entry. 7.6.4.3-21 The TVM will support Address Verification System (AVS) for bank card CDRL 7-13 payments in a configurable manner that allows the AVS feature to be turned on or off by the agency and accommodates acceptance of both U.S. and non-U.S. issued cards. When a U.S. bank card is used for payment, the TVM will prompt the customer to enter the billing address ZIP code. 7.6.4.3-22 All bank card transactions will be authorized prior to dispensing media or CDRL 7-13 loading fare products. If a bank card is declined for any reason the TVM will display related information to the customer and cancel the current transaction. 7.6.4.3-23 If bank communications are unavailable, bank card transactions will be CDRL 7-13 disabled, and the TVM will enter “cash only” mode. 7.6.4.3-24 The customer will have the ability to cancel a transaction at any point CDRL 7-13 before full payment has been inserted in cash or a bank card authorization has been received. 7.6.4.3-25 If any failure occurs during a transaction, the TVM will automatically cancel CDRL 7-13 the current transaction and indicate the cancellation on the screen. 7.6.4.3-26 If a transaction is canceled automatically or by the customer, all inserted CDRL 7-13 cash will be returned, and credit/debit card transactions will be reversed, as necessary.

AGY-21-008-IT 149 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.4.3-27 The TVM will be configurable to provide receipts: CDRL 7-13 • Upon customer request • Automatically for transactions above a configurable dollar value, or optionally for transactions below the configurable value • For every transaction Never (when receipt stock is empty) 7.6.4.3-28 All receipts will have a printed indication that the receipt is not a valid CDRL 7-13 ticket, and will contain at least the following information: • Machine Number – up to eight (8) alphanumeric characters • Date – month, day and the last two (2) digits of the year, totaling nine (9) characters • Time – four (4) digits separated by a colon and followed by two (2) letters “AM” or “PM,” using a 12-hour clock • Station name or location where purchased – up to 16 characters • Card/Account number • Value purchased and remaining balance (if applicable) • Transaction amount • Machine-unique transaction sequence number Final receipt information will be determined during design review. 7.6.4.3-29 Receipts for bank card transactions will also include information as CDRL 7-13 identified in Federal Regulations E and Z, and other information necessary to comply with banking and Federal regulations. 7.6.4.3-30 The TVM will employ an adjustable time-out period to return the TVM to CDRL 7-13 the idle state if no input is received between transaction steps. The time- out period will be adjustable by authorized staff. 7.6.4.3-31 A screen saver may be activated after a programmable idle period has CDRL 7-13 passed, and will support the following at a minimum: • Static image in any common graphics format, e.g., JPG, TIFF, BMP, GIF • A repeating “slide show” of static images • Text messages and imported text-based files • Webpages and other dynamic markup language files • Pre-recorded video in any common codec and format, including MPEG, WMV, MOV, AVI, H.264 Any combination of the above 7.6.4.3-32 The screen saver will automatically terminate and the TVM will display the CDRL 7-13 home screen as soon as any button is pressed, or a card is presented to the contactless reader.

AGY-21-008-IT 150 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.4.3-33 For all new card purchase transactions, the time from acceptance of the CDRL 7-13 cash payment or credit/debit card approval to media issuance will not exceed three (3) seconds. 7.6.4.3-34 Where transactions produce multiple media, the time between successive CDRL 7-13 media being deposited in the return tray will not exceed two (2) seconds each. 7.6.4.3-35 When applicable, the receipt printer will deposit receipts in the return tray CDRL 7-13 within three (3) seconds of the completion of a transaction. 7.6.4.3-36 For completed or canceled transactions, the TVM readiness to begin CDRL 7-13 another transaction will not exceed three (3) seconds.

7.6.4.4 Service Operations

Req # Requirement Assigned CDRL 7.6.4.4-1 A detailed service operations document including service procedures and CDRL 7-13 screen flows will be provided during design review for agency review and approval. 7.6.4.4-2 Each TVM will automatically perform self-diagnostic tests upon startup, CDRL 7-13 and at adjustable regular intervals (once per day by default). Self- diagnostic tests will at a minimum: • Confirm communications with back-office • Check the status of all major electronic modules • Exercise all electro-mechanical devices • Confirm all software and configuration files are up to date Any failures or exceptions identified during self-diagnostics will be recorded in the TVM’s internal audit registers and transmitted to the back- office. 7.6.4.4-3 Each TVM will be capable of performing test diagnostic tests that are CDRL 7-13 manually initiated by service staff while the TVM is out of service and the front door is open. 7.6.4.4-4 Inside the TVM will be a keypad, and keyboard if needed, and optional CDRL 7-13 display for use by maintenance and revenue service personnel while the outer door is open. The customer display may be used for maintenance purposes if viewable while using the service keypad. 7.6.4.4-5 The service keypad will be used to enter access (login) codes and CDRL 7-13 maintenance and diagnostic commands. All routine service interaction with the TVM will be via this keypad.

AGY-21-008-IT 151 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.4.4-6 A failure to login using the keypad after opening the TVM door will CDRL 7-13 generate an intrusion alarm. 7.6.4.4-7 The service display will be used to indicate TVM error codes and will have CDRL 7-13 the capability of displaying multiple error codes, such that one error code will not need to be cleared to display other error codes. 7.6.4.4-8 The TVM will not commence in-service operation until the outer door is CDRL 7-13 closed and the outer door lock is returned to its fully secured position. 7.6.4.4-9 All-access will be traceable through the System Monitoring and CDRL 7-13 Management Application (see Section 8.4) and all access transactions will be individually recorded and transmitted to the SMMA at the time of occurrence. 7.6.4.4-10 To support revenue servicing and maintenance authorized technicians, the CDRL 7-13 TVM will produce audit tickets, including but not limited to: • Coin vault removal/insertion • Bill vault removal/insertion • Software versions and TVM configuration • TVM revenue status • TVM maintenance alert status Final audit ticket information will be determined during design review. 7.6.4.4-11 Each audit ticket will indicate at a minimum: date, time, TVM number, CDRL 7-13 technician name or number, and activity information.

7.7 Simple Ticket Vending Machine (PRICED OPTION) The simple TVM (sTVM) is envisioned to be a smaller version of the Full-Service TVM and offer a subset of the features. These sTVMs will be deployed at light rail stations , including the Purple Line, and allow riders to purchase limited-use fare media.

7.7.1 General Requirements

Req # Requirement Assigned CDRL 7.7.1-1 The sTVM will be designed as a simple, low-maintenance, and low- CDRL 7-14 complexity machine in a cost-saving design that provides the functionality specified herein and the common design requirements in Section 4.

AGY-21-008-IT 152 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.1-2 The sTVM will be designed to accommodate users who need to purchase CDRL 7-14 limited-use fare media or paper tickets. At a minimum, these functions will be supported: • Purchase contactless limited use fare media or paper tickets • Accept U.S. coins and bills • Accept magnetic stripe, and EMV contact and contactless bank cards, including mobile wallets (e.g., Apple Pay, Google Pay, and Samsung Pay) • Print and issue receipts • Display instructions and notices • Provide audio output of messages and instructions, configurable by the user at the sTVM • Contain required intrusion alarm system with audible alarm at sTVM locations • Communicate over a network to send and receive transaction data in real-time A full list of transactions and detailed process flows will be determined during design reviews. 7.7.1-3 The sTVM will be modular with the ability to disable or enable the CDRL 7-14 hardware components listed in Section 7.7.2 individually. The modules and components will be easily serviced as specified in Section 7.7.4.4. 7.7.1-4 If a component or function is enabled/disabled, the sTVM will CDRL 7-14 automatically adjust its display, operation, and maintenance status according to the active components. 7.7.1-5 The sTVM will be able to accept credit and debit cards and cash/coin for CDRL 7-14 payment. 7.7.1-6 One type of fare media will be issued by default. The sTVM will be able to CDRL 7-14 be configured to issue either limited-use contactless media specified in Section 5.5, or paper tickets that use paper stock with built-in security features to be defined during design review. Alternate media types may be configured for issuance in the future if it does not have an impact on the simple design of the machine.

AGY-21-008-IT 153 | Page

APPENDIX 1

7.7.2 Hardware

7.7.2.1 Enclosure

Req # Requirement Assigned CDRL 7.7.2.1-1 The overall dimensions of the sTVM enclosure will not exceed 70 inches CDRL 7-14 high, 20 inches wide, and 15 inches deep. The agency prefers a simple design without excess size or features that may contribute to increased costs. 7.7.2.1-2 The design of the sTVM enclosure will permit installation as stand-alone CDRL 7-14 units, side-by-side units, or back-to-back units, and in recessed areas. 7.7.2.1-3 sTVM cabinets will be constructed from stainless steel without any visible CDRL 7-14 fasteners. The enclosure finish and corners will be rounded to avoid sharp edges, corners, or protrusions that may cause injury to customers. 7.7.2.1-4 sTVM enclosures will be rugged and function under harsh environmental CDRL 7-14 conditions including: direct sunlight, moisture, dust/grit/sand, humidity, electrical storms, exposure to an urban environment, and the range of elevations and altitudes in the operating region , per the requirements in Section 4.7. 7.7.2.1-5 sTVM enclosures will be resistant to corrosion, abrasion, scratching, CDRL 7-14 impacts, and vandalism, and withstand standard cleaning materials. Color and finish will be such that it minimizes reflection and is highly resistant to fading, cracking, and peeling. 7.7.2.1-6 The cabinet will be constructed to provide the highest protection against CDRL 7-14 vandalism and burglary. Reinforcement will be provided at the locations (screen, door hinges, access ports, etc.) where there is a higher possibility of vandalism. 7.7.2.1-7 The sTVM mounting pedestal and any external features (such as button CDRL 7-14 panels, rain shields, and light fixtures) will be weatherized, robust, and vandal resistant. 7.7.2.1-8 While all outer doors are secured, the machine will remain operational and CDRL 7-14 undamaged after experiencing any impact resulting in a concentrated load of 400 pounds per one (1) square inch on any part of the enclosure. 7.7.2.1-9 The sTVM cabinet and mounting hardware will accommodate variations in CDRL 7-14 station and sidewalk construction. Mounting pedestals will be sized according to need, and specifics will be provided by the agency during design review. All installed sTVMs must comply with ADA requirements, including but not limited to the distance (minimum and maximum height) of user functions while at any MTA platform grade.

AGY-21-008-IT 154 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.1-10 The sTVM cabinet will provide controlled levels of access to the interior of CDRL 7-14 the equipment for maintenance personnel, revenue servicing personnel, and cash processing personnel, as defined by the agency. Locks must be secured locks, programmable to more than one key. CyberLocks (#CLT- T6H) and CyberKey (#CK-IR7) will be used from Crest Lock Co., Inc. for all light rail and Metro station sTVMs. 7.7.2.1-11 The enclosure will accommodate signage, markings, and other CDRL 7-14 instructional materials produced by the agency. 7.7.2.1-12 As necessary, blanking plates will be provided for installation over any CDRL 7-14 outer door openings resulting from the removal of an external component or module. All such blanking plates will be easily secured and will provide security against intrusion and vandalism. 7.7.2.1-13 The sTVM enclosure and pedestal design will be submitted to the agency CDRL 7-14 for review and approval.

7.7.2.2 Display

Req # Requirement Assigned CDRL 7.7.2.2-1 The sTVM will include a customer display screen bearing simple and easy CDRL 7-14 to read instructions which sequentially instruct the customer how to perform available functions. 7.7.2.2-2 The display screen will consist of a color, trans-reflective backlit flat panel CDRL 7-14 display that is clearly viewable in daytime and nighttime conditions. 7.7.2.2-3 The display screen will measure at least 9” inches diagonally. CDRL 7-14 7.7.2.2-4 The display screen will provide a resolution of no less than 1024 by 768 CDRL 7-14 pixels, and at least 65,000 colors (RGB 16 bit) per pixel. 7.7.2.2-5 The display screen will produce a minimum of 500 nits brightness with at CDRL 7-14 least a 500:1 contrast ratio, and provide a level of visibility sufficient to allow all displayed instructions to be read easily by the customer under all ambient light conditions, including direct sunlight, and without the need for any additional peripheral light source or shading device. 7.7.2.2-6 The display will have the ability to adjust brightness automatically based CDRL 7-14 on ambient light conditions in order to maximize visibility. 7.7.2.2-7 The display screen will display characters and symbols compliant with all CDRL 7-14 ADA requirements. 7.7.2.2-8 The visibility and usability of the display will be unaffected by CDRL 7-14 precipitation, temperature, sunlight, and other environmental conditions typical of the Baltimore operating region.

AGY-21-008-IT 155 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.2-9 The display will be protected to be resistant to scratches, vandalism, and CDRL 7-14 other wear. Coatings or other materials applied to the outer surface of the display’s protective shield will withstand normal customer use, industry- standard station cleaning materials, and be easily replaced if necessary. 7.7.2.2-10 The display screen will be easily replaceable from within the sTVM interior CDRL 7-14 and require minimal maintenance effort. 7.7.2.2-11 All portions of the display screen will be visible and not obstructed by any CDRL 7-14 portion of the sTVM door, mounting bezels, or other external elements. 7.7.2.2-12 The display screen will be installed close enough to the sTVM surface to CDRL 7-14 avoid any parallax effect, or the apparent shift of screen objects relative to customer touches or button placement.

7.7.2.3 Bill Handling Unit

Req # Requirement Assigned CDRL 7.7.2.3-1 The sTVM Bill Handling Unit (BHU) will accept paper currency and include a CDRL 7-14 bill validator, escrow module, and bill vault. 7.7.2.3-2 The bill validator will be capable of accepting all variations of $1, $2, $5, CDRL 7-14 $10, $20, $50, and $100 bills in circulation at the time of Final Acceptance. 7.7.2.3-3 As the U.S. Treasury releases new designs of bills, the bill validator will be CDRL 7-14 capable of being programmed to accept the new designs while continuing to accept the current designs. 7.7.2.3-4 The bill validator will be equipped with a protective shutter to ensure that CDRL 7-14 foreign matter does not enter the BHU while the machine is not accepting bills. 7.7.2.3-5 The bill validator will remain closed until a transaction is selected for which CDRL 7-14 cash payments are available. The shutter will automatically open once the payment due has been displayed. 7.7.2.3-6 The bill validator will be able to accept bills inserted in any of the four CDRL 7-14 possible lengthwise orientations. 7.7.2.3-7 The bill validator will accept one bill at a time and will determine the CDRL 7-14 denomination and validity of the currency. 7.7.2.3-8 The bill validator will determine the denomination and validity of both CDRL 7-14 sides of a document by dimension checks and pattern and color recognition.

AGY-21-008-IT 156 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.3-9 The bill validator will meet the following acceptance rates: CDRL 7-14 • At least 98% of valid bills are accepted upon initial insertion. • At least 99% of valid bills are accepted in no more than two insertion attempts. 7.7.2.3-10 The bill validator will identify valid acceptable bills with at least 99.999% CDRL 7-14 accuracy. 7.7.2.3-11 The bill acceptor may reject bills with excessive physical defects. CDRL 7-14 7.7.2.3-12 The bill validator will be able to detect counterfeit bills, including copies CDRL 7-14 made in either single or double-sided printing on an electronic copier and those made with color printers. 7.7.2.3-14 The bill validator will be designed to reject or expel pieces of paper or CDRL 7-14 other foreign material that can be introduced into the bill insertion slot. 7.7.2.3-15 The bill validator will be secured via a high-security lock and will be CDRL 7-14 separately removable for servicing. 7.7.2.3-21 The BHU will be equipped with a removable bill vault. The bill vault will CDRL 7-14 have a capacity of no less than 500 stacked bills in street condition and weigh no more than 50 pounds when full. 7.7.2.3-22 The bill vault will be constructed of sturdy and tamper-proof material and CDRL 7-14 will withstand normal handling and regular removal and replacement without deformation that would in any way interfere with the insertion and removal process. 7.7.2.3-23 It will not be possible to open the bill vault while installed in the BHU, nor CDRL 7-14 will it be possible to install an open or unlocked bill vault into the BHU. When properly installed in the BHU, it will not be possible to access bills in the bill vault without damaging the vault in an obvious manner. 7.7.2.3-24 The bill vault will remain secure when removed from the sTVM. Access to CDRL 7-14 the bill vault will be granted only with keys available to revenue staff. 7.7.2.3-25 The bill vault will have handles placed to avoid injury and provide CDRL 7-14 adequate hand clearance for easy insertion, removal, and carrying. 7.7.2.3-26 Each bill vault will include a printed and electronically encoded serial CDRL 7-14 number. The serial number will be read by the sTVM for reporting upon bill vault insertion and removal.

AGY-21-008-IT 157 | Page

APPENDIX 1

7.7.2.4 Coin Handling Unit

Req # Requirement Assigned CDRL 7.7.2.4-1 sTVMs will be equipped with a Coin Handling Unit (CHU) including, but not CDRL 7-14 limited to, a coin acceptor/verifier, a coin escrow module, and a coin vault. 7.7.2.4-2 The coin acceptor/verifier will accept all variations of nickels, dimes, CDRL 7-14 quarters, and dollar coins in circulation at the time of Final Acceptance. 7.7.2.4-3 As the U.S. Treasury releases new designs of coins, the coin CDRL 7-14 acceptor/verifier will be capable of being programmed to accept the new designs while continuing to accept the current designs. 7.7.2.4-4 The coin acceptor will contain a coin insertion slot that will be sized to limit CDRL 7-14 the dimensions of inserted material to the largest coin accepted. To minimize jams, the coin slot will also be sized to prevent the simultaneous insertion of two coins. 7.7.2.4-5 The coin insertion slot will be equipped with a protective shutter to ensure CDRL 7-14 that foreign matter does not enter the CHU while the machine is not accepting coins. 7.7.2.4-6 The coin insertion slot will remain closed until a transaction is selected for CDRL 7-14 which cash payments are available. The shutter will automatically open once the payment due has been displayed. 7.7.2.4-7 The geometry of the coin path and other provisions of the coin acceptor CDRL 7-14 will prevent the retrieval of coins by fishing such as with wire or attached thread. 7.7.2.4-8 The coin acceptor/verifier will determine the denomination and validity of CDRL 7-14 coin types and identify invalid or counterfeit objects (“slugs”). 7.7.2.4-9 The coin acceptor/verifier will meet the following acceptance rates: CDRL 7-14 • At least 98% of valid coins are accepted upon initial insertion. • At least 99% of valid coins are accepted in no more than two insertion attempts. All known counterfeit coins, common slugs, foreign coins, and coins of denominations not accepted by the machine are rejected upon every insertion. 7.7.2.4-10 The coin acceptor/verifier will identify valid acceptable coins with at least CDRL 7-14 99.99% accuracy. 7.7.2.4-11 The coin acceptor/verifier will reject and return to a coin return bin CDRL 7-14 unverified, counterfeit, excessively bent, and foreign coins, as well as slugs and other foreign objects. 7.7.2.4-12 The coin acceptor/verifier will be key locked into the machine and will be CDRL 7-14 removable for service and replacement.

AGY-21-008-IT 158 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.4-18 Each sTVM will be equipped with a removable coin vault. CDRL 7-14 7.7.2.4-19 The coin vault will withstand regular removal, replacement, and normal CDRL 7-14 handling without deformation or in any way interfering with the insertion and removal process. 7.7.2.4-20 It will not be possible to open the coin vault while installed in the machine, CDRL 7-14 nor will it be possible to install an open or unlocked coin vault into the machine. When properly installed in the machine, it will not be possible to access coins in the coin vault without damaging the vault in an obvious manner. 7.7.2.4-21 The coin vault will be self-locking and self-closing so that when removed CDRL 7-14 from the machine, it cannot be opened other than through an authorized process. Any coin vault will remain secure when removed from the sTVM. Access to the coin vault will be granted only with keys available to revenue staff. 7.7.2.4-22 The coin vault will have a handle or handles placed to avoid injury, which CDRL 7-14 provides adequate hand clearance for easy insertion, removal, and carrying. 7.7.2.4-23 Each coin vault will include a printed and electronically encoded serial CDRL 7-14 number, and a set of serialized keys. The serial number will be read by the sTVM for reporting upon coin vault insertion and removal.

7.7.2.5 Bank Card Processing Unit

Req # Requirement Assigned CDRL 7.6.2.5-1 The sTVM will be PCI- and EMV-certified for the acceptance of bank-issued CDRL 7-14 credit and debit cards using all common formats based on the latest version of the standard at the time of Final Acceptance. sTVMs will be capable of re-certification with newer versions of the PCI and EMV standards via software upgrades, as necessary. 7.6.2.5-2 The sTVM will include a Bank Card Processing Unit (BCPU) to process bank CDRL 7-14 cards (credit and debit), including mobile wallets (e.g., Apple Pay, Google Pay, and Samsung Pay), for the payment for fare products and media. 7.6.2.5-3 The BCPU will include: CDRL 7-14 • Magnetic stripe reader • Contactless bank card reader • Contact (or chip) bank card reader • PCI- and ADA-compliant Personal Identification Number (PIN) pad

AGY-21-008-IT 159 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.5-4 The magnetic stripe and contact bank card reader will be combined to CDRL 7-14 accept and process standard-size cards with ISO/IEC 7811 magnetic data stripes and all EMV-complaint contact (chip and PIN) cards, with a configurable parameter to process debit and credit cards or to process all payment cards as credit. 7.6.2.5-5 The magnetic stripe/contact bank card reader will consist of a push/pull CDRL 7-14 (insert/remove) card reader such that the bank card is not captured completely by the reader. Sensors will detect the insertion and removal of cards from the reader unit. 7.6.2.5-6 The magnetic stripe/contact bank card reader card slot will be sealed so CDRL 7-14 that no liquids introduced into the slot enter the interior of the machine. 7.6.2.5-7 The contactless bank card reader will read and support all open payment CDRL 7-14 contactless standards, including but not limited to: • VISA payWave® • MasterCard PayPass® • American Express ExpressPay® • Discover Zip® • Contactless EMV (e.g., Apple Pay, Google Pay) 7.6.2.5-8 The contactless bankcard reader will be separate and apart from the CDRL 7-14 customer-facing smartcard reader (see Section 7.7.2.9) used to process load transactions. Both readers will be clearly identified to avoid confusion. 7.6.2.5-9 The BCPU will include a secure bank card PIN keypad. The PIN Pad will be CDRL 7-14 vandal resistant, weather-resistant, and not be removable from outside and be easily replaceable. It will have a life expectancy of 5 million cycles. 7.6.2.5-10 The layout of the keys on the PIN keypad will be similar to those of CDRL 7-14 touchtone telephones, and the central “5” key will have a raised dot or other identifying tactile feature to aid the visually impaired, in compliance with all applicable ADA requirements. The pin pad will be easily accessible to ensure users with dexterity issues or that require two hands to operate the pin pad have the space to do so. 7.6.2.5-11 The PIN keypad will employ encryption as required in accordance with CDRL 7-14 banking requirements. The SI shall supply all PIN keypads with production encryption keys injected in a secure, PCI-compliant manner. 7.6.2.5-12 The PIN keypad will be capable of operating in both an encrypting and CDRL 7-14 non-encrypting or “clear” mode so that it can be used for data entry and customer selection by the visually impaired.

AGY-21-008-IT 160 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.6.2.5-13 The PIN keypad will support PIN entry when magnetic stripe debit cards CDRL 7-14 are used, and whenever EMV-enabled cards are used, as transaction procedures dictate. The PIN keypad may also be used to enter ZIP codes to satisfy address verification requirements, as a configurable parameter.

7.7.2.6 Media Encoder/Dispenser

Req # Requirement Assigned CDRL 7.7.2.6-1 The sTVM will incorporate an internal media dispensing unit that will issue either limited-use fare media specified in Section 7.4.2 or paper tickets. 7.7.2.6-2 When configured to issue limited-use contactless media, the media CDRL 7-14 dispensing unit will be integrated with a ISO/IEC 14443 contactless smartcard reader/encoder that will be used to encode and issue limited- use contactless media stored in the sTVM. This is in addition to the external contactless smartcard reader/encoder used by customers to process load transactions (see Section 7.7.2.9). 7.7.2.6-3 The media dispensing unit will include a thermal printer capable of printing CDRL 7-14 on both limited-use contactless media and paper stock with built-in security features. The media dispensing unit, with the printer and contactless reader, if included, is collectively referred to as the Media Encoder/Dispenser (MED). 7.7.2.6-4 The MED will utilize removable rolls for the contactless and paper media. CDRL 7-14 The rolls will securely hold the media and enable service staff to quickly replenish or exchanging stock with a serialized key set. 7.7.2.6-5 The sTVM will have a capacity of no less than 500 limited-use or paper CDRL 7-14 tickets. 7.7.2.6-6 The MED will dispense limited-use or paper tickets into a media dispense CDRL 7-14 tray or slot no more than three (3) seconds after commencing the encode/dispense process. 7.7.2.6-7 Prior to dispensing a limited use ticket, the MED will confirm that the CDRL 7-14 ticket is functioning properly. If the MED cannot read the media or verify the data is encoded correctly, the module will capture the ticket in a reject bin and attempt to encode/dispense another ticket. 7.7.2.6-8 When issuing a paper ticket, a printer error will result in the ticket being CDRL 7-14 sent to the reject bin and another ticket being printed. 7.7.2.6-9 The reject bin will have a capacity of no less than 10 tickets and will send CDRL 7-14 rejected ticket information to the back-office for tracking and inventory.

AGY-21-008-IT 161 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.6-10 If the MED fails to issue a ticket after a configurable number of attempts CDRL 7-14 (initially set to three [3]), the sTVM will disable the MED module and send a maintenance alert.

7.7.2.7 Barcode Reader

Req # Requirement Assigned CDRL 7.7.2.7-1 The sTVM will incorporate a 2D barcode reader to enable the loading of CDRL 7-14 value and products using a QR (or Aztek) codes that will access the customer’s transit account using the SI provided APIs. 7.7.2.7-2 The barcode reader will be optimized for scanning QR codes from mobile CDRL 7-14 screens and will accommodate a wide range of mobile device screen sizes and QR code sizes under wide range of environmental factors (e.g., sun glare, phone screen protectors). 7.7.2.7-3 The barcode reader will be able to accommodate real-world environmental CDRL 7-14 factors, such as different scanning angles (ranging from at least 0 to 45 degrees) and at varying distances from the reader, and shall be designed to maximize usability without customer education. 7.7.2.7-7 The barcode reader will have a LED aimer and a minimum 752x480 pixel CDRL 7-14 sensor. 7.7.2.7-7 The MTA prefers a forward or upward facing mirrored configuration with a CDRL 7-14 scan range between 0” (flush) and 6” from the barcode reader. 7.7.2.7-8 Errors with transactions and validations for all barcode scans will create a CDRL 7-14 data record.

7.7.2.8 Receipt Printer

Req # Requirement Assigned CDRL 7.7.2.8-1 The sTVM will be equipped to print and issue receipts for fare transactions CDRL 7-14 and audit tickets for maintenance activities. 7.7.2.8-2 Receipts will be able to include all alphanumeric characters in both upper CDRL 7-14 and lower case and all ASCII characters. Printed characters will be produced with a minimum height of 0.12 inches and a maximum height of up to 1 inch. 7.7.2.8-3 The printer will utilize a thermal print head that provides no less than 100 CDRL 7-14 dots per inch of resolution.

AGY-21-008-IT 162 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.8-4 Thermal print heads will produce no fewer than 250,000 receipts without CDRL 7-14 misprinted pixels due to wear or electronic failure. 7.7.2.8-5 The printer will be equipped with a cutting mechanism to cut individual CDRL 7-14 receipts from the roll supply. Each cutter will perform at least 1 million cuts without requiring replacement or sharpening. The cutter shall be designed such that no adjustment of the cutting edges will be required.

7.7.2.9 Customer Interface

Req # Requirement Assigned CDRL 7.7.2.9-1 In addition to the display and other modules described in this section, CDRL 7-14 several elements on the front of the sTVM will comprise the customer interface including, but not limited to: • Physical pushbuttons • Audio interface • Headphone jack • Media dispense tray/slot • Instructional graphics and text • Information sign Final sTVM configurations will be determined during design review. 7.7.2.9-5 In order to provide customer selection functionality, pushbuttons will be CDRL 7-14 present and following these characteristics: • Made of stainless steel, hardened aluminum, or other agency- approved hardened and weather-resistant material • Have tactile movement when pressed • Be accompanied by an audible tone when pressed • Provide less than 8 ounces of resistance when pressed • Be protected against vandalism, including impact from customers • Be liquid-proof and sealed from outside moisture • Not be removable from the outside • Compliant with all applicable ADA guidelines 7.7.2.9-6 The sTVM will include an audio interface and internally mounted vandal- CDRL 7-14 resistant speaker to provide configurable audio tones and voice annunciation. 7.7.2.9-7 sTVM audio volume will be remotely and field adjustable for each sTVM CDRL 7-14 and will be audible in all station environments.

AGY-21-008-IT 163 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.9-8 The sTVM will provide a standard jack for headphone use in addition to the CDRL 7-14 internally mounted speaker. Whenever headphones are plugged into the jack, the external speaker will be disabled, and all tones and messages will be directed to the headphone jack. 7.7.2.9-9 The sTVM will include a media dispense tray or bin that will safely hold CDRL 7-14 dispensed media and receipts. 7.7.2.9-10 The media dispense tray will be recessed and may be covered with a clear CDRL 7-14 polycarbonate spring-loaded or weighted door. The dispense tray and its door will be robust, scratch-resistant, visually prominent, and resistant to intrusion from the outside. 7.7.2.9-11 The media dispense tray will be designed to drain any liquids that enter. CDRL 7-14 7.7.2.9-12 sTVM instructional graphics and text will be modular and able to be CDRL 7-14 changed to match different sTVM configurations, if applicable. All text will be agency-configurable, including support for up to five (5) foreign languages. 7.7.2.9-13 Instructional graphics will include diagrams that clearly depict proper CDRL 7-14 insertion orientation of bills and bank cards into their respective slots. 7.7.2.9-14 The design of instructions and graphics will minimize glare and other CDRL 7-14 effects of sunlight and ambient lighting. 7.7.2.9-15 sTVM instruction text will include raised lettering and braille instructions in CDRL 7-14 conformance with ADA requirements. 7.7.2.9-16 Conceptual designs of the sTVM instructions and related graphics will be CDRL 7-14 submitted during design review for agency review and approval. 7.7.2.9-17 The sTVM will incorporate a removable information signage holder in a CDRL 7-14 prominent position to display printed information, including but not limited to: • Fare pricing and information • Agency contact information • Service announcements 7.7.2.9-18 The information signage holder will be suitable for use in an outdoor CDRL 7-14 environment, securely mounted, and may supplement information on the customer display. 7.7.2.9-19 The agency will be responsible for the design and production of the CDRL 7-14 signage to be placed in the information signage holder. 7.7.2.9-20 The sTVM front panel will include a convex “fisheye” mirror, which will CDRL 7-14 enable a customer using the sTVM to see behind them.

AGY-21-008-IT 164 | Page

APPENDIX 1

7.7.2.10 Locks

Req # Requirement Assigned CDRL 7.7.2.10-1 The sTVM outer door lock will utilize an electronic high-security lock such CDRL 7-14 as Cyber Lock® or agency-approved equivalent. 7.7.2.10-2 The keyways for all high-security keys will be registered to the agency, and CDRL 7-14 replacements shall be available only to authorized personnel, or their authorized representative. All keys will be serialized for inventory and control purposes.

7.7.2.10-3 Sensors will detect the status of the outer door lock. The sTVM door shall CDRL 7-14 be considered open and unsecure if the outer door lock is not in the fully locked position. 7.7.2.10-4 All security locks will capture and hold the key whenever the lock is open. CDRL 7-14

7.7.2.11 Alarms

Req # Requirement Assigned CDRL 7.7.2.11-1 Each sTVM will be equipped with an alarm unit that will have the ability to CDRL 7-14 monitor machine security conditions and provide alerts to the back-office in real-time. If the sTVM does not have power or is disabled for any reason, the alarm unit will continue to operate independently and monitor the machine for security breaches and impacts. 7.7.2.11-2 The alarm unit will be disarmed through an authorized entry and will be CDRL 7-14 triggered by an unauthorized entry. Each time an alarm event is detected, the event record with date and time will be stored and transmitted to the back-office.

7.7.2.11-3 Adjustable sensors will detect direct physical impacts to the sTVM CDRL 7-14 enclosure, breakage of the customer display, and attempts at unauthorized or forced entry. The alarm unit will activate the siren as soon as the impact sensor is triggered. The siren will shut off and re-arm after an adjustable time period unless continued impacts or attempts at intrusion are detected. 7.7.2.11-4 Access to the interior of the sTVM for maintenance and servicing using an CDRL 7-14 authorized key will disable the alarm while service is being performed. If authorized sTVM access is not followed, the intrusion alarm will be activated and the sTVM will record and transmit a security event. 7.7.2.11-5 A security and alarm process for sTVM access will be submitted for review CDRL 7-14 and approval by the agency.

AGY-21-008-IT 165 | Page

APPENDIX 1

7.7.2.12 Communications

Req # Requirement Assigned CDRL 7.7.2.12-1 The sTVM will communicate real-time with the back-office through a CDRL 7-14 secure communications interface to send and receive data including but not limited to: • Transaction information • Event (alarm and maintenance) status alerts, including but not limited to: o Hard drive failures o Low battery and battery failures o Overheating o Door malfunctions o All revenue component malfunctions o UPS failures o Out of service events o Number of swipe payment card transactions (for life cycle maintenance) o Number of bill note transactions (for life cycle maintenance) o Payment card acceptance failures including reason codes (e.g., insufficient funds) o Payment card reader failures o Bill note component failures o Bill vault component failures o Communication failures o Smartcard Encoder/Dispenser (SED) failures • Time synchronization information • Configuration parameters • Remote commands or status inquiries • sTVM identifier (unique name or number) • Station/platform name The list of communications information, including events and the name of the events that need to be sent to the back-office, will be finalized during design reviews. All information will be exportable from the back-office to CSV and PDF file formats. A web-based dashboard will be available to maintenance personnel to identify maintenance issues by sTVM, using simple graphical displays, as well as the ability to easily drill down to detailed failures by sTVM. The dashboard will be displayed on PC screens and at least two (2) large, flat-panel monitors (not less than 50” displays).

AGY-21-008-IT 166 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.12-2 All communications between the sTVMs and back office will be via a CDRL 7-14 hardwired connection. The SI will be responsible for removing and replacing all existing Ethernet cabling runs from the communication cabinets in each metro station to the installed location of the equipment with new CAT6 or better rodent resistant or armored cabling. The SI shall be responsible for all network hardware (e.g., network switches) necessary to connect the equipment at the installed locations. 7.7.2.12-3 If required for PCI certification, a second Ethernet port will be provided to CDRL 7-14 transmit payment data separate from other transaction data. 7.7.2.12-4 The sTVM cabinets will be capable of housing a network switch to enable CDRL 7-14 all devices in one area to be connected through a single connection to the station communications room and limit the number of Ethernet runs required to each installation location. 7.7.2.12-5 The capability to add a modular cellular modem will be possible if CDRL 7-14 requested by the agency at locations that do not have a hardwired network connection. 7.7.2.12-6 Each sTVM will incorporate a Supervisory Control and Data Acquisition CDRL 7-14 (SCADA) interface. The SCADA signals may be daisy-chained from other devices or fed directly from a station input.. 7.7.2.12-7 The sTVM SCADA interface may be tied to local station controllers, CDRL 7-14 emergency management control panels, or remote-control systems to initiate emergency mode or other SCADA conditions. The sTVMs will remain in emergency mode or other SCADA condition until the SCADA signal is closed or deactivated. 7.7.2.12-8 The SCADA control signals will supersede any other control signals, CDRL 7-14 including those from the System Monitoring and Management Application (see Section 10.4). For example, if the SCADA signal initiates emergency mode and an “enter revenue service” signal is sent from the SMMA, the sTVM will remain in emergency mode.

7.7.2.13 Power Supply

Req # Requirement Assigned CDRL 7.7.2.13-1 Solar power is preferred by the agency. Solar-powered sTVMs will include CDRL 7-14 a 12V 27AH battery to provide backup power. 7.7.2.13-2 If the sTVM shuts down due to loss of power, upon restoration of power CDRL 7-14 the sTVM will automatically resume operations.

AGY-21-008-IT 167 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.2.13-3 The sTVM will be equipped with a modular, filtered power supply which CDRL 7-14 will be connected to the incoming grounded electrical service. The power supply will be connected to the incoming electrical service (120 V) and deliver all of the necessary operating voltages for the machine. Voltages internal to the sTVM will not exceed 125 V. 7.7.2.13-4 A power switch will turn the power supply on or off and will be separate CDRL 7-14 from the main circuit breaker that removes all power to the sTVM. There will be no safety risks to maintenance personnel with the machine power turned off. 7.7.2.13-5 A GFCI duplex convenience outlet will be installed within the interior of CDRL 7-14 each cabinet. This outlet will be protected by a separate circuit breaker internal to the machine enclosure and will be grounded. 7.7.2.13-6 Appropriate warning labels will be provided on or near any components or CDRL 7-14 cables that may have hazardous voltages present.

7.7.3 Software

7.7.3.1 Transaction Records

Req # Requirement Assigned CDRL 7.7.3.1-1 sTVMs will generate, store, and transmit a discrete data record for each CDRL 7-15 transaction performed. 7.7.3.1-2 Each transaction record will be unique and will include the following information, at a minimum: • Date and time • Device ID • Station/Location ID • Card/account number • Transaction type (e.g., sale) • Limited-use media/paper ticket sold • Stored value or fare products loaded • Fare category (e.g., full fare, reduced fare) • Transaction value • Payment type and amount • Transaction result (e.g., success, failure) • Transaction ID Transaction records details will be finalized during design review.

AGY-21-008-IT 168 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.3.1-3 sTVMs will maintain local data records in non-volatile memory in the event CDRL 7-15 that communications to the back-office systems are unavailable. The local records will only be removed when verification of database storage of each record is received from the back-office.

7.7.3.1-4 Any offline transactions will be recorded as such as part of the transaction CDRL 7-15 data so that offline transactions can be easily identified and tracked. Once communications are online, all offline transactions and events will be immediately sent to the back-office for processing.

7.7.3.2 Audit Registers

Req # Requirement Assigned CDRL 7.7.3.2-1 All sTVMs will provide audit register counts for purposes of data tracking CDRL 7-15 and analysis. The audit registers will store counts of specific events, including access logs of maintenance personnel logging into the sTVM, in non-volatile memory, and will not be able to be modified or erased. 7.7.3.2-2 The audit registers will maintain counts and value of the following events CDRL 7-15 as applicable: • New fare media issued • Fare product sold • Stored value loaded • Account inquiries • Cash transaction, by amount and denomination • Credit Card transactions, by amount • Debit Card transactions, by amount • Count of approved and denied transactions • Count of read failures Final audit register events will be determined during design reviews. 7.7.3.2-3 Audit register records will be transmitted to the back-office at the end of CDRL 7-15 service day for reconciliation or based on a configurable time period.

AGY-21-008-IT 169 | Page

APPENDIX 1

7.7.3.3 Events and Alarms

Req # Requirement Assigned CDRL 7.7.3.3-1 sTVMs will provide real-time status of device events and alarms through CDRL 7-15 the SMMA (see Section 8.4.). The sTVM will also maintain local event and alarm logs in the event that communications to the back-office are unavailable. 7.7.3.3-2 In addition to transmitting real-time events and alarms, the sTVM will CDRL 7-15 transmit periodic “heartbeat” messages that confirm communication with back-office and basic status. The “heartbeat” frequency will be adjustable by sTVM. 7.7.3.3-3 The sTVM will generate, store, and transmit alert information for relevant CDRL 7-15 events, including but not limited to: • Power on • Power off • Reboot • Back-office communications failed/restored • Maintenance parameter changed • New fare table received/activated • New software received/activated • New configuration data received/activated • New list received/activated • Anti-virus definitions and security updates downloaded • Internal clock reset • sTVM clock error • Data memory near full/full • Low battery • Failed bank card authorization request • Defective media captured in reject bin • Maintenance technician log in and logout • Maintenance parameter changed • Revenue service technician log in and logout • Bill vault removed/installed • Coin vault removed/installed • Printer jam/failure • sTVM “heartbeat” check Final events and alerts will be determined during design reviews. 7.7.3.3-4 The sTVM will detect when the bill vault is near-full and full, and record CDRL 7-15 and transmit an event record. The determination of a near-full condition will be adjustable by the agency for each sTVM. 7.7.3.3-5 The BHU will cease to accept bills and indicate a “no bills accepted” CDRL 7-15 message on the display when the bill vault becomes full.

AGY-21-008-IT 170 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.3.3-6 The BHU will automatically reset all appropriate counters when the bill CDRL 7-15 vault is removed and/or replaced. 7.7.3.3-7 The coin acceptor will not accept coins once the vault has reached 90% CDRL 7-15 capacity or configurable amount. 7.7.3.3-8 The SED will monitor the contents of the card stock and transmit an event CDRL 7-15 to the back-office when the inventory is below a configurable threshold, and when the inventory is empty. 7.7.3.3-9 Whenever an alarm siren or condition is active, the sTVM will go out of CDRL 7-15 service. When the alarm condition ends, the sTVM will perform self- diagnostics, and resume normal operations. 7.7.3.3-10 Events will be considered alarm conditions of varying severity. The CDRL 7-15 assigned priority of all alarms will be configurable by the agency. 7.7.3.3-11 For each alarm event, a corresponding event to clear the alarm will be CDRL 7-15 transmitted by the sTVM as soon as the alarm condition is no longer present. Alarm conditions may be cleared either automatically by the sTVM or manually by service staff. 7.7.3.3-12 The sTVM will have the capacity to locally store a minimum of one (1) year CDRL 7-15 of event and alarm data.

7.7.4 Operations

7.7.4.1 Voice Annunciation

Req # Requirement Assigned CDRL 7.7.4.1-1 When the headphone jack is used, a voice annunciation system with CDRL 7-15 adjustable volume will provide context-sensitive voice messages, in audio form, conveying information shown on the device display to meet all ADA requirements. 7.7.4.1-2 Each voice annunciation message will occur as close as possible to the CDRL 7-15 event or change in transaction status as possible and be as brief as possible to convey the necessary information. 7.7.4.1-3 The voice annunciation will support multiple languages in concert with the CDRL 7-15 multi-lingual capabilities in Section 7.7.4.2. Required languages will be finalized by the agency during design review.

AGY-21-008-IT 171 | Page

APPENDIX 1

7.7.4.2 Multi-Lingual Capabilities

Req # Requirement Assigned CDRL 7.7.4.2-1 The sTVM will include a selection button to change the display and the CDRL 7-15 voice annunciation language between English and up to five (5) other available languages. 7.7.4.2-2 The MTA will provide text translations to the SI for recording. The SI shall CDRL 7-15 hire a third-party to provide audio recordings of all translations. Audio translations will be submitted for agency review and approval. 7.7.4.2-3 English will be the default language while the sTVM is in idle mode and the CDRL 7-15 sTVM will return to English after a transaction is completed or canceled. 7.7.4.2-4 The alternate language button will be active at all times and available on all CDRL 7-15 screens while the sTVM is in service. Pressing an alternate language button at any time will cause the display and audio messages to the selected language. 7.7.4.2-5 Supported languages required for translations and audio recordings will be CDRL 7-15 provided by the agency during design review.

7.7.4.3 Customer Operations

Req # Requirement Assigned CDRL 7.7.4.3-1 The sTVM will be able to sell one or more limited use fare media or paper CDRL 7-15 tickets in a single transaction 7.7.4.3-2 The operating status, configuration, and active fare table for each sTVM CDRL 7-15 will determine the available options. Only options that are enabled will be shown to the customer. 7.7.4.3-3 For all transactions, the sTVM will display a progression of screens to the CDRL 7-15 customer that will be easy to understand and intuitive. 7.7.4.3-4 All information presented by the sTVM will be capable of being modified CDRL 7-15 by authorized agency staff. Modifications will be able to be made remotely or by removable storage media. 7.7.4.3-5 A detailed customer operations document, including screen, flows CDRL 7-15 depicting “snapshots” of each screen layout arranged as a logical flow chart will be provided during design review for agency review and approval. 7.7.4.3-6 The sTVM will have clear instructions to indicate the steps a customer must CDRL 7-15 follow to perform any transaction. The sequence of steps will be clearly indicated by the use of graphics and text. Wherever possible, universal graphics and symbols will be used that can be understood without having to read the displayed text.

AGY-21-008-IT 172 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.4.3-7 English-speaking customers will be able to complete a purchase in a CDRL 7-15 maximum of three (3) screens. 7.7.4.3-8 For sales transactions, the SED will read and/or encode cards as necessary CDRL 7-15 to capture account numbers and initialize the media. The sTVM will send the card data to the back-office, along with all relevant fare purchase and payment information, to create and load the associated transit accounts, and generate sales transactions. 7.7.4.3-9 All transactions will be individually recorded, stored, and transmitted to CDRL 7-15 the back-office by the sTVM using the SI-provided APIs (see Section 5.3.1). 7.7.4.3-10 All transactions will initiate communication with the ATP (see Section 8.2) CDRL 7-15 to query or modify transit accounts associated with the fare media in real- time. If communications with the back-office are unavailable, the sTVM will enter a limited or “degraded” mode. Degraded functionality will be defined during design reviews. 7.7.4.3-11 In offline mode, the sTVM will be able to take cash payments to sell single CDRL 7-15 rides or other limited fare products, in order to provide a means for customers to enter gated rail stations. The details of which products will be sold in offline mode, and the risk mitigations strategies to be employed (such as writing to the media), will be determined during design review. 7.7.4.3-12 If the sTVM loses communications with the back-office, upon restoration, CDRL 7-15 the sTVM will automatically initiate communications and send any data generated in offline mode. 7.7.4.3-13 When payment is required, the sTVM will automatically detect what form CDRL 7-15 of payment the customer has inserted. Customers will not have to choose whether the transaction will be by cash or bank card. 7.7.4.3-14 When paying by cash, the sTVM will permit the customer to deposit coins CDRL 7-15 and bills in any sequence. 7.7.4.3-15 Prior to authorizing a bank card transaction, the sTVM will prompt the CDRL 7-15 customer to choose whether the purchase is a credit or debit transaction. For debit transactions, the sTVM will prompt for PIN entry. 7.7.4.3-16 The sTVM will support Address Verification System (AVS) for bank card CDRL 7-15 payments in a configurable manner that allows the AVS feature to be turned on or off by the agency and accommodates acceptance of both U.S. and non-U.S. issued cards. When a U.S. bank card is used for payment, the sTVM will prompt the customer to enter the billing address ZIP code. 7.7.4.3-17 All bank card transactions will be authorized prior to dispensing media or CDRL 7-15 loading fare products. If a bank card is declined for any reason the sTVM will display related information to the customer and cancel the current transaction.

AGY-21-008-IT 173 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.4.3-18 If bank communications are unavailable, bank card transactions will be CDRL 7-15 disabled, and the sTVM will enter “cash only” mode. 7.7.4.3-19 The customer will have the ability to cancel a transaction at any point CDRL 7-15 before full payment has been inserted in cash or a bank card authorization has been received. 7.7.4.3-20 If any failure occurs during a transaction, the sTVM will automatically CDRL 7-15 cancel the current transaction and indicate the cancellation on the screen. 7.7.4.3-21 If a transaction is canceled automatically or by the customer, all inserted CDRL 7-15 cash will be returned, and credit/debit card transactions will be reversed, as necessary. 7.7.4.3-22 The sTVM will be configurable to provide receipts: CDRL 7-15 • Upon customer request • Automatically for transactions above a configurable dollar value, or optionally for transactions below the configurable value • For every transaction • Never (when receipt stock is empty) 7.7.4.3-23 All receipts will have a printed indication that the receipt is not a valid CDRL 7-15 ticket, and will contain at least the following information: • Machine Number – up to eight (8) alphanumeric characters • Date – month, day and the last two (2) digits of the year, totaling nine (9) characters • Time – four (4) digits separated by a colon and followed by two (2) letters “AM” or “PM,” using a 12-hour clock • Station name or location where purchased – up to 16 characters • Card/Account number • Value purchased and remaining balance (if applicable) • Transaction amount • Machine-unique transaction sequence number Final receipt information will be determined during design review. 7.7.4.3-24 Receipts for bank card transactions will also include information as CDRL 7-15 identified in Federal Regulations E and Z, and other information necessary to comply with banking and Federal regulations. 7.7.4.3-25 The sTVM will employ an adjustable time-out period to return the sTVM to CDRL 7-15 the idle state if no input is received between transaction steps. The time- out period will be adjustable by authorized staff.

AGY-21-008-IT 174 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.4.3-26 A screen saver may be activated after a programmable idle period has CDRL 7-15 passed, and will support the following at a minimum: • Static image in any common graphics format, e.g., JPG, TIFF, BMP, GIF • A repeating “slide show” of static images • Text messages and imported text-based files • Webpages and other dynamic markup language files • Pre-recorded video in any common codec and format, including MPEG, WMV, MOV, AVI, H.264 Any combination of the above 7.7.4.3-27 The screen saver will automatically terminate and the sTVM will display the CDRL 7-15 home screen as soon as any button is pressed, or a card is presented to the contactless reader. 7.7.4.3-28 For all purchase transactions, the time from acceptance of the cash CDRL 7-15 payment or credit/debit card approval to media issuance will not exceed three (3) seconds. 7.7.4.3-29 Where transactions produce multiple media, the time between successive CDRL 7-15 media being deposited in the return tray will not exceed two (2) seconds each. 7.7.4.3-30 When applicable, the receipt printer will deposit receipts in the return tray CDRL 7-15 within three (3) seconds of the completion of a transaction. 7.7.4.3-31 For completed or canceled transactions, the sTVM readiness to begin CDRL 7-15 another transaction will not exceed three (3) seconds.

7.7.4.4 Service Operations

Req # Requirement Assigned CDRL 7.7.4.4-1 A detailed service operations document including service procedures and CDRL 7-15 screen flows will be provided during design review for agency review and approval.

AGY-21-008-IT 175 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.4.4-2 Each sTVM will automatically perform self-diagnostic tests upon startup, CDRL 7-15 and at adjustable regular intervals (once per day by default). Self- diagnostic tests will at a minimum: • Confirm communications with back-office • Check the status of all major electronic modules • Exercise all electro-mechanical devices • Confirm all software and configuration files are up to date Any failures or exceptions identified during self-diagnostics will be recorded in the sTVM’s internal audit registers and transmitted to the back-office. 7.7.4.4-3 Each sTVM will be capable of performing test diagnostic tests that are CDRL 7-15 manually initiated by service staff while the sTVM is out of service and the front door is open. 7.7.4.4-4 Inside the sTVM will be a keypad, and keyboard if needed, and optional CDRL 7-15 display for use by maintenance and revenue service personnel while the outer door is open. The customer display may be used for maintenance purposes if viewable while using the service keypad. 7.7.4.4-5 The service keypad will be used to enter access (login) codes and CDRL 7-15 maintenance and diagnostic commands. All routine service interaction with the sTVM will be via this keypad. 7.7.4.4-6 A failure to login using the keypad after opening the sTVM door will CDRL 7-15 generate an intrusion alarm. 7.7.4.4-7 The service display will be used to indicate sTVM error codes and will have CDRL 7-15 the capability of displaying multiple error codes, such that one error code will not need to be cleared to display other error codes. 7.7.4.4-8 The sTVM will not commence in-service operation until the outer door is CDRL 7-15 closed and the outer door lock is returned to its fully secured position. 7.7.4.4-9 All-access will be traceable through the System Monitoring and CDRL 7-15 Management Application (see Section 10.4) and all access transactions will be individually recorded and transmitted to the SMMA at the time of occurrence. 7.7.4.4-10 To support revenue servicing and maintenance authorized technicians, the CDRL 7-15 sTVM will produce audit tickets, including but not limited to: • Coin vault removal/insertion • Bill vault removal/insertion • Software versions and sTVM configuration • sTVM revenue status • sTVM maintenance alert status Final audit ticket information will be determined during design review.

AGY-21-008-IT 176 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.7.4.4-11 Each audit ticket will indicate at a minimum: date, time, sTVM number, CDRL 7-15 technician name or number, and activity information.

7.8 Customer Service Point of Sale

7.8.1 General Requirements

Req # Requirement Assigned CDRL 7.8.1-1 The Customer Service Terminal (CST) will be a modular device, used to CDRL 7-8 support fare sales, card personalization, and many other functions, and will support multiple configurations, depending on the peripheral modules included. The CST hardware will be optimized for its intended use and configuration. 7.8.1-2 CSTs will be designed to permit the rapid exchange of the device and CDRL 7-8 peripheral modules to restore service in minimal time. Repairs will be performed in the field and no special tools or instruments will be required for the exchange of modules. 7.8.1-3 The SI shall supply CST in multiple configurations, all of which will utilize CDRL 7-8 the same SI-supplied application and OEM software. 7.8.1-4 The Sales Office CST will provide all functions available and will be installed CDRL 7-8 for walk-up customer transactions. The device will include: • Integrated touchscreen and computer enclosure • Separate keyboard and mouse • Contactless smartcard reader • 2D Barcode scanner to read barcoded fare media • Cash drawer • Bank card processing module • Customer display • Receipt printer • Digital camera and tripod • Document scanner • Extended-use smartcard printer/encoder • Uninterruptible power supply • Communications interfaces as necessary

AGY-21-008-IT 177 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.1-5 The Portable CST will be based on a laptop computer or tablet with an CDRL 7-8 integrated touchscreen interface, keyboard, and pointing device. The portable configuration will support remote sales and card personalization programs. The device will include the following modules, which will be identical to those used for the Sales Office CST (except where noted): • Contactless smartcard reader • 2D Barcode scanner to read barcoded fare media • Bank card processing module • Receipt printer • Digital camera and tripod • Document scanner • Extended-use smartcard printer/encoder • Cellular broadband data modem (specific to Portable CST Terminal) and other communications interfaces as necessary 7.8.1-6 All CST configurations and peripheral modules will be subject to agency CDRL 7-8 review and approval. 7.8.1-7 To accommodate the required variety of installation locations, the CST CDRL 7-8 (excluding peripheral modules) will be compact and easily positioned for user comfort.

AGY-21-008-IT 178 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.1-8 The CST will conduct a variety of transactions. At a minimum, these transactions will include: • Sell all supported fare media (and create new transit accounts) • Sell all supported fare products (e.g., stored value and passes) and load fare products to transit accounts • Query transit account status (e.g., associated rider classification, active/inactive, blocked/unblocked) • Query fare payment transaction history • Query sales transaction history • Query adjustment transaction history • Enable fare product for autoload (requires funding source in customer account) • Generation of fare payment reversal (e.g., cancellation) • Generation of sales reversal (e.g., refund) • Generation of an account adjustment (e.g., credit or debit) • Transfer of balance between two accounts • Block/unblock card, account, or individual fare product • Lost, stolen, or damaged card replacement (e.g., associate new card with an existing account) • Generation of an opt-out refund (e.g., close transit account and issue refund) • Create new individual customer account • Create new institutional customer account • Query customer account status/data • Modify customer account data • Register (e.g., link) a transit account to an individual or institutional customer account • Unregister (e.g., unlink) a transit account from an individual or institutional customer account • Add a funding source to an individual or institutional customer account • Close an individual or institutional customer account • Encoding, printing, and issuance of personalized extended-use fare media (when configured to do so), including the addition of a photo

AGY-21-008-IT 179 | Page

APPENDIX 1

7.8.2 Hardware

7.8.2.1 Personal Computers

Req # Requirement Assigned CDRL 7.8.2.1-1 The CST will include an integrated flat panel touchscreen display with full CDRL 7-8 HD (1920×1080) resolution. 7.8.2.1-2 The touchscreen will provide suitable touch sensitivity and resolution to CDRL 7-8 satisfy operator selection and input requirements. 7.8.2.1-3 The CST will include integrated Gigabit Ethernet or a cellular broadband CDRL 7-8 modem to satisfy the requirements of the configuration. 7.8.2.1-4 If possible, there is a preference for the CST to be delivered as a web- CDRL 7-8 based application, where the required peripheral modules could also be attached to existing PCs.

7.8.2.2 Keyboard and Pointing Device

Req # Requirement Assigned CDRL 7.8.2.2-1 The Sales Office CST will include a separate full-sized keyboard and a CDRL 7-8 mouse with a scrolling wheel. 7.8.2.2-2 The Portable CST will include an integrated keyboard and pointing device. CDRL 7-8

7.8.2.3 Contactless Smartcard Reader

Req # Requirement Assigned CDRL 7.8.2.3-1 The contactless smartcard reader will be a separate module cabled to the CDRL 7-8 CST. 7.8.2.3-2 The CST will support the ability to interface with two (2) contactless CDRL 7-8 smartcard readers, one (1) each for the customer and the clerk.

7.8.2.4 Barcode Reader

Req # Requirement Assigned CDRL 7.8.2.4-1 The barcode reader will be a separate module optimized to read QR codes CDRL 7-8 from mobile screens. 7.8.2.4-2 The reader will be a separate module cabled to the CST and accessible to CDRL 7-8 the customer to allow the scanning of a mobile virtual card.

AGY-21-008-IT 180 | Page

APPENDIX 1

7.8.2.5 Cash Drawer Module

Req # Requirement Assigned CDRL 7.8.2.5-1 The cash drawer will open only under command of the CST, which will CDRL 7-8 monitor the status of the drawer at all times. 7.8.2.5-2 The cash drawer will incorporate an insert with space for five (5) bill CDRL 7-8 denominations and five (5) coin denominations. 7.8.2.5-3 When the cash drawer opens or closes, an alarm or bell will sound CDRL 7-8 indicating when the drawer has released and is open, and when the drawer has been closed and is locked. 7.8.2.5-4 The cash drawer will accommodate installation under a counter, be pry- CDRL 7-8 resistant, and be made of high-quality, heavy-gauge steel.

7.8.2.6 Bank Card Processing Module

Req # Requirement Assigned CDRL 7.8.2.6-1 The CST will be PCI- and EMV-certified for the acceptance of bank-issued CDRL 7-8 credit and debit cards using all common formats based on the latest version of the standard at the time of Final Acceptance. CSTs will be capable of re-certification with newer versions of the PCI and EMV standards via software upgrades, as necessary. 7.8.2.6-2 The bank card processing module will be an integrated module cabled to CDRL 7-8 the CST. 7.8.2.6-3 The bank card processing module will include: CDRL 7-8 • Magnetic stripe reader • Contactless bank card reader • Contact (or chip) bank card reader • PCI- and ADA-compliant Personal Identification Number (PIN) pad 7.8.2.6-4 The contactless bank card reader will read and support all open payment CDRL 7-8 contactless standards, including but not limited to: • VISA payWave® • MasterCard PayPass® • American Express ExpressPay® • Discover Zip® • Contactless EMV • Google Pay • Apple Pay • Samsung Pay • LG Pay

AGY-21-008-IT 181 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.2.6-5 The bank card processing module will include a secure bank card PIN pad. CDRL 7-8 The layout of the keys on the PIN pad will be similar to those of touchtone telephones, and the central “5” key will have a raised dot or other identifying tactile feature to aid the visually impaired, in compliance with all applicable ADA requirements. 7.8.2.6-6 The bank card processing module will employ PIN encryption as required CDRL 7-8 in accordance with banking requirements. The SI shall supply bank card processing modules with production encryption keys injected in a secure, PCI-compliant manner. 7.8.2.6-7 The PIN keypad will support PIN entry when magnetic stripe debit cards CDRL 7-8 are used, and whenever EMV-enabled cards are used, and transaction procedures dictate. The PIN pad may also be used to enter ZIP codes to satisfy address verification requirements. 7.8.2.6-8 The CST will support the ability to interface with two (2) bank card CDRL 7-8 processing modules, one (1) each for the customer and the clerk.

7.8.2.7 Receipt Printer

Req # Requirement Assigned CDRL 7.8.2.7-1 The CST receipt printer will print on a single roll of continuous thermal CDRL 7-8 paper. 7.8.2.7-2 The receipt printer will provide for the easy loading of a new paper roll. CDRL 7-8 7.8.2.7-3 The receipt printer will have a cutting edge to enable the operator to CDRL 7-8 manually separate the receipt from the roll.

7.8.2.8 Customer Display

Req # Requirement Assigned CDRL 7.8.2.8-1 The customer display will convey transaction price, status, and other CDRL 7-8 pertinent information. 7.8.2.8-2 The customer display will separately mount on a pole or other support for CDRL 7-8 optimum visibility for all customers, including those in wheelchairs. 7.8.2.8-3 The customer display will use a backlit liquid crystal display (LCD), LED, or CDRL 7-8 other highly visible display technology suitable for the office environment. 7.8.2.8-4 The customer display will provide no less than two (2) lines of text, with a CDRL 7-8 minimum of 24 characters per line, with each character no less than 0.5 inches high.

AGY-21-008-IT 182 | Page

APPENDIX 1

7.8.2.9 Digital Camera and Tripod

Req # Requirement Assigned CDRL 7.8.2.9-1 When configured to issue personalized fare media, the CSTs will include a CDRL 7-8 digital camera and tripod for capturing customer photos. 7.8.2.9-2 The camera will include a built-in flash and an image sensor of no less than CDRL 7-8 five (5) megapixels. The camera will produce images of suitable resolution, clarity, and contrast to satisfy the requirements of photo ID cards. 7.8.2.9-3 For each camera, the SI shall provide a tripod optimized for the specific CDRL 7-8 CST installation and photo-capture location.

7.8.2.10 Scanner

Req # Requirement Assigned CDRL 7.8.2.10-1 When configured to issue personalized fare media, the CSTs will include a CDRL 7-8 digital scanner for capturing customer eligibility documents and securely transmitting the documents to the back-office. 7.8.2.10-2 The scanner will support the capture of black & white and color images at CDRL 7-8 a resolution of at least 1200 x 1200 dpi. 7.8.2.10-3 The scanner will support the auto-feeding of documents and support CDRL 7-8 double-side scanning at no less than 10 pages per minute.

7.8.2.11 Extended Use Smart Card Printer/Encoder

Req # Requirement Assigned CDRL 7.8.2.11-1 The EU smartcard printer/encoder module will utilize re-transfer printing CDRL 7-8 technology and will encode EU smartcards with requisite data (such as an encrypted token) in coordination with the printing process. 7.8.2.11-2 The EU smartcard printer/encoder will print edge-to-edge (e.g., “full CDRL 7-8 bleed”) in at least four (4) colors (YMCK), and will apply the printed images to a laminate film and then apply the laminate to either side of the card. 7.8.2.11-3 The EU smartcard printer/encoder will employ easily replaceable ribbons CDRL 7-8 for the transfer printing and lamination films. 7.8.2.11-4 The EU smartcard printer/encoder will provide print resolution no less CDRL 7-8 than 300 dots per inch. 7.8.2.11-5 The EU smartcard printer/encoder will produce at least 75 cards per hour. CDRL 7-8

AGY-21-008-IT 183 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.2.11-6 The EU smartcard printer/encoder will include input and output card CDRL 7-8 hoppers with a capacity of no less than 100 cards each, which will be lockable for security. 7.8.2.11-7 Upon successful printing and encoding, the EU smartcard printer/encoder CDRL 7-8 will inform the CST of the successful issuance of each card, and the identification number of each issued card.

7.8.2.12 Communications

Req # Requirement Assigned CDRL 7.8.2.12-1 The CST will communicate with the back-office via a secure Internet CDRL 7-8 connection to send and receive transaction information, event and status information, clock synchronization information, positive/negative lists, and configuration parameters. This will be possible both automatically at scheduled times and manually by authorized users. 7.8.2.12-2 All communications between the back-office and the CSTs will be via a CDRL 7-8 direct Ethernet connection or cellular broadband data modem. 7.8.2.12-3 For all transactions requiring back-office access to a transit account, or CDRL 7-8 establishing a new account, the CST will communicate with the back-office in real-time using the SI-provided APIs (see Section 5.3.1). 7.8.2.12-4 Transactions requiring back-office access to a transit account will be CDRL 7-8 disabled if the CST is unable to communicate with the back-office. 7.8.2.12-5 CST communication with the back-office will be able to be initiated CDRL 7-8 manually at any time without affecting the automated procedures. 7.8.2.12-6 If the CST has missed a scheduled communication with the back-office, CDRL 7-8 upon restoration of communications, the CST will automatically initiate communications.

7.8.2.13 Uninterruptible Power Supply

Req # Requirement Assigned CDRL 7.8.2.13-1 Each CST will receive power from a dedicated Uninterruptible Power CDRL 7-8 Supply (UPS) with sufficient battery capacity to operate all components of the CST for a minimum of 10 minutes. 7.8.2.13-2 The UPS will allow the CST to perform a controlled shut down without any CDRL 7-8 loss of data whenever the UPS determines that there has been a loss of primary power.

AGY-21-008-IT 184 | Page

APPENDIX 1

7.8.2.13-3 The UPS will provide no less than 500 joules of overvoltage (surge) CDRL 7-8 protection for all connected devices.

7.8.3 Software

7.8.3.1 Operating System and Application Software

Req # Requirement Assigned CDRL 7.8.3.1-1 The CST will utilize a standard, current Microsoft Windows® operating CDRL 7-9 system. All OEM-supplied operating system and application software will be subject to agency review and approval during design review. 7.8.3.1-2 The CST will use application software that is developed with a high-level CDRL 7-9 language and that supports all functions described herein. 7.8.3.1-3 If risk mitigation (e.g., positive/negative) lists are employed (see Section CDRL 7-9 5.6), the CST will receive and store updated lists from the back-office. If a card presented for replenishment is on a risk mitigation list, the CST will act accordingly. 7.8.3.1-4 Once installed, the CST will not enter service until it has communicated CDRL 7-9 with the back-office to receive current fare tables, application software, administrative and maintenance logins, positive/negative lists, and other configuration data. 7.8.3.1-5 Authorized users will be able to remotely monitor and manage the CSTs CDRL 7-9 using the SMMA (see Section 8.4). Remote management functions will include: • Changing configuration parameters • Enabling and disabling payment methods • Downloading data • Extracting transaction and event records • Synchronizing date and time 7.8.3.1-6 On each CST, the SI shall supply, install, and configure client versions of CDRL 7-9 anti-virus and anti-malware software.

AGY-21-008-IT 185 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.3.1-7 The SI shall submit descriptions of the CST software design for agency CDRL 7-9 review and approval. CST software design submittals will include: • CST data registers • CST transaction, event, login, etc. records • CST operator interface • CST configuration parameters and their value range • CST risk mitigation list storage, update, and processing (if applicable) • CST transaction limitation procedures • CST setup and administration procedures • CST login types and permitted functions • CST anti-virus and anti-malware software and procedures

7.8.3.2 Data Records

Req # Requirement Assigned CDRL

7.8.3.2-1 The CST will generate transactions and events, including operator login CDRL 7-9 and logout and diagnostics. Each data record will incorporate a unique identification number for that CST and day and will be date/time stamped. 7.8.3.2-2 Each CST customer transaction record will consist of the following, at a CDRL 7-9 minimum: • Date and time • Device ID • Location ID • Operator (e.g., clerk) ID • Card/account number • Transaction type (e.g., card sale, value load, account inquiry) • Cards sold (where applicable) • Stored value or fare products loaded (where applicable) • Fare category (e.g., full fare, reduced fare) • Transaction value (where applicable) • Payment type and amount • Transaction result (e.g., success, failure) • Transaction ID Transaction records details will be finalized during design review.

AGY-21-008-IT 186 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

7.8.3.2-3 When a user signs on to the CST, the following data will be stored in a data CDRL 7-9 record: • Date and time • Device ID • Location ID • Operator ID • Login attempts When the user logs off the CST, the device will store a similar record. 7.8.3.2-4 The CST will be capable of detecting basic internal malfunctions and will CDRL 7-9 annunciate failures directly on the operator display and to the SMMA (see Section 8.4). The malfunction detection will cover at least failure of power or control circuitry, and any failure of the contactless smartcard reader that could result in a false, incomplete, or corrupted encoding of a smartcard. 7.8.3.2-5 The CST will be capable of recording data locally representing no less than CDRL 7-9 1,000 events, including changes in status, communication problems, and problems detected during the automatic diagnostic testing. At a minimum, each event record will include: • Date and time • Device ID • Event code • Any associated event data • Identifier of the failed test • Iteration number of test • Reason for test failure (unique code) Additional information to define the nature of the failure 7.8.3.2-6 Each CST will contain audit registers that track the following information at CDRL 7-9 a minimum: • The total count and value of all transactions completed by the CST since data was last uploaded to the back-office. • The date and time of the last successful data upload to the back- office. These registers will be modified only by the CST itself and will not be manually alterable. 7.8.3.2-7 Audit register records will be transmitted to the back-office at the end of CDRL 7-9 service day for reconciliation, or upon a configurable time period.

AGY-21-008-IT 187 | Page

APPENDIX 1

7.8.3.3 Fare Table Updates

Req # Requirement Assigned CDRL

7.8.3.3-1 The CST will maintain a table of fares which will include the list of all CDRL 7-9 products to be sold or replenished, their prices, characteristic parameters (such as the validity periods for unlimited ride passes), and other dynamic information such as the text to display on the operating and customer displays and receipts. 7.8.3.3-2 Each time the CST communicates with the back-office, the back-office will CDRL 7-9 transmit any updates to the fare table; the CST will store any such updates, as necessary. With each update of the fare table, the CST will confirm that the table has been properly updated. 7.8.3.3-3 The CST will retain in non-volatile memory the current and at least two (2) CDRL 7-9 future fare tables. Each future fare table will include all entries to reflect the intended fare structure and the date and time at which the new fare structure is to take effect. 7.8.3.3-4 Any new fare table will be activated automatically in the CST at the CDRL 7-9 specified date/time as programmed by the agency.

7.8.3.4 Software Updates

Req # Requirement Assigned CDRL

7.8.3.4-1 When required, modification of the CST application software and any OEM CDRL 7-9 application or operating system software will be performed by downloading new software from the back-office. The back-office database will record and track the version number of all such software in each CST, and the date that the software versions were downloaded and installed. 7.8.3.4-2 Each time the CST communicates with the back-office, the back-office will CDRL 7-9 transmit any updates to the CST application software. The CST will not commence updating the application software until it has received and verified the complete update. 7.8.3.4-3 Upon receipt and verification of the software update, the CST will apply CDRL 7-9 the update (rebooting if necessary) at a time configurable by the agency for each CST.

AGY-21-008-IT 188 | Page

APPENDIX 1

7.8.3.5 Configuration Control

Req # Requirement Assigned CDRL

7.8.3.5-1 Operating parameters will be downloadable to the CST from the back- CDRL 7-9 office via the wide-area network provided by the agency and cellular data networks, as appropriate for each installation or CST configuration. 7.8.3.5-2 The CST will support configurability through numerous adjustable CDRL 7-9 parameters. The CST application software will at minimum support configuration for: • Value of deposit to be collected for new or replaced fare media • Fare products available for sale and upgrade • Pricing • Payment method selection • Receipt content • All text and touchscreen labels • Authorized users and passwords (if stored locally at the CST) • All other relevant fare table entries

7.8.3.6 Smart Media Inventory Control

Req # Requirement Assigned CDRL

7.8.3.6-1 Upon issuance and/or initialization of a smartcard, the CST will record an CDRL 7-9 issue record, including the date, time, fare category, card identification number, and other pertinent information of the smart card and any associated account. The CST will transmit this record to the back-office. 7.8.3.6-2 The Media Inventory Management System (MIMS) (see Section 8.5) will CDRL 7-9 track the smartcards distributed to each agency sales location. Using the list of cards issued to each sales location and the issuance and/or initialization records previously transmitted to the back-office, it will be possible for authorized users to query the MIMS for the identification numbers and total quantity of smart media that remain in each sale location’s inventory.

AGY-21-008-IT 189 | Page

APPENDIX 1

7.8.4 Operations

7.8.4.1 Login and Logout

Req # Requirement Assigned CDRL

7.8.4.1-1 The CST will remain inactive and unable to perform any functions unless a CDRL 7-9 proper login has been completed. 7.8.4.1-2 The CST will support at least three (3) levels of logins with assigned CDRL 7-9 functionality configurable by the agency. 7.8.4.1-3 The CST will require the operator to identify the starting cash drawer CDRL 7-9 balance at the start of each shift. 7.8.4.1-4 The CST will support relief shifts, with the replacement of the cash drawer. CDRL 7-9 The CST will also maintain statistics for the relief shift separately and will not affect the main shift information. 7.8.4.1-5 If the CST has not been used in a number of minutes configurable by CDRL 7-9 agency, the user will be automatically logged out. The CST will close all files and display the login prompt screen. 7.8.4.1-6 Upon logging out or otherwise indicating an end-of-shift condition, the CST CDRL 7-9 will produce a report and receipt depicting the ending balance of the cash drawer. 7.8.4.1-7 The CST will store a data record for each successful login, each CDRL 7-9 unsuccessful login, and each logout.

7.8.4.2 Sales

Req # Requirement Assigned CDRL 7.8.4.2-1 The CST will function as an intelligent cash register, allowing customers CDRL 7-9 and clerks to interact in a manner that is as similar as possible to normal retail sales transactions. Sales transactions will include: • Purchase of new fare media • Adding of value and passes to existing media and accounts 7.8.4.2-2 When issuing a new EU smartcard, the CST will permit the clerk to select CDRL 7-9 whether an agency-configurable card fee (e.g., deposit) is to be collected. 7.8.4.2-3 At no time will the CST add a pass to an account if doing so would result in CDRL 7-9 the account having more than one active pass valid on the same service. 7.8.4.2-4 All unlimited ride rolling passes will be added to the account in the CDRL 7-9 pending state (without an expiration date set for the pass product).

AGY-21-008-IT 190 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.4.2-5 The purchase of multiple cards and multiple fare products for each CDRL 7-9 account will be able to be performed in a single transaction, with payment collected once. 7.8.4.2-6 When configured to conduct sales, the CST will support a variety of CDRL 7-9 payment methods, including: • Cash • Checks • Agency and third-party issued vouchers • Bank cards (credit and debit) • Any combination of the above The CST will also support the payment, or partial payment, for the purchase of a pass using stored value in the same transit account where the pass is being loaded. 7.8.4.2-7 The CST will support split payments where up to three (3) payment CDRL 7-9 methods, including multiple bank cards, will be able to be used to complete payment for a single sale. 7.8.4.2-8 For each sales transaction, the CST will enable the clerk to select the CDRL 7-9 payment method. If the clerk selects more than one (1) payment method, the CST will prompt the clerk to enter the amount to be paid using each payment method. 7.8.4.2-9 Cash transactions will provide the total amount due, allow the clerk to CDRL 7-9 enter the amount tendered, and display the change due. 7.8.4.2-10 The CST will control and monitor the cash drawer and open the cash CDRL 7-9 drawer upon calculation and display of the amount of change due. 7.8.4.2-11 The CST will print a customer receipt for every completed sales CDRL 7-9 transaction. Receipts will include the resulting status and value of the customer’s account, where applicable. 7.8.4.2-12 For each completed transaction, a sales transaction will be stored and CDRL 7-9 transmitted to the system back-office using SI-provided fare distribution API (see Section 5.3.1.2). 7.8.4.2-13 The CST will enable a clerk to display (and print via the receipt printer) CDRL 7-9 totals of all completed transactions by that clerk for the current day. 7.8.4.2-14 The CST will enable an administrative user to display (and print via the CDRL 7-9 receipt printer) totals of all conducted transactions for the current and each of the prior seven (7) days. These totals will indicate daily totals by clerk and payment type. As necessary, the CST may retrieve this data from the back-office.

AGY-21-008-IT 191 | Page

APPENDIX 1

7.8.4.3 Issuance of Personalized Media

Req # Requirement Assigned CDRL 7.8.4.3-1 When configured to do so, the CST will include the necessary software and CDRL 7-9 peripherals to enable the agency to issue personalized cards to customers eligible for reduced fares, agency employees, and in support of other fare programs. 7.8.4.3-2 Personalized cards will include the cardholder’s name and photograph CDRL 7-9 printed on one side of the card, accompanied by other agency-defined graphics and information. 7.8.4.3-3 The SI shall supply printing templates (also known as “masks”) using CDRL 7-9 agency-supplied graphic designs for all personalized card types. The CST will support no less than 25 pre-loaded templates from which the user will select prior to printing. Where possible, template selection will be automatic based on card type. 7.8.4.3-4 When printing a personalized card, the CST will scale the photo image to fit CDRL 7-9 within the area defined by the printing template without distorting the image or changing its native aspect ratio. 7.8.4.3-5 The CST will support the issuance of personalized cards in individual and CDRL 7-9 bulk production modes. 7.8.4.3-6 For individual card personalization, a digital camera controlled by the CST CDRL 7-9 will capture the customer images, as necessary. 7.8.4.3-7 Upon successful production of the personalized smart card, the CST will CDRL 7-9 store a transaction record, including all personalization data, the identification number of the issued card, the digital photograph image, and all other transaction data. The CST will transfer the entire transaction record, and all accompanying data, to the back-office. 7.8.4.3-8 The Sales Office CST will exclusively support production runs (using data CDRL 7-9 imported from an external open) for bulk card personalization in quantities of one (1) to no less than 100 cards per batch. 7.8.4.3-9 For bulk card personalization production runs, the CST will use data files CDRL 7-9 imported in an SI-specified format. The data files will include the customer name, digital photograph, and other information as required. 7.8.4.3-10 Upon successful production of each card, the Sales Office CST will store a CDRL 7-9 transaction record similar to those created for individually personalized cards and transmit all records to the back-office. 7.8.4.3-11 The agency will issue customers with reduced fare and paratransit CDRL 7-9 privileges smartcards with personalized information printed on the card, including a digital photograph and the name of the cardholder. Using the appropriate customized printing template for reduced fare and paratransit media, the CST will print and issue personalized cards.

AGY-21-008-IT 192 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.4.3-12 The CST will support the capture of all data needed to validate, register, CDRL 7-9 and issue personalized fare media for reduced fare and paratransit customers. 7.8.4.3-13 The CST will support manual entry of reduced fare and paratransit CDRL 7-9 customer account registration data using a simple graphical user interface. 7.8.4.3-14 The CST will capture reduced fare and paratransit applications and CDRL 7-9 supporting documentation using the SI-provided document scanner. 7.8.4.3-15 The CST will capture reduced fare and paratransit customer photographs CDRL 7-9 using the SI-provided camera. 7.8.4.3-16 All customer data captured and used by the CST will be securely stored CDRL 7-9 within the CRM system customer database (see Section 8.3.2) using the SI- provided APIs (see Section 5.3.1) and will not be stored locally on the CST.

7.8.4.4 Fare Media Inquiry

Req # Requirement Assigned CDRL 7.8.4.4-1 Whenever fare media is presented to the CST contactless smartcard or CDRL 7-9 barcode reader, the CST will read the card/QR code and query the back- office using the SI-provided transit account management API (see Section 5.3.1.5) to display the current status and value of the associated transit account on the operator display and customer display. 7.8.4.4-2 If the customer’s smartcard or QR code is not functioning, the CST will CDRL 7-9 permit the clerk to manually enter the card identification number. 7.8.4.4-3 Upon request, the CST will query the back-office database for details of the CDRL 7-9 most recent transactions posted to the transit account. Upon receipt of the transaction history, the CST will display the results on the operator display. 7.8.4.4-4 The number of prior transactions to display will be agency-configurable CDRL 7-9 and will initially be set to the last 10 transactions. 7.8.4.4-5 For each prior transaction displayed, history details will include, at a CDRL 7-9 minimum: • Date and time of the transaction • Generating device/system (e.g., TVM, retail location, autoload) • Transaction type (e.g., sales transaction, stored value usage, pass usage, adjustment) • Transaction value • Transaction location (e.g., station name, bus route)

AGY-21-008-IT 193 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.4.4-6 Upon request, the CST will print a receipt of the current status and value of CDRL 7-9 the account.

7.8.4.5 Customer Account Management

Req # Requirement Assigned CDRL 7.8.4.5-1 The CST will enable operators to set up and modify customer accounts CDRL 7-9 using the SI-provided customer account management API (see Section 5.3.1.6). 7.8.4.5-2 The CST will enable the operator to create a new customer account and CDRL 7-9 register an anonymous transit account. 7.8.4.5-3 The CST will enable the operator to modify any fields in the existing CDRL 7-9 customer accounts that are deemed user alterable. 7.8.4.5-4 The CST will enable operators to establish, modify, and cancel customer CDRL 7-9 subscriptions for autoload, including the addition and modification of funding sources. 7.8.4.5-5 To prevent manual data entry error, the identification number of the CDRL 7-9 customer’s card will be captured by the contactless smartcard reader, and the bank card processor module will be used to read any bank card data required for autoload subscription. 7.8.4.5-6 Reduced fare privileges are subject to expiration. The CST will include a CDRL 7-9 function to re-authorize reduced fare privileges and update the customer’s account information with a new reduced fare privilege expiration date.

7.8.4.6 Media Replacement

Req # Requirement Assigned CDRL 7.8.4.6-1 The CST will support replacing registered EU smartcards by disassociating CDRL 7-9 the lost or stolen card from the account and linking a new card in its place. 7.8.4.6-2 Prior to replacing a registered EU card, the CST will require verification of CDRL 7-9 the customer’s identity through the entry of the customer’s account information, and/or answers to secret questions, as recorded in the back- office. 7.8.4.6-3 If the replacement card requires no personalization, the CST will prompt CDRL 7-9 the operator to present the new card to the contactless smartcard reader.

AGY-21-008-IT 194 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.8.4.6-4 When replacing a previously issued personalized card, the CST will support CDRL 7-9 the use of the digital photograph, printing template, and other data from the original issue record to facilitate replacement without requiring the cardholder’s presence, or the use of the digital camera to create and store a new digital image. 7.8.4.6-5 Upon reading or issuing the replacement card, the CST will transmit to the CDRL 7-9 back-office an issue record containing the card’s identification number, and a corresponding record to block use of the lost card. 7.8.4.6-6 Replacing a malfunctioning smartcard will be possible. Procedures to CDRL 7-9 replace a defective card will be similar to those used to replace a lost registered card, but the replacement of a defective card will not require the card to be registered. The replacement process will support the entry of the defective card’s identification number as the means to initiate a replacement.

7.8.4.7 Refunds and Adjustments

Req # Requirement Assigned CDRL 7.8.4.7-1 CST operators with appropriate access rights will be able to initiate transit CDRL 7-9 account adjustments by reversing prior sales or fare payment transactions, or directly adding or removing stored value or passes. 7.8.4.7-2 CST operators with appropriate access rights will be able to initiate an opt- CDRL 7-9 out refund that results in the closing of a transit account and issuance of a cash or check refund to the customer. 7.8.4.7-3 The CST will fully record and transmit to the back-office all adjustment and CDRL 7-9 reversal transactions.

7.9 Mobile Fare Inspection The SI shall provide a comprehensive mobile solution that provides the agency with mobile fare inspection using a handheld device and mobile application. Compact, lightweight solutions suited for a field environment are preferred. The MTA prefers minimizing the number of devices that field staff will have to carry to perform fare Inspection.

AGY-21-008-IT 195 | Page

APPENDIX 1

7.9.1 General Requirements

Req # Requirement Assigned CDRL 7.9.1-1 The SI shall provide portable and secure handheld ruggedized devices CDRL 7-10 suitable for outdoor operation. The devices shall be designed for field inspection and support real-time communications with the back-office. 7.9.1-2 Field inspection devices shall include mobile applications that enable CDRL 7-10 authorized users to inspect account-based electronic media. 7.9.1-3 The portable devices will be PCI compliant and NFC-enabled mobile CDRL 7-10 handsets. 7.9.1-4 The portable devices will be able to scan 2d barcodes from mobile device CDRL 7-10 screens. 7.9.1-5 The portable device will include a display that is easily readable by CDRL 7-10 inspectors while performing their duties. A display that includes color to easily differentiate between valid and invalid inspection is desired. It will not be necessary to rely on two separate devices to inspect fares and view the inspection results. 7.9.1-6 The mobile devices will be portable and not unreasonably hinder a user’s CDRL 7-10 ability to perform fare enforcement and security duties. 7.9.1-7 The mobile devices will be capable of being housed in a case or mounted CDRL 7-10 in a fixed cradle that contains power connections. The mobile devices must be easily installed and removed, without special tools. 7.9.1-8 Power chargers for the mobile devices will be provided and enable CDRL 7-10 carrying and charging using either a standard 120V AC power outlet or 12V DC car charger. 7.9.1-9 Battery life of the mobile devices will last at least one (1) full day of active CDRL 7-10 use. Standby times will be considerably longer, but at least two (2) days without regular activity. 7.9.1-10 Mobile devices will be rugged and function under harsh environmental CDRL 7-10 conditions including: direct sunlight, dust/grit/sand, humidity, snow, ice electrical storms, earthquakes, exposure to an urban environment, and the range of elevations and altitudes in the Baltimore region (see Section 4.7). 7.9.1-11 The mobile devices will include embedded NFC functionality, including a CDRL 7-10 contactless reader capable of reading all media compliant with both Type A and B variants of the ISO/IEC 14443 standard. 7.9.1-12 The mobile devices shall include sufficient storage to hold the status list CDRL 7-10 and several days’ worth of transaction data.

AGY-21-008-IT 196 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 7.9.1-13 Mobile device communications will include short and long-range CDRL 7-10 communications technologies, including NFC, cellular (3G GSM/CDMA, 4G LTE), Bluetooth (4.0 and above), Wi-Fi (802.11 ac), and an embedded GPS receiver. Wired communications via USB or other serial communications protocol will also be available. 7.9.1-14 Mobile devices will be remotely managed through the SMMA and/or the CDRL 7-10 agency provided Mobile Device Management (MDM) tool AirWatch. 7.9.1-15 The provided applications will be installed and managed using the CDRL 7-10 AirWatch, which will also control what services, applications, and functionality are accessible on the devices. By default, only the SI-provided applications will be enabled, and users will not have access to any other device features such as phone calls, web browsing, email, etc. 7.9.1-16 MTA desires a single solution that allows authorized users to perform CDRL 7-10 inspections. 7.9.1-17 The SI shall be the system of record for all inspection results. If local data is CDRL 7-10 written to the card to support inspections for offline inspections or payments, the inspection result displayed on the inspection hardware and application shall be provided to the SI backend with all supporting details. This includes any data used to determine the displayed inspection result. 7.9.1-18 The Inspection application shall allow for perpetual login with an agency CDRL 7-10 configurable automated logoff (e.g., end of shift, after x hours of standby, etc.).

7.9.2 Hardware

Req # Requirement Assigned CDRL 7.9.2-2 Hardware will include the ability for different visual and audible feedback CDRL 7-10 based on the result determined from the mobile fare inspection application.

AGY-21-008-IT 197 | Page

APPENDIX 1

7.9.3 Mobile Fare Inspection Application

7.9.3.1 User Interface

Req # Requirement Assigned CDRL

7.9.3.1-1 The SI shall develop a mobile fare inspection application that enables CDRL 7-11 agency personnel to inspect the contactless fare media in support of fare enforcement.

7.9.3.1-2 The fare inspection application will employ a user interface that is based CDRL 7-11 on industry-accepted user interface design standards, and user experience that is user friendly for frontline staff in a field environment. The UI and UX shall consider ergonomics, human factors, and graphic design best practices to assist in the development of the application layout and interaction.

7.9.3.1-3 The fare inspection application will require login via the APIs by the fare CDRL 7-11 inspector via manually entry, or by reading a contactless employee badge, if available. The login will be validated against a list of valid credentials. Repeated login rejections will lock the device until unlocked by an administrator.

7.9.3.1-4 The fare inspection application will not require the fare inspector to enter CDRL 7-11 the route or location where inspection is occurring to determine if a customer has valid fare.

7.9.3.1-5 The fare payment status reported by the inspection device will display at a CDRL 7-11 minimum, the result (e.g., valid or no valid fare payment), a minimum of the last 12 transactions for the transit account (including date/time and location of taps), cardholder data (if registered). If a valid payment is found, the time and date of payment, location payment was made, fare product used, product validity, amount paid, and fare category associated with the account.

7.9.3.1-6 The fare inspection results will be clearly presented to minimize confusion CDRL 7-11 by inspectors and customers.

7.9.3.1-7 The fare inspection application will provide the inspector with a clear and CDRL 7-11 visible notification when the device is offline.

7.9.3.1-8 The fare inspection application user interface will be subject to agency CDRL 7-11 review and approval during design review.

7.9.3.1-9 The fare inspection application will clearly show the date and time that the CDRL 7-11 status list was updated from the backend system

AGY-21-008-IT 198 | Page

APPENDIX 1

7.9.3.2 Transaction Processing

Req # Requirement Assigned CDRL

7.9.3.2-1 The mobile fare inspection application will use the SI-provided fare CDRL 7-11 inspection API (see Section 5.3.1.4) to query the transaction history maintained within the ATP in real-time. 7.9.3.2-2 If risk mitigation techniques are employed in the system (see Section 5.6), CDRL 7-11 the fare inspection application will be able to read any data written to the media and receive updated status lists from the back-office to support offline processing. 7.9.3.2-3 All inspections will generate fare inspection transactions that include the CDRL 7-11 following information, at a minimum: • Date and time • Device ID • Operator ID • Route number/station ID • Geo-location information (GPS data) • Media type • Card/account number • Fare category (e.g., full fare, reduced fare) • Fare instrument or product used (where applicable) • Transfer validity (if applicable) • Inspection result (valid, invalid, incomplete) • Reason for inspection result (e.g. paid, card blocked, no tap, etc.) • Transaction ID Final inspection transaction data will be determined during design review.

7.9.3.2-4 Authorized users will be able to query and run ad-hoc reports and statistics CDRL 7-11 from the back-office for inspection information by device, inspector ID, inspection result, inspection location, or any combination of inspection transaction data.

AGY-21-008-IT 199 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

7.9.3.2-5 The mobile fare inspection application will maintain audit registers that CDRL 7-11 track the following information at a minimum: • The overall activity of an inspector and/or device including the ability to identify how long the inspector is logged onto a specific device, how long a device has been active and the inspectors that have been logged onto that device. • The total count and value of all transactions completed by the mobile fare inspection application since data was last uploaded to the back-office. • Total count of all transactions that have not synced with the back- office. • The date and time of the last successful data upload to the back- office. • The date and time of the last successful status list update from the back-office These registers will be modified only by the mobile fare inspection application itself, will not be manually alterable, and will be available to view from within the mobile application. 7.9.3.2-6 Audit register records will be transmitted to the back-office at the end of CDRL 7-11 service day for reconciliation, or upon a configurable time period.

7.10 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 7-1 Equipment Hardware and Software X X X Required for Phase 1 with Common Design Specifications possible updates needed for subsequent Phases CDRL 7-2 Validator Hardware Design X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 7-3 Validator Software Design X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 7-4 Driver Display Hardware and X X X Required for Phase 1 with Software Design possible updates needed for subsequent Phases CDRL 7-5 Faregate Hardware Design X X X Required for Phase 1 with possible updates needed for subsequent Phases

AGY-21-008-IT 200 | Page

APPENDIX 1

Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 7-6 Faregate Software Design X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 7-7 Rail Station Agent Console X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 7-8 Customer Service Terminal Hardware X X X Required for Phase 1 with Design possible updates needed for subsequent Phases CDRL 7-9 Customer Service Terminal Software X X X Required for Phase 1 with Design possible updates needed for subsequent Phases CDRL 7-10 Mobile Fare Inspection Device X X X Required for Phase 1 with Hardware and Software Design possible updates needed for subsequent Phases CDRL 7-11 Mobile Fare Inspection Application X X X Required for Phase 1 with Design possible updates needed for subsequent Phases CDRL 7-12* Full-Service Ticket Vending Machine X X X Required for Phase 2 with Hardware Design (PRICED OPTION) possible updates needed for subsequent Phases CDRL 7-13* Full-Service Ticket Vending Machine X X X Required for Phase 2 with Software Design (PRICED OPTION) possible updates needed for subsequent Phases CDRL 7-14* Full-Service Ticket Vending Machine X X X Required for Phase 2 with Hardware Design (PRICED OPTION) possible updates needed for subsequent Phases CDRL 7-15* Full-Service Ticket Vending Machine X X X Required for Phase 2 with Software Design (PRICED OPTION) possible updates needed for subsequent Phases *CDRL only applies if the priced option is exercised 8. Back-office Requirements General back-office functionality. Most of these sections will have a direct correlation to the APIs and hardware, but not all.

AGY-21-008-IT 201 | Page

APPENDIX 1

8.1 General Requirements Req # Requirement Assigned CDRL 8.1-1 The back-office will comply with all common design requirements in CDRL 8-1 Section 4 and all system security requirements in Section 5.8. 8.1-2 The SI shall develop and submit for agency approval during design review CDRL 8-1 a back-office hardware design specification that provides a detailed description of all hardware components that will comprise the back-office, and the purpose, functions, interdependencies, configuration, and communication requirements of each component. Given the cloud-hosted nature of the system, the back-office hardware design specification will include detailed information on the configured environments, including virtualized server configurations and default resource allocations. 8.1-3 The SI shall develop and submit for agency approval during design review CDRL 8-1 a back-office software design specification that provides both graphical and narrative descriptions of each software component of the back-office. The back-office software design document will include at a minimum: • Functional description, purpose, supplier, and version of each software component • Interfaces and communication flows between components • Installation and configuration documentation 8.1-4 All back-office systems, with the exception of the Data Warehouse, will CDRL 8-1 provide real-time access to no less than seven (7) years of historical data. The Data Warehouse will provide unlimited access to historical data (see Section 8.7). 8.1-5 User access to all back-office applications will support two-factor CDRL 8-1 authentication controlled through the MTA-provided Duo application. Individual users or user groups will have access to specific systems where appropriate for standard business operations. All-access control will comply with agency security policies 8.1-6 The SI shall be responsible for all back-office operations and maintenance CDRL 8-1 under the Back-office Operations Agreement (see Section 15.3). 8.1-7 Software updates to back-office software, databases, and associated CDRL 8-1 modules will be centrally managed with appropriate version control in place. Software releases will only be released by authorized system administrators following agency approval.

8.2 Account-Based Transaction Processor The primary component of the back-office will be the Account-Based Transaction Processor (ATP). The SI shall deploy an ATP that maintains all transit accounts and performs real-time fare calculation and validation for closed-loop payments. Accurate and secure transaction processing will be critical to ATP operation.

AGY-21-008-IT 202 | Page

APPENDIX 1

8.2.1 General Requirements

Req # Requirement Assigned CDRL 8.2.1-1 The ATP will enable core system functions, including but not limited to: CDRL 8-2 • Fare media sales and issuance, and the creation of new transit accounts • Fare product sales and the loading of fare products (e.g., stored value and passes) to transit accounts • Maintenance of transit account status, balance, and transaction history • Fare payment supporting real-time fare calculation, such that all back-office-approved fare payment requests (i.e., with response received within established timeout) include the fully calculated fare, fare product used, balance remaining, transfer time remaining, and other pertinent information, as applicable to the fare being paid • Processing of open payment transactions (see Section 5.4) • Real-time fare inspection for closed-loop and open-loop fare payments • Automatic reloading of value to transit accounts (e.g., autoload) • Modification of transit account balances based on adjustments, refunds, reversals, and balance transfers • Blocking/unblocking and closing of transit accounts • Setting of all specified transit account management configuration parameters (e.g., fraud detection parameters, negative balance limits, etc.) 8.2.1-2 The fare distribution, payment, and inspection devices, and supporting CDRL 8-2 back-office systems, will access ATP functions using the SI-provided APIs (see Section 5.3.1) via a direct, real-time connection to the ATP. 8.2.1-3 The ATP will maintain transit accounts that store all fare products (e.g., CDRL 8-2 stored value and passes) loaded by customers, and deduct value in real- time as accounts are used for payment. 8.2.1-4 The ATP will create and maintain transit accounts associated with all open CDRL 8-2 payment PAs used for payment within the system. These transit accounts will track PA status and usage, and enable the calculation of fares for open payment transactions (see Section 5.4).

AGY-21-008-IT 203 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.2.1-5 For transit accounts associated with closed-loop media, the ATP will CDRL 8-2 maintain separate stored value purses to segregate stored value loaded using pre-tax benefit cards (see Section 5.7) and through pre-tax benefit programs (see Section 6.6.4). The system will support a general (i.e., post- tax) purse, a pre-tax transit purse, and a pre-tax parking purse, at a minimum. Order of precedence rules will be able to be configured to deduct store value from the pre-tax purses first when the service being paid for is eligible for the use of pre-tax funds. 8.2.1-6 The ATP will support all customer service functions impacting transit CDRL 8-2 account status and balance that are available through all customer service channels using SI-provided devices and systems, including the CSTs, CRM system, customer, and intuitional websites, and IVR system.

8.2.2 Fare Distribution

Req # Requirement Assigned CDRL 8.2.2-1 The ATP will support the real-time loading of fare products through all fare CDRL 8-2 distribution channels. With the exception of single-ride ticket sales at TVMs (see Section 7.6), no loading of fare value to a transit account will be permitted without an active connection to the ATP. 8.2.2-2 The ATP will manage the automatic reloading of value for fare products CDRL 8-2 that are configured for autoload. Autoload will be based on the configuration parameters described in Section 6.6.3 and will require the transit account to be registered with a valid funding source stored in the associated customer account. 8.2.2-3 All payments will be accepted or authorized prior to the loading of any fare CDRL 8-2 value. Following payment confirmation, the ATP will update the transit account balance in real-time to allow for immediate use by the customer.

8.2.3 Fare Payment

Req # Requirement Assigned CDRL 8.2.3-1 When processing a fare payment, the ATP will provide an online server CDRL 8-2 validation response within 500 milliseconds. 8.2.3-2 Generation of a fare payment validation response will require real-time CDRL 8-2 fare calculation, including query of the transit account, full-fare calculation, and update of the account balance, to be performed prior to providing an approval or denial response to the fare payment device. Server authorization rate requirements are specified in Section 16.1.3.1

AGY-21-008-IT 204 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.2.3-3 The real-time fare calculation performed by the ATP will be based on the CDRL 8-2 fare structure configuration described in Section 8. The calculation will incorporate all attributes of the ride being taken, transit account rider classification, transit account balance, available fare products and order of precedence rules, transfer status, and all other factors that influence the fare to be charged. The online fare payment calculation algorithm will be presented for agency review and approval at design review. 8.2.3-4 The online fare validation response generated by the ATP will include at a CDRL 8-2 minimum: • Payment status (e.g., success or failure) • Account rider classification • Fare product used • Fare charged • Remaining balance • Transfer time remaining Other relevant transaction data may be included and identified during design review. 8.2.3-5 When real-time communications are not available and device-level fare CDRL 8-2 validation occurs using the risk mitigation techniques described in Section 5.6., the original validation request, appended with the offline validation result, will be sent to the ATP, and processed to update the account status and balance, as soon as communications are reestablished. 8.2.3-6 If an offline validation result matches the (i.e., online) result determined CDRL 8-2 by the ATP, the use of an offline result will be recorded for reporting purposes, but no other action is required. 8.2.3-7 If an offline validation result was to deny the payment, while the (i.e., CDRL 8-2 online) result determined by the ATP was to accept the payment, no fare will be charged, and the transaction will be flagged as an exception within the transit account. These exceptions will be identified as such for customer service staff viewing the transaction history and used to populate exception reports as required during design review. 8.2.3-8 If an offline validation result were to accept the payment, while the (i.e., CDRL 8-2 online) result determined by the ATP was to deny the payment, a fare payment should be processed by the ATP. If there is no stored value, fare products, or PA to use for payment, the fare will be recorded as a negative balance in the account. 8.2.3-9 The ATP will support the tracking of negative stored value balances that CDRL 8-2 occur as a result of offline fare payment acceptance or agency configured fare policies (see Section 6.7) for transit accounts associated with both closed-loop and open payment media.

AGY-21-008-IT 205 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.2.3-10 The ATP will accommodate late arriving transactions through the CDRL 8-2 recalculation of individual fare payments, or the total fare due for a prior accounting period. Transactions occurring within an accounting period may remain in a pending state and updated directly until that accounting period (e.g., service month) is closed, after which an adjustment transaction may be generated. 8.2.3-11 Transit account transaction history and balance information will be CDRL 8-2 updated in real-time as late-arriving transactions are received and processed to reflect any recalculation performed. Modified transactions and adjustment transactions issued for prior accounting periods will be clearly flagged when viewing transaction history through any customer service channels (CRM, customer website, etc.).

8.2.4 Fare Inspection

Req # Requirement Assigned CDRL 8.2.4-1 When processing a fare inspection, the ATP will provide an online server CDRL 8-2 inspection response within 500 milliseconds. 8.2.4-2 Generation of a fare inspection response will require a query of the transit CDRL 8-2 account to determine whether a fare payment occurred. Server authorization rate requirements are specified in Section 16.1.3.1. 8.2.4-3 Real-time fare inspection determination by the ATP will be based on the CDRL 8-2 fare structure configuration described in Section 8. The determination will incorporate fare payment transactions (e.g., approved and denied) recorded by the ATP, transit account rider classification, available fare products, transfer status, and all other factors that influence possible payment by the customer. The online fare inspection algorithm will be presented for agency review and approval at design review.

AGY-21-008-IT 206 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.2.4-4 An online fare inspection response generated by the ATP will include at a CDRL 8-2 minimum: • Payment status (e.g., valid, or invalid) • Account rider classification • Fare product used (if valid tap is found) • Fare charged (if valid tap is found) • Location and equipment type (e.g. TVM, bus, gate) tapped (for valid tap found) • Transfer time remaining (if valid tap is found) • Account balance • A minimum of the most recent 12 Fare payment transaction history • Account’s pass products • Last 6 digits of the printed card number • Type of fare media (e.g., virtual closed-loop, physical closed loop, open payment) If the payment is determined to be invalid, an associated reason code will be provided (e.g., no tap, blocked card). Other relevant transaction data may be included and identified during design review. 8.2.4-5 When real-time communications are not available, device-level fare CDRL 8-2 inspection may occur using the risk mitigation techniques described in Section 5.6. Transaction data will be sent to the ATP as soon as communications are reestablished. Any fare inspections performed offline will be recorded as such, so that offline transactions can be easily identified and tracked. The offline fare inspection algorithm will be presented for agency review and approval at design review.

8.3 Customer Relationship Management System The SI shall deploy a Customer Relationship Management (CRM) system that provides access to all transit and customer account information, and the ability to track all customer service contacts and requests from initiation through resolution.

8.3.1 General Requirements

Req # Requirement Assigned CDRL 8.3.1-1 The SI shall deploy a COTS, web-based CRM system that provides central CDRL 8-3 management for all customer data, customer service operations, and fare media and product ordering and fulfillment, as well as cradle-to-grave tracking of all customer service contacts and requests.

AGY-21-008-IT 207 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.3.1-2 The core function of the CRM system will be to support call center CDRL 8-3 operations with a tool that provides a 360-degree view of the customer, and enables the creation, viewing, and modification of customer service records related to contacts, requests, and the actions taken to resolve those requests.

8.3.1-3 The CRM system will be supported by an isolated customer database, CDRL 8-3 which will be fully compliant with all applicable PCI standards published at the time of system launch, and all agency, state, and local policies for the handling of Personally Identifiable Information (PII). 8.3.1-4 The CRM system will support the management of special fare programs, CDRL 8-3 which will allow transit accounts to be linked to an institutional customer (e.g., employer or school) for account management and the loading of value (see Section 6.6.4). 8.3.1-5 The CRM system will provide central order management and fulfillment CDRL 8-3 functionality for the distribution of fare media and products sold through all online fare distribution channels, including orders placed through the mobile app, customer website, and institutional website (see Section 9.3). The CRM system will interface with the Media Inventory Management System (see Section 8.5) to maintain proper fare media inventory controls.

8.3.2 Customer Database

Req # Requirement Assigned CDRL 8.3.2-1 An isolated customer database will maintain customer accounts that store CDRL 8-3 all customer data, including all personal and payment information, associated with both individual and institutional customers (see Section 6.6.2). 8.3.2-2 All data in the customer database will be encrypted using strong CDRL 8-3 cryptography, such as TDEA or AES, and all payment data will be stored in a tokenized form. 8.3.2-3 The customer database will serve as the repository for all information on CDRL 8-3 customers applying for a reduced fare classification, including storage of applications, and supporting documentation, eligibility parameters, and card personalization information, such as a customer photograph. 8.3.2-4 The customer database will serve as the repository for all information on CDRL 8-3 employees and contractors who are issued transit access cards, including card personalization information, such as an employee photograph.

AGY-21-008-IT 208 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.3.2-5 Customer information that is specific to a piece of fare media issued to a CDRL 8-3 customer, such as card personalization data (e.g., printed name, DOB, and photograph) will be stored in a unique cardholder record within the customer database. The cardholder record will have a one-to-one relationship with the fare media issued (i.e., linked to the associated transit account), and will be sperate from customer accounts, to which many transit accounts may be linked.

8.3.3 CRM Tool

Req # Requirement Assigned CDRL 8.3.3-1 The COTS, web-based CRM tool will support call center and in-person CDRL 8-3 customer service operations by providing a complete view of the customer and related transit and customer account data, including all activity associated with both registered and anonymous transit accounts associated with all forms of accepted fare media. 8.3.3-2 The CRM tool will connect to the ATP and customer database using the SI- CDRL 8-3 provided APIs (see Section 5.3.1), and provide a fully integrated interface for customer service staff to view and modify customer and transit account data. 8.3.3-3 The CRM tool will allow customer service staff to perform customer CDRL 8-3 account actions, including but not limited to: • Create new individual customer account • Create new institutional customer account • View customer account status and data • Modify customer account data • Register (e.g., link) a transit account to an individual or institutional customer account • Unregister (e.g., unlink) a transit account from an individual or institutional customer account • Add a funding source to an individual or institutional customer account • Close an individual or institutional customer account

AGY-21-008-IT 209 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.3.3-4 The CRM tool will enable customer service staff to perform transit account CDRL 8-3 actions, including but not limited to: • Sell all supported fare media (and create new transit accounts) • Sell all supported fare products (e.g., stored value and passes) and load fare products to transit accounts • Query transit account status (e.g., associated rider classification, active/inactive, blocked/unblocked) • Add and update cardholder record data • View fare payment transaction history associated with closed-loop media • View open payment transaction history and authorizations through entry of card data (i.e., fPAN or tokenized PAN) provided by the customer • View fare capping progress against all configured fare caps • View sales transaction history • View adjustment transaction history • Enable fare product for autoload (requires funding source in customer account) • Generation of fare payment reversal (e.g., cancellation) • Generation of sales reversal (e.g., refund) • Generation of an account adjustment (e.g., credit or debit) • Attempt reauthorization of a balance due against a PA previously used for open payments (and removal of the associated account from the hotlist) • Transfer of balance between two accounts • Block/unblock card, account, or individual fare product • Lost, stolen, or damaged card replacement (e.g., associate new card with existing account) • Generation of an opt-out refund (e.g., close transit account and issue refund) 8.3.3-5 The CRM tool will allow viewing and modification of all customer account CDRL 8-3 data. A request by the customer to reset a password or IVR PIN will require the answering of security questions set at the time of account registration (see Section 6.6.2). For password resets, a temporary password will be automatically e-mailed to the customer. 8.3.3-6 The CRM tool will accept credit cards and debit cards for payment during CDRL 8-3 fare media and product sales and the setup of autoload. The CRM tool will also support the payment, or partial payment, for the purchase of a pass using stored value in the same transit account where the pass is being loaded.

AGY-21-008-IT 210 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.3.3-7 The CRM tool will support split payments where up to three (3) payment CDRL 8-3 methods, including multiple bank cards and stored value, will be able to be used to complete payment for a single sale. 8.3.3-8 The CRM tool will enable the bulk registration and loading of transit CDRL 8-3 accounts in support of special fare programs through the entry of a transit account/fare media ID range or upload of a file. 8.3.3-9 The CRM tool will enable the bulk sale and issuance of EU and LU fare CDRL 8-3 media, including the initialization and loading of the associated transit accounts, through the entry of a transit account/fare media ID range or upload of a file. 8.3.3-10 The CRM tool will enable the bulk blocking of transit accounts and issuance CDRL 8-3 of transit account adjustments through the entry of a transit account/fare media ID range or upload of a file. 8.3.3-11 All proposed file formatting for the support of the CRM’s bulk functionality CDRL 8-3 will be reviewed and approved by the agency during design review and prior to the start of development.

8.3.4 Customer Service Records

Req # Requirement Assigned CDRL 8.3.4-1 The CRM system will track all customer service contacts and requests, and CDRL 8-3 the actions taken to resolve those requests, in customer service records that can be created, viewed, and modified using the CRM tool. 8.3.4-2 Customer service records will be created automatically based on CDRL 8-3 customer-initiated actions performed through the websites or IVR system. 8.3.4-3 All actions performed by customer service staff that result in a change to a CDRL 8-3 customer or transit account will automatically generate a customer service record. 8.3.4-4 Customer service staff will be able to manually create or update (e.g., add CDRL 8-3 notes) a customer service record when responding to customer service requests in person, over the web, or by phone. 8.3.4-5 Customer service records will be created for actions associated with both CDRL 8-3 anonymous and registered transit accounts and will be linked to a specific customer account whenever possible. 8.3.4-6 The CRM system will support the classification of customer service records CDRL 8-3 by type and severity for reporting purposes, using pre-defined selections and custom text fields.

AGY-21-008-IT 211 | Page

APPENDIX 1

8.4 System Monitoring Application The SI shall deploy a System Monitoring and Management Application (SMMA) that provides real-time monitoring of all devices and back-office systems down to the component and process level, as well as remote control of the devices through the issuance of commands.

8.4.1 General Requirements

Req # Requirement Assigned CDRL 8.4.1-1 The SI shall deploy an SMMA that enables the central monitoring and CDRL 8-4 management of all SI-provided devices and systems. 8.4.1-2 The SMMA will include a web-based tool that provides access to all CDRL 8-4 monitoring and management functions, and provides all information in a clear, organized dashboard using color graphics and text. 8.4.1-3 The SMMA dashboard will include a system map that can be drilled down CDRL 8-4 into by location to view and control the status of system components. The system map will be dynamically updated when devices or systems are added and removed, and configurable to allow editing of device groups, locations, and location names as the system expands. 8.4.1-4 The SMMA tool will be accessible remotely using any modern desktop or CDRL 8-4 mobile web browser, using a mobile-responsive design.

8.4.2 Device and System Monitoring

Req # Requirement Assigned CDRL 8.4.2-1 The SMMA will provide real-time performance and status monitoring for CDRL 8-4 all devices, back-office systems, and network nodes using the SI-provided device management API (see Section 5.3.1.7). 8.4.2-2 The SMMA will store and provide historical performance and status CDRL 8-4 monitoring statistics for all devices, back-office systems, and network nodes for a period of not less than seven (7) years. This data will, at a minimum, be available via on-demand reports. Report design and reported metrics will be determined and approved by the agency in design review.

AGY-21-008-IT 212 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.4.2-2 The SMMA will monitor the operational status and performance of the CDRL 8-4 devices and their components, including: • Bus Validators • Platform Validators • Driver Displays • Ticket Vending Machines (if option exercised) • Faregates • Customer Service Terminals • Mobile Fare Inspection Devices 8.4.2-3 The SMMA will display device attributes, including but not limited to CDRL 8-4 device type, device ID, location, status, events, and alarms. 8.4.2-4 Device status reported by the SMMA will include operational status (e.g., CDRL 8-4 in-service, degraded mode, out of service, or no communications), maintenance alarms associated with individual device modules, and revenue alerts (e.g., vault almost full/full and low stock/out of stock), as described in the equipment sections of these specifications (see Section 7). 8.4.2-5 The SMMA will monitor and display in real-time the status of all back- CDRL 8-4 office systems (i.e., virtualized servers), subsystems, applications, databases, and processes. Details of which processes will be monitored will be provided during design review. 8.4.2-6 Processor load, memory utilization, errors, and other system CDRL 8-4 performance indicators will be available in real-time to help prevent performance degradation and troubleshoot back-office issues. Alarm types and thresholds will be able to be configured to allow for custom alerts. 8.4.2-7 The SMMA will monitor all SI-provided API endpoints and support real- CDRL 8-4 time dashboard reporting on API server load, response times, and errors. 8.4.2-8 Devices, systems, and network nodes that are not reporting status for any CDRL 8-4 reason will be easily identifiable, and the last known status and history will be available. 8.4.2-9 The SMMA will automatically generate alerts via email and text message. CDRL 8-4 The trigger, frequency, and cancellation of these alerts will be configurable.

AGY-21-008-IT 213 | Page

APPENDIX 1

8.4.3 Device Management

Req # Requirement Assigned CDRL 8.4.3-1 The SMMA will support the real-time issuance of device commands, and CDRL 8-4 device configuration, using the SI-provided device management API (see Section 5.3.1.7). 8.4.3-2 The SMMA will support the issuance of device commands system-wide CDRL 8-4 and by device type, location, and individual device. 8.4.3-3 Command sets will vary by device but will include configuration, CDRL 8-4 maintenance, revenue, and customer service functions, as described in the equipment sections of these specifications (see Section 7). Commands will be defined during design review. 8.4.3-4 SMMA commands will utilize an appropriate command protocol based on CDRL 8-4 industry standards, such as SNMP3, or a modern functional equivalent. The protocol chosen will be supported by all devices and systems and take into account expected network traffic and potential for intermittent communications. 8.4.3-5 The SMMA will support the setting and distribution of all configuration CDRL 8-4 parameters stored locally at the devices, including positive and negative lists, as described in these specifications.

8.5 Media Inventory Management System The SI shall deploy a Media Inventory Management System (MIMS) that maintains a full inventory of all fare media procured and issued by the agency.

Req # Requirement Assigned CDRL 8.5-1 The MIMS will maintain an inventory of all serialized agency-issued fare CDRL 8-5 media (e.g., EU and LU media) as it is held by the agency, regional partners, and third-party distributors, and eventually issued to customers.

AGY-21-008-IT 214 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.5-2 The fare media inventory data maintained within the MIMS will include at CDRL 8-5 a minimum: • Media serial number • Media type • Media/account status • Expiration date • Batch ID • Order ID • Location • Ship date • Tracking information Final data fields used for inventory management purposes will be determined during design review. 8.5-3 The MIMS will support the tracking of fare media from delivery of the fare CDRL 8-5 media by the manufacturer through issuance to a customer, including all movements from bulk storage facilities to agency inventory locations (e.g., transit store) and finally individual sale locations (e.g., individual TVM or retail store). 8.5-4 The MIMS will support the bulk issuance of EU and LU media by CDRL 8-5 identifying appropriate batch IDs and serial number ranges to fulfill orders placed by regional distribution partners, and through the institutional website (see Section 9.3). 8.5-5 The MIMS will track the current and historical status of all media in CDRL 8-5 inventory. Whenever a transaction causes a change in card status, the MIMS will update all card records accordingly. A history of all updates will be maintained to provide an audit trail.

8.6 Revenue Management System The SI shall deploy a Revenue Management System (RMS) that maintains a general ledger of all financial activity within the system, tracks receivables, and supports the settlement of funds between all participating agencies.

8.6.1 General Requirements

Req # Requirement Assigned CDRL 8.6.1-1 The RMS will be built using COTS enterprise-level financial management CDRL 8-6 software that interfaces with SI-designed software modules to provide the required functionality.

AGY-21-008-IT 215 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.6.1-2 The RMS will support the full auditing of all system financial activity, CDRL 8-6 including reconciliation of all system accounts, and end-to-end tracking of revenue as it is generated and recognized by the agency. 8.6.1-3 The RMS will include flexible APIs that enable the import and export of CDRL 8-6 financial data to and from external systems. 8.6.1-4 The SI shall employ an expert with the accounting and technical CDRL 8-6 knowledge necessary to fully setup and configure the RMS based on accounting best practices and the specific design of the delivered system.

8.6.2 General Ledger

Req # Requirement Assigned CDRL 8.6.2-1 The RMS will include a COTS General Ledger (GL) module that will be fully CDRL 8-6 installed and configured by the SI. 8.6.2-2 The GL will include accounts to track deferred revenue, earned revenue, CDRL 8-6 receivables, payables, and expenses based on the transactions generated by the system. 8.6.2-3 The GL account structure shall be defined with the agency during design CDRL 8-6 review and will align with the account structure in the agency’s existing financial management systems, where applicable. 8.6.2-4 Revenue recognition process will be automated and configurable at the CDRL 8-6 fare product-level based on time and usage parameters, including at a minimum: • Recognition at product sale • Recognition at product first use • Recognition per use (i.e., for stored value and trip-based products) • Recognition at product expiry • Daily recognition over product validity period • Monthly recognition over product validity period 8.6.2-5 The RMS will support the reconciliation of the stored value deferred CDRL 8-6 revenue GL account balance to the total transit account balances maintained within the ATP at any point in time. 8.6.2-6 The GL will maintain Cash-In-Transit balances for all sales channels CDRL 8-6 through which revenue is collected, down to the individual device-level, and for each individual bankcard (credit/debit) transactions processed through the MTA processor. Cash-In-Transit balances may be brought in through the AR module (see Section 8.6.3) or directly posted to the GL.

AGY-21-008-IT 216 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.6.2-7 The system will support the automated reconciliation of funds collected CDRL 8-6 through all sales channels, down to the individual device-level, and for each individual bankcard (credit/debit) transaction settled by the MTA processor. 8.6.2-8 The system will support the automated clearing of Cash-In-Transit CDRL 8-6 balances based on the reconciliation of collected funds. 8.6.2-9 The system will support the automated handling of reconciliation CDRL 8-6 exceptions resulting from non-payment, including notification of bank card chargebacks. Exception handling will support the automated generation of system transactions (e.g., sales reversals) necessary to adjust transit account balances and write-off uncollectable funds. 8.6.2-10 As part of design review, the SI shall be responsible for mapping each CDRL 8-6 transaction type generated by the system to the appropriate general ledger entries to support automated categorization and summarization by the system. 8.6.2-11 Summary entries will be posted to the GL automatically at the end of CDRL 8-6 each closeout period, no less than daily. 8.6.2-12 The agency will have the ability to generate manual GL postings to CDRL 8-6 support corrections and the tracking of activity that is not performed by the system.

8.6.3 Accounts Receivable

Req # Requirement Assigned CDRL 8.6.3-1 The RMS will include a COTS Accounts Receivable (AR) module that will be CDRL 8-6 fully installed and configured by the SI and will support the creation and management of receivables within the GL. 8.6.3-2 The AR module will track receivables for prepaid and post-bill fare media CDRL 8-6 and product sales initiated through the CRM system (see Section 8.3) and institutional website (see Section 9.3) to support bulk sales and special fare programs (see Section 6.6.4). 8.6.3-3 The AR module will support the establishment of AR accounts for CDRL 8-6 individual and institutional customers, which can be dynamically generated based upon billing source, event and time period, and transaction type. 8.6.3-4 The AR module will support the ability to record billing items (e.g., fare CDRL 8-6 media and products) by line item in order to identify unique accounting classification codes.

AGY-21-008-IT 217 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.6.3-5 The AR system will support the issuance of refunds for fare media and CDRL 8-6 product sales as needed. 8.6.3-6 The AR module will support the application of payments (full and partial), CDRL 8-6 credit memos, and adjustments against AR customer accounts. The process will support batch entry of receipts and lockbox functionality. 8.6.3-7 The AR module will support the setting of configurable credit limits for CDRL 8-6 institutional customers. The AR module will support the automated generation of credit holds and disabling of order privileges within the institutional website when the credit limit is reached. 8.6.3-8 The AR module will support the automatic generation of interest charges CDRL 8-6 for accounts that are past due and generate dunning (e.g., collection) letters for overdue receivables when accounts become delinquent. 8.6.3-9 The AR module will support the aging of receivables and an automated, CDRL 8-6 fully auditable write-off process to be defined during design review. 8.6.3-10 The AR module will support the automatic generation of invoices and CDRL 8-6 monthly statements detailing account activity, including the consolidation of multiple AR accounts on a single customer statement. 8.6.3-11 The AR module will provide the ability to perform online queries of CDRL 8-6 account activity (e.g., billing, collection, and adjustment) by customer and receivable to support the display of invoice, account, and payment status in the CRM system and on the institutional website.

8.6.4 Funds Settlement

Req # Requirement Assigned CDRL 8.6.4-1 The RMS will support the settlement of revenue between participating CDRL 8-6 agencies based on configurable fare reciprocity formulas to be defined whenever an additional agency is added. 8.6.4-2 The RMS will perform all revenue distribution calculations and provide CDRL 8-6 the necessary reporting to enable the settlement of funds between the agencies 8.6.4-3 As additional regional agency partners are on-boarded, the RMS GL will CDRL 8-6 serve as a sub-ledger to the general ledgers maintained within the participating agencies’ enterprise financial systems.

AGY-21-008-IT 218 | Page

APPENDIX 1

8.6.5 Financial Reporting

Req # Requirement Assigned CDRL 8.6.5-2 The RMS will produce standard accounting reports that accurately CDRL 8-6 capture deferred and recognized revenue, in both summary and detail formats, for each participating agency. 8.6.5-3 The AR module will provide standard AR reports, including but not CDRL 8-6 limited to aged trial balance (with “as-of date” functionality), customer transaction, cash on account, and AR customer listing reports. 8.6.5-4 RMS reports will be used to make manual entries in the participating CDRL 8-6 agencies’ general ledgers. No electronic interfaces between the RMS and the agencies’ existing financial systems will be required.

8.7 Data Warehouse The SI shall deploy a data warehouse that serves as a repository for all system-generated data. The central back-office database and all other supporting databases (e.g., customer and financial databases) will feed the data warehouse. The data warehouse will be the source for data analytics and reporting.

Req # Requirement Assigned CDRL 8.7-1 The data warehouse will be built using an enterprise-class ODBC- CDRL 8-7 compliant relational database scaled to 200% of the anticipated transaction volumes. The data warehouse will utilize the most recent version of Oracle Database, MS SQL Server, or agency-approved equivalent. 8.7-2 The data warehouse will store all transaction data generated by the CDRL 8-7 system. At a minimum, the data warehouse will collect data from the following systems: • Account-Based Transaction Processor (ATP) • Customer Relationship Management (CRM) System • System Monitoring and Management Application (SMMA) • Media Inventory Management System (MIMS) • Revenue Management System (RMS)

AGY-21-008-IT 219 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.7-3 Data captured in the data warehouse will include at a minimum: CDRL 8-7 • Fare media and product sale transactions from the ATP • Fare payment transactions from the ATP • Fare inspection transactions from the ATP • Adjustment, refund, reversal, and balance transfer transactions from the ATP • Customer service records from the CRM system • Device events and alarms from the SMMA • Back-office events and alarms from the SMMA • Device audit register data • Fare media inventory data from the MIMS • Financial data and accounting entries from the RMS • Other analytics data to support fraud detection/prevention 8.7-4 The data warehouse will not store any customer PII or payment data. CDRL 8-7 8.7-5 Data received from the various systems will be maintained in the data CDRL 8-7 warehouse at the individual event, record, or transaction level. Normalization and de-normalization for purposes of improving database efficiency will be supported. 8.7-6 All data will be transmitted to the data warehouse in real-time or on a CDRL 8-7 configurable frequency that can set depending on the source, and never less than daily. 8.7-7 An interface to the data warehouse will provide the ability to query the CDRL 8-7 database directly. All data will be accessible and available for use by the agency. 8.7-8 All data in the data warehouse will be accessible using standard SQL CDRL 8-7 query tools. All data will be retrievable as standard ASCII or binary data. 8.7-9 The data warehouse will provide online access to detailed transaction CDRL 8-7 information for the life of the system. The SI shall propose an allocation of storage resource sufficient to store no less than ten (10) years of detailed transaction information. If additional storage is required in the future, MTA shall be able to purchase additional storage through the Back-Office Operations Agreement. 8.7-10 The SI shall supply tools that enable the agency archive data, and to CDRL 8-7 purge old or unwanted data from the data warehouse. Purging will be an administrative function that will permanently delete data over a specified date range or based on other criteria.

AGY-21-008-IT 220 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.7-11 The SI shall provide a preliminary design specification for the data CDRL 8-7 warehouse at design review, including at a minimum: • Descriptions of all data to be stored • Data fields with type and length • Total amount of data storage available and any data compression schemes • Communications protocols being used • Timing for the transmission of data to the data warehouse • Test procedures to ensure that all required data is being captured and that all required capabilities are present • Data warehouse operating procedures The final design specification for the data warehouse, including the complete data dictionary and schema, will be delivered 120 days prior to the start of system integration testing. 8.7-12 All systems and interfaces requiring access to real-time data, including CDRL 8-7 the ATP, CRM system, SMMA, RMS, and websites will capture data from the source systems directly. The data warehouse will not be used to support any production systems, or for any purpose other than data analytics, reporting, and the export of data to external systems. 8.7-13 As part of implementation, the SI shall deliver a full and complete data CDRL 8-8 dictionary and schema for the data warehouse. The SI shall also provide details for the extract, transform, and load (ETL) processes used to capture data from the source systems.

8.8 Reporting System The SI shall deploy a reporting system that provides an interface to run pre-defined and custom reports. The primary data source for the reporting system will be the data warehouse, although other sources of data may be utilized depending on the reporting need.

Req # Requirement Assigned CDRL 8.8-1 The SI shall deploy a COTS, web-based reporting system that interfaces CDRL 8-9 with the data warehouse, and other systems as necessary, for the generation of canned and custom reports.

AGY-21-008-IT 221 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.8-2 Canned or predefined reports will include, but are not limited to: CDRL 8-9 • Ridership reports • Sales reports • Customer service reports • Maintenance reports • Device and system performance (KPI) reports • Financial reconciliation reports • Financial settlement reports • Exception reports • Fraud detection reports • Inspection reports 8.8-3 The SI shall provide 30 canned reports, to be defined and developed with CDRL 8-9 the agency during design review and throughout the Back-office Operations Agreement (see Section 15.3). 8.8-4 The reporting system will allow agency users to design and run custom CDRL 8-9 reports. These reports will be able to be saved and shared across users. 8.8-5 Custom reports will be defined using a query design tool. Custom report CDRL 8-9 queries will be able to access all data within the data warehouse. 8.8-6 Reports will be able to be run and viewed through a web interface, as CDRL 8-9 well as exported in several formats, including but not limited to Adobe Acrobat, MS Excel, MS Word, CSV, and plain ASCII text. All file formats will include the same data and general layout where possible. Data files (e.g., Excel and CSV) will be generated such that data can be extracted without formatting and can be imported into third-party tools without manipulation. 8.8-7 The reporting system will allow all reports to be configured to run CDRL 8-9 immediately and/or on a scheduled basis through the web interface and automatically delivered to one or multiple email addresses. Email deliveries may be scheduled on a daily, weekly, or monthly basis and in any of the available file formats. 8.8-8 The reporting system will support data analytics to be defined by the CDRL 8-9 agency during design review. 8.8-9 The reporting system will generate web-based dashboards to display CDRL 8-9 real-time system usage statistics and real-time system performance against required performance metrics (see Section 16). 8.8-10 The reporting system web interface will be mobile-optimized and CDRL 8-9 support all modern desktop and mobile browsers, including but not limited to Internet Explorer, Firefox, Safari, Chrome, Mozilla, and Opera.

AGY-21-008-IT 222 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 8.8-11 Access to the reporting system web interface will be password CDRL 8-9 controlled. The ability to create and run reports will be configurable by user type. User accounts will be set up with custom access levels that define which reports can be viewed, and what data can be queried for custom reports.

8.9 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 8-1 Back-office Software Design X X X Required for Phase 1 with Specifications updates needed for subsequent Phases CDRL 8-2 Account-Based Transaction Processor X X X Required for Phase 1 with Design updates needed for subsequent Phases CDRL 8-3 Customer Relationship Management X X X Required for Phase 1 with System Design updates needed for subsequent Phases CDRL 8-4 System Monitoring and Management X X X Required for Phase 1 with Application Design updates needed for subsequent Phases CDRL 8-5 Media Inventory Management X X X Required for Phase 1 with System Design updates needed for subsequent Phases CDRL 8-6 Revenue Management System Design X X X Required for Phase 1 with updates needed for subsequent Phases CDRL 8-7 Data Warehouse Design X X X Required for Phase 1 with updates needed for subsequent Phases CDRL 8-8 Data Warehouse Data Dictionary and 120 Calendar Days Prior to Schema Integration Testing CDRL 8-9 Reporting System Design X X X Required for Phase 1 with updates needed for subsequent Phases CDRL 8-10 Canned Report Specifications 120 Calendar Days Prior to

Integration Testing

AGY-21-008-IT 223 | Page

APPENDIX 1

9. Customer Application Requirements Describes the frontend customer applications.

9.1 Customer Application Design

9.1.1 Design Criteria

Req # Requirement Assigned CDRL

9.1.1-1 All interfaces between the websites, IVR, mobile application*, and back- CDRL 9-1 office systems (e.g., ATP and customer database) will be the responsibility of the SI and will use the SI-provided APIs (see Section 5.3.1). 9.1.1-2 The SI shall contract with a web and mobile application* design firm with CDRL 9-1 extensive experience developing user-friendly UI/UXs, e-commerce, retail, social media, and transit websites and mobile applications*. 9.1.1-3 The websites and mobile applications* will be built using the latest CDRL 9-1 design and e-commerce best practices, including dynamic design via HTML5, AJAX, and server-side programming languages. The development tools and design for the website will be subject to agency review and approval during design review. The website will use responsive design optimized for desktops, mobile apps, and tablets. 9.1.1-4 All transmissions of customer data, including username, password, and CDRL 9-1 any customer PII, will be TLS-encrypted (TLS v1.2 or higher) via the HTTPS protocol. 9.1.1-5 The websites and mobile application will be designed and tested for CDRL 9-1 cross-platform compatibility, including but not limited to: • Platforms: Windows, Apple, Linux, Unix • Browsers: Internet Explorer, Microsoft Edge, Safari, Chrome, Firefox, and Opera • Mobile App Operating systems: Android and iOS 9.1.1-6 The SI shall work closely with the agency's IT and web services teams to CDRL 9-1 develop an approved user interface design. The agency will play a critical role in the website and mobile application* design and testing throughout the implementation. The SI shall develop a full set of user stories during design review based on agency input and approval.

AGY-21-008-IT 224 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.1.1-7 The SI shall provide detailed screen flows depicting “snapshots” of each CDRL 9-1 screen layout arranged as a logical flow chart followed by interactive screen flows that use a collaborative interface design tool (e.g., Figma, InVision, etc.) for agency review and approval during design review. The flows will depict all web and app* screens as they will be configured for revenue service. 9.1.1-8 The websites and mobile application* will be compliant with all CDRL 9-1 applicable ADA regulations. 9.1.1-9 The websites, mobile application, TVMs *, and IVR systems will be CDRL 9-1 provided in multiple languages, including English and up to five (5) other languages to be identified by the agency during design review. 9.1.1-10 The SI is responsible for all voice recordings for appropriate systems CDRL 9-1 (e.g., TVMs, IVR). 9.1.1-11 All website content and design elements will be able to be modified by CDRL 9-1 the agency. The SI shall provide a robust Content Management System (CMS) to perform website updates for both consumer and institutional websites, which includes text, images, animations, and videos. 9.1.1-12 The SI shall be responsible for all website updates throughout the term CDRL 9-1 of the back-office operations agreement (see Section 15.3). *Mobile application and TVM portions of the requirement will apply if the mobile application or TVMs options are exercised under this contract

9.1.2 Payment Processing

Req # Requirement Assigned CDRL

9.1.2-1 The websites and mobile application* will accept credit cards and debit CDRL 9-1 cards, for payment during fare media and product sales and the setup of autoload. These systems will also support the payment, or partial payment, for the purchase of a pass using stored value in the same transit account where the pass is being loaded. 9.1.2-2 The websites and mobile application* will support split payments where CDRL 9-1 up to three (3) payment methods, including multiple bank cards, will be able to be used to complete payment for a single sale. 9.1.2-3 All payments initiated via the websites and mobile application* will be CDRL 9-1 accepted using e-commerce best practices and processed in a manner that is compliant with the latest PCI standards at the time of Final Acceptance. All payment data will be encrypted for transmission using TDEA and TLS v1.2, at a minimum.

AGY-21-008-IT 225 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.1.2-4 The websites and mobile application* will support Address Verification CDRL 9-1 System (AVS) for bank card payments in a configurable manner that allows the AVS feature to be turned on or off by the agency and accommodates acceptance of both U.S. and non-U.S. issued cards. 9.1.2-5 The websites and mobile application* will prompt users when a payment CDRL 9-1 is declined and allow entry of an alternate funding source. Failed payments will be recorded in a separate payment exception file (with denial code). 9.1.2-6 If a payment authorization is not completed within a configurable time CDRL 9-1 period or is interrupted, the websites and mobile application* will cancel the transaction and notify the customer. Any canceled transactions will be recorded. 9.1.2-7 Users will be e-mailed a receipt for all successfully completed sales, CDRL 9-1 including the fulfillment of an autoload. Users will have the option of opting-out of e-mail notifications via a customer-facing website and mobile application* interface and will allow separate configuration (on or off) of each email notification type. *Mobile application portions of the requirement will apply if the mobile application option is exercised under this contract

9.2 Customer Website The SI shall sub-contract to a professional website design and development firm to deliver a customer website and provide all hardware and software necessary to support website operations, and interfaces to internal and external systems needed to perform the required functions.

9.2.1 General Requirements

Req # Requirement Assigned CDRL

9.2.1-1 The SI shall deploy a customer website that allows registered and CDRL 9-2 unregistered customers to purchase fare media and products and perform transit and customer account management functions.

AGY-21-008-IT 226 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.2.1-2 The customer website will allow customers to perform the following CDRL 9-2 functions, at a minimum: • Purchase new fare media • Create a new customer account • View and manage account settings and customer profile • Register an extended-use card (e.g., transit account) • Purchase fare products (e.g., stored value and passes) • Add a funding source • Set up, modify, and cancel autoload of stored value and passes • View transit account balance and status information • View and download sales, usage, and adjustment transaction history • Initiate a customer service request (e.g., refund request) • Report a card lost or stolen • Request an opt-out refund (e.g., close transit account) • Provide a home page designed and focused on marketing and education on how to use the electronic fare system • Support for FAQs including short videos (e.g., embedded YouTube videos) designed by the agency • Support for social logins (e.g., Facebook, Twitter, Google, etc.) Final customer website functions will be determined during design review.

9.2.2 Fare Media Purchase and Registration

Req # Requirement Assigned CDRL

9.2.2-1 The customer website will allow the ordering of agency-issued EU fare CDRL 9-2 media to be delivered by mail. Ordering of fare media via the website may require registration of the media (e.g., transit account) at the time the order is placed. 9.2.2-2 The customer website will allow the creation of a new customer account. CDRL 9-2 During creation of a customer account, the website will capture all customer registration data (see Section 6.6.2), including the credentials (e.g., username, password, and IVR PIN) used to access the website and IVR account management functions (see Section 9.5). All customer account data will be stored securely in the customer database (see Section 8.3.2).

AGY-21-008-IT 227 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.2.2-3 During the creation of a new customer account, the website will provide CDRL 9-2 the ability to register previously issued EU fare media. Fare media (e.g., transit account) registration will not be required to create a customer account. 9.2.2-4 Registered customers will be required to login to the website using a CDRL 9-2 username or e-mail address, and an account password. The use of a username or e-mail address as the primary login credential will be determined during design review. 9.2.2-5 The website password will have configurable security requirements, CDRL 9-2 including but not limited to minimum password length, required use of letters/numbers/symbols, and forced password reset after a configurable time period or on-demand. 9.2.2-6 Registered customers will have the ability to view and modify registration CDRL 9-2 data at any point in time. Password and PIN data will be masked when presented on the website. 9.2.2-7 The website will support the registration of multiple EU cards (e.g., transit CDRL 9-2 accounts) under a single customer account. Registered customers will be able to add new cards when logged into the customer website. Customers will assign each card nickname, which will be stored in the transit account and used to differentiate cards registered to the same customer.

9.2.3 Fare Product Purchases

Req # Requirement Assigned CDRL

9.2.3-1 Registered and unregistered customers will be able to initiate a load of CDRL 9-2 value (e.g., stored value and passes) via the website using a credit card, debit card, or bank account (ACH) transfer. The website will support the entry of transit account information and the selection of pass products and pre-defined or custom stored value amounts, subject to configurable minimum and maximum limits. 9.2.3-2 Registered customers will have the ability to save and modify funding CDRL 9-2 sources, including credit cards, debit cards, and bank accounts for one-off purchases and autoload payments. Funding source information will be stored securely within the customer database in a tokenized form (see Section 5.7).

AGY-21-008-IT 228 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.2.3-3 Registered customers will be able to enable, disable, and modify the CDRL 9-2 autoload of stored value and passes (see Section 6.6.3). As part of the autoload setup process, the customer will select the stored value amount or pass to be loaded and the type of autoload (e.g., threshold or periodic). Autoload setup will require a funding source to be added or selected. 9.2.3-4 During autoload setup, the customer will be able to select a primary and CDRL 9-2 backup funding source. If payment authorization of the primary funding source fails, authorization against the backup funding source will be attempted. If payment authorization is not received, the autoload will be automatically disabled. 9.2.3-5 For one-off purchases and autoload, the website will provide customers an CDRL 9-2 option to split payment between a minimum of two funding sources.

9.2.4 Account Status and Transaction History

Req # Requirement Assigned CDRL

9.2.4-1 Registered and unregistered customers will be able to use the website to CDRL 9-2 view transit account balance (e.g., stored value and pass) and status (e.g., rider classification, active or blocked) information by entering a fare media ID. 9.2.4-2 Transit account balance information will include the current stored value CDRL 9-2 balance and the state (e.g., active/inactive) and remaining validity (e.g., expiration date or rides remaining) of all passes. 9.2.4-3 Registered customers will be able to view no less than 18 months of prior CDRL 9-2 transaction history, showing all sales, usage, and adjustment transactions. The transaction history will be viewable and sortable on the website, and able to be downloaded in PDF and Excel formats.

9.2.5 Customer Service

Req # Requirement Assigned CDRL

9.2.5-1 The website will include general information on the use of the system, CDRL 9-2 including an FAQ section, information on where to purchase fare media and value, the cardholder agreement, and general program information and updates.

AGY-21-008-IT 229 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.2.5-2 Registered customers will have the option of initiating a customer service CDRL 9-2 request via the website. This action will automatically generate a request within the CRM system (see Section 8.3) and assign the request to the appropriate customer service staff. 9.2.5-3 The website will allow registered customers to report a card lost or stolen. CDRL 9-2 This action will immediately result in the associated fare media being blocked from further use. The customer will have the option of being mailed a replacement card or purchasing a new card and having the balance transferred. For the mailing of a replacement card, a configurable replacement fee will be able to be charged. 9.2.5-4 The website will allow registered customers to close a transit account and CDRL 9-2 request an opt-out refund. This action will immediately result in the associated fare media being blocked from further use. The operational policies governing the issuance of a refund will be defined during design review. 9.2.5-5 The website will include links to the agency websites with schedules, fares, CDRL 9-2 and other general transit information.

9.3 Institutional Website The SI shall sub-contract to a professional website design and development firm to deliver an institutional website and provide all hardware and software necessary to support website operations, and interfaces to internal and external systems needed to perform the required functions.

9.3.1 General Requirements

Req # Requirement Assigned CDRL

9.3.1-1 The SI shall deploy an institutional website that allows employers, schools, CDRL 9-4 social service agencies, and other institutions to order fare media and administer transit accounts on behalf of participants in special fare programs (see Section 6.6.4).

AGY-21-008-IT 230 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.3.1-2 The institutional website will provide the following functions at a CDRL 9-4 minimum: • Register a new institution (e.g., create a new institutional customer account) • Add participants (e.g., transit accounts) to an institutional customer account • Delete participants (e.g., transit accounts) from an institutional customer account • Reset password • Load value (e.g., stored value and passes) to participants’ transit accounts • Block participants’ transit accounts (i.e. fare media) and/or use of loaded value • Bulk order extended-use and limited-use media with a user- friendly interface and seamless import of participant data • Bulk load fare products and stored value • Send automated, configurable reminders to institutions and/or participants within a configurable time period prior to a product's expiration (e.g., x days prior to a monthly pass expiring) • Make a payment • View order history, invoices, and payment status • Support multiple shipping addresses per institution • Provide a home page designed and focused on marketing and education on how to use the electronic fare system • Support for FAQs including short videos (e.g., embedded YouTube videos) designed by the agency • Support multiple admin logins per institution, with configurable permission levels Final institutional website functions will be determined during design review. 9.3.1-3 The agency will be able to use the institutional website to serve as CDRL 9-4 administrators for their own programs as necessary and will support superuser access to all institutional accounts. 9.3.1-4 The website design, features, media fulfillment, product, and stored value CDRL 9-4 loads will support physical extended- and limited-use media, including mobile app media.

AGY-21-008-IT 231 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.3.1-5 The websites and mobile applications* will be built using the latest design CDRL 9-4 and e-commerce best practices, including dynamic design via HTML5, AJAX, and server-side programming languages. The development tools and design for the website will be subject to agency review and approval during design review. The website will use responsive design optimized for desktops, mobile apps, and tablets. 9.3.1-6 The website will be designed and tested for cross-platform compatibility, CDRL 9-4 including but not limited to: • Platforms: Windows, Apple, Linux, Unix • Browsers: Internet Explorer, Microsoft Edge, Safari, Chrome, Firefox, and Opera

9.3.2 Registration

Req # Requirement Assigned CDRL

9.3.2-1 Prior to using the institutional website, institutions will need to be CDRL 9-4 approved by the agency and registered through the creation of an institutional customer account. 9.3.2-2 The agency will use either the institutional website or CRM system (see CDRL 11-4 Section 8.3) to register an institution and configure all parameters governing the institution’s participation in a special fare program (see Section 6.6.4). 9.3.2-3 Registration will capture all institutional customer registration data (see CDRL 9-4 Section 6.6.2), including the credentials (e.g., username, password) used by an institution’s administrator to access institutional website functions. 9.3.2-4 Following registration, a special fare program administrator from the CDRL 9-4 institution will be able to login to the institutional website to perform all configured functions. 9.3.2-5 All data associated with institutional customer accounts will be stored CDRL 9-4 securely in the customer database (see Section 8.3.2). 9.3.2-6 The SI shall develop a full set of user stories during design review based on CDRL 9-4 agency input and approval.

AGY-21-008-IT 232 | Page

APPENDIX 1

9.3.3 Adding and Deleting Participants

Req # Requirement Assigned CDRL 9.3.3-1 Special fare program administrators will be able to add participants (e.g., CDRL 9-4 transit accounts) to their institutional customer account individually using a fare media ID, and through a bulk, process using an imported file in an agency-defined format. 9.3.3-2 When adding participants, the institution will be able to provide card CDRL 9-4 personalization information (e.g., employee name or ID) that uniquely identifies the participant in possession of the associated fare media. If personalization information is provided, it will be securely stored in the transit account and serve as a unique identifier separate from customer registration data, should the participant chooses to register the card (see Section 9.2.2). 9.3.3-3 Registered and unregistered customers with existing fare media will be CDRL 9-4 able to be added to an institutional customer account as participants. 9.3.3-4 Special fare program administrators will be able to delete participants CDRL 9-4 from their institutional customer account, individually by selection, and through a bulk process using an imported file in an agency-defined format.

9.3.4 Placing Orders

Req # Requirement Assigned CDRL

9.3.4-1 Special fare program administrators will be able to initiate the loading of CDRL 9-4 value (e.g., stored value and passes) to participants’ transit accounts individually by selection, and through a bulk process using an imported file in an agency-defined format. 9.3.4-2 When adding value to participant accounts, special fare program CDRL 9-4 administrators will be able to select from the available fare products configured for their account and choose whether to initiate a one-time or recurring load (e.g., autoload), on an individual participant basis. The period for recurring loads will be defined in the institutional customer account configuration. 9.3.4-3 If their account is configured to allow it, special fare program CDRL 9-4 administrators will be able to place bulk orders for extended-use and limited-use fare media to be delivered by mail. Bulk sales will include LU fare media where the associated transit accounts are pre-loaded with value.

AGY-21-008-IT 233 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.3.4-4 When fulfilling a bulk EU fare media order, the system will automatically CDRL 9-4 generate an import file pre-populated with the fare media IDs to support the addition of participants by the institution.

9.3.5 Payment

Req # Requirement Assigned CDRL

9.3.5-1 Payment terms for institutional customers will be configured as part of the CDRL 9-4 institutional customer account setup. The agency will be able to configure accounts such that payment is required at the time an order is placed, or to allow the institution to be invoiced based on established payment terms. 9.3.5-2 For institutions where prepayment is required, the institutions will be CDRL 9-4 required to provide a funding source in the form of a credit card or debit card,. Funding source information will be stored securely within the customer database in a tokenized form (see Section 5.7). 9.3.5-3 For institutional orders where invoicing is configured, an invoice will CDRL 9-4 automatically be generated by the RMS (see Section 8.6), posted to the institutional website, and sent electronically to the institution. 9.3.5-4 The RMS will track all receivables for institutional customers in the AR CDRL 9-4 module (see Section 8.6.3). The agency will be able to configure credit limits for AR customer accounts, which will result in the automatic disabling of order privileges within the institutional website when the credit limit is reached. 9.3.5-5 Special fare program administrators will be able to view current payment CDRL 9-4 status (e.g., balance due, accrued interest, and due date) and at least 18 months of invoices, and order and payment history, via the institutional website. The invoices, orders, and payment history will be viewable and sortable on the website, and able to be downloaded in PDF and Excel formats. 9.3.5-6 The institutional website will support the administration of transit benefits CDRL 9-4 programs by employers and third-party administrators. Institutions will be required to indicate whether loads are being funded using pre-tax dollars. Stored value and fare products purchased using any pre-tax dollars will be identified as such and segregated within the transit account to ensure compliance with all applicable IRS regulations.

AGY-21-008-IT 234 | Page

APPENDIX 1

9.4 Fare Payment and Account Management Mobile Application (PRICED OPTION)

9.4.1 General Requirements

Req # Requirement Assigned CDRL 9.4.1-1 The SI shall develop and maintain a mobile customer account management CDRL 9-6 application for Android and iOS. The application will be publicly available (e.g., Apple App Store, GooglePlay, etc.) to download. 9.4.1-2 The mobile application will be developed for the latest versions of CDRL 9-6 operating systems for Android and iOS. The SI will also support future OS version updates, patches, and security updates for the duration of the contract. 9.4.1-3 The SI will support the most recent version of the operating system, and at CDRL 9-6 a minimum, the previous versions of the operating systems for Android and iOS that represents a minimum of 95% of all U.S. users. 9.4.1-4 The SI will provide a customer mobile application that allows users to CDRL 9-6 perform the same functions available from the customer website. The mobile app will use SI-provided APIs to connect to the ABT for account functionality unless previously agreed between the mobile app developer and MTA. 9.4.1-5 The customer mobile application will include enhanced functionality, CDRL 9-6 including the ability to create and use electronic or digital fare media from the user’s mobile device to pay by interacting with the SI provided validator. 9.4.1-6 The ABT will be the system of record for media and account actions CDRL 9-6 (purchases, registration, usage, etc.) performed in the mobile application. 9.4.1-7 The mobile application will support English and up to five (5) different CDRL 9-6 foreign languages, localized to the Baltimore area. Languages will be determined during final design review. 9.4.1-8 The mobile application will generate and provide mobile app usage CDRL 9-6 analytics including, but not limited to: • Quantitative analytics – user actions, usage trends • Audience segmentation • User paths • Uninstall tracking • Crash and event reporting • Real-time alerts

AGY-21-008-IT 235 | Page

APPENDIX 1

9.4.2 User Interface

Req # Requirement Assigned CDRL

9.4.2-1 The application will employ a user interface that is based on industry- CDRL 9-6 accepted user interface design standards, and consider ergonomics, human factors, and graphic design best practices to assist in the development of the application layout and interaction. All text, graphics, and logos within the app are subject to design review approval. 9.4.2-2 The mobile application will allow customers to opt into automated push CDRL 9-6 notifications regarding their registered transit account(s) and customer account. Notifications may include usage, payment loads/autoload, low balance, service alerts, transfer time remaining, fare caps reached, account password change notification, account access/changes. Each notification will be independently configurable, not all notifications on or all notifications off. Final list to be determined during design review. 9.4.2-3 The customer mobile app will allow customers to perform the following CDRL 9-6 functions, at a minimum: • Create, view, and manage customer account profile data (e.g., password, PIN, name, billing/shipping address, configure biometrics on or off, etc.) • Purchase/provision new fare media • Order new fare media • Add and remove fare media (e.g., transit account) to the customer account • View transit account balance and status information • View sales, usage, and adjustment transaction history, including date, time, and amount • View fare capping information, including a user-friendly snapshot of fare caps reached with graphical and text displaying amount of cap, amount spent to date, and amount remaining to cap, and the ability to view fare capping details for all accumulators in use • Report fare media lost or stolen • Purchase fare products (e.g., stored value and passes) • Add, remove, and manage up to three (3) funding sources • Set up, modify, and cancel autoload of stored value and passes • Initiate a customer service request (e.g., refund request, media replacement) • Request an opt-out refund (e.g., close transit account) Final customer functions will be determined during design review.

AGY-21-008-IT 236 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.4.2-4 The mobile application will allow customers to create a customer account. CDRL 9-6 The required steps and process to create a customer account will be similar to the customer website. Successfully created accounts via the mobile app will be immediately available to login via other customer- facing applications (e.g., website, IVR). 9.4.2-5 The mobile app will allow registered and unregistered customers to CDRL 9-6 purchase fare media and products. 9.4.2-6 Registered and unregistered customers will be able to use the mobile app CDRL 9-6 to view transit account balance (e.g., stored value and pass) and status (e.g., rider classification, active or blocked) information by entering a fare media ID. 9.4.2-7 Transit account balance information will include the current stored value CDRL 9-6 balance and the state (e.g., active/inactive) and remaining validity (e.g., expiration date or rides remaining) of all passes. 9.4.2-8 Customers will be required to sign into their customer account to access CDRL 9-6 (view or manage) fare media registered to a customer account. 9.4.2-9 Registered customers will be able to access their account from either the CDRL 9-6 mobile app, IVR, or website, regardless of where the account was created. (e.g., accounts created via the mobile app will be accessible via the website and vice versa) 9.4.2-10 The mobile app will support password security best practices, including CDRL 9-6 but not limited to minimum password length, required use of letters/numbers/symbols, and forced password reset after a configurable time period or on-demand. Final password security requirements will be determined during design review. 9.4.2-11 The mobile app will support password reset best practices, including but CDRL 9-6 not limited to two-factor authentication (2FA), including support for text message and email. Changing an account password via the mobile application will log out the user on all previous logins using the old password. 9.4.2-12 The mobile app will support biometric (e.g., fingerprint, face recognition) CDRL 9-6 log in as an option to a password and social logins (e.g., Facebook and Google account). 9.4.2-13 The mobile app will support persistent login. The duration of the login will CDRL 9-6 be configurable.

AGY-21-008-IT 237 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.4.2-14 The mobile app will support the registration of multiple fare media (e.g., CDRL 9-6 transit accounts) under a single customer account. Registered customers will be able to add new fare media when logged into the mobile app. Customers will be able to assign and edit nicknames within the app, which will be used to differentiate media registered to the same customer. 9.4.2-15 The mobile app will allow customers to sort and arrange the display order CDRL 9-6 for registered media if the customer has multiple media registered to their account. Customers will be able to quickly see and navigate all transit accounts associated to the customer account. 9.4.2-16 Registered customers will have the ability to save and modify funding CDRL 9-6 sources, including credit cards, debit cards, and bank accounts for one-off purchases and autoload payments. Funding source information will be stored securely within the customer database in a tokenized form (see Section 5.7). 9.4.2-17 Customers will be able to add value or products to registered or CDRL 9-6 unregistered fare media. 9.4.2-18 The mobile app will support PayPal and mobile wallet payments such as CDRL 9-6 Google Pay, Apple Pay, and Samsung Pay as funding sources. 9.4.2-19 Registered and unregistered customers will be able to initiate a load of CDRL 9-6 value (e.g., stored value and passes) via the mobile app using a credit card and debit card, including support for split payments. Loading value will not require the funding source to be saved to an account. 9.4.2-20 Registered customers will be able to initiate a load of value (e.g., passes CDRL 9-6 and stored value) via the mobile app using stored value from other fare media registered to the same account. 9.4.2-21 Registered customers will be able to enable, disable, and modify the CDRL 9-6 autoload of stored value and passes (see Section 6.6.3). As part of the autoload setup process, the customer will select the stored value amount or pass to be loaded and the type of autoload (e.g., threshold or periodic). Autoload setup will require a funding source to be added or selected. 9.4.2-22 During autoload setup, the customer will be able to select a primary and CDRL 9-6 backup funding source. If payment authorization of the primary funding source fails, authorization against the backup funding source will be attempted. If payment authorization is not received, the autoload will be automatically disabled. 9.4.2-23 Registered customers will be able to view no less than 18 months of prior CDRL 9-6 transaction history, showing all sales, usage, and adjustment transactions.

AGY-21-008-IT 238 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.4.2-24 The mobile app will include general information on use of the system, CDRL 9-6 including an FAQ section, information on where to purchase fare media and value, the cardholder agreement, and general program information and updates. 9.4.2-25 Registered customers will have the option of initiating a customer service CDRL 9-6 request via the mobile app. This action will automatically generate a request within the CRM system (see Section 8.3) and assign the request to the appropriate customer service staff. 9.4.2-26 The mobile app will allow registered customers to report a card lost or CDRL 9-6 stolen. This action will immediately result in the associated fare media being blocked from further use. The customer will have the option of being mailed a replacement card or purchasing a new card and having the balance transferred. For the mailing of a replacement card, a configurable replacement fee will be able to be charged. 9.4.2-27 The mobile app will allow registered customers to close a transit account CDRL 9-6 and request an opt-out refund. This action will immediately result in the associated fare media being blocked from further use. The operational policies governing the issuance of a refund will be defined during design review. 9.4.2-28 The mobile app will include links to the agency websites with schedules, CDRL 9-6 fares, and other general transit information. 9.4.2-29 The mobile app will support balance transfers between transit accounts CDRL 9-6 registered to the same customer account. 9.4.2-30 Registered customers will be able to purchase products and value to CDRL 9-6 multiple accounts in a single transaction. Separate transactions will not be necessary for a user to load funds or products to multiple transit accounts.

9.4.3 Digital Fare Media

Req # Requirement Assigned CDRL

9.4.3-1 The mobile application will support purchasing and issuing digital, mobile- CDRL 9-6 optimized Aztek code-based fare media (or QR code-based fare media if data elements are greater than 250 bytes) by registered customers. The digital fare media will interact with the SI provided validators to pay for transit service. Support for unregistered customers is required but may be removed during design review. 9.4.3-2 Digital fare media will be available for all fare categories. Pre-verification CDRL 9-6 codes will be required for certain reduced fare categories.

AGY-21-008-IT 239 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.4.3-3 All digital fare media will include a unique system identifier visible to the CDRL 9-6 customer, in addition to the customer assigned nickname to help identify the correct card if multiple digital cards are stored on the mobile device/app. Digital fare media will be managed similarly as physical fare media. 9.4.3-4 The digital fare media will be used from within the mobile device and will CDRL 9-6 be automatically associated to a customer account. 9.4.3-5 The mobile app will allow customers to convert physical fare media into CDRL 9-6 digital fare media. All products, value, and usage history from the physical fare media will be automatically associated to the new digital credential. The physical fare media will be immediately blocked from further use. 9.4.3-6 The mobile app will have an intuitive interface that will allow customers to CDRL 9-6 migrate digital fare media between any device associated to the customer account. Moving the fare media between devices will be tracked and include a counter for the number of moves within the system and readily available to agency customer service staff for troubleshooting and fraud mitigation. The counter will allow MTA staff to modify and reset to zero. Once the digital media has been moved to a new device, the media on the old device will be removed, or otherwise prevented from further use. 9.4.3-7 The digital fare media will include security features to mitigate fraud and CDRL 9-6 the usage of shared credentials. Security features to be finalized during design review. 9.4.3-8 The digital fare media will be able to be inspected using the SI Fare CDRL 9-6 Inspection solution. Security measures will be included to support fare inspection and will be finalized during design review. 9.4.3-9 The mobile application will support multiple digital fare medias and CDRL 9-6 multiple fare categories on a single mobile device. 9.4.3-10 Customers will be able to load value to digital fare media via the retail CDRL 9-6 network (e.g., Transit stores, 7-11, grocery stores), vending machines, website, IVR and mobile app, which will require an in-app barcode.

AGY-21-008-IT 240 | Page

APPENDIX 1

9.5 IVR

9.5.1 General Requirements

Req # Requirement Assigned CDRL

9.5.1-1 The SI shall deploy an IVR system that provides customers a self-service CDRL 9-5 interface to obtain up-to-date transit and customer account information, and perform account management functions, over the phone. 9.5.1-2 The IVR system will integrate with the call center phone system. The call CDRL 9-5 center will be hosted and operated by the MVA. 9.5.1-3 The IVR system will support touch-tone entry and voice recognition to access CDRL 9-5 all IVR functions. The IVR speech recognition engine will not have a limit to the number of words it can recognize. 9.5.1-4 The IVR system will support the use of teletype writing (TTY) and text-to- CDRL 9-5 speech (TTS) devices by the hearing impaired. 9.5.1-5 The IVR system will support English and up to five (5) other languages to be CDRL 9-5 identified by the agency during design review. 9.5.1-6 The IVR system will support the transfer of customers to and from MVA and CDRL 9-5 agency phone systems used for general customer support. 9.5.1-7 The IVR system will be fully configurable by the MVA and agency, including CDRL 9-5 the IVR script, functions available to customers, and handoffs to and from external systems. 9.5.1-8 The IVR system will be subject to agency review and approval at design CDRL 9-5 review.

9.5.2 IVR Functions

Req # Requirement Assigned CDRL

9.5.2-1 The IVR system will allow customers to perform the following functions at a CDRL 9-5 minimum: • Obtain transit account balance and status information • Obtain sales, usage, and adjustment transaction history • Purchase fare products (e.g., stored value and passes) using a funding source already associated with the account • Set up, modify, and cancel autoload of stored value and passes for already existing funding sources Report a card lost or stolen Final IVR system functions will be determined during design review.

AGY-21-008-IT 241 | Page

APPENDIX 1

Req # Requirement Assigned CDRL

9.5.2-2 The IVR system will have an introduction that will be configurable by the CDRL 9-5 agency and will provide customer notifications and answers to common customer questions. 9.5.2-3 Unregistered customers will be able to use the IVR system to obtain transit CDRL 9-5 account balance (e.g., stored value and pass) and status (e.g., rider classification, active or blocked) information by entering a fare media ID. 9.5.2-4 Access to account information other than balance and status, and access to CDRL 9-5 all account management functions, will require the entry of an IVR PIN that is set at the time of account registration (see Section 6.6.2). 9.5.2-5 Following the successful entry of an IVR PIN, the IVR system will present CDRL 9-5 registered customers with an option to access their transaction history. Transaction history selection will provide customers the details of the last five (5) transactions performed (e.g., sales, usage, and adjustments) and include an option to hear more. 9.5.2-6 Registered customers will be able to initiate a load of value (e.g., stored CDRL 9-5 value and passes) via the IVR system using a saved funding source. The IVR system will support the selection of pass products and pre-defined stored value amounts, and entry of custom stored value amounts, subject to configurable minimum and maximum limits. 9.5.2-7 Registered customers will be able to enable, disable, and modify the CDRL 9-5 autoload of stored value and passes (see Section 6.6.3) via the IVR system. As part of the autoload setup process, the customer will select the stored value amount or pass to be loaded and the type of autoload (e.g., threshold or periodic). Autoload setup will require the use of a saved funding source. 9.5.2-8 Registered customers will be able to report a card lost or stolen via the IVR CDRL 9-5 system. This action will immediately result in the associated fare media being blocked from further use. The customer will have the option of being mailed a replacement card or purchasing a new card and having the balance transferred. For the mailing of a replacement card, a configurable replacement fee will be able to be charged. 9.5.2-9 The IVR system will provide an option to reach a live representative at any CDRL 9-5 time. When a customer is transferred to a customer service agent, all relevant data entered through the IVR system (e.g., fare media ID and customer account data) will be auto-populated within the CRM tool (see Section 8.3.3) used by the agent.

AGY-21-008-IT 242 | Page

APPENDIX 1

9.6 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 9-1 Customer Application Common Required for Phase 1 with Design Specifications X X X possible updates needed for subsequent Phases CDRL 9-2 Customer Website Design Required for Phase 1 with X X X possible updates needed for subsequent Phases CDRL 9-3 Mobile Website Design Required for Phase 1 with X X X possible updates needed for subsequent Phases CDRL 9-4 Institutional Website Design X X X Required for Phase 3 CDRL 9-5 Interactive Voice Response System Required for Phase 1 with Design X X X possible updates needed for subsequent Phases CDRL 9-6 * Fare Payment and Account Required for Phase 2 with Management Mobile Application X X X possible updates needed (PRICED OPTION) for subsequent Phases *CDRL 9-6 will only apply if the mobile application option is exercised under this contract 10. On-Board System Integration Requirements 10.1 CAD/AVL Integration Req # Requirement Assigned CDRL 10.1-1 The SI shall be responsible for the integration of the fare system CDRL 10-1 equipment installed onboard buses (FPV and/or BOD) with the existing Trapeze CAD/AVL system installed on agency vehicles. 10.1-2 The SI shall partner with Trapeze and be fully responsible for the CAD/AVL CDRL 10-1 integration, including all labor, hardware, and software costs incurred by both parties to successfully integrate the two systems. Any licensing costs necessary to support the CAD/AVL integration will be included in the SI’s cost proposal. 10.1-3 The SI may use either J1708/J1587 or ITxPT standards to support CDRL 10-1 integration with the CAD/AVL system; however, use of ItxPT is preferred. 10.1-4 The SI will provide all necessary cabling and equipment on the bus to CDRL 10-1 support this integration, as required, and determined by the configuration of each bus type.

AGY-21-008-IT 243 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 10.1-5 The integration will use either the SI-provided CAD/AVL Integration API CDRL 10-1 (see Section 5.3.1.8) or an API provided by Trapeze and will be used to capture operator login and trip data (i.e., single sign-on) and geo-location data from the CAD/AVL system. 10.1-6 The fare system will capture the following login and routing data from the CDRL 10-1 CAD/AVL system, at a minimum: • Operator ID • Pattern • Block • Route • Run • Direction 10.1-7 Login and routing data will be captured at login to the CAD/AVL system CDRL 10-1 and upon any change. Capture of this data will sever as the bus operator login to the fare system. 10.1-8 The login and routing data captured from the CAD/AVL system will be CDRL 10-1 appended to every fare transaction generated by the FPV. 10.1-9 The FPV will capture geo-location data generated by the CAD/AVL system, CDRL 10-1 including at a minimum: • Raw Global Positioning System (GPS) coordinates • Stop ID 10.1-10 Geolocation information will be captured for each fare transaction CDRL 10-1 generated by the FPV. As customers often continue to validate fares after a bus has the left the stop, the fare system will associate transactions to the last know Stop ID until then the next stop is reached (e.g., triggered by door opening). 10.1-11 The geo-location data will be appended to every fare transaction CDRL 10-1 generated by the FPV. The FPV may also include an embedded GPS receiver, and append locally captured GPS coordinate data to each transaction. 10.1-12 A detailed Interface Control Document (ICD) detailing message formats CDRL 10-1 and contents, procedures, interfaces, and transport protocols will be provided for the CAD/AVL integration.

10.2 Mobile Data Routers Integration Data communications for the SI-provided onboard equipment will be enabled through the existing onboard mobile router installed on MTA vehicles. The existing onboard router provides data communications via 4G and Wi-Fi for other onboard bus systems (such as CAD/AVL) and has the necessary capacity and capabilities to support the fare system.

AGY-21-008-IT 244 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 10.2-1 The SI shall integrate with the existing Sierra Wireless AirLink MG90 mobile CDRL 10-2 data router for data communications to the back-office. 10.2-2 The SI will provide all necessary cabling and equipment on the bus to CDRL 10-2 support this integration, as required, and determined by the configuration of each bus type. 10.2-3 The fare system will connect to the mobile data router via Ethernet. CDRL 10-2 10.2-4 The SI shall work with the MTA to support all necessary routing of data CDRL 10-2 coming off of the vehicles. 10.2-5 The SI will use 802.11 Wi-Fi communications for the exchange of non- CDRL 10-2 critical data at bus yards and other locations.

10.3 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 10-1 CAD/AVL Integration Specifications X X X Required for Phase 1 with possible updates needed for subsequent Phases CDRL 10-2 Mobile Data Router Integration X X X Required for Phase 1 with Specifications possible updates needed for subsequent Phases

11. Design Review Requirements 11.1 General Requirements Assigned Req # Requirement CDRL 11.1-1 Formal design reviews will be conducted to evaluate design progress, as CDRL 11-1 well as the technical, functional, and programmatic adequacy of the design in meeting the requirements in these specifications.

11.1-2 The SI shall submit a design review plan for agency review and approval CDRL 11-1 within 30 calendar days of the kickoff of each Phase. This plan will describe the scope, schedule, and deliverable format for each of the formal design reviews.

AGY-21-008-IT 245 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 11.1-3 The SI shall conduct three (3) formal design reviews for each Phase of the CDRL 11-1 project for a total of nine (9) reviews: Phase 1 design review • Conceptual Design Review (CDR) • Preliminary Design Review (PDR) • Final Design Review (FDR) Phase 2 design review • Conceptual Design Review (CDR) • Preliminary Design Review (PDR) • Final Design Review (FDR) Phase 3 design review • Conceptual Design Review (CDR) • Preliminary Design Review (PDR) • Final Design Review (FDR) The requirements for each design review Phase are described in this section. 11.1-4 Design reviews will consist of the following activities at a minimum: CDRL 11-1 • A design review package will be submitted by the SI and reviewed by the agency and consultant staff • A Master Issues List (MIL) will be created as a result of the review and will be provided to the SI • A formal design review meeting, or series of meetings, will be held between SI and agency staff, where the SI will explain the design and the agency will confirm compliance with the applicable requirements. Where possible, issues will be resolved during the design review meetings. • All issues discussed during the meetings will be documented. The agency will determine the appropriate action to close an issue, considering where the project is in the overall design. • If required, the SI shall resubmit the design review package, or parts of the package, to address the issues identified during the agency review and subsequent design review meeting • The design review package will be approved upon the agency’s determination that there are no critical open issues remaining in the MIL for that design Phase Other design review activities may be requested by the agency throughout the design review process.

AGY-21-008-IT 246 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 11.1-5 Each design review package will include documents in a searchable CDRL 11-1 electronic format (e.g., PDF) that will be shared via the agency-provided document control system (see Section 3.3.10), and at least one reproducible hard copy. 11.1-6 The SI shall submit design review packages that include all required CDRLs CDRL 11-1 and supporting documentation at least 21 calendar days prior to each formal design review meeting. 11.1-7 The agency will provide comments on the design review packages at least CDRL 11-1 seven (7) calendar days prior to each formal design review meeting. 11.1-8 Design review meetings will occur in Baltimore with the SI project CDRL 11-1 manager, lead engineer, and all relevant technical staff attending in person. The specific location will be identified by the agency, and a teleconference phone number will be available for remote participation where permitted. 11.1-9 The SI and/or the agency may establish suitable confidentiality and CDRL 11-1 nondisclosure agreements associated with design review submittals.

11.2 Conceptual Design Review The objectives of each Phase’s Conceptual Design Review (CDR) is to acquaint the agency with the SI's intended system design for the project’s current Phase, resolve any open items related to external system interfaces, and provide the basis for proceeding with the current project Phase’s Preliminary Design Review (PDR).

Assigned Req # Requirement CDRL 11.2-1 Each phase’s CDR package will be submitted within 45 calendar days CDRL 11-2 of the applicable Phase’s kickoff.

AGY-21-008-IT 247 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 11.2-2 At a minimum, each Phase’s CDR will include the following: CDRL 11-2 • Confirm the structure of the SI's management team and the scope of any subcontractors • Provide preliminary specifications for all equipment described in these specifications • Provide narrative descriptions of the major systems and subsystems proposed by the SI • Provide system block diagrams identifying all interfaces between system components, including external systems that will not be provided by the SI but will interface with the system • Describe the responsibilities and schedule for completion of detailed system interface definitions • Provide a software conceptual design, including software block diagrams for key system components • Confirm the SI’s understanding of the intended operations and maintenance environment • Identify key information and decisions required from the agency. • A preliminary list of user stories will be provided for any systems that interface with end-users, including internal and external end-users

In addition to the items listed above, specific submittals will be required as part of the Phase’s CDR. The CDR submittals are identified in the required submittals sections of these specifications. 11.2-3 If resubmittal of all or part of the Phase’s CDR package is required, the CDRL 11-2 SI shall provide the revised documents within seven (7) calendar days following completion of the formal design review meetings.

11.3 Preliminary Design Review The objectives of each Phase’s PDR are to review the progress of the system design and evaluate compliance of the completed design and work in progress with the requirements of these specifications applicable to the current project Phase. The SI is encouraged to categorize PDR information into logical topics for organized review and discussion.

Assigned Req # Requirement CDRL 11.3-1 Each Phase’s PDR package will be submitted within 60 days of the CDRL 11-3 applicable Phase’s CDR approval.

AGY-21-008-IT 248 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 11.3-2 Each Phase’s PDR will represent approximately 75% completion of the CDRL 11-3 total technical and operational system design of the applicable Phase. 11.3-3 Each Phase’s PDR may be conducted as a series of meetings in CDRL 11-3 Baltimore locations relevant to the topics being discussed. Where possible, the formal PDR meetings should be limited to confirmation of previously reviewed and approved-in-principle submittals, as well as the resolution of open items. 11.3-4 At a minimum, each Phase’s PDR will include the following: CDRL 11-3 • Schedule compliance review and discussion of variances or delays • Detailed hardware and software specifications for all SI- supplied devices, including power diagrams, functional block diagrams, mounting arrangements, and installation methods • Detailed software flow charts for all back-office systems • Complete customer and operator user interface specifications, flow charts, and messages for all SI-supplied devices and systems, including accommodations for all boundary and error conditions • Detailed interface and communication specifications for all internal and external system interfaces • Detailed specifications for all configuration control systems • Detailed specifications for access control systems supporting back-office operations • Detailed descriptions of system backup and recovery procedures • List of special tools and diagnostic test equipment needed for the maintenance of each SI-supplied device and system • A substantially complete list of user stories will be provided for any systems that interface with end-users, including internal and external end-users.

In addition to the items listed above, specific submittals will be required as part of PDR. The PDR submittals are identified in the required submittals sections of these specifications. 11.3-5 If resubmittal of all or part of the Phase’s PDR package is required, the CDRL 11-3 SI shall provide the revised documents within 14 calendar days following completion of the formal design review meetings.

11.4 Final Design Review The objective of Final Design Review (FDR) is to finalize the detailed system design that satisfies all of the requirements in these specifications.

AGY-21-008-IT 249 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 11.4-1 Each Phase’s FDR package will be submitted within 60 days of PDR CDRL 11-4 approval for the applicable project Phase. 11.4-2 Each Phase’s FDR will represent 100% completion of the detailed CDRL 11-4 system design with production specifications and drawings ready for release for the applicable project Phase. 11.4-3 Data submitted for each Phase’s PDR will be updated to a level of detail CDRL 11-4 consistent with a completed design and resubmitted as part of FDR for the applicable project Phase. 11.4-4 At a minimum, each Phase’s FDR will include the following: CDRL 11-4 • Schedule compliance review and discussion of variances or delays • Assembly drawings for all SI-supplied devices, down to the Lowest Level Replaceable Unit (LLRU) • Electrical schematic drawings for all SI-supplied devices • Preliminary “as-built” drawings and prototypes for all device mounting configurations • Final system architecture drawings • Detailed software specifications for all back-office systems with software module descriptions in a narrative format and data flow diagrams to the lowest level of decomposition • Detailed specifications for all application programming interfaces (APIs) supporting frontend and back-office operations • Detailed specifications for all system transaction formats • Detailed descriptions of all message formats and data elements for device and system events and alarms • Interface control documentation for all systems and subsystems • Complete data dictionary and detailed database design documentation, including all tables, views, and materialized views for all database schemas in the system, in electronic format (e.g., ER Studio) • Documentation of database programming features including, but not limited to, queries, query formats, triggers, jobs, functions, and procedures • A complete list of user stories will be provided for any systems that interface with end-users, including internal and external end-users

In addition to the items listed above, specific submittals will be required as part of FDR. The FDR submittals are identified in the required submittals sections of these specifications.

AGY-21-008-IT 250 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 11.4-5 Each Phase’s FDR will include a review of the spare parts required to CDRL 11-4 support the system. The SI and agency shall jointly review the spare parts listed in the contract and reallocate, delete, and add parts, as necessary. 11.4-6 If resubmittal of all or part of the Phase’s FDR package is required, the CDRL 11-4 SI shall provide the revised documents within fourteen (14) calendar days following completion of the formal design review meetings.

11.5 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 11-1 Design Review Plan X X X Kickoff for the applicable project Phase + 30 Calendar Days CDRL 11-2 Conceptual Design Review Package X Kickoff for the applicable project Phase + 45 Calendar Days CDRL 11-3 Preliminary Design Review Package X 60 Calendar Days Following applicable project Phase’s CDR Approval CDRL 11-4 Final Design Review Package X 60 Calendar Days Following applicable project Phase’s PDR Approval

12. Testing Requirements The SI shall plan for, perform, monitor, and document all tests required to prove acceptable design and delivery of the system, including all components and subsystems, and the integrated system as a whole. The SI shall furnish system equipment that meets the criteria specified for all tests.

The SI shall begin no portion of any Phase’s system testing (Factory Testing, Integration Testing, or Acceptance Testing) unless all design reviews and testing prerequisites for the applicable Phase have been successfully completed and approved in writing by the agency. If some elements of the system are rolled out prior to the Phase’s complete deployment, all testing stages will be completed in their entirety for each segment of deployment.

The testing for each Project Phase, with the exception of Phase 3, will be completed in three stages: Factory Testing, Integration Testing, and Acceptance Testing. Phase 3 will contain all the testing stages except for Factory Testing since no hardware is expected to be delivered. Likewise, if the TVM option for

AGY-21-008-IT 251 | Page

APPENDIX 1

Phase 2 is not exercised Factory Testing will again be omitted since no hardware would be delivered within the Phase. The test stages and individual tests of which those stages are comprised are summarized in Exhibit 12-1 and described in more detail in the following sections.

AGY-21-008-IT 252 | Page APPENDIX 1

Exhibit 12-1 Testing Overview Condition for Conditions for Testing Stage Test Purpose Project Phase Commencement Completion 1. First Article Inspect first production First piece of pre- All equipment types Configuration unit hardware production equipment deemed to meet Inspection (FACI) configuration and quality produced (for each applicable hardware prior to full production equipment type) for the configuration run Project Phase being requirements in the tested technical specification for the Project Phase being tested 2. Factory Test that SI-provided First piece of pre- All equipment types Acceptance equipment and systems production equipment deemed to meet Phase 1 & 2* Testing (FAT) meet all human factors, passed FACI (for each applicable human Factory environmental, and equipment type) for the factors, environmental *May be omitted Testing maintainability Project Phase being and maintainability requirements prior to full tested requirements in the from Phase 2 if the production run technical specification TVM option is NOT exercised for the Project Phase being tested 3. Production Confirm each piece of 1. All equipment types Production runs for all Acceptance Test equipment is properly passed FAT for the Project equipment completed (PAT) constructed and Phase being tested and each piece of functional following 2. Equipment production equipment passed PAT production run commenced for the for the Project Phase Project Phase being being tested tested

AGY-21-008-IT 253 | Page APPENDIX 1

Condition for Conditions for Testing Stage Test Purpose Project Phase Commencement Completion 4. Functional Unit Test full functionality of 1. Partial system All functionality required Test (FUT) each system component development and in technical specification individually in a lab functionality is ready for demonstrated for each environment prior to preliminary review and system component, and integration. As demonstration all cycling test passed for functionality is developed, the Project Phase being 2. Component-level FUT will include periodic tested software development system demonstrations completed for the Project for the MTA to witness. Phase being tested 3. Production components installed and Integration configured in the test lab All Project Phases Testing for the Project Phase being tested 5. System Test all functionality of 1. All system components All functionality required Integration Test the integrated system, passed FUT for the Project in technical specification (SIT) including possible Phase being testing demonstrated on fully regression testing for 2. Fully integrated system integrated system in the previous Project Phases’ installed and configured test lab for the Project functionality in a lab in the test lab for the Phase being tested, environment Project Phase being including applicable tested regression tested functionality

AGY-21-008-IT 254 | Page APPENDIX 1

Condition for Conditions for Testing Stage Test Purpose Project Phase Commencement Completion 6. Field Install and test all 1. Integrated system All functionality required Integration Test functionality of the passed SIT for the Project in technical specification (FIT) production system in the Phase being tested demonstrated on a fully field, including possible 2. Production back-office integrated system in the regression testing for fully installed and field for the Project previous Project Phases’ configured for the Project Phase being tested functionality Phase being tested including applicable 3. 10% of all equipment regression tested types installed in the functionality production environment for the Project Phase being tested

30-Day Settling Period All Project Phases

AGY-21-008-IT 255 | Page APPENDIX 1

Condition for Conditions for Testing Stage Test Purpose Project Phase Commencement Completion 7. Pilot Test system functionality 1. Integrated system 1. All transactions including possible passed FIT for the Project successfully processed regression testing for Phase being tested throughout 90-day pilot previous Project Phases’ 2. Completion of 30-day run for the Project Phase functionality with settling period for the being tested including all structured test and ad- Project Phase being applicable regression hoc use of friendly users tested tested functionality 3.All equipment installed 2. Peak transaction in the production volumes reached for environment for the stress testing for the Acceptance Project Phase being Project Phase being All Project Phases Testing tested tested including all applicable regression tested functionality 3. No major issues outstanding on the punch list for the Project Phase being tested including any issues found when testing applicable regression test functionality

AGY-21-008-IT 256 | Page APPENDIX 1

Condition for Conditions for Testing Stage Test Purpose Project Phase Commencement Completion 8. System Test that system fully 1. Pilot complete for the System meets all Acceptance Test meets all performance Project Phase being performance (SAT) requirements including tested requirements in the possible regression technical specification testing for previous for three consecutive 30- Project Phases’ day periods for the performance Project Phase being requirements in the tested including all technical specification applicable regression tested performance requirements 9. Final 1. Fully installed production system Acceptance passed SAT for all Project Phases After all Project 2. All documentation delivered and Phases have training conducted for all Project Phases completed SAT 3. All requirements of the contract confirmed as met for all Project Phases

AGY-21-008-IT 257 | Page

APPENDIX 1

12.1 General Requirements Assigned Req # Requirement CDRL 12.1-1 All system components and subsystems will be tested individually and in CDRL 12-1 integrated environments to ensure that they meet all technical, functional, and performance requirements in these specifications. 12.1-2 Testing will incorporate all requisite integration with existing agency CDRL 12-1 systems as described in these specifications. 12.1-3 The SI shall provide all labor and materials required for system testing, CDRL 12-1 including but not limited to closed-loop fare media and bank cards, and all support services and facilities required to stage, inspect and test all hardware and software being supplied. 12.1-4 All tests and inspections will be documented by the SI and monitored and CDRL 12-1 signed off by the agency or their representatives, as well as by the SI or its representatives. 12.1-5 The SI shall test and verify that they can successfully utilize the agency- CDRL 12-1 provided communications networks for deployment of the system as designed. 12.1-6 Any and all hardware or software not passing inspection or test will be CDRL 12-1 replaced, or otherwise corrected by the SI and retested, at no additional cost to the MTA. 12.1-7 The SI shall establish the agency test facility as specified in Section 12.3 no CDRL 12-1 later than the commencement of integration testing, specified in Section 12.5. 12.1-8 Prior to the start of any project Phase’s formal testing, the SI shall conduct CDRL 12-1 a “dry-run” review and testing of hardware and software components to identify and resolve any issues that arise before formal testing commences. 12.1-9 Successful completion of each project Phase’s various stages of testing will CDRL 12-1 be subject to agency approval based on approved test criteria.

AGY-21-008-IT 258 | Page

APPENDIX 1

12.2 Test Documentation

12.2.1 Inspection and Test Plan

Assigned Req # Requirement CDRL 12.2.1-1 The SI shall submit a draft inspection and test plan for agency review and CDRL 12-1 approval during each Phase’s design review, and shall submit a final inspection and testing plan to be used in connection with all inspections and tests described in this specification no less than 60 calendar days prior to the start of any Phase’s testing. 12.2.1-2 Each Phase’s inspection and test plan will include a detailed schedule CDRL 12-1 indicating the sequence of each test, where and when each test will take place, and the number of SI-provided staff covering each test. 12.2.1-3 Each Phase’s inspection and test plan will cover all SI, equipment supplier, CDRL 12-1 and subcontractor inspections and tests to be performed, including those performed under the SI’s QA program (see Section 3.3.8). 12.2.1-4 Each Phase’s inspection and test plan will include plans for each factory CDRL 12-1 and integration test defined in this section, including: 1. First Article Configuration Inspection (FACI)* 2. Factory Acceptance Test (FAT)* 3. Production Acceptance Test (PAT)* 4. Functional Unit Testing (FUT) 5. System Integration Test (SIT) 6. Field Integration Test (FIT) Acceptance testing will be described in a separate acceptance test plan. *Items 1-3 are only required in the project Phase’s test plan if the project Phase being tested requires hardware delivery 12.2.1-5 Each Phase’s inspection and test plan will detail the number and range of CDRL 12-1 tests, as well as the criteria for acceptance of each Phase of testing. All performance measurement procedures and acceptance criteria, including the number and type of failures allowed in each Phase of testing, will be subject to agency review and approval. The plan will also include any agency-specified requirements identified during PDR. 12.2.1-6 Each Phase’s inspection and test plan will identify any requirements the SI CDRL 12-1 intends to meet by any means other than the testing process described in this specification.

AGY-21-008-IT 259 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.2.1-7 Each Phase’s inspection and test plan will include performance testing CDRL 12-1 such as load, stress, endurance, and spike testing for applicable devices and software that simulates peak ridership and transaction volumes over various time intervals. The agency may provide updated transaction volume projections for use in the inspection and test plan at design review. 12.2.1-8 No Phase’s inspections or tests will be performed until the SI has received CDRL 12-1 agency approval of the applicable Phase’s inspection and test plan and the associated schedule.

12.2.2 Inspection and Test Procedures

Assigned Req # Requirement CDRL 12.2.2-1 SI shall prepare and submit to the agency a detailed procedure for each CDRL 12-2 inspection and test to be performed. 12.2.2-2 Detailed inspection and test procedures will be submitted to the agency CDRL 12-2 for review and approval a minimum of 30 calendar days prior to the corresponding test unless otherwise specified herein. 12.2.2-3 The SI shall conduct no inspection or test until approval of the CDRL 12-2 corresponding test procedure has been granted the agency. 12.2.2-4 Detailed inspection and test procedures will include mapping or CDRL 12-2 references to the project Phase’s design documents and functional RTM CDRL requirements related to the test. This mapping will be present both in the testing documentation and a separately maintained Requirements Traceability Matrix (RTM). 12.2.2-5 Inspection and test procedures will include detailed test scripts for each CDRL 12-2 test case to be performed as part of the test. Test scripts will include test case setup instructions and preconditions, step-by-step instructions for performing the test, and expected results for each step. 12.2.2-6 A re-test will be performed for any failed test cases and for system CDRL 12-2 components requiring adjustment, repair, or replacement as a result of the testing, up to and including the entire system, if deemed necessary by the agency.

AGY-21-008-IT 260 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.2.2-7 Detailed inspection and test procedures will be delivered for each factory CDRL 12-2 and integration test defined in this section, including: 1. First Article Configuration Inspection (FACI)* 2. Factory Acceptance Test (FAT)* 3. Production Acceptance Test (PAT)* 4. Functional Unit Testing (FUT) 5. System Integration Test (SIT) 6. Field Integration Test (FIT) *Item’s 1-3 are only required for inspection and test procedures in Phases with hardware delivery 12.2.2-8 The agency reserves the right to develop additional test procedures and CDRL 12-2 include ad-hoc test cases to be performed by the SI or other designated third-parties, during all Phases of testing.

12.2.3 Inspection and Test Reports

Assigned Req # Requirement CDRL 12.2.3-1 The SI shall submit a written report for each inspection and test that is CDRL 12-3 performed, including copies of all data generated during the test, for agency review and approval. 12.2.3-2 Inspection and test reports will include the detailed test scripts from CDRL 12-3 the associated procedures noting any exceptions to the stated test conditions, recording all relevant setup and configuration information (e.g., fare media serial numbers and device IDs), and marking each step as passed or failed. 12.2.3-3 Inspection and test reports will include detailed test results, including CDRL 12-3 all transaction data generated, detailed failure descriptions and resolution, modifications or repairs pertaining to the components or systems being tested, and any re-test results. 12.2.3-4 All transaction data generated during testing will be submitted in Excel CDRL 12-3 format to allow for simple storage and analysis by the agency.

AGY-21-008-IT 261 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.2.3-5 Detailed inspection and test reports will be delivered for each factory CDRL 12-3 and integration test defined in this section, including: 1. First Article Configuration Inspection (FACI) 2. Factory Acceptance Test (FAT)* 3. Production Acceptance Test (PAT)* 4. Functional Unit Testing (FUT)* 5. System Integration Test (SIT) 6. Field Integration Test (FIT) *Item’s 1-3 are only required for inspection and test procedures in Phases with hardware delivery 12.2.3-6 Reports will be submitted to the agency for review and approval within CDRL 12-3 10 calendar days of the completion of any test. 12.2.3-7 No stage of testing will be considered complete until the associated CDRL 12-3 report is approved by the agency.

12.2.4 Test Waivers

Assigned Req # Requirement CDRL 12.2.4-1 If a component or subsystem is considered by the agency to be identical or CDRL 12-4 substantially similar in design and configuration to equipment previously deployed in other applications with similar or more stringent environments, specific tests of that system component may not be necessary. To obtain a waiver, the SI must provide a formal request to waive testing for each applicable component or subsystem. 12.2.4-2 If the SI desires a waiver of testing, the SI shall submit required CDRL 12-4 information for each applicable component or subsystem 60 calendar days prior to the date of planned testing.

AGY-21-008-IT 262 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.2.4-3 A request to waive testing will include the following information: CDRL 12-4 • List of the locations and quantities of previously installed equipment, including duration of revenue service • Description of all relevant differences between the other installation locations those described in this specification • Description of all relevant differences between the previously installed equipment and the components being provided to meet the requirements of these specifications • Test results for all relevant tests that have been conducted on the equipment • Reliability data for the equipment, as verifiable through the purchasers • Proposed cost credit to the contract for granting the waiver of testing 12.2.4-4 Based on the submitted data, the agency will determine whether CDRL 12-4 requirements for testing will be waived. 12.2.4-5 Specific testing requirements for each system component will be CDRL 12-4 considered individually, and waivers will be issued on an individual test and component basis; it is possible the agency may grant a waiver for certain tests while others will still be required. 12.2.4-6 No waivers will be granted for the integration or acceptance testing of the CDRL 12-4 components or system.

12.3 Agency Test Facility The agency shall identify and provide a secure facility in Baltimore for the placement of an SI-furnished test facility where the agency and SI may test system hardware and software. The agency will be responsible for providing and maintaining network communications to the test facility. The SI shall provide all maintenance support for the test facility equipment, systems, and interfaces through Final Acceptance, and maintain the test facility software configuration throughout the terms of the warranty and software maintenance agreement (see Section 15).

Assigned Req # Requirement CDRL 12.3-1 The SI shall furnish a test facility on agency property for both SI and CDRL 12-5 agency use. 12.3-2 The SI shall update the agency test facility software as necessary to CDRL 12-5 maintain a fully mirrored environment of SI’s test facility.

AGY-21-008-IT 263 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.3-3 The test facility will include a separate back-office instance, including the CDRL 12-5 account-based transaction processor and all specified support systems, which fully replicates the production environment. The test facility back- office hardware will be identical to the production system hardware, but will not require the system redundancy specified in Section 5.10. 12.3-4 The test facility will include at least two (2) units of every equipment type CDRL 12-5 deployed within the system, including any existing equipment (e.g., CAD/AVL system) that is integrated with the new fare system. The agency will be responsible for maintaining the configuration of any test facility equipment that is not provided by the SI. 12.3-5 The agency test facility will be fully installed and configured for the Phase CDRL 12-5 being tested prior to the commencement of integration testing and will include at a minimum: • Fully integrated back-office with ATP and all support systems (i.e., CRM system, SMMA, MIMS, RMS, data warehouse, and reporting system) • Two (2) bus validators, each connected to a driver display, mobile data router, and agency-provided Bus-In-A-Box (BIB) with an integrated CAD/AVL system • Two (2) TVMs supporting both bus and rail configurations • Two (2) faregates, including a standard and ADA-compliant gate • Two (2) CSTs, with all supported peripherals • Two (2) mobile fare inspection devices • Two (2) internet-connected PCs configured to access customer and institutional websites, and all web-based back-office tools (e.g., CRM tool, SMMA, and reporting system) 12.3-6 With the exception of factory testing, all specified formal testing will be CDRL 12-5 conducted in Baltimore, and all laboratory-based testing will be conducted in the agency test facility. 12.3-7 The agency test facility will have the ability to connect directly to the CDRL 12-5 merchant acquirer or any other processing entity to fully test the processing of credit and debit transactions. 12.3-8 The SI shall provide all special tools, documentation, and test and CDRL 12-5 inspection equipment necessary for troubleshooting, testing, repairing, and calibrating all devices and modules in the agency test facility down to the LLRU.

AGY-21-008-IT 264 | Page

APPENDIX 1

12.4 Factory Testing

12.4.1 First Article Configuration Inspection

The purpose of First Article Configuration Inspection (FACI) is to confirm that the first unit of each equipment type that is manufactured or procured by the SI meets the hardware configuration and quality requirements in these specifications. FACI will be conducted at the SI’s facilities.

Assigned Req # Requirement CDRL 12.4.1-1 The agency will be notified no less than 60 business days prior to the CDRL 12-1 commencement of any Project Phase’s FACI; subsequently, the SI shall be advised regarding the agency’s attendance. 12.4.1-2 The SI shall deliver all data, including the latest drawings, specifications, CDRL 12-1 quality documentation, and test procedures required for adequate inspection of the first article system components a minimum of 30 calendar days prior to any Phase’s FACI. 12.4.1-3 Each Phase’s FACI will take place at the point of assembly, after CDRL 12-1 manufacture or procurement of the first production units for each of the system components: bus validators, driver displays, ticket vending machines (if option exercised), faregates, customer service terminals, mobile fare inspection devices, mobile fare validation devices, and the back-office, including all subsystems. 12.4.1-4 Each Phase’s FACI will verify that the production units comply with these CDRL 12-1 specifications, including design configuration and drawings as approved during the final design review, or the latest revision thereof. 12.4.1-5 At each Phase’s FACI, the agency will have the right to inspect any and all CDRL 12-1 of the units produced to date. 12.4.1-6 Expectations for the quality of workmanship for the future production of CDRL 12-1 components will be established at each Phase’s FACI. 12.4.1-7 Documentation of quality inspections performed at subcontractor facilities CDRL 12-1 or of the SI’s quality inspections of components manufactured by others will be available for the agency review at each Phase’s FACI. 12.4.1-8 No additional production units will be manufactured or procured by the SI CDRL 12-1 until the applicable Phase’s FACI has been approved by the agency.

12.4.2 Factory Acceptance Test

The purpose of the Factory Acceptance Test (FAT) is to demonstrate that the system components to be furnished meet the human factors, environmental, and maintainability requirements contained in this specification. In the event that the SI has already conducted similar tests on identical or nearly identical equipment, the agency may, but are not obligated to, accept the results of those tests as satisfying some or all of the requirements in this section.

AGY-21-008-IT 265 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.4.2-1 Successful completion of the applicable project Phase’s FACI, including CDRL 12-1 agency approval of all inspection reports, is a pre-requisite for the commencement of the applicable Project Phase’s FAT. 12.4.2-2 The SI shall prepare and submit the applicable Phase’s FAT test procedures CDRL 12-1 within 21 calendar days following the completion of the applicable Phase’s FACI for review and approval by the agency. 12.4.2-3 System components to be tested in the applicable Phase’s FAT will be CDRL 12-1 from the first run of production units and may be chosen by the agency. Once chosen, the units may not be modified without the express consent of the agency. Once a particular series of tests begins on a particular unit, it should be completed on that unit. 12.4.2-4 Each Phase’s FAT will be conducted by the SI at the SI's facility or at a CDRL 12-1 subcontractor’s facility designated by the SI. The SI shall provide all necessary supplies for FAT. 12.4.2-5 The agency will, at its discretion, assign staff or representatives to witness CDRL 12-1 and/or periodically audit each Phase’s FAT progress. 12.4.2-6 Human factors testing will demonstrate device compliance with the CDRL 12-1 general design requirements in Section 4 and component requirements identified in Section 7. 12.4.2-7 Environmental testing will demonstrate compliance with the CDRL 12-1 environmental requirements contained in Section 4.7. 12.4.2-8 Maintainability testing will demonstrate compliance with the CDRL 12-1 maintainability requirements set forth in Section 4.6. 12.4.2-9 If SI has already conducted substantially similar tests to those described CDRL 12-1 herein the SI shall submit the procedures and results of those tests to the agency for consideration at least 60 calendar days prior to the applicable Phase’s scheduled FAT. 12.4.2-10 The SI shall be responsible to maintain reports of all tests conducted CDRL 12-1 throughout each FAT, showing each test conducted and the test results. The reports will be submitted to the agency at the conclusion of each Phase’s FAT for review and approval. 12.4.2-11 Results not meeting specified requirements will be fully documented and CDRL 12-1 explained by the SI, and a corrective action plan will be submitted. 12.4.2-12 Successful completion of the applicable Phase’s FAT will be a prerequisite CDRL 12-1 for the manufacturing of the applicable Phase’s production system components. 12.4.2-13 The agency may delay the delivery of any applicable Phase’s system CDRL 12-1 components until FAT procedures are successfully completed and approved.

AGY-21-008-IT 266 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.4.2-14 If at any time after the FAT results have been approved a design change is CDRL 12-1 made, the performance of the modified system components will be demonstrated as conforming to this specification and the test results will be resubmitted for agency approval.

12.4.3 Production Acceptance Test

The purpose of the Production Acceptance Test (PAT) is to demonstrate that each piece of equipment manufactured or procured by the SI is operational and meets the design and quality requirements described in these specifications.

Assigned Req # Requirement CDRL 12.4.3-1 The SI and their subcontractors shall perform PATs on each system CDRL 12-1 component at the point of manufacture as an integral part of their QA program prior to each shipment. 12.4.3-2 Each Phase’s PATs will verify, and the SI shall certify, that all appliable CDRL 12-1 system components contain the correct materials, are assembled properly, and function all in accordance with these specifications. Testing should include validation against established performance metrics. 12.4.3-3 Each Phase’s PATs will verify that each unit is produced to at least the CDRL 12-1 same quality level as the unit presented for in the applicable Phase’s FACI and FAT. 12.4.3-4 At a minimum, and as applicable, these tests will test the following CDRL 12-1 functions: • General device operation and performance in all modes • Data generation and transfer • Alarms generation and transmittal • User interface control and display 12.4.3-5 The SI shall update PAT procedures based upon experience gained from CDRL 12-1 subsequent testing and/or system component operation. Test procedures will be expanded to focus on areas that prove to be, or have historically been, troublesome. 12.4.3-6 The SI shall be responsible for maintaining complete reports of all PATs CDRL 12-1 that are performed. The reports will note any failures, subsequent corrective measures, and retests. 12.4.3-7 All reports shall be submitted to the agency for review and approval within CDRL 12-1 5 business days of the completion of the Phase’s PAT testing. 12.4.3-8 The agency may choose to observe, participate in, conduct, or repeat CDRL 12-1 testing on any item to confirm the validity of the SI’s test procedures and results. The agency may also perform, at their discretion, ad-hoc tests to ensure the quality of the system components. The SI shall provide appropriate access to support ad-hoc testing if required.

AGY-21-008-IT 267 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.4.3-9 Successful completion of a Phase’s PAT on all applicable equipment will be CDRL 12-1 a prerequisite for the installation of that equipment at agency facilities.

12.5 Integration Testing

12.5.1 Functional Unit Testing

The purpose of Functional Unit Testing (FUT) is to demonstrate in a controlled laboratory environment that each of the system components and associated software furnished by the SI meets all functional requirements contained in these specifications prior to full system integration.

Assigned Req # Requirement CDRL 12.5.1-1 Successful completion of component-level software development and CDRL 12-1 installation of production equipment in the agency test facility for the project Phase being tested (see Section 12.3) are pre-requisites for the commencement of FUT. 12.5.1-2 All FUT tests will be conducted by the SI at the agency test facility in CDRL 12-1 Baltimore. 12.5.1-3 Each Phase’s FUT test procedures will be submitted to the agency for CDRL 12-1 review and approval at least 60 calendar days prior to the scheduled FUT. 12.5.1-4 Each Phase’s FUT functional and cycling tests will demonstrate all base CDRL 12-1 functions of the system components. 12.5.1-5 All device interfaces with the back-office necessary to perform the FUT CDRL 12-1 testing may be simulated if the interfaces or back-office software is not ready to be tested. 12.5.1-6 All contactless media to be used in FUT will be provided by the SI. The SI CDRL 12-1 shall document, inventory, and track media usage during testing. Contactless media will be the same or similar to those planned for revenue service. 12.5.1-7 The agency will, at its discretion, assign staff or representatives to CDRL 12-1 witness and/or audit FUT testing. 12.5.1-8 The SI shall be responsible for maintaining complete reports of all tests CDRL 12-1 performed throughout FUT, showing each test conducted and the test results. 12.5.1-9 Results not meeting specification requirements will be fully documented CDRL 12-1 and explained by the SI, and a plan for corrective action will be submitted.

AGY-21-008-IT 268 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.5.1-10 All test reports will be submitted to the agency at the conclusion of each CDRL 12-1 project Phase’s FUT for review and approval. 12.5.1-11 If at any time after the FUT results have been approved a design change CDRL 12-1 is made, the performance of the modified system components will be demonstrated as conforming to these specifications and the test results will be resubmitted for agency approval.

12.5.1.1 Devices

FUT testing of the devices will cover the bus validators/driver displays, ticket vending machines (if option exercised), faregates, customer service terminals, mobile fare inspection devices, and mobile fare validation devices (if option exercised), and will include the tests described in this section. Successful completion of the testing requires no failures or discrepancies in the functionality agreed to at FDR.

Assigned Req # Requirement CDRL 12.5.1.1-1 The SI shall complete functional tests for all devices to verify the proper CDRL 12-1 performance and operation of the devices. The SI and the agency shall jointly develop the structure, timing, and pass/fail criteria of the functional FUT testing. 12.5.1.1-2 After completing the device functional testing, the SI shall conduct CDRL 12-1 device cycling tests, which will consist of performing transactions using all media and transaction types. 12.5.1.1-3 Cycle testing will be comprised of at least: CDRL 12-1 • 8,000 transactions each for bus validators/driver displays, ticket vending machines (if option exercised), and faregates • 4,000 transactions each for customer service terminals, and mobile fare inspection devices 12.5.1.1-4 Subsequent to the successful completion of each Phase’s FUT, the SI CDRL 12-1 shall conduct an environmental cycling test. The environmental cycling test will subject each type of applicable device to a scaled down cycling test under the environmental extremes specified in Section 4.7 to demonstrate the capability of the device to operate successfully under these conditions.

12.5.1.2 Back-office, Websites, IVR, Mobile Applications

FUT testing for the back-office tools and websites will include the tests described in this section. Successful completion of the testing requires no failures or discrepancies in the functionality agreed to at the FDR, and 100 percent accuracy of all data exchanges and display.

AGY-21-008-IT 269 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.5.1.2-1 The SI shall complete functional tests for the back-office tools and CDRL 12-1 websites which will demonstrate and verify all functions described in these specifications, including the review and usability testing of all user- accessible screens and commands. 12.5.1.2-2 Any required interfaces to external systems to demonstrate this CDRL 12-1 functionality may be simulated. 12.5.1.2-3 The SI shall generate samples of all available reports as compliant with the CDRL 12-1 designs approved at the applicable project Phases’ FDRs for review and approval by the agency.

12.5.2 System Integration Test

When a project Phase’s FUT has been successfully completed, the SI shall conduct a System Integration Test (SIT) for the applicable Phase. SIT will confirm that when installed, the fully integrated system will perform, operate, and communicate as required in a controlled laboratory environment.

SIT is intended to demonstrate all device functionality and back-office operation, monitoring, and reporting functions described in these specifications with full integration of the devices and back-office, including all support systems. SIT will also test communications and data transmission over agency and third-party networks, as required to complete the tests. With successful completion of each Phase’s SIT, all software and configuration files for the applicable Phase will be “frozen,” and the SI shall make no changes without agency authorization

Assigned Req # Requirement CDRL 12.5.2-1 The applicable project Phase’s FUT for all applicable components and CDRL 12-1 systems must be completed and approved prior to the commencement of SIT. 12.5.2-2 All SIT testing will be conducted by the SI at the agency test facility in CDRL 12-1 Baltimore. 12.5.2-3 Prior to any Phase’s SIT, the SI shall complete the setup of the agency test CDRL 12-1 facility, including the installation and configuration of all applicable system components, the test facility back-office, workstations required for back- office operation, and all integration required in these specifications. The SI shall connect fare collection equipment to additional equipment or simulators as necessary to create a functional model of the system. 12.5.2-4 The SI shall submit detailed SIT test procedures for each Phase to the CDRL 12-1 agency for review and approval no later than 60 calendar days prior to commencement of the applicable Phase’s SIT. A software installation plan and system configuration diagram for the agency test facility will be submitted as part of the SIT procedures.

AGY-21-008-IT 270 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.5.2-5 For each Phase’s SIT, the test system will be provisioned with test data CDRL 12-1 simulating the system’s operational databases under full operational load. Full operational load will be defined in the applicable Phase’s SIT test procedure and approved by the agency prior to the commencement of SIT. 12.5.2-6 The SI shall conduct a series of detailed transactions and other operations CDRL 12-1 that will fully emulate a broad spectrum of usage and operating scenarios, in sufficient quantity to ensure the validity of the test results. The SI shall provide a list of operating scenarios as part of the SIT test procedure for agency review and approval. 12.5.2-7 At a minimum, each Phase’s SIT will include: CDRL 12-1 • Ten (10) days of continuous testing of all system components, during which the components will be operational 24 hours a day • A minimum of 500 transactions at each system component type, including bus validators, driver displays, mobile data routers, ticket vending machines, faregates, customer service terminals, mobile fare inspection devices, testing all transaction types • A minimum of 100 transactions each performed through the. CRM system, customer website, institutional website, and IVR system, testing all available functions • All alarm and boundary conditions tested at a minimum of 50 times each • Applicable Online and offline transactions • Phase 2 and Phase 3’s SIT will include applicable regression test cases that cover transactions tested in previous Project Phases Specifics of each Phase’s SIT testing will be included in the SIT procedures to be reviewed and approved by the agency. 12.5.2-8 The SI shall conduct data transmission testing during SIT to demonstrate, CDRL 12-1 exercise, and verify transaction processing and data uploads from all devices, and the download of configuration data to each of the various device types. The SI shall confirm proper data transfer rates between all devices and systems. 12.5.2-9 SIT will demonstrate monitoring, configuration, and control of all field CDRL 12-1 devices using the SMMA. 12.5.2-10 SIT will include database accuracy testing, which will demonstrate the CDRL 12-1 accuracy between the AUT (application under test) and the relational database in which application-generated data is stored. The testing should also demonstrate atomicity, consistency, insolation, and durability of the database.

AGY-21-008-IT 271 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.5.2-11 Each Phase’s SIT will include a full system audit and settlement test, which CDRL 12-1 will demonstrate the flow of all transactions through the system with the appropriate reporting, accounting, and settlement calculations demonstrated. 12.5.2-12 The agency test facility will be connected directly to the merchant acquirer CDRL 12-1 or any other processing entity to fully test the processing of purchases through all sales channels supporting credit/debit sales. 12.5.2-13 The agency will, at their discretion, assign staff or representatives to CDRL 12-1 witness and/or augment SIT tests. This could include providing ad-hoc test scripts to be undertaken by the SI and witnessed by the agency. 12.5.2-14 During SIT, all software modifications will be reviewed, demonstrated, CDRL 12-1 tested, and approved by the agency. The SI shall record version information for all software modules including the date and time the software was created, the size of each file, and version number. 12.5.2-15 The SI shall provide detailed test reports and “as-tested” software CDRL 12-1 documentation at the conclusion of each Phase’s SIT for agency review and approval.

12.5.3 Field Integration Test

Upon completion of SIT and initial field installation activities, the SI shall conduct a Field Integration Test (FIT) wherein all devices, back-office systems, websites, interfaces, and all other aspects of the system are exercised in what will become the production environment. The FIT will demonstrate that the system is ready to enter the acceptance testing Phase.

Assigned Req # Requirement CDRL 12.5.3-1 Installation of the applicable system components at the agency’s CDRL 12-1 properties will commence upon approval of the applicable Phase’s SIT. The entire production back-office and at least 10% of the total install base for each type of equipment must be fully installed and configured prior to the commencement of the applicable Phase’s FIT. 12.5.3-2 All FIT testing will be conducted by the SI in the production environment in CDRL 12-1 Baltimore. 12.5.3-3 The SI shall submit detailed FIT test procedures to the agency for review CDRL 12-1 and approval no later than 60 calendar days prior to commencement of the applicable Phase’s FIT. Pre-and post-installation checklists and test reports will be included for all installed equipment as part of the FIT procedures.

AGY-21-008-IT 272 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.5.3-4 For each project Phase’s FIT, the production system will be provisioned CDRL 12-1 with test data simulating the system’s operational databases under full operational load. Full operational load will be defined in the FIT test procedure and approved by the agency prior to the commencement of FIT. 12.5.3-5 Similar to SIT, the SI shall conduct a series of detailed transactions and CDRL 12-1 other operations in FIT that will fully emulate a broad spectrum of usage and operating scenarios, in sufficient quantity to ensure the validity of the test results. All functional characteristics of the installed system components at each location will be tested to ensure the operation of the components as specified, including interfaces with the back-office and integration with agency systems. 12.5.3-6 At a minimum, each Phase’s FIT will include: CDRL 12-1 • Twenty (20) days of continuous testing of all system components, during which the components will be operational 24 hours a day • A minimum of 500 transactions at each system component type, including bus validators, driver displays, mobile data routers, ticket vending machines, faregates, customer service terminals, and, mobile fare inspection devices, testing all transaction types • A minimum of 100 transactions each performed through the CRM system, customer website, institutional website, and IVR system, testing all available functions • All alarm and boundary conditions tested at a minimum of 50 times each • Phase 2 and Phase 3’s FIT will include applicable regression test cases that cover transactions tested in previous Project Phases

Final transaction volumes and specifics of FIT testing will be included in the applicable Phase’s FIT procedures to be reviewed and approved by the agency. 12.5.3-7 The applicable Phase’s FIT procedures will identify and describe all CDRL 12-1 necessary tests to verify proper installation and interfacing of the system components across all system facilities. 12.5.3-8 The SI shall conduct data transmission testing during FIT to demonstrate, CDRL 12-1 exercise, and verify transaction processing and data uploads from all devices, and the download of configuration data to each of the various device types. The SI shall confirm proper data transfer rates between all devices and systems. 12.5.3-9 FIT will demonstrate monitoring, configuration, and control of all field CDRL 12-1 devices using the SMMA.

AGY-21-008-IT 273 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.5.3-10 FIT will include database accuracy testing, which will demonstrate the CDRL 12-1 accuracy between the AUT (application under test) and the relational database in which application-generated data is stored. The testing should also demonstrate atomicity, consistency, insolation, and durability of the database. 12.5.3-11 FIT will fully test all system redundancy measures and successfully CDRL 12-1 demonstrate the execution of the disaster recovery plan. This will include at a minimum: • Failover testing, in which the SI validates that each of the hosted back-office systems and system hardware/software components correctly fails over automatically to the remaining online back- office site or backup hardware/software component with no degradation of service under peak projected operating loads • Disaster recovery simulations in which the SI runs mock simulations with agency staff to validate their Disaster Recovery Plan is adequate to handle a total system outage 12.5.3-12 Each Phase’s FIT will include a full system audit and settlement test, which CDRL 12-1 will demonstrate the flow of all transactions through the system with the appropriate reporting, accounting, and settlement calculations demonstrated. 12.5.3-13 The system will be connected directly to the merchant acquirer or any CDRL 12-1 other processing entity to fully test the processing of purchases through all sales channels supporting credit/debit sales. 12.5.3-14 Agency witnessing and participation will be required for the successful CDRL 12-1 completion of FIT. This could include providing additional test scripts to be undertaken by the SI and witnessed by the agency. 12.5.3-15 SI shall submit all FIT test reports to the agency for approval at the CDRL 12-1 conclusion of each Phase’s FIT. 12.5.3-16 A 30-day settling period will commence upon approval of each Phase’s FIT CDRL 12-1 test reports. 12.5.3-17 The agency may, at their sole discretion, conduct additional ad-hoc testing CDRL 12-1 during the 30-day settling period. Ad-hoc testing may include limited “friendly user” testing. 12.5.3-18 Installation of system devices may continue to occur throughout the 30- CDRL 12-1 day settling period, but all devices must be installed and tested prior to the start of acceptance testing.

AGY-21-008-IT 274 | Page

APPENDIX 1

12.6 Acceptance Testing Acceptance testing will include a pilot and the System Acceptance Test (SAT). Both Phases of testing will be described in detail in an acceptance test plan developed jointly with the agency and delivered by the SI.

12.6.1 Pilot

Following the 30-day settling period, the agency will conduct a 90-day pilot for each project Phase with one or more stages using a limited and controlled user population to exercise all system functions, fare products, and policies. Pilot testing will be planned with the SI and included as part of the Master Program Schedule.

Assigned Req # Requirement CDRL 12.6.1-1 At least 90 calendar days prior to the scheduled start of the applicable CDRL 12-6 Phase’s pilot, the SI shall submit an acceptance test plan, developed jointly with the agency that includes the structure, timing, and measurement criteria for conducting and evaluating the pilot. 12.6.1-2 Each Phase’s pilot will not commence until the applicable Phase’s FIT has CDRL 12-6 been approved, the subsequent 30-day settling period has passed, and 100% of the applicable field equipment has been installed. 12.6.1-3 All test data will be purged from the system prior to the start of the pilot. CDRL 12-6 12.6.1-4 The SI shall commence reporting on all applicable system performance CDRL 12-6 requirements defined in Section 16 at the start of each Phase’s pilot. 12.6.1-5 Each Phase’s pilot will be designed to exercise all system functions, fare CDRL 12-6 products, and policies in a Phased approach. Successive Phases will not be undertaken until the previous Phase has been completed successfully. 12.6.1-6 Each Successive Phase’s pilot will be designed to validate that system CDRL 12-6 functions, fare products, and policies exercised in previously delivered Phases still function as expected. Any critical defect/failure found related to previous functionality will be recorded, and corrective actions taken prior to the completion of the pilot 12.6.1-7 The SI will be responsible for supporting all elements of each pilot, CDRL 12-6 including, but not limited to, system and equipment maintenance, media distribution, funds settlement, reporting, and customer support. 12.6.1-8 Performance testing such as load, stress, endurance, and spike will occur CDRL 12-6 during each 90-day pilot and will include at a minimum the successful processing of an equivalent of 22 days of transactions at projected peak volumes. Transaction volumes and how they will be generated will be detailed in the acceptance test plan.

AGY-21-008-IT 275 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.6.1-9 During each Phase’s pilot period, the agency and the SI shall meet no less CDRL 12-6 than two times per week to discuss progress, issues, and results. The SI shall provide written status reports against established measurement criteria. 12.6.1-10 Each pilot stage will undergo analysis, review, and approval of data CDRL 12-6 integrity and system performance by the agency before moving to the next pilot stage. All critical issues will be recorded, and corrective actions taken prior to the completion of the pilot. 12.6.1-11 If all Phases are completed successfully, the Phase’s pilot duration will be CDRL 12-6 no longer than 90 days. 12.6.1-12 Each Phase’s pilot will continue for its scheduled duration unless a critical CDRL 12-6 failure or failures cause suspension of the pilot (see Section 16.2.3.3). When a critical failure has been resolved, the pilot will resume for a duration determined by the agency, up to and including a full 90-day period.

12.6.2 System Acceptance Test

The start of System Acceptance Testing for each Phase, will designate the beginning of revenue service for the Phase’s applicable system components. The Phase’s warranty term (if hardware was delivered in the phase being tested) and SMA for all the Phase’s applicable system components (see Section 15.1 and Section 15.2) will also start at this time. The achievement of the start of System Acceptance Testing will be based upon the successful completion of the applicable Phase’s Pilot and is subject to written approval from the agency.

When a Phase’s pilot has been deemed complete by the agency, the SI shall commence the applicable Phase’s System Acceptance Test (SAT), which will verify that the system and all provided equipment meet the system performance requirements specified in Section 16 prior to Final Project Acceptance. If the SI is unable to successfully complete System Acceptance Testing in Phase 1 or Phase 2, the MTA reserves the right to remove subsequent Phases from the contract.

Assigned Req # Requirement CDRL 12.6.2-1 Each Phase’s SAT will commence upon the successful completion of the CDRL 12-6 applicable Phase’s pilot. 12.6.2-2 SAT will be performed in the production environment with all applicable CDRL 12-6 components, subsystems, and networks completely operational, online, and in service. 12.6.2-3 The SI shall submit any revisions necessary to the acceptance test plan as a CDRL 12-6 result of the pilot at least 10 calendar days prior to the commencement of the applicable Phase’s SAT for agency review and approval.

AGY-21-008-IT 276 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.6.2-4 Each Phase’s SAT will be comprised of three consecutive 30-day periods in CDRL 12-6 which all system components (including those delivered in previous Phases) must meet or exceed all performance requirements defined in Section 16. The acceptance test plan will describe in detail how the SI will measure and report on each of the performance requirements throughout SAT. 12.6.2-5 The level of system use during each SAT will be decided by the agency and CDRL 12-6 included in the acceptance test plan and may range from a group of friendly users to unrestricted public use. 12.6.2-6 The SI will be responsible for supporting all elements of SAT, including, but CDRL 12-6 not limited to, system and equipment maintenance, media distribution, funds settlement, reporting, and customer support. 12.6.2-7 If the applicable performance requirements defined in these specifications CDRL 12-6 are not attained during any one of the 30-day periods, the SAT will be extended a minimum of 90 days to allow for three consecutive 30-day periods in which the requirements are met. 12.6.2-8 The SI shall identify and implement remedial action at no cost to the CDRL 12-6 agency in the event that an applicable system component does not meet the specified performance requirements during SAT. 12.6.2-9 During each SAT, the agency and the SI shall meet no less than two (2) CDRL 12-6 times per week to discuss progress, issues, and results. The SI shall provide formal reports on system performance at the end of each 30-day period. 12.6.2-10 Periodically during each Phase’s SAT, the agency will audit the reports CDRL 12-6 generated by the system to confirm the accuracy and completeness of the information presented. All event records shall be reviewed and compared to known events such as door openings events, alarms, and power outages. 12.6.2-11 Within 10 business days following the completion of each Phase’s SAT, the CDRL 12-6 SI shall provide all testing data, reports, and other testing information to the agency for review and approval.

12.6.3 Final Project Acceptance

Achievement of Final Project Acceptance Milestone will be based upon the successful completion of all the Project Phases’ SAT and the delivery of all the Project’s contractually required work, equipment, and documentation, and is subject to written approval from the agency. The agency will issue a letter of acceptance upon approval of the SI’s request for the Final Project Acceptance.

AGY-21-008-IT 277 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 12.6.3-1 The SI shall submit a request for Final Project Acceptance upon completion CDRL 12-6 of the last Project Phase’s SAT and determination that all Project work has been completed in accordance with the Project’s specifications. 12.6.3-2 Final Project Acceptance will be contingent on satisfying all of the CDRL 12-6 following conditions of the implementation. The agency will grant Final Project Acceptance only when: • SAT for all Project Phases has been successfully completed and approved by the agency • All system devices are delivered, installed, and operational • All back-office systems and software, including all required reports, are installed and fully-functional • All websites are live and fully-functional • All spare parts have been delivered • All initial batches of fare media have been delivered and accepted by the agency • All contract deliverables have been delivered to the agency and accepted • All disaster recovery plans have been successfully demonstrated and approved by the agency • All training has been provided and accepted by the agency • All required intellectual property has been delivered to the agency or the escrow agent • All Final resolutions to all identified critical issues (as classified by the Failure Review Board) are fully implemented and accepted by the agency 12.6.3-3 Once all of the Project’s requirements have been met, the SI may submit a CDRL 12-6 formal request for Final Acceptance. The agency will respond to the request within 10 business days.

12.7 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 12-1 Inspection and Test Plan X X X 60 Calendar Days Prior to the Start of each project Phase’s testing CDRL 12-2 Inspection and Test Procedures X Minimum of 30 Calendar Days Prior to Each Test CDRL 12-3 Inspection and Test Reports X 10 Calendar Days Following Each Test

AGY-21-008-IT 278 | Page

APPENDIX 1

Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 12-4 Inspection and Test Waivers 60 calendar days prior to the start of each Phase’s Testing CDRL 12-5 Agency Test Facility Design X X X Required for Phase 1 with updates needed for all subsequent Phases CDRL 12-6 Acceptance Test Plan X 90 Calendar Days Prior to the Start of each Phase’s Pilot

13. Training Requirements 13.1 General Requirements Assigned Req # Requirement CDRL 13.1-1 The SI shall provide a comprehensive training program to educate and CDRL 13-1 train agency personnel in all details of the payment system, enabling them to properly operate, service, and maintain the system and each of its components throughout its useful life. 13.1-2 The SI shall provide three (3) rounds of training for each course outlined in CDRL 13-1 section 13.4, with one (1) round of training occurring for each Phase. As subsequent project Phases introduce new components and features the training and training courses will be updated to reflect these new features. A round of training is not considered complete until written acceptance of the completed training has been provided from the agency to the SI. 13.1-3 The SI shall deliver a training plan that proposes the training courses to be CDRL 13-1 delivered to the agency. The course curriculum will include all instruction of agency personnel. 13.1-4 The SI shall provide training to the following agency staff, at a minimum: IT CDRL 13-1 and finance professionals, supervisors, maintenance and repair personnel, auditors, planners, field operations and command center personnel, customer service and transit store personnel, managers, and trainers. 13.1-5 The SI shall develop and deliver train-the-trainer courses that provide CDRL 13-1 agency training instructors with the necessary instruction to deliver system training in the future without additional SI support. 13.1-6 The training program will include classroom training provided by the SI's CDRL 13-1 staff. The SI may supplement their training, as appropriate, by allowing OEM representatives to train agency staff on subassemblies and devices.

AGY-21-008-IT 279 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 13.1-7 The SI's training program will include formal and informal instruction with CDRL 13-1 working equipment, manuals, and diagrams as instructional tools. 13.1-8 The SI shall assume that the agency staff does not have knowledge of any CDRL 13-1 system features. However, the SI may assume that maintenance personnel have the basic skills pertinent to their crafts. 13.1-9 Course sizes will be designed to assure that all trainees have some level of CDRL 13-1 one-on-one training with equipment and software. 13.1-10 Courses will be limited to a maximum of eight (8) hours per day. CDRL 13-1 13.1-11 The SI shall provide device training units that enable students to receive CDRL 13-1 hands-on equipment operation and maintenance instruction while in a classroom setting. The training units will be powered by a standard 120V AC power source. 13.1-12 When appropriate, training will occur in the field or location of service. CDRL 13-1 13.1-13 The SI may use installed revenue equipment or spare parts as training aids CDRL 13-1 in lieu of mockups and for demonstration and for practical exercises in replacing, testing, disassembly, and assembly of equipment. However, the SI shall be responsible for ensuring that such parts are not damaged or modified in any way. 13.1-14 The agency will furnish the following training-related items upon SI CDRL 13-1 request: • Space for classroom lectures and practical training on equipment (location and class times will be set by the agency) • Projectors, screens, whiteboards, and similar equipment • Shop space as needed • Buses or stations with installed system equipment Requests shall be made at least two (2) weeks prior to the scheduled training. 13.1-15 The SI will provide video of all training sessions to the agency. CDRL 13-1 13.1-16 The SI shall provide records of the training provided on a weekly basis to CDRL 13-1 the agency. 13.1-17 All materials used in the training programs, such as training rigs, fare CDRL 13-1 media, manuals, simulators, and drawings, will become the property of the agency upon completion of the training.

AGY-21-008-IT 280 | Page

APPENDIX 1

13.2 Training Plan Assigned Req # Requirement CDRL 13.2-1 The SI shall develop and submit for agency approval a training plan that CDRL 13-1 documents the design of the program for training agency personnel and each course to be delivered. 13.2-2 The training plan will include at a minimum the following for each course: CDRL 13-1 • Identification and summary descriptions of the training course, including course lengths • The methods of training to be used • Learning objectives and outcomes • The sequence of activities • Targeted trainees for each course • Maximum number of trainees per course • Methods and criteria for evaluating performance, including an objective grading system to report the progress of trainees during the training • Resources required, such as equipment, shop space, video recorders, etc. A minimum of two (2) training sessions for each course will be provided. 13.2-3 A training schedule will be included in the SI’s training plan. The schedule CDRL 13-1 will consider the sequence of training, hours of instruction, trainee availability, limitations on course sizes, and venue for the training. 13.2-4 The training plan will address the SI’s approach for training agency trainers CDRL 13-1 to deliver training subsequent to the SI's involvement. It will describe the SI's approach, resources and hours required, and any training aids that might be included.

13.3 Training Materials Assigned Req # Requirement CDRL 13.3-1 The SI shall provide all necessary training materials for the delivery of each CDRL 13-2 course discussed in the training plan.

AGY-21-008-IT 281 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 13.3-2 At a minimum the following training materials will be provided by the SI: CDRL 13-2 • Course agenda and objectives • Resources and facilities required for the course • Detailed lesson plans or outlined presentations • Pre- and post-training assignments • Instructions for using any audiovisual support and equipment • Student discussion guides and handouts • All relevant manuals • Quick reference guides • Operational system equipment • Computer-based presentations 13.3-3 Training documentation will be separate from the operation and CDRL 13-2 maintenance manuals (see Section 13.5) but may reference those manuals. 13.3-4 The SI will provide hard copies of the training materials for all expected CDRL 13-2 attendees, plus five (5) spare copies. 13.3-5 Draft training materials will be submitted at FDR. Final training materials CDRL 13-2 will be submitted to the agency at least 30 calendar days before training classes are scheduled to begin. All documentation and training material will be submitted in an electronic form specified by the agency. 13.3-6 Training materials will be updated as required during the course of CDRL 13-2 instruction to reflect the installed system. 13.3-7 During the warranty and SMA terms (see Section 15), the SI shall provide CDRL 13-2 updated course instruction and materials resulting from any significant system hardware or software changes. 13.3-8 The agency reserves the right to edit and reproduce portions or all of the CDRL 13-2 training materials for internal use. If the SI produces an update or new training aids (e.g., video recordings, manuals, etc.) within two (2) years following the completion of the training, the agency will receive copies of the updated material at no cost for use in agency training programs.

13.4 Training Courses The SI shall provide the following training courses and provide all course content and training materials in an agency-approved format. The first round of all training listed below must be delivered and approved by the agency before the completion of the Phase 1 Pilot. Any additional features introduced in Phase 2 and Phase 3 will warrant the delivery of updated training courses that cover the impacted new components/features. Updated training will be delivered and approved by the agency before the completion of the applicable Phase’s Pilot.”

AGY-21-008-IT 282 | Page

APPENDIX 1

Field All agency maintenance personnel who may be required to perform scheduled Maintenance maintenance and support activities will attend a training course. This course and Servicing will provide the employee all knowledge necessary for operation, troubleshooting, maintenance, repair, component change-out, and scheduled maintenance of all field devices. Shop Repair A selection of mechanics and electricians, who will perform the periodic overhaul, remedial repair, and adjustment of system components, will be given a comprehensive instruction course in the operation, troubleshooting, maintenance, repair, and overhaul of the equipment. Operation, Supervisory personnel who will manage system equipment and service Configuration, technicians will receive specialized training in the operation, configuration, and and administration of the devices. This class will provide instruction on those Administration activities that are limited to the administrative and maintenance logins of the field equipment, as well as activities governing the configuration of the devices. Back-office Personnel who will use the back-office systems will be trained in the use of all User Training application programs and functions provided by the system. The SI shall structure this training as a series of logically arranged topics so that individual users may attend only those portions of the course that are of interest. This training will include at a minimum: • General back-office user procedures • Status monitoring functions • Device configuration parameters • Device management functions • Fare table management • Hotlist management • Media inventory management • Generation of all standard reports • Bankcard authorization operations and configuration • Backup data retrieval procedures • Interfaces with other systems Back-office Those management personnel who will perform accounting and financial Accounting management will receive specialized training in the use of the RMS and financial reporting. Using sample data created from testing or other sources, RMS data and reports will be generated from the system and used to explain the resulting output.

AGY-21-008-IT 283 | Page

APPENDIX 1

Back-office Systems personnel who will be responsible for administration and Administration maintenance will be trained in all aspects of system administration to ensure optimal performance, as well as correct minor system problems. Content will include at a minimum: • User administration • Networking configurations • Interfaces with other agency computer systems • Merchant acquirer interface Report and The SI shall instruct advanced users and administrators in the use of the Query reporting system, and data warehouse design and query generation, including Generation the use of the report writer tool. and Customization Support The SI shall provide training on the use, operation, and maintenance of all Systems and support systems and special tools. Special Tools Website The SI shall provide training on the website administrative functions. The Administration course will include at a minimum: • Discussion of the underlying website design and linking to other sites • Instruction on how to configure all pages of the website • Review of all procedures to modify database tables that affect website content • Demonstration on how to monitor the website status and operating conditions • CMS content updates Customer The SI shall provide customer service training on all aspects of the system Service that will be visible to and used by the public, and the tools that those agency Training staff will employ. The course will cover at a minimum: • All fare products, policies, and transaction types • CST functionality and user interfaces • CRM system functionality and user interfaces • Use of the customer website • General account management features and functions Fare Inspector The SI shall provide fare enforcement staff with training on all aspects of the Application fare enforcement solution including: Training • Reporting • Inspection level investigation and queries • Inspection application operation and field level troubleshooting • Distribution of mobile fare inspection application, updates and management of software on devices Hardware operation and field level troubleshooting

AGY-21-008-IT 284 | Page

APPENDIX 1

13.5 Manuals In addition to training materials and instruction, the SI shall provide instruction manuals on how to manage, operate, and maintain the entire fare system on an ongoing basis. The manuals will include detailed documentation for all equipment, systems, and software.

13.5.1 Manual Content and Format

Assigned Req # Requirement CDRL 13.5.1-1 Manuals will contain all text, step-by-step procedures, illustrations, CDRL 13-3 drawings, block diagrams, schematics, parts lists, troubleshooting guides, and repair and replacement procedures needed to allow the agency to operate, maintain, diagnose and repair all equipment and systems. 13.5.1-2 All manuals will be written in clear and concise English, will use English CDRL 13-3 and/or metric units of measurement, and will be written to assume the reader has no more than an 8th-grade education. 13.5.1-3 Care will be taken to provide easily understood explanations and step-by- CDRL 13-3 step instructions with cross-references to all drawings, diagrams, and photographs. 13.5.1-4 Block diagrams illustrated parts breakdowns, and schematic drawings will CDRL 13-3 be used to facilitate descriptions of assemblies and the relationships of components, subsystems, and systems. 13.5.1-5 Electrical wiring diagrams and other diagrams necessary for the operation CDRL 13-3 of the equipment will be provided. No single diagram will show more than one system or parts thereof, and diagrams will be complete and legible in all respects. 13.5.1-6 Device and software manuals will include the following content at a CDRL 13-3 minimum: • General field equipment familiarization material • Location, function, and operation of all controls, and indicators • Field equipment setup, login, and shutdown procedures • Symptoms, diagnostic methods, and procedures for isolating minor faults • Description of all user messages and enunciations 13.5.1-7 Manuals related to repair, maintenance, and installation will provide all CDRL 13-3 information needed for troubleshooting service failures, performing equipment and installations and replacements, and for performing preventative maintenance for each component, including general servicing, and inspecting.

AGY-21-008-IT 285 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 13.5.1-8 Manuals related to back-office operation and maintenance will be CDRL 13-3 presented in terms that are meaningful to users. They will include functional explanations and descriptions of each application program and its use. Step-by-step procedures will be provided that explain how each parameter is configured and the effects obtained by varying each parameter. All user guidance, alarms, and error messages will be described, along with the steps necessary for recovery from error. 13.5.1-9 Operating instructions will describe procedures to be followed as a result CDRL 13-3 of system restarts or failures. The documents will contain sufficient information to enable the user to restart or reconfigure the system and analyze diagnostic data dumps. 13.5.1-10 Disaster recovery procedures will be clearly specified in sufficient detail to CDRL 13-3 consider all possible scenarios. Recovery instructions will describe detailed procedures to be followed in the event that system recovery is needed. Detailed data backup and recovery procedures will be provided. 13.5.1-11 The SI shall submit an illustrated parts catalog including all installation CDRL 13-3 hardware, wiring assemblies, and LLRUs. Each listed part in the illustrated parts catalog will be referenced by the SI using an assigned part number and, where applicable, OEM part number. The illustrated parts catalog may be a subset of the maintenance materials. 13.5.1-12 All manuals will be submitted in hard copy and electronic format. At least CDRL 13-3 30 hard copies of each manual and will be delivered to satisfy the hard copy requirement. 13.5.1-13 Documentation provided in electronic file format will include: CDRL 13-3 • Manuals and illustrated parts catalogs will be provided in PDF format and in a modifiable electronic format (MS Word) • CAD files will be provided in PDF format • Schematic drawing will be provided in PDF format 13.5.1-14 Electronic files will be able to be deployed individually or hosted on a CDRL 13-3 server to allow multiple users to access the same data. Information will not be encrypted and will be developed and delivered using standard authoring tools such as MS Word, Excel, Visio, and PowerPoint, or Adobe Acrobat. 13.5.1-15 One complete set of documents will be provided to the agency 90 CDRL 13-3 calendar days prior to the start of acceptance testing. 13.5.1-16 Information gathered during installation and acceptance testing, and CDRL 13-3 throughout the warranty and SMA terms, will be incorporated into the manuals for submittal to the agency.

AGY-21-008-IT 286 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 13.5.1-17 Revisions to the manuals will be recorded on a control list in the front of CDRL 13-3 each document. The list will be issued with each revision and will show the date of each revision and the page reference. The SI shall maintain all updated lists for each document. The agency will review and comment on each manual submission as required. 13.5.1-18 Sensitive information that is not to be distributed to all departments will CDRL 13-3 be contained in a separate document marked “Confidential.” The nature of this information will be mutually agreed upon between the SI and agency.

13.5.2 Required Manuals

The following manuals will be required at a minimum. The complete set of documentation will be submitted by the SI and approved by the agency during design review. Additional manuals may be requested by the agency.

Device and Software Manuals Operating Instruction Manual Preventative Maintenance Manual Corrective / Field Maintenance Manual Shop Repair and Overhaul Manual Parts Manual Software and Programming Manual Software Source Code Manual User Quick Reference Guides Field Maintenance Quick Reference Guides OEM Manuals – As supplied Back-office Manuals Administrator’s Manual User’s Manual Pricing Engine, System Configuration, and Business Rule Management Manual Customer Relationship Management System Operations Manual System Monitoring and Management Application Operations Manual Revenue Management System Operations Manual Data Warehouse Design and Database Structure Manual

AGY-21-008-IT 287 | Page

APPENDIX 1

Device and Software Manuals Reporting System Operations Manual Software Source Code Manual OEM Manuals - As supplied API Manual – Structure, definitions Support System Manuals Operations and Maintenance Manual OEM Manuals - As supplied Website Manuals Customer Website Design and Administration Manual Institutional Website Design and Administration Manual Fare Inspection Manuals Fare Inspection Hardware Application Operation and Administration Manual Fare Inspection Mobile Application Operation and Administration Manual

13.6 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 13-1 Training Plan X X Will be delivered for each project Phase’s PDR and FDR CDRL 13-2 Training Materials X 30 calendar days prior to the start of each Phase’s Training CDRL 13-3 Manuals X X X 90 Calendar Days Prior to each Phase’s Acceptance Testing

14. Installation Requirements General requirements for installing hardware for the system (onboard, transit stores, and back-office).

AGY-21-008-IT 288 | Page

APPENDIX 1

14.1 General Requirements Assigned Req # Requirement CDRL 14.1-1 The SI shall supply all labor, supervision, and materials required for the CDRL 14-1 installation of all new equipment and systems delivered in accordance with these specifications. 14.1-2 The SI shall install and test all bus validators and driver displays on agency CDRL 14-1 vehicles. The SI shall provide and install all cabling and hardware necessary to properly install and secure the equipment in its planned location.

14.1-3 The SI’s installation of any equipment, will in no way interfere with or CDRL 14-1 degrade the operation of the Agency's current AFC system. Exceptions to this requirement must be requested in writing by the SI at least 60 days prior to the requested installation taking place and will be subject to agency approval. 14.1-4 The SI shall validate that all onboard SI installed equipment is working CDRL 14-1 properly with the agency’s existing mobile data routers. If issues are found, the SI will work with the agency to identify and correct any communication problems that exist. 14.1-5 The SI shall provide and install all mounting brackets, special hardware, CDRL 14-1 electrical and communication wiring, and service loops, and terminations/connections required to install all bus validators and driver displays onboard vehicles. 14.1-6 The SI shall install and test all TVMs, rail station operator consoles, and CDRL 14-1 faregates at agency metro stations. The agency will provide the necessary power at the device installation locations. The SI shall provide and install all required cabling and hardware necessary to properly install, secure, and activate the equipment in its planned location.

14.1-7 The SI shall be responsible for replacing all existing Ethernet runs from the CDRL 14-1 communication cabinets in each metro station to the install locations of all SI-provided equipment. The SI shall use CAT6 or better cabling for the Ethernet runs, and shall be responsible for any network hardware (e.g., network switches) necessary to connect the equipment at the installed locations. 14.1-8 The SI shall install and test all TVMs and platform validators at agency light CDRL 14-1 rail stations. The agency will provide the necessary power and communications at the device installation locations. The SI shall provide and install all required cabling and hardware necessary to properly install, secure, and activate the equipment in its planned location.

AGY-21-008-IT 289 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 14.1-9 The SI shall provide and install all TVM, platform validator, rail station CDRL 14-1 operator console, and faregate mounting hardware and support structures, such as pedestals, stainless steel mounting poles, and mounting brackets, as needed. Use of mounting pedestals or stanchions to support validators, consoles, faregates, and TVMs will be subject to agency review and approval. 14.1-10 The SI shall install and test all customer service terminals at agency ticket CDRL 14-1 offices and designated satellite locations. The agency will provide the necessary power and communications at the device installation locations. The SI shall provide and install all required cabling and hardware necessary to properly install and secure the equipment in its planned location. 14.1-11 The SI shall install and all mobile fare inspection devices and mobile fare CDRL 14-1 validation devices at designated agency locations. The agency will provide the necessary power and communications at the device installation locations. The SI shall provide and install all required cabling and hardware necessary to properly install and secure the equipment in its planned location. 14.1-12 The SI shall install, configure, and test all equipment, back-office systems, CDRL 14-1 and other necessary hardware and software for the agency’s onsite test facility (see Section 12.3) at a location designated by the agency. The agency will provide the necessary power, communications, and rack space at the installation location. The SI shall provide and install all required cabling and hardware necessary to properly install and secure the test equipment in its planned location. 14.1-13 A commissioning test will be performed for each installation and may be CDRL 14-1 witnessed by the agency. Detailed test results will be recorded to show that each device and system has been inspected and tested in accordance with these specifications and submitted to the agency for review and approval. 14.1-14 The SI shall match the existing floor during the installation of new CDRL 14-1 faregates and TVMs, where necessary. 14.1-15 The SI shall be responsible for the removal and relocation of existing metal CDRL 14-1 handrails currently located near faregates, if required during the installation of the new faregates.

AGY-21-008-IT 290 | Page

APPENDIX 1

14.2 Installation Plan Assigned Req # Requirement CDRL 14.2-1 The SI shall provide a detailed installation plan for agency review and CDRL 14-1 approval at each Phase’s FDR, and a final version no later than 120 calendar days prior to the first delivery of equipment. 14.2-2 The installation plan will describe all aspects of device and system CDRL 14-1 installation for each Phase of the implementation, including but not limited to, site and vehicle surveys, antenna testing, prototype installations, site preparation, pre-wiring, equipment, and vehicle staging, production installation, quality assurance and control, scheduling, and storage/disposal of removed equipment according to local and EPA regulations. It will also detail the installation and configuration of all software systems, including the back-office, systems, interfaces and web applications, and their respective schedules. 14.2-3 In the install plan, the SI shall provide the power and communication CDRL 14-1 requirements for each piece of equipment and at each install location. The communication requirements will include a description of the networking equipment necessary at all bus yards and rail stations to connect the SI devices to the agency-provided fiber backbone. These requirements may be revised and submitted to the agency following completion of the site surveys (see Section 14.3). 14.2-4 The installation plan will include, but is not limited to: CDRL 14-1 • Bus Validators • Bus Validator mounting hardware • Driver displays • Driver display mounting hardware • Ticket Vending Machines (if option exercised) • Rail Station Operator Consoles • Platform Validators • Faregates • Customer Service Terminals • Mobile Fare Inspection Devices • Mobile Fare Validation Devices (if option exercised) • Back-office hardware, including redundant system hardware • Back-office applications and databases • Web applications • Mobile Application (if option exercised) • System interfaces and API configuration • Test environment hardware and devices • Spare parts • Support equipment • Smartcard media

AGY-21-008-IT 291 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 14.2-5 The installation plan will include patron routing and traffic flow patterns CDRL 14-1 around work areas during faregate construction. Patron routing will be developed in collaboration with the MTA.

14.3 Site Surveys Assigned Req # Requirement CDRL 14.3-1 The SI shall perform detailed site surveys for all vehicle types, and CDRL 14-1 equipment and back-office install locations, including rail stations, bus stops, retailers, and other agency locations to identify installation requirements and any existing provisions that may be used to support installation. 14.3-2 Initial vehicle and rail station surveys will be completed as a part of the CDRL 14-1 design review process. As part of each Phase’s FDR, the SI shall submit the installation details and specifications for all equipment installations for agency for review and approval. 14.3-3 The SI shall identify all communication requirements at bus and rail sites, CDRL 14-1 including a description of all networking equipment necessary to connect the SI devices to the agency-provided fiber backbone. Agency facilities that will house networking equipment will be identified during design review. 14.3-4 Prior to the rail installation, the SI shall identify any modifications or CDRL 14-1 additional provisions needed for installation of the system equipment and related system components but shall work as much as possible within the limits of station design. All modifications will be subject to agency approval.

14.4 Prototype Installations Assigned Req # Requirement CDRL 14.4-1 The SI shall perform a prototype installation of the field devices in each of CDRL 14-1 the different field environments in which the equipment will be installed, including a prototype installation of all bus equipment for each vehicle type. 14.4-2 The prototype installations for each vehicle type in the bus fleet will help CDRL 14-1 determine the appropriate mounting locations for each piece of equipment, and any mounting bracket requirements not identified during the site surveys.

AGY-21-008-IT 292 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 14.4-3 The bus validators and driver displays will be mounted and positioned CDRL 14-1 such that they minimize encroachment on passengers, and do not obstruct the driver’s field of vision, including the view of the front door. The prototype installation results will be documented and submitted to the agency for review and approval. 14.4-4 The prototype installations will be subjected to at least one (1) week of CDRL 14-1 service to ensure the robustness and integrity of the installation design. 14.4-5 All prototype installations are subject to agency review and approval CDRL 14-1 before installation in other locations will be permitted.

14.5 Onsite Work Requirements Assigned Req # Requirement CDRL 14.5-1 All SI and subcontractor employees working within operating rail stations, CDRL 14-1 platforms, rights-of-way, and bus divisions will comply with applicable rail and bus operations rules and procedures, including safety rules and regulations. All onsite personnel engaged in installation activities shall attend agency safety training and briefing sessions before working on site. 14.5-2 The SI shall deliver and execute a safety access plan for all onsite work. CDRL 14-1 Such safe access will be afforded to construction equipment, vehicles, and personnel in accordance with agency policies and OSHA regulations. All access plans will be subject to review and approval by the agency. 14.5-3 The SI shall comply with and be responsible for all regulatory CDRL 14-1 requirements applicable to design, construction, installation, and testing, including the application and granting of all applicable permits. 14.5-4 If any work is to be performed within fifty (50) feet of the railroad tracks CDRL 14-1 the SI will procure and provide proof of Railroad Insurance. The SI will also be responsible for completing all required Railroad Training before any work within fifty (50) feet of the tracks begins.

14.6 Installation Procedures Assigned Req # Requirement CDRL 14.6-1 The SI installation procedures will be in accordance with the approved CDRL 14-2 installation plan and agency rules and guidelines. 14.6-2 The SI shall provide a proposed schedule for back-office and system CDRL 14-2 equipment installation and configuration.

AGY-21-008-IT 293 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 14.6-3 The SI’s proposed installation methodology will seek to maximize the CDRL 14-2 efficiency with which the installation is performed while minimizing the impact on transit operations. 14.6-4 Any holes that must be created in bus vehicles that extend into bus CDRL 14-2 flooring or through vehicle exterior will be sealed using wiring grommets to the satisfaction of the agency. 14.6-5 Any damage to rail stations or bus facilities as a result of the TVM, CDRL 14-2 platform validator, or faregate installations will be repaired by the SI at its expense. Any holes that must be created will be sealed to the satisfaction of the agency.

14.7 Shop and As-Built Drawings Assigned Req # Requirement CDRL 14.7-1 The SI shall submit shop drawings used in its manufacturing facility, CDRL 14-3 assembly facility, or shop to fabricate, assemble, and/or install parts of the system, whether manufactured from raw materials or purchased from others in a ready-to-use condition. Shop drawings and their projected delivery dates should be noted on the master program schedule. 14.7-2 Shop drawings will be signed by and bear the seal of a Maryland licensed CDRL 14-3 Professional Engineer where appropriate. 14.7-3 Shop drawings will be submitted in a format designated by the agency no CDRL 14-3 less than 45 calendar days prior to the start of installation for agency review and approval. 14.7-4 The SI shall revise and resubmit drawings that have been reviewed by the CDRL 14-3 agency and marked "Disapproved" or “Unacceptable for Evaluation”. No work indicated by any shop drawings will be commenced until drawings have been marked as "Approved" or “Approved as Noted.” 14.7-5 The SI shall document each device installation in the form of an as-built CDRL 14-4 drawing. The as-built documentation will identify equipment location information, wiring traces, and all additional information needed to maintain the newly installed infrastructure. 14.7-6 For each vehicle type on which system equipment is installed, the SI will CDRL 14-4 supply as-built drawings showing the routing of all wires and the method and location of all device mounting installations. As necessary, these drawings may include digital photographs of sufficient detail and clarity to convey the necessary information.

AGY-21-008-IT 294 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 14.7-7 All drawings will contain dimensions, physical details, connections, and CDRL 14-4 other information pertinent to system diagnostics, maintenance, and troubleshooting. 14.7-8 The SI shall submit for each set of as-built drawings the following no later CDRL 14-4 than 30 calendar days following each equipment installation: • One (1) copy on electronic media, in a format approved by the agency • Thirty (30) reproducible CAD-generated hardcopies Drawings will reside in the document control system as specified. 14.7-9 A master index of drawings will be submitted that clearly indicates the CDRL 14-5 organization of the shop and as-built drawings, listed by drawing number. The master drawing index will also provide cross-references to related drawings and will indicate the hierarchy of all drawings and drawing layers.

14.8 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 14-1 Installation Plan X 120 Calendar Days Prior to each project Phase’s Equipment Delivery CDRL 14-2 Installation Procedures X Will be delivered for each project Phase’s FDR CDRL 14-3 Shop Drawings 45 Calendar Days Prior to any component’s Start of Installation CDRL 14-4 As-Built Drawings 30 Calendar Days Following Each Installation CDRL 14-5 Master Index of Drawings With Submittal of Each Drawing

15. System Operations Requirements Prior to the successful completion of required training, and the granting of Final Acceptance for the applicable part of the system, the SI shall retain full responsibility for operations and maintenance of the system. Following Final Acceptance for the applicable part of the system, the SI will retain some operations and maintenance responsibilities under the warranty and operations and maintenance agreements described in this section.

Within “Section 8.0 Operations and Maintenance Support” of the pricing sheet, each individual Phase of the project requires individual pricing for the Annual Software Maintenance Agreement (SMA) and

AGY-21-008-IT 295 | Page

APPENDIX 1

Annual Back-office Operations Agreements (BOA). This allows the SI to accurately capture incremental operations and maintenance cost increases as additional systems and functionality are added within each new Phase. Furthermore, while maintaining an on-time schedule is critically important, in the unlikely event the project is delayed by the MTA, the pricing sheet includes an annual escalation rate for the SMA and BOA to allow the SI to cover any potential increased costs from an agency-driven schedule delay of 12 months or more.

A 12-year base contract for System Operations is planned for all back-office support. The operations and maintenance responsibilities not covered by the warranty and operations and maintenance agreements described in this section will be performed by the agency or contractors starting at Final Acceptance for the applicable part of the system. Agency- and SI-performed operations and maintenance responsibilities are as follows:

Equipment, Software or System MTA Hybrid Notes/Actions Systems Integrator

Call Center Operations X MTA will operate

In-Person Customer Service X MTA will operate

Financial Management X MTA will operate Institutional Partner X MTA will operate Management MTA will outsource to future 3rd Retail Network X party Rail Faregate Maintenance X MTA will perform maintenance Rail Station Operator Console X MTA will perform maintenance Maintenance Station Agent Terminal X MTA will perform maintenance Equipment Stand-Alone Validator (Light X MTA will perform maintenance Rail) Maintenance Rail Communications X MTA will perform maintenance infrastructure Maintenance Operator Display Unit X MTA will perform maintenance Maintenance Bus Onboard Validator X MTA will perform maintenance Maintenance Mobile Data Router X MTA will perform maintenance Maintenance MTA will perform equipment Bus Communications X maintenance and cellular services Infrastructure Maintenance contract Payment Processor X MTA will manage maintenance Maintenance

AGY-21-008-IT 296 | Page

APPENDIX 1

Equipment, Software or System MTA Hybrid Notes/Actions Systems Integrator

Fare Inspection Device X SI will perform maintenance Maintenance Customer Service Terminal/Point of Sale (POS) X SI will perform maintenance machine Maintenance IVR Hosting and Maintenance X SI will perform maintenance Central System Hosting and X SI will perform maintenance Maintenance Data Warehouse Maintenance X SI will perform maintenance Reporting System/Tool X SI will perform maintenance Maintenance Test Environment Maintenance X SI will perform maintenance Fare Media Inventory System X SI will perform maintenance Maintenance Institutional Website X SI will perform maintenance Maintenance Consumer Website X SI will perform maintenance Maintenance System Monitoring System X SI will perform maintenance Maintenance Customer Relationship Management System X SI will perform maintenance Maintenance Financial Management System X SI will perform maintenance Maintenance Primary Back-office X SI will perform maintenance Maintenance Agreement Mobile Application Hosting X SI will perform maintenance Maintenance MTA will perform equipment Test Lab Maintenance X maintenance; SI will perform software maintenance MTA will perform equipment Ticket Vending Machine X maintenance; SI will perform Maintenance software maintenance

In order to facilitate a smooth transition of these responsibilities and transition of the SI-performed operations and maintenance responsibilities at the end of the agreements, agency personnel will shadow the SI’s personnel during system testing, and throughout the operations and maintenance agreements. Exhibit 15-1 shows the timeline for the operations and maintenance agreements.

AGY-21-008-IT 297 | Page

APPENDIX 1

Exhibit 15-1 Operations and Maintenance Agreement Timeline

The timing shown in Exhibit 15-1 is for demonstration purposes only. All project phasing is described in detail in Section 1.2.

15.1 Warranty Req # Requirement Assigned CDRL 15.1-1 The SI shall provide a minimum one (1) year warranty that begins after CDRL 15-1 completion of each applicable Phase’s 90-day Pilot approval. The SI shall clearly indicate warranty duration provided in the proposal. 15.1-2 The Phase 1 warranty will include equipment and installation delivered in CDRL 15-1 Phase 1: • Account-based back-office hardware and sub-components • Bus Validators • Bus Operator Displays • Platform Validators • Installed Faregates as part of Phase 1 • Rail Station Agent Consoles • Customer Service Terminals • Mobile Fare Inspection Devices 15.1-3 The Phase 2 warranty will include all equipment and installation delivered CDRL 15-1 in Phase 2: • Ticket Vending Machines (if option exercised) • Remaining faregates installed as part of Phase 2 15.1-4 The SI shall warrant that all of the equipment, computer systems, and CDRL 15-1 software provided for the system, including those components warrantied by third-party suppliers, will be free from defects in operation, material, and workmanship under normal operating use. Remedial work to correct deficiencies will include the repair or replacement of equipment, components, devices, and/or materials.

AGY-21-008-IT 298 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.1-5 The warranty will cover the following: CDRL 15-1 • Repair or replacement of all equipment or systems required as a result of an identified hardware defect • Software updates or re-writes required to repair all identified software defects or bugs, and apply all necessary patches or security updates released by the SI or third-party software providers throughout the term of the warranty • All labor associated with hardware and software testing and deployment, both in the lab and field environments, needed to support warranty activities 15.1-6 All software maintenance performed under the warranty will comply with CDRL 15-1 the software maintenance requirements in Section 15.4. 15.1-7 The SI shall provide a new component or subsystem if a particular CDRL 15-1 component or subsystem was repaired or replaced three (3) times for the same failure. 15.1-8 If during the warranty term, the rate of failure of any component or device CDRL 15-1 exceeds 10% of the mean quantity installed, a “fleet defect” will be declared, and the entire quantity of such components or devices will be considered defective. 15.1-9 If a fleet defect is declared, the SI shall undertake and complete a CDRL 15-1 corrective work program to replace all components of that type with new (not refurbished) components. The repair schedule and procedures will be subject to agency review and approval. All items replaced under these terms shall be warranted for at least one (1) year after replacement. 15.1-10 A fleet defect will be considered resolved when the installed components CDRL 15-1 are determined to meet or exceed all of the KPI requirements, and upon agency approval. 15.1-11 The SI shall be responsible for all personnel, labor, tools, materials, CDRL 15-1 shipping charges, and other costs associated with the repair or replacement of components and/or subsystems throughout the warranty term. 15.1-12 Any system component repaired or replaced under terms of warranty will CDRL 15-1 be warrantied for at least six (6) months, or the remaining duration of the original warranty, whichever is longer. 15.1-13 Following the completion of the warranty term, should there be warranty CDRL 15-1 work to complete, the warranty will be extended to provide equal coverage for each piece of equipment.

AGY-21-008-IT 299 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.1-14 The warranty will not apply to any equipment that has been damaged by CDRL 15-1 any person other than the SI or SI’s assignee. Environmental conditions described in these technical specifications will be considered normal operating conditions for this system and shall not qualify for exclusion. 15.1-15 The agency will operate and maintain the equipment and software in CDRL 15-1 accordance with the SI’s specific instructions in order to maintain this warranty. The agency will be held blameless if the SI has provided inadequate or inaccurate training, and/or incomplete operating manuals, maintenance manuals, electrical and electronic schematics, mechanical diagrams, or software documentation. 15.1-16 In the event the SI fails to comply promptly with warranty requirements, CDRL 15-1 the agency will, upon written notice to the SI, have the right to deduct the cost of the agency’s prevailing labor and material costs for repairing a defect from any compensation due, or coming due, to the SI. In the event the SI has been paid in full, the SI shall agree to compensate the agency for the costs incurred. 15.1-17 Spare modules used by the SI during the warranty term will be replaced. CDRL 15-1 The SI shall maintain sufficient spare sub-assemblies, modules, and components to meet the system availability requirements through the conclusion of the warranty. 15.1-18 The SI shall follow proper agency security procedures for gaining access to CDRL 15-1 field equipment and facilities and shall not engage in such procedures without having received agency-provided training. The SI shall not modify or repair any equipment in revenue service without the approval of the project manager or an agency-authorized representative. 15.1-19 During the entire warranty term, all repairs, adjustments, or replacements CDRL 15-1 of equipment by the SI shall be documented by the SI within an agency- provided maintenance management system at the completion of every day. 15.1-20 The SI shall develop a warranty plan outlining processes and procedures to CDRL 15-1 be implemented to meet all specified warranty requirements. A draft of the warranty plan will be submitted at FDR and a final version will be provided a minimum of 90 calendar days prior to the start of any warranty term.

AGY-21-008-IT 300 | Page

APPENDIX 1

15.2 Software Maintenance Agreement Req # Requirement Assigned CDRL 15.2-1 The Software Maintenance Agreement (SMA) will commence upon CDRL 15-2 completion of each applicable Phase’s Pilot approval. Prior to the start of any of the SMAs, all software maintenance activities shall be covered by the SI. 15.2-2 The SMA will provide a complete system software maintenance for CDRL 15-2 twelve (12) years. 15.2-3 After successful completion of each applicable Phase’s 90-day Pilot, the CDRL 15-2 SI will provide software maintenance for the components delivered with each applicable Phase. The duration of each Phase’s SMA will align with the Phase 1 twelve (12)-year agreement. Thus, the agreements for each Phase will all end at the same time. Prior to the start of any agreement, all activities shall be covered by the SI. 15.2-4 The software maintenance agreements will cover the following: CDRL 15-2 • Software updates or re-writes required to fix all identified software defects or bugs throughout the term of the agreement • Application of all necessary patches or security updates released by the SI or third-party software providers • All software testing and deployment, both in the lab and field environments, needed to support these activities 15.2-5 All software maintenance performed under the SMAs will comply with CDRL 15-2 the software maintenance requirements in Section 15.4. 15.2-6 Software to be maintained under the SMAs will include all required CDRL 15-2 updates to the APIs and associated specifications provided by the SI. 15.2-7 During the term where an SMA is in effect, the SI shall update training CDRL 15-2 course materials and manuals as needed to reflect software changes performed under the agreement. 15.2-8 All third-party software will be maintained at the most current or CDRL 15-2 previous version at no additional charge throughout the term of the applicable SMA, so long as it does not involve a major rewrite of the SI’s software. 15.2-9 The SI and the agency shall agree on an appropriate course of action if CDRL 15-2 a third-party software provider goes out of business, or if maintenance updates for third-party software degrades the performance of the SI’s system.

AGY-21-008-IT 301 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.2-10 Throughout the SMA terms, the SI shall document all equipment CDRL 15-2 repairs, adjustments, or replacements within an agency-provided maintenance management system, Maximo, by the end of each day. 15.2-11 Throughout the terms of the SMAs, the SI will meet the associated CDRL 15-2 system performance requirements (e.g., device reliability and accuracy) specified in Section 16. 15.2-12 Failure to meet the specified requirements will result in deductions CDRL 15-2 from the monthly SMA payments made to the SI. Deductions will be based on the level of performance, and impacted by persistent failures, as specified in Section 16. 15.2-13 The SI shall submit a Software Maintenance Plan for review and CDRL 15-2 approval identifying the approach to meeting the requirements of the applicable SMA.

15.3 Back-Office Operations Requirements 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 and report on system performance and health and support immediate downtime issue resolution 24 hours a day/365 days a year ensure timely and accurate processing of transactions, oversee the 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 maintains up‐to‐date system patching and configuration.

Req # Requirement Assigned CDRL 15.3-1 The SI shall be responsible for performing all back-office operations and CDRL 15-3 support throughout the term of the back-office operations agreement. 15.3-2 The SI shall provide a back-office operations agreement for twelve (12) CDRL 15-3 years following the approval of Phase 1’s 90-day Pilot. 15.3-3 After successful completion of each applicable Phase’s 90-day Pilot, the SI CDRL 15-3 will provide back-office operations for the components delivered with each applicable Phase. The duration of each Phase’s agreement will align with the Phase 1 twelve (12)-year agreement. Thus, the agreements for each Phase will all end at the same time. Prior to the start of any agreement, all activities shall be covered by the SI.

AGY-21-008-IT 302 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.3-4 Under the back-office operations agreements for each applicable Phase,, CDRL 15-3 the SI shall be responsible for the following activities: • Monitoring system performance and health • Ensuring timely and accurate processing of transactions • Overseeing the operation of all back-office support systems (e.g., CRM and financial management systems) • Overseeing website operation, and providing content updates upon request from the agency • Overseeing mobile application operation and providing content updates required by the agency to improve accuracy, responsiveness, and end-user usability • Maintaining system configuration, and making configuration changes upon request from the agency • Testing and deployment of website and configuration changes • Supporting report updates and ad-hoc data requests 15.3-5 The SI shall be responsible for agency-specified customer and institutional CDRL 15-3 website content and operation updates no less than quarterly. Updates to the welcome pages to provide critical customer updates and alerts will be supported on an ad-hoc basis. 15.3-6 The SI shall be responsible for agency-specified system and fare CDRL 15-3 configuration updates, including updates to all device and system configuration parameters defined in these specifications, and fare table and configuration updates to support all fare structure elements specified in Section 6. Configuration updates will be supported no less than quarterly. Ad-hoc updates to system configuration and fare pricing will be supported to resolve system issues and accommodate special events. 15.3-7 The SI shall be responsible for updates to the SI-provided reports no less CDRL 15-3 than quarterly. Data warehouse queries will be developed and executed on an ad-hoc basis to support agency data requests. 15.3-8 The SI’s lead engineer will continue in a full-time operations and CDRL 15-3 maintenance services role throughout the term of the back-office operations agreement. The SI may propose an alternate to fill the primary operations management role, subject to agency approval, and may elect to have additional onsite staff as needed to meet the requirements of the back-office operations agreement. 15.3-10 The SI shall allow agency staff to shadow all back-office operations and CDRL 15-3 support activities throughout the back-office operations agreement. 15.3-11 Throughout the term of the back-office operations agreement, the SI will CDRL 15-3 meet the associated system performance requirements (e.g., back-office accuracy, availability, and server authorization rate) specified in Section 16.

AGY-21-008-IT 303 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.3-12 Failure to meet the specified requirements will result in deductions from CDRL 15-3 the monthly back-office operations payments made to the SI. Deductions will be based on the level of performance, and impacted by persistent failures, as specified in Section 16. 15.3-13 The SI shall develop a back-office operations plan and operating CDRL 15-3 procedures outlining the processes and procedures to be implemented in order to meet all specified back-office operations requirements. A draft of the back-office operations plan will be submitted at FDR and a final version will be provided a minimum of 90 days prior to the start of the back-office operations agreement term. 15.3-14 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. 15.3-15 The SI will provide mobile application support for all applications delivered as part of the new fare system. This includes: • Inspection Application • Validation Application • Fare Payment and Account Management Application (if Option is exercised) 15.3-16 Mobile application back-office operations that may be separate from the back-office (e.g., mobile application information available through app stores or other app management and monitoring system) will be the responsibility of the SI and may include: • Monitoring system performance and health • Mobile App operation, and updates to meet app store requirements, design guidelines and best practices • Testing and deployment of app updates and configuration changes • Supporting report updates and ad-hoc data requests

15.4 Software Maintenance Requirements During the specified term of the warranty and SMA, and during any optional extensions exercised by the agency, the SI shall provide software and firmware maintenance services described in this section. When referred to in this section, the term software is understood to include all software and firmware provided by the SI and third-party suppliers under contract with the SI.

15.4.1 General Requirements

Software maintenance will include custom software updates, third-party device firmware updates, database software updates, operating system updates, API updates maintenance and updates, antivirus updates, license renewal, and other activities needed to maintain system operations and meet the performance standards set forth in these specifications.

AGY-21-008-IT 304 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.4.1-1 The SI shall provide preventative and corrective software maintenance to CDRL 15-2 support system operations while meeting the performance standards set forth in these specifications. 15.4.1-2 Performance of software maintenance activities will be completed in a CDRL 15-2 manner that does not disrupt or degrade system operations, to the fullest extent possible. 15.4.1-3 The SI shall make corrections and modifications to the system software in CDRL 15-2 coordination with the agency staff. Serious issues (e.g., any error which causes system reliability or availability to fall below stated requirements) will be investigated immediately and adhere to the 16.2.3.3-3 Failure Severity requirements. 15.4.1-4 Software and firmware updates will be clearly documented and submitted CDRL 15-2 in advance of deployment for agency review and approval. 15.4.1-5 Software and firmware deployment will be scheduled and planned with CDRL 15-2 the agency. Advance notification will be provided, and approval granted by the agency, for all software maintenance activities requiring interruption of service or system operations. 15.4.1-6 As standard practice when repairing deficiencies and releasing device or CDRL 15-2 back-office system fixes or upgrades, the SI shall prepare and run regression testing scripts to test that each build delivered to the test environment does not result in any issues with the devices and systems currently in operation, including those that are not being updated. Any regression issues will be documented as deficiencies and resolved accordingly. 15.4.1-7 If the agency deems the condition requiring correction affects the CDRL 15-2 operation of other system components, then the SI shall provide repair or replacement of the system components that fail, regardless of whether the warranty term has expired for those components. 15.4.1-8 The SI shall keep all software environments (training, test, development, CDRL 15-2 staging, and production) at the same configuration and patch level as appropriate. 15.4.1-9 The SI shall update the agency test facility throughout the warranty and CDRL 15-2 SMA terms to maintain a fully mirrored environment of SI’s test facility. 15.4.1-10 SI shall maintain a change log of all changes that are performed and CDRL 15-2 provide this changelog to the agency on a mutually agreed-upon schedule. The changelog must be sufficiently detailed to allow the agency to determine when any feature was added or modified, and the scope of the change.

AGY-21-008-IT 305 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.4.1-11 Software must be upgraded to support the latest Windows Server and CDRL 15-2 Client software no more than 2 years from the date of release and must be updated no later than 1yr prior to the end of support, at no additional cost to the agency.

15.4.2 Communication, Response, and Resolution

Req # Requirement Assigned CDRL 15.4.2-1 The SI shall provide technical support to the agency for the general use CDRL 15-2 and operation of the software via telephone throughout the warranty and SMA terms. Telephone support will be provided by the SI during normal business hours (8 a.m. to 5 p.m. Eastern Time), Monday through Friday, excluding holidays. 15.4.2-2 The SI shall provide a phone number and e-mail account for the reporting CDRL 15-2 of software defects or malfunctions, and system outages, 24 hours a day, seven (7) days a week. 15.4.2-3 During the warranty and SMA terms, the SI shall respond to reports of CDRL 15-2 system outages within 15 minutes of notification, 24 hours a day, seven (7) days a week. A fully qualified service representative will be onsite within 24 hours after being contacted by agency staff if it is determined that a physical presence is needed to resolve the identified issue. 15.4.2-4 During the warranty and SMA terms, the SI shall respond to a report of CDRL 15-2 any software defect or malfunction within two (2) hours of notification. A fully qualified service representative will be onsite within 24 hours after being contacted by agency staff if it is determined that a physical presence is needed to resolve the identified issue. 15.4.2-5 The SI shall make every attempt to fix software problems impacting CDRL 15-2 revenue collection within three (3) hours of being reported. 15.4.2-6 If the software problem impacts revenue collection, but the repair will CDRL 15-2 take longer than three (3) hours, the SI shall report the cause of the problem as soon as it becomes evident, and provide status reports at least every four (4) hours thereafter, until the problem is corrected or a workaround is established. 15.4.2-7 The SI shall submit to the agency no less than monthly a bulletin setting CDRL 15-2 forth planned modifications and updates to the software, upgrade schedules, and a calendar of key dates for system changes for the coming three months and beyond.

AGY-21-008-IT 306 | Page

APPENDIX 1

15.4.3 Software Change Management

Req # Requirement Assigned CDRL 15.4.3-1 The SI shall support software change management meetings no less than CDRL 15-2 monthly throughout warranty and SMA terms, either in person or via phone. 15.4.3-2 The SI shall track and maintain a list of software maintenance issues and CDRL 15-2 open items. The SI shall distribute the list to the agency in advance of each monthly meeting. 15.4.3-3 The SI shall notify the agency whenever corrections, modifications, or CDRL 15-2 revisions of system software are available, and in advance of deployment. 15.4.3-4 Without releasing the SI from its obligations under the warranty and SMA, CDRL 15-2 the agency has the right to refuse to install any updates, at their sole discretion. 15.4.3-5 All changes to any delivered and installed part of the system must comply CDRL 15-2 with the mutually agreed upon change request and software deployment procedures defined in the SI’s Project Management Plan (see Section 3.3.3).

15.4.4 Software Enhancements

Req # Requirement Assigned CDRL 15.4.4-1 Enhancements include modifications to the software that add capabilities CDRL 15-2 and improve or change software functions that are not modifiable using the system configuration parameters defined in these specifications. 15.4.4-2 The SI shall provide to the agency all support required to develop and CDRL 15-2 deploy such enhancements at the SI's labor rates specified in the price schedule.

15.5 Equipment Repair and Replacement Following each applicable Phases’ Final Acceptance, and completion of the Phase 1 and Phase 2 maintenance agreement, all equipment maintenance, including field and shop repair, will be performed by the agency. The SI shall facilitate the procurement of all components and supplies necessary to support maintenance activities.

AGY-21-008-IT 307 | Page

APPENDIX 1

Req # Requirement Assigned CDRL 15.5-1 Spare devices and modules used by the SI for all maintenance activities CDRL 15-5 performed prior to Final Acceptance, as well as during the warranty, will be replaced with brand new equipment a maximum of 14 calendar days after use. 15.5-2 The SI shall provide instructions and pricing for the purchase of CDRL 15-5 replacement devices and modules for all SI-supplied equipment, including but not limited to: • Bus Validators • Platform Validators • Driver Displays • Ticket Vending Machines (and all modules) • Faregates (and all modules) • Station Agent Terminal Equipment • Customer Service Terminals (and all peripherals) • Mobile Devices • Handheld Fare Inspection devices The purchase of replacement equipment may be through the SI or OEM, and pricing may be provided for repaired or refurbished equipment, in addition to new equipment. 15.5-3 The SI shall provide a recommended list of spare modules and parts to CDRL 15-6 support the installed fleet at completion of SAT. Recommended quantities will be provided based on expected usage. 15.5-4 The SI shall provide a recommended list of consumables at completion of CDRL 15-7 SAT to support system operations for one year. Consumables are items that have a limited life cycle due to constant use and are expected to be replaced on a frequent basis, such as bulbs, fuses, and receipt paper. Recommended quantities will be provided based on expected usage. 15.5-5 The SI shall provide a list of special tools needed to maintain the fare CDRL 15-8 payment system at completion of SAT. Special tools are defined as special diagnostic tools and equipment that is not readily available from commercial sources. The SI shall provide sufficient documentation to allow the agency to manufacture these tools.

15.6 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 15-1 Warranty Plan X 90 Calendar Days Prior to the Start of each phase’s Warranty

AGY-21-008-IT 308 | Page

APPENDIX 1

Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 15-2 Software Maintenance Plan X X Will be delivered for each project Phase’s PDR and FDR CDRL 15-3 Back-office Operations Plan X 90 Calendar Days Prior to the Start of BO Ops CDRL 15-4 Spare Device and Module X X X During each Phase’s design Replacement Plan reviews CDRL 15-5 Spares List At Completion of each Phase’s SAT CDRL 15-6 Consumables List At Completion of each Phase’s SAT CDRL 15-7 Special Tools List At Completion of each Phase’s SAT

16. System Performance Requirements The SI shall meet all the applicable performance requirements contained within individual equipment and back-office sections of these specifications in addition to those described throughout this section for each project Phase being tested/deployed. The performance requirements described in this section are Key Performance Indicators (KPIs), all of which will be measured and reported on by the SI starting at each project Phase’s acceptance testing (see Section 12.6), and used as the primary criteria for the passing of each project Phase’s SAT and granting of each Phase’s Final Acceptance. In addition, a subset of the KPIs will be measured and reported on by the SI throughout each of the system operations agreements, and failure to meet these requirements will result in a credit being assessed and applied against the monthly operations payments made to the SI.

16.1 Key Performance Indicators

16.1.1 Equipment

16.1.1.1 Reliability (Failure Rate)

Equipment reliability will be calculated as an equipment failure rate:

# = × 100 # 𝑜𝑜𝑜𝑜 𝐶𝐶ℎ𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 Chargeable failures 𝑜𝑜𝑜𝑜are𝐴𝐴𝐴𝐴 defined𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝑃𝑃 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃in Section𝑜𝑜𝑜𝑜 𝐸𝐸𝐸𝐸 16.2.3.1𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸.𝐸𝐸 Active𝐸𝐸 pieces of equipment are defined as those deployed for customer and agency use in the production environment and do not include spares or test equipment.

AGY-21-008-IT 309 | Page

APPENDIX 1

Equipment failure rate calculations must not exceed the KPI requirement outlined in the table below during each measurement period in order to pass.

Payments Impacted

Base Require Measurement Ops

KPI # Device Credit ment Period Assessed SMA - office Agreement Back

16.1.1.1-1 Bus Fare Payment Validators < 5% Calendar Month 10%  16.1.1.1-2 Platform Fare Payment Validators < 5% Calendar Month 10%  16.1.1.1-3 Bus Operator Displays < 5% Calendar Month 10%  16.1.1.1-4 Ticket Vending Machines* < 20% Calendar Month 10%  16.1.1.1-5 Faregates < 10% Calendar Month 10%  16.1.1.1-6 Station Agent Terminal Equipment < 10% Calendar Month 10%  16.1.1.1-7 Customer Service Terminals < 10% Calendar Month 10%  16.1.1.1-8 Mobile Fare Inspection Devices < 10% Calendar Month 10%  16.1.1.1-9 Barcode Scanners < 5% Calendar Month 10%  *If equipment option is exercised and only AFTER the Phase 2 SMA has started

16.1.1.2 Accuracy

Equipment accuracy will be based on comparing the quantity and value (where available) of transactions generated by the devices, as recorded within the device audit registers, to those received by the back- office:

| | = 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝑛𝑛𝑛𝑛 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 − 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 | | = 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝑛𝑛𝑛𝑛 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 − 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 Both the transaction count and𝐸𝐸𝐸𝐸 𝐸𝐸𝐸𝐸value𝐸𝐸𝐸𝐸𝐸𝐸 calculations𝐸𝐸𝐸𝐸 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅(where𝑅𝑅𝑅𝑅𝑅𝑅 applicable)𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 must𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 exceed the KPI requirement in order to pass.

AGY-21-008-IT 310 | Page

APPENDIX 1

Payments Impacted Base Require Measurement

Credit Ops KPI # Device ment Period Assessed SMA - office Agreement Back

16.1.1.2-1 Bus Fare Payment Validators > 99.99% Calendar Month 12.5%  16.1.1.2-2 Platform Fare Payment Validators > 99.99% Calendar Month 12.5%  16.1.1.2-3 Bus Operator Displays > 99.99% Calendar Month 12.5%  16.1.1.2-4 Ticket Vending Machines* > 99.99% Calendar Month 12.5%  16.1.1.2-5 Faregates > 99.99% Calendar Month 12.5%  16.1.1.2-6 Station Agent Terminal Equipment > 99.99% Calendar Month 12.5%  16.1.1.2-7 Customer Service Terminals > 99.99% Calendar Month 12.5%  16.1.1.2-8 Mobile Fare Inspection Devices > 99.99% Calendar Month 12.5%  16.1.1.2-9 Barcode Scanners > 99.99% Calendar Month 12.5%  *If equipment option is exercised and only AFTER the Phase 2 SMA has started

16.1.2 Back-office

16.1.2.1 Accuracy

Back-office accuracy will be determined based on any incident where a device or back-office generated transaction is recorded incorrectly within the associated system.

Payments Impacted

Base Measurement Ops

KPI # System Requirement Credit Period Assessed SMA - office Agreement Back

16.1.2.1-1 Account-Based Transaction < 2 incidents Calendar Month 10%   Processor 16.1.2.1-2 Customer Relationship < 2 incidents Calendar Month 10%   Management System 16.1.2.1-3 Revenue Management System < 2 incidents Calendar Month 10%  

AGY-21-008-IT 311 | Page

APPENDIX 1

Payments Impacted

Base Measurement Ops

KPI # System Requirement Credit Period Assessed SMA - office Agreement Back

16.1.2.1-4 Data Warehouse < 2 incidents Calendar Month 10%   16.1.2.1-5 Reporting System < 2 incidents Calendar Month 10%  

16.1.2.2 Availability

Back-office availability will be calculated based on the total out of service hours for the associated system:

= 1

𝑂𝑂𝑂𝑂𝑂𝑂 𝑜𝑜𝑜𝑜 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻 𝑓𝑓𝑓𝑓𝑓𝑓 𝑡𝑡ℎ𝑒𝑒 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂 𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴𝐴 − Out of service hours are defined as all hours𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 during𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂 which the𝐻𝐻 𝐻𝐻𝐻𝐻𝐻𝐻𝐻𝐻system𝑓𝑓𝑓𝑓𝑓𝑓 is not𝑡𝑡ℎ𝑒𝑒 in𝐵𝐵 𝐵𝐵𝐵𝐵a fully𝐵𝐵 𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂𝑂 operational𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 state and includes all time necessary to respond and repair. Scheduled maintenance hours are excluded from the calculation. Total operating hours are defined as the number of hours in a day (24) multiplied by the number of days in the month of measurement.

Payments Impacted Base Measurement

Credit Ops KPI # System Requirement Period Assessed SMA - office Agreement Back

16.1.2.2-1 Account-Based Transaction > 99.99% Calendar Month 12.5%   Processor 16.1.2.2-2 Customer Relationship > 99.99% Calendar Month 12.5%   Management System 16.1.2.2-3 System Monitoring and > 99.99% Calendar Month 12.5%   Management Application 16.1.2.2-4 Media Inventory Management > 99.99% Calendar Month 12.5%   System 16.1.2.2-5 Revenue Management System > 99.99% Calendar Month 12.5%   16.1.2.2-6 Data Warehouse > 99.99% Calendar Month 12.5%  

AGY-21-008-IT 312 | Page

APPENDIX 1

Payments Impacted Base Measurement

Credit Ops KPI # System Requirement Period Assessed SMA - office Agreement Back

16.1.2.2-7 Reporting System > 99.99% Calendar Month 12.5%   16.1.2.2-8 Websites (Web Server) > 99.99% Calendar Month 12.5%  

16.1.3 Operations

16.1.3.1 Fare Media Read Rate

Fare media read rate will be the percentage of fare media read within 100 milliseconds of presentation. This is measured from the recognition of correctly presented media by the reader to the transmission of an associated fare payment or fare inspection API request.

100 =

𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝑜𝑜𝑜𝑜 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑤𝑤𝑤𝑤𝑤𝑤ℎ𝑖𝑖𝑖𝑖 𝑚𝑚𝑚𝑚 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝑜𝑜𝑜𝑜 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 Payments Impacted Base Measurement

Credit Ops KPI # Transaction Type Requirement Period Assessed SMA - office Agreement Back 16.1.3.1-1 NFC-Based Fare Media > 99.9% Calendar 12.5% (Closed-Loop Cards and Open Month  Payments) 16.1.3.1-2 Barcode-Based Fare Media > 99.9% Calendar 12.5%  Month

16.1.3.2 API Response Rate

API response rate will be the percentage of API requests that are responded to by the ABT within 50 milliseconds. This is measured from receipt of an API request by the API server to the transmission of a response to the system or device that generated the request.

50 =

𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝑜𝑜𝑜𝑜 𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑡𝑡𝑡𝑡 𝑤𝑤𝑤𝑤𝑤𝑤ℎ𝑖𝑖𝑖𝑖 𝑚𝑚𝑚𝑚 𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝑜𝑜𝑜𝑜 𝐴𝐴𝐴𝐴𝐴𝐴 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 AGY-21-008-IT 313 | Page

APPENDIX 1

Payments Impacted Base Measurement

Credit Ops KPI # Transaction Type Requirement Period Assessed SMA - office Agreement Back 16.1.3.2-1 Fare Payment Requests > 99.9% Calendar 12.5%  Month 16.1.3.2-2 Mobile Fare Inspection Device > 99.9% Calendar 12.5%  Transactions Month

16.1.3.3 Report Generation

Report generation will be based on any incident where a canned report developed and delivered by the SI takes more than ninety (90) seconds to be generated.

Payments Impacted

Measurement Base Credit Ops

KPI # Report Type Requirement Period Assessed SMA - office Agreement Back 16.1.3.3-1 Canned Report < 2 incidents Calendar 10%  Generation Month

16.2 Performance Monitoring

16.2.1 General Requirements

Assigned Req # Requirement CDRL 16.2.1-1 The SI shall be responsible for measuring performance against all KPIs. CDRL 16-1 16.2.1-2 System performance will be measured using the data generated by the CDRL 16-1 system and stored in the data warehouse. Data generated manually will be used when it is the only option for tracking an activity associated with a particular KPI (e.g., response time). 16.2.1-3 The SI shall automate the capture of all necessary data and KPI calculation CDRL 16-1 wherever possible. For validation purposes, the agency will have full access to the source data and code used to perform the calculations.

AGY-21-008-IT 314 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 16.2.1-4 The SI shall commence performance measurement during the pilot and CDRL 16-1 continue to perform this activity throughout the operations agreements. 16.2.1-5 The SI shall monitor and preform usability enhancements for the barcode CDRL 16-1 scanner. Barcode scanning will provide a response to customers within 500ms on the first try with no errors at least 99% of the time.

16.2.2 Failure Review Board

A Failure Review Board (FRB) will be established to determine, in the event of a dispute, which equipment and back-office failures will be chargeable against the performance KPIs. The FRB will also assess the severity of failures during acceptance testing in order to make a determination on the successful completion of the various Phases’ pilot and SAT, the granting of Final Acceptance, and whether any fleet defects exist.

Assigned Req # Requirement CDRL 16.2.2-1 The FRB will be established during the 30-day settling period prior to any CDRL 16-1 acceptance testing to evaluate equipment and back-office failures, as well as other system issues, throughout acceptance testing. 16.2.2-2 The acceptance test plan submitted by the SI will include a proposed FRB CDRL 16-1 structure and system performance review process. 16.2.2-3 At a minimum, the FRB will be comprised of the agency’s project CDRL 16-1 manager, or a designated representative, and the SI’s lead engineer. 16.2.2-4 The members of the FRB will attempt to settle any disputes based on the CDRL 16-1 requirements in these specifications and will use best judgment in any scenarios where the requirements are silent or unclear. 16.2.2-5 The agency’s project manager will make the final and binding decision on CDRL 16-1 any disputes that remain unsettled by the FRB after a period of 10 business days. 16.2.2-6 The FRB will be responsible for the review and approval of the CDRL 16-1 acceptance test plan and shall agree to the criteria for the execution and approval of the acceptance test Phases. 16.2.2-7 During any acceptance testing, the FRB shall meet no less than weekly. CDRL 16-1 The FRB will review all failures and other system issues that arise during any of the pilots and SATs to assess their severity (see Section 16.2.3.3) and impact on the completion of these test Phases. 16.2.2-8 Following each Phase’s Pilot and SAT, the FRB will make a CDRL 16-1 recommendation on whether to approve or extend these test Phases. Final discretion for the approval of acceptance testing and the granting of each Phase’s Final Acceptance will reside with the agency.

AGY-21-008-IT 315 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 16.2.2-9 Following the final Phase’s Final Acceptance, the FRB will continue to CDRL 16-1 meet monthly for the remainder of the operations agreements. During this time, the FRB will be responsible for reviewing system performance and settling any disputes around the measurement of the KPIs.

16.2.3 Failure Definition

16.2.3.1 Chargeable Failures

A chargeable failure is a hardware or software malfunction where the delivered equipment or systems fail to perform or perform in a way that does not meet the requirements in these specifications. Chargeable failures count against the system performance KPIs (see Section 16.1).

Assigned Req # Requirement CDRL 16.2.3.1-1 Chargeable failures include, but are not limited to, the following: CDRL 16-1 • A malfunction which prevents the system component from performing its designated function, or meeting the performance criteria, when used and operated under the environmental and operational conditions stated in these specifications • A malfunction that might cause a threat to customers, employees, or others • An occurrence that does not cause the system component to become entirely inoperable, but requires some form of maintenance attention to restore normal function • Any occurrence where data is not successfully transmitted between elements of the system • Planned software updates or fixes that adversely affect the operation or performance of the system • Scheduled maintenance or repair activities that adversely affect the operation or performance of the system

AGY-21-008-IT 316 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 16.2.3.1-2 The following specific conditions, at minimum, will be considered CDRL 16-1 chargeable failures in any components or systems delivered: • Software anomalies and bugs (every incident of a software anomaly or bug causing a malfunction will be considered a failure) • Hardware failures that are not clearly a result of conditions outside the requirements of this specification • Failures of mounting hardware • Data storage failures, including those due to the disk space provided • Partial or complete failure of a passenger display • Failure to accurately read and/or process a card • Failure to properly register and report any transactions • Data download/upload failure • Event or alarm transmission failure • Unexpected shutdown of equipment or a system • All maintenance requiring module replacements 16.2.3.1-3 Under mutual agreement, the FRB will classify additional failures as CDRL 16-1 chargeable or non-chargeable as required. 16.2.3.1-4 Chargeable failures will affect the reliability, accuracy, and availability KPI CDRL 16-1 calculations.

16.2.3.2 Non-Chargeable Failure

A non-chargeable failure is a malfunction caused by a condition external to the system component under consideration, and not included in a functional, environmental, test, or other requirement in these specifications. A non-chargeable failure is not expected to be encountered during normal and correct operation of the system components.

Assigned Req # Requirement CDRL 16.2.3.2-1 Non-chargeable failures include, but are not limited to, the following: CDRL 16-1 • Mishandling of equipment or back-office system components • Any failures caused by externally applied stress conditions outside of normal operating conditions and in excess of the requirements in these specifications • Failures caused by incorrectly exercised operating, maintenance or repair procedures performed by the agency where correct procedures have been delivered by the SI (failures resulting from any maintenance or repair performed by the SI will be chargeable) • Failure caused by vandalism • Communications failures beyond the control of the SI • Downtime due to scheduled maintenance

AGY-21-008-IT 317 | Page

APPENDIX 1

Assigned Req # Requirement CDRL • Heater or battery adjustments • Dependent failures as a result of a nonchargeable failure 16.2.3.2-2 All other failures will be considered relevant and chargeable unless CDRL 16-1 determined to be non-chargeable by the FRB. 16.2.3.2-3 Non-chargeable failures will not affect the reliability, accuracy, and CDRL 16-1 availability KPI calculations.

16.2.3.3 Failure Severity

Assigned Req # Requirement CDRL 16.2.3.3-1 During the pilot and SAT, the FRB will evaluate failures to establish their CDRL 16-1 severity as critical or non-critical. Critical failures will need to be resolved in order to approve the test Phase, and in some cases, may result in an extension of the test Phase. 16.2.3.3-2 The FRB shall be the sole arbiter of failures and their severity. For CDRL 16-1 incidents declared failures, the FRB shall assign severities according to the following general guidelines, subject to modification by the FRB. 16.2.3.3-3 At a minimum, critical failures will include incidents that produce a major CDRL 16-1 or substantial business impact, or impact to normal operations, such as: • Non-trivial loss of revenue or expense • Significant negative customer experience • Limited or loss of access to a production application • System operation at a degraded level, such that normal business operations cannot be conducted • Application or system experiencing continual or repeated issues 16.2.3.3-4 At a minimum, non-critical failures will include incidents that produce little CDRL 16-1 or no business impact, or impact to normal operations, such as: Negligible loss of revenue or expense Minor customer inconvenience System operating at a degraded level such that normal business operations are minimally impacted

16.3 Performance Reporting Assigned Req # Requirement CDRL 16.3-1 The SI shall be responsible for reporting on performance against all KPIs on CDRL 16-1 a monthly basis.

AGY-21-008-IT 318 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 16.3-2 The SI shall create canned reports that can be run, viewed, and CDRL 16-1 downloaded by the agency using the reporting system (see Section 8.8). These reports will not count toward the custom reports to be defined by the agency. 16.3-3 At a minimum, the following reports will be provided: CDRL 16-1 • Device reliability • Device accuracy • Device availability • Back-office accuracy • Back-office availability • Server authorization rate • Maintenance response time 16.3-4 The reports will be generated without manual data entry by the SI CDRL 16-1 wherever possible. 16.3-5 The reports will include tables and graphical charts showing the current CDRL 16-1 and historical performance of each device of the system under measurement. 16.3-6 The reports shall include a calculation of any credits to be assessed in the CDRL 16-1 current month based on current and prior performance (see Section 16.4). 16.3-7 The SI shall commence performance reporting during the pilot and CDRL 16-1 continue to perform this activity throughout the operations agreements.

16.4 Credit Assessment Assigned Req # Requirement CDRL 16.4-1 Credits will be assessed for a failure to meet any KPIs identified as having CDRL 16-1 an associated credit (see Section 16.1). 16.4-2 A failure will result in the percentage in the “Credit Assessed” column CDRL 16-1 being applied to the full amount of the operations payment identified in the “Payment Impacted” column for the month of measurement. 16.4-3 A failure to meet the same KPI for two or more months in a row will CDRL 16-1 constitute a persistent failure, and result in a multiplier being applied to the credit percentage. 16.4-4 The credit multiplier will increase by a factor of one for each month that a CDRL 16-1 KPI is not met (e.g., if a KPI is not met two months in a row, the credit will be doubled in the second month; if a KPI is not met three months in a row, the credit will be tripled in the third month)

AGY-21-008-IT 319 | Page

APPENDIX 1

Assigned Req # Requirement CDRL 16.4-5 Successfully meeting a KPI will end a persistent failure and reset the credit CDRL 16-1 multiplier. 16.4-6 The total credit applied to an operations payment will be capped at 25% of CDRL 16-1 the full amount of that payment in a calendar month. Credits will not be carried over from month to month. 16.4-7 The SI shall be responsible for reporting on credits in the system CDRL 16-1 performance reports (see Section 16.3) and will deduct credits directly from any invoices submitted to the agency.

16.5 Required Submittals Submittal Submittal Due Description No. CDR PDR FDR Other CDRL 16-1 Performance Measurement Plan X X Required for each Phase’s PDR and FDR.

AGY-21-008-IT 320 | Page