Account-Based QR Ticketing - How to Match QR Entry and Exit Records
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.
The General Flow of an Account-Based QR Ticket Transaction
Let us first consider how an account-based QR ticketing system would work in principle.
The passenger needs to have an eWallet or a bank account and a mobile phone application. The mobile application must have a function that supports the generation of a transit QR code.
There are few reasons why the passenger’s mobile phone should create the QR code itself. Instead, the passenger requests the creation of a transit QR ticket from the ticket issuer, which is an account-holding financial institution such as an eWallet or a bank 
, 
. At this point we do not know whether the passenger will ever use this ticket. However, the ticket issuer will store the ticket as a potential or pending ticket.
It is possible that the passenger later requests another QR ticket. The Ticket issuer does not know whether the existing, i.e., pending ticket had been scanned or whether the passenger had to create a new one without using the previous one first.
Therefore, the ticket issuer cannot discard the previous ticket. The ticket issuer has to wait until a certain grace period has passed. The grace period would have to be defined based on the timing requirements of the system and the associated liability rules. Ideally, a generated QR ticket would only be discarded after all time limits have lapsed and the ticket issuer would not be liable for the ticket anymore.
The passenger presents 
it to the validator on the vehicle or the automated gate. Depending on the result of the QR code validation
, the gate will open or deny entry/exit 
, 
The validator or gate will generate an entry transaction record with the QR data as well as identifiers for the station, route and transport operator. In the case of in-vehicle validators, the station may be the nearest stop or a GPS location.
The validator or gate will send the entry records to a system that collects account-based ticketing records
.
The passenger will use the previously generated QR code or create a new one and scan it on exiting the vehicle or the platformrecords.
The validator or gate will create an exit record with the same data as the entry record. The exit records will be sent to the QR ticketing service records, 
, 
.
The QR ticketing service will match entry and exit records, calculate the fare, and create ticketing transactions for the level-4 settlement system records
,
.
The level 4 system clears the ticketing transaction by sorting them by Transport Operator and ticket issuer. Finally, the level 4 system will add it all up and create a settlement position for each participant and initiate the financial debit and credit transactions 
, 
, 
.
The Problem of Matching Entry and Exit Records
The topic of this article will be the problem of matching the entry and exit records.
The main problems that need to be solved are the following:
-
Difficulty of defining data that links two QR codes generated by the same passenger.
-
Missing entry or exit records because the customer did not scan or the record has not been uploaded.
-
Missing entry or exit records because the system is trying to match records that arrive before and after a processing deadline.
-
Wrong matching of entry and exit of two different trips. The entry record of the first trip is matched to the exit record of the second trip because the exit of the first trip and the entry of the second trip are missing. They may be missing because the passenger has not scanned the QR code or the record has not been uploaded yet.
Anonymity, Privacy and Account-Based Ticketing
Complete privacy in a fare collection system can only be achieved if all ticketing transactions are fully anonymous and have no identifiers that support matching the start and destination of a trip or that link multiple trips.
Unfortunately, in account-based systems complete anonymity cannot be achieved. Any account-based ticketing system must rely on some sort of identifier for the passenger account from which the fare is to be deducted.
In this regard, no account-based system has a complete defense against determined governments who like to track the movement of their citizens.
Therefore, the best we can hope for is some level of privacy that requires extra steps to link movement records to a person. The system should not have any function or process that creates surveillance data in some automated fashion.
What Data Could be Used for Matching Records
Account Identifier
Traditionally, entry and exit records will be matched using some sort of account information, which does not change[1].
Every new QR code generated by the passenger using the same eWallet or bank account will contain the same account identifier.
Unfortunately, using the account identifier is in conflict with two other important principles: privacy and fraud prevention through tokenization.
We have already established that full anonymity cannot be achieved. Nevertheless, it makes sense to keep the link between account identifier in the QR code, account and account holder in as few places as possible.
That is where tokenization comes in. Ideally, the tokenization should "randomize" the account identifier in the QR code. Nobody but the ticket issuer should be able to reconnect the randomized identifier with the actual account number, and therefore the passenger.
If the above is correct, then the account identifier cannot be used to connect entry and exit records. The tokenization service may assign a new token for any new QR code generation, and it cannot be guaranteed that the passenger ewallet or bank application does not generate new QR codes and therefore requests a new account token.
It is, of course, possible to keep the account token the same for a certain period of time. But then another question arises. For how long should we keep the token the same?
If the token remains the same for too long, the promise of privacy goes out of the window. If it changes in between entry and exit transaction, we have a mismatch with no way to find the two matching records by using the account identifier.
Using the account identifier also creates a heavy reliance on the correct functioning of the tokenization service and the synchronization of tokenization and fare calculation service.
We would mix two very different domains, ticketing and payment, which creates dependencies that should be avoided in a well-designed system.
|
In the end, a decision has to be made whether to dispense with anonymity altogether and include the actual account identifier or a long-lived account token. The tokenization would then address some fraud concerns but nothing else. |
Ticket Identifier
Ticket identifiers fit the pre-paid ticket use case better than post-paid, i.e., account-based, tickets.
If they are used in an account-based ticket, they could be designed in a way that supports entry/exit record matching.
The creation of the ticket ID should take place in the AFCS domain. The ticket issuer, who usually resides in the payment domain, should get the ticket ID from the AFCS. Apart from segregating ticket and payment functions, this would have the added benefit of record matching, identifier creation, and record upload happening in the same tightly integrated system.
Unfortunately, matching records based on ticket identifiers poses the same challenges as using account tokens. The system cannot know whether matching exit and entry records belong to the same trip or to two trips with two records missing.
There is also the added complication of requesting a new ticket identifier during QR code ticket creation. This alone may make a ticket identifier impractical.
Time and Location
Any matching method should always take the time and location of the entry and exit records into account.
Especially in train systems with fixed stations, travel time will be within certain limits (train interruptions or emergency situations excluded). Therefore, the time stamp of entry and exit record should match the usual travel time between entry and exit station.
In train systems we can also infer from the entry station and entry platform which other stations can be reached. An exit record from a different station should therefore belong to a second trip.
Missing Ticket Scans
The problem of a missing entry or exit record has different severities depending on the mass transit system in which the account-based QR tickets are used.
In general, train and bus systems with fixed stations and clear controlled access to the paid area will be easier to manage than mass transit systems like city buses and Jeepneys.
The following table lists some differences between the two types of mass transport systems.
| Fixed stations with validators forming a barrier between paid and unpaid areas | In-Vehicle barriers | |
|---|---|---|
Examples |
Trains, Subway, Rapid Bus |
Buses, Jeepneys |
Entry/Exit Records |
The validator knows whether the passenger is entering or exiting the paid area and marks the records accordingly |
The validator has no way of telling which way the passenger is going unless there are multiple doors that are dedicated to entering and exiting the vehicle |
Enforced scan |
The validator is usually automated gates that grant entry or exit only after a valid fare media is presented |
There is no organic way to enforce scanning the fare media. Buses may have barriers that work like an automated gate, but this does not exist in the Philippines. |
Exception Handling - Scan failed, fare media invalid, passenger device not working (low battery) |
There will be personnel that are equipped with handheld scanners and can assist. |
The driver may be able to assist, but more often than not they will take the usual "system not working, cash-only" approach |
Transaction upload |
It is possible to provide stable, always available network connections with potential backup that allow frequent transaction record uploads |
In the best case there will be a low-bandwidth mobile data connection. Even then there will be areas of bad or no coverage. In some instances uploads can only happen when the vehicle returns to the depot or not at all when it is parked somewhere else. |
|
|
An account-based QR ticketing system will need a very different approach to work well in Jeepneys and city buses. The same applies to long-range bus and train services that will likely require a system more reminiscent of a boarding pass. |
A possible future-proof solution
I would prefer a QR ticketing standard that separates QR code, ticketing and payment information.
The QR data should have at least a ticket identifier and an account identifier. The account identifier should have meaning on to the issuer with the only caveat that it needs to be unique if is to be used for record matching.
The standard should also make a clear distinction between the lifetime of a ticket and the lifetime of the QR code data. The QR data lifetime needs to be very short and is required for frequent regeneration of the data to prevent copying and multiple scans.
The ticket lifetime, on the other hand, survives the frequent regeneration of the QR data.
References
Copyright Sources
OpenClipart, “Witch with crystal ball vector illustration.” freesvg.org, Sep. 2014, Accessed: Jun. 11, 2026. [Online]. Available: https://freesvg.org/witch-with-crystal-ball-vector-illustration.