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.

An Open Transport account standard can potentially be used for many different purposes (some of which we may not even know about yet).

Some examples of account interoperability could include:

• Enable a customer to view the details of a joint rail & subway or a combined bus & ferry ticket
• Presentation of all transport permutations taken as part of a MaaS (Mobility-as-a-service) system, especially in a fragmented or deregulated transport provider network
• Allow new services to be created that provides a single “transport dashboard” view of all participating accounts
• Reporting back to the customer or operator the environmental / green impact of their total journeys
• As the basis of a multi-modal gamification service (e.g. in the same way that smart energy meters now encourage customers to use fuels more efficiently & cheaply)
• Collation of all unpaid journeys or tickets in one central place and then used as the basis if a multi-modal Account Based Travel (ABT) or ePurse proposition

This standard can also either be adapted into existing systems or used as the basis for new ones.