Fare payment modernization: account-based ticketing, fare capping, open-loop

Fare payment modernization is one shift wearing three names. Agencies are moving the fare logic off the plastic card and into a back-office account, and once that move is made, two things become possible that were not before. Riders can tap an ordinary bank card or phone instead of a special transit card, which is open-loop. And the system can add up a rider’s trips over a day or a week and stop charging once they have paid the price of a pass, which is fare capping. Account-based ticketing is the back office that makes both work. The three terms describe one change from different angles.

That is the useful way to read the vocabulary. Closed-loop and open-loop describe what a rider taps. Card-based and account-based describe where the fare is worked out. Fare capping is a fare policy that only an account-based system can run well. Get those three distinctions straight and most of the confusion in this corner of transit technology clears up.

What each term actually means

Start with what the rider taps. A closed-loop system uses fare media the agency issues and controls: a smartcard or an app that only works on that network. An open-loop system accepts the contactless bank cards, phones, and watches riders already carry, riding the same tap-to-pay rails as a coffee shop. Open-loop rarely replaces the agency card. Most programs run both, so a rider without a bank card is not shut out.

The more important distinction is where the fare is calculated, because that is the part that actually changed.

Question	Card-based	Account-based
Where value or a pass lives	On the card’s chip	In a back-office account keyed to the card
Where the fare is calculated	On the card and reader, at the gate	In the back office, after the tap
What the reader does	Reads and rewrites the card in a fraction of a second	Records the tap and reports it; the fare is priced centrally
Changing a fare or a pass	Reconfigure the readers, often reissue cards	Edit one rule set in the back office
When the network is down	Keeps working; the card carries its own state	Must admit the rider now and settle the charge later
Fare capping	Impractical; the card cannot see a whole week	Native; the account totals every tap

In a card-based system, the rider’s value or pass lives on the card’s chip, and the fare is settled at the gate. The reader checks the card, deducts the fare, and writes the new balance back, all in the fraction of a second before the gate opens. In an account-based system, the card (or bank card, or phone) is only an identifier. The reader records that this token tapped here at this time and reports it to a back office, which looks up the rider’s account, applies the fare rules, and charges accordingly. Account-based ticketing, usually shortened to ABT, is the name for that back-office model. The tap is the same to the rider. What differs is that the intelligence has moved from the card to a server the agency controls.

Those two axes combine into the three arrangements a rider is likely to meet.

	Closed-loop, card-based	Closed-loop, account-based	Open-loop, account-based
What the rider taps	Agency smartcard	Agency smartcard or app	Bank card, phone, or watch
Where value lives	On the card	Back office	Back office
Who issues the media	The agency	The agency	Any bank or wallet
Fare capping	No	Yes	Yes
Example	The original stored-value transit card	OMNY card, Hop card	OMNY and TfL contactless, LA Metro

Account-based is not a peer of closed-loop and open-loop. It sits underneath both. A modern agency card and an open-loop bank card can ride on the same account-based back office. The only difference between them is the media the rider presents.

Where the fare logic runs, and why it matters

The move to a back office sounds like plumbing, but it is close to the whole story. In a card-based system, every fare rule has to be encoded on the cards and the readers. Change a fare, add a pass, or adjust a transfer window, and you are reconfiguring a fleet of readers and, often, reissuing or rewriting cards out in the field. The system is only as current as its slowest-updated reader. Account-based systems move that logic to one place. A fare change is a change to a rule set in the back office, and every tap after that is priced the new way.

The trade-off is that the back office now has to answer fast and stay up. A card-based reader can settle a fare on its own even with the network down, because the card carries its own state. An account-based reader has to admit the rider now and reconcile the charge later, which means it has to decide, in the moment, whether a tapped card is good for the fare. That risk-based call is the hard engineering problem open-loop systems solve, and it is why the back office, not the reader, is where these programs live or die.

Fare capping, and why it needs the account

Fare capping is the rider-facing payoff. Instead of asking riders to guess in advance whether they will ride enough to justify a day pass or a monthly pass, the system counts their trips as they go and stops charging once they have paid what the pass would have cost. The rider earns the pass by riding, with no money down.

Portland’s TriMet Hop system is a clean illustration. Two paid fares in a day earn a Day Pass, and the rest of that day is free until 3 a.m. Once a rider has paid $100 as an adult ($28 for Honored Citizen and Youth) in a calendar month, the rest of the month is free. New York’s OMNY runs a rolling version: pay for 12 rides in any seven-day window, roughly $35 at the full fare or $17.50 reduced, and the rest of the week rides free.

The equity case is the reason capping gets funded. A monthly pass is a discount available only to riders who can float the lump sum at the start of the month, which is often exactly the riders least able to. Capping hands the same discount to someone paying trip by trip. But it only works if the system can see all of a rider’s trips and add them up, which a card that settles each fare in isolation cannot do. Capping is account-based ticketing’s clearest reason to exist. It also comes with a catch worth telling riders plainly. The count only holds if they tap the same card or device every time, because the back office caps per token, not per person.

Who has moved, and what riders got

The pattern is now a decade old and still spreading. London’s Transport for London extended contactless bank-card payment to the Tube and rail network in 2014, after starting on buses in 2012, and paired it with a daily cap and a Monday-to-Sunday weekly cap. That daily-and-weekly cap model is the one much of the industry has echoed since.

Agency and program	What riders can tap	The cap or pass rule
London, TfL	Bank card, phone, or Oyster	Daily cap plus a Monday-to-Sunday weekly cap
Portland, TriMet Hop	Hop card, bank card, or phone	Two fares earn a Day Pass; $100 adult ($28 reduced) caps the month
New York, MTA OMNY	Bank card, phone, or OMNY card	12 rides in a rolling 7 days, then free the rest of the week
Boston, MBTA	Bank card, phone, or watch	Open-loop tap-to-ride since Aug 1, 2024; account features phasing in
Los Angeles, LA Metro	Bank card, phone, or TAP card	Open-loop full fare across Metro and 26 TAP agencies in 2026

The results are real but still early in most US systems, and they are not uniform. TfL has run open-loop with capping for over a decade. Several US agencies turned it on only in the last two years, and some capabilities that look finished are still rolling out. Boston’s MBTA switched on open-loop tap-to-ride on August 1, 2024 as the rider-facing first phase of an account-based rebuild, with fuller account features arriving in stages after. Los Angeles turned on open-loop for full-fare riders across Metro and its partner agencies in 2026, with reduced-fare open-loop planned for 2027. Read any single agency’s capabilities as a snapshot, not a finished state.

What to watch

The unglamorous questions decide whether these programs deliver. Reduced-fare and cash riders are the test. An open-loop system that only serves people with bank cards narrows access rather than widening it, which is why the agencies furthest along keep the closed-loop card and are extending capping and open-loop to reduced-fare riders too. Interoperability is the next seam. A rider crossing between agencies wants one account and one cap, and that only happens when neighboring systems share a back office or agree on how theirs talk to each other, the same center-to-center problem that runs through the rest of transit technology. And the back office itself is now a critical system. When the fare logic lives on a server, that server’s uptime, its fraud handling, and the privacy of the trip histories it accumulates become the agency’s problem in a way a stack of stored-value cards never was.

Strip the vocabulary away and fare payment modernization is a single move: the fare stops living on the card and starts living in an account the agency runs. Open-loop is what that lets riders tap, and fare capping is what it lets the agency offer. The tap feels identical. Everything that decides whether it works now happens after it.