Toll interoperability: what EETS demands of your backend

Toll interoperability is usually presented to the public as a device story: one on-board unit that works across borders. For the operators who have to deliver it, the work sits almost entirely in the backend. The European Electronic Toll Service, EETS, imposes a role separation that most existing toll systems were never designed to express, and the cost of interoperability is the cost of retrofitting that separation into a platform built on the opposite assumption.

The regulation, reduced to its architectural consequence

EETS derives from Directive (EU) 2019/520 and its implementing regulation. The policy aim is that a road user holds one contract and one device, and can drive any tolled road in the Union regardless of who charges for that road.

Delivering that requires two roles to be formally distinct:

• The toll charger operates a toll domain, sets tariffs and is responsible for enforcement. It does not hold a contract with every user driving its roads.
• The EETS provider holds the contract with the user, issues the on-board unit, invoices the user, and stands behind the toll charger's claims for those users.

That is the whole architectural instruction. Everything else in an interoperability programme is a consequence of it, and the programmes that overrun are the ones that treated it as an interface requirement rather than a data model requirement.

The assumption that breaks

A toll system built over a decade for one domain carries an assumption that is rarely written down anywhere: every recorded passage belongs to a customer that this system knows, and the resulting claim is pursued against that customer.

Under EETS neither half holds. A passage may belong to a user whose contract data sits inside another company's platform and is not visible to the charger at all. The claim is not against the driver; it is against the provider representing that driver.

Introducing that concept, a contractual relationship that exists outside your system yet carries a receivable, is the substantive change. It is not a new column. It touches passage assignment, receivables management, dispute handling, enforcement referral and statutory reporting, and in a mature landscape it touches a large number of existing integrations at once.

This is why the first useful deliverable in an interoperability programme is rarely code. It is an inventory of everywhere the current model assumes charger and provider are the same party. That inventory is consistently longer than the architecture documentation suggests, for the same reason interface inventories always are: the assumption propagated into reports, batch jobs and downstream extracts that no one lists as integrations. We covered how those landscapes accumulate in enterprise application integration patterns, and the toll-specific baseline in toll collection system architecture in Europe.

Trust between organisations with no shared infrastructure

Data moves between companies that share no network, no directory and no user administration. Each side has to prove its identity to the other, automatically, for years.

The mechanism is mutual authentication with certificates, which is well understood and generates an operational burden that project plans routinely omit:

• Certificates expire. An expired certificate stops exchange with a counterparty completely. Because validity periods run to years, the first expiry lands long after the project team has moved on. Renewal and monitoring have to be automated, not diarised.
• Counterparties multiply. Every additional provider and every additional domain brings its own certificates, endpoints, test environments and maintenance windows. What three counterparties make manageable by hand, thirty make a standing operational function with an owner.
• Authorisation is row-level. A provider may see the passages assigned to its own users and nothing else. That is a data-level decision, not a system-level one, and it has to hold when a reporting tool queries the store directly rather than going through the interface that enforces it.

The third point causes the most durable damage, because an authorisation check implemented only at the interface is bypassed by every other route into the data. Placing that check at a single enforcement point rather than reimplementing it per application is the core of our IAM and Keycloak work, and the reasoning is set out in Keycloak for enterprise IAM and SSO.

Settlement is defined by its exceptions

Settlement between charger and provider is where commercial risk concentrates, because claims now run between organisations whose interests do not align.

The happy path is undemanding. A passage is recorded, assigned to a provider, included in a periodic statement and paid. The architecture is decided by what happens when that does not occur, and at national traffic volumes the exceptions are numerous in absolute terms even at low rates.

Three cases shape the design:

• The disputed passage. The provider rejects a line because its records place the vehicle elsewhere, the on-board unit was inactive, or the classification is contested. Resolution needs a defined procedure with deadlines, evidence on the charger side that withstands challenge, and an outcome both parties can reconstruct months later.
• The late passage. Enforcement and roadside data do not always arrive promptly, particularly from units with interrupted connectivity. A record that lands after a period has closed must flow into a supplementary run without reopening a closed period, because reopening breaks every reconciliation downstream.
• The unassignable transit. A detection with no valid provider assignment cannot simply be dropped. It belongs in a clearing pool with follow-up, and the size of that pool is an operational metric that should be reported rather than tolerated.

All three impose the same underlying requirement: every line has to be traceable from detection to statement, with timestamp, source and each processing step retained. Without that lineage a dispute cannot be argued, and the charger absorbs the loss by default. The settlement mechanics themselves are covered in more depth in cross-border toll billing integration patterns.

Evidence is decided at capture, not at dispute

EETS shifts where the burden of proof sits. While charger and provider were the same organisation, doubt about a detection was an internal quality matter. Once the claim runs against another company, the same doubt becomes a commercial dispute with a counterparty that has every reason to press it.

What makes a detection defensible is fixed at capture time, not when it is challenged months later. Three properties carry most of the weight:

• Corroboration. An assignment resting solely on the on-board unit's signal is harder to defend than one supported by an independent observation. Where a second source exists, it belongs attached to the record rather than in a separate system nobody joins under time pressure.
• Immutable storage. Any later correction must remain visible as its own event with timestamp and author. A store where records can be overwritten in place loses its evidential value entirely, regardless of whether anything ever was overwritten, because the counterparty only has to establish that it could have been.
• Retention aligned to the dispute window. If evidence is deleted before the last possible challenge expires, the gap appears precisely when it is expensive. Reconciling data protection requirements against evidential need belongs in the design, not in an operational exception later.

The second property is where existing systems most often need retrofitting. Detection stores were historically built as working data with operator correction, which was reasonable in single-party operation. In multi-party operation it is the first thing a counterparty's audit will attack.

Classification belongs in reference data

Vehicle classification is not harmonised across member states. Axle count, maximum permissible weight, emission class and trailer status enter the calculation with different weightings, and one physical vehicle configuration can fall into different classes in two domains.

The recurring mistake is to treat that mapping as part of rating logic. Once conversion between classification schemes lives in rating code, a tariff change in one country becomes a software change, and onboarding a new domain becomes a development project with a release cycle attached.

Holding the mapping as versioned reference data with validity periods, and having rating read it, converts a tariff change into a data change with an approval step. The validity periods are not optional: a passage from last month must be rated under the tariff in force at the time of travel even when rating happens later, and systems that store only the current tariff cannot reproduce their own historic invoices.

Operating in a multi-party model

Interoperability changes day-to-day operations as much as it changes architecture, and that part rarely appears in the project mandate.

In single-party operation an incident was an internal event with one owner. In multi-party operation the same incident involves counterparties with their own operating hours, escalation paths and maintenance windows. Three requirements follow, and they should be settled before the first counterparty is connected.

Each counterparty needs a named technical contact and an agreed response time. Without that agreement, resolving a transmission fault takes as long as the slower party needs, while receivables continue to accrue against a flow nobody is currently reconciling.

Maintenance windows have to be coordinated. A counterparty that takes its interface down unannounced creates a backlog on your side whose clearance takes longer than the outage itself, because catch-up processing competes with the current day's volume. At national traffic levels a few hours of backlog is its own incident with its own recovery plan.

Monitoring needs a per-counterparty view. A single aggregate health metric across all providers hides the failure of one connection until it is large enough to move the total, by which point days have passed. Monitoring has to alert that a specific connection has delivered nothing for longer than its own normal interval, and that interval has to be derived from each counterparty's actual rhythm rather than from one global threshold. Providers differ substantially in batch cadence, and a threshold tuned for the busiest one is blind to the quietest.

A migration path that survives contact with production

For an operator with a working toll system, a full rebuild is rarely the right answer. The sequence that holds up runs in four steps.

Extend the data model to carry the external contractual relationship first, without altering existing processing. Then build the exchange layer toward counterparties as a component sitting in front of the core, so the core never learns the protocol details and can be replaced independently later. Then run one counterparty through a complete settlement cycle, including at least one disputed line, because only a dispute exercises the resolution path. Only then onboard further providers.

The third step is the one most often compressed, since a cycle with no dispute completes faster and looks like progress. A cycle without a dispute demonstrates that the happy path works. The happy path was never the risk.

Our work on tolling and road charging platforms generally starts at the same question, and it is not whether a system can be made interoperable. It is which assumption in the existing data model stands in the way. That assumption is nearly always the same one, and it is nearly never written down.