Universal Ticketing Agent

Redefining Open Loop in Transit Ticketing with UWB

Introduction

Ultra-wideband (UWB) technology is taking its first steps in the transit ticketing (fare collection) world. It may, eventually, change the way the transit services are registered, the fares are evaluated, and charges are attributed to the rider. This specifics and the variety of the the UWB-based ticketing solutions is beyond the scope of this post.

Here, we discuss another capability that UWB technology brings. A UWB-enabled transit ticketing tool selector, together with the rider’s UWB-enabled Contactless Rider Device (CRD), can mutually determine which ticketing tool should engage the transit gateway or validator.

For us, in this post, the UWB is merely a means of frictionless, hands-free selection of the most relevant ticketing tool on the CRD, such as contactless EMV (cEMV), QR-code, face recognition, a UWB-specific ticketing tool, or anything else, that may come to mind. The presence of multiple ticketing tools on the CRD, and their hands-free selection broadens the technical-level interoperability.

The Universal Ticketing Agent (UniTiAg) cloud ensures the business-level interoperability, where the Transit Agency (TA) is paid off for the services rendered to riders. Together, technical-level interoperability and business-level interoperability effectively broaden open-loop ticketing.

Let’s see how open-loop ticketing will look like in the near future.

Present State

First ideas to implement open-loop ticketing in public transit emerged around 15 years ago. “Open loop” meant using open-loop cards, i.e. cards issued by widely accepted card schemes like Visa, Mastercard, American Express, etc.

There was hope that, eventually, all closed-loop cards, like Oyster in Transport for London, Octopus in Hong Kong, Presto in Toronto, and others would be replaced by open-loop ones, and transit riders could tap the same card to gain access to transit services worldwide without any friction.

As it often happens with time, great enthusiasm has turned into great frustration. Apparently, it is costly to implement open-loop ticketing. The ticketing business processes are expensive, mostly because of complex compliance regulations such as PCI DSS and EMV Level 3 imposed by payment schemes.

Additionally, various local government regulations impose inclusion policies for unbanked and underbanked riders, such as “cash must be accepted,” whereas the rider experience with debit cards and prepaid reloadable cards is poor, because of card schemes’ regulations for transit ticketing.

Transit agencies are losing hope of eliminating the closed-loop cards which they still need to serve unbanked and underbanked customers, spending extra money to support both open-loop and closed-loop ticketing systems simultaneously.

Current Regulatory and Technological Landscape

Meanwhile, the payment industry, regulatory requirements, and underlying technologies have undergone significant changes over the past 15 years.

  • Apart from credit card payments, we have now real-time bank account access, various stored-value e-wallet schemes, B2C payment schemes, and cryptocurrency exchanges.
  • European Union regulations capping interchange rates make credit card issuing barely profitable in Europe.
  • Smartphones and other personal devices can support nearly any payment and authentication procedure. Modern smartphones have UWB communication capabilities.
  • FiRa Consortium is developing UWB specifications for public transit. See their brochure here.
  • At least one UWB-based transit project has started. See: Transit Ticketing Global 2025; NXP blog.
  • Apple and Google operating systems provide smartphone wallets that can keep many ticketing tools as well as provide payer authentication.
  • Online two-sided marketplaces (TSMPs), providing services for both shoppers and sellers – such as Amazon, Temu, Walmart, Booking.com, Uber, and the like – sell their goods and services online worldwide. *)
  • Some “one-sided” marketplaces such as Netflix, Spotify, and the like sell services online. Although the latter lack seller and seller reconciliation services, they can rely on the reconciliation capabilities of their acquiring processors. *)

It’s high time to redefine and redesign open-loop ticketing!

*) No UniTiAg affiliation with the mentioned marketplaces is implied.

What Is Open-Loop?

Let’s start from the very beginning and see how the rider and the transit agency perceive open-loop ticketing.

Rider’s User Story:

“As a rider, I want to use the same personal device to get immediate access to public transit service worldwide, without any preliminary action required before I start riding.”

Transit Agency’s User Story:

“As a transit agency, I want to be paid off (settled) for the services I provide to any personal device holder without preliminary registration of this device in my ticketing system, with validation latency not greater than 100 – 350 msec per passenger per validator or gateway.”

Open-loop ticketing utilizing credit cards mostly fits in both user stories (apart from the validation throughput on transit vehicles). Credit cards are accepted worldwide because of EMV Level 3 business-level interoperability. Transit agencies are paid off because of payment card schemes’ clearing and settlement services.

The problems here are:

  • The cost of this solution.
  • Modern payment schemes are not in the scope of EMV Level 3 business level interoperability, effectively excluding or undermining unbanked or underbanked passengers.

So, the question is: can we redesign open-loop ticketing and make the solution cheaper and more inclusive by utilizing modern payment and underlying technologies?

Universal Ticketing Agent (UniTiAg) is Part of the Solution

The TSMP gives the rider an Open-To-Ride Balance (OTRB) associated with a device (CRD) and an app on it. The OTRB is a money value that can be used to gain access to transit services. Through the UniTiAg cloud, the OTRB is shared across all participating transit agencies (TAs).

The TA’s validator registers the fare associated with the presented rider’s device and the OTRB linked to this device. The TA is a seller on one or several TSMPs, and it is paid by the TSMP through the marketplace’s seller reconciliation process.

You can learn more about the UniTiAg open-loop model here: UniTiAg Business Architecture.

One can object here. Not all riders are, e.g., Amazon *) shoppers; not all transit agencies want or are able to be Amazon sellers. In the UniTiAg realm, the relations between TSMPs and their online sellers – TAs – would look like this.

This is a many-to-many relationship. Any particular TA can be a seller at one or several TSMPs.

UniTiAg improves business-level interoperability compared to closed-loop ticketing where business-level cross-TA interoperability does not exist. Using ubiquitous, worldwide-present TSMPs can improve UniTiAg’s business-level interoperability and make it comparable with cEMV’s where we still have Visa loop, Mastercard loop, etc.

UWB technology, plus CRDs, plus UniTiAg can solve the interoperability problem on all levels and open the ticketing loop.

*) No UniTiAg affiliation with the mentioned entities is implied.

Business-Level Interoperability

The classic closed-loop ticketing model gives us several thousand small closed loops, one loop for each TA. The UniTiAg model provides several wide overlaid closed loops. The level of fragmentation is significantly lower than in the classic closed-loop scheme. Let’s unite UniTiAg loops together.

FiRa Consortium’s UWB specs enable technical-level interoperability.

The UWB specs cannot help with the business-level interoperability. After a proper tool is selected in the CRD, and the fare is determined and registered in the TA’s ABT system, the TA still needs to be paid. This is where the UniTiAg process is necessary to achieve the business-level interoperability, to “open the loop”.

 

UniTiAg Example with UWB

A potential transit rider, let’s call her Ms. Rider, travels a lot worldwide. Ms. Rider has accounts at two TSMPs: MP1 and MP2 which participate in UniTiAg. All transit agencies that Ms. Rider is planning to use are sellers on at least one of these TSMPs.

CRD Setup

Ms. Rider creates two OTRBs:

  • OTRB1 – with marketplace MP1. Ms. Rider creates this OTRB using MP1’s app on Ms. Rider’s CRD). The Mp1’s app created the CRD Token1 linked to the OTRB1 and  placed in the CRD.
  • OTRB2 – with marketplace MP2. This time, Ms. Rider uses MP2’s app on the same CRD. Respectively, another CRD Token2 is created by MP2’s app and is linked to OTRB2 on the same CRD.

After that, Ms. Rider’s CRD  is set indefinitely, without any further friction required for riding.

Rider’s User Experience

Let’s see how the redefined open-loop ticketing works, from the rider’s perspective.

  1. Ms. Rider walks near a ticketing tool selector, on her way to a gateway, in a subway operated by a TA that is a seller at TSMPs MP1, MP2, and MP4. The ticketing tool selector, a UWB-enabled device, communicates with Ms. Rider’s CRD to select the most relevant ticketing tool for further use. The ticketing tool selector can be combined with a validator or can be a separate device.
  2. The CRD and the ticketing tool selector determine that only CRD Tokens associated with MP1 and MP2 can be used to get access to this subway. They also determine which communication channel will be used for validation purposes: e.g., UWB, cEMV, QR – etc. It is UWB, in our example.
  3. The ticketing tool selector selects CRD Token2, as per Ms. Rider’s priority settings, and presents the CRD Token2 to the validator via the predetermined communication channel – UWB.
  4. The validator further follows the UniTiAg offline process to validate the ride, and the gate opens to let Ms. Rider in.

Per the proposed solution, the MP’s app does not store the OTRB amount. In general, storing e-Money balances can work with a closed-loop solution. Giving access to the particular e-Money segment to all TAs would require creating and supporting a so-called Trusted Execution Environment (TEE) across all validators of all TAs, and all TSMP aps. This would require complex legal and financial relationships and key hierarchy across all participants, slow down the authentication process, and increase the cost of such a solution.

The process of using OTRB, updating its value across all transit agencies and marketplaces, as well as OTRB reporting for the purposes of charging the riders and reconciling TAs is covered by UniTiAg. This is how the business-level interoperability is achieved.

Take-Aways

  1. Classic open-loop ticketing in public transit is based on complex compliance regulations and outdated payments technologies. It is high time to revise it.
  2. UniTiAg proposes a ticketing model that engages online marketplaces – TSMPs. UniTiAg introduces OTRB – a transit money value – and manages OTRBs in UniTiAg cloud. This significantly decreases the level of fragmentation in the current closed-loop and open-loop ticketing landscapes.
  3. Joining UniTiAg forces with CRD providers, such as Apple, Google, Samsung, etc., and using modern communication technologies such as UWB, enables creation of a modern open-loop ticketing solution.

Posted

in

by

Eugene Lishak

Tags:

, ,