OCPI vs OICP: Choosing the Right EV Roaming Protocol
Two protocols dominate EV roaming in Europe and increasingly worldwide: OCPI (the Open Charge Point Interface) and OICP (the Open Intercharge Protocol). Both solve the same fundamental problem — enabling drivers to charge on networks they don’t have a direct account with — but they differ substantially in architecture, governance, and market philosophy.
Choosing between them is not a technical exercise. It’s a market-access decision. The EV roaming protocol you implement determines which roaming hubs you can connect to, which partners you can reach, and how much architectural flexibility you retain as EV roaming protocols evolve.
Why EV Roaming Protocols Exist
The Interoperability Problem in Charging Networks
Without roaming, every CPO is an island. A driver with an account at Network A cannot charge at Network B’s stations. Multiply this across a market with dozens of CPOs and eMSPs, and the result is fragmented infrastructure that undermines driver confidence and slows EV adoption.
EV roaming protocols standardize the data exchange needed to bridge these islands: driver authentication, charger discovery, session tracking, and billing reconciliation across network boundaries.
What Roaming Means for CPOs and eMSPs
For a CPO, roaming means more sessions on existing hardware — drivers from partner networks generate additional revenue without additional customer acquisition cost. For an eMSP, roaming means a broader charging footprint for its subscribers without owning or operating stations. Both sides benefit, but the protocol they use to connect determines the complexity, cost, and flexibility of that connection.
OICP — The Open Intercharge Protocol
Who Maintains OICP (Hubject)
The OICP protocol is developed and maintained by Hubject, a joint venture originally founded by BMW, Bosch, Daimler, EnBW, innogy, and Siemens. The protocol specification is published on GitHub, but its development is governed by Hubject rather than an independent foundation.
This governance model means OICP evolves based on Hubject’s platform roadmap. Operators using OICP are, in practice, Hubject platform customers — the protocol and the hub are tightly coupled.
OICP’s Hub-Centric Architecture
OICP is designed around a centralized hub model. All data exchange — authorization, session data, CDRs — flows through the Hubject intercharge network. There is no peer-to-peer option. If you implement OICP, you connect to Hubject. If Hubject connects a new partner, you gain access automatically.
This simplifies connectivity. A single integration gives access to Hubject’s entire network, which spans 500,000+ charge points across 60+ countries. The trade-off is architectural dependency: your roaming capabilities are bound to one platform.
Key OICP Capabilities and Limitations
OICP handles the essentials: EVSE data (locations, availability), remote authorization (start/stop), and CDR exchange for billing. It supports multiple authentication methods (RFID, QR code, Plug & Charge), and Hubject’s Plug & Charge infrastructure is a distinct advantage for operators implementing ISO 15118.
Limitations include no native smart charging module (unlike OCPI 2.2.1+), limited tariff structure flexibility compared to OCPI’s modular Tariffs module, and no direct AFIR NAP data exchange support. Hubject addresses some of these gaps through platform features rather than protocol extensions, which means the capability exists but is tied to the Hubject ecosystem.
OCPI — The Open Charge Point Interface
Peer-to-Peer vs Hub Model
OCPI, maintained by the EVRoaming Foundation, supports both hub-based and peer-to-peer connections. A CPO can connect to multiple roaming hubs (Gireve, e-clearing.net, and others) or establish direct bilateral links with specific eMSP partners. This architectural flexibility is OCPI’s defining advantage — no single platform dependency.
How OCPI Differs Architecturally
OCPI’s modular architecture means operators implement only the modules they need (Locations, Sessions, CDRs, Tariffs, Tokens, Commands, ChargingProfiles). Each module supports push and pull interaction patterns. The protocol is transport-agnostic (RESTful HTTP) and version-negotiated per connection.
For a comprehensive treatment of OCPI architecture, module design, and implementation challenges, see our OCPI protocol deep dive.
OCPI vs OICP: A Head-to-Head Comparison
| Dimension | OCPI | OICP | OCHP | eMIP |
|---|---|---|---|---|
| Steward | EVRoaming Foundation | Hubject | e-clearing.net | Gireve |
| Governance | Independent foundation (open) | Corporate (Hubject JV) | Corporate (e-clearing.net) | Corporate (Gireve) |
| Architecture | Peer-to-peer + hub + hybrid | Hub-only (Hubject) | Hub-only (e-clearing.net) | Hub-only (Gireve) |
| Smart charging module | Yes (ChargingProfiles, from 2.2.1) | No | No | No |
| V2G readiness | Expected in 3.0 | No | No | No |
| AFIR NAP support | Yes (from 2.3.0) | Via platform features | Limited | Via platform features |
| Plug & Charge (ISO 15118) | Protocol-level support | Strong — Hubject PKI infrastructure | Limited | Limited |
| Tariff complexity | High (modular Tariffs module) | Basic pricing structures | Basic | Moderate |
| Primary market | Pan-European, expanding globally | DACH, Benelux, expanding globally | DACH region | France, Southern Europe |
| Current version | 2.3.0 | 2.3 | 1.4 | 1.0 |
| Spec access | Open (GitHub) | Open (GitHub) | Restricted | Restricted |
Where OICP Wins
- Plug & Charge infrastructure: Hubject’s ISO 15118 PKI infrastructure is the most mature in the industry, making OICP the path of least resistance for operators implementing Plug & Charge.
- Onboarding simplicity: A single integration gets you the entire Hubject network. No multi-hub management, no bilateral negotiations.
- Network size: 500,000+ charge points and growing. For operators whose priority is maximum roaming reach with minimum integration effort, OICP delivers.
Where OCPI Wins
- Architectural independence: Multi-hub, peer-to-peer, or hybrid — OCPI doesn’t lock you into a single platform.
- Smart charging: The ChargingProfiles module (from 2.2.1) enables eMSP-driven charging limits — critical for grid-integrated charging and energy flexibility.
- AFIR readiness: OCPI 2.3.0 directly supports NAP data exchange and ad-hoc payment flows mandated by AFIR.
- Tariff flexibility: OCPI’s Tariffs module handles complex pricing structures (time-of-use, energy-based, flat fee combinations) that OICP’s simpler pricing model cannot express.
OCHP and eMIP — The Other Roaming Options
Two additional EV roaming protocols exist but with narrower adoption. OCHP (Open Clearing House Protocol), maintained by e-clearing.net, is used primarily in the DACH region. eMIP (eMobility Inter-Operation Protocol), maintained by Gireve, is prevalent in France. Both are hub-specific protocols, similar to OICP in their architectural coupling.
As GreenFlux documented, the market is consolidating around OCPI as the open standard, with hub-specific protocols (OICP, OCHP, eMIP) serving their respective ecosystems. Most operators targeting pan-European roaming implement OCPI as the baseline and add hub-specific protocols as needed.
Which Protocol Should You Implement? A Decision Framework
If You’re Operating in the Hubject Ecosystem
If your business model centers on Hubject’s network — whether because your partners are there, you need Plug & Charge PKI, or your market is Hubject-dominated (DACH, Benelux) — OICP is the pragmatic choice. The integration is well-documented, Hubject provides testing tools, and the network effect is substantial.
If You Need Multi-Hub or Peer-to-Peer Flexibility
If you’re building a platform that needs to connect to multiple roaming hubs, establish direct partnerships, or operate across diverse European markets, OCPI gives you the architectural foundation. Implementing OCPI first means you can add Gireve, e-clearing.net, and peer-to-peer links without protocol changes — only configuration.
When You Need Both
Many mature operators implement both. OCPI handles multi-hub connectivity and peer-to-peer partnerships. OICP connects to the Hubject network specifically. The protocols can coexist in the same platform with a shared data layer and separate connector modules.
Codibly’s OCPI & OICP interoperability services and OCPI Accelerator are designed for this dual-protocol reality — teams that need production-grade roaming across multiple ecosystems without building every integration from zero.
Roaming Isn’t a Protocol Decision — It’s a Market-Access Decision
OCPI and OICP both enable EV roaming. The technical differences — architecture, module design, governance — matter primarily because of what they imply for market access, partner flexibility, and long-term platform evolution.
OICP offers simplicity and immediate access to the largest single roaming network. OCPI offers architectural independence and alignment with where European regulation is heading. Most operators targeting scale will eventually implement both, with the sequencing determined by where their partners and drivers are today.
The protocol choice shapes your platform architecture for years. Make it based on your market strategy, not just the spec sheet. For an overview of how the OCPP vs OCPI comparison fits into the broader EV charging protocol landscape, start there.
Frequently Asked Questions
OICP supports EVSE data exchange, remote authorization, CDR processing, and Plug & Charge (ISO 15118) through Hubject’s PKI infrastructure. It does not include dedicated smart charging or dynamic tariff modules. Its functionality is tightly integrated with the Hubject platform, so some capabilities are delivered as platform features rather than protocol-level specifications.
The decision depends on market priority and partnership strategy. If your primary roaming partners are on Hubject, start with OICP. If you need flexibility to connect to multiple hubs and establish direct partnerships, start with OCPI. For pan-European operations, plan for both — OCPI as the open foundation, OICP for Hubject-specific access. Also consider regulatory context: AFIR compliance leans toward OCPI 2.3.0’s NAP support.
Yes. Both protocols map to the same underlying business data (locations, sessions, CDRs, tariffs, tokens). A well-architected platform abstracts this data into an internal model and exposes it through protocol-specific adapters. The complexity is in maintaining two credential stores, two CDR reconciliation pipelines, and two sets of partner-specific configurations — but the data model is shared.