A fleet customer emails their GPS provider: "Under the Data Act, please send us all the data our trackers have produced since January, and send a copy to our insurer." Support opens the portal, runs the mileage report for each month, exports the CSV and replies with a few attachments.
The customer did get a file. They did not get what they asked for.
This post is an operations and product view for telematics operators. It is not legal advice, and whether the Data Act applies to a given operator, device or service is a question for your counsel.
What changed for telematics operators
The EU Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025. Since then, the user of a connected product, such as a fleet that runs retrofit trackers, can ask for the data the product and its related service produce, and can ask for it to be made available to a third party they name. An insurer, a leasing company, a workshop or a transport management system are the usual examples.
From 12 September 2026, a second step applies. Connected products and related services newly placed on the EU market must be designed so that this data is accessible to the user by default: easily, securely, free of charge and in a structured, machine-readable format. A new tracker model or a new portal release launched now falls under that rule.
For vehicles, the European Commission's guidance on vehicle data (published 12 September 2025) draws a line that matters for every operator. Raw and pre-processed data, such as positions, speed, odometer readings and fuel or battery values, together with the metadata needed to read them, are in scope. Derived data, meaning the results of the operator's own analysis, is not.
Why the mileage report is the wrong answer
Most operator back offices were built to sell analysis. They export mileage per vehicle per month, trip summaries, driving scores and alert histories. Those are useful products, and they are exactly the derived outputs the guidance places outside the request.
What the customer asked for sits one layer down: the position and event stream for their devices, the device attributes, and a description of what each field means, its units and its time zone. On a Traccar-based platform, that data already exists. It is simply not something the portal was ever asked to hand over.
Three things usually go wrong when requests are handled through support:
- The wrong data goes out. A summary report instead of the raw records, so the request is not really answered.
- Too much data goes out. A database export or a broad login reaches other vehicles, other tenants or driver details that were never part of the request.
- Nobody can say what went out. There is no record of who asked, which devices and dates were covered, who received the data and when.
Why a sub-user login is not sharing
The common shortcut for third parties is a portal login. The insurer gets a sub-user account and "can see everything they need".
They can also see everything else in that customer account, for as long as the account stays active, with no link to what the customer agreed to share. A directed-sharing request is narrower: these vehicles, this data, this recipient, until this date. A login does not hold any of that, and it does not expire on its own.
Where the data identifies a driver, data-protection rules still apply on top. That is another reason to keep sharing scoped and logged rather than open-ended.
What a data-access page looks like in an operator Admin
The fix is not a new reporting dashboard. It is a separate page, per client account, that treats data access as its own workflow:
- Self-service raw export. The client picks devices and a date range and downloads positions, events and device attributes in CSV or JSON, with a metadata sheet that lists field names, units, time zone and device model.
- Directed sharing. The client names a recipient, chooses devices, data scope and an end date, and the system issues a scoped link or API access that can be revoked and that expires on its own.
- A request and delivery log. Who asked, what was covered, who received it and when, kept with the client account rather than in a support inbox.
- A plain "what we collect" page. Built from the device models the operator actually sells, so the customer can see before signing what data exists and how to get it.
- Derived products kept apart. Mileage reports, risk scores and alerts stay where they are, as the operator's own service, not mixed into the raw export.
None of this replaces the tracking engine. On Traccar, the raw records are already stored. The work is the customer-facing layer around them: scoping, delivery, expiry and audit.
Where it sits in a back office we built
We built GeoLox Admin end to end: the back office for an insurance-telematics operator running on Traccar. It already holds the pieces a data-access page would hang from: a Traccar connection with user and device sync, client users with their own sub-users, device import, a mileage report with CSV export, and per-device subscriptions.
To be clear about scope: GeoLox Admin is the example here because it shows where such a page belongs, next to clients, devices and subscriptions. This post does not describe a Data Act feature of GeoLox Admin or claim any compliance work.
A short checklist for operators
- Can a client export raw positions and events for chosen devices and dates without opening a ticket?
- Does every export come with a description of the fields, units and time zone?
- Can a client share data with a named third party for a limited time, and revoke it?
- Is there a log of each request and each delivery?
- Are derived reports clearly separate from the raw export?
- Does the next device model or portal release you launch have access built in from day one?
If most answers are "no", the gap is in the product, not in the support team.
Talk to us
We build Laravel admin panels and Flutter apps on Traccar for GPS and fleet operators. If you want to plan a data-access and sharing page for your platform, alongside your counsel's advice, talk to us at https://techmania.solutions