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.
Steve Munro 
Steve writes: “Presto cannot currently handle co-payments in situations where a rider takes more than 35 trips in one month. ”
Is this 35 GO trips, or 35 trips of any kind? It’s never been clear to me.
Steve: When a rider takes the 36th combined local/GO trip, the problem is that the GO fare is zero for that trip, and the “rebate” for the local trip causes the fare to go negative. The fare collection software is not set up to deal with negative fares as the assumption is always that the next increment of any trip will cost enough to offset the discount applied retroactively to the previous segment’s fare.
LikeLike
Great article, and great research Steve!
Some (minor) comments:
[i]What is the problem with co-payments beyond 35 trips a month?[/i]
Isn’t this a bit of a red-herring? It’s a problem, yes. But they’ve said they are going to fix it. I don’t see that short-term technological glitches (and we know there will be with any system) are worth much debate. This is true of the other glitches (in hardware or policy), that will all likely have to be changed/fixed quickly such as Presto cards not working at TTC machines (for intitial use, reloads, etc.); negative balances requiring an in-person visit to a Presto office to reset, the requirement to use your Presto card within 7 days of receiving it, or have to phone to have it reset (but oddly unlike negative balances, a visit in person doesn’t work).
Steve: This issue is described elsewhere and will be fixed. More generally, it speaks to the basic design of Presto fare collection with an on-card ePurse that is decremented as you use fares rather than a central system that reconciles all of the trips and appropriate discounts after the fact.
Credit card service charges … wow, I haven’t seen these since way back in the early 1990s. I wasn’t aware that many people still got them. Surely, someone who uses their credit card for transit … or for their morning coffee, as so many now do … are going to be on a plan where they don’t pay a per-transaction service charge. They are more common for debit cards, but presumably people will select card plans accordingly.
Steve: The service charges also affect the “vendor”, in this case the transit system. The reason many shops won’t take credit/debit for small purchases is that the fees they pay wipe out the transaction. A vendor with a very large volume of transactions can negotiate a lower and possibly flat rate for services.
Open payment in Ottawa for 2012. We’ve seen reports elsewhere that these Presto open payment devices will arrive in 2012. However, Presto, publicly, and also the folks in Ottawa, are maintaining that Presto will be fully implemented there by the end of 2011. Has there been a delay?
Steve: I have heard both dates. Wait and see.
LikeLike
Thanks Steve. This is what the journalists at our “newspapers” should be doing, but instead we get half-truths and rhetoric.
Did you get any information on the 24-hour online fare update and the implication for local buses?
It baffles me that the system allows a local bus rider to enter into a negative balance situation. If i take multiple (and separate) local bus trips out in Oakville right now with only one fare on my card, how will the system know not to let me on again?
Steve: This is a side effect of the system design. If they don’t want to do real-time balance updates, they should have the ability for a card to go to a negative balance up to a set limit. Better, they should do all of the processing centrally, but that requires a more robust communication system. Part of the problem with the original design lies in the then-current capabilities of cell networks.
LikeLike
A trial on one route comes across as TTCspeak for “we’re not going to implement system-wide”. If it were not, we would have PoP system wide, or at least on all streetcar routes, and time-based transfers beyond 512 St. Clair. Given the despicable way the split 501 “trial” was conducted I personally have little time for the TTC’s notion of honest evaluation.
Since it is surely untenable that 30m vehicles operate by front door payment, the new Commission should demand that the TTC implement a new transfer and PoP fare strategy to be fully in service prior to the entry to service of the first Flexity downtown cars, implementable in both electronic and non-electronic forms. This strategy would account in staffing and financial terms for the need to have frequent fare inspection both by visible and plainclothes inspectors. Where difficulties are experienced, the next step should be to fix, not abandon.
The direction to Staff to implement this by this date should take an old school form “Hereof nor you nor any of you may fail as you will answer the contrary at your Peril”.
LikeLike
Steve: “When a rider takes the 36th combined local/GO trip, the problem is that the GO fare is zero for that trip”.
Actually, it’s zero from trip 41 onwards. Trips 36-40 get a very heavy discount (87.5%), which could easily rtesult in a GO fare less than the co-fare credit. But I’m nit-picking – thanks for explaining this.
Given that the contract payments are all about deliverables, and the co-fare agreement existed long before Presto was even thought of, the extra work will come at no additional cost to the taxpayer.
Steve: Sorry about that.
LikeLike
Thank-you for the most informative and balanced post.
I agree that fare rules must be adapted. There would certainly be winners and losers. However, keep in mind, there are winners and losers today. People are paying more for short trips to subsidize the longer trips. I’m not saying this is good or bad, but that it’s an economic reality.
The flat fare to which we’ve become accustomed was created originally (in large part) for operational cost and convenience reasons. As (if?) we transition to electronic payment, how important are these?
Is it really a big deal if the fare boundary policy is changed is some fashion? I don’t think this would necessarily hurt transit agencies. The double fare penalty in place today turns away would be customers who need to commute over the boundary. This is a growing segment.
Speaking from professional experience, the pattern on the Presto project – and especially the TTC is typical for systems/technology projects that cross the pre-existing bounds. Many years ago, I worked for a major manufacturer that was implementing a global ERP system. This irked those used to local control. Some people in Europe were fired and the VP from the largest manufacturing site was called onto the carpet at HQ and told to get with the program. The project ended up being very successful.
The caveat at is that at that company – renowned for being able to implement things – project failure is simply not at option!
At the TTC, I don’t think we can say the same thing. It’s not a surprise to read that the TTC requirements grew – it’s a typical strategy of denial to throw in arcane requirements late in the game to ‘derail’ a project that you don’t want.
LikeLike
What is to stop someone from setting a very short (cheaper) distance as their ‘default’ for GO, and just never tapping out after a longer one? Not a GO user, but it seems like a obvious way to game the system.
LikeLike
That does not inspire great confidence.
Steve: At least the card isn’t blue.
LikeLike
Tom West wrote, “Given that the contract payments are all about deliverables, and the co-fare agreement existed long before Presto was even thought of, the extra work will come at no additional cost to the taxpayer.”
Never mind ‘no additional cost’, this ‘extra work’ should have been part of the initial roll out. What is the big deal about crediting an amount back to one’s e-purse?!? That requirement should have been part of the specs given that it became necessary to deduct the full local fare when the rider boards a bus heading to a GO station.
What is implemented in Presto is akin to the Beer Store charging the deposit on a two-four of beer bottles, and when you go to return them, you don’t get a credit if you are not purchasing a new box of beer at that time!
LikeLike
Check out the massive cost spike that resulted from the implementation of the Utah Transit Authority’s contactless credit card system. This occurred without any concomitant increase in ridership.
Steve: The linked article is the first in a series, and it will be interesting to see where the author goes with his thesis. A good argument can be made that the fare payment mechanism is not a major factor in attracting riding, and other issues such as service quality and general transit demand could also be at work. Over the 2006-2009 period reviewed in this article, ridership stayed flat, although there were large swings up and down the netted out to zero. A big increase in service in 2008 corresponded with a jump in ridership, some of which was lost when service was cut back again in 2009. The rise in cost/mile was lowest in the year with greatly increased service, and this suggests a considerable overburden of fixed costs that were diluted with the service increase.
Certainly the line “operation support” grew at a much faster rate than any other category in dollar terms, and has done so consistently over the period. This trend was established before the contactless fare system roll out began in late 2008.
On the question of bank fees, the author does not talk about micropayments, adjustments in service charges or billing schemes that would present a credit card charge for transit use on an accumulated monthly basis (and hence lessen the fee/fare ratio substantially).
Finally, it should be noted that the website is operated by a firm that describes itself as an “alternative payment company”, and they have an interest in presenting traditional credit card operations in an unfavourable light.
LikeLike
John Palmer says: “What is to stop someone from setting a very short (cheaper) distance as their ‘default’ for GO, and just never tapping out after a longer one? Not a GO user, but it seems like a obvious way to game the system.”
Imagine your trip is Oakville-Union, and you set your default as Oakville-Clarkson. If GO Transit’s ticket checkers will have scanners to check your Presto card. If you not between Oakville and Clarkson, they will be able to see that you haven’t over-ridden the default, and thus don’t have a proper ticket. If you’ve boarded at Union, then either you haven’t tapped on (illegal), or you’ll need to tap off at Oakville and pay the correct fare.
LikeLike
John Palmer asks: “What is to stop someone from setting a very short (cheaper) distance as their ‘default’ for GO, and just never tapping out after a longer one? Not a GO user, but it seems like a obvious way to game the system.”
This occurred to me too. Actually, you could ask, “why not just not tap your Presto card when you get on?”
The answer: GO fare inspectors will have portable readers that can tell them if the proper fare has been applied. So you’re taking the same risk as you would by riding further than your ticket allows, or not buying a ticket in the first place.
I presume that in addition to the on-card purse (which could be as simple as a single number representing value) and transit-system-related “products”, the card stores details of your current (and past?) trips for inspection purposes.
This prompts (not “begs” if one is a pedant) the question: if the purse and information are not on the card, but all in the system — as I suppose it would be if you paid by RFID credit card or similar — how would your fare be inspected? Instead of talking to the RFID card/phone, which like Sgt. Schultz knows nothing, the fare inspector’s machine would have to pull up that rider’s data from the system. I have no idea how great a technical challenge this will be.
Steve: A mobile inspection device would “call home” over the internet (just like readers on vehicles) to determine whether a card had been recently tapped/swiped for entry to the system.
If the TTC maintains the fare inspection intensity I’ve noticed on the Queen and Lake Shore cars, a bandwidth of zero would suffice.
LikeLike
Ed’s reply raises an intersting point about open payment systems that doesn’t seem to have been considered: when boarding a bus, you don’t always pay the same amount. If it’s a transfer, you pay nothing. If it’s a co-fare, you pay something different. With Presto, details of the previous few trips are stored, so the correct fare can be calculated off-line. With open payment via a credit/debit card, the system *has* to be all on-line, meaning they have to call home with every transaction.
I’ve seen portable credit/debit card machines in taxis and they use the cellphone network. Only problem is that it takes about 30 seconds to go through – fine for a taxi, not so good for boarding a bus. The alternative is to have some sort of always-on wireless connection, either through the cellphone network or through wifi.
Stepping back slightly, the TTC’s main motivation for open payment is that it is somehow cheaper than Presto, because the back-end side of things will be handled by the banks. As Steve pointed out in reply to Ed, the system has to call home and find out about previous trips, some new back-end infrastructure will be required.
Given there is about $1bn per year spent on transit, and assuming (1) the Big Five all have an equal share, and assuming a rather 5% transaction fee for the banks, then it’s only worth at most $10m per year per bank. I’m not convinced the banks would consider it worth there while to invest in the required systems.
I actually like the idea of using only my debit card to pay for transit. If open payments were a more mature technology and/or Presto not rolling out as we speak, then I’d prefer it to Presto. However, no large transit network has an open payment system, so the technological risk is significant, whereas Presto’s technology is off-the-shelf.
Steve: A lot depends on the design of the back end. As long as transit fares are billed more or less in real time, there will always be the problem of response time and figuring out which trip segments generate a new or incremental fare. If the trips taken are “remembered” and reconciled after the fact to produce a consolidated bill, you avoid the need for instant response.
LikeLike
It appears that the “powers that be” have yet to solve this…. scheduling and proper placement of stops may never get solved … at least in my lifetime.
LikeLike
Was there any word in your meeting if/when they would support purchasing monthly passes with the card … some of us just hate having to tap a card every time we get on a the system … if I know I will use the system 90 rides this month … why should I have to scan the card each time I do it?
Steve: They should be able to handle passes as a “product” although their approach so far has been to count the trips you are taking and give an equivalent to pass discount once you close in on the maximum trip count. Not having to tap in raises a more general issue about self-service fare collection systems. Riders who already have a valid fare (however it is issued), don’t show it to anyone or “tap in”, they just board the vehicle. Operations on the Queen car work like that today. The real issue is that someone has to check cards now and then. I still have a perfect record of never encountering a fare inspector on the TTC.
For stations with barrier controls, you would use your card to open the barrier, and it should recognize that you have a valid pass just as turnstiles handle Metropasses today. If you were using, say, your cell phone to identify yourself, you would already have registered it in the system and bought a pass that would be assigned to its account. Even on a deferred billing plan, the turnstile would let you through, but when the transaction hit the back end system, it would not incur and fare.
LikeLike
Ed wrote, ‘I presume that in addition to the on-card purse (which could be as simple as a single number representing value) and transit-system-related “products”, the card stores details of your current (and past?) trips for inspection purposes.’
An interesting point, as this is something that has been part of the POP inspections: occasionally, seeing the ‘history’ on a 10-ride ticket can prompt certain actions.
A number of years ago, I had a colleague who used one of the non-Lakeshore services each day who related an observation regarding POP checks. The checks were common in one direction (I believe it was outbound in the afternoon, so I’ve tailored this anecdote to match that) between Union and the first stop out. This colleague noted that one regular in the afternoon usually got a ride into the city in the morning, so their 10-ride ticket would have punches only (or mostly) from Union. A day or two after an outbound ticket check, he noticed a switch to inbound checks for a day or two afterwards.
LikeLike
george Bell wrote, “some of us just hate having to tap a card every time we get on a the system”
I could see the powers that be adding a pass as a product that doesn’t need tapping in. That would be a good way to squeeze more money out of those who “just hate having to tap a card every time we get on a the system.” 😉
As much as one might use their pass to its full extent and beyond each month, there will always be the occasional month where some event (sickness, vacation, unexpected closure of workplace or part of the city, other personal issue, etc.) could knock a week or so out of one’s transit use. With the tap in and pay bit-by-bit until the pass price cap comes into effect, one won’t have to pay the full price of the pass if one does not end up using it that much.
Not a huge price to pay, but still a price. Who am I to get in the way of anyone who wants to pay extra?
LikeLike
George Bell said: some of us just hate having to tap a card every time we get on a the system … if I know I will use the system 90 rides this month … why should I have to scan the card each time I do it?
First of all, it’s hardly onerous to tap on, but even aside from that consideration taps provide ridership data. Now the TTC would probably prefer their usual ad hoc ridership counts (it’s tradition, like our transfers) but better data should ultimately mean better service planning. It doesn’t have to be exact, just a better approximation that “let’s send some inspectors out counting on Christmas Day at 3pm to justify closing route X”.
LikeLike
Mark Dowling wrote, “it’s hardly onerous to tap on…”
Quite true, and thinking about other systems, it is not uncommon for doors on vehicles to remain shut when the train arrives in a station and then automatically shut after about 15 seconds. This means that many needing to board or leave the train to push a button to open/reopen the door. Tapping on is no more or less onerous than doing this.
Steve: FYI the doors on the new LFLRVs will be push-button operated.
LikeLike
Steve writes, apropos of fare inspection on RFID cards, “A mobile inspection device would “call home” over the internet (just like readers on vehicles) to determine whether a card had been recently tapped/swiped for entry to the system.”
Yes, and thinking about it further, the system has to accept zillions of calls, what’s one more? But it mostly doesn’t have to process them *that* fast. When you tap/wave your open payment device, and there’s a ten-second delay in posting your ride to the database and calculating your balance, not much will go wrong.
On the other hand, the fare inspector needs almost instantaneous access to information when they check a rider’s record. Inspection would not work well if latency gets up past, oh, five seconds or so. This is a different requirement from the “post ride info in a reasonable length of time”. Again, I have no idea how great a technical issue this might be.
LikeLike
Steve wrote, “FYI the doors on the new LFLRVs will be push-button operated.”
Having the buttons and using them are two different things! 😉
GO’s Bombardier coaches have them as well, but don’t always use them in user-activate mode (I’m tempted to say they rarely use them, but I haven’t used GO much lately to say from recent experience). I suspect the operation will be just like the rear door operation on buses where the operator can select to manually open the door or leave it in automatic mode where the user hitting a crash bar or stepping on a treadle switch opens it.
LikeLike
I agree, punching each time isn’t a huge issue for most people…but I think it’s a barrier to acceptance on Go Lines for those who like to cut it close, which is quite a few given the number of people who “just” make it on in the morning…if they all have to line up to punch and then miss their trains they will quickly go back to monthly passes…easily resolved with extra presto machines I guess…or more frequent Go Service…at Union during rush hour it will be chaos waiting for a tap machine if they don’t have enough…
LikeLike
Steve, are you willing to take a bet with me on whether or not the new, all-doors loading streetcars will be forced to sit in a carhouse for months because the fare collection technology needed to operate them will not yet have been procured when they arrive? Either that or some idiotic scheme like having them be POP-only because there is no way to collect fares onboard the car.
It seems that the utter insanity of paying hundreds of millions of dollars for one piece of equipment while spending a decade dragging your fact on another item necessary to use the first one (automated fare collection) escapes a lot of people. TTC is still acting like new fare collection technology is an ‘if’ not a ‘when’ as the delivery of new streetcars looms closer and closer.
Steve: I hate to say this, but I have the same fear myself. There is a very strong contingent within the TTC for whom any form of proof of payment is simply beyond the pale. When the current Commission leaves office, and without knowing what the new Council will bring, I fear that we may be back to a Commission that is unwilling to push the organization into the late 20th century.
LikeLike
Fascinating stuff!
This topic qualifies as an excellent case study for a Systems Analysis and Design course.
The 36-40 ride problem sounds like someone on the design side didn’t look at the scenarios before the coding started (like that ever happens!). The same applies to the having to push a special button when tapping out on a non-standard trip truly smacks of bad design. I’ve heard from some Presto users that didn’t know the special button was a requirement for a non-default trip and got accordingly whacked.
The revenue recognition issue (who gets the fare dollars) could be partly resolved if the province guaranteed that the transit operators always received full revenue even for a discounted fare. Of course getting the province to guarantee any funding for transit would be a start in the right direction!
Steve: As an IT person who wrote his first non-trivial code back in the 60s, yes, I’ve seen this sort of thing before many times (n both the public and private sectors).
LikeLike
The TTC got 11 responses to their tender call for an Open Payment system:
Proposal- R39PN10871- Open Payment System
Proposal Closed: Friday, September 10, 2010
Proposals Received: 11
Proponents
ACS TRANSPORTATION SOLUTIONS
CUBIC TRANSPORTATION SYSTEMS
INGENICO CANADA LTD.
INSIDE CONTACTLESS
LG CNS AMERICA INC.
MPAYY, INC.
PRECASH INC.
SCHEIDT & BACHMANN
THALES TRANSPORTATION SYSTEMS
VISA CANADA CORPORATION
WORLD DEBIT SERVICES LTD.
LikeLike