Every operator publishing real-time data eventually faces the same question: which standard should the network commit to? The answer is usually presented as a technical detail, settled by whoever configures the feed. It is not a technical detail. The choice determines which platforms can consume your data, which authorities will accept it, and how much integration work each new partner will require for the next decade.
This article compares the two standards at architecture level. For implementation, see our guide on how to integrate GTFS-Realtime and SIRI with existing bus fleet hardware.
The two standards in one paragraph each
GTFS-Realtime extends the GTFS static specification. It was designed by Google to feed consumer journey planners and it inherits GTFS's greatest strength: simplicity. Three feed types cover almost everything an operator needs to publish, namely trip updates, vehicle positions and service alerts. The data model is deliberately narrow, which makes feeds fast to produce and fast to consume.
SIRI, the Service Interface for Real Time Information, is a European CEN standard. It was designed by and for transport authorities, and it reflects that origin: a richer data model, more service types, and explicit support for negotiated exchanges between systems rather than one-way publication. It expresses concepts GTFS-RT cannot express, such as detailed connection protection between services or structured situation descriptions.
Where each standard actually wins
The comparison only becomes useful once you look at who consumes the data.
GTFS-RT wins on consumer reach. Google Maps, Moovit, Transit and most third-party journey planners consume GTFS-RT natively. If your objective is passenger visibility, this is the shortest path, and there is no realistic alternative.
SIRI wins on institutional integration. National and regional access points across Europe are built around SIRI profiles. If a regional authority aggregates data from twenty operators, it will almost certainly specify SIRI, because the standard was designed for exactly that aggregation problem. This is particularly true in the Nordics, where national data infrastructures are mature and specifications are enforced rather than suggested.
SIRI wins on expressiveness. Structured disruption information, planned versus unplanned distinctions, and service interchange concepts have no clean equivalent in GTFS-RT. If your network relies on guaranteed connections between services, GTFS-RT will force you to flatten information you actually need.
GTFS-RT wins on cost of ownership. Fewer message types, less profile negotiation, smaller payloads, more available tooling. On a small or medium network, the difference in implementation and maintenance effort is real.
The question is not which one, but which one first
Framing this as an exclusive choice is the most common mistake. In practice most European operators end up publishing both, because the two standards serve two different audiences that do not substitute for each other.
The right question is therefore about sequencing and about architecture. Which feed do you need first, given your immediate obligations and your visibility goals? And can your system produce the second one later without a rebuild?
That second question is the one that matters over ten years. If real-time state is held in one internal model and standards are treated as output formats, adding a feed is a configuration task. If the standard is baked into the core of the system, adding the second one becomes a project.
The five questions to put to a vendor
Ask these before comparing feature lists.
Which feeds are in production today, and for which clients? Supported is not the same as running. Ask for a live feed URL and the name of an operator using it.
Which SIRI profile, and which version? SIRI is a family of specifications, and national profiles differ. A vendor supporting SIRI in general may not support the profile your regional authority actually requires.
Can both feeds run simultaneously from the same data? If producing GTFS-RT and SIRI requires two separate pipelines, you will maintain two sets of inconsistencies.
What is the end-to-end latency? Measure from the vehicle event to the feed being readable by a consumer, not from the internal database write. The difference between the two figures is often where the real problem sits.
How are service alerts handled? This is where implementations diverge most. A dispatcher entering a disruption once should produce a valid alert in both standards without retyping it.
What this means for your specification
Do not write that the solution must be compliant with GTFS-RT and SIRI. Compliance is claimed by everyone and verified by no one.
Specify observable behaviour instead. Name the exact feeds required and the profile version for each. State a maximum end-to-end latency and how it will be measured during acceptance testing. Require that a single dispatcher action produce consistent output across all published feeds. Require that historical feed data be exportable.
Those four requirements are testable in acceptance. Compliance statements are not.
A note on where this is heading
The two standards are converging in scope but not merging. Consumer platforms show no sign of adopting SIRI, and European authorities show no sign of abandoning it. Assuming that one will absorb the other, and building on that assumption, is the one decision that ages badly.
The durable position is architectural rather than editorial: keep real-time state in a single internal model, treat every standard as an output, and make adding the next one a configuration change. Operators who did this five years ago added SIRI to existing GTFS-RT feeds in weeks. Those who did not are still budgeting for it.
Wondering which feed your network should publish first? Pysae's team can walk through your obligations and your current data setup.