Universal Ticketing Agent

Redefining Open Loop in Transit Ticketing with UWB and Wallets

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 smart device (a phone), 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 smart device, 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 smart device, and their hands-free selection broadens the device-level interoperability.

The Universal Ticketing Agent (UniTiAg) cloud ensures the business-level interoperability, where the TA (transit agency) is got paid for the service provided to any smart-device holder. Together, device-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 can start using any transit agency.”

Transit Agency’s User Story:

“As a transit agency, I want to be paid (reconciled) 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 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 because of payment card schemes’ clearing, settlement, and reconciliation services. It is still required, though, that each transit agency is a merchant in several payment schemes.

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 or a ticketing tool (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 smart device wallets such as Apple, Google and Samsung wallets *), 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 device-level interoperability. Additionally, they allow the TA, together with the device wallet, to choose a proper ticketing tool among the ones present in the device wallet.

The UWB specs cannot help with the business-level interoperability. After a proper tool is selected in the wallet, 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 Apple Wallet and UWB

Let’s consider the following example, using an imagined Apple Wallet service. Google or Samsung wallet with UWB capabilities would work in a similar way *).

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.

Ms. Rider creates two OTRBs:

  • OTRB1 – with marketplace MP1. Ms. Rider creates this OTRB using MP1’s app on Ms. Rider’s iPhone. During the OTRB creation, the app interacts with Apple Pay and Wallet on this device. As a result, the OTRB1 is created with a unique Device OTRB Identifier (ID). It is placed in the iPhone’s Apple Wallet. Ms. Rider decides to associate OTRB1 with her PayPal account. Ms. Rider uses this PayPal account as a payment method on marketplace MP1, for regular purchases. MP1 charges this PayPal account for EUR 40, which is the initial OTRB1 value.
  • OTRB2 – with marketplace MP2. This time, Ms. Rider uses MP2’s app on the same iPhone. Respectively, another OTRB with a unique Device OTRB ID is placed in the same Apple Wallet. Ms. Rider associates OTRB2 with her bank’s savings account, which Ms. Rider uses on marketplace MP2. MP2 charges the bank account for USD 40, which is the initial OTRB2 value.

Contrary to the classic open loop where the payment method must be associated with a contactless credit card number, Ms. Rider has a wider variety of choices of payment methods, such as direct bank account debit (covers customers without credit history), prepaid reloadable cards (covers unbanked customers), a cryptocurrency account, etc. The variety of choices depends solely on the TSMP’s payment methods options.

Ms. Rider also sets the Apple Wallet to use the MP2’s OTRB2 first if a transit validator provides both options, that is the transit agency is a seller on both marketplaces, MP1 and MP2.

After that, Ms. Rider is all set indefinitely, without any further friction required for riding with any TA that participates in UniTiAg and sells its rides on TSMPs MP1 or MP2.

Let’s see how the iPhone wallet structure would look like for a typical rider.

The wallet keeps OTRB IDs in two sections: one for UWB-enabled OTRBs and another for cEMV-enabled cards. Some cEMV cards that the rider may have in this wallet are associated with UniTiAg TSMPs, and they have OTRB IDs.

There may be more sections like this, if, apart from cEMV-enabled and UWB-enabled ticketing or payment tools, there are more technological channels supported by the wallet (e.g., QR-code ones, face recognition, etc. – whatever may be implemented in the future).

The Device OTRB ID does not comprise any Ms. Rider’s personal data. The latter belongs to the TSMP and may be shared with the device wallet, but it is never presented to UniTiAg or the validator. This is how UniTiAg preserves personal data protection and ridership anonymity.

Similarly to Device PAN or card number, (DPAN), the Device OTRB ID is unique across the UniTiAg realm, and it is never shared with other smart devices.

In the above example, in cEMV card section, we demonstrate two options:

  • One of the cEMV card images is bound to a TSMP. It can be used in UniTiAg ticketing, as well as in classic open-loop.
  • Another cEMV card image can be used for any contactless payments, including the classic open-loop ticketing. The rider has not set it for using in the UniTiAg system.

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 iPhone 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 iPhone’s Apple Wallet and the ticketing tool selector determine that only the Device OTRB IDs 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 Wallet selects MP2’s OTRB2, as per Ms. Rider’s priority settings, and presents the Device OTRB2 ID to the validator via the predetermined communication channel – UWB. (Some instructions for a rider may be required at this moment if the communication channel is not UWB).
  4. The validator further follows the UniTiAg process to validate the ride, and the gate opens to let Ms. Rider in.
  5. While Ms. Rider is on the subway train, the TA reports the fare and the OTRB ID to UniTiAg, and the latter updates the OTRB amount across all participating transit agencies.

Per the proposed solution, Apple Wallet does not store OTRB amounts. In general, Apple Wallet allow storing e-Money balances. This 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 environment across all validators of all TAs, all TSMPs, and all wallets (Apple, Google, etc.). This would require complex legal relationships and asymmetric (public) 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.

*) this process description does not imply any affiliation with wallet providers.

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 smart device wallet 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:

, ,

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *