Record keeping, data protection and information sharing

Every control in an AML/CFT program is worthless to an examiner, an FIU or a court if the firm cannot show what it did and why. At the same time, compliance teams hold some of the most sensitive personal data in the business: identity documents, financial histories, suspicions. Running a program well means keeping the right records for long enough, protecting them, sharing them only where allowed, and deleting them when the duty ends.

What records to keep

Recommendation 11 (Record keeping) sets the baseline. Firms must keep all necessary records on transactions, domestic and international, for at least five years after the transaction, and records obtained through customer due diligence, account files, business correspondence and the results of any analysis for at least five years after the business relationship ends or after an occasional transaction. Transaction records must be sufficient to reconstruct individual transactions so they can provide evidence for prosecution, and records must be available swiftly to competent authorities.

For a crypto business, "sufficient to reconstruct" means more than a ledger entry. The table below is good practice rather than a field list set by the standard.

The analytics row is often missed. Attribution labels change, so an exposure result re-run today may differ from the one that drove a decision two years ago. Keep a snapshot or export of the result you relied on, with its date.

How long, and from when

Five years is the international minimum, not a fixed term. National law may require longer, and some records must be kept beyond their normal date:

• legal holds for investigations, preservation requests, litigation or regulatory reviews override deletion;
• the trigger matters: five years from the end of a relationship can mean decades for a long-standing customer;
• program records (risk assessments, audits) are kept to show what the firm knew and did at each point.

Data protection pushes the other way: once the retention period ends and no hold applies, personal data should be deleted or anonymized. A retention schedule names each record type, its trigger, its period and the owner who confirms deletion.

-- Customer records past retention with no legal hold (standard SQL)
SELECT c.customer_id, c.relationship_end_date
FROM customers c
LEFT JOIN legal_holds h
  ON h.customer_id = c.customer_id AND h.released_at IS NULL
WHERE c.relationship_end_date < CURRENT_DATE - INTERVAL '5' YEAR
  AND h.customer_id IS NULL;
-- Interval syntax differs between engines (e.g. DATEADD, DATE_SUB)

The query lists closed relationships older than five years that have no open legal hold, the candidates for deletion review. The five-year figure is a placeholder for the longest period that applies in the firm's countries. A person still reviews the list, because holds are sometimes recorded late.

Data protection principles

Data protection laws differ, but most rest on principles first set out internationally in the OECD Privacy Guidelines (1980, revised 2013) and echoed in ISO/IEC 29100 (privacy framework) and the NIST Privacy Framework (2020).

On-chain data is public, but once a firm links an address to a customer, the address and its history become personal data in the firm's hands. Analytics on customer wallets should be covered by a data protection impact assessment.

Reconciling AML and privacy duties

The two regimes are designed to coexist. Since February 2018, Recommendation 2 asks countries to coordinate so that AML/CFT requirements are compatible with data protection and privacy rules. In practice:

• Legal obligation as the basis. Collecting and keeping AML data is usually justified by the legal duty itself, so consent is not the basis and cannot be withdrawn to force deletion.
• Access requests and tipping-off. When a customer asks for their personal data, the response must not reveal an STR, an investigation or a law-enforcement request. Most regimes provide an exemption; the firm needs a procedure so staff apply it consistently.
• Cross-border transfers. Group-wide monitoring and Travel Rule messages move personal data between countries; the firm checks that each transfer is permitted and protected.
• Counterparty protection. Before sending Travel Rule data, the firm checks that the counterparty VASP can protect it (see the lesson Identifying and vetting the counterparty).

Minimization applies inside compliance too. Investigators should not pull the full histories of unrelated customers into a case file because they share a counterparty; a reference to the linked case is enough. Responses to production orders include what was asked for, not the whole account. And data gathered for one purpose, such as device fingerprints collected for fraud prevention, can be used for AML monitoring where the law permits, but the reuse should be documented rather than assumed.

Sharing information

Sharing has three distinct settings, with different rules.

Within a group. Recommendation 18 requires group-wide programs, including policies for sharing information needed for CDD and ML/TF risk management. The November 2017 revision of its Interpretive Note clarified that this includes information on unusual or suspicious transactions and their analysis, and Recommendation 21 was amended at the same time so that tipping-off rules do not block this sharing. Safeguards on confidentiality and use still apply.

Between unrelated VASPs. The Travel Rule is mandatory sharing. Beyond it, sharing customer information or suspicions with another firm needs a legal basis, which some countries provide through specific gateways and others do not. Sharing that a report was filed with an unrelated firm is generally tipping-off. Sharing addresses linked to a hack, without personal data about customers, is common and lower risk.

With partnerships and authorities. Public-private partnerships operate under specific legal arrangements. FATF's Guidance on Private Sector Information Sharing (November 2017), its Stocktake on Data Pooling, Collaborative Analytics and Data Protection (July 2021) and its report Partnering in the Fight Against Financial Crime: Data Protection, Technology and Private Sector Information Sharing (July 2022) describe how such sharing can meet data protection requirements, including through privacy-enhancing technologies that allow joint analysis without exposing raw data.

Secure storage and access

Compliance records need controls proportionate to their sensitivity, often aligned with an information-security standard such as ISO/IEC 27001:

• Need-to-know access, with the STR register and case notes restricted to the compliance team and named managers;
• encryption in storage and transit, and strong authentication;
• audit logs of who viewed or exported records, reviewed regularly;
• integrity: write-once storage or hashed exports for evidence, so records can be shown to be unaltered;
• retrievability: tested ability to produce a customer's full file, with transactions and analytics snapshots, within days of a request;
• outsourcing controls: the firm remains responsible when records sit with a vendor or cloud provider.

Exam focus: R.11 requirements (at least five years, transaction records sufficient to reconstruct transactions, CDD records, account files, correspondence and analysis results kept after the relationship ends, swift availability); crypto-specific records, including dated analytics snapshots and Travel Rule data; legal holds and retention triggers; the core data protection principles and how they apply to AML data; R.2 and the compatibility of AML and privacy rules; handling access requests without tipping-off; the three settings for sharing (group under R.18 and the 2017 changes, unrelated VASPs, partnerships) and the FATF documents on sharing; secure storage, access control, integrity and retrievability.