Disclaimer: I work for a transit agency which is in the process of deploying a new fare collection system, but I don’t work on fare collection, and nothing here should be construed as official agency doctrine. Furthermore, everything here is derived from publicly available knowledge.

Fare collection has come a long way from the days of tokens and ticket choppers, but it’s also become fiendishly complex. Nowadays, you can tap your contactless payment card or device for a ride on the subway, use your SEPTA Key card to buy a coffee, and more. But what’s actually happening under the covers? Just what are these systems?

Broadly speaking, automatic fare collection systems can be characterized as either open-loop or closed-loop, and closed-loop systems can be further subdivided into card-based and account-based. Before we get into the minutia of these things, a high-level overview: closed-loop systems are kind of like casino chips, where you have to convert your money into “something else” first, and that “something else” only exists in a particular context, whereas open-loop systems are basically the same as buying something at a store with a credit or debit card.

Closed-loop, card-based

Let’s start with the simplest case: a closed-loop, card-based system. In a closed-loop, card-based system, cards are proprietary to the system, and value “exists” on the card itself. Most older stored-value AFC systems—SmarTrip, Oyster, Clipper, ORCA, the CharlieCard, and yes, the venerable MetroCard—are closed-loop, card-based systems. One of the advantages of a card-based system is that it works very well when some parts of the system don’t have full-time connectivity. This used to be the case for bus fareboxes at many agencies—20 years ago, or even ten years ago, the idea of putting a cellular modem on every bus wasn’t necessarily an easy sell.

So, you needed for bus fareboxes to be able to read data from a card, debit a stored-value wallet as appropriate (or use a pass), accept cash reloads at the farebox, and display the current value, all without contacting a central server or backend. Because all of the relevant information lives on the card, this is easy for a card-based system to do. In some implementations, the card also stores recent ride history, which means you can do neat things like read the ride history off the card without having to contact the backend, as Farebot does.

Now, to be clear, in a card-based system, information doesn’t live solely on the card—in most card-based systems, there is also a central server or backend which gets updated by all of the devices in the network. For most devices, like rail turnstiles, platform validators, and ticket vending machines, which are permanently networked, this means that taps get uploaded pretty quickly, but it’s not uncommon for bus fareboxes to only upload transactions when the bus returns to a depot, meaning that there could be a lag of hours or even a day.

Consequently, it’s possible to have transactions which only exist on a card and the device the card was tapped on (like a bus farebox), but which haven’t made it back to the central server yet. This makes actions like replacing a card interesting—you can’t necessarily trust the card value which is stored in the backend, since there could be unsynced transactions. You might need to wait until every device has uploaded a batch of transactions, or put controls in place to catch transactions that come in after the new card is issued. As an example, suppose a user taps a card with $20 on a bus, and, before the transaction makes it to the backend (e.g. later that night at the depot), reports the card as defective/lost/stolen, and opts to have the value on their card transferred to a new card. But wait! The value in the backend is $20, because the latest tap hasn’t synced! So you either have to delay the transfer until some settlement period has elapsed, or have a mechanism in place to catch the “straggler” taps and apply them to the “replacement” card.

Simply put, in a card-based system, the card is the source of truth, complicating operations like online reloads and card replacements which are initiated from the backend. All of these things can be implemented, but it requires more work—like pushing online reloads out to faregates and fareboxes (which have limited memory and can’t necessarily hold every pending online reload), and requiring bus riders performing online reloads to wait to get their reloaded value until after the bus has been back to the depot and downloaded pending online reloads.

Closed-loop, account-based

By contrast, in an account-based system, the card is simply an opaque token which points to an account which lives in a central system. In theory, you can even have multiple such tokens pointing to a single account (although that can create complications which we’ll come back to later). In an account-based system, there is much more of an expectation that every part of the system is, in normal operation, connected to a central server. Of course, there may be fallback store-and-forward modes available, but they’re not meant for routine use.

Why move from card-based to account-based? In short, many things are easier in an account-based AFC system. Individual devices in the system (fareboxes, turnstiles, platform validators, etc.) no longer have to hold fare tables or perform complex computations—instead they simply report to a backend “card X tapped on device Y at time T”, and the backend does all the hard thinking. As a consequence, some account-based implementations don’t show the current value of a stored-value card when the user taps, although this doesn’t have to be the case.

In an account-based system, online reloads are way easier—instead of having to wait for the user to tap their card at a device which has had the reload pushed to it in order to load funds or passes to the card, all you have to do is update the account value in the backend, and you’re done! Similarly, replacing cards is easier. Because there’s no value on the card, it’s just a matter of hotlisting the deactivated token, and adding the new token to the account.

Now, what was that about multiple tokens? In a basic stored-value system, it doesn’t matter if there are multiple tokens (cards, devices, etc.) pointing to the same account. It doesn’t even matter if multiple people bearing multiple tokens ride simultaneously! But, as soon as you add time-based passes or fare capping to the system, things get interesting. Products like time-based passes are generally sold on the assumption that they are only being used by a single person at a time (and some agencies go further and make their passes explicitly non-transferrable). Thus, in an account-based system, there may be a need to require that only one token be active at a time, if several are registered to a given account, or designate a single token to be associated with a time-based pass.

(As an aside, in closed-loop systems, whether account-based or card-based, there is no expectation that the “card” be a contactless smart card—it could be a magnetic stripe card like the old paper BART and Metrorail farecards or MetroCard (which is polyester). For an account-based system, anything which can be uniquely linked to an account (like a QR code, for example), can be used as a “token”. Could that be an existing credential of some sort? It most certainly could! This includes things like student IDs, government IDs (which can in turn be linked to eligibility verification for reduced fares, etc.), and more.)

Open-loop

In an open-loop fare collection system (sometimes also described as “open payment”, although that term can also be used to describe a more expansive concept), every “end device” (i.e. a bus farebox, rail faregate or turnstile, platform validator, etc.) is a “point of sale”. These endpoints accept bankcards (contactlessly, in most cases), and interact (more-or-less directly) with payment networks.

The simplest case for open-loop fare collection is pay-as-you go fares: you tap a contactless credit or debit card (or a device, such as a phone or wearable emulating such a card), it charges your account, and you ride! Adding fare capping on top isn’t much harder: at the end of each capping period, you look at every card, and refund those whose total spend during the capping period exceeds the cap.

But what about time-based passes? Remember how we talked about “tokens” before, in reference to account-based closed-loop systems? When you think of these “tokens”, you would most likely think of an agency-issued card (or virtual card). But, that token could also be a bankcard! In other words, you can associate a contactless bankcard (or virtual card) with an account, and then use that card or device to access an account which may contain stored value and/or passes, rather than being charged a single pay-as-you-go fare every time.

In fact, I’ve done exactly this in Chicago—I walked up to a Ventra TVM, double-clicked my Apple Watch to pull up a particular payment card, tapped it to the card target, and then “loaded” a 3-day pass to my virtual bankcard exactly as if I had tapped a Ventra card. Now, “loaded” is a serious misnomer here, since in fact I haven’t “loaded” anything whatsoever to my card. Instead, what I’ve actually done is added a pass to the account which happens to have my bankcard associated to it as a token. Now, when I tap my bankcard, rather than being charged the PAYG fare, instead the system sees that there is an account associated with that card, and that that account has a valid pass associated with it, and in turn uses that pass. (To be pedantic, the Ventra implementation is interesting: the first tap of any card/device is always PAYG, but it also creates an account for that PAN—so the next time you tap, it then acts like a closed-loop token pointing to an account, which can then be loaded with stored value or a pass.)

Like account-based closed-loop systems, the expectation is that all of the devices in an open-loop fare collection system have connectivity most, if not all, of the time. Without connectivity to a central server, it’s impossible to know anything about a card or device being presented to a reader, aside from the PAN itself (the “card number”). And even when a device has connectivity, it may still take longer to authorize a transaction than a transit agency deems acceptable, resulting in the end device returning an affirmative response (i.e. allowing the rider to ride) before the transaction has been fully processed. We’re only talking about hundreds of milliseconds here, but the passenger volumes at some high-volume stations make this a serious concern. Similarly, mobile validators on buses have to suffer the round-trip latency of a wireless network, which can be longer than someone would reasonably want to wait to board a bus.

However, this creates a situation known as “first ride risk”, where you could tap a card that would be declined, but the device allows you to ride anyway. Some time later, the transaction actually makes its way through the network, and is declined (e.g. because the card has insufficient funds, is overlimit, etc.). The card will then be hotlisted within the transit network, and be declined on subsequent taps, but the cost of the “first ride” is probably unrecoverable—thus the name “first ride risk”.

There are other nuances to consider—like the fact that in a straight PAYG model, every tap turns into a credit/debit transaction of its own, with its own transaction fee. Bundling or aggregating transactions can mitigate this, but creates downstream implications for the relationship between a transit agency and its acquiring bank.

Once upon a time, it was thought that agencies would deploy “pure” open-loop systems, where there was no agency-branded fare media whatsoever. In North America, the Utah Transit Authority was one such agency—in 2009, they deployed a new fare collection system which, at least at first, only accepted contactless credit and debit cards. Later, UTA launched a closed-loop card of their own, the FAREPAY card, and, in the final act, UTA stopped accepting contactless credit and debit cards, effective April 2018.

Open-loop-only, however, creates significant equity concerns, and a terrible rider experience for those who are unbanked: “go to the corner store, get a GPR card, accept their terms of service and fees, load some cash on it, then come back and pay your fare”. It also means that the agency has no choice but to pay interchange fees on every transaction—there’s no option to shift frequent riders to a closed-loop product, where interchange fees are no longer a factor.

But, at the same time, as a complementary element to other parts of a fare collection system, open-loop fare collection provides huge advantages for infrequent riders—rather than having to buy a particular farecard and figure out how to load value (and how much value to load), or buy a pass, all you have to do is tap the bankcard or device you already have.

“Hybrid” cards

This is such an odd duck that it deserves a heading all to itself: there are some cards out there, such as first-generation Ventra cards, and SEPTA Key cards, which bear all of the indicia of general-purpose reloadable cards, such as a network logo, a 16-digit PAN, expiration date, and CVV, a signature panel on the back, etc., but, within the context of the issuing transit agency, function as a closed-loop account-based card! Indeed, these can best be though of as two cards in one—a GPR card for use at normal points of sale, and an account-based token with an associated “travel wallet” which can be used within the issuing transit network. (Oh, and yes, this means that you can load some money on a SEPTA Key card, hop on a Keystone, and then use that very same card to board the subway. But, spot the flaw! Those two transactions will be coming out of different accounts—the first from the Travel Wallet, and the second from the entirely separate debit account associated with the card.)

There’s another “hybrid” card which is worth noting: the Barclaycard OnePulse, which combined a standard contactless credit card with an Oyster card, by running both applications on the same chip. As far as the Oyster network was concerned, the card was no different than any other Oyster card, and as far as EMV devices were concerned it was just another EMV card. Without delving too deeply into ISO 7816 and ISO 14443, these kinds of integrations are fairly straightforward, since you can easily distinguish the applications by AID.

Putting it all together

So, we’ve briefly outlined three different types of fare collection systems. It’s worth explicitly noting at this point that these options aren’t mutually exclusive. Indeed, any two (or even three!) of these options can co-exist in the same system, although I’m not aware of any closed-loop system that has both card-based and account-based options coexisting—and, as noted above, a pure open-loop system, without any agency-branded closed-loop option, has some significant potential downsides.

(False) dichotomies

When open payment for transit first started to gain traction, more than a decade ago, there were a number of arguments that tended to be made in favor of open payment, particularly as an upgrade path for legacy card-based, closed-loop systems. But the reality is a little fuzzier than some of those arguments make it out to be—there are few bright-line distinctions here, and instead many nuanced tradeoffs.

  • Interoperability: One of the common arguments in favor of open-loop fare collection is that precisely because the cards or devices being accepted are standard payment cards that can be accepted by anyone, anywhere, it becomes easier to develop fare programs which interoperate across transit agencies and across equipment vendors.

    But adopting an open-loop payment system doesn’t automatically mean that Transit Agency A will be able to give a transfer discount to riders transferring from Transit Agency B just because they used the same contactless bankcard or device on both systems. There still has to be some kind of shared backend and shared fare engine that can look at an account’s tap history and make those decisions. If (and this is a big if) that shared backend provides open interfaces that other vendors can plug into, then yes, those agencies could indeed procure entirely different fare collection systems from entirely different vendors, linked only by a common fare engine.

    Beyond that, there’s no reason a closed-loop system, whether card-based or account-based, can’t be made interoperable. This is the intention of the APTA Contactless Fare Media Specification, for example, and ISO 24014. In the United States, there are some transit smartcards, like SmarTrip, Clipper, and ORCA, which cover many agencies and a sizable territory. They’re also proprietary systems, operated by a single vendor or consortium of vendors, meaning that agencies looking to join the program have no choice but to buy that vendor’s equipment.

  • Product diversity: While it’s true that some of the oldest automated fare collection systems out there (which are generally card-based closed-loop systems) are challenged in their ability to implement fancy features like fare capping, that’s not really an open-loop vs. closed-loop distinction. Indeed, modern closed-loop, account-based fare collection systems (like the Go CT card) are capable of implementing all sorts of fancy features, except for accepting bankcards right at the farebox. More broadly, it’s important to separate thinking about fare policy from thinking about fare collection systems, because they are in fact two very different things.

None of this is meant to say that open payment is bad, or that transit agencies with legacy card-based closed-loop systems should keep running them forever (indeed, we have to turn the mainframe off eventually). Nor is it meant to say that open payment is a panacea that will solve all of our fare collection concerns and, while we’re at it, get the trains running on time. Rather, a modern fare collection system must necessarily implement the right bundle of technologies to provide options for all riders—banked and unbanked, frequent and infrequent, bus and rail, and so on.