EV Roaming Solutions: OCPI, OICP & Cross-Network Charging Implementation
Drivers have decided EV charging is one market. Operators still pay for three: a hub fee on every outside transaction, an integration cost per bilateral partner, and an internal reconciliation burden that grows with every counterparty. Closing that gap is what EV roaming is supposed to do. In most deployments, it mainly relocates the cost.
The Roaming Paradox: Drivers Want One Network, Operators Pay for Three
A Charge Point Operator (CPO) exposes its stations to outside demand but routes that demand through a hub that takes margin on every session. An e-Mobility Service Provider (eMSP) extends coverage by paying another company to handle commercial relationships with stations it could otherwise reach directly. Both sides gain reach; both sides hand margin to the intermediary; both sides accept a settlement pipeline they do not fully control.
The way out is not better hub negotiation. It is a platform architecture that stops treating ev roaming as a separate integration project and starts treating it as a property of the eMSP/CPO stack itself.
Why the Hub-Only Route Has Quiet Economics
Roaming hubs like Hubject, Gireve, and e-clearing.net are cheap per transaction and expensive per strategy. Fees typically run a few cents per kilowatt-hour or a low-single-digit percentage of the session. At small volume that is invisible. At 10,000 roaming sessions a month and a 40 kWh average, a realistic profile for a mid-sized eMSP in one national corridor, hub economics quietly take six figures a year per route.
Hubs are right for long-tail coverage: the networks a driver touches once a year on holiday. They are wrong for the five or ten counterparties that carry most of the volume. Operators who recognise this early design their platform so bilateral integration does not require a parallel engineering team.
The OCPI Middleware That Quietly Decided the Market
OCPI (Open Charge Point Interface), governed by the EVRoaming Foundation, stopped being one option among several years ago. Regulation pulled it forward, every hub except Hubject now speaks it natively, and Hubject translates to it on the way out. For an eMSP or CPO platform the consequence is direct: if the stack cannot speak fluent OCPI (Locations, Sessions, Tariffs, CDRs, Tokens, plus the Plug & Charge flows added in 2.3) it is ev roaming-ready in name only.
Our OCPI protocol architecture guide walks the module model in depth; the OCPI vs OICP comparison covers how Hubject’s proprietary layer fits around it. What matters commercially is that OCPI-native platforms retain optionality (hub, bilateral, or direct AFIR compliance) while Hubject-first platforms do not.
Roaming Hubs at a Glance
The right hub is less about feature lists and more about governance model, protocol stance, and regional centre of gravity.
| Hub / Platform | Headquarters | Primary Protocol | Geographic Reach | Typical Fit |
|---|---|---|---|---|
| Hubject | Germany (Berlin) | OICP (native); bridges to OCPI |
Global, strongest in DACH with broad automotive-OEM presence | Operators prioritising reach across automotive-brand networks and Plug & Charge ecosystems |
| Gireve | France (Paris) | OCPI native | Europe, strongest in France, Benelux, Iberia | EU CPOs and eMSPs wanting a single OCPI-first hub without a proprietary translation layer |
| e-clearing.net | Netherlands | OCPI native | Europe, non-profit, multi-country membership | Operators preferring a neutral, cooperative governance model over a commercial hub |
| EVRoaming Foundation | Netherlands | OCPI (standards body, not a hub) | Global specification, adopted by hubs and operators alike | Reference point for the protocol itself, not a hub an operator joins |
When Peer-to-Peer Actually Pays
Peer-to-peer OCPI integration is often dismissed as heavyweight. That is correct for an operator running only hub-routed traffic, and wrong for one whose volume has concentrated on a handful of counterparties. The crossover is predictable. Once a corridor carries a few thousand roaming sessions a month with a single partner, bilateral OCPI pays back the integration cost inside a quarter and keeps paying afterwards.
In a recent engagement with a European eMSP client, replacing two hub-routed corridors with direct OCPI connections recovered roughly 18% of margin on that volume. The technical work was not the bottleneck. Tariff mapping across national markets and aligning token authorisation (RFID, app tokens, Plug & Charge) across counterparties consumed most of the effort. Fleet-focused operators face a related monetisation pattern covered in our note on NACS + roaming monetization for fleet hubs.
AFIR and NEVI Turned Compliance Into a Roaming Stack
Roaming used to be commercial strategy. It is now partly regulatory. The European Union’s Alternative Fuels Infrastructure Regulation (AFIR, 2023/1804) requires public CPOs to publish real-time availability and pricing data and make both accessible to eMSPs, with OCPI the default implementation path. The US NEVI formula program builds interoperability into federally funded charging sites and, even at reduced funding, has pulled US operators toward OCPI faster than the market would have done alone. The build was coming anyway. The window to do it on commercial terms rather than under compliance pressure is closing.
The Build That Eats Two Quarters: Where the Time Actually Goes
A competent OCPI stack can be in production in four to six weeks if the operator starts from a certified codebase such as our OCPI Accelerator; from scratch the same work runs nine to twelve months. The protocol itself is rarely the schedule risk. Two things are. Every market has local tariff structures (peak tiers, idle fees, grace periods, subscription discounts) that must flatten into OCPI’s tariff object without losing commercial intent. Token authorisation across counterparties is the other trap, where RFID, app tokens, and Plug & Charge identifiers converge in ways that rarely match the textbook.
A full eMSP-side platform view is covered in our eMSP platform architecture pillar. A sensible sequence for a first-time ev roaming build is to lock module scope first, pick hub or bilateral as the opening move, use conformance tooling from the Open Charge Alliance for testing, and launch on one corridor before expanding.
One Roaming Architecture, Not Three Integration Silos
Operators who win the next cycle will treat OCPI, OICP, and cross-hub routing as one platform layer, not three integration projects bolted on as each counterparty appears. The layer scales linearly with partners when designed in, and exponentially in maintenance cost when not. The standards are stable, the regulatory pressure is real, and the commercial case for owning the integration layer is clearer than it was twelve months ago. For operators ready to move, Codibly offers OCPI and OICP integration services and an accelerator stack that compresses months of protocol work into weeks.
Frequently Asked Questions
EV roaming lets a driver start a charging session at a station run by one operator using an account issued by another, with authentication, pricing, and billing handled in the background. It borrows the mobile-telephony model: drivers keep their home provider, operators settle invisibly, and the network stretches wherever roaming agreements exist. On the asset side the same mechanism is sometimes called ev charging roaming.
They solve different problems. OCPI is an open standard for the CPO-to-eMSP exchange and is the default for direct bilateral roaming and AFIR-aligned data sharing in the EU. OICP is Hubject-native and required to interact with Hubject’s intercharge network. A production eMSP platform typically implements OCPI as the primary interface and OICP specifically for Hubject connectivity. Our OCPI vs OICP comparison has the full breakdown.
With a pre-built, certified OCPI stack, hub onboarding typically takes four to eight weeks, depending on module scope and tariff complexity. Building the stack from scratch adds nine to twelve months before the first live session. Most operators underestimate tariff mapping and token authorisation, not the protocol itself.
Yes. Peer-to-peer OCPI integration is how most enterprise and fleet agreements are structured. It removes the hub’s cut and leaves both sides in control of commercial terms, though each new partner is a separate onboarding. Peer-to-peer and hub membership are most often run together: the hub for broad reach, bilateral deals for the corridors that move the most volume.
For the driver, ideally like nothing at all. The app shows every station on the route, including those on networks the driver has never enrolled with. The home eMSP token (or Plug & Charge where supported) authenticates the session, pricing appears before it starts, and the invoice arrives on the usual statement. Behind the scenes, OCPI Session and CDR messages flow between the CPO, the hub or bilateral partner, and the eMSP in near-real time. US networks such as EVgo publish their roaming partners openly, which is why en route EV charging on those corridors feels indistinguishable from charging on a driver’s home network.