My Dream Team Philippine AFCS

The transit card would be the successor of the existing Transpo™ cards. Currently, only AF Payments issues such cards under the beep™ brand name. The Transpo™ standard is based on NXP™ DesFire™ cards. The government owns the specifications for the transit app residing on the DesFire™ card and the exclusive issuing right of AF Payments, Inc. has expired many years ago. Still, no other company has developed and issued their own cards.

Since the transit card would form the backbone of our ideal AFCS, we would have to make some changes to enable as many companies to issue transit cards under their own brand. In my view, this could be done by implementing the following policies:

Under no circumstances should the scheme provider of our ideal AFCS agree make a particular technology exclusive. Since the data storage requirements and the access restrictions are openly available, other technology providers may decide to invest in creating their own transit cards. However, the economics of such a move would be challenging as all L1 devices likely need to be changed to support a different interface to the L1 fare media.

Many years ago, AF Payments developed their own QR ticketing specification and made it available for everybody to study on GitHub™ (5). This standard was meant mostly for pre-paid single journey tickets but did not exclude post-paid tickets. I wrote about the use of some elements of the standard by Gcash™ in this post (6).

In our ideal AFCS, the QR data must be standardized for both pre-paid and post-paid tickets. As we want as many QR ticket issuers as possible, there would be a standard backend interface as well, but this would be separate from the fare media QR data standard discussed here.

As with the transit card acceptance mark, QR tickets also should have their own acceptance mark. Ideally, the QR and transit card acceptance marks should be linked. Using the current terminology as an example, there would be a Transpo mark for the transit card and a Transpo QR acceptance mark for QR tickets.

There is little to be said about the fare media. EMV has been around forever, and the EMV card will have to be used as they are issued. Our ideal AFCS has no say in this.

The unique processing requirements for ticketing transactions have been refind through implementations in many countries. Our ideal AFCS would have a centralized EMV ticketing processing system that implements the established protocols and data requirements and connects the AFCS to the processing infrastructure of the payment card schemes and switches see The High-level Interfaces of L3 and L4 Systems.

The logos of the participating payment card schemes would indicate the acceptance of their payment products at the gate or validators.

Just to be clear, the acceptance of EMV payment cards at ticketing kiosks or at the ticketing counter does not make those payment cards a fare medium. In this case they would just be the funding source for the purchase of a ticket, which could be a QR ticket, a single journey card or additional oad for the transit card.

In my ideal PAFCS, anybody can be a fare media issuer. Settlement risks would not be managed by restricting access, but by security deposits, enforcement of rules and exclusion from the system if the issuer cannot meet their obligations.

Fare media issuers (FMI) must follow the rules and specifications set by the scheme provider for the fare media they issue. The FMI runs their own issuer system and performs authentication and authorization, sells tickets to the passenger or collects money for post-paid ticketing transaction, and settles ticket sales with the PAFCS settlement system.

While not ideal, it is likely that the concessionaire for the L4 settlement system will also be the first, and maybe for a long time the only, issuer of transit cards. In any case, in our ideal PAFCS the concession clearly separates the two distinct roles of a L4 settlement system and that of an issuer.

Payment card fare media will be supported by all financial institutions that issue Visa or MasterCard products. Payment card fare media is not accepted by all transport operators, but if it is accepted, any card will work.

E-wallets will, at their own discretion, issue QR tickets, either post- or pre-paid. Transport operators may issue any type of QR ticket, but most will likely just become issuers of single journey QR tickets.

In our system, AFCS providers contract with transport operators for the operation and maintenance of the ticket acceptance infrastructure which comprises validators such as automated gates or bus validators, station equipment and L3 systems. Most of the time the AFCS provider who operates the equipment will also procure and install it, but transport operators are free to contract with multiple providers for parts of the system.

AFCS providers do not have contracts (explicit or implicit) with anybody but the transport operator. If the transport operator has an obligation towards the passenger, the settlement system or fare media issuers, they can subcontract that obligation to the AFCS provider, but the counterparties still have to go to the transport operator to enforce their legal rights.

For historical reasons it is likely that the government will act on behalf of a subset of transport operators such as the existing light rail systems, the newly built subway, the north-south commuter railway and some of the Rapid Bus Lines, and include the role of the AFCS provider into the concession agreement. In our ideal PAFCS they would be a separate concession, which may well be given to the same concessionaire.

In our ideal system that clearing and settlement system (L4) is completely separate from every other function.

In traditional AFCS the distinction between L4 system and fare media issuer system was not very sharp. Often the AFCS provider played the role of a fare media issuer, usually of a stored value offline type fare media, and also operated the clearing and settlement system. As such, the functions of an issuer system were tightly integrated with the settlement part of the system.

Our ideal AFCS would not want to limit itself to just one type of fare media. As each fare media requires very different authentication and authorization protocols, adding new fare media types to a monolithic issuer/settlement system becomes impossible, or at least expensive and unwieldy.

To me, it seems, therefore, that the settlement system should be independent of the issuer systems.

The clearing and settlement system would then be limited to the following functions:

Data analytics is closely related to the clearing and settlement functions and would therefore be performed by the same entity that is responsible for clearing and settlement. Nevertheless, in our ideal system the functions are strictly separated and could be given to different companies if necessary.

This article has already become too long. I will therefore leave the following to future posts: transport operator, scheme provider, passenger, registrar, centralized key management, interoperability certification and reporting/data analytics