Trust centre

What we claim is in the code and on record

Security principles present in the code, each with its evidence record; status of compliance programmes (not certification); service levels and security questionnaire requests.

Request the security questionnaire Evidence records →

Method

01Every claim is bound to an evidence record
02The record states what it supports and what it does not show
03The evidence level is the basis of the claim, not product availability
04The verification date is on the record; an overdue record is flagged

This page carries no certification, no numeric service level and no partner name; what does not exist is not written.

Principles

Principles present in the code

Every principle is tied to an evidence record. The record says what it supports and what it does not show; the evidence level is the basis of the claim, not product availability.

01 1/4 Present in source code

default: deny

Fail-closed relationships

No location, tariff, session, CDR or token flows unless an explicitly accepted, active relationship exists between the two parties. A completed handshake does not open data flow; publish scope defaults to deny.

Inspect evidence

Fail-closed partner relationships· Source code review

No location, tariff, session, CDR or token flows unless an explicitly accepted, active partner relationship exists between the two parties; publish scope defaults to deny and changes are written to an audit ledger.

Supports:That a completed credentials handshake does not open data flow and that scope is an explicit, auditable decision.

Does not show:Contractual data-sharing permissions; those come from the signed agreement and DPA.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

02 1/4 Present in source code

hash(prev) → entry

Audit ledger with hash chain

Settlement ledger entries are chained by hash; a statement can be re-verified against its inputs. Scope changes are written to an audit ledger as well.

Inspect evidence

Hash-chained settlement ledger· Source code review

Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.

Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.

Does not show:Fee rates or splits; those are in the participation agreement, not on this site.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

03 1/4 Present in source code

retention → sweep

Token hashing and delete-on-expiry

Token material pushed to the hub is hashed; encrypted credentials and hashes are deleted by a scheduled sweep as soon as their retention time expires.

Inspect evidence

Retention sweep for token material· Source code review

Hashed token data and encrypted credentials are deleted as soon as their retention time expires; the sweep runs on a schedule and is the most conservative setting available.

Supports:The delete-on-expiry rule stated on the trust page.

Does not show:A data-controller’s own retention obligations; those are set in each DPA.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

04 2/4 Real screen or document

PAN: never stored

No cardholder data

The hub does not store, process or route cardholder data; card payment, where it exists in a partner flow, stays with the partner’s payment provider. The SAQ-A scoping document describes the target architecture.

Inspect evidence

Compliance programme status· Document

ISO/IEC 27001:2022 in progress (gap assessment, target end of 2026), SOC 2 in planning, PCI DSS SAQ-A scoped as a self-assessment; the matrix tracks each control’s status and owner.

Supports:That the programmes exist and their stated status on the trust page.

Does not show:Any certification or attestation: none has been issued for E-Gridium.

Source: Hub repository, docs/compliance/compliance-status.json and COMPLIANCE-MATRIX.md · Verified4 October 2026

All evidence records →

05 1/4 Present in source code

scope: party × role

Per-party scoping

Portal views are scoped to party and role: a partner sees only its own statements, records and contract; CPO-only and eMSP-only views are kept apart.

Inspect evidence

Hub portal views per role· Source code review

The portal route table defines hub-operator views (directory, map, settlement windows, approvals, partners, contract queue, aggregators, operations, stuck work) and partner views (my statements, my records, my contract, roaming, data quality) with CPO-only sharing sets and tariffs and eMSP-only tokens, sessions, reservations and commands.

Supports:The portal views listed on the role pages.

Does not show:What a given partner sees in production; access is scoped per party. Real screens will be added as separate product-flow records.

Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026

All evidence records →

Evidence records

Every record this page and all other pages rest on, with source and verification date.

All records →

Engineering transparency

Engineering footprint of the hub

Twelve services in one monorepo (OCPI adapter, clearing platform, identity, roaming mesh, PKI, map data, sandbox, ops MCP, mocks and migrations), 593 database migrations, 87 architecture decision records, about 1,500 test files, and three OpenAPI documents with 83 paths in total.

Does not show: Production scale, partner counts or service levels; counts describe the codebase, not the traffic.

Source: Hub source repository, counted on 4 October 2026 · Last verified: 4 October 2026

Open the evidence record →

12
services, one monorepo: 593
database migrations: 87
architecture decision records: ~1,500
test files: 83
OpenAPI paths, three documents

Compliance

Compliance programmes

Programmes are published with their status. None of these is a certification: Any certification or attestation: none has been issued for E-Gridium.

Standard	Status	Phase	Target date	Statement
ISO/IEC 27001:2022iso-27001	In progress	Gap assessment against Annex A; ISMS scope statement maintained	31 December 2026	The hub is operated under an information security management system aligned with ISO/IEC 27001:2022. Audit readiness is tracked control by control; no certification audit has been scheduled yet.Source: docs/compliance/compliance-status.json · Last verified: 4 October 2026
SOC 2 Type IIsoc2	Planning	—	—	Trust Service Criteria are mapped to the same control set; the attestation engagement is in planning.Source: docs/compliance/compliance-status.json · Last verified: 4 October 2026
PCI DSS SAQ-Apci-saq-a	Self-assessment	—	—	The hub does not store, process or route cardholder data; card payment, where it exists in a partner flow, stays with the partner’s payment provider. The SAQ-A scoping document describes the target architecture.Source: docs/compliance/pci-dss-saq-a.md · Last verified: 4 October 2026

2/4 Real screen or document

Inspect evidence

Compliance programme status· Document

ISO/IEC 27001:2022 in progress (gap assessment, target end of 2026), SOC 2 in planning, PCI DSS SAQ-A scoped as a self-assessment; the matrix tracks each control’s status and owner.

Supports:That the programmes exist and their stated status on the trust page.

Does not show:Any certification or attestation: none has been issued for E-Gridium.

Source: Hub repository, docs/compliance/compliance-status.json and COMPLIANCE-MATRIX.md · Verified4 October 2026

All evidence records →

Service levels

No published number

No numeric service level is published on this site; service levels, how they are measured and what follows from them are defined in the participation agreement.

Agreements →

Enterprise review

Security questionnaire

We answer your information security and procurement team’s questionnaire; answers rest on the evidence records above and the compliance matrix. Send the request through the contact form.

Request questionnaire Evidence records →

How it proceeds

01Apply with your role and versions endpoint
02Sign the participation agreement and DPA
03Handshake in the sandbox, then accept relationships

Connect your network or app once; decide the rest per partner.

Apply to connect Onboarding and sandbox →