Exhibit C - Requirements Traceability Matrix.xlsx
XLSX spreadsheet 32 KB Posted
- Solicitation number
- 33365
- Issued by
- Hartford County, Connecticut
About this file
Requirements Traceability Matrix Summary
This document is a Requirements Traceability Matrix (RTM) for the Connecticut Department of Transportation's (CTDOT) Contactless Fare Collection Platform procurement. The RTM serves as an evaluation tool for assessing whether proposers' technical solutions comply with the detailed requirements outlined in the Scope of Work. The matrix is organized into five primary categories: Validators (18 requirements), Fare Calculation Software (16 requirements), Mobile Ticketing (30 requirements), Other Services (14 requirements), and CTrail Mobile Ticketing Options (6 requirements), totaling 84 distinct requirements. The validators must support contactless EMV payments (Level 1, 2, and 3 certified for major card brands), mobile wallets (Apple Pay, Google Pay, Samsung Pay), offline transaction storage for 96 hours, QR code scanning, anti-pass back mechanisms, and physical durability suitable for New England climates with an expected 5-year lifespan. The fare calculation software must configure business rules, apply discounts and fare capping, manage credentials and deny lists, process PCI-compliant transactions, and provide comprehensive reconciliation and monitoring capabilities. The mobile ticketing application must run natively on iOS and Android, support multiple transit agencies (up to 20), enable fare capping across agencies, provide real-time analytics and reporting, and be deployed and revenue-ready within three months of contract notice to proceed.
Proposers must indicate compliance status for each requirement by selecting "Yes," "No," or "Alternative" from dropdown menus, with explanations required for any non-compliant or alternative responses. Key service requirements include installation support across eight CTtransit garages for 600 validators, migration of existing Go CT account data from current farebox systems, support for university pass programs (U-Pass), reduced fare program administration for seniors and persons with disabilities, integration with existing cash farebox systems, paper ticket generation and validation, and coordination with Amtrak for CTrail rail ticketing integration. The contractor must provide payment processing solutions with connections to payment networks, propose credit card processing approaches with transparent fee pass-through using optimal Merchant Category Codes, support simultaneous implementation across 13 different transit agencies with separate merchant IDs, provide training (minimum 80 hours), digital marketing assets, and maintain ongoing software updates at no additional cost throughout the contract term.
View the file
Other files
Show all 13
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Contactless Fare Collection Platform | |
| Instructions: Requirements Traceability Matrix | |
| About | The Requirements Traceability Matrix informs CTDOT and the selection committee of how the Proposer's technical solution fulfills the requirements as listed in the Scope of Work. The Matrix's items correspond to numbered items in the Scope of Work. |
| Column D: Compliant | The Proposer should indicate whether their technical solution is compliant with the listed item, by selecting "Yes", "No", or "Alternative" from the drop-down column. |
| Column E: Alternative | If "No" or "Alternative" is selected under the "Compliant" column, the Proposer should explain why they are not compliant (e.g., not currently compliant but adding functionality at a later date), or the proposed alternative to the item. If "yes" is selected in the "Compliant" column, no explanation is required. |
Matrix
| Item # | Category | Requirement | Compliant | Alternative |
| 1.1 | Validators | EMV Level 1, 2, and 3 certified for Visa, Mastercard, Discover, and Amex and implements any additional Payment Scheme transit specific requirements. | ||
| 1.2 | Validators | Compatible with the Mass Transit Transaction (MTT) Deferred Authorization Framework and equivalent transaction models from the Payment Schemes. | ||
| 1.3 | Validators | Compliant with PCI PTS v4.0 (or higher). | ||
| 1.4 | Validators | Supports Apple Pay, Google Pay and Samsung Pay mobile wallets. | ||
| 1.5 | Validators | Store taps for at least 96 hours, in case of a communications failure with back-end software. | ||
| 1.6 | Validators | Supports the inclusion and exclusion of specific BIN ranges. | ||
| 1.7 | Validators | Supports initial offline data authentication (ODA) when a card is tapped to check card number formats, expiration date, and deny lists in less than 0.5 seconds. | ||
| 1.8 | Validators | Supports allow and deny lists, where each entry may contain a (hashed) PAN, (hashed) PAR, or BIN and deny list management that supports manual and automatic addition to/removal from deny list and automatic debt recovery processes. | ||
| 1.9 | Validators | Contains an anti-pass back mechanism with a configurable pass back interval such that pass back can be allowed within x seconds of the first tap to enable multi-rider boarding and not allowed within x + y seconds of the first tap to control fraud while optionally allowing multi-rider boarding. The variable x can be set to low value or zero where multi-rider boarding is not supported. | ||
| 1.10 | Validators | Physically durable validator meeting rigorous standards for use in public transit environments and New England climate year-round. | ||
| 1.11 | Validators | The validator display must be easily visible during sunlight and contain RGB lights to communicate status to customers and operators. Display shall be scratch and shatter resistant. | ||
| 1.12 | Validators | Integrate with the transit vehicle’s standard wiring for power and ethernet, with option for the validators to receive internet connectivity via a data-enabled SIM card if no router exists on the vehicle. | ||
| 1.13 | Validators | Able to scan, interpret, authenticate and validate QR codes that may encode a ticket or an identifier linked to an account. | ||
| 1.14 | Validators | Supports DC power inputs between 9V and 32V. | ||
| 1.15 | Validators | Mobile inspection device can be used by fare enforcement staff to validate the right to travel of transit customers on-board transit vehicles. | ||
| 1.16 | Validators | Validators shall have an expected lifetime of at least 5 years in the environmental conditions expected in deployments in Connecticut. | ||
| 1.17 | Validators | The validators must be able to operate in online and offline scenarios and shall have an operational availability of 99.5% over the operational service day. Contractor to describe their method of measuring and reporting this performance indicator. | ||
| 1.18 | Validators | Provide a certified installation team acceptable to the transit agency to install validators onboard transit vehicles. The transit agency reserves the right to handle installation through in-house maintenance personnel. In such event, the contractor shall furnish all materials needed and only bill the agency for the cost of materials. | ||
| 1.19 | Validators | Supply and install power management units that enable validators to stay in a powered-on state for a period of at least 30 minutes when the bus is powered-off. | ||
| 2.1 | Fare Calculation Software | Configure the devices and contactless fare payment system with the transit agency’s business rules, fares, routes and stop locations. Contractor shall provide access to the contactless fare payment system to transit agency authorized personnel and perform all other initial integration activities. The contractor shall also provide the transit agency with the ability to configure specific fare rules, discounts, and caps in the contractor’s systems. | ||
| 2.2 | Fare Calculation Software | Apply the fare rules, discounts, and fare capping policies such that the correct final fare amount is charged to each customer at the end of each service day. | ||
| 2.3 | Fare Calculation Software | Support fare management rules including discounts to base fare linked to rider's concession eligibility, multi-period fare capping, combination of discounts and capping, multi-agency fare capping and transfer discounts, and different base fares/caps for local/express service. | ||
| 2.4 | Fare Calculation Software | Provide discounts in the form of reduced Base Fares and caps to groups of transit customers and/or their credentials. These groups may include for example: seniors, persons with disabilities, youth, veterans, and students. These groups, the discounts and the members in the group can be defined by the transit agency in the contractor’s systems. Contractor shall apply the configured fare rules correctly to every received tap from credentials in a group. | ||
| 2.5 | Fare Calculation Software | Provide the transit agency with exports of the fares configured in and applied by the contractor’s systems in a GTFS-Fares V2.0 format. | ||
| 2.6 | Fare Calculation Software | Compliant with all PCI and Payment Scheme rules to process Visa, Mastercard, Discover, and American Express debit, credit, and pre-paid transactions, including the Visa Mass Transit Transaction (MTT) model, equivalent mass transit transaction models from other Payment Schemes, and future MTT models as they are made available. The Contractor’s Qualified Security Assessor (QSA) will prepare an initial and annual Report on Compliance (ROC) with PCI-DSS requirements and prepare and provide the associated Attestation of Compliance (AOC). | ||
| 2.7 | Fare Calculation Software | Send final charges to the payment processor for settlement request at the end of every service day. | ||
| 2.8 | Fare Calculation Software | Enable the transit agency to verify the state and completeness of all received taps and final charges and provide reconciliation and exceptions reporting that show discrepancies including but not limited to a) taps captured by the validators, (b) taps sent to and received by the fare calculation software, c) fare charges sent to the payment processing vendor, and d) fare charges settled by the payment processing vendor. | ||
| 2.9 | Fare Calculation Software | Provide an interface so that all transaction data excluding full PAN or other PCI sensitive information can be accessible for the transit agency or third parties as directed by the transit agency. | ||
| 2.10 | Fare Calculation Software | Provide the ability for the transit agency to monitor all processed taps and transactions and understand their “state” and “status” (note that “state” corresponds to information regarding whether the tap transaction went through all steps of processing and “status” corresponds to the results of the aforementioned processing). This requires the contractor to provide (1) a user interface for transaction monitoring by transit agency personnel, and (2) an automated interface that can be integrated by the transit agency. | ||
| 2.11 | Fare Calculation Software | Minimize financial loss for the transit agency by providing services to manage credential lists, identify fare evasion and suspicious credentials, and implement processes to recover financial losses by ensuring the highest degree of revenue recovery is achieved with the least impact to transit customers. Recovery of debt associated with first tap risk or authorization failures will follow the associated card brand payment card industry rules for automated debt recovery including rider tap debt recovery. | ||
| 2.12 | Fare Calculation Software | Provide list management to limit the usage of credentials that are not allowed to enter the paid area of the transit system. Validators should locally store allow and deny lists of Bank Identification Numbers (BINs) and (tokenized) credential Primary Account Numbers (PANs) and Payment Account References (PARs) and validate each tap against them. Contractor is responsible for creating these lists by gathering information from different systems and ensuring timely validator list updates. Whitelists are typically used for pilot testing where only specific cards or BINs are accepted and deny lists contain cards that have failed account verification, authorizations, settlement request, been reported lost or stolen, or be subject to suspicious activities. Whitelists may also be used to support special cards such as compatible student IDs for U-Pass and CTpass programs. | ||
| 2.13 | Fare Calculation Software | Provide risk management to minimize the loss of revenue by identifying suspicious and fraudulent transactions and by validating each transaction against the pre-configured list of rules. Contractor shall configure risk rules based on requirements from transit agencies, Payment Schemes, and own observations. Contractor shall coordinate with transit agencies on risk management rules to balance revenue recovery risk with customer experience. | ||
| 2.14 | Fare Calculation Software | Provide an interface for mobile inspection devices for fare enforcement staff to view recent tap transactions, customer account information, including eligibility for discount or benefit or fare program being used for travel. Riders traveling under a program such as U-Pass for university students should be available and guide the fare inspector to ask for university ID as appropriate. | ||
| 2.15 | Fare Calculation Software | Provide debt management to detect bad debt, initiate recovery processes in accordance with the MTT models of the Payment Schemes and provide mechanisms for the transit customers to clear their debt. The debt being recovered can be before automated debt recovery is successful or after all automated debt recovery attempts have failed. Transit customer options to clear the debt should include tapping their open loop credential that has a debt on any validator or contacting the transit agency to request that their debt be manually recovered. Where either method of transit customer-initiated debt recovery generates a near real time authorization request and if authorization request is approved, results in the open loop credential being removed from the deny list of every validator so that the credential can again be used for travel. The transit agency will have a means to generate reports on debt and unrecoverable debt (bad debt) that remains after all automated debt recovery attempts have been exhausted. The transit agency will also be able to manually settle debt with customers. | ||
| 2.16 | Fare Calculation Software | Provide services to allow transit customers and the transit agency the ability to link payment credentials with transit accounts and enable account features such as the ability to review transaction histories and receive and answer transaction-related inquiries. These services should include storage of account information, a website and real-time customer service interface with tap information, support multiple credentials per account. Contractor will provide customer support to transit agencies, provide them an interface for fare rules, and provide them access to account histories and manage discount products linked to accounts. Contractor will also offer reporting to transit agency on revenue, operations, transfers, fare capping, customer tracking, debt recovery, and disputes. | ||
| 3.1 | Mobile Ticketing | A native application that runs on IOS and Android and is available in the Apple App Store and Google Play Store as a free download. | ||
| 3.2 | Mobile Ticketing | Doesn’t require a user account or sign in to purchase tickets but is optional. | ||
| 3.3 | Mobile Ticketing | Doesn’t require a user to store a payment method but is optional. | ||
| 3.4 | Mobile Ticketing | Supports purchasing and validating multiple tickets at the same time on a single device and validating each ticket individually as required by visual or electronic validation. | ||
| 3.5 | Mobile Ticketing | Provides a simple and intuitive ticket selection interface. | ||
| 3.6 | Mobile Ticketing | Generates mobile fare product with a QR code to allow validation of fares electronically through a QR code reader, with ability to validate visually. | ||
| 3.7 | Mobile Ticketing | Contains security features to prevent the use of fraudulent mobile tickets. | ||
| 3.8 | Mobile Ticketing | Accept payments from Visa, Mastercard, American Express and Discover Payment networks. | ||
| 3.9 | Mobile Ticketing | Accept payments from non-bank cards, such as the Cash App, to meet the needs of unbanked and underbanked customers. | ||
| 3.10 | Mobile Ticketing | Accept mobile wallet payment options, including but not limited to, Apple Pay, Google Pay and Samsung Pay mobile wallets. | ||
| 3.11 | Mobile Ticketing | Customization and personalization features, including unique branding for up to 20 different transit agencies or services in Connecticut. | ||
| 3.12 | Mobile Ticketing | Capable of handling fare structures and agency specific business rules for up to 20 different transit agencies or services in Connecticut. | ||
| 3.13 | Mobile Ticketing | Support transit agency fare capping policies, with the potential to introduce a statewide fare cap that may include fare purchases from multiple transit agencies in Connecticut contributing to potential statewide fare cap(s). | ||
| 3.14 | Mobile Ticketing | Incorporate fare changes and new fare products, as they become available in Connecticut. | ||
| 3.15 | Mobile Ticketing | Provide back-end dashboards with access to data on usage, ridership, sales and revenue for separate services ("System"). | ||
| 3.16 | Mobile Ticketing | Regular software updates to the System shall be provided at no cost throughout the term of the contract. | ||
| 3.17 | Mobile Ticketing | The System shall provide various levels of user access rights that allow and restrict access to various functions. To support program administration of statewide fare programs, CTDOT will require the ability to access, view, and download reporting information mentioned in section 2.16.7 for all transit agencies in Connecticut. | ||
| 3.18 | Mobile Ticketing | The System shall provide access to an unlimited number of users and feature multiple user access levels with password protection to ensure system settings are secure. | ||
| 3.19 | Mobile Ticketing | The reporting dashboard shall display ridership statistics including stop location, bus route/block/run, date, time, and GPS coordinates of boardings. | ||
| 3.20 | Mobile Ticketing | Ability to see sales and transaction data in real-time or near real-time. | ||
| 3.21 | Mobile Ticketing | Ability to integrate or ingest fare data from current or future cash farebox vendors for transit agencies in Connecticut. The analytics platform should show purchase data from mobile ticketing purchases, purchase data from cash fareboxes, and combined purchase data. | ||
| 3.22 | Mobile Ticketing | Ability to run sales, usage summary, user statistics, fare transaction statistics, and revenue summary reports. Ability to set up additional custom reports to meet CTDOT’s data needs. | ||
| 3.23 | Mobile Ticketing | Ability to easily export all data for integration with other software systems and tools. | ||
| 3.24 | Mobile Ticketing | Ability to issue refunds to customers. | ||
| 3.25 | Mobile Ticketing | Application Programming Interface (API) for extracting usage data that is free for CTDOT and its designees to access, use, and share. | ||
| 3.26 | Mobile Ticketing | Ability for third party applications such as Google Maps, Apple Maps, Transit App, Citymapper, and Transportation Network Companies (TNCs) to offer mobile tickets in their app via API or SDK. Integrations shall not result in ongoing or recurring fees to CTDOT from either the contractor or the trip planning application vendor(s). | ||
| 3.27 | Mobile Ticketing | Data security for the mobile ticketing application, system, and interfaces shall employ the most current industry and U.S. government techniques to ensure that all data is safeguarded from unauthorized access or use and programs are protected from any known cyber-attack or computer virus. The entire mobile ticketing platform system, all system applications that process payments, and all communications and computer systems comprising the entire mobile ticketing app shall be in full compliance with the latest Payment Card Industry (PCI) standards. Additionally, the Platform application shall contain a variety of security features to allow for applicable transit agency personnel to easily identify invalid, expired, or fraudulent mobile tickets. | ||
| 3.28 | Mobile Ticketing | The mobile ticketing application must be deployed and in use at an existing transit agency that provides over 10,000,000 annual transit trips. | ||
| 3.29 | Mobile Ticketing | Hosting, operation, and maintenance of the mobile ticketing app must be the responsibility of the contractor. | ||
| 3.30 | Mobile Ticketing | The contractor shall be responsible for providing API Access or Software Development Kits. | ||
| 3.31 | Mobile Ticketing | Upon receipt of a notice to proceed, the mobile application shall be fully designed, developed, tested, deployed in the Apple App Store and Google Play Store, and revenue ready within three months. | ||
| 4.1 | Other | Contractor will have connection(s) to the payment networks for authorization and settlement of payment transactions via payment processors to settle fares to the transit agencies’ bank accounts. The contractor will propose credit card payment processing solution(s) as part of the proposal. The contractor shall outline all payment processors it has previously integrated with in prior deployments. If the contractor proposes handling payment processing as a part of a turn-key solution, CTDOT and each regional transit agency reserves the right to use a payment processor of its choice in the future. The contractor agrees to pass through credit card processing fees with no markup and will provide credit card processing invoices to the transit agency upon request. The contractor agrees to use the most cost advantageous Merchant Category Codes (MCCs) to minimize interchange fees. | ||
| 4.2 | Other | Contractor will provide a solution to generate and validate single-use or limited-use paper tickets with unique and secure QR codes and must be able to generate paper tickets in bulk for printing and distribution by the transit agency. | ||
| 4.3 | Other | Contractor will provide a comprehensive back office and system integration with the transit agency’s current and future cash farebox vendor. All cash and transfer issuance transactions from the farebox will be transmitted to the central back office for consolidated reporting alongside all other electronic fare media. | ||
| 4.4 | Other | Contractor will provide a solution to migrate and maintain all existing Go CT accounts (regular and reduced fare) from the back office of CTDOT’s existing farebox vendor to the contractor’s back office. The Go CT cards are a MIFARE DESfire smart card. CTDOT’s goal is to seamlessly transition Go CT customers from tapping at the farebox to tapping their Go CT cards at the new validators provided by the contractor, without having to issue new cards to existing Go CT card customers. CTDOT to provide all card data and account balance information to the contractor for the migration. | ||
| 4.5 | Other | Contractor will provide a digital university pass solution for CTDOT’s U-Pass Program. Validators supplied by the contractor shall be capable of accepting taps from student ID cards with embedded RFID or NFC chips. For educational institutions that do not have compatible embedded RFID or NFC chips, there should be a mechanism to enable adding open loop credit or debit cards and enable linking multiple concessions such as age based and zero value caps each with their own validity period. | ||
| 4.6 | Other | Contractor will provide a digital pass solution for CTDOT’s CTPass Program. | ||
| 4.7 | Other | Support CTDOT in implementing innovative multi-modal fare integration goals, such as opportunities to support the validation of Metro-North Railroad unitickets on board Connecticut buses in the future, if unitickets are made available for purchase in the MTA Traintime app. | ||
| 4.8 | Other | Contractor to propose a web-based solution for transit agencies to digitally administer reduced fare programs for seniors (ages 65+), persons with disabilities, Veterans, and youth (ages 5-18). The transit agency requires a secure channel to allow customers the ability to upload proof of eligibility documentation and link a reduced fare benefit to a payment credential. The solution may also allow transit customers to visit customer service locations to provide proof of eligibility to transit agency personnel and link their payment credential to a reduced fare benefit by tapping a device at the customer service booth. If CTDOT establishes a Digital Eligibility Verification solution like the Cal-ITP Benefits portal in the future, the contractor will be required to ensure availability of an integration point to support a secure tokenization interface and token linking interface for the solution. | ||
| 4.9 | Other | Provide CTDOT with a project implementation plan and project schedule for review and approval by CTDOT. The project implementation plan shall detail how the Validators, Fare Calculation Software, Mobile Ticketing, and all supporting services are delivered – up to and including testing – to the Transit Agency, including timelines, activities, dependencies, responsibilities, project organization, communication and governance, and risks and mitigations. Contractor shall assign a single point of contact for the transit agency during the implementation period, and this person is responsible to ensure that the project is carried out in accordance with the project implementation plan. There are 8 different CTtransit garages throughout the state that the contractor will be responsible for coordinating bus availability with site personnel at each facility for the installation of the initial 600 validators on CTtransit vehicles. | ||
| 4.10 | Other | The contractor shall provide all applicable manuals and non-localized training material for all applicable different types of users of the system to each transit agency prior to commissioning. The contractor shall also provide up to 80 hours of training (on-site or remote) to transit agency personnel covering, at minimum, the following topics: Device installation procedures, operational procedures, configuration, incident management and customer support procedures, device management, reporting, and transit customer support inclusive of responding to and managing open loop card chargebacks. The contractor shall provide a Training Plan to the transit agency indicating the target audience, topics covered, training format and timeline. | ||
| 4.11 | Other | The contractor shall provide to the transit agency a suite of digital marketing assets to deploy for marketing purposes as well as analytic tools, including referral campaigns, promotion codes, and customer URL links, to measure and quantify customer conversion and marketing effectiveness. | ||
| 4.12 | Other | Ability to simultaneously implement contactless fare collection platform across 13 different transit agencies, including capacity to work with staff, enter into separate agreements with same pricing extended to all agencies, accommodate unique merchant IDs, and provide each transit agency its own administrative back-end portal. | ||
| 4.13 | Other | Future optional support for Express Mode (Apple Wallet) and Fast Mode (Samsung Wallet) for transit where either closed loop or open loop fare media can be used for fare payments allowing transit customers to tap their device without unlocking it. | ||
| 4.14 | Other | Future optional support for contactless hands-free boarding or paid zone entry that uses Bluetooth or ultra-wideband (UWB) technology allowing riders to board buses and enter paid zone areas and not have to remove their phone from their pocket and tap at the validator. | ||
| 5.1 | CTrail mobile ticketing option | Ability to perform a QR code integration and/or ensure communication with Amtrak Rail Ticketing system(s) to incorporate Amtrak/CTrail cloud database solution currently in effect for Hartford Line rail service, that allows for Amtrak and CTrail conductors to validate CTrail tickets sold through CTrail eTix Mobile Ticketing application utilizing scanning of a mobile displayed QR code. | ||
| 5.2 | CTrail mobile ticketing option | Ability to coordinate with Amtrak to provide a QR code displayed by the Mobile Application per the defined format specification. | ||
| 5.3 | CTrail mobile ticketing option | The contractor’s system shall provide Data import of mobile application ticket sales data to CTrail/Amtrak cloud database utilizing an Amtrak supplied API. | ||
| 5.4 | CTrail mobile ticketing option | Ability to perform integration given the following assumptions: the CTrail ticket QR code shall contain the CTrail unique identifier, ticket number, and validity date; and that CTDOT shall ensure that Amtrak provides documentation and the API require for the data import to the contractor at the start of development. | ||
| 5.5 | CTrail mobile ticketing option | Ability to integrate and/or coordinate with CTDOT's current eTix mobile ticketing vendor and Amtrak given their current process as outlined in item 5.5 of the SOW. | ||
| 5.6 | CTrail mobile ticketing option | Ability to integrate and/or coordinate with CTDOT's current eTix mobile ticketing vendor and Amtrak given the current solution's General Technical Scope as outlined in item 5.6 of the SOW. |
File details come from the government source that posted it. Updated .