Trends in smart ticketing

I’ve been thinking a lot about smart ticketing system trends in recent months. It is a subject of interest to a lot of our clients.

Card-centric ‘Closed-loop’ Systems

At the front-end of a smart ticketing system, the customer needs a way of allowing the system to determine whether to let him travel or not. Conventionally, this has been a ticket in the customer’s hand, allowing a reader to check the customer’s right to travel. When smart ticketing systems emerged in the ‘offline’ world of the 1990s, storing the ‘travel right’ on the smart card was seen as the only way to design the architecture. Such systems are ‘card-centric’ or ‘card-based’. In most cases, to-date, these are implemented with Contactless Transit Cards (CTCs); i.e. cards specific to ‘transit’ (with, perhaps, a few permitted ancillary uses). Because the CTCs operate in a closed environment (i.e. it is not ‘general’ payment instrument), these systems are termed ‘closed-loop’.

Even where system components (e.g. station gates) were online, they were unable to perform online travel authorisations fast enough to meet the entry/exit speed requirements of the Transit industry. This reinforced the need for the data (travel rights and value) to be stored on the smart cards, for access at the point of presentation. This architecture became a massively distributed data management problem. Furthermore, a lost card could mean a lost PAYG balance, or a lost travel right.

To accommodate this architecture, some Payment Schemes (e.g. MasterCard and Visa) published specifications for Contactless Payment Cards (CPCs) embodying data storage areas in the card, which could potentially be used to store transit tickets; sometimes called ‘Transit Data Areas’. However, the Payment Schemes have not made availability of such data storage mandatory, and issuers have not yet issued CPCs to these specifications, widely. The fact that a transit operator will currently see few of these cards and therefore cannot rely on data being present is a severe inhibitor to the use of CPCs with this ticketing functionality.

Implementation of TDA would probably need to be an international trend before being worth trying to exploit it. (For example, the UK Cards Association (UKCA) has said that UK banks will never issue CPCs with this functionality on them.)

Shift to Account-centric Systems

In an increasingly on-line world, we are seeing a shift toward account-centric systems; where customer accounts are held in a back-office, and a token to securely identify the relevant account for the travel right is stored ‘in the cloud’. The result is an architecture that is much easier to manage, maintain and extend. It becomes easier to know your customer and make new offers, such as ‘loyalty’. This approach will also accommodate potential future developments in technologies used to identify customers/accounts, such as beacons and biometrics, and is therefore more future-proofed than a card-centric approach. However, it can be more difficult to be responsive at the point of use, compared with card-based architectures. Careful design of the system is needed to ensure that customer passage is not impeded.

Such account-centric schemes can be either:

• Closed-loop: the card is a CTC (i.e. it is transit-scheme-specific), however, the balance and status information is maintained at the back-office (where the fare calculation are also performed),
• Open-loop: the card is a CPC (i.e. it is a general payment instrument).

The use of a CTC in an account-centric environment may seem strange, since the advantage of the CTC (everything available at the point of presentation) seems to be lost when referencing the account at the back-office. However, using a CTC in such an environment can be an economically-attractive first step in migrating from a card-centric scheme to an account-centric scheme. This approach permits the transition to occur without the need to upgrade the readers in the field to accommodate a new Payment Scheme card. Hence ‘transition to account-based’ can be achieved prior to, and independently from ‘introduction of a new card-type’. This may be considered desirable, in that, the problems of each change will occur separately, and can be managed independently.

Smart Ticketing Solution Taxonomy

Image may be NSFW.
Clik here to view.

I’ve produced a ‘taxonomy’ matrix which groups smart ticketing solutions:

• On the ‘Payment Type’ axis there are open-loop and closed-loop payment (i.e. cEMV which works most anywhere vs transit-only balance).
• On the ‘Centricity’ axis, there are:
  • Customer Medium (which includes cards, phones and ‘wearables’ such as watches);
  • Transit accounts in back-office;
  • Payment Scheme with connection to the EMV infrastructure via a Merchant Acquirer.

In general, cEMV cards cannot be written to by the transit reader. There is a specification for the Transit Data Area in EMV , but it has not gained any significant usage. Equally, Payment-Scheme-centric solutions cannot use transit cards. Hence two cells are greyed out below.