The Settlement Computer is FiatRails' institutional settlement infrastructure suite for bringing multilateral netting to cross-border flows, tokenised asset settlement, stablecoin obligations, and emerging digital currency rails that currently settle largely on a gross basis.
Five of the eight product surfaces are now live on testnet on a custom Avalanche L1. The testnet demonstrates shared netting, ISO 20022 message generation, Travel Rule data capture, multi-source peg verification, risk analytics, and corridor-level settlement configuration.
This article is a status update. It explains what is operating on testnet today, what remains in design, how the shared-chain architecture supports cross-product netting, and where regulatory engagement sits.
Product status at a glance
| Product | Status | Function |
|---|---|---|
| Settlement | Live on testnet | Cross-border multilateral netting |
| PayNet | Live on testnet | Retail / mobile flow aggregation into ISO 20022 settlement messages |
| RiskNet | Live on testnet | Protocol-native risk analytics and admission control |
| AssetNet | Live on testnet | Tokenised asset DVP obligation compression |
| StableNet | Live on testnet | Stablecoin obligation netting and peg / rule checks |
| Trade | In design | Trade finance obligation netting |
| Grid | In design | Energy settlement netting |
| Nexus | In design | Agentic clearing for autonomous economic agents |
Why one chain, multiple products
The Settlement Computer runs as a single multi-tenant Avalanche L1 with eleven consensus-level precompiles. Every product on the chain shares the same netting engine, compliance gate, peg oracle, and settlement state machine — but operates within isolated corridors with per-corridor configuration, role-based access control, and supervisory observability.
The reason the architecture is multi-tenant rather than per-product is that institutional flows do not respect product boundaries. A bank settling cross-border FX obligations is also settling tokenised asset DVP, also settling stablecoin obligations to its retail customers, also receiving micro-transaction aggregations from mobile money corridors. If each of those flows runs on a separate chain or settlement network, the bank captures only the compression available within each silo. If they run on a shared netting layer, cross-product offsets become available.
The shared layer also delivers operational consolidation: one set of validators, one compliance framework, one set of supervisory access controls. Institutional adoption is constrained by integration overhead more than by technology. One chain that handles five product surfaces is materially easier to evaluate, license, and connect to than five chains.
What is live on testnet
Settlement
Multilateral netting for cross-border institutional settlement. Eleven corridors operating on the testnet across the UAE, Africa, Asia, and Europe, with bilateral pre-netting, residual carry-forward, and cross-corridor aggregation for currencies that span multiple corridors.
Across synthetic testnet obligations, Settlement has demonstrated average compression above 91 per cent across active corridors, with cross-corridor netting layered on top to capture additional savings between corridors sharing the same currency. Future pilot reporting will publish methodology, window counts, gross notional, and corridor mix in detail. Privacy is enforced via Pedersen commitments and Bulletproofs zero-knowledge range proofs in the consensus layer, so amounts are committed homomorphically without being exposed.
Settlement is the foundation. Every other product builds on it.
PayNet
Micro-transaction aggregation with AI-powered ISO 20022 translation. PayNet ingests retail and mobile money flows — formats that are not natively settlement-eligible — and translates them into CBPR+-compatible pacs.008 messages that can enter the multilateral netting engine.
PayNet's role is not to replace mobile money. It converts fragmented retail-originated obligations into settlement-eligible institutional messages. Tens of thousands of obligations have been processed in committed mode on the testnet, with the translation pipeline running continuously and producing high cache hit rates against repeated message structures.
The product addresses one of the structural reasons institutional netting infrastructure has not reached emerging market corridors: the originating flows are formatted for retail rails, not interbank rails, and the translation layer between the two is the bottleneck.
RiskNet
Protocol-native risk analytics and closed-loop admission control. RiskNet applies network-science and stress-testing models to determine whether an obligation should be admitted, reduced, held, or rejected before it enters a settlement window.
Twenty-five algorithms run on the testnet every thirty seconds across all active corridors, computing counterparty risk scores, corridor concentration metrics, network and systemic risk measures, and stress test outcomes (technical models include DebtRank, multiplex DebtRank, K-shell decomposition, graph centrality, Cover-2, Cover-3, and reverse stress). The output drives a four-band admission decision per obligation: FULL_ADMIT, REDUCED, HOLD, or REJECT.
RiskNet's distinction from traditional settlement risk monitoring is granularity. Existing settlement infrastructures score risk at the member or portfolio level. RiskNet scores at the counterparty-corridor-window level, drawing on data only the protocol itself can see — the difference between gross and net obligations, the historical compression pattern of each corridor, and the bilateral exposure structure across the participant graph.
The platform is designed to support BCBS 248-style intraday liquidity reporting and PFMI-aligned risk monitoring, producing structured risk data outputs that align with supervisory reporting expectations.
AssetNet
Multilateral netting for tokenised financial assets with atomic delivery-versus-payment compression. AssetNet handles paired DVP obligations — cash and asset legs together — and finds offsets across counterparties while preserving atomic settlement guarantees on each pair.
Five tokenised asset corridors are operating on the testnet, named after major tokenised US Treasury and money market fund instruments active in institutional digital asset markets — BUIDL, OUSG, BENJI, USYC, and bIB01. Over one hundred thousand DVP obligations have been ingested across these testnet corridors. Several hundred netting windows have been completed. Several thousand on-chain settlement instructions have been executed.
References to BUIDL, OUSG, BENJI, USYC, and bIB01 describe supported testnet asset profiles and do not imply affiliation, endorsement, integration, or commercial relationship with the issuers or asset managers of these instruments.
The full participant taxonomy — custodians, central counterparties, market makers, broker-dealers, and asset managers — is supported with KYB Tier 3 verification, sanctions screening, and per-corridor permissioning.
Large segments of cross-border repo and tokenised collateral activity remain fragmented across venues, counterparties, and jurisdictions, without a universal cross-asset netting layer for tokenised obligations. AssetNet is designed for that gap.
StableNet
Multilateral netting for stablecoin obligations with multi-source peg verification, ISO 20022 message generation, and Travel Rule data capture. Three stablecoin corridors are operating on the testnet — USDC, XSGD, and RLUSD — with continuous synthetic obligation flow and auto-triggered settlement execution every ten minutes.
In a representative testnet window close, StableNet demonstrated compression of 4.96 to 1 — an 84 per cent capital reduction. The testnet includes twenty-two baseline compliance-rule checks mapped to sanctions screening, EU MiCA requirements, the US GENIUS Act framework and its pending implementation rules, and Singapore's stablecoin regulatory framework. Travel Rule data is structured using IVMS101-compatible fields, with AES-256-GCM at-rest encryption and RFC 6962 Merkle proofs committed on-chain per window close so that record inclusion can be verified independently.
The peg oracle uses three to five effective sources per stablecoin pair on the testnet, combining settlement-grade signed feeds (EIP-712 typed data) with public market data sources. Peg-deviation circuit breakers are enforced before netting.
Seven institutional stablecoins have issuer-risk profiles in the StableNet registry: USDC, USDT, EURC, PYUSD, XSGD, RLUSD, and USDPT.
Registry support means the testnet contains issuer-risk profiles and oracle-pair configurations for these stablecoins. It does not imply partnership, endorsement, commercial relationship, or live integration with any issuer.
What is in design
Three further products complete the eight-product Settlement Computer suite. They are scoped, the subject of provisional patent filings, and architected on the same multi-tenant chain — but build sequencing follows pilot demand:
- Trade — maturity-aware netting for trade finance. Document-anchored settlement for letters of credit, bills of lading, and documentary collections.
- Grid — energy settlement netting for electricity, gas, and distributed energy resource obligations. Circular debt resolution with time-indexed settlement windows.
- Nexus — agentic clearing for autonomous economic agents. Machine-native settlement with causal shared state, graph-derived credit pricing, and adaptive liquidity optimisation.
The design-phase products share the same precompile stack as the live products, so build time is dominated by domain-specific compliance rules, message format adapters, and pilot integration rather than core protocol work.
Cross-product netting
The architectural advantage that justifies the multi-tenant model becomes visible when obligations span products. A bank running corridors across multiple products on the Settlement Computer can have its USD-denominated obligations from Settlement (cross-border FX), AssetNet (tokenised asset cash legs), and StableNet (stablecoin payments) aggregated at the chain layer for cross-corridor netting.
This is not a future feature. The Netting precompile already supports cross-corridor aggregation by currency, and per-currency netting rounds run on the testnet across multi-corridor populations. Cross-corridor netting on the Settlement product alone has demonstrated material additional compression on top of per-corridor netting.
The same mechanism extends across products as additional product-specific obligations enter the shared netting engine. The marginal cost of running a fifth product on the chain is modest; the marginal benefit, in terms of cross-product compression, scales with how many product surfaces a participant uses.
Patent posture
The Settlement Computer architecture is the subject of seven United States provisional patent applications, comprising approximately 437 draft claims that are expected to inform corresponding non-provisional filings:
- PROV-001 — Core multilateral netting architecture
- PROV-002 — Cross-corridor netting and bilateral pre-netting with residual carry-forward
- PROV-003 — Trade finance and energy settlement variants
- PROV-004 — Agentic clearing for autonomous economic agents
- PROV-005 — Micro-transaction aggregation and ISO 20022 translation
- PROV-006 — Tokenised asset DVP netting (~106 draft claims, 26 invention families)
- PROV-007 — Digital currency netting for stablecoins and CBDCs (~44 draft claims, 17 invention families)
Filing dates have been established for all seven provisional applications, subject to conversion into non-provisional filings within the applicable deadlines. The portfolio is intended to cover the entire eight-product Settlement Computer architecture, including the cryptographic privacy layer (Pedersen commitments with homomorphic netting, AES-256-SIV metadata encryption, Bulletproofs range proofs, and Shamir's Secret Sharing key distribution) and the post-quantum-ready authentication layer (ML-DSA, the lattice-based digital signature standard specified in NIST FIPS 204).
Regulatory and compliance posture
The Settlement Computer is designed for regulatory observability rather than against it. The compliance gate enforces sanctions screening, jurisdictional rules, and stablecoin-framework alignment before any obligation enters the netting engine. The Travel Rule layer captures IVMS101-compatible data for every cross-border movement. The risk analytics layer produces structured outputs aligned with BCBS 248-style intraday liquidity reporting and PFMI-aligned risk monitoring.
Tiered view keys provide cryptographic supervisory access — regulators can be granted granular, scoped, time-bounded access to the records they are entitled to see, without exposing those records to other participants or operators. The architecture is designed to support future assessment against PFMI-style finality and operational resilience expectations, including Principle 8 (Settlement Finality) and Principle 17 (Operational Risk).
Engagement and enquiries are active across multiple jurisdictions — central bank dialogue, sandbox enquiries, and innovation hub interactions in the Middle East, Europe, and Asia-Pacific.
What comes next
Three priorities for the next phase of the Settlement Computer:
- Move from testnet to controlled pilot. Bringing real institutional flows onto the live products under supervisory observation in one or more jurisdictions. The technical platform is ready; the regulatory pathway is the gating factor.
- Activate the design-phase products in response to pilot demand. Trade, Grid, and Nexus are scoped and the subject of provisional filings. Build sequencing follows where institutional demand materialises first.
- Extend the cross-product netting story. As more product surfaces operate on the shared chain, the cross-product offsets compound. The next round of testnet metrics will quantify this directly.
The Settlement Computer is no longer only a design thesis. Five product surfaces are running on testnet, the shared netting layer is operational, and the next phase is controlled institutional validation.
The questions now move from architecture to adoption: which corridors, which participants, which supervisory pathway, and which pilot flow should come first.
Those are the conversations FiatRails is having now.
This article is part of the FiatRails Insights series on institutional settlement infrastructure.