Two rails. One balance sheet. Always on.
An indicative view of how QNTM is being designed to coordinate fiat and stablecoin settlement, structured compliance records, and supervisory visibility within one governed operating layer.
The Settlement Engine
Diagram: Rail A (Red) and Rail B (Green), connected by the Bridge (Blue).
Rail A — Fiat
Faster Payments, SEPA, SWIFT, ISO 20022. GBP / EUR / USD on regulated correspondent rails. The conventional banking surface, operated to UK PRA + FCA standards.
Rail B — Tokenised
Stablecoins (regulated perimeter) and tokenised RWA (originated by AGENTZ and other partners). Atomic settlement with Rail A. Authorisation-first by design — every Rail B activity classified + approved per jurisdiction.
The 5-Layer Control Stack
Policy / Real-Time Accounting / Treasury / Compliance / Evidence. Wired into both rails — not bolted on. Policy before execution. Always. Supervisor-readable, auditor-readable, customer-readable on the same evidence trail.
Multi-Agent Consensus - Settlement Governance
QNTM is being designed around consensus across independent control layers before regulated execution. The goal is structural enforcement, not procedural sign-off.
Step 1 - Proposal
The target model begins by receiving and structuring a transaction request, whether that request originates from a client instruction, an API call, or an authorised automated treasury workflow.
Step 2 - Compliance Validation
The intended compliance layer validates the proposal against the institution's policy record, the applicable legal and regulatory ruleset, and the transacting party's mandate parameters. The design goal is that regulated execution does not proceed without successful validation, and that failed validations produce a structured reason code.
Step 3 - Execution
The execution layer is intended to release an instruction only after the required settlement and policy approvals are present, with the approval chain committed to the event record before external transmission.
Human Governance
Material transactions and enhanced-scrutiny cases are intended to route to designated human officers based on mandate and policy thresholds configured with each institution. The model is not being designed for unilateral execution in those cases.
The Compliance Metadata Tag
The target operating model assigns each regulated transaction a structured compliance record containing identifiers and timestamps, initiating party and mandate references, routing context, policy-decision outputs, screening metadata, human-review flags where applicable, and an event-ledger reference.
The design intent is for this record to be committed before execution and made available to authorised operators, compliance reviewers, and supervisory parties where the regulatory relationship requires it.
The Canonical Event Ledger
The target model uses an append-only event ledger as the reconstruction layer for transaction history, policy validations, and system state changes. It is intended to serve as the primary record for account states, positions, and compliance decisions across the QNTM operating environment.
Observer Agent - Planned Supervisory Interface
The Observer Agent is being designed as a provisioned, read-only interface for authorised oversight bodies and internal control teams. The intended scope includes balance visibility, compliance-record access, reserve and reconciliation views where applicable, and system-health indicators.
This is the supervisory model QNTM is being built toward, not a statement that continuous regulatory interfaces are already live today.
Specific authorities, access scopes, and delivery methods depend on authorisation, jurisdiction, and the supervisory relationships established over time.
The 5-Layer Control Stack
Every transaction routed through the QNTM platform passes the 5-Layer Control Stack before settlement. No exception lanes. No bypass. The control stack is not a wrapper around the rails — it is the rails. Supervisors, auditors and customers see the same evidence trail.
L1 — Policy & Authorisation
Pre-execution policy gate. Risk limits, jurisdictional rules, signer authority, scope of mandate. No transaction enters the rails without an authorisation receipt.
L2 — Real-Time Accounting
Double-entry ledger update concurrent with execution. No batch-settlement lag. The ledger is the source of truth, not an after-the-fact reconciliation.
L3 — Treasury & Liquidity
Real-time treasury position, liquidity metrics, intraday capital. ICAAP / ILAAP-grade rigour from Day Zero of Phase 2.
L4 — Compliance & AML
Continuous transaction screening — sanctions, PEP, behavioural anomaly. SAR-ready evidence trail. AML model versioning, not snapshots.
L5 — Evidence & Audit Trail
Immutable per-transaction evidence store. Regulator-readable, auditor-readable, customer-readable. Every decision carries policy receipts and ledger anchors.
Agentic interface (above all five)
Programmable banking primitives. Every API response carries policy-decision metadata so an autonomous agent can answer 'why did you do that' at human and machine fidelity.
Security Architecture
The production design is intended to use HSM-managed keys for settlement instructions and ledger events, isolated execution environments for critical control components, and mutually authenticated external connections. Final controls will be documented in the security and due-diligence materials shared with qualified counterparties.