8 Step EV Charging Roaming Checklist for Chargepoint Operators
Operator-side EV charging roaming is the integration layer, usually built on the OCPI protocol, that lets your charge points exchange location data, sessions, tariffs and billing records with other networks, so drivers from any partner scheme can charge and pay at your sites. If you operate or host chargers commercially, the immediate action is simple: run an OCPI readiness check, or book a technical scoping call with your supplier, before you sign any hub agreement.
TL;DR:
Connecting through a roaming hub provides quick, wide coverage but incurs per-session fees that can grow significantly at high volumes.
Building direct OCPI links with specific partners is cost-effective for high-volume corridors but requires ongoing integration and maintenance efforts.
Ensuring data accuracy, correct tariff mapping, and CDR reliability are crucial for maximizing revenue, minimizing disputes, and maintaining driver satisfaction.
Supporting standards beyond OCPI, such as OCPP and OpenADR, is essential for stable operation, load management, and future scalability.
Emphasizing site data quality and operational disciplines before expanding reach helps avoid costly rework and maximizes long-term ROI.
Table of Contents
What is EV charging roaming for chargepoint operators?
Operator-side roaming has nothing to do with drivers switching between apps or RFID cards. That is a separate, driver-facing question this guide deliberately sets aside. For a chargepoint operator (CPO), roaming means your back office talks to other companies’ back offices so their customers can use your hardware and you get paid for it.
Three roles matter here. The CPO owns the physical charger and publishes its location, availability and tariff data. The eMSP (e-mobility service provider) owns the driver relationship, issues the payment token, and bills its own customer. Sitting between them, a roaming hub routes the technical connection so a CPO doesn’t need a separate integration with every eMSP on the market.
Nearly all of this runs on OCPI, an open protocol maintained by the EVRoaming Foundation. The modules a CPO needs to understand first are:
Locations — publishes site and connector data so partners can find your chargers
Tariffs — sets the price a roaming driver pays at your site
Sessions and CDRs — track live charging activity and generate the billing record once a session ends
Tokens and Credentials — authorise a partner’s driver and authenticate the connection itself
Benefits and trade-offs of opening chargers to roaming
Roaming exists to solve one problem: idle chargers earn nothing. Opening your network to eMSP partners widens the pool of drivers who can plug in, which lifts utilisation on sites that otherwise sit quiet outside peak hours. Fleet operators and corporate account holders increasingly expect their EV cards to work at destination charging sites, and roaming is what makes that possible without you signing separate contracts with every fleet card provider.
The trade-off is control. Once you plug into a hub, an eMSP’s pricing model can override your preferred tariff structure for roaming sessions, and you’re relying on a third party’s billing accuracy for revenue you can’t directly verify.
Hub fees typically sit at a few pence per session at low volume. At scale, they can quietly cost six figures a year on a single high-traffic corridor.
Practical trade-offs to weigh before onboarding:
Revenue upside: broader driver access, higher utilisation, fewer wasted assets
Margin erosion: per-session hub fees compound at volume
Payment risk: some MSPs apply fixed pricing that can misalign with your commercial model, and late settlement is a real operational risk
Brand reach: fleet and employer billing integrations often require roaming as a baseline capability
Roaming hub vs direct peer-to-peer OCPI: which should you choose?
Most commercial operators face this decision early: connect through a roaming hub, build direct bilateral OCPI links with specific partners, or run both. Each has a distinct cost and effort profile.
A hub connection gives you one technical integration and access to a large pool of partners in one move. Hubs such as GIREVE and Hubject connect very large numbers of charge points across many countries, so a single certified connection buys instant reach. You pay for that reach through per-session or per-CDR fees, and you inherit the hub’s data standards and testing requirements.
Direct peer-to-peer OCPI cuts out the hub fee entirely. You negotiate terms and pricing directly with a partner eMSP, which suits high-volume, predictable corridors, such as a fleet depot with a dedicated logistics partner. The cost is integration effort: every direct partner needs its own connection, credential exchange and ongoing maintenance.
For most commercial operators, the practical sequence looks like this:
Connect to a roaming hub first, to get broad coverage live quickly
Monitor session volume by partner over several months
Identify corridors where volume is high and consistent
Migrate those specific corridors to direct bilateral OCPI links
Keep the hub connection for everything else, where volume doesn’t justify a dedicated integration
Pro Tip: Track hub fees against per-corridor session counts from day one. The crossover point where direct peering pays for itself usually arrives sooner than operators expect, often within a single high-traffic site’s first year.
What technical components do CPOs need to implement?
Getting operator-side roaming live means implementing a defined set of OCPI modules correctly, not just switching a feature flag. Each module governs a specific piece of the data exchange between your charge point management system (CMS) and partner platforms.
Credentials comes first: it’s the handshake that establishes and authenticates the connection between two parties before any other data flows. Version discovery runs alongside it, confirming which OCPI version both systems support, since mismatched versions are a common early failure point.
CDR accuracy deserves particular attention. CPOs generate the CDR after a session ends and push it to the eMSP for validation and settlement, and errors here directly delay or reduce payment. Token authorisation matters just as much: a slow or incorrect token check at the charger stalls the driver and generates support complaints that land on your desk, not the eMSP’s.
Getting tariffs, settlement and reconciliation right
Tariff publication sounds straightforward until you’re mapping one pricing structure across several partner platforms with different rate formats, time bands and currency handling. A tariff that displays correctly on your own app can render incorrectly once translated through a hub to a third-party eMSP, so testing tariff display from the partner’s side, not just your own, catches errors before they hit live drivers.
Settlement runs on the CDR pipeline. Once a session ends, the CDR moves to the eMSP for validation, and disputes typically arise from mismatched energy figures, session timing errors, or tariff misapplication.
Reconciliation is where operational cost quietly builds. Manually checking CDRs against expected revenue across multiple partners is slow and error-prone at any real volume.
Automate CDR matching against your own metering data rather than trusting partner totals blindly
Set a fixed settlement review cycle, weekly at minimum, monthly at most
Flag exceptions immediately rather than batching disputes for month-end review
Keep a partner-by-partner tariff mapping log so pricing errors are traceable to their source
Pro Tip: Build exception reporting into your reconciliation process from launch. Catching a tariff mapping error in week one is a five-minute fix; catching it after six months of sessions is a dispute with every partner it touched.
How do you implement roaming: checklist and timeline
Getting from zero to live roaming follows a predictable sequence, though the timeline depends heavily on your starting point.
Audit site data: confirm connector metadata, site addresses and meter accuracy are correct and complete
Check OCPP health: your charge point protocol layer needs to be stable before adding a roaming layer on top, since OCPP and OCPI serve different but connected purposes
Version discovery: confirm which OCPI version you and your hub or partner support
Credential exchange: establish and authenticate the connection
Publish Locations: push accurate, complete site data live
Implement Tokens and Sessions: enable partner driver authorisation and live session tracking
Enable CDRs: confirm billing records generate correctly and match metered energy
Certification and testing: pass the hub’s test environment before going live
Timelines vary sharply by starting point. A certified, off-the-shelf codebase can be production-ready in a matter of weeks; building from scratch may take several months to a year… Delays cluster around tariff mapping errors and certification testing, since hubs such as GIREVE run automated tests that expect clean location data and correct response-time behaviour before allowing production access.
How Swift Charging supports commercial roaming readiness
Swiftcharging works with chargepoint operators, landlords and fleet managers through the full readiness journey, not just the installation. That starts with site surveys that check the metadata and metering accuracy roaming depends on, moves through CMS and OCPI integration planning, and covers load management design so your electrical capacity supports both local demand and roaming session spikes.
Tariff configuration is part of that same conversation: getting your pricing structure right before you connect to a hub avoids the mapping errors that cause disputes later. Where sites qualify, Swiftcharging also helps with government EV charging grant applications to offset infrastructure costs.
When evaluating any supplier for roaming readiness, ask directly: which OCPI version do they support, do they have hub certification experience, and how do they handle CDR reconciliation disputes. A supplier without clear answers on all three is a red flag worth taking seriously.
Security and privacy considerations in EV charging roaming
Operator-side roaming multiplies your attack surface because every hub and eMSP connection is another authenticated channel into your CMS. Credential exchange, the OCPI module that authenticates partner connections, is the first line of defence, and weak credential management is the most common way roaming integrations get compromised.
Token authorisation carries its own risk. A poorly validated token check can let unauthorised sessions start, which shows up later as a billing dispute you can’t win because the authorisation step itself was never properly verified. Building strict token validation into your CMS, rather than trusting a partner’s assertion at face value, closes that gap.
Data privacy matters just as much as payment security. Location and session data flowing to partner eMSPs can include timestamps, energy usage patterns and, indirectly, driver behaviour. Commercial landlords and facilities teams handling this data need to know exactly what their CMS and hub share downstream, and with whom, particularly where a site sits on leased or multi-tenant commercial property.
Version discovery, checking which OCPI version both systems support, isn’t just a compatibility step. Older OCPI versions carry weaker security assumptions than current ones, so running an outdated version on a production connection is a genuine exposure, not a minor technical debt item.
The practical baseline for any commercial operator: encrypt credential exchange, log every authorisation attempt, review partner access permissions on a fixed schedule, and treat any hub or eMSP connection as a live security relationship requiring ongoing oversight, not a one-off integration task you complete and forget.
Where is EV charging roaming heading next?
Regulatory pressure is pushing roaming from a competitive advantage toward a baseline expectation. Many public tenders and funded charging sites now require open roaming protocol support as a condition of the contract, which means operators without OCPI competence risk being excluded from public procurement entirely, not just missing out on extra revenue.
Hub consolidation looks set to continue. As networks mature, expect fewer, larger hubs handling the bulk of roaming traffic, with direct bilateral connections increasingly reserved for the highest-volume, most predictable corridors rather than general coverage.
Data quality standards are tightening too. Hubs already run certification tests that check location accuracy, response times and CDR correctness before allowing production access, and that bar is likely to rise as roaming volumes grow and disputes become more expensive to resolve manually.
For fleet operators specifically, expect deeper integration between roaming and depot billing systems, so a single fleet card genuinely works the same way whether the vehicle charges at base or at a partner site during a route. That shift favours CPOs who treat roaming as a core platform capability rather than an afterthought bolted onto an existing CMS.
The direction is consistent: roaming stops being optional infrastructure and becomes a standard expectation baked into procurement, tendering and fleet contracts. Operators who build the technical and commercial discipline now, rather than reacting once a partner or tender demands it, will find the transition considerably less disruptive than those who leave it until it’s unavoidable.
Overview of industry standards beyond OCPI
OCPI handles the roaming layer, but it doesn’t work alone. Two other standards matter to any commercial operator building a complete charging stack.
OCPP (Open Charge Point Protocol) governs the connection between the physical charger and your charge point management system, the layer beneath roaming. OCPP and OCPI serve genuinely different purposes and need to work together: OCPP keeps the charger itself talking correctly to your CMS, while OCPI extends that data outward to roaming partners. A charger with unstable OCPP behaviour will produce unreliable data no OCPI integration can fix downstream.
OpenADR (Open Automated Demand Response) is a less familiar name to most CPOs but increasingly relevant. It standardises how energy grids and large consumers communicate demand response signals, relevant to any commercial site managing load against grid constraints or time-of-use tariffs. As roaming volumes grow and sites host more simultaneous sessions, demand response coordination becomes a real operational concern, not a theoretical one.
The interoperability challenge is that these standards weren’t designed as one unified system. A charger can be perfectly OCPP-compliant and still fail an OCPI certification test because its location metadata or response times don’t meet a hub’s requirements. Version mismatches compound this: running OCPP 1.6 alongside a modern OCPI 2.2.1 integration is technically possible but creates friction points that a fully aligned stack avoids.
Commercial operators procuring new infrastructure should ask suppliers directly how their CMS handles all three standards together, rather than assuming OCPP compliance automatically means OCPI readiness.
Benefits and challenges for end-users in roaming scenarios
Roaming’s biggest practical benefit for end-users, whether that’s a fleet driver, a hotel guest, or an employee using a workplace charger under a corporate scheme, is access. Roaming genuinely increases the pool of chargers a driver can use under a single account or card, which matters directly to commercial landlords and fleet managers because it’s what makes a site attractive to visiting drivers who aren’t already customers of your own network.
For fleet managers specifically, roaming means drivers on the road can charge at partner sites and have that session billed straight back to the fleet account, rather than requiring reimbursement claims or separate payment cards. That single detail is often the deciding factor in whether a fleet chooses one charging network over another.
The challenges sit mostly on the pricing and reliability side. When a roaming partner’s eMSP applies its own tariff to a session at your site, the end-user sees a price you don’t fully control, which can create a mismatch between what your business intended to charge and what actually appears on the driver’s bill. Session reliability across partner integrations also varies. A driver who hits an authorisation delay because a token check is slow experiences that as your site’s failure, even though the fault sits in the roaming handshake between two other companies’ systems.
For commercial hosts, the practical takeaway is that end-user experience in a roaming scenario is only as good as the weakest integration in the chain, which is exactly why the technical discipline covered earlier in this guide matters as much for driver satisfaction as it does for your own settlement accuracy.
Why operator-side roaming deserves more attention than it gets
Most advice on this topic still gets written for drivers hunting for a charging app, which leaves procurement and technical teams with almost nothing practical to work from. That gap is the real problem. Operators are told roaming is “important” without anyone explaining what OCPI module to implement first or how to read a hub’s fee structure.
The conventional wisdom that hub connectivity alone is sufficient falls short. A hub gets you reach, but treating it as the finish line rather than the starting point leaves margin on the table once volume builds on specific corridors. The operators who get roaming right are the ones who treat CDR reconciliation and tariff mapping as ongoing operational disciplines, not one-off setup tasks.
What should commercial operators prioritise first? Data quality, not partner count. A charger with clean, accurate Locations and reliable CDR generation will out-earn one connected to five hubs but riddled with mapping errors. Get the fundamentals right before chasing broader reach, and the reach question tends to answer itself.
— Swift Charging
Ready to make your sites roaming-ready?
Technical providers design and implement the technical groundwork operator-side roaming depends on, from site surveys and CMS integration through to tariff configuration and load management for multi-partner traffic. Where installations qualify, grant applications can be handled to help offset the cost of infrastructure upgrades.
If you’re a chargepoint operator, commercial landlord or fleet manager weighing up hub connectivity or planning a new site build, the practical next step is a technical scoping conversation before you commit to any hub agreement. Getting your data, metering and tariff structure right first saves significant rework once partners start sending live traffic. Book a site survey for your Chichester commercial property and get a clear picture of what roaming readiness looks like for your specific sites.
Sources
FAQ
What does EV charging roaming mean for a chargepoint operator?
It means your CMS exchanges Locations, Sessions, Tariffs and CDRs with partner eMSPs, usually via OCPI, so drivers from other networks can charge and pay at your sites.
Is OCPI the only protocol I need for roaming?
OCPI handles the roaming exchange itself, but it works alongside OCPP, which manages the charger-to-CMS connection underneath it, and increasingly OpenADR for demand response.
How long does it take to go live with roaming?
A certified, off-the-shelf codebase can reach production in four to six weeks; building an integration from scratch typically takes nine to twelve months, with tariff mapping and certification testing the most common delay points.
Should I use a roaming hub or connect directly to eMSPs?
Start with a hub for broad coverage, then migrate your highest-volume corridors to direct bilateral OCPI connections once session data shows they justify the integration effort.
Can Swift Charging help with roaming implementation?
Yes. Swiftcharging supports commercial operators with site surveys, CMS and OCPI integration planning, tariff configuration and load management to prepare sites for live roaming.
Recommended