It’s not often that transport & mobility looks too far beyond the comfort and confines of our own industry for inspiration. But there’s a recent revolution going on in the Financial Services industry that has been transformative for the customer (and consequently has a serious impact on the providers).

In the last year and a half, since January 2018, the larger banks in the UK (and in Europe) have been mandated through regulation to apply changes to their systems. This initiative has forced the major players to allow integration between their customer accounts. Called Open Banking (also known as PSD2), it puts the customer in control of their finances by allowing them to use the provider they want to view and manage their financial details.

Open Banking was intended as a programme designed to open up banking data. It’s intended consequence in the UK was to force the biggest banks to make their online banking account information open yet secure in a standard manner. And some 18 months on it has been seen mainly as a success, although its not been entirely plain sailing.

One other consequence of this initiative has been to make this rich source of data available to other trusted 3rd parties. New players (e.g. FinTech startups and non-bank innovators that recognise the opportunity) who have created different services, such as money management and reporting products.

But now the time has come for transport to take a leaf out of banking’s book (is that a cheque book?) and adopt a similar approach. By allowing different transit or mobility accounts to integrate with each other using a common open standard.

In the same way that Open Banking has pushed the UK’s nine largest banks and building societies towards having have interoperable accounts… we believe that both public transit providers, private transport operators and mobility-as-a-service companies must now do the same.

The definition of Mobility-as-a-Service (MaaS) is not uniformly agreed in the transport and transit industry. In fact, on the subject of self-service account provision, there is a significant device. Many MaaS aggregation platform vendors and some transport authorities/regulators believe in the utopian vision of a single mobility account for all transport providers. Whereas the individual transport providers usually want to maintain and grown the accounts they have (and the data and marketing permissions they have access to). Justified by the need to build an ongoing relationship between the transport provider and their customers… usually with the expectation that this will help them build insight and grown revenue.

MaaS is us shown in a version of this diagram

Here, the MaaS aggregator sits between the transport providers below and the customer above (perhaps via an array of further MaaS Providers). Thus delivering a single point of access for all: journey planning, booking/buying and customer account functionality.

But there is section missing from this diagram, based on the assumption that the Transport Providers themselves do NOT have their own self-service functionality and therefore do not each have online accounts for their customers to access their services directly.

But they do… and in a fragmented transport ecosystem, each individual transport provider has their own separate account (usually even if they are part of a larger operating group).

This means that the typical MaaS diagram needs to be extended out to show this:

And these existing transport provider accounts are used by customers (albeit to varying extents) for them to look, book and manage their respective mode of mobility.

As part of creating the Open Transport standard, we have considered how the data exchanged via the API will be enforced on an automatic and day-to-day basis (in other words, without human intervention).
Our concern is that without any enforcement the standard wouldn’t be trusted and therefore might not gain the full adaption it needs to.

But luckily there are several ways to govern the data exchanged within an interoperable technology standard, each with their benefits and potential stumbling blocks:

Centralised look-up

This is where at least some of the reference data is managed and accessed in a central hub. This hub is an easy way to ensure consistency of the standard, as every party that implements it has to use the centralised look-up service in some way. Changes to the look-up are protected by restricting update access and only providing read access to the reference data. However it means that the hub needs to be highly available and potentially capable of dealing with many consecutive requests (if the standard is popular or the implementations are too “chatty”). Note: availability can be significantly improved by simply having a duplication of the central hub data just replicated in another location.

Decentralised look-up

This is where every implementation of the standard has a copy of the reference data and they also become a hub. Updates to every decentralised look-up are propagated out to the other participating parties. This allows for a far more fail-resilient solution that is not dependant upon a single central service. However the consistency of the data at each replicated look-up implementation must be maintained, or there is the risk that an error can get into the system and propogated out. Plus any delay in the propagation of the data means a potentially inconsistent service.

No centralised or decentralised look-up

This is where enforcement of the standard is done just by each implementation, but with no look-up. This means that any new implementation can be created quicker, does not have to wait for a central hub to be initially updated & checked and also does not have to bother hosting or maintaining a decentralised look-up service. But for obvious reasons this approach has the greatest likelihood that the standard will not be enforced correctly or fully, as each implementation done this way is dependent upon how closely the developers want to follow and test things.

As already mentioned in a previous blog posting, the Open Transport team have for now chosen to use a centralised look-up service to maintain strict enforcement of the standard.

For those who are not familiar with the term “Delay Repay”, it is an existing scheme across UK rail operators to provide financial compensation when there is a delay to a customer’s journey.  (You can also get a refund if your train journey is cancelled)

But, although Delay Repay is a national scheme, some train operating companies have different scenarios when Delay Repay is triggered (some after a 15 minute delay, others after 30 minutes). Plus there are also different conditions & ways for claiming a fare back too.

In short, it is rather a complex customer process (sometimes not made that obvious by every train operator) that can use some rather clever technology behind the scenes to match claims to delays. This technology includes: Optical Character Recognition (OCR) of a train ticket image uploaded to a website and ‘fuzzy’ matching of any delay times with historic DARWIN train running information.

The need to comply with the Delay Repay scheme means that Train Operators either have to develop and provide this service themselves, or partner with a compensation scheme service provider (CSSP). In the latter case, the rail operator then has to provide the CSSP with direct access to their rail booking systems, to allow claims to be processes on their behalf.

But what if a customer account for every operator used a standard method for integration? What if there was a consistent way of providing secure external access to the required ticket and journey information in an account to process a Delay Repay claim?

This access could then allow a CSSP to integrate with a customer’s account and even create a permanent agreed link between these two parties (that either could break whenever they wanted). This would mean that not only could the CSSP validate the data for the journey the customer is claiming for, but by creating this permanent link… they could also process any subsequent delay claims without manual intervention in the future.

For every rail customer across the UK the impact would be huge!

Each delayed customer (with such a link enabled) could then benefit from an automated Delay Repay service. A reversal of the old ways, now flipped around so the customer does not have to instigate every claim when they are delayed. The CSSP would then just have to match the feeds they already get with every delayed ticket data they have access to, plus any available journey information (if only to prove that the customer was indeed travelling on the train service being automatically claimed for).

The impact for the transport authorities would also be significant too. Consistent implementation of an Automatic Delay Repay scheme is something the UK rail industry has been aiming for. This vision can now be facilitated by the introduction of a uniform integration standard.

The implementation of an open API to facilitate consistent secure access to every rail customer’s account has other implications too. The complete adoption of the standard would mean that theoretically the entire UK rail industry would only need to use one CSSP. It could therefore centralise around a single best-of-breed service.

Or more frankly put… the first CSSP to ensure that their systems can fully integrate with an Open Transport API specification would find themselves at a significant advantage in the UK rail market.

The team who are busy creating the Open Trasport API standard have recently spent time discussing whether there is the need to have a look-up of reference data for the standard. An example of this data would be a list of participating transport operators and their account locations (e.g. URLs).

Unlike the global banking system (which the Open Banking initiative is based upon and which is similar to what we are looking to achieve) there is no central sort-code register equivalent for every transport/transit operator.

Therefore some sort of central way to look-up even basic information seems like it is an inevitability.

Taking the decision to create an Open API specification for transport account interoperability was a great first step. However we also appreciate that:

1. We cannot build out a complete API instantly, as it needs consideration and input from a number of different people (ideally subject-matter-experts for each relevant mode of transport / mobility)

2. There is the initial priority to focus on an aggregated view of basic travel account information, before moving on to more complex / richer functionality that may need wider specialist input & validation.

Therefore we have created an initial roadmap of the most likely features that the API will support. This has been broken down into three distinct phases.

Note: At this point we are not giving specific timescales for each phase. Nor are we fixing any of the features beyond the first phase, as this may change as we get specialist & industry feedback.

What we have also decided is not to get involved (in the short term) in the integration of travel accounts and payment services. This will leave transport operators to currently process their own payment transactions in any way they want (transfer, cash, credit card, etc. ) until such time as Phase 3 becomes more of a reality.

Each time a person uses a transport service they can create a trail of data behind them. This trail is particularly rich when technology is used as either the medium for purchasing (e.g. a credit card or online payment service) or when used for the actual transportation (e.g. a ride sharing app, a smartcard, etc.).

But what happens to this data when reservations or tickets for different modes of transport are purchased on multiple websites, apps and kiosks? And what is the impact when journeys are taken using different combinations of buses, trains, subway, car share, etc.?

This data ends up scattered around a number of databases or information stores run by each transport provider. Which then creates an issue:

The Issue:

The customer doesn’t have a joined-up picture of their own purchases/tickets and journeys made.

The Solution:

The Open Transport API has been created to provide a standard for the interoperability of any transit service / transport provider account. It allows this fragmented data to still be stored in different systems, whilst also providing an aggregated view of this data in the account of the customer’s choice.

Following recent contribution from transport subject-matter-experts (SMEs) and technical specialists, we have now update the draft API Specification.

This draft is currently at version 0.2
https://app.swaggerhub.com/apis/open-transport/p-customer-account/1.0.2

Note: This API Specification is not yet at a peer review stage. If you would like to be involved please contact us

We believe that the use of an Open transport API will facilitate the standardisation of digital account integration for transport providers. Which will in-turn help to bring true interoperability of data, such as ticketing/purchase and journey information.

But the private sector transport cannot implement this initiative alone. It requires universal support to make the change towards a workable MaaS (Mobility-as-a-Service) multi-modal multi-operator model for all customers. Thus helping to shift people towards mass transit that will reduce emissions and deliver health benefits for society.

More active means of travel are only going to become more prevalent across entire transport networks in the future. With journeys being made via car-sharing, sustainable transportation and potentially other more innovative schemes (e.g. powered scooters) . But this requires a collective embracing of an Open Standards for account interoperability across the combined private and public sectors.

We therefore think it is an obvious role of any Transport Authority to widely encourage the use of a open standards for transport accounts. With the eventual aim of delivering true data interoperability and reducing barriers to customer adoption.

Or put a different way… every Transport Authority needs to ensure that they do not stifle development in newer integration technologies and provide direction & help in making sure that consistent inter operable transport standards are adopted and maintained.

Mobility-As-A-Service (“MaaS”) is the concept that users of transport or transit services migrate away from personally owned means of transportation and adopt an on-demand & pay-per-use service instead. This shift in behaviour (and potentially billing) means a user can then choose their preferred trip based on: cost, time, environmental factors, convenience or a combination of these.

But how does the creation of an Open API for transport account interoperability forward the aims of Mobility-As-A-Service?

1. A clearer view of online transport accounts
   The aggregation of accounts via single interoperable standard API would give consumers the ability to quickly, simply and efficiently consolidate all their accounts into one place. E.g. to use one chosen online travel account for viewing information about all other modes (e.g. bus tickets, rail carnets, etc.).
   There is even the potential opportunity to allow new services into the market, in the same way that Money Dashboard (https://www.moneydashboard.com) uses Open Banking technology to give consumers a ‘unified view of their finances’ and is called an Account Information Service Provider (AISP).
   
2. Removing barriers to MaaS adoption
   It is anticipated that by creating an easier way for consumers of travel services to access multiple accounts online, that they are more likely adopt it and use it. Therefore by removing the need to sign-up or remember new account details for every different MaaS provider, a key barrier to the use of multiple mobility service is removed.
   
3. Reducing the cost of innovation
   Providing anything from scratch is usually quite hard, whereas copying or adopting what already exists is easier. IT Departments or their suppliers don’t have to spend time and money coming up with a new way to integrate with another travel account.
   Plus the benefit of an Open Standard is that, should it need changing or enhancing, this can be fed back into the standard too.