The End of Ownership: Unlocking MaaS (Mobility as a Service)

Ditch the car keys. Explore Mobility as a Service (MaaS), the digital revolution integrating trains, buses, and scooters into one seamless app for total travel freedom.

December 11, 2025 8:17 am | Last Update: March 22, 2026 12:34 pm

⚡ IN BRIEF

Helsinki’s Whim – The First True MaaS Operator: Launched in 2016, Whim (now part of MaaS Global) was the world’s first fully commercial MaaS platform, allowing users to subscribe to unlimited public transport, taxis, and rental bikes via a single app. By 2020, it had 100,000+ users and reduced private car use by 12% in the Helsinki region, proving that a “car‑free” subscription model is commercially viable.
Four Levels of MaaS Integration: Industry standards (e.g., UITP MaaS Alliance) define four maturity levels: Level 1 – Information (e.g., Google Maps), Level 2 – Booking & Payment (single transaction for a multi‑modal trip), Level 3 – Bundled Subscriptions (monthly fee for a package of services), Level 4 – Societal Integration (policymakers use MaaS to manage traffic and emissions). True MaaS is considered Level 3 or above.
Account‑Based Ticketing (ABT) vs. Smart Cards: Legacy smart cards (e.g., London’s Oyster, Hong Kong’s Octopus) store value offline, making cross‑operator fare calculation complex. MaaS requires Account‑Based Ticketing (ISO 24014‑1), where the user’s account is central and fares are calculated in the cloud. This allows any payment method (contactless bank card, QR code) to be used across multiple operators without pre‑loading value.
Open APIs & TOMP‑API Standard: MaaS relies on open data exchange. The TOMP‑API (Transport Operator to MaaS Provider) is the leading technical standard (adopted by the Dutch Ministry of Infrastructure) for real‑time availability, booking, payment, and trip tracking between transport operators and MaaS platforms. It uses OAuth 2.0 authentication and JSON payloads, enabling seamless integration of trains, bikes, scooters, and taxis.
Railways as the “Backbone”: In a mature MaaS ecosystem, high‑capacity rail (commuter, regional, high‑speed) forms the core trunk, handling > 80% of the passenger‑kilometers. MaaS makes rail attractive by solving the “first and last mile” problem through integrated bike‑share, e‑scooters, and ride‑hailing, reducing the need for feeder car trips to the station by an average of 30% in pilot cities.

On a crisp February morning in 2016, a Finnish startup called MaaS Global opened the doors to a small office in Helsinki, releasing an app that would challenge a century of transport orthodoxy. Whim allowed users to pay a single monthly subscription (€59 for unlimited public transport, 30 taxi rides, and city bike access) and navigate the city by any combination of train, bus, tram, taxi, or rental bike—all through one interface. Within 18 months, 12% of Whim’s active users had sold their private cars, and the city’s overall vehicle kilometers traveled dropped by 3%. It was a watershed moment: the concept of Mobility as a Service (MaaS) had moved from academic papers to a live, commercial reality. MaaS is not just an app; it is a fundamental re‑architecting of how transport is consumed, shifting from ownership (of a car) to service usage (paying for mobility outcomes). For railways, this presents both a challenge and an unprecedented opportunity. As the high‑capacity backbone of the urban mobility ecosystem, rail must integrate seamlessly with bikes, scooters, taxis, and ride‑hailing to offer a door‑to‑door service that competes with the convenience of the private car. This article explores the technical, operational, and business model foundations of MaaS, the integration levels that define its maturity, and the standards (TOMP‑API, ISO 24014‑1) that make it work.

What Is Mobility as a Service (MaaS)?

Mobility as a Service (MaaS) is a digital service model that integrates multiple transport modes (public transport, shared mobility, taxis, car‑share, bike‑share, and even walking) into a single, user‑centric platform. Instead of owning a private car, users purchase mobility outcomes—such as a “door‑to‑door trip” or a “monthly mobility package”—through a unified app that handles planning, booking, payment, and often subscription management. The concept was first formalised in the 2014 Finnish transport code, which mandated that all transport operators open their data and ticketing interfaces to third‑party MaaS providers. The European Union has since supported MaaS through initiatives like the MaaS Alliance (led by UITP) and the IMOVE project, which demonstrated cross‑border MaaS in four European corridors. MaaS is built on three technical pillars: (1) open data (real‑time availability, schedules, pricing) via standardised APIs (e.g., TOMP‑API, GTFS‑RT); (2) account‑based ticketing (ISO 24014‑1) where fares are calculated in the cloud and can combine multiple operators; and (3) intermodal journey planning that considers user preferences (fastest, cheapest, greenest) across all modes. For railways, MaaS is a strategic lever to capture a larger share of urban mobility by solving the “first and last mile” problem—making it as easy to reach the station by bike or scooter as by car.

1. The Four Levels of MaaS Integration

The industry recognises a maturity model that ranges from basic information to fully integrated mobility management. These levels (defined by the UITP MaaS Alliance) are critical for understanding MaaS’s value proposition.

|
\n\n\n\n

Level	Description	Example / Implementation
1 – Information Only \n	The app aggregates information from different operators (schedules, real‑time updates) but does not support booking or payment. \n	Google Maps, Apple Maps, national journey planners (e.g., DB Navigator without ticket purchase). \n
2 – Booking & Payment Integration \n	Users can plan, book, and pay for a multi‑modal trip in a single transaction. However, tickets are still per‑trip (no bundling). \n	Whim’s pay‑as‑you‑go mode, Trainline (train + taxi), Uber’s integration with public transport in some cities. \n
3 – Bundled Subscriptions \n	Mobility is sold as a monthly subscription package (e.g., unlimited public transport + a fixed number of taxi/bike minutes). This is the core MaaS business model. \n	Whim’s Urban (€59/month) and City (€24/month) plans; Öffi‑plus in Vienna; Jelbi in Berlin (transport + shared mobility). \n
4 – Societal Integration \n	The MaaS platform is used by public authorities to manage traffic, reduce congestion, and meet emissions targets (e.g., by incentivizing off‑peak travel or capping car use). \n	Singapore’s Land Transport Authority’s “MaaS” pilot; planned integration in Helsinki’s city‑wide mobility targets. \n

Most current MaaS implementations are at Level 2 or Level 3. Level 4 remains a goal for smart city planning, requiring close public‑private governance and real‑time demand management.

2. Technical Backbone: Open APIs, TOMP‑API & Account‑Based Ticketing

MaaS is fundamentally an integration challenge. Three technical layers are critical:

Open Data APIs (GTFS‑RT, SIRI): For real‑time information, MaaS platforms ingest data from transport operators using standards like GTFS‑RT (General Transit Feed Specification – Real‑Time) for public transport and GBFS (General Bikeshare Feed Specification) for shared mobility. For railways, this means exposing real‑time train positions, delays, and occupancy via open, documented APIs.
TOMP‑API (Transport Operator to MaaS Provider): The leading transaction standard for MaaS. Developed by the Dutch Ministry of Infrastructure and Water Management, TOMP‑API defines endpoints for availability, booking, payment, and trip tracking. It uses OAuth 2.0 for security, JSON payloads, and supports both public transport and on‑demand mobility (taxis, car‑share). As of 2025, it is being adopted across the Netherlands, Flanders, and several German regions.
Account‑Based Ticketing (ISO 24014‑1): Legacy smart cards (e.g., Oyster, Octopus) store value on the card; each operator’s validator deducts locally. This makes it nearly impossible to combine different operators’ fares into a single trip. Account‑Based Ticketing (ABT) moves the logic to the cloud: the user’s account (linked to any payment method – contactless card, phone, QR code) is debited centrally after the trip. The system calculates the optimal fare combination (e.g., a combined train‑plus‑bike fare). ABT is now mandated by the EU’s Delegated Regulation (EU) 2017/1926 on multimodal travel information services.

For railways, implementing these standards requires a shift from legacy IT systems to cloud‑native, API‑first architectures. Major operators like SNCF (via its “SMS” platform) and Deutsche Bahn (via the “DSS” – DB Smart Service) are now exposing ticketing APIs for MaaS integration.

3. The Railway’s Role: Backbone of the MaaS Ecosystem

In a dense urban mobility landscape, rail (commuter, regional, high‑speed) provides the high‑capacity trunk that moves the majority of passenger‑kilometers efficiently. MaaS leverages rail by solving the “first and last mile” with flexible, shared modes:

Station as a Hub: MaaS apps guide users to the station via an e‑scooter or bike‑share (often integrated with the same subscription). The app can reserve a bike at the destination station, ensuring a seamless chain. For example, the Jelbi platform in Berlin combines BVG’s U‑Bahn, S‑Bahn, buses, and several shared mobility providers (e‑scooters, car‑share, bike‑share) in one app, with a unified payment account.
Increased Rail Mode Share: Data from Helsinki’s Whim showed that active MaaS users increased their public transport usage by 21% and reduced private car kilometers by 12%. By making rail accessible without a car, MaaS directly boosts ridership, especially for off‑peak and reverse‑commute trips.
Revenue Models: Railways can generate new revenue streams by selling “wholesale” access to their capacity to MaaS operators. Under a bundled subscription, the MaaS provider pays the railway a fixed monthly fee per user (or a discounted per‑ride rate) in exchange for guaranteed volume. This is analogous to the mobile virtual network operator (MVNO) model in telecom.

For this to work, railways must provide real‑time occupancy data (so MaaS apps can suggest less crowded carriages) and dynamic pricing for demand management. Several pilot projects (e.g., in the Netherlands with NS) are experimenting with “MaaS‑ready” fares, such as discounted subscriptions for users who combine train with shared mobility.

4. Business Models & Barriers to Implementation

Despite technical progress, MaaS faces significant commercial and regulatory hurdles:

Business Model Fragmentation: Transport operators have different incentives. Public transport operators (PTOs) aim to maximize ridership; private mobility providers (e.g., Uber, Lime) focus on profitability per trip; MaaS operators seek to aggregate and retain subscribers. Revenue sharing agreements are complex. A 2023 study by the European Commission found that only 25% of MaaS pilots achieved financial sustainability without public subsidy.
Data Sharing & Privacy: MaaS platforms require granular data from operators, including real‑time occupancy, which some operators view as commercially sensitive. The GDPR restricts sharing of personal data without explicit consent. MaaS platforms must therefore implement “privacy by design,” often using tokenized identifiers and anonymizing location data after trip completion.
Regulatory Barriers: In many jurisdictions, public transport ticketing is legally required to be operated by the PTO itself, making it difficult for third‑party MaaS apps to resell tickets. The EU’s Multimodal Digital Mobility Services (MDMS) regulation (in development) aims to force PTOs to open their ticketing APIs to certified third parties, similar to the EU’s PSD2 for banking.
Inclusion & Equity: MaaS is often app‑based and requires a smartphone and bank account, potentially excluding elderly, low‑income, or non‑digital citizens. Some cities (e.g., Vienna) have countered this by requiring that MaaS subscriptions be also available at physical outlets and that discounted “social” packages be offered.

Despite these barriers, the trend is clear: a growing number of cities and transport authorities now mandate open APIs and account‑based ticketing as part of their public transport contracts, laying the foundation for a competitive MaaS marketplace.

Comparison: Traditional Transport Model vs. MaaS Model

|
\n\n\n\n\n\n\n

Aspect	Traditional Transport Model	MaaS Model
User experience \n	Fragmented: separate tickets, apps, and payment methods for each mode (train, bus, taxi). \n	Unified: one app for planning, booking, and payment across all modes. \n
Payment model \n	Pay‑per‑ride; each operator charges separately. \n	Single transaction or monthly subscription covering multiple operators. \n
Planning \n	Mode‑centric: users plan around a specific mode (e.g., take the train, then find a taxi). \n	User‑centric: the app optimises for the fastest, cheapest, or greenest door‑to‑door journey. \n
Data sharing \n	Siloed; operators often reluctant to share real‑time data with competitors. \n	Open API; operators expose data to MaaS platforms to enable integration. \n
First/last mile \n	Often a barrier: stations may be inaccessible without a car. \n	Integrated: the app suggests a shared bike, scooter, or ride‑hail to/from the station. \n
Revenue model \n	Each operator optimises its own revenue (farebox, subsidies). \n	MaaS operator aggregates demand and shares revenue with operators (often via wholesale agreements). \n
Sustainability focus \n	Secondary; individual operators may promote sustainable modes, but not coordinated. \n	Explicit: MaaS platforms can nudge users toward lower‑carbon modes (e.g., train vs. car) and provide CO₂ tracking. \n

Editor’s Analysis: The Monetization Gap

MaaS promises a seamless mobility experience, but it has yet to prove a sustainable business model for public transport operators (PTOs). The current reality is that MaaS platforms are often “thin” aggregators that retain a small margin (5–10%) on transactions, while PTOs bear the full cost of running train and bus services. In the Helsinki Whim model, MaaS Global paid HSL (the public transport authority) a fixed fee per user, which was significantly lower than the full farebox revenue HSL would have received had those users purchased traditional tickets. This created tension: HSL’s ridership increased, but its revenue per passenger dropped. Several PTOs have since moved to build their own MaaS‑like apps (e.g., Deutsche Bahn’s “Mobilitätsgarantie,” SNCF’s “Maas” initiative) to retain customer relationships and revenue.

The next phase of MaaS will likely involve a shift from “aggregator” models to platform cooperatives where PTOs and shared mobility operators jointly own a MaaS platform, sharing both data and revenue. The EU’s upcoming MDMS (Multimodal Digital Mobility Services) regulation is expected to require that PTOs open their ticketing APIs at regulated wholesale prices, similar to the European Commission’s approach to railways (the “passenger rights” regulation). Until such regulatory frameworks are in place, MaaS will remain a patchwork of pilots and niche services, rather than the universal, car‑replacing mobility system it aspires to be. For railways, the strategic imperative is clear: they must not only open their data and ticketing but also actively partner with MaaS platforms—or risk becoming just another commodity in a mobility marketplace where customer ownership lies elsewhere.

— Railway News Editorial

Frequently Asked Questions (FAQ)

1. What is the difference between a MaaS app and a traditional journey planner like Google Maps?

Traditional journey planners (e.g., Google Maps, Apple Maps) operate at Level 1 (Information Only) or sometimes Level 2 (booking for one or two modes). They show you the options, and you may be able to book a train ticket via a link, but you cannot pay for a multi‑modal trip (e.g., train + taxi + bike) in a single transaction. A true MaaS app (Level 2 or 3) allows you to plan, book, and pay for the entire door‑to‑door journey within the same interface, often using a single payment method or subscription. Moreover, MaaS apps provide “interoperability” across modes: they can split a fare between operators, apply subscription caps, and offer combined products (e.g., a monthly pass covering both train and bike‑share).

2. How does Account‑Based Ticketing (ABT) work, and why is it essential for MaaS?

Account‑Based Ticketing (ABT) is a system where the user’s travel entitlements are stored in a central cloud account, not on a physical smart card. When the user taps a contactless bank card, smartphone, or QR code at a validator, the system records the “tap‑on” and “tap‑off” events, calculates the fare (potentially across multiple operators), and debits the user’s account after the trip. ABT enables fare capping (e.g., automatically charging the daily or weekly cap rather than per‑ride), cross‑operator bundling (a single account can be used for train, bus, bike, and taxi), and post‑paid subscriptions. Legacy smart cards (like Oyster in London) store value on the card itself, making it difficult to combine fares from different operators because each validator would need to communicate with all operators’ back‑ends in real‑time. ABT is defined in ISO 24014‑1 and is now a mandatory requirement for new ticketing systems under EU procurement guidelines for public transport.

3. What is the TOMP‑API, and why is it important?

The Transport Operator to MaaS Provider API (TOMP‑API) is an open standard that defines the interface between transport operators (e.g., a railway company, a bike‑share operator) and MaaS platforms. It covers the full lifecycle of a trip: availability (real‑time capacity), booking (reserving a seat or vehicle), payment (calculating and settling fares), and trip tracking (updating the user on progress). TOMP‑API uses RESTful principles, OAuth 2.0 authentication, and JSON data formats. It was developed by the Dutch government in collaboration with operators and MaaS providers and has been adopted as the national standard in the Netherlands and Flanders. For railways, implementing TOMP‑API endpoints allows their services to be seamlessly integrated into any MaaS app, reducing the need for custom integrations for each operator. The standard is now managed by the MaaS Alliance and is being considered for European standardisation.

4. How does MaaS handle data privacy, especially with shared mobility providers tracking user locations?

Data privacy is a critical concern. MaaS platforms typically collect location data from multiple sources: train occupancy (aggregated), bike‑share station availability (static), and, for on‑demand services like taxis or scooters, precise trip tracking. To comply with the EU’s General Data Protection Regulation (GDPR), MaaS platforms must implement privacy by design. This includes: (1) obtaining explicit consent for each type of data collection; (2) using pseudonymisation (the user’s account ID is replaced with a temporary token for the transaction); (3) minimising data retention (e.g., location data is deleted after trip completion unless the user consents to long‑term analytics); and (4) providing transparent dashboards where users can see what data is held and request deletion. Some MaaS platforms also allow users to opt out of data sharing with specific operators (e.g., not sharing location with taxi companies). The European Commission’s MDMS proposal includes provisions for a “common privacy framework” for multimodal travel data.

5. Can MaaS work in rural areas, or is it only for cities?

While MaaS is most advanced in dense urban areas (Helsinki, Vienna, Berlin), rural MaaS is emerging as a way to reduce car dependency in low‑demand areas. The challenge is lower population density and the absence of high‑frequency public transport. Rural MaaS pilots (e.g., in the Netherlands’ “MaaS pilot Achterhoek,” Sweden’s “UbiGo”) often combine: (1) on‑demand public transport (flexible buses that deviate from fixed routes); (2) car‑sharing; (3) bike‑sharing; and (4) taxis. The MaaS app serves as a “mobility wallet” that subsidises or caps the cost to make these combined services competitive with private car ownership. For railways, rural MaaS may involve integrating with regional rail and using the train as the trunk, with flexible shuttles timed to connect with train arrivals. The economics remain challenging; many rural MaaS pilots require public subsidy. However, the EU’s Rural MaaS initiative (under the CEF programme) is funding several projects to develop replicable models.