Account Based Transit Card - The Good, the Bad and the Ugly

Ingo Noka
Advice

In my dream team AFCS (here)(1), I declared the transit card to be "the backbone of my ideal AFCS." I made the implicit assumption that the transit card would be an offline stored value card.

This assumption wasn’t quite correct. A transit card does not have to be a stored value offline card. It can be account-based as well. The question is whether it is possible to build an AFCS in the Philippines that dispenses with the offline stored-value altogether and make everything, including the transit card, account-based.

I think it will be difficult under the unique circumstances of the Filipino market. While the benefits of an account-based transit card may outweigh its disadvantages, it remains to be seen whether the transit operators will accept the residual risk of delayed online authorization.

Account Based Transit Card - What Is it?

The account based transit card consists of a fare media and a backend account system. The fare media part has two functions. One function is to identify the account with a unique identifier stored on the fare media. The second function is a means to authenticate the fare medium offline.

The offline authentication is dynamic, which means that the validation device (tier 1) is able to determine whether the fare media is genuine[1].

The unique identifier of the transit card links the card to an account balance maintained by a backend system. The identifier can be anything[2], as long as the identifier is unique and secured by a successful offline authentication. The link between authentication and identifier is usually established in one of two ways:

  1. By sending the identifier within a secure authenticated session link between fare medium and validator, or

  2. By including the identifier into the diversification data of the fare media specific authentication key.

Strictly speaking, EMV cards meet all the above criteria. The two main differences between an EMV card and a transit card are:

  1. The transit card follows a proprietary protocol while the EMV card follows the international EMV standard, and

  2. The transit card is designed specifically with the fare collection application in mind, while the EMV card was designed for general purpose payments.

Account based transit card may store the same information as stored value cards. It will be more efficient to keep that information in the backend account record though.

I can see some value in recording transaction data and “offline” limits to manage the risk during periods of reduced network availability.

What is an Offline Stored-Value Card?

The offline stored-value fare medium contains the balance, that is the amount available for a ticketing transaction. The actual amount the passenger has available is always stored on the fare medium. There is no need to contact a backend system. The backend system may keep a balance as well, but this balance will go out of sync every time the fare medium conducts a transactions or adds to the balance.

Like the account-based card, the offline stored-value card also performs authentication offline, provides a unique identifier and stores additional data.

Stored value transit cards would also contain additional data, including

  1. transit pass products such as weekly or monthly travel passes,

  2. discounts, such as senior citizen or student discounts,

  3. lifecycle information, such as an expiry date,

  4. transaction information such as entry station, or

  5. risk management data such as last exit time, maximum number of transactions without blacklist update and so forth.

Can an AFCS survive on account-based Fare Media alone?

The answer is as always "It depends." The decisive factor is connectivity and the transport operator’s attitude towards fraud management.

Account-based fare media thrives in environments with reliable, economical and fast network connectivity to every validator. With a good network connection, the backend systems can update the validators often enough to stop fraudulent use of fare media before too much losses accumulate. Any environment in which the AFCS must continue to operate for prolonged periods of time with little or no network connectivity, losses could spin out of control.

It also works with operators who have a mature risk practices that seeks to balance innovation, customer convenience and fraud risk. Operators who would rather have customers form long queues at the teller booth than risk a few dollars of fraud will likely resists the introduction of account-based fare media.

Account based transit card vs. Account Based QR and EMV Cards

An interesting aspect of an account based transit card is that it would blur the demarcation to other account based systems such as eWallets and EMV payment cards.

The passenger sees little difference between a post-paid QR code ticket and an account-based transit card. Why then would a passenger transfer money to an account-based transit card if they can access the eWallet balance directly?

The differentiating factor is dynamic authentication. A QR code supports at most static authentication. An NFC-based transit card can perform dynamic authentication.

Of course there are ways to manage the risk of static QR codes. But, is that even necessary?

An account-based transit card transfers an account number to the ticket validator. Scanning a QR ticket presented by the passenger does exactly the same. So, why not replace camera and QR code scanning with NFC? We get dynamic authentication and turn the transit card into an access tool for eWallet balances. E-Wallets would immediately be on an equal footing with the EMV payment card system!

That is an interesting thought, but in this article I will focus on the differences between account-based and stored value transit cards.

Comparison of Account Based and Stored Value Transit Card

The main benefit of an account-based fare medium is the relative ease at which the account balance can be topped up. While offline-stored value card always need to be physically present at a device with a suitable NFC reader, the balance of an account based card can be updated through any of the many digital channels such as bank accounts, eWallets and so forth.

Its biggest disadvantage is that at the time of entry/exit, the validation terminal has no way to check whether the passenger has enough money in their account.

If the majority of your passengers are poor enough to worry about every peso, a flexible risk management would be necessary.

There will be many instances of the card balance being short of a few pesos, and if each time the account-based transit card is blocked, the system will come to a standstill pretty quickly.

Finding the line between granting a tiny overdraft and closing the account will determine whether account-based transit cards will survive the harsh conditions of fare collection in the Philippines.

Whether an overdraft facility can work in practice also depends on the relative ease at which an overdrawn account can be abandoned and a new account opened. Unfortunately, anything that can be done to prevent account hopping[3] will likely require personal data and therefore clash with the need for privacy. Completely anonymous account based transit cards may not be achievable.

Important While creating the following table, I realized that pretty much anything an offline stored-value transit can do, can also be done by an account-based transit card. There are more differences between stored value offline card and even account based transit card and general purpose EMV payment cards.
Feature Stored-Value Account Based1

Add to Card Balance

Requires a NFC capable mobile phone and dedicated application. Otherwise, requires ticketing kiosks or teller devices. For public transport that does not have fixed stations, establishing a top-up infrastructure that is dense enough will be cost-prohibitive and can be ruled out.

No need to present the card. Balance top-up can be done online though any digital channel such as online bank transfer or eWallet payment. Transit card may also be linked to the balance of an eWallet so that separate top-up is not necessary.

Access to Card Balance

Instant and no delay with NFC Mobile phone app. Delayed increases as well as decreases if through backend balance.

Mobile phone up does not need the card to check balance. Balance increases available immediately. Delayed balance decreases from ticketing transactions.

Offline Transaction Support

Validation terminal has access to the card balance without network connection. Transaction upload can be delayed for prolonged periods of time.

Entry and exit transaction does not need network connection. Delayed authentication and blacklist distribution requires frequent and reliable network connectivity.

Transit products and discount cards

Offline stored value cards are specifically designed for this use case. The card will usually have space for information that defines transit products (such as weekly tickets) or that identify the card as a concessionary card that grants a certain discount.

An account based transit card can be designed with the same functionality as stored value cards[4]. If the card was designed for a minimal function of transferring account information, then the backend system would need to apply products and discounts when calculating the fare. A visible indication at the validator identifying the discount or product at the validator would not be possible.

Privacy and anonymity

completely anonymous unless card is personalized for products or discounts (for instance a senior citizen card or a student card)

can be done, but will create problems with frequent account hopping.

Fare calculation

Done by validator. Offline and based on data stored on the card.

Done by backend system. Based on data transmitted by the validators to the backend system.

Missing transaction recovery

Missing uploads could be recovered by storing a transaction history on the card and transferring it together with the current transaction.

Instant Settlement

Settlement depends on transaction uploads. Especially for Jeepney or UV express, where instant settlement is mostly needed, uploads will often occur no more than once a day. Instant settlement is unlikely or at least difficult to achieve.

Account based systems need frequent transaction uploads. Turning an upload into an almost-instant settlement should be possible, or at least easier than for stored value cards.

Best suited for …​

Mass transport that requires cheap validation terminals with infrequent and cost efficient network connectivity: Jeepneys, city buses. Unfortunately, this is also the environment in which a top-up infrastructure will not exist.

Mass transport with fixed stations, good network connections, with clear demarkation between paid and unpaid area, protected by automated gates: city light rail, subway, rapid bus lines

1 We only consider transit cards. EMV cards are not included.

References

(1) I. Noka, “My Dream Team Philippine AFCS.” Ingo’s AFCS Blog, May 2026, Accessed: May 27, 2026. [Online]. Available: https://afcsblog.ingonoka.com/post/ideal-afcs-ph/.

Copyright Sources

melwe, “judge.” Free SVG Website, Mar. 2021, Accessed: May 27, 2026. [Online]. Available: https://freesvg.org/melwe-judge.

1. Static authentication only protects the data itself and ensures that the data was actually generated by the correct authority. It says nothing about the card or mobile device presenting the QR code. It cannot detect whether the QR code is an exact copy either.
2. One might be tempted to use the unique chip identifier, which is basically a serial number hard-coded by the chip manufacturer. However, any device that can mimic the chip interface could present any serial number it chooses and with no further authentication, this could become a security nightmare.
3. Account hoping: the practice of frequent abandoning of accounts and opening new ones. A practice that may be used to avoid paying for transactions that exceed the account balance.
4. The same is not true for generic QR codes and EMV payment cards.