In every public EV charging session, two business roles are involved: the company that operates the station, and the company that owns the customer relationship. These are the CPO and the eMSP.
Get this split straight and the rest of the EV charging business model follows from it. Miss it and the industry’s announcements read like noise.
CPO: the Charge Point Operator
A CPO is the company that:
- Owns or leases the physical charging hardware
- Installs and maintains the stations
- Sets the prices (the tariffs)
- Reports station status (available, occupied, faulty)
- Carries responsibility for electrical, mechanical, and software reliability
The CPO sees the world from the station’s perspective. Its questions are operational: how many stations do we run, what is the uptime, how many kWh did we dispense this month, which sites are saturated?
There is a mechanical test for the role, and it does not depend on what the company calls itself. A CPO’s backend terminates the OCPP connection from each charger, which means it runs a CSMS. It also holds the electricity supply contract for the site, so kWh costs and demand charges land on its P&L. Neither of those is true of an eMSP.
Revenue comes from selling charging sessions. The CPO bills eMSPs, who in turn bill drivers, for each kWh delivered, sometimes plus session fees or idle fees.
eMSP: the e-Mobility Service Provider
An eMSP is the company that:
- Owns the relationship with the EV driver
- Provides the app, the RFID card, the in-car navigation integration
- Holds the customer’s payment method
- Markets on coverage, meaning how many stations one account reaches
- Bills the customer for charging sessions
The eMSP sees the world from the customer’s perspective. Its questions are commercial: how many drivers do we serve, how many sessions per month, are they renewing?
The mechanical test here is the credential. The eMSP mints the token the driver carries, whether that is an RFID UID, an app-issued identifier, or a contract certificate, and the CPO validates it. Owning hardware is not part of the role. An eMSP that starts buying chargers has taken on a second role, not expanded the first one.
eMSP revenue comes from a markup on charging sessions, subscription fees, sometimes home-charger hardware sales, and partnership economics.
Why the split exists
A CPO could run its own app and bill drivers directly, with no eMSP anywhere in the picture. Some do. The split survives anyway, because the two jobs have almost nothing in common.
Specialization. Customer-facing software, support queues, and payment processing are different competencies from installing switchgear and keeping a site online. Splitting the roles lets each party do the thing it is actually staffed for.
Network effects for eMSPs. A driver wants one account that works everywhere. An eMSP contracted with many CPOs offers coverage that a single-network app cannot, and coverage is the lever it competes on. The account is only as good as the map behind it.
Capital efficiency for CPOs. A DC site means power electronics, a utility service upgrade sized to the site’s total kW, trenching, and permitting, all paid before the first session. An app means engineering plus customer acquisition, also paid before the first user. Those two spends compete for the same balance sheet.
Cross-border roaming. A French eMSP wants its drivers covered when they cross into Germany. The German CPO wants those sessions on its hardware. Neither has to enter the other’s market for that to work. They need a protocol.
How to tell which role a company is playing
Marketing copy blurs the two constantly. The wiring does not. Four questions settle it:
- Who terminates OCPP? The CPO’s backend. An eMSP backend never speaks OCPP at all.
- Who issued the token? The eMSP. The CPO only checks it, and the OCPI Tokens module is how that check happens without the CPO ever seeing the customer behind it.
- Whose tariff applies? The CPO publishes the tariff attached to the connector. The eMSP adds its own markup when it bills the driver.
- Who emits the CDR? The CPO writes the charge detail record. The eMSP receives it and turns it into a line on a customer invoice.
A company can answer “us” to all four. That means it is playing both roles, not that the roles have merged.
How CPO and eMSP work together (the OCPI angle)
Every roamed session bridges a CPO and an eMSP, and OCPI is the bridge:
- Driver opens the eMSP’s app
- The app shows nearby chargers, including stations operated by other CPOs
- That map data arrives through the OCPI Locations module, where each partner CPO publishes its stations to the eMSP
- Driver picks a station and taps “start charging”
- OCPI Commands module: the eMSP asks the CPO to start the session
- OCPI Tokens module: the CPO validates the driver against the eMSP-issued token
- Session begins, with live data flowing over the OCPI Sessions module
- Session ends. OCPI CDRs module: the CPO sends the final billing record
- The eMSP charges the driver’s payment method, typically with a markup
The eMSP never touches the station. The CPO never touches the driver’s card.
Visualized:
flowchart LR
Driver([Driver]) -->|App + payment| eMSP[eMSP]
eMSP -->|OCPI| CPO[CPO backend]
CPO -->|OCPP| Station[Charging station]
Station -.->|Physical charging| Driver
style Driver fill:#dbeafe,stroke:#2563eb
style Station fill:#dcfce7,stroke:#16a34a
style eMSP fill:#fef3c7,stroke:#d97706
style CPO fill:#fef3c7,stroke:#d97706The driver interacts with exactly two things: the app and the plug. Everything between them is invisible, and that invisible layer is where the business model lives.
When one company plays both roles
Some companies are vertically integrated, acting as CPO and eMSP inside their own ecosystem. That works when the customer base is either captive or large enough to keep the stations busy on its own, and when the company can fund infrastructure and customer acquisition at the same time.
The ceiling is roaming. A closed integrated network is worth only what its own account holders will spend at it, no matter how good the hardware is. Opening those stations over OCPI leaves the hardware and the app untouched and simply widens the set of parties allowed to authorize a session. That is the structural reason an integrated network with spare capacity eventually publishes an OCPI interface: the alternative is paying for utilization it has forbidden itself to sell.
A third role: the Hub
When many CPOs and many eMSPs want to roam with each other, bilateral connections multiply. Ten CPOs and ten eMSPs is 100 connections, each with its own credentials exchange, version negotiation, and support contact.
Hubs collapse that. A hub is a third party holding connections to many CPOs and many eMSPs, so any CPO on the hub can reach any eMSP on the hub without a direct link. Hubject is one, and it operates on both sides of the Atlantic.
Hubs charge fees (per session, per kWh, or by subscription) and absorb integration complexity in return. Whether that trade pays off depends on how many partners you actually need and how much engineering time integration is currently eating. The hub versus peer-to-peer comparison works through the decision.
A fourth role: the NSP (Navigation Service Provider)
OCPI’s role definitions name one more party. An NSP helps drivers find chargers: map apps, route planners, in-car navigation. It consumes Locations data from CPOs or from a hub and usually stops there, without handling authorization or billing. In a system built almost entirely around transactions, the NSP is the read-only participant.
Why this all matters
The role you pick determines:
- Where the customer relationship lives (eMSP)
- Where the physical asset and the operating P&L live (CPO)
- Who captures margin per session (split between tariff and markup)
- What your roaming arrangements look like (direct, hub-based, or both)
- Which OCPI modules you implement, and in which direction
If you are building in EV charging, the first strategic question is which role or roles you are playing. That answer sets capital requirements, customer acquisition strategy, the OCPI modules you build, and which hardware decisions you even get a vote on.
The part that trips people up
The labels are not properties of companies. They are properties of a connection.
OCPI encodes this directly. Since 2.2, a party’s Credentials object carries a list of roles instead of a single one, so the same backend can register as CPO on one link and as eMSP on another, each with its own party_id and country_code. The protocol never asks what kind of company you are. It asks what you are doing on this connection.
That has a consequence worth sitting with: data and money run in opposite directions. Locations, sessions, and CDRs flow from CPO to eMSP. Cash flows from driver to eMSP to CPO. The CDR is the one object where the two meet, which is why a disagreement over CDRs is almost never an integration bug. It is a commercial dispute wearing a JSON schema, and the team that owns your CDR pipeline needs a line into finance as much as into engineering.