Who Actually Runs Your Ledger? An Outsourcing Register for UK Aergo Deployments

When a UK bank, insurer or payments firm puts an Aergo-based service into production, the board paper often asks a deceptively simple question: who is the supplier? The honest answer is plural. Aergo may supply the protocol and client software, but the operational service depends on node hosts, RPC providers, bridge operators, oracle feeds, key custodians and monitoring tools. Treating the blockchain as a single vendor is not merely imprecise; it obscures the dependencies that UK operational resilience and outsourcing expectations require firms to govern.

Start with the dependency map, not the contract

An Aergo deployment is a stack of services rather than a monolithic product. A permissioned network may run on infrastructure operated by the firm, a consortium partner or a cloud provider. A public-network integration may rely on third-party RPC access, indexers and block explorers. A token bridge introduces operator and liquidity dependencies. Price or identity feeds introduce oracle dependencies. Key management may sit with an internal HSM team, a specialist custodian or a cloud key service. Each of these can affect the firm's ability to provide an important business service.

The outsourcing register should therefore begin with a dependency map. For each material service, record the legal entity, jurisdiction, role in the Aergo stack, data and assets touched, substitutability, current contract or arrangement, and the internal owner. The protocol itself may not be a supplier in the contractual sense, but the entities that operate, host and connect it usually are. The register exists to make that distinction explicit.

Materiality thresholds that survive scrutiny

A register becomes useful only when it separates the critical from the merely convenient. UK operational resilience rules, which came into force in March 2025, require firms to understand how disruptions to third parties could affect important business services. In 2026, that logic should be applied to Aergo deployments with clear thresholds.

A dependency is likely to be material if its failure or unavailability could impair transaction submission or confirmation, prevent access to private keys, undermine the integrity of evidence, interrupt regulatory reporting, or cause customer harm. A self-hosted Aergo node may not be a vendor dependency, but the underlying cloud region and the team that operates it are. An RPC provider may look peripheral until it becomes the only route by which applications read chain state. A bridge operator may be material not only for transfers but for the firm's ability to unwind positions.

Thresholds should be documented, reviewed at least quarterly and revisited on change. A binary label of critical or non-critical is rarely enough. Tiering dependencies by impact tolerance, recovery time and substitutability gives the board a more honest picture.

Concentration risk is rarely where the diagram says

Concentration risk in an Aergo deployment often hides in shared providers and shared regions. Several applications may use the same RPC provider. Several consortium members may host nodes in the same cloud region. A single custodian may hold keys for multiple services. A bridge may depend on a small set of operators or liquidity providers. An oracle feed may aggregate data from sources that are less independent than the dashboard suggests.

The register should capture fourth-party dependencies where they affect a material service. It should also record the firm's exposure to a provider withdrawal, outage, sanctions event or jurisdictional change. Scenario testing matters here: if the primary RPC route fails, what is the fallback; if the bridge operator pauses activity, what is the wind-down path; if the key custodian changes terms, what is the migration plan? Concentration limits and secondary routes are architecture decisions, not procurement afterthoughts.

Exit is a design artefact

For many Aergo deployments, exit planning is treated as a contractual clause. It is better understood as a design property. The register should record, for each material dependency, the exit route, the data export format, the state reconstruction method, the key migration procedure, the bridge wind-down plan, the oracle fallback and the estimated time and cost of substitution.

Some dependencies are easier to exit than others. A hosted node can often be replicated. A proprietary indexer may be harder to replace. A bridge may have no clean exit mid-transaction, which makes pre-funded reserves, governance approvals and incident playbooks part of the exit story. The board does not need every technical detail, but it does need to know which dependencies could delay or prevent an orderly withdrawal.

Audit evidence ages quickly

An outsourcing register is not an annual spreadsheet. It is a controlled record that should move with the deployment. Each entry should link to the evidence that supports it: contracts, service descriptions, SLAs, assurance reports, penetration tests, key ceremony records, change tickets and incident reviews. Version history and ownership matter. Auditors and internal risk functions will want to see not only what the register says today but how it was updated when a provider changed, a bridge operator was replaced or a new oracle feed was introduced.

The register should also map to the firm's control framework. If a third party operates nodes, which controls cover patching, access management and monitoring? If a custodian holds keys, how is the segregation of duties evidenced? The register is most valuable when it connects dependency information to the evidence that proves the firm is managing it.

Board reporting: one page, three questions

Board reporting should be concise. A useful one-page view answers three questions: which dependencies could stop an important business service, what is the firm's concentration and exit exposure, and what changed since the last report? Supporting metrics might include the number of tier-one dependencies, the percentage of material services reliant on a single provider, the results of exit or failover tests, and the status of open remediation actions.

This is not a demand for technical detail at board level. It is a demand for accountability. Senior managers remain responsible for the services they provide, even when the underlying ledger is shared. The register helps translate a complex Aergo deployment into a governance artefact that risk, compliance and the board can use.

A practical register shape for Aergo builds

A workable template might include an identifier, service name, provider legal entity, role in the Aergo stack, data and assets involved, materiality tier, substitutability, concentration notes, exit route, evidence owner and next review date. The exact fields should fit the firm's existing outsourcing and operational resilience frameworks rather than create a parallel universe.

The important step is cultural: stop asking who the blockchain vendor is and start asking which entities can affect the service. Once that question is routine, the register becomes a living map of accountability rather than a compliance ornament.