Update 1: July 28, 2010 at 4:00 pm: Comments and clarifications by Ernie Wallace at Presto have been added to this article.
On July 26, I visited the folks at Presto and talked with Ernie Wallace, Executive Project Director, about the system and its plans. Subsequently, I did some digging of my own, primarily on the Ontario government website. The information below is organized to keep topics and the logical flow intact rather than to represent the sequence of the conversation.
How does the PRESTO System Project fit with various local and provincial agencies?
Presto started off as a project within the Ministry of Transportation, and a line item for the project still appears within the Ministry’s Budget Estimates. The contract with Accenture is administered by Metrolinx as an agent of the Ministry. Wallace himself, and other senior Presto staff, appear on the Metrolinx portion of the “Sunshine List” for highly-paid employees of Crown agencies.
Update: The PRESTO team is made up of seconded Provincial staff, GO employees, hired contract employees and contractors through vendors of record.
Metrolinx does not set policy or general direction for the Presto project. This function remains at the Ministry.
The contract with Accenture covers the implementation and operation of Presto for a 10-year period for the eight transit agencies who signed on as the original members. Any expansion of scope such as the now-in-progress Ottawa implementation would be subject to an add-on agreement between the Ministry and Accenture and, of course, an additional payment.
Fare policies remain with each of the local systems for which Presto provides services. The electronic model (“fare topology”) for each system is built into Presto, including any “co-fare” agreements between operators. The best-known of these are between GO Transit and some of the local carriers whose bus systems feed GO where the combined Presto fare is lower than the individual fares for each leg of the journey. Similar schemes can be set up for any of the member transit systems.
The important point here is that a decision to give a combined fare (for example, to Mississauga Transit users who transferred to the TTC subway) is up to the local systems involved (and presumably their Councils for whom any change in fare revenue is of some interest). Presto does not impose a co-fare on any cross-border travel, and would participate in decisions to implement one only to the point of technical feasibility.
The Metrolinx Board does not set fare policies except for GO Transit which is a division of Metrolinx.
What is the nature of the Accenture contract?
According to Ernie Wallace, this contract is in the public domain except, possibly, for some commercial terms. If so, I believe that the Ministry could settle some debates about Accenture’s role simply by releasing the main contract and any subsequent amendments or additions.
Most importantly, Wallace challenged statements claiming that Presto’s and Accenture’s business model depends on expanding the reach of the system, particularly to the TTC, to ensure high transaction volumes. Wallace states that Accenture is providing a specified service (implementation, rollout and support for 10 years on 8 systems) for a fixed price.
Today’s Star reports the scope of the contract this way:
The Ontario government says it has a $250 million contract with Accenture to develop and operate Presto by 2016. That includes the design and the software, the testing, the manufacturing and testing of devices.
This does not include the provisioning of devices for individual transit system stations or vehicles.
Although this may be a fixed price contract, what we don’t know is whether Accenture invested in staff and infrastructure based on a presumed expansion to other, larger systems. Their pricing for add-ons of smaller increments could be affected by their expectations of future growth and recapture of the investment.
Update: The following information was provided by Presto to explain the contract and budget arrangements. In the quote below, “Estimates” refers to the Ontario government estimates, the formal process by which spending is approved by the legislature. Presto and Metrolinx fall within the Ministry of Transportation. “RBP” refers to Results Based Planning, and reports for all Ministries are available. These include information about the previous year’s results and spending.
The contract is a public contract and the overall costs, terms and conditions including deliverable descriptions can be made available but the specific commercial terms and pricing is competitive information and cannot be released. The planned budget for Ottawa is known but contract amendments have only been executed for initial planning and requirements gathering and specific service provider $ for change cannot be released by PRESTO.
The $14,368,000 is the total all in Operating budget for 10/11 including all operating contracts, program costs both people and administration/facilities etc.
[...] each year a capital allocation is provided (ie $50M) to cover all existing contract commitments, approved changes and capital investment of PRESTO, GO and Service Providers.
Accenture and their sub-contractors do all the software development engineering, manufacturing and maintenance. They operate the backend datacentres, call centre and provide the networks and network management
Both [the downtown Presto System Project office] and GO PRESTO offices are funded by MTO and one third of the SP teams costs as well and are in the estimates.
The annual RBP plans and allocations are all in for PRESTO as it relates to the PRESTO Program and all the related contracts and the GO PRESTO team.
And in a separate note:
I [Ernie Wallace] can discuss and show all the deliverables and total roll ups. We intend to put these up on the web but it will take about a week [...] .
The Accenture contract includes all the device costs for stations buses etc. along with infrastructure costs like networks.
Accenture’s contract is based on payment for deliverables and has no transaction fees or payments based on transit revenues or number of cards or volume devices or traffic etc. Added work is handled through a rigorous change process and is usually fixed price again by deliverable.
What are some of the technical details of Presto’s operation?
Two important components of Presto are the concept of an “electronic purse”, the value of pre-paid fares already in a user’s account, and preloaded “products” on the Presto card. Each of these products represents one transit system.
This arrangement allows for some decentralization of processing in that a Presto reader on a bus can have a “conversation” with a card used on that bus system without “calling home” to complete the transaction. This saves on real-time communication delays, and the challenges in some areas of getting reliable, fast cell coverage for the equipment on buses to communicate with the central network.
The trade-off is that this approach doesn’t work if the payment card isn’t “owned” by the system and used to store data. Credit cards, for example, are “read only” and customer tracking all has to be done in the back office system for co-fare arrangements (or even transfers within one system) to be properly handled.
Presto can support flat fares, zone fares, distance-based and time-based fares and, as mentioned earlier, co-payment arrangements where trips across boundaries between operators trigger a discount fare arrangement. All fares require that users “tap on” when they board a vehicle to begin their journey, and when they cross into a new transit system. Zone and distance-based fares require users to “tap out” when they leave that leg of their journey.
Typically, users who fail to tap out are charged a large penalty fare as an incentive to formally complete their journey. This can be confusing in a multi-carrier system such as we have in the GTA where each trip segment has its own fare rules.
A special arrangement exists for GO customers who can define their “default” trip so that it is deducted as a standard charge when they travel. This avoids the need to tap out at their destination, but also causes problems for any non-standard trip where a user must indicate a “non default” fare is requested by pressing a button on the Presto reader.
User confusion is inevitable, and this scheme only works because GO Transit is, today, primarily a commuter service rather than an all-day, two-way provider of regional transit where trips will have a much greater variety of origins and destinations. (See Toronto Star articles here, here and here.)
I can’t help feeling that Presto was build for an age where technical constraints (or budgets) forced choices on system designers that are no longer appropriate, and that the “elephant in the room” of GO and its then-current self view as a commuter system have driven much of the overall design.
Update: The following information was provided by Presto.
PRESTO was built largely on the latest card technology and security technology and using Microsoft operating systems and COTS software and utilizing a proprietary fare and device management system from Europe, future developments including those proposed for Ottawa and TTC will adhere to open architecture principles and standards and core systems will not be based on proprietary software.
What is the problem with co-payments beyond 35 trips a month?
Presto cannot currently handle co-payments in situations where a rider takes more than 35 trips in one month. The reason for this lies in the underlying design of the fare calculation and charging mechanism.
In a co-fare situation, when you take a local bus and then a GO train, there are actually three parts to the fare calculation:
- You board a local bus. At this point the system does not know you are planning to switch to a train, and it charges the full local fare.
- You transfer to the train. At this point, the need for a partial refund of your local fare is evident.
- The system calculates your train fare and deducts the credit for your local co-fare. However, if you are on the 36th trip or more in one month, the result of this value is negative.
This possibility was not contemplated when the system was designed, but Presto is working on it. If the local transit system used the same scheme for fare calculations (free after 35 fares), there would be no problem. However, the situation is complicated by the possibility that one could take local trips that did not involve GO, and these would be subject to local rules that could involve volume discounts or pass-type fares. The interaction of co-fares and each local set of fare rules is a challenge for any cross-system fare card regardless of the technology.
What are Presto’s plans for open payment systems?
The Presto readers now in use cannot interact with standard media such as credit and debit cards. The processes and rules for this are complex, and are the subject of international standards in the payment industry. Presto is a very small fish in a very big pond, and must adapt its system to meet world standards. However, Presto plans to install readers capable of handling standard media for its Ottawa rollout in 2012 and will retrofit the existing system.
Note that this only gets us to the point where a credit card is recognized by the reader. What is still needed is the back-end system to track users, calculate their fares, and bill either a locally-maintained ePurse, or send a bill to the user’s credit card company. Those who argue for a open payments system design claim that money would be saved on some components of the system both through standardization and by offloading some functionality to the payment system.
One obvious issue is the question of service charges. If each fare is billed as a separate transaction, one would pay dearly in service charges (and interest if you run a balance on your credit card) for the “convenience” of using your credit card. This could be avoided if the payment industry adopted a new scheme for “micro payments”, but this requires negotiations between the banks and the providers such as Presto or an independent TTC system. Large transaction volumes are an important component here.
Presto plans to have open payment capability in the 2014-5 time frame. Like so many other projects, this is driven by the Pan Am games. Riders on the Air Rail link should be able to pay for their journey with a credit card directly rather than having to acquire a Presto card for this purpose.
With open payments, Presto hopes to support a “library” of cards that could include a province-wide university student card, a city services card, or any other type of card identifying a large group of travellers. This could be done strictly as a means of convenience (students could register their cards for transit services wherever Presto operated), or Presto could become a service provider to agencies and institutions outside of the transit field. My own view is that they should stick to transit and get that working before trying to turn themselves into a bank.
Related to open payments technology is the ability to use a mobile device. In the simplest implementation, the device’s own identity is registered against “your” Presto account. Billing would likely be against your ePurse. However, mobile apps will eventually be commonplace allowing your “phone” to act as a surrogate for a physical account card, and your mobile device could itself become a library replacing physical credit cards. That’s a future well beyond what is needed for a Presto open payments rollout.
Where does the TTC fit?
It is no secret that the TTC has been dragging its feet on implementation of smart card technology, although the subject has been under discussion for 10 years. The original TTC estimate of $140-million (2000$) has bloomed to $416-million (2010$ plus escalation) based in part on a better understanding of the needed infrastructure changes. This amount does not include planned system expansions (which bring the total to the $489-million figure reported by me and others), but it probably does include costs for some system aspects like wiring within stations that could be replaced by wireless communications. The TTC has quoted Presto a 7-year implementation period which is probably excessive for connection to an existing system where the foundations have already been provisioned.
From the Star:
Presto officials have estimated those costs for the TTC would be about $320 million, including devices, upgrades to infrastructure, wiring, project management, devices and central system changes.
That’s $320m versus $416m, a tidy sum regardless of whose estimate one believes, and this must be funded somehow.
Update: The following information was provided by Presto.
PRESTO was built largely on the latest card technology and security technology and using Microsoft operating systems and COTS software and utilizing a proprietary fare and device management system from Europe. Future developments including those proposed for Ottawa and TTC will adhere to open architecture principles and standards and core systems will not be based on proprietary software.
The original TTC estimate from a decade ago was only for hard and directly related TTC assets (devices etc) . No PRESTO systems development was included. TTC’ s scope, business requirements, infrastructure needs and device requirements have increased dramatically.
Presto says that it is prepared to be ready both for the startup of Transit City (the Sheppard line) and for one line (likely Queen 501) on the TTC in time for the new streetcars which will use all-door loading. However, the time for a commitment one way or another is now given the lead times to finalize the fare structure and build a TTC rollout into Presto’s plans. This collides with the TTC’s own scheme for an open payments trial rollout in the 2010-1 period.
The TTC claims that banks are prepared to fund a trial installation of an open payment system on the streetcar network, or some subset of it. That claim needs to be nailed down both as to scope and technology. Whatever is installed must be the basis for expansion, not a throwaway, and future costs must be clearly understood up front (the banks may be less generous when it comes to a full system rollout) .
John Lorinc has an article in today’s Globe on the current state of affairs in various cities in the USA.
I am not convinced that a trial on only one TTC route will be workable because, unlike riders of GO and a few regional feeder systems, TTC riders have complex trip patterns of which the Queen car is only one part. The impetus for some form of smart card is driven by the need to shift token users (and later ticket and even cash users) to a fare medium that can be used for travel through the system, including automatic entrances. A workable transition plan for co-existence of smart cards and existing payment systems must be in place and well-understood when any trial begins.
The Question of Transfers
The TTC must also address its current complex fare structure regarding transfers. The present rules are just about impossible to define in a way that an automated system can interpret because the topology of the system is so complex. Defining the point at which one trip ends and another begins for fare purposes requires detailed knowledge of the network, of what a “reasonable” trip might be and extenuating circumstances. What looks like an out-of-the-way route may simply be a matter of convenience, even an accessibility requirement to avoid using the subway. A lengthy stopover could be a quick bit of shopping, a longer-than-expected lineup at Starbucks, or the perennial half-hour gap in Queen service.
A pre-requisite for any new payment system will be a change in TTC fares to a time-based system. Such a move is more important even than the technology debate as it will be the basis of a new fare “topology”. This will require fundamental changes in TTC operating practices such as how paper transfers will be issued and used during a transitional period, and this should occur well before a smart card rollout.
One could equally argue for a move to a zone or distance based system, but the political upheaval of such a move — the effect on fares for long-haul riders — would be a major barrier to the implementation. By contrast, a time-based fare would greatly simplify travel, and would reduce costs for some who don’t buy a Metropass but would receive the convenience of, in effect, a short-term pass.
Some at TTC will say “we can’t afford to change fares”, but the simple fact is that the fare structure must change to one that is easy to understand, monitor (electronically) and enforce. A fare must be based on something easy to calculate — the passage of time and/or distance — not on arcane rules almost unchanged since the 1920s. A decision on a new fare structure cannot wait until the day before a smart card system goes live because the new rules must be embedded in the new system.
(For the historically minded, here are two rather elderly transfers that have long passed their allowed time of use. On the left of each pair of images, we have a Winchester car transfer from the Toronto Railway Company on April 1, 1895. On the right, we have a Bay car Toronto Transportation Company transfer from Nov. 19, 1924. Parts of the text setting out the transfer rules will sound rather familiar.
(Collectors please note that the words “First day issued” were already on this transfer when I received it.)
The Reality of the Political Calendar
The TTC began to look at open payments as an option for its fare cards in 2009, and this interest escalated in 2010 when a contract was let for a detailed review and implementation plan. A draft Request for Proposals (RFP) will likely come to the TTC’s August board meeting for approval, and with the lead time for such things, responses are not likely to be back before the current Commission whose last meeting is on September 30, 2010.
Where the proposal will go from there depends on the outcome of the October municipal election, the winner of the mayoralty race, and the makeup of the new Council and Commission. Many of the initiatives started by the current regime will be suspect, if not outright ridiculed and discarded, for purely political reasons as the new administration beats its chest and sets off in a new, if vague, direction. This will not be the time for continuing what the Miller/Giambrone regime started, especially a project that won’t yet be launched.
Although the “banking industry” is said to be eager to fund a trial implementation (just as MasterCard has money in the New York City trial), the details of such an arrangement will not be known until the TTC receives and publishes the responses to its RFP.
There are many questions to be asked about any smart card rollout whether it be Presto, a separate TTC system, or some hybrid. However, we are unlikely to see a strong advocate for a TTC-based implementation, and technically savvy Commissioners/Councillors are hard to find. Couple this to the TTC, a notoriously technology-averse organization with a reputation for bungling projects, and we don’t have a recipe for success.
That said, Presto has yet to show that it can handle a really big rollout either. In its early days, the project itself went through upheavals in management and direction. Any rollout in Toronto will require committed buy-in and participation by the TTC, and this will not come from a contentious us-vs-them relationship.
Presto still only serves a small subset of GTA riders and trip complexities. We have already heard complaints about usability and customer service, and whether the model will scale up to be a truly GTA-wide medium remains to be seen.
Meanwhile, Transportation Minister Kathleen Wynne darkly hints that funding of other Toronto projects is threatened if TTC goes its own way on a farecard system. Queen’s Park really needs to put its money on the table. After delaying half of the already-announced spending on Transit City, Queen’s Park should think twice about forcing Toronto to pay substantially for an imposed fare collection system. I don’t want to hear about all that gas tax — it would take three years of gas tax revenue to pay for a Presto rollout in Toronto, and that money is already earmarked for other transit improvements. If this is an important regional strategy, then it needs to be funded as a regional service through Metrolinx and its long-awaited “Investment Strategy”.
Metrolinx and Queen’s Park must address local transit funding, fare structures and service. Local operations, including fare collection, are a vital part of the regional network, and must be well-funded. Any move to reduce fares for cross-border travel will require changes to subsidies, assuming Ontario will pay any. Ontario talks about getting people out of cars and reducing congestion, but prefers to cherry-pick the projects it will support and fund, while leaving the rest to local municipal agencies and tax revenues.
Toronto and the TTC must set the stage for a move to smart cards with a fare structure review, preferably as early as the 2011 budget cycle, certainly no later than the beginning of 2012. If we are moving to a time-based fare, this decision must be taken soon so that it can be implemented before smart cards are rolled out on the TTC regardless of the technology.
Too many candidates waste their time drawing lines on maps when there are operational issues like this facing the TTC and the City. Fare structures are not just a technology debate for transit and IT geeks, they are basic to transit policy and service. This issue, together with the need to fund a projected half-billion dollar operating deficit in 2011, is the challenge for the incoming Council and for Queen’s Park.