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 needs a direct link to every eMSP it wants to serve. That is the N-by-N problem: the number of connections grows with the product of the parties on each side, not the sum.
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, how to find and evaluate the hubs that serve your market, 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 depends on drivers from other mobility service providers being able to use them. That is roaming. Without it, only your own customers can plug in, and if you have no driver-facing app of your own, nobody can.
To enable roaming with one other party, you need four things:
- A signed business agreement covering contract terms, settlement, and pricing.
- A technical integration: the OCPI Credentials handshake, endpoint configuration, testing.
- An operational relationship (support contacts, incident response, monitoring).
- Per-session financial settlement.
To roam with fifty eMSPs, you need fifty of each. The legal, technical, operational, and financial overhead scales linearly with partner count, and none of it is the work you set out to do, which was selling electricity. There is a practical ceiling on direct integrations for any team, and it is set by how many partner relationships that team can carry rather than by anything in the protocol.
A hub moves the ceiling. The hub maintains the 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 against nine in a full peer-to-peer mesh. At ten and ten, it is twenty against a hundred. That widening gap is the entire argument for the model.
What hubs actually do
Concretely, a hub does these things.
Aggregate roaming partners. The hub holds agreements with CPOs on one side and eMSPs on the other. Connecting to the hub gives you reach to whoever is already on it.
Translate between protocol versions. A hub can accept OCPI 2.1.1 on one side of a connection and speak 2.2.1 or 2.3.0 on the other, reconciling the differences in the middle. You implement the version your hub agrees to speak to you. (For how the versions differ, see the OCPI version history.)
Translate between protocols. A hub can also bridge OCPI to other roaming protocols, such as OICP, for partners that have not moved.
Route messages. A Locations push from you goes once to the hub, and the hub fans it out to the connected eMSPs. A Token query from an eMSP goes through the hub to the right CPO.
Normalize data. Partner implementations vary, and some of them send data that is technically malformed. A hub can clean up the common cases so downstream parties do not each have to write the same defensive code.
Provide a single contractual interface. One contract with the hub covers the business terms for every party it represents.
Settle transactions. A hub can calculate who owes whom for each session, aggregate that into invoices, and execute the transfers.
Provide observability. A dashboard covering session counts, error rates, partner status, and financial flows.
Manage onboarding. When you want to add a partner reachable through the hub, the hub does most of the work.
OCPI has a module for the hub’s own bookkeeping: HubClientInfo lets a hub tell every connected party who else is on the platform and whether each of them is currently online. It is the closest thing in the spec to a live directory, and it is worth asking whether a prospective hub actually implements it.
How to find the hubs in your market
Hub rosters, ownership, and protocol support change, so a printed list ages badly and a stale list is worse than none. Find the current answer yourself, in this order.
Ask the eMSPs you most want to reach. Which hubs are they already connected through? Their answer is the only roster that matters to you, because reaching them is the reason you are shopping.
Ask your CSMS or back-office vendor. Roaming connections are frequently bundled, and you may already be paying for one.
Read the hub’s own OCPI documentation. The versions endpoint and the credentials documentation tell you what the platform will actually speak, in more detail than a sales page will.
Check the party ID registries and industry associations in your region. Registered party IDs are a public trail of who is operating as a CPO, eMSP, or hub in a given country.
Hubject and Gireve are two names worth knowing as starting points for that research. Hubject was founded in Germany and also operates in North America; Gireve is European. Treat both as names to go verify rather than as a shortlist, and confirm coverage against your own partner list before you commit.
If what you are actually looking for is the driver-facing networks rather than the clearing layer between them, that is a different question: see major EV charging networks compared.
How hubs make money
Hub pricing comes in a handful of recognizable shapes.
Per-session fee. A flat amount per roamed session, regardless of its size. Predictable, and it works in your favor when your average session is large.
Per-kWh fee. The fee scales with energy delivered, which suits a portfolio of short AC sessions better than a DC fast charging one.
Percentage of session revenue. The fee tracks gross session value, which means it moves with local tariffs and with every price increase you make.
Monthly subscription plus volume tier. A base fee for connectivity, with per-session or per-kWh charges layered on as usage grows.
Custom enterprise pricing. Bespoke terms, usually bundling extras such as analytics or a dedicated support path.
The comparison that matters is not the headline rate but the total against the alternative. For a revenue-share deal, annual hub cost is sessions per year multiplied by average session value multiplied by the percentage; for the flat models it is sessions multiplied by the unit fee. Put your own numbers in. Then price the other side: the engineering time to build one direct integration, plus the ongoing cost of operating it, multiplied by the number of partners you would have to reach that way. With five partners, the direct path is worth pricing seriously. With fifty, that multiplication usually answers the question on its own. The economics of OCPI roaming works through the fee stack in more detail.
Hub vs direct peer-to-peer
Covered in depth in OCPI hub vs peer-to-peer, but worth summarizing.
Use a hub when:
- You want reach across many partners with low overhead.
- The hub’s fees are reasonable for your traffic profile.
- You do not need fine-grained control over each 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.
- Fee savings on that volume justify the integration cost.
- You need a partner the hub does not reach.
Use both when:
- You have both a handful of relationships worth owning and a long tail that is not worth a contract each.
The structure worth aiming for is both: direct where the volume and the relationship justify the work, hub for everything else.
What to look for in a hub
If you are choosing a roaming hub, evaluate these.
Coverage in your markets. Which CPOs and eMSPs does the hub connect to where you operate? Its roster is your reachable partner list.
Protocol support. Which OCPI versions does it speak, on your side and on your partners’ side? Does it bridge legacy protocols if you need that?
Pricing. Per-session, per-kWh, percentage, subscription? Negotiate against your volume.
Onboarding speed. How long until you are live? How long to add a new partner through them?
Operational SLAs. Uptime commitments, support response times, incident notification.
Settlement services. Do they handle invoicing and money movement, or only data?
Data ownership and privacy. Who owns the data flowing through the hub, and what happens to it if you leave?
Lock-in considerations. How hard is switching? Are your partner relationships portable?
Reference customers. Talk to operators already connected, and ask specifically about incidents rather than features.
If none of the answers satisfy you, the third option is building the clearing layer yourself, which is a different project with a different risk profile: see OCPI roaming hub build vs buy (coming soon).
The settlement question
A subtle but important distinction. Some hubs handle financial settlement between parties; others move only data.
Settlement-as-a-service hubs: the hub bills the eMSP for sessions delivered, pays the CPO minus its fee, handles VAT and tax treatment, and manages disputes. You get a clean monthly statement.
Data-only hubs: the hub moves messages, and financial settlement stays bilateral between CPO and eMSP. You handle invoicing, payment, and reconciliation yourself.
Settlement services add real value and deepen the lock-in at the same time. Leaving a settlement hub means re-establishing money flow with every partner individually, which is a harder exit than re-establishing data flow. Data-only hubs are easier to leave and cost you more finance operations headcount while you stay.
Hubs and protocol evolution
Bridging versions is the product a hub sells, which gives it a commercial reason to implement a new OCPI version before the operators connected to it do. That in turn gives a small operator a way to reach partners on a newer version without running a migration project: you keep speaking the version you already implement, and the hub translates.
The versions are worth keeping straight, because partners will quote them at you. OCPI 2.2 was published in March 2020 and 2.2.1 in June 2020, and despite the point release they are distinct versions, so a partner on one is not automatically compatible with the other. OCPI 2.3.0 followed in February 2025, and what is new in 2.3.0 covers what it added.
Translation has a limit worth naming before you rely on it. A hub can only bridge what both versions can express. Where a newer version adds a field with no equivalent in the older one, the party on the older version does not receive it, and no amount of hub cleverness invents the data. That is why version bridging buys you time rather than exemption: it defers your migration, it does not cancel it.
Risks of hub dependence
A few concerns worth pricing in.
Hub outages. If your hub goes down, the roaming traffic that runs through it stops. One hub means one point of failure for that traffic.
Hub pricing changes. Contracts get renegotiated, and a rate increase flows straight into your operating costs with no change in what you receive.
Hub acquisition or shutdown. Ownership changes can bring changes in service, pricing, or strategic focus, none of which you control.
Data exposure. Your session data flows through the hub. Whatever separation exists between the hub’s clients is a property of that hub’s architecture and contract, not something OCPI guarantees, so ask how it works and get the answer in writing.
Lock-in friction. Leaving a hub means re-establishing data flows with every party you reached through it. The migration is not trivial, and it happens on the hub’s timetable as much as yours.
Mitigations:
- Connect to more than one hub if the traffic is business-critical and the volume justifies it.
- Keep direct P2P connections with your top partners as a fallback path.
- Negotiate pricing and termination terms that protect you before you need them.
- Audit the hub’s data handling practices against the contract, not against the sales deck.
Why hub density varies by market
Hub density varies between markets, and the reason is structural rather than cultural. A neutral clearing layer needs paying customers on both sides: independent CPOs that do not own an eMSP, and independent eMSPs that do not own chargers. Where that fragmentation exists, a hub has a business. Where a small number of vertically integrated operators own both the chargers and the driver-facing app, there is less left to clear, and what roaming does happen can be arranged directly between the few parties involved.
Regulation pushes the same way. Where rules require ad hoc access and price transparency across networks, tariff and location data has to move between parties somehow, and a clearing layer is the cheapest way to move it. In Europe, AFIR compliance and OCPI (coming soon) is a worked example of regulation creating data flows that a hub is well placed to carry.
Apply the test to your own market rather than to a continent. Count the independent parties on each side, and check how many of the chargers you want to reach belong to an operator that also sells to drivers directly. That ratio predicts how much a hub can do for you far better than any regional generalization.
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, in exchange for a fee and a dependency.
- Hubs aggregate partners, translate between OCPI versions and sometimes other protocols, route messages, and often settle payments.
- Pricing is per-session, per-kWh, a percentage of revenue, or a subscription with usage tiers, and every one of those is negotiated bilaterally.
- The structure to aim for is direct peer-to-peer with strategic, high-volume partners plus a hub for the long tail.
The thing worth watching is that a hub’s value and its risk are the same property: it is the party that knows all of your counterparties. On the day you leave, you find out which of those relationships were yours and which were the hub’s, and the answer is not always the one the dashboard implied. If a partner matters to you commercially, sign something directly with them while you still have a hub connection to fall back on. That is cheap to do early and expensive to arrange in a hurry. The protocol underneath all of it is OCPI, and how it relates to OCPP and ISO 15118 is covered here.