The disruption of transport

Every industry is seemingly being disrupted right now. It seems as if there is almost an inevitability about it, regardless of whether this disruption is commercially viable or not.

And disruptive start-ups have to start somewhere, typically by taking revenue or customers away from more established brands. Meaning that market fragmentation is an almost inevitable consequence:

  • Challenger banks entered the financial services market to take business from the High Street banks
  • Tesla look custom away from traditional car manufacturers by providing innovation, distance, style and performance from electric cars

And transportation disruption is now upon us. Uber is worth around $100Bn (yes Billions!) and eScooter companies like Bird and Lime are scooping up users and propelling them along urban tarmac near you. Meaning that there are more & more online accounts being created for each & every mobility service.

What Open Transport is therefore trying to do is create a way to put the customer back in control of their transport data.

By allowing them to use the online account of their choice and to securely link it to their other transport accounts. In this way they can have a central view of all their tickets, journeys and travel discounts, without having to log into each account separately.

So even if the transport market becomes increasingly fragmented, the data can all be integrated in the account(s) that the user wants.

Updating the Open Transport roadmap

In an earlier post, we showed our roadmap of intended functionality, broken into 3 phases. Since then we have discussed the possibility of adding a third data entity to the first phase: concessions (in addition to tickets and journeys).

Concessions, also called travelcards/railcards or entitlements provide a discount across one or mode modes of transport – mainly public transit.

This additional entity was felt to to be sufficiently important to add to the initial release of the specification as we believe that not having it would be a further barrier to the adoption of account interoperability… especially in a younger demographic, who tend to be early adopters of technology.

Modern mobility needs account interoperability

The way that people now travel in rural areas, suburbs and cities has changed (and will change further and more quickly) as customer needs have evolved and mobile technologies have gained increasing acceptance. Transportation users have become more used to mixing modes that combine mass transit such as rail, subway and bus services with more private services, such as car & bike sharing, scooter and other micro-mobility initiatives.

Each of these services now typically provides an online account to plan, book, view and manage each mode of transportation separately. Rail tickets and journeys can be viewed in a user’s train account, bus journeys are stored in an online bus account and individual car hire websites just show the bookings made for their vehicles. There are exceptions (such as Uber, which now allows other services such as electric scooters to also be booked within their App), but the usual situation is still “one mode, once account”.

However, as transport increasingly moves to more of an on-demand proposition, which should ideally provide the best end-to-end (door-to-door) solution in the cheapest, easiest or greenest way… the old data silos created for each mode are going to be an issue.

Data about a user’s complete journey therefore either needs to sit in a central (aggregated) account, or the individual accounts need to find a way to integrate between themselves (federated) and share the necessary data to provide a single joined-up view.

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.