Advice

Account-based QR ticketing is surprisingly challenging to implement.

The timing and throughput requirements of a mass transit system such as the LRT and MRT lines in Manila require an offline decision by the gate or validator. We also have to accept that delayed uploads and missing records cannot entirely be avoided.

As a result, the matching algorithm for entry and exit records gets riddled with exceptions. In fact, no matter how we design the system, a certain number of records will refuse any attempt of matching and fare calculation.

While I will focus on the matching of entry and exit records, a complete solution must also consider liability allocation and requires a certain amount of risk acceptance. Any attempt to make an QR account-based ticketing system fool prove with no chance of even the tiniest loss will fail!

I have gathered my thoughts on the topic, but I feel that there is a lot more to say. Please do not consider this little write-up the be-all and end-all on the subject.

I was asked recently how I would design an account-based QR code ticketing solution. That is a simple question. But it would require more than one article to even just scratch the surface.

It brought back memories of discussions about static offline authentication and other topics which I thought are buried and forgotten under the thousands of pages of EMV specification and the long-winded migration from magnetic stripe to chip cards.

But here we go again. The good old magnetic stripe swipe under the "modern" guise of a QR code scan.

Nevertheless, I am old enough to remember most of it and decided to take a quick shot in this article.

A message exchange on FaceBook prompted me to write a response to my friend Regie, which became so long that I turned it into an article.

I already talked about the risk of anonymous account-based transit cards in my previous article (1). In this piece I am adding a couple thoughts on the topic.

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.

In March 2026, a number of international, i.e. foreign, companies have attended the market sounding of the DOTr in Singapore (see (1), (2)). My empathy score is rather low, but even I worry about them.

During my time at AF Payments, I learned that the live of a concessionaire is not always easy. I often thought about what we could have done better or different.

That is why I have collected a few recommendations, especially for non-filipino companies who might consider entering the bidding process for the Philippines AFCS concession.

For the readers who cannot be bothered to read the whole thing, here are the top five tips: