Request_for_Information.pdf

City of Tucson

Request for Information # 270200

TRANSIT ACCOUNT AND PASSENGER SYSTEM

(TAPS)

Industry Capabilities, Recommended Delivery Approach, and Industry Outreach

Sun Tran | Sun Link Streetcar | Sun Shuttle

October 2026

Important Notice. This RFI is issued solely to obtain information from the marketplace. It is not a Request for Proposals, Invitation for Bids, offer to contract, or promise that a future procurement will occur. Responses are voluntary and will be used to inform project planning, requirements development, acquisition strategy, budgeting, and risk management.

Contents

1. RFI Purpose and Market Research Objectives

1.1 Market Research Objectives

1.2 What the Agency Is Not Seeking at This Stage

2. Program Background and Current Environment

2.1 Preliminary Business Drivers

3. TAPS Vision and Desired Outcomes

3.1 Desired Outcomes

4. Preliminary Functional Concept

5. Preliminary Technical and Operational Concept

5.1 Questions Embedded in the Technical Concept

6. Information Requested from Respondents

7. Recommended Project Delivery and Implementation Approach

7.1 Requested Industry Recommendation

7.2 Preliminary Workstreams for Comment

8. Data, Cybersecurity, Privacy, and Identity Management

8.1 Identity and Privacy Questions

8.2 Cybersecurity Information Requested

9. Interfaces, Interoperability, and Future Fare Readiness

9.1 Future Fare Strategy Questions

10. Operations, Maintenance, Support, and Lifecycle

11. Commercial, Pricing, and Contracting Information

11.1 Contracting Recommendations Requested

12. Vendor Qualifications and Relevant Experience

13. Demonstrations and Follow-Up Industry Engagement

13.1 Potential Demonstration Topics

14. RFI Response Instructions

15. Agency Questions for Industry

Appendix A – Preliminary Capability Matrix

Appendix B – Preliminary Implementation Workstreams

Appendix C – Respondent Information Form

Appendix D – Suggested Response Format

Closing Statement

1. RFI Purpose and Market Research Objectives The purpose of this Request for Information is to identify organizations with the capability and experience to help plan, design, configure, implement, integrate, host, operate, and support a Transit Account and Passenger System (TAPS), and to obtain industry recommendations regarding how a project of this type should be structured and delivered.

The agency has developed a preliminary enterprise Scope of Work describing a potential future-state platform for rider registration, customer account management, credentials, utilization tracking, reporting, cybersecurity, system integration, and future account-based fare collection. Before finalizing a procurement strategy or detailed requirements, the agency wants to understand the current marketplace, available solution models, implementation practices, technology alternatives, cost drivers, risks, and lessons learned from comparable programs.

1.1 Market Research Objectives

• Identify software vendors, systems integrators, consultants, fare-technology providers, cloud/platform providers, and other firms capable of delivering all or portions of the envisioned program.

• Understand whether the marketplace generally provides TAPS-type capabilities as a commercial off-the-shelf platform, configurable software-as-a-service solution, systems integration engagement, custom development, or combination of these models.

• Obtain recommendations on the most practical initial scope and implementation sequence.

• Understand which functions should be included in a base procurement and which should be deferred, treated as options, or procured separately.

• Identify proven approaches to rider registration, identity assurance, mobile and physical credentials, and utilization tracking in a fare-free or potentially fare-restored environment.

• Understand integration approaches with validators, mobile applications, CAD/AVL, GTFS, APC, business intelligence, payment processors, and future fare collection systems.

• Obtain information regarding cybersecurity, privacy, data minimization, accessibility, continuity, hosting, support, and lifecycle practices.

• Obtain order-of-magnitude information regarding implementation duration, staffing, licensing, hosting, hardware, integration, support, and other major cost drivers.

• Identify procurement and contracting practices that reduce risk and encourage meaningful competition.

• Identify innovations, alternative approaches, and lessons learned that the agency may not have considered.

1.2 What the Agency Is Not Seeking at This Stage

The agency is not requesting binding proposals, firm pricing, final system designs, or proprietary source code.

Respondents are encouraged to challenge assumptions in this RFI and recommend a different approach where industry experience indicates that another model would better achieve the agency's objectives.

2. Program Background and Current Environment Sun Tran, Sun Link Streetcar, and Sun Shuttle operate in an environment where ridership, customer service, planning, safety, performance management, and future fare policy decisions increasingly depend on reliable and usable customer and service information. Existing ridership information is primarily aggregate and does not provide a complete account-based view of individual customer utilization, credential status, eligibility, communications history, or future fare-payment readiness.

The current fare-free environment reduces the immediate need for conventional fare payment, but it also creates an opportunity to consider a rider-account platform separately from a traditional farebox replacement. The agency is interested in whether a customer account and credential platform can provide near-term operational and analytical value while preserving a practical path to future fare collection if policy changes.

2.1 Preliminary Business Drivers

• Establish a modern rider account capability without unnecessarily locking the agency into a single future fare technology.

• Improve understanding of service utilization while preserving appropriate privacy protections.

• Provide riders with practical mobile and non-mobile credential options.

• Improve customer service, account support, and communications.

• Support reliable reporting, dashboards, planning, performance measurement, and grant-related information needs.

• Create a scalable foundation for future eligibility programs, reduced-fare administration, stored value, fare capping, open payments, and regional mobility integration.

• Reduce dependence on fragmented manual processes and disconnected customer information.

3. TAPS Vision and Desired Outcomes TAPS is envisioned as an enterprise customer account platform rather than a stand-alone card database. The agency's preliminary concept includes rider registration, account management, credential management, usage-event capture, administrative tools, reporting and analytics, secure interfaces, and future fare-readiness. The final solution concept may change based on information received through this RFI.

3.1 Desired Outcomes

• A customer-centered experience that is simple, accessible, multilingual where appropriate, and usable by riders with and without smartphones.

• A maintainable account platform that supports fixed-route bus, and streetcar services.

• A solution that minimizes collection and retention of information not necessary for legitimate business purposes.

• Reliable operational and analytical information with documented data ownership and stewardship.

• Open, documented, secure interfaces that reduce unnecessary vendor lock-in.

• A phased implementation that produces useful near-term capabilities and avoids premature investment in functions that may not yet be needed.

• A supportable long-term operating model with clear service levels, lifecycle responsibilities, and predictable recurring costs.

• An architecture that can accommodate future fare policy and regional mobility changes without replacement of the core platform.

4. Preliminary Functional Concept The following capabilities reflect the agency's current thinking. They are presented to support meaningful industry feedback and should not be interpreted as final mandatory requirements. Respondents should identify capabilities they recommend adding, removing, combining, simplifying, or deferring.

Capability Area Preliminary Concept Rider Registration Self-service web/mobile registration; assisted registration; accessible enrollment; duplicate-account controls; exception handling.

Identity / Eligibility Identity assurance or eligibility workflows appropriate to the business purpose; alternatives to broad collection of government-issued identification are specifically welcomed.

Customer Accounts Profiles, contact preferences, status, credentials, history, administrative notes, communications, and controlled account maintenance.

Mobile Credentials QR or other mobile credentials suitable for rider identification and/or validation.

Physical Credentials Cards or other non-smartphone credentials, issuance, replacement, inventory, lifecycle, and association to accounts.

Utilization Tracking Capture of credential-use or boarding events with available route, stop, vehicle, device, and timestamp context.

Customer Service Account search, registration assistance, credential support, issue resolution, controlled access to sensitive fields, and history.

Administration Role-based permissions, business rules, reference data, audit review, notifications, configuration, and operational dashboards.

Reporting / Analytics Standard and ad hoc reporting, exports, BI integration, trend analysis, data-quality reporting, and executive dashboards.

Future Fare Functions Readiness for fare products, stored value, reduced-fare programs, fare capping, payment processing, refunds/adjustments, and revenue reporting.

5. Preliminary Technical and Operational Concept The agency currently anticipates a secure, modular, scalable, cloud-hosted solution with separate non-production and production environments, documented interfaces, configurable roles, auditability, backup and recovery, monitoring, and support. Respondents should describe whether this concept aligns with current industry practice and identify more effective alternatives.

5.1 Questions Embedded in the Technical Concept

• Should the agency procure a single prime contractor, a software platform plus systems integrator, or separate specialized components?

• Which capabilities are mature commercial products, and which typically require custom development?

• What validator or credential-reader architecture is appropriate if the initial objective is usage tracking rather than fare payment?

• What level of offline operation is normally required on vehicles or at stations?

• What data should be captured at validation, and what data should intentionally not be captured?

• What cloud deployment and data-residency models are most common for comparable public-transit systems?

• What are the practical advantages and disadvantages of QR credentials compared with contactless cards, account tokens, open-loop media, or other approaches?

• What implementation responsibilities should remain with the agency, and which should be assigned to the contractor?

6. Information Requested from Respondents Respondents are requested to provide candid, experience-based information. The agency values specific recommendations and tradeoffs more than simple confirmation that a respondent can meet the preliminary concept.

Topic Requested Information Company / Team Company profile; role in the market;

products/services; partner ecosystem; relevant transit experience; U.S. public-sector experience.

Recommended Solution Model Recommended platform and delivery model;

COTS/SaaS/configurable/custom components;

prime/subcontractor structure; hosting model.

Recommended Initial Scope Capabilities to implement first; capabilities to defer;

rationale; minimum viable operational release.

Implementation Approach Discovery, requirements, design, configuration, integration, pilot, testing, deployment, stabilization, and transition approach.

Schedule Typical duration; critical path; dependencies;

agency decisions needed; realistic pilot and production timelines.

Architecture High-level architecture; major components;

validators/readers; mobile and physical credential approach; integration patterns.

Data / Analytics Data model; event capture; BI/reporting; data ownership; portability; retention; data quality;

API/export capabilities.

Cybersecurity / Privacy Security framework; identity/access; encryption;

logging; vulnerability management; privacy-by-design; incident response.

Accessibility Approach to digital accessibility, language access, assisted service, and non-smartphone users.

Support Model Warranty; service desk; SLAs; release management;

patching; monitoring; disaster recovery; lifecycle and technology refresh.

Cost Information Rough Order of Magnitude (ROM) implementation cost ranges; recurring costs; hardware; integration;

licensing; hosting; support; optional capability cost drivers.

Topic Requested Information Procurement Advice Recommended contract structure; pricing model;

evaluation approach; demonstrations; proof-of-concept; negotiations; optional services.

Risks / Lessons Learned Common failure modes; dependencies;

data/privacy risks; adoption issues; vendor-lock-in risks; mitigations.

Innovation Capabilities or approaches the agency should consider that are not reflected in the preliminary

SOW.

7. Recommended Project Delivery and Implementation Approach A central purpose of this RFI is to obtain industry recommendations on how the agency should deliver the project. Respondents should not assume that the task structure in the preliminary SOW is fixed.

7.1 Requested Industry Recommendation

• Recommended procurement packaging and prime-contractor model.

• Recommended discovery and requirements-validation period before final design.

• Recommended proof-of-concept, pilot, or limited-production approach, including what should be proven before full deployment.

• Recommended sequencing of registration, credentials, validators, reporting, integrations, and future fare functions.

• Recommended number and purpose of environments (development, test, training, staging, production).

• Recommended data-migration strategy and whether legacy data should be migrated at all.

• Recommended approach to customer enrollment and adoption.

• Recommended cutover and stabilization period.

• Recommended division of responsibility among agency staff, software vendor, systems integrator, hardware vendor, and other third parties.

• Recommended governance, decision rights, change control, and quality-management structure.

7.2 Preliminary Workstreams for Comment

• Program initiation and governance

• Requirements validation and business-process design

• Solution architecture and detailed design

• Cloud environments and cybersecurity

• Rider registration and account management

• Identity / eligibility workflows

• Mobile and physical credential management

• Validator / reader deployment

• Interfaces and data integration

• Reporting and analytics

• Testing and acceptance

• Training and organizational change

• Pilot and production deployment

• Warranty, support, and lifecycle transition

8. Data, Cybersecurity, Privacy, and Identity Management Because TAPS may contain personally identifiable information and may eventually support payment-related functions, the agency seeks specific industry guidance on security and privacy architecture. Respondents should distinguish controls needed for the initial rider-account and utilization-tracking phase from controls that become necessary if payment functions are added later.

8.1 Identity and Privacy Questions

• What level of identity assurance is actually necessary for basic rider registration and utilization tracking?

• When is government-issued photo identification appropriate, and what lower-data alternatives are commonly used?

• How should youth, riders without identification, visitors, vulnerable populations, and assisted-registration customers be handled?

• What information should be mandatory, optional, or avoided?

• How should duplicate accounts be detected without excessive collection of personal information?

• What retention periods are typical for account, credential, transaction, audit, and identity-verification information?

• Can identity-verification evidence be validated without retaining document images? If so, describe recommended practices.

• How should consent, notices, account deletion, correction, and records requests be handled?

8.2 Cybersecurity Information Requested

• Security architecture and shared-responsibility model.

• Identity and access management, privileged access, and multi-factor authentication.

• Encryption in transit and at rest and key-management practices.

• Audit logging, monitoring, security-event retention, and alerting.

• Secure development lifecycle, vulnerability management, penetration testing, and third-party risk management.

• Incident response, breach notification, recovery, and forensic support.

• Business continuity, recovery time objectives, recovery point objectives, and backup testing.

• Independent security certifications or assessments relevant to the offered service.

• Approach to future payment-card security if open-loop or stored-value payment functions are introduced.

9. Interfaces, Interoperability, and Future Fare Readiness The agency seeks an architecture that can exchange information with existing and future systems through secure, documented interfaces. Respondents should identify which integrations are standard product capabilities, which typically require configuration, and which are custom.

Interface Area Information Requested Mobile / Web Applications Registration, account management, credential presentation, notifications, and support.

Validators / Scanners Credential validation, offline buffering, device health, configuration, and event transmission.

CAD/AVL Trip, route, stop, vehicle, or service context where useful and technically feasible.

Interface Area Information Requested GTFS / GTFS-Realtime Service context and customer-facing integration where appropriate.

APC Reconciliation or comparative analysis of credential events and passenger counts.

Business Intelligence APIs, data exports, semantic models, scheduled extracts, or direct integration.

Identity Services Optional third-party identity or eligibility verification.

Payment Processors Future payment authorization, settlement, tokenization, and related services.

Regional Partners Future shared credentials, account federation, reciprocity, or regional mobility services.

Other Fare Systems Future account-based fare collection, fare engines, or legacy fare equipment.

9.1 Future Fare Strategy Questions

• Should rider-account management and future fare collection be procured as one platform or deliberately separated?

• What design decisions made during the initial fare-free phase would create unnecessary cost or constraints later?

• How should the agency preserve competition for a future fare system?

• What credential media should be used now if future stored value, fare capping, reduced fares, or open payments are possible?

• What account, transaction, and fare-engine boundaries are recommended?

• What should be included as priced options in an initial procurement versus competed later?

10. Operations, Maintenance, Support, and Lifecycle Respondents should describe the operating model they recommend after go-live, including responsibilities for application administration, device support, cloud operations, cybersecurity, releases, configuration, customer support, reporting, and incident management.

• Recommended service desk tiers and escalation model.

• Typical service-level metrics and target ranges.

• Release frequency and approach to backward compatibility.

• Security patching and emergency change processes.

• Device monitoring and field maintenance, if validators/readers are included.

• Backup, disaster recovery, continuity testing, and annual exercises.

• Configuration and change management.

• Knowledge transfer and documentation required to avoid excessive vendor dependency.

• Data extraction and transition assistance at contract end.

• Typical useful life and refresh cycle for field hardware.

• Approach to product roadmap governance and optional enhancements.

11. Commercial, Pricing, and Contracting Information The agency requests non-binding, order-of-magnitude commercial information solely for planning.

Respondents may provide ranges, assumptions, unit pricing structures, or representative pricing models.

Proprietary information should be clearly marked in accordance with applicable law and agency instructions.

Cost Category Requested ROM Information One-Time Implementation Discovery, configuration, design, project management, integrations, testing, deployment, training.

Software Subscription, license, platform, user, account, transaction, or other pricing metrics.

Cloud / Hosting Hosting, storage, data transfer, environments, monitoring, backup, disaster recovery.

Credentials Mobile credential costs, physical cards/media, personalization, issuance equipment.

Field Hardware Validators/readers/scanners, mounts, networking, spares, installation, maintenance.

Integrations Standard connectors, APIs, custom interfaces, third-party fees.

Support Warranty, annual maintenance, service desk, SLAs, managed services.

Optional Future Fare Fare engine, payment gateway, payment processing integration, open payments, fare capping, reduced fare.

Professional Services Hourly rates, task-order services, enhancements, consulting, change management.

Exit / Transition Data export, transition support, documentation, decommissioning.

11.1 Contracting Recommendations Requested

• Recommended initial contract term and renewal/options structure.

• Recommended fixed-price versus time-and-materials allocation by project phase.

• Recommended use of milestones and acceptance-based payments.

• Recommended approach to software subscriptions and price escalation.

• Recommended treatment of third-party services and pass-through costs.

• Recommended warranty period and post-warranty support model.

• Recommended data ownership, configuration ownership, interface documentation, and transition rights.

• Recommended performance guarantees, service credits, or other remedies.

• Any procurement provisions that commonly discourage qualified vendors or unintentionally reduce competition.

12. Vendor Qualifications and Relevant Experience Respondents should provide concise information demonstrating relevant capability and experience.

• Legal company name, headquarters, primary contact, and website.

• Company role: software provider, systems integrator, fare-system provider, consultant, hardware provider, managed-service provider, or other.

• Years providing relevant services and approximate number of comparable active customers.

• Three to five comparable public-transit implementations, preferably identifying agency size, modes, project scope, implementation date, and respondent role.

• Experience with fare-free systems transitioning to account-based capabilities or fare restoration, if applicable.

• Experience with fixed-route bus, streetcar/rail, and paratransit environments.

• Experience integrating with validators, CAD/AVL, APC, GTFS, BI, identity services, and payment systems.

• Key partners or subcontractors normally used for a project of this type.

• Relevant certifications, security attestations, or quality-management practices.

• Reference contacts, if respondents are willing to provide them at the RFI stage.

13. Demonstrations and Follow-Up Industry Engagement The agency may elect to conduct non-competitive informational meetings, demonstrations, or follow-up interviews after reviewing RFI responses. Participation in such activities would be for market research only and would not confer an advantage in any future procurement.

13.1 Potential Demonstration Topics

• Rider self-registration and assisted registration.

• Account administration and customer-service workflows.

• Mobile QR and physical credential lifecycle.

• Validator or reader operation, including offline behavior.

• Reporting, dashboards, exports, and data-quality monitoring.

• Role-based access, audit logs, privacy controls, and administrative security.

• Configuration tools and business-rule management.

• API and integration capabilities.

• Future fare functions, if available.

• Support portal, monitoring, release management, and operational administration.

14. RFI Response Instructions

Item Instructions Response Format Electronic PDF; respondents may also provide an editable copy if permitted by procurement instructions.

Suggested Length Approximately 25–40 pages excluding appendices;

concise responses are preferred.

Due Date To be inserted by the agency.

Submission Method To be inserted by the agency's procurement office.

Questions Submit through the procurement contact and method identified in the issued RFI.

Confidential Information Clearly identify information claimed to be confidential or proprietary; treatment remains subject to applicable public-records law.

Item Instructions Cost to Respond The agency will not reimburse respondents for costs incurred in preparing a response or participating in follow-up market research.

Future Procurement Response or non-response to this RFI will not determine eligibility for any future solicitation unless expressly stated in a future procurement.

15. Agency Questions for Industry

1. What type of company or team is best positioned to serve as the prime contractor for TAPS, and why?

2. Does the market offer a mature commercial platform that meets most of the envisioned needs, or should the agency expect significant systems integration or custom development?

3. What should the agency implement first to create meaningful operational value without overbuilding the system?

4. Which elements of the preliminary Scope of Work should be removed, deferred, or treated as optional?

5. How should the agency approach rider identity assurance? Is government-issued photo identification necessary for the initial use case?

6. What credential technology would you recommend for a fare-free initial deployment that may later support fares?

7. What field hardware, if any, should be deployed during the initial phase?

8. How should TAPS interact with APC and CAD/AVL information without creating unnecessary complexity?

9. What is the recommended architecture for reporting and analytics: embedded tools, agency BI platform, data warehouse/lakehouse, or another model?

10. What are the most significant privacy risks in linking rider identities to trip or boarding activity, and how should the project mitigate them?

11. What cybersecurity standards, certifications, or independent assessments should the agency require?

12. What implementation duration is realistic from notice to proceed through stable production operations?

13. What agency staffing and subject-matter expertise will be required during implementation and after go-live?

14. Should the agency require a pilot? If so, what should the pilot prove and how long should it operate?

15. What are the major cost drivers, and where can the agency simplify scope to control lifecycle cost?

16. What pricing model provides the best transparency and predictability for this type of system?

17. What contract structure best preserves competition for future fare collection and payment capabilities?

18. What data ownership, API, documentation, and exit provisions are essential to avoid vendor lock-in?

19. What are the most common reasons comparable transit technology projects fail or experience major delays?

20. What performance measures and service levels should be included in a future contract?

21. What should the agency require for disaster recovery, continuity, and offline operations?

22. What customer adoption and change-management activities are essential?

23. What accessibility and non-smartphone alternatives should be designed into the program from the beginning?

24. What future capabilities should the agency architect for now but avoid purchasing until needed?

25. What important question has the agency not asked in this RFI?

Appendix A – Preliminary Capability Matrix Capability Preliminary Status RFI Feedback Requested

Registration Base concept Industry recommendation requested

Customer account management Base concept Industry recommendation requested

Identity / eligibility assurance Base concept, approach not finalized

Industry alternatives specifically requested

Mobile credential Base concept Recommend technology and lifecycle

Physical credential Base concept Recommend media and issuance model

Utilization event capture Base concept Recommend data and hardware architecture

Customer service tools Base concept Recommend workflows and integration

Reporting / analytics Base concept Recommend embedded vs enterprise BI approach

Cybersecurity / privacy Base concept Recommend control framework and certifications

Interfaces / APIs Base concept Recommend standards and integration patterns

Stored value / fare products Future option Recommend architecture and procurement timing

Fare capping / reduced fare Future option Recommend architecture and procurement timing

Open payments Future option Recommend architecture and procurement timing

Regional interoperability Future option Recommend governance and technical approach

Mobility as a Solution (MaaS) / emerging mobility

Future option Recommend whether to architect now

Appendix B – Preliminary Implementation Workstreams Workstream Preliminary Description

1 Program initiation, governance, and project controls 2 Requirements validation and business-process design 3 Architecture and detailed system design 4 Cloud environments, cybersecurity, privacy, and continuity 5 Registration, identity/eligibility, and customer accounts 6 Mobile and physical credentials 7 Validators/readers and field infrastructure, if required 8 Interfaces, data integration, reporting, and analytics 9 Testing, training, change management, and documentation 10 Pilot, deployment, stabilization, and operational transition 11 Warranty, maintenance, support, and lifecycle management 12 Optional future fare and regional mobility capabilities

Appendix C – Respondent Information Form Field Respondent Information

Company Name Headquarters Primary Contact Title Email / Phone Website Company Type / Role Proposed Prime Contractor Proposed Key Partners Relevant Transit Customers Available for Follow-Up Meeting / Demo Yes / No

Appendix D – Suggested Response Format

1. Cover Letter and Respondent Information

2. Executive Summary

3. Understanding of the TAPS Opportunity

4. Recommended Solution and Delivery Model

5. Recommended Initial Scope and Phasing

6. Technical Architecture and Credential Strategy

7. Data, Cybersecurity, Privacy, and Identity Approach

8. Interfaces and Future Fare Readiness

9. Implementation Approach and Schedule

10. Operations, Support, and Lifecycle Model

11. Commercial Model and ROM Cost Information

12. Relevant Experience and References

13. Risks, Lessons Learned, and Procurement Recommendations

14. Innovations / Alternative Approaches

15. Responses to the Agency Questions for Industry

16. Exceptions, Assumptions, and Additional Comments

Closing Statement The agency appreciates industry participation in this market research effort. The information received will be used to refine the TAPS concept, determine an appropriate procurement and implementation strategy, develop realistic requirements and budgets, identify risks, and decide whether and how to proceed with a future solicitation.