The six modules of the 4orm platform, what each one does for a bank or dealer, where compliance actually lives, and the honest build status of every piece as of June 2026.
4orm is not a blockchain. It is a regulated institutional control plane: compliance, the canonical ledger of record, the token registry, and treasury and banking integration live off-chain inside the regulated perimeter, while the blockchain is a swappable execution surface. Ethereum and Stellar at launch, bounded interoperability later, and no chain ever a dependency.
That single architecture decision drives everything a reviewer will notice about the platform. Compliance is enforceable and auditable by a supervisor because the authoritative records sit where supervisors can examine them, not on a public chain. Issuers stay chain-portable instead of riding one chain's fate. There is no public token, so there is no crypto-market dependency and no optics problem with conservative institutions. And competitors who are the chain, Polymath being the nearest example, structurally cannot offer the same posture; the full head-to-head is document 02.5.
Token standards are policy-aware by construction: ERC-3643 and ERC-1400 aligned contracts carrying investor eligibility, transfer restrictions, and jurisdiction rules, kept portable across execution surfaces. Banking integration speaks ISO 20022, because the plumbing 4orm connects to is the plumbing banks already run.
| MODULE | WHAT IT DOES | WHO IT SERVES FIRST |
|---|---|---|
| Digital settlement network | Instant, auditable institutional transaction settlement with delivery-versus-payment finality, following the lifecycle pattern Project Samara validated | Banks and credit unions clearing institutional flows |
| Tokenized CAD deposits | Bank-issued digital deposits for institutional use (DepositToken-CAD): a regulated deposit instrument under OSFI Group 1a treatment, deliberately not a stablecoin | Deposit-taking institutions; the wedge product |
| RWA issuance and registry | Native tokenization of registrable claims with the smart-contract registry, holder records, and audit trail regulators expect | Issuers and the dealers who bring them |
| Tokenized collateral engine | Real-time collateralization and margin efficiency against tokenized positions, releasing the buffers multi-day settlement forces institutions to hold | Treasury and lending desks |
| Regulated RWA marketplace | Secondary liquidity for institutional tokenized assets inside the eligibility and transfer rules the control plane enforces | The whole network; the layer no Canadian venue offers today |
| Trust and estate digitization | Digital representation of trust and estate holdings, bringing administratively heavy claims onto the same registry and settlement rails | Trust companies and advisory channels |
The compliance engine, the onboarding and issuer workflow, the token registry, the canonical ledger of record, treasury integration, allocation logic, and the supervisory-reporting layer are the revenue center and the moat together. They are never licensed, mirrored, or delegated to a chain or platform partner. Execution surfaces are interchangeable; the control plane is not.
This data room marks status plainly, and the product is no exception. What exists today: the institutional architecture, independently reviewed at 7.5/10 on architecture fit and 8.5/10 on strategic fit; a live interactive demo simulating 191 institutions through tokenization, lifecycle, and settlement (document 03.4 and the Demo Exchange site); the integration and security frameworks scoped; and the three-phase engineering build contracted to SPEER Technologies with full IP ownership.
What does not exist yet: shipped production code. The MVP build begins at the close of the Pre-Seed, by design rather than by delay, scoped to the deposit-token pilot with a single lead institution. The sequencing logic, gates, and the twelve-month path from foundation to production are documents 03.5 and 03.6; the build economics are itemized in 05.5; and the risks that attach to a pre-production platform are stated with their controls in 10.4.
| COMPONENT | EVIDENCE | STATUS |
|---|---|---|
| Institutional architecture | Independent review scores; Samara-pattern settlement design | VALIDATED |
| Interactive demo | Live, simulating 191 institutions end to end | LIVE |
| Engineering engagement | SPEER three-phase contract, rates in Schedule A | CONTRACTED |
| Custody and compliance design | Built against the CIRO framework; HoldCo / OpCo / CustodyCo separation | DESIGNED |
| Production MVP | Deposit-token pilot scope; build gated to the close | POST-CLOSE |
Sources: the 4orm institutional architecture review; the live Demo Exchange walkthrough; the February 2026 pitch deck (document 01.1) for the six-module framing; the 4orm-SPEER partnership agreement (economics in 05.5); CIRO Digital Asset Custody Framework (February 2026); documents 02.5, 03.5, 03.6, and 10.4 of this data room for the competitive, sequencing, and risk detail.
Prepared for approved data room members. This document does not constitute an offer to sell securities or a solicitation of an offer to buy securities. 4orm Finance Holdings Inc. is the parent entity of 4orm OpCo, 4ormEx OpCo, and 4orm Trust Co; technology is developed by KCS Capital, an independent research and development firm.