Open Transport and ITSO

Whilst receiving feedback about our evolving customer account API specification, we have also had some people ask us how the Open Transport standard for secure account integration works with ITSO. Therefore we thought this post should clarify things…

Open Transport
The Open Transport standard for customer account interoperability facilitates the integration of different transport operator accounts owned by the same individual. Once linked, the standard allows a person to view all purchases, usage and even concessions (e.g. discounts and railcards) in another account.

ITSO allows transport authorities or operators to put different tickets and concessions onto a range of compatible plastic smartcards (and now mobile devices). This provides a wide selection of card, ticket and concession possibilities, plus means the customer doesn’t need to carry multiple smartcards around with them.

However, the ITSO standard does not assume that the user has a self-service account (although this can be useful) and in many cases works perfectly well without one.

Therefore the two standards work well together, but for two different use cases:

  1. ITSO when needing interoperability between all smartcards and smart devices (e.g. ticket gates)
  2. Open Transport when needing integration & data sharing between different transport customer accounts

The diagram below shows where these two operate.

Why peer review of a standard is important

The Open Transport initiative currently have two different API specifications our for wider peer review:

1. Customer-account
This is a standard for the interoperability of transport account data. The current data types described are: Purchase, Usage & Concession

2. Operator-info
This is a standard for a central look-up service for all transport /mobility. Its main purpose is to act as a transport API directory service that can be queried to provide the URLs of each participating operator (including the location of each Customer-account API).

Our plan is to circulate these specifications to as many transport industry representatives as possible over the next month, get feedback, make all agreed changes and then issue both as “version 1” in early January 2020.

We want this initial release to be as correct as it can be . We also want it to be as useful as it can be to as wide a range of transport operators. Therefore we need the maximum number of technical and subject-matter-experts in each transport mode (bus, ferry, escooter, taxi, ride-share, etc.) to review what we have done, ask questions and provide feedback or suggested amends.

And of course, the more people that look at it now… the less changes we will potentially have to make subsequently 😉

Customer Account API spec update to v0.9.2

We have now updated the ‘Customer Account” API Specification to version 0.9.2

This is available to view on SwaggerHub here:

For this update we have added to the “usage” entity potentially any number of “services” that are consumed. Each ‘service” each having a “type” and “amount”.

So as well as expecting to cover “services” such as free & paid for Electric Vehicle (EV) charging, we think this covers other wider purposes, including in-flight purchases on aircraft.

Note: The “Operator Info” API specification has not changed and currently is at version 0.9.1

Open Transport Customer Account API now available on ProgrammableWeb

We have submitted our “Customer Account” API to ProgrammableWeb, the world’s leading source of news and information about Internet-based APIs and this has been accepted.

Details can be found here:

Note: This version submitted (v0.8.1) was the one issued for wider industry peer review and ratification. However it has been updated since, based on some immediate feedback.

Therefore our plan is to submit a further version once we have a ratified v1.0 standard for this API (and the operator central look-up API) towards the very end of 2019.

The problem with a dis-aggregated transportation network and why one MaaS Platform is not the answer

Residents and visitors of cities, regions and even countries often face a dis-aggregated public transportation network (what we have alternatively called a fragmented transport landscape). Making it more difficult for them to move around without resorting to private transport modes that are typically higher carbon producing than their mass transit competitors.

So the idea of Mobility-as-a-Service (MaaS), providing the means to plan, book and pay for transportation through a single platform and payment system , looks attractive. The Utopian ideal is that it will be possible in the future to do away with a personally-owned car at some point. And instead rely upon an ever-changing collection of mobility services made up on those private and public providers.

But unfortunately the reality of the situation with urban and suburban transport is that, when some public transport providers (e.g. rain, subway and buses) are merged together into a single MaaS platform and even when some private providers merge their services (e.g. taxi and eScooter, as in the case of Uber)… it is not technically or commercially realistic to link all these providers in the same proposition. Meaning that regular commuters or less regular tourists & visitors have no central account to view all their transportation activity.

Even if you had a Transport Authority that (through carrot, stick or Jedi mind trick) combined the top 10 or more providers of mobility in a region or country into an aggregated platform, you may still not have a significant number of the smaller (typically private) transport providers that make up the entire mobility ecosystem.

Which may actually be anti-competitive.

Benefits of Open Standards in Transport

Open Standards are useful when developing a technical system. They help to ensure that one application can work with another application in a common way.

They therefore provide flexibility to the solution, as they enable:

  • Data to be shared
  • Software to be written by different people or organisations
  • Components to be reused and adapted
  • And remove lock-in to a particular vendor or specific proprietary technology

In short, they give the owner (e.g. the person specifying / commissioning the system) the option to pick from different best-of-breed components that work together. Thus making switching one or more parts of the solution less difficult (e.g. expensive) at a later stage – potentially from smaller-sized vendors.

The transport industry owes a lot of its improvements to early Open Standards, without many people realising it:

  1. The standard gauge railway, still used around the World today, has been based around the same width of rail tracks adopted by George Stephenson around 1830
  2. The 3-point car seat belt was invented by Nils Bohlin at Volvo (just over 50 years ago now). But the patent was given away to the rest of the automotive industry for free, as it was recognised that this innovation has the potential to save so many lives… and has done since.

Now, we at the Open Transport initiative are not saying that our work on transport account interchangeability is life saving. But the adoption of the Open Standard for customer account data could save time & effort and remove some vendor lock-in.

The first API Directory for Transport?

Devising a centralised transport operator look-up service has been an interesting output for the Open Transport initiative (as well as creating the actual customer account integration API). But it wasn’t something that we originally anticipated that we would need to do. It was just something that we identified along-the-way as being necessary for true interoperability across multiple operator accounts.

This has resulted in us publishing a draft API specification for this service here:

In the past we have compared this transport look-up service to the Sort Code or BIC/SWIFT reference used in Financial Services. This was the closest common reference we could find to describe what we wanted to do. (Yes, there are other less well-known API services in banking, such as the newer PRETA Open Banking Europe directory )
And after some research we realised that what we actually wanted to create was something that resembled a combination of:

  1. A Sort Code / IBAN API look-up service E.g.
  2. The City of Los Angles transport MDS (Mobility Data Specification) reference file:

So what we have actually ended up with now is (we believe) the specification for the first API Directory for Transport, delivered as an API.

User Experience principles for Open Transport adoption

When creating the Open Transport API and its associated documentation, it would have been easy to fall into the the trap of just of just focusing on the technology tasks.

However, it was also a key consideration of the team to consider the User Experience of those systems that have adopted the Open Standard for transport and transit account interoperability.

We therefore followed (and will continue to follow) these principles wherever possible:

  1. Secure & trustworthy
    This is customer data we are dealing with (albeit not PII : Personally Identifiable Information) so ensure that the solution can securely integrate and transfer the correct data – and make it clear to all that it is safe to use.
  2. Understandable & usable
    Don’t create a solution that is too complex to initially set-up or maintain.
  3. Customer choice & control
    The user should be fully in control of what accounts they integrate and know what data will be shared. They should also be allowed to break the integration whenever they want.
  4. Seamless
    This integration is additional functionality that a user will see in their transport account, so try not to make it different from what they expect (e.g. avoid presenting jargon or technical stuff back to them).

Note: When using the term “User”, it is generally accepted that this refers to the end user of the solution (e.g. the customer using a browser). However, as this is a technical standard, we also wanted to ensure that we also made things as useful as possible for the technical user (e.g. the architect or developer) responsible for implementing the specification too.

API Specification v0.9.1

Today there’s two updates to the Open Transport API:

  1. The creation of a new centralised operator look-up API (following our recent decision to create an API that will act as a directory of each registered mobility operator). This has been given the name “operator-info” and the specification set at version 0.9.1
  2. An update to the “customer-account” API Specification, also now at version 0.9.1

Both are available to view on Swaggerhub here:

And we now invite anyone to review both these updated API specifications and provide their thoughts and feedback.

An improved user experience with interoperable transport accounts

One of the expected benefits of an interoperability standard for transport accounts is the improvement it gives the end user.

Suppose you are a traveller who uses 6 different transport services on a pretty regular basis. This means that (aside from how you plan and buy your tickets) to get a collective view of what purchases you have made and the journeys taken… you need to log into each individual account separately every time you want an update. You then have to somehow compare the details in each screen.

However, if the user was able to link their different transport provider and MaaS platform accounts together (yes, they will have to log-in to each to associate them first) then subsequently they could log into any one of them and get a collective view of all their transport tickets, journeys and concessions.