Author Archives: Ideal Interface

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 …

Continue reading “Turning MaaS on its head”

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 …

Continue reading “Federated accounts provide an alternative approach to transport interoperability”

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 …

Continue reading “Why transportation needs to look to Open Banking for its future”

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 …

Continue reading “Travel account aggregation doesn’t give the whole picture”

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. …

Continue reading “Enforcing data consistency in the Open Transport specification”

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 …

Continue reading “How to make Delay Repay for Rail much easier with an Open Transport API”

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 …

Continue reading “Deciding upon an Open Transport look-up service”

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. …

Continue reading “Building the Transport Account API Roadmap”

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.). …

Continue reading “Creating a joined-up picture of customer mobility”

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.2https://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