The January 2026 AFIR mandate forced a hardware upgrade across Europe’s public charging networks. New payment terminals arrived. ISO 15118 firmware shipped. Compliance boxes were checked.

But a quieter problem emerged alongside the new hardware: the data behind those payment terminals is now stranded. The terminal reports one ad-hoc price. The driver-facing mobile app shows another. The roaming partner receives a third figure through OCPI. For a driver, this is confusing. For a CPO reporting to a National Access Point (NAP), it is an AFIR compliance failure waiting to happen.

AFIR’s data transparency requirements demand a single, consistent truth about pricing and availability flowing from every charger to national registries. Most operators assumed the hardware would handle this. It does not. The hardware captures data, but it does not reconcile it. That responsibility falls squarely on the software architecture connecting the terminal, the OCPP backend, and the roaming layer. And in most charging networks today, those three systems were never designed to talk to each other.

The Three-Stream Problem

To understand why AFIR payment terminals create data silos, you need to follow the data through three parallel streams that rarely converge.

Data Stream Source Format Destination
Payment Terminal Card reader / NFC unit (vendor-specific) CSV export, proprietary API, or batch upload Payment processor, then accounting
Mobile App / Backend OCPP connection between charger and CSMS OCPP MeterValues, StatusNotification, session records Driver app, fleet dashboard, internal analytics
Roaming Partner OCPI interface between CPO and eMSP OCPI Tariffs, CDRs, Sessions modules eMSP partner systems, National Access Point

Each stream was built by a different vendor, at a different time, for a different purpose. The payment terminal vendor optimized for PCI compliance. The CSMS team optimized for charger uptime. The roaming integration was bolted on to meet OCPI requirements for cross-network access.

The result: three isolated data stores, each holding a partial view of the same charging session. When a driver plugs in, the terminal logs a transaction. The CSMS logs a session. The OCPI interface creates a CDR. If the dynamic pricing logic in the CSMS does not propagate to the payment terminal and the OCPI tariff object in real time, these three records diverge.

That divergence is where AFIR compliance breaks down — and where NAP reporting becomes unreliable.

What AFIR Actually Requires (And Why Silos Fail the Test)

Article 5 of AFIR and the associated Delegated Acts require that operators provide “static and dynamic data” to National Access Points. This includes real-time pricing, connector availability, and power output. The data must be accurate, current, and consistent across all consumer-facing channels — and from April 2026, it must be delivered in DATEX II format.

A CPO cannot satisfy this if:

  • The payment terminal shows a cached price that was accurate two hours ago.
  • The OCPI tariff sent to roaming partners uses a different pricing formula than the app.
  • The CSMS holds session data that never reaches the NAP because the reporting pipeline only pulls from the terminal vendor’s export.

This is the operational reality for many networks that scaled quickly through Q4 2025 to meet the January deadline. Terminals were installed by one vendor. The CSMS was managed by another. The OCPI layer was handled by a third. Nobody owned the data reconciliation layer, because nobody was asked to build one.

Fixing the Architecture: A Unified Data Layer

The fix is not a better payment terminal. The fix is an interoperability layer that connects the terminal, the CSMS, and the roaming interface into a single source of truth.

In practice, this means three architectural decisions:

  1. OCPP as the canonical data source. The OCPP backend should be the authoritative record for every charging session. MeterValues, StatusNotification, and TransactionEvent messages already carry the richest, most granular data. Payment terminal transactions and OCPI CDRs should derive from this canonical source rather than maintaining independent records.
  2. Real-time pricing propagation. Dynamic pricing decisions (whether driven by time-of-use, grid load, or demand signals) must propagate simultaneously to the payment terminal display, the mobile app, and the OCPI Tariffs module. This is an event-driven architecture problem: when a pricing decision is made in the CSMS, every downstream system must receive it within seconds.
  3. A single NAP reporting pipeline. Rather than stitching together data from three vendors into a quarterly export, the reporting layer should read directly from the unified OCPP dataset. This ensures the data flowing to National Access Points matches what the driver sees on the terminal and what the roaming partner sees in the CDR.
Architecture Component Current State (Siloed) Target State (Unified)
Session record Terminal, CSMS, and OCPI each create independent records OCPP TransactionEvent is the single source; terminal and OCPI derive from it
Pricing Terminal vendor controls display; CSMS calculates; OCPI publishes separately Pricing engine pushes to all three endpoints simultaneously
NAP Reporting Manual export from terminal vendor + OCPI data stitched together Automated pipeline reads directly from unified OCPP data store
Reconciliation End-of-month manual reconciliation (if it happens at all) Real-time validation: every session is cross-checked across streams on completion

This is not a theoretical architecture. When a major US utility needed to unify 70+ datasets from siloed legacy systems into a single decision-support platform, the core principle was the same: designate a canonical data source, build real-time pipelines from it, and retire the manual export-and-reconcile workflow. The domain was different, but the data integration pattern is directly transferable to CPO operations.

Why This Matters Beyond Compliance

Here is the strategic argument for fixing data silos now rather than treating them as a Q2 cleanup task.

The Network Code on Demand Response (NC DR) is expected to open flexibility markets to EV charging infrastructure in 2027. To participate, a CPO must demonstrate real-time visibility into charger state, power output, and load flexibility. That visibility requires exactly the kind of unified data architecture described above.

A CPO whose OCPP backend, payment layer, and roaming interface operate as isolated islands cannot provide the granular, real-time data that grid operators and aggregators need to dispatch flexibility signals. The data silo problem is a compliance risk today and a revenue blocker tomorrow.

The operators who consolidate their data architecture in 2026 will enter 2027 with the infrastructure to monetize their charging network as a grid asset. Those who postpone the fix will spend 2027 retrofitting their software on a deadline, the same way many spent late 2025 retrofitting their hardware.

One Data Architecture, Not Three Compliance Workarounds

AFIR compliance does not end at the payment terminal. The terminal is one data source among three, and unless those three sources converge into a single, authoritative record, the data transparency that the Alternative Fuels Infrastructure Regulation demands will remain out of reach.

The technical path forward is clear: establish OCPP as the canonical session record, propagate pricing decisions in real time across all consumer-facing channels, and automate NAP reporting from the unified dataset. This is a solvable architecture problem, and solving it now positions your network for the flexibility revenue that the NC DR will bring.

The question worth asking now: does your data architecture serve three separate compliance requirements, or does it serve one unified operational truth?