How the Internet of Mobility will Transform Mobility Ecosystems
We iomob.net believe a seamless mobility experience for end users requires at a minimum the following: Mobility aggregation requires that the user be able to Discover the mobility services around them, get Multimodal Routing of any combination of those services, Book or Unlock mobility devices or services through the app, Onboard services when they require users to do so prior to accessing them and Pay for any of the services through the same app. Anything short of these, which was reinforced to us by our guru advisor Susan Shaheen from UC Berkeley, means an inferior experience that is not self contained in the app, requiring the user to exit the app to actually conduct their journey.
Obviously this chart is not exhaustive. There are thousands of mobility startups and established players innovating in the space and it’s not realistic to represent them all here. However, as a general rule, I believe you can group the mobility aggregation marketplace in these categories, essentially going from least seamless and inclusive to the most: Journey Planners, Vertically Integrated MSPs, Web 2.0 MaaS and finally Web 3.0 Internet of Mobility (Iomob).
Journey Planners
I am surprised at how frequently we get the question how is Iomob different from Citymapper or Google Maps. As you can see from the chart, there really is no comparison. Let’s take Google Maps, something probably every reader of this post has used and probably continues to, to assist with journey planning. Google Maps has great mapping tech. In cities that use the GTFS standard for transit data, Google Maps has quite accurate info on most public transit services. They also have great information on traffic data, allowing them to estimate the time to drive in your own car or take a taxi. In some cities, Google Maps will also estimate the fare for taking an Uber or Grab. Google Maps will tell you how long it takes to walk or bike to your destination too. That’s about it though.
Google Maps does not allow you to do multimodal routing of different services. Perhaps your most optimal route is to take a bikeshare to metro. Not offered. Want to book or unlock the scooter? Not available through Google Maps nor most journey planners either. Want seamless payment through the app of differen mobility services? Not going to happen. While Citymapper, as an example, offers users way more MSPs and more support for multimodal routing than Google Maps, journey planners mostly enable discovery of mobility services around the user and some routing information.
Vertically Integrated MSPs
Uber, Lyft, Grab and other MSPs, most of whom started with ride hailing, have started to acquire or partner with other forms of MSPs like scooters and bike sharing, to begin to offer a suite of mobility services to their users. As you can see from the chart, to an extent, this offers much more of a seamless integrated experience for end users as they can obtain multimodal routing, book, unlock, onboard and pay for services owned (or partnered) by the vertically integrated MSP. The problem with this model for mobility users is that this seamless experience only is achieved by the services owned by the integrated MSP. In many cities of the world we have 3 bikeshare services, dozens or even hundreds of taxi and ridehailing services, 5 electric scooter services, not to mention public transit (for which some of these integrated MSPs are now trying to atleast superficially incorporate as well).
So from a certain perspective vertically integrated MSPs do offer a more seamless user experience. But it is limited to the services the MSP controls. This is a very suboptimal experience for end users, and really an effort to leverage economies of scale to crowd out the smaller players. In many cities, this model is not even legal or possible. For example in Barcelona, where we are based, electric scooter sharing companies only are allowed to operate 2000 vehicles in the city. That is way less than the estimated potential demand for 100,000. So no one company can provide ubiquitous access to mobility user needs and if it were allowed, the capital costs required would be insurmountable. Furthermore individual operators or types of business models like private ridehailing continue to be under regulatory threat worldwide. The government of Catalonia just announced they are imposing a rule that private ridehailing servcies in the region will only be allowed to operate when the user has booked the service between 6 and 12 hours in advance.
Web 2.0 MaaS
The global mobility marketplace has been quite excited, and I believe reasonably so, with the introduction of what is commonly referred to as Mobility as a Service (MaaS). What MaaS aims to do is to offer users access to a wider range of mobility services offered by third party MSPs through a seamless user experience. In MaaS models, most famously pioneered by Whim out of Helsinki an Moovel from Portland, at least one major MSP in important mobility categories (bike sharing, scooter sharing, taxis, public transit, etc) is recruited to participate in the aggregation service that will be packaged and offered to users either in a pay-as-you-go single journey, or in a monthly service plan offering users a range of packages depending on their expected use of the services on a monthly basis.
In our opinion Web 2.0 MaaS aggregation is superior to Journey Planners and Vertically Integrated MSPs because they increase seamless access to multimodal routing, booking and payment in a city. While they are quite close in nature to the Vertically Integrated MSP, most MaaS providers do not own and operate their own service and therefore are more incented to provide their users with access to the best routing options for their needs. However just like Vertically Integrated MSPs, MaaS operators generally do not offer access to any legal MSP in the city. In fact many, specifically negotiate exclusive arrangements with a larger provider of a certain mode of transit, say the largest taxi operator, and then agree not to allow other taxi services to be part of their aggregation. The problem for the user and the mobility ecosystem as a whole, is that this exclusive arrangement results in inefficiencies (how often does the large taxi operator have the closest free taxi to the end user?) and crowds out startups and smaller MSPs, and especially independent taxis.
The Internet of Mobility: Iomob
We have already written quite a bit in previous posts about the difference between Web 2.0 MaaS and Iomob.
When we began envisioning what Iomob could achieve leveraging blockchain technologies, we recognized that an Internet of Mobility could transform mobility on a global scale in ways that result in more inclusive access to the ecosytem for startups, small operators and even independent ones, while providing a superior end user experience and optimizing public transit as a fundamental part of the mobility ecosystem.
So we set about building a tech stack that could support our vision of a fully seamless mobility service that integrates discovery, multimodal routing, booking/unlocking, onboarding and payment of ANY legal mobility service in the marketplace. That is to say, a permissionless system, whereby small operators, startups and even independent providers could be connected to Iomob and when they are amongst the best options for a user, they will be visible. This creates an open network effect whereby any MSP connected to Iomob can compete and collaborate with all the others in the ecosystem.
While Iomob is focused primarily on the creation of the Iomob protocol and the architecture to enable the seamless experience, we also realized early on that we could not just publish our open source code and assume other companies and startups would build apps to connect to the protocol.
Instead, we committed to building a high quality, seamless end user application. We are hard at work completing the first version of the end user application which will serve as the basis for our initial pilots.
As Iomob is not only a permissionless platform where any legal MSP can participate, it is also decentralized. Iomob will not own or monopolize the platform. Any mobility aggregator, including the Vertically Integrated MSPs or the Web 2.0 MaaS aggregators can connect to the Iomob protocol and offer services through it.
And the app we are building is open source. That is to say we are building the app so that any company who wants to can leverage the app, rebrand it and offer mobility aggregation services to their customers via the Iomob protocol. In fact, one of the first projects we are developing is with Renfe, the Spanish rail giant with 17 million annual customers. With the liberalization of the European rail market coming in 2020, Renfe has decided to proactively embrace new business models. In 2019 we will be collaborating with Renfe to offer our full open tech stack, testing all of the key parts of the seamless integration (discovery, multimodal routing, booking and payment) of any mobility services that wish to connect to the Iomob protocol. As Iomob is permissionless, any legal MSP will be able to connect to the Renfe app in Spain, INCLUDING their competitors who will be entering the liberalized train market in Spain in the coming years.
So why would Renfe embrace this model? They know if they don’t do it others will anyway, they see this as a way to increase revenues in new areas removing dependence on revenue only from train tickets in a liberalizing market and to increase the seamless mobility experience for their own customers. But there is more. If Renfe so chooses to enable this, the Renfe app (white labelled from Iomob) could work for anyone traveling to any city in the world where Iomob operates. So, for example a frequent user of the app in Spain flies to say Pittsburgh where Iomob also is developing a pilot with support from Ford Motors and the City. The Renfe app user will get access to seamless mobility experiences (including onboarding of services they have never heard of that are local to the Pittsburgh marketplace) in Pittsburgh.
This same scenario can occur with any transport or MSP or aggregator or startup by connecting to the Iomob protocol, whether they choose to use the Iomob white label app or not.
One last point. The chart refers to “Tools and support for mobility network management”. In blockchain there is a term called smart contracts. The term is a bit of a misnomer; Vitalik Buterin, a cofounder of the Ethereum blockchain, recently referred to smart contracts as persistent scripts. In Iomob, smart contracts are used to define the rules that govern revenue sharing and other transactions that may occur between untrusting parties.
Iomob is working with cities to understand what types of use cases are emerging that can transform how transit authorities engage with the local mobility ecosystem. One scenario that has emerged: A transit authority wants to establish a persistent script that regulates the number of private ridehailing vehicles and licensed taxis which can circulate in the city. With such a script a city could establish that, for example, only 2,000 such vehicles are allowed to circulate at any given time. However, in the event of an emergency (e.g. hurricane, earthquake, terrorist attack), a dynamic script or change to the persistent script can be made in seconds which increases the permitted vehicles. All of this can be done without actual contracting and negotiations occurring between parties.
Similarly another city asked us if we could enable them to leverage smart contracts to offer subsidies to private MSPs to replace public transit services in instances when demand is really low and the cost to deliver the service is excessive (e.g. night time bus route where only 1 or 2 passengers need the service). Again, the city could establish a cap on the subsidy and any prerequisites for MSP eligibilty and if those have been validated, private MSPs near the users could offer the service, saving taxpayer money and providing efficient mobility services.
Perhaps what I have described sounds futuristic to some. It is not. We are in alpha on many parts of our tech stack and will be commencing at least three pilots this year, two of which I have already referenced (Renfe in Spain and Pittsburgh with Ford’s sponsorship). By the end of next year, we expect that every item discussed in this post will be completed and deployed.
The mobility marketplace has become increasingly fragmented and the need to enable seamless, decentralized mobility aggregation has never been greater. While there are many emerging entrants in the aggregation space, for the reasons outlined here, we are convinced that the Internet of Mobility offers the best future for MSPs, citizens and cities.
About us:
Iomob is working to decentralize and build the Internet of Mobility, by incentivizing and facilitating the use of alternative transport. By using the blockchain, iomob plans to minimize fees and allow mobility providers and end-users alike to connect on a peer-to-peer basis. In their own words: Iomob is “a system which produces a useful output at the lowest possible marginal cost.”Learn more about Iomob by connecting with us:
