What does 'real-time' data portability actually mean?
My name is Thomas, and I am a Researcher at the Open Data Institute and was a Summer Fellow at the Data Transfer Initiative (DTI). My work operates at the intersection of technology, policy, and open ecosystems, and I’m grateful for the opportunity this summer to tackle one of the most pressing and ambiguous questions in digital regulation.
Across the globe, regulators are looking to data portability as a tool to dismantle data silos, lower switching costs for users, and create a more level playing field. Leading the way is the EU, where the Digital Markets Act (DMA) mandates “continuous and real-time” data portability.
However, these landmark regulations have left a critical interpretation gap. Namely, they never defined what “real-time” actually means. This ambiguity leaves regulators without a clear compliance benchmark and platforms without clear guidance. My research this summer, which has been published in the paper Defining ‘real-time’: A toolkit for assessing data portability, addresses this gap directly.
Beyond absolutes: Introducing Functional Real-Time (FRT)
The central finding of our research is that “real-time” is not an absolute measure but is context-dependent. To bring clarity to this, we introduced two key concepts.
The first is Absolute Real-Time (ART), which is the theoretical, instantaneous moment an event occurs. This is a physical limit that is impossible to achieve in practice. The second, and more important, concept is Functional Real-Time (FRT). This is the point of diminishing returns, beyond which further reductions in latency (delay) provide no meaningful benefit to the user for a given task. For example, a 500-millisecond delay is disastrous for a video call, but a five-minute delay for a blood glucose reading may be perfectly functional, as the body’s own chemistry isn’t necessarily faster than that. So, the FRT is the threshold that matters.
To build this framework, we developed a new taxonomy to classify data transfer systems and used it to analyse 18 different implementations across the health, finance, and social media sectors. This allowed us to map why and how delays to FRT happen in practice.
Latency as a feature, not a bug
We found that latency is often not a technical failure but a deliberate architectural choice that trades raw speed for other essential functions.
One major factor is the use of intermediary processes. Financial aggregators like Plaid and Yodlee, for instance, introduce delays of seconds or even minutes. This is most likely explained by their performing vital functions like managing the complexity of thousands of different bank connections whilst performing fraud checks (amongst other security measures). Given that getting this wrong could imply significant financial risk, a kind of intermediary hub model is a legitimate trade-off here, which sacrifices instantaneous speed for safety.
In other cases, delays are built in to add analytical value. For example, the Dexcom G7’s public API for third-party developers intentionally delays glucose data by over an hour. This is a policy choice to provide a high-quality, retrospective trend-data service rather than a live feed.
The ‘natural rhythm’ of data
Beyond these architectural choices, we observed that data itself has an intrinsic cadence; a natural speed limit set by either physical or digital constraints.
This is most obvious in health monitoring, which has a physical cadence. As mentioned, a continuous glucose monitor (CGM) is limited by the body’s physiology. It takes at least 5 minutes for glucose to diffuse from the blood to the interstitial fluid, where sensors take their measurement. Therefore, the FRT for this use case is 5 minutes. Attempting to poll the sensor every second would be counterproductive, yielding no new information and needlessly draining the battery.
In purely digital systems, this cadence is often defined by a digital cadence related to mutability. Delivering an immutable (ie, unchangeable) data stream, like a stock tick from Alpaca or Tradier, simply requires appending new data. But platforms like Slack or Gmail are mutable (ie, messages can be edited or deleted). A “real-time” system here must not only deliver new messages quickly but also synchronise all edits and deletions instantly to all users. This creates a far more complex challenge and shifts the architectural priority from simple delivery to state synchronisation (eg, ensuring that all deletions, changes, etc, are the same across devices, as well as new entries), which itself can introduce latency.
A toolkit for regulators
This research provides policymakers and enforcers with a practical toolkit (the taxonomy and the FRT framework) to move beyond absolutist views of speed.
This framework has direct implications for enforcing laws like the DMA. For compliance assessments, the taxonomy helps identify when latency is a legitimate trade-off versus a deliberate tactic to undermine portability. This allows regulators to spot potential anti-competitive delay. This brings us back to Dexcom. While its public API has a 1-3 hour delay, Dexcom’s own first-party app receives data on a near-real 5-minute cycle. Our FRT framework allows a regulator to scrutinise this discrepancy and question whether the longer delays align with legitimate technical and physical constraints.
My time as a Fellow with DTI has reinforced my belief, and the core mission of the ODI, that effective policy must be built on a foundation of technical reality. It has been made clearer to me that we can help ensure that new data portability remedies are not just fast, but effective and truly fit-for-purpose by defining “real-time” in a functional, context-aware way.