Catalog / Anomaly, Fraud & Risk Detection / ANOM-039

Haulage fleet compliance and fuel/telematics anomaly detection

Read tachograph downloads, flag driving and rest-time violations, reconcile tachograph, telematics and time-clock data per driver, and compare fuel card, toll and telematics data per truck to find unusual consumption, fuel theft and recording errors.

A German haulage firm must read, evaluate and archive tachograph data, answer for every driving- and rest-time violation, and at the same time watch the largest cost block after wages: diesel. In practice, dispatchers or the owner scroll through evaluation lists, compare fuel-card statements with tour data by hand and correct time records late in the month. Rule-based tachograph tools already do the legal evaluation well. AI adds what rules miss: reconciling three data sources per driver, spotting trucks that burn more than they should, and drafting the warnings and corrections.

Problem & value

  • Today: tachograph files are downloaded (often in bulk), evaluated in a rule-based tool and the violation list is worked through by hand. Fuel card invoices, toll statements and telematics reports sit in separate portals and are checked only when a number looks odd. Time records from the tachograph, the telematics system and the payroll time-clock differ and are corrected manually before payroll.
  • Legal pressure: the company, not the driver, carries the duty to download the data on time (vehicle unit within 90 days, driver card within 28 days), to evaluate it and to take effective measures against violations and operating errors; the IHK points out that this core duty cannot really be handed to a service provider [1]. Smart tachograph version 2 records border crossings and loading/unloading, and authorities can check vehicles remotely at the roadside, so gaps and manipulation become more visible to enforcement [2].
  • AI value: (1) the rule engine finds the violation, AI finds the pattern behind it (same tour, same dispatcher, same shipper waiting time); (2) cross-source checks find missing manual entries, other-work gaps and implausible card-less driving; (3) per-truck consumption baselines separate driving style, load, route and weather from real anomalies such as siphoning, card misuse or a leaking tank; (4) an LLM drafts the driver query, warning or time-record correction for a human to release.
  • Honest sizing: vendor claims about fuel savings and theft rates in the market are mostly self-reported and sometimes contradict each other; treat any "x % theft" number as unverified. The solid value is time saved on evaluation and reconciliation and earlier detection of obvious outliers, not a guaranteed fuel saving.
  • Boundaries: tour optimisation is OPT-001, charging of electric trucks OPT-021, driver camera monitoring VIS-028, driving-style scoring for insurance PRED-030, general payroll checks ANOM-037, and expense fraud ANOM-009.

Variants

  • Compliance only: tachograph evaluation plus AI summaries and warning drafts. The most mature variant.
  • Fuel and telematics only: fuel card vs telematics reconciliation and per-truck consumption outliers.
  • Combined: one driver/truck/day record joining tachograph, telematics, fuel, toll and time-clock data. Highest value, highest data effort.
  • Subcontractor and light-vehicle fleets: since 1 July 2026 light commercial vehicles over 2.5 t in international transport need a smart tachograph v2 and fall under the driving and rest-time rules [2], so more small firms enter scope.
  • Private use: not applicable.

How it works

  1. sources: tachograph downloads (vehicle unit + driver card) / telematics / fuel and toll cards / time-clock / TMS tour data
  2. ingestion + identity matching (driver, card, plate, trailer, tour, station)
  3. legal rule layer (daily/weekly driving time, breaks, rest periods, missing entries, card and download gaps)
  4. cross-source reconciliation (tachograph vs telematics vs time-clock, per driver and day)
  5. fuel layer (litres bought vs tank capacity and vehicle position, consumption per 100 km vs truck baseline)
  6. anomaly layer (peer and history baselines, time-series residuals, isolation forest; context: load, route, season)
  7. LLM layer (explain flag, draft driver query / warning / time-record correction)
  8. human review (dispatcher, fleet manager, HR)
  9. case log + feedback labels
  • Rules first: violations are defined by law and must be reproducible, so the legal evaluation stays rule-based and certified tools remain the basis. AI does not decide what counts as a violation.
  • Anomaly detection: consumption per truck is a time series with strong context effects (payload, topography, stop-and-go, reefer unit, winter). Residuals against a per-truck model, or against comparable trucks on the same routes, are more reliable than fixed thresholds; a rule of thumb sometimes quoted in fleet-management material is to review deviations above roughly 5 % per vehicle and month (not verified against a primary source; a starting point, not a standard).
  • Fuel-theft logic: the strongest signal is a fuel-card transaction with no matching vehicle position or a volume larger than the tank can take; a fall of the tank-level signal while stationary is the second. Not every anomaly is fraud (sensor drift, refuelling of reefer units, canister fuel for machines).
  • Human-in-the-loop: a flag is a reason to ask, not proof. Drivers get to explain before any consequence.

Data preparation

Which data: tachograph files with driver and vehicle identifiers, telematics exports or API data (position, odometer, fuel level, consumption), fuel and toll card transactions, time-clock records, tour data from the TMS, vehicle master data.

Where it lives: tachograph evaluation tool and download terminal or remote download service, telematics portal of the truck maker or a third party (e.g. Webfleet, Fleetboard, Geotab), fuel card provider portals, the toll provider, the payroll/time-recording software, the TMS and Excel sheets of the dispatchers.

Typical gaps: driver cards not assigned or missing in the master data, plates changed after trailer swaps, telematics fuel signals uncalibrated or absent in mixed fleets, fuel cards used for several trucks, free-text tour data, and time-clock data that is entered later by hand. Different clocks and time zones make joins hard.

Preparation steps: 1. Build one master table: driver, driver card, truck, trailer, fuel card, telematics unit (PREP-005). 2. Switch to remote download or a download terminal so files arrive complete and on time. 3. Check the fuel level and consumption signals per truck, mark trucks without a usable signal. 4. Align timestamps and time zones across all sources. 5. Collect 6-12 months of history per truck for baselines and a list of already known cases as labels (PREP-020). 6. Restrict access: the data shows individual drivers (PREP-023).

Tools: the existing tachograph and telematics exports, SQL or DuckDB, a spreadsheet for the first reconciliation.

Rough share of effort: about 40-50 percent of the project, mostly identity matching and cleaning mixed telematics sources. See GUIDE-003.

Implementation paths

Which path for whom

  • SMB — Path A: most telematics and tachograph vendors already offer evaluation, alerts and fuel reports; an add-on is faster than a build for a fleet of 20-100 trucks.
  • Enterprise — Path B: large or multi-brand fleets need their own reconciliation across several vendors, ERP and payroll, so a data pipeline on cloud APIs fits.
  • Developer — Path C: open-source anomaly detection on own hardware keeps driver data in-house and runs on CPU.
  • Tachograph evaluation: established tools for download management and violation lists, for example from the tachograph manufacturers and fleet-software vendors (TIS-Web / DTCO ecosystem, Transics/Trimble, Webfleet, Fleetboard, Geotab, Samsara and specialist evaluation tools). Check which ones offer AI-based summaries rather than fixed lists.
  • Telematics fuel reports: per-trip and per-100-km consumption with thresholds and alerts exist in mainstream platforms [3]; the Webfleet page documents alerts, outlier analysis and fuel reporting but does not itself describe fuel card matching or theft detection, so ask vendors specifically for card-to-vehicle reconciliation.
  • Fuel card providers: many provide their own plausibility alerts (card used far from the truck, over-tank volumes). Quality varies; test with your own history.
  • Choose A when: one telematics vendor covers most trucks and the process is standard. Verify EU hosting, a DPA (AVV), works-council readiness and how scores are explained.

Path B — Build on cloud APIs

  • Data layer: telematics vendor APIs, fuel-card and toll exports and the TMS in a warehouse in an EU region.
  • Analytics: gradient boosting or time-series residual models per truck, an anomaly library such as PyOD, run in a managed ML service.
  • LLM layer: an EU-hosted model drafts explanations, driver queries and correction proposals; pseudonymise driver names before the call.
  • Choose B when: you have several telematics brands or want fuel, tachograph and payroll in one view.

Path C — Self-host (open source)

  • Stack: Postgres or DuckDB, scikit-learn, PyOD or Prophet-style forecasting, Grafana for dashboards, n8n for the workflow; a small local LLM (llm-small class) for drafts.
  • Hardware: HW1; the analytics run on CPU. The legal tachograph rules still need a certified evaluation tool or a very carefully tested rule set.

Path D — Custom training

Only for large fleets with years of labelled theft and fault cases, for example a per-truck consumption model trained on CAN-bus data. Rarely justified for a mid-sized haulier.

State of the art (2026)

  • Rule-based tachograph evaluation is a commodity; AI-assisted explanations and cross-source reconciliation are early-adopter features, offered by some vendors but not yet standard.
  • Smart tachograph v2 is mandatory in international transport for heavy vehicles since 19 August 2025 and for light commercial vehicles over 2.5 t since 1 July 2026; remote enforcement equipment is in place in the Member States [2]. This raises the cost of undetected violations.
  • Fuel anomaly detection works well for obvious cases (transaction without vehicle presence, over-tank volumes). Subtle siphoning and diffuse driving-style effects remain hard because consumption depends on load, route and weather. Many public accuracy figures come from vendor blogs without method; do not rely on them.
  • Limits: poor or missing fuel-level signals in older trucks, label scarcity, concept drift with seasons and new routes, and false positives that damage trust with drivers. The legal verdict on a violation always needs a human and the original data.

Shared resources & combinations

  • Anomaly stack (anomaly-detection, tabular-ml, time-series): shared with ANOM-005 (industrial sensors), ANOM-037 (payroll validation, same time-record reconciliation logic) and ANOM-009 (card spend). One feature store with entity resolution serves all.
  • Same fleet data: OPT-001 (tour planning) needs the same plan-vs-actual data; PRED-006 (predictive maintenance) uses the same CAN-bus signals; VIS-028 and PRED-030 touch driver behaviour and should be governed by the same works agreement.
  • Documents: DOC-006 reads delivery notes and DOC-001 fuel and toll invoices; both feed reconciliation.
  • Downstream: AGENT-006 for the monthly close and cost allocation per truck.

Effort, cost & KPIs

  • Path A: weeks to activate if the telematics vendor is already in place; add-on pricing typically per vehicle and month.
  • Path B: 3-6 months for data integration, models and workflow; integration of mixed telematics sources is the cost driver.
  • Path C: 3-6 months with a data engineer; low running cost.
  • KPIs: share of downloads on time, violations per 1,000 driving hours, time spent on evaluation per week, mismatches between tachograph and time-clock found and corrected, share of fuel transactions reconciled automatically, confirmed fuel anomalies per quarter, false-positive rate, litres per 100 km per truck group.

People & change

Involve early: management (mandate and the rule that flags are indications), the fleet manager or head of dispatching as process owner, IT for telematics and payroll interfaces, and the data owners of the fuel card and time-recording data. The DPO and the works council come before any driver-level analysis starts.

Works council: yes. A system that combines driving, rest, position and fuel data per named driver is objectively suited to monitor behaviour and performance (§87(1) no. 6 BetrVG); §90(1) no. 3 requires early information about AI-supported work processes. A works agreement should name the purposes (legal compliance, theft protection, time-record correction), exclude continuous performance ranking, set retention and forbid automatic sanctions (GUIDE-004).

AI literacy: Art. 4 AI Act requires measures for staff; train dispatchers on what a flag means and how to talk to drivers (GUIDE-006).

Communication and pilot: present the tool as relief from list work and as protection of honest drivers against wrong accusations. Start with 5-10 trucks, run in shadow mode for 2-3 months, and track false positives before acting on flags (GUIDE-008, GUIDE-009).

Typical concerns: driver surveillance (limit purposes, be transparent), fear of dismissal for small violations (human decision, coaching first), blame shifting between dispatch and driver (the pattern view shows when the schedule causes the violation).

Risks, regulation & compliance

  • Driving-time law: Regulation (EC) No 561/2006 (driving times, breaks, rest), Regulation (EU) No 165/2014 on tachographs, as amended by Mobility Package rules, the German Fahrpersonalgesetz and Fahrpersonalverordnung (§2 FPersV on downloads), and the Arbeitszeitgesetz for working time. Download deadlines are 90 days for the vehicle unit and 28 days for the driver card, counted from the first event after the last download [1]. Enforcement in Germany lies with BALM and the Land authorities; fines for violations can hit both driver and company.
  • EU AI Act: depends. Pure fuel and consumption analytics is minimal risk. Annex III point 4(b) lists AI intended to monitor and evaluate the performance and behaviour of workers as high-risk; a system that scores individual drivers and drives disciplinary action may fall under it. Design it as compliance and cost anomaly detection with human decisions, document the intended purpose, and have it assessed legally [4].
  • GDPR and BDSG: vehicle data is personal data once a vehicle is assigned to a driver. Consent is hardly voluntary in employment, so the basis is §26 BDSG or Art. 6(1)(f) with a balancing test; continuous 24/7 monitoring of work behaviour is not justifiable, theft protection and legal compliance can be; secret tracking is generally unlawful. A DPIA is regarded as mandatory for this kind of monitoring, which also requires a DPO under §38 BDSG [5]. Use short retention for position data and pseudonymised aggregates for fleet evaluation. Art. 22 GDPR: no solely automated decisions with significant effect.
  • Labour and tax: minimum wage and working-time documentation (MiLoG) rely on correct time records; GoBD applies to archived fuel and toll invoices.
  • Mitigations: keep the legal evaluation rule-based and reproducible, log AI suggestions versus final decisions, test flag rates per driver group, let drivers comment before consequences.

Getting started

  1. Check that downloads run on time (90/28 days) and are gap-free; fix this before any AI.
  2. Get works council and DPO on board; write purpose, data scope and retention down.
  3. Build the master table driver-card-truck-fuel card and run a one-month manual reconciliation of tachograph vs time-clock.
  4. Join fuel card and telematics for 6-12 months and list transactions without vehicle presence and the top consumption outliers per truck.
  5. Ask your current vendors which of this they already offer; add a custom layer only for the gaps.
  6. Pilot with a small group in shadow mode, record outcomes as labels, then expand.

Sources

  1. IHK Stuttgart — Auslesen von Fahrerkarten und Fahrzeugeinheiten (90/28-day deadlines, employer duty to evaluate; page dated 2020) — https://www.ihk.de/stuttgart/branchen/verkehrswirtschaft/sozialvorschriften-beschaeftigung/sozialvorschriften/auslesen-von-fahrerkarten-682606
  2. European Commission — Smart tachograph version 2: enforcement and retrofit phases (19 August 2025; light vehicles from 1 July 2026) — https://transport.ec.europa.eu/news-events/news/stronger-and-more-unified-enforcement-eu-rules-international-road-transport-smart-tachograph-2025-08-19_en
  3. Webfleet — Fuel monitoring and analysis (vendor page; alerts, outlier analysis, reports) — https://www.webfleet.com/en_gb/webfleet/fleet-management/fuel-management/fuel-monitoring
  4. AI Act — Annex III high-risk systems (point 4 employment and worker monitoring) — https://artificialintelligenceact.eu/annex/3/
  5. Dr. Datenschutz — GPS-Überwachung am Arbeitsplatz und der Datenschutz (legal basis, DPIA, retention) — https://www.dr-datenschutz.de/gps-ueberwachung-am-arbeitsplatz-und-der-datenschutz/
  6. EUR-Lex — Regulation (EC) No 561/2006 on driving times and rest periods — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32006R0561
  7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj