It has been widely noted that open-loop ticketing systems, despite huge social demand, cannot defeat the closed-loop ones judging by the three criteria: cost, throughput, and convenience.

Can the open–loop ticketing systems win this battle? We say: “yes, they can” and propose some constructive ideas.

Validation Methods

We will be talking here about ABT (Account-based Ticketing) systems introduced in one of our previous articles. The focus of the current article is Open-Loop ABT ticketing systems only.

• The article discusses flat fare validation based on Tap On schemes as well as distance/zone-based validation based on Tap On – Tap Off schemes.
• The article does not cover use cases where the validator has enough time to wait for the issuer response which generally takes 1 – 5 seconds.

The open-loop card does not provide any ticketing-specific information to the validator. Hence, the Open-Loop ABT system must implement any (or both) of the following two methods of fare validation: Up-Front Validation and Informed Validation.

Up-Front validation means that the validator makes a stand-alone validation decision, right after the tap, solely based on the tapped contactless token ID (e.g., a card number) and a stop-list of such tokens. The validator does not have means and time to determine whether the card is in good state. So, there is a risk that the passenger may get a free first ride causing (so called, FRR – First Ride Risk).

Note: The Up-Front validator initiates a card-present contactless payment transaction. The card issuer approval/decline response comes in several seconds. By the time the passenger completes the ride, the transit system already knows the issuer response and may place the token in the stop list.

Informed Validation means that the validator, communicates with the Transit Host (an ABT computer system and database) to either download the account data, associated with the contactless token, or to request the validation decision from the Transit Host.

• The simplest example of the Informed Validation is when the validator downloads a positive list of period passes from the Transit Host.
• A more comprehensive and typical example of informed validation would be a validator’s or Transit Host’s decision based on the positive list of accounts with card statuses and/or checked or prepaid (preauthorised) ABT stored-value balances.

• Additionally, the ABT data may comprise the same data that a closed-loop card usually possesses. Such approach can be useful for transit operators migrating from closed-loop to open-loop ticketing solution. The account data will look like this:

Typical ride and rider data in the closed-loop card (e.g. MiFare card)

We will discuss in this article advantages and disadvantages of both validation methods, validation latencies peculiar to them, as well as some options of latencies reduction.

1. As already described in one of our previous articles, Tap Latency is the time the card must remain in the card reader’s electromagnetic field. Tapping the contactless card, also known as NFC (Near Filed Communications) card may take around 250-750 msec for EMV contactless cards.
2. The latencies peculiar to the Informed Validation method are discussed in the next section.
3. The validator, making an uninformed decision, must be a PoS, certified by each card scheme accepted. software and firmware updates and recertifications may be requested by the card schemes.
4. According to main industry players, e.g. Littlepay, card-present contactless and FRR costs are not significant. This will be discussed in our future articles.
5. In all cases tokens with offline token authentication (EMV term – Dynamic Data Authentication) should be used.
6. The Transit Host can keep the same account data properties the closed-loop cards store. In migration projects phasing out closed loop, the validation decisions, fare, and discount calculations can be applied right at the time of validation, not by the end of day, making adoption by riders easier. 
7. In some cases, the debit card will not be accepted. In other cases, the debit cardholder will be “overcharged” at the first tap and will “get money back” next day. This experience is even worse for concession eligible passengers. In some countries, card issuers may surcharge the account holders for debit transactions. The details will be discussed in our future articles.

Informed Validation: Host Access Latencies

Let’s see how fast the validator can obtain either the account data or the validation decision from the Transit Host.

Stationary Validators

Stationary validators are in a better position. They can be connected to the transit host by fast cables and network hubs. The signal propagation latency is negligible compared to other latencies. Though, the implementation of such a fast network, especially in transits with many stations stretched across many miles, may have its cost.

The transit host needs some time to retrieve the account data. The reasonable time for that could be around 30-70 msec in the peak period. “reasonable” means that the faster the host computer system is the more expensive it is. Let’s assume, for the matter of example, the Transit Host Latency around 30 – 70 msec.

Moveable Validators

Moveable validators on buses, streetcars, etc, are in worse position. The only way to access the host for them would be via Wi-Fi or wireless cellular network.

You can install an app on your smartphone that measures internet access speed and observe the measured ping latency. If you have a good Wi-Fi, you can get as low as 10-20 msec to ping some nearest web server. If you are not on Wi-Fi, the ping latency for wireless cellular network can be around 100-200 msec on the LTE network.

Unfortunately, the Wireless Latency substantially depends on connection quality and the load on the wireless system. There would not be any surprise if the Wireless Latency can reach several seconds, or connection can be refused at all. The frequency of such cases matters, as it increases FRR.

That is why, in some cases, Informed Validation method should utilize Proactive Data Synchronisation of account data stored in the Transit Host with the moveable validators’ local memory. The Transit Host can provide actual data to each moveable validator in advance, before the passenger boards the transit vehicle. The validator keeps the nearly actual account data in its memory, like SSD (Solid State Drive) with access latency around 2- 5 msec.

Validation with Proactive Data Synchronization

We will illustrate how Informed Validation combined with Proactive Data Synchronization works. The passenger is going to use a contactless EMV card in City of OZ mass transit agency in the following steps.

Step 1. The passenger registers the card in OZ online website using a laptop or smartphone browser. The OZ app on a smartphone is good for this as well. The passenger submits the card number or PAN (Primary Account Number). Now, an OZ Account associated with the PAN is created.

Note: using any contactless token with a unique ID instead of PAN, like a senior card, is possible as well.

Step 2. The passenger buys some “OZ money” or tops-up their OZ Account balance, using OZ website or OZ app. The passenger pays with the same card. In some cases, top-ups via PayPal, any other Visa, Mastercard credit cards, etc., may be allowed.

In certain cases (most likely, for credit card holders sporadically using these transit services) the passenger may decide not to top-up the account and use PAYG (Pay As You Go) option. Instead of prepaid balance, the account will have “card status checked” flag.

Note: whatever means of payment is used, it still tops-up the OZ Account, associated with the PAN used on the first, account registration, step. It is this card the passenger is going to tap at OZ Transit subway gateways and buses. this card PAN is now a unique token in OZ ABT system. It is not a means of payment at the validator. (In real life, the PAN is tokenized by itself, to preserve non-disclosure of sensitive cardholder data)

Upon completion of OZ account top-up, the OZ Transit Host proactively propagates the new balance across all OZ bus validators.

Within several seconds or minutes (no rush here) since the top-up, every OZ bus validator “knows” the PAN and the “OZ money” balance associated with it.

Step 3. The passenger taps the card at a validator. Its card reader derives the PAN and executes offline authentication of the card (see explanation of ODA (Offline Data Authentication in our previous article).

• If this is a bus validator, it finds the account balance, account properties, tap history in the validator’s SSD memory, calculates the fare with all discounts, and turns on the green light (if the balance is enough). Naturally, there is a several-second (if not several-minute) interval between this and the previous step. This time should be enough for OZ Transit Host to propagate the new balance on this account to all moveable validators.

• If this is a stationary, gateway validator, it requests the balance from the OZ Transit Host, and either opens or closes the gate.

Step 4. The passenger enjoys the ride. During this time, the validator reports the new ride data to the OZ Transit Host. The latter propagates the updated account data to all other bus validators.

Step 5, Optional. The passenger taps-off (if required). It is similar to Step 3 (Tap On).

After that, the passenger can board another bus, and everything starts from the very beginning.

Feasibility Study

Synchronizing the validator’s local database for each moveable validator seems to cause a lot of wireless data traffic, especially if the transit agency has thousands of buses, etc. en route at the same time.

The data traffic bandwidth can be high too. Imagine trains arriving to the central transit hub, 1 train per minute. Imagine hundreds of passengers tapping off at the same time, before boarding nearby buses.

The good thing is that data synchronization does not need to be real-time. We always have a minute or two between the card tap-off and its next tap-on. Besides, the data synchronization does not need to be flowless. If some bus validator is late with data synch, it can afford 200 msec or so to get the data from the Transit Host. The average throughput matters, not a single tap delay.

Even if wireless does not work or is too slow, the risk is just a risk of a free ride which may be insignificant if such cases are rare.

When the data traffic is overloaded at peak hours, we do not need to synchronize all data fast. We can resort to synchronizing first the accounts with critically low balances. The registered accounts funded by credit cards do not need to be synchronized fast either.

Note also, that the ABT system can apply up-front validation method to a subset of the accounts. For example, the ABT system can maintain a list of friendly IINs (Issuer Identification Numbers – a prefix of the card number, also known as BIN) where FRR risk is negligible. This may reduce the data traffic.

Data synchronization can also be prioritised by transit topology. For example, the tap-off data originated at Union Station must first reach bus routes adhered to Union Station.

We created a mathematical model to assess the data traffic volumes and costs as well as the validator memory capacity. The vital data is presented in the following table.

As you can see, the validator’s data download and storage requirements are below the capacity of a modern smartphone. For large systems, the bottleneck might be in the wireless data traffic in some specific operating areas. In big transit hub areas, utilizing Wi-Fi may be reasonable.

If you represent a transit operator, please contact us, and we can substitute your data to our model, and optimize the data traffic costs for you.

Takeaways

1. Up-front validation has the lowest validation latency, the same as closed-loop ones. On the other hand, this method has its disadvantages:
   • First Ride Risk
   • Cost of first ride cost recovery and transactions aggregation
   • Difficulty to engage unbanked passengers and to use non-EMV contactless tokens
   • Different rider experience with closed-loop and open-loop cards
   • Poorer debit cardholders experience.
2. Informed Validation method provides rider experience similar to closed-loop card one whereas wide variety of open-loop contactless EMV cards are acceptable, together with locally issued contactless tokens.
3. Informed Validation on moveable validators requires proactive data synchronisation.
4. Proactive data synchronization is feasible. When wireless connectivity is statistically poor, the Upfront Validation method may negatively impact FRR and throughput.
5. Informed Validation method implementation may have its own costs. Minimisation of these costs will be discussed in our future articles.

Credits

Thanks to Paul Griffin and Littlepay for their contribution in reviewing this article.

Authors: David Lunt, Technical Director, Melbourne & Eugene Lishak, Associate, Toronto, Payments Consulting Network

David and Eugene have worked on ticketing systems since 2011 and 2008 respectively. They both bring a wealth of knowledge to the Payments Consulting Network on this topic.

***

This is part of a series of transit articles.

If you found this article helpful and would be interested in reading similar articles by our consulting team, please subscribe to our newsletter.

To get notified of our latest posts, follow Payments Consulting Network company LinkedIn page and click on the bell icon at the top right section of our company profile.