An EV charging roaming hub is the clearinghouse that lets a driver plug in at a charger their own app has never heard of and still get billed cleanly. It sits between many charging operators (CPOs) and many mobility service providers (eMSPs), giving each party a single integration point instead of one connection per counterparty. Without a hub, every CPO would need a direct link to every eMSP it wants to serve — an N-by-N integration problem that becomes unmanageable well before you reach the hundreds of providers operating across North America and Europe.
Roaming is what happens between networks; it is not the same thing as the protocol a station uses to talk to its operator. Hubs live in the roaming layer, speaking OCPI (and sometimes other roaming protocols) to move station data, authorization, and billing records between parties.
This article explains what a roaming hub does, the business model behind it, who the major hubs are in each region, and how to decide whether to use one, run direct peer-to-peer, or do both.
The problem hubs solve
Imagine you operate a CPO with 500 charging stations. Your business model depends on enabling drivers from many different mobility service providers (eMSPs) to use your chargers — that’s roaming. Without it, only your own customers (if you have any) could use your stations, and you’d be a tiny island.
To enable roaming with another party, you need:
- A signed business agreement (contract terms, settlement, pricing).
- A technical integration (OCPI Credentials handshake, endpoint configuration, testing).
- An operational relationship (support contacts, incident response, monitoring).
- Per-session financial settlement.
To roam with 50 eMSPs, you need 50 of each of those. To roam with 500 (the realistic count of mobility service providers across all regions you might want to cover), you need 500 of each.
This is unworkable for any operator. The legal, technical, operational, and financial overhead scales linearly with partner count. Most operators max out at 10-20 direct integrations before the work overwhelms the team.
A hub solves this. The hub maintains the 500 individual relationships. You maintain one — with the hub. The hub handles routing, normalization, and (often) settlement.
flowchart LR
CPO1[CPO A] --> HUB[Roaming Hub]
CPO2[CPO B] --> HUB
CPO3[CPO C] --> HUB
HUB --> EMSP1[eMSP 1]
HUB --> EMSP2[eMSP 2]
HUB --> EMSP3[eMSP 3]
style HUB fill:#2563eb,stroke:#1e40af,color:#fffEach party integrates once with the hub instead of once per counterparty. Three CPOs and three eMSPs need six connections through a hub, versus nine in a full peer-to-peer mesh — and the gap widens fast as parties grow.
What hubs actually do
Concretely, a hub does these things.
Aggregate roaming partners. The hub has agreements with many CPOs and many eMSPs. By connecting to the hub, you get reach to all of them.
Translate between protocol versions. Your hub might support eMSPs on OCPI 2.1.1, 2.2.1, and 2.3.0 simultaneously. You only need to support the version your hub speaks to you, and the hub reconciles the differences. (For how those versions differ, see the OCPI version history.)
Translate between protocols. Some hubs bridge OCPI to other roaming protocols (OICP, eMI3, etc.) that some legacy partners use.
Route messages. A Locations push from you goes once to the hub; the hub fans it out to all connected eMSPs. A Token query from an eMSP goes through the hub to the right CPO.
Normalize data. Partner implementations vary. Some send slightly malformed data. The hub often cleans up the most common issues so downstream parties don’t have to.
Provide a single contractual interface. You sign one contract with the hub covering the business terms for all the parties it represents.
Settle transactions. Many hubs handle the financial settlement between parties — calculating who owes whom for each session, aggregating into invoices, executing transfers.
Provide observability. A dashboard showing session counts, error rates, partner status, financial flows, etc.
Manage onboarding. When you want to add a new partner reachable through the hub, the hub handles most of the work.
The major hubs
A non-exhaustive list of significant roaming hubs and hub-style interoperability platforms, split by where they are strongest. Rosters, ownership, and protocol support change over time — treat this as a starting point, not a live directory.
North America:
Hubject North America — the US arm of Hubject (see below); operates a roaming and Plug&Charge clearing house serving North American CPOs and eMSPs.
ChargeHub (Canada) — Montreal-based; aggregates North American CPOs and eMSPs and is well known for its cross-network mapping and roaming.
Vendor-integrated interconnects — large North American networks such as ChargePoint, EVgo, and Electrify America interconnect through OCPI-based roaming, sometimes directly and sometimes via hub-style brokers, so that a driver on one app can charge on another network.
Europe:
Hubject (Germany) — one of the oldest and largest, and the maintainer of the OICP roaming protocol; it also supports OCPI and has expanded well beyond Europe.
GIREVE (France) — a major pan-European interoperability platform, OCPI-native, connecting hundreds of thousands of charge points.
e-clearing.net (Netherlands) — one of the original open roaming clearing houses, Dutch- and European-focused.
Bosch Service Solutions — global operator, often bundled with other Bosch mobility services.
Plugsurfing / Electromaps / EVPass — pan-European and country-specific aggregators (Electromaps is strong in Spanish-speaking markets; EVPass is Swiss-based).
There are also smaller regional hubs and emerging entrants in both regions. In most geographies the hub market is competitive, with more than one option serving a given area.
How hubs make money
Common pricing models:
Per-session fee. Each roamed session costs €0.03-€0.20 depending on the hub and your volume tier. Simple, predictable.
Per-kWh fee. A fee per kWh roamed (€0.001-€0.01/kWh). Aligns cost with energy delivered.
Percentage of session revenue. 1-5% of the gross session revenue. Higher revenue → higher fee. Often used in markets with higher charging tariffs.
Monthly subscription plus volume tier. A base monthly fee for connectivity, plus per-session or per-kWh fees scaling with usage.
Custom enterprise pricing. Large CPOs and eMSPs negotiate bespoke pricing, often including additional services (analytics, dedicated support, faster onboarding).
A quick illustrative calculation (plug in your own numbers): a hub charging 2% of revenue on 100,000 roamed sessions a year that average €15 (roughly $16) each works out to about €30,000 (roughly $32,000) a year for that one hub connection. That is reasonable value if the alternative is standing up 50 direct integrations and running them. It is far less attractive if you only have five partners you actually need to reach — at that scale, direct peer-to-peer may cost less over time.
Hub vs direct peer-to-peer
A topic covered in depth elsewhere (OCPI Hub vs Peer-to-Peer) but worth summarizing here.
Use a hub when:
- You want to reach many partners with low overhead.
- The hub’s fees are reasonable for your traffic.
- You don’t need the highest level of control over the partner relationship.
- Speed of onboarding new partners matters.
Use direct P2P when:
- The partnership is strategically important and high-volume.
- You want to negotiate operational terms directly.
- The fee savings on high-volume traffic justify the integration cost.
- You need to support a partner the hub doesn’t reach.
Use both when:
- You’re at scale and want the best of both — direct with your top partners, hub for the long tail.
Most mature operators end up with both.
What to look for in a hub
If you’re choosing a roaming hub, things to evaluate.
Coverage in your markets. Which CPOs and eMSPs does the hub connect to in your region? Their roster determines your reachable partners.
Protocol support. Does the hub support the OCPI version(s) you want to speak? Does it bridge to legacy protocols if needed?
Pricing. Per-session, per-kWh, percentage, subscription? Negotiate based on your volume.
Onboarding speed. How long to go live? How long to add a new partner reachable through them?
Operational SLAs. Uptime guarantees? Support response times? Incident notification?
Settlement services. Do they handle invoicing and money flow, or just data?
Data ownership and privacy. Who owns the data flowing through the hub? What happens if you leave?
Lock-in considerations. Can you switch hubs easily? Are your partner relationships portable?
Reference customers. Talk to other operators using the hub. What’s their experience?
The settlement question
A subtle but important detail. Some hubs handle the financial settlement between parties; others only handle the data flow.
Settlement-as-a-service hubs: the hub bills the eMSP for sessions delivered, pays the CPO (minus its fee), handles VAT/tax, manages disputes. You get a clean monthly statement.
Data-only hubs: the hub moves messages between parties but financial settlement is bilateral between CPOs and eMSPs. You handle invoicing, payment, and reconciliation yourself.
Settlement services add value but also lock you in more deeply. If you leave the hub, you have to re-establish settlement with every partner directly. Data-only hubs are easier to leave but require more financial operations work on your side.
Hubs and protocol evolution
Hubs play an important role in industry-wide protocol evolution.
When OCPI 2.2.1 became the production baseline, hubs were among the earliest adopters, because supporting several versions internally is their value proposition. Operators with hub connections often reached partners running 2.2.1 through their hub before implementing 2.2.1 themselves — the hub bridged them from 2.1.1 to the newer version transparently.
The same pattern applies with OCPI 2.3.0 and the still-in-development 3.0. Hubs adopt early, bridge older operators to newer capabilities, and gradually push the ecosystem forward. For where the protocol is heading, the OCPI version history tracks what changed and when.
If you’re a small operator, your hub may be your primary path to staying current on protocol versions without a migration project of your own.
Risks of hub dependence
A few real concerns to think about.
Hub outages. If your hub goes down, your roaming traffic stops. If you have one hub, you have a single point of failure for a significant fraction of your business.
Hub pricing changes. Hub pricing tends to be sticky once set, but contracts get renegotiated. A price increase from your hub flows directly to your operating costs.
Hub acquisition or shutdown. Hubs get acquired (or, rarely, shut down). A change in ownership may bring changes in service, pricing, or focus.
Data leakage / competitive issues. Your session data flows through the hub. The hub’s other clients (which may include your competitors) don’t see your specific data, but the hub itself sees everything. Trust matters.
Lock-in friction. If you leave a hub, your data flows have to be re-established with every party you had reached through them. The migration is non-trivial.
Mitigations:
- Use more than one hub if your business is critical and you can afford it.
- Maintain direct P2P connections with your top partners as a fallback.
- Negotiate contract terms that protect you on pricing and termination.
- Audit your hub’s data handling practices and contracts.
Hubs in different regions
A short geographic overview.
Europe: mature hub market. Multiple hubs serve overlapping geographies. OCPI is the dominant protocol with some legacy OICP still bridged.
North America: a younger hub market than Europe. ChargeHub, Hubject’s North American operation, and a handful of others aggregate partners, but many large networks (ChargePoint, EVgo, Electrify America) run direct OCPI interconnects with major eMSPs, or are vertically integrated with their own eMSP, which reduces the reliance on a neutral hub.
Asia (excluding China): patchy. Japan has some emerging hubs. South Korea and Taiwan have national-scale operator structures that reduce hub need.
China: different structure — large national charging operators (Star Charge, Teld, State Grid) dominate, with hub-like aggregation done by app providers more than dedicated roaming hubs.
Latin America and Africa: emerging. Local hubs are forming but coverage is uneven.
Key takeaways
A roaming hub is the practical answer to the N-by-N integration problem in EV charging roaming. The short version:
- A hub turns one-connection-per-partner into a single integration, reachable across both the North American and European ecosystems.
- Hubs aggregate partners, translate between OCPI versions and sometimes other protocols, route messages, and often settle payments — but the fees and the operational dependency are real.
- Pricing is per-session, per-kWh, a percentage of revenue, or a subscription, and it is negotiated bilaterally.
- Most mature operators end up doing both: direct peer-to-peer with their strategic, high-volume partners, and a hub for the long tail.
Used well, a hub gives a smaller operator broad reach with one integration; combined with selective direct partnerships, you get the best of both worlds. If you want the underlying protocol that makes any of this work, start with what OCPI is and how it compares to OCPP and ISO 15118.