eMSP Platform Features: A 2026 Architecture Checklist for Driver, Operator, Settlement, and Compliance Capabilities

eMSP platform features were a stable list in 2022 — driver identity, in-app session control, OCPI roaming, tariff display, payment processing, and basic CDR reconciliation. The list of what an eMSP provides has grown by half since then, and the platforms still anchored on the 2022 list are about to discover that AFIR enforcement, ISO 15118-20 plug-and-charge, OCPI 2.2.1 hub maturity, V2G market entry rules, and FERC Order 2222 / EU CER aggregation are not optional roadmap items. They are capabilities the platform either has by 2026 or has to retrofit under deadline pressure, with the regulatory consequences of getting it wrong falling on the operator. This guide walks the buyer-evaluation lens an operator should run against any eMSP platform — the one they own, the one they are about to procure, or the one they are about to build — organized by the five capability categories that matter for the next decade rather than the last one. The four-lever eMSP platform investment thesis sets the strategy; these eMSP platform features are how an operator checks whether the strategy is actually shipped.

The eMSP Capability List That Survived 2022 — And the Five Forcing Functions That Made It Obsolete

A 2022-era eMSP delivering driver identity, OCPI roaming with one hub partner, tariff display, in-app payments, basic CDR reconciliation, and a workable support flow was a credible platform. Every vendor product page on today’s SERP still describes that platform. Most procurement RFPs still build their requirements around it. The list looks complete because the language used to describe it has not changed.

Five forcing functions reshaped the list between 2023 and 2026. AFIR — EU Regulation 2023/1804 — mandates payment-method openness, real-time station data, and ad-hoc charging without subscription at any new public charger of 50 kW or more, with gates binding for existing operators in 2026-2027. ISO 15118-20 plug-and-charge moves from roadmap differentiator to baseline buyer expectation. OCPI 2.2.1 hub maturity raises the depth bar across Sessions, CDRs, Tariffs, and bilateral Tokens authorization. V2G market entry — functional structures in the UK, NL, and DE plus landing US ISO/RTO pilots — turns bidirectional energy from R&D into product. And FERC Order 2222 plus the EU CER package together make the eMSP a potential aggregator counterparty for any fleet, depot, or V2G operator.

What does an eMSP provide today that it did not three years ago? Regulatory-grade capability across all five surfaces — not a longer feature list, but a deeper one. The audit question shifted from “does the platform have these features?” to “do the features survive an honest audit against forcing functions that close in 2026 and 2027?” The five eMSP capabilities below organize that audit.

Driver-Facing Capabilities: Identity, Roaming, In-App Experience, and the Plug-and-Charge Discipline

The driver-facing surface is the one drivers feel. It is also the one that hides the most consequential platform decisions, because the experience that works at a thousand drivers can fail at fifty thousand without anyone noticing until the support tickets land.

The emsp identity model comes first because it determines everything downstream. A federated model — separate Tokens per CPO partner under OCPI’s authorization flow — gives roaming reach but fragments the driver’s view of charging history, payment, and loyalty. A single-eMSP-identity model gives a coherent experience but loads onto the platform every Tokens negotiation with every counterparty. There is no neutral choice; the platform either owns the driver relationship or shares it with every partner the eMSP integrates. The decision locks in the driver UX for five years.

emsp roaming is usually reported as a partner count. The number that matters is integration depth. A platform with twenty CPO partners at 70 percent Sessions, 60 percent CDRs, and 40 percent Tariffs coverage is providing less actual emsp ev charging reach than a platform with eight partners at 100 percent depth. Counting partners is not counting capability. Plug-and-charge sits between this surface and compliance: ISO 15118-20 defines the protocol, and the practical capability is PKI certificate handling and the back-end settlement when a driver plugs in at an unfamiliar charger and the cable handshake authenticates them without a screen tap. EU automakers expect this to work by 2026; operators serving premium-segment drivers cannot defer it without losing them. The driver app development companion walks through the in-app surface that backs all of this.

Operator-Facing Capabilities: Tariff Management, CPO Onboarding, Workflow Surface, and the Operator’s Time-to-Change

Operator-facing capabilities are the ones eMSP staff use every day, and the ones vendors describe in the most over-engineered language. The audit cuts through the language by measuring one thing: how many days from operator decision to live production change, for each common operational action?

emsp tariff management is the first measurement. A platform whose tariff surface is a configuration file requires engineer intervention to change a price. A platform whose tariff layer is a CRUD surface with effective-dating and audit logs lets a commercial operator change pricing in minutes and lets the finance team reconstruct what the tariff was on any historical date when a settlement dispute lands. Every vendor claims tariff changes; the audit question is “can you change tariffs by 9am Friday to go live by 9am Monday, with the audit trail your CFO needs?”

CPO partner onboarding is the second. The surface includes OCPI credentials exchange, hub agreement papering, certificate provisioning, depth negotiation on Sessions and CDRs, and the operational handshake that confirms the partner is actually delivering. Most platforms make the first three workable and leave the last two as project work the operator inherits. A platform compressing onboarding to two-week per-partner cycles scales roaming reach at the speed regulatory and commercial pressure demands. Cross-network EV roaming patterns describe the topology; the operator workflow decides whether the topology scales. Time-to-change bundles tariff, partner onboarding, support, and dispute resolution into one metric. A platform whose answer is “30 days” cannot serve a market whose tariff rules change quarterly. The parallel CPO-operations surface lives in the CPO-side platform companion — different products for different teams.

Settlement & Financial Capabilities: CDR Lifecycle, Multi-Party Reconciliation, Tax/VAT, and the Margin Discipline Layer

Settlement is where vendor product pages get vague and where platforms quietly diverge. The surface is unglamorous — Charge Detail Record collection, validation, normalization, reconciliation across counterparties, invoicing, tax handling, and dispute workflow. None of it shows up in a marketing screenshot. All of it decides whether the platform makes money for the operator or quietly leaks margin every transaction.

CDR lifecycle ownership is the first audit question. Does the platform own the CDR from charge-port telemetry through Tokens authorization through Sessions update through reconciliation through settlement engine through invoicing — or does it hand off to a third-party settlement provider somewhere in the middle and pay vendor margin every transaction forever? End-to-end ownership exposes auditable emsp settlement state at every step; a hand-off exposes only what the third party chooses to surface. Multi-party reconciliation is the second: a single charging session in 2026 can involve the driver, the eMSP, the home CPO, a roaming CPO, the OCPI hub, the payment processor, the tax authority, and — for V2G or DR-enrolled assets — the aggregator counterparty. Can the platform tell the operator today what the margin per kWh is across every roaming network?

Tax and VAT cross-border is the third. EU member-state VAT rates differ, place-of-supply rules differ, and reverse-charge handling differs; US state-by-state sales tax on charging sessions varies by interpretation. A platform treating cross-border as a roadmap item locks the operator out of EU multi-market growth without a rebuild. The engineering decisions behind this surface live in the engineering-decision companion; the capability question here is whether the platform exposes the right surface for the operator’s finance team to configure and audit.

Compliance & Regulatory Capabilities: AFIR Readiness, ISO 15118-20, OCPI 2.2.1, Data Residency, and the 2026 Forcing Functions

The compliance surface is where the forcing functions land. Each one imposes a specific capability gate, has a deadline, and has a regulator with enforcement powers. Platforms that already shipped these capabilities sell against the platforms that have not. The platforms that have not are about to learn that you cannot retrofit compliance into firmware that was never designed for it.

emsp afir readiness is the first gate. EU Regulation 2023/1804 mandates contactless payment acceptance without account creation at new public chargers of 50 kW or more from 2024, real-time station status data published in machine-readable formats, and OCPI-based roaming for any cross-network operator. The platform-side capability is the payment-acceptance flow without a Tokens-authenticated session, the public real-time data API with sub-minute latency, and the OCPI 2.2.1 baseline. emsp iso 15118 readiness is the second: plug-and-charge moves from differentiator to expectation between 2025 and 2027 across EU markets, with contract certificate provisioning, certificate-chain validation, and back-end settlement tied to the right billing relationship.

OCPI 2.2.1 protocol architecture is the third gate, and the OCPI module integration in production work that goes with it is the difference between a working roaming partnership and a non-working one. Data residency adds a parallel constraint — the Open Charge Alliance defines the protocol; member-state regulators define where the data is allowed to land; ISO/IEC 27001:2022 is the security baseline operators are increasingly contracted to verify. V2G readiness and aggregation rules are the fourth gate — moving from optional to mandatory between 2026 and 2028 as ISO 15118-20, UK/NL/DE market entry, FERC Order 2222, and the EU CER framework make the eMSP a potential aggregator counterparty. The EVRoaming Foundation framing is the reference for cross-network V2G transactions.

Forcing function	Capability gate it imposes	2026 status	2027 status
AFIR (EU Regulation 2023/1804)	Contactless payment without account; real-time station data API; ad-hoc charging without subscription; OCPI roaming for cross-network operators	Mandatory for new public chargers ≥50 kW; member-state enforcement ramping	Retrofit windows bind across most EU member states for existing fleet
ISO 15118-20 Plug-and-Charge	Contract certificate handling; PKI infrastructure; certificate-authenticated session settlement	Baseline buyer expectation in EU + US automaker pilots	Driver-experience differentiation gap widens for platforms without it
OCPI 2.2.1 Hub Maturity	Depth across Sessions, CDRs, Tariffs, bilateral Tokens authorization with hub-mediated counterparty handshake	Hub partners require 2.2.1 depth for new partnerships	2.1.1-only platforms locked out of new roaming partnerships
V2G Market Entry	Bidirectional energy settlement; grid-services billing; ISO 15118-20 V2X compatibility	Optional in most markets; commercially relevant in UK, NL, DE	Moving from optional to mandatory in fleet, depot, and utility-affiliated programs
FERC Order 2222 + EU CER Aggregation	Aggregator-counterparty workflow; DER aggregation enrollment; grid-services revenue settlement	US ISO/RTO pilots active; EU CER framework in implementation	eMSP becomes a potential aggregator counterparty for fleet/depot/V2G operators

The Capability Audit Operators Should Run Before the Next Contract Renewal

The five categories above are the audit framework; the way to use it is the audit itself.

The emsp checklist that follows is not a procurement document with hundreds of yes/no questions. It is a five-category, five-forcing-function review with a Pass/Watch/Fail rubric on each capability gate. Pass means the platform demonstrably ships the capability today and the operator can verify it against a production workflow. Watch means it exists with caveats — partial coverage, manual workarounds, or roadmap dependencies that have not landed. Fail means the capability is on a slide deck and not in production. Operators who run this emsp evaluation early — before the next contract renewal — have time to negotiate. Operators who run it at renewal time migrate under deadline pressure.

The eMSP platform features that survive the audit share a posture: capability gates evaluated against regulatory deadlines, not vendor preferences. They share a discipline: audit trails, effective-dating, and dispute workflows in every category, not bolted on after the operator discovers they are missing. The four-lever investment thesis is where the capital decisions sit; the API and integration-topology deep dive is where the engineering decisions sit; the emsp capabilities audited here are how the operator confirms that capital and engineering met the regulatory ground that 2026 has already moved. For operators pursuing a platform build or rebuild, the custom eMSP platform engagement lives in that lane; for operators accelerating phase-one production on a pre-certified protocol base, the eMSP Engine accelerator path compresses the calendar without conceding ownership of the capability surface.

The capability audit also presupposes a role decision the operator may not yet have made. Before evaluating capabilities, the question is whether the platform serves the eMSP role, the CPO role, or both simultaneously — and the revenue model that follows each choice. Our eMSP vs CPO role-and-revenue decision companion walks through what each role captures, where the revenue models meet at the OCPI settlement layer, and the three operator profiles in 2026 where the integrated-stack answer (running both roles on one platform) is the right one. The role decision comes first; the capability audit confirms the platform delivers it.

Capability category	Audit question	Pass	Watch	Fail
Driver-facing	Do identity, roaming reach, in-app experience, and plug-and-charge compose into a single coherent driver experience?	Single eMSP identity surfaces unified history; ISO 15118-20 contract certificate handling in production	Identity unified; plug-and-charge works for some automaker certificates but not all	Federated identity fragments driver view; plug-and-charge on roadmap only
Operator-facing	What is the time-to-change for tariff updates, CPO partner onboarding, and operational changes?	Tariff change 2 business days; CPO onboarding 2 weeks; support escalation 1 hour	Tariff change inside a week; CPO onboarding 4-6 weeks; manual workarounds documented	Tariff change requires engineer ticket; CPO onboarding 3+ months
Settlement	Can the platform tell the operator today what the margin per kWh is across every roaming network?	Full CDR lifecycle ownership; real-time per-network margin visibility; dispute workflow inside contractual SLA	End-to-end ownership but margin visibility on monthly batch; disputes surface within SLA grace period	Settlement handed off to third-party provider; margin visibility through vendor report only
Compliance	Does the platform pass AFIR, ISO 15118-20, OCPI 2.2.1, and data-residency capability gates in production today?	All four in production with audit trails and certificate provisioning workflows in place	Three of four in production; one in late-stage rollout with documented timeline	Two or fewer in production; multiple capabilities described as “on the roadmap”
Integration depth	Is the platform’s reach a partner-count claim, or measurable OCPI module coverage per partner?	Per-partner module coverage published; bilateral Tokens authorization documented; tax/VAT configurable per market	Partner count reported; module coverage available on request; tax handling partial cross-border	Partner-count headline; module depth opaque; tax/VAT single-market only