The first question a risk and compliance lead asks isn't "how fast?", it's "what controls govern this, who holds the assets, and what happens when something goes wrong?" The regulated controls stay with the institution; the blockchain is only an execution surface underneath.
"What we hear from Canadian risk leads: the question isn't "is this safe," it's "where does the accountability sit when something goes wrong." That's the question this page is built to answer.
4orm does not replace your compliance function. It removes the duplicate work between your compliance function and every other Canadian institution's compliance function. Below: every responsibility that stays in your hands, paired with the specific mechanism we change. You stay accountable. We make accountability cheaper.
When a customer walks into your branch, you do the full KYC (know your customer), identity verification, beneficial ownership, source of funds, PEP (politically exposed person) screening. PCMLTFA (the Proceeds of Crime, Money Laundering and Terrorist Financing Act) puts that responsibility on you. That responsibility does not move to 4orm.
Your verified result is stored as a cryptographically-signed credential attested by the issuing institution. When that customer transacts with a different Canadian institution on 4orm, the receiving institution relies on the credential under a PCMLTFA reliance-on-identification framework (PCMLTFR s. 105 / FINTRAC Guidance on identification by another reporting entity): the receiving institution still satisfies itself that the verification meets statutory requirements through a written agreement with the originating institution, ongoing access to underlying records, and re-validation where its own risk-based assessment requires it. The duplicate KYC labour across the network is reduced, proportional to network adoption. Savings ramp with the number of participating institutions; below a five-institution threshold, the per-institution saving is materially smaller.
You decide who's inside your risk appetite. 4orm is not the financial institution of record. We do not bank anyone.
A canonical rail-level check against OFAC, OSFI and FINTRAC sanctions lists fires before the token moves. The token refuses to transfer if either party is sanctioned. The rail catches the obvious denials before they hit your compliance team's queue. Estimated impact: substantial reduction in false-positive alert volume reaching the manual disposition tail. Today, the manual review of false positives is where the labour sits, not the rules engine itself.
Suspicious transaction reports, large cash transaction reports, electronic funds transfer reports: the filing obligation is statutory under PCMLTFA and stays with you. Your CAMLO signs off. FINTRAC's relationship is with you, not with 4orm.
Reports auto-generate in FINTRAC's required format, attested cryptographically, queued for your CAMLO's sign-off. The 24-hour aggregation rule runs continuously across the canonical ledger: no more reconciling across systems to detect aggregated sub-threshold activity. Most of the compile-and-file labour per report is removed. Your CAMLO still signs off; the keystrokes are gone.
Internal management accounting, capital adequacy reporting, tax reporting: all yours. The institution is the regulated entity; 4orm is the rail.
Both sides of every cross-institution trade reference the same on-ledger record. The matching engine your bank already runs continues to operate; what disappears is the break-investigation tail: the manual work of investigating mismatches. Most of the break-investigation labour. The auto-matching that already happens today is preserved; the manual exception work goes away.
Investigatory access to customer detail stays gated through you, under lawful production order. PIPEDA and Quebec Law 25 obligations stay with you.
Aggregate pattern-level visibility flows to designated regulators via a read-only supervisory feed: total flows, velocity, sector exposure, suspicious-activity counts. No customer detail in the feed. Continuous, so the "request and wait" examination cycle stops consuming your compliance bandwidth.
In one sentence: you stay accountable, we make accountability cheaper. The dollar value of this redistribution of work is on the What It Saves page.
Every regulated function stays inside the institutional control plane. These are the design rules behind it.
No issuance, transfer, settlement or redemption occurs without compliance approval. Compliance is part of the transaction, not a wrapper around it. Every instruction flowing through the platform carries an eligibility assertion: the smart-contract logic and the off-chain compliance engine must both confirm the action before it proceeds. Approval is a prerequisite, never an after-the-fact audit step.
The platform's record, not blockchain state alone, is the authoritative ledger of ownership and supervisory finality. The on-chain rail is the execution surface; the canonical ledger reconciles and timestamps every event with off-chain regulatory context, custody confirmation, and institution-level identifiers. This means the record a regulator, auditor or court would rely on is institution-controlled and readable without any blockchain tooling. Any discrepancy between on-chain state and the canonical ledger triggers an automatic reconciliation hold.
Settlement is a governed operation of the platform, coordinated across treasury, banking, custody and ledger, not a separate product or a second workflow bolted on after trade execution. The delivery-versus-payment (DvP) logic is embedded: the asset leg and the cash leg are committed atomically in the same instruction, removing the open-window counterparty exposure that exists in T+1/T+2 settlement cycles. Settlement finality is recorded immediately on the canonical ledger and confirmed to both custodians.
Tokens are not usable until custody is confirmed; custody mappings stay aligned with ownership integrity and settlement finality at all times. The platform integrates with a licensed Canadian trust company of the institution's choosing and does not self-custody. Before any token can be issued, transferred, or redeemed, the platform confirms a live custody mapping: the physical or book-entry asset backing the token is held in a segregated, identified account at the qualified custodian, and that confirmation is written into the canonical record. Custody confirmations are refreshed at each material event.
Cross-chain movement stays subordinate to compliance and supervisory governance: it is added later, under controls, and never as a launch dependency. The platform's initial operating perimeter is a permissioned, institution-only network where every participant is fully verified and every settlement currency is a regulated Canadian dollar instrument. Any future cross-chain bridge or external network connection requires a fresh compliance assessment, institution consent, and supervisory review before it is enabled. This means the risk perimeter cannot expand without deliberate institutional decision-making.
Every participant is onboarded before they can transact, and eligibility is enforced at every step, a deterministic, compliance-first control.
Eligibility is continuously enforced, not a one-time check at onboarding.
Who holds the assets, and what "settled" actually means.
Assets and cash are held with a qualified, licensed custodian (a licensed Canadian trust company), in segregated accounts with operational separation of duties. Custody is a partner surface, 4orm integrates with it rather than self-custodying.
Settlement is delivery-versus-payment: the asset leg and the cash leg move in the same instant, or not at all. There is no open settlement window, so counterparty risk between trade and settlement is removed. Finality is irreversible and recorded on the canonical ledger.
| Regulator & instrument | Specific obligation | How 4orm meets it |
|---|---|---|
| FINTRAC / PCMLTFA Proceeds of Crime (Money Laundering) and Terrorist Financing Act |
Know your customer (KYC) and beneficial-owner identification for every reporting entity and client. Verification before account opening; ongoing monitoring for material changes. | Compliance-native gate blocks all activity until KYC and beneficial-owner ID are confirmed by the institution. Eligibility is re-checked at every transaction, not only at onboarding. See KYC in the sandbox → |
| FINTRAC / PCMLTFA Large cash transaction report (LCTR) |
File a large cash transaction report (LCTR) within 15 days of receiving C$10,000 or more in cash.4 | Every transaction is evaluated against the C$10,000 threshold at the time of instruction. The platform flags eligible transactions and generates the structured LCTR data record for the institution of record to file. See compliance report generation → |
| FINTRAC / PCMLTFA 24-hour aggregation rule |
Aggregate transactions by the same client within a 24-hour window; report if the total reaches C$10,000.5 | The canonical ledger maintains a rolling 24-hour aggregation per client identity. When the running total crosses the threshold, the reporting obligation is automatically flagged and the LCTR data record is queued for the institution. See AML screening → |
| FINTRAC / PCMLTFA Electronic funds transfer report (EFTR) |
File an electronic funds transfer report (EFTR) for international electronic transfers of C$10,000 or more, incoming or outgoing.1 | Cross-border transfer instructions are tagged at submission. The platform identifies transfers meeting the C$10,000 threshold and generates the structured EFTR data record. The institution files it; 4orm provides the technical record and timestamp trail. |
| CSA / NI 31-103 Canadian Securities Administrators, National Instrument 31-103 |
Registration as a dealer; suitability, KYC, and know-your-product obligations for each trade recommendation. | 4orm is pursuing restricted dealer registration (Phase 2 pathway). In the interim, activity runs inside a registered institution's regulatory perimeter. Eligibility and suitability checks are embedded in the transaction gate. See regulatory pathway → |
| CSA / NI 21-101 and NI 23-101 Marketplace and order-protection rules |
Marketplace operator obligations: transparent order display, best execution, and fair access for NI 21-101 / NI 23-101 purposes. | The order book and matching engine are designed to meet marketplace-operator standards as 4orm scales toward marketplace operator designation (Phase 3). Order records are immutable and available for supervisory inspection. See trade execution → |
| CSA Interim approach to value-referenced crypto assets |
Settlement currency must be a regulated CAD instrument, a regulated CAD stablecoin or a regulated tokenized deposit held inside a licensed institution. Non-bank stablecoins are not permitted settlement instruments.2 | Settlement is restricted by policy to a regulated CAD stablecoin or a regulated tokenized deposit. Non-bank stablecoins are excluded at the settlement-currency selection layer: the platform will not construct a settlement instruction denominated in an unapproved instrument. See settlement currency selection → |
| OSFI / B-10 OSFI's third-party risk management guideline |
Federally regulated financial institutions must apply risk-based oversight of all third-party arrangements, including concentration risk, exit planning, and audit rights.3 | 4orm provides standardized third-party risk documentation aligned to OSFI B-10, including control descriptions, audit-log export, and contractual audit-access provisions. The institution retains all oversight and termination rights. SOC 2 (security and operational controls audit standard) Type II is targeted before scaled deployment. |
| OSFI / B-13 Technology and cyber risk management guideline |
Federally regulated financial institutions must manage technology risk, cyber risk, and resilience of critical technology services, including those obtained from third-party providers, with documented governance, identification, protection, detection, response and recovery practices. | 4orm is designed and operated against the B-13 control domains: documented governance and architecture, identity and access management, change and patch management, vulnerability and penetration testing, monitoring and incident detection, encryption in transit and at rest, and tested business-continuity and disaster-recovery plans. The institution retains visibility into all of these through the third-party risk package and audit-log export. |
| OSFI / E-21 Operational risk management and operational resilience |
Federally regulated financial institutions must identify, measure, monitor and manage operational risk across the enterprise, including critical operations performed by third parties, and demonstrate operational resilience against severe-but-plausible disruptions. | Critical operations performed through 4orm are mapped, tolerances are documented, and severe-but-plausible-disruption tests are coordinated with the institution. Recovery time and recovery point objectives are contractually agreed; the incident-response framework below describes the runbook. See incident response → |
| OSFI Crypto-asset exposure, capital and liquidity guidance |
Tokenized deposits remain inside the bank's regulated capital and liquidity perimeter; crypto-asset exposures must be identified, measured, and reported. | Tokenized deposits issued through 4orm are liabilities of the issuing institution, not obligations of 4orm. The asset stays inside the institution's balance sheet. Capital and liquidity treatment is the institution's, and 4orm provides the data record for regulatory reporting. See tokenized deposit context → |
| Bank of Canada / RPAA Retail Payments Activities Act |
Designated payment systems must meet operational risk, safeguarding of funds, and incident-reporting standards under the Retail Payments Activities Act (RPAA). | 4orm is designed to meet RPAA designated-system standards as the platform scales. Safeguarding of user funds is achieved through integration with the licensed custodian; operational risk standards are addressed through the SOC 2 program and the incident-response framework below. See incident response → |
| PIPEDA + Quebec Law 25 Personal Information Protection and Electronic Documents Act + Quebec Act 25 |
Collection, use, and disclosure of personal information must meet PIPEDA requirements federally and Quebec's Law 25 (Act 25) provincially, including breach notification within 72 hours of detecting a risk of serious injury. | Personal data is held on Canadian infrastructure. Data-minimization principles are applied at design time: 4orm processes only the identifiers necessary for the compliance function. The breach-notification SLA (72-hour notification to the institution) is specified in the incident-response framework. See incident response → |
| Provincial trust regulations Qualified custody requirement |
Assets held on behalf of clients must be custodied by a qualified, licensed trust company operating under provincial trust-company legislation. | 4orm integrates a licensed Canadian trust company as the qualified custodian. 4orm never self-custodies client assets. Custody confirmation is a prerequisite for tokenization and a required element of every settlement instruction. See tokenization custody confirmation →6 |
Forward-looking targets for the pilot build; clearly labelled. Targets are validated via SOC 2 (security and operational controls audit standard) before scaled deployment.
Recovery time objective (RTO): 4-hour target for full platform restoration. Recovery point objective (RPO): 1-hour target for maximum data loss window. Canonical ledger is replicated continuously to a secondary Canadian region. Failover is automated; manual override available to the institution.
Forward-looking targetTargeted 24/7 on-call rotation for Severity 1 incidents affecting settlement integrity, compliance gate failures, or custody confirmation failures. Escalation path reaches the institution's designated contact within 30 minutes of Severity 1 declaration.
Forward-looking targetTarget: notify the institution's security and compliance lead within 2 hours of 4orm declaring a potential personal-data breach. Full incident report delivered within 24 hours. The institution is the notification controller under PIPEDA and Quebec Law 25; 4orm provides the technical record and timeline.
Forward-looking target4orm targets delivery of all technical records, logs and data extracts to the institution within the statutory windows: OSFI expects prompt notification of material operational incidents; FINTRAC requires suspicious transaction reports (STRs) without tipping off; CSA expects timely disclosure of material operational failures. The institution is the regulated entity that files; 4orm provides the auditable record under the institution's instruction.
Forward-looking targetWhen a transaction pattern triggers an STR (suspicious transaction report) flag, 4orm writes an immutable flag record to the canonical ledger and notifies the institution's anti-money laundering (AML) compliance officer of record. The institution files the STR with FINTRAC. 4orm never discloses directly to FINTRAC, and never tips off the subject. The technical record and auditable trail are available to the institution on demand.
When a sanctions or adverse-media signal hits a transaction, 4orm freezes, notifies the institution's compliance officer, and lets the institution decide and report. Five steps, summarized; click below for full detail of each.
The compliance engine detects a hit against a sanctions list (OFAC, Canadian Consolidated Sanctions List) or an adverse-media signal during a transaction or during a batch re-screen of existing participants.
All pending transactions involving the flagged identity are placed on an automated hold. No new instructions can be submitted for the flagged party. The hold is recorded on the canonical ledger with a timestamp and flag reference.
4orm sends an automated alert to the institution's designated compliance contact within minutes of the hold being placed. The alert includes the flagged identifier, the source list or signal, and a data export of all affected transaction records.
The institution's compliance officer reviews the hit. If it is a false positive, the officer can authorize a release with a documented rationale. If confirmed, the institution instructs account freeze through its own systems; 4orm enforces the freeze at the platform layer simultaneously.
The institution files any required reports with FINTRAC, OSFI, or the CSA as the regulated entity of record. 4orm provides the complete, immutable technical record under the institution's instruction. 4orm does not file independently or disclose to regulators without the institution's direction.
The compliance map above shows what the rail does. These are the operational controls and architecture supports that keep it running cleanly, the things your CAMLO, CFO and CIO will all want to see written down before pilot.
These controls ensure a secure, transparent and compliant operational environment for institutional digital-asset lifecycle management. The institution remains the regulated entity of record; 4orm provides the technical surface and the auditable record underneath.
Clear boundaries matter as much as what the platform does. These are firm design-level constraints, not disclaimers.
The institution's designated anti-money laundering (AML) compliance officer is the officer of record for all FINTRAC obligations. 4orm is the embedded technical layer that runs the checks, writes the records, and surfaces the flags. The compliance decision and any regulatory filing belong to the institution.
The institution's own KYC process is the first line. 4orm is the embedded re-check layer that runs eligibility verification at every subsequent transaction, not at initial onboarding alone. The institution owns the customer relationship and the onboarding decision.
When a regulator issues a production order or an information request, the institution receives it as the regulated entity of record. 4orm provides the complete technical record, logs and data extracts under the institution's instruction. 4orm does not respond to regulators independently on behalf of the institution.
4orm integrates licensed Canadian trust companies as qualified custodians. 4orm itself never holds, controls, or has discretionary authority over client assets. Custody is a partner surface; it is never internalised. See the Custody verification principle →
4orm does not issue any digital currency, stablecoin, or payment instrument. Settlement currency is a regulated CAD stablecoin or a regulated tokenized deposit issued by the institution itself. 4orm is not registered or operating as a payment service provider or money-services business for the purpose of processing payments.
4orm is being designed for interoperability with major institutional tokenization networks, JPMorgan Onyx / Kinexys, BlackRock BUIDL, SIX Digital Exchange (SDX), and the BIS Project Agor framework, as those networks open their cross-chain interfaces. We will use only cross-chain protocols with institutional pedigree and proven security track records (Chainlink CCIP is the current evaluation target, given its SWIFT and Project Guardian institutional precedent), and only with Canadian regulatory sign-off. The interoperability layer is a bounded extension of the platform, not an independent bridge ecosystem. KCS retains authority over the canonical ledger of record, reconciliation, compliance enforcement, and supervisory auditability. Today this is roadmap; once productionized, this is the architecture that lets your bank reach global counterparties without leaving the Canadian regulatory perimeter.
We are in active discovery on several foundational decisions: the legal wrapper for the tokenized deposit, the instrument classification, the bridge proof model for cross-chain transfers, and the destination-chain policy mirroring framework. We are publishing this transparently as we resolve each one. If you're a CAMLO or risk lead and you'd like to walk through where we are on each, contact us, these are conversations we want to have early, not late.
Bank-grade controls, designed in from day one. (Targets for the pilot build; not yet independently certified.)
Type I in the pilot phase; Type II targeted before scaled deployment.
Hardware security modules and multi-party computation for key material.
Regulated workloads kept on Canadian infrastructure under Canadian governance.
Append-only records for every transaction and administrative action.
End-to-end encryption of data in transit and at rest.
High-availability deployment, DR with defined RTO/RPO, continuous monitoring.
Integration philosophy: 4orm connects to your existing core banking, treasury, custody and reporting systems (ISO 20022, APIs) rather than replacing them, lowering deployment risk.
4orm is sandbox-stage and building toward full registration in phases, compliance-first, not a shortcut.
Forward-looking roadmap, not a guarantee of regulatory outcome or timing.
The control model above reflects how regulated Canadian digital-asset activity is structured. Regulatory obligations and the building blocks are real and cited; the platform's own status is forward-looking (sandbox-stage).
Forward-looking; sandbox-stage. Educational only; not an offer of securities and not legal, financial or tax advice.