EV roaming is the arrangement that lets a driver use one provider's app or card on another company's chargers. It borrows the term from mobile phones, and the economics are similar: the network that serves the customer is not the network the customer has a contract with, so the two need to exchange data in real time and settle money afterwards. This guide covers the roles, the connection models, the data that flows, and where settlement goes wrong.
The roles
- CPO (charge point operator): operates the chargers and the CSMS that runs them. It knows locations, status and energy delivered.
- eMSP (e-mobility service provider): has the relationship with the driver: app, RFID card, contract, billing. It issues tokens and bills the driver.
- Hub: an intermediary that connects many CPOs and eMSPs so each party integrates once instead of with every partner.
- Other roles exist in the standards (OCPI defines NSP for navigation services and others), but CPO and eMSP are the two that matter for money.
Many companies hold both roles: a CPO with its own app is also an eMSP. Inside one company that is just internal accounting. Roaming starts when the driver's eMSP and the charger's CPO are different companies.
Connection models
Peer-to-peer (bilateral)
Each CPO and eMSP pair connects directly, typically with OCPI. They exchange credentials, agree commercial terms in a bilateral contract, and push data straight to each other. The advantages are control and no intermediary fees; you see exactly what your partner sends. The cost is that every new partner is a new integration project: a credentials handshake, testing, data quality fixes, and a contract.
Through a hub
A hub sits in the middle. Each party connects once and the hub routes messages, often with a standard contract framework and sometimes with financial clearing. Hubject (with its OICP protocol) and GIREVE are well-known examples in Europe; hubs also exist that speak OCPI, which defines routing headers (OCPI-from-party-id, OCPI-to-party-id and the country codes) for exactly this purpose. The trade-off is fees and an extra party in every troubleshooting session, in exchange for reach.
Hybrid
In practice most networks of any size do both: a hub for long-tail reach and direct OCPI links with the few large partners that carry most of their roaming volume. Your platform needs to handle the same token or location arriving through more than one path without double-counting.
| Peer-to-peer | Hub | |
|---|---|---|
| Integrations to reach N partners | N | 1 (plus per-partner activation) |
| Commercial contracts | Bilateral, one per partner | Often a framework via the hub |
| Settlement | Bilateral invoicing | Bilateral, or clearing via the hub if offered |
| Debugging | Two parties | Three parties |
| Typical protocol | OCPI | OCPI, OICP, eMIP |
What flows between CPO and eMSP
Whichever protocol you use, the same categories of data move. In OCPI terms:
- Locations: CPO to eMSP. Sites, EVSEs, connectors, power, opening hours and real-time status, so the eMSP's app can show where to charge. See the Locations module.
- Tariffs: CPO to eMSP. What the CPO will charge the eMSP for a session. See OCPI tariffs.
- Tokens: eMSP to CPO. Which RFID cards and app identities are valid, either pushed as a whitelist or checked in real time. See tokens and real-time authorization.
- Commands: eMSP to CPO. Start or stop a session from the driver's app. See the Commands module.
- Sessions and CDRs: CPO to eMSP. Live session progress, then a final charge detail record that is the basis for billing. See Sessions and CDRs.
Authorization: whitelist vs real time
When a roaming driver taps a card, the CPO has to decide quickly whether to start. OCPI tokens carry a whitelist field that tells the CPO how to behave: ALWAYS (use the cached token list, never ask), ALLOWED (the CPO may use the cached list or ask in real time), ALLOWED_OFFLINE (ask the eMSP in real time; the cached list may be used only when the eMSP cannot be reached), and NEVER (always ask in real time). Getting this wrong produces either slow starts or sessions the eMSP refuses to pay for. Your CSMS also has to bridge this to the charger: OCPP Authorize has to answer within the charger's timeout, so a slow real-time lookup to a partner is a real risk.
Settlement
Roaming has two price relationships. The CPO charges the eMSP a wholesale price, defined by the tariff it published and the contract between them. The eMSP charges the driver a retail price, which can be different and is the eMSP's business. The CDR is the bridge: it contains the session's timing, energy, the tariff that applied and the CPO's calculated cost.
The eMSP typically aggregates CDRs from each CPO over a period and reconciles them against its own records before paying the CPO's invoice. If a hub provides clearing, the hub does that aggregation and nets amounts across parties. Either way, the CDR is the unit of truth, and its quality decides how much time you spend on disputes.
Where settlement goes wrong
- Tariff drift. The CPO changed a tariff but the eMSP still has the old version, so the eMSP shows the driver one price and receives a CDR at another. Always reference the exact tariff in the CDR and push tariff updates promptly.
- Missing or late CDRs. A charger that goes offline mid-session and uploads its transaction hours later produces a late CDR. Make sure your pipeline handles that and that contracts allow a reasonable delay.
- Zero-energy and very short sessions. Decide, and agree with partners, whether failed starts generate CDRs. Many disputes are about sessions where the driver received nothing.
- Time zones and rounding. CDR timestamps are UTC; tariff restrictions such as time-of-day are evaluated in the location's local time. Totals should match the sum of charging periods within the rounding rules you both use.
- Duplicate CDRs via two paths. In hybrid setups, make sure a session is reported through exactly one route.
Choosing an approach
If you are a new CPO, a hub connection is the quickest way to make your chargers usable by many eMSPs' customers. As volume concentrates in a handful of partners, direct OCPI links become worth the effort. If you are an eMSP, the logic is the same in reverse. In either case, build your roaming layer on a clean internal model of sessions, tokens and tariffs, so adding a protocol or a hub is an adapter rather than a rewrite. The OCPP to OCPI mapping post shows what that internal model has to capture.
Key takeaways
- Roaming is a CPO and an eMSP exchanging locations, tokens, sessions, CDRs and tariffs, either directly or through a hub.
- Peer-to-peer gives control; hubs give reach. Most mature networks use both.
- The CDR is the billing record. Invest in its accuracy and in tariff synchronization, because that is where disputes come from.
HashTech builds OCPI roaming integrations as part of the CSMS platforms we deliver; see our EV charging work.
