AML/CTF Compliance Platform

End-to-End Requirements Document

Chief Compliance Officer · Version 1.5 — Draft for review — 5 August 2026

• Entity type: Money Services Business (MSB) registered with FINTRAC, Canada — virtual currency dealing permission
• Products in scope: Fiat on/off-ramp (CAD), custodial wallets & transfers, merchant crypto payments / OTC
• Customer base: Retail individuals and business entities
• Existing stack: Sumsub (identity + Travel Rule) · AMLBot (crypto/address checks) · Marble (rule engine integrated; screening not yet built) · Internal Case Management (not linked to compliance)

Legal disclaimer. This document is a technical and operational requirements specification. It is not legal advice. Every obligation cited below must be validated against current FINTRAC guidance and confirmed by qualified Canadian AML counsel before go-live. FINTRAC revoked 86+ MSB registrations in Q1 2026 alone, disproportionately in the virtual currency sector — sign-off by counsel is not optional.

Contents

0. Change Log
1. Purpose & Scope
2. Regulatory Basis & Obligation Register
3. Current State Assessment
4. Gap Analysis
5. Target Architecture
6. Functional Requirements
7. Process Flows
8. Rule Library — Starter Set
9. Data Model & Canonical Events
10. Integration Specifications
11. Non-Functional Requirements
12. Compliance Programme Governance
13. Testing & UAT
14. Go-Live Checklist
15. Delivery Roadmap
16. Risks, Assumptions & Open Items
17. Glossary

Figures

• Figure 1. Current-state architecture
• Figure 2. Target logical architecture
• Figure 3. Deployment view
• Figure 4. Customer onboarding flow
• Figure 5. Real-time transaction decisioning sequence
• Figure 6. Alert to STR workflow
• Figure 7. Travel Rule — outbound transfer
• Figure 8. LVCTR aggregation and filing
• Figure 9. Core compliance data model
• Figure 10. Delivery roadmap

0. Change Log

Version 1.1 — revised against confirmed platform status

Version 1.2 — KYB confirmed live

The residual issue is not collection but handoff: beneficial owner names sit in Sumsub and are not yet reaching Marble Screening. Until screening is live and that feed is built, no beneficial owner is checked against any sanctions list. See RSK-09 and FR-316.

What this changes materially

The most important revision is not any single module. It is that the platform currently detects without capturing. The Marble rule engine is integrated and producing decisions, but there is no alert management layer to receive them and no link into case management. Detection output is being generated and discarded.

From an examiner’s perspective this is a worse posture than having no monitoring at all. A firm with no monitoring has a capability gap. A firm whose system identifies risk and then drops it on the floor has a documented, timestamped record of having known something and done nothing with it. The alert-to-STR chain in §7.3 is the single most heavily examined path in any AML programme, and yours is currently severed in two places.

Phase 1 of the roadmap has therefore been reordered to close this loop before anything else is built.

1. Purpose & Scope

1.1 Purpose

Define the complete set of business, functional, technical and operational requirements necessary for the platform to operate lawfully as a FINTRAC-registered MSB dealing in virtual currency, and to survive a FINTRAC examination.

1.2 In scope

• Customer onboarding and identity verification (individuals and entities)
• Sanctions, PEP and adverse-media screening
• Blockchain address and counterparty risk screening
• Customer risk rating and periodic review
• Real-time and batch transaction monitoring
• Travel Rule (virtual currency transfer information)
• Regulatory reporting to FINTRAC
• Alert triage, investigation and case management
• Record keeping, retention and audit trail
• Compliance programme governance artefacts

1.3 Out of scope (this document)

• Securities regulation (CSA/CIRO) — applies if any crypto asset traded is a security or derivative
• Tax reporting under CARF/RCASP to CRA — separate workstream, see §16
• Quebec AMF money services licence — required if serving Quebec residents
• Consumer protection, market conduct, custody/technology audits

1.4 Audience

Compliance, Engineering, Product, Internal Audit, external AML counsel, and FINTRAC examiners.

2. Regulatory Basis & Obligation Register

2.1 Governing instruments

2.2 The five pillars of the compliance programme

Every requirement in this document traces back to one of these. FINTRAC examines all five.

Note on P5. A one-page memo will not pass. FINTRAC expects a testing programme with documented sampling methodology, control walkthroughs, findings, and a tracked remediation plan.

2.3 Reporting obligation register

Critical. Each obligation is independent. Filing an STR does not discharge the LVCTR, LCTR or EFTR obligation. If a transaction triggers both, both must be filed. The single largest publicly reported crypto penalty in Canada (C$176.96M, October 2024) involved 1,068 unreported STRs in one month, 1,518 missed LVCTRs, and 7,557 unflagged Iran-linked transfers.

2.4 Threshold quick reference

3. Current State Assessment

3.1 Components in place

3.2 Current architecture

Figure 1. Current-state architecture — red nodes are unbuilt or unconfirmed and block go-live

Red nodes are unbuilt. The amber node exists but is disconnected. The critical observation is the chain across the middle of the diagram: Marble Rule Engine → Alert Management → Case Management → FINTRAC Reporting is broken at every link. Rules fire, and nothing downstream receives the output.

3.3 Control ownership matrix

Where two vendors sit adjacent to each other, obligations fall into the seam between them. This matrix exists to make every seam explicit and assign it an owner.

The rule to hold onto: a vendor performs a function; it never assumes your obligation. FINTRAC examines you, not Sumsub, Marble or AMLBot.

4. Gap Analysis

4.1 GAP-01 — RPAA registration (licensing, not technical) — BLOCKER

Your FINTRAC MSB registration covers AML obligations only. Because you operate a CAD fiat on/off-ramp and merchant payment settlement, and hold end-user fiat balances, you very likely also require registration as a Payment Service Provider with the Bank of Canada under the Retail Payment Activities Act. The RPAA is activity-based: purely crypto-to-crypto services are generally out of scope, but fiat on/off-ramps and wallets that hold fiat balances bring an entity into scope.

The RPAA operates entirely separately from FINTRAC — a valid MSB registration provides no defence. Registration requires an operational risk and incident response framework, an end-user funds safeguarding plan (safeguarded account with a qualified Canadian banking partner, plus insurance or guarantee), and ongoing reporting. Penalties for unregistered operation are severe.

Action: Legal determination required within 2 weeks. If in scope, this drives the critical path, not the AML build.

4.2 Technical and process gaps

4.3 GAP-04 detail — the Marble Screening dependency chain

Choosing Marble for screening is sound: it keeps screening and rules in one platform, one audit trail, one alert stream. But it introduces a three-link dependency chain, and every link must be resolved before screening can go live. This is a procurement item as much as an engineering one, which is why it sits in Phase 0 of the roadmap.

Link 1 — Marble Screening is a licensed feature. Screening is a premium offering within Marble and requires a licence key; it is not enabled by default in the open-source deployment you are already running. Deployment also has its own infrastructure requirements distinct from the rule engine.

Link 2 — the underlying data is OpenSanctions, which requires a commercial licence. Marble Screening is built on OpenSanctions data and matching. OpenSanctions is free for non-commercial use only; commercial users must hold a data licence or an API subscription. As an MSB you are unambiguously a commercial user.

Link 3 — Canadian dataset coverage must be explicitly verified. OpenSanctions does carry the Canadian lists, including the Consolidated Canadian Autonomous Sanctions List (SEMA and JVCFOA designations) and Criminal Code listed terrorist entities. But a global screening product does not necessarily enable Canadian datasets by default, and coverage must be confirmed list by list rather than assumed from a marketing claim of global coverage.

One caveat that must be written into the policy. The Consolidated Canadian Autonomous Sanctions List published by Global Affairs Canada is maintained for administrative purposes; it is not itself a regulation and does not carry force of law, and the published version may lag the regulations. The regulations are the law. Your procedures must therefore state that the consolidated list is a screening aid, and that a match — or a near-miss on a recently amended regulation — is resolved against the regulations themselves.

Screening frequency benchmark. OSFI supervises federally regulated financial institutions rather than MSBs, so its expectations do not bind you directly. They are nonetheless the clearest published Canadian benchmark, and an examiner will recognise them: screening at minimum weekly and daily for larger institutions, new client names checked at or as soon as reasonably possible after onboarding, the same measures applied to recorded beneficial owners and third parties, and screening integrated into transaction monitoring rather than run as a separate exercise. Marble refreshes sanctions data several times per day, so daily screening is achievable — adopt it, and document the choice.

5. Target Architecture

5.1 Logical architecture

Figure 2. Target logical architecture

5.2 Key design decision — the Compliance Orchestration Layer

Do not point every service directly at every vendor. Introduce a single orchestration layer that:

• Normalises all business events into one canonical compliance event schema
• Sequences the screening calls (sanctions → address risk → rules → decision)
• Applies fail-closed logic if a vendor is unavailable
• Owns idempotency, retry and dead-letter handling
• Writes every decision and its full input payload to the immutable audit log

This is what makes the system explainable to an examiner: one place holds “what did we know, when did we know it, and what did we do”.

5.3 Deployment view

Figure 3. Deployment view

Data residency: host in a Canadian region. Confirm where Sumsub and AMLBot process and store personal data, and paper it in the vendor agreement — PIPEDA applies and FINTRAC expects records to be producible in Canada within 30 days.

6. Functional Requirements

Requirement convention: MUST = regulatory obligation or go-live blocker. SHOULD = strongly recommended. MAY = optional enhancement.

6.1 Module: Customer Onboarding — Individuals (FR-100)

6.2 Module: Customer Onboarding — Entities / KYB (FR-200)

Status: built. Sumsub KYB is live and traces ownership to ultimate natural persons. The requirements below therefore serve as a verification checklist rather than a build specification — walk the live flow against each one and retain the evidence, since an examiner will test the control, not the vendor’s capability. FR-207 is the exception: it depends on screening, which is not yet live.

6.3 Module: Sanctions, PEP & Adverse Media Screening (FR-300)

Marble Screening implementation requirements

On false-positive reduction. Screening tools market noise reduction as a headline benefit, and the operational case for it is real. But every suppressed match is a decision not to look at something. Tune for precision only after you have measured recall against a known test corpus, and never let a false-positive target drive configuration — the regulatory asymmetry is total, since a missed true match is a sanctions breach and a false positive is only analyst time.

6.4 Module: Blockchain Address & Counterparty Risk (FR-400)

6.5 Module: Customer Risk Rating (FR-450)

6.6 Module: Transaction Monitoring (FR-500)

6.7 Module: 24-Hour Aggregation (FR-550)

6.8 Module: Travel Rule — Sumsub (FR-600)

Sumsub is the Travel Rule provider and the capability is in place. The requirements below are therefore about configuration, Canadian specificity and evidence, not about building or procuring. The vendor solves counterparty reach; it does not solve your obligation.

6.9 Module: FINTRAC Regulatory Reporting (FR-700)

6.10 Module: Case Management (FR-800)

6.10a Module: Alert Management (FR-850) — new, highest priority

This module does not exist today. The Marble rule engine is integrated and producing decisions; nothing captures them. Until this layer is built, every other detection control in this document is inert — a rule that fires into nothing has no compliance value, and the record that it fired is evidence against you rather than for you.

6.10b Module: Case Management Integration (FR-870) — new

Case management exists but is not connected to the compliance stack. These requirements cover the linkage; §6.10 covers the workflow the linked system must then support.

6.10c Module: Examination Workspace (FR-880) — new

Regulators and independent reviewers need access to evidence. They must not be given a login to the operational platform. Direct production access exposes data outside the scope of the examination — including unrelated customers — with no way to withdraw what has been seen, and no record of the boundary having been respected.

6.11 Module: Record Keeping & Audit (FR-900)

6.12 Module: Compliance MI & Oversight (FR-950)

7. Process Flows

7.1 Customer onboarding

Figure 4. Customer onboarding flow

7.2 Transaction decisioning — real time

Figure 5. Real-time transaction decisioning sequence

7.3 Alert to STR

Figure 6. Alert to STR workflow

Independence check. The “No” branch at H closes the STR question only. LVCTR/LCTR/EFTR obligations for the same transaction are evaluated separately and are unaffected.

7.4 Travel Rule — outbound

Figure 7. Travel Rule — outbound transfer

7.5 LVCTR aggregation and filing

Figure 8. LVCTR aggregation and filing

8. Rule Library — Starter Set

Thresholds below are illustrative starting points. Every one must be calibrated against your actual risk assessment and customer base, then tuned with evidence.

8.1 Threshold and structuring

8.2 Velocity and behaviour

8.3 On-chain risk

8.4 Geography and sanctions

8.5 Merchant and OTC specific

8.6 Network and identity

9. Data Model & Canonical Events

9.1 Core entities

Figure 9. Core compliance data model

9.2 Canonical compliance event

Every business event MUST be normalised to this shape before entering the compliance layer. This is the contract between core platform and compliance.

{
  "event_id": "uuid",
  "event_type": "DEPOSIT|WITHDRAWAL|TRANSFER|EXCHANGE|SETTLEMENT|ATTEMPT",
  "event_timestamp": "ISO8601",
  "customer": {
    "customer_id": "string",
    "customer_type": "INDIVIDUAL|ENTITY",
    "kyc_status": "VERIFIED|PENDING|EXPIRED|REJECTED",
    "risk_rating": "LOW|STANDARD|HIGH",
    "risk_model_version": "string",
    "pep_status": "NONE|DOMESTIC|FOREIGN|HIO|RCA",
    "jurisdiction": "ISO3166",
    "onboarding_date": "ISO8601"
  },
  "transaction": {
    "transaction_id": "string",
    "direction": "INBOUND|OUTBOUND|INTERNAL",
    "asset": "BTC|ETH|USDT|CAD|...",
    "amount": "decimal",
    "amount_cad": "decimal",
    "fx_rate": "decimal",
    "fx_source": "string",
    "fx_timestamp": "ISO8601",
    "status": "PENDING|COMPLETED|REJECTED|ATTEMPTED"
  },
  "counterparty": {
    "type": "VASP|UNHOSTED|INTERNAL|BANK|MERCHANT",
    "name": "string|null",
    "vasp_id": "string|null",
    "address": "string|null",
    "chain": "string|null",
    "bank_details": "object|null"
  },
  "screening": {
    "sanctions_status": "CLEAR|POTENTIAL_MATCH|CONFIRMED_MATCH|NOT_SCREENED",
    "sanctions_list_version": "string",
    "address_risk_score": "number|null",
    "address_risk_categories": ["string"],
    "address_exposure_type": "DIRECT|INDIRECT|NONE",
    "screening_timestamp": "ISO8601"
  },
  "travel_rule": {
    "required": "boolean",
    "status": "SENT|RECEIVED|INCOMPLETE|NOT_REQUIRED",
    "originator": "object|null",
    "beneficiary": "object|null"
  },
  "channel": {
    "source": "WEB|MOBILE|API|OTC",
    "ip": "string",
    "device_fingerprint": "string",
    "geo": "ISO3166"
  },
  "aggregates": {
    "rolling_24h_cad": "decimal",
    "rolling_7d_cad": "decimal",
    "rolling_30d_count": "integer",
    "declared_expected_monthly_cad": "decimal"
  }
}

9.3 Data quality requirements

10. Integration Specifications

10.1 Integration map

10.2 Integration requirements

10.3 Marble specifics

11. Non-Functional Requirements

12. Compliance Programme Governance

12.1 Documentation deliverables

12.1a Compliance roles and segregation of duties

FINTRAC requires an appointed Compliance Officer. It does not prescribe the rest of the structure — but it does examine whether decisions were made by people with appropriate authority and independence. The roles below are the minimum functional set; on a small team one person may hold several, subject to the prohibited combinations in §12.1c.

A note on terminology. Other jurisdictions use Money Laundering Reporting Officer (MLRO — UK, EU, Singapore, UAE, Cayman) or Chief Anti-Money Laundering Officer (CAMLO — used by Canadian federally regulated financial institutions). Under the PCMLTFA the statutory role is simply the Compliance Officer, which is the CCO above. If the business later operates under another regime, expect the MLRO title and its specific nominated-officer duties to apply there in addition, not instead.

12.1a-ii Roles beyond the second line

The roles above are almost entirely second-line. A compliance programme that exists only in the second line fails examination, because the first line is where risk is actually seen and the third line is what proves the whole thing works.

Why the Sanctions Officer is called out separately. It is tempting to fold sanctions into AML because the screening tooling is shared. The obligations are not. Sanctions arise under different statutes, are strict liability, require disclosure to the RCMP and CSIS rather than FINTRAC, and carry an immediate rather than a scheduled deadline. Filing a Terrorist Property Report to FINTRAC does not discharge the SEMA disclosure duty, and vice versa. If one person holds both roles — which is reasonable at your scale — the two obligation sets MUST still be separately documented and separately evidenced.

12.1b Role authority at each decision point

12.1c Segregation of duties — enforced in software

These MUST be enforced by the system, not by policy alone. Policy-only segregation fails under workload pressure and cannot be evidenced to an examiner.

On small teams. A firm at your stage may reasonably run with a CCO, a deputy, two analysts, and outsourced QA and independent review. That is defensible. What is not defensible is one person drafting and approving the same STR, however small the team — that pair always requires a second individual.

12.2 Training requirements

12.3 Governance cadence

13. Testing & UAT

13.1 Test coverage

13.2 UAT acceptance criteria

• Every MUST requirement traced to at least one passing test case
• Zero critical or high defects open
• Sanctions screening false negative rate: zero on the test corpus
• Report generation accuracy: 100% on the FINTRAC validation test suite
• All fail-closed scenarios verified with zero event loss
• CCO formal sign-off on end-to-end walkthroughs of onboarding, monitoring, alert-to-STR, and Travel Rule
• Independent review of rule logic against the documented risk assessment

14. Go-Live Checklist

14.1 Regulatory

• FINTRAC MSB registration current, with virtual currency permission, and details accurate
• RPAA applicability determined by counsel; if in scope, Bank of Canada registration complete and safeguarding in place
• Quebec AMF licence assessed (if serving Quebec residents)
• Compliance Officer appointed, documented, and adequately resourced
• All §12.1 documentation approved by senior management
• Enterprise risk assessment completed and signed
• External AML counsel review of the full programme complete
• FINTRAC API enrolment complete (application + secret) with FWR fallback tested

14.2 Technical

• All MUST requirements implemented and tested
• Marble Screening licence + OpenSanctions data licence executed
• Marble Screening live with Canadian datasets verified list by list
• Every Sumsub-held name reconciled against a Marble screening record
• Beneficial owner and director names confirmed flowing from Sumsub KYB into screening
• KYB flow walked against FR-201 to FR-206 with evidence retained
• Retrospective re-screening operational and timed
• AMLBot screening on 100% of deposits and withdrawals
• Marble ingestion at 100% coverage — reconciled against ledger
• Alert management live — every rule decision captured, zero loss demonstrated
• Case management linked — alert to case to STR proven end to end
• 24-hour aggregation validated at boundaries
• Travel Rule configured to the Canadian CAD 1,000 threshold and evidenced
• Travel Rule fallback path tested for counterparties Sumsub cannot reach natively
• Travel Rule and KYC records exported from Sumsub into your own 5-year archive, restoration tested
• FINTRAC report generation and submission tested end to end
• Case management with SLA, four-eyes and immutable audit live
• 5-year immutable retention configured and verified
• Monitoring, alerting and on-call rota live
• DR tested

14.3 Operational

• Compliance team hired and trained; capacity modelled against forecast alert volume
• All staff trained with records retained
• Alert volume forecast validated by parallel run
• Escalation paths documented and rehearsed
• FINTRAC information request response procedure tested against the 30-day clock
• Parallel run completed — minimum 30 days recommended before full live traffic

15. Delivery Roadmap

Figure 10. Delivery roadmap

Sequencing logic. Three things drive this order.

Phase 0 is cheap and slow. Legal determinations, FINTRAC API enrolment and the Marble/OpenSanctions licences all have external lead times you cannot compress by adding engineers. Start them in week 1 even though none of them produce visible progress.

Phase 1 closes the detection loop before anything else is built. This is the change from v1.0. Alert management, case management linkage and screening now precede the reporting stack, because reporting has nothing to report from until alerts are captured and investigated. Building the report builder first would produce a submission pipeline with an empty intake.

Phase 3 is lighter than in v1.0. The rule engine is integrated and Sumsub already provides Travel Rule, so what remains there is configuration, evidence and tuning rather than construction.

On the go-live date. 15 March 2027 assumes Phase 0 starts immediately and RPAA does not apply. If RPAA is in scope, the Bank of Canada review adds roughly 60–90 days for a complete application on top of 3–6 months building the operational risk framework and end-user funds safeguarding plan — and that becomes the binding constraint, not this AML build.

16. Risks, Assumptions & Open Items

16.1 Key risks

16.2 Assumptions

• A-01: FINTRAC MSB registration is current and includes the virtual currency permission
• A-02: Marble is self-hosted under your control, with Ingestion and Decision APIs available
• A-03: AMLBot API supports the chains and assets you list
• A-04: Sumsub verification flows can be configured to FINTRAC-prescribed methods
• A-05: Engineering capacity is available to build the orchestration layer
• A-06: Budget exists for a Travel Rule solution and, if needed, a sanctions screening vendor

16.3 Open items requiring decision

17. Glossary

End of document. Version 1.0 — Draft for review.