Media-Based VS Account-Based Ticketing: a conversation between ticketing media

Alessandro Sosi | 22.08.2022

“Account Based Ticketing and Mobile Ticketing are synonyms.”

“Wow, Account Based ticketing is amazing, but it cannot be used on a large scale because it excludes less tech-savvy people.”

“Account Based Ticketing is EMV.”

These are just some of the claims we regularly hear when we explain that we develop Account-Based Ticketing (ABT) systems for passenger transport. There is certainly a lot of confusion around this term, which actually boils down to one definition: Account-Based ticketing is a ticketing method in which the proof of entitlement to travel does not require any physical media held by the passenger but it is rather maintained in a comprehensive back office system and readily accessible at any time.

In this blog post we have analyzed this definition, explaining why we believe ABT is the ticketing method of the present projected into the future.

This post, however, wants to tell the story from the perspective of the media used for ticketing. The result is a funny conversation, which we believe can help clarify some fundamental differences between Card / Media-based (MBT) and Account-Based systems (ABT).

Enjoy the reading!

PAPER TICKET

MBT

I’m a paper ticket: by definition, I am not secure, because I’m like cash and it’s difficult – if not impossible – to track me, especially in real time.

It is of little use to embellish myself for anti-counterfeiting purposes, if not to increase my printing cost.

My biggest flaw is my cost of ownership, especially distribution.

ABT

I am not a ticket, I am a simple token to access the actual ticket which is secured in the central system. I am just the physical representation of a digital ticket on the server.

My security is based on the connection with the central server or, in the absence of connectivity, with offline risk management techniques.

I can be issued locally, anywhere, through simple off-the-shelf devices connected to the central system (but also capable of operating offline). I cost very little.

SMART CARD

MBT

I am a smart card and I am in fact a small computer. My security is based on the use of the Secure Element.

Being a computer, I have to interact with other computers: the readers (validators) I come into contact with are equipped with intelligence.

I am usually part of a closed loop system and I am provided by a transport operator: my purchase and management costs are not marginal. I am an hazardous waste therefore I must be disposed of properly.

ABT

I am the same smart card, but I can be used in a different way, i.e. as a simple read-only token (adopting the necessary secure communication protocols with the validator), while the travel tickets are stored on the server.

It is thus possible to simplify the readers, avoiding the use of Secure Elements. Authentication is performed not between card and reader, but between card and central system (and therefore it is intrinsically more modern and more secure).

I could even be any smart card, even a supermarket loyalty card or a hotel key card.

In a phase of progressive evolution from a MBT system to an ABT system, I could store an ABT token in my data model.

SMARTPHONE

MBT

I am a mobile phone and I have to host the travel ticket. I can do this by emulating a smart card (in HCE mode), but this is only possible for Android (and not for iOS) in the European market. I am just a more expensive support for travel tickets actually conveyed like a smart card.

I have to have the ticket read by an external reader (validator), making use of its processing and connectivity capabilities. My connectivity is not used.

I can do it within an app, but if the app is deleted, the ticket is irretrievably lost.

ABT

I am a smartphone and I am used to the full extent of my functionalities, namely connectivity and user interface. The ticket is on the server and I only offer the link to it.

As per ISO/TR 20526, I am an “Active dynamic media” and compared to a “Passive dynamic media” (like a smart card) I have two great advantages:

1) a user interface

2) the Internet connection

and therefore I can allow not only the direct paradigm but also the inverse validation paradigm (i.e. QR code stickers on board the vehicle or at a stop, framed by my camera).

I am the only ticketing scenario in which the user feels technologically involved (user in the loop) in terms of responsibility and enabling investments.

I am the preferred channel for doing MaaS.