If you’re a CPO or eMSP planning your OCPI roaming strategy, the question of hubs comes up early. Should you connect through a hub? Build your own? Or stick to peer-to-peer with each partner? If you’re still new to the protocol, what OCPI is and how a roaming hub works are useful primers before the architecture decision.
The answer depends on your scale, your strategic position, your engineering capacity, and your market context. This article walks through the three architectural options and helps you decide which fits your situation.
Option 1: Pure peer-to-peer
You connect directly to each partner. No intermediary.
Architecture: Your CSMS speaks OCPI directly to each partner’s OCPI endpoint. Bilateral Credentials handshake with each. Each partner is its own integration. For the deeper technical contrast, see hub vs peer-to-peer OCPI.
When this fits:
- Small partner count (under ~10).
- Strategic relationships where bilateral negotiation is valued.
- You want full control over each integration.
- Hub fees feel disproportionate for your volume.
- You operate in a region where hubs don’t cover your needed partners well.
Cost profile:
- Per-partner integration cost (~2-6 engineer-weeks each).
- Ongoing maintenance per partner.
- No hub fees.
- Higher coordination overhead (contracts, support, monitoring per partner).
Engineering implications:
- Build OCPI client + server once, reuse for all partners.
- Build per-partner configuration: their URL, their token, their quirks.
- Build robust observability (per-partner status, error rates, etc.).
- Build settlement / billing reconciliation per partner if you handle that.
Scaling:
- Linear cost with partner count. At ~15 partners, the operational overhead starts dominating engineering capacity.
- At ~20+ partners, most operators add a hub for the long tail.
This is where most CPOs and eMSPs start. It’s also where many should stay — adding a hub before you need it is premature optimization.
Option 2: Connect to a third-party hub
You connect to one (or more) hubs. The hub mediates your roaming with many other parties.
Architecture: Your CSMS speaks OCPI to the hub. The hub speaks OCPI (or other protocols) to many other parties. From your perspective, you have one integration; you reach many partners.
When this fits:
- Medium-to-large partner count (10+).
- You want operational simplicity.
- The hub covers your target market well.
- You don’t want to manage many bilateral relationships.
- You’re comfortable with the hub’s pricing and data handling.
Cost profile:
- Hub integration cost (~4-12 engineer-weeks one-time).
- Hub fees (per-session, per-kWh, or percentage of revenue).
- Lower per-partner ongoing cost.
- Reduced operational complexity.
Engineering implications:
- Build OCPI client + server (you’d need this anyway).
- Integrate with the specific hub’s flavor of OCPI (may have quirks).
- Build settlement integration if hub handles money flow.
- Build observability around hub status (single-point-of-failure awareness).
Scaling:
- Largely flat cost regardless of how many partners you reach through the hub.
- Hub fees scale with traffic, not partner count.
- Operational overhead stays low even at 100+ effective partner reach.
This is the right choice for most operators who want broad reach without proportional engineering investment.
Option 3: Build your own hub
You become a hub yourself, connecting many parties on each side.
Architecture: You build a multi-tenant OCPI platform. You sign up CPOs and eMSPs as parties. Your platform mediates the data flow between them.
When this fits:
- You see a hub opportunity in a market or vertical that existing hubs don’t serve well.
- You have product/engineering capacity to build a real platform.
- You can build a neutral identity (you’re not just a CPO trying to call yourself a hub).
- You have the patience for multi-year market development.
Cost profile:
- Significant build cost (likely 6-18 engineer-months for v1).
- Ongoing platform maintenance (multiple FTEs).
- Sales, partnerships, settlement, support teams.
- Multi-million-dollar multi-year investment.
Engineering implications:
- Build a multi-tenant OCPI platform with proper isolation between parties.
- Build a sophisticated routing layer.
- Build settlement infrastructure.
- Build observability across many connected parties.
- Build security infrastructure (PKI, certificate management, secret handling).
- Build partner-onboarding tooling.
Scaling:
- Revenue scales with traffic, not party count.
- Operational complexity scales with party count.
- Becoming a commercial hub typically takes 3-5+ years of focused investment.
This is the option that almost no individual CPO or eMSP should choose. Building a hub is its own business; pursuing it because “we need roaming” is the wrong reason.
A decision framework
A simplified flow:
flowchart TD
A[Roaming needed] --> B{Hub as a<br/>business?}
B -->|Yes| H[Option 3<br/>Build a hub]
B -->|No| C{Fewer than<br/>10 partners?}
C -->|Yes| P[Option 1<br/>Pure P2P]
C -->|No| D{Hub covers<br/>most partners?}
D -->|Yes| M[Option 2<br/>Hub plus select P2P]
D -->|No| N[Multiple hubs<br/>plus select P2P]
style H fill:#fee,stroke:#c33
style P fill:#eef,stroke:#33c
style M fill:#efe,stroke:#3c3- Are you a CPO/eMSP with strategic roaming needs? → Option 1 or 2, not 3.
- Do you have fewer than 10 target partners? → Option 1 (pure P2P).
- Do you have 10-50 target partners with a clear hub that covers most of them? → Option 2 (hub) for most; consider P2P for top 2-3 strategic.
- Do you have 50+ target partners or operate across multiple regions/protocols? → Option 2 (hub or multiple hubs) is the practical choice.
- Are you a dedicated platform company building hub-as-a-product? → Option 3, but expect a multi-year journey.
Most operators land at “Option 2 with selective P2P for strategic partners.” That hybrid is the most common mature configuration.
The hub evaluation checklist
If you choose Option 2 (connect to a hub), evaluate hubs on:
Coverage. Which parties does the hub connect to in your target regions? Compare lists across hubs. A hub’s value in North America hinges on reaching networks like ChargePoint, EVgo, Electrify America, Flo, and EV Connect; in Europe it hinges on the likes of IONITY, Allego, and Fastned. Confirm the hub actually connects the parties you need, not just a long roster elsewhere.
Protocol support. Which OCPI versions? Bridging to legacy protocols (OICP, eMI3) if needed?
Pricing structure. Per-session, per-kWh, percentage? Model your unit economics.
Operational SLAs. Uptime, support response, incident notification.
Data handling. Privacy practices, data retention, jurisdictional considerations.
Settlement. Do they handle the money flow, or just data?
Partner onboarding speed. Adding a new partner reachable through them — fast or slow?
Lock-in. Can you switch hubs cleanly? Is your data portable?
Reference customers. Talk to operators currently using the hub.
A realistic evolution path
For a CPO scaling roaming from scratch:
Year 1: P2P with 1-3 strategic partners. Learn the protocol, learn the operations, build the foundation.
Year 2: Add a hub to extend reach. Now you serve maybe 30-50 eMSPs total (3 P2P + the hub’s roster).
Year 3: Refine. Add a second hub if needed for geographic coverage. Promote 1-2 hub connections to P2P if volume justifies.
Year 4+: Steady state. P2P with top 5-10 partners; hub for the long tail; multiple hubs for multi-region coverage.
This is a more sustainable path than trying to do everything P2P or relying on a single hub for everything.
Cost comparison illustrated
A hypothetical CPO with 100,000 roamed sessions/year.
Pure P2P with 20 partners:
- Build cost (one-time): ~$200K-$500K (one OCPI implementation).
- Per-partner integration (one-time): ~$30K-$80K × 20 = $600K-$1.6M.
- Annual maintenance: ~$50K-$200K (engineering time across 20 partners).
- Total Year 1: ~$850K-$2.3M.
- Annual ongoing: ~$50K-$200K.
Hub-mediated reaching 20 partners:
- Build cost (one-time): ~$200K-$500K.
- Hub integration (one-time): ~$50K-$150K.
- Annual hub fees: ~$30K-$100K depending on volume and structure.
- Annual maintenance: ~$20K-$50K.
- Total Year 1: ~$300K-$800K.
- Annual ongoing: ~$50K-$150K.
The hub option is dramatically cheaper for Year 1 and saves on ongoing operational overhead. The break-even where P2P pays for itself (per-partner) is at very high volumes — typically tens of thousands of sessions per partner per year.
What about hybrid?
Most mature operators are hybrid. Specifically:
- P2P with top partners where volume justifies the operational investment and strategic value justifies the bilateral relationship.
- Hub for the long tail where lower per-partner volume doesn’t justify P2P costs.
This isn’t a compromise — it’s the right answer at scale. It minimizes per-session costs on high-volume partnerships while keeping reach broad through the hub.
Risks to plan for
A few risks worth considering at the strategy stage.
Hub failure or pricing change. If your hub goes down or doubles its fees, you have limited short-term options. Mitigate by maintaining P2P with critical partners.
Protocol evolution. OCPI versions change. Your hub may not move at the same pace as your protocol roadmap, and OCPI version differences (coming soon) can affect which modules a hub supports.
Regulatory shifts. Especially in Europe, AFIR and similar regulations may impose hub-like requirements (NAPs) that change the landscape.
Acquisition or shutdown. Hubs are companies. They get acquired. Some have been shut down. Your data and operations need contingencies.
The honest summary
For most OCPI operators, the right roaming architecture is “hub-mediated with selective P2P.” Pure P2P is right for small or specialized cases. Building your own hub is right only if hub-as-a-business is your strategy. The hybrid model gives you reach plus strategic control. Start where the cost makes sense, monitor as you grow, and evolve the mix over time. Don’t over-engineer at the start; don’t under-invest as you scale.