We are incredibly proud to announce that Open Transport has made the 2020 Transport Ticketing Global Awards Shortlist. Our work, in creating the first open API specification for transport account interoperability, is in the category of Ticketing Technology of the Year.
The winners will be announced at the Transport Ticketing Gala Dinner & Awards ceremony on 28 January 2020. This will be held in the impressive “Making the Modern World” hall at the Science Museum.
This is further confirmation of how positively the industry is reacting to the work done so far by the Open Transport Initiative. 2020 promises to be a great year.
Thursday 5th December saw Hayden Sutherland present the Open Transport work to a number of Maas Scotland members and other interested parties. This was part of an event called “Data: Fuelling the transport technology revolution”
The purpose of the Open Transport session in the afternoon was to get a wider peer of what has been produced by the initiative so far, with the aim of creating an Open Standard by early 2020
The first part of the session was to:
- Provide attendees with an overview what Open Transport provides
- Explain why we think this innovation is needed
- Go into more detail about what it is we have created (and is not)
- Describe the proposed high-level architecture
- Highlight the timescales for the next few weeks until the specifications become an Open Standard
Hayden then took part in an interactive workshop session (Q&A and more detailed discussion), where different MaaS Scotland members asked questions and contributed thoughts including:
- Similarities to Open Banking and points of differentiation
- Methods of validating users looking to join different transport accounts
- How the Open Transport standard intersects or aligns with other standards
- What the following steps would be & any barriers to achieving this
Overall the group was very supportive of the work done so far. They also acknowledged that this was a first step towards wider market acceptance and adoption of open standards and that more work was now required to develop both the centralised ‘operator-info’ API look-up directory service and create a reference implementation of an account using the ‘customer-account’ API integration specification.
Open Transport would therefore like to extend its huge thanks to MaaS Scotland for all its support so far.
Today members of the Open Transport initiative attended World Rail Festival in Amsterdam .
The World Rail Festival is a global event where over 900 attendees come to meet and discuss commercial strategy, digital transformation, next generation ticketing, customer experience, revenue management, MaaS and smart mobility, stations, connectivity, real time information in the rail, bus and urban mobility sectors.
At this event many different people from across the transport industry got to hear about the work that Open Transport has done and the plans to release two API specifications as Open Standards from early January 2020.
A leaflet was also produced for the event and handed out for further information. This can be downloaded as a PDF:
Given that many people still asked the same questions (e.g. “Why are you doing this for free?” and “Where do I see this?”) it has led us to strongly consider the addition of a set of Frequently Asked Questions (FAQs) on this website.
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.
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.
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!
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…
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:
- ITSO when needing interoperability between all smartcards and smart devices (e.g. ticket gates)
- Open Transport when needing integration & data sharing between different transport customer accounts
The diagram below shows where these two operate.
The Open Transport initiative currently have two different API specifications our for wider peer review:
This is a standard for the interoperability of transport account data. The current data types described are: Purchase, Usage & Concession
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 😉
We have now updated the ‘Customer Account” API Specification to version 0.9.2
This is available to view on SwaggerHub here: https://app.swaggerhub.com/apis/open-transport
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
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.