The previous article introduced open-loop ticketing approach. In this article, we are going to discuss one of open-loop ticketing challenges that is contactless cards tap latency, i.e., the duration of time the card must stay in the card reader’s electromagnetic field.

Whereas closed-loop ticketing systems can control the quality of cards they use, open-loop ones must deal with wide diversity of cards in the passengers’ hands. This may affect average contactless card tap latencies and, as a result, the validation throughput.

If the open-loop validation throughput is not satisfactory the transit agency must resort to a hybrid type of ticketing systems where the regular passengers use fast closed-loop cards whereas sporadic passengers and tourists use open-loop ones. Hybrid systems would require extra equipment and higher operations costs.

Here, we are going to discuss factors that affect tap latencies in open-loop ticketing systems.

Note: this article is relevant to all types of open-loop ticketing systems, regardless of whether they are account-based or not.

Part One. What is Tap Latency?

Definitions

Card – a device that operates as a contactless “Integrated Circuit Card” according to Contactless EMVCo specifications. The Card can be in plastic form or a gadget, such as watches, smartphones, etc. We are talking here about open-loop cards. That means that the Card is issued by a card scheme recognised worldwide, such as Visa, Mastercard, Amex, etc.

Note: We understand that account-based systems may extend the category of cards they consider open-loop ones, but this will be a topic of another article.

Contactless cards are also called NFC (Near Field Communications) cards.

Validator – a device that grants or denies access to transit services. In the open-loop ticketing world, the Validator, sometimes, initiates a payment transaction via an open-loop card scheme.

Card Reader – a device, connected to or embedded in the Validator, that communicates with the Card via contactless interface. Like Cards, Card Readers operate according to Contactless EMVCo specifications.

Note: Whereas mass transit agencies often utilise unique validation software and, sometimes even hardware, they should implement standard 3rd party’s Card Readers to minimise expenses related to EMV and card schemes certifications and compliance.

Tap Latency – the duration of time the Card must stay in the Card Reader’s electromagnetic field to give the Card Reader an opportunity to communicate with the Card and retrieve all the Card’s data that the Validator may later need for further access validation and (optionally) payment transaction origination.

• The Tap Latency does not include the time the Validator needs to process the retrieved data and make a validation decision to deny or give access to transit services. This process does not require the Card be present in the Card Reader’s electromagnetic field.
• The Tap Latency does not include the payment transaction latency either, that is the duration of time the Validator needs to obtain the card issuer’s approval of the payment transaction request, such as purchase, or pre-authorisation, or card status check. This may take up to several seconds, the approval usually comes after the patron gains access to the transit service.

Desired Tap Latency

According to Nielsen Norman Group’s “Response Times: The 3 Important Limits”, “0.1 second is about the limit for having the user feel that the system is reacting instantaneously.” We believe that reducing the Tap Latency to this level would gain customer appreciation: “I don’t even need to stop when I tap my phone!”

From the validation throughput standpoint, the Tap Latency does not need to be so low.

• Subways and railway station gateways “would be happy” to have at most 350 msec to keep the throughput at the day peak period on a satisfactory level.
• A rural bus driver and his patrons will probably be happy with the Tap Latency up to 500 msec.

Note: the above numbers depend on the gateway design, and many social factors such as the population destiny, passengers’ habits, etc. We would recommend that mass transit agencies start designing their open-loop ticketing systems (and closed-loop ones too) from defining Tap Latency limits and stipulating them in their ticketing system requirements.

Measurements

To better understand factors that impact Tap Latencies we measured the volume of data that Visa and Mastercard cards provide to the Card Reader. We also probed Tap latencies by tapping a few cards on Android device running NFC EMV Explorer Android app that communicates with the Cards in the same way the Card Readers do, and measures data volumes and tap component latencies.

We found that taps usually take between 270 and 800 msec. The Android smartphone is not the best Card Reader, and we did not try all cards in the world. So, our Tap Latency measurements are not complete.

The following table may give you some understanding of the transmitted data volumes and tap latencies.

We also found that recently issued plastic cards are, in general, faster than cards issued several years ago.

Part Two. Factors Affecting Tap Latency

Even though we tested some cards, measured their speed, and analysed some performance data provided by the industry, we still cannot provide any reliable numbers that would allow to calculate some “industry-wide average” Tap Latency or other statistical characteristics.

The problem is that there are many contactless cards out there, in people’s hands. Some were issued a long time ago whereas some were issued recently. There are many smart gadgets in use with the wallet apps as well. Some of them are faster than others.

Even if we had some statistics from some mass transit agency, it would not be applicable to another mass transit agency operating in different social and technological environment because the card and gadgets distribution could be different there.

That is why we call this analysis qualitative. This analysis determines factors affecting Tap Latency but does not provide reliable latency values.

A. Data Transmission Speed

According to Contactless EMVCo specifications, Book D, 6.3.2.4. Cards and Card Readers use a subset of data transmission protocol ISO/IEC 14443 with bit rate 106 kbit/sec. This is the mandatory bit rate, but Book D, 6.3.2.4, allows higher bit rates if supported by both Card and Card Reader.

The payload transmission speed, further measured in “useful” kbits/sec should account for 1.5 – 2.0 redundancy factor. The redundancy is caused by control bits, service bits, pauses between characters and between frames, pauses to change the transfer directions, low-level protocol commands, recovery after transmission errors, etc.

The volume of “useful” data the Card sends to the Card Reader is up to 10 kbit, as per the table above. The Card Reader sends even less data to the Card. Therefore, ideally, the data transmission component of the Tap Latency should be in the range of 150 – 200 msec assuming bit rate 106 kbit/sec.

B. Card Processor’s Speed

Tap Latency comprises duration of time the Card needs to process the Card Reader’s command and prepare data for the Card Reader. If we are talking about cheap microprocessors embedded in the plastic cards, this Tap Latency component may be quite high.

Most of the data that card needs to send to the Card Reader has already been prepared in advance and already resides in the Card’s memory, but the Card must do to some encryption job, called Offline Data Authentication (ODA). Without ODA (also known as DDA, CDA, etc), the Validator cannot distinguish the genuine Card from a counterfeit one.

In brief, the ODA process means electronically signing some unpredictable and unique piece of data that the Card Reader sends to the Card. This data is called challenge. The Card signs the challenge electronically applying its private key and returns to the Card Reader the signed challenge called Signed Dynamic Application Data.

Note: cards that do not support ODA cannot be accepted in open-loop ticketing. By the time the card issuer determines that the card is counterfeit and declines the transaction, several seconds has already passed, and the fraudster is already enjoying the ride. This is not just risk of the free first ride. Without the ODA, anybody can create a smartphone app which can simulate a card with a different card number at each next tap. Every ride would be a free ride with such an app. Stop lists of counterfeit card numbers will not help. An alternative to ODA would be only the expensive fare enforcement police.

Mastercard card, Australian debit card eftpos, and many other cards creates Signed Dynamic Application Data within Generate Application Cryptogram command. Visa includes this data element in Get Processing Options (GPO) command. We did not measure Visa’s ODA latency, but we assumed it should be of the same order of magnitude as the Mastercard’s one because the same card microprocessors are used in both.

We tried several Cards in plastic form issued in different countries and in different times, and we found that despite the Signed Dynamic Application Data represents not more than 13% of the entire data transmitted to the Card Reader, Generate Application Cryptogram command may take around 40% of the entire Tap Latency, for recently issued cards.

We found that newer cards do ODA faster, and we found that Apple Pay and Google wallets do this practically with the data transmission speed. The situation with card speeds seems to be better than it was 5 years ago.

C. Card Reader Processor’s Speed

Tap Latency comprises the duration of time that the Card Reader requires to render its logic and prepare the data to be sent to the card. If the Card Reader has a fast microprocessor, we can consider this latency negligible, compared to the data transmission latency.

Fast microprocessors are more expensive but considering that the ticketing systems need just thousands, not millions, validators, having fast Card Readers is not something unfeasible to achieve and may be justified by higher throughput and better passenger experience.

D. Card Reader Data Transmission Speed

The Card Reader must have powerful electromagnetic field with proper configuration, allowing multiple options of Card orientation and maximizing the width of the area where the Card can be detected in the field and can communicate with the Card Reader.

The Card Reader should support higher bit rates than just 106 kbit/sec.

E. Wallets Speed

Google and Apple Pay wallets demonstrate significantly lower Tap Latencies which is not a surprise. The smartphone can transfer data faster and, most importantly, do cryptographic calculations, such as ODA, faster.

We also noticed that there are some factors that reduce the smartphones’ Tap Latency, up to several times.

• Other applications open in the smartphone. They can consume some of the phone processing power and memory and make the wallet slower or even stop working.
• The way people position their phones at the Card Reader’s electromagnetic field area. This requires some experience and can be improved with time.

• The phone protective cover. Some of them may screen the electromagnetic field.

F. EMV Contactless Kernel 8

Kernel 8 is a new EMVCo standard. Upon implementation of Kernel 8 by card and card reader vendors, the Tap Latency will tend to decrease. We will not see such cards and card readers in mass within the next several years though.

Kernel 8 allows transmitting less data from card to the Card Reader, because of switching to a different algorithm of public key encryption, so called Elliptic Curve Cryptography (ECC). Currently, RSA-based public keys and certificates that the Card provides to the Card Reader has the total length around 360 bytes which amounts to 35% of the overall data volume retrieved from the Card Reader. Tap Latency reducing potential here is around 25%.

Kernel provides other improvements in card-to-reader communication command flow that can reduce the Tap Latency even more.

Kernel 8 is still based on the same bit rate 106 kbits/sec (data transmission protocol described in Book “EMV Level 1 Contactless Interface v3.2.” Higher bitrates are allowed but they are not mandatory. If the industry responds to the Tap Latency challenge by increasing bit rate, this will not happen just because of Kernel 8.

Part Three. Takeaways

1. When implementing an open-loop ticketing system, mass transit agencies must be aware of its Tap Latency limits because they are dictated by acceptable level of validation throughput in peak periods.
2. The mass transit agencies should forecast and measure Tap Latencies on earlier stages of their project’s implementation, through focus groups and pilot projects.
3. The agencies should pay close attention to the performance characteristics of Card Readers they are going to implement.
4. The following factors help to decrease Tap Latency:

• • Faster plastic cards microprocessors
  • Faster Card Readers
  • Higher data transmission speeds supported by Cards and Card Readers
  • Higher adoption of smart gadget’s wallets
  • Faster smart gadgets with better contactless antennas
  • Better Contactless EMV standards, like Kernel 8 and beyond
  • Better patrons’ tapping skills.

***

Authors: David Lunt, Technical Director, Australia & Eugene Lishak, Associate, Canada, 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 we will be publishing in the next few weeks.

***

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

Are you interested in reading articles on a particular payments topic, company, payments industry executive or author? Click the search icon, it’s that magnifying glass on the top right-hand side of the website, and type in the keywords that interest you. You will then be presented with a list of any articles that Published On: 17 November 2022Categories: Blog, Transit TicketingTags: Closed loop cards, closed-loop ticketing, contactless EMV card, data authentication, data transmission, David Lunt, Eugene Lishak, open loop cards, open loop ticketing, tap latency