Escrow is the cheapest clause in a charging platform contract, and the price is the most honest thing about it. A source code escrow agreement places a copy of the vendor’s code with a neutral third party, to be released to the customer if a defined trigger fires, most often the vendor’s insolvency. For an annual fee that barely registers against the platform spend, a procurement team can close out the scariest line on the risk register: what happens to a network of charge points already in the ground if the company running the software behind them stops existing. It is a reasonable control to buy. What it does not do is convey ownership, and the distance between those two things is where charge point operators get hurt.

Source Code Escrow Is Priced Like Insurance Because That Is What It Is

The mechanism was designed for a different industry. Escrow became standard practice in the on-premise era, when the customer already had a working installation running on its own hardware and needed protection only against the vendor disappearing partway through a maintenance term. The binaries sat in the customer’s data center. The deposit covered the one missing piece: the ability to keep fixing them.

A charging platform inverts that arrangement. The software runs in the vendor’s cloud, on the vendor’s infrastructure, under the vendor’s operations team, and the customer holds an account login. The deposit stops being the missing piece and becomes the only piece, arriving stripped of the machinery that made it useful in the first place.

Insurance underwriting explains the pricing. The premium is low because the payout is narrow and the trigger is rare, which is precisely what makes the clause easy to approve and easy to forget. Difficulty begins when that clause is presented upward as the answer to ownership, a question that turns on whether ownership was ever available to you in the first place. A software escrow agreement is a contingent claim on a future delivery, conditional on an event that may never be defined the way the buyer imagines it.

What the Escrow Agreement Withholds Is the Part That Actually Runs the Platform

Start with whether the code arrives at all. In the United States, Section 365(n) of the Bankruptcy Code, added in 1988, lets a licensee elect to retain its rights when a trustee rejects an intellectual property license. The trustee must then hand over any embodiment of that intellectual property it holds, and must not interfere with the licensee’s right to obtain one from another entity, an escrow agent included. Both obligations run only as far as the license or a supplementary agreement provides, and an escrow agreement is exactly the supplementary agreement that language contemplates. The statute protects an escrow arrangement that was drafted properly. It manufactures nothing where the drafting was thin. European insolvency regimes differ by member state, which is why an operator running networks in several countries tends to negotiate this clause more than once.

Then there is the trigger itself. Standard release conditions cover insolvency, bankruptcy filings, cessation of trading, and sometimes a sustained failure to meet maintenance obligations. They rarely cover the more common ways a platform goes away: an acquisition followed by a product sunset, a strategic exit by a solvent parent, the deprecation of the service tier you happen to sit on, or a renewal quote that reprices the relationship beyond what the business will carry. Those are commercial events, and surviving one is an exit cost rather than an insolvency claim.

Assume the trigger fires and the deposit lands. What arrives is a repository frozen at a point in time. Running a charge point management system (CPMS) from it takes several things the deposit does not automatically carry: a license broad enough to host, modify, and commercially operate the software rather than merely maintain it; the third-party and open-source components whose own licenses may not travel with the release; the build pipeline, infrastructure definitions, and secrets management that turn a repository into a running system; and the operational knowledge behind all of it, from firmware quirks across a dozen charger manufacturers to certificate lifecycle handling and the roaming credentials already live in production.

Verification is where that risk is either priced or ignored. Escrow agents sell it in tiers: a file inventory and integrity check at the bottom, a compile-and-build test in the middle, and a full build with functional testing on clean infrastructure at the top. Only the top tier answers the question the buyer actually has. Deposits routinely stay at the cheapest tier for the life of the contract, because verification is the first line cut when the escrow budget is challenged, and an unverified deposit records an assumption rather than a capability.

Capability is the part no agreement can deposit anywhere. When an EV-charging hardware manufacturer needed Open Charge Point Protocol (OCPP) 1.6 folded into its own IoT cloud, Codibly’s team completed the integration inside a month, and the reason had little to do with code changing hands. Protocol knowledge moved with the delivery, which is the substance of what a charging station management system (CSMS) and CPMS engagement transfers.

Six gates a source code escrow deposit must clear between a vendor exit and a running charging platform. The exit event covers insolvency, acquisition followed by product sunset, service tier deprecation and an unaffordable renewal quote, of which only the first is a standard release condition. Gate one asks whether the event is a listed release condition, gate two whether the deposit will actually be delivered under Section 365(n) and differing European insolvency regimes, gate three whether the license is broad enough to host, modify and commercially operate, gate four whether anyone verified the deposit builds across the three verification tiers, gate five whether the release carries the build pipeline, infrastructure definitions and third-party component licenses, and gate six whether the team can actually operate it. The outcome, a CPMS running under your control, is reached only where every gate was negotiated, priced and tested before the trigger fired.
Every gate is a clause someone either negotiated or signed as drafted. Full source ownership does not insure against the gates; it removes them.

Three Ownership Structures, Three Different Assets at Year Five

Charging platform procurement offers three structures, and the clarifying way to compare them is to ask what the operator holds on the day the term ends.

Structure What the contract conveys on day one How you get the source code Right to modify and operate in production What you hold at year five
SaaS subscription: the vendor hosts, operates, and upgrades the platform A right to use the hosted service for the term. No code, no infrastructure, no build pipeline. You do not. None. Configuration only, within the limits the vendor chooses to expose. A renewal quote, and whatever data the exit clause allows you to export.
Escrow-backed subscription or hosted license: the same service, with a deposit held by a third party The same right to use, plus a contingent claim on a code deposit held by an escrow agent. Only if a defined trigger fires, and only to the extent the agreement and the verification tier actually support delivery. On release, typically a limited right to maintain for internal use. Hosting, modification, and commercial operation must be negotiated separately. A renewal quote, plus a contingency whose condition is unknown unless verification was bought and exercised.
One-time license with full source ownership: a productized core delivered as source The source code, the right to modify it, and deployment into your own cloud from day one. It is delivered at handover. No trigger required. Full. You control the roadmap, the hosting decision, and the release schedule. A running platform on your own infrastructure and a codebase on your own balance sheet.
Three charging-platform ownership structures, compared by what the operator holds when the term ends.

The middle row is the one that gets mis-sold. “Escrow-backed” and “owned” turn up on the same slide often enough that buying teams treat them as grades of a single thing, when they price differently for a reason. An escrow-backed license is a subscription with a contingency attached, and the asset at year five is still a renewal conversation. Full source ownership changes the governing question from whether the vendor survives to whether the operator has the capability to run what it owns. That second question is one the operator can answer, budget for, and act on.

The third structure is not theoretical. Codibly built a scalable OCPP 1.6J server for IMP PAN that runs across Poland, Denmark, and the Netherlands under the customer’s own control, multi-site and multi-country, with no dependency on a vendor’s hosting decision. On the US side, Banyon Power’s managed charging platform was built to the same shape: installer commissioning, a homeowner app, charging orchestration and utility-facing dashboards in one system rather than four disconnected tools, on an AWS Cloud and IoT Core architecture. It is the company’s own platform, credible enough on that basis to carry its conversations with utilities and investors. Neither operator is holding a renewal quote. The protocol-layer version of the same choice, for teams weighing whether to write the backend themselves, sits in the build, buy, or accelerate analysis of an OCPP backend.

The Clauses That Decide Whether “Escrow-Backed” Means Anything

Where escrow is the right control, and it frequently is, the value lives entirely in the drafting. The standard paper an escrow agent circulates is written to be signable, which means it defaults to the narrowest workable version of every term. Each clause below is a negotiation with a price attached, and a team that treats the set as boilerplate has bought the cheapest version of all of them.

Clause The standard version The version worth negotiating Why it decides the outcome
Release triggers Insolvency, bankruptcy filing, cessation of trading. Add product discontinuation, sunset following an acquisition, material and unremedied service failure, and loss of the certifications the platform depends on. Platforms are lost to commercial decisions far more often than to insolvency.
License grant on release A limited right to maintain the software for internal use. An explicit right to host, modify, and commercially operate, exercisable by a named integrator acting on your behalf. A maintenance-only grant leaves you holding code you may not lawfully run as a business.
Verification tier File inventory and integrity check of the deposit. Full build and functional test on clean infrastructure, repeated on a defined cadence. Only a build test proves the deposit compiles into the system you are actually running.
Deposit scope and cadence Application source, refreshed annually. Source plus build scripts, infrastructure definitions, dependency manifests, and operating documentation, refreshed at every major release. A repository without its build environment is not a deployable system.
Third-party and open-source components Silent. A schedule of dependencies, with written confirmation that their licenses survive a release to you. One non-transferable commercial component can block production use of everything around it.
Transition assistance and step-in Absent, or capped at a token number of hours. A defined transition period with named personnel, runbooks, and knowledge transfer, priced in advance. Capability is the part of a platform that no deposit can hold.
The six escrow clauses that determine whether an “escrow-backed” platform contract performs when it is called on.

Cost follows directly from that table. A standard single-beneficiary source code escrow agreement is inexpensive on an annual basis, small enough that it rarely attracts scrutiny at renewal. Verification at the upper tiers, the counsel time to negotiate release conditions and license scope, and any multi-beneficiary or multi-jurisdiction structure are what move the number, and they are also the only components that determine whether the arrangement performs when it is finally called on. An escrow line that costs almost nothing is usually reporting the tier of everything beneath it.

Requirements-level questions about the platform itself belong in a separate document, and the CPMS RFP checklist covers those. The clauses above govern what the contract conveys once the requirements are settled.

What Procurement Should Be Negotiating Instead

Escrow earns its place as a control on residual risk once the ownership structure has been chosen. An operator running a small network with no in-house engineering function is very likely right to rent, and a well-drafted escrow clause with real verification and genuine transition assistance is the sensible way to cover the tail risk of that decision. That is escrow doing the job it was built for.

Where the platform is core to the business, the negotiation worth having concerns the structure rather than the contingency. A productized core, licensed once and delivered as source, deployed into the operator’s own cloud with protocol capability transferred alongside the code, removes the event that escrow exists to insure against. The CPMS Engine and the eMSP Engine are built on that model, and operators are running production networks on it today. Ask a vendor what happens to your network if they disappear, and under that structure the honest answer is that very little happens at all.

Own the Charging Software white paper promo - Codibly