Open Transport presents to Ticketing Card Forum

Today (3 December 2019), Hayden presented the work of the Open Transport initiative to the Ticketing Card Forum (TCF) in London run by Smartex.

At the event, he explained how Mobility-as-a-Service (MaaS) is maturing as a concept, that transport start-ups are growin in number & market share and that Maas platforms across cities and regions are evolving

However the expansion of the mobility market also creates issues. In that each new entrant into the transport market is a new source of customer data, each new MaaS platform creates its own customer account AND introduces proprietary integration standards. Plus at the same time the existing transport providers are enriching their self-service accounts to provide a better user experience AND build a relationship with their customers.

He also explained that Open Transport has published both draft API specifications for industry peer review and that by 20th December all feedback and questions were expected. This gives a small amount of time over the Christmas holiday period to finalise the specifications ready for v1.0 and its release as an Open Standard.

Where else do federated accounts exist?

Open Transport is based upon the idea that that different transport and mobility accounts owned by the same individual can be integrated together in a federated manner. This means that the Transport Provider can still have their own customer account and that is does not need to be merged up into one super account e.g. as part of a Mobility-as-a-Service (MaaS) Platform.

In fact, our ‘Customer-account’ specification allows Transport Provider and MaaS Platform account data to be interoperable… even if they are based on entirely different technologies and from different vendors.

But where else does this federated approach to account integration exist?

Well this is easy, its Open Banking. Initiated in January  2018,  legislation was introduced that the 9 biggest UK banks must release their data in a secure, standardised form, so that it could be shared more easily.

Since then, APIs have been published for read/write account access. This has then allowed the secure data exchange between accounts whilst preserving the all-important bank & customer relationship. But still allowing the customer to view their account transaction history and to carry out other functions from within the account of their choice.

Why we decided to create Open Transport

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

This works in the same way that Open Banking does for bank accounts – where a person can link one current account to another. Meaning they do not need to log into both accounts at the same time to get a joint view of their complete financial transactions.

Our standard does not directly deal with transport ticketing or financial transactions, other standards do that very well. It simply provides a means of remotely viewing the transport data (including ticket / purchase data) stored in the system of each different participating transport operator.

The team behind this initiative decided to design a standard for the entire transport industry, not just for one vendor. Something that, when mature enough, can be released an an Open Standard. Creating a free-to-use and consistent way for accounts provided by different suppliers and technologies to integrate and share transport data.

We think the transport industry needs this innovation, so we created it!

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.