Today is an important date for the Open Transport initiative, with the official launch of Version 1 of the Open Transport Application Programming Interface (API) specifications and their conversion to an Open Standard.
As we start a new year (and also a new decade) some entrepreneurs and innovative types will be thinking about novel ideas and approaches to transportation for the year(s) ahead. And quite possibly utilising modern technology and maybe even a micro-mobility solution. Therefore perhaps Hayden’s idea of a solar-powered skateboard start-up in Glasgow might eventually become a reality. But we significantly doubt it! 🙂
So if you’re looking to launch a new transport provider or mobility service, here are a few questions you should be asking yourself:
Are you planning to create an online account to enable your customers to self-serve? (e.g. to register, log in, check their status, view their usage and pay)
Are you expecting that at some (any) point in the future your transport service will be part of a wider and integrated mobility platform or proposition?
Would it be beneficial to any of your customers to have an end-to-end view of all their transport contracts and usage
If the answer to any of these three questions if “yes”, the perhaps you should consider adopting the Open Transport account interoperability standard from the beginning. And then implementing this as an API, so that important (non personal) data such as ticketing, journey and discount information can be exchanged. The details are available to view here and from 3rd January 2020 this will be an Open Standards, able to be used without cost.
Plus… if you are serious about your Transport Service account API being found, you could register it with our centralised transport operator API look-up service too. For more details contact: email@example.com
The Open Transport initiative has made some great progress so far. With a range of different transport and data specialists providing feedback on our draft API specifications until the peer review period closed recently.
It therefore looks like we will be able to create a first complete version of our API specifications as-planned for the beginning of January 2020.
So to celebrate the fantastic progress so far and get ready for the coming months… we will be having a launch event in Glasgow on Friday 3rd January 2020.
ABT is the acronym for Account Based Ticketing (or Account Based Travel, to give it a more appropriate name). This is the concept where customers use a central “back office” account for transport, rather than buy individual tickets in advance.
This account allows either pre-pay functionality (where the customer adds funds to the account beforehand and journeys are then subtracted as they travel) or post-pay (where journeys are made and the customer is then subsequently billed for their usage).
Both of these options can also be used alongside:
1. A “best fare” promise, where the customer is only charged the minimum possible amount over a travelling time period (e.g. a day, a week or longer).
2. A multi-modal proposition, where journeys across several modes of transport (e.f. bus, train, subway and even ferry) all get charged back to the same account
In fact, several of the founding members of the Open Transport initiative have experience of delivering an ABT project. Meaning they have first-hand knowledge of both the effort needed to design & implement such a scheme… as well as the potential benefits of such a service too.
And this, in part is why the Open Transport initiative was created. As our founders saw yet another transport system being created that locked Authorities and Transport Providers into a proprietary technology standard or vendor. Meaning that even more silos of customer mobility account & usage information were generated.
And that’s why we are now about to give away all the work we have done in creating a transport account interoperability standard. Why we are creating an Open Standard for mobility accounts to unlock the data held within them, rather than perpetuate the increasing lock-in that could happen as more and more ABT schemes are demanded and supplied.
As well as releasing a “customer-account” API specification (for the consistent integration of purchase, usage and concession transport data), we have also published an “operator-info” specification too.
This “operator-info” is our design for a central transport look-up for both validating key mobility data and providing references to each transport operator’s account APIs, including participating “customer-account” locations.
However, interestingly we have also had enquiries recently from other (non-transport) organisations, asking if this specification could also be applied on a wider scope & regional basis (e.g. as the look-up service for a Smart City, as nothing seems to exist in that space either).
The simple answer to this question is… “yes”.
Once the “operator-info” specification has been peer reviewed and then released as an Open Standard as planned on the 3rd January 2020, it can then be free to adopt and adapt for transport look-up or wider purposes if it suits. (All we ask is that credit is publicly given to Open Transport when either API is used)
Transport & mobility data belongs to the account owner. So why shouldn’t they have quick and convenient access to all their transport account data in the way that they want?
This may seem like a bold claim, especially when so many transport providers are looking to leverage their customer data and monetise their digital platforms. But the travelling customer really should be in control of their mobility account and be able to effortlessly grant, modify and revoke access whenever they want.
Our Open Transport standard for account data sharing therefore specifies 3 different “customer-account” data entities.
Note: None of the data entities we are proposing in our “customer-account” specification are personally identifiable information (PII).
Purchase This can be a Ticket, pass to travel, contract to use a MaaS service, etc.
Usage Journey, parking duration, etc. The specification also includes services consumed when this usage takes place e.g. electric vehicle (EV) charging, in-flight phone calls, etc.
Concession This would be for something such as a Railcard or staff discount scheme. But could also include a pre-paid voucher / coupon, etc.
The integration of different transport accounts owned by the same person (e.g. their rail, subway and electric scooter accounts) is certainly a technical challenge. But one that the Open Transport initiative believe can be overcome, especially if common standards such as open APIs are used.
But technology isn’t the only barrier to overcome. Complete transport account interoperability also needs transport providers to accept they are just part of the complete customer journey.
It also requires different industries such as public transport, transport technology & MaaS platform vendors and even airlines & car parking apps to integrate and work together for the benefit of the customer. Leading to the swifter and easier implementation of an end-to-end Mobility-as-a-Service (MaaS ) transport ecosystem.