TTC Request For Pre-Qualifications

TORONTO TRANSIT COMMISSION
REQUEST FOR PRE-QUALIFICATION STATEMENTS
OPEN STANDARDS-BASED FARE PAYMENT SYSTEM
REFERENCE NO: R39PN10871
Submit complete Pre-Qualification Statement package to:

Toronto Transit Commission
Materials and Procurement Department
Project Procurement Section
5160 Yonge Street, 6th Floor
Toronto, Ontario
M2N 6L9
Attention: Joanna Raimondo

Senior Contract Administrator
To be received by the TTC no later than 4:00 p.m. on Friday, September 10, 2010, Please submit
one (1) original and six (6) copies of the Submission.
Table of Contents
PAGE
1. INTRODUCTION...............................................................................................................................1
2. DEFINITIONS ....................................................................................................................................1
3. PROCUREMENT SCHEDULE ...........................................................................................................1
4. RESERVED RIGHTS OF THE COMMISSION ..................................................................................2
5. EVALUATION CRITERIA..................................................................................................................2
6. SUBMISSION REQUIREMENTS.......................................................................................................2
7. DRAFT SCOPE OF WORK ............................................................................................5
Appendix A – Corporate Information

Appendix B – Joint Venture (if applicable)
Appendix C - Detailed Technical Submittal Information
Appendix D – Declaration Statement
TORONTO TRANSIT COMMISSION PRE-QUALIFICATION STATEMENT
Open Standards-Based Fare Payment System
Reference No. : R39PN10871 Page 1
1. INTRODUCTION
The Toronto Transit Commission is soliciting from interested parties Pre-Qualification Statement
Packages to establish a list of pre-qualified bidders to participate in a procurement process for the
funding, acquisition, installation, operation, repair, and maintenance of a new, open standards-based
fare payment system.
Respondents must demonstrate they meet all the requirements listed in the submission requirements
to the satisfaction of the Commission in order for them to be considered qualified and short listed to
participate in a Structured Multi Phase Bid Process (SMPBP). SMPBP is a process in which the
technical and commercial requirements are discussed with all qualified potential proponents to
finalize requirements prior to a formal Request for Proposal.
2. DEFINITIONS
• The Commission: The Toronto Transit Commission.

• TTC: The Toronto Transit Commission.
• Respondent: The party or parties submitting the pre-qualification statement.
• Proponent: The party or parties submitting the pre-qualification statement and evaluated and
judged as pre-qualified.
• Consultant: The successful proponent submitting a proposal for the open standards-based
fare payment system.
• Project: Refers to open standards- based fare payment system.
• Work: services or any part thereof, required by the contract for the Project.
3. PROCUREMENT SCHEDULE
Following is the proposed procurement schedule which is subject to change at the discretion of the
TTC:
Issue Request for Pre-Qualification Statements August 9, 2010

Issue draft Commercial Terms August 23, 2010
Close Request for Pre-Qualification Statements September 10, 2010
Evaluate Pre-Qualification Statement Submissions September 17, 2010
Kick Off Meeting with Proponents (review September 24, 2010
SMPBP process)
Issue draft Request for Proposal Documents September 24, 2010
to Proponents
Conduct confidential meetings with Proponents October 4-8, 2010
Conduct meetings/negotiate commercial terms October 11-22, 2010
Issue Request for Proposal October 25, 2010
(final technical and commercial terms)
Proposal responses due October 29, 2010
Complete Proposal Evaluation obtain authorization
and Contract award November 30, 2010
4. RESERVED RIGHTS OF THE COMMISSION

The Commission, at its sole discretion, may request clarifications or request additional information,
as deemed necessary to evaluate the Pre-qualification Statement Package submissions.
The Commission retains the sole discretion to determine whether a submission is responsive and if
the Respondent is capable of performing the Work of the contract.
The Commission reserves the right, at its sole discretion, to determine the number of pre-qualified
Proponents.
The Commission reserves the right to not proceed with a Request for Proposal.
5. EVALUATION CRITERIA
Submissions will be evaluated on the basis of the information provided by the Respondent. Each
submission will be re viewed to determine if the submission is responsive to the submission
requirements outlined herein. Selection of Proponents will be based on the pass/fail criteria listed
herein and relevant information provided by the Respondent in fulfillment thereof.
Respondents who fail to provide any of the information/documentation required under the
“Submission Requirements” below may have their submissions rejected without further evaluation.
The Respondent should exercise care when completing its submission as failure to complete the
documents fully or to provide all information required will affect the evaluation of its submission and
may cause its submission to be rejected.
The Respondent must ensure that all information provided is correct, as it may be investigated by
the Commission.
6. SUBMISSION REQUIREMENTS
In addition to the signed Appendix D – Declaration Statement, the Respondent is requested to
submit the information listed below in order for their submission to be considered and such
information shall be evaluated based on meeting the requirements. Respondents are requested to
structure their submission in accordance with the categories listed below:
A. Cover Page (to include identification of all Team Members)

B. Cover Letter (2 pages maximum)
C. Table of Contents
D. Executive Summary (Optional)
E. Corporate and Team Information
.1 Corporate Information – use Appendix A to the Pre-Qualification Statement
.1 Provide a single contact person for all future communication between TTC and
the respondent. Please identify the contact person’s name, title, organization,
address, telephone number, fax number, and email address.
.2 Provide a summary of relevant corporate experience of the Respondent. The

information requested shall specifically highlight the following areas:
- Background and capabilities;

- Number of years in business;
- Depth of available relevant resources;
- Relevant corporate experience completed since 2000, including the
following:
- Project Name and Location;
- Client Reference Name & Phone No.;
- Other Major Consulting/Subconsulting Participants;
- Project Capital Cost CDN$;
- Project Duration;
- Description of the Project;
- Description of Services Provided;
.3 If the Pre-qualification Statement is being submitted by a Joint Venture, one

Corporate Summary should be completed that includes all requested information
for each of the Joint Venture participant. Complete Appendix B – Joint Venture
and submit as part of the Pre-qualification Statement. One of the joint venture
participants shall be nominated as being the principle in charge during the pre-
qualification process. The principle in charge shall be authorized by the other
joint venture participants to receive instructions for and on behalf of any and all
participants of the joint venture. Each joint venture participant shall demonstrate
its authorization of the participant in charge by submitting with the Pre-
qualification Statement a letter signed by a legally authorized representative of
each joint venture participant.
.2 Team Information
A summary of the directly related and relevant experience and qualifications of the
proposed Program Manager(s), Project Manager(s), and Design Engineer, as well as all
key proposed project team members (including Subconsultant staff). The resumes
should be tailored to specifically highlight relevant professional and academic
qualifications and experience on projects similar to or directly related to the Scope of
Work of this Prequalification Statement.
The information requested shall specifically highlight the following areas:
- number of years of direct experience;
- technical qualifications, including academic qualifications and professional
associations;
- a list of relevant experience for each key project team member specifically
highlighting their relevant experience and qualifications, roles and
responsibilities, description of the project, services provided, complexity, etc.
- a list of each Team Member’s references. These references should be able to
describe the relevant qualifications and capabilities of Team Members seeking
to take a leading role to design, operate and maintain the TTC’s transit fare
collection operation.
.4 Controlling Interest: Identify the individuals or companies who hold an interest in each
Team Member.
.5 Financial Information: Please produce information sufficient to document financial

viability and the ability to perform the services requested including but not limited to
Audited Financial Statements.
.6 Expected Advisors: Identify the companies and individuals who are expected to act as
legal, financial, or other advisors for the Team.
F. Open Fare System – Project Methodology and Approach to the Work
Each submission shall be clearly designed and presented with the goal of allowing the TTC to readily
ascertain if the proposed Project Methodology and approach to the Work will accomplish the TTC’s
goals for this transaction as described in the Scope of Work. The technical aspects of the proposed
Project Methodology and Approach to the Work must be as detailed as possible to help in this
endeavor. Respondents are encouraged to discuss items such as: project understanding, approach to
the work, schedule, challenges and solutions to the design, operating and maintenance, etc. Please
also provide a preliminary work flow process map which identifies the entire proposed Open Fare
System with the different service provider and Team Member functionality identified with the
process map.
H. Detailed Technical Submittal Information
When preparing submissions, TTC requires that the Respondent addresses in specific terms and
provide detailed discussion, that addresses each of the criteria listed in Appendix C - Detailed
Technical Submittal Information for the evaluation process, as well as other discussion that
demonstrates the Respondent’s responsiveness to requirements of the Scope of Work. In addition,
respondents are required to complete Appendix C by providing a specific reference(s) to sections
and/or pages in their submission that addresses each of the listed evaluation criteria. Additionally,
the respondent must state whether the section addresses the evaluation criteria by indicating a
“yes” or “no” answer in the column provided.
END OF DOCUMENT
APPENDIX A – CORPORATE INFORMATION
PRE-QUALIFICATION STATEMENT
REFERENCE NO. R39PN10871
Company Name: ___________________________________________
Registered Address: ________________________________________
Contact Name and Title: ______________________________________________
Telephone No.: ______________________________________________
Fax No.: ____________________________________________________
Email Address: _______________________________________________
PROPONENT’S RESPONSE
1. CORPORATE PROFILE
a) Background and capabilities
b) Number of years in business
c) Depth of available relevant

resources
2) RELEVANT CORPORATE
EXPERIENCE
END OF DOCUMENT
Appendix A – Page 1 of 1
APPENDIX B – JOINT VENTURE
REFERENCE NO. R39PN10871
NAMES OF COMPANIES
FORMING JOINT VENTURE
NAME OF JOINT VENTURE

(if applicable)
NAME OF PARTICIPANT IN
CHARGE
EACH JOINT VENTURE PARTICIPANT SHALL ATTACH LETTER OF AUTHORIZATION AS DETAILED IN SECTION 6, E, 3.
END OF DOCUMENT
APPENDIX A – Page 1 of 1
Pre-Qualification Statement
Reference No. R39PN10871
INSTRUCTIONS: Provide specific references to the section(s) and page(s) where each of the evaluation criteria are addressed and documentation of
compliance is provided.
Reference to Specific Section of

Respondent's Response where Compliance
with Criteria is Addressed and Documentation
Technical & Operating Qualifications Assessment is Provided
Section of Response (pg. Section Addresses

# or Sect.) Specifically (Y/N)
Category A Criteria
Is the proposed solution based on open standards of the financial services and payments industry?
Is the proposed solution based on an open architecture?
Is the proposed solution account-based?
Is the proposed solution "online" and, therefore, configured to authorize transactions in real-time (within the transaction
speeds described in the Scope of Work)?
Does the proposed solution account for and provide a solution to all data communications networks required for real-
time communications at subway and surface locations?
Does the proposed solution include a pre-paid, contactless card program that is free of fees when used for TTC transit
services (including a pervasive card issuance and reload network across the TTC's system, as well as through Toronto
area retail locations)?
Does the proposed solution implement contactless readers on every powered turnstile?
Does the proposed solution implement contactless readers on every surface vehicle?
Does the proposed solution implement a proof-of-payment ("POP") system (equipment and procedures) for streetcars
and LRV's?
Does the proposed solution include open-loop pre-paid, contactless card vending machines (with reload capabilities) in
every TTC station?
Does the proposed solution enable the TTC to satisfy all applicable Payment Card Industry ("PCI") requirements?
Does the proposed solution enable the TTC to satisfy all applicable privacy standards?
Does the proposed solution (and accompanying business terms) protect the TTC against revenue losses, such as
equipment and system outages that would result in revenue losses?
Page 1 of 4


Does the proposed solution (and accompanying business terms) provide functionality and economic assurances to
track, audit, and remit all TTC revenues?
monitor, control, and eliminate customer chargeback risk for the TTC?
Does the proposed solution include a business continuity plan and processes?
monitor, control, and eliminate fraudulent transaction risk for the TTC?
Does the proposed solution provide a customer support operation in the form of a web site and customer service call
center?
Does the proposed solution provide necessary maintenance support for the operation of the equipment and
infrastructure and performance measures that allow tracking of operational and business outcomes?
Does the proposed solution comply with all Canadian banking laws, rules, and regulations, including INTERAC?
Does the proposed solution leverage COTS equipment and services?
Does the proposed solution enable TTC to accept media complying with the EMV standard?
Does the proposed solution address all TTC accessibility requirements, including AODA and appropriate legal
requirements?
Is the proposed solution for the OSFS modular, allowing components and sub-systems to be easily replaced, or
operated by TTC or a third party?
Is an implementation and deployment plan consistent with Section 6 of the Scope of Work provided?
Does the proposed solution enable the distribution, sale, and processing of all TTC fare products, including all
concession and non-concession fares?
Does the proposed solution allow TTC to control, modify, and create their fares and fare policies independently of the
Private Partner?
Does the proposed solution provide for fare enforcement by Special Constables?
Page 2 of 4


Does the proposed solution account for all financial certifications and auditing requirements for an open standards
payments system?
Does the proposed solution allow TTC to audit fully all payment and usage transactions?
Does the proposed solution demonstrate compliance with the performance metrics described in Section 12 of the Scope
of Work?
Does the proposed solution allow TTC to monitor and report on performance metrics?
Does the proposed solution provide a test and quality assurance plan (including support for test facilities) for validating
the operational, business, and technical outcomes required by TTC?
Does the proposed solution include a Data Mart that can be independently operated by the TTC and accommodate
TTC's business requirements?
Does the potential Private Partner possess relevant technical and operational experience to meet the requirements
expressed in the RFPQ Scope of Work (e.g. has operated a Level 1 volume payment card processing operation, has
installed point of sale equipment in a Level 1 merchant environment, has operated and maintained a point of sale
network (in compliance with financial and payment industry rules and regulations) in a Level 1 merchant environment)?
Category B Criteria
If the proposed solution includes a pre-paid, contactless card program, does program include a retail sales and reload
network equal to/or greater than the current number of TTC ticket agent locations?
Is the proposed solution accompanied by a detailed project plan and project management team structure that supports
TTC's desired implementation timeline and system program management requirements?
Does the proposed solution permit a fare payment solution for cross-boundary travel?
Does the proposed solution account for a PRESTO system in the Greater Toronto Area?
Does the proposed solution accommodate the single fare cash user on all surface and subway vehicles?
Page 3 of 4


Category C - Financial Qualifications Assessment
Did the proposer provide a capital plan that clearly delineates all sources and amounts of capital required to finance: a)
the acquisition of all equipment, software, and accompanying infrastructure to implement an open standards-based
payment system at the TTC, and; b) operate, maintain, and - if necessary - refresh all equipment and infrastructure that
comprises the open standards-based payment system?
Does the proposal demonstrate a commitment to underwrite the required capital costs?
Does the proposer clearly describe its organizational and operating structure (e.g. is the proposer structured as a legal
partnership, or as a prime contractor assembling appropriate organizations as sub-contractors)?
Depending on the proposer's organizational and operating structure, does the proposer provide a financial guarantee
(e.g. performance bond or parent organization guarantee)?
Page 4 of 4
APPENDIX D – DECLARATION STATEMENT
Reference NO. R39PN10871
The following Declaration is to be checked off and signed by an officer(s) of the Respondent.
I/ We hereby declare that the information provided herein is true and correct to the best of
my/our knowledge. I/ We further acknowledge that false statements on the application will
result in rejection of this application and restriction from participating on any subsequent
Request for Proposals, for the Open Standards-Based Fare Payment System.
Name _________________________________ Title _______________________________
Signature _________________________________ Date _______________________________
Name _________________________________ Title _______________________________
Signature _________________________________ Date _______________________________
Name _________________________________ Title _______________________________
Signature _________________________________ Date _______________________________

TORONTO TRANSIT COMMISSION
Open Standards-Based
Fare Payment System
DRAFT SCOPE OF WORK
AUGUST 9, 2010
Table of Contents
1 Open Standards Fare System............................................................................................................ 9

1.1 Introduction ............................................................................................................................. 9
1.1.1 Market Opportunity and Background................................................................................ 9
1.1.2 Technical and Operating Overview................................................................................. 10
1.2 Objectives for the OSFS......................................................................................................... 11
1.2.1 Transaction Structure and Business Requirements .......................................................... 11
1.2.2 Customer Experience Requirements ............................................................................... 14
1.3 Current Operating Scenarios................................................................................................... 15
1.3.1 Additional Considerations .............................................................................................. 17
1.4 Abbreviations and Definitions ................................................................................................ 18
1.4.1 Abbreviations ................................................................................................................. 18
1.4.2 Definitions ..................................................................................................................... 20
2 OSFS Technical Requirements ...................................................................................................... 29
2.1 Overview ............................................................................................................................... 29
2.2 Description of Key System Components................................................................................. 30
2.3 Compliance with Standards, Codes, Laws, and Applicable Certifications ............................... 31
2.3.1 Standards for Payment Processing .................................................................................. 32
2.3.2 Standards for Manufacture of Equipment to be Installed on TTC Property ...................... 33
2.3.3 Standards for Design and Implementation of Software for Implementation on TTC
Property ....................................................................................................................................... 33
2.4 General Design Requirements ................................................................................................ 34
2.4.1 Compliance with Laws Offering Protections for Disabled Persons .................................. 34
2.4.2 Operating Design............................................................................................................ 34
2.4.3 Environmental Guidelines for Installations ..................................................................... 35
2.4.4 Electrical Requirements.................................................................................................. 37
2.5 General Structural and Material Requirements........................................................................ 39
2.5.1 Hardening against Vandalism and Fraud......................................................................... 39
2.6 Software ................................................................................................................................ 39
2.7 Operating Standards Compliance............................................................................................ 41
2.8 Revenue Security and Servicing ............................................................................................. 41
Page 2
2.8.1 Revenue Accountability.................................................................................................. 41
2.8.2 Revenue Servicing.......................................................................................................... 42
2.8.3 Bill /Coin Acceptance Configuration .............................................................................. 42
2.9 Equipment / System Reliability Standards .............................................................................. 43
2.9.1 Fare Media Vending Device ........................................................................................... 43
2.9.2 Reader Assembly for Surface Vehicles ........................................................................... 44
2.9.3 Reader Assembly for Installation in Subway Stations...................................................... 44
2.9.4 Central Processor............................................................................................................ 45
2.10 Maintenance Requirements .................................................................................................... 45
2.10.1 Corrective Maintenance.................................................................................................. 46
2.10.2 Preventive Maintenance.................................................................................................. 47
3 Business Processes and Functional Requirements of the OSFS....................................................... 48
3.1 Revenue Assurance ................................................................................................................ 48
3.1.1 Fare Acceptance ............................................................................................................. 48
3.1.2 Fare Calculation ............................................................................................................. 49
3.1.3 Transaction Processing for Single Trips (PAYG) ............................................................ 56
3.1.4 Pre-Funded Transactions ................................................................................................ 59
3.1.5 Customer Support for Fare Payment ............................................................................... 59
3.2 Processes Specific to Transit Merchants ................................................................................. 64
3.2.1 Automatic Reload of Transit Accounts ........................................................................... 64
3.2.2 Customer Claims (Non-Chargeback) Intake and Processing............................................ 64
3.2.3 Risk Mitigation............................................................................................................... 66
3.2.4 Business Processes in Support of Revenue Assurance..................................................... 69
3.3 Business Intelligence Reporting and Processing ..................................................................... 73
3.3.1 Transactional Integrity Processing .................................................................................. 73
3.3.2 Operations Performance ................................................................................................. 74
3.4 Customer Satisfaction ............................................................................................................ 78
3.5 Central Processor ................................................................................................................... 78
3.5.1 Overview........................................................................................................................ 78
3.5.2 General Requirements .................................................................................................... 79
3.5.3 Fare Rules Engine .......................................................................................................... 81
3.5.4 Automated Reload of Transit Accounts........................................................................... 82
Page 3
3.5.5 Data Mart ....................................................................................................................... 82
4 Marketing and Customer Communications for New OSFS............................................................. 90
4.1 Overview ............................................................................................................................... 90
4.2 Requirements ......................................................................................................................... 91
4.2.1 TTC’s Customer Base .................................................................................................... 91
4.2.2 Issuer Support Requirements .......................................................................................... 92
4.2.3 Merchant Support Requirements..................................................................................... 92
4.2.4 Private Partner Affiliates ................................................................................................ 93
4.3 Scope of Campaign ................................................................................................................ 93
4.3.1 TTC In-Home................................................................................................................. 93
4.3.2 TTC Guidelines for Advertising and Promotions ............................................................ 95
4.3.3 Graphics Inventory ......................................................................................................... 95
4.3.4 Duration of Campaign .................................................................................................... 95
5 Operating Procedures for New OSFS............................................................................................. 95
5.1 Maintenance Support ............................................................................................................. 95
5.1.1 Maintenance Management System.................................................................................. 95
5.1.2 Field Support.................................................................................................................. 96
5.2 Customer Support .................................................................................................................. 98
5.2.1 Applicable TTC Customer Service Policies .................................................................... 99
5.3 Training for TTC Employees................................................................................................ 101
6 Implementation Plan for OSFS .................................................................................................... 101
6.1 Overview ............................................................................................................................. 101
6.2 Summary Deployment Plan.................................................................................................. 102
6.2.1 Phase I Deliverables ..................................................................................................... 103
6.2.2 Phase II Deliverables .................................................................................................... 104
6.3 OSFS Launch....................................................................................................................... 109
7 Subway Environment................................................................................................................... 109
7.1 General ................................................................................................................................ 109
7.1.1 Functionality of Fare Gates in New OSFS..................................................................... 109
7.1.2 Overview of Current TTC Fare Gates ........................................................................... 110
7.1.3 Release of Fare Gate for Entry...................................................................................... 110
7.1.4 Fare Gate Messaging and Displays to Customers .......................................................... 113
Page 4
7.1.5 Message Sets................................................................................................................ 113
7.1.6 Permanent Graphics...................................................................................................... 113
7.1.7 Audible Tones .............................................................................................................. 114
7.1.8 Stand Alone or “Orphan Mode” Operation.................................................................... 114
7.1.9 Passback Control .......................................................................................................... 115
7.2 Fare Media Vending Devices or Kiosks for Open Standards System..................................... 115
7.2.1 Overview...................................................................................................................... 115
8 Surface Vehicles.......................................................................................................................... 132
8.1.1 Overview...................................................................................................................... 132
8.1.2 Fare Payment Processing .............................................................................................. 133
8.1.3 Reader Assembly Functional Requirements .................................................................. 134
8.1.4 Transaction Processing ................................................................................................. 135
8.1.5 Hardware Requirements ............................................................................................... 140
9 Other TTC Locations ................................................................................................................... 145
9.1.1 Overview...................................................................................................................... 145
9.1.2 Concept of Operations .................................................................................................. 145
9.1.3 Equipment.................................................................................................................... 146
9.1.4 Customer Agents .......................................................................................................... 146
9.1.5 Equipment Maintenance ............................................................................................... 148
9.2 Non-TTC Retail Sales and Distribution Locations ................................................................ 150
9.2.1 Overview...................................................................................................................... 150
9.2.2 Concept of Operations .................................................................................................. 150
9.2.3 Business and Functional Requirements ......................................................................... 151
9.2.4 Financial Settlement ..................................................................................................... 155
9.3 Test Lab............................................................................................................................... 155
9.4 Installation Requirements..................................................................................................... 156
9.4.1 General Guidelines for TTC On-Site and for Legacy LRV Installations ........................ 156
9.4.2 On-Site Installation Support.......................................................................................... 156
9.4.3 Surface Vehicle Equipment .......................................................................................... 157
9.4.4 In-Station Equipment.................................................................................................... 158
10 Customer Service Call Centre .................................................................................................. 159
10.1 Overview of Operation......................................................................................................... 159
Page 5
10.2 Concept of Operations.......................................................................................................... 159
10.3 Functional Requirements for the IVR System ....................................................................... 160
10.3.1 IVR System Customer Support ..................................................................................... 160
10.3.2 IVR Design Features .................................................................................................... 160
10.3.3 Voice Recognition Technology..................................................................................... 161
10.3.4 Customer Agents .......................................................................................................... 161
10.3.5 Training ....................................................................................................................... 161
10.3.6 Call Scripts................................................................................................................... 162
10.4 CSCC Performance Standards .............................................................................................. 162
11 Website for New Open Fare Payment System .......................................................................... 163
11.1 Overview ............................................................................................................................. 163
11.2 Concept of Operations.......................................................................................................... 163
11.3 Functional Requirements...................................................................................................... 164
11.3.1 Key Functionalities....................................................................................................... 164
11.3.2 Design and Customer Interfaces ................................................................................... 165
11.3.3 Payment Transaction Processing................................................................................... 166
11.3.4 Multilanguage .............................................................................................................. 166
11.3.5 Configuration of Website.............................................................................................. 166
11.3.6 Database....................................................................................................................... 167
11.3.7 Customer Access to Account Information ..................................................................... 167
11.3.8 Sales and Reload .......................................................................................................... 168
11.3.9 Compliance with Applicable Laws and Regulations Concerning Sale and Use of GPR
Devices ..................................................................................................................................... 169
11.3.10 Accepted Forms of Payment ..................................................................................... 170
11.3.11 Understanding Billing Statements from My Financial Institution............................... 170
11.3.12 Sales and Reload Locations ...................................................................................... 170
11.3.13 Security, Privacy and Technology............................................................................. 170
11.3.14 Frequently Asked Questions ..................................................................................... 170
11.3.15 Website Cookies....................................................................................................... 170
11.3.16 Design Features and Creative Content....................................................................... 171
11.3.17 Performance Requirements ....................................................................................... 171
11.3.18 Website Availability ................................................................................................. 171
Page 6
11.3.19 Website Response Times .......................................................................................... 171
11.3.20 Transaction Volumes ................................................................................................ 171
11.3.21 Security .................................................................................................................... 171
11.3.22 Testing ..................................................................................................................... 172
11.3.23 Documentation ......................................................................................................... 172
11.3.24 Use of TTC’s Logos and Trademarks........................................................................ 172
11.3.25 Use of Information about TTC Operations ................................................................ 172
12 Performance Standards ............................................................................................................ 172
12.1 Overview ............................................................................................................................. 172
12.2 Sales Availability ................................................................................................................. 174
12.3 System Component Performance.......................................................................................... 174
12.3.1 Transaction Processing ................................................................................................. 174
12.3.2 Central Processor.......................................................................................................... 175
12.3.3 Data Mart ..................................................................................................................... 175
12.3.4 Network Communications ............................................................................................ 175
12.3.5 Website ........................................................................................................................ 176
12.3.6 Customer Call Centre ................................................................................................... 176
12.3.7 Equipment.................................................................................................................... 176
12.3.8 Field Maintenance ........................................................................................................ 177
12.3.9 Business Operations ..................................................................................................... 177
13 System Program Management.................................................................................................. 179
13.1 Overview ............................................................................................................................. 179
13.2 PMO Team .......................................................................................................................... 179
13.3 Project Plan.......................................................................................................................... 180
13.3.1 Program Launch ........................................................................................................... 182
13.3.2 Weekly Progress Meetings ........................................................................................... 182
13.4 Project Plan Reporting and Documentation .......................................................................... 182
13.5 Quality Assurance Plan ........................................................................................................ 183
13.5.1 Plan Requirements........................................................................................................ 183
13.5.2 Quality Assurance Supervisor....................................................................................... 185
13.6 Design Review Process ........................................................................................................ 185
13.6.1 Conceptual Design Review (CDR) Process................................................................... 186
Page 7
13.6.2 Preliminary Design Review .......................................................................................... 186
13.6.3 Final Design Review .................................................................................................... 187
13.6.4 Project Closeout/OSFS Operational Phase .................................................................... 187
14 Testing Methodology/Master Test Plan .................................................................................... 187
14.1 Overview ............................................................................................................................. 187
14.2 Test Plan.............................................................................................................................. 188
14.2.1 Test Plan Scope ............................................................................................................ 189
14.2.2 PCI Compliance Certification ....................................................................................... 191
14.2.3 Scope of Friendly User Test.......................................................................................... 191
14.3 Performance Measures ......................................................................................................... 193
14.4 Evaluation of Test Results.................................................................................................... 193
14.4.1 Chargeable Failures...................................................................................................... 194
14.4.2 Non-Chargeable Failures .............................................................................................. 194
Appendix A: Overview of TTC’s Current Fare Collection System ....................................................... 195
Appendix B: Wheel-Trans Services ..................................................................................................... 202
Appendix C: Proof of Payment Concept of Operations - Current Light Rail Vehicle Operations.......... 203
Appendix D: TTC Turnstile Information............................................................................................. 207
Appendix E: Transit City..................................................................................................................... 211
Page 8
1 Open Standards Fare System
1.1 Introduction
The Toronto Transit Commission (“TTC”) seeks a public-private partnership (the
“Transaction”) with one or more private sector partners (the “Private Partner”) relating to the
funding, acquisition, installation, operation, repair, and maintenance of a new, open standards-
based fare system (the “OSFS”). TTC requires that the OSFS rely on generally-accepted
business processes and the technical standards of the financial payments industry. It is expected
that the OSFS will coexist with TTC’s existing fare collection system (the “Current System”) for
an initial transition period and, with the exception of acceptance of cash at fare-boxes,
subsequently replace use of the Current System. This document will discuss the TTC’s value
proposition to potential Private Partners, as well detail the technical and operating requirements
and functionality of the OSFS.
1.1.1 Market Opportunity and Background

The TTC is the third largest public transit system in North America (behind the New York City
Transit and the Mexico City Metro systems) providing approximately 1.5 million paid rides, on
average, per day, or roughly 475 million annually. While the individual values related to these
transactions may be small – an attribute the TTC shares with other retail environments across the
Greater Toronto Area (the “GTA”) – collectively these smaller transactions represent a
significant market opportunity. Generally known as “micro-” or “low-value” payments,
consumer transactions valued at less than $5 accounted for approximately $6 trillion in consumer
spending in 2007. The potential revenue opportunity from using technology to efficiently
process micro-payments, coupled with businesses’ and consumers’ desire to improve transaction
speeds and convenience, are driving the replacement of cash transactions in many venues with
electronic payments, particularly using contactless payment options.
Due to a captive clientele, public transit providers like the TTC are well positioned to drive the
rapid and widespread adoption of innovative contactless payment usage. Contactless fare
collection systems are being implemented across the world in order to achieve more efficient
public transit operations. The TTC’s vast physical infrastructure and extensive transit routes are
surrounded by thousands of retail and other service outlets that thrive on micro-payment
transactions. Accordingly, if the TTC were to transition to an innovative contactless fare
collection system, the resulting change in its more than 700 thousand customers’ payment
behaviour and preferences may profoundly influence more general consumer payment use for
everyday retail purchases across the GTA.
Public transit offers private sector businesses (“Prospective Partners”) a highly favourable
opportunity for converting micro-payments from cash to electronic payment methods. Currently,
the TTC conducts an average of 1.5 million micro-payment transactions per day, or nearly 475
Page 9
million on an annual basis. At the same time, budget constraints and competition from other
modes of transportation are prompting public transit systems like the TTC to find innovative
ways to reduce expenses, fund needed capital investments and increase revenues by improving
customer travel experiences. Contactless payment technologies offer a way to achieve these
goals and create a “win-win-win” proposition for the TTC, its customers, and the financial
services industry. Cost, however, is still a major consideration in the decision to utilize this
new payment technology. The challenge for the TTC is determining how to best balance the
long-term benefits against the near-term capital investment required to introduce innovative
fare payment options.
With this in mind, the TTC has engaged The KMA Group, LLC (“KMA”) as lead advisor to
assist the TTC in connection with the solicitation and evaluation of proposals from Prospective
Partners for the OSFS. The TTC’s business, technical, and functional requirements for the OSFS
are discussed in detail in subsequent sections of this document, but it considers an open system
as any automated fare payment system that accommodates several types of contactless media;
some of which may also be used to purchase consumer goods from retail vendors other than the
TTC. These include bank issued contactless credit and debit cards, open-loop general purpose
reloadable contactless cards (“GPR”), and other contactless payment devices, such as Near Field
Communications (“NFC”)-enabled mobile phones. It also includes business solutions that offer
alternative means for initiating person-to-person, or person-to-business payment transactions, but
that ultimately rely on open standards systems and networks to complete an electronic exchange
of funds.
Subject to Commission approval, the TTC is committed to adoption of open standards

technology and systems that relieve TTC of the operational and business requirements associated
with the issuance and support of its own, unique proprietary fare media and payment system. As
such, the TTC seeks a partnership with a Private Partner that has broad experience and expertise
in contactless micro- or low-value payment systems. The goal of this procurement process will
be to identify optimal technologies and associated business terms for the OSFS system through
an interactive and collaborative procurement process with Prospective Partners.
1.1.2 Technical and Operating Overview

The TTC is issuing this Request for Pre-Qualifications (the “RFPQ”) for the purpose of
procuring the OSFS and requisite business and operations support services. This new system
will be designed and implemented to use and conform with established financial and payments
industry open standards for an account-based payment system. It will permit customers to use
contactless, open standard cards and other devices issued by financial institutions, and other
certified issuers of contactless general purpose payment cards, to pay fares directly at fare gates
and other points of controlled entry to TTC transportation services. Payment will be made with
direct use of these contactless cards and devices, without the specific need for customers to
purchase TTC-issued, closed-loop fare media.
Page
10
By using this approach, TTC will enable all of its customers to pay fares in ways already
available to consumers when paying for goods and services at any retail store, via the internet, or
through interaction with customer sales and service centres. All media used for fare payment by
all customers will be contactless “smart-cards” that conform to open standards from a technical
standpoint. Accordingly, in responding to this RFPQ, the Private Partner will structure its
business, operating, and customer service solution to support acceptance of payments in a
manner that is typical of a retail merchant. TTC, in turn, will assume a “merchant” approach as
its management and business model to support ongoing OSFS operations.
The information provided below describes the Business and Functional Requirements for the
OSFS. Responses to this RFPQ must, at a minimum, adhere to all requirements described below
in delivering a state-of-the-art, electronic fare payment, media sales and distribution, operations
support, and processing business and technical solution. Chief among the RFPQ requirements is
that the OSFS operates independently of TTC’s Current System. By “layering-on” the OSFS
solution, the Private Partner will preserve the OSFS’s integrity as a financial payment system
that is operationally distinct from other TTC systems.
TTC anticipates that the successful respondent will design, build, implement, and support a fully
tested and functional OSFS, including all field and back-office software, hardware, and firmware
necessary to support an open-standard, account-based system. In developing the Business and
Functional Requirements set out below, however, TTC has also introduced the opportunity for
the respondents to offer innovative options, provided that all proposed options and enhancements
are, at a minimum, entirely based on open standards business and technical requirements. In so
doing, TTC intends to assure that the final OSFS solution can capture relevant, beneficial
business and technical innovations emanating from the payments industry that may occur and
prove applicable as project implementation moves toward completion. TTC wishes to assure that
neither TTC nor its customers encounter business or technical barriers to using the same range of
payment options available to customers as they pay for goods and services in a general retail
environment.
1.2 Objectives for the OSFS
1.2.1 Transaction Structure and Business Requirements

In addition to the general opportunities discussed in Section 1.1.1., the TTC believes that there
are many reasons why the OSFS, specifically, represents a tremendous business opportunity for
prospective Private Partners, including the following:
• Exceptional Ability for Attracting New Customers. The successful Proposed Partner
will have access to all new customers using debit or credit card based media. It is
anticipated that the new media and provider will be the default replacement for the TTC
Metro Pass media, providing access to the TTC’s ever-increasing number of patrons who
use this fare media. Currently, approximately 50% of TTC rides are taken by customers
Page
11
using pass products. When considered with those customers who purchase bulk trips,
over 90% of TTC’s total sales volume is derived from Pre-Funded fare options (e.g.
passes and bulk trip purchases). Bulk trip purchases conducted at retail locations
require a minimum 5-trip purchase.
• Exclusivity Potential. The TTC is prepared, dependent on contractual terms, to review

opportunities for a scope of exclusive use of a predetermined period for the successful
Private Partner.
• Commuter Parking Lot Operation Potential. The TTC currently operates 29

commuter parking lots. The successful Private Partner may have the opportunity to
administer parking charges for each of these lots.
• Dominant Retail Activity. The Greater Toronto Area that is served by the TTC has the
most robust economy in Canada. This area had combined retail sales of over $60 billion
in 2009, providing tremendous sales potential for prospective Private Partners.
• TTC Riders Increasingly Using Cashless Methods of Payments. Approximately 50%

of the TTC rides are made using transit passes and forego paying per trip with cash,
tokens, or tickets.
• Continued System Expansion and Modernization. The TTC is a well-known and well-
established public entity to partner with. The TTC has consistently evolved to fit the
changing demographics of Toronto.
In order to access this lucrative Toronto market entrance and customer acquisition opportunity,
the Private Partner chosen by the TTC to provide and operate the OSFS will be charged with:
1) Underwriting the Capital Investment Related to the OSFS. The Private Partner will design
and install all equipment and infrastructure necessary to transition the TTC to an OSFS at the
Private Partner’s expense.
2) Operating, Maintaining, and Refreshing the OSFS for an Annual Fee. The Private Partner
will operate, maintain, and refresh (as required) the OSFS throughout the TTC’s entire
transportation system for a specified term. The Private Partner will receive an annual payment
for operating and maintaining the OSFS, which will be calculated as a fixed percentage fee of the
TTC’s annual fare revenues (subject to an annual minimum and maximum fixed amount). The
TTC expects the fixed fee, and associated minimum and maximum, to be equal to or less than its
current cost of collecting fare revenues.
Page
12
3) Developing and Sharing New Revenues with the TTC. The Private Partner will share the
revenues generated from credit, debit, and pre-paid payment usage outside of the TTC’s transit
system with the TTC (“Non-Fare-box Revenues”) (subject to a minimum annual guarantee and
annual maximum to the TTC) for a specified term.
The term of the operating and maintenance agreement, as well as the annual fee for operating the
OSFS, will be competitively bid by prospective Private Partners. In addition, the nature and
structure of Non-Fare-box Revenues, as well as the proposed terms for sharing Non-Fare-box
Revenues, will be proposed by prospective Private Partners.
In addition to these specific requirements, the TTC’s general goals for a successful partnership to
provide the OSFS include:
• Enhancing the customer experience by making it more convenient to pay for fares by
utilizing various forms of contactless payment devices.
• Funding, acquiring, certifying (system level), installing, operating, repairing, replacing,

upgrading (as required by new standards), and maintaining a new OSFS system to
provide for modern fare collection technology, including forward compatible contactless
readers, vending machines or multi-purpose kiosks dispensing contactless GPR cards,
and appropriate back-office systems necessary to accommodate a more cost-effective,
account-based fare collection solution.
• Developing a new and unique relationship with the private sector to shift implementation
expenditures, servicing functions, and associated costs involved with fare collection, so
as to eliminate the capital investment and matching or reducing the operating costs
directly incurred by the TTC.
• Seamless adoption of innovations in fare payment technology and business processes,

including forward compatible contactless readers, kiosks, and the appropriate back-office
systems necessary to accommodate market-driven, cost effective non-proprietary fare
payment solutions.
• Achieving significant operating cost savings through the life of the agreement by assuring
that the total cost of ownership of the OSFS remains competitive with market-driven
solutions for payment processing.
• Sharing in new, non-fare box revenues generated by the Private Partner.
To achieve these business goals, the TTC requires that the Private Partner respond with an
optional turnkey solution that would design, build, install, and maintain a fully operational
OSFS, according to the business and technical criteria described in this RFPQ. In addition,
Page
13
upon full implementation of the OSFS, the Private Partner will have full responsibility for its
successful operation, including the provision of all support functions needed to meet the
performance standards set out in this RFPQ. With regard to the operation of the OSFS, these
support functions will include:
• Maintenance of all hardware, software, and systems that comprise the OSFS for a
specified period of time to be determined during the procurement process;
• Processing of all payments, electronic and cash, due to TTC from the OSFS system;
• Collection of revenues from Fare Media Vending Devices (FMVDs) or other automated
means of dispensing fare media, such as multi-purpose kiosks, deployed on TTC property
and elsewhere according to the requirements of this RFPQ;
• Operation of the Web Site and OSFS Customer Service Call Centre;
• Day-to-day management of the OSFS, both as specifically required by TTC and in order
to assure achievement of business goals and performance standards set out in this RFPQ;
• Operation of the Non-TTC retail sales network.
The TTC requires the OSFS to be fully operational according to the timeline described in this
RFPQ. Prior to implementation of the OSFS, and for a period during which both the OSFS and
the TTC’s Current System coexist, the TTC will continue to be responsible for operations in
support of the Current System. At no time during the period of operation of the Current System
will the Private Partner have responsibility for operation or maintenance of the Current System.
With the exception of physical attachment of certain OSFS components to Current System
hardware, as well as reliance on power infrastructure as described in this RFPQ, the OSFS will
function completely independently of the TTC Current System.
1.2.2 Customer Experience Requirements

The TTC’s customer service goals and requirements for the OSFS include, but are not limited to:
• Enhancing customers’ fare payment experience through simplification of steps in a

manner that, from the customer’s perspective, yields tangible improvements.
Simplification entails permitting customers to use contactless media and devices already
in their possession, having been issued by financial institutions and other certified issuers
of contactless electronic payment media; paying directly at the fare gate or fare box,
without the intervening step of acquiring a specific TTC issued transit ticket; adopting
familiar, proven customer service principles and procedures used in making retail
purchases; and providing flexibility in purchase and reload locations, as well as options
for using alternative forms of contactless payment media.
Page
14
• Reducing challenges facing customers in interpreting fare policies, products, and
payment methods by leveraging customers’ experience with credit and debit payments
and accompanying customer support models for such retail payments.
• Assuring access to, and use of, contactless media by all TTC customers, especially the
under-banked and those who choose not to use credit and debit payment instruments
already in their possession for fare payment.
• Assuring access to, and use of, a wide range of contactless devices and alternative
payment options that more closely match their retail payment needs and general
purchasing behaviour.
• Meeting, and when possible, exceeding customer service levels available at “best-in-
class” service providers through business, technical, and operational improvements in
customer service interactions with TTC customers.
• Enhancing flexibility and speed with which TTC reacts to business, technical, and
customer service innovations when accepting and processing fare payments, as well as
when accessing and exchanging information concerning customers’ fare payment
interactions with the TTC.
• Maintaining, if not enhancing the overall customer experience both in terms of ease of
fare media use, accuracy and reliability of acceptance of fare payment, and time required
for payment and boarding TTC transportation services.
1.3 Current Operating Scenarios

The Toronto Transit Commission (TTC) provides public transit in the City of Toronto, and into
neighbouring York and Peel Regions. Toronto is 622 square kilometres in size and has a
population of 2.7 million people, with another 2.9 million people in the surrounding Greater
Toronto Area. The TTC serves the City with a grid network of three subway lines, one
intermediate capacity transit line, 11 light rail (or streetcar) lines and more than 160 bus routes.
The TTC is a 24-hour operation that carries close to 1.5 million passengers on a typical weekday,
or roughly 475 million annually, using a fleet of 700 subway cars, close to 250 streetcars and
more than 1,700 conventional and paratransit buses. TTC carries almost 80% of all the transit
trips taken in the GTA.
The TTC uses a simple fare system with a flat-fare structure, allowing customer to travel an
unlimited distance-per-trip for one fare. The TTC is a pay-as-you-enter, pay-as-you-board transit
system, with seamless integration between subway, bus and streetcar services. Entry is by cash,
ticket, token, valid pass or valid transfer. A more detailed description of the TTC’s current fare
collection system in provided in the Appendices.
Page
15
The TTC serves the City of Toronto with a grid network of subway and rapid transit lines, light
rail (or streetcar) lines and more than 160 bus routes. All but two surface routes make over 240
connections to the subway system during the morning and afternoon rush hours.
The TTC operates 14 bus routes into neighbouring municipalities, and the neighbouring transit
agencies run more than 30 bus routes into Toronto that connect directly with the TTC subway
system or other surface routes. The TTC operates contracted transit services into these adjacent
municipalities. The OSFS will need to accommodate, and track, non-TTC fare payments for
subsequent revenue settlement. The development of operating scenarios will be part of Design
Review. During Design Review, the needs of “cross-boundary” customers will need to be
addressed.
Almost all TTC bus and streetcar routes operate all day, every day. The surface network
provides service to within a five-to-seven minute walk of most areas within the city. More than
95 percent of Toronto residents live within 400 metres of some TTC service.
One of the TTC’s most important features is efficient, convenient and free transfers between all
services and modes. At many stations, customers can quickly transfer between buses, streetcars
and subways without passing through turnstiles or paying an additional fare. This is critical for a
grid-based system that feeds riders from surface vehicles to subways for high-speed trips into the
downtown core, and throughout the network.
The majority of TTC services operate at peak intervals of five to 10 minutes, with some service
as frequent as every two minutes, and off-peak service every two to 30 minutes.
TTC subway trains operate about every two-and-a-half minutes during peak periods. At other
times, they run every six minutes or better. More than 85 percent of daytime routes operate until
approximately 1 a.m., every day.
The TTC has made huge strides over the past decade to make public transit more accessible for
everyone. The TTC’s accessible bus fleet has grown to more than 1,600 vehicles, and over 90
percent of the TTC’s bus routes are wheelchair and scooter friendly. The bus fleet will be fully
accessible by 2011.
The TTC’s next generation of subway trains – the Toronto Rocket – is a six-car-fixed
configuration train with open gangways, enabling riders to move freely from one end of the train
to the other. The 30 fully accessible train sets will replace the subway fleet’s oldest cars.
Toronto’s next generation of streetcars will also be accessible. The TTC is poised to bring the
very best light rail vehicles (LRV’s) to the existing network of streetcar routes. The LRV proof-
of-payment fare collection concept of operations is provided in the Appendices.
Wheel-Trans is the TTC’s paratransit service. It is responsible for door-to-door accessible transit
service for people with physical disabilities who have the most difficulty using conventional
Page
16
transit services. Service is provided beyond City limits to the airport, and to established
boundary transfer points in order to co-ordinate trips with other accessible paratransit services
within the Greater Toronto Area. Wheel-Trans carries more than two million riders annually, or
close to 7,000 trips on typical weekday. This service is operated using vehicles owned by the
TTC, as well as accessible taxis with which TTC contracts.
Wheel-Trans also provides a service called Community Bus. It is an accessible, fixed-route

service primarily focused on individuals who have some difficulty accessing the conventional
transit system.
The following table provides a summary of the TTC Operating Inventory, which will be updated
accordingly during detailed design.
Summary of TTC Operating Inventory

Total With
Total
Description Planned
Current
Expansion
Subway and Rapid Transit Stations 70 80
Staffed Subway Entrances 80 90
Unattended Subway Entrances 40 50
Subway Entrance Turnstiles 500 650
Subway/Surface Within-Station Transfer Locations 45 60
Subway Sation Commuter Parking Lots 29 31
Buses 1,600 1,800
Streetcars 250 N/A
New LRVs with POP Operation N/A 200
Transit City LRVs N/A 200
Wheel-Trans TTC-owned Vehicles 200 350
Wheel-Trans Contracted Taxis/Sedans 700 700
TTC Third-Party Ticket Agents 1,200 1,200
Other Third-Party Distributors 600 600
Table 1 – Summary of TTC Operating Inventory
1.3.1 Additional Considerations

The Reader Assembly should accept open- and closed-loop ISO 14443 Type A/B contactless
media (e.g. financial payment instruments, employee IDs, student IDs, etc.). The Reader
Assembly should accommodate additional secure applications that may be based on non-
financial payment transactions.
With the aforementioned in mind, please describe an OSFS solution specifically for:
• TTC single fare, cash paying customers on surface vehicles and subways;
• LRV POP system;
• Transit City;
• Cross-boundary fare payment situations.
Page
17
These specific situations are discussed in more detail within subsequent sections of this RFPQ.
Please discuss operational and technical challenges, if any, identified with these fare payment
situations as well.
1.4 Abbreviations and Definitions
1.4.1 Abbreviations
3DES Triple Data Encryption Standard
AC Alternating Current
ACH Automated Clearing House
AES Advanced Encryption Standard
ANSI American National Standards Institute
AODA Accessibility for Ontarians with Disabilities Act
API Application Programming Interface
ASTM American Society for Testing and Materials
BI Business Intelligence
CBA Canadian Banking Association
COTS Commercial off-the-shelf
CPU Central Processing Unit
CSA Canadian Standards Association
CSR Customer Support Representative
CSCC Customer Service Call Centre
DDA Direct Deposit Account
DIN Deutsches Institute fur Normung (German Institute for Standardization)
DUKPT Derived Unique Key per Transaction
EIA Electrical Industries Alliance
EMI Electromagnetic Interference
EMV Europay MasterCard VISA
FMVD Fare Media Vending Device
FUT Friendly User Test
GB Gigabytes
GHz Gigahertz (Frequency of One Billion Cycles per Second)
Page
18
GPR General Purpose Reloadable
GPS Global Positioning System
GUI Graphical User Interface
IEEE Institute of Electrical and Electronic Engineers
ISO,ISO/IEC International Standards Organization
IVR Interactive Voice Response
KPI Key Performance Indicator
LCD Liquid Crystal Display
LED Light Emitting Diode
LTE Long Term Evolution
MCBF Mean Cycles between Failures
MFIPPA Municipal Freedom of Information and Privacy Protection Act
MTBF Mean Time between Failures
NEC National Electrical Code
NEMA National Electrical Manufacturers Association
NFC Near Field Communications
NFPA National Fire Protection Agency
NTP Notice to Proceed
ODBC Open Data Base Connectivity
OEM Original Equipment Manufacturer
PAYG Pay-As-You-Go
PCI DSS Payment Card Industry Data Security Standard
PCI PED Payment Card Industry PIN Encryption Device
PCI PA Payment Card Industry Payment Application
PIN Personal Identification Number
PIPEDA Personal Information Protection Electronics Document Act
POE Point of Entry
POS Point of Sale
QA/QC Quality Assurance/Quality Control
QOS Quality of Service
Page
19
QSA Qualified Security Analyst
RDBM Relational Database Manager
RF Radio Frequency
RFID Radio Frequency Identification
RoHS Restrictions of Hazardous Substances
SLA Service Level Agreement
SQL Structured Query Language
SSL Secure Sockets Layer
TTC Toronto Transit Commission
TTC CSC Toronto Transit Commission Customer Service Centre
UL Underwriters Laboratory
ULC Underwriters Laboratories of Canada
UPS Uninterruptible Power Supply
VAC Volts Alternating Current
VDC Volts Direct Current
WAN Wide Area Network
1.4.2 Definitions
AODA Fare Gate. A specially designed control gate that conforms to requirements of the
Accessibility for Ontarians with Disabilities Act (AODA) in order to allow use by a customer
with disabilities.
Address Verification System (AVS). A functionality used primarily by the financial services to
further supplement verification of the identity of the person presenting a credit card for payment.
The process entails comparing address details, usually the postal code of the billing address on
file with the card issuer, with information provided by the person presenting the card at the point
of sale.
Account Based Fare Payment. A business and technical approach that 1) uses a unique number
to identify, organize, and otherwise manage all fare payment activities; 2) processes all activities
related to the account through a central processor; and 3) enables activation of account activity
by presentation of a device containing the account number and, most often, other pertinent
information, to a reader that then enables communication with the central processor for initiation
and completion of business activities on the account.
Page
20
Advanced Encryption Standard. A symmetric key encryption standard, adopted and used
widely, that uses 128-bit block ciphers and key sizes of 128, 192, and 256 bits.
Authentication. In payment systems, refers to the verification of the genuineness of the

payment device being presented at a reader in order to complete a transaction. Payment systems
frequently have several means of establishing the authenticity of the actual card or device
covering a range of procedures and technical enhancements, often accompanied by physical and
electronic means.
Authorization. In payment systems, refers to the process of evaluating the status of an account
and, more specifically, the financial readiness to assure payment to a merchant for the requested
amount of the authorization.
Authorization Response Code. A three-digit number that is generated as part of the

authorization process in payment card transactions. Codes are a short-hand that enables further
description of the response and the reason for the response (e.g., “insufficient funds” or “lost or
stolen”) from the issuer of the payment card to the authorization request.
Autoload. In transit fare payment, the capability for automated replenishment of the account
with sufficient funds or with a specific capability, such as a pass with specific use privileges, so
that the account holder may continue to use the credential associated with the account without
initiating the replenishment steps repetitively. For the OSFS solution, the Autoload function will
be available as an option to customers who wish to maintain an account balance or renew
purchases of a specific fare product on an ongoing basis. The procedure will require registration
and establishment of a means of payment acceptable to TTC.
Automated Clearing House (ACH). A batch-oriented electronic funds transfer system

governed by the National Automated Clearing House Association (NACHA) Operating Rules
which provide for the inter-bank clearing of electronic payments for participating depository
financial institutions.
Bank-Issued Credit and Debit Cards. Payment cards issued by financial institutions certified
to issue them under the laws and regulations of Canada, or other country in which they are issued
to customers who qualify. In their key physical, technical, and operating characteristics, these
cards conform to standards developed, promulgated, and enforced by the financial services and
payments industries, and their representatives and affiliates
Bank Identification Number (BIN). More commonly, the Issuer Identification Number, (IIN)
a series of digits used according to ISO/IEC 7812 guidelines used to identify the issuing
institution for credit and debit cards. It consists of a major industry identifier, a six-digit IIN, and
a single digit check sum that uses the Luhn algorithm as an authenticity check.
BASE24. Canadian version of financial payments messaging protocol.
Page
21
Bill Acceptor. A component, usually as part of an automated vending machine or similar device
such as a bank ATM that is designed to verify the authenticity of currency.
Bill Vault. A secure, uniquely identified container used to hold currency accepted by a bill
system, usually as part of an automated vending machine or similar device.
Business and Functional Requirements. A set of specific requirements that define what
capabilities the Open Standards Fare System (OSFS) must have in order to support fare payment
operations at TTC.
Call Scripts. A structured series of statements created for use by Call Centre personnel and
intended to assist these personnel in developing and effectively using responses to customer
inquiries that are accurate, consistent, and comprehensive.
Campaign. A term often used in a public transit context to refer to a concerted effort to
accomplish a task across a broad, comprehensive field of endeavour.
Card Validation Codes (CVC). Also referred to as Card Verification Data or Card Verification
Value, the Card Validation Code is a security feature used by card associations and the financial
services industry to assist merchants and issuers to authenticate the payment card for “card-not-
present” transactions. There are different CVC codes and processes associated with how they are
used in validation of the presence and authenticity of the card.
Central Processor. The centralized, back-office data and operations system for business
function outsourcing that enables and controls all business functions in support of processing
fare payments for the Open Standards Fare System (OSFS). Among those functions performed
are: fare payment processing; revenue management and settlement; business activity, financial,
network, and operational monitoring; data management, broadcasting, and field worker specific
messaging; and customer service call center and web site operation and support.
Clearinghouse. Also often called a merchant acquirer, a clearinghouse provides processing of

financial payments such that payments between transacting parties are cleared and settled
accurately and timely according to rules of the financial services and payments industries.
Code 39. One possible bar code symbology used to encode alphanumeric characters in creating
an optically readable or scanable bar code.
COTS. Commercial Off-the-Shelf hardware and software supplied by the Private Partner.
Contactless Media or Devices. As applicable for use in the OSFS, media and devices that are:
ISO/IEC 14443 and 7816 compliant, equipped with a microprocessor or “chip,” and are
applicable for use as contactless payment media or devices by complying with, or having been
licensed to use technologies and protocols of the financial services and payments industries.
Page
22
Contactless Readers. Hardware that uses RF induction technology in order to support proximity
reading of contactless smart cards. ISO 14443/ISO15963 is the international standard for
proximity telecommunications for contactless smart cards and readers. The contactless smart
card reader enables communication between the contactless smart card and other systems, which
itself communicates with other components in a larger system for processing information.
Corrective Maintenance Plan. The protocols developed to address unpredictable equipment

and system failures and events that occur during the normal operation of the Open Standards
Fare System. These “unscheduled” failures and events are the result of a wide range of causes,
not the least of which are actions of individuals, whether intentional or accidental, that interfere
with the designed functionality and operation of the OSFS.
Current System. Refers to all hardware, software, firmware, systems, and supporting
infrastructure built for and currently supporting the collection of fares at TTC from customers
who wish to ride TTC transportation services.
Customer Service Call Centre. The facility that is provided by the Private Partner that houses
hardware, software, personnel, and other means in conjunction with the OSFS required to
establish, manage, and maintain customer accounts and provide customer service as described in
this RFPQ.
Design Review. A formal process required by TTC during which Private Partner will present
detailed information and documentation about the technical, operational, and business solution
for the OSFS. A common organization is a three step process, consisting of a Conceptual Design
Review, a Preliminary Design Review, and a Final Design Review. Taken in order, each step in
the process delves more deeply into detail and by so doing brings the process of finalization of
TTC’s business and functional requirements for the OSFS to the point that both TTC and the
Private Partner have a comprehensive understanding of the required outcomes.
End-to-End Encryption. A process of securing data from point of contact to the financial
processing site with no decryption in the interim.
Europay MasterCard Visa (EMV) Standard. A standard originally developed under the
auspices of VISA and MasterCard for the purpose of interoperability between Integrated Circuit
cards and Point of Sale terminals used for their acceptance and for authentication of credit and
debit card transactions. The most common implementations of the EMV standard are AEIPS
(American Express), J smart (JCB), M-Chip (MasterCard), and VSDC (VISA). The EMV
standard is being adopted globally under mandates from card associations as a means of
increasing security of credit and debit transactions through the use of cryptographic algorithms.
These algorithms permit authentication of the card to the Point of Sale Terminal and to the back
office processor.
Page
23
Faregate. Refers to Current System equipment installed at TTC’s subway stations that acts as a
barrier and control mechanism to un-paid access to TTC’s transportation services. TTC’s fare
gates that accept payment of fares are of two types: those that use bi-directional rotating barrier
arms and those that consist of a bi-directional door to allow for AODA and other access. All
Current System Faregates that currently accept payment of fares will be equipped with Open
Standard Fare System (OSFS) Reader Assemblies.
Fare Media Vending Device. An automated, self-service vending device that will be installed at
all TTC subway stations for use by customers to purchase, reload, and dispense contactless
General Purpose Reloadable (GPR) cards. GPR cards dispensed from Fare Media Vending
Devices (FMVDs) will be open standard cards; once purchased or reloaded with adequate funds
or a fare purchase option, and dispensed from the FMVD, the GPR will be immediately usable
for payment of TTC fares.
Field Maintenance. Refers to maintenance activities that are specifically expected to occur
while equipment being serviced remains where it has been deployed for normal business
operations. The types of remedial actions expected to be taken may be lesser in scope, requiring
fewer steps and tools in order to be accomplished.
Finger-Tip Maintenance. A maintenance procedure that can be performed on a piece of

equipment that requires no, or very minimal hand tools or other devices in order to be completed.
General Purpose Reloadable (GPR) Cards. A type of payment card available to consumers
that functions like a debit card, but is unique in that it is not issued by a financial institution or
other issuer to a particular, identified person. Instead, it is available in the first instance
anonymously, typically at through a retailer who sells the card to the consumer. The consumer
pays for the card and loads the account with a dollar value at the time of purchase. Unlike “gift”
cards, which use similar open standards technology, GPR card are reloadable to a predetermined
limit, at which time the card holder needs to identify himself to the issuer, or acquire a new card.
Hand-Held Point of Sale Device. For the OSFS solution, a portable device that can be used for
payments, validation of paid fares performed by Special Constable, and potential sale and
reloads of transit accounts, for accessing information about customers’ account status, and for
validation or Proof of Payment purposes are defined in this RFPQ. The Hand-Held Point of Sale
Device must comply with open standards of the financial services and payments industries, must
be capable of extended battery life to enable use throughout a tour of service, and may have other
features, such as NFC capability, as required by TTC and as developed by the Private Partner in
order to meet the requirements of this RFPQ.
Hotlist. Terminology typically referring to a listing of accounts that are no longer valid and may
not be accepted by the OSFS.
Page
24
ISO/IEC 14443. A standard adopted by the International Standards Organization for contactless
devices imbedded with microprocessors and that operate in a range of less than 10 centimetres
and at a frequency of 13.56 MHz.
ISO/IEC 18092. A standard adopted by the International Standards Organization for short-
range, bi-directional wireless communications using magnetic induction between devices within
a range of 10-20 centimetres.
Issuer. In the payments industry, the authorized entity, usually a financial institution, that
distributes credit and debit cards to its customers under the terms of a banking agreement with
the customer.
“Layered-on.” An approach to development, design, and implementation of the OSFS that

avoids the active, co-dependent integration of the OSFS with other operating, business, or
technical system in the interest of preserving the stand-alone nature of a payment system based
on open standards. This approach may not preclude capture of information from non-payment
system sources, provided that it is done in a manner that is consistent with open standards
technology and practices of the financial services and payments industry.
Maintenance Management System (MMS). A business tool that enables monitoring and
management of operation and maintenance of a particular system through a series of equipment
sensors, computer applications, dispatching and information sharing capabilities, and reporting
and analytical functions.
Merchant. In card payment systems, the seller of products that has agreed to terms and
conditions for acceptance of payment cards and devices issued by financial institutions and other
entities. The terms and conditions in these agreements cover technology standards, security,
protocols for exchanges of funds, and guidelines governing the acceptance of certain types of
payment products. These terms and conditions have been developed by the financial services and
payments industry and, because they govern currency exchange, also fall under laws and
regulations of numerous government entities.
Merchant Acquirer. Sometimes simply referred to as the Acquirer, a processor that is often
times an affiliated financial institution that acts as processing intermediary for the acceptance of
payment media and the exchange of funds between the merchant and the customer. The Acquirer
gathers transactional data from the merchant, routes it through the appropriate network to the
issuing bank, and relays information from the issuing bank back to the merchant that enables the
payment transaction to complete. The Acquirer also acts as a clearing house for the settlement of
funds between the customer’s issuing bank and, ultimately, the merchant’s depository bank.
Near Field Communications (NFC). A technology primarily associated with mobile phones
that enables short-range, wireless exchanges of data between similarly-equipped devices. The
Page
25
technology, which is compliant with ISO 14443 standards for proximity devices, combines the
capabilities of a contactless smart card and a contactless reader into a single piece of equipment.
Non-TTC Retail Sales and Reload Locations. Physical sites that are distinct from any location
owned or operated by TTC and where the Private Partner has established the capability for TTC
transit customers, at a minimum, to acquire contactless media that could be used for paying TTC
fares, to purchase and reload TTC fares accessible through use of contactless media in an
account-based, open standard manner.
Open Architecture. Open architecture refers to hardware and software solutions that permit
adding, upgrading and swapping components without proprietary constraints. Typically, an open
architecture publishes all or parts of its architecture that the developer or integrator wants to
share. The open business processes involved with an open architecture may require some license
agreements between entities sharing the architecture information. The ''software architecture'' of
a program or computing system is the structure or structures of the software system, which
comprise software components, the externally visible properties of those components, and the
relationships between them. The term also refers to documentation of a system's software
architecture. Documenting software architecture facilitates communication between
stakeholders, documents early decisions about high-level design, and allows reuse of design
components and patterns between projects.
Open Database Connectivity (ODBC). An approach to computer systems and database design
that provides a standard, independent interface for communication with databases. The solution
layers-in software that acts as a translator between an application and a database, such that both
the database and the application can use their native programming language in exchanging data.
Open Standard. Refers specifically to the open architecture solutions developed by financial
institutions and the payments industry, and are regulated under Canadian banking laws that have
enabled the development, distribution, implementation, and ongoing operational support of
payment devices, processing systems, and business protocols for the exchange of funds typically
between consumers and merchants that provide products and services.
Open Standards Fare System. A system to support transit fare payment operations that in its
business, technical, and functional execution and operation uses standards and protocols of the
financial services and payments industries for the electronic transfer of funds. The standards and
protocols of the financial services industry define and, therefore, standardize the technical
characteristics underlying electronic transfers of funds, but also encompass procedures to ensure
the integrity of the system and adherence to standards by participants in the electronic funds
transfer processes.
Orphan Mode (Off-Line). A possible status of a component of the Open Standards Fare
System, usually a Reader Assembly, in which there is no telecommunications between the device
Page
26
and the Central Processor. While in this status, the device is unable to execute standard
transaction processing protocols and, instead, is governed by special operating protocols that
allow certain operations, in particular the acceptance of fare media, until normal
telecommunications are restored.
Payment Transaction. A process resulting in the exchange of funds between two entities in a
business transaction.
Personal Identification Number (PIN). In the context of payment systems, a unique set of
numeric characters selected by the customer to act as a security mechanism to control access to
an account or information. PINs are usually used in conjunction with debit cards issued by
financial institutions, though are now common as an added layer of security for systems and
services with restricted access.
Point of Entry (POE). Any physical location designated by TTC as a controlled point of paid
access to TTC’s transportation services. This includes locations that are in subway stations and
are protected through a gating or barrier system, or on surface vehicles where a particular
location is designated for customer to pay fares (i.e., at the front of the bus on or near the fare
box).
Point of Sale. In retail, the location where the payment or purchase transaction occurs. In the
OSFS, the points of sale of fare products will be the Fare Media Vending Device and, in the case
of Single Ride fares, the fare gate or bus fare box at which customers will present contactless
media and devices for payment of fares. For the OSFS, the Point of Sale device or terminal will
be a Reader Assembly that consists of a contactless device reader and supporting hardware and
software.
Pre-Funded. Refers to a processing category for “bulk” transit fares in which the fare product is
purchased in advance and, therefore, is intended to be used for an extended period. Examples of
these fare products are transit passes and an advance, value-based fare product where the value
of the purchase exceeds the cost of a single ride.
Preventive Maintenance Plan. A formal series of procedures, usually developed both based on
recommendations of equipment manufacturers and from practical, in-field operating results of
the equipment, that if performed according to schedule, minimize the number of unanticipated
equipment failures that occur. The plan is intended to maximize the time that equipment is
operational and limit maintenance activities to predictable actions along a structured timeline.
This approach enables the maintenance provider to manage its resources more effectively, as
well as minimize disruptions in service to a narrow range of uncontrollable events (such as
vandalism or major disasters).
Page
27
Qualified Security Assessor (QSA). An entity or individual that has been certified by the
payments and financial services industry under Payment Card Industry-Data Security Standards
(PCI-DSS) guidelines to evaluate compliance of a participating entity in the electronic transfer of
funds.
Quality Assurance (QA). Refers to a structured plan of activities that, upon completion, will
provide a level of confidence and assurance that the product or work being performed conforms
to requirements stated in the RFPQ, but also other applicable standards, codes, laws, and
guidelines.
Quality Control (QC). Specific activities required by a Quality Assurance plan that are
intended to confirm the status of a deliverable under the RFPQ as compared to specific
requirements.
Reader Assembly. A series of interdependent components that taken together function to accept
and process open standards payment transactions. The precise configuration of components will
depend on their deployment conditions, whether in subway stations or on moving vehicles.
Sales Availability. An approach to measuring the performance of the Open Standards Fare
System that places emphasis on measuring the performance of the principal overall functionality
of the OSFS, to assure access to TTC transportation services by maximizing the time during
which customers can purchase fares and have payment accepted by TTC.
Secure Sockets Layer. An encryption protocol used to transmit information securely over the
Internet.
Service Level Agreement (SLA). A specific performance level that is formally defined and
included in a contractual relationship between parties.
Single Trips (PAYG). The complete journey or revenue trip on TTC’s transportation system
permitted by payment of one fare by an open standards payment media. The journey could entail
multiple modes of transportation, depending on the exact interpretation of fare policy approved
by TTC’s Commission.
Store and Forward. In processing data over a telecommunications network, the technique of
enabling an intermediate holding place for data so that it can later be sent to its final destination.
This capability is usually provided in circumstances where telecommunications service may be
interrupted, typically where mobile communications are being used, as a means of preventing
loss of data gathered from ongoing activities that generate the data.
Tokenization. A process for obfuscating private and financial data.
Triple DES (3DES). threefold use of a block cipher originally developed by IBM.
Page
28
2 OSFS Technical Requirements
2.1 Overview
TTC requires the Private Partner to design, furnish, install, and operate an OSFS for customer
fare payment. The OSFS must operate independently of TTC’s Current System. All
components, systems, business and operating solutions comprising the OSFS will be installed in
a manner to be “layered-on” to TTC’s in-place physical infrastructure for its Current System.
The OSFS will operate in an account-based manner consistent with business principals,
procedures, and standards of the financial services and payments industries. The Private Partner
will provide a solution that will enable TTC to function as a “merchant” by accepting fare
payment at Points of Entry to the TTC system. Acceptance of fare payment will be in a manner
that is based on, and strives to be as closely identical to business, technical, and customer
services processes for acceptance of contactless, open standards financial industry payments at
retail stores. TTC’s Business and Functional Requirements for this solution are provided in
Section 3. These Business and Functional Requirements will be finalized during Design Review.
Figure 1 Open Payment Fare System
Figure 1 provides a general overview of the major components required for an open payments
fare system (OSFS). From left to right, customer use their open payments media in the form of
Page
29
contactless bank cards, cellular phones, General Purpose Reloadable (GPR) cards, and other
form factors by tapping at transit access points or points of entry (POEs) to transportation
services. These transit access points contain financial payment card Reader Assemblies that
generate a financial transaction when a customer taps on. This financial transaction is
authenticated and authorized in real-time over cellular wireless data channels linking the access
point to the OSFS Central Processor. What a customer pays for a fare depends upon the fare
policy and pricing determined by the TTC and encapsulated within the fare rules engine.
Enforcement is done via hand-held readers, which are portable Point of Sale (POS) devices that
are used by Special Constables to check that customers have tapped their cards and other
contactless payment devices.
Some of the key OSFS central services include a customer web site, call centre, financial
payments processing, system monitoring and management, data mart and reporting/business
intelligence services. The data mart provides the TTC with a complete, raw transaction history
of all open payment transactions (properly obfuscated). Reporting and business intelligence
services using this data mart enables, among other things, service level reporting for all business
functions required by TTC, including planning purposes, audits, generation of tax receipts,
financial reconciliation, and ad hoc report generation for business and analytical purposes.
In providing the OSFS solution, TTC requires that the Private Partner use proven, commercially
available hardware, software, equipment, and services that were designed and certified for
operation of open standards payment systems. Likewise, TTC requires that all other components
and systems for the OSFS utilize principles, equipment, and services that comply with an Open
Architecture approach to design, development, certification, testing, and implementation of
business and operating systems.
TTC recognizes that its “merchant” environment poses unique circumstances atypical of
“merchant” environments at retail stores. The technical specifications in this section provide
additional requirements for the design, manufacture, testing, and installation of all hardware and
software. These technical specifications provide minimum standards to assure that all hardware
and software for the OSFS solution is fully adapted and suitable to TTC’s operating
environment.
The technical requirements in this section apply to all components, hardware, software, systems,
back office operations unique to TTC, and processes delivered to TTC as the OSFS solution.
Additional requirements specific to individual components are provided in separate sections of
this RFPQ.
2.2 Description of Key System Components

The Private Partner will provide an optional turn-key solution for the OSFS that will include all
equipment, hardware, software, operating systems, and other services as specified in this RFPQ.
Page
30
System components will be deployed to enable purchase and use of contactless, open standard
media on all TTC modes of transportation.
The Private Partner will provide the following specific equipment and systems:
• Central Processor capable of processing, recording, and reporting all fare transactions and
capable of providing computer processing in support of related systems and functions of
the OSFS;
• Fare Media Vending Devices capable of sale and reload of contactless General Purpose
Reloadable media;
• Reader Assemblies designed for installation and operation on all TTC surface vehicles
and contracted Wheel-Trans services;
• Reader Assemblies designed for installation and operation on all TTC streetcars (both
legacy and LRV);
• Reader Assemblies and associated hardware designed to support off-board, Proof-of-

Payment for TTC’s new Light Rail Vehicle (LRV) system;
• Reader Assemblies designed for installation on all legacy TTC fare gates and for
operation in Subway stations;
• Hand-held or portable devices capable of reload and validation of fares in circumstances

where TTC utilizes a Proof of Payment (POP) approach, fare enforcement, or when
supplementing fare payment capacity at public events and other high volume loading
circumstances;
• Customer Service Centre with IVR facilities and with access to staffed customer service
representatives that enable customers to purchase, reload, and manage transit accounts
and to support all customer business interactions with the OSFS, including all supporting
payment equipment;
• Web Site to enable customers to purchase, reload, and manage transit accounts.
Detailed requirements specific to each of the aforementioned equipment and systems are
provided in this RFPQ.
2.3 Compliance with Standards, Codes, Laws, and Applicable Certifications

In providing the OSFS solution, the Private Partner will comply with the versions of the
following standards that are in effect at the completion of Final Design Review. All components,
Page
31
systems, and processes will be based on and comply with the Standards and Codes listed below.
The OSFS solution must comply with all relevant Canadian privacy laws, including but not
limited to, MFIPPA and PIPEDA. The Private Partner must also comply with all laws,
regulations, and codes of the Province of Ontario and the Government of Canada as they apply to
financial payment processing and provisioning of the OSFS. The Private Partner must adopt and
use principles of open architecture system design and implementation in all aspects of the OSFS
solution, as well as conform to an iterative development process for the OSFS.
In addition, the Private Partner must comply with all applicable provisions of the Accessibility
for Ontarians with Disabilities Act (AODA) and the Human Rights Commission in the design,
development, implementation, and operation of the OSFS system and related services.
2.3.1 Standards for Payment Processing

The OSFS, including but not limited to the Contactless Reader, the Reader Assembly, the
Central Processor, and all media or devices distributed for sales and reload of transit accounts,
must comply with the following Standards for payment processing and exchanges of data for the
purpose of electronic transfers of funds:
• American ExpressSM • ISO/IEC 15693-1 (NFC)

• ANSI Standard—General Purpose Plastic • EMV Level 1 and Level 2 along with EMV
Cards Contactless (supporting SDA, DDA and
CDA protocols)
• ANSI X9.2 and 8 PIN Pad Unique Key and
Encryption • ISO/IEC14443, Parts 1-4
• BSIS 7799:2002 • ISO/IEC10373
• Canadian Banking Association • ISO18092/ECMA-340—NFCIP-1
• Canadian Department of Finance • ISO 27001
• Canadian Bankers Association • J Smart
• Discover Zip • MasterCard EMV MChip
• Security (3DES, AES, Master/Session, SSL, • MasterCard PayPass
etc.)
• MasterCard PayPass MStripe
• INTERAC
• Mifare
• ISO/IEC7811
• NCITS 322-2002
• ISO/IEC7813
• NFC ECMA-352
• ISO/IEC7816
• PCI (all applicable standards such as PCI
• ISO/IEC8584 DSS, PCI PED, PA-DSS etc.)
Page
32
• VISA PayWave • VISA EMV PayWave (qVSDC)
• VISA PayWave MSD
Further standards requirements and certifications may be identified during Design Review.
During the process of implementation, testing, piloting and, subsequently, during normal
operations, the Private Partner must comply with and enable accommodation of all standards,
procedures, processes and protocols applicable to electronic funds transfers and payment systems
developed and used by the financial services and payments industries in Canada.
Certification of all payment devices, processes, services, and systems will be the responsibility of
the Private Partner.
2.3.2 Standards for Manufacture of Equipment to be Installed on TTC Property

TTC requires that all equipment designed for installation on its property meet applicable safety
and technical standards required by laws and regulations of Canada; and all safety, technical, and
performance standards applicable to manufacturers of open standards payment devices,
equipment, and hardware intended for deployment in Canada.
Likewise, TTC requires that all equipment provided by the Private Partner for the OSFS be fully
capable and otherwise hardened to perform and meet all business, technical, operating, and
customer service requirements in the specific physical operating environment of TTC’s
transportation system across all modes of service delivery and vehicles, facilities, and
environments where customers board and use TTC’s transportation services.
During Design Review, the Private Partner must document, and when requested demonstrate the
capabilities of any and all equipment being provided for the OSFS to comply with the
requirements of this section. Further details regarding environmental conditions and applicable
standards will be provided during Design Review.
2.3.3 Standards for Design and Implementation of Software for Implementation on TTC
Property
In providing software solutions and applications for the OSFS, the Private Partner will comply
with all standards for development, configuration, implementation, operation, and upgrade used
by the financial services and payments industries. Additionally, whenever available, the Private
Partner will license, configure, and use commercially available, off-the-shelf (COTS) software
and all principles of open architecture design.
During Design Review, the Private Partner must provide documentation and certifications of
compliance with the requirements of this section. Further details regarding applicable standards
will be detailed by TTC and finalized during Design Review.
Page
33
2.4 General Design Requirements
The Private Partner will design all OSFS equipment to remain in operation and withstand the
unique challenges of the transit merchant environment in the City of Toronto and in the Greater
Toronto Area. All equipment designed by the Private Partner for use of TTC customers will be
ergonomic, free of safety hazards, easy to use, be visually appealing, and be fully compliant with
AODA standards. Equipment provided by the Private Partner will allow maintenance, revenue
servicing, and other authorized personnel of either the Private Partner or TTC, safe, secure, and
easy access for the performance of their duties. All equipment deployment will be subject to
TTC engineering review.
2.4.1 Compliance with Laws Offering Protections for Disabled Persons

All features, components, and systems of the OSFS will comply with AODA, along with all
applicable Laws and Regulations of the Province of Ontario regarding accessibility and
provisions. As required by law, or as necessitated by changes in standards and practices in the
open standards of the financial services and payments industry, the Private Partner must modify,
upgrade, or amend the OSFS system, its business and operating support systems, and all other
aspects of the OSFS for TTC to whatever extent necessary to assure ongoing complete
compliance with those applicable laws, regulations, and open standards.
2.4.2 Operating Design

All equipment and components installed as part of the OSFS must be:
• In-field upgradeable, by remote means, for both firmware and software;

• Extensible, allowing new functionality and services;
• Equipped with bypass functionality such that any and all applications can reside in the
Reader Assembly Unit (e.g., the unattended terminal) instead of the Contactless Reader
component of the Reader Assembly;
• Designed for a physical operating environment at least as severe as TTC’s and that found in
the Greater Toronto Area;
• Robust and reliable; capable of fault tolerances and speedy recovery from interruptions in
power, component failures, communications, and software malfunctions;
• Consistent with principles of modular design that allow easy accessibility and “plug-and-
play,” in-field replacement of defective components, thereby effectively minimizing MTTR
(mean time to repair/replace);
• Use of standard I/O interfaces such as RS232, USB, Bluetooth, IRDA, and other, when
interfacing equipment assemblies to TTC equipment (e.g., when interfacing to TTC
turnstiles);
Page
34
• Consistent with designs that support “Finger-Tip” maintenance, requiring minimal use of
tools for access to and release of components requiring removal and replacement; and
having colour-coding and keying of components, wiring and harnesses, plugs and
connectors that support single-orientation and positioning for correct installation;
• Consistent will principles of open architecture system design, development and
implementation;
• Equipped with maintenance, remote monitoring, and test mode functionalities for all
equipment deployed in the field;
• Designed according to principles of human factor engineering and AODA in order to
maximize the acceptance and utility of equipment intended for customer use and for
servicing by maintenance personnel;
• Designed to be free from all safety hazards and to comply with all TTC and other safety
standards and codes;
• Equipped with vandal-resistant features that discourage and minimize the effects of
vandalism attempts and fraudulent access to or removal of equipment;
• Equipped with physical security features, in addition to technical, operational, and
administrative security features required by INTERAC, PCI-DSS, PCI-PTS, and PCI PA
where applicable, as well as Tokenization and End-to-End Encryption;
• Must include an administrative and operational support application for the Central Processor
and other data systems;
• All other applicable security features for the protection of sensitive transaction data, that
prevent unauthorized access to and/or removal of equipment and data. (e.g.,, tamper
resistant, trip sensors, vandal resistant, and all other similar functionalities);
• Security and Payment Device Life Cycle process – end-to-end lifecycle management
protocols to store, initialize, track, manage, and audit devices in the field; (for example this
includes all financial payment procedures and resources to support secure bank key
injections of Reader Assemblies).
• Have the appropriate approvals such as CSA, RoHS, and RF device etc. for use of such
devices within the Canadian marketplace.
2.4.3 Environmental Guidelines for Installations

Equipment installed at TTC will be subjected to a wide range of environmental conditions and
will vary according to the location and mode of transportation. The following information is
presented as guidelines for the design and evaluation of the compatibility and suitability of OSFS
equipment for the purpose of fare payment operations on TTC property, its vehicles, and the
vehicles, property, and circumstances where OSFS equipment may be deployed in support of
Page
35
revenue operations. At a minimum, TTC requires the Private Partner to demonstrate and certify
performance levels in each of the categories cited below that are indicative of the robustness of
the equipment that the Private Partner will provide and that can assure achievement of the
operating and business performance requirements detailed in this RFPQ. During Design Review,
the Private Partner will be required to certify, and if requested, demonstrate the stated
characteristics of the equipment being provided. The Private Partner must assure that actual field
conditions at installation locations are accounted for and reflected in the specifications and
capabilities of all equipment manufactured and deployed for the OSFS.
At a minimum, the following environmental factors will be addressed in designing equipment for
deployment across all modes of transportation as required as part of the OSFS, such that all
equipment will meet TTC’s performance standards:
Intrusion of Contaminants
At a minimum, all OSFS devices intended for deployment on TTC vehicles and other vehicles
providing transportation services in connection with or under contract for TTC, or intended for
deployment on TTC property must be at least IP65 sealed. Additional specific factors that will be
considered in evaluations include, but are not limited to:
• Dust;
• Moisture from direct and indirect spraying on equipment, either at high pressure or low
pressure;
• Foreign substances (e.g., liquids such as pop, coffee, tea; metals, paper products, and
other non-liquid substances, etc.);
• Electromagnetic interference and compatibility (EMI and EMC), appropriately according
to modes of transportation. For LRV and new buses this will be EN61000 and
EN50121, EN55024/22, FCC Class B or equivalent.
Climate Conditions
• Temperature ranges: ranges vary by mode of transportation. Equipment in subway
stations will typically need to operate in the range of -25 to +60 Centigrade. Exposed
equipment for surface operations will be required to operate in the -40 to 65 Centigrade
range.
• Extreme temperature changes (For those locations where the temperature ranges stated
above are exceeded heaters/coolers (fans) independent of the hardware assembly may be
specified and used.);
• Relative humidity (a range of 5-95%, non-condensing);
• Rainfall and snowfall;
• Sunlight and solar radiation;
Page
36
• Wind.
Physical Stress
• Vibration and structure borne-stresses;
• Inclination of equipment for FMVD and other automated vending equipment;
• Vandalism and integrity against deflection (ULC50 standard, forces applied in pounds
and direction of force, acceptable degrees of deflection, etc., or IK09 – 10 joules impact
resistance);
• Shock resistance for surface vehicle mountings.
Other Requirements
• Fire Retardant – all devices on board vehicles must comply to applicable fire retardant
standards i.e. NFPA F16-101, -102 , DIN5510 for low toxicity and low smoke;
• All antennas exposed to open air must be protected against high voltage/high current
faults according to all applicable Canadian standards;
• Corrosion protection – all exposed devices including antennas must comply to all
applicable Canadian standards (for example MIL-F-14072D);
• All devices, including any power supplies used to power those devices must have the
appropriate certifications and markings for operation within the Canadian Marketplace
(i.e. CSA, UL, CE, RF device, etc.).
2.4.4 Electrical Requirements
2.4.4.1 Power Standards for In-Station Installations

TTC will provide its engineering standards for equipment to be installed in TTC property during
Design Review. These will include, among other standards, details and information about the
following:
• Power source;
• Power continuity;
• Voltage excursions (must withstand 115VAC +/- 10%);
• Power losses and reinstatements;
• Circuit breakers (GFI required);
• Grounding (as per safety standards for electrical equipment exposed to moisture and
standing water).
Page
37
2.4.4.2 Cabling Standards for In-Station Installations
TTC will provide its engineering standards for equipment to be installed in TTC property. The
Private Partner must comply with these standards, which will include, but not be limited to:
• CSA standards for power and data;
• If wired connections required, must adhere to the CSA standards and connection
standards as required by the device manufacture (for device assemblies);
• Must follow connector standards as required by TTC, CSA and suggested by device
manufacture (for device assemblies, e.g., RJ45 may be appropriate internal to fare gates
in subways, however, M12-type connectors, or locking RS232 connectors, would be
required for surface vehicle assemblies.).
Further details will be provided during Design Review.
2.4.4.3 Power Standards for Surface Vehicle Equipment

TTC will provide its engineering standards for equipment to be installed on TTC surface
vehicles, including Light Rail Vehicles (LRVs). These standards will address, but not be limited
to requirements regarding the following:
• Power source;
• Power continuity;
• Voltage excursions;
• Power losses and reinstatements;
• Circuit breakers;
• Grounding;
• Power conditioning;
• Filters and transient surges;
• Protections against reverse polarity, temporary voltage drops and fluctuations;
• Prevention of battery drain.
It must be noted that standards for streetcars, LRVs, buses, and Wheel-Trans vehicles are not
identical. Standards for each vehicle type will be detailed during Design Review.
2.4.4.4 Cabling Standards for Surface Vehicle Equipment Installations

During Design Review, TTC will provide its engineering standards for equipment to be installed
on TTC surface vehicles, including new Light Rail Vehicles (LRVs) that will be placed into
service during the term of an agreement with the Private Partner.
Page
38
These standards will be largely the same as those required for in-station installations, however,
cable types and connection types must be suitable for the bus and streetcar environment.
Typically, RJ45 connectors are not permitted on buses and streetcars. Instead, M12 connectors
must be used.
As noted above, standards for streetcars, LRVs, buses, and Wheel-Trans vehicles are not
identical. Standards for each vehicle type will be detailed during Design Review.
2.5 General Structural and Material Requirements

TTC will provide its general engineering standards for equipment to be installed in TTC property
during Design Review Additional specific requirements relative to fare collection equipment are
provided in the sections below.
2.5.1 Hardening against Vandalism and Fraud

All equipment installed on TTC property will be hardened against vandalism, unauthorized
intrusion and fraudulent modifications. Equipment will be designed with the following features:
• Absence of pry points;
• Tamper-proof mounting hardware and fasteners;
• Locks made of hardened, drill and pry resistant materials;
• Active/passive tamper mechanisms that when triggered, automatically and completely
delete all stored data, bank keys, private data, and other transactional information in a
manner to assure compliance with PCI;
• Concealed design features for all locks, hinges, and potential access points, so as to resist
use of unauthorized access with the assistance of tools;
• Industrial grade security locks with profile catches and key capture mechanisms, which
are active when doors and access panels are in the open position;
• Reinforcement of areas vulnerable to vandalism and attempts at forced entry.
• All device surfaces including, but not limited to key pads, LCD display, contactless smart
card readers, contact smart card readers, device enclosures, and other equipment features
are equipped with ‘tamper evidence’ mechanisms that clearly show presence of actual or
attempted tampering.
2.6 Software
TTC requires that the OSFS use non-proprietary, open standards technology to the fullest extent
possible. Likewise, TTC requires The Private Partner to adopt principles of open architecture
design, development and implementation when providing the OSFS solution. TTC recognizes
that some specific solutions required of the Private Partner will result in equipment, software,
and firmware solutions that may largely be proprietary products of the Private Partner.
Page
39
Nonetheless, TTC requires that all equipment and services integral to the stand-alone OSFS
allow for “plug-and-play” or immediate interchangeability of components without violation of
the Private Partner’s or any third party’s proprietary rights and without requiring modification of
new component add-ins, or without any remediation by the Private Partner or, by extension, by
TTC to components remaining from the Private Partner’s original implementation. To ensure
TTC’s requirements are met, TTC further requires that all equipment, software, firmware, and
system interfaces will be standardized, documented, and licensed to TTC for its sole
discretionary use. For example, documentation should be complete and sufficient for TTC, or an
authorized third party to integrate additional services, replace components, modify software, and
perform data fusion for any business purpose required by TTC.
No software or operating system solution for any aspect of the Private Partner’s OSFS will
inherently hinder or prevent TTC’s “plug-and-play” requirement. All software and operating
system solutions for the OSFS will be forward compatible with open standards of the financial
services and payments industry. To the extent that Private Partner uses “open source” software as
part of its solution, Private Partner must ensure it is in full compliance with any applicable “open
source” licensing agreements and must indemnify TTC from any exposure resulting from use of
“open source” software. Private Partner must ensure it has acquired all necessary rights to any
third party software used in Private Partner’s solution.
Furthermore, any business applications and technologies developed by the vendor that will be
maintained and operated in the TTC environment by the TTC staff will be expected to follow
TTC architecture and development standards. The following is a summary of some of the
standards areas for this include:
Development
The Information Technology Services (ITS) Department has standardized on C#.NET and the
Microsoft .NET platform for all custom application development. Accessibility is an emerging
standardization area for ITS, and the vendor will be expected to comply with all applicable
Provincial and Federal legislation. The TTC’s current accessibility standard is WCAG 2.0. The
vendor may be asked to utilize an accessible content capability (i.e. SharePoint) and/or follow
TTC internal accessibility standards for .NET development.
Architecture
The TTC has a complex technology environment with a mixture of modern and legacy
technologies. New development is expected to follow architecture standards, some of which is
summarized below.
Database – Oracle is the current preferred standard in order to support software or technology
package requirements. Acceptable database versions will be provided at the time of
Page
40
development. In addition, the implementation team will be expected to adhere to the data
architecture, database design and database operating standards.
Reporting – Business Objects Enterprise (BOE) is the enterprise reporting standard. Data
repositories and reports are expected to be deployed within the BOE environment.
Integration – Integration technologies are expected to follow open industry interoperability

standards (i.e. XML, Web Services) and to have reliability and monitoring technology
provisions.
Monitoring – The TTC uses CA Unicenter for enterprise management and monitoring.
Applications and technologies implemented in the TTC environment must plug into monitoring
standards.
Existing and New Packages – When possible the TTC favours utilizing the existing commercial
off the shelf (COTS) package capabilities that are already in place. In the case of the introduction
of a new package, customizations impacting the ability to upgrade of the package are not
permitted.
2.7 Operating Standards Compliance

TTC requires that Private Partner to be responsible for and pay for all ongoing security
standards, audits, system checks, and other functionalities, as required by the financial payments
industry/Canadian Banking regulations. The Private Partner must be responsible and bear all
expenses for achieving and/or establishing compliance with all Federal, Provincial, and
Municipal Government regulations. Furthermore, the TTC may request to view these audits at
any time, or at its discretion, may undertake to audit the Private Partner at any time to ensure that
all compliance requirements and standards are met.
2.8 Revenue Security and Servicing

TTC requires that all equipment for the OSFS provide the highest degree of security, accuracy,
and integrity in the handling of revenues. TTC’s standards are intended to assure customers of
the integrity of revenue operations and provide visible evidence of the reliability and integrity of
the operation of the new OSFS.
2.8.1 Revenue Accountability

All components of the OSFS will be capable of tracking all transaction activities involving
purchase, reload, and use at Reader Assemblies mounted on fare gates and all surface vehicles,
and at any other point of acceptance, sale, reload, initialization, or other activity related to the
required functionalities of the OSFS of contactless fare media, transit accounts, General Purpose
Reloadable cards, and other devices used in connection with the OSFS system. Revenue tracking
includes real-time tracking of all sales channels in the OSFS system, i.e., the Web Site, FMVDs
(both on TTC property and elsewhere), the Customer Service Call Centre, and all other sales and
Page
41
distribution locations as described in this RFPQ, or as developed by the Private Partner in
connection with or on behalf of the implementation of the OSFS system.
The data required to execute and record all transactions is described in Section 3, Business and
Functional Requirements. The TTC requires the Private Partner to provide all raw data as
specified by TTC in the Business and Functional Requirements, and as finalized during
Design Review, for use by TTC.
Capture of this data will be in a manner that permits TTC, the Private Partner, and an authorized
independent auditor to reconstruct, track, and analyze all elements in the transaction process
from initiation by the customer through completion of the exchange of funds between the
customer, the Private Partner, and TTC.
2.8.2 Revenue Servicing

The Private Partner will provide revenue servicing of all Fare Media Vending Devices installed
at TTC stations for a period of time as specified by the terms of its contract with TTC. By
revenue servicing is meant the removal of cash deposited in Fare Media Vending Devices,
restocking of contactless media and receipt stock, secure transport and deposit of collected funds
into the bank account of a depository institution acceptable to TTC, full accounting and reporting
of funds collected from Fare Media Vending Devices, and all other activities associated with the
processing of revenues at Fare Media Vending Devices.
The design of Fare Media Vending Devices will enable complete revenue servicing to occur in
no more than 10 minutes, starting from the moment that the FMVD door is opened until the
FMVD is returned to normal operation. TTC requires that the time required to complete revenue
servicing be optimized for each type of device and its use in the TTC operating environment.
All steps in the servicing protocol must be completed within the prescribed timeframe.
2.8.3 Bill /Coin Acceptance Configuration

Throughout the term of the Agreement with TTC, the Private Partner will ensure that Fare Media
Vending Devices deployed in TTC stations accept Canadian currency notes/coins in circulation.
The Private Partner must initiate configuration changes to bill acceptor software to permit
uninterrupted transition to acceptance of newly issued Canadian currency. The Private Partner is
responsible to assure that all updated configurations are in place, tested, and fully operational
before the issuance date of any new Canadian Currency, including the proposed plastic bills such
as the type used in Australia.
Furthermore, the FMVD must be designed in such a manner that bill /coin acceptors can be
configured, modified, changed etc. as required for detecting and rejecting counterfeit bills of all
denominations on a continual basis.
Page
42
2.9 Equipment / System Reliability Standards
Achievement of the following reliability standards is prerequisite to TTC’s final acceptance of
listed individual components and the overall OSFS.
For measurement of reliability, a cycle is defined as follows:

• One completed Payment Transaction at a Fare Media Vending Device;
• One accepted Fare Payment Transaction by a Reader Assembly mounted on a Fare Gate,
including the release and rotation of the barrier arm (if applicable);
• One accepted Fare Payment Transaction at a Reader Assembly mounted on a bus,

streetcar or other surface vehicle;
• Once completed Payment Transaction at the Customer Web Site;
• Customer Web Site up time during TTC operating hours.
MCBFs may vary across transportation modes and will be defined by TTC during Design
Review.
MCBF will be monitored, tracked and recorded by the system device monitoring system where
all results will be made available at regular intervals and upon request by the TTC.
2.9.1 Fare Media Vending Device

The FMVD will use both MCBF and MTBF as measures of component performance. Specific
MCBF and MTBF standards, and the capability to monitor and report on them, must be provided
for the components including, but not limited to those listed below:
• LCD display;
• Keypads;
• Thermal Printers;
• Power Supply;
• Secure Memory/Tamper Battery Backup (note that this is not the UPS);
• Memory / Flash / Hard Drive;
• Contactless Reader surfaces;
• Fare media dispensers;
Page
43
• Cell Phone Modem.
Other components for which MCBF and MTBF must be specified, tracked, and reported will be
defined during Design Review.
2.9.2 Reader Assembly for Surface Vehicles

Reader Assemblies for surface vehicles will also have MCBF and MTBF standards specified, tracked, and
reported. These measures will take into consideration the mobile nature of surface vehicles and their
operational characteristics and operating environment.
Specific MCBF and MTBF standards, and the capability to monitor and report on them, must be
provided for components including, but not limited to those listed below:
• LCD display;
• Keypads;
• Power Supply;
MCBFs and MTBFs for these Reader Assemblies will be detailed during Design Review.
Additionally, the Private Partner will be required to achieve Sales Availability Standards
outlined in Section 13, Performance Standards.
2.9.3 Reader Assembly for Installation in Subway Stations

Reader Assemblies intended for installation in TTC subway stations will have MCBF and MTBF
standards specified, tracked, and reported. This measure will take into consideration the harsh
environment in subway stations, and all operational characteristics endemic to the subway
environment.
Specific MCBF and MTBF standards, and the capability to monitor and report on them, must be
provided for components including, but not limited to those listed below:
• LCD display;
• Keypads;
Page
44
• Thermal Printers;
• Power Supply;
MCBFs and MTBFs for these Reader Assemblies will be detailed during Design Review.
Additionally, the Private Partner will be required to achieve Sales Availability standards outlined
in Section 12, Performance Standards.
2.9.4 Central Processor

The central processor will need to fully support TTC business continuity. As the central
processor is a complex system, it will need to be redundant, resilient, and capable of fully
supporting automatic fall over and other functionalities and processes.
A key performance indicator of the Central Processor that must be tracked and report is percent
availability measured in Mean Time Between Failures.
During Design Review, the Private Partner must provide complete business continuity/disaster
recovery plans for the Central Processor.
2.10 Maintenance Requirements

TTC requires that the Private Partner perform all maintenance on equipment and systems that
comprise the OSFS for a period of time to be specified in the terms of TTC’s contract with the
Private Partner. Because the OSFS will be “layered-on” to TTC’s Current System, there will be
no requirement to perform maintenance for any aspect of the Current System, however, any
maintenance activities, such as device swap outs, repairs that involve removal of equipment, etc.
that may affect the data collected at the device must be reported at least daily in order for the
TTC to maintain data integrity, audit process, and any data integration with either the OSFS or
Current System.
TTC is responsible for the provision of continuous power to support normal operation of the
OSFS. Likewise, TTC will maintain the mechanical portion of the Current System fare gates and
all Current System components that are used to house or mount new Open Standard Fare
Equipment through the transition to full implementation of the OSFS. TTC intends to continue
its role in supporting the operation of the Current System until such time, at TTC’s discretion,
TTC determines that with the exception of the acceptance of cash at vehicles equipped with fare-
Page
45
boxes, the OSFS will be the sole means for customers to pay TTC fares for transportation
services.
A state of the art device management and monitoring system will be part of the Private Partners
service offering in connection with the OSFS system solution. This device management and
monitoring service will be based on open standards; will be a COTS system that may be easily
interfaced (i.e., loosely coupled) to other central processor functions.
Equipment deployed on TTC property will be designed to alert the Central Processor of all status
conditions, usage counts, and preventative maintenance status and conditions. This system will
be flexible, robust, provide remote diagnostics/testing and be remotely adaptable to changing
parameters monitored. This system must work independent of the type of contactless payment
device monitored and connection type (wired or wireless).
The Central Processor will have the capability to generate work orders for replacing, repairing,
performing preventative maintenance, or requiring further local investigation of devices. These
work orders can be broadcast to designated maintainers in the field via SMS, text messaging,
web page, or via email to any commercially available wireless communications device. As part
of the device installation and configuration, all devices will be tagged with location and
device/merchant identifiers as stated below. This information will be provided with all specific
device work orders.
Equipment deployed on TTC property will be designed to facilitate all corrective and preventive
maintenance tasks.
Equipment will have automatic, self-test and trouble-shooting routines designed to speed
diagnosis of problems and identify appropriate components for replacement. Features of the
design will permit easy identification, inspection, removal, replacement, and adjustment of
components in support of the testing routines.
All equipment components will be clearly and permanently marked with unique serial numbers
in both alphanumeric and bar code formats for tracking and auditing purposes. Individual
components will weigh no more than 10 kilograms in order to facilitate transport by a single
maintainer.
The Private Partner will also provide a payment device management system that may or may not
be part of the regular device management system. Specifically, this payment device
management system will be responsible for all device key loadings/exchanges, and for in-field
secure encrypted device application loads/reloads (e.g., upgrades).
2.10.1 Corrective Maintenance

TTC requires that the Private Partner develop and execute a Corrective Maintenance Plan for all
Open Standard Fare Equipment. Execution of the plan must conform to TTC’s requirements and
Page
46
protocols for authorized access to TTC facilities by outside contractors and vendors as described
in Section 5 of this RFPQ. The plan must include goals, procedural details, and resource
commitments that demonstrate the Private Partner’s ability to achieve TTC’s performance
standards for the OSFS. The final Corrective Maintenance Plan will be subject to TTC’s
approval prior to completion of Design Review.
TTC requires that all corrective maintenance consist of in-field replacement of components.
Subject to TTC’s review and approval during Design Review, the Private Partner will design all
equipment deployed in TTC stations and on TTC vehicles and on vehicles contracted by TTC to
provide transportation services on its behalf, to enable replacement of all components necessary
to return the equipment to revenue service in less than 15 minutes. Replacement of components
will require only one person to execute all replacement tasks within the allotted time. The
replacement of components will be facilitated by designs that maximize the use of commercially
available parts, configurations, and physical features and markings that assist maintenance
personnel in orientation and easy installation of parts in the replacement process. Replacement
of components includes all specific device configurations required for that particular device
location and security (including any banking and operating keys). The payment device
management system/service will be accessible to the service technician from the field device
installed which will allow a complete installation to occur from the field, without requiring
additional central service steps. Once the installation/replacement has been complete, the central
service will allow a complete, end-to-end financial test transaction to be completed, ensure
proper operation.
TTC requires that the Private Partner provide a complete and upgraded Corrective Maintenance
Protocol during the course of each phase of Design Review. This will consist of all necessary
manuals and documentation required to support Corrective Maintenance of Open Standards
Equipment.
2.10.2 Preventive Maintenance

The Private Partner must provide and execute a detailed Preventive Maintenance plan for Design
Review. The plan must include goals, procedural details, and resource commitments that
demonstrate the Private Partner’s ability to achieve TTC’s performance standards for the OSFS.
The Preventive Maintenance Plan will identify tasks for each piece of equipment, along with
support materials and tools needed to accomplish preventive maintenance tasks.
All equipment will be designed to enable finger-tip maintenance to the fullest extent possible and
enable the performance of all preventive maintenance tasks by a single maintainer without the
need to remove the equipment from the field or in-service operation for more than 30 minutes.
TTC requires that the Private Partner provide a complete Preventive Maintenance plan as part of
each phase of Design Review. This will consist of all necessary manuals and documentation
Page
47
required to support Preventive Maintenance of Open Standards Equipment. The final Preventive
Maintenance plan will be subject to TTC’s approval prior to completion of Design Review.
3 Business Processes and Functional Requirements of the OSFS

The solution proposed for TTC’s new fare payment system will be an account-based system that
functions according to business processes and technical guidelines for open standards payments
of the financial services and payments industries. Such an account-based system will require a
robust back-office that not only supports all open standards requirements, but is also capable of
supporting TTC’s day-to-day fare payment business operations and oversight of the Private
Partner. Therefore, this section provides requirements of the technical functionality and business
processes needed to support all stakeholders in the operation of the OSFS.
Business and Functional Requirements for the OSFS fall into three major areas:
• Revenue Assurance;
• Risk Mitigation and Management; and
• Business Intelligence Reporting and Management.
3.1 Revenue Assurance

Revenue Assurance encompasses all revenue collection, verification, and settlement processes.
Specifically, this must include functionality addressing financial control, auditing, and reporting,
as well as the IT systems and equipment necessary to support such functions.
3.1.1 Fare Acceptance

The OSFS back-office must support the following acceptance functionality at Reader Assemblies
for fare payment processing:
• In-System (i.e., within transit): Acceptance functionality using standard, financial industry
and card association type-certified readers for all contactless media and devices – including,
but not limited to Europay, MasterCard, and VISA (EMV) compliant media – conforming to
ISO 14443A/B standards and other applicable standards, such as NFC, as listed in Section
2.3.1 above, issued by the financial services industry and other certified issuing entities. This
should include – but not be limited to – credit and prepaid co-branded open and closed-loop
cards, as well as other contactless media and devices and processing methodologies that
directly or indirectly rely on open standards for processing of electronic payments;
• Out-of-System (i.e., outside of transit): Processing and management functionality of
acceptance environments using standard card association type-certified POS devices of all
contactless and magnetic stripe media – including, but not limited to EMV compliant media,
devices and processes – conforming to ISO 14443A/B standards, and other applicable
standards such as NFC, as listed in Section 2.3.1 above, issued by the financial services
industry and other certified issuing entities. This should include – but not be limited to –
Page
48
credit, debit, and prepaid co-branded open and closed-loop cards, as well as other form
factors or processing methodologies that directly or indirectly rely on open standards for
processing of electronic payments; and
• Migration to EMV--Fare acceptance in Canada must also take into consideration the EMV
migration currently taking place. A wide variety of EMV compliant and non-EMV
compliant contactless customer bank cards will be in place for quite some time. Contactless
debit (INTERAC) is evolving (along the lines of contactless EMV but may have some
additional constraints), contactless Magnetic Stripe, and Contactless EMV etc. will need to
be considered not only at the front-end equipment assembly, but also at the Central Processor
depending on the type of payment made and the processing option of either Pay-As-You-Go
(PAYG) or Pre-Funded. Furthermore, EMV allows on-line and off-line transactions as well
as supporting various security schemes determined by the card issuer which directly affect
the customer tap experience. These must be taken into account by the Private Partner.
• Acceptance and processing functionality for any form factors or devices that contain
contactless chips conforming to financial industry standards and ISO/IEC 8583/BASE24 and
all other relevant standards for the exchange of data used in electronic processing financial
transactions.
3.1.2 Fare Calculation

Fare calculation will be performed by a centralized, table/rules-driven payment module
(hereafter the “Central Processor”) that calculates and differentiates appropriate transit fare
charges processed via the OSFS. The table/rules-driven payment module, as well as other
configurable systems, will have an operational support and administration application for
configuration and types of values. The Central Processor will use an account-based
methodology, as described below.
In-system at TTC, the form of payment media or devices accepted at Reader Assemblies on Fare
Gates and TTC buses, Streetcars, LRVs and Wheel-Trans will be contactless media and devices.
For the purposes of accepting payment from customers for sale and/or reload of General Purpose
Reloadable cards dispensed from Fare Media Vending Machines, contactless media/devices,
contact media and devices and magnetic stripe cards will be accepted. (Note that magnetic stripe
cards will no longer be accepted once EMV is fully rolled out into the hands of the bank
customers). At out-of-system locations, and at non-POE locations in-system, such as FMVDs,
payment media processed by the OSFS may use any means of data transfer, such as contactless,
contact and magnetic stripe, provided that the media is ISO/IEC 14443 compliant and recognized
by the financial services payments industries as being consistent with generally accepted
payment card associations’ business and technical standards in a manner that does not interfere
with or cause material modification of those standards. Note that this does not preclude the use
of NFC payment devices that may be present in cellular phones in the future.
Page
49
TTC requires conformity with financial services and payment industry guidelines; such that
all end devices, systems, media, and related support services can be supported in a “plug-and-
play” manner through reliance on commercial, off-the-shelf (COTS) equipment and services.
No aspect of the technical design or the actual implementation will impede forward
compatibility with financial service and payment industry products and services, or COTS
devices, systems, media, and related support services.
The Central Processor will also be capable of processing and accepting both EMV and non-
EMV-compliant media as well as account-based, Pre-Funded and PAYG type transactions. The
complete and fully operational fare payment solution must comply with Payment Card Industry
Data Security Standards (PCI-DSS), and any other security standards required by card
associations, issuers, and authorized standards bodies and regulators for the financial services
and payments industries. Additional security above and beyond PCI standards (such as
Tokenization, End-To-End Encryption) is both desirable and encouraged.
TTC anticipates the Private Partner to proceed as though bank-issued payment media, when
presented in the transit merchant environment being implemented at the TTC, will serve the dual
purpose of a transit credential and a general payment device. In this dual purpose, all aspects of
the OSFS will comply with card associations’ standards and generally accepted practices of the
financial services and payments industries.
TTC wishes to assume the role of a merchant when selling fares. To do so, for the purposes of
fare calculation, TTC requires that all of its fare products will fall within one of two categories
for sales, reloads, and processing of payments:
• Single Trips (PAYG)s (i.e., Pay-As-You-Go), and
• Trips Paid in Advance (i.e., Pre-Funded fare products, such as period passes and bulk
purchases of “value-based fares”).
A complete categorization of TTC fare products into the two processing groups is provided in a
subsequent section.
Pricing and usage control of “Single Trips (PAYG),” “Trips Paid in Advance,” or those trips
associated with discounting or concession fares will occur based on table/rule driven parameters.
Parameters will be comprehensively defined in tables encompassing and enabling all pricings
and authorized uses (i.e., transfers, reduced fares, etc.) available under current TTC fare policy.
The range and flexibility of such parameter settings should also enable pricing options by mode
of transportation, route, location of devices, time of day, as well as other criteria stated in the
TTC’s fare policy or determined by the TTC’s executive management. Parameter table settings
should be controlled through the Central Processor.
Page
50
A comprehensive listing of parameter settings required for the OSFS will be detailed during
Design Review and will take into account the OSFS solution offered by the Private Partner. The
Private Partner may offer additional parameter settings and functionalities as options in addition
to the parameter settings and functionalities that are required by TTC and that will be provided
during Design Review.
With this functional framework in mind, fare calculation will occur in the following manner:
• The Central Processor will capture data (i.e.,” taps”) read from the fare media as distinct
trips. The Central Processor will be capable of distinguishing payment taps on transit
devices from other financial payments, and from unpaid “taps” or boardings for which no
payment is due according to TTC’s fare policies.
• Trips and associated charges will be applied to transit accounts based on the type of
processing establish for the customer’s account;
• Trips and charges captured must be routed to and stored in the Central Processor in order
to support all business support functions, such as, but not limited to revenue assurance,
risk management, ridership reporting (i.e., linked and unlinked trips), and business
intelligence functions;
• Data read and captured from fare media, which must be used for calculating payments
and authenticating transit usage – must only use those data fields present and readable on
open standards compliant media;
• Additional data, such as GPS data or location data, may be appended to data read from
payment media. This may occur only if it is appended upstream from any media-reader
interactions (i.e., outside the contactless payment application) and that such data
complements, but does not interfere with open standards business technology, and
operating practices;
• Transit trips must be associated with an account number that can be an obfuscation of the
financial account number through Tokenization, which will be assigned to the payment
media in a manner to assure compliance with PCI-DSS Standards and all other applicable
security standards and payment industry best practices;
• The Central Processor will capture data read from payment media and then process it as
either Single Trips (PAYG) or as Trips Paid in Advance (Pre-Funded), applying the
appropriate charges, if any, within these processing categories;
• Application of pricing for Single Trips (PAYG) must be based on table/rules-driven

parameters stored in the Central Processor. Pricing criteria must include multiple
additional parameters, as defined by TTC’s fare policy and business operations. These
Page
51
may include any precedence order of application as determined by TTC. All pricing and
additional criteria will be applied to the evaluation of the final cost of a transit trip, or a
series of multiple transit trips, taken with a single piece of media;
• This transaction is verifiable, reversible and repeatable;
• The Central Processor will convert Single Trips (PAYG) into a format consistent with
retail merchant payment transactions. Options for this configuration must be parameter
driven, and must include options for transaction aggregation and for non-aggregation
capabilities consistent with card association standards and accepted card association and
merchant practices. Options must also be consistent with practices available to closed-
loop, as well as General Purpose Reloadable (GPR) open standards payment media.
Although, closed loop and GPR cards may have different transit rules associated with
them, both card types and devices must follow the same processes within the Central
Processor.
• The Central Processor must be capable of parameter settings that are tailored to and
accommodate the unique processing requirements of open standard card association
products, products of other certified issuers (i.e., anonymous GPR open and closed-loop
cards, Travel and Entertainment card issuers, etc.), such that all open standard card
products that are contactless can be accepted and processed;
• The Central Processor must be capable of processing standard, ISO/IEC 8583/BASE 24

data from all form factors, such as magnetic stripe, contactless, and contact, issued in
compliance with open standards by the payments industry.
• The Central Processor must provide the necessary interface, configurations and files for
processing payments with any commercially available merchant acquirer.
• The Central Processor must include functionality capable of managing authorization and
pre-authorization of open-loop payment media issued by banks and non-banking financial
services entities, direct funding service providers (such as pensioner and social benefits
programs) made possible through electronic transfers of funds;
• The Central Processor must be capable of accepting, and appropriately processing, third
parties’ closed-loop media that conform to open standards business and technical
guidelines for transit payment, such as employee identification cards, student payment
cards, government subsidized transit benefit cards, and other direct payment media. It is
expected that the closed loop card would contain a contactless payment application
identical to the open card, but that it would be restricted to use at TTC.
Page
52
3.1.2.1 Fare Policy Matrix
The OSFS will process all TTC fare options in two categories: Single Trips (PAYG) and Pre-
Funded trips. This categorization reflects TTC’s conceptualization of how its customers will pay
for fares, either as individual trips or in bulk purchases as passes and values greater than one trip.
The following tables present TTC’s fare products and their pricings, where applicable, according
to the aforementioned processing categories.
Pre-Funded Processing Category

Adult Fares (72% of total rides)
% of Total
Fare Product Price TTC Rides Notes
5 tokens $ 12.50 Minimum purchase is 5 tokens.

26.2%
10 tokens $ 25.00 Minimum purchase is 10 tokens.
Monthly Pass $ 121.00
MDP program: for more
MDP Monthly Pass $ 111.00 44.2% information for MDP and VIP,
please refer to the appendices.
VIP Various
Weekly Pass $ 36.00 1.9%

Senior/Student Fares (12% of total rides)
% of Total
Fare Product Price Notes
TTC Rides
5 tickets $ 8.25 Minimum purchase is 5 tickets.
8.2%
10 tokens $ 16.50 Minimum purchase is 10 tickets.
Monthly Pass $ 99.00
MDP program: for more
3.3%
MDP Monthly Pass $ 89.00 information for MDP and VIP,
please refer to the appendices.
Weekly Pass $ 28.00 0.2%
Page
53
Other Fares (5.5% of total rides)
% of Total
TTC Rides
Weekdays-one person.
Holidays/weekends-up to 6
Day/Family Pass $ 10.00 2.4% persons, a maximum of 2 adults.
Special promotions during
holidays.
Child Ten Ticket $ 5.50 1.8% Sold in strips of ten rides.
TTC; Mississauga; Brampton;
GTA Pass $ 52.00 1.2%
York Region
Second
fare equal
to ticket or Available to adults, seniors,
token rate, students, and children; sold in
Downtown Express 0.1%
or minimum quanties of 5 and 10
Express rides.
Sticker
Pay-As-You-Go Processing Category

(10.5% of total rides)
% of Total
TTC Rides
Adult Cash Fare $ 3.00 8.8%
Senior/Student Cash
$ 2.00 1.2%
Fare
Child Cash $ 0.75 0.5%
The following further revenue products fall under the category that requires Pre-Funded
processing:
Pre-Funded Revenue Fares
• Convention Passes-pricing varies depending on the number of passes and number of days
of travel sold;
• Special Event Passes;
• Post-Secondary Pass.
Note that there are a number of non-revenue fare products (i.e. not sold to the public) that will
need to be processed. These include passes for TTC employees, TTC pensioners, TTC student
employees, etc. TTC will provide details about these non-revenue fares in Design Review.
Nonetheless, these fares would be processed and managed in a Pre-Funded manner.
Page
54
In addition, TTC requires that the OSFS is capable of processing the following fare payment
functions and products:
• Transfers among all modes, including on-board Proof-of-Payment (POP) on Queen

Street;
• Future POP on TTC’s Legacy streetcar routes;
• Cross-boundary fare policies;
• TTC Times Two with GO Transit.
More information about these programs are provided in the Appendices to this RFPQ.
During the process of Design Review, TTC will consider fare policy options that could enhance
customer service and result in increased ridership and in increased general use of public
transportation. The final outcome of these considerations will be presented at Design Review and
will be the basis for implementation of the OSFS solution.
In offering proposals for processing these fare products, as well as all others included in the
tables above, the Private Partner will need to take into account the specific requirements, rules,
and regulations that govern the management, distribution, and use of these fare products. A
complete matrix of applicable parameters will be developed and finalized during Design Review.
In all instances, processing of these fare products must comply with processes and procedures of
the financial services and payments industries. At the same time, the Private Partner is
encouraged to suggest options for TTC’s consideration that would enhance the utility of these
fare options and the media used to pay fare in a manner consistent with the business and
functional requirements in this RFPQ.
TTC requires that the OSFS calculate Single Trips (PAYG) (Pay-As-You-Go) and Pre-Funded
fares in an account-based manner. In doing so, the OSFS will capture all usages or “taps” of
contactless media and devices and calculate payments due TTC. Each usage or “tap” will be
authorized in real time against information about the transit account that is either stored in or
available through the Central Processor. An authorization that returns an “approval” will permit
entry to the system. An authorization approval will be conditional on a validation of the active
status of the customer’s account with the OSFS using standard authorization protocols of the
financial services and payments industry. The authorization process will, at a minimum, check
for:
• Active status of a Pre-Funded transit account;
• Active status of the customer’s credit, debit, or GPR contactless media or device to pay
fares as Single Trips (PAYG)s or “pay-as-you-go;” and
Page
55
• Authenticity of the contactless payment media or device.
In determining the actual payment due from customers, the OSFS will also apply all other TTC
fare policy and business rules governing including, but not limited to, free transfers (including
“transaction-free” transfers), velocity checks, or “passbacks.”
During Design Review, TTC will work with the Private Partner to create a comprehensive Fare
Matrix that summarizes all current TTC fare policy pricings and usage guidelines for processing
fare transactions with the OSFS. The Fare Matrix is subject to change at TTC’s discretion during
Design Review. As part of Design Review, the Private Partner must submit a comprehensive
flow chart that illustrates transaction process flows for programming the Central Processor.
3.1.3 Transaction Processing for Single Trips (PAYG)

The OSFS must support the payment of fares as Single Trips (PAYG). At present, TTC’s fare
policy is to charge a flat rate for a Single Trips (PAYG) on its system. The OSFS must also be
configured in a manner that would permit other fare pricing options at TTC’s discretion by the
enabling of functionality built into the OSFS. In taking this approach, TTC wishes to have the
widest possible latitude to develop, evaluate and implement fare policy and pricing options that
maximize TTC’s revenues while offering customers convenient and economical fare payment
options,
Among the required options to be made available and implemented on demand are: non-
calendar-based, or “rolling” passes; and discounting options such as “best fare”, which would be
based on achieving pre-determined usage thresholds within time parameters set by TTC. The
system should also be flexible to allow for additional functionality such as permitting time,
distance and direction based trips.
The OSFS must allow customers to purchase Single Trips (PAYG) at the point of entry to the
TTC system, whether at Fare Gates or on vehicles equipped with Reader Assemblies. TTC
requires the Private Partner to replicate the customers’ experience at a retail merchant by
allowing direct presentment of a contactless credit, debit, or GPR without any intervening steps.
This functionality must be realized in a manner that protects TTC’s revenue, as well conforms to
business and technical guidelines for open standards payments for authentication of contactless
payment instruments and authorization processes for retail payments as required and certified by
card associations and the financial services industry.
Upon presentation of contactless payment media to a reader, processes required to assure

payment of fare must be configured to be executed in real-time. In the event that network
communications between readers and the OSFS back-office are not operational, the OSFS will
possess functionality to authenticate locally all contactless media presented for payment. For
EMV-compliant cards, an off-line EMV transaction is permitted. For non-EMV-compliant
cards, Store and Forward may be used. From a customer point of view, off-line transactions
should not be noticeable by the customer. Should an off-line transaction occur, however, the
Page
56
Private Partner should endeavour to have on-line connectivity restored as quickly as possible.
The Open Standards System must have the capability of supporting a “local” hotlist and BIN
table resident at the Reader Assembly; however this local hotlist should not replace the Central
Processor hotlist. The design of the local hotlist must enable TTC to sustain its risk management
efforts within norms for the TTC merchant environment, and within thresholds established by the
financial services and payments industries for management of fraud. Furthermore, when network
communications with the back-office are re-established, the OSFS solution must be capable of
resuming normal operations. This includes appropriate processing of fare payment transactions
performed during any period of network communications inoperability. The Central Processor
must have sufficient power to process any spike in transactions that may occur once the network
connection has been re-established.
Sustained maximum transaction per second performance measures are specified in Section 12 of
this document.
Acceptance speeds of 500ms or less for all types of EMV and non-EMV cards must be assured
for completion of the authorization process at all points of fare payment and contactless device
acceptance, regardless of the number of transactions taking place at individual POEs in the TTC
transit system. The Central Processor must be designed to exceed at least twice the maximum
anticipated transactions per second at TTC.
As the Private Partner may not be responsible for issuing customer bankcards, and because banks
have the options of issuing a variety of EMV-compliant cards, the Private Partner must execute
additional testing and due diligence across all bank cards issued within the Greater Toronto Area
consumer market to verify and assure conformance with the acceptance speed requirement of
500ms or less.
As part of the design review and testing, financial payment test card suites for the whole range of
EMV and non-EMV that are in customers hands (available from MasterCard, VISA and various
other third parties) will be tested and system performance measured for test cards in the suites.
The OSFS must have the capability of aggregating individual Single Trips (PAYG)s – subject to
predetermined time and/or dollar value parameters (e.g., 2 weeks or $15.00, whichever comes
first) by the back-office into a single payment transaction. Such time and dollar value
functionality must be resident in the Central Processor and managed via a table/rules-driven
methodology, or via an alternate, easily modifiable means. Such aggregation rules and table
settings may be subject to card association financial industry approval.
The Central Processor must be programmed with additional functionalities consistent with
capabilities needed to support open standards payments in a retail merchant environment, such
as, but not limited to the following:
Page
57
• The dollar value of an authorization after the first tap within the predetermined
aggregation period;
• Single or dual authorization capability.
• Customer-directed authorization (i.e., use the INTERAC network as opposed to the

VISA or MasterCard network with regards to future Debit Contactless).
The purpose of such parameter settings is to permit flexibility when addressing processing
requirements of unique brands, rate issues, and operating impacts associated with certain
processing modes for differing brands and card associations. The Private Partner may propose
additional parameter settings or procedures that further enhance the Private Partner’s
capabilities to operate the proposed OSFS effectively and assure achievement of TTC’s
required performance standards; including the acceptance of all open standards contactless
media and devices.
The OSFS will be capable of reposting payment transactions presented at the end of the
aggregation period or once the predetermined dollar value threshold is reached. For each
declined payment authorization, the OSFS must capture the decline code returned by a merchant
acquirer and determine whether such decline was a hard decline (i.e., fraud or lost/stolen card) or
a soft decline (i.e., temporarily inactive account because of an overdrawn or similar status).
In response to soft declines only, the OSFS must be configured to support reposting soft-declines
for authorization based on table-driven time and count parameters. In providing the OSFS
solution, the Private Partner will configure the OSFS to allow TTC the flexibility of treatment of
hard and soft declines when allowing customers to enter the transit system.
The OSFS must be capable of supporting orderly, auditable close-out of Single Trips (PAYG) or
Pay-As-You-Go accounts and customers’ transition to and enrolment in Pre-Funded accounts. In
this transition process, the OSFS must be capable of aggregating all Single Trips (PAYG)
transactions, whether posted at the time of or subsequent to the customers’ enrolment and
transition to Pre-Funded account. The Private Partner may propose alternative methodologies to
TTC for its consideration and approval for handling customer accounts that allow for seamless
transition between fare payment processing and payment options.
The OSFS must incorporate all functionality and data elements required by the financial services
and payments industries to enable and assure accurate calculation, processing, auditing and
payment of interchange rates and other fees.
The OSFS must incorporate all functionality, processes, and data elements required by the
financial services and payments industries to enable and ensure protection against chargebacks.
This capability must also enable the Private Partner to challenge chargebacks so as to minimize
financial losses and assure meeting card association risk management guidelines and rules.
Page
58
3.1.4 Pre-Funded Transactions
The OSFS will process the sale and use of TTC fare products categorized as Pre-Funded as
traditional retail purchases using open standards payment devices. Purchasing in this context
will include the ability for the customer to “reload” their transit account with sufficient funds to
make a Pre-Funded purchase, as well as the capability to permit recurring reloads (i.e., “auto
loads”) according to parameters permitted by TTC, but made available as options to customers.
Venues for making purchases of Pre-Funded fare products should include, but not be limited to
the Fare Media Vending Machines, the Web Site, the Customer Service Call Centre, Non-TTC
Retail Sales and Reload Locations provided by the Private Partner, and other sites participating
in the OSFS as required in the RFPQ.
Acceptance of contactless credit, debit, and GPR devices at all sales and reload locations for
TTC transit fares must conform to financial services industry and card association rules,
procedures, and processes.
Once a payment transaction is authorized, the OSFS must record and support the payment
settlement process. It is assumed a denial response from the authorization process will end the
sales transaction and/or deny customer’s entry to or use of TTC’s transportation services. In
addition, the OSFS must associate the fare product purchase with a unique customer account
number in a manner that complies with PCI-DSS. For each Pre-Funded fare option available, the
Central Processor will apply appropriate corresponding fare rules for use of the Pre-Funded fare
product.
Functionality consistent with that outlined in this Section 3.1.4 must be available to address
online and offline network communications.
3.1.5 Customer Support for Fare Payment

All customer support functions will be enabled by account information within the OSFS’s
Central Processor. Consistent with generally accepted payment processing standards and
practices, Reader Assemblies at points-of-entry should only provide simple approval and denial
of payments in response to authorization requests.
Information about dollar value of payments, the type of Pre-Funded fare purchase associated
with accounts, and whether or not a charge will be incurred will be unavailable at Reader
Assemblies.
The Central Processor must possess functionality and interfaces supporting the required Web
Site. In addition, functionality should be present to support sales of fares through the required
Customer Service Call Centre via an Interactive Voice Response (IVR) system and access to a
person fulfilling the role of a Customer Service Representative. Customer Service
Representatives will have multi-language skills representative of the customers served by TTC.
Page
59
The Central Processor must also be capable of supporting alternative payment methods, such as
SMS-text enabled payments, provided that such payment methods conform to generally-accepted
financial and payment industry standards, and customers have funds guaranteed through their
personal banking relationships, cell phone payments, bill payment providers, and other means
and entities that use open standards of the financial services and payments industries.
Access to account-based information resident in the Central Processor must be accommodated

via an online registration process. The registration process supported by the Central Processor
must provide options appropriate for the payment media purchased. For security and privacy
purposes, the Central Processor must require establishment of a unique password or PIN
(personal identification number) or equivalent process, such as user defined queries, as defined
by Canadian Financial Standards, to access payment and trip information for an account.
The Central Processor must support the following functionalities customer-directed account
management and inquiries via the Web Site:
• Selecting and purchasing all Pre-Funded products available under TTC’s fare policy;
• Authentication processes consistent with TTC and other applicable policies and
procedures for customers eligible for concession fares, such as reduced fare customers,
employees, and contractors;
• Account management and summary information relating to trips taken, per trip charges,
payments, account setups and registrations, account cancellations and refund processing,
auto-reload management, account transfers, and claims status.
• Secure report generation of trips, charges, and other account information, as required by
the customer, either to PDF, direct to the customer’s printer, or to additional common
formats and software, such as EXCEL.
Sales transactions and customer inquiries through the Web Site must be executed in real-time.
Sales transaction processing must permit customers to use credit or debit as forms of payment.
Customers preferring to use PIN-based debit cards will be supported according to financial
industry guidelines for processing PIN-based debit transactions. This functionality may require
use of commercially available, card association type-certified software and hardware. It may
also require development of additional capabilities, such as end-to-end encryption, to ensure
protection of restricted PIN data, secure storage of customer information, and acknowledgements
of participation in compliance with PCI-DSS.
Processing options that could benefit TTC and its customers, but that are not fully supported by
open standards guidelines should be brought to TTC’s attention when proposing OSFS solutions.
The Central Processor will support collection of required information for executing
authorizations according to financial services and payment industry guidelines. Information
Page
60
required may include, but not be limited to, card validation codes, postal codes, and telephone
numbers required as part of address verification services, and card expiration data.
Fare sales through a staffed customer service centre, or through a combination of a staffed sales
centre and IVR whether under the direct auspices of the Private Partner or through a third-party
arrangement with an existing retail sales or other network, must be supported in the same manner
as web-based sales. The Central Processor must support secure access to customer account
information in compliance with PCI-DSS. The credit or debit card account used for payment
will be the same card account that a customer will be required to present for validation at TTC
points-of-entry.
The Central Processor must retain and enable access to historical information related to trips
taken and payment transactions made by customers. For all payment transactions, historical
transaction information made available to customers must be in a manner consistent with
information captured by open standards media used in processing retail payments, as required by
card associations and financial services and payments industry standards, and reflect TTC’s
requirement as a transit merchant to assure customer access to trip information associated with
customers’ financial payments to TTC. For historical information, capture and access should
conform to PCI-DSS, all applicable Canadian privacy laws as well as appropriate laws regarding
receipts. For information about trips taken, customers will have access to detailed historical
information through the Web Site and the Customer Service Centre’s IVR and live agents.
Information captured will be identical for all open standards media accepted, including any
closed-loop media, such as payment media issued in connection with transit and social benefits
programs.
Information must be captured and made available to customers in real time. The OSFS must be
capable of supplementing payment transaction information with information provided from TTC
as a transit merchant regarding Points of Entry to TTC’s transportation services. The OSFS will
be capable of supporting access to information voluntarily provided by customers in establishing
transit accounts, including details of customers’ processing and payment preferences, such as
automatic reload.
Information available to the customer must at a minimum consist of the following:

• Trips taken, identified by date, time, and location of contactless media acceptance;
• The dollar value of the trip(s) taken, including a record of transfers taken at no additional
cost to the customer;
• The date and time billing for exchange of funds occurred;
• The fare product purchased;
• The merchant paid.
Page
61
Additional information that must be made available to the customer may be identified during
Design Review.
As part of its support of Web Site operations, the Central Processor must enable customers and
Customer Agents to transfer account balances and associated activities, from one open standard
compliant contactless device to another. Self-service transfers should be restricted to bank-
issued media and to media that has been registered at the Central Processor by customers. This
capability must be available at the Customer Call Centre to customer service staff and to
customers who chose to use the IVR system, provided that access is in conjunction secure entry
of a PIN by customers themselves. This capability must also be available at Non-TTC Retail
Sales and Reload Network locations, in accordance with rules allowed by the CBA and bank-
issued cards.
The Central Processor must support customer claims and requests for refunds or credits. Two
categories of claims should be supported: usage related claims and payment related claims.
Usage claims concern all issues arising from individual transit trips taken and paid using an
account established through the OSFS. These claims are unique in that they originate with use of
payment media at the point of entry or acceptance to TTC’s transportation services.
Payment claims arise from the exchange of funds between a customer and TTC. For transit
accounts established using media issued by financial institutions, exchanges of funds are
documented on the customer’s account statements from the financial institution. These customer
claims are handled directly with the financial institution, or the issuer of the payment media. The
Central Processor will record and make available information about payments made from
customers’ accounts to customers and authorized personnel for the purpose of supporting the
resolution of payment claims made through their issuer. The back-office claims functionality
supported via the Central Processor must be certified as PCI-DSS compliant and should contain
all necessary and sufficient information to support any and all claims that customers could
potentially make.
The Central Processor will also provide auditing and issue tracking capabilities for intake and
resolution of all customer claims. All claims and issues will be tracked to completion and
archived.
The Central Processor must be capable of processing a refund or adjustment to a customer’s

credit or debit card on the same business day, or as determined by CBA rules, at an appropriate
time after an investigation by representatives of the Private Partner determines that resolution via
a refund is appropriate and authorization for a refund or adjustment is given. Refunds and
adjustments should only be made to a customer account that is active and registered with the
Central Processor.
Refund processing must result in automatic generation of a statement for financial reporting and
auditing purposes. The refund process should interface with risk management and business
Page
62
intelligence functions, as described below. This interface will support analysis and investigation
of account usage and payments, as well as other risk management activities required of
merchants.
The Central Processor provided by the Private Partner must be capable of supporting a balance
protection program for Pre-Funded TTC fare products. This program would ensure customers
whose eligible contactless media was lost or stolen against the loss of remaining Pre-Funded
product balances in their transit accounts only, provided that:
• Customers registered their transit accounts in the balance protection program in advance
of the loss of their contactless media according to guidelines established by TTC and the
Private Partner;
• Customers reported their contactless media as lost or stolen according to guidelines
established for the Program.
Any proposed protection plan must comply with existing accepted regulations, rules, and
practices of the financial services and payments industry in Canada.
Provided customers chose this option, the Central Processor would support generation of an
email notification about the balance protection claim.
Likewise for co-branded closed-loop media, issued directly by the TTC or through a third party
on TTC’s behalf, the Central Processor must support renewal and re-issuance notifications.
Registration should be accomplished under TTC’s balance protection program, as outlined
above, and would be a prerequisite for providing this customer service option. As part of the
notification and re-issuance processes, the Central Processor must provide support for self-
directed information access and media renewal through interactive processes accessible on the
Web Site and through the Customer Call Centre.
The OSFS must be capable of immediate broadcast of the addition of a lost or stolen contactless
payment device to the centralized hotlist, as well as to any local hotlists, should these be
incorporated in the proposed solution, on all contactless readers at all points-of-entry. Likewise,
the OSFS Central Processor must be capable of accepting hotlists from card associations and
other financial industry service providers, and populating the centralized hotlist on the Central
Processor, or at other components and functionalities comprising the OSFS system solution.
Processing and procedures for updating Reader Assembly hotlists will need to be designed and
implemented according to accepted standards of the financial services and payments industry.
Affirmation of receipt of updated hotlist information by all components of the OSFS should be a
prerequisite for the timing of customer refunds. The Central Processor would also be configured
to transfer the remaining balance to another account provided that the account was established
Page
63
using a contactless device accepted by TTC. The Private Partner may propose other options for
remuneration to the customer for incorporation into the functionality for the OSFS.
3.2 Processes Specific to Transit Merchants
3.2.1 Automatic Reload of Transit Accounts

The OSFS must support the automatic reload of all Pre-Funded fare purchases. Customers will
have the opportunity to “opt-in” for automatic reloading of their transit account.
In the interest of good customer service, the OSFS will support the following customer options
for automatic reloading:
• The frequency of the automatic reload;
• For Pre-Funded pass products only, the number of days prior to their expiration that
automatic reload will occur;
• For value-based Pre-Funded reloads only, the balance threshold at which the automatic
reload will occur for any value-based Pre-Funded products.
The OSFS must be configured to allow table/rule-driven settings of the number of authorization
attempts that will be allowed for the purpose of automatically reloading an account. For each
declined authorization, the OSFS must operate consistent with the procedures listed above in
earlier parts of Section 3. Additionally, in the event that a Pre-Funded account is no longer valid
due to excessive decline responses, the OSFS must be capable of alerting registered automatic
reload users of the card status via email or SMS text messages, or other similar means.
All Automatic reload of transit accounts will comply with Canadian Banking standards. In
particular, auto reloads using Debit accounts will only be done on a strictly periodic basis (i.e.
monthly) and only for a fixed amount. If any of these parameters changes, the OSFS must
notify and obtain from the customer permission to accept these changes.
3.2.2 Customer Claims (Non-Chargeback) Intake and Processing

The OSFS must efficiently process complaints and inquiries from customers. Processing of
claims supported by the back-office (other than chargebacks) will be addressed in two
categories:
• Claims of an inaccurate fare payment calculation resulting from the acceptance of an
open standard, bank-issued credit and debit contactless devices. These claims may be for
payments of Pre-Funded purchases, or as for Single Trips (PAYG) transactions at fare
gates, bus fare boxes, and other points of entry to TTC’s transit system.
• Claims resulting from the sale or reload of anonymous open or closed-loop open standard
contactless devices at points of sale owned or operated by TTC that accept cash.
Page
64
The OSFS must be capable of supporting compilation and management of claims from all
sources of customer contact with the TTC, including:
• The Web Site provided by the Private Partner;
• Customers’ phone communications with the Customer Call Centre;
• Letters and e-mails directed to the TTC;
• Walk-in claims submitted at TTC’s Customer Service Centre at 1900 Yonge Street.
Data captured for claims processing must be consistent with data required for processing
payment claims in an open standards processing or retail merchant environment. At a minimum,
the OSFS must capture, process, and support management of the following information:
• Customer name, address, phone number, and email account;
• Account number and payment media type and issuer;
• Claim reference number;
• Date, time and location of incident;
• Amount of claim;
• Description of claim, with comments field;
• Point of Entry or Point of Sale Device serial number;
• Comments field for investigation process;
• Investigation result code;
• Approval code and authorizing entity or individual;
• Claim resolution amount;
• Method of claim resolution;
• Resolution date;
• Processing date.
Once an investigation has been completed and a determination made, claim disposition will be
fully automated so that investigation and resolution can occur typically in less than two calendar
days. The resolution period will be explicitly presented to the customer as part of the terms and
agreement.
The OSFS will support the following claim resolution and disposition processes:
• Calculation of pro rata payment amounts for all fare products based on time and date of
claim receipt;
Page
65
• Preparation of a claim disposition statement that can be generated and sent to customers
as an e-mail, an SMS text message, or as automatically generated reprinted
correspondence for mailing to the customer;
• Menu driven selection of resolution codes and descriptions;
• Ability to apply credits to customer accounts for next business day payment;
• Reporting of claims resolved;
• Preparation of a consolidated financial statement and reconciliation to settlement files;
• Tracking of claims processed and outstanding claims in queue;
• Account closeout; and
• Transfers of balances and historical data to new accounts.
Additional functionality may be defined during Design Review.
3.2.3 Risk Mitigation

Because financial industry payment media is involved, risk mitigation takes on the dimension of
assuring that risk performance falls within financial industry and card association guidelines for
acceptable risk management performance. The Private Partner must comply with all risk
management procedures and guidelines of the financial services industry and of payment card
associations regarding acceptance of contactless credit, debit, and GPR devices. TTC requires
that these standards apply to all open standard media accepted for payment of TTC fares,
whether the media is issued by financial institutions or other entities.
TTC requires that the OSFS must be capable of the specific functionalities described in the
sections below.
3.2.3.1 Fraud Detection and Analysis

The OSFS must be capable of and support end users in dynamic review of ongoing and historical
processing data in order to detect suspicious purchase, payment, and usage activity. This
dynamic review must permit immediate remedial steps, primarily in the form of hot-listing of
card devices and broadcasting to stakeholders, as well as system-wide to all OSFS end devices
and operating infrastructure, of information or instructions that is pertinent to managing risk.
The OSFS must support timely review of data and the gathering of information on suspicious
activity and potential fraud. Fraud detection and analysis must use best-in-class financial
industry practices and procedures, including but not limited to:
• Batching of inquiries to payment device issuers;
• Conversion of inquiries into hotlists ready for uploading and broadcasting to end devices;
Page
66
• Matching customer inquiries originating from the Web Site, the Customer Call Centre,
and other sources to merchant-hot listed contactless media and devices;
• Analysis of use and purchase patterns that are considered suspicious (e.g., multiple
purchases of high-value fare media in the same day, or over a short period of 2 or 3
days);
• Detection of abnormal, or extraordinary contactless device usage;
• Device tracking issues.
Additional parameters, procedures, and techniques for fraud detection and analysis will be
detailed during Design Review.
As guidelines, the Private Partner must configure the Central Processor to support effective risk
management in a retail merchant environment must be taken into account, as well as capabilities
specifically demanded by transit merchant operations. Transit expertise from TTC should be
used by the Private Partner in this case to further enhance the Private Partner’s risk management
efforts. The fraud detection and analysis system must be capable of generating alerts, state and
status reports automatically and should not solely rely on manual investigations.
Results from all risk management and fraud detection activities must be tracked and reported to
TTC and other stakeholders and partners in the OSFS system and business network.
3.2.3.2 On-Line Authorization

The primary barrier against financial loss is online, real-time authorization with issuer databases
of active and inactive contactless media and devices. The OSFS must be capable of real-time
access to all required pre-authorization, authorization, and authentication capabilities of the
financial services industry and other entities issuing devices for acceptance at TTC. The OSFS
must permit active, real-time access to databases and information stored at the Central Processor.
Additionally, the OSFS must be capable of supporting risk management procedures, systems,
and activities that are consistent with those of retail merchants, as well as activities required by
TTC acting as merchant accepting payments using open standards devices. This capability must
extend across a full range of parameters, including but not limited to:
• Pre-Funded purchase amount by account;
• Pre-Funded fare product purchase by type;
• Frequency of Pre-Funded intra-business day purchases, set by time interval and location
of usage;
Page
67
• Frequency of Pre-Funded inter-business day purchases, set by time interval and location
of usage;
• Single-Trip usage and payment transactions, by day, time, and location of usage;
• Device status, functionality history, including capture of data regarding tampering, and
other activities;
Parameter settings and data about usage will be controlled and accessed through the Central
Processor. Access and control will be made available to authorized personnel in a secure
manner in compliance with PCI-DSS.
3.2.3.3 Operation in Orphan Mode

In the event that real-time authorizations or pre-authorizations and other, dependent or related
business operations are interrupted because of telecommunications failures, or degraded service
the OSFS solution provided by the Private Partner must be capable of and support the operation
of all equipment, components, services, and systems in orphan, or off-line mode, performing
“stand-in” transactions until network communications are restored. The characteristics of “stand-
in” processing will be parameter driven, and include the setting to stop all processing until full
system functionality is restored. This setting may be based on time or number of transactions as
determined by further risk profile analysis. Once telecommunications are re-established the
stored transactions will be forwarded to the central processor and processed as stored and
forward transactions (i.e., no signals are sent back to the field devices as the transaction has
already occurred).
Orphan mode operation will require additional risk mitigation capabilities. Store and forward
will require the payment devices storing the transactions to be PCI compliant. It will also require
additional business logic for accepting timely payments at Reader Assemblies.
Note that EMV-compliant media are specified completely for off-line authentication and may
require additional parameters, processes etc. to be executed once the telecommunications path is
restored.
TTC requires a second layer of risk mitigation to control acceptance of contactless devices
through the presence of a local resident hotlist at Reader Assemblies. The OSFS must be
capable of supplementing this capability by enabling periodic downloads of transit-merchant
hotlists to readers. The merchant hotlists may be distinct from the global hotlists generated by the
financial industry as well as limited in number and scope.
The localized, reader-resident hotlist must be capable of retaining information about recent
transactions at both an individual, stand-alone reader, or from readers that have been daisy-
chained as part of a fare gate array in a station complex. This functionality is present in order to
Page
68
enable “pass back” protection, as well as to allow for setting transaction ceilings. This capability
in orphan mode must be identical to the on-line capability available through the Central
Processor for the OSFS. The Private Partner may propose alternative solutions that assure that
passback protection for either an array of fare gates at a station entrance and/or a combination of
station entrances or stations is possible.
In orphan or off-Line mode, the entire decision to allow a customer to proceed is contained
with the Reader Assembly. From a risk mitigation point of view and customer acceptance,
this mode should appear no different than the on-line mode.
In the event of orphan-mode operation, whether localized to a specific reader or system-wide, the
OSFS must be capable of uploading data from orphaned POS’s, processing the data, and then
globally refreshing all end devices, components, and systems comprising the OSFS and
accounting for all payment and usage transactions.
3.2.4 Business Processes in Support of Revenue Assurance
3.2.4.1 Sales Reconciliation and Reporting

The OSFS will support the preparation of financial reports in accordance with all TTC’s business
practices required to support fare payment business operations. In addition, the OSFS will be
designed to provide processing and posting detail for every transaction that occurs. By
transaction is meant all activities involving the exchange of funds, whether electronic or in cash
(for example, at Fare Media Vending Machines), or the usage of payment media at any point of
acceptance in the OSFS solution.
All details regarding the transaction must be captured in a manner that assures accurate and
comprehensive identification and posting of all fare payment and usage activity required by
TTC; prevents loss of data and accounts for possible processing delays due to intra- and inter-
day business activities; assures data security, integrity, and completeness; and that enables full
compliance with PCI-DSS. In providing the OSFS solution, the Private Partner must incorporate
functionalities, controls, and features that fully recognize and, in the performance of all required
business functions of the OSFS, compensate for operating conditions that will occur in the TTC
“merchant” environment.
The OSFS will support auditing, reconciliation, and reporting of sales and usage activity by
capturing and providing access to comprehensive information on the status of all system
components and functionalities in the transaction processing chain.
At a minimum, the following reporting capabilities must be available in electronic format using
commercial, off-the-shelf programs and in on-demand printable format:
• On demand, one-to-one reconciliation of Single-Trip (aggregated and non-aggregated)
and Pre-Funded transaction clearings with bank deposits made by the merchant acquirer
to TTC’s depository account at the transaction-level detail;
Page
69
• Calculation and recording of all revenues, fees, and chargebacks in the deposit ledger
account of TTC;
• On-demand reconciliation by unique usage and payment transaction of fees charged by
card associations, networks, TTC’s internal switch application, and TTC’s merchant
acquirer;
• On-demand capture and comparison by individual points of sale and by unique fare
product types of all usages;
• Report of refunds pending and processed because of claims, account transfers, and
account close-outs;
• One-to-one matching of Pre-Funded transaction clearing records to bank deposit records;
• One-to-one matching of Single Trips (PAYG) to the transaction clearing records to bank
deposit records;
• Receivables report for each by issuer;
• Single Trips (PAYG) usage report;
• Pre-Funded liability report that captures all funds added, usage, refunds, and
chargebacks, as well as the opening balance liability to customers at the beginning and at
the end of each calendar month.
Detailed reporting capabilities will be identified, defined, and finalized during Design Review.
To assure that the full range of reports required by the TTC which will be identified throughout
the development and operating of the OSFS system can be made available, the Private Partner
must provide:
• Access to raw financial transactional data (appropriately obfuscated via tokenization);
• Access to transit data associated with each of the above transactions, including but not
limited to: date, time, Reader Assembly position and location, direction of travel, etc. of
transaction.
• Ability to integrate this data with other TTC data/services into an independent data mart
and business intelligence services system.
As described below, TTC will rely on a Data Mart provided by the Private Partner to access data
and generate reports. During Design Review, TTC will provide specific examples of report
formats that it requires to assure that the Data Mart is capable of satisfying TTC’s business
requirements.
Page
70
Of primary importance will be the identification by TTC with aid and cooperation from the
Private Partner, of essential financial and transit data elements required for the Data Mart
and business intelligence function. During Design Review, all data sets and data elements,
whether unique or derived, will be identified, reviewed, and finalized.
3.2.4.2 Chargeback Management

In support of acceptance of payments made with bank-issued media, the OSFS must support
management of chargebacks, and related inquiries and disputes according to business rules and
procedural requirements defined by card associations and merchant acquirers. Generally, card
association refers to VISA and MasterCard, though American Express, Discover, and other
entities have similar chargeback functionalities and procedures. Merchant acquirer refers to
processors and the affiliated financial institutions that execute authorizations and settlement.
The OSFS must incorporate all functionality and data elements required by the financial services
and payments industries to enable and assure management of chargebacks, including accurate
calculation, processing, and payment of interchange rates and other fees.
Key business processes that must be supported are:

• Management of chargeback inquiries and disputes, including but not limited to accessing,
compiling, and responding with required transaction information;
• Determination, processing and administration of refunds;
• Identification and analysis of opportunities for chargeback claim rebuttals stemming from
duplicate processing, customer error, and improper application of association rules;
• Processing and reporting of financial and data streams.
• Automated daily and monthly reconciliation by card types and by fraud and non-fraud
chargeback categories;
• End-user initiated ad hoc status reports across all processing, reconciliation and reporting
functions;
• Direct electronic data transfer from merchant acquirers, American Express, Discover,
and other issuing and processing entities, as required, including the receipt and storage of
claim or informational requests originating with merchant acquirers;
• Supporting analytical tasks performed during the investigative process, including but not
limited to the following:
o Review of incoming data for financial accuracy and completeness;
Page
71
o Ascertaining data integrity;
o Validation of charge backs against original transactions;
o Analysis of historical activity by account, including search capabilities for

multiple charge backs by a single account, pending charge backs, and pending
reversal actions;
o Online formulation and preparation of a rebuttal response;
o Online classification of chargeback records and documentation of actions taken;
o Automated monitoring of chargeback claim progress towards resolution

consistent with deadlines prescribed by card associations;
o Tracking of charge backs for closed-loop, TTC-issued products, or with co-

branded, general purpose reloadable products;
• In the case of closed-loop fare payment media, query capabilities regarding balances and
transactional histories for both payment and usage;
• Automated capabilities to negative list media and report recovered funds in the case of
closed-loop fare payment media;
• The capability to assemble and exchange in electronic format documentation from the
back-office system for use in dispute resolution, such as screen shoots, reports, facsimile
receipts, and original claims transmittals.
• Automated data integrity and uniqueness tests, which match and load incoming data with
updated and transaction-specific information that concern prior reversal activity and
duplications, and loading and storing of compiled data in dedicated tables;
• Generation of facsimile receipts for use in disputing charge backs;
• Manage processing of and administration of payment adjustments for customer claims.
3.2.4.3 Data Integrity and Quality

The Central Processor must perform periodic data integrity checks for all data that is captured for
reporting, analysis, and support of business operations. Accurate and complete file downloads to
the transaction level detail are required in order to support operation of all OSFS reporting and
analytical support functions. Data integrity checks must account for timing issues that may occur
because of unavailability of telecommunications with Reader Assemblies and other equipment
operating as part of the OSFS at the time of data transfers. Procedures to ensure data quality
Page
72
must be configured in a manner so that the data capture (in particular the transit portion of the
data) is an accurate representation of the actual data (for example, GPS coordinates for a
transaction on a surface vehicle), are de facto actual, or within a high degree of certainty
correspond to the actual coordinates where the transaction took place.
Financial services and payments industry best practices for ensuring data integrity and quality
must be followed. The Private Partner must demonstrate capability and positive results
experience in assuring data integrity in processing electronic funds transfers and payments.
3.3 Business Intelligence Reporting and Processing

The OSFS must provide and support Business Intelligence Reporting and Processing across all
business and functional requirements. TTC requires a distinct data repository, or Data Mart,
within the Central Processor functionality that captures information from every element of the
transaction processing and operating chain. Additionally, the Business Intelligence and
Reporting function must be scalable and fully redundant.
At a minimum, the business intelligence functionality must support all financial and planning
functions in addition to the following three areas used to analyze, evaluate, and plan short and
long term TTC and Private Partner business operations:
• Transactional Integrity;
• Operations Performance;
• Customer Satisfaction.
3.3.1 Transactional Integrity Processing

The OSFS must support reconciliation of all usage and payment activity on a one-by-one usage
and payment transaction basis. Reconciliation should be enabled by capturing specific data that
originates from the following sources:
• Contactless devices presented for payment and access to the TTC system;
• Contactless readers at the point of sale or system entry;
• Field devices that respond to contactless media acceptance and permit access to
transportation;
• Field devices that provide location specific data that is used to enhance data capture for
usage and financial transactions;
• Communications devices that enable processing of contactless device data upstream from
the back-office, the merchant acquirer, and an issuing entity;
• The Web Site and its operating system;
Page
73
• The Customer Call Centre and associated IVR system; and
• All point of sale and/or reload locations, or other entities (e.g., such as schools,
universities, social benefits organizations, etc.) involved in permitting use of TTC’s
transportation services through issuance or use of open standards contactless media.
The OSFS must include functionality to populate specific data fields that have been created for
the reconciliation process, as well as comply with PCI-DSS requirements. The OSFS must be
capable of exception processing so that corrective actions may be taken in the event of an
interruption in communications.
Accepted practices for exception processing must be followed, including automated exception
processing procedures.
3.3.2 Operations Performance
An account-based OSFS requires performance monitoring to ensure compliance with card
association procedures, sustain operational viability, and track progress towards business goals.
The back-office must access information in real-time, as well as produce standard and ad hoc
reports, in order to support performance reporting for the OSFS.
At a minimum, performance criteria that apply to account-based systems must include:

• Sales availability;
• Real-time versus store-and-forward processing ratio;
• Transaction success rate for real-time versus orphan mode;
• Wireless network availability for buses;
• Authorization speeds;
• Denial processing rates for Single Trips (PAYG) and Pre-Funded payments;
• Fraud loss rates;
• Size, accuracy, and refresh performance of hotlists;
• Data accuracy and capture rate.
Additional requirements will be identified and finalized during Design Review.
Since the OSFS for TTC must be configured to process transactions and provide support services
in real-time, it requires efficient, robust, high Quality of Service (QOS) telecommunications
network and supporting telecommunications operations environment. Network operations must
be supported by active, real-time monitoring and reporting through dashboards to ensure all
components of the OSFS operate via a real-time connection to the Central Processor.
The OSFS must monitor, record, and provide access to information essential for remediation,
root cause analysis, and disaster recovery of all network operations. In order to do so, the
Page
74
Central Processor must be enabled with a Data Mart component that permits end users direct
access to and control over use of data required to support telecommunications operations.
The OSFS will capture information about the status of the following system components and
functions through a series of programmable system sweeps made available through on-screen
reports, dashboards, and alarms including, but not limited to:
• Communications network status: the Central Processor must use and/or compile
information from a monitoring program of network status, including disaster recovery
sites, as well as all remote sites where payment system equipment resides.
• Field equipment: the Central Processor must compile the status of equipment in the
payment processing chain, including but not limited to contactless readers, fare media
kiosks/vending devices, and fare gates.
• Transaction processing: the Central Processor must enable analysis, data accumulation,
and placeholders for individual messages or thresholds to scan transaction log files from
the current processing stream. This process must automatically generate reports on:
o Gaps in transaction processing according to POS location, time and volume based
parameter settings;
o Excessive delay request before reaching the merchant acquirer;
o Slow response times from the merchant acquirer;
o Reversal processing from the merchant acquirer or internal to the Central Processor;
o Denial processing by code (used as a measure of internal and external system
throughput);
o Issuer or switch unavailability;
o In-system, off-line processing volumes;
o In-system response times;
o Any interruptions in normal real-time transaction processing.
Additional measure to be monitored will be identified during Design Review. Processes for
handling alerts, notifications, and work orders must be identified by the Private Partner as part of
their submission, and will be subject to review and approval during Design Review.
The OSFS must be capable of automatic and manual initiation of work orders and targeted alerts
to predetermined recipients responsible for equipment and network preventive and corrective
maintenance, event remediation, field operations, and customer support. In addition, automated
alerts must be disseminated by email, web alerts, and SMS text messaging. The OSFS must also
be capable of supporting the generation and dissemination of manual alerts and work orders as
the result of observed field conditions by Private Partner, by TTC personnel, as a result of
Page
75
information intake at the Customer Service Call Centre, or centrally via the Maintenance
Management Control Centre.
The OSFS must support generation of monthly management reports summarizing all
performance measures and reconciling processing monitoring software messages with opened
work orders and event reports. These performance measures will be fully described in the terms
and conditions agreement.
3.3.2.1 Sales Availability

As part of the Operations Performance functionality, the OSFS must be designed to provide a
universal metric of system readiness to accept fare payments. This metric, hereafter referred to
as Sales Availability, reflects a customer-centric perspective in the required readiness and full
functionality of the end-to-end payment system to perform sales transactions, and/or accept
payments at system points-of-entry in a real-time processing environment. It is also intended to
reflect the requirement of financial institutions and payment industry business partners for “on-
line, real-time” pre-authorizations, authorizations and authentications, as well as timely
processing of funds transfers by end-of-business day in a manner that is typical of a retail
merchant sales environment.
The Private Partner is required to report daily on the Sales Availability of all OSFS hardware,
software, firmware, and related support systems that are in operation for TTC. The Private
Partner will also enable the generation of ad hoc, on-demand updates on Sales Availability for
the OSFS operating for TTC.
This report will automatically be generated by the OSFS and be in either PDF format, EXCEL,
web page, or similarly common, accepted, and available format. Details of proposed solutions
will be presented during Design Review and subject to approval by TTC.
Calculation of Sales Availability must incorporate, at a minimum, the performance data in terms
of hours of full functionality from the following:
• Telecommunications network;
• Central Processor internal operations;
• External processing operations and systems (i.e., merchant acquirers and issuer
processing systems);
• Field maintenance and revenue servicing operations.
Further details of the Sales Availability performance measure will be provided during Design
Review.
Page
76
3.3.2.2 Telecommunications Network
Optimal revenue processing and risk management requires maximum possible operational up
time or availability. While all POS devices in the system must be capable of processing payment
transactions in orphan mode (i.e., off-line), network unavailability prevents authorization/pre-
authorization by the Central Processor, either independently or in conjunction with the financial
and payment networks. This condition potentially increases financial risk for the TTC.
The Central Processor must be capable of uploading network status messages, and details of
work orders and trouble tickets, that impact network uptime. The starting and ending times of
such events should be accumulated by day and stored in the back-office for inclusion in the
overall calculation of sales availability.
3.3.2.3 Central Processor
3.3.2.3.1 External Processor Operations

In order to process a Single Trips (PAYG) or Pre-Funded payment transaction, the OSFS must
process an authorization request to the issuing entity of the contactless payment device. The
OSFS will initiate authorization requests and capture results. Unsuccessful transactions,
stemming from failures in the processing stream, are recorded as denial messages from the
merchant acquirer. A constant stream of unsuccessful transactions due to external system-related
errors may be an indicator of problems with the bank processor.
The OSFS must be capable of tracking responses from issuers and processing systems external to
the OSFS, including but not limited to recording the date, time, and frequency of such messages
for calculation of the overall sales availability, and according to standard financial industry and
payment services practices.
3.3.2.3.2 Field Maintenance and Revenue Servicing Activity

The OSFS will monitor and report on the impact of all field maintenance and revenue servicing
activity on Sales Availability. All maintenance activity that effects normal operation of OSFS
equipment will be monitored and reported through the Central Processor. Reports will
encompass all system and equipment events that result in or have an impact on corrective and
preventive maintenance.
The Central Processor will capture and report on specifics of start and end dates and times,
locations of event, specific equipment affected, and all other necessary details to support
assessment of equipment and system status, and manage and report on remediation efforts.
This reporting function must be supplemented by implementation of a commercially available

Maintenance Management System. The design and implementation of the Maintenance
Management System must be accomplished in a manner that supports efficient management of
the full range of maintenance activities required to support the OSFS and meet TTC’s
Page
77
performance standards. At the same time, the design and implementation of the Maintenance
Management System must not impede or interfere with security and risk management
requirements of open standards payment systems and components.
3.4 Customer Satisfaction

The OSFS must provide a repository for quantitative information that can be used to assess
customer satisfaction across the range of services and interactions being offered. The repository
must be capable of compiling the results of activities performed by the Private Partner, including
other participants and participants in the OSFS solution, such as, but not limited to Customer
Service Call Centre activities, customer inquiries through the web site.
3.5 Central Processor
3.5.1 Overview
The OSFS for TTC will be an account-based fare payment system. It will be built according to
business, operating, and technical principals and standards for electronic transfers of funds
through credit, PIN-debit, ACH, and other proven means used by the financial service and
payments industry. TTC requires that the system solution support its customers in a payment
experience for transit fares that in all key attributes equals customers’ experience in purchasing
at a retail store.
In this vision for transit fare payment, the Central Processor is key to executing the Business and
Functional Requirements described in Section 3. TTC requires that the Central Processor fulfill
the following critical business functions:
• Fare Policy Repository and Calculation Engine for all sales and reloads of transit
accounts including but not limited to the Web Site, the Customer Call Centre, and Non-
TTC Retail Sales and Reload Locations;
• Payment authorization and transaction processing for all sales and reload of transit
accounts initiated at locations managed by the Private Partner, including settlement of
accounts and deposit of funds to TTC’s DDA bank account;
• Central data repository and control location for all OSFS business operations and
integrated devices installed on TTC property, or interfacing with the Central Processor;
• Central data repository for all business and operating reporting and Data Mart functions
required by TTC to support: TTC’s financial and business reporting requirements, its
revenue operations as merchant, its continuous monitoring of system performance and
management of the Private Partner under terms of TTC’s agreement with the Private
Partner.
The Private Partner will design, build, operate, and maintain the Central Processor according to
the requirements provided in the following sections. Only individuals authorized by TTC and the
Page
78
Private Partner will have access to and control over functionalities, data, information, operating
parameters, and all other business functions of the OSFS.
Only TTC will have authority to implement Fare Policy and pricing changes for fare
products, determine procedures and rules for acceptance of contactless media and devices
for fare payment, and affect any changes to the operation of the OSFS that would impact
its customers and revenue operations that control access to TTC’s transportation services
3.5.2 General Requirements

The Central Processor will be built using state-of-the-art, commercially available equipment and
software that conform with and support all payment industry standards. All hardware, operating
systems, database manager, components, and peripherals of the Central Processor will consist of
state-of-the-art commercially available equipment from OEM suppliers.
The Central Processor will be provided as an optional turnkey solution, with all necessary
processing, memory and expandability, data storage, and software applications to operate,
monitor, and manage the OSFS.
The Central Processor will have the following capabilities:

• Unified applications and controls for the entire OSFS;
• Table/template-driven parameters for all business functions;
• Data download for fare pricing tables, fare product tables, and fare policy procedures;
• Processing, in real-time and according to required transaction speeds and all payment
industry standards, of all payment, sales, reload and acceptance transactions for
contactless media and devices accepted for payment of TTC fares from all end devices
and points of sale and reload;
• Authorization, clearing and settlement of credit, signature and PIN-debit, and GPR pre-
paid devices in real-time and according to required transaction speeds and all payment
industry standards and protocols, including ISO/IEC, Canadian banking regulations and
applicable laws and regulations of the Province of Ontario, through merchant acquirers
all established networks for electronic transfers of funds;
• The full range of risk management operations and procedures to support merchant
acceptance of contactless open standard media and devices;
• Standard report generation, as defined by the TTC and financial industry requirements;
• Data Mart operations built on commercially available, distributed, multi-user industrial
strength relational database;
Page
79
• A test region capability and functionality to permit loading and testing of changes to
business and operating parameters prior to implementation, as well as for in-field device
testing for replaced/installed devices;
• Flexible database design to permit pre-loading of business and operating parameters prior
to implementation;
• Transaction processing control and monitoring;
• Point of Sale (“POS,” i.e., Reader Assembly, Fare Media Vending Device, etc.) and end-
device monitoring and control;
• Event monitoring, data capture, and storage across all business functions;
• Monitoring of system security;
• Capture and storage of historical parameter settings;
• Automated reporting of a security breach of any end-device installed on TTC property;
• Automated and user-programmable data redundancy, backup, and archiving for all
transactions, data, software to secure media without user intervention, such that no
system or subsystem failure will result in loss or degradation of data;
• Disaster recovery processes that are automatic and seamless, and that can be incorporated
into a TTC disaster recovery program if required;
• Scalability and independence of applications to address future TTC business
requirements and to assure that changes to unique business functions have no impact to
core Central Processor operations;
• Secure, controlled access and remote operation of Central Processor functions via a
system administrative function;
• User-friendly, menu-driven GUI interfaces with help functions;
• Capacity to support a minimum of 5,000,000 daily payment and/or usage transactions
without degradation of performance levels;
• Capable of supporting at least 10,000 TPS (transactions per second) during peak rush
hour activity;
• Full redundancy capability to allow continuous operation and transition to recovery sites
without effect on fare payment acceptance at TTC and other participants in the OSFS;
• 100% excess data storage capacity at the time of initial launch of the OSFS;
• Capability to accommodate a 100% increase in POS and other end devices for sale,
reload, and acceptance of fare payment;
Page
80
• Encryption of all data processing according to Canadian Banking standards and under full
compliance with PCI;
• Continuous global synchronization of all OSFS end devices with the Central Processor
for all business functions, Fare Table settings, data transfers, and time settings;
• Simultaneous receipt and processing of transaction data from all end devices in the OSFS
without impacting TTC’s required performance standards or any perceptible impact to
customers’ interactions with the OSFS;
• Processing error control and remediation, so that the Central Process can capture data
needed to detect processing errors, compile data on erroneous transactions, and format
and stream data into appropriate formats that allow same-day event remediation;
• Parameter settings used for detection analysis and reporting will be table/rule driven and
applicable to all data captured by the Central Processor.
3.5.3 Fare Rules Engine

The Central Processor will calculate and apply all fare products, pricings, and usage rules of
TTC’s Fare Policy in processing payment transactions.
The Central Processor will capture TTC’s Fare Matrix in a comprehensive series of parameter-
driven Fare Tables. Under direction and authorization from TTC, the Fare Tables will permit the
Private Partner to globally set and change all parameters for the sale and use of TTC’s fare
products.
Access to this capability will be provided through a secure protocol that will not only require
two-factor authentication to be enabled, but also record access and all changes to Fare Tables
according to PCI-DSS standards.
The Central Processor will distinguish and record all categories of Fare Tables developed for
implementation. The Central Processor will record the status of Fare Tables throughout the
history of their development, use, and expiration and provide secure, auditable records of all
changes made to Fare Tables and related Central Processor functions.
Additionally, the Central Processor will be designed to:

• Permit menu-driven fare pricing changes that can be set for global application or can be
targeted to apply to specific TTC routes, lines, events using effective start/end dates,
start/end times, and location settings in any combination;
• Control visual displays on Fare Media Vending Devices, the Web Site, the Customer Call
Centre, and other end devices and systems used for retail sale and reload of contactless
media and devices that describe TTC fare products and pricings and enable customers to
properly select and pay for transportation; and
Page
81
• Store, automatically load, and automatically remove predetermined changes to the Fare
Tables.
In support of sales and reload of fare media used for customers transit accounts, all Fare Tables
and applicable parameter settings will be downloadable to end devices used for sale and reload
of fare media through any commercially available wireless telecommunications network.
Downloading of Fare Tables and applicable parameter settings affecting contactless media
acceptance will not interfere with normal transaction processing and acceptance of fare payment
at Points of Entry to TTC’s transportation services.
3.5.4 Automated Reload of Transit Accounts

The Central Processor will support automated reload of Pre-Funded transit accounts. The Private
Partner will furnish detailed process and transactions flows for Automated Reload as part of
Design Review.
3.5.5 Data Mart

The Private Partner will furnish TTC with a Data Mart. All OSFS business and operating data
will be stored and accessible to TTC and the Private Partner through the Data Mart.
TTC intends for the Data Mart to be used by personnel whose principal experience and
competencies reside in management and operation of TTC’s fare payment operation and its
transportation services. As such, the Data Mart will be outfitted in a manner that supports easy
access and use by these “power” business end users, without the need for special, professional
competencies in computer programming and computer science. TTC’s business end users will be
expected to have competency in common, commercially available office programs, such as the
Microsoft suite of office products in order to understand and utilize Data Mart tools and
functionalities.
The Data Mart will use state-of-the-art principles of relational database design and management.
It will be ODBC compliant, support SQL commands and queries, and contain only standard,
non-proprietary instructions, procedures, and commands.
The Data Mart will interface – using open standards – with TTC’s existing WAN. The Data Mart
will be equipped with security software that allows for secure, two-factor authentication access
for use of the Data Mart. Security software for the Data Mart will comply with PCI-DSS, as well
as all other applicable security standards required by card associations, issuers, financial services
and payment industry regulators, and other entities responsible for assuring the security of
electronic funds transfers and payment processing.
The Data Mart must be hosted at a Canadian site and must comply with all applicable financial,
security, and privacy standards, including but not limited to PCI-DSS and MFIPPA.
Page
82
The Data Mart will be designed and implemented in a user-friendly manner with a full range of
business tools that permit TTC personnel easy access to:
• Generate reports;
• Configure and query all database tables and relationships;
• Customize and edit queries and reports;
• Download data either on an ad hoc or regular, pre-determined bases without impacting
the processing capabilities of the Central Processor;
• Allow creation of new datasets, tables, and other business intelligence functionalities and
tools as required;
• Allow data integration and fusion with other TTC data and services in order to provide
TTC with a comprehensive operations overview.
The Data Mart will automatically capture and retain all data and information related to the
operation of the OSFS. At a minimum, data sets described in subsequent sections will be
generated by the Central Processor and captured by the Data Mart. A final, comprehensive listing
of data sets will be developed during Design Review.
The Data Mart will have the capability to store and retrieve required data for a period of no less
than seven (7) years. Data that exceeds this time limit will be automatically transferred to
permanent archival storage. Archived data will be easily reloaded to the Data Mart for query and
reporting purposes without excessive delays and in a timeframe that permits TTC and other
authorized end users timely support of business operations.
All data capture, storage, and retrieval functionalities of the Data Mart must comply with all
applicable Canadian laws, including but not limited to laws regarding the storage, access, and
use of private data.
3.5.5.1 Standard Reports

The Data Mart will be capable of supporting the production of standard reports. Reports will be
viewable on-line and capable of being downloaded and produced as hard copy.
The Data Mart will be configured so that TTC, or other authorized users, can develop and place
into regular production any number of standardized reports using pre-defined data sets populated
by the Central Processor and available through the Data Mart.
Any Standard Reports will be exportable to commercially available software applications

without the need for extraordinary steps or procedures arising from the design of the Central
Processor or the Data Mart.
Page
83
Standard Reports will be available in a menu-driven format to allow for production of “flash” or
preliminary versions on an ad hoc basis.
The following are categories of Standardized Reports that TTC requires. Many data elements are
in common among the report categories required below. A full description of the report and
supporting data elements will be provided during Design Review. All required reports will be
available to TTC in a variety of formats, including but not limited to PDF, EXCEL, and web
page.
Required Standard Reports are as follows:
• Revenue and Ridership Reports;
• System Status and Maintenance;
• Financial Reconciliation and Reporting;
• Reports required by TTC for planning purposes; and
• Sales and Reload.
Additional reports will be specified during Design Review.
3.5.5.2 Ad Hoc Reports

The Data Mart will support queries and extracts of data through a series of menus and screens
that enable end user to construct ad hoc reports. All defined queries will be available both as
screen displays and as outputs for printing by each authorized user. The Data Mart will be
capable of storing queries for future use, or for use as the basis of a Standard Report.
3.5.5.3 Data Universe

TTC requires that the Private Partner, with input and cooperation from TTC, define the universe
of all data elements required to support the generation of Standard Reports, as well as those
elements required for all monitoring and reporting functions of the OSFS. Subject to review and
approval by TTC, the Private Partner and TTC will finalize the scope of the data universe to be
made available at the launch of OSFS revenue service during Design Review. This description
must include details of the data base environment, connections, roles, tools, and business process
support functionality in support of the data mart. Subsequent to launch, the Private Partner, with
review and approval of TTC may recommend refinements and changes to the data universe that
aim to improve OSFS business results.
In defining the data universe, the Private Partner is required to incorporate all data elements
necessary to:
Page
84
• Support operation of an open standards “merchant” approach to fare payment, transaction
processing and settlement, risk management, business operations, and customer service;
• Support specific requirements of TTC as a “transit” merchant.
At a minimum, the data universe will consist of the following data fields:
• Transaction type (i.e., Pre-Funded or Post-paid, fare category and pricing);
• Posting date of transaction at the back office;
• Authorization request amount;
• Authorization transaction amount;
• Authorization response code;
• Address verification response code (Pre-Funded transactions only);
• Bank authorization trace number;
• Merchant ID number;
• Transaction reference number (distinct from the PAN);
• Transit agency;
• Transit service type (i.e., bus, train, etc.);
• Card type (credit, debit, dual);
• Unique issuer ID (for banks, BINs);
• Authorization ID;
• Clearing ID;
• Denial date;
• Denial reason code;
• Denial reason source;
• Registration date and time;
Page
85
• Registration cancellation date and time;
• Source of sale: web or Customer Service Call Centre;
• Pre-fund account reference number;
• Purchase type ID (i.e., to identify the type of Pre-Funded purchase made, based on TTC
fare policy matrix);
• Hotlist calendar date;
• Hotlist reason code;
• Total count of hotlist additions;
• Total count of hotlist as of date;
• Unique refund ID number;
• Refund date and time;
• Refund amount;
• Refund reason code;
• Refund approval code;
• Refund destination PAN;
• Authorized approver name;
• Authorized approver ID;
• Date and time authorized approver added to file;
• Date and time authorized approver deleted from file;
• Transfer original PAN number;
• Transfer unique PAN substitute identifier;
• Replacement PAN;
• Replacement of unique PAN substitute identifier;
Page
86
• Transfer amount;
• Account balance file: date account balance file is created;
• Paid balance;
• Transfer balance;
• Refund balance;
• Other balance(s);
• Passes start date;
• Passes end date;
• Terminal failure start date;
• Terminal failure end date;
• Failure code;
• Terminal disposition code;
• Test card PAN;
• Source of test card;
• Test reason;
• Ride status code;
• Tap number;
• Fare implementation date;
• Fare expiration date;
• Cost of tap.
Additionally, the Private Partner must identify and provide any additional transaction fields
required by the Canadian financial payments industry in support of TTC open payments,
including EMV. Other types of data strictly associated with transit (i.e., including but not
Page
87
limited to location and direction or travel of Reader Assemblies, surface vehicles, etc.) will also
be specified and finalized during Design Review.
As determined by TTC, the back-office must generate specific files compromised of select data
sets from the lists above. The files are the basis of specific reconciliation and reporting reports
that may be required by TTC, and that as a minimum, have been described as reports above.
They also serve as the basis for ad hoc reporting.
At a minimum, the composition and structure of files must enable:
• Financial reconciliation through capture of processing and posting details of each

transaction performed by the Central Processor;
• Exception processing through capture of processing, settlement, and posting details of

each transaction performed by the Central Processor;
• Authorization tracking and control through capture of all requests and responses from the
Central Processor and other systems;
• Clearing and processing reconciliation for banks, merchant acquirers, and all other
entities engaged in the processing of payment and/or usage transactions;
• Reconciliation of Single Trips (PAYG) settlement and clearing details through one-to-
one matching of transactions;
• Pre-funded account activity tracking and management, including activities by customers

or Customer Agents;
• Tracking of Reader Assemblies and other field equipment deployed or installed on TTC
property;
• Tracking of unpaid transactions;
• Tracking of all hotlisting activity by source of hotlist action;
• Tracking and management of refunds to customers;
• Management of communications and other systems failures;
• “Cradle-to-grave” monitoring and management of customer claims;
• Comprehensive tracking of all configuration and activity result messages, including but
not limited to decline reason codes, Reader Assembly acceptance result codes, failure
Page
88
codes, test card usages, customer service codes for resolution of inquiries; authorized
approver codes;
• Tracking of account balances on all transit accounts;
• Monitoring of current processing categories and fare pricings; and
• Tracking of positive and negative exception lists for transfers between all modes of
transportation by tap sequence, as required by TTC’s fare policies and procedures.
The above is provided in order to gauge the scope of what is required only and is by no means
exhaustive. During Design Review, TTC and the Private Partner will finalize the data universe.
Final approval of the data universe by TTC is required prior to the Private Partner moving ahead
with programming of the Central Processor, final design of equipment, and manufacture of
system components.
3.5.5.4 Maintenance Management System

The Central Processor will be equipped with and support a Maintenance Management System for
the OSFS. The Maintenance Management System will use commercially available software that
is capable of modification to meet the specific requirements of TTC and the OSFS. Required
capabilities include, but are not limited to:
• Monitoring and polling of the health and self-diagnostics of all OSFS equipment and
operating systems, including network connectivity, and tracking all events and problems
associated with end devices on TTC property;
• Automatic generation of work orders, dispatching of Private Partner’s maintenance

personnel, recording and reporting events to the Data Mart for the purpose of report
generation and system performance monitoring;
• Tracking all parts and inventory to be used in preventive and corrective maintenance of
end devices on TTC property;
• Supporting Maintainers in use of hand-held devices and communications equipment used

in performing preventive and corrective maintenance work in the field, including but not
limited to: providing screens for data entry that capture maintenance activity performed;
access to manuals, procedures, historical data on equipment performance and repairs; and
• Archiving all events and data associated with maintenance of the OSFS. (i.e., has its own
database).
The Private Partner will provide a detailed description of the Maintenance Management System
proposed for the OSFS, along with supporting operating protocols for corrective and preventive
Page
89
maintenance that are supported by and fully leverage the capabilities of the Maintenance
Management System. As part of Design Review, TTC and the Private Partner will validate and
finalize the required business and operational functionalities of the Maintenance Management
System. The final outcome of Design Review of the Maintenance Management System is subject
to TTC’s approval.
4 Marketing and Customer Communications for New OSFS
4.1 Overview
The Private Partner will develop and execute a comprehensive marketing and information
campaign (“Campaign”) for the OSFS. The purpose of the Campaign will be to:
• Drive customer awareness, understanding, and use of the OSFS, such that TTC’s
customers are encouraged, and ultimately prefer to adopt and use contactless open
standard media and devices for payment of TTC transit fares;
• Drive general awareness among residents and visitors who do not use TTC’s
transportation services currently, or who use public transportation services infrequently,
of the benefits of TTC’s OSFS and using contactless media for fare payment; and
• Assure customer awareness and widespread use of alternative, non-TTC sale and reload
locations such as the Web Site, off-property automated sales and reload locations, and
participating merchants in the Non-TTC Retail Sales and Reload Network.
Over the course of the term of the agreement, the Private Partner must propose the execution of
follow-up Campaigns that are aimed at sustaining interest and continued adoption of the OSFS.
These follow-up Campaigns will include refreshes of information and promotional materials at a
minimum of once per calendar year, and more often should the physical condition of materials,
or absence there of warrant their replacement.
The Private Partner will include the development of the Campaign in the Design Review
Process. To the extent that it includes, makes reference to, or uses logos and trademarks of the
OSFS, TTC, or TTC’s transportation services, including those portions of the plan that are
intended for non-TTC merchants and affiliates, the Campaign in all its aspects will be subject to
review and approval by TTC. Any posting or display of any materials for the Campaign, whether
or not TTC or TTC’s transportation services are referenced, requires prior approval from TTC
according to published guidelines applicable to posting of advertising and information materials
on TTC property.
Page
90
In executing the Campaign, the Private Partner will develop marketing and information materials
intended for use by issuers and merchants. In this regard, TTC will participate as the Private
Partner’s principal, though not exclusive merchant client.
To fulfill all requirements in this RFPQ, TTC anticipates the Private Partner to develop and
maintain a Non-TTC Retail Sales and Reload Network consisting of a broad range of merchant
partners and retail sales locations for contactless GPR media and devices. The Private Partner’s
marketing and information materials will be developed to be effective and useful across all issuer
and merchants supporting TTC’s OSFS implementation and operation.
4.2 Requirements
4.2.1 TTC’s Customer Base

As a public service entity, TTC must provide safe, reliable, and convenient transportation
services to all customers wishing to ride TTC trains and surface vehicles, including Wheel-
Trans. This mandate encompasses assuring that, as an option for all persons wishing to use
TTC’s transportation services, access to and use of new contactless open standard media and
devices is readily available and easily understood.
TTC requires that the Private Partner use marketing and promotional techniques that demonstrate
detailed awareness and understanding of:
• Consumer demographics, not only for customers in the TTC service area, but also for
consumers in general, recognizing that Toronto, and the Greater Toronto Area, is an
international destination for business and tourism;
• The range of consumer access, reliance, and use of traditional banking and non-
traditional means of executing financial transactions;
• Consumer awareness issues regarding contactless technology;
• Consumer awareness of and issues with use of payment cards for retail purchases;
• The educational role that marketing materials will play in addressing consumer concerns
about the OSFS specifically, of the multi-cultural and multi-lingual demographics of
TTC’s customers, of the City of Toronto’s and the Greater Toronto Area’s status as an
international destination for commerce and tourism, and about technology and
alternative payment systems generally; and
• Consumers’ awareness and use of TTC’s transportation services and of the potential
advantages to consumers and positive impacts of increased use of public transportation
Page
91
on individuals and on Greater Toronto Area residents, visitors, businesses, and other
members of the community.
4.2.2 Issuer Support Requirements

In accordance with payment industry best practices, the Private Partner will provide detailed
marketing and information plans for issuers of contactless open standard media and devices that:
• Address consumer awareness, both locally in the TTC service area, and more broadly in
recognition of Toronto’s prominence as an international destination;
• Establish an understanding of consumer demographics of both banked and unbanked

individuals;
• Address training for issuer employees and affiliates in the implementation and operation
of the OSFS; and
• Reflect to the fullest extent possible TTC’s adoption of a “merchant” approach to fare
payment.
4.2.3 Merchant Support Requirements

TTC requires the Private Partner’s marketing and information Campaign address not only the
needs of TTC as its principal merchant partner, but also the marketing and information needs of
other merchant partners that will be integral to the expanded sales and reload network for
contactless GPR cards and for purchase of Pre-Funded TTC fare products.
In accordance with payment industry best practices, the Private Partner will provide detailed
marketing and information plans for Merchants accepting, selling, and reloading contactless
open standard media and devices that:
• Include strategies to ensure customer satisfaction at TTC’s in-system Fare Media

Vending Devices and at Points of Entry (“POE”) to TTC transportation services, as well
as at other merchant POS locations, whether these locations are staffed or automated;
• Include formal strategies for coordination between Issuers and Merchants to optimize
adoption of contactless media and devices;
• Provide pathways for acquisition and installation of suitable POS devices, as well as
necessary support to institute contactless media and device payment processing;
Page
92
• Provide comprehensive guidance on implementation issues, including training for
merchants’ employees in the sale, reload, and acceptance of contactless media and
devices, with particular attention to contactless GPR media and devices;
• Provide guidelines for acceptance and tabulation of consumer feedback as a means to

informing refinements of merchant-specific solutions; and
• Establish protocols for measurement and evaluation of actual results relative to Campaign
initiatives.
TTC requires that the Private Partner either perform focus groups, or otherwise demonstrate the
effectiveness of the creative advertising materials that are being proposed. This should include
market testing, as well as analysis of results of OSFS operations that may be indicative of the
effectiveness of the Campaign.
TTC will work with the Private Partner to inform the development of information and
promotional materials by the Private Partner so as to assure awareness of TTC and transit-
specific issues and concerns. To the extent that any materials relate information about TTC, its
transportation services, or its fare products, the content, form, and scope of all customer
information and promotional materials will be subject to review and approval by TTC, which
will not be reasonably withheld.
4.2.4 Private Partner Affiliates

TTC requires that the Campaign bring awareness to all Private Partner affiliates specifically, as
well as stakeholders in the delivery of the OSFS generally. This marketing and information effort
should be at a minimum directed at and consider the following: contactless media and device
issuers; manufacturers of equipment that support contactless media and devices; processors;
payment acquirers; payment brands, and; purveyors of alternative payment systems and services.
4.3 Scope of Campaign
4.3.1 TTC In-Home

TTC requires that the Private Partner’s Campaign anticipate utilization of TTC’s in-system
opportunities for physical display and distribution of marketing materials and information about
the OSFS. In order to do so, the Private Partner must work through TTC’s contracted service
provider that manages all potential advertising space on TTC property. Contact information and
other details for securing advertising and display space on TTC property and its equipment will
be provided during Design Review.
TTC’s in-system opportunities for physical display and distribution of marketing materials and
information about the OSFS are defined and limited by the existing exclusive advertising
contracts. Specifically, these contracts govern the amount of media space for the following:
Page
93
• Posters within subway stations and on surface vehicles;
• Platform video screens;
• Metro News, a “newspaper-“style product available within the subway system (see
metronews.ca for additional details).
TTC will facilitate the Private Partners purchase from the current TTC advertising contractor of
other and/or additional media space, such as “wrapping” of TTC subway cars and surface
vehicles, turnstiles, and “station domination” for the Private Partner’s Campaign.
TTC can also provide opportunities for consumer education and information through the
following channels:
• TTC’s current web site;
• TTC customer information brochures (provided the Private Partner provides creative
development, print and production);
• TTC public address announcements within the subway system.
The Private Partner would be responsible for production costs of all marketing and information
materials to be placed in TTC media space for the Private Partner’s Campaign.
The Private Partner should note that the TTC neither owns nor maintains surface vehicle shelters.
Hence, the Private Partner will need to explore media opportunities for surface vehicle shelters
with the City of Toronto.
As part of the business and operating agreement with the Private Partner, TTC will permit the
Private Partner to place links on TTC’s website, on the web page addresses as determined by
TTC, to the web address for the Web Site to be provided by the Private Partner as part of the
OSFS solution. Technical details as well as guidelines for acceptable postings of such links are
posted on the TTC web site at www3.ttc.ca/Terms_and_conditions_of_use/index.jsp. Additional
details will be provided during Design Review.
The Private Partner is encouraged to identify additional opportunities for information and
promotional activities, such as tabling events, which could promote and otherwise enhance
customer awareness, knowledge about contactless payments, and acceptance and use of the
OSFS solution, customer service enhancements, and product offerings. During Design Review,
TTC will consider the appropriateness and value of these opportunities in the context of the
requirements of this RFPQ and the mutually beneficial business opportunities offered by the
Private Partner.
Page
94
4.3.2 TTC Guidelines for Advertising and Promotions
Details of guidelines for Advertising and Promotions are available through the contracted service
provider that manages availability and use of advertising space on TTC property. Contact
information and other details for securing advertising and display space on TTC property and its
equipment will be provided during Design Review.
TTC will provide access to guidelines for use of its Logos and Trademarks during Design
Review.
4.3.3 Graphics Inventory

TTC will provide access to dimensional graphics and copy during Design Review.
4.3.4 Duration of Campaign

TTC requires the Private Partner to initiate the Campaign in coordination with appropriate key
milestones in the overall OSFS Implementation Plan. The launch of the Campaign will be
subject to TTC’s final review and approval.
The Campaign will endure for at least 6 months after full implementation of the OSFS. During
this phase of the Campaign, the Private Partner will maintain sufficient quantities of marketing
and information materials to assure constant presence and availability at designated display and
distribution locations of participants in the OSFS Program. This includes all TTC on-property
locations, as well as physical and virtual locations and display sites for all other affiliates and
participants in the OSFS Program.
During this phase of the Campaign, TTC requires that the Private Partner perform refreshes of
Campaign materials and information intended for permanent display. All initial posting and
subsequent refreshes of marketing and information materials will be done by the Private Partner.
During this phase of the Campaign, depending on actual achievement of goals for market
penetration and for use of open standard fare media and devices to pay TTC transit fares, the
Private Partner will be required to reconstitute the Campaign in a manner to achieve agreed-upon
goals.
5 Operating Procedures for New OSFS
5.1 Maintenance Support
5.1.1 Maintenance Management System

In addition to providing preventive and corrective maintenance for all OSFS equipment and
systems provided in response to this RFPQ, the Private Partner will furnish and adapt a
commercially available, off-the shelf Maintenance Management System. The Maintenance
Management System, configured in a manner that:
Page
95
• Allows for monitoring and reporting on the condition of all equipment, systems, sub-
systems, functionalities, and support services (such as telecommunications, transaction
processing by the Central Processor, etc.) needed for normal, in-service operation of the
OSFS;
• Enables timely status updates to be broadcast via email, SMS text message, and
automated phone messaging to all stakeholders in the operation of the OSFS, including
those stakeholders specifically identified by TTC;
• Enables automated generation of work orders for both corrective and preventive
maintenance;
• Dynamically calculates preventive maintenance cycles based on actual performance of

equipment and reports regarding the nature, components, and other relevant tasks
performed during corrective or preventive maintenance, or according time, cycles, and
other parameters as identified either by the OEM or other authoritative source or entity;
• Interacts with inventory management systems and logistics programs to assure an

adequate supply of parts and materials to sustain operations according to TTC’s
performance criteria;
• Works in conjunction with the OSFS security/key management system used for open
payments.
Reports as well as raw data from the Maintenance Management System will be uploaded to the
Data Mart. At a minimum, data from the Maintenance Management System will be uploaded
daily throughout the year. TTC will have the capability to upload data at other intervals and with
greater frequency at its discretion through direct access to the MMS reporting and data
management engine.
The Maintenance Management System must incorporate industry best practices across the range
of functionalities offered, and include at a minimum both device management and monitoring
functionality.
5.1.2 Field Support

During FUT and for a minimum of 3 months after system-wide launch, TTC will provide
supervised access to all maintenance personnel employed by the Private Partner for the purpose
of servicing OSFS equipment installed on TTC property. During this period, TTC will provide
supervision, monitoring, and guidance on proper procedures when working on the OSFS solution
for TTC, and when accessing fare payment equipment installed on legacy TTC fare system
equipment or on TTC vehicles.
Page
96
While on TTC property, the conduct of Private Partner personnel must conform to all applicable
safety laws and regulations. Additionally, as an example, the following TTC guidelines, which
are subject to confirmation and change by TTC during Design Review, are for on-site work for
personal safety and regard for customers using TTC’s transportation services apply to all
contractors performing work on TTC property. Personal Protective Equipment (PPE) must be
worn, including: safety shoes bearing the green emblem of certification under CAN/CSA Z195;
hard hats; reflective vest; and safety glasses.
Prior to starting work on a TTC site, TTC staff will meet with each contractor to communicate
important safety expectations, such as:
• When working in a public area, the work area must be delineated for visibility with safety
cones and safety tape;
• In addition, all contractors working on TTC property must have a Site Permit issued by
TTC. TTC issues site permits, which are location and individual specific;
• All contractors and sub-trades assigned to a work site must have Workplace Safety and
Insurance Board (WSIB) coverage in the Province of Ontario. Documentation of such
coverage must be on file with TTC;
• A supervisor must always be on site to supervise work;
• All work must be performed during off-peak TTC hours.
Additional applicable TTC rules and regulations will be defined during Design Review.
After the initial three month period, the Private Partner will be required to be familiar with and
comply with all TTC procedures for access to TTC facilities by private contractors. Periodic
reviews of the performance of the Private Partner will continue under the required Project
Management Plan described in Section 13.
In order to support its field maintenance operations, as well as coordinate its maintenance
activities with TTC, the Private Partner will establish, furnish, and support the operation of a
Maintenance/Monitoring Project Desk. The Private Partner, in coordination with TTC and as part
of Design Review, will develop, test, and publish a Maintenance Manual. The Maintenance
Manual will document all procedures, protocols, equipment, tools, and part necessary for
maintaining the OSFS in a state of good repair and for achieving TTC’s required performance
standards.
The Maintenance Project Desk will serve to assure implementation, management and
coordination of all maintenance support activities for the OSFS according to agreed-upon
procedures, including but not limited to:
Page
97
• Oversight of all corrective and preventive maintenance activities;
• Coordination with TTC for supervised access to TTC facilities;
• Operational and business oversight of the Maintenance Management System;
• Acceptance and disposition of trouble calls either generated by the Maintenance

Management System, originating with field maintenance personnel, or reported by
customers via the Web Site or Customer Call Centre, and/or through other channels, as
deemed necessary.
Field Maintenance personnel will be under the control of the Project Desk. The Private Partner
will take necessary steps to assure that field personnel can communicate in real-time directly
with the Maintenance Project Desk. The Project Desk will maintain the capability to dispatch
field maintenance personnel in response to system events as described in the approved
Maintenance Manual.
The Maintenance Project Desk will have direct access to information about the status of the
OSFS, including access to information from the Central Processor, the Web Site, and the
Customer Call Centre. The Maintenance Project Desk will be capable of receiving information
from the TTC about its services and business operations directly, in a manner deemed
appropriate by TTC.
The Private Partner will staff the Project Desk on a 24 by 7 basis for the first six months of
operations after system-wide launch of the OSFS. The Project Desk will be equipped with a toll-
free telephone number, email, and SMS text messaging access. After the initial six month period,
subject to TTC’s review and approval, an alternative staffing schedule may be proposed to better
reflect actual performance of the OSFS, the Maintenance Management System, and the field
maintenance staff.
5.2 Customer Support

TTC requires that the Private Partner utilize business and technical capabilities in the account-
based design of the OSFS to facilitate management of customers’ transit accounts. The Private
Partner must enable the OSFS, dependent functions, and related service providers to address
transit account issues through customer, self-directed means, and through means aided by staffed
customer representatives.
Transit account management issues to be addressed include, but are not limited to:
• Refund processing, both for claims adjustments and for other actions as deemed
necessary either by the Private Partner or TTC as merchant;
Page
98
• Transfers of balances, whether in terms of dollars or time, between transit accounts, to
new transit accounts, and between processing categories (i.e., Single-Trip and Pre-
Funded);
• Usage of contactless media and devices, including the capability to analyze and
remediate issues regarding usages or “taps;”
• Processing of reports of lost or stolen contactless GPR devices that were issued through
the OSFS;
• Acceptance of customer preferred alternative payment methodologies, provided that these

methodologies and systems are fully compatible with open standards of the financial
services and payments industries and ultimately rely on EFT for deposit of funds to
TTC’s bank accounts.
The Private Partner must incorporate all means of transit account management pertinent to a
retail merchant approach to fare payment. TTC requires that the Private Partner as a minimum
incorporate the customer support functionalities, features, performance, and degree of customer
support provided by retail merchants, while incorporating additional functionalities as described
in this RFPQ and as they are further described or refined during Design Review.
The OSFS must record and report on all transit account activity, whether initiated as a result of a
customer inquiry or interaction, or otherwise executed by the Private Partner. This requirement
includes the capability to access information on the status of the account and all activities
pending on the account, whether initiated by the customer or the Private Partner.
During Design Review, the Private Partner will present detailed descriptions of technical
solutions, business processes, and customer support procedures for the purpose of transit account
management.
The Private Partner must automate transit account management to the fullest extent possible.
TTC’s performance requirements are explicitly set to correspond to levels achievable through
comprehensive automation and administrative streamlining. Manual tasks will impact TTC
operations and cost in its role providing oversight, monitoring, and control of OSFS
performance.
TTC requires that all transit account management activities are reported and reconciled with
related payment and usage activities of the Central Processor. All reporting and reconciliation
activities will be enabled by the Central Processor and the Data Mart function of the OSFS.
5.2.1 Applicable TTC Customer Service Policies

In designing and implementing the OSFS, the Private Partner must configure the OSFS to
support business and customer service activities required by TTC’s Customer Service Policies. A
full description of these policies will be provided during Design Review.
Page
99
In addition, to facilitate implementation of an open standard, merchant approach to fare payment,
TTC has established the following guidelines governing payment of fares by customers:
• Except where permitted according to TTC policies to pay fares by directly depositing
cash into a fare box, in order to pay fares, all customers, whether regular full-fare
customers or customers entitled to a concession or reduced fare, are required to use
contactless media or devices accepted for payment of TTC fares.
• Adult customers may allow another person to pay their fare in accordance with TTC’s
fare policies and procedures. Customers choosing to do so will need to be informed of
any other applicable rules and regulations regarding the use of payment cards issued to
them.
• Customers entitled to concession or reduced fares must first execute procedures needed to
comply with TTC’s rules and regulations for eligibility for concession or reduced fares.
TTC will administer the eligibility process and provide the Private Partner with
authorization to charge eligible customers at the appropriate reduced fare. The Private
Partner will configure the OSFS to accept authorization for eligibility for reduced fares
from TTC on an account basis.
Customers pre-qualified by TTC for payment of reduced fares will have the following
options:
Registration as the credential and payment instrument for reduced fares of a single, open-
loop, co-branded contactless card or device issued in the eligible person’s name by their
financial institution or other certified issuer of payment instruments. The Private Partner
will configure the OSFS to permit TTC to generate a unique confirmation number to be
used by the customer to verify eligibility when registering.
• The Private Partner will enable the OSFS to permit certain customers eligible for
concession fares to register, with use of their unique confirmation number, their
contactless media in one of the following ways:
1. In person at a customer service location designated by TTC;
2. By using the Web Site; or
3. Through the Customer Service Call Centre.
• In order to address the distribution of fare media and the payment of fares by children
of school age and other students enrolled at an academic institution, TTC will address
potential options during Design Review. The Private Partner is encouraged to present
options for distribution and fare payment for these customers that are consistent with
Page
100
an open standards approach to fare payment and the desired functionality of the
OSFS.
• For TTC employees, outside contractors, and other authorized individuals as

determined by TTC, the Private Partner will furnish equipment and configure the
OSFS to permit issuance of closed-loop, open standard contactless devices in a
manner consistent with the overall requirements of the OSFS and through the use of
COTS equipment and services. The Private Partner will configure the system to allow
TTC to control the following: issuance of devices, the permitted usage of devices in
terms of access to TTC transportation services, and the potential for permitted usage
of the issued contactless device as a building access pass. TTC does not require the
Private Partner to implement or manage TTC’s facilities access system. Under the
terms of the RFPQ, the Private Partner is required to provide TTC with technical
details about the configuration and operation of the open standard contactless devices
that will enable TTC, or a service provider of TTC’s choosing, to enable use of these
devices as building access passes. The Central Processor furnished by the Private
Partner will be programmed to recognize these devices as access passes having no
payment functionality or capability.
During Design Review, the Private Partner may propose alternative solutions to achieve these
required functionalities. All proposed alternatives are to be presented during Design Review for
consideration and approval by TTC.
5.3 Training for TTC Employees

An approved training plan will be developed and submitted as part of the OSFS solution. This
training plan will include a schedule as well as TTC-approved training materials.
6 Implementation Plan for OSFS
6.1 Overview
TTC requires that the Private Partner submit a plan for the complete deployment and
implementation of the OSFS in no more than 24 months after official launch of the project,
according to the defined guidelines in the Project Plan described below in Section 13. The
timeframe is subject to the TTC’s ability to provide power, and engineering and design efforts
necessary to support the OSFS. TTC’s acceptance of the proposed plan is subject to TTC’s
review and approval at Design Review. Earlier deployment and implementation is encouraged,
provided that the Private Partner adheres to all requirements in this RFPQ and in no way
compromises the quality, functionality, and effectiveness of any deliverable.
As a guideline for the Private Partner in responding to the RFPQ process, TTC has devised the
following Deployment Plan with the intent of expediting implementation, while assuring the
Page
101
least possible impact on TTC customers and employees as they continue to use and support
TTC’s Current System prior to launch of the OSFS.
Except for the delivery date of the completed system, all aspects of the Deployment Plan
included in this RFPQ are subject to revision as a result of new information presented to TTC
during the course of the RFPQ process or as a result of Design Review.
Included in the Deployment Plan are key business milestones for the Private Partner. TTC
regards the Private Partner’s business milestones as critical path issues equal in importance to
other deliverables of equipment and services necessary for the timely launch and subsequent
operation of the OSFS.
6.2 Summary Deployment Plan

In presenting this Summary Deployment Plan, TTC recognizes the requirement in this RFPQ for
the Private Partner to concurrently:
• Provide all equipment and systems necessary for an OSFS, both at TTC’s facilities and
those of other merchants;
• Introduce and support broad-based issuance, consumer adoption, and widespread
merchant acceptance of contactless media and devices;
• Establish an extensive, Non-TTC Retail Sales and Reload Network for contactless GPR
media and devices.
TTC has provided more detailed information about Legacy LRV proof-of-payment fare
collection requirements in the Appendices to this RFPQ. These requirements will be an
important component of the Private Partner’s proposed deployment plan for the OSFS.
TTC recognizes that the key element of the OSFS is the capability to process payment of TTC
fare products in the manner required in Section 3, Business and Functional Requirements. The
Summary Deployment Plan is structured to support implementation of this key functionality as
the cornerstone of TTC’s transition to a merchant approach to fare payment. During Design
Review, TTC and the Private Partner will review and, upon approval from TTC, finalize the
Deployment Plan. During Design Review, TTC will consider options proposed by the Private
Partner that could optimize the business, technical, operating, and customer service requirements
and outcomes specified by TTC in this RFPQ.
Equally important, TTC requires that the Private Partner establish widespread market
penetration, familiarity, and use of open standard contactless media and devices in the TTC
service area. The Summary Deployment Plan is structured to support implementation of this key
requirement as an essential feature of TTC’s transition to a merchant approach to fare payment.
Page
102
Prior to official launch of the OSFS, TTC will continue to operate and maintain its Current
System. TTC customers will only have the option of using Current System media for payment of
fares prior to official launch. After official launch for the period of transition prior to
decommissioning TTC’s Current System, TTC customers will have the option to continue to use
the Current System. TTC, at its sole discretion and based on the performance of the Private
Partner in achieving required business and performance goals described in this RFPQ, will
determine the duration of the transition period and the exact timing of decommissioning.
6.2.1 Phase I Deliverables

For Phase I, the following OSFS elements will be designed, installed, tested, and deemed fully
operational by TTC.
6.2.1.1 Central Processor and Data Mart

At the conclusion of Phase I, the Central Processor and Data Mart for the OSFS will operate in a
live environment. All business and functional requirements necessary to support normal business
operations of the Central Processor and dependent systems and functionalities as described in
this RFPQ will have been implemented and tested, and after completion of testing to TTC’s
satisfaction, accepted by TTC.
6.2.1.2 Test Lab

The Private Partner will have equipped and implemented the Test Lab with hardware, software,
telecommunications, and all other equipment and functionalities identical to that required for
revenue service at TTC and at Non-TTC Retail Sales and Reload Locations. All types of
equipment and related assemblies of the OSFS will be provided in a fully functional mock-up
that is capable of “live” transaction processing. The Test Lab will be fully functional and be
capable of simulating and testing all possible business, customer service, and operating scenarios
required of the OSFS for TTC’s acceptance of fare payment.
6.2.1.3 Subway System Wireless Infrastructure

The Private Partner will equip all Subway stations with infrastructure to support wireless
telecommunications for the OSFS. All design elements, hardware, and software for the wireless
infrastructure that the Private Partner will provide must support a high-availability network
approach and equipment configuration, as well as enable operational processes to support TTC’s
business, operating, and technical requirements. By high availability, TTC means uptime of at
least 99.99% at full capacity (i.e., with no reduced bandwidth capacity).
Testing of the wireless equipment will be conducted using both using fully qualified network
analyzers at each wireless connection point /reader assembly as well as the testing of the wireless
equipment using actual Reader Assembly equipment will have been completed to assure that all
performance standards are met. Additionally, if wireless service in the subway station is
extended to customer use, testing will be conducted under full load (i.e., full capacity
conditions).
Page
103
All required security standards will be met by the wireless network provided by the Private
Partner for the OSFS solution.
The wireless network required for operating the OSFS system at subway stations must not
interfere with any existing TTC wireless networks. In particular, the TTC radio network (at
approximately 800MHz) must not be impacted in any way by any cellular data network installed
in subway stations.
6.2.2 Phase II Deliverables

For Phase II, the following OSFS elements will be designed, installed, tested, and deemed fully
operational by TTC.
6.2.2.1 Wireless Telecommunications Services Established for TTC’s Surface Fleet and for
Subway Stations
TTC requires that the OSFS communicate with the Central Processor using commercially
available wireless telecommunications. The Private Partner will provide detailed technical and
operating requirements for the type of commercially available service that is capable of
supporting the operation of the OSFS to meet TTC’s performance requirements.
The Private Partner must itself directly procure and enter into a contractual relationship with a
commercially available wireless telecommunications service provider that is capable of meeting
the technical and operating specifications required by the Private Partner.
At a minimum, TTC requires that the telecommunications capabilities of the OSFS support at 3G
EV-DO Rev A (TIA-856) wireless communications technology. In designing the OSFS, the
Private Partner will, at a minimum, provide details of:
• CDMA and or GSM standards;
• Data services required;
• Technical approach to IP addressing;
• Technical approach for Static Routing, or other alternative that is proposed by the Private
Partner;
• Required redundancies;
• Service plan levels in terms of data requirements, bandwidth, and access protocols;
• Required Service Level Agreement (SLA);
• Required availability in the TTC service area at a level compatible with risk management
capabilities inherent in the proposed OSFS solution.
Page
104
The Private Partner’s response to this RFPQ will provide details of how the proposed wireless
technical solution will comply with PCI-DSS and mitigate transactional and system risk,
including but not limited to the following types and categories of security risk:
• Authentication;
• Eavesdropping or “sniffing” attacks;
• Network mapping;
• Lost or stolen active modems;
• Wireless probing;
• Piggybacking;
• War driving;
• Man-in-the-middle attacks;
• Address Resolution Protocol attacks.
The Private Partner must comply with all financial security standards for the transmission of
financial data over cellular networks.
TTC recognizes that 4G and Long Term Evolution (LTE) wireless communications technology
may become available during the expected implementation timeline for the OSFS. As part of its
response to this RFPQ, TTC requires the Private Partner to submit a statement on the
applicability of forthcoming 4G and LTE technologies in supporting the OSFS. This statement
must describe how the Private Partner’s OSFS solution, specifically choices of hardware,
software, operating systems, assembly configurations, and other design and technical elements
will be adaptable to currently available wireless technology, as well as steps needed to transition
to 4G and LTE technologies.
In responding to this RFPQ, the Private Partner should propose, along with supporting analysis
and commentary, the optimal telecommunications solutions to support the OSFS during the
required term of the operating agreement between TTC and the Private Partner. The Private
Partner must demonstrate an understanding of wireless cellular surface availability of 3G
networks and also demonstrate the effectiveness of the proposed technical solutions across all
surface transportation modes that will rely on the OSFS for fare payment. The proposed solution
must also support a modular component approach that assures easy, “plug-and-play” upgrades of
wireless system components to occur.
Page
105
To the greatest extent possible, TTC wishes to “future-proof” the Open Standards Payment
System solution against pending, near-term advances in wireless telecommunications services as
well as in electronic payments technology. In its choice of wireless telecommunications for the
OSFS, TTC requires incorporation of the most advanced, proven, effective, and reliable wireless
telecommunications technology, as well as the technology that assures that fastest possible
transaction speeds with the least dropped calls.
During Design Review, the Private Partner will provide comprehensive requirements for wireless
telecommunications service necessary to support the OSFS. These requirements will be
accompanied by an evaluation of wireless telecommunications alternatives, and will demonstrate
how the recommended technology will work in compliance with TTC’s performance standards.
After TTC’s acceptance of the Private Partner’s final recommendation for wireless
telecommunications service, TTC requires that the Private Partner perform drive tests and use
network analyzers to evaluate connectivity under different weather and other conditions at TTC
bus stops, streetcar stops, and Subway locations to determine the availability and quality of
wireless service. Subject to TTC’s review and approval, the Private Partner may submit
commercially available evaluations of wireless performance as a benchmark for guiding the
Design Review process. TTC, at its discretion, may permit the use of data about the performance
of wireless-enabled TTC systems as a benchmarking tool.
Wireless services will be designed and available for use in coordination with the installation and
operation of the required Test Lab. Testing will have been completed to confirm required SLAs,
as well as to identify locations in the TTC service area where remedial steps, if any, are required
to assure compliance with required wireless service levels.
6.2.2.2 Surface Fleet On-Board Reader Assemblies

TTC’s surface fleets will be equipped with Reader Assemblies. All Reader Assemblies will have
been tested by the Private Partner and accepted by TTC as ready for revenue operation. The
Private Partner will execute Friendly User Tests with customers possessing contactless media
and devices pre-issued by financial institutions and contactless GPR media intended for retail
sale and reload.
6.2.2.3 Subway Fare Gate Reader Assemblies

TTC’s Subway stations will be equipped with Reader Assemblies. All Reader Assemblies will
have been tested by the Private Partner and accepted by TTC as ready for revenue operation. The
Private Partner will execute friendly user tests (FUT) with customers possessing contactless
media and devices pre-issued by financial institutions and contactless GPR media intended for
retail sale and reload.
Page
106
6.2.2.4 Web Site
The Private Partner will complete design, development, and implementation of the Web Site.
This will include all content, graphics, functionalities and links so that the Web Site will be
accepted by TTC and ready for revenue operation. The Web Site will undergo and successfully
complete all testing, including ethical hack testing. The Web Site will be certified as PCI_DSS
compliant. The Web Site will be constructed in a manner that permits limited access in a staged
area for Friendly User Testing.
6.2.2.5 Customer Call Centre

The Private Partner will complete design, development and implementation of equipment, site
facilities, telecommunications, software, and access to the Central Processor to permit live
operation of the Customer Call Centre. Actual hours of operation of the Customer Call Centre
must at least equal, if not exceed TTC’s current hours of operation for its customer service and
support operations. A final determination of hours of operation and staffing for the initial launch
of the OSFS will be made during Design Review.
During the course of the term of its agreement with TTC, the Private Partner must right-size the
capabilities of the Customer Call Centre, and its supporting staff and infrastructure, to meet the
performance requirements in this RFPQ.
Staff for the Customer Call Centre will have completed all training necessary to support revenue
operations. Training of Customer Call Centre staff will be completed prior to a period of
independent testing of staff and the IVR system. As part of independent testing, the Web Site
will undergo and successfully complete all security and integrity testing, including ethical hack
testing, and will be independently certified as PCI_DSS compliant.
6.2.2.6 Non-TTC Retail Sales and Reload Network

The Private Partner will have completed all business agreements and operating, technical, and
business support necessary for the Non-TTC Retail Sales and Reload Network targeted to
support TTC bus and streetcar stops and subway stations. All agreements between the Private
Partner and service providers in the Non-TTC Retail Sales and Reload Network will be must
comply with the letter and intent of the Private Partner’s agreement with TTC, in regard to the
business, operational, and technical goals and performance standards for the OSFS.
6.2.2.7 Market Penetration of Partner-Issued, Co-Branded Contactless Media and Devices

Contractual goals for conversion of partner payment card portfolios to contactless media and
devices will be met.
6.2.2.8 Marketing and Information Campaign

All marketing and information materials, campaign strategies, and media buys will be complete
and ready to support full launch of the OSFS.
Page
107
6.2.2.9 Training and Operations Support
All Training of TTC and Operations Support staff required for the OSFS will be completed no
later than three months prior to the official launch date. All support systems and operations,
including protocols and procedures for Disaster Recovery, Risk Management, and Field
Maintenance will be fully operational and functioning as though in revenue operations. TTC
requires that the Private Partner execute and successfully complete to TTC’s satisfaction a
Disaster Recovery Drill. All Risk Management and Field Maintenance Support must meet
contractual performance standards prior to official launch of the OSFS.
6.2.2.10 PCI Compliance

The Private Partner will present results of audits and penetration testing by the QSA for TTC’s
review and approval. All procedures, protocols, technical solutions, and remedial steps as a result
of QSA audits must be reviewed and a plan for achieving full certification presented prior to
Phase III.
System solution against pending or anticipated near-term updates to PCI-DSS guidelines. As part
of Design Review, TTC requires the Private Partner to present its analysis and assessment of
PCI-DSS, PCI-PED, PCI-PA compliance issues, including but not limited to recent non-
mandatory modules such as Open Protocols, Secure Reading and Exchange of Data (SRED), and
Integration described in Version 3.0 of the Payment Transaction Security (PTS) Requirements of
the PCI Security Standards Council.
The Private Partner will assess any and all PCI impacts on TTC operations and provide direction
on the implementation of remedies.
6.2.2.11 EMV Compliance

System solution against pending or anticipated near-term updates to EMV and related banking
standards. As part of Design Review, TTC requires the Private Partner to present its analysis and
assessment of EMV, EMV rollout, EMV compliance issues, including but not limited to
customer spend controls, off-line transactions, and changing security suites.
All open payments devices must be EMV compliant. FMVDs must support both contact and
contactless EMV, while all Reader Assemblies installed to accept fare payment in subways and
on TTC surface vehicles, as well as on other vehicles that provide transportation services in
conjunction with or under the auspices of TTC, must support contactless EMV.
6.2.2.12 Phase III Deliverables

For Phase III, the following OSFS elements will be designed, installed, tested, and deemed fully
operational by TTC.
Page
108
6.2.2.13 Subway/Subway Fare Media Vending Devices
TTC’s Subway and Subway stations will be equipped with Fare Media Vending Devices. Prior
to installation, all Fare Media Vending Devices will have been tested and accepted by TTC as
ready for revenue operation. The Private Partner will have executed Friendly User Tests at Fare
Media Vending Devices with customers possessing contactless media and devices pre-issued by
financial institutions and contactless GPR media intended for retail sale and reload.
6.2.2.14 TTC On-Site Customer Service Centre

The TTC Customer Service Centre at 1900 Yonge Street will be fully operational as a part of the
OSFS solution. All TTC staff assigned to 1900 Yonge Street will be trained and prepared for
revenue operation prior to the official launch date.
6.3 OSFS Launch

TTC requires that the Private Partner, in coordination the Private Partner’s affiliates and TTC,
develop and execute a Launch Strategy for the OSFS. The development of a Launch Strategy
will be included in the Design Review Process.
The goal of the Launch Strategy will be to assure that TTC can maximize business and
customers services opportunities in transitioning to a merchant approach to fare payment. The
Private Partner will structure and support the Launch Strategy to assure that TTC’s customers are
aware of opportunities and advantages to approach payment of transit fares in a manner typical
of purchases at retail stores.
TTC requires collaborative review and updating of the Launch Strategy throughout all phases
program implementation to reflect progress towards stated business and operating goals for the
OSFS.
TTC will determine the date of the official launch of the OSFS. Granting of an official launch
date and authorization to launch will be contingent on the Private Partner’s performance with
regard to all business, technical, and operating requirements in this RFPQ.
7 Subway Environment
7.1 General
7.1.1 Functionality of Fare Gates in New OSFS

All TTC Subway stations are equipped with fare gate arrays that are used to control entry to the
transportation system. There are basically three types of fare gates in operation for normal
ingress and egress: low-wheel turnstiles, with bi-directional rotating barrier arms that can be used
for either ingress or egress; “swing” gates designed for AODA-compliant access for persons with
disabilities and special mobility issues, and “high-wheel” turnstiles.
Page
109
During the implementation of and transition to the new OSFS, all Legacy fare gate equipment
will remain in place and fully operational. Excluding new Reader Assemblies attached to Legacy
fare gates, the maintenance of all Legacy fare gates and related equipment will remain the
responsibility of TTC.
For the new OSFS, all fare gates that currently accept payment of fares will be equipped with
new, OSFS hardware to be used in accepting fares from new contactless open standard fare
media and devices. No alterations of the functionality or physical design of the fare gates will be
required or permitted, except as described below in order to enable the installation of new, open
standard contactless reader assemblies.
When the OSFS is fully operational, the payment of fares with new, open standard contactless
devices will have the same effect on the operation of fare gates as payment with TTC’s Legacy
fare media. A description of the required operational and technical solution for use of Legacy
fare gates in the OSFS environment is contained in the Section entitled “Concept of Operations.”
7.1.2 Overview of Current TTC Fare Gates

Included with this RFPQ are dimensional drawings of a typical fare gate deployed in the TTC
system that the Private Partner must equip with new, open standard reader assemblies. Currently,
it is envisioned at the TTC that the open payments Reader Assembly will be contained within the
fare gate housing, with only the customer interfaces exposed to view and use.
A detailed review of each fare gate type that will be equipped with new, OSFS Reader
Assemblies and other necessary hardware will occur during Design Review, including:
• Location and a description of the power supply in the fare gates;

• The recommended exterior location available for mounting of the contactless reader
used in payment of fares; and
• The interior space available for installation of additional components of the reader
assembly.
Prior to submission of a response to this RFPQ, prospective Private Partners will have the
opportunity for closer inspection of various fare gates that will be equipped with OSFS reader
assemblies. A final determination of the placement, as well as other features of the reader
assembly and its functionality for the OSFS will be made during Design Review.
7.1.3 Release of Fare Gate for Entry

New Reader Assemblies will be installed on each fare gate that currently accepts TTC Legacy
fare media. These devices will be designed in a manner to replicate customers’ current
experience upon payment of fare and entry to the TTC system using TTC’s Legacy fare media.
Page
110
All functionality required of the new Reader Assemblies must be accomplished on a stand-alone
basis. For release of the fare gate barrier arm, the Reader Assemblies must interface to the gate
release mechanism via an industry standard port, for example an RS232 or USB port. No
modification to open standard contactless readers, or other open standard hardware that
comprises the Reader Assembly is permitted.
Additionally, a release of the fare gate by the Reader Assemblies for the OSFS must be
accomplished without interference with the normal operation of TTC’s current fare collection
system. However, TTC owns the fare gate and the electro-mechanical mechanism for releasing
the gate. During Design Review, TTC will work with the Private Partner regarding any
modification of its interface that is necessary to release the existing release mechanism so that it
can be interfaced to the Reader Assembly through use of an industry standard port.
The Reader Assembly will enable the fare gate to operate in the following modes:
• Open:-- allow appropriate number of entries based on fares paid;
• Closed: -- disallow entry (fare gate out of service), and;
• Emergency Operation: -- permit exit only and deny all entry; permit “free-wheeling” or
unlimited unpaid entry as well as exiting capability. Only TTC will have the authority to
implement the Emergency Setting for fare gates.
The OSFS must be capable of setting OSFS Reader Assemblies to the Open or Closed condition
independently of other fare gates in the array and independently of the operation of TTC’s
Legacy fare payment system.
In the event of an OSFS equipment failure or other condition that prevents payment of fares via
the OSFS during the transition period when both TTC’s Legacy fare payment system is still in
operation, implementation of the Closed setting of the OSFS will not interfere with or interrupt
the normal operation of TTC’s Legacy fare payment system. The Contactless Reader that is part
of the Reader Assembly mounted on the exterior of the fare gate will display a unique visual
message, distinct from those used for authorization approvals and denials, to indicate that the
fare gate is closed for acceptance of OSFS media only.
During Design Review, the Private Partner will provide details regarding the operation of the
Device Management System, along with use cases that illustrate all aspects of device capabilities
for review and approval by TTC.
Setting of operating modes for the fare gates will be controllable both remotely and locally.
Remote setting of operating modes will occur via a system wide broadcasting capability. The
Private Partner will manage the status of fare gates for Open and Closed operation. Provided that
Reader Assembly hardware and software are operational and functioning according to
specifications, the fare gate will automatically default to the Open condition.
Page
111
TTC anticipates a transition period during which both TTC’s Legacy fare collection system and
the OSFS will operate side-by-side. The OSFS capability for Emergency mode settings will be
reviewed during Design Review.
For equipment failures only, excluding interruptions or failures of telecommunications

connectivity for the fare gate, implementation of the closed setting will occur automatically.
Manual setting of a fare gate in the closed condition must be capable either remotely via the
Central Processor or locally. Local setting in a closed mode will be possible by accessing the
fare gate cabinet and performing a simple interaction with the Reader Assembly inside the fare
gate cabinet. Manual settings could be performed by personnel with authorized access to TTC
equipment.
The Reader Assembly will record all status conditions of the fare gate in connection with the
operations of the OSFS and forward status data to the Central Processor for reporting purposes,
as described in the device management and monitoring section of this document.
The Reader assembly at fare gates must include additional functionality to support TTC fare
products that could allow multiple entries from a single customer account.
For reporting and audit purposes, Reader Assemblies must be capable of providing a record of
releases of the gate mechanism. The record will associate the gate mechanism release with the
customer account used to pay fare. This association of the gate mechanism release with the
customer’s account will be accomplished in the context of tokenization of the account
information that the OSFS will perform.
The record of gate releases will consist of at least the following:

• The account used for payment;
• A date and time stamp;
• A unique identifier for the Reader Assembly and fare gate.
For reporting and auditing purposes, the Reader Assembly will have the capability to capture
data regarding authorized servicing of the card reader assembly for maintenance activities and
other authorized purposes, the Reader Assembly must be capable of forwarding this data to the
Central Processor on a daily basis.
A record of all transaction activity (e.g. authorized, as well as unauthorized activity) to the fare
gate cabinet will consist of the following:
• A secure access code of the authorized individual accessing the fare gate;
• A date and time stamp, and;
Page
112
• A unique identifier for the Reader Assembly and fare gate.
When the OSFS is fully operational, and at such time that TTC’s Current System has been
decommissioned, the Reader Assembly will be configured to require interaction from authorized
personnel to record their access to the fare gate.
All transmission and exchanges of data originating with the Fare Gate used in payment
processing and reporting will comply with all applicable security standards of card associations,
issuers, and regulatory entities with oversight of the financial service and payments industries.
7.1.4 Fare Gate Messaging and Displays to Customers

The Contactless Reader mounted on the exterior of the fare gate will have visual and audible
indicators that provide distinctive messages for approval or denial of an Authorization and
comply with relevant standards such as AODA. Details of light colours, patterns, audio etc. will
be addressed Design Review.
In addition, the Private Partner may be required to provide the necessary interfacing to the
appropriate Legacy visual indicators already mounted on the fare gates that correspond to
approval or denial of entry via the TTC’s electromechanical turnstile interface board.
The Private Partner has the option of proposing a supplementary alphanumeric and audio display
that could convey additional details about the contactless transaction including but not limited to,
the reason for authorization denials in accordance with financial standards. Any such proposal
must comply with AODA requirements, as well as messaging requirements of the financial
services and payments industry.
Provisioning of this feature must be accomplished to assure compliance with TTC’s performance
requirements for transaction processing, authorization response times, and reporting.
TTC requires that the proposed solution use commercially available, non-proprietary design and
equipment. All physical and technical aspects of the proposed solution would be required to
conform to maintainability and installation guidelines described below.
7.1.5 Message Sets

In the event that the Private Partner proposes a solution for supplementary alphanumeric and
audio displays for the sake of conveying additional details about the contactless transaction, the
Private Partner must provide details of the proposed message sets. Any proposal by the Private
Partner must comply with open standards of the financial services and payments industry, and
work within the standing rules, regulations and practices of the Canadian banking system.
7.1.6 Permanent Graphics

Permanent graphics related to industry standard branding of payment card and payment device
readers will conform to guidelines of the financial services and payments industries. In addition,
Page
113
permanent graphics to instruct customers on contactless media usage consistent with messages
required and sanctioned by card associations and brands will be mounted either on the exterior or
adjacent to the OSFS Contactless Reader. These will be determined during detailed Design
Review.
7.1.7 Audible Tones

The Reader Assembly must also emit audible tones to indicate the results of transaction
processing and must comply with AODA standards. A minimum of two tones, each with a
distinct pitch, are required to correspond with a transaction approval and a transaction denial.
The decibel level of the tones will be programmable locally, and capable of being heard and
distinguished at a minimum of 25 feet to alert both the customer and nearby TTC personnel of
the results of the transaction. This will vary by station location and, thus, needs to be
programmed according to each location.
7.1.8 Off-Line or Orphan Mode Operation

Each Reader Assembly will be designed to operate in Off-Line or Orphan Mode. This may occur
when communications with the Central Processor is interrupted.
In the event of a power interruption, the Reader Assembly may be provided with an alternative
battery source to permit normal shutdown of the Reader Assembly. Before shutdown, the Reader
Assembly will ensure that all transactions are completed and then it will activate the “Closed”
visual indication, which will remain on until power from the battery source is exhausted.
In the event of a telecommunications service interruption, the Reader Assembly will continue
operations in Stand-In or orphan mode. Under this circumstance, transaction processing will rely
on typical payment industry authentication processes for contactless device and reader
interactions, as well as authorization of contactless media and devices by use of a Local Hotlist.
The Local Hotlist will consist of account numbers parsed in a manner to minimize TTC’s
financial risk under circumstances of a temporary loss of telecommunications services. The
Private Partner will populate the Local Hotlist in light of collaborative analysis between TTC and
the Private Partner based on current on-line hot lists.
Population of the Local Hotlist with updated information will occur at a minimum of once a day.
The Local Hotlist will be capable of holding a minimum of 50 thousand accounts. The Local
Hotlist will have memory capacity dedicated solely to the hot listing function.
During a telecommunications outage, all transactions at the Reader Assembly, including records
of activities at the Fare Gate, will be recorded and stored in secure non-volatile memory within
the secure unattended terminal as per financial payment standards. This Store and Forward
function will operate independently of the Local Hotlist and will not rely on the Local Hotlist
memory. The capacity of the Store and Forward function as well as the duration that the Reader
Assembly is allowed to be in Orphan Mode will be determined during detailed design.
Page
114
7.1.9 Passback Control
The Reader Assembly for the OSFS will include a passback control feature. This feature will
allow TTC to control the use of unlimited ride fare products, such as passes, by limiting the
number of concurrent trips within a specified time. The time period during which a passback is
not permitted will be a table driven parameter setting. The setting will be controlled remotely
from the device management system. Settings can be programmed either to affect all Reader
Assemblies at a given station, or to affect select Reader Assemblies within a station location.
7.2 Fare Media Vending Devices or Kiosks for Open Standards System
7.2.1 Overview
An integral part of TTC’s business plan for the OSFS is the assurance that all TTC customers
have numerous convenient locations to purchase contactless media accepted for paid access to
TTC transportation services. Consistent with this policy, TTC requires that the Private Partner
equip each point of paid entry to the Subway system with Fare Media Vending Devices
(“FMVD”) or Kiosks. TTC will identify all Subway system stations and locations for
deployment during Design Review.
7.2.1.1 FMVD Deployment

All FMVDs deployed in TTC stations and surface vehicle platform areas will conform to a single
design. Additional FMVDs may be required in order for the Private Partner to comply with
TTC’s performance standards for these machines as described below. A final determination of
the number and location of FMVDs will be at TTC’s sole discretion and in part based on based
on customer demand and actual performance of the Private Partner in meeting business and
operational goals required under this RFPQ.
In providing a FMVD solution appropriate for all TTC transportation services, the Private
Partner must consider the differing requirements for Legacy POP where FMVDs are required at
surface stops and onboard vehicles. Further information is provided in the Appendices.
As part of its response to this RFPQ, the Private Partner must provide a plan for the deployment
of FMVDs that meets TTC’s requirements and is consistent with the Private Partner’s overall
business plan for marketing, distribution, and issuance of additional contactless smart cards and
devices that can be used for fare payment at TTC. Success in the Private Partner’s overall
business plan may reduce the need for additional FMVD beyond the minimum two FMVDs per
paid entry location, but will not result in waiver of TTC’s requirement to meet all performance
standards for FMVD equipment. All decisions about the final deployment strategy and the
number and placement of FMVDs in TTC stations will be subject to TTC’s review and approval.
TTC’s decision in the matter of FMVD deployment will be final.
Page
115
7.2.1.2 Design Criteria
TTC requires that the successful design for the FMVD encourage and support reliance on
automated vending machines for sale and reload of transit account. All contactless media and
devices either sold or reloaded at FMVDs will be ISO 14443 compliant, as well as comply with
applicable standards listed in Section 2.3.1 and all applicable Federal, Provincial, and Local
Laws and Regulations for issuance and reload of media and devices used for electronic transfers
of funds.
The FMVD will be designed so that customers can easily understand and use them for all
purchase and customer support functions described below. By ease of understanding and use,
TTC specifically requires that all FMVD customer interfaces and all design elements that are
visible to the customer consistently apply best available, state-of-the-art features for supporting
media sales and reload, multi-language capabilities suited to the location at which the FMVD is
deployed, and for exchanges of information between the FMVD and customers for all purposes
described in this RFPQ. All FMVDs will comply in both design and final installation with all
AODA requirements for persons with disabilities, as well as incorporate features of human factor
engineering.
As part of the design review process, the Private Partner will be required to provide a working
prototype of the proposed FMVD or kiosk. As noted earlier, all FMVDs deployed in TTC
stations will conform to a single physical design. The proposed FMVD design and solution must
be capable of operating in all TTC environments, including the subway and on the street at
surface vehicle stops. Both the physical and functional design of the FMVD is subject to review
and approval by TTC during Design Review, which includes TTC’s Advisory Committee on
Accessible Transit (ACAT).
7.2.1.3 Functional Requirements
7.2.1.3.1 Online Operations

Under normal circumstances, all FMVDs will operate in an on-line connection to the Private
Partner’s Central Processor. Each FMVD will also be designed to be capable continuing limited
operation of select functions in “orphan” or off-line status with the Private Partner’s central
processor. The extent of functionality permitted in orphan mode will be detailed during Design
Review.
7.2.1.3.2 Fare Purchase Options

The FMVD will be designed to sell all regular full fare TTC fare purchase options and reload all
TTC regular and concession fare purchase options. TTC’s current fare purchase options are
listed in the Appendices. Sales and reloads will function in an account-based manner. Under
normal operating conditions, all sales and reload transactions being must occur on-line and in
real-time.
Page
116
Successful completion of a sales or reload transaction requires that the FMVD is on-line with the
Central Processor managed by the Private Partner. In the event of an interruption in
communications, sales and reload transactions will not be processed until communications are
restored. The Private Partner is required to configure FMVD and supporting wireless
telecommunications to meet performance standards described below and to maximize Sales
Availability of all FMVDs.
The FMVD will have the capability to implement new fare purchase options and new pricings
via remote instructions initiated from the central processor. FMVDs will be capable of remote
configuration with new fare purchase options or new fare pricing options on a location by
location basis, on a Subway line by line basis, or on a basis that groups FMVDs at different
locations.
The FMVD will also have the capability to implement changes to payment acceptance options
(i.e., acceptance of cash, credit or debit cards, coin, etc.) for the sales and reload of transit
accounts. FMVDs will be capable of remote configuration of these parameters.
All configurable parameters for FMVDs will include table/rule driven parameters for effective
dates and times.
Such configuration changes will only be possible when the FMVDs are on-line with the central
processor. Such changes will be made under exclusive control of TTC as merchant, and will be
capable of simultaneous execution at sales and reload locations at non-TTC locations in the TTC
merchant network. Only TTC, or its designated authorized representative, will make policy that
determines fare purchase options and fare pricing. Only TTC will have the capability to initiate
a change that affects available fare purchase options or pricing of fares at TTC locations and
throughout the entire merchant network that sells TTC fares.
Possible configurations will be implemented through a series of table-driven parameter settings.

Parameter settings available to TTC include, but are not limited to the following:
• Customer category, as defined by TTC’s fare policy (e.g., regular full fare; reduced fares
for seniors, disabled; employees; contractors; students);
• Peak and Off-peak fares;
• Unrestricted access;
• By service mode (i.e., subway, streetcars, Wheel-Trans, local and express buses) and
individual route or combination of routes, and;
• Times and duration of activation and deactivation in terms of hours, specific dates, and
specific time periods.
Page
117
TTC must be enabled to execute changes to the parameter setting for fare pricings and fare media
purchase options without intervention by the Private Partner.
7.2.1.3.3 Fare Media Issued

All fare purchase options will result in issuance of an open-loop, General Purpose Reloadable
(GPR) contactless and magnetic strip, or dual-interface card. The GPR media issued by the
FMVD must be ISO 14443 compliant and compliant with all applicable standards described in
Section 2.3.1, applicable laws of the Province of Ontario, and all banking rules and regulations
for issuance and reload of media and devices used for electronic transfers of funds.
If the purchase transaction is completed successfully, the GPR card issued by the FMVD will be
immediately available to pay TTC fares and gain access to transportation via any POE to the
TTC system.
7.2.1.3.4 Customer Payment Options

New FMVDs will be capable of accepting Canadian currency in bill denominations of $5, $10,
$20, $50, and $100, Canadian coin denominations in $0.25, $1.00, and $2.00, and credit and
debit cards for sale and reload of transit accounts. Due to fraud, certain bills may not be
accepted.
No change will be returned to customers paying with Canadian currency.
FMVD will not escrow currency. In the event that the amount of currency deposited in the
FMVD is less than the desired purchase, the currency will nonetheless remain in the FMVD and
be applied to an account associated with an open-loop GPR card dispensed from the FMVD. The
transaction will complete itself and dispense a GPR card to the customer. The GPR card will be
fully functional and, to the extent that sufficient funds are available in the account, the customer
will be able to use the GPR card for transit fare payment or other retail purchases. Unless the
customer makes a Pre-Funded purchase, the dollar value loaded to the customer’s account will
be equal to the total value of the currency accepted by the FMVD. The customer will have the
opportunity to reload that transit account either using currency or credit/debits by initiating
another transaction.
FMVDs will also accept payments made with both contactless, contact, and magnetic stripe
credit and debit cards issued by financial institutions, as well as other open-loop GPR that are
magnetic stripe-only cards. GPR transit accounts will be reloadable at the FMVD, or accepted
directly at the reader on TTC turnstiles provided they are successfully authorized for payment.
FMVDs will only accept a single form of payment to complete a transaction. Split tickets (i.e.
use of more than one fare media product and transit account for the payment of a single
transaction) will not be supported by the FMVD or the Central Processor.
Page
118
7.2.1.4 Risk Management
7.2.1.4.1 General Requirements

In processing payments made with credit cards, FMVDs will be capable of supporting all risk
management processes available to merchants that accept credit cards for payment, including but
not limited to Address Verification Services (AVS, or entry of postal codes as part of the
payment authorization process). The central processor and all FMVDs will be configured to
support global Address Verification Services should they be supported by the issuing financial
institution. The central processor and all FMVDs will also support AVS for other direct payment
cards or devices, provided that the cards or devices are contactless enabled and that the card or
device issuer’s central processor is capable of supporting AVS.
All hardware components and software used to control FMVD functionality will be PCI-DSS,
PCI-PED, and INTERAC compliant. In particular, the device must be PCI POS B compliant,
enabling more cost-effective upgrades.
7.2.1.5 PIN Pads

To enable acceptance of PIN-based debit or ATM cards, the FMVD will be equipped with PCI-
PED and INTERAC. The FMVD itself, along with all operating systems and
telecommunications support for the FMVD, will be PCI-DSS compliant.
7.2.1.6 Customer Support
7.2.1.6.1 General Requirements

The FMVD will provide customer support in the form of a secure on-line, internet access to
account information and activity. Access to account information will require customers to either
present the contactless fare media or device to the reader located on the FMVD, or manually
enter the account number on the key pad on the FMVD. Additionally, access to the account will
require the customer to enter a Personal Identification Number (PIN).
In order to acquire a PIN number, the customer will need to choose the option to establish a PIN
either at the time of initial purchase of the fare media, in the course of reloading the account for
an already issued fare media with additional value, or in order to make another fare media
purchase with remaining value.
7.2.1.7 Receipt Printer

The FMVD will be equipped with a thermal receipt printer. At the successful conclusion of each
purchase transaction, or at the conclusion of a customer inquiry, should the customer request it,
the FMVD will print a receipt. Receipts for payment transactions will provide the following
transaction details, in accordance with all receipt issuance requirements mandated by the
Canadian banking system:
• Type of Transaction;
Page
119
• Fare Option Purchased;
• Date, Time and Location of Transaction;
• Payment Method;
• Amount of Payment;
• Authorization Code (for Credit Card payments only), and
• Payment Card Account Number in the appropriate format.
The FMVD will allow a customer to choose whether or not they wish to have a receipt of their
transaction printed.
7.2.1.8 Customer Messaging and Displays

All information related to payment transactions, customer inquiries, and other functionalities of
the FMVD will be displayed on a colour, liquid crystal display (LCD). The size of the screen
will be determined at Design Review. The proposed screen physical features must be suited to
the TTC operating environment and appear and perform in a manner enables easy use by
customers. The LCD will be equipped with anti-glare features and finishes, with programmable
graphics and a minimum resolution of 1200x800dpi. Brightness and contrast ratios will permit
customers to read messages and information directly from the screen under normal lighting
conditions in TTC stations, as well as conditions where there is minimal or no additional light
source.
Messaging and displays will comply with AODA requirements as well as provide capabilities to
display messages and instructions, whether in visual or audible format, in multiple languages.
The number of languages that can be displayed or used at any one time, as well as the library of
language choices, will be determined during Design Review.
TTC wishes to note that in-station operating conditions typically require that additional measures
be taken to assure the viability of equipment and compliance with required performance
standards. TTC requires that LCD equipment be vandal-resistant and comply with UL
certification testing for direct impact. Through utilization of protective overlays, or similar
methodologies, the Private Partner will assure that light transmission is 90% or better.
The FMVD LCD will be equipped with a screen saver. The screen saver function will be
parameter and table driven, so that the content, timing of screen changes, activation or
deactivation of the screen saver can be accomplished remotely. Screen saver content for FMVD
deployed in TTC stations, on other TTC property, or intended to include information about TTC,
its transportation service, or related messages is subject to prior approval by TTC. Screensaver
functionality must include the capability to message in multiple languages as required by TTC.
Page
120
7.2.1.9 Customer Transactions
7.2.1.9.1 General Functionality

Customer transactions will be accomplished through a series of menu options. Menu options
will be displayed on the LCD and chosen by customer interaction with a touch-screen and/or a
series of programmable soft-buttons. Customers will be able to use either means of interacting
with the FMVD and work through sequential menu options that allow completion of the desired
transaction. Menu options will be designed to accommodate all fare media sale, reload, and
information request options stated in the RFPQ. Design of menus and sequencing of steps will be
consistent across similar functions and will be intended to ease understanding of the transaction
process and expedite steps required to complete transactions. Menus and sequencing of steps will
also be compliant with acquirer specifications for various transaction types permitted under
applicable rules and procedures of the financial services and payments industry.
7.2.1.9.2 Transaction Cancellation

All menus will afford the opportunity for customers to cancel a transaction by touching a defined
area of the LCD. A separate, clearly marked button dedicated to the cancellation function must
be provided.
Under certain conditions, transactions are subject to cancellation prior to their completion, either
automatically by the FMVD or Central Processor, or manually by the customer.
Manual cancellation by the customer can only occur prior to insertion of any currency for
payment or the presentment of credit or debit cards or other acceptable devices for payment.
Cancellation of transactions will occur in a manner that complies with Canadian banking rules
and accepted practices of the financial services and payments industries. The cancellation
process must be familiar to customers as one they experience in a retail environment, at ATMs,
and other means of retail purchases.
Several accepted ways a transaction is automatically cancelled are:

• A pre-programmed time-out has been reached prior to the insertion of any currency or
presentment of a credit or debit card for payment. The programming of the time-out
setting will be table driven.
• A communication failure that interrupts full authorization of a credit or debit transaction;
• The appearance of conditions described in BASE24 protocols during the course of a
credit or debit transaction;
• Failure of the fare media dispensing mechanism, and;
• Other failures in the FMVD or Central Processor that impede the completion of the
transaction.
Page
121
In the event of a transaction cancellation, the FMVD will display messages and perform
functions in accordance with Canadian banking and processor rules.
Customers may not cancel a transaction that has been completed. A completed transaction is one
for which a credit or debit authorization from the clearinghouse has been received or one for
which currency has been inserted into and accepted by the FMVD.
All selections made either via the LCD touch screen or programmable soft buttons will be
accompanied by clear, distinct audible tones. Tones emitted by the FMVD can be adjusted to
volumes that will permit them to be heard in TTC stations.
7.2.1.9.3 Accommodations for Persons with Disabilities

All aspects of the FMVD design will comply with AODA standards.
7.2.1.9.4 Transaction Speeds

The Private Partner will design and implement FMVDs so that transaction times experienced by
customers are comparable to those experienced by customers at ATMs and other comparable
automated devices developed for the financial services and payments industries.
7.2.1.9.5 Time-Out Settings

The FMVD will be equipped with Time-Out settings. Settings will govern steps in the
transaction process that are initiated by the customer and steps in the transaction process that are
dependent on other systems. All time-out settings will be controlled through a series of table
driven parameters. Settings will be determined in consultation with TTC; TTC will have final
approval over time-out settings for FMVD installed in TTC stations and other locations, if any,
owned or operated by TTC.
7.2.1.9.6 Instructional Graphics

The front of the FMVD will be equipped with space for a static information display for TTC use
only. The size and placement of the display space will permit posting of instructions on how to
operate the FMVD, information on how to contact customer service in the event of a FMVD
malfunction, and fare purchase options. The Private Partner may use as an acceptable guideline
the approach used for ATMs and other automated devices designed for the financial services and
payments industries.
7.2.1.9.7 FMVD Status Indicator

For contactless transactions at the FMVD, the FMVD will be equipped with a status indicator
display screen that is distinct from the LCD used for transactions. The purpose of this distinct
display is to convey messages on the status of the FMVD so that customers can know the
FMVD’s readiness to perform transactions in advance.
Page
122
Messages displayed on the Status Indicator will identify all modes of degraded operation as well
as the comprehensive “Out of Service” message indicating that no use of the FMVD is possible.
The Private Partner must conform to standard rules regarding messaging for the financial
services and payments industries.
7.2.1.10 Other Functionalities
7.2.1.10.1 General Principles

In addition to the baseline fare media sales, reload, and customer support functionalities
described above, TTC will consider all proposals that seek to: expand the utility of the FMVD in
a manner that supports the use of public transportation; augment customer convenience and
access to information, and provide economic benefit to customers and the TTC.
7.2.1.10.2 Loyalty Program

In order to maximize potential benefits to customers, TTC requires that the OSFS have the
capability of supporting a loyalty program. To do so, the FMVD must be capable of accessing
information about the status of customer accounts registered to participate in the program.
The structure and operation of the loyalty program supported through the OSFS and the FMVD
will be fully compatible with customer loyalty programs devised and supported by issuers of
financial industry payment instruments. The loyalty program must be designed to calculate
rewards at a minimum based on: frequent use of TTC transit services; on purchases of select fare
purchase options, whether individually or in combination; and on ridership at predetermined
frequencies and in certain travel patterns over specified periods of time. TTC also requires that
the OSFS have the capability of tailoring the loyalty program to respond to changing market
conditions and emerging business opportunities. For example, TTC recognizes its importance as
the core of regional travel by TTC and other public transportation customers. Similarly, TTC
recognizes the importance and complementary nature of non-public modes of transportation as
customers accomplish their travel requirements. TTC wishes to encourage the Private Partner to
configure the OSFS solution in a manner that would permit TTC to support these programs and
opportunities.
The loyalty program must be capable of representing rewards as either direct discount applicable
only for travel on TTC, or as “points” in the manner compatible with loyalty programs offered
by merchants in connection with payment cards issued by financial institutions.
The FMVD will be designed for use as an access point for information about customers’ loyalty
accounts as well as loyalty rewards opportunities offered either by TTC alone or in cooperation
with other entities.
Page
123
7.2.1.10.3 Reporting Requirements
In order to support reporting of compliance with TTC’s performance standards for the
availability and reliability of FMVD, the FMVD will at a minimum provide automated reporting
of the following:
• Cash Box Contents
The total dollar value and contents by bill denomination, associated with a history of activity
for the cash box. Details of activity must at a minimum include the unique identification
number of the cash box, the time it was inserted and removed, the unique identification
number of the individual performing maintenance.
• Media Inventory
The count of pieces of GPR stock available for sale in the FMVD.
• Activity History
A complete listing of all activity performed by the FMVD. This includes, but is not limited to
a report of all sales and reloads activity, “said-to-contain” status of cash boxes, and entries to
the FMVD for revenue and maintenance servicing, tamper events, connection/outage events,
Mean Times Between Failure (MTBF) counts, as well as details of the activities performed
during those entries. The activity history will include a listing in date order of all errors that
occurred, as well as recorded inactivity or failures of systems that support FMVD normal
operations. All activities will be date and time stamped. Additional details will be specified
and finalized during Design Review.
7.2.1.11 FMVD Hardware Components
7.2.1.11.1 Bill Acceptor

In order to achieve compliance with TTC’s performance standards for the availability and
reliability of FMVD, the FMVD will be equipped with a bill acceptor that is proven to perform
under conditions typically found in TTC stations, at usage levels projected at TTC stations, and
under the range of environmental conditions outlined in Section 2.
Bill acceptance will be enabled by the following capabilities:
• A bill acceptor unit that will use state-of-the-art technology to validate the following
denominations of Canadian currency: $5, $10, $20, $50, and $100. The bill validation
software for the bill acceptor will be capable of evaluating all versions of the
aforementioned bill denominations that are in circulation. The Private Partner must
initiate hardware, software, and configuration changes to bill acceptor software to permit
uninterrupted transition to acceptance of new Canadian currency. The Private Partner is
Page
124
responsible to ensure that all updated hardware, software, and configurations are in place,
tested, and fully operational before the issuance and circulation of any new Canadian
currency.
• The bill acceptor unit will consist of a single entry slot with aperture or mechanical
shutter that will automatically open when a sale or reload transaction is ready for
insertion of currency for payment. The aperture or mechanical shutter will remain open
until all currency has been received or until a table-driven time-out has been reached.
To further support compliance with TTC’s performance standards, components of the bill
acceptance system will be capable of remote diagnosis of malfunctions, reporting of status at
pre-determined intervals and on demand from a centralized location.
The Bill Acceptor will meet the following performance standards:

• Initial insertion: 98% acceptance of authentic currency;
• Second insertion: 95% acceptance of authentic currency, and;
• The Bill Acceptor will be capable of rejecting 100% of all counterfeit Canadian currency,
as well as 100% of all foreign currencies.
The Private Partner must provide a Bill Acceptor that is capable of upgrades and reconfiguration
to both hardware and software that maximizes the effectiveness of the Bill Acceptor’s
capabilities to prevent acceptance of counterfeit currencies.
7.2.1.11.2 Bill Vault

The FMVD will be equipped with a bill vault with the following features:
• Capability of storing validated currency. The capacity of the bill vault will be a minimum
of 2,000 pieces of Canadian currency;
• The bill vault will be constructed in a manner and with materials so that at capacity, the
total weight of the vault is no more than 10 kilos and that no physical distortion occurs
when the vault is fully loaded;
• The bill vault will also be hardened to withstand impacts when dropped from a height of
no less than one meter and be fully operational and secure, and;
• Installation of the bill vault will be integral to the operation of the FMVD. If the bill vault
is not installed, or improperly installed, the FMVD will automatically be taken out of
service. Only one orientation will be permitted for proper installation of the bill vault.
Page
125
7.2.1.11.3 Receipt Printer
The FMVD will be equipped with a separate Receipt Printer capable of printing alphanumeric
characters. The printer will be a direct thermal type; with printing capabilities will include upper
and lower case letters and graphics. Printed characters will have the following characteristics:
• Minimum height:
• Font type:
• Height to width ratio:
Receipts issued will comply with all form and content requirements of financial institution
regulations credit and debit card receipts. Receipts will also contain information about the
transaction, as noted earlier in this section, which will provide a detailed record of the transaction
that took place and support customer inquiries in the event that further investigation is required.
The receipt printer will be remotely configurable in a manner consistent with rules and
regulations of the financial services and payments industries. Receipts will be available for all
transactions at the FMVD, including all possible cancelled transactions. Customers will be
provided with the option of receiving a printed receipt at the conclusion of the transaction
sequence. If a transaction failed or was cancelled either by the customer or automatically by the
FMVD, a receipt will automatically be dispensed. If no receipt stock is available at the FMVD,
this status will be displayed on the LCD screen and the overhead electronic display board.
Customers wishing to use a FMVD with no receipt stock will be asked whether to proceed prior
to the start of the transaction.
Receipts will be printed and dispensed to a tray in a timeframe comparable to response times at
ATMs and other automated devices used by the financial services and payments industries. The
receipt will be deposited in the same tray used for depositing the GPR media.
7.2.1.11.4 Fare Media Tray

The FMVD will be equipped with a media tray for the deposit of newly purchased GPR. The
opening for the fare media tray will have the following features:
• A recessed design;
• A clear, durable, and scratch-resistant polycarbonate door that covers the entire opening
of the tray and is affixed in a manner that opens inward and returns to a normally closed
position via mechanical action or gravity;
• A design that minimizes any pinching hazard and protects against any physical intrusions
to the tray while the GPR media is being dispensed;
• A design that permits drainage of liquids in the tray to an area outside the FMVD, and;
Page
126
• A light indicator that flashes inside the tray at the moment that the payment transaction is
completed and the FMVD will deposit the GPR media in the tray. The duration of the
flashing light shall be no less than 5 seconds, or until the start of another transaction.
7.2.1.11.5 PIN Pad

To support acceptance of debit cards as payment, as well as perform additional means of
customer interactions with the FMVD, the FMVD will be equipped with a PIN pad. The PIN
pad will meet all standards required by the financial services and payments industries, including
but not limited to:
• PCI – PED;
• INTERAC standards;
• Master Session;
• EMV Level 1 and Level 2 compliant.
• All banking industry standards for data entry required to support payment transactions;
• Applicable standards regarding the physical characteristics and durability of surfaces,
such as wear, fade, spill, dust, and intrusion resistance;
• Applicable standards of banks, acquirers, and the financial services and payments
industry regarding audible and visual messaging and screen flows that affirm acceptance
and rejection of customers’ interaction with the LCD display in completion of the
transaction.
7.2.1.11.6 Credit/Debit Card Reader

The FMVD will accept magnetic stripe, contact, and contactless open-loop credit and debit cards
issued by financial institutions and other entities to individual customers. The acceptance of
magnetic stripe credit and debit cards is solely for the purpose of sale and reload of transit
accounts at the FMVD. The bank card readers, contact, magnetic stripe and contactless must
comply with all INTERAC and all EMV level 1 and level 2 requirements.
The Credit/Debit Card Reader will be modular and upgradeable to permit upgrades for increased
processing capabilities and maintenance of compatibility with financial services and payments
industries standards, as well as applicable technical standards.
7.2.1.11.7 GPR Dispenser

The FMVD will dispense open standard General Purpose Reloadable (GPR) cards. Once a fare
product has been purchased or reloaded onto the account associated with the GPR card, the GPR
card dispensed or reloaded at the FMVD must be capable of immediate use at any POE to TTC’s
transportation system, as well as capable of being used at any retail store accepting them in a
manner consistent with the functionalities and capabilities of an open standard GPR card.
Page
127
The GPR Dispenser will comply with all open standards requirements of the financial services
and payments industries for automated issuance of GPR cards. Additionally, the GPR Dispenser
will consist of at least two (2) GPR media stackers, or other appropriate mechanisms, that are
each capable of storing or dispensing from the FMVD at least one-thousand (1,000) pieces of
GPR media.
The GPR Dispenser will be equipped to capture all GPR media that failed to dispense due to a
processing error, GPR media defect, or other event interfering with dispensing of a fully
functioning GPR card. A record of the failed dispensing event, along with records of all GPR
Dispenser activity, will be captured and sent to the Central Processor and available through the
Data Mart.
7.2.1.12 Transaction Records

The Private Partner will assure that all banking security requirements for wireless transmission
of financial records must be met.
7.2.1.13 Fare Payment Processing of FMVDs
7.2.1.13.1 Concept of Operations

TTC wishes to simplify the fare payment experience for its customers by implementing a
“merchant” approach to fare payment. A “merchant” approach means that customers’ experience
when paying fares at FMVDs will, resemble to the greatest extent possible and practical their
experiences paying for products in retail store. In so doing, TTC wishes to minimize obstacles in
the learning curve as customers transition to exclusive use of the OSFS.
7.2.1.13.2 Customer Interactions

This section describes customers’ interaction with the Contactless Reader as they present any of
the accepted contactless cards or devices for payment at any FMVDs deployed to support the
OSFS. TTC wishes to identify key aspects of the merchant approach that must be preserved in
providing the OSFS solution for FMVDs. Additionally, TTC wants to assure that technical
solutions for the OSFS will be realized in a way that neither impedes nor prevents compatibility
with progressive improvements to the payment experience as they become available to private
sector retailers at-large. Once the transition to OSFS is complete, TTC requires that the OSFS
solution for FMVDs can easily and economically undergo the market-driven, evolutionary
improvements that would be available to any retail merchant accepting open standards, account-
based contactless media and devices for payment.
During Design Review, the Private Partner must provide a roadmap that details its approach to
assuring that necessary upgrades, improvements, and refreshes to the OSFS occur in a manner
that assures the viability and continued business and operational effectiveness of the OSFS
solution during the term of the operating agreement and, going forward, in a manner that assures
the continued sustainability of the OSFS solution beyond the term of the agreement.
Page
128
Key elements of the merchant approach that define the Concept of Operations for the FMVDs
are described in the following sections.
7.2.1.13.3 Presentment of Contactless and Non-Contactless Media

The FMVD must be capable of accepting presentment of contactless and non-contactless
payment devices for the sale and reload of transit fare media accounts.
All aspects of presentment of contactless and non-contactless payment devices at FMVDs for
sales and reload of transit accounts must occur in a manner identical to presentment in a retail
store.
The Private Partner will develop logical sequences of steps and processes for the interaction
between the customer and the FMVD to support acceptance of payment from the customer that
are consistent with customer experiences in a retail environment and reflect the specific
experience and requirements of sale and reload of TTC fare products through and automated
vending machine. The sequence of steps in this process, which will be supported through a series
of interactions between the customer and the FMVD using screen displays and buttons, must be
clear and simple to understand, must avoid confusing customers, must minimize the number of
interactions between the customer and the FMVD, and must in every aspect of design and
execution enhance and support the customer experience of using automated vending devices.
Presentment and processing options must account for the following scenarios:
• Customers may wish to use anonymous GPR cards available at the FMVD, or to use GPR
cards accepted by TTC for fare payment that are brought to the FMVDs after having been
acquired from another source, for paying TTC fares. As acceptable forms of payment,
TTC requires that FMVDs accept cash as described in this RFPQ, but also accept credit
and debit cards. Acceptance of payment from credit and debit cards, or other devices
equipped with open standards payment capabilities, will be in a manner identical to
presentment and acceptance in a retail store.
• Customers may wish to use the FMVD to purchase or reload their transit account that is
associated with a contactless chip enabled device that has been issued to the customer
directly, in the customer’s name as part of an account relationship through a financial
institution or other authorized issuer of payment cards. In this case, the customer is using
the account-based contactless card issued in their name as both payment medium for the
purchase of TTC fare products, as well as the payment medium for presentment at Points
of Entry to TTC’s subway and surface transportation system.
7.2.1.14 Hardware Requirements, Structures and Finishes

The Private Partner will provide hardware for the FMVD manufactured using materials,
structures, and finishes that will withstand the harsh conditions present across all modes of
transportation services provided by TTC; that will be durable for at least five (5) years beyond
the term of TTC’s agreement with the Private Partner for the provision and operation of the
Page
129
OSFS; and that when prescribed maintenance is performed will maintain its physical appearance,
visual appeal, and operational integrity, and therefore not impact the required performance of
the FMVD for at least five (5) years beyond the term of TTC’s agreement with the Private
Partner.
During Design Review, the Private Partner must submit for TTC’s review and approval all
technical drawings and specifications for all FMVDs and other OSFS equipment.
7.2.1.15 Accommodations for Persons with Disabilities

The customer interface of the FMVD will comply with AODA standards.
7.2.1.16 Time and Date Clock

Each Reader Assembly in the FMVD will have an internal time and date clock. The Reader
Assembly time and date clock will periodically synchronize with the time and date clock
maintained at the Central Processor. Synchronization with the Central Processor will occur at
least once a day or as stipulated by the financial processor. Additionally this synchronization
may be done immediately each time after an interruption in telecommunications services has
been restored.
7.2.1.17 Communications and Power for FMVDs
7.2.1.17.1 Wireless Communications for FMVDs

All FMVDs installed in TTC stations will communicate with the Central Processor in real-time.
All required functionalities of the FMVDs, including transaction processing and uploading and
downloading of data regarding all aspects of FMVD operation, will occur as necessary via
commercially available wireless telecommunications services. The Private Partner will provide
technical specifications that describe the service levels required to support the operation of
FMVD in accordance with TTC’s performance requirements.
In the event of a communications failure, the FMVD and its Reader Assembly will have the
capability of operating in stand-alone or “orphan” mode. In this mode the FMVD will operate in
a downgraded mode where certain functionality may not be available. The FMVD will display
that it is in degraded mode to the customer. As soon as telecommunications connectivity is
restored, the FMVD and its Reader Assembly will resume normal operations in a “real-time”
mode.
After a pre-determined (and programmable) length of time, if telecommunications have not been
restored, the FMVD may be configured to execute an orderly shutdown. The FMVD will exhibit
a closed visual indicator to customers.
Page
130
7.2.1.17.2 Power
The position and location of the FMVD will be determined by the TTC and Private Partner
during Design Review. Initial estimates of FMVD power and foot print and volume will be
provided by the Private Partner in order to assess location and power needs within the station.
7.2.1.17.3 Alternative Power

FMVDs will be equipped with alternative, back-up power which will allow the FMVD to operate
for up to 10 minutes without power.
At the conclusion of the 10 minute period, the FMVD will automatically shut down in an orderly
fashion (i.e., complete any and all transactions and associated technical housekeeping required
for a shutdown) and cease operation.
As part of the orderly shut-down, the FMVD will transmit all reports and data to the central
processor.
7.2.1.18 Private Partner Requirements

The Private Partner will develop, test, manufacture, install, and operate all FMVDs for the
OSFS. This responsibility includes performance of all corrective and preventive maintenance for
the FMVDs installed on TTC property, whether in Subway stations or at other locations as
required by this RFPQ, for a term to be determined. As part of this service, maintenance reports,
services, and analysis will be provided to the TTC at an agreed upon regular basis. Additional
reports may be request by the TTC at any time.
As part of Design Review, the Private Partner will provide detailed documents that describe the
physical and functional characteristics of the FMVD and Reader Assembly. Documentation will
enable TTC to verify the capabilities and functionalities of FMVD and the Reader Assembly, as
well as include certification of compliance with open standards of the financial services and
As part of Design Review, the physical characteristics will be determined by TTC and the
Private Partner.
7.2.1.19 Performance Standards

The Private Partner will provide FMVDs that are capable of meeting and supporting all
performance standards required of the OSFS solution that are described in Section 12. During
Design review, the Private Partner will document and, if required by TTC, demonstrate through
actual testing on site at TTC locations and or test facilities, the capabilities of the FMVD and its
components.
7.2.1.20 TTC Procedures for On-Property Servicing of Equipment

TTC will provide guidelines for on-property servicing of equipment during Design Review.
Page
131
7.2.1.21 Installation
In conjunction with TTC personnel from appropriate departments and areas of responsibility, the
Private Partner will develop and submit for TTC approval an installation plan for FMVDs to be
deployed for the TTC OSFS. At a minimum, the Installation Manual will provide the following:
• A detailed description of all FMVD components, accompanied by drawings, images, and

technical specifications;
• A parts and materials list encompassing all installation scenarios for each TTC station
location;
• A detailed drawing, to be approved by TTC, that shows the exact physical location of the
FMVD placement;
• Detailed installation procedures;
• A detailed field quality assurance and testing protocol;
• A detailed trouble-shooting guide;
• Details of safety procedures and protocols to be followed;
• An installation schedule that identifies the amount of time and Private Partner personnel
resources required to complete timely installation.
The Private Partner will work with TTC to develop and publish an Installation Manual that will
be used to guide the required installation process during Design Review. The Installation Manual
will be subject to review and final approval by TTC.
8 Surface Vehicles
8.1.1 Overview
The Private Partner will procure and install new Reader Assemblies on TTC’s surface vehicle
fleets. The Reader Assembly will be designed in a manner that permits installation on all surface
vehicles in TTC’s fleets. The design of the Reader Assembly must also be suitable and adaptable
for installation on a broad range of different surface vehicles, such that a complete redesign of
the Reader Assembly would not be required for future additions to TTC’s surface transportation
fleet.
The new Reader Assemblies will process payment of all TTC fares by accepting all contactless
media and devices that comply with open standards of the financial services and payment
industries.
The customer-facing appearance of the Contactless Readers integral to the Reader Assemblies
will be identical in appearance to Contactless Readers mounted on Fare Media Vending Devices.
Page
132
For Contactless Readers installed on surface vehicles only, the Private Partner will provide
unique interfaces that enable TTC’s Operators to see results of responses from the Central
Processor and Reader Assembly as customers’ present contactless media and devices for fare
payment.
As part of Design Review, the Private Partner will provide detailed documents that describe the
physical and functional characteristics of the Reader Assembly. Documentation will enable TTC
to verify the capabilities and functionalities of the Reader Assembly, as well as include
certification of compliance with open standards of the financial services and payments industries.
The new LRVs will operate using a proof-of-payment (POP) fare collection system and,
therefore, will operate fundamentally different than TTC buses. All OSFS proposals must
address these differences, which are discussed in more detail in Appendix C.
8.1.2 Fare Payment Processing
8.1.2.1 Concept of Operations

TTC wishes to simplify the fare payment experience for its customers by implementing a
“merchant” approach to fare payment. A “merchant” approach means that customers’ experience
when paying fares at Points of Entry to TTC transportation services will very closely resemble
their experience paying for products in a retail store. To the greatest extent possible, TTC wishes
to replicate customers’ payment experience in retail stores, thereby removing as many obstacles
to the learning curve as customers’ adopt use of the OSFS.
This section describes TTC’s requirements for customers’ interactions with the Contactless
Reader as they present for payment any of the accepted contactless cards or devices at the Point
of Entry to TTC’s transportation services. In providing this descriptive detail, TTC identifies key
aspects of the merchant approach that must be preserved in providing the OSFS solution at
Reader Assemblies on surface vehicles. Additionally, TTC wants to assure that technical
solutions for the OSFS will be realized in a way that neither impedes nor prevents compatibility
with progressive improvements to the payment experience as they become available to private
sector merchants at-large.
Once the OSFS is fully operational and accepted for revenue service, TTC requires that the
OSFS solution for Reader Assemblies can readily support upgrades emerging from market-
driven, evolutionary improvements in the financial services and payments industry. In its role as
a merchant, TTC specifically requires that the OSFS can accommodate improvements that would
be available to any retail merchant accepting open standards, account-based contactless media
and devices for payment. No aspect of the Reader Assembly design and implementation will
impede processes or procedures required by financial institutions and the payment industry, or
interfere with compliance with all required financial services and payment industry standards.
Page
133
8.1.2.2 Customer Interactions
Key elements of the merchant approach that define the Concept of Operations for the OSFS are
described below.
8.1.2.2.1 Presentment of Contactless Media

All aspects of presentment of Contactless Media at Contactless Readers for fare payment will
occur in a manner identical to presentment in a retail store. Customers will:
• Present Contactless Media to the Contactless Reader at the time that payment is required.
For payment of TTC fares, this will occur only at Points of Entry (i.e., Reader
Assemblies installed in Subway stations and Reader Assemblies at entry point to TTC
surface vehicles;
• Customers will only receive either an approval or denial response at the Point of Entry.
No details of account balances are provided. Customers will need to have prior
knowledge of their ability to pay, or simply rely on the payment authorization process for
acceptance or denial of the method of payment being presented. As is the case in a retail
environment, further details about the status of the customer’s account will require the
customer to check with their financial institution or transit account independent from the
‘tap-on’ payment process.
• As stated above, customers perform inquiries about their transit account balances as a
separate step in the payment process. For accounts issued to customers by financial
institutions, remediation of account issues will require that customers deal directly with
their issuing financial institution. For co-branded GPR cards that are sold and accounts
that are reloaded at Fare Vending Machines located in TTC stations, customers may
inquire about account status and reload accounts at those Fare Vending Machines. Out-
of-system, Customers may make inquiries at designated sales and reload locations located
off TTC property.
8.1.3 Reader Assembly Functional Requirements

All functionality required of the New Reader Assemblies must be accomplished on a stand-alone
basis, with no integration with elements of TTC’s legacy fare payment system.
If applicable, there may be some integration with on-board location monitoring equipment
already installed on TTC vehicles. If this integration is required, only standard serial interfaces
on the reader assembly will be used to integrate to existing TTC equipment. Integration issues
will be detailed and finalized during Design Review.
8.1.3.1 Concept of Operations

During the implementation of and transition to the new OSFS, all legacy surface vehicle fare
equipment will remain in place and fully operational. The maintenance of all legacy surface
Page
134
vehicle fare equipment will remain the responsibility of TTC throughout the implementation and
transition periods.
No alterations of the functionality or physical design of legacy fare equipment will be required or
permitted. No mounting or attachment of OSFS equipment is permitted to any legacy fare
equipment, except as described below in order to enable access to power, routing of additional
cables, or provide physical stabilization for the new Open Standard Payment System equipment.
8.1.4 Transaction Processing
8.1.4.1 Acceptance of Contactless Media and Devices

The Reader Assembly will include a commercial, off-the-shelf (COTS), non-proprietary
contactless reader. The Contactless Reader will be at a minimum ISO 14443, Type A and B
compliant.
When the Reader Assembly is communicating with the Central Processor, acceptance of
contactless media and devices will occur in 500ms or less. When communications to the Central
Processor are unavailable, the Reader Assembly will process transactions in orphan mode in
500ms or less. As previously described, additional risk mitigation checks and balances will be in
place to minimize any potential card fraud while in orphan mode.
The Reader Assembly will be equipped with software and configurable, table-driven parameter
settings that allows, among other things, TTC to set upper limits for transaction processing
speeds that would automatically cause the Reader Assembly to default to Orphan Mode.
8.1.4.2 Reader Assembly Operations

The Reader Assembly will have the capability to operate only while the bus, streetcar, or other
surface vehicle is in revenue service.
The operator will be able to set the Reader Assembly to In Service/ Out of Service as the surface
vehicle enters and exits revenue service. Service Status is a reportable item.
All Reader Assemblies will clearly indicate that they are In Service or Out of Service to the
customer and vehicle operator via light/LED indicators mounted integrally to the reader.
The Reader Assembly will begin an initialization process as soon as the surface vehicle engine is
running or when the surface vehicle propulsion system is engaged. No intervention by any
personnel will be necessary for the Wake-Up and Initialization process to begin and continue
through to completion.
The initialization process will entail a self-diagnostics protocol that will check all components in
the Reader Assembly, perform security protocol checks including, but not limited to application
signature checks and key checks, and initiate a live connection via the wireless service provider
back to the Central Processor.
Page
135
If all steps of the Initialization process are completed except for confirmation of wireless
connectivity, the Reader Assembly must automatically report its status to the Central Processor
once wireless communication is restored. The end-to-end initialization process must take no
longer than 120 seconds to complete after the start of the surface vehicle propulsion system.
The Reader Assembly will only indicate that connectivity has been achieved as part of the
Initialization Process at the start of surface vehicle operations prior to pull-out. During the course
of revenue service, there will be no visual or audible indication that the Reader Assembly lacks
connectivity to the wireless network. During the course of revenue service, the Reader Assembly
will not provide any indication of resumption of wireless connectivity after a lapse in wireless
service. In short, from a customer point of view (and/or the surface vehicle operator point of
view) the surface vehicle card reader functions identically whether or not it is connected to the
network or not.
When the surface vehicle engine is not running, or the surface vehicle propulsion system is off,
the Reader Assembly will be capable of detecting the loss of power from the surface vehicle
electrical system, complete any pending transaction and perform all the necessary technical
housekeeping required before shutting down. This includes, but is not limited to, securely
authenticating and storing all status, files, records, and configurations in non-volatile memory.
A restarting of the surface vehicle engine, or turning on of the surface vehicle propulsion system
will cause the initialization process to begin again.
During Design Review, the Private Partner must describe all use cases inherent in the proposed
functionality of the Reader Assembly design for installation on TTC’s surface vehicle fleet and
Wheel-Trans vehicles.
8.1.4.3 Reporting of Reader Assembly Activity

The Reader Assembly will record all status conditions in connection with the operation of the
OSFS and forward status data to the Central Processor for reporting purposes.
For reporting and auditing purposes, the Reader Assembly must have the capability to capture
data regarding all approved and denied transactions.
When connectivity with the wireless network is operational, the Reader Assembly must be
capable of forwarding, at a minimum, the following data to the Central Processor as part of the
real-time transaction data stream:
• The account used for payment;
• A date and time stamp;
• A unique identifier for the Reader Assembly;
Page
136
• All changes in the status of the Reader Assembly or any component therein;
• All configuration changes initiated through the Central Processor;
• All communications with the Central Processor;
• All communications failures;
• All power failures and restorations;
• GPS/Location data available through the modem and wireless telecommunications
service;
• All additional information necessary to provide full accountability and audit of all
interactions between the Reader Assembly and customers.
Finalization of the requirements outlined in the aforementioned list will be completed during
Design Review.
In the event of an interruption of real-time wireless network connectivity, the Reader Assembly
will have the capability to store and forward all required data transmissions described above.
The capability to store-and-forward will include the capacity to store a minimum of 7 days of
payment transactions and related data for Reader Assembly status reports.
The Reader Assembly will be capable of completing the store-and-forward function as soon as
wireless connectivity is restored. The Reader Assembly’s performance of the store-and-forward
function will neither interrupt nor impede normal transaction processing. The Reader Assembly
will provide unique memory for the store and forward functionality, such that accumulation of
data in the store-and-forward memory will not diminish or impact the memory used for the Local
Hotlist.
Provided the Reader Assembly is operational and wireless connectivity is established, the Reader
Assembly must forward all data in the store-and-forward memory to the Central Processor on a
daily basis at the close of the Business Day, whether the surface vehicle is in revenue service or
not.
8.1.4.4 Diagnostic Reporting

The Reader Assembly will be equipped with operational self-diagnostic capability. If wireless
connectivity is available, the Reader Assembly will be capable of reporting on the status of non-
operational components. Otherwise, the Central Processor will interact with individual Reader
Assemblies to check on their status on a periodic basis throughout in-service operation.
In the absence of a response from the Reader Assembly that is indicative of normal operations,
the Central Processor will record the event and broadcast an alert to the Maintenance Facility and
Page
137
the Maintenance Management System provided by the Private Partner. This alert will also be
broadcast to TTC in an automated manner via e-mail and/or SMS text.
Further details concerning device management and monitoring will be determined during
detailed Design Review.
8.1.4.5 Reader Assembly Messaging and Displays to Customers

The Contactless Reader that is part of the Reader Assembly mounted on the surface vehicle will
have visual and audible indicators that provide distinctive messages for approval or denial of a
payment transaction made with a contactless device. Visual indicators on the Contactless Reader
will be lighted displays that clearly convey the approval or denial message and that are visible
from a distance of 6 feet and will comply with AODA standards.
The Private Partner has the option of proposing a supplementary alphanumeric display that could
convey additional details about the reason for authorization denials. Any proposal for an
alphanumeric display would be restricted to a solution that would only display messages derived
from Authorization Response Codes that are supported by all participants in the acquisition and
processing of open standard, account-based financial payment transactions.
Any proposed messaging must be identical to messages that are conveyed to customers at a
merchant or retail point of sale. These messages typically provide additional details, or
instructions, to customers in the event the customer has experienced a denial after presentment of
a payment device to a reader.
TTC requires that any option that proposes additional functionality would only provide
supplementary alphanumeric messages to response codes resulting from a soft decline.
Provisioning of this feature must be accomplished to assure compliance with TTC’s performance
requirements for transaction processing, authorization response times, and reporting.
The display of alphanumeric characters for this functionality will at a minimum conform to
messaging and information display guidelines for the financial services and payments industries
and AODA.
8.1.4.6 Transaction Location Information

Surface vehicles using open payment standards will require location information in order to
enforce TTC transit rules and fare policies. Either location sensing equipment must be installed
as part of the OSFS system or the OSFS system should interface to existing on-board GPS/stop
location data. This will be determined during detailed Design Review. In all cases only standard
serial (e.g., RS232, USB, etc.) ports will be used as the hardware interface on all card reader
assemblies.
Page
138
8.1.4.7 Audible Tones
The Reader Assembly must also emit audible tones to indicate the results of transaction
processing. A minimum of two tones, each differentiated in pitch, is required to correspond with
a transaction approval and a transaction denial. Additional tones may be required as a result of
Design Review.
The decibel levels of the tones will be programmable locally. The decibel level of audible tones
emitted by Reader Assemblies will be adjustable and will comply with AODA and TTC
standards.
The ability of Reader Assemblies to emit audible tones will be included as part of initialization
and automated self-diagnostic check performed each time the Reader Assembly is powered up.
8.1.4.8 Permanent Graphics

Permanent graphics related to industry standard branding of payment card and payment device
readers will conform to guidelines of the financial services and payments industries. In addition,
permanent graphics to instruct customers on contactless media usage consistent with messages
required and sanctioned by card associations and brands will be mounted either on the exterior or
adjacent to the OSFS Contactless Reader. These will be determined during detailed Design
Review.
8.1.4.9 Off-Line or Orphan Mode Operation

Each Reader Assembly will be designed to operate in Off-Line or Orphan Mode. This may occur
when telecommunications service is interrupted.
In the event of a telecommunications service interruption, the Reader Assembly will continue
operations in Orphan Mode. Under this circumstance, transaction processing will rely on
Authorization of contactless media and devices by use of a Local Hotlist.
8.1.4.10 Local Hotlist

The Local Hotlist will consist of account numbers developed and parsed in a manner to minimize
TTC’s financial risk under the circumstances of a temporary loss of telecommunications
services. The Private Partner will populate the Local Hotlist after collaborative analysis between
TTC and the Private Partner of TTC’s risk history as a merchant. Population of the Local Hotlist
with updated information will occur at a minimum of two times per business day, or by manual
command originating from the Central Processor.
The Local Hotlist will be capable of holding a minimum of 50,000 accounts. The Local Hotlist
will have memory capacity dedicated solely to the hot listing function. Immediately after
resumption of telecommunications service, the Local Hotlist will be updated with current data.
Updating will occur on an exception basis, i.e., the Local Hotlist will be repopulated only with
Page
139
changes to the prior version already resident in the Reader Assembly memory in order to
minimize transmission times and data download bandwidth.
8.1.4.11 Store and Forward Capability

During a telecommunications outage, all transactions at the Reader Assembly will recorded and
stored in dedicated memory. This Store and Forward function will operate independently of the
Local Hotlist and will not rely on the Local Hotlist memory. The capacity of the Store and
Forward function as well as the duration that the Reader Assembly is allowed to be in Orphan
Mode will be determined during Design Review.
8.1.4.12 Passback Control

The Reader Assembly for all surface vehicles, buses, streetcars, and Wheel-Trans vehicles, will
include a Passback Control feature. This feature will allow TTC to control the use of unlimited
ride fare products, such as passes, by limiting the number of concurrent trips within a specified
time. The time period during which a passback is not permitted will be a table driven parameter
setting and will be part of the Reader Assembly configuration. The setting will be controlled
remotely from the Central Processor. Settings can be programmed at a minimum to affect:
• A specific Reader Assemblies assigned to a particular surface vehicle;
• All Reader Assemblies assigned to all surface vehicles;
• All Reader Assemblies on all surface routes globally;
• Any of the aforementioned possibilities in combination with designated Reader
Assemblies installed at Subway locations.
The Private Partner must submit details of its proposed solution for review and approval during
Design Review. Other potential setting may be developed during the course of Design Review
and may need to be incorporated into the OSFS solution.
8.1.4.13 Time and Date Clock

Each Reader Assembly will have an internal time and date clock. The Reader Assembly time and
date clock will periodically synchronize with the time and date clock maintained at the Central
Processor and/or financial service provider. Synchronization with the Central Processor will
occur as necessary to ensure clock jitter does not exceed one (1) second / day throughout all
seasons of the year.
8.1.5 Hardware Requirements

TTC requires that the proposed solution from the Private Partner use only commercially
available, non-proprietary design and equipment. All physical and technical aspects of the
proposed solution would be required to conform to maintainability and installation guidelines
described below.
Page
140
8.1.5.1 Data Storage
In the event that data storage requirements are exceeded, the Reader Assembly will conduct an
orderly shutdown and remain out of service until data in the non-volatile memory can be sent to
the Central Processor.
The Reader Assembly will have the capability to have data resident in its memory downloaded at
the Private Partner’s secure maintenance facility. In the first instance, the capability will consist
of reinitializing wireless connectivity between the Reader Assembly and the Central Processor
while the Reader Assembly is at the maintenance facility of the Private Partner.
The Private Partner will implement protocols and procedures for the secure handling of all data
that is downloaded from Reader Assemblies at the maintenance facility. Access to data in the
Maintenance Facility will conform to PCI-DSS standards and is auditable by a third party. The
Maintenance Facility will be certified as PCI-DSS compliant as part of the overall certification of
the new OSFS developed for TTC by the Private Partner.
8.1.5.2 Communications
The Reader Assembly will be designed to operate over commercially available wireless
networks using 3G or better standards. The Reader Assembly will be forward compatible for
4G and LTE wireless communications so that when they are widely available, TTC will be able
to upgrade to those services at its own discretion. A non-integrated, self-contained cellular
modem can be used for communications allowing for easy upgradeability.
8.1.5.3 Structure and Finish Requirements

TTC seeks a design for the Reader Assembly that is functional, attractive and clearly indicative
of the technical advances offered by the OSFSs. The Reader Assemblies must also be
operationally effective and efficient, and well-suited to the physical environment of all surface
vehicles in TTC’s fleet. Additionally, the Private Partner must incorporate design features that
assure conformity with standards used by the financial services and payments industries that
support consumer recognition and easy understanding of the purpose and use of the Reader
Assembly for payment of transit fares.
TTC requires that the Private Partner propose designs of the Reader Assembly that:
• Enable installation of the Contactless Reader interface in an optimal position for use by
customers on any surface vehicle currently in service at TTC, as well as being suitable or
adaptable to installation on surface vehicles operated as part of the Wheel-Trans program;
• Enable installation of the Reader Assembly in a manner that does not interfere with the
normal operation of surface vehicles and the required activities of Operators while
performing their driving responsibilities;
• Enable Operators to have a clear view of Operator displays;
Page
141
• Enable minimal adaptation of the Reader Assembly to permit installation on future
additions to TTC’s surface vehicle fleets;
• Enable full replacement of the Reader Assembly components in a “plug-and-play”
manner, in 10 minutes or less with minimal requirement of tools.
During the Design Review phase, TTC will provide the Private Partner with access to all surface
vehicles in its fleet to facilitate the design process and the dry fitting of Reader Assemblies.
The Private Partner must submit all designs for the Reader Assembly, as well as detailed
drawings showing proposed installation locations. The Private Partner must also fabricate full
scale models of proposed designs and work with TTC personnel to execute a dry fitting on each
model in TTC’s fleet during Design Review.
All Reader Assemblies will be manufactured to conform will all applicable electrical standards,
codes, and procedures applicable to the type of surface transportation vehicle (bus, streetcar,
LRV) on which it is installed. Similarly, all Reader Assemblies will comply with all TTC
requirements for installation of vendor equipment on TTC surface vehicles. TTC’s requirements
will be detailed during Design Review.
All Reader Assemblies will be manufactured to resist intrusion of foreign objects and moisture of
any sort. Specifically, moisture seals on all components and wiring harnesses shall preclude the
intrusion of water directed at Reader Assemblies.
The external structure and finishes of Reader Assemblies will be free and clean of any
projections, sharp edges or corners that could result in personal injury via incidental contact with
the Reader Assembly. All exterior finishes will resist corrosion, abrasion, and scratching, as well
as be free of any physical manifestations of the manufacturing process, such as weld marks,
irregularities, discolouration, distortion, and cracks.
Each Reader Assembly will have a unique, alphanumeric serial number permanently mounted as
a unique tag attached to the exterior of the Reader Assembly. The same tag will also include bar
codes.
The same serial number will be affixed to each major component of the Reader Assembly so that
components can be matched with the complete Reader Assembly unit as delivered by the Private
Partner. Identification tags attached to Reader Assemblies will be tamper resistant tags.
The Reader Assembly and housings for all exposed components of the Reader Assembly will be
manufactured to withstand extended use in TTC’s bus and streetcar environment. This includes
variations in temperature and humidity. The private partner may add additional components to
the card Reader Assembly required for the card Reader Assembly to operate effectively under
Page
142
environmental conditions, for example, a heater for readers on surface vehicles. Materials used
should withstand attempts at vandalism, theft, and physical abuse.
During Testing and Acceptance, the Private Partner must provide TTC with documentation of
independent test results of all components for vibration, water intrusion, electrical interference,
etc.
TTC in conjunction with the private partner will develop installation, performance and operating
tests and procedures applicable to Reader assemblies.
The Private Partner will work in conjunction with the TTC in determining minimum
requirements for fabrication of housings and other components of Reader Assemblies, whereby
the experience of the private sector can be brought to bear in developing optimal, economically
sustainable standards for this type of equipment.
All surfaces not constructed using stainless steel, aluminum, or plating will be painted using
corrosion-resistant paint. The final finish will be a hardened, enamel finish that is free from all
application defects. TTC, in accordance with AODA and other applicable requirements, will
determine the colours used for painting of exposed surfaces of the Reader Assembly.
8.1.5.4 Accommodations for Persons with Disabilities

All AODA standards will be met in the design, fabrication, functionality, and installation of
Reader Assemblies intended for use on TTC’s surface vehicles and vehicles for service providers
participating or using the OSFS system.
8.1.5.5 Maintenance
Maintenance of Reader Assemblies for surface vehicles must at a minimum incorporate all
maintenance procedures and protocols for Reader Assemblies to be deployed in the subway
system. Addtionally, maintenance protocols must take into consideration specific requirements
for maintenance on surface vehicles.
8.1.5.6 Performance Requirements

The Private Partner will provide Reader Assemblies for all surface vehicles that are capable of
meeting and supporting all performance standards required of the OSFS solution that are
described in Section 12. During Design Review, the Private Partner will document and, if
required by TTC, demonstrate through actual testing on site at TTC locations and or test
facilities, the capabilities of the Reader Assembly and its components that were manufactured for
installation on surface vehicles.
8.1.5.7 TTC Procedures for On-Property Servicing of Equipment

TTC will provide guidelines for On-Property Servicing of Equipment during Design Review.
Page
143
8.1.5.8 Hardware, Structure and Finishes
The Private Partner will provide hardware for Reader Assemblies intended for installation on
surface vehicles that are manufactured using materials, structures, and finishes that will
withstand the harsh conditions present at across all surface modes of transportation services
provided by TTC and other participants in the OSFS; that will be durable for at least five (5)
years beyond the term of TTC’s agreement with the Private Partner for the provision and
operation of the OSFS; and that when prescribed maintenance is performed will maintain their
physical appearance, visual appeal, and operational integrity, and therefore not impact the
required performance of Reader Assemblies for at least five (5) years beyond the term of TTC’s
agreement with the Private Partner.
During Design Review, the Private Partner must submit for TTC’s review and approval all
technical drawings and specifications for all Reader Assemblies and other OSFS equipment.
8.1.5.9 Installation Requirements

TTC requires that the Private Partner install all Reader Assemblies in a manner conforming to
applicable TTC procedures and safety standards. All applicable procedures and safety standards
will be provided during Design Review.
In addition, TTC requires that the Private Partner, with guidance and cooperation from TTC,
prepares an Installation Manual for Reader Assemblies. The final version of the Installation
Manual will be subject to review and approval by TTC.
At a minimum, the Installation Manual will provide the following:
• A detailed description of all Reader Assembly components, accompanied by drawings,

images, and technical specifications;
• A parts and materials list encompassing all installation scenarios for each TTC surface
vehicle type;
• Detailed installation procedures by type of surface vehicle;
• A detailed field quality assurance and testing protocol;
• A detailed trouble-shooting guide;
• An installation schedule that identifies the amount of time and Private Partner personnel
resources required to complete timely installation.
The Private Partner will work with TTC to develop and publish an Installation Manual that will
be used to guide the required installation process during Design Review. The Installation Manual
will be subject to review and final approval by TTC.
Page
144
9 Other TTC Locations
9.1.1 Overview
TTC operates a walk-in Customer Service Centre on the first floor of its headquarters location at
1900 Yonge Street, Toronto, Ontario. Currently, the Customer Service Centre serves as a sale
and reload location for legacy TTC fare media, a point of intake for customer inquiries about
TTC’s Current System; and as a point of contact for general information about TTC’s
transportation services.
TTC intends to continue operating its Customer Service Centre with TTC staff through the
period of implementation of the OSFS. During this time, TTC will continue to address all
inquiries regarding the Current System and TTC’s transportation services.
Once the OSFS is operational, the TTC CSC will assume the new functionality of supporting
customer service related to the OSFS. The purpose of the TTC CSC will be to provide customers
with:
• Sale of contactless GPR media accepted for fare payment on TTC, as well as reload
opportunities for transit accounts;
• Access to “hands-on” assistance from TTC’s staff on the purchase and use of all forms of
open standard, contactless media and devices;
• Access to account information and TTC staff assistance with inquiries and problem
resolution;
• Intake opportunities for claims that can be handled by TTC as a merchant;
• Guidance on other opportunities and procedures for inquiries and claims resolution that
are not the purview of TTC.
Additional functionality will be identified during detailed Design Review.
9.1.2 Concept of Operations

The TTC CSC will be an integral part of TTC’s vision for a merchant-based approach to fare
payment. TTC requires that its CSC function as a physical portal for direct contact with
Customer Agents who can provide immediate assistance in all aspects of the Open Standards
Payment System.
The Private Partner must propose a solution for TTC’s CSC that in its outward appearance, in its
provisioning with equipment, and in its overall capabilities and performance exceeds customer’s
expectations and experience in conducting business in an automated retail merchant
environment.
Page
145
9.1.3 Equipment
9.1.3.1 Fare Media Vending Devices

In order to support TTC’s CSC operation, the Private Partner will equip TTC’s CSC with
FMVDs. The FMVDs installed at the CSC will be identical in design and function to those
installed in TTC’s subway locations. The number and placement of machines will be determined
9.1.3.2 Internet Access

Window locations at TTC’s Customer Service Centre will also be equipped with computerized
access to the Web Site. Access to the Web Site will be enabled with all functionalities that would
permit Customer Agents to assist customers in person in the same manner as live agents assigned
to the Private Partner’s CSCC can when conducting business over the phone. All manner of Web
Site access and functionality will be identical to what is available to customers accessing the
Web Site through their personal computers and other web-enabled means. Any additional
equipment such as PIN pads required for customers to add value to their accounts will also be
provided.
9.1.3.3 Surface Vehicle Reader Assembly

To facilitate customers’ learning experience, the Private Partner will install mock-ups of surface
vehicle Reader Assemblies at a central CSC location. The Reader Assemblies will be fully
operational, except that it will not permit the processing of payment transactions. The Reader
Assembly will be capable of cycling through the various modes of media acceptance and status
conditions that customers would experience under normal operations.
In order to facilitate the educational purpose of this installation, the Private Partner will provide
TTC with sufficient contactless test media. The test media will activate the Reader Assembly so
that it can be used to illustrate normal operations, except for the execution of actual payment
transactions.
The results of “test” and demonstration activity as the Reader Assembly will be captured and
capable of being displayed to customers via simulated access to the Web Site at any FMVD in
TTC’s CSC.
9.1.4 Customer Agents
9.1.4.1 Duties and Responsibilities

TTC will rely on Customer Agents employed by TTC to assist walk-in customers and address in-
person inquiries only.
Once the OSFS is operational, all telephone inquiries regarding the OSFS will be directed to the
CSCC operated by the Private Partner.
Page
146
TTC intends to maintain its own call intake capabilities. However, the call-intake capability will
be modified to instruct customers to contact the Private Partner’s CSCC for all inquiries related
to the OSFS. TTC’s call system will have the capability to provide “warm” transfer link for calls
to the CSCC and will be multi-language capable.
9.1.4.2 Training
The Private Partner will include TTC’s Customer Agents in its training program about the OSFS,
including all aspects of FMVD and Web Site usage and contactless media and device recognition
and usage.
At a minimum after completion of training, TTC’s Customer Agents will be proficient in

addressing:
• Use of FMVD for purchase and reload of contactless GPR media;
• Use of FMVD and internet access to acquire information about individual customer
accounts and the OSFS program at TTC;
• Use of surface vehicle Reader Assemblies for payment of fares;
• How to find sales and reload locations for contactless GPR media that are off TTC
property;
• Inquiries about fare purchase options and pricings;
• Inquiries about PAYG and Transaction Aggregation for billing purposes;
• How to resolve payment issues versus usage issues;
• Contactless device replacement issues;
• Refund and chargeback requests;
• Reports of lost or stolen contactless devices;
• Registration processes for options available to customers when using the OSFS;
• Enabling/disabling Autoload for Pre-Funded accounts;
• Inquiries about concession fares and procedures needed to qualify;
• Customer complaints;
• Explanation of statements provided by the OSFS;
• Inquiries about GPR products issued through Fare Media Vending Devices on TTC
property;
• Inquiries about use of Fare Media Vending Devices;
• Payment of fares for several individuals by one individual paying under a single account;
Page
147
• Referrals to appropriate resources for inquiries outside the responsibility of TTC’s CSCs
and of the general responsibilities and capabilities of TTC as a merchant.
Further training areas may be identified throughout the course of the OSFS development.
Identification of these training areas and the subject matter of training materials will be
identified, developed, reviewed, and approved during Design Review.
TTC anticipates that Customer Agents will be required to refine and develop further
competencies related to customer support for the OSFS. The Private Partner will incorporate
TTC’s CSC staff in all plans for continuing education about the OSFS.
9.1.4.3 Customer Service Scripts

Based on the accepted Operating Plan Statement, the Private Partner will develop and publish
Customer Call Centre Scripts for use by Customer Agents. The basis for these Customer Service
Call Scripts will be to anticipate and document all likely interactive discourses between
Customers and Customer Agents. TTC requires that the Private Partner, in conjunction with TTC
staff, review and modify the scripts for training purposes and use in a face-to-face customer
service environment.
TTC requires that the Private Partner proactively revise Customer Service Scripts in response to
actual Customer Agent’s experience in handling customer inquiries. The Private Partner must
include feedback from all Customer Service operations in the revision process. To do so, TTC
requires that the Private Partner include formal intake from TTC’s CSC.
9.1.5 Equipment Maintenance
9.1.5.1 Equipment to be Maintained

TTC requires the Private Partner to maintain all OSFS equipment installed at the CSC for a term
to be determined during the procurement process.
Equipment under maintenance is:

• All FMVDs;
• All surface vehicle Reader Assemblies;
• All equipment provided by the Private Partner for the Customer Service Call Centre;
• All equipment provided by the Private Partner used for accessing the Web Site;
• All other equipment provided by the Private Partner to other participants or affiliates in
the use of the OSFS.
Page
148
9.1.5.2 Performance Standards
The Private Partner will be responsible to assure that all services/equipment installed at the TTC
CSC is 100% available during normal hours of operation. If required, the Private Partner can
install redundant equipment and local consumable stock (paper rolls etc.) to ensure that this SLA
is achieved.
Normal hours of operation will be determined during Design Review.
For Web Site access through FMVD and computerized equipment, availability will be 99.99%,
or no more than one hour of downtown annually.
9.1.5.3 Reporting Requirements

The Private Partner will report on activities and performance regarding the OSFS the using the
same methodology and metrics as for the Private Partner’s CSCC.
The Private Partner will provide TTC with standard reports that capture all business activity. In
providing this capability, the Private Partner must detail the connection procedure to the
environment, associated security, and the user interfaces. In addition, standard reports will track
performance of the FMVD and interactions with the Web Site facilitated by TTC’s Customer
Agents.
The content and format of standard reports will be finalized during Design Review.
Standard reports will be provided using tools that simplify access and use of reports and enable
ad-hoc report production. The Private Partner will provide TTC direct access to the report
generation facility of its business solution. TTC will have the capability of generating standard
reports at will on an intra-day basis as of a given start and end date.
Standard reports will capture information from all business functions of the CSC by date, time of
day, and day by hour, and at a minimum include:
• Customer Agent activity reports;
• Caller activities that result in warm transfers to the Private Partner’s CSCC;
• Utilization of Web Site resources.
The Private Partner will provide TTC with a direct feed of data files used in preparation of all
standard reports. Data files will be transmitted to TTC’s Data Mart at the conclusion of each
business day.
Page
149
9.2 Non-TTC Retail Sales and Distribution Locations
9.2.1 Overview
TTC wishes to assure that its customers have widespread, convenient opportunities to purchase
fares for travel on TTC services. The convenience and ubiquity of Non-TTC Retail Sales and
Distribution Locations must surpass the convenience of purchasing and reloading fares at TTC
in-system locations.
To this end, TTC requires that the Private Partner develop and execute a plan that would offer
customers an off-property network for sales and reload of customer transit accounts that is
consistent with customer demand and that assures access to fare media for customers who are
unbanked.
By network, TTC refers specifically to physical locations known and conveniently accessible to
customers that are:
• Proximate to TTC surface vehicle stops and subway stations;
• Retail and other “destination” locations for a broad range of consumer activities, such
that sales and reload of accounts can dovetail with those activities rather than require
travel to a transit-only destination to buy and reload TTC fares.
TTC also requires that the Private Partner implements the OSFS in a manner that supports
participation of all public and private direct funding programs that use contactless or NFC-
enabled media or devices in compliance with open standards and financial industry payment
protocols.
9.2.2 Concept of Operations

At Non-TTC Retail Sales and Distribution Locations, TTC customers will have the same
opportunities to purchase GPR cards and reload their transit accounts as they have at FMVDs
installed in TTC stations, on the Web Site, and through the Customer Call Centre established by
Customers who already have in their possession contactless open standard media or devices must
be able to purchase or reload their transit account with any TTC revenue fare product or payment
option allowed by TTC policy.
Customers who do not have contactless open standard media or devices will have the opportunity
to purchase a General Purpose Reloadable (GPR) that is a contactless and magnetic stripe card.
The GPR card will be an open-loop card that can be used for other retail purchases in addition to
purchase and reload of transit accounts. At a minimum, all staffed Non-TTC Retail Sales and
Reload Locations will offer open-loop, contactless and magnetic stripe open standard GPR cards
for sale and reload.
Page
150
Staffed locations may offer sales and reload, either individually or in combination, through direct
interaction with sales or customer service personnel, or through automated vending machines
intended for direct customer use that are installed at the location.
9.2.3 Business and Functional Requirements

Non-TTC Retail Sales and Reload Locations will be capable of processing transactions in real-
time. All self-directed customer sales and reloads of contactless media accepted for fare payment
at TTC must be completed at the time of sales and reload so that:
• Customers whose transactions have been approved can immediately use the GPR media
or devices newly acquired at the Non-TTC Retail Sales Location for transportation
services;
• Customers who already have GPR or other contactless media or devices enabled for
payment of TTC fares through self-directed sales and reload by customers can, upon
completion of an approved transaction, immediately use the GPR media or devices
acquired at the Non-TTC Retail Sales Location for transportation services.
9.2.3.1 Fare Payment Options

All Non-TTC Retail Sales and Reload Locations will offer regular, full-fare customers the
opportunity to reload all regular, full-fare TTC fare purchase options.
TTC customers entitled to self-funded purchase or reload special discounted, or concession fares
will have the opportunity to reload TTC concession fares for which they are eligible.
9.2.3.2 Availability of Contactless GPR Media and Devices

All staffed locations in the Non-TTC Retail Sales and Reload Location network will make
available GPR media or devices in sufficient supply to service customer demand. All GPR media
or devices available at these locations will be both contactless and magnetic stripe enabled as a
means of assuring access to the broadest possible network of sales and reload locations.
9.2.3.3 Service Levels
9.2.3.3.1 Locations
TTC requires the Private Partner to identify and include in the Non-TTC-Retail Sales and Reload
network suitable, convenient locations where customers can readily purchase and reload their
transit accounts.
All locations to be included in the network must provide customers with a safe, secure, and
appealing environment complementary to the purchase and reload process. TTC requires the
Private Partner to choose network locations with the purpose of encouraging their use, such that
TTC customers would prefer these locations because of their added convenience, accessibility,
and security.
Page
151
TTC requires that the Private Partner submit a business plan as part of its response to this Scope
of Work that identifies its strategy, criteria, and methods of executing and supporting the Non-
TTC Retail Sales and Reload Network. The plan should include information about the Private
Partner’s marketing and customer communications plan, as well as information about the
presumed participants and number of locations in the proposed network.
9.2.3.3.2 Hours of Operation

TTC requires that all locations in the Non-TTC Retail Sales and Reload Network provide the
opportunity to purchase and reload transit accounts during all hours of their normal business
operation.
TTC requires the Private Partner to include locations in the network that are available for
purchase and reload of transit accounts during normal hours of operation of TTC’s transportation
services. These locations can include staffed retail stores that operate on a 24 hours per day, 7
day per week basis or unstaffed locations that are operate on a 24 hours per day, 7 day per week
basis.
For unstaffed locations, TTC requires the Private Partner enlist network locations that offer
customers a maximum degree of safety and security. TTC prefers locations that offer secure,
controlled access to the transaction device. Locations such as ATMs, which offer bright lighting,
surveillance by cameras, and other security features, are also preferred.
The Private Partner has the opportunity to establish additional, discretionary staffed or unstaffed
locations for sale and reload of transit accounts. These locations may be targeted to not only
satisfy TTC’s requirements, but also expand on the Private Partner’s ability to dovetail with
plans to deliver a broader range of services to TTC customers. The Private Partner has the option
to determine the hours of operation of these discretionary locations.
9.2.3.4 Equipment
TTC requires that all locations in the Non-TTC Retail Sales and Reload Network that offer
automated self-service for sales and reload of transit accounts use programs, customer interfaces
and displays, and customer marketing and, where applicable and not exclusive to the business
and operational characteristics or requirements of TTC, communication materials that are
identical to those used for FMVDs installed on TTC property.
Where existing automated, self-service equipment (such as ATMs) cannot be modified or

supplemented with additional automated equipment, TTC will only require use of identical
functionalities and on-screen messaging and interfaces. The unavailability of a cash payment
option at existing automated, self-service equipment will not disqualify the inclusion of a
particular location in the network.
Page
152
At locations where space for additional automated, self-service equipment is available, TTC will
require use of identical functionalities and on-screen messaging and interfaces. The
unavailability of a cash payment option for this equipment will not disqualify the inclusion of a
particular location in the network.
For Non-TTC Retail Sales and Reload locations with space available for additional automated,
self-service machines, the Private Partner may, with prior notice to TTC, enable other
applications and functionalities than can be run and offered to customers through the identical
FMVD physical infrastructure.
9.2.3.5 Customer Service

The Private Partner must provide the same levels of customer service at Non-TTC Retail Sales
and Reload Locations as provided through sales and reload opportunities on TTC property.
The Private Partner must provide uniform standards and customer service levels across similar
network locations. All staffed locations must be provided with and adhere to the same customer
service standards. All staffed or unstaffed locations that offer the option of self-directed,
automated sales and reloads of transit accounts must be provided with and adhere to the same
customer service standards in all aspects of the customer’s interaction with automated
equipment.
9.2.3.6 Customer Service Policies

The Private Partner will develop written Customer Service Policies that will be contractually
binding on all participants in the Non-TTC Retail Sales and Reload Network.
Customer Service policies will be developed in cooperation with TTC, the participants in the
network, and the Private Partner. All customer service policies will be developed as part of
Design Review and will be subject to TTC’s review and approval.
TTC’s purpose in this collaborative effort is to assure:
• A uniform approach to customer service across all participants in the network;
• An overall level of customer service that meets or exceeds levels of customer service
currently offered at TTC in connection with its Current System;
• A level of customer service that will enhance customers’ experience when purchasing
and reloading contactless media and devices at network locations in a manner that
supports continued use of network locations.
For staffed locations, TTC requires inclusion of the following Customer Service procedures:
• Single, In-Line Purchase and Reload. TTC requires that customers wishing to purchase
and reload TTC fare options, either by using a GPR card acquired at the Non-TTC Retail
Sales and Reload Location, or by purchasing and reloading a transit account associated
Page
153
with contactless media or devices issued by financial institutions or other entities, can do
so in the same purchase lines used for all other products and services offered at the
network location. Customers will not be required to pay in separate lines or at dedicated
locations when purchasing or reloading a transit account.
• “Single swipe, tap or insertion” Presentment. TTC prefers solutions that support
activation, sales, and reload of transit accounts through customers’ interactions that are
typical for use of payment cards in a retail environment. This includes the use of an
approved PIN-Pad if required.
• Payment Options. All participants in the network must be capable at a minimum of
accepting magnetic stripe credit; contactless and contact credit /debit; and pre-paid, GPR
reloadable cards for purchasing and reloading of transit accounts.
• Prominent Placement of GPR media. GPR contactless media must be placed
prominently within the network location, and merchandised in a manner that enables
customers to easily locate and identify it. Merchandising of GPR media will comply with
all applicable federal, state, and local laws and regulations regarding all types of payment
cards.
• Availability of Marketing and Information Materials. The Private Partner will furnish
all network locations with approved marketing and information materials. These
materials will provide information about TTC’s OSFS, including details of fare payment
options, customer service options and opportunities, and TTC’s transportation services.
Marketing and information materials will include materials with uniform messaging that
identify the location as a merchant for sales and reload of transit accounts in TTC’s
OSFS. These materials will be suitable for prominent posting and display inside the
location and for exterior viewing. The Private Partner must assure that a sufficient supply
of marketing and information materials is consistently available at all network locations.
• Merchant Familiarity with TTC Fare Products and Customer Service Options. The
Private Partner is required to assure that owners and operators of the network locations
are familiar with TTC’s OSFS, fare products, and customer service options in use of the
OSFS. TTC reserves the right to monitor and evaluate the performance of network
locations according to the standards described in this RFPQ.
9.2.3.7 Performance Measures and Monitoring

The Private Partner will implement performance measures and a performance monitoring
program for the Non-TTC Retail Sales and Reload Network.
Performance measures will at a minimum include:

• Availability of GPR stock for initial distribution and sale;
• Availability of Marketing and Information materials for customer consumption; and
Page
154
• Customer complaints registered against the network location, broken down into
complaints against the sales and reload transaction process and all others.
The Private Partner will develop and submit performance measures and its monitoring plan as
part of Design Review. TTC will have final approval over the proposed performance standards
and performance monitoring plan as part of the Design Review process.
9.2.4 Financial Settlement

All financial settlement between the Non-TTC Retail Sales and Reload Network will occur
through the transaction processing capabilities provided by the Private Partner through the
Central Processor.
TTC requires next day settlement of all funds due from the purchase of Pre-Funded TTC fare
products at network locations.
PAYG transactions will be settled with TTC according to procedures described in Section 3,
Business and Functional Requirements.
9.3 Test Lab

In order to support developing, testing, and ongoing operation of the OSFS, the Private Partner
will equip a TTC-owned site as a Test Lab.
TTC will designate the site of the Test Lab and will provide the location with power complying
with a set of minimum specifications outlined by the Private Partner to enable testing and
continuous, normal operation of OSFS end devices in the Test Lab environment.
The Private Partner will equip the Test Lab with the following types and quantities of devices
and capabilities, subject to review and approval by TTC during Design Review:
• Bus, streetcar, LRV, and Wheel-Trans Reader Assemblies, installed to simulate a typical
field implementation—Quantity of 4;
• Subway Reader Assemblies installed on TTC fare gates—Quantity of 4;
• FMVDs;
• LRV POP-related fare payment equipment;
• Computer Web Site account access;
• All open payment media that will be used, or is anticipated being used, on the TTC
OSFS;
• Access via the Internet to the Private Partner’s Central Processor for the purpose of
monitoring system performance during testing and normal operation.
Page
155
Actual quantities of equipment must be sufficient to simulate all possible operating conditions
for payment of fares and will be determined during detailed Design Review.
The Private Partner will be responsible for maintenance of all OSFS equipment in the Test Lab
for a term to be determined during the process of this procurement.
Performance requirements for field installations of OSFS equipment apply to installation of this
equipment in the Test Lab.
All equipment installed in the Test Lab will be enabled to perform all functionalities required in
the Business and Functional Requirements for the OSFS. Full implementation of the Test Lab
must be completed concurrently with the implementation of the Central Processor so that testing
of Central Processor functionality can begin at the earliest possible opportunity, as outlined in
the phased implementation plan in Section 6.
9.4 Installation Requirements
9.4.1 General Guidelines for TTC On-Site and for Legacy LRV Installations
The Private Partner is responsible for all installation of equipment for the OSFS on TTC surface
vehicles, in TTC subway stations, Legacy LRV locations, and at other designated sites as
described in this RFPQ, or as resulting from the TTC’s request to include certain transportation
services, participants, programs, or other aspects related to the functionality and purpose of the
OSFS solution and business requirements.
All on-site and all vehicle equipment installations will be executed by Private Partner resources.
TTC will provide supervised, controlled access to its facilities and equipment in a manner that
assists and fully supports the Private Partner’s efficient, effective, and timely compliance with
the requirements of this RFPQ. In addition, TTC will make available personnel with subject
matter expertise whose responsibility will be to facilitate the installation activities of the Private
Partner with additional knowledge and insight about TTC operations, equipment, infrastructure,
and other relevant subject matter as it relates to the planned implementation of the OSFS. Under
no circumstances will TTC be required to provide labour or materials resources directly needed
to execute physical, technical, testing, and other attributes of the installation process.
The Private Partner, its affiliates, its subcontractors, and any other personnel under the
supervision and control of the Private Partner will abide by all TTC requirements, rules,
procedures, and safety standards while on TTC property. Details of TTC’s requirements will be
provided during Design Review.
9.4.2 On-Site Installation Support

The Private Partner will provide the following in support of on-site installations:
• Labour and supervision;
Page
156
• Materials and tools;
• Comprehensive installation manuals, including drawings and/or pictorial representations
of equipment, components, parts; step-by-step installation procedures with detailed
specifications of tools required; and in-field testing procedures.
Installation manuals will be included in the Design Review process and subject to TTC review
and approval. All installation procedures will be subject to TTC’s Quality Assurance/Quality
Control procedures and guidelines.
Prior to installation, and in conjunction with the staging process, all equipment and components
will be “kitted” in a manner that facilitates field installation. Prior to installation, the Private
Partner will conduct “dry runs” of the kitting and installation procedures to validate the accuracy
and timeliness of the installation process.
All installations will be scheduled in advance in coordination with TTC. TTC requires that
installations occur without interruption of or interference with normal service delivery
operations. TTC will specify times available to the Private Partner for execution of installations
during Design Review. The Private Partner must perform installations at times and locations
required by TTC so as to permit normal operations to continue without interruption from Private
Partner installation activities.
TTC requires that the Private Partner conduct installation operations in a manner that shields
TTC customers and employees from physical injury, prevents damage and protects all TTC
equipment, property, and maintains access to public rights-of-way.
9.4.3 Surface Vehicle Equipment

Installation and field testing of Reader Assemblies for surface vehicles will occur at TTC bus
garages, car houses. TTC will provide facilities for staging of Reader Assemblies. Kitting of
Reader Assemblies will occur prior to arrival of equipment on-site at TTC facilities for actual
installation.
In the event that installation of a roof-top, or other antenna, may be required, the Private Partner
will be expected to work with the TTC to identify an acceptable solution. In addition, the Private
Partner must comply with all applicable safety standards and regulations if external antennas are
required.
All installations will be executed in a manner that protects Reader Assemblies, cables and
conduit, and other components integral to normal operations from unauthorized access,
vandalism, or accidental damage or abuse.
Page
157
9.4.4 In-Station Equipment
9.4.4.1 Wireless Communications

TTC requires the use of wireless telecommunications to support operation of all in-station OSFS
equipment. Power and communications required to support this wireless communication will be
determined during detailed Design Review.
9.4.4.2 Reader Assemblies for Fare Gates

Installation and field testing of Reader Assemblies for fare gates will occur at Subway stations.
The Private Partner will provide necessary vehicles and equipment to permit its contractors to
execute installation of Reader Assemblies for fare gates at station locations.
TTC will provide facilities for staging of Reader Assemblies. Kitting of Reader Assemblies will
occur prior to loading on vehicles and transporting to stations for on-site installation.
In the event that installation of an external, roof-top, or other antenna may be required, the
Private Partner will be expected to work with the TTC to identify an acceptable solution.
All installations will be executed in a manner that protects Reader Assemblies, cables and
conduit, and other components integral to normal operations from unauthorized access,
vandalism, or accidental damage or abuse.
9.4.4.3 Fare Media Vending Machines

During Design Review, TTC will work with the Private Partner to identify optimal locations for
the installation of new Fare Media Vending Machines. In station locations of these machines will
be optimized for customer convenience and use, as well locations that require little or no
physical modifications.
In many cases, optimal deployment of new machines will require strategic redeployment of
legacy TTC vending machines prior to installation of new machines.
TTC is responsible for the redeployment, removal and/or storage of all legacy fare vending
machines. The removal of existing legacy equipment will be coordinated with the installation of
new machines so that all equipment moves will occur outside of peak TTC hours of operation.
TTC will be responsible for providing access to power for the new Fare Media Vending
Machines.
As part of the process of removing TTC’s legacy vending machines, TTC will terminate power
supplies in a manner consistent with requirements for new Fare Media Vending Machine
installation. TTC will also provide an installation-ready site, which will include removal of any
hazards, flush-filing of holes, and removal of unnecessary protruding conduit and wiring.
Page
158
All installations will be executed in a manner that protects Fare Media Vending Machines, cables
and conduit, and other components integral to normal operations from unauthorized access,
vandalism, or accidental damage or abuse. The Private Partner will return the site to a clean,
orderly state, having removed all debris and remnants of site installation work prior to leaving
the installation site and moving on to the next installation location.
10 Customer Service Call Centre
10.1 Overview of Operation

The Private Partner is required to establish, staff, and operate a Customer Service Call Centre
(CSCC) to provide customer support for the OSFS for TTC. This requirement includes the
provisioning of all equipment, technology, and physical space necessary to house staff and
equipment to conduct business. It also includes proper training of professional staff to enhance
the performance of the CSCC and assure compliance with required TTC performance standards.
The CSCC will be separate and distinct from TTC’s Customer Service Centre. It is not, however,
required that the Private Partner establish a unique entity to fulfill this requirement. The Private
Partner must, however, fulfill this requirement in a manner that assures compliance with TTC’s
performance standards.
The CSCC will only address customer service issues related to the OSFS. Inquiries about TTC
transportation services and all other non-fare payment issues will be directed to the appropriate
TTC source for resolution. TTC will provide the Private Partner with information necessary to
enable the Private Partner’s CSCC to direct customers with inquiries about non-OSFS to the
appropriate TTC resources for resolution.
10.2 Concept of Operations

The purpose of the CSCC is to provide TTC customers the same customer service opportunities
afforded users of the OSFS Web Site.
The CSCC will offer the identical features and functions of the Web Site, except that the medium
for customer interaction will be phone communication. In the first instance, phone
communication will be through the use of an Interactive Voice Response (IVR) system, and then
by access to live Customer Service Phone Agents. The use of IVR technology is intended to
reduce the number of calls directed to live operators. At all times during normal business hours,
callers will have the ability to speak to a Customer Agent by Opting-Out of the IVR system.
Multi-language capabilities will be provided for all aspects of the CSCC business and system
solution, and for the operational support provided through the CSCC in a manner that reflects the
requirements and diversity of TTC’s customer base. Languages to be supported at the CSCC will
be defined by TTC during the detailed Design Review.
Page
159
Like all other aspects of the OSFS, the goal in design and implementation of the CSCC is to
incorporate state-of-the-art technology and best practices from call centres supporting merchant
operations. By requiring incorporation of this base of knowledge and consumer experience, TTC
intends to assure that the CSCC solution facilitates and encourages use of the OSFS.
10.3 Functional Requirements for the IVR System
10.3.1 IVR System Customer Support

The Private Partner will implement a state-of-the-art CSCC that relies on an IVR system to
reduce the number of calls that must be handled by live agents. The CSCC will be equipped with
an Automated Call Director (ACD) to route inbound calls to the IVR.
The IVR will be sized to accommodate at least 200% of the anticipated call volume for the
OSFS.
The IVR will be designed to address, at a minimum, the following key support functions in an
automated manner:
• Pre-Funded purchases of all available TTC regular, full-fare options;
• Reload of any Pre-Funded account, whether regular fare or concession fare account;
• Inquiries about recent account activity, whether payment activity or usage activity;
• Establishment of a password for an account;
• Acceptance credit or debit as payment, including acceptance of all information in support
of Address Verification Services and other required credit and debit card security
protocols; and
• In the case of registered accounts based on contactless devices issued by financial
institutions, the IVR will be capable of comparing account data entered into the system to
Caller ID information already collected during the registration process.
10.3.2 IVR Design Features

Like the Web Site, the CSCC’s IVR System will not be able to open accounts for customers
entitled to concession fares. For this purpose, the IVR will refer customers to live agents and
provide direction to accessing detailed instructions on becoming eligible for concession fares.
The IVR will incorporate standard techniques and menus for handling calls in an interactive,
automated environment. At a minimum, the IVR system will be capable of the following in
identifying the specific request of the caller and leading to its fulfillment:
• Single key request for repetition of a prompt;
• Access to generic or specific help from anywhere in the IVR menus;
Page
160
• Re-prompting capability in the event of no response or an erroneous response;
• A prompt to speak directly to a live agent, with any information already captured by the
IVR automatically forwarded to the live Customer Agent that will handle the call;
• The capability to skip menus, or type in the correct sequence of keyed entries at any time
in order to advance the IVR process;
• The capability to support multiple languages;
• The capability to accept voice messages after normal business hours and forward these
messages to voice-mail boxes of live Customer Agents; and
• TTY enabled.
To document IVR system speech as well as assure accuracy of all IVR system responses, the
IVR must be capable of producing printed texts of IVR speech.
10.3.3 Voice Recognition Technology

The Private Partner may incorporate Voice Recognition Technology (VRT) into the IVR system.
If utilized, the voice recognition technology must have a default capability to connect to a live
agent in the event of failed attempts to use the IVR.
10.3.4 Customer Agents

The Private Partner will employ Customer Agents to handle incoming calls from customers. The
number of Customer Agents employed will be sufficient to handle call volumes in a manner
consistent with TTC’s performance standards for the CSCC and must provide multi-language
support.
10.3.5 Training
The Private Partner will train Customer Agents about the OSFS, TTC’s fare policy and fare
payment options, and contactless media and device recognition and usage.
At a minimum, Customer Agents will be trained to be proficient in addressing:

• Inquiries about fare purchase options and pricings;
• Inquiries about PAYG and Transaction Aggregation for billing purposes;
• How to resolve payment issues versus usage issues;
• Contactless device replacement issues;
• Refund and chargeback requests;
• Reports of lost or stolen contactless devices;
• Registration of customers;
Page
161
• Enabling/disabling Autoload for Pre-Funded accounts;
• Inquiries about concession fares and procedures needed to qualify;
• Customer complaints;
• Use of the Web Site;
• Explanation of statements provided by the OSFS;
• Inquiries about the GPR product issued through Fare Media Vending Devices on TTC
property;
• Inquiries about use of Fare Media Vending Devices; and
• Payment of fares for several individuals by one individual paying under a single account.
TTC anticipates that Customer Agents will be required to refine and develop further
competencies related to customer support for the OSFS. These additional requirements will
emerge from the results of Final Design Review of the OSFS and on acceptance by TTC of the
Private Partner’s final Program Plan, as described in Section 13.
10.3.6 Call Scripts

Based on the accepted Program Plan, the Private Partner will develop and publish Call Scripts
for use by Customer Agents. Call Scripts will anticipate and document all interactive discourses
between customers and Customer Agents.
TTC requires that the Private Partner proactively revise Call Scripts in response to actual
Customer Agent experience in handling customer inquiries. To do so, TTC requires that the
Private Partner initiate and maintain a process for ongoing, independent evaluation of Customer
Agents. The evaluation process will include a formal plan for remediation and improvement that
includes further training and the opportunity for management intervention.
10.4 CSCC Performance Standards

The IVR system must be capable of a call capture rate of at least 98% and a call abandonment
rate of no more than 2%.
At the conclusion of a call, the IVR must make that line immediate available to the next caller.
Hours of operation will be 24 by 7.
During Design Review, the Private Partner must provide a detailed plan that describes how the
Private Partner will monitor and evaluate customer demand, and how demand thresholds will be
met with specific adjustments to resources available at the CSCC. TTC recognizes that decreases
in customer demand for CSCC services may also occur, and that the proposed plan from the
Private Partner for CSCC resources should also include steps to address this circumstance. The
Page
162
Private Partner’s plans for CSCC resource levels will be subject to review and approval by TTC
11 Website for New Open Fare Payment System
11.1 Overview
The Private Partner will design, build, operate, and maintain a dedicated E-commerce Web Site
for TTC’s Open Fare Payment System. The Web Site will operate independently of TTC’s web
site, but will have links that direct customers to TTC’s own web site. The Web Site must be
hosted in Canada, and must comply with all financial, security, and privacy standards as required
by applicable Canadian laws and regulations including, but not limited to PCI-DSS, MFIPPA
and PIPEDA.
The Web Site for the Open Fare Payment System will also have the capability to introduce links
to other web sites that, by mutual agreement between TTC and the Private Partner, enhance
customer service by providing access to information and services that complement customers’
overall travel experience on TTC.
TTC also requires that the Private Partner collaborate with TTC in developing Web Site creative
or customer-facing design. This collaboration includes the development of an effective and
appropriate web site that will enhance and support the Private Partner’s marketing plan.
TTC requires the Private Partner to submit Web-Site and all related marketing creative to TTC
for TTC’s review and final approval before proceeding with implementation of the Web Site. In
realization of creative materials for the Web Site, the Private Partner must adhere to TTC’s
general guidelines that are provided in Section 11.2 below, Concept of Operations.
Operation of the Web Site will proceed according to the Open Fare Payment System
implementation timeline described in Section 6.
11.2 Concept of Operations

The Web Site for the Open Fare Payment System is central to TTC’s vision for a merchant-based
approach to fare payment. TTC requires that the Web Site for the Open Fare Payment System
function as a portal for sale and reload of TTC’s fare products; for customers’ secure access to
timely, accurate information about their accounts; and for access to other useful information
presented as either integral to the Web Site, or as accessible through links to other web sites.
The Private Partner must propose a solution for the Web Site that in its outward appearance, its
familiarity and ease of use, its range of features, and its overall performance closely adheres to
customers' expectations and experience in conducting business via retail merchant’s web site.
The Web Site must be capable of operating on mobile browsers for hand-held devices and
cellular phones.
Page
163
In implementation of the Web Site, the Private Partner must develop and install technology and
features that assures comprehensive security and privacy for customers using the Web Site, as
well as compliance with all applicable requirements of AODA, W3C, WCAG 2.0, General Level
2 and Colour Level 3 and criteria used for TTC’s development of its own web site. Prior to
launch of the Web Site for revenue service, the Web Site must be certified as fully PCI-DSS
compliant.
Furthermore, the technology used must be maintainable, extensible, scalable, and allow remote
updates and adding of additional functionality.
The Private Partner will perform an independent usability and accessibility audit of the proposed
Web Site and present findings and results during Design Review.
The website must designed in such a manner to accommodate multiple transit merchants (see
appendices regarding cross-boundary, inter-regional services).
11.3 Functional Requirements
11.3.1 Key Functionalities

The Web Site will function as:
• An e-commerce site for sales and reload of all TTC fare products, including enrolment
activities for service options and fulfillment of eligibility requirements for concession
fares;
• A portal for customers to perform management activities on their account, including but
not limited to reviewing balances and transferring balances to new accounts;
• A portal for customers to access real-time information about the status of their accounts,
including detailed account histories of payments, usage, and other activities on their
transit accounts that would allow customers to perform self-directed customers service;
• A portal for customers to communicate with the Private Partner and submit e-mail
inquiries about their accounts, request resolution in the form of refunds or other action on
the part of the Private Partner, or be referred to a live agent in the event that issue
resolution requires more detailed interaction with a Customer Service Representative;
• A portal for customers to obtain general information about TTC’s OSFS, along with
FAQs, help (with search function) and contact points;
• A portal, via web links, for customers to access information about TTC’s transportation
services and other information and services;
• A Message centre for TTC and Private Partner communication with customers.
Page
164
11.3.2 Design and Customer Interfaces
The Private Partner will adhere to standard e-commerce web site design practices and
conventions. In implementing the web-site, the Private Partner will provide a secure, auditable
interface that will support all aspects of customers’ interaction with the web site. All features will
be designed in a manner that not only facilitates customer use, but builds on customers’
familiarity with e-commerce web sites and instils confidence in the security, accuracy, and
reliability of the web site.
The Web Site will feature detailed educational messaging that will walk customers through all
aspects of use and interaction with TTC’s OSFS. Messaging will include related information
about open standard contactless products, their availability and use, and as warranted by market
conditions and availability of payment products and options, additional materials and/or links to
appropriate sites that will inform and assist customers.
Whenever data entry is required of customers, the Private Partner will employ standard
conventions for keyed data entry that comply with all applicable security requirements for a
retail payment website.
Similarly, the Web Site will be enabled with buttons or on-screen tabs that support navigation
within each of the specialized Web Site pages. At a minimum, the following common buttons are
required:
• Home;
• Log-Off;
• Create Account;
• Review Account History;
• Shopping Cart;
• Print;
• Search;
• Back;
Check Out; and
• Cancel/Start Over.
The Web Site will also be equipped with a time out function. The time setting for the period of
inactivity will be a table-driven parameter. A time-out will return the customer to the Home
page.
Page
165
For all required functions, the Private Partner will provide detailed site maps that identify all
logical steps required by customers. Site maps will be subject to TTC review and approval prior
to the start of programming and web site build.
11.3.3 Payment Transaction Processing

The Web Site will be capable of processing financial transactions. As such, the Web Site must
comply with all applicable standards of the financial services and payments industries, including
but not limited to those listed in Section 2.3.1, and be capable of supporting Address Verification
and Card Validation Codes for all credit cards and of accepting PIN debit entry in a secure
manner consistent with financial industry requirements and PCI-DSS.
The Web Site, in conjunction with the Private Partner’s Central Processor, will accept at a
minimum the following payment options using contactless-enabled devices:
• American Express;
• Discover;
• INTERAC;
• MasterCard; and
• VISA
TTC recognizes that numerous alternative payment systems are available to customers who make
purchases via web sites. These alternative systems have been developed in response to customer
security concerns, as well as in recognition of the added flexibility of certain technical solutions
to be tailored to customers’ individual preferences.
TTC requires that the Private Partner’s solution for the Web Site be capable of accepting
payment from alternative payment systems. As part of Design Review, TTC requires that the
Private Partner present review options for possible acceptance of alternative payment systems.
TTC requires that all options under review conform to standards for electronic funds transfers
and open standards.
11.3.4 Multilanguage
The Web Site must support Multi-languages. In addition to English and French other languages
must be supported as determined by the TTC.
11.3.5 Configuration of Website

All Web Site pages will be easily configurable to reflect changes that affect the use of the Web
Site in the sale and reload of TTC fare products, access to and management of customer
accounts, and access to information available on the Web Site.
Page
166
The Private Partner will provide a secure technical protocol and change management procedures
to control and monitor configuration of the Web Site.
11.3.6 Database
The Private Partner will equip the Web Site with a database capable of recording and reporting
on all activity on the Web Site. This capability will include all customer-initiated activity as well
as all administrative activity initiated by the Private Partner.
The database will use SQL so that TTC has access to data and the capability to upload data to the
Data Mart.
All records will be created and stored automatically. Records created will have the purpose of
reporting on transactions and access to the web site. Additionally, records will be sufficient to
support customer inquiries about their accounts and any resolution of issues initiated by
customers through the Web Site.
The business logic for the Web Site will process all payment transactions and record all activity
through the Central Processor. The Web Site operating system will be capable of uploading new
information that affects pricing of fares, purchase options, customer information, and emergency
notifications from TTC.
11.3.7 Customer Access to Account Information

Customers will have secure access to their account information and history. Access will be
provided once the customer has established a PIN and have correctly answered a preset question
chosen by the customer for use in accessing either Pre-Funded or PAYG accounts. Customers
will not be required to identify themselves personally in order to establish a PIN, provided the
account was established using an anonymous, contactless GPR device.
For all contactless devices issued by financial institutions, the Web Site will be capable of
accepting data that would be used by the customer’s financial institution to validate the identity
of the bearer of the contactless device.
Account history data will consist of payment history at the Web Site, as well as usage history of
the account media at Points of Entry to TTC transportation services. All data will be furnished to
the customer in compliance with PCI-DSS and Canadian banking rules.
Account history data through the web site, which for tax purposes must be available for up to one
year and printable by the customer detailing all usage for the year, must at a minimum consist of
the following:
• Payment transaction date;
• Payment clearing date;
Page
167
• Last four digits of payment media;
• Fare type: Pre-Funded or PAYG;
• Pre-Funded purchase type;
• Amount of payment;
• Usage date; and
• Usage location.
Further details will be identified and specified during Design Review.
11.3.8 Sales and Reload

As described in Section 3, Business and Functional Requirements, the Open Fare Payment
System only permits one active Pre-Funded fare option per customer transit account. Under
circumstances described in Section 3, a customer’s account that has been used for a Pre-Funded
purchase, and nonetheless has sufficient funds for additional fare purchases, will automatically
default to a PAYG transaction. When this automatic default occurs, it will be clearly delineated
in the customer’s account record accessible either through the Web Site or the Customer Service
Call Centre.
The Web Site will have unique pages that support Pre-Funded sales, reload, and account
management, and PAYG account management via the Open Fare Payment System with at a
minimum the following operations:
• Home: Destination for starting e-commerce activities and providing of baseline

information about the OSFS. The page will provide: a series of steps as fill-in blank with
instructions on how to proceed.
• TTC fare options: The page will provide a descriptive menu of fare options and prices,
with appropriate interface to enable selections.
• Account creation: Pre-Funded.
• Account access: PAYG. The procedure for media issued by financial institutions will
require validation of the actual cardholder. For holders of anonymous GPR media, the
procedure will require establishment of an account password or PIN, prior to accessing
the account. No personal information that would further identify the customer will be
required by TTC, except in circumstances where it is required by law or regulation.
• Account password creation, modification, and re-establishment.
Page
168
• Forgot password;
• Account login;
• Fare option selection;
• Shopping cart contents;
• Description of payment options and how to identify contactless media accepted at TTC
Points of Entry;
• Autoload option;
• Balance protection enrolment option (only for anonymous GPR card holders);
• Selection of preferred payment method;
• Entry of security codes (i.e., Address Verification, Card Validation Codes);
• Secure checkout;
• Confirmation of purchase;
• Customer account inquiry or claim;
• Password E-mail;
• Password confirmation;
• Print / Report functionality (local printer, PDF, etc.);
• Export functionality – to Excel, text, and other common software and formats;
Additional functionality will be determined Design Review.
11.3.9 Compliance with Applicable Laws and Regulations Concerning Sale and Use of
GPR Devices
The Private Partner is responsible to comply with all applicable Laws and Regulations
concerning the sale and use of GPR devices. As part of Design Review, the Private Partner will
provide a written statement describing the GPR product that will be sold as integral to the OSFS
solution.
Page
169
11.3.10 Accepted Forms of Payment
As a unique menu selection, the Web Site will provide information about Accepted Forms of
Payment, including specific information on how to identify and/or acquire contactless devices
accepted by the TTC for fare payment. The Web Site will also offer clear instruction how to use
contactless and other open standards devices and payment alternatives accepted by the OSFS via
graphical representations and instructional text.
11.3.11 Understanding Billing Statements from My Financial Institution

As a unique menu selection, the Web Site must provide detailed information to assure that all
customers are informed about how their PAYG and Pre-Funded purchases will appear on billing
statements from their financial institutions.
11.3.12 Sales and Reload Locations

As a unique menu selection, the Web Site must provide detailed information to assure that all
customers are made aware of sale and reload locations. The Web Site will be equipped with
mapping and way-finding capability to facilitate access to sales and reload locations, as well as
use of public transportation. Other information and mapping capabilities may be offered to
customers, but only on an Opt-In basis.
11.3.13 Security, Privacy and Technology

As a unique menu selection, the Web Site will provide customers with information about
Security of Open Fare Payment System, including privacy concerns and personal security when
using payment media. Additionally, the Web Site will provide customers with a menu option that
offers information about Contactless technology and the various types of contactless devices
available to them. The OSFS solution must comply with all relevant Canadian privacy laws,
including but not limited to, MFIPPA and PIPEDA.
11.3.14 Frequently Asked Questions

The Web Site will provide customers with access to Frequently Asked Questions. The Private
Partner will be required to develop scripts that enable the customer to understand the Open Fare
Payment System and how to effectively use the Web Site.
11.3.15 Website Cookies

Customers who enable their browsers to store cookies will have the opportunity to Opt-In to
have the Web Site store information that will assist subsequent access to the Web Site. Any
information that could be used to complete a payment transaction will be excluded from the
cookie.
The Web Site is required to function when cookies are blocked by the customer.
Page
170
11.3.16 Design Features and Creative Content
TTC will work with the Private Partner with regards to specific TTC content requirements.
11.3.17 Performance Requirements

In executing the Web Site, the Private Partner will employ standard programming and design
languages. The Web Site will be capable of supporting all web browsers currently supported by
the site www.ttc.ca, and will employ open web standards to ensure the broadcast compatibility
with modern browsers and devices, while preserving compliance with AODA and applicable
privacy standards. Customers must be able to access the Web Site in all manners typically in use,
including personal computers, smart phones, and other portable devices with internet access
capabilities.
11.3.18 Website Availability

The Web Site must be capable of operation 24 hours per day continuously throughout the year.
At a minimum, TTC requires the Web Site hosting services to assure 99.99% availability, or no
more than a total of 60 minutes down time per year. TTC requires that the Private Partner
confirm response time performance through an independent monitoring service.
11.3.19 Website Response Times

The Web Site must have a response time of no less than 5 seconds during peak usage hours. TTC
requires that the Private Partner confirm response time performance through an independent
monitoring service.
11.3.20 Transaction Volumes

The Web Site must be capable of supporting 150% of TTC’s total current sales transaction
volumes for any given day without noticeable impact on transaction speed. During the term of
TTC’s contract with the Private Partner, the Private Partner will expand the capacity of the Web
Site on an as needed basis in order to meet the criteria in this section.
11.3.21 Security
The Private Partner will provide secure hosting services for the Web Site. The Web Site and
hosting service must be PCI-DSS compliant. TTC requires that the Private Partner provide proof
of PCI-DSS certification at the standard of a Level I merchant prior to launch of the Web Site.
TTC requires that the Private Partner maintain certification of full compliance with PCI-DSS
throughout the effective period of the Private Partner’s business contract with TTC.
All data processed via the Web Site, including administrative work, claims processing, and work
order processing will be encrypted in an “end-to-end” manner in compliance with anticipated
PCI-DSS requirements. Furthermore, additional security/security vulnerability tests will be
conducted.
Page
171
11.3.22 Testing
The Private Partner is responsible to execute comprehensive testing of the Web Site to assure
that it functions according to TTC’s requirements. Additionally, the Web Site must undergo
independent testing and certification of its strength against malevolent attacks and ethical hacks.
TTC regards the integrity and continuous operation of the Web Site as a mission critical
function.
11.3.23 Documentation
Documentation requirements will be provided by TTC and finalized during Design Review.
11.3.24 Use of TTC’s Logos and Trademarks

Guidelines for use of TTC’s logos and trademarks will be determined during Design Review.
11.3.25 Use of Information about TTC Operations

Use of information about TTC operations will be determined during Design Review.
12 Performance Standards
12.1 Overview
TTC regards the OSFS as a mission-critical function in its mandate to deliver safe, reliable
public transportation services. After full implementation, TTC’s customers will rely on the OSFS
as their preferred means of accessing TTC’s transportation services.
TTC also regards the Open Standard System a “gateway” service, introducing transit riders to
and providing them with a first impression of TTC, its transportation services, and its pivotal role
as a transportation service provider for residents and visitors to the Greater Toronto Area. TTC is
well aware of the customers’ interaction with the method of fare payment as an essential
precursor to each and every ride taken on surface vehicles and subway services. The customer-
friendliness, availability, reliability, accuracy, and appearance of the OSFS will play an integral
role in the public’s perception of TTC and its dedication to good customer service.
In adopting an account-based, open standards approach to fare payment modeled on a “merchant

approach” to fare payment, TTC requires a level of performance that meets or exceeds standards
for customer-friendliness, availability, reliability, accuracy, and appearance in customers’
payment experience at retail merchant locations and through emerging, market-sensitive
alternative payment means.
In formulating the following performance measures, TTC wants to assure:

• Accountability of the Private Partner, and any and all affiliates, to deliver optimal levels
of customer service, such that TTC customers who pay fares can be assured of easy,
convenient, reliable, and accurate access and use of TTC’s transportation services;
Page
172
• Full control and accountability over timely, accurate remittance of all funds and
payments due TTC from the Private Partner;
• Further encouragement of the public to use TTC’s transportation services as a first choice
for their travel needs.
In developing the performance standards set out below, TTC intends to track performance from
two perspectives. The first is the perspective of customers as they assume a role of paying fares
at a transit merchant. TTC was guided by the principle that the OSFS must operate in a manner
and level of performance typical of electronic POS payment devices at retail merchants: virtual
100% availability to accept payments from customers. Like any retail merchant, TTC wishes to
assure that customers who are able to pay, or who have appropriate credentials that entitle them
to concession fares, are able to purchase TTC’s “product,” a trip on a bus, streetcar, or a subway.
The second is from the perspective of TTC as owner and the public entity with ultimate
responsibility for the Private Partner in the delivery and operation of the OSFS. To this end, TTC
has provided examples of detailed performance measures for business and functional aspects of
the OSFS. Further examples, requirements, and SLAs will be provided during Design Review.
TTC requires that the Private Partner meet or exceed all performance standards described in this
Section of the RFPQ. This requirement applies to the performance of the Private Partner and all
affiliates throughout the duration of the agreement with TTC. It also applies to all aspects of the
OSFS solution; both as originally delivered and accepted by TTC, and over the course of the
business and operating agreement with the Private Partner as the OSFS solution undergoes
required upgrades and re-certifications by the Private Partner.
TTC and the Private Partner will use the same data and information originating from the Central
Processor and Data Mart in order to track, analyze, and report on performance. As part of Design
Review, TTC and the Private Partner will finalize all elements of the data universe that will drive
and populate all performance reporting.
TTC developed the specific performance requirements guided by the criteria described below. In
developing and implementing the OSFS, the Private Partner must follow these general criteria, as
well as enable the system solution to achieve the specific, quantitative measures in the following
sections.
• System Availability: normal sales and usage measure in terms of sales availability,
system and component failure, downtime and component uptime percentages over
periods of time, as well as in terms of component specific failures tracked as MCBFs and
MTBFs;
Page
173
• Maintainability and Operability: design of the system and all of its components that
facilitates sustaining normal operations, including initial installation and ongoing
component replacements and repairs;
• Expandability: design of the system to allow inclusion of new functionalities based on

open standards payment systems with minimal effort and investment of resources;
• Integrity and Security: capability of the system to handle events that may disrupt data
transmissions, including directed malicious attacks, and to recover lost data, reconstruct
events, eliminate corrupted or duplicate data, and minimize financial and operating risk in
response to a full range of real and potential threats;
• Open Standards: capability to permit “plug-and-play” in transferring hardware and

software to different applications and multiple products within the OSFS;
• Scalability: capability to handle increased transactional activities and operating volumes;
• Reliability: capability to operate consistently, without error, under all conditions and
situations
12.2 Sales Availability

Overall Sales Availability >98%
Overall System Reliability (over mission time of 1 year) >99.99%
Availability Lost Due to Maintenance
Preventive <0.2%
Corrective <1.2%
Availability Lost Due to Wireless Network <0.5%
Availability Lost Due to Revenue Servicing <0.1%
12.3 System Component Performance
12.3.1 Transaction Processing

Tap Acceptance Speed at all Reader Assemblies <500ms
Acceptance Read Error Rate (Card-Reader Interface) <0.01%
Tap Acceptance Processing Capacity 200% of system-wide daily ridership
Page
174
Tap Acceptance Volume 10,000 TPS (Taps Per Second).
Total Transaction Clearing/Settlement Capacity 200% of system-wide daily

clearings/settlements
Clearing Volume All transactions cleared within four

(4) hours of the end of the
transaction day.
12.3.2 Central Processor

Overall System Availability 99.99%
Consecutive Days at 100% Availability 100 days
Autoload Processing Success Rate 100% intra-day posting for

authorized transactions
Soft Decline Reposting Success Rate 100% intra-day posting for

authorized transactions
Clearing Record Capture 99.99% intra-business day; 100%

next business day
Availability of Prior Business Day Settlement By 5:00 a.m. of next business day
Usage Data Capture Accuracy 99.99% intra-business day; 100%

next business day
12.3.3 Data Mart

Overall System Availability 99.99%
Consecutive Days at 100% Availability 100 days
Reader Assembly Hotlist Refresh >99.9% Intra-day update
Reader Assembly Orphan Mode File Loss Ratio <0.0001%
Business Intelligence ETL Processing 99.99% intra-business day; 100%

next business day
Maximum Delay for Loading of Intra-Day Data 1 hour
12.3.4 Network Communications

Wireless Service Level Agreement (Latency) 90-120ms
Page
175
Wireless System Availability 99.9%
Wireless Dropped Connection Rate <2 %
12.3.5 Website
Sales Availability 100%
Overall Availability 99.99%
Response Rate <5 seconds (Keynote e-Banking

Index, or better)
Success Rate >99.5% (Keynote Credit Card Web

Transaction Index, or better)
12.3.6 Customer Call Centre

Sales Availability 99.5%
Dropped Call Rate <2%
Average Wait for Live Agent <2 minutes
IVR All Trunk Busy (ATB) 0.5%
IVR User Success Rate 99.5%
IVR Transfer-Out Success Rate 99.9%
Customer Agent ATB 98% of Available Hours
12.3.7 Equipment
Reader Assemblies MCBF/MTBF: 4 million/5years
Reader Assembly File Loss Ratio <0.0001%
Fare Gate Reader Assemblies MCBF, MTBF: 4 million/5years
In-System Fare Media Vending Devices
Sales Availability 98%
Media Dispensing MCBF/MTBF 1,000,000/40,000 hrs
Page
176
Bill Handling Unit MCBF 500,000
Cash Box MCBF/MTBF (Not applicable)
Contactless Reader MCBF/MTBF: 4 million/5years
12.3.8 Field Maintenance

Mean Time to Repair Once on Site <10 minutes
Mean Travel Time to Field Repair Site <60 minutes
Revenue Servicing Once on Site <15 minutes
Maximum Annual Hours in Degraded Mode Due to 1 hour

cash box full condition
Required performance measures will be re-visited periodically during the term of the agreement
with the Private Partner at key milestones of the lifetime of the equipment and the business
operation; estimates may be recalculated on actually measured service times.
12.3.9 Business Operations

Daily Financial Reconciliation Completion Rate 99.99% intra-business day; 100%
next business day
Daily Financial Reconciliation Accuracy 99.99% intra-business day; 100%

next business day
Availability of Current Monthly Financial Statement By fifth business day of following

month
Accuracy of Merchant Acquirer and Interchange Fee 100% Processing
Settlement (Cash in TTC DDA Account) Next day (including weekends)
Usage (“tap”) Reconciliation to Fare Gate Releases >99.9%
Usage (“tap”) Reconciliation by Fare Product >99.9%
Real-time/Store-Forward Ratio <0.05
Claims Processing
Payment Processing Claims Rate
PAYG Claims <0.2%
Page
177
Pre-Funded Claims <0.2%
Usage Claims Rate
PAYG Claims <0.1%
Pre-Funded Claims <0.1%
Resolution Processing 100% <2 business days
Financial Settlement of Claims 100% by next processing day

following claim resolution
Claim Forwarding Ratio
Denial Processing
Valid Denials: Bank Net <1%
Valid Denials: Merchant <10%
Invalid Denials <1%
Transaction Reversal Ratio
Excessive Delay Denials <0.5%
Stand-in Ratio <0.5%
Risk Management
Loss Rates <0.5%
PAYG <0.5%
Pre-Funded <0.5%
CB/Dispute Ratio 1% for 2 consecutive months.
Merchant Hot listing Effectiveness Ratio 99.999%
Orphan Mode Hotlist Effectiveness Ratio 95%
Page
178
13 System Program Management
13.1 Overview
To enable TTC to determine that the Private Partner is fulfilling requirements of the RFPQ, TTC
requires the Private Partner to provide a Program Management Plan (PMP) for the
implementation and subsequent operation of the OSFS. A preliminary PMP will be submitted as
part of the response to this RFPQ in order to demonstrate the Private Partner’s approach to
implementing and managing the OSFS project and ongoing operation. The Private Partner will
be required to submit a final detailed PMP as part of the Design Review process.
As part of its PMP, TTC requires the Private Partner to identify and implement a formal
organizational structure for the purposes of executing the PMP and reporting to TTC on progress
towards implementation of the OSFS. Each position in the organization structure will clearly
define roles and responsibilities through the life cycle of the OSFS project and the governing
agreement.
The organizational structure will be designated as the Program Management Office (PMO).
Organizationally, it will have full business responsibility for assuring the performance of the
Private Partner and all affiliated entities in the delivery of the OSFS. As such, TTC, through its
designated representatives, will deal directly with the PMO in all matters relating to the OSFS.
The PMO shall survive the full life cycle, specifically the design, implementation, and ongoing
operation for the term of TTC’s agreement with the Private Partner, of the OSFS and will
continue to serve as the overall OSFS business management office. The PMO will be organized
appropriately for each phase of the OSFS system.
13.2 PMO Team

The PMO will be headed by a Program Manager. The Private Partner will appoint a Program
Manager with suitable senior level experience in the development, design, implementation, and
operation of open standard payment systems comparable in size, scope, and complexity to the
system required by TTC. Appointment of this individual will be subject to TTC’s review and
final approval prior to the start of Design Review. Unless in TTC’s evaluation this individual’s
performance is unsatisfactory, the individual will remain as Program Manager until at least one
year after full launch of TTC’s OSFS. A review of the Program Manager’s skill sets and
expertise during the operational phase of the OSFS will be conducted.
The Program Manager will serve as the principal representative of the Private Partner. As such,
the Program Manager will have complete authority and responsibility for the day-to-day
management of the PMP. Specific responsibilities will include, but not be limited to:
• Timely achievement of all OSFS project milestones;

• Integration of design, manufacturing, installation and operation;
Page
179
• Regular reporting of progress, including the establishment of weekly, face-to-face OSFS
project status meetings during the entire implementation phase of the Project;
• Render all decisions on behalf of the Private Partner, all affiliates and business partners,
and PMO team members that will further the timely implementation and fulfillment of
all business and functional requirements for the operation of the OSFS.
TTC requires that the Program Manager have an on-site office locally in Toronto through
implementation and for at least one year after full launch of the OSFS.
TTC reserves the right to request the replacement of the Program Manager at any time during the
execution of the Project Plan. TTC’s request will be provided in writing. The Private Partner’s
replacement candidate is subject to TTC’s review and written approval.
13.3 Project Plan

TTC requires the Private Partner, through its PMO, to submit a comprehensive, detailed Project
Plan. Submission of the Project Plan will occur no later than thirty (30) days after TTC
Commission approval of the Private Partner’s proposal, or as mutually agreed. Milestones,
critical paths, resources (in particular estimate of resources required of TTC), and deliverables as
per standard project management procedures must be clearly and explicitly defined in this plan.
As part of its response to this RFPQ, TTC requires that the Private Partner submit a high-level
draft Project Plan to illustrate how the Private Partner would allocate resources and structure
progress to achieve the implementation timeline described in the RFPQ.
In addition to permitting tracking of progress towards completion of the OSFS, the Project Plan
will include:
• The organization chart for the PMO, with positions, responsibilities, names with
resumes and credentials of all individuals on the PMO team, including the naming of
an executive director from the Private Partner, a program director or manager from the
Private Partner, and functional leads (such as Project Manager(s), Test Manager(s), and
Design Engineer);
• Procedures/processes for exchanging information, documenting official
correspondence, and tracking progress;
• A Capital Program Management schedule that details the dependent of activities and
critical path task, items, and activities;
• A detailed GANTT chart listing all deliverables, milestones, certifications, tasks,
efforts, and responsible parties to the Project Plan;
• A separate document corresponding to the GANTT chart that provides detailed
descriptions of all tasks and deliverables summarized by the GANTT chart;
Page
180
• A plan for prioritized submission, review, and approval of design documents for all
equipment, processes, services, support functions such as marketing and
communication, and all other deliverables identified in the Project Plan.
• A Design Review process that clearly outline roles, responsibilities, duties, efforts, and
all other required tasks for completion of Design Review that assures compliance with
all requirements in this RFPQ;
• A Risk Management Plan that will detail processes to identify, analyze, control, and
mitigate risk. The Risk Management Plan will also describe methods for monitoring
risk and executing remedial steps in response to events.
• An Issue Resolution Process that clearly and comprehensively details how all issues are
identified, tracked, and resolved, which must include an issue/project review process;
• A proposed Request for Change (RFC) process;
• A Quality Assurance Plan that covers all aspects of the OSFS testing, piloting, and
delivery of the OSFS and all of its components in accordance with the requirements of
this RFPQ, including but not limited to performance, stress, and business continuity
testing and validation;
• A Certification Plan that will include acquisition, validation, maintenance, and delivery
of verifiable certification of compliance with all standards, rules, regulations, laws,
procedures, and other guidelines and process necessary for the delivery of the OSFS
solution in compliance with all requirements of this RFPQ, including but not limited to
EMV certification, INTERAC certification, PCI certification, and payment application
certifications;
• A Data/System Integration Plan that will include all OSFS integrations required to TTC
systems in order for the OSFS system to operate according to the requirements in this
RFPQ, including but not limited to existing STOP location indicators, Device
ID/location specifications, GPS/locations systems, and turnstile integrations.
Additionally, the Project Plan will identify any tools, software, services, and other requirements
that the Private Partner would plan to use with regards to facilitating the processes and
communications with the TTC (i.e., web portals, issue tracking software, project dashboards, use
case software, and test software).
The Project Plan submitted by the successful Private Partner will be subject to TTC’s review and
approval during Design Review and will be subject to applicable TTC design review
requirements prior to proceeding with manufacture of equipment and implementation of the
OSFS.
Page
181
13.3.1 Program Launch
As part of the Project Plan, the PMO will conduct a Program Launch Meeting. The Program
Launch Meeting will occur within ten (10) days of finalization of the Project Plan.
The purpose of the meeting will be to review:

• The overall Project Plan and schedule;
• The scope of work for the Open Fare Payment System;
• The responsibilities of the Private Partner, its affiliates (if any), and TTC;
• The terms and conditions of the Agreement between TTC and the Private Partner;
• The proposed design of the OSFS business and technical solution;
• The Private Partner’s Operating Statement.
13.3.2 Weekly Progress Meetings

The Private Partner will convene Weekly Progress Meetings. All required members of the PMO
team will attend, along with appropriate representatives from TTC and from the Private Partner’s
affiliates (if any). The PMO team will be supplemented, as necessary, with qualified technical
and administrative support to ensure that the PMO team can address all issues that arise during
Weekly Progress Meetings.
The purpose of these meetings is to identify, report on, and address as expeditiously as possible
all issues arising during the course of execution of the Project Plan. Specifically, all issues
arising from reports, inquiries, and commentary presented during the meeting will be addressed
immediately and, if possible, resolved during the meeting. Open items will be recorded on an
Action List for expeditious follow-up.
The Private Partner will prepare formal agendas for each meeting and provide minutes recording
the results of meeting activities.
Additionally, the Private Partner may also provide a real time project and issue identification
dashboard/communications link (e.g., email, text message, etc.) for TTC to further expedite
project progress, while at the same time providing real-time, transparent views of ongoing OSFS
implementation.
13.4 Project Plan Reporting and Documentation

The PMO will establish a secure on-line data room for the purpose of maintaining all
documentation and correspondence between the PMO, the Private Partner, and TTC. Only
authorized TTC and Private Partner team members will have access to the on-line data room. A
documentation and revision control system will be used throughout the execution of the entire
Project Plan for the OSFS.
Page
182
The PMO will prepare and maintain a Weekly Progress report, which will be available via the
secure on-line data room. The Weekly Progress Report will have the following elements:
• An updated Project Plan;
• An Action List for each task and deliverable identified on the Project Plan. The Action
List will identify responsible parties, track current status, and record comments about
the items identified on the list;
• A current Risk Management Plan;
• A correspondence log with subject matter and all parties identified;
• A project status dashboard highlighting current issues, milestones, tracking and other
Key Performance Indicators (KPIs) of the project.
Required contents of the Weekly Progress report will be detailed for TTC’s review and finalized
13.5 Quality Assurance Plan

TTC requires that the Private Partner develop and maintain a Quality Assurance (QA) Plan. The
purpose of the QA Plan is to assure that all aspects of the OSFS being are provided in full
compliance with the specifications in the RFPQ document.
TTC requires an IEEE 730 compliant plan that is specific to the OSFS Project. The Private
Partner must submit its QA Plan within thirty (30) days of Project Launch the QA Plan is subject
to TTC review and approval prior to its implementation. The QA team should be comprised of
members of TTC’s ITS-Quality Assurance staff, relevant TTC departmental representatives, as
well as QA/Test Analysts from the Private Partner.
Under the Quality Assurance Plan, the Private Partner will be responsible for all affiliates and
entities involved in the delivery of the OSFS.
All aspects of the Private Partner’s QA Plan will be subject to TTC’s review and approval during
Design Review.
Roles and responsibilities of the TTC and Private Partner with regards to the QA Plan shall be
determined during Design Review.
13.5.1 Plan Requirements

At a minimum, the QA Plan will contain the following:
• An organization chart with reporting responsibilities;
• A statement of responsibilities of all QA personnel;
Page
183
• A description of methods, procedures, forms, and activities used in assurance of
compliance with OSFS specifications and requirements as stated in the RFPQ;
• Specific procedures to address manufacture, inspection, and testing of equipment;
certification and configuration of equipment for deployment in field locations;
documentation and testing of remedial actions; software and hardware updates; follow-
through on modifications arising from actions required during Weekly Status Meetings;
documentation of changes to hardware and software; and oversight of activities by all
parties regarding the installation and testing of OSFS components, whether on-site at
TTC or at other locations integral to the system;
• Procedures for providing TTC and the Private Partner with written reports that document
all QA activities.
Included in the responsibilities of the QA team are:
• All aspects of fabrication and installation of equipment;
• Inspection of equipment prior to acceptance for installation;
• Inventory and staging of equipment;
• Documentation of events;
• Compliance with specifications in the RFPQ;
• Final inspection of hardware and software;
• Safety of all Private Partner personnel engaged in the delivery of the OSFS.
TTC requires reporting of status of activities executed under the QA Plan. Certified QA Reports,
including but not limited to project QA issues and test plan execution, will be presented at the
time of the Weekly Status Meeting.
TTC reserves the right to conduct an independent inspection of all hardware, software, and other
equipment that is delivered for installation and use on TTC property. For the non-financial
aspects of the plan, TTC’s ITS-Quality Assurance staff will have monitoring and approval
responsibility. TTC’s performance of independent QA activities will not modify the Private
Partner’s responsibilities under the RFPQ.
TTC reserves the right, with adequate advance notice to the Private Partner, to have access to the
facilities of the Private Partner for the purpose of QA review. This right includes the authority to
perform QA activities for hardware and software during the manufacturing process, to inspect
documentation and records of plans and procedures, and to review other documents pertinent to
the delivery of the required hardware and software for the OSFS.
Page
184
Finally, TTC reserves the right to be intimately involved in all testing and Quality Assurance
directly related to TTC’s transit operations, other transit operations being served by the OSFS,
fare pricing and policies, customer interactions and communications, and OSFS system piloting.
13.5.2 Quality Assurance Supervisor

The Private Partner will designate an individual as Quality Assurance Supervisor (QAS) for the
OSFS Project. The QAS will have demonstrated experience in managing QA programs that are
comparable in size and complexity to the OSFS Project. Preference to individuals with financial
payment experience will be given.
TTC requires that the QAS remain available in the TTC service area during the entire
implementation phase of the Project. The QAS will be the contact point for all QA matters, will
represent the Private Partner in audit and review activities, and will be the sole responsible party
on behalf of the Private Partner for determination of compliance with specifications and
requirements stated in the RFPQ.
13.6 Design Review Process

TTC requires the Private Partner to incorporate a formal Design Review Process into the
Program Management Plan. The Design Review Process will consist of three steps: Conceptual
Design Review (CDR), Preliminary Design Review (PDR), and Final Design Review (FDR).
As part of the Design Review Process, the Private Partner will establish procedures for control of
information and expeditious transmittal, review, and approval of Design Review materials in
accord with the Program Project Plan. TTC requires that all processes and procedures for Design
Review for all steps outlined above be submitted for review and approval as part of the overall
Program Management Plan.
The Private Partner will be required to submit documents, drawings, and data as need to support
each step of Design Review. The Private Partner will provide full and complete drawings in
English that include information to communicate all details of the concept, design, and physical
characteristics of the item submitted for review. As needed, the drawings will conform to TTC
CADD standards and will be accompanied by documentation that describes the installation,
operation, maintenance, and all other features that are required for TTC’s evaluation of the item
under review.
During the Design Review Process, the Private Partner will assure the on-site availability of the
originators of the documents and drawings submitted for Design Review. As a consequence of
the Design Review Process, TTC may request additional documentation and drawings, as well as
other tangible support (such as prototypes or samples of parts, components, etc.) to support the
Design Review.
Page
185
13.6.1 Conceptual Design Review (CDR) Process
The purpose of Conceptual Design Review (CDR) is for the presentation of the Private Partner’s
plan for fulfilling the business, technical, and operational requirements stated in the RFPQ. This
outline of the Private Partner’s concept will also serve to:
• Identify additional information required by either TTC or the Private Partner;
• Review the OSFS in sufficient detail to preview potential issues or possible modifications
that could materially benefit the outcome of the Project;
• Inform both parties of new technical opportunities not anticipated in the RFPQ, but which
are noteworthy of consideration;
• Address impacts of the conceptual design on administrative and procedural aspects of the
Agreement between the Private Partner and TTC;
• Relate TTC business, technical, and operational requirements directly to the Private
Partner’s design.
The Private Partner will prepare and submit all documentation for TTC’s review and approval no
less than five (5) business days in advance of CDR meetings. TTC will provide the Private
Partner with a response to the CDR submission no later than thirty (30) business days after the
in-person CDR Meeting. The Private Partner may not proceed to Preliminary Design Review
(PDR) until TTC’s approval of CDR. TTC reserves the right to provide reviewed design
documentation to the Private Partner incrementally as the documentation becomes available in
order to speed up the Design Review process.
13.6.2 Preliminary Design Review

For Preliminary Design Review (PDR), TTC requires the Private Partner to submit detailed
drawings and documentation of all items presented in CDR as well as additional materials that
permit TTC to conduct a thorough technical and functional evaluation of the proposed solution.
TTC will provide the Private Partner with specific instructions on aspects of CDR that require
extensive detail and documentation for the PDR phase.
During PDR, the Private Partner will present details of its installation plan for all hardware and
software required for the Open Standard Payment System. Details will include a staging plan and
an on-site inventory management plan; all aspects of and steps in the physical installation
process; Testing Methodology/Master Test Plan and special requirements and contingencies;
timeline and staffing proposals; proposed schedules for access to TTC facilities; and all support
requested of TTC. The installation plan will also identify all PMO team members performing
installations, along with supervisory personnel that will be in-charge while installations are in
progress.
Page
186
TTC must approve the installation plan prior to start of equipment installation or the staging of
equipment at TTC facilities.
All PDR documentation and drawings must be submitted to TTC for review no less than thirty
(30) days prior to the start of PDR Meetings.
Approval of all PDR documents and drawings is required prior to proceeding to Final Design
Review (FDR).
13.6.3 Final Design Review

Final Design Review (FDR) will occur at a time when TTC determines that the Private Partner’s
design is fundamentally completed. FDR will provide an opportunity for both parties to conduct
a detailed review of the Private Partner’s understanding of TTC’s operations, its customers, the
business and technical requirements such that there is full understanding and agreement over all
details of the OSFS prior to start of equipment manufacturing and systems programming. The
Private Partner must submit all FDR documentation and drawings no later than forty-five (45)
days prior to the start of in-person FDR Meetings.
The Design Review Process will be closed out upon TTC’s written acknowledgment that all
issues regarding the design of all elements of the OSFS have been resolved.
13.6.4 Project Closeout/OSFS Operational Phase

At the conclusion of the implementation and testing, and subsequent commissioning of the
OSFS, a project closeout phase will be conducted. The Project Closeout Phase will include at a
minimum a final project review, a final security compliance and certification review, a lessons
learned review, and a final project closeout report. Additionally, any and all further information,
processes, procedures, licenses, documentation, and data required for the operation of the OSFS,
as it affects TTC will be issued at this stage of the OSFS project.
TTC reserves the right to use independent third parties for all reviews in the Project Closeout
Phase. Furthermore, TTC reserve the right to audit the Private Partner during the operational
phase to ensure certification and compliance with, for example but not limited to, such standards
as PCI and any and all rules, regulations, procedures, and standards of the financial services and
14 Testing Methodology/Master Test Plan
14.1 Overview
TTC requires that the Private Partner develop and execute a comprehensive Test Protocol for the
OSFS. In executing the Test Protocol, the Private Partner in consultation with and, where
appropriate, with guidance from the TTC, will formulate all plans; test case/scripts; provide
written procedures that describe all test activities, methodologies, and measurements of success;
Page
187
provide all necessary equipment and personnel resources; and document and report on all test
results.
Under direct supervision by TTC, the Private Partner will execute the Test Protocol to ensure
that all systems, equipment, firmware, software, and other OSFS business and functional
components meet the requirements stated in this RFPQ as well as all required certifications. The
Private Partner is responsible for all phases of the Test Protocol, including the integration of the
Test Protocol with the Project Plan.
The development of the Test Protocol will be integrated with Design Review. TTC will not
proceed into other phases of the Project Plan without satisfactory completion of Design Review.
TTC reserves the right to require the Private Partner to perform testing in addition to that
described in the Testing Methodology/Master Test Plan. TTC may, at its discretion at any time
during the Project Plan and after official launch of the system, conduct its own testing.
TTC has the right to review and approve the Test Methodology/Master Test Plan developed by
14.2 Test Plan

There will be master and subsidiary test plans that will be developed by the Private Partner and
approved by the TTC during Preliminary Design Review phase. Additionally, TTC will create
its own User Acceptance Test plan during Preliminary Design Review phase and executed upon
final acceptance.
The written Test Plan will be developed and approved by TTC as part of Design Review. The
Test Plan will validate that the OSFS:
• Meets all functional, business and operating requirements described in this RFPQ;
• Is fully operational and ready for revenue service at the time of launch;
• Meets all safety and environmental standards;
• Any new functional, business, and operational requirements arising out of Design
Review;
• Any standards not mentioned in the RFPQ that the TTC deems necessary for design,
implementation, and maintenance of the OSFS;
• Meets all certifications, financial or otherwise.
The Test Plan will be structured as a series of steps consisting, at a minimum, of the following:
Page
188
• First Article Inspection Testing (FAIT): a live test using hardware and software that
verifies that the Private Partner has met all business and functional requirements of this
RFPQ. Successful completion of FAIT is required prior to start of equipment
manufacture. The Private Partner will conduct the FAIT; test results will be subject to
review and approval by TTC.
• Production Acceptance Testing (PAT): prior to shipment for inventory and staging prior
to installation, a test of all manufactured equipment to verify that equipment complies
with all functional and configuration requirements in this RFPQ. TTC will require
compliance certificates or certified test results from vendors and Original Equipment
Manufacturers (OEMs) for all their equipment. The Private Partner will execute test cases
to validate functionality that is not covered by the compliance certificate or certified test
results.
• Operating Acceptance Testing (OAT): a live test in the Test Lab established by the
Private Partner of all hardware, software, and all contactless media and devices to be
accepted when the Open Standards System is in revenue service. At OAT the Private
Partner, in cooperation with and oversight by TTC, will perform the first round of Use
Case tests as a means of verifying that all business and functional requirements in this
RFPQ are met.
• Pre-Launch Friendly User Testing (FUT): a live test of Use Cases of the OSFS performed
using equipment installed in the field on TTC property and at Non-TTC Retail Sales and
Reload Network Locations. The FUT will be conducted in conjunction with the phased
implementation of the OSFS described in the overall Project Plan. Any testing required
by financial institutions, partners, or other entities involved with the OSFS will be
conducted at this point, which will include at a minimum user acceptance testing (UAT).
Approvals and certification of the OSFS system by such institutions will be required by
such institutions, partners, or other entities, which must be identified in advance by the
Private Partner, before any TTC approvals can be granted.
Subsequent to Design Review, the Private Partner may revise and update the Test Plan, subject
to TTC review and approval. TTC will consider post-Design Review revisions to the Test Plan if
the Private Partner supplies written documentation and supporting information that is satisfactory
to TTC to indicate that a revision or waiver to the approved Test Plan is warranted.
14.2.1 Test Plan Scope

The written Test Plan will at a minimum include the following elements:
• Written Test Procedures organized in distinct phases and steps that are consistent with the
approved overall Project Plan, and that encompass all OSFS components, services
provided across all aspects of the OSFS solution and all elements of TTC’s transportation
Page
189
services, and business and customer service functionalities during all phases of
implementation;
• Personnel resources required for execution of the Test Plan;
• A Test Failure Reporting and Remediation Plan that is integral to the Private Partner’s
Quality Assurance/Quality Control Plan.
In addition, the Test Plan will specifically address the following systems, components, and
functionalities:
• Wireless network operations and connectivity across all TTC subway stations and for all
surface vehicle stops where OSFS equipment will be in revenue service. This testing will
include extensive performance and stress testing designed to meet and exceed real-world
conditions, for example: all turnstiles being used to full capacity while fifty percent
(50%) or more are using their cell phones.
• All field equipment installed on TTC property for:
o Certification as compliance with all financial services, payment industry, and card
association standards (for example, INTERAC);
o EMV compliance (i.e., contactless EMV for card reader assemblies, contactless
and contact magnetic stripe for FMVDs);
o PCI-DSS certification (including PCI-PED for FMVDs);
o Canadian contactless bank card coverage (at time of rollout);
o NFC compliance;
o Environmental tests as required by TTC, CSA, and CRTC;
o Maintainability tests across all installation locations and vehicle type installations;
o Interoperability of OSFS equipment, functional components (i.e., web site,
Customer Call Centre, merchant acquisition, Central Processor, and all
interfaces), networks interfaces, and software applications;
o Regression testing to ensure that the OSFS can meet performance requirements at
maximum operating loads and stresses across all installation locations and
required operating conditions;
o Connectivity tests;
o Performance and stress testing;
o Remote update/upgrade testing;
o Key management and security tests.
Page
190
• All back office functions, including but not limited to execution of all processes, data
transfers, reporting, financial reconciliation and management, auditing, and monitoring of
transactions, as well as monitoring and reporting on system-wide operations.
The Test Plan will include provision for TTC design staff to review drawing containing details
and locations of all eternal, roof-top, or other antenna or equipment required for the installation
of the OSFS solution.
TTC will identify further tests during Design Review.
14.2.2 PCI Compliance Certification

Because the OSFS will accept credit and debit cards, the OSFS will be certified as PCI-DSS and
INTERAC compliant. The Private Partner will acquire certification for PCI-DSS and INTERAC
to the level and version required at the time that the OSFS system goes live.
During the term of its Agreement with TTC, the Private Partner will take necessary steps to
assure continuous PCI-DSS certification of all equipment and services provided under the terms
of the Agreement with TTC. TTC will cooperate with the Private Partner to ensure access to its
facilities and personnel in the execution of PCI-DSS compliance audits and remedial actions. In
the event of a security breach, the Private Partner will be responsible to execute all remedial
actions to the OSFS and restore full PCI-DSS certification.
In addition to furnishing PCI compliant hardware and software, the Private Partner will engage a
Qualified Security Assessor (QSA) as proscribed by PCI-DSS for the purpose of an independent
certification of compliance. The Private Partner will integrate requirements of the PCI-DSS
compliance into the Design Review process.
Furthermore, all other required certifications will be maintained by the Private Partner. In the
event that new financial certifications are required for systems, components, devices, and other
elements of the OSFS and these cannot be “grandfathered” into the current OSFS solution, the
Private Partner must, at their expense and effort, upgrade, replace, modify, and recertify all
affected components of the OSFS.
14.2.3 Scope of Friendly User Test

The Friendly User Test (FUT) is designed as a live, in-service test of the entire OSFS. All
equipment, support services, hardware, software, and business components of the Open Standard
System will be active and in full revenue service for the FUT. Additionally, the Private Partner
will need to work with any and all financial institutions, acquirers, and other entities to ensure
that the FUT qualifies as a financial pilot of the OSFS.
TTC requires that the Private Partner conduct the FUT with a select, limited number of
participants using actual contactless media and devices to pay TTC transit fares using all transit
Page
191
fares and all transit modes. Ideally, the contactless media used by the “test participants’ will
accurately reflect the market composition of the City of Toronto, the Greater Toronto Area, and
the potential visitors to the Greater Toronto Area. The market composition would include
MasterCard, American Express, VIA, GPR cards, and INTERAC contactless debit (if available
at the time) issued from a wide variety of banks and card issuers. Both magnetic stripe,
contactless, and contactless EMV bank cards will be trialed.
The duration of the FUT will be a minimum of eight (8) weeks, or as required either by the
outcome of the FUT, by the financial services and payment industries entities involved in the
OSFS project, or by TTC, after completion of all other testing required by the Test Plan. During
the course of FUT, TTC requires that participating Testers perform a combined minimum of
25,000 acceptance transactions on TTC buses, streetcars, and at Fare Gates in TTC Subway and
Subway stations. Additionally, TTC requires that Testers perform a minimum of 1,000 payment
transactions at each of the following sales and reload sites:
• Web Site;
• Customer Service Call Centre;
• Non-TTC Retail Sales and Reload Locations.
Any additional requirements for testing as required for certifications by the financial services and
payments industries, or entities or partners in the OSFS project will be conducted as this time.
The FUT will be conducted in two phases. The First Phase will last a minimum of four (4)
weeks, or until satisfactory completion of testing. Participants in Phase I will consist of a team of
Testers comprised of Private Partner personnel and TTC personnel.
TTC requires that the Private Partner develop a comprehensive series of use cases. The use cases
will consist of detailed steps or scripts that will test all possible scenarios, including exceptions
and alternatives, for interaction with the OSFS by end users. The use cases will provide test
scripts to address all fare payment options and policies, functionalities, processes and
performance criteria required by the RFPQ.
Use cases will be developed and approved by TTC during Design Review. Use cases will be
subject to revision as required by TTC at TTC’s sole discretion or as a result of actions taken by
the Private Partner in the completion of the Program Plan.
The use cases will be constructed for the following end user populations:
• Customers who will use the OSFS to purchase TTC fares and ride TTC transportation
services;
• TTC and Private Partner employees responsible for operation, management, and
oversight of the OSFS;
Page
192
• Business partners, affiliates, and merchant participants in the Non-TTC Retail Sales and
Reload Network.
Phase II of FUT will begin after successful completion of Phase I and completion of installation
of OSFS equipment system-wide and at all participating Non-TTC Retail Sales and Reload
Locations.
Phase II will last for a minimum of four (4) consecutive weeks. During this period, with prior
consent of TTC, the Private Partner will activate use the OSFS by a larger, but select population
of Friendly Users.
The purpose of Phase II will be to increase the volume of sales and use transactions to achieve
the minimum levels, to stress test the OSFS for reliability, availability, maintainability, and
accuracy, and to evaluate and fine tune the performance of all maintenance, revenue servicing,
and customer support operations.
The Private Partner will provide daily and weekly reports on the performance of the OSFS
during Phase II of FUT. TTC requires in-person, weekly review of reports and evaluation of test
results.
During Phase II, all operating malfunctions will be logged (tracked) and included in weekly
reports. TTC defines an operating malfunction as an event that results in system or equipment
inoperability or failure to perform all required functions described in this RFPQ, subsequent
Design Review, or required by procedures, protocols, and regulations for processing of
electronic funds transfers and payments. Typically an operating malfunction would require
maintenance in order to restore the system or equipment to normal operation.
All operating malfunctions will be analyzed for root causes. Results of analysis will be logged in
weekly reports. Root Cause Analysis will include a description of remedial steps and a timeline
for testing and completion of remedial actions.
Any additional tests required by the Private Partner, its affiliates, participants in the OSFS
program, and financial services and payments industry standards will be conducted during the
FUT and reported on. Only when all parties have been satisfied as to the functionality, reliability
and performance of the tests will the system move to the next step.
14.3 Performance Measures

As a condition of TTC’s final acceptance of the OSFS, all Performance Criteria described in
Section 12 of this RFPQ must be met during FUT.
14.4 Evaluation of Test Results

All Test Results will be evaluated on a Pass or Fail basis according to the Performance Measures
in Section 12 or this RFPQ.
Page
193
Failures in testing will be categorized as either Chargeable or Non-Chargeable. The Private
Partner will be responsible for remediation of all chargeable failures prior to TTC’s acceptance
of the OSFS for revenue service.
14.4.1 Chargeable Failures

Typically, Chargeable Failures relate to, but are not limited to the following: equipment design;
equipment manufacture; equipment quality; quality of component parts; software errors;
installation errors; and failures in Private Partner installations, operating maintenance, and repair
procedures. Chargeable failures and guidelines for determining them will be defined during
Design Review.
14.4.2 Non-Chargeable Failures

Typically, Non-chargeable Failures comprise, but are not limited to: mishandling or accidents;
failure of test facilities and test instruments; equipment failures under conditions beyond those
stated in the RFPQ specifications; failure of expendable items; and failures due to incorrect
execution of operating procedures. Non-Chargeable Failures and guidelines for determining
them will be defined during Design Review.
Page
194
Appendix A: Overview of TTC’s Current Fare Collection System
(see www.ttc.ca for more information)
This Appendix is an excerpt from a report prepared for TTC by Parsons in May 2007. The complete
Parsons report documents the results of a collaborative effort among members of the TTC Smartcard
Project Team, external consulting teams, and functional area and executive staff to define a possible
smartcard fare collection system for the TTC and to evaluate the potential benefits and costs it could
deliver. The smartcard fare collection study for the TTC was spurred not only by business interests
regarding the technology’s potential, but also by the Greater Toronto Area Fare System (GTAFS) The
specific chapter presented here, Section 6, updates the October 2000 TTC Fare Collection Study’s
overview and appraisal of the TTC’s existing fare collection system. The appraisal focuses on the
existing system in relation to customer and employee experience, revenue and ridership accountability,
business strategy, fiscal impacts, and regional integration.
The purpose of including this information is to provide the Private Partner with an overview of TTC’s
Current Fare Collection System. Whenever possible, and as specified, information in the original report
has been updated to reflect current conditions. Generally, in terms of fare products, policies, and
procedures, there have been no notable changes since the submission of the Parsons report in May 2007.
The full text of the report is available to prospective bidders on request. However, except for the portions
of the original report excerpted here, users of the original Parsons report from May 2007 are cautioned not
to assume that other portions of the complete report apply to TTC’s request for an Open Standard Fare
System solution as described in this RFPQ.
Note that TTC has developed new fare policies regarding Proof-of-Payment on Legacy LRVs. Please
refer to the Appendices for additional information.
For the sake of convenience in referencing the original Parsons May 2007 Report, original Section
numberings have been kept intact. The excerpt in this Appendix begins with Section 6.1 and concludes
with Section 6.4.
CUSTOMER AND EMPLOYEE EXPERIENCE

This section presents a review and appraisal of the TTC fare and transfer strategies, fare media
distribution and sales, and fare payment and enforcement.
Fare and Transfer Strategies
The TTC’s fare strategy is categorized as flat vs. differentiating. This means the TTC fares are not
differentiated by distance, time of day or mode, but are a fixed price. The advantages to a flat fare
strategy are primarily simplicity and ease of use for customers as well as ease of administration,
monitoring and enforcement for the TTC.
The fare collection system is built with a mix of automated, mechanical and manual collection and
inspection systems and processes. As a result, there is a mix of fare media. In addition to paying with
cash, other payment options include pre-paid fare products. Exhibit 6.1-1, TTC Fare Media and Prices,
lists the current TTC fare types and prices and Table 6.1-2, 2009 Ridership by Fare Type, summarizes the
2009 ridership by fare type.
Page
195
Exhibit 6.1-1: 2010 TTC Fare Media and Prices
Table 6.1-2: 2009 Ridership by Fare Type
PERCENT
FARE TYPE
2009 RIDERSHIP
Tickets
10.0%
(Senior, Student and Children)
Token
26.2%
(Adult)
Monthly Metropasses
47.5%
(Adult, Senior, Student and Children)
Weekly Pass
2.1%
Cash
10.5%
Day Pass 2.3%
Other
1.4%
(GTA Pass, Annual/Premium Passes)
Tickets and Tokens, good for one trip (includes transfer), may be purchased in sets of five or ten. The sets
of five and ten are sold at the base price. Tickets are printed paper for visual inspection by Station
Collectors and Surface Vehicle Operators and tokens are custom-designed metal for dropping in and
activating a Subway turnstile or dropping into Subway or Surface Vehicle fareboxes.
Monthly passes, good for unlimited travel on all regular TTC services for a calendar month, are available
for purchase at Adult, Senior and Student prices. Metropasses are now transferable, but any Student or
Senior presenting a Student or Senior Metropass must show a qualified photo ID, if requested. The
Page
196
passes have magnetic strips with encoded pass information and may be swiped at a magnetic card reader
at any equipped turnstile or parking gate to allow entry. They may also be “flashed” at a Station Collector
or Surface Vehicle Operator for visual validation.
Weekly passes, good for unlimited travel on all regular TTC services for a calendar week, are available
for purchase at Adult, Senior and Student prices. Like the monthly pass, they, too, have magnetic strips
with encoded pass information and may be swiped at a magnetic card reader at any equipped turnstile.
They may also be “flashed” at a Station Collector or Surface Vehicle Operator for visual validation.
Day/Family passes are good for unlimited travel on regular TTC services from start of service through
5:30 AM the next day on any day. On Saturdays, Sundays or statutory holidays, the pass allows up to six
people to travel on just one pass (maximum 2 adults). Day/Family passes are printed on card stock with
scratch off month/day. They are visually validated by Station Collectors and Surface Vehicle Operators.
Transferring from mode to mode is free for a one-way, continuous trip. Paper transfers
from Subway to Surface Vehicles are taken from Transfer Issuing Machines which are
generally located within a few metres of the Subway entry turnstiles. The customer
merely pushes a button and a transfer is date/time stamped and issued. Transfers from a
Surface Vehicle to the Subway or to another Surface Vehicle are time-punched paper
transfers issued by the Surface Vehicle Operator. Both types of transfers require visual
validation by the Station Collector and/or Surface Vehicle Operator. Customers transferring at subway
and Rapid Transit Trains (RT) stations with integrated surface route terminals do not require a paper
transfer.
Fare Media Distribution and Sales
Fare products are distributed to and sold by Station Collectors, 3rd Party Ticket Agents, via Token and
Pass Vending Machines and through the Metropass Discount Plan and through the Volume Incentive
Program.
Station Collectors sell fare media inside most Subway entrances through
“Collector Booths”, located adjacent to entry turnstiles. Although the
Collector booths are alarmed and secure, there are risks associated with having
employees handle cash. In addition, Station Collectors, while present in the
staffed entrances, their ability to provide expanded customer assistance is
constrained because they need to remain inside the booth selling and inspecting
fares.
Token Vending Machines are located at most unattended entrances and dispense two, five or ten tokens.
The machines are also located in higher volume stations to reduce queuing at the Station Collector’s
booth during peak periods of the day. The machines accept cash payment only – no credit/debit cards. In
2010, there are 107 Token Vending Machines in the TTC Subway system. Revenues are collected and
tokens and change replenished on a regular basis.
Pass Vending Machines are located at select stations. These machines dispense monthly and weekly
Metropasses and accept only debit card payment. In 2010, the TTC is in the process of installing 40 Pass
Vending Machines in the TTC Subway system. Monthly and weekly Metropasses, tied to a fixed
calendar period, are replaced with new passes near the end of each validity period.
3rd Party Ticket Agents are external to the TTC. In 2010, there are approximately 1,200 3rd Party Ticket
Agents located throughout the City of Toronto. Ticket Agents can order fare media at any time, but there
Page
197
are minimum order quantities and monthly sales quotas. Typically, supplies of fare media are paid for
upon delivery, but, in some cases, agents are issued credit. Ticket agents not only benefit from the foot
traffic generated by the sales of TTC fare media, but also receive a 1 percent commission on sales. In
order to keep inventories of weekly and monthly passes current, deliveries to Ticket Agents are ongoing.
These deliveries are labour intensive.
Metropass Discount Plan is a program that allows the TTC customers to enroll in a
12 month pass purchase program. The incentives to do so include an 8 percent
discount on the cost of each month’s pass. Monthly passes are delivered, by mail,
to each enrollee by the Metropass manufacturer. Customers not only enjoy
considerable savings, but also the added convenience of receiving their next
month’s pass by mail.
Volume Incentive Pass (VIP) Program: The VIP program is similar to the Metropass Discount Plan with
some additional features and flexibility to better meet the needs of corporations and institutions. The
program provides a price discount to corporations and institutions based on a commitment to purchase a
minimum monthly volume of passes for a one-year period. The TTC delivers the passes to the
organization and collects the fees. The organization then distributes the passes to their employees and/or
students.
Table 6.1-3, Fare Media Sales by Sales Channel, summarizes the TTC’s 2008 revenue by each sales
channel.
Table 6.1-3: Fare Media by Sales Channel
PERCENT
SALES CHANNEL
2008 REVENUE
Station Collectors 50%
3rd Party Ticket Agents 33%
Vending Machines 10%
Metropass Discount Plan 7%
Fare Payment
Fares are paid or validated upon entering the Subway system or upon boarding a Surface Vehicle.
There are three points of fare payment or validation in the Subway system:
• Mechanical turnstiles (for dropping tokens or swiping Metropasses) or
• Station Collector (for visual validation of Metropass, Day/Family Passes, transfers and Photo IDs
of concession products) or
• Farebox at the Station Collector’s booth (for dropping cash, tickets, tokens).
Note: As mentioned previously, transfers are obtained through a Transfer Issuing Machine located
just beyond the point of entry.
On the TTC buses, there are two points of fare payment or validation:
Page
198
• Farebox (for dropping cash, tickets and tokens) or
• Operator (for visual validation of Metropasses, transfers and issuance of a transfer)
On the TTC streetcar, if a customer enters the front door, there are three possible points of fare payment
or validation:
• Farebox (for dropping cash, tickets and tokens), or
• Operator (for visual inspection of Metropasses, transfers and issuance of Proof of
Payment/Transfer) and,
• If customer is requested to present proof-of-payment by a Special Constable
If a customer enters through the rear door of a Streetcar, there is no point of fare payment and one
possible point of fare validation -- by a Special Constable, if requested. For further information about
Proof-of-Payment (POP) fare payment, see the Appendices.
Fare Enforcement
As described in the previous section, the fare collection system is built with a mix of automated,
mechanical and manual collection and inspection systems and processes. Fare enforcement is also
function of this mix.
• Fare enforcement for magnetic media is automated at the Subway turnstile. If a Metropass is not
valid and a customer attempts to swipe it at the magnetic reader on the turnstile, the turnstile will
not activate. Fare enforcement of magnetic media on a Surface Vehicle or at a Station Collector’s
booth is by visual inspection. If the media looks unusual or if printed dates are not valid, the
customer will be stopped and required to pay the fare or, in some cases cited.
• Fare enforcement for tokens at the Subway turnstile is mechanical. If something other than a
TTC token is dropped into the turnstile’s slot, the turnstile will not activate. At the Surface
Vehicle farebox, enforcement is by visual inspection once dropped in the farebox.
• Fare enforcement for printed fare media requires visual inspection in both the Subway and on
board a Surface Vehicle. If the media looks unusual or if printed/scratched off dates/times are not
valid, the customer will be stopped by the Station Collector or Surface Vehicle Operator or
Special Constable and required to pay the fare or, in some cases cited.
The TTC’s Internal Audit Department, with the assistance of Transit Special Constables, conducts a fare
evasion study annually. Tests are conducted throughout the system and fare evasion rates are currently
estimated to be 1.6% of total revenues. The following describes the focus of the audits:
• Proof of Payment: The team records the total number of customers on the Streetcar, and the
number of customers with invalid fare media. The process for doing this is to direct the Operator
to announce a fare inspection. The auditors record the number of customers perceived to be
evading a fare by counting the number of people who exit the Streetcar immediately after the
announcement is made.
• Illegal Entry: Plain clothes auditors observe and count the number of people entering the Subway
station via driveways used by Surface vehicles. This number is reflected as a percentage of all
paying customers using those same stations.
• Transfers: Surface transfers, given to Station Collectors, are checked for proper time, date and
validity for connecting routes.
• Metropasses: Checked for forgeries.
Page
199
• Foreign and Fraudulent Receipts: Farebox revenues are sampled for counterfeit tickets, tokens,
bills and foreign coins and slugs.
It is important to note that printed fare media (tickets and Metropasses) can be duplicated for illegal
distribution, metal tokens can be forged (and, in fact, have). TTC recently discontinued adult tickets to
addressing counterfeiting concerns. Additionally, TTC recently introduced/issued an up-graded bi-metal
token to address this issue. In addition, unless a customer is spotted by an employee, the TTC fare
collection system has no means to control passes that are passed back to friends who then use them a
second time to flash at the Station Collector for entry.
Several transfers can be taken from the Transfer Issuing Machine by any individual and doled out to non-
paying individuals. In addition, directional transfers are difficult to understand and explain and time of
validity is not always clear. This situation causes a high number of transfer disputes which, according to
the TTC’s Operator Assault Task Force’s 2005 Report of Findings, is one of the leading causes of
assaults on Operators.
REVENUE AND RIDERSHIP ACCOUNTABILITY

Fare revenue reporting is also a function this mix of automation, mechanical and manual collection. Most
revenue and ridership data rely on manual entries. This not only makes reporting and reconciliation
inefficient, but it also makes it prone to errors; however, there are a number of “checks and balances” to
detect, reduce, and correct the errors typically associated with any manual system.
• Most Station Collectors accept cash only and while cash from sales by Station Collectors is
transported directly to a bank for counting, the only method for reconciling Collector sales is to
conduct a manual reconciliation comparing bank receipts to the issuance of ‘float” and fare media
consignments. The TTC currently accepts debit or credit payments at 10 stations.
• Token Vending Machines also accept cash only and there is no remote sales reporting.
Reconciliation of these machines rests on the comparison of the manual entry of each Token
Vending Machine’s sales recorded by a Token Vending Machine Attendant and the cash counts
from the machines. Sales are tracked by the machines and collected when stocked and emptied on
a scheduled basis.
• Likewise, entries through turnstiles are not automatically or remotely reported; therefore, the
reconciliation of tokens extracted is dependent on the manual recording of entries taken from the
mechanical counters inside each turnstile.
Pass Vending Machines, however, accept debit payments only, so these sales transactions are processed
automatically by the machines and reconciled against bank settlement reports.
Surface Vehicle Operators do not sell fare media or touch cash; however, they are expected to observe
and inspect the cash dropped in the farebox. For this purpose, there is a clear glass window displaying the
cash, ticket or token deposited. Then, at the end of the service day, the locked and specifically designated
farebox vault is removed for counting and processing. This same procedure is applied to the handling of
farebox vaults at Station Collector booths and the token boxes in the turnstiles. There is no automated
method of counting ridership or recording ridership by type. There is an assumption of ridership by the
amount of cash collected and an estimate of ridership by fare type by sampling ticket types.
Page
200
REGIONAL FARE INTEGRATION
The Toronto municipal boundary acts as a fare zone boundary and customers using local transit services
are required to pay a second fare either at the boundary or upon entry to the TTC system. Unlike TTC,
GO Transit has a differentiating fare strategy – charging by distance traveled – while other GTA operators
have a flat fare strategy. The following summarizes some of the successful integration efforts.
TTC – GO Transit – TTC: Customers who ride the TTC immediately before and after a GO train or
GO bus can use the TTC transfer from their first ride to board the second TTC vehicle.
Greater Toronto Area (GTA) Weekly Pass: The GTA Pass is accepted on all TTC, Mississauga,
Brampton, and York Region Transit Routes. Pass holders are not required to pay an additional fare when
crossing into another municipal boundary.
PRESTO: The Government of Ontario, Metrolinx/GO Transit, and participating transit agencies within
the Greater Toronto and Hamilton Area (GTAH) are in the process of implementing an electronic
(smartcard) fare payment system called PRESTO. TTC has committed to install PRESTO Farecard
readers at 12 TTC subway stations, many of which have inter-regional connections with GO Transit and
these other GTAH transit agencies, and on select TTC transit services such as the Transit City LRV
network. These inter-regional locations facilitate the flow of cross-boundary transit customers between
TTC and adjoining transit services, and represent approximately 10% of TTC’s annual ridership.
In addition, TTC operates contracted transit services into these adjacent municipalities. The needs of
“cross-boundary” customers will need to be addressed as part of the OSFS solution. The OSFS will need
to accommodate, and track, non-TTC fare payments for subsequent revenue settlement. The development
of operating scenarios will be part of Design Review.
Exhibit 6.4-1, Daily Transit Trips in the GTA, shows the distribution of the total daily transit trips by
operator within the region. The TTC carries the lion-share of all transit trips in the Greater Toronto Area
with only 5% of the total ridership crossing the TTC service boundary.
Exhibit 6.4-1: Daily Transit Trips in the GTA
Page
201
Appendix B: Wheel-Trans Services
Wheel-Trans is a division of TTC responsible for door-to-door and “community bus” accessible
services for persons with physical disabilities who have the most difficulty using conventional
transit services. Transportation service is provided by a mixed fleet off TTC-owned Wheel-Trans
vehicles and contracted accessible taxis and sedan taxis.
Wheel-Trans transportation services are integrated with regular TTC transportation services. All
rides are arranged by booking one day in advance commencing at 7:00 a.m on a first-come-first-
serve basis. Booking Wheel-Trans can be done in three ways:
• Internet
• Automated Telephone System
• Reservations Office through a live Representative
Further details about the Wheel-Trans program are available on line at TTC’s website,
www.ttc.ca.
In 2009, Wheel-Trans customers took approximately 2.5 million trips. This equates to
approximately 7,700 daily trips taken by 60,000 Wheel-Trans registrants. In 2009, there were
200 TTC-owned Wheel-Trans revenue vehicles. In addition there were approximately 700
contracted accessible taxis and sedans available to provide Wheel-Trans transportation services.
Payment of Fares
Regular TTC fares apply on all Wheel-Trans services. Payment of fares on Wheel-Trans vehicles
are with appropriate TTC fare media or exact cash. Bus drivers and taxi drivers do not sell
tickets, tokens, passes or make change. If a customer does not have the correct or exact fare at
the time of boarding, the customer is required to forward the fare within five days to the Wheel-
Trans office located at 580 Commissioners Street, Toronto, Ontario.
Page
202
Appendix C: Proof of Payment Concept of Operations - Current Light Rail
Vehicle Operations
This Appendix discusses the Proof of Payment Concept of Operations for the current (legacy)
Light Right Vehicle (LRV) system. The purpose of this discussion is to inform the development
of a POP solution for the Open Standard Fare System (OSFS) being provided by the Private
Partner.
Although many aspects of the desired POP operation are described in this Appendix, further
detailed requirements will need to be specified, developed, and analyzed to refine these concepts
in a manner that can yield a fully operational OSFS. This concept of operations document may
vary in breadth, depth, and scope compared to other concept of operations documents. These
variations are normal and should in no way be an indication of the importance of these contents.
Similarly, detailed concepts, processes, and requirements not covered in this document will not
exclude consideration, development, or possible inclusion of those concepts, processes from the
final accepted OSFS solution developed and approved during Design Review.
These are the guidelines that were developed based on plans developed prior to the OSFS
concept.
General Overview
Legacy LRV concept of POP fare payment operations for the OSFS will be based on the
following principles:
• The Legacy LRV system is a POP system. Enforcement of fare payment will entail
customers having the ability to provide proof of payment for all journeys on the Legacy
LRV system.
• The Legacy LRV system will require use of on-board and of off-board POP automated
vending machines to ensure that customers who do not have an open standard bank-
issued card, who do not have access to an available non-retail sales and reload location
proximate to the LRV stops, or who simply chose to pay on-board will have the
opportunity to pay the appropriate fare.
• All Legacy LRVs will be equipped with two on-board POP automated vending machines.
• The Legacy POP system will fully support concession fares.
• The Legacy LRV system will for the most part consist of a series of stops corresponding
to current streetcar stops. Where the Legacy LRV stop coincides with a TTC subway
station, the Legacy LRV Concept of Operations may be adapted to fit within the context
of the subway station.
Page
203
• Legacy LRV stops are above ground and will utilize a barrier free system. During the
initial roll-out of the Legacy LRV, while significant areas of TTC and other Transit
Agencies are not enabled with the OSFS, TTC fare media for its fare payment system
will be regarded as valid POP receipts. All stops are unattended.
• The Legacy LRV may initially roll out supporting current fare media only. It will
transition to support the OSFS using OSFS devices, including such devices as Reader
Assemblies, POP vending machines, and other equipment such as hand-held devices used
by Special Constables for enforcement purposes.
• The Legacy LRV system will use all current TTC fare payment products and OSFS fare
payment products, and adhere to TTC fare policies and procedures.
• The Legacy LRV system will use all required OSFS system equipment, processes, and
operating procedures, including all back office functionalities provided through the
Central Processor and all support functionalities provided to support customers paying
with OSFS media and devices.
• Customer flow to and from the Legacy System via TTC and other Service Providers will
need to be as unrestricted as possible.
• The OSFS system solution must be capable of operating under conditions imposed by the
operating environment of the Legacy LRV system.
Current and OSFS system Fare Product Support
The Legacy LRV POP system will initially support current TTC fare media and fare products.
This current media includes:
• TTC Passes;
• TTC Concession Tickets;
• TTC Tokens; and
• Transfers.
Support for TTC’s current fare media will continue until the OSFS is fully operational and
through the transition period proposed in the RFPQ.
The Legacy POP system must support all OSFS products. All customer services afforded to
OSFS users will be available and supported for Legacy LRV customers. In all cases, the Legacy
POP system must support payment for POP media using cash, credit/debit, GPR cards, and all
other devices and media accepted and supported by the OSFS.
Legacy LRV Implementation
Legacy LRV implementation is scheduled to begin in 2011 with the delivery of three (3) LRVs.
The implementation period will continue through 2018, when the last of 204 new LRVs are
Page
204
delivered. Beginning in 2013, approximately 35 LRVs will be placed into revenue service each
year. A complete schedule of the Legacy LRV program will be provided at Design Review.
The actual implementation timeline for OSFS on Legacy LRVs will need to be coordinated with
the implementation of the OSFS itself. A potential staging of the OSFS could avoid the need for
the Legacy LRV to accept Current TTC Fare System media.
Proof of Payment
The definition of a Proof of Payment instrument for the Legacy LRV is key to understanding of
the Legacy LRV Concept of Operations. Generally, a POP receipt is any form of receipt that
unequivocally proves that a customer has paid for that particular journey on transit.
For an OSFS, the POP receipt for customers who pay with cash on board Legacy LRVs can be a
paper receipt, which would have printed on it the date, time, location of purchase, and any other
information required by TTC. That POP paper receipt could also be the media used to entitle the
cash paying customer to allowable transfers.
In the OSFS stage only, POP receipts become contactless media that conforms to open standards
business, technical, and operating requirements of the financial services and payments industries.
Consistent with the concept of operations outlined in the RFPQ, customers already in the
possession of an open standards device must be able to use that device as Proof of Payment on
board Legacy LRVs. Similarly, customers boarding and having no such open standards device,
or those wishing to pay with cash, must be able to purchase open standards contactless media on
board the LRV in a manner identical to that in TTC subway stations.
A major difference is that open standards media in possession of customers will not have a visual
display that indicates whether fare has been paid. No POP receipts will be required for OSFS
customers who already have a contactless open standard deice in their possession. They simply
tap their smart card on the Reader Assemblies located at the doors of the Legacy LRV as the
method of payment for that transit ride.
For the OSFS, validation of payment will be through electronic means only. Special Constables
will be equipped with portable, hand-held devices capable of reading OSFS contactless media.
These portable, hand-held devices will communication in real-time to the OSFS Central
Processor and return a response to the bearer within the timeframe required in this RFPQ.
The Central Processor for the OSFS will be configured to compare taps made at Reader
Assemblies to those made at special hand-held devices in the possession of Special Constables.
Should no initial tap upon the Reader Assemblies installed on Legacy LRV be found recorded on
the Central Processor, when the Central Processor accepts a tap from the hand held, it will return
a unique response code to the hand held device to alert the Special Constable to the fare evasion
event. At that point, the Special Constable will proceed according to appropriate guidelines for
handling fare evaders on TTC services.
Page
205
Other important issues and constraints will come to light during discussion and refinement of this
Concept of Operations during Design Review.
Preliminary Guidelines for the On-Board Fare Media Vending Device (FMVD)
An integral part of Legacy LRV POP operations is the on-board Fare Media Vending Device
(FMVD). The FMVD intended for on-board operations has the same core functionality as the
FMVD intended for installation in TTC’s subway stations. In addition, however, it must be able
to withstand all environmental and operational factors associated with LRV operations, as well
as the fact that its form factors (footprint, dimensions, etc.), power, and communications
requirements are compatible with mobile LRV operations. Furthermore, the OSFS requirement
for use of real-time communications will use the cellular network and may require
communications to/from all open payments equipment to use the onboard LRV Ethernet
network.
TTC has developed preliminary drawings that describe preferred configurations and locations, as
well as counts of the number of FMVDs required at a minimum for the deployment on Legacy
LRVs. This information will be provided to the Private Partner at Design Review.
On-Board Reader Assemblies
The Reader Assembly intended for deployment on Legacy LRVs has all the same requirements
as the Reader Assembly intended for installation on TTC’s surface vehicles and other surface
vehicles that participate in the OSFS solution. In addition, however, it must be able to withstand
all environmental and operational factors associated with LRV operations, as well as the fact that
its form factors (footprint, dimensions, etc.), power, and communications requirements are
compatible with mobile operations.
TTC has developed preliminary drawings that describe preferred configurations and locations, as
well as counts of the number of Reader Assemblies that would be required for the deployment of
Reader Assemblies on Legacy LRVs. This information will be provided to the Private Partner at
Design Review.
Staged Implementation
As noted earlier, successful implementation of the OSFS, both from a technical and operation
standpoint, as well as from the standpoint of achieving related business goals for the acceptance
and use of OSFS contactless devices for payment of fares, may impact TTC’s conceptual plans
for the equipping of Legacy LRVs with POP capability.
The Private Partner must consider these factors in developing a proposed POP solution for
Legacy LRVs and submit a proposed solution as part of its response to this RFPQ.
Page
206
Appendix D: TTC Turnstile Information
The following figures below provide the general sizing and dimensions of one of the TTC
entrance turnstiles (Tomsed Turnstile). Please note that,
• Drawings are not to scale,

• All dimensions are in inches,
• Tolerances are,
o Fractional +/- 1/32
o Two Decimal Place +/- 0.01
o Three Decimal Place +/- 0.005
o Angular +/- ½”
Direction of
Customers Entering Fare
Figure 2 Tomsed Turnstile
Page
207
Figure 3 Tomsed Turnstile – Top View
Figure 4 Tomsed Turnstile - Side View
Page
208
Figure 5 Tomsed Turnstile - Front View
Page
209
Figure 6 Tomsed Turnstile - Back View
Page
210
Appendix E: Transit City
Through Metrolinx, the Province of Ontario is providing funding for the four priority Transit
City projects.
Sheppard East LRT
This route will operate between Don Mills subway station and Meadowvale Road in northeast
Scarborough and will intersect with the Sheppard subway line, GO Transit Stouffville line, Don
Mills LRT, and the Scarborough Malvern LRT.
Length of project route: 14km

Number of stops: 30
Start of construction: 2009
Schedule start of service: 2013
Finch West LRT
This route will originate at Finch station on the Yonge subway line and travel west, connecting
to the extension of the Spadina Subway, the Jane LRT, and provide service to Humber College’s
North Campus.

Number of stops: 30
The Minister of Environment has issued TTC with a Notice to Proceed for the Finch West LRT
project. This notice indicates the approval of the provincial Environmental Project Report. The
Notice to Proceed specifies that the Minister has found this project does not have any potential
for a negative impact on a matter of provincial importance that relates to the natural environment
or cultural heritage. The Notice to Proceed can be found on the
www.toronto.ca/involved/projects web site.
Eglinton Crosstown LRT
This route will link Kennedy subway station in the east with Pearson Airport and the
Mississauga Transitway and will operate underground for an approximate distance of 10km from
Laird Drive in the east to Keele Street in the west. Customers will be able to connect with the
Bloor-Danforth subway, Yonge-University-Spadina subway, and both Don Mills LRT and Jane
LRT.

Number of stops: 42
Page
211
The Minister of Environment has issued TTC with a Notice to Proceed for the Eglinton
Crosstown LRT. This notice indicates the approval of the provincial Environmental Project
Report. The Notice to Proceed specifies that the Minister has found this project does not have
any potential for a negative impact on a matter of provincial importance that relates to the natural
environment or cultural heritage. The Notice to Proceed can be found on the
www.toronto.ca/involved/projects web site.
Scarborough Rapid Transit LRT
This project will redevelop the current system into a modern LRT, as well as extend the project
from its current terminus at McGowan subway station north to Sheppard Avenue.
Length of project route: TBD

Number of stops: 10 (3 new)
Page
212
THIS PAGE INTENTIONALLY LEFT BLANK
Page
213

TTC Request For Pre-Qualifications

Uploaded by

Copyright:

Available Formats

You might also like

TTC Request For Pre-Qualifications

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TTC Request For Pre-Qualifications

Uploaded by

Copyright:

Available Formats

TORONTO TRANSIT COMMISSION

REQUEST FOR PRE-QUALIFICATION STATEMENTS

OPEN STANDARDS-BASED FARE PAYMENT SYSTEM

REFERENCE NO: R39PN10871

Submit complete Pre-Qualification Statement package to:

Attention: Joanna Raimondo

Appendix A – Corporate Information

• The Commission: The Toronto Transit Commission.

Issue Request for Pre-Qualification Statements August 9, 2010

4. RESERVED RIGHTS OF THE COMMISSION

A. Cover Page (to include identification of all Team Members)

.1 Corporate Information – use Appendix A to the Pre-Qualification Statement

.2 Provide a summary of relevant corporate experience of the Respondent. The

- Background and capabilities;

.3 If the Pre-qualification Statement is being submitted by a Joint Venture, one

.5 Financial Information: Please produce information sufficient to document financial

F. Open Fare System – Project Methodology and Approach to the Work

H. Detailed Technical Submittal Information

Company Name: ___________________________________________

Registered Address: ________________________________________

Contact Name and Title: ______________________________________________

Telephone No.: ______________________________________________

Fax No.: ____________________________________________________

Email Address: _______________________________________________

b) Number of years in business

c) Depth of available relevant

NAME OF JOINT VENTURE

Reference to Specific Section of

Section of Response (pg. Section Addresses

Reference to Specific Section of

Section of Response (pg. Section Addresses

Reference to Specific Section of

Section of Response (pg. Section Addresses

Reference to Specific Section of

Section of Response (pg. Section Addresses

Name _________________________________ Title _______________________________

Signature _________________________________ Date _______________________________

Name _________________________________ Title _______________________________

Signature _________________________________ Date _______________________________

Name _________________________________ Title _______________________________

Signature _________________________________ Date _______________________________

1 Open Standards Fare System............................................................................................................ 9

1.1.1 Market Opportunity and Background

Subject to Commission approval, the TTC is committed to adoption of open standards

1.1.2 Technical and Operating Overview

1.2 Objectives for the OSFS

1.2.1 Transaction Structure and Business Requirements

• Exclusivity Potential. The TTC is prepared, dependent on contractual terms, to review

• Commuter Parking Lot Operation Potential. The TTC currently operates 29

• TTC Riders Increasingly Using Cashless Methods of Payments. Approximately 50%

• Funding, acquiring, certifying (system level), installing, operating, repairing, replacing,

• Seamless adoption of innovations in fare payment technology and business processes,

• Sharing in new, non-fare box revenues generated by the Private Partner.

• Operation of the Non-TTC retail sales network.

1.2.2 Customer Experience Requirements

• Enhancing customers’ fare payment experience through simplification of steps in a

1.3 Current Operating Scenarios

Name ___ Title _

Signature ___ Date _

Name ___ Title _

Signature ___ Date _

Name ___ Title _

Signature ___ Date _