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.
A person’s journey (e.g. making their regular commute to work) does not start and end when they board and get off a bus or train. For most travellers there is also additional travel taking place (e.g. when they leave the house to get to the stop or station and when they continie their onwards journey at the other end to get to their work place).
In some cases these additional pieces of travel are on foot. But in other cases these are made by taxi, ride share, electric scooter or even another bus or train.
In a fragmented transport environment this therefore makes it rather hard for the travelling customer to piece together their entire door-to-door journeys made using more than one mode of transportation. Typically needing them to log into and view multiple online accounts at the same time.
What we are therefore developing at Open Transport is a way to link these different transport provider accounts for the same individual. Once linked, they can then log into an account of their choosing and get a much better consolidated view of their end-to-end journeys (plus their tickets purchased and any discounts they are entitled to)
We have been asked what our timescales are around delivering an Open Standard, so we thought we would be completely transparent about our aims here.
Note: The current work to create both API specifications (‘customer-account’ and ‘operator-info’) are the intellectual property of Ideal Interface. This will change when version 1.0 of the Open Standard is created.
14th October 2019 (International Standards Day) Draft ‘Customer-account’ API specification v0.9 issued for industry peer review
4th November Draft ‘Operator-info’ look-up API specification v0.9.1 issued for industry peer review
20th December Final date for feedback and questions
3 January 2020 Launch of v1.0 as Open Standard. This will also be be when there is the official handover of on-going management and further changes of specification & documentation from Ideal Interface to a new ‘Open Transport’ organisation.