OCPI Explained: What CPOs and eMSPs Actually Need to Build for EV Roaming

If you operate charging stations, or you’re building an app that lets drivers pay for charging across networks they don’t own, you’ve probably run into three letters that decide whether your business scales past your own hardware: OCPI.

This isn’t a protocol spec walkthrough. It’s the business-level picture: who OCPI serves, why it matters more in 2026 than it did two years ago, and what it actually takes to get a working integration live.

---

First, the confusion to clear up: OCPI is not OCPP

Two "OC" protocols run EV charging, and mixing them up is the fastest way to misbrief a development team.

• OCPP (Open Charge Point Protocol) connects a physical charger to its back-end management system. It’s the "start charging, stop charging, here’s the meter reading" conversation between a station and its operator.
• OCPI (Open Charge Point Interface) connects two businesses: a Charge Point Operator and an e-Mobility Service Provider. It’s the "your customer just charged at our station, here’s the bill" conversation between platforms.

Put simply: OCPP is inside your network. OCPI is between networks. A driver’s session might touch both in the same few minutes without ever knowing it.

---

The two roles: CPO and eMSP

• CPO (Charge Point Operator) owns and runs the physical chargers — site selection, hardware, energy procurement, uptime, OCPP-side control.
• eMSP (e-Mobility Service Provider) owns the driver relationship — the app, the subscription or payment account, customer support, and the promise that "you can charge anywhere."

Many companies do both. But the moment a driver wants to charge on a network they don’t have a direct account with, someone needs OCPI to make that session, and the money behind it, work.

---

Why this matters more right now

EV roaming used to be a nice-to-have. It’s becoming a compliance requirement and a competitive baseline at the same time.

• Regulatory push: The EU’s Alternative Fuels Infrastructure Regulation requires public CPOs to expose real-time availability and pricing data to eMSPs, with OCPI as the standard implementation path. Similar interoperability expectations are showing up in publicly funded charging programs elsewhere.
• Driver expectations: Nobody wants five charging apps on their phone. Networks that don’t roam lose sessions to the ones that do.
• Ad-hoc payment mandates: Regulations increasingly require contactless, no-account-needed payment at public chargers — which pushes more session and settlement data through the same interoperable rails OCPI provides.

If your roadmap has "expand to new markets" or "partner with fleet operators" on it, OCPI is usually the dependency nobody scoped early enough.

---

How roaming actually connects: bilateral vs Hub

There are two ways a CPO and an eMSP link up:

• Bilateral (peer-to-peer): Direct connection between one CPO and one eMSP, with access tokens exchanged under a contract. Full control, but every new partner is a new integration.
• Hub: Both sides connect to a central roaming hub instead of to each other. One connection opens access to every partner already on the hub. Faster to scale, less control over each relationship.
• Mixed: Larger operators often run both — bilateral for a handful of strategic partners, Hub for everything else.

The right model depends on how many roaming partners you need and how fast you need them. A CPO launching in one market with two eMSP partners doesn’t need Hub complexity. A CPO planning multi-country expansion almost always does.

---

What OCPI actually moves between platforms

Underneath the business relationship, OCPI standardizes a specific set of data exchanges:

• Locations — where chargers are, what connectors they have, live availability
• Sessions — authorization, start/stop, real-time status of an active charge
• CDRs (Charge Detail Records) — the final, standardized record used for billing and settlement between CPO and eMSP
• Tariffs — pricing so an eMSP can show a driver the real cost before they plug in

Get the CDR and settlement layer wrong and it doesn’t fail loudly — it fails as a slow trickle of billing disputes and reconciliation headaches that show up months later.

---

Build, integrate, or buy?

Most operators face this decision at some point:

1. Build OCPI support in-house into an existing CSMS — makes sense if charging is core to your product and you already have engineering capacity around your charger backend.
2. Integrate an existing OCPI module into a CSMS you’re already running — faster, but only as good as how well it’s wired into your session, auth, and billing data.
3. Connect through a roaming hub provider — lowest engineering lift to reach many partners, at the cost of a dependency on that hub’s uptime and commercial terms.

None of these are purely technical decisions. They’re shaped by how many markets you’re in, how many partners you need, and how much of the driver-facing experience you want to control directly.

---

Where this fits with the rest of your charging stack

OCPI doesn’t replace OCPP, a driver app, or a payment stack — it’s the layer that lets all of those talk to someone else’s version of the same thing. A charging platform built without roaming in mind from day one usually means retrofitting session and billing logic later, which is a more expensive rebuild than most teams budget for.

---

Frequently Asked Questions

Do I need OCPI if I only operate in one country?
Not immediately — but if any regulatory framework in your market requires public availability and pricing data sharing, or if you plan to partner with fleet operators or other networks, OCPI is the standard path to get there without custom point-to-point integrations for every partner.

Is OCPI the same as OICP?
No. OICP is Hubject’s own protocol, required specifically to connect to Hubject’s network. OCPI is the open, vendor-neutral standard and the default for most bilateral roaming and regulatory-driven data sharing. Many production platforms run OCPI as their primary interface and add OICP only where a Hubject connection is required.

What version of OCPI should we build against?
Most production deployments in 2026 run OCPI 2.2.1, with 2.3.0 adoption growing for its added regulatory and tax-support features. OCPI 3.0 is still in development and not yet a safe target for new production builds.

Can our existing OCPP-based charging backend add OCPI without a rebuild?
Usually yes, if the backend already has clean session, location, and tariff data models. The OCPI layer sits alongside OCPP rather than replacing it — the two protocols serve different sides of the same charging session.

---

Building or extending a charging platform with roaming in mind — CDRs, tariffs, and multi-partner connections included — is exactly the kind of system work our EV CSMS — Charging Station Management System (OCPP/OCPI) service is built for. If you’re scoping an OCPI integration or evaluating build-vs-buy, reach out at hello@simplico.net.