AMPLIFY  VOL. 35, NO. 8
  

The recent succession of global crises shows us why it is so important to become more sustainable, adaptable, and resilient. For cities, regions, and even countries, mobility has a fundamental role to play in achieving those objectives.

The concept of Mobility as a Service (MaaS) that emerged nearly 10 years ago has the potential to shift mobility in the right direction. A digital channel letting users plan, book, and pay for multiple types of mobility services could offer access so convenient and beneficial that it would trigger the demise of the private car. But even in places where MaaS was deployed in the most innovative way, this hasn’t happened to the expected extent.

In our 2021 Arthur D. Little (ADL) report on the promise of MaaS, we wrote:

Several more years and multiple further attempts at defining appropriate market models, enabling regulations, and value propositions will however be required to test and learn what are the required ingredients — and the order in which they need to be added to the mix — for the MaaS concept to be able to deliver on its promises. Successful design and deployment of MaaS should be considered as a journey requiring a comprehensive approach, including strategic, technical, regulatory, and change considerations.¹

In this article, we will go through some of those key considerations and shed some light on crucial technical implications.

Traditional MaaS Approaches Have Failed

MaaS has historically been driven by business-to-consumer (B2C) actors, public transport operators (PTOs), and transport organization authorities (OAs). B2C actors were user experience–focused but lacked the necessary foundation to enact their vision, while PTOs were often driven by the need to ensure the enduring relevance of public transport alongside the emergence of new types of mobility service providers (MSPs).

Both approaches focused on a partial view of the puzzle. Consequently, an outright failure to consider the needs and constraints of all involved stakeholders (mobility users, OAs, MSPs, and actors in the wider mobility ecosystem) led to most MaaS deployments implementing partial use cases. In the absence of robust coordination between stakeholders, they ended up implementing whatever was technologically achievable for their use cases, usually leading to underwhelming user experiences because of limited ecosystem integration and collaboration.

Figure 1² shows a useful model to understand the levels of integration required for a mature, value-creating MaaS initiative that enables seamless experiences and robust management. Certainly, this doesn’t mean technology cannot help address mobility challenges and opportunities, but it must do so in the context of a coherent, end-to-end, user experience–driven approach. This requires some key actions:

1. Supporting end-to-end mobility supply management from planning to real-time operation, going beyond just presenting travel options to helping organize all mobility supply in line with demand and wider societal goals.

2. Universally addressing the digital/physical interface to mobility, typically linked to the way mobility is accessed and charged, to stop breaking user experiences along physical silos, especially since the mobility landscape constantly shifts.

3. Enabling a proactive, multi-modal mobility experience that goes beyond a broker model (i.e., one that juxtaposes independent MSP offerings). Most journeys aren’t explicitly planned by users, and delivered journey options and fares should be integrated based on a desired outcome, not MSP silos.

Importantly, all items above need much higher levels of standardization and data and services exchange to allow market solutions to scale. This is an area where technology can digitize the necessary collaboration between ecosystem actors to help reach high levels of MaaS integration.

Digitally Enabling Organization Authorities to Manage Multi-Modal Mobility

From the OA viewpoint, MaaS needs to expand beyond trying to simplify end-user access to mobility supply into a space where such supply can also be managed, in line with demand and overarching mobility ambitions. Several limitations will need to be overcome, including the following:

• Many current MaaS deployments either display mobility options users don’t need or are unable to display options users would need because they aren’t available. Simplifying access to mobility is most useful when the supply matches user needs.

• If behavioral change aligned with declared societal goals is a key objective for MaaS, then OAs must increase their understanding of end-to-end mobility needs and coordinate the supply in a way that reinforces those goals. This cannot be left to MSPs and free market principles only.

• There is no cross-mode collaboration similar to the one that has been used between public transport authorities (PTAs) and PTOs over the last several decades. An updated model incorporating everything from planning to operation is needed across all modes.

• OAs must frame data-sharing regulations across the mobility ecosystem, ideally based on a set of converging global practices and standards coordinated between cities, regions, and countries worldwide, enabled at the speed of digital.

From a technical perspective, the key enabler is the digitization of new data-sharing regulations between actors in a local mobility ecosystem. This will drive a new set of technical capabilities for OAs in the mobility management space, helping them make supply-and-demand balancing decisions aligned with stated societal goals:

• Mobility modeling and planning. Historical movement and usage data from MSPs, including new modes such as micro-mobility, should be collected with existing data, covering the assets, supply, and usage of mass transit, road networks, parking, and private car (and, soon, self-driving vehicles). Leveraging artificial intelligence (AI) will complement classic modeling approaches to paint a more accurate picture of mobility flows and patterns. If combined with carefully collected mobility event data (see next section on integrated mobility access), it can also be used to more accurately segment mobility users according to their behavior and potential attraction to MaaS.

• Tactical planning. A new type of collaboration on tactical supply/demand alignment (similar to what typically takes place between an OA and mass transit operators on things like timetables) should happen for new mobility modes, potentially with “softer” alignment mechanisms (e.g., trip-based subsidies to incent shared mobility). Such collaboration should be digitized to help the production and maintenance of a master mobility transport plan.³

• Operational window. Pushing for near-real-time exchange of supply and usage data from all MSPs should be a top OA objective. This should also extend to the exchange of dynamic mobility regulation, covering everything from capacity requests (e.g., the maximum number of scooters allowed in an area) to speed limits and parking constraints. When combined with supply and usage data from MSPs, this will open up the ability to monitor and control the enforcement of mobility regulations.

LADOT-Leveraged Standardization in Micro-Mobility Data Sharing

In 2016, California’s Los Angeles Department of Transportation (LADOT) became a pioneer in OA-led data-sharing regulation when it announced its intention to ask mobility providers to share data that would enable it to optimize safety, efficiency, and passenger experience.¹ The result was the creation of the Mobility Data Specification (MDS).² Thanks to this, the city was able to better understand interchanges between micro-mobility and mass transit, reduce excess scooters in specific areas, and enforce parking rules for them.³ The specification has continued to expand in scope and has been adopted by many OAs since.

¹ Carey, Christopher. “How Los Angeles Took Control of Its Mobility Data.” Cities Today, 1 July 2020.

² “About MDS.” Open Mobility Foundation, accessed August 2022.

³ “Use Cases: How & Why Cities Use MDS.” Open Mobility Foundation, 9 December 2021.

Addressing the Friction Between Digital & Physical Access to Mobility

There’s a lack of continuity between the digital experience of users (to manage their accounts, plan trips, etc.) and physical access to mobility. This is the area where most users experience friction in MaaS. In the worst cases, the user’s experience breaks along MSP lines, with the use of deep links into multiple apps and accounts. In the best cases, mobility access and even payment are digitally integrated for some MSPs but fares are not, leading to a broker model in which the user accesses a variety of separate offerings. These issues have a few underlying causes:

• New MSPs mean new ways to physically access mobility (e.g., vehicles) using mechanisms like near-field communication (NFC), Bluetooth, or QR codes. These cannot be centrally imposed if we want to remain flexible to new MSPs.

• User accounts are usually split between MSP lines, forcing users to register individually with MSPs and link their accounts.

• Apart from the workaround of implementing “all you can eat” subscriptions, fares are not simplified or integrated across mobility modes. The complexity of MSPs’ offerings is made visible to the user, with multi-modal journeys incurring a financial penalty. Features like needs-based mobility subscriptions, multi-modal daily or weekly caps, and trip discounts aren’t possible. This means fares cannot be effectively used to drive sought-after behavioral change.

• In some cases, the issues above still exist even between legacy mass transit PTOs.

From a technical standpoint, moving to a careful implementation of account-based ticketing (ABT) coordinated by the OA is a sensible step to support this transition:

• ABT decouples a MaaS user account, managed on the back end, from the mobility-access device. Devices simply become a token to identify the account, increasing choice and allowing the integration of MSP-specific access and mobility events.

• ABT can define universal, sophisticated, multi-modal, back-end fare rules based on transactions received from various mobility modes. This allows MaaS operators to implement integrated multi-modal fare management (e.g., a micro-mobility leg is less expensive when combined with a mass transit ride in a single journey), as well as mobility offerings that go beyond a list of competing offerings from MSPs. Combined with sophisticated compensation rules and clearing, this can drive a simpler experience and a behavioral nudge.

• ABT can simplify mobility account management for users, offering MaaS accounts that cover the integrated mobility offerings users have subscribed to and allowing invoicing and charging for all mobility usage.

• ABT provides a new data source to trace end-to-end journeys across all modes. However, care must be taken when collecting and using this data (see sidebar “Things to Keep in Mind When Implementing ABT”).

• With ABT, there is also an option to offer an EMV (contactless bank card or mobile wallet) as an already-in-your-pocket mobility access method doubling as a payment method.

Beyond ABT, solutions aiming to replace a centrally managed repository of mobility events (e.g., bookings, mobility usage events) with a distributed general ledger are appearing (e.g., FairsFair⁴). This promising approach would give users control over their data and digital identities and natively enforce privacy. This would also foster trust and data transparency for collaboration between parties that can process data they have access to for the purposes agreed with users (e.g., fare calculation).

As for already-in-your-pocket identification tokens, continuous progress in personal digital wallets and sovereign digital identities (e.g., eIDAS⁵) means that the advantage of open loop– based systems might be attainable soon without the need to mix concerns between identification and payment.

Things to Keep In Mind When Implementing ABT

Although the concept of ABT provides a practical pathway to MaaS enablement, benefits such as user experience, flexibility, and total cost of ownership (TCO) can be drastically reduced if care is not given to the following:

• Open-loop EMV (contactless bankcard) cannot be the only access mechanism. It is critical to run a hybrid system with OA-issued cards to: (1) support complex fares (and discounts) targeted at specific groups; and (2) cover the needs of the entire user population, regardless of whether they’re banked or unbanked, residents or visitors.

• ABT implies transferring more data than the user might be aware of (or willing to share), like a record of all of the user’s mobility events. This is particularly an issue in open-loop scenarios that don’t require preregistration. Data privacy, anonymization, and minimization must be front of mind.

• Better separation of concerns should be enforceable in the future. In ABT, one organization often ends up assuming many roles, which not only prevents deployment when no obvious coordination entity exists, but also stifles innovation if one does and micromanages. Open standards should be considered to avoid this — including secure device authentication, user account identification programs, and mobility event representation — as well as to help avoid vendor lock-in.

Going Beyond a Glorified Journey Planner & Mobility Marketplace

Most people think of an app when they think of MaaS. It is, of course, bigger than this, but a dedicated user interface is still an important piece of the puzzle. Unfortunately, most MaaS apps take a traditional plan-book/ticket-pay approach, limiting their potential:

• Multi-modal journey planning is not always fully dynamic, often failing to consider a real-time supply of unscheduled mobility modes. Many MaaS journey planners still rely on set rules for combining modes and only then look for options to fulfill journey legs.

• More fundamentally, there is also an assumed proactivity of users for planning and booking mobility, even though that’s only one way people consume mobility. Many journeys are recurring, and ways to complete them become quickly known by the users, rendering the need for proactive planning far less useful; users tend not to plan journeys they know.

• Use cases are too focused on single trips by individuals and fail to consider the various contexts within which mobility needs emerge. For example, return journeys, access to private vehicles, traveling with a group or family, and traveling for leisure versus business purposes all impact the relevance of journey options. Your Saturday morning family trip to the mall should probably not involve e-scooters!

• In a similar way, there is an excessive focus on MSP-specific advance booking, often caused by a lack of proper integration with MSPs’ back ends and mobility access events. This reinforces a marketplace and broker-style user experience with a nonintegrated juxtaposition of mobility options and fares.

• MaaS applications often provide a limited way to interact with users to promote behavior change during disruptions. They are usually limited to providing information on such disruptions outside the context of a future or current journey, leaving the user to plan their own alternative arrangements.

To respond to these challenges from the user interface point of view, we should move away from a plan-book/ticket–pay model in favor of a know-and-go one:

• When users explicitly plan a journey, it’s important to ensure that the journey-planning engine is truly multi-modal, considering real-time options alongside expected location and status of all available mobility to put together the best journey.

• For other journeys, the services powering the MaaS user experience need to be better at predicting a user’s mobility needs and the context from captured usage and preferences data (and possibly agenda or event data), in compliance with applicable user data privacy regulations. AI is key in this scenario to identify mobility needs, especially recurring ones before they happen, and to proactively propose options that consider real-time supply conditions. Real-time journey tracking should also be implemented to provide appropriate support within a started journey (planned or not), especially during disruptions.

• Options provided by journey planners, prompted by users or not, need to align to rules set by OAs to regulate mobility. There must be a way for them to decide when and what options to present to users, depending on considerations other than supply. Adding a loyalty management element to the equation can strengthen this ability, especially when fully integrated multi-modal fares and offerings cannot yet be achieved via ABT.

• MaaS applications and services should master end-to-end multi-modal journey orders and coordinate just-in-time bookings across various mobility services as required, an essential step toward providing users with journey assurance. MaaS services need to more closely resemble e-commerce apps in which an order includes multiple items with appropriate replacements or cancellations when something goes wrong.

When integrated into a MaaS user interface and combined with seamless access and charging across mobilities, these actions can enable users to know what they need to know when they need to know it, and go without worrying about mobility access, fares, or journey alternatives when required.

Pushing for Further Standardization of Mobility Data & Services

There is, however, a key underlying enabler to the capabilities discussed above: data. Whether it’s to understand historical access or supply, predict how and where new types of mobility should be deployed, share mobility access events that are used to calculate fares or integrate with MSPs’ own ticketing and booking systems, predict a recurrent mobility need, or provide real-time advice on a current journey, significantly wider data exchanges and service integration are required.

Here are the categories that must be addressed by advanced data-sharing regulations, ideally framed and enabled by enhanced OAs:

• Mobility infrastructure data exchanges. These cover the data managed by the OA relating to mass transit networks, stations and mobility hubs, road networks and infrastructure, and traffic and parking data, whether historical or real time. NeTEx and General Transit Feed Specification (GTFS)/GTFS-Flex (guided scheduled and on-demand transport), DATEX II (traffic), and APDS (parking) are all good standards to consider.

• MaaS and MSP data and services exchanges (public and private). These cover data provided by MSPs regarding their routes and schedules for mass transit and guided transport in general (note that MSPs include PTOs), as well as real-time and historical status of vehicles, fleet capacity and deployment information, and telemetry. Data regulation information must also be covered here. Services such as ticketing, booking, and direct vehicle commands (e.g., unlock/lock) should be provided by MSPs. NeTEx and SIRI, GTFS, GTFS-Flex, GTFS-Realtime, GTFS-Fares v2, MDS (shared mobility), and Transport Operator Mobility-as-a-Service Provider Working Group (TOMP-WG) are all standards to consider.

• Urban planning and events data exchanges. These cover information on public spaces as well as points of interests. Such a data exchange could (and should) expand to many new classes of points of interest, including businesses and venues (think Google Maps) and events planned across a geography to help plan mobility accordingly.

Accelerated global coordination will be needed to further the standardization movement to help MSPs mutualize their investments across geographies and help solution providers provide advanced solutions that benefit from deeper data and services integration. Such standardization will foster innovation in the MaaS space.

Many encouraging initiatives already exist. Some focus on developing specific standards families, like MobilityData for the GTFS/General Bikeshare Feed Specification (GBFS) family of standards or the Open Mobility Foundation for MDS. Other initiatives aim to create cohesive bundles of data and services standards that can be used to enable MaaS, including the Data4PT initiative⁶ for mass transit data and the NAPCORE project,⁷ focused on harmonizing data standards for National Access Points in the EU. In the Netherlands, the CDS-M Working Group covers more ground and more specifically centers on defining a coherent group of standards that enable MaaS.⁸

Lastly, OAs need to enable data and service exchange hubs that digitize the related data-sharing regulations and facilitate secure exchanges between all involved parties of the mobility ecosystem. They need to implement clear data governance enforced by technical capabilities, such as data and services catalogs and strict privacy-aware access-control mechanisms.

Digitally Enabling Mobility Goes Beyond MaaS

The seamless mobility experience and expected behavioral shifts that are at the core of the MaaS promise can only be delivered if MaaS is considered within the context of a new organization and the integration of the mobility ecosystems and systems supporting them. We can see the seeds of that change in a few places where meaningful MaaS initiatives have been implemented, but there is still a long way to go.

OAs are in a natural position to act as facilitators to regulate and orchestrate such ecosystems. This includes initiating new capabilities (in multi-modal mobility planning and management, integrated ticketing and fare management, and — if they decide to — MaaS user interfaces), as well as data- and services-sharing regulations and hubs that enable open, privacy-conscious exchanges between actors. And another type of effort, regarding the definition and expansion of standards to cover all aspects of services and data that should be exchanged in a modern multi-modal MaaS scenario, also needs to accelerate — this time at a global level.

To conclude, let’s remember that the starting point to successful MaaS must be an offer that is attractively priced, accessible, and sustainable based on the needs and goals of users, society, and businesses. This requires the creation of a mobility ecosystem in which all actors, private and public alike, benefit. Such an ecosystem should be framed by regulations codifying the way it has agreed to collaborate; only then can it reach success, with the meaningful contribution of technology.

References

¹  Van Audenhove, François-Joseph, Mickael Tauvel, et al. “Beyond MaaS: How to Realize the Promise of Mobility as a Service.” Arthur D. Little, September 2021.

²  Sochor, Jana, et al. “A Topological Approach to Mobility as a Service: A Proposed Tool for Understanding Requirements and Effects, and for Aiding the Integration of Societal Goals.” Research in Transportation Business & Management, Vol. 27, June 2018.

³  Van Audenhove, François-Joseph, et al. “The Future of Mobility 3.0.” Arthur D. Little, March 2018.

⁴  FairsFair is a data clearinghouse on the blockchain.

⁵  ”eIDAS Regulation.” European Commission, accessed August 2022.

⁶  Data4PT website, accessed August 2022.

⁷  ”About NAPCORE.” National Access Point Coordination Organisation for Europe (NAPCORE), accessed August 2022.

⁸  ”City Data Standard — Mobility (CDS-M).” Municipality Amsterdam, accessed August 2022.