Account-Based Ticketing - Too much Fraud Potential?

I need to make one important point before I start. This is not about whether account-based transit tickets should be part of an AFCS in the Philippines or not.

Whatever problems need to be overcome, we have to accept that account-based transit tickets, whether based on eWallets, dedicated transit cards, or debit cards, are a necessity. Without it, automated fare collection will not spread beyond the train systems in Manila. Account-based tickets with credit cards will not be enough.

The inconvenience of loading stored value offline cards paired with the prohibitive cost of maintaining a load infrastructure would confine the AFCS technology to mass transit with fixed stations.

For account-based transit ticketing to go beyond credit cards, the industry, especially the transport operators, needs to adopt a mature risk management practice that does not spend 99% of the effort on trying to prevent the last fraction of a basis point of potential fraud.

Even in rather sophisticated markets such as Singapore, it took years and many unproductive meetings until this was resolved. As soon as the account-based system was in place, it turned out that the risk was completely blown out of proportion.

In contrast to credit cards where the issuer would usually be liable, the fraud liability for account-based transit tickets should be shared between ticket issuers and transport operators.

The allocation of liability is similar to card-not-present fraud which the major payment schemes have tried to solve forever.

In the case of fare collection, the operator only gives up a revenue opportunity with marginal cost. The ticket issuer, on the other hand, stands to lose the entire ticket price in cash.

Of course, there are a number of technical fraud reduction measures that can be implemented (see here for more details: (2)). However, fraud cannot be stopped altogether. Fraud^[1] must be made unattractive, i.e., cost-prohibitive.

For instance, if you have to buy a new card every time you use your card without enough money in your account, it would be cheaper to pay for the trip in the first place. The same goes for "abandoning" eWallet accounts that have been used for fraudulent ticket transactions. There are only that many phones and mobile numbers one can use to create new eWallet accounts.

Some account-based ticket issuers may focus their efforts on reducing the time gap between entry/exit transaction and authorization. They may also try to reserve the maximum possible ticket price on entry.

This could work to some extent in the rail systems in Manila. But it will fail in buses, Jeepneys, UV express, and so forth. Even in the train stations, the network connections may not be reliable enough to achieve the necessary speed and uptime for the requirements of a high-volume mass transport system.

Deducting the maximum possible fare may also exclude passengers who have just enough money for the actual fare, but not enough for the maximum possible ticket price.

As I said in my article (1), eWallets and transit card issuers need to establish risk practices that do not close accounts because of a few pesos. My hypothesis is that many times when a few pesos are missing in the account, the balance will be topped up eventually to activate the account for another trip, or in the case of wallets for other transactions.

How much revenue loss can be tolerated also depends on the revenue. If there is not enough money to tolerate some fraud, account-based transit cards are dead in the water.

Eve the ability of the credit card industry to tolerate a certain amount of fraud is not so much coming from sophisticated fraud management; it is based on sufficient revenue that allows them to treat fraud as a cost of doing business.

(1) I. Noka, “Account Based Transit Card - The Good, the Bad and the Ugly,” Ingo’s AFCS Blog, May 2026, Accessed: Jun. 01, 2026. [Online]. Available: https://afcsblog.ingonoka.com/post/account-based-vs-stored-value/.

(2) AF Payments, Ingo Noka, “QR Code Standard for Transport Ticketing - Risk Management.” GitHub, Sep. 2019, [Online]. Available: https://github.com/afpayments/QCAT_QR_TICKETING_STANDARD/blob/cccdb3805abd83f1a1b0bb8a77bea7ea0c7e9656/qr-code-ticketing-risk-management.adoc.

OpenClipart, “Gate of a castle vector.” freeSVG.org, Sep. 2013, Accessed: Jun. 01, 2026. [Online]. Available: https://freesvg.org/gate-of-a-castle-vector. OpenClipart, “Vector graphics of ancient fighter with shield and sword.” freeSVG.org, Jul. 2014, Accessed: Jun. 01, 2026. [Online]. Available: https://freesvg.org/vector-graphics-of-ancient-fighter-with-shield-and-sword. OpenClipart, “A dragon with wings.” freeSVG.org, May 2016, Accessed: Jun. 01, 2026. [Online]. Available: https://freesvg.org/a-dragon-with-wings.