KYC and AML Regulations Around the World: How a Snowflake-Based Data Repository Helps Companies Stay Compliant

Know your customer (KYC) and anti-money laundering (AML) obligations have moved from a compliance checkbox to a core operational discipline for institutions around the world. Banks, payment institutions, crypto-asset service providers, real estate agents and even bookkeeping and accounting firms increasingly sit under the same regulatory umbrella, and that umbrella keeps getting bigger as international standards drive tighter, more harmonized supervision.

For data engineering teams, this is an architecture problem as much as a legal problem. Regulators don’t just want a current snapshot of “who is this customer today.” They want to know what an institution knew, when and how a risk assessment evolved over time. That kind of traceability is hard to add onto a system, but it’s what a well-designed data repository – built on Data Vault 2.0 principles and hosted on Snowflake – is suited to provide.

This article explores the shared logic behind global KYC/AML regimes, looks at the data challenges that logic creates and shows how Snowflake can support regulatory reporting – regardless of the jurisdiction.

The global KYC/AML regulatory landscape

The common legal foundation

Most jurisdictions’ AML frameworks trace back to the same source: the recommendations of the Financial Action Task Force (FATF), the international standard-setting body for combating money laundering and terrorist financing. Individual countries then implement FATF’s recommendations through their own statutes – for example the EU’s Anti-Money Laundering Directives, the US Bank Secrecy Act, the UK’s Money Laundering Regulations. A common misconception is that these laws apply only to banks. In fact, their reach is wider. Bookkeeping offices, real estate agencies and businesses that regularly handle large cash payments are routinely classified as “obligated” or “covered” institutions, with many of the same core duties as a bank.

The regulators

Almost every jurisdiction has two kinds of authority:

• A financial intelligence unit (FIU) – the national body that receives and analyzes suspicious transaction reports, cooperates with foreign FIUs, maintains AML registers and issues interpretive guidance for obligated institutions. The specific name varies by country, but the functions are similar.
• One or more sectoral supervisors – authorities who oversee banking, payments, capital markets, or crypto-asset activity, often also responsible for authorizing and licensing regulated firms within their sector.

Core obligations

Regardless of sector or jurisdiction, obligated institutions are generally expected to:

• Maintain and regularly update a documented AML risk assessment
• Apply customer due diligence (CDD) procedures calibrated to the assessed risk level (not as a one-time onboarding exercise, but an ongoing program constantly reviewed as the risk environment changes)
• Apply enhanced due diligence for politically exposed persons (PEPs) and for transactions involving high-risk jurisdictions
• Report suspicious transactions to the relevant FIU and conduct routine threshold-based reporting (specific thresholds and currencies vary by jurisdiction – for example, €15,000 under various EU member-state rules, or $10,000 for US currency transaction reports)
• Keep records in a form that supports audit and regulatory inspection, not just internal use

What’s changing

Regulatory regimes worldwide are moving in a consistent direction: toward tighter harmonization, expanded beneficial-ownership disclosure and more granular reporting expectations. The EU, for instance, is shifting from directive-based, country-by-country transposition toward a directly applicable AML regulation (AMLR) enforced by a new centralized authority. This pattern of consolidating supervision is showing up, in different forms, across other regions as well. Local rules can also shift quickly within a single sector; crypto-asset licensing regimes in particular have seen frequent legislative change in multiple countries as authorities work out how existing AML frameworks apply to digital assets.

The reporting burden is only going to get heavier, more granular, and more demanding across markets. This will have direct implications for how institutions structure their data.

Why this creates a data architecture problem

• Fragmented sources. Customer, account, transaction and ownership data exist across core banking systems, payment platforms, CRM tools, case management systems and external sanctions/PEP watchlists. KYC risk assessment requires connecting all of these dots.
• Point-in-time obligations. If a regulator or FIU asks “what was this customer’s risk classification and PEP status on the date of this transaction,” an institution needs to precisely reconstruct history precisely.
• Full audit trail requirements. Every change to a risk score, ownership structure, or due diligence outcome needs to be traceable: what changed, when and from what source.
• Increasing reporting frequency and granularity. As regulators around the world harmonize, the volume and specificity of what institutions must be able to produce on demand is expected to increase, not decrease.
• Cross-entity and cross-border consolidation. Groups operating across jurisdictions increasingly need a consolidated, governed view, rather than siloed reporting per entity or per country.

A data warehouse designed only for “what does the customer look like right now” will struggle here. What’s needed is a repository designed to preserve history, track lineage and support flexible, auditable reporting – one that can serve multiple regulators’ requirements from a single model.

How a Snowflake-based data repository helps

Data Vault 2.0 as the modeling foundation

Data Vault 2.0 is a natural fit for KYC/AML reporting because it separates business keys, relationships and historized descriptive data into distinct structures:

• Hubs hold the core business keys – customer ID, account ID, counterparty ID – which provides a stable, non-volatile anchor point regardless of how source systems change.
• Links model relationships: a customer to an account, a transaction between counterparties, an ownership chain in a beneficial-ownership structure.
• Satellites capture descriptive attributes with full history. Every change to a KYC risk score, PEP flag, or due diligence outcome is preserved as a new satellite record rather than overwritten. This is exactly what point-in-time regulatory reconstruction requires.

Time Travel and historization

Snowflake’s Time Travel, layered on top of a Data Vault model, enables an institution to check the state of its data as it existed on any given date within the retention window. This is useful for internal investigations and for responding to regulator requests about what was known at a specific point in time, wherever that regulator sits.

Point-in-time (PIT) tables

Raw vault satellites are powerful but not always convenient to query directly for reporting. PIT tables pre-join hub, link and satellite data into a stable, reporting-ready structure as of a given date, which makes periodic regulatory submissions (monthly, quarterly, or ad hoc) far faster to generate without re-deriving history each time.

Governance and access control

Snowflake’s role-based access control (RBAC) allows fine-grained separation between compliance teams, business teams and auditors. This is important given that KYC data intersects heavily with data protection regimes such as the EU’s GDPR. Row- and column-level security can restrict PII visibility while still allowing aggregated risk reporting to flow to the teams that need it. Moreover, they can be tailored by jurisdiction where data residency rules require it.

Near-real-time monitoring with dynamic tables and tasks

For elements of AML that benefit from near-real-time visibility, like transaction monitoring aggregates, sanctions/PEP match flags, risk score recalculation, dynamic tables (with task handling autosuspend/scheduling gaps) can keep derived reporting layers current without a full custom ETL pipeline for every refresh.

Cost governance

Compliance workloads often spike around reporting deadlines and ad hoc regulator requests. Resource monitors and budgets are a way to keep this cost visible and controlled.

Cross-border consolidation

For groups with entities in multiple jurisdictions, Snowflake’s ability to unify data from different regional deployments into a single governed repository is well aligned with the global direction of travel – international harmonization efforts are explicitly about reducing fragmentation across borders, and a consolidated data layer makes group-wide reporting far more tractable than reconciling per-entity, per-country spreadsheets.

Reference architecture sketch flow

The process might look like this:

• Ingestion – CDC or streaming ingestion (e.g., via Kafka) from core banking, payments, CRM and external watchlist feeds
• Raw Vault – hubs, links and satellites capturing full, unmodified history from source systems
• Business Vault – derived structures: computed risk scores, aggregated transaction monitoring metrics, resolved beneficial-ownership hierarchies
• Reporting layer – PIT tables and a star schema optimized for regulatory and BI consumption
• Output – scheduled regulatory submissions to national FIUs and supervisors, ad hoc audit query support and internal dashboards

Practical considerations

• Data quality at ingestion is non-negotiable. A Data Vault preserves history faithfully, but it will just as faithfully preserve bad data – garbage in, garbage out applies directly to suspicious activity detection.
• Time Travel retention vs. cost. Longer retention windows support deeper historical reconstruction but carry a storage cost. This needs deliberate tuning rather than a default setting, and should reflect the record-keeping periods required in each jurisdiction an institution operates in.
• Model adaptability. With reporting regimes tightening across multiple regions, the reporting layer (not the Raw Vault) should be the primary place absorbing new requirements. The point of Data Vault’s separation of raw and business layers is to avoid re-engineering historical data every time reporting rules change.
• Migration from legacy systems. Institutions moving off legacy on-prem warehouses (stored procedures, older ETL tools) need a deliberate mapping exercise – translating legacy business logic into Snowflake-native constructs (dynamic tables, streams, tasks) rather than a lift-and-shift that just recreates old technical debt in a new platform.
• Multi-jurisdiction design. Keeping thresholds, reporting formats, and retention periods in reference/configuration tables rather than hard-coded logic is what lets a single repository serve reporting obligations across multiple countries without forking the pipeline for each one.

Partnering with an experienced team to ensure compliance

KYC and AML regulations are increasing and becoming more harmonized almost everywhere. A data repository built on Data Vault 2.0 principles and hosted on Snowflake isn’t just a convenient warehouse pattern for this – it’s a compliance-readiness strategy in its own right. Full historization through satellites, point-in-time reconstruction through Time Travel and PIT tables, and governed access through RBAC together give an institution the ability to answer, credibly and quickly, the questions every regulator eventually asks, no matter which country they’re in.

Want to learn more about making your data more secure and compliant? Looking for a proven partner with Snowflake expertise? Get in touch with our team.

FAQ

Does a Data Vault model on Snowflake replace the need for a compliance team’s own case management system?

No. The repository described here is the data backbone underneath compliance operations – it historizes and consolidates data for reporting and audit purposes. Case management, investigator workflows and decisioning tools typically remain separate systems that read from (and sometimes write back into) this repository, rather than being replaced by it.

How far back does Time Travel actually let us go for an audit request?

Time Travel is bounded by the retention period configured per table or schema (up to 90 days on Snowflake Enterprise Edition and above, shorter on Standard Edition), so it’s not a substitute for long-term historization. That’s why the article recommends explicit end-dating on satellites as the primary mechanism for point-in-time reconstruction, with Time Travel used as a secondary, shorter-window audit tool for very recent changes.

Do we need a full Data Vault implementation to get these benefits, or can a smaller team start simpler?

A full Raw Vault / Business Vault / reporting-layer separation is the long-term target, but teams can start with just the historized satellite pattern (insert-only, end-dated records) on the handful of tables that actually feed regulatory reporting – typically customer risk profile and transaction details. The rest of the model can be built out incrementally as reporting requirements grow.

How does this approach handle a change in reporting requirements, such as a new EU AMLR field or a new threshold in another jurisdiction?

Since raw historical data sits in the Raw Vault untouched, new requirements are absorbed in the Business Vault and reporting layers – new derived fields, new threshold logic, or new jurisdiction-specific reference data can be added without reprocessing or restating the underlying history. This is the main practical payoff of keeping raw and business logic separated.