Summary

  • The five Regional Internet Registries do not publish one comparable global cost account. For 2024, RIPE NCC reported EUR 36.274 million of expenditure, ARIN reported USD 30.3 million of operating expense, LACNIC reported USD 11.274 million of operating expense, and APNIC's listed audited expense lines sum to about AUD 33.466 million. AFRINIC's reviewed 2024 disclosure gives identifiable sub-lines, including USD 122,311 for remote sites and USD 97,678 for computers, but not a safely comparable total operating-expense denominator in the same source.
  • Those native-currency figures must not be added without a stated exchange-rate date and accounting reconciliation. Membership counts must not be added into a “global member” denominator either: RIR definitions differ, organisations can hold several accounts or belong in more than one region, and year-end members do not equal paying member-months.
  • A 5%, 10% or 15% addressable-cost sensitivity produces pools of EUR 1.814 million to EUR 5.441 million at RIPE NCC, USD 1.515 million to USD 4.545 million at ARIN, AUD 1.673 million to AUD 5.020 million at APNIC and USD 564,000 to USD 1.691 million at LACNIC. These are not savings forecasts. A shared service would itself cost money, require migration and parallel operation, and leave local legal, language, billing and member-governance work in each region.
  • Regional authority should remain where rights are interpreted: contracts, identity checks, sanctions, disputes, elections, language, local payment and accountability. Common infrastructure is most plausible where machines perform the same coordination task: data schemas and APIs, conformance testing, escrowed logs, backup and recovery, common security controls, inter-RIR transfer validation and the interface with IANA.
  • The right reform is a federated shared-service market with portability, independent assurance and regional exit rights, not a single unaccountable global registry. Members should be able to compare the full cost, resilience and service quality of a regional implementation with a common platform before funding another replacement stack.

Five institutions are not the same as five necessary implementations

The Regional Internet Registry system solves two different problems that are often fused. One is political and legal: organisations need a body in their region that understands their law, languages, payment systems, operating conditions and member community. The other is technical: every allocation, transfer and registration must fit a globally unique number-resource system.

Regional authority is valuable because a network in Nairobi, Montevideo, Brisbane, Amsterdam or Virginia should not have to resolve every identity, contract and governance question through one remote global bureaucracy. Local institutions create routes for participation and challenge. They can adapt training and support to different markets. They distribute institutional failure rather than placing every resource holder under one board.

Global uniqueness points in the opposite direction. An autonomous system number cannot be unique only within a region. A prefix cannot be authoritatively registered to incompatible holders in two databases. Transfer records, delegated statistics, RPKI certificates and reverse DNS depend on common syntax and coordinated state. The core technical product is one coherent namespace expressed through regional custody.

It does not follow that each region must independently procure, build, secure and recover every component of that product. Five boards may be necessary for accountable rights administration while five separate authentication systems, codebases, monitoring stacks, test frameworks and disaster-recovery designs are not. The cost question begins at that boundary.

The objective is not consolidation for its own sake. A single global operator could create a catastrophic concentration of power and failure. The objective is to identify repeated technical work, test its cost, and design a common substrate that preserves regional control and credible exit. That is a federated architecture rather than a merger.

The public accounts do not form a global ledger

Any claim about the “cost of five back offices” should begin by refusing a false total. The RIRs report in different currencies, use different financial years and classifications, and draw different boundaries around programmes, foundations, investments and shared work. A dollar at ARIN is not a dollar-equivalent line at APNIC without an exchange-rate convention. A personnel category in one report may include costs that another places under programmes or contractors.

The most defensible 2024 comparison keeps each account in its native currency and labels its accounting basis.

Registry 2024 published expense envelope used here Currency and qualification
RIPE NCC 36.274 million EUR, reported total expenditure in the 2025 comparative account
ARIN 30.300 million USD, reported operating expenses
APNIC 33.466 million AUD, sum of listed audited expense lines; not presented here as a separately labelled single total
LACNIC 11.274 million USD, reported operating expenses
AFRINIC no comparable total used Reviewed disclosure supplies sub-lines, including remote-site and computer expense, but not a denominator safe to join to this table

The figures come from official audited or financial reporting, but the table is not an audit consolidation. RIPE NCC's 2024 amount is a comparative figure in its 2025 financial report. ARIN's amount comes from its 2024 financial presentation. APNIC's amount is arithmetic across expense lines in its 2024 audited financial report. LACNIC's amount comes from its 2024 independent auditor's report.

AFRINIC's omission from the envelope comparison is substantive, not cosmetic. Its 2024 finance disclosure identifies USD 122,311 for remote sites and USD 97,678 for computers, among other expense sub-lines, but the reviewed page does not provide a total operating-expense figure on a basis that can be treated as the fifth equivalent denominator. Inserting an estimate would create the appearance of completeness at the cost of accuracy.

The missing common ledger is itself a governance defect. The RIR system asks members and the wider Internet to trust that regional duplication produces value, yet it does not publish a reconciled map of what is duplicated, shared or unique. A global comparison should not require outsiders to reverse-engineer five accounting taxonomies.

Member counts cannot manufacture comparability

Dividing each expense envelope by members may appear to solve the scale problem. It can instead compound it. An RIR “member,” “customer,” “service member,” “LIR account” or fee-paying organisation is not necessarily the same unit. One legal entity can hold multiple accounts within a region. A multinational group can have relationships with multiple RIRs. Some end users receive services under categories that do not correspond to an LIR. Year-end counts ignore opening and closure dates.

Adding regional counts and calling the sum “global members” would therefore double-count some organisations and combine unlike definitions. Dividing native-currency expenditure by that total would add a currency error to a denominator error. Even a per-member figure within one RIR must state whether it uses organisations, accounts, invoices, paying member-months or eligible voters.

Member counts remain useful inside a registry when definitions are stable. They can reveal whether a fixed platform cost is being spread over a growing or shrinking payer base. They can also test distribution among fee cohorts. They should not be used to claim that one region is efficient because its unadjusted expense per reported member is lower than another's.

Workload denominators are also imperfect. A transfer can require more legal and identity work than a routine IPv6 allocation. A registry with a larger legacy database may carry more data-quality work. Language coverage, sanctions exposure, fraud attempts and payment infrastructure differ. Comparing raw ticket counts would reward shallow handling and penalise difficult environments.

The correct comparison is functional. What does each RIR spend to provide a defined service level for authentication, registry data, RPKI, transfer validation, billing, member support, governance and continuity? Which costs are direct, shared and regional? Which outcomes—availability, accuracy, completion time, fraud detection, recovery and user satisfaction—were achieved? That account can preserve regional difference without surrendering comparability.

Expense envelopes reveal scale, not duplication

The four comparable envelopes show that the question is material. They do not identify which share can be shared. Personnel dominates several accounts. ARIN reported USD 20.9 million of salaries and benefits within USD 30.3 million of operating expenses and an average of 102 employees. RIPE NCC reported EUR 24.321 million of personnel expense in 2025, 62% of total expenditure. APNIC reported AUD 20.072 million of employee-benefit expense in 2024. LACNIC reported USD 5.527 million of salaries and personnel expense.

People are not automatically back-office duplication. Hostmasters, community staff, legal advisers, trainers, engineers and executives perform different work. Local-language support and member governance cannot be replaced by a shared database. A software team maintaining a region-specific stack may be more duplicable than a staff member resolving a local corporate transfer, but even software carries institutional knowledge and security responsibility.

Technology labels are not directly comparable either. ARIN reported USD 4.0 million for engineering operations in 2024. RIPE NCC reported EUR 3.177 million of information-technology expense in 2025, but substantial engineering labour sits in personnel and organisational activity categories. LACNIC reported USD 402,525 of information-technology maintenance in 2024, while other technical labour and depreciation appear elsewhere. AFRINIC's computer and remote-site lines total USD 219,989, but they cannot represent its complete technical cost.

A comparison based only on those labels would produce a misleadingly low duplication estimate for organisations that employ engineers directly and a high estimate for those using suppliers. The accounting must follow function across payroll, contractor, cloud, licence, depreciation, facility and shared-service lines.

This is why an addressable-cost range is more honest than a claim that “five systems cost five times one system.” Some functions genuinely repeat. Some are regional. Some common obligations already share standards while implementation remains separate. Some diversity is deliberate resilience. The cost account must identify each class before savings are claimed.

A sensitivity range identifies the missing fact

In the absence of a functional ledger, assume that 5%, 10% or 15% of each comparable 2024 expense envelope is potentially addressable by common infrastructure or procurement. Applying those shares produces the following native-currency pools.

Registry 5% sensitivity 10% sensitivity 15% sensitivity
RIPE NCC EUR 1.814m EUR 3.627m EUR 5.441m
ARIN USD 1.515m USD 3.030m USD 4.545m
APNIC AUD 1.673m AUD 3.347m AUD 5.020m
LACNIC USD 0.564m USD 1.127m USD 1.691m

These values are not projected savings. “Addressable” means only that the amount is used to test the scale of functions that might be delivered differently. A common platform has its own staff, hosting, assurance, support and governance. Migration requires parallel operation. Regional adapters remain. Contracts may carry exit cost. Security hardening can increase expenditure before it lowers it.

If, for illustration, a mature common service cost half of the addressable pool and transition amortisation consumed a further 20% during early years, the initial net reduction would be 30% of the pool, not 100%. A 10% addressable share would then imply a 3% envelope effect. That is a scenario, not a forecast; the central cost and transition share could be higher or lower.

The sensitivity has two purposes. First, it prevents advocates from presenting every regional expense as removable duplication. Second, it prevents incumbents from dismissing shared services as financially trivial without publishing the addressable share. At RIPE NCC, even the 5% pool is EUR 1.814 million. At ARIN it is USD 1.515 million. Those amounts are large enough to merit evidence.

AFRINIC should not be forced into the table through speculation. Its disclosed USD 219,989 for remote sites and computers is a minimum visible pair of infrastructure lines, not a full addressable-cost pool and not a savings estimate. A common ledger should establish the missing denominator before a five-region scenario is stated.

What must remain regional

The back office cannot be separated from rights administration by drawing a line around “technology.” Software implements legal and policy choices. Authentication determines who can control resources. A transfer process encodes evidence requirements. A billing hold can affect access. A certification action can alter routing signals. Regional authority must therefore control the rules and contested decisions even when common software executes them.

At least seven functions should remain regionally accountable.

Contracts and membership status. The legal relationship, eligibility rules and remedies arise under a regional institution's documents and governing law.

Identity and corporate change. Mergers, insolvency, succession and authority documents vary by jurisdiction. Common tools can collect evidence, but a regional decision-maker must remain answerable for acceptance.

Disputes and sanctions. A rights-affecting hold, denial, revocation or transfer challenge requires local legal competence, reasons and appeal.

Billing and payment. Currency, tax, banking access, local affordability and collection law differ. A single global invoice engine should not determine regional fee policy.

Language and service access. Translation is not a cosmetic layer when members must understand obligations, cure defects or vote.

Member governance. Elections, General Meetings, budgets, policy participation and removal mechanisms must remain attached to the members whose institution is acting.

Regional risk choice. Members may prefer a more expensive control, data location or continuity arrangement because their threat and legal environments differ. A common operator must not erase that choice.

These retained functions are not an excuse for five complete stacks. They define the regional edge that a common substrate must serve. Each RIR can own policy, adjudication and member relationships while using certified shared components beneath them.

What can plausibly share a substrate

The strongest candidates are functions where interoperability is already mandatory and regional variation creates little public value.

Common data models and APIs. Registry data, RDAP responses, delegated statistics and transfer messages should conform to shared schemas. Separate implementations can remain, but maintaining five divergent validators and test suites adds little accountability.

Conformance and release testing. A common suite can verify that each implementation preserves uniqueness, authentication boundaries, RPKI rules, transfer states and public interfaces. Regions can add local tests without rebuilding the core.

Escrowed event logs and recovery evidence. Standardised, tamper-evident logs can support independent audit and continuity. The data need not be placed under one operational controller; replicated custody and threshold access can preserve regional authority.

Backup, restore and disaster-recovery tooling. Regions should retain independent copies and the ability to operate, but common recovery formats, drills and failover contracts can reduce reinvention and make mutual aid possible.

Inter-RIR transfer validation. Cross-region transfers require both institutions to agree on state. A shared message protocol, case status and cryptographic evidence layer can reduce manual reconciliation without deciding the legal merits.

Security controls. Authentication libraries, hardware-key support, vulnerability handling, dependency scanning and incident playbooks can be developed and assured jointly while credentials and final authority remain regional.

The IANA interface. Requests for top-level number-resource allocations and reverse-DNS changes already cross a global boundary. Standard request packages, status evidence and reconciliation can be shared.

Commodity procurement. Monitoring, code hosting, security testing, content delivery and some licences may produce purchasing leverage without centralising rights.

The criterion is not whether a function is technical. It is whether regional divergence creates accountable choice or merely repeated cost and inconsistent risk.

IANA demonstrates a thin global layer, not a replacement registry

IANA's number-resources service maintains the top-level allocation relationship among the global pool and the RIRs. Its allocation data and published request procedure show a bounded interface: RIRs submit defined requests, IANA evaluates them under policy and updates authoritative records. Monthly performance reporting publishes service-level results.

This arrangement proves that a thin global coordination layer can operate without absorbing regional member relations. IANA does not invoice every LIR, adjudicate every merger, run every regional election or provide every local training programme. It coordinates the root of the number-resource system.

The lesson should not be stretched. IANA's low request volume at a particular time does not show that it could cheaply become the world's retail registry. Regional records and identity work are far larger. Nor does a service-level agreement remove the need for political accountability at the global layer.

The relevant design principle is bounded authority. A shared RIR substrate should have a precise technical mandate, measurable service levels and no power to set regional fees or decide contested rights. Its interfaces should be open enough that a region can leave without reconstructing its history from an opaque vendor database.

The 2016 IANA Numbering Services SLA offers another useful principle: service, reporting, review and termination can be expressed contractually among institutions. A future common platform needs an equally explicit agreement, but with stronger provisions for source access, data portability, security incidents and regional continuity.

Existing cooperation is too thin to answer the cost question

The Number Resource Organization already coordinates the RIRs. It supports joint positions, the Address Supporting Organization relationship with ICANN, shared projects and some common expenses. That cooperation refutes the idea that every shared mechanism would be institutionally alien.

It does not provide a full service-cost ledger. An NRO expense contribution says little about the engineering and administrative functions that remain separately funded. The 2024 NRO Executive Council record notes that common expenses were divided among four RIRs because of AFRINIC's condition. The record illustrates joint financing and the governance difficulty created when one region cannot participate normally; it does not quantify the duplicated back offices.

Cooperation can also become a shield. A joint committee or standard may be cited as evidence of efficiency while each region still maintains its own implementation, suppliers and assurance. Conversely, separate implementations may be valuable if they prevent one software defect from affecting the world. The public needs a component map, not a binary label of “shared” or “regional.”

For each major capability, the map should state: common standard, common code, common operator, common procurement, reciprocal backup, independent implementation or region-specific function. It should show annual full cost and the reason for the chosen degree of separation. That would turn architectural diversity into an accountable decision.

Diversity has an insurance value

Five implementations can prevent correlated failure. A vulnerability, operational mistake or governance capture in one region need not disable the others. Separate suppliers and codebases can reveal assumptions through comparison. Regional staff can continue service when another institution is in litigation or loses leadership.

That insurance is real, but diversity must be designed to produce it. Five systems built from the same vulnerable dependency, hosted by the same cloud provider and administered through similar credentials can appear independent while failing together. Five incompatible systems with no tested portability can make a regional collapse harder to repair.

The resilience account should therefore measure fault domains. Code lineage, hosting, identity providers, key-management hardware, network transit, critical suppliers, jurisdiction and privileged access should be mapped. A common component should have multiple operators or reproducible deployment where concentration would be dangerous. Regional copies should be tested for recovery rather than assumed to work.

Shared infrastructure can improve diversity if it provides a portable reference implementation while allowing independent operation. It can also weaken diversity if one central team controls production for all regions. The desired architecture separates common engineering from common failure.

Members should be shown the price of that insurance. If independent implementation costs an additional amount, the report should state the failure scenario it mitigates and the evidence that independence is genuine. “Regional autonomy” should not be a ceremonial label attached to identical dependencies.

A shared service needs stronger governance than a vendor contract

Centralising a component changes power. The common operator can become indispensable to five regions, giving its management leverage that no individual RIR member can easily challenge. A procurement saving can therefore create a governance liability.

The service should be constituted around limits. Ownership could be joint, but no single RIR should control it. Board representation should not be the only accountability mechanism because five institutions can collectively protect their supplier. Technical performance, security incidents, related-party transactions, executive pay and cost allocation should be publicly reported.

Regional customers need enforceable exit. Data and logs must be exportable in documented formats. Source code or reproducible alternatives must be available under escrow or open licensing for critical components. A region should be able to operate a recent version independently while migrating. Termination should not interrupt authoritative service.

Cost allocation also needs a rule. Equal fifths may burden smaller regions. Allocation by reported members can be gamed by definitions. Allocation by transactions may undercharge regions with large fixed-state complexity. A blended formula could use a common base, resource records, active accounts, transaction load and ability-to-pay adjustment, with sensitivity disclosure.

Disputes between the platform and a region should not be resolved solely by the other RIR executives. Independent technical arbitration and a continuity protocol are needed. Rights-affecting action must remain with the region, while service-performance disputes can be judged against the common contract.

The standard should be higher than ordinary outsourcing because the service supports globally unique public infrastructure. Cheap centralisation without portability would exchange five cost centres for one monopoly.

Portability can create competition without fragmenting uniqueness

The most useful alternative to both five closed stacks and one monopoly is accredited portability. A region could select among certified operators or operate a component itself, provided each implementation passes common conformance, security, continuity and data-portability tests.

The authoritative policy and rights decision would remain regional. The technical service provider would execute under a bounded contract. Switching providers would not change who owns a resource or which member body governs the relationship. A common event format and reconciliation layer would preserve global uniqueness.

Competition would expose cost. If an incumbent regional implementation is efficient and responsive, it can remain. If a common operator can provide a better service at lower full cost, members can see the comparison. If a provider fails, another can reconstruct state from escrowed data and logs.

Portability must not become unregulated privatisation. Providers would require strict conflict rules, independent audit, incident disclosure, staff screening and restrictions on secondary use of registry data. They should not use operational dependence to sell unrelated services to resource holders. Accreditation should be revocable without endangering continuity.

Open interfaces also enable smaller improvements. A region might share only the test platform and recovery tooling while retaining its registry application. Another might adopt a common RPKI component. Evidence can accumulate component by component instead of forcing a dangerous “big bang” migration.

This modularity changes the debate from ideology to performance. The question becomes whether a defined component meets service, cost and control thresholds, not whether regionalism or centralism is morally superior.

The transition bill must be disclosed before the savings

Shared-service proposals often compare the mature common system with the full current cost and omit transition. That is the easiest way to create fictional savings.

Migration requires inventory, data cleaning, interface adaptation, security review, legal analysis, staff training and parallel operation. Existing contracts may have termination cost. Legacy systems may need to remain read-only for audit. A common platform must support the most complex regional case, not an idealised average. Staff knowledge can be lost before the replacement is stable.

The business case should publish at least three phases: build and assurance; parallel run and migration; mature operation. Each phase should show regional and central FTE, supplier cost, contingency, decommissioning, service risk and the date when net benefit is expected. Benefits should be discounted and tested under delay, lower adoption and higher security cost.

No staff saving should be counted merely because a position is labelled duplicative. Local integration, oversight and rights administration remain. Savings require an actual removal or redeployment decision. If released staff are moved into new programmes, that may create value but it is not a cash saving.

The business case should also include the cost of exit and failure. A cheap platform that cannot be replaced may carry a larger long-term liability than separate systems. A continuity reserve, tested independent deployment and contractual step-in rights are part of full cost.

A five-RIR functional ledger is the first reform

Before selecting architecture, the RIRs should publish a common functional ledger for at least three years. It would not replace audited accounts. It would restate them into comparable service families.

The ledger should cover registry data and RDAP; resource requests and transfers; RPKI; authentication; billing; member support; policy and governance; training and engagement; measurement and research; security and continuity; legal and compliance; and corporate overhead. For each, it should identify direct FTE, contractors, technology, facilities, allocated overhead, workload units and outcomes.

Definitions should be common and regional exceptions explicit. The report should reconcile back to each audited account in native currency. A separate exchange-rate appendix can offer converted scenarios using average and closing rates, but native figures should remain primary. Purchasing-power comparisons may inform affordability, not replace cash accounts.

Member denominators should be published in several forms: unique legal organisations where known, active accounts, paying account-months and fee cohorts. Cross-region duplicates should be estimated only through a privacy-preserving method and reported as a range. No global per-member figure should appear until the denominator is reconciled.

The ledger should identify current sharing. If two RIRs use common code, joint procurement or reciprocal recovery, the cost and service effect should be visible. If separate implementation is retained for resilience, the fault domain and tested benefit should be stated.

With that evidence, members can debate a 5%, 10% or 15% addressable share using actual functions rather than intuition. The uncertainty range narrows through disclosure, not rhetorical confidence.

Regional members must authorise the bargain separately

A joint platform cannot be legitimate merely because five executives agree. Each membership carries different cost, risk and control. A region with a modern low-cost stack may subsidise regions with expensive legacy systems. A small registry may gain resilience but fear domination by larger contributors. A region under institutional stress may need continuity support while being unable to exercise normal governance.

Each RIR should therefore present the same business case in a locally intelligible form and obtain member authority under its own rules. The vote should specify components, cost-allocation formula, governance rights, data location, performance thresholds, exit and review date. Approval of “cooperation” in principle is too broad.

Minority protections matter. A contributing region should not be trapped by a four-to-one decision that materially changes its rights. Nor should one region veto security patches needed by all. The agreement can distinguish ordinary operational decisions, supermajority constitutional decisions and unilateral regional exit.

Members should also see who loses institutionally. Shared systems can reduce executive scope, local engineering discretion and supplier relationships. Those interests do not invalidate the proposal, but they create incentives that should be disclosed. Independent review is particularly important when the people recommending consolidation or separation control the budgets affected.

The bargain should be revisited after evidence exists. A five-year term with annual service reporting and a third-year independent review would permit investment without creating permanence. Components that fail the cost or control test can return to regional operation.

The target is thin coordination with thick accountability

Internet number resources need a thin global coordination layer: enough shared state and protocol to preserve uniqueness, verify transitions and recover service. They need thick accountability wherever an institution interprets rights, collects money, resolves disputes or sets priorities.

The present system can invert that principle. Technical implementations may be thickly duplicated, while members receive thin comparative accounts of cost and performance. Regional institutions defend autonomy at the software layer but may offer limited choice at the budget layer.

A better design would make common machinery boring and contestable. Data formats, test suites, logs, recovery packages and security controls would be standardised, assured and portable. Regional institutions would compete on accountable service: clear decisions, fair fees, local access, rights protection, operating competence and member control.

This does not assume that every shared component will save money. Some common controls may be worth adopting because they improve security or continuity at the same cost. Some separate systems may deserve retention because they create genuine fault isolation. The decision rule is full public value, not minimum expenditure.

The audited envelopes establish only the scale of the opportunity to ask. At 5%, the addressable pools are already material. At 15%, they are strategic. The absence of a comparable AFRINIC denominator and common service taxonomy prevents an honest global total. That uncertainty should trigger disclosure, not invented precision.

Five regional institutions can remain guardians of regional rights without treating five back offices as an article of faith. The burden should reverse: before members fund another separate rebuild, the registry should show why independence at that component creates more resilience, accountability or value than a portable shared service. Before members approve centralisation, the proposed operator should show that common cost will not become common control.

A pilot should test portability before consolidation

The first shared-service experiment should not touch final resource authority. It should select a component whose failure is reversible and whose performance can be measured across regions. A common conformance-and-recovery platform is a stronger candidate than a single production registry application.

Each RIR could submit anonymised or synthetic versions of its critical case paths to a shared test suite: account recovery, corporate change, transfer state, RPKI issuance, RDAP publication, delegated statistics and backup restoration. The suite would verify common invariants while preserving regional policy branches. Results could be published as pass rates, remediation times and unresolved divergence without exposing credentials or sensitive cases.

The second phase could standardise export and replay. Each region would produce a signed, documented package containing the state needed to reconstruct an authoritative service at a defined point. An independently operated environment would restore the package under controlled conditions. The test would measure completeness, time to service, manual intervention, undocumented dependencies and whether the region could validate the reconstructed result.

That exercise would create value even if no production service were consolidated. It would expose hidden lock-in, weak documentation and incompatible state models. It would also establish the portability required for future competition. Members would gain continuity evidence rather than a promise that backups exist.

Only after those controls worked should the RIRs pilot a common production component. Inter-RIR transfer messaging is a plausible choice because both sides already need a shared view of case state while retaining authority over their own approval. The pilot could cover a limited set of transfers, run beside existing channels and stop automatically if reconciliation fails. No common operator would be able to approve a transfer; it would only carry signed evidence and status.

The pilot account should disclose full cost. Regional staff time, central engineering, assurance, procurement, legal work, parallel operation and incident response all belong in the denominator. Reported benefit should include fewer manual reconciliations, shorter elapsed time, lower error, stronger evidence and recovery capability—not only cash savings.

Success thresholds should be set before launch. A component should proceed only if it meets service availability, security, portability, cost and regional-control thresholds for a sustained period. A cheaper component that weakens exit should fail. A more expensive component may pass if it delivers a material and authorised resilience gain, but the account must state that the return is resilience rather than savings.

The pilot should also include a forced exit. One participating region would invoke the documented transition to its independent implementation using the shared export, while other regions continue service. This is the only credible test of whether portability is a right or a clause. After restoration, records, signatures and public interfaces should reconcile without the former provider's discretionary assistance.

Staff and member experience should be assessed separately. Engineers may face simpler maintenance while rights staff encounter awkward local exceptions. Members may receive faster service but less intelligible reasons. A technical pass cannot compensate for a weaker route of challenge. The regional body remains responsible for the whole service even when a common operator performs a component.

Procurement should prevent the pilot winner from becoming the permanent provider by default. The specification, interfaces and test suite should remain available to qualified alternatives. Any extension should require a fresh cost comparison and member decision. Intellectual property created with member money should not create a toll gate against those members.

This sequence—common tests, proven restoration, bounded messaging, forced exit—answers the most important question before institutional stakes rise. Can the RIRs share machinery while preserving independent authority and recovery? If the answer is no at a small scale, a global platform should not proceed. If the answer is yes, members will have evidence strong enough to challenge the cost of the next five separate implementations.

Cost comparison must include service quality and rights risk

Lowest cost is an incomplete procurement rule for authoritative infrastructure. A regional system may cost more because it supports a language, payment channel or appeal route that a common service would neglect. A shared service may cost less while increasing recovery time or concentrating privileged access. Those differences need a common valuation frame.

The comparison should report a financial result and four non-financial accounts. The service account covers availability, latency, completion time, defect rate and support. The security account covers identity assurance, privileged access, vulnerabilities, incidents and recovery. The rights account covers reasons, appeal, portability, data protection and the ability of the regional institution to override or stop an automated action. The resilience account covers supplier concentration, independent deployment, restored-state tests and correlated failure.

Each account should use thresholds rather than a decorative score. A proposal that fails a critical rights or continuity threshold should not be rescued by a favourable weighted average. Within the acceptable set, members can compare full cost and incremental benefit. This prevents an inexpensive but captive platform from appearing efficient merely because the future exit bill is outside the spreadsheet.

Uncertainty should be explicit. Supplier prices, migration duration, security requirements and regional adoption will change. The business case should show ranges and identify which assumption produces the claimed advantage. If benefit disappears when migration takes six months longer, members should know that before approval. If common assurance becomes cheaper only after all five regions join, the dependence on full adoption should be stated.

The same method disciplines the defence of separate systems. A region that claims autonomy benefit should identify the independent fault domain, tested exit and rights advantage it obtains for the extra cost. Paying twice for nominal independence while sharing the same cloud, identity provider and untested backup is not resilience.

Comparative governance is therefore the real product of the ledger. It gives each regional membership the evidence to choose where separation is worth its price and where repetition survives only because no one has been required to account for it.

Sources and method

The native-currency expense envelopes use RIPE NCC's Financial Report 2025 for the 2024 comparative expenditure, ARIN's 2024 financial presentation, APNIC's audited 2024 financial report, LACNIC's 2024 independent auditor's report and AFRINIC's 2024 finance disclosure. The APNIC amount is the arithmetic sum of the listed expense lines; it is labelled accordingly rather than represented as a separately printed total.

The discussion of the global coordination layer uses IANA's official number-resources overview, allocation data, request procedure and performance report, together with the NRO's 2016 IANA Numbering Services SLA. The 5%, 10% and 15% addressable-cost cases and the illustrative transition case are sensitivities, not forecasts. No cross-currency total, global member count, realised saving or AFRINIC full-expense estimate is asserted.