Home MetroCard Slowly leaving the MetroCard behind

Slowly leaving the MetroCard behind

by Benjamin Kabak

A swipeless, credit card-based fare payment system is in our subway-riding future.

Now that the MTA is well on its way toward building out an in-house real-time bus tracking system, the authority’s fare payment technology will be the next to see an upgrade. On and off for four years, the authority has run various contact-less fare payment pilot programs, and after the most recent one, Chair and CEO Jay Walder vowed to move forward with a replacement for the MetroCard.

“The history of some of the technology pieces is that we did a pilot to get to the next pilot and then we did the next pilot to get to the pilot after that,” he said to me in November. “The point of the pilot ending is that we are concentrating on moving out into the production phase of getting this done, and I think you will see contracts early-to-mid next year that will be moving this forward for the subway and bus system.”

That future is nigh. As Digital Transactions reported this week, the MTA will soon begin issuing the requisite documents to solicit proposals for the next-generation fare payment technology. The industry site has more:

MTA officials tell Digital Transactions News that they plan to publish a so-called Concept of Operations, a document outlining the agency’s broad plans that would help vendors develop formal proposals. That document is expected to be available for review soon, though the agency hasn’t given an exact date.

“Once we finish our industry-outreach activities, we will begin the process of turning that into technical requirements and move into high-level system design, and then detailed system design,” an MTA spokesperson tells Digital Transactions News by e-mail. “We expect to issue an RFP [request for proposals] this year to enable us to identify a systems integrator. One of their tasks will be to work with us to do the detailed design.”

The program will be centered on using general-purpose, contactless credit, debit, and prepaid cards and other media based on the ISO 1443 contactless technology standard. That would include contactless fobs that already come with some payment cards, and stickers that attach to cell phones.

Digitial Transactions notes that while the contours of the payment system is in place, the details remain unknown. The cost, for instance, should be steep, and as the MetroCard system cost $750 million to install in the mid-1990s, overhauling turnstiles and the like will require an outlay of capital.

Timing too is a concern. It took the MTA 12 years to move from a consulting project to actual implementation of the MetroCard when it first tried to replace tokens. The time-to-live for this project, though, should be considerably shorter as the MTA has already conducted the pilots for this project. Widespread implementation and scalability are the primary drivers here. The death clock for the MetroCard moves another second toward midnight.

You may also like


David in NYC February 3, 2011 - 4:03 pm

There can’t be any justification for MTA to spend the billions it will take to overhaul turnstiles and payment cards when service continues to get cut and stations go unmanned.
Why does MTA continue to blow huge amounts of money on gee-whiz construction projects when stations are absolutely filthy with full garbage cans and rats roaming freely?
A clean subway station with a helpful staff member would be the most bang for the buck and completely change the image so many people have of the NY subway system.

Andrew February 3, 2011 - 6:02 pm

As tacony palmyra points out, operation of this system will save money.

As for the initial capital outlay, the MetroCard equipment is nearing the end of its useful life. If the MetroCard system were sticking around for the long run, that equipment would need to be replaced. The alternative to switching to a contactless system is not doing nothing.

BrooklynBus February 4, 2011 - 9:38 am

Maybe the answer to just to wait a little longer before switching.

tacony palmyra February 3, 2011 - 4:10 pm

David, while I agree that the MTA needs to spend more money on station cleaning, I think the hope is that contact-less fare collection is cheaper than the current system because it requires less maintenance. I’m sure somebody can find the stats on how much the MTA spends making sure the Metrocard machines and readers on the turnstiles work correctly.

Donald February 3, 2011 - 4:49 pm

So why is the MTA cutting service at the same time they keep doing expensive projects? First it was the plaform screen doors. Today it’s the Metrocards. What will it be tomorrow?

BBnet3000 February 3, 2011 - 5:01 pm

The capital (construction and replacement) budget and the operations budgets are seperate, and come from somewhat different sources, and money does not move easily between them.

Joe Steindam February 3, 2011 - 5:41 pm

In addition to BBnet3000’s statement, these are just requests for proposals (and in this case, the MTA isn’t even doing that just yet). No funds are being allocated to put out these requests, they are barely starting the process for these upgrades. It’s not worth complaining about it at this point.

If you want to stop the MTA, wait until the get the results of the RFP’s and complain during the review process the MTA will do then.

Andrew February 3, 2011 - 6:02 pm

Besides, the MTA is looking for platform screen door installations that pay for themselves through advertising.

Alon Levy February 4, 2011 - 4:31 am

There’s a legitimate reason to pad: if the train is scheduled to go at the maximum technical speed but falls behind, there’s no way for it to catch up. However, it’s better to do this throughout the line, not just at the terminal, by scheduling each station-to-station segment at a few percent longer than best technical time (Switzerland uses 7%). It helps maintain consistent headways.

In contrast, padding at the terminal only is equivalent to no padding for all purposes other than making the line manager look good. This is because it forces the train to go at maximum technical speed away from the terminal, or else headways become erratic.

To add another complication, local trains on NYCT that fall behind can catch up by skipping stops. Peak service is so frequent that it won’t hurt people at the skipped stops too much. So I’m not convinced any padding is useful outside express lines.

Andrew February 6, 2011 - 10:35 pm

I’m not sure what this is doing here and not in the post on on-time performance, but in any case –

Trains aren’t scheduled based on maximum theoretical speed, which doesn’t account for real life interference (e.g., track congestion and door holding); they’re scheduled based on observed running times. There’s no need to pad above what’s observed.

Scheduling recovery time at the terminal is good practice, so that a train that’s fallen behind schedule can still leave on time for its next trip. The terminal is the best place for recovery time, since anywhere else it delays though riders. And recovery time at the terminal doesn’t boost OTP, since OTP is calculated based on the scheduled arrival time at the terminal.

Skipping stops is very customer-unfriendly, especially on lines with express service. In my experience, it isn’t very effective, since it increases dwell times at the stops that are served while riders figure out what’s happening. It should be done as a last resort. Even if service is nominally frequent, the train in question is running late, so people have already been waiting longer than they normally expect to wait. Incidentally, when OTP is calculated, trains that have skipped stops are automatically considered late.

Benjamin Kabak February 3, 2011 - 6:03 pm

Actually, it’s been MetroCards for years. Moving from an expensive proprietary system with high dollar collection costs to a more open fare system with lower revenue collection costs actually saves and generates money despite the capital outlay. So if you’re going to complain at a public hearing — and this goes for David too — you should keep in mind two things:

1. The capital and operating budgets are two very distinct entities, and it’s nearly impossible to move money from one to the other. The MTA will continue to invest in upgrading and maintaining its system on the capital side while slashing operating cuts to meet that budget. If you don’t like that, complain to Albany.

2. By spending capital money on upgrades and efficiencies, the MTA saves money on the operating side in the long term. This is a prime example of that principle at work — and the glass doors might be as well depending upon the economics of it.

The knee-jerk in New York is to complain about everything, but with MetroCard technology nearing the end of its shelf life and with the chance to save on fare collection costs, upgrading makes way too much sense. The better question is: Can the MTA do it fast enough?

Scott E February 3, 2011 - 5:22 pm

What concerns me is not the feasibility of the contactless sensor, that’s been done countless times across the world already. I wonder about infrastructure — each turnstile would need a live, reliable 24/7 data connection back to the “master controller”. I don’t think such a connection exists right now. As we learned from the Lockheed Martin lawsuit, network access just doesn’t extend everywhere. This could turn into a fiasco, and the reasons will be identical to the aforementioned security project.

pea-jay February 4, 2011 - 12:58 am

This seems extra concerning when it comes to bus fare payment. On one hand a touch-and-go card would speed boarding dramatically, so much so I would love the only other permitted payment to be a $5 bill (An incentive to use/get one of these cards). On the other hand how well will those bus reader communicate with the master controller. Would they just presume cash available in the linked bank account or that the card was not reported stolen and should be deactivated/ignored?

John February 4, 2011 - 9:24 am

Plenty of other cities have figured this out on buses…

BrooklynBus February 4, 2011 - 9:43 am

If anyone remembers, originally the bus fareboxes were outfitted with a different top piece to allow the MetroCards to be flashed. It was at the last minute that they all had to be retrofitted to allow swipes. I wonder how much extra that costed.

Andrew February 6, 2011 - 10:38 pm

When the mechanical fareboxes were first replaced with electronic fareboxes, they had a swipe slot on top for potential future farecard use. I don’t think any farecard details had been worked out yet.

In the end, the slot wasn’t compatible with the farecard system that was ultimately developed (or maybe it was just decided that dipping would work better than swiping), so the turnstiles had to be replaced again.

pete February 4, 2011 - 2:08 pm

AFAIK, every metrocard subway station already has an “internet”-ish connection back to headquarters. Not sure if its subway fiber or Verizon copper T1s or Verizon leased fiber circuits. Metrocard doesn’t require an internet connection back to the server, metrocards aren’t checked against the server before the turnstyle or bus fare box “takes” the fare, but they are shortly (not sure for subway, 1 minute?, buses are synced every 1-4 days, personal experiance). The WMATA in DC already uses RFID farecards for all buses and the Metro (the legacy paper mag cards still exist). I’m not sure if WMATA RFID cards are real time validated, or crypto secured, or not secured at all and can get replay attacked. Same with WMATA paper cards.

Scott Mercer February 3, 2011 - 5:30 pm

Stations go unmanned?

In Los Angeles, every single subway station and light rail station is unmanned.

Count your blessings.

TN Moving Stories: MTA Prepares To Go Beyond MetroCard, JetBlue Goes NextGen, and House Transpo Committee Announces ReAuth Road Trip | Transportation Nation February 4, 2011 - 8:57 am

[…] MTA is preparing for the next generation of MetroCard–or, as Second Avenue Sagas puts it, “the death clock for the MetroCard moves another second toward […]

BrooklynBus February 4, 2011 - 9:56 am

I think it took longer than 12 years to realize MetroCard. I seem to remember it being about 9 years behind schedule with implementation originally scheduled for around 1985. Was it supposed to have been ready in three years?


Leave a Comment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More

Privacy & Cookies Policy