Presto implementation has been underway since a 2012 master agreement between the TTC and Metrolinx, and they are now at the half-way mark in a 15-year contract. In spite of this, some functionality included in that contract has not yet been provided, and there are no service level agreements (SLAs) in place setting out basic issues for system performance and financial penalties to Metrolinx for failure. Indeed, although the TTC has claimed revenue losses thanks to problems with Presto, Metrolinx has not accepted that it owes the TTC anything.
Until quite recently, Presto, like so much that comes from Metrolinx and Queen’s Park, was a “good news story” where TTC riders switching to the fare card drove fast growth for that system. The convenience of Presto versus tokens and the disappearance of the Metropass shifted over two-thirds of TTC riding onto Presto. The chart below shows the breakdown for April 2019. The Presto share is expected to reach 95% when legacy media are withdrawn.
However, the good news hides problems with the system as it exists both for Presto users and those who might shift to that system in the future.
The heart of Toronto’s problem with Presto lies in the way the system was imposed. TTC was prepared to go with an alternative vendor for a new fare card system, but were told by Queen’s Park that failure to adopt Presto would put all of the provincial subsidy programs at risk. This was a very big, heavy stick for the government to use, and it shows just how desperate they were that Ontario’s largest transit system be a client (with associated revenue and prestige) of the Presto system.
During the ongoing discussions that began in the fall 2010, the Province and Metrolinx maintained that the common PRESTO Farecard system was their recommended approach to achieving the Plan’s inter-regional policy objective of increasing cross boundary travel. The Province and Metrolinx committed to upgrade the PRESTO system to meet the TTC’s distinct and forward-looking customer, business and financial needs, including advances in fare payment technologies using open payments. The Province and Metrolinx indicated that billions of dollars of funding for some existing TTC programs which had been promised publicly (Provincial gas tax, new streetcars, Eglinton and Scarborough transit initiatives) could be in jeopardy without PRESTO. The adoption of PRESTO was thus approved in June 2011, subject to developing acceptable operating and financial agreements and confirming the funding necessary to proceed. [p 7]
Despite a competing proposal from Xerox subsidiary ACS that would cost over $300 million less than Presto, the TTC was forced to accept the provincial system.
Presto did not perform as it needed to, and contracted functionality is still not available.
The TTC entered into the Agreement with Metrolinx on November 12, 2012. The base term is 15 years (2027), with an option to extend for one additional year at Metrolinx’s discretion and an additional four years by mutual agreement. Key elements of the Agreement include:
- Metrolinx to make modifications and enhancements to the PRESTO system to allow for an e-fare account based payment system with an open architecture using industry standards to accommodate open loop financial cards, mobile applications and future technological innovations (“PRESTO NG”)
- Metrolinx to finance, implement and operate the PRESTO NG system and provide a wide range of “managed services” (e.g. back office operations; customer services; revenue collection and maintenance of all system field equipment)
- In return, TTC to pay a fee of 5.25% of TTC fare revenues processed through the PRESTO system [pp 7-8]
The TTC contemplated a variety of payment mechanisms years ago.
The TTC’s Business Requirements specified both open payment and an account-based architecture, which was to have been built alongside the existing PRESTO card-based architecture. In such a system, customer convenience and flexibility would be maximized. A customer could choose to have a PRESTO card with all its fare policy benefits (e.g. fare concession, 2-hour transfer), or to get some of those benefits using a non-registered open-payment card (e.g. Visa, Mastercard), or to get all fare policy benefits with a registered open-payment card. These concepts were an essential component of the Agreement and were fundamental to the TTC’s agreement in 2012 to accept the PRESTO system versus a competitive market-based solution. [p 11]
Two key capabilities – fares for travel between transit agencies such as York Region Transit and TTC, and the move to “open payments” and an account based system – have yet to be implemented. Regional integration is hoped for later in 2019, but there is no firm date for a change to the payment mechanism.
What Are Account Based Fares?
Account based fares and open payments are closely related, and they are fundamentally different from how Presto works today.
With Presto, fare calculations and validation occur between card readers and the cards themselves. Information about the account balance and any bulk purchase such as a pass is stored on the card. This allows a transaction to occur without any link back to a central system, an arrangement dating back to Presto’s early days when wireless links from their roving bus fleet were not reliably available. However, this forces all of the payment logic into the architecture of the readers and cards constraining the functions they can support.
This arrangement is responsible for the lag between an online account update and the appearance of new “money” on your Presto card. Until you tap onto a reader that “knows” you loaded more money online, you have money in the central system, but cannot use it because the fare machines don’t “see” it.
Imagine if software had to be loaded into every phone so that it could calculate the cost of a call and maintain your account balance. That, in effect, is the complexity Presto imposes, something that should have been designed out of the system years ago.
In the case of a credit or debit card, Presto cannot “write” information onto the card, and so distance-based functions such as GO fare calculations cannot be handled. Only a flat, standard charge is possible such as an adult TTC fare, and without a two-hour transfer privilege.
In an account based system, a rider has a transit account just as they would have one for their mobile phone or credit card, and activity (trips, transfers, border crossings) is accumulated as it occurs. At the end of a billing period, the cost of these trips is calculated with any appropriate discounts such as loyalty programs, time-of-day fares or special event promotions. A Presto card, any other smart card, or a smartphone app can be registered as the rider’s transit identification, but in all cases processing happens in the “back end” with monthly billing to a bank account or credit card. Riders who have not set up accounts simply use their credit cards for pay-as-you-go billing.
The important distinction is that the system needs only track a rider’s travel, not compute the fare in real time based on “today’s rules”. Those rules can be updated in the central billing system rather than having to be integrated in the reader software and pushed out network wide. There is no need for an electronic purse or “e-purse” on the card which must hold enough money (or some form of pass) to pay for any trip a rider might take.
Presto tickets (sometimes referred to as limited use media or “LUMs”) would still exist, but Presto readers would only have to verify when the ticket expires or how many trips are left on it.
Metrolinx plans to make account based fares available sometime in 2020 with open payments in 2021, but there are no firm dates, nor is there a specification of just what functionality Metrolinx will support.
Gaps in the Presto TTC System
Other gaps between the TTC’s Presto contract and current capabilities include:
- Flexible and dynamic fare policies/products
- Support for other than standard fares and environments such as
- Presto tickets dispensed as receipts for cash fares on surface vehicles
- Device availability/reliability
- Service Level Agreements (SLAs)
- Third-party sales network