Turning MaaS on its head

In earlier posted we have explained how complete account aggregation (across all transport modes, private and public) is not possible, especially in a fragmented and deregulated environment. And how federated account integrations compliment the an aggregated Mobility-as-a-Service model. This can be explained further by turning the typical MaaS scheme diagram on its head and placing the “Central MaaS aggregator platform” at the bottom and placing the different transport providers on top.

This then shows how each of the accounts within the MaaS scheme can still integrate between themselves as well as with a central platform.

However the adoption of a common account interoperability standard would also mean that accounts outside of the MaaS scheme could be integrated too.

Federated accounts provide an alternative approach to transport interoperability

We have previously explained in an earlier blog post how the typical diagram of Mobility-as-a-Service (MaaS) needs to be extended to show the customer accounts of the individual transport providers.

But this situation, made more complex in a fragmented transport environment, means that customer, ticket & journey information data is locked away in each respective transport provider’s systems. It does not provide a joined-up view of multi-modal (e.g. across bus, train, scooter) or multi-provider (e.g. across different operating companies) information.

However, we think there is another way to join this data up, without using an aggregated MaaS platform. A means by which each individual transport provider account can link directly and securely with another.

Shown in this diagram

This federated approach to account integration provides a way of delivering transport account interoperability… whilst at the same time allowing the transport provider to maintain their own account functionality and data. This way the transport provider can still have a direct and managed relationship with their customers, without migrating them to a MaaS aggregation platform.

It is also worth mentioning here that we still think that there is a role for a MaaS aggregator, particularly in a highly regulated / controlled transport ecosystem. In fact, we believe that it is best for a customer if they have a choice. Meaning that there’s the need for both an aggregated and federated approach to account integration, with both working together to ensure that as many modes of mobility are interoperable as possible

Why transportation needs to look to Open Banking for its future

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.

Travel account aggregation doesn’t give the whole picture

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.

Enforcing data consistency in the Open Transport specification

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.

How to make Delay Repay for Rail much easier with an Open Transport API

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.

Deciding upon an Open Transport look-up service

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.

Building the Transport Account API Roadmap

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.

Creating a joined-up picture of customer mobility

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.