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

%d bloggers like this: