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.
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.
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:
- 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
- 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.
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 https://www.openbankingeurope.eu/directory/about-the-obe-directory/ )
And after some research we realised that what we actually wanted to create was something that resembled a combination of:
- A Sort Code / IBAN API look-up service E.g. https://www.sortcodes.co.uk/sort-codes-api
- 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.
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:
- 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.
- Understandable & usable
Don’t create a solution that is too complex to initially set-up or maintain.
- 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.
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.
Today there’s two updates to the Open Transport API:
- 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
- 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.
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.
Our aim for the Open Transport Initiative is for it to be adopted as a standard by as many transport operators and MaaS platforms as possible. It is why we plan to make v1.0 an Open Standard and freely available without conditions or constraints.
“So what do the participating organisations expect to get out of it?” Is a common question we get asked.
The simple answer is that we believe that an interoperable standard for transport accounts has been a long time coming, too long. And when speaking with end users (the travelling customers) about what we are creating, many assumed that such a thing already existed and is being used.
The work to create the API Specification to the current version (v0.9) has had valued contributions from many different people within the transport and technology sectors. Each have understood that their effort has no actual reward and even that (in theory) someone nefarious could: come along, take what has been done already, slightly change it and publish it as their own proprietary standard. But that hasn’t stopped us doing it anyway.
However, as one of our founding team has said many times already:
“The Chinese have a phrase ‘the best time to plant a tree is 20 years ago, the next best time is now’. We are therefore planting something out in the open for the benefit of transport account interoperability. With the hope that it will grow and evolve over time”
Yes, for some who want to create lock-in and further silos of customer data, the idea of adopting this Open Standard will be scary.
For those who see the Open Transport initiative for what it is (a benefit to the end user and a way to save technical time & effort) they realise that it’s a treat we have given the entire mobility industry.
The incremental delivery of the the Open Transport initiative has been the plan since it started. Trying to deliver (what we believe) all the functionality the transport industry needs at once
- Would not be realistic, given the limited resources of the founding team
- Does not allow for flexibility in delivery over time, as our understanding of user and industry needs
We have therefore agreed to have 3 phases, with the basics delivered in Phase 1 across just five use cases:
- Link accounts
- Un-link accounts
- Read Purchase (e.g. ticket)
- Read Usage (e.g. journey made)
- Read Concession (e.g. discount)
We did originally consider other use cases around end-to-end journey planning and best fare calculations. But the market for this is already mature / crowded.
Our agreed phased roadmap is therefore more focused on developing the interoperability between a customer’s individual transport accounts, with an evolving richness of functionality
The complete roadmap is shown here:
We have been asked if it is possible to list out the possible benefits of releasing and adopting a standard for transport account interoperability. So here are a few we have come up with:
- Mobility-as-a-Service (MaaS) needs to provide a joined-up view of transportation made across multiple modes to the customer. This is especially relevant in more fragmented/ deregulated markets where the details of tickets, journeys and other data can be scattered around numerous accounts.
- Bespoke integration between systems and applications create lock-in between transport providers and their vendors, meaning there is reduced flexibility in implementing best-of-breed solutions.
- Open Standards for APIs save time on the analysis and specification of technical interfaces (we’ve therefore done the work in advance)