An ALM platform for a liability that has no matching asset.
CaptureNow is an asset and liability management platform for durable carbon removal. It measures a corporate's residual emissions liability, vetted removal assets through a three-proof gate, structures a bilateral financial instrument, and manages the book over a 10–25 year horizon. Built on Helium's orchestration layer with a new deterministic computation layer.
A long-dated, regulated liability meets a short-dated market
Companies carry a growing clean-up debt — tonnes they will be legally required to remove by their net-zero year. Today it is treated as an annual expense: buy cheap offsets, retire them, book the cost. New rules are forcing a shift toward long-lived removal assets held on balance sheet.
Mandatory, growing, long dated
Every large manufacturer and exporter carries a forward emissions liability. CSRD, ISSB/IFRS S2, SSBJ, SBTi V2.0 and CBAM are converging to make holding durable removal assets mandatory — not optional.
Short, low durability, no balance sheet fit
The voluntary carbon market trades mostly short, avoidance-based credits at registry face value. No standardised, duration-matched, balance-sheet-recognisable removal asset exists to stand against the liability.
Demand becomes forced
SBTi V2.0 raises the durable removal share of neutralisation. CORSIA Phase 2 and CSRD assurance converge around 2028. Demand shifts from voluntary to regulatory-mandated.
CBAM arbitrage delta
A structural spread between domestic carbon price and EU CBAM border cost forms part of the floating leg economics. The platform computes this delta per credit and carries it into fair value and lease rate.
Five capabilities, end to end
The orchestrator sequences — it never decides
Every routing, proof-gate and matching decision is a deterministic Python function in the computation layer, reproducible from state alone. No AI model makes a routing, gate or matching decision. Break this and the audit story breaks.
Enforcement is not a comment in a doc — it is a CI test gate. Every decision function carries an fca_critical marker, is 100% unit-tested, and CI blocks merge if any test fails.
Score the asset, certify it, match it, manage it.
The platform sits above registries, brokers and marketplaces. Its job is to convert a spot-traded, registry face value carbon position into a duration-matched, balance-sheet-recognisable asset book and keep it solvent against a moving liability over 10–25 years.
The three-proof gate
No asset can be matched or placed into an instrument until it independently clears all three tests. Each produces a signed certificate that travels with the asset for its full lifecycle.
Science
Confirms actual net removal quantity — not registry face value. Includes measurement, audit status and a durability tier.
Legal
Confirms clean title, registry lock-out, defined cure obligation, adequate replacement pool and jurisdictional permissibility.
Financial
Establishes fair value at inception, IFRS-9 accounting classification, lease rate and CBAM border delta.
Asset, instrument, structure
Net Removal Tonne (NRT)
A tonne verified by measurement, confirmed by audit, durability-tiered, held without retirement, legally clear and fair-valued. Also framed commercially as a Net Removal Warrant (NRW).
Carbon Liability Swap (CLS)
A 10-year bilateral derivative, extendable to 25 years, under ISDA with a bespoke Carbon Product Supplement. Fixed leg: lease rate by durability tier. Floating: permanent removal price index.
Three balance sheets
Client treasury deposit stays at its bank. Cure reserve sits in a ring-fenced Durability Trust vehicle. The fee-earning platform stays capital-light — a manager, not a principal carrying last-resort risk.
Four durability tiers
Seven platform capabilities
Liability workbench
Connect a corporate system, ingest GHG inventory, model the full liability to net zero, compute residual exposure, and display the live Carbon Solvency Ratio.
Asset intelligence
Continuously refreshed, asset-level view of every monitored removal credit — registry status, removal score, durability tier, title and forward price, reversals flagged in near-real-time.
Proof certification
The science, legal and financial gate producing signed certificates, a rejection register and a public verification endpoint for counterparties.
Matching and structuring
Optimised liability-to-asset matching across five dimensions. Draft instruments with alternatives. Mandatory human approval before execution.
Lifecycle and cure
Daily valuation and margining, automated reversal detection, 90-day cure workflow, buffer pool monitoring and escalation when replacement is not found.
Disclosure and reporting
One-click ISSB and IFRS S2 packs, board reports, border reports and certificate registers generated from platform data.
Forward strategy
Client-specific guidance on optimal instrument size, cheapest tier mix satisfying regulation, and when to settle versus roll — in plain language and as structured data.
Two layers, three sides, one matching core.
Helium's orchestration layer is the conductor — it sequences workflows, holds durable state, inserts human approvals, calls AI models and pulls data from connectors. The computation layer is the new carbon-specific brain — deterministic math only, no model in any decision path. Together they drive 17 modules across three sides.
Helium orchestration over new computation
The conductor
Sequences multi-step workflows, holds durable long-running state, inserts human checkpoints, calls AI models with fallback and cost control, pulls registry data via connectors, enforces multi-tenant RBAC isolation, and logs every step. Decides flow — never decides numbers.
The calculators
Six deterministic engines: Liability Modeller, Three-Proof Scorer, Matching/Optimiser, Pricing & NAV, Margin & Collateral, Carbon Solvency Ratio. Plus regulated audit signing: immutable hash-chained INSERT-only ledger, JOSE/JWS certificate signing, and CASS client-asset segregation.
~40% of code volume may be reused from Helium (accounts, roles, sign-in, database, cache, API skeleton, RBAC). But only ~15–20% of the effort and risk. The cost and failure risk sit entirely in the new computation layer. Frame it as a large head start on plumbing, not “half the product.”
Three sides and a matching core
Liability ingestion
The matching core
Registry and producer intelligence
Seven steps from intake to live instrument
Four data layers, one shared schema
Technology choices
Five phases to a pilot-ready platform.
The software platform can be delivered in roughly five months by a dedicated squad. The build is sequenced so the reused orchestration lands first and de-risks the new computation work. Each phase closes with a working, tested increment. Legal, accounting and regulatory enablers run in parallel on longer external tracks and gate the move from pilot to live product.
Five phases in order
Foundation
Supply side
Liability + matching
Instrument + compliance
Hardening
Sequenced from the data outward
- Stand up environments, pipeline, secrets and observability.
- Define and publish the shared schema package across all four layers.
- Build the storage layer, event bus and adapter interfaces.
- Build the first registry adapters and MRV ingestion skeleton.
- Put the fca_critical test harness and coverage gates in place from day one.
- Complete registry adapters and deterministic reversal detection with auditable lineage.
- Build the NRCS removal scoring model, permanence haircuts and adverse audit override.
- Build audit extraction (VVB parse), durability atlas and legal title verifier.
- Build pricing engine, forward curves by tier and CBAM border delta.
- Run the supply pipeline end-to-end against sandbox registry data.
- Build liability ingestion and normalisation from corporate ERP/treasury systems.
- Build forward modelling across base, accelerated and stress scenarios.
- Build the residual calculator and obligation classifier with 100% coverage.
- Build the Carbon Solvency Ratio engine and its event publishing.
- Wire up the buy-side orchestration end-to-end.
- Build the three-proof orchestrator with deterministic routing only.
- Build JOSE/JWS signed certificates and the hash-chained INSERT-only audit ledger.
- Build the matching engine once its objective function is authored and signed off.
- Build CLS/NRW term sheet generation in machine-readable and human-readable form with FpML output.
- Build mandatory human approval checkpoints with maker-checker workflow.
- Build daily valuation, variation margin, cure workflow and buffer pool monitoring.
- Build dashboard, ISSB/IFRS S2 disclosure packs, registers and board reports.
- Finalise the client ERP/treasury API and the counterparty verification endpoint.
- Security hardening, audit trail review and end-to-end integration tests.
- User acceptance on sandbox data, then a pilot-ready handover.
What gates the move from pilot to live
The software build is the short, controllable track. These external enablers are longer and largely outside the team's control. Production go-live with real client assets and live instruments cannot happen until they clear.
Delivered. A working platform that ingests data, scores and certifies assets, computes solvency, matches liabilities, generates a draft instrument and produces disclosure packs — all on sandbox and test data with a verifiable audit trail. Enough to demonstrate the concept, run an internal pilot and support diligence.
Not delivered. A live regulated product. Executing a real instrument with real client assets requires the ISDA supplement, a signed IFRS-9 accounting opinion, FCA authorisation, and counterparty mandates. Those are the enabler tracks above.
What the build assumes and where risk sits.
Every assumption below is either drawn directly from the source documents or is a standard condition for a build of this scope. They are the items most worth resolving before committing to scale. The five-month timeline holds only while these hold.
What the five-phase plan depends on
A dedicated squad Assumed
The plan assumes a multidisciplinary team: backend and data engineers, an ML engineer, a quant developer for matching and valuation logic, a front-end engineer and a delivery lead — with access to legal and accounting subject matter input. A lean operations-only group is insufficient for the build window.
Stable specifications Assumed
The documented architecture and schemas are assumed stable for the build window. Material changes to the instrument design or data model during the build ripple through every layer and will move the dates.
Sandbox and test data Assumed
The pilot runs on sandbox registry access and representative test data, including synthetic edge cases for reversals and adverse audits. Live registry feeds are not required to reach pilot readiness, but they are required to go live.
Objective function authored first Build pending
The matching engine's optimisation objective and constraints must be specified and signed off before Phase 2 / Month 4. The source documents flag this as the team's own work to author. It is on the critical path for the matching feature.
Long-state spike completed first De-risk required
Holding a 10–25-year instrument's state — with a daily mark-to-market loop and resumable maker-checker approval interrupts — is heavier than chat-style runs Helium was built for. A small spike must validate this before Phase 0 numbers go into any plan or pitch. If Helium can't support it, a LangGraph + Postgres checkpoint engine is embedded instead.
Scoring training data Build pending
The source, format and update cadence of the dataset that trains the removal scoring model are not yet defined. The model can be built and tested on representative data, but real-world accuracy depends on this dataset being sourced and validated before go-live.
Outside the software — but gating the product
ISDA Carbon Supplement External sign-off pending
The supplement that defines the CLS swap does not yet exist in standardised form. External counsel must draft it and engage the relevant working group — estimated at ~18 months. Instrument execution is blocked until it exists and FpML bank messaging is confirmed.
IFRS 9 accounting opinion External sign-off pending
The claim that custodied credits qualify for held-to-maturity treatment is under review and requires a partner-level opinion from a major firm. The materials note this is load-bearing for the business model and a precondition for a bank credit committee. Not yet issued.
FCA authorisation Authorisation pending
The platform targets custody, arranging and managing investment permissions, 12–18 months from application. The design anticipates the controls required. The permissions are not yet held. This is the critical path item for a live regulated product.
Named counterparties Prospective
Banks, distributors, anchor clients, insurers and investors appearing in the materials are described as in negotiation, with named counterparties requiring signed mandates before external citation. Integration points are in scope as technical work — not as confirmed partnerships.
Registry access agreements Pending
Commercial agreements for registry API access (Verra, Puro.earth, TGO and others) are pending. The legal structure of the joint custodian Durability Trust entity referenced in the anchor deal is also unresolved. Both are listed as critical-path items in the source documents.
Where to focus diligence
Financial model is illustrative Assumption risk
The accompanying financial model is explicitly driver-based and illustrative, with several key inputs as placeholders. The base case reaches approximately 15% of the stated revenue threshold. Only an accelerated, liability-linked path — which books fees on undelivered forward mandates — approaches the target. Read as structure, not forecast.
Going concern and operating risk Risk
The sources list principal risks explicitly: reversal and cure performance under stress, an early-revenue going concern position dependent on later funding, and an arm's-length and consolidation status that is subject to opinion and audit and not yet established.
The dependencies are sequential. The legal supplement precedes the accounting opinion, which precedes the assurance engagement, which underpins the first client onboarding and the authorisation evidence. The engineering build can proceed in parallel — but the matching engine objective function, the scoring model training data, the long-state spike, and the consolidation/arm's-length opinion are the four items most worth resolving before committing to scale.