The EU is obsessed with data sharing. Or rather, the lack of it. Insufficient data flows are seen as a strategic barrier to creating a thriving data economy.1 Lately, the Union has been pushing for data sharing through different policy, regulatory, and funding instruments.
A preeminent one are “data spaces”. The premise here is that governance and technical barriers are impeding data flows that would otherwise happen, fostering new products or services. Thus the EU is funding - with 2 billion Euros of direct investment - these initiatives to create data flow-enabling governance and technical architectures.Every time I hear about the lack of data sharing I wonder to what extent that is true.
Recently I’ve been diving deep into micromobility services in European cities and I’ve found an “evident” reality: nothing is as simple as it seems. The degree of complexity in the tech stack powering what may seem a fairly simple municipal service - docked bikesharing - is staggering. For this stack to function, huge amounts of data need to be shared between the many players running different components of that service.
When I realized this, the question that came to mind was: how easy is then to share data among these companies? And immediately after, where does this leave the EU’s assessment of the current state of data sharing and its efforts to tackle it?
Let me run through some of the details of the bikeshare service tech stack before taking a step back to ponder on what this means for broader efforts aimed at improved data sharing.
What's really under the hood of a shared bike service?
In the quest for gaining profitability while meeting public goals, the shared micromobility sector is getting more sophisticated by the day. This is reflected in the complexity of its tech stack, which comprises physical hardware, embedded connectivity, operations software, user interfaces, and analytics and AI services.
Launched in June of this year, Bilbaobizi, the system of my hometown, Bilbao, is a great example: Lyft Urban Solutions supplies e‑bikes and docking stations, Serveo operates the service, and Urban Sharing’s Urban Crew software coordinates rebalancing, charging and maintenance. For this stack to function, millions of data points are created and shared among the players running each of these layers.
Here are some of the data-generating artifacts that come into play every time one gets a bike to go from home to work:
First, there are the physical bikes, their batteries, and the charging stations where they are docked. Inside the vehicles and the stations there are different pieces of hardware and sensors, such as GPS modules, accelerometers, and sensors on batteries, gyroscopes and wheels. To locate and control the vehicles, these also have cellular or IoT sensors - which run on SIM cards that enable remote communication. In the middle there is the software that collects all this data to manage fleets (rebalancing, maintenance, battery control and incident monitoring). On top of these is the App layer that we use to locate, unlock and pay for the bikes, as well as other Apps used either by city managers to monitor compliance with regulations and tender agreements, or by fleet operators running specific tasks.
To all these layers we could add AI and data-analytics for different tasks across the layers. An example of this is the integration of an AI-powered predictive tool to forecast when bikes will be available that has been deployed in Barcelona’s Bicing system since 2022. Other companies, like Vianova, integrate different data sources to power mobility dashboards and different analytic use cases for cities.
As the figure above illustrates, different players run different layers of the stack - or even components within each layer. For example, Lyft Urban Solutions (which resulted from the purchase of PBSC Urban Solutions by Lyft in 2022) are the providers of vehicles and docking stations of the shared bike services in many European cities. Other vehicle manufacturers such as Segway are also present in countries like Poland. Multiple companies offer the IoT sensor devices that enable the communication with the vehicles, which may or may not be integrated with the vehicle’s own electronic control unit or ECU.2 While sometimes these devices come with an incorporated SIM card, in other cases this has to be purchased separately.
Just to recap, so far we have the providers of the hardware, sensors and communication devices, and SIM cards.
Let’s move on to operations now.
Here we have the company running the operations, who may do it on its own software, but increasingly use specialized software solutions from companies like Urban Sharing or Qucit. They may also run their user-facing app, but this is sometimes run by a third party or the city directly.
Lastly, there are companies that have built their businesses around developing dashboards and other platforms, including specific AI modules to run operations and provide information to users. These can be yet another layer, whose main user is not necessarily the bike rider nor the operator, but the city who wants to have detailed information on how the vehicles are moving around its streets. Vianova and Ride Report are examples of such companies.
Some companies offer an integrated solution, providing the vehicles, managing the fleets and running the user-facing apps. In other cities, however, different players provide different components and functions. Selecting specialized providers for hardware, software and analytics is optimal for getting top-notch products in each category, but carries integration costs. By contrast, all-in-one services can result in vendor lock-in and slower innovation. Cities like Bilbao or Gdansk are also selecting hybrid approaches, where different vendors - in charge of different components - join together for a tender. This is probably optimal, but requires a lot of data sharing among each of the players. And when I mean a lot, I mean A LOT.
Recently, Voi's CTO revealed that “everyday, we collect 100 billion data-points”. Running a shared micromobility entreprise is a tech and data operation. In his view, you simply cannot run these companies without AI.
How does your bike trip data travel through the stack?
Picture this: You're late for a meeting and there is a public transit strike. You pull out your phone, find a shared-bike station a block away, and register with your city’s bikeshare App. You scan the QR code. The lock clicks open and you start pedaling. In that two-minute interaction, you've just initiated a cascade of data across a handful of companies, a conversation that spans from the cloud to the curb.
First, the App sends your register information to the operator and gives you a unique ID. Your payment details are sent to a third payment processing entity that validates you and returns that info to the operator, which shares it with the App. Then an encrypted “unlock” request zips from the App to the operator, which authenticates you and dispatches a command to the bike's IoT lock to let you pick the bike. That entails, assuming these are run by four different entities (App, operator, payment processor and IoT device cloud), already six data transactions.
Then you start riding, and the IoT unit instantly beams a 'trip start' event - with GPS, battery, and a pseudonymous user ID - sent back to the operator. During and after the trip, the vehicle IoT will send to the operator status changes of the vehicle (unlocked and locked) with timestamps as well as battery levels. The organization running the IoT sensors will also send telemetry data with the vehicles’ positions and speeds.
This silent, invisible journey happens thousands of times a day: in Barcelona, Bicing services were used 18 million times in 2023.
But there is more data sharing.
For you to have that bike ready when you need it, there needs to be a well-run operation behind the scenes to maintain, repair, recharge and rebalance bikes across the city. This is done by the fleet operator. If the operator managing the fleet is different from that running the operations management software - as in the case of Bilbao mentioned above -, all the information received by the latter will then need to be shared with the operator’s workforce so they can perform relevant tasks such as battery swaps or vehicle rebalancing. The fleet operator’s employees may have a dedicated App, where they receive the information from the software platform and in turn input task status, maintenance logs, or information on replaced parts.
The operator also shares data with the user-facing App to show vehicle availability to rushing commuters like you. It also shares data with the city, via an analytics platform or directly, with continuous feeds on vehicle status and locations. Cities rarely ask for datasets: they either specify event/availability APIs or establish Service Level Agreements (SLAs) with concrete indicators that they monitor. In other words, data-sharing is structured around clear regulatory or operational use cases.
The city also shares data with the operator - directly or via the platform - on policy changes, parking rules, or geofences. Users can also provide additional data such as satisfaction surveys to the operator, who may or may not share this data with the city.
These are the basic data flows - there are more related to payments, receipts, etc - that occur in any normal day of your city’s bikeshare system. There can also be other data sharing events down the line, for example if datasets are made openly available or shared with other entities for academic study, insurance coverage calculations, or to respond to law enforcement requests.
When the need is clear, the data will flow
So, what can the humble shared bike teach us about the grand vision for a European data economy?
The primary lesson is one of pragmatism. The intricate data flows web of bikesharing wasn't born from a top-down mandate or a pre-defined set of standards. It was forged by necessity. It demonstrates that when a clear business case or policy goal exists, be it operational efficiency, regulatory compliance, or user convenience, organizations will find ways to build the necessary technical and governance bridges.
This bottom-up reality presents a challenge to the "build it and they will come" philosophy of some data space initiatives. Instead, cities should act as market-shapers, setting clear and specific goals for mobility, sustainability, or public safety, and then facilitate the data interoperability - for example demanding open APIs among stack layer players in tenders - needed to achieve them. Articulating and aligning incentives and funding around very specific use cases with quantified targets is the most pressing need right now.
The complex tech stack of a bikeshare system also provides important lessons for urban policymakers thinking how data will enable and transform city services beyond mobility. The bikeshare stack of multiple, specialized vendors collaborating in real-time through a web of APIs is a template for how other urban services will likely evolve.
Crucially, it proves that data doesn't flow because of standards; standards emerge because data needs to flow. Data sharing thrives when it’s directly tied to a tangible outcome, be it a charged battery, a balanced station, or a compliant ride. Before we build continent-spanning data infrastructures, we should first ask: what problems are we trying to solve?
As the bikes on our streets quietly demonstrate, once you have a clear answer, the data will find a way to flow.
There is a tension at the core of the EU’s approach. One the one hand, it has led the charge in personal data protection, but at the same time, it seeks to promote data sharing as a core strategic lever to foster a thriving data economy.
An ECU is a small computer within a vehicle that controls various electrical systems or subsystems.