Architecting AML Regulatory Reporting at Scale

Why AML reporting is the hardest data problem in a bank

On the surface, AML regulatory reporting looks like a data problem. A regulator — FINTRAC in Canada, FinCEN in the US — wants you to report certain transaction patterns: electronic funds transfers above a threshold (EFTR), cash transactions above a threshold (CTR), suspicious behaviour (STR), and unusual transactions (UTR). Take the data, format it, send it.

In practice, the difficulty is that the regulator wants the linked story: who originated the funds, who received them, who controls the account, what KYC level the parties are at, what FX leg routed through which intermediary, what cyber signals fired around the session. That context is scattered across hundreds of source systems — retail core banking, capital markets, commercial lending, wires, FX, treasury, customer hubs, identity systems — each with its own schema, refresh cadence, and ownership.

The 2nd FINTRAC regulatory package made that explicit: approximately 30 distinct use cases, each linking the financial transaction to FX, customer/account, and cyber data, across private, retail, capital markets and commercial lines of business. Architecturally, that's not a reporting project. It's an enterprise integration platform.

The reference architecture, end to end

The platforms we've designed for Tier-1 banks share a common shape — five logical layers, each independently scalable and independently audited:

• Source ingestion. Change-data-capture from core banking, Workday HR, customer hubs, FX engines and cyber signals. Some systems publish events; legacy systems expose batch extracts that we wrap in a schema-validated loader.
• Streaming spine. Kafka-style event streams carrying financial transactions, KYC updates, sanctions hits, and account lifecycle events. Topics are partitioned by customer or account so per-entity ordering is preserved.
• Linking and enrichment. Stream-processing jobs join the transaction event to customer master data, account hierarchies, FX legs, KYC profiles, and historical behaviour. The output is a regulator-shaped, fully linked reportable record.
• Detection and rules. Actimize hosts the AML detection scenarios for STR/UTR; deterministic threshold rules and reference data drive EFTR/CTR. Output is a stream of candidate submissions plus their evidence.
• Submission and lineage.A submission service formats EFTR/STR/CTR/UTR payloads to FINTRAC's schemas, signs them, and ships them through the secure channel. Every record carries a lineage ID back to its source events.

The platform sits on Azure — AKS for containerized services, PostgreSQLfor the regulatory submission store, Azure Storage for raw events, and Azure Monitor / Sentinel for security and observability. On Big-Five Canadian deployments we've enhanced Actimize on AKS with PostgreSQL specifically for CTR capabilities at scale.

Why event streaming, not nightly batch

Historic AML reporting was a nightly batch process. That worked when reportable obligations were measured in days. Today, FINTRAC's expectation — and frankly, the bank's own risk appetite — is much closer to near real time. EFTRs need to fire reliably regardless of when the underlying wire settles. STRs benefit from joining live behavioural signals to the transaction.

Event streaming gives us three things batch can't. First, backpressure-aware ingestion: a slow upstream doesn't take down the regulator pipeline. Second, replay: when a rule changes, we can reprocess the affected window without touching the source systems. Third, per-entity ordering: by partitioning on customer or account, we guarantee that an amendment to a transaction is processed after the original, even when ten thousand events a second are flying through.

Cost-wise, AKS gives us elastic compute that scales with volume — month-end, year-end and FX-volatility spikes don't require permanently-provisioned capacity.

Threat modeling as a first-class architecture artifact

AML reporting is a hostile environment. Bad actors are actively trying to slip below thresholds, structure transactions, or contaminate KYC data. A good AML platform isn't just compliant — it's adversarial-aware.

Every architecture we deliver in this space comes with an explicit threat model: STRIDE on each component boundary, data classification on every store, and least-privilege identity for service-to-service calls. Secrets live in Azure Key Vault; service identities use managed identities, not static credentials. Sensitive payloads — KYC documents, customer PII — are encrypted with envelope keys keyed to the line of business.

On the regulatory submission side, every payload is signed and the signing key is hardware-backed. That means a tampered or replayed submission is detectable not just by FINTRAC's side, but by our own audit pipeline.

KYC and Money Service Business onboarding

AML reporting is downstream of KYC. If KYC is wrong, the reports are wrong. One of the more interesting tactical pieces we've worked on is the onboarding flow for Money Service Businesses(MSBs) — a customer category that's legitimately high-risk and where the KYC due-diligence requirements are material.

The architectural pattern: a screening pipeline that pulls MSB registrations, sanctions lists and beneficial-ownership data into a customer enrichment graph; a tactical case- management UI for the AML investigations team; and an audit trail that links every onboarding decision back to the evidence that supported it. The tactical solution buys time while the strategic customer hub catches up — but its outputs are the same shape, so the strategic platform inherits the data without rework.

Lessons from delivering this at two Tier-1 banks

• Treat the regulator schema as a contract. Build to it from day one. Do not let internal data shapes leak into the submission layer.
• Linking is the work. EFTR/STR rules are the easy part. Joining 30 use cases of customer, account, FX and cyber data correctly is where 80% of the engineering goes.
• Lineage is non-optional. When a regulator questions a submission, you need to show every event that contributed to it within minutes — not days.
• Architecture Review Board approval is not a rubber stamp.Use it as a forcing function. The reviews we've been through have caught data-residency and key-management issues that would have been very expensive to fix later.
• Cloud-native ≠ cloud-only. Some upstream systems will stay on-prem for years. The architecture has to be honest about hybrid integration.

Need this for your bank or fintech?

SEYSO has architected AML and regulatory reporting platforms across multiple Tier-1 Canadian and US banks — covering LCTR, EFTR, STR, UTR, CTR, KYC and CFT obligations. If you're modernizing financial-crime technology, replatforming Actimize, or scoping a new regulatory program, we'd love to talk. Bring the regulator obligations and the source-system mess; we'll bring the architecture.