Thank you for Subscribing to CIO Applications Weekly Brief
A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.

Head of Revenue Management
Dr Michael Kuperberg, Chief Architect Blockchain and Dlt Solutions, Moritz Von Bonin, Head Of Blockchain and Dlt Solutions, and Jörg Strubberg
Blockchain-based Mobility-as-a-Service Platform with Instant Income Disbursement


When designing our new, blockchain-based platform for Mobility-as-a-Service, we started with a business case to improve the “back-office” operations and to make it easier to create end-toend journeys involving multiple carriers. But the first questions to ask are: what is already available in the market, is blockchain the right technology for this, and why is decentralization a key topic here?
It is clear that blockchain-based solutions must avoid technology lock-in, since it leads to vendor lock-in and consultant lock-in - such a situation is often the case when a company wants to sell a self-developed product based on a niche platform
Blockchain Consortia and Decentralization
TradeLens, Food Trust and Marco Polo are working manifestations of cooperative blockchain based consortia which run business networks in production and not just as pilots. TradeLens and Food Trust are supply chain management solutions based on open-source Hyperledger Fabric blockchain; Marco Polo is built on R3 Corda. However, there is no blockchain consortium for transportation or decentralized Mobility-as-a-Service (MaaS).
Decentralization means that there is no single all-powerful party with elevated rights: business network members participate in a transparent, consensus-based decision making; participants also have an authoritative replica of the shared ledger data.By storing the shared business rules on the blockchain, participants can verify data changes against the tamper-proof business rules. Blockchains and Distributed Ledger Technology (DLT) form a building block in an enterprise landscape of applications and platforms – and it is essential not to reinvent the wheel, but rather to forge meaningful cooperations.
Users of public transportation want a fair pricing model and a seamless experience, whereas the transportation providers need a reliable source of income and adequate information about travel patterns. Many transit users have come to expect “flat tickets” which are honoured by multiple carriers as long as the ticket’s validity in terms of time and area (e.g. zones) is observed by the users. In many regions, “tariff unions” are organizations enabling this. A MaaS platform to create a seamless experience does not start with another shiny new app that competes for a user’s attention. It starts with collaboration between mobility providers which might otherwise compete with each other. When such collaboration is codified into rules, the MaaS platform may provide a single ticket for a multi-leg journey – even including carriers which have dynamic pricing (such as airlines) or distance-based pricing (such as taxis). In the past, creating such multi-leg setups required intensive coordination behind the scenes, and carriers would have to endure until their share of income was disbursed.
For transit, the income from “flat tickets” is traditionally shared by the carriers based on rules for “revenue sharing” – and these rules are frequently independent of the actual carriers involved in a specific trip, and from the precise. In other words, the ticket revenue is disbursed following pre-agreed business rules and approximations, even though these do take into account which outlet has sold the ticket (to reimburse the seller’s overhead).
Thus, to improve the carriers’ cash flow, income sharing should be fast and transparent. However, many pre-existing solutions have been designed for monthly (“batch”) runs, and involve rudimentary tools with minimal auditability and traceability. We strive to improve these processes using blockchain technology, introducing transparency and tamperproofness.
The architecture of our Mobility-as-a-Service (MaaS) platform is API-oriented so that different vending sources (e.g. apps, TVMs, staffed outlets, etc.) can be combined. Encouraging participation from any transportation modes (air, land and sea), the MaaS platform supports complex, multi-mode tickets (incl. flat-priced “packages”) but also simple, single-mode tickets (flat-priced or distance-based). Whenever a ticket is sold, the participating providers are immediately credited with their share. Additionally, we provide white-label apps for travellers and for fare inspectors.
Choosing Technology and the Organization
The ticket rules are encoded as smart contracts, and information about a sold ticket is recorded in a GDPR-compliant manner and with visibility restricted to those providers which have an (income) share in the particular ticket. The providers have the ability to host a ledger node with their own replica of the data which is visible to them. Through a modular design, information about actual payments can be exchanged through interfaces, i.e. end-users and transportation providers do not work with cryptocurrencies.
It is clear that blockchain-based solutions must avoid technology lock-in, since it leads to vendor lock-in and consultant lock-in - such a situation is often the case when a company wants to sell a self-developed product based on a niche platform.
Therefore, we were determined to choose a technology that has proven itself on the market, has a large pool of educated developers, and which can be deployed in a consortial way (i.e. in a permissioned network). Thus, we have chosen Hyperledger Fabric, and the initial version of our MaaS platform was developed in partnership with IBM, starting with the income sharing module.
As the next steps, we are establishing a consortial setup that empowers platform participants to co-govern the platform design, its operating rules, and serves as the foundation for seamless tickets – with a seamless income sharing in the backend.

