What Is Data Encryption?

Data encryption converts readable information, called plaintext, into ciphertext using an algorithm and a key. Without the appropriate cryptographic key or authorized access mechanism, the underlying information cannot be read in its original form. 

So, what does “encrypted” mean in operational terms? 

A stolen laptop, an intercepted application programming interface (API) call, or a misconfigured storage bucket yields noise instead of a customer file. Encryption does not stop data from being taken. It removes the value from what gets taken, provided the keys were managed properly. In practice, encryption can fail when keys are exposed, lost, poorly stored, or inadequately managed, even when the underlying cryptographic algorithm remains secure.

Encryption Algorithms That Matter in Financial Services

Two cryptographic approaches are most relevant to financial data protection: symmetric and asymmetric encryption.

Symmetric algorithms use a single key for both encryption and decryption. AES-256 is a widely used symmetric encryption standard for protecting data at rest and is suitable for high-volume financial data environments. Its main operational challenge is secure key distribution and storage, because the same secret key must be available to authorized systems or users who need to encrypt or decrypt data.

Asymmetric algorithms use a mathematically linked key pair. Public-key cryptography supports functions such as authentication and key establishment. Modern secure systems commonly combine public-key cryptography with symmetric encryption. Public-key mechanisms can establish or authenticate a secure session, while symmetric encryption protects the larger volume of data exchanged during that session.

Where Data Encryption Applies Across the AML Workflow

Privacy-enhancing technologies are an emerging area in collaborative financial crime detection. The UK Financial Conduct Authority’s Global AML TechSprint examined how homomorphic encryption could support financial crime information sharing by enabling computations on encrypted data without exposing the underlying information in plaintext.

What Regulators Require

Encryption requirements differ across jurisdictions, but generally assess encryption alongside access controls, key management, data protection, incident response, and operational resilience measures when protecting sensitive information.

The EU General Data Protection Regulation identifies encryption as an example of an appropriate technical and organizational measure under Article 32. Article 32 does not impose a blanket requirement to encrypt every item of personal data. Instead, it identifies encryption and pseudonymization among the measures that organizations should consider in proportion to the risks associated with processing personal data. Financial institutions therefore need to assess the sensitivity of customer and transaction information, as well as the risks associated with how that information is processed, stored, and transferred.

The Digital Operational Resilience Act adds more specific expectations for cryptographic controls within the EU financial sector. Its technical standards address the lifecycle of cryptographic keys, including their generation, storage, renewal, backup, retrieval, revocation and destruction. Therefore, encryption controls also need to cover the full lifecycle of the keys protecting AML records.

FATF Recommendation 16 addresses the information that must accompany certain qualifying transfers and is particularly relevant to payment transparency and virtual asset transfers. Where transfer information contains personal data, institutions also need to apply the data protection and information security requirements that govern the relevant payment, transfer or virtual asset activity. Encryption can form part of those safeguards, although FATF Recommendation 16 should not be presented as a standalone encryption mandate.

Record retention creates another operational challenge. US AML recordkeeping requirements can require certain records to be retained for five years. Encrypted archives therefore need a documented key management process that preserves authorized access to the keys required to decrypt records throughout the applicable retention period. A lost encryption key can make a required record inaccessible, making key management part of the institution’s broader recordkeeping responsibility.

Why Key Management Matters as Much as Encryption

Encryption depends on effective key management. Financial institutions need key management controls covering key generation, storage, access permissions, rotation, backup, recovery, revocation, and destruction, with clear ownership and documented procedures to maintain access to encrypted records. This is particularly important for AML records that must remain retrievable after applications, databases, encryption systems, or responsible personnel have changed.

Preparing AML Data for Post-Quantum Cryptography

NIST finalized its quantum-resistant standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 and FIPS 205 for digital signatures. NIST’s draft IR 8547 proposes timelines for transitioning away from vulnerable public-key cryptography, including the eventual removal of quantum-vulnerable algorithms from approved use. Because IR 8547 remains draft guidance, its proposed timelines should be treated as planning signals rather than final regulatory deadlines. 

A June 2026 US executive order also established a 2030 target for federal agencies to transition high-value assets and high-impact systems to post-quantum key-establishment methods. The requirement is directed at the US federal government, so financial institutions should not treat the date as a universal private-sector regulatory deadline. It is nevertheless a useful planning horizon for organizations managing long-lived sensitive data.

AML records retained for several years may therefore remain sensitive during the period in which organizations transition from current public-key cryptography to post-quantum alternatives. One reason organizations are planning for post-quantum cryptography is the “harvest now, decrypt later” threat. An adversary could capture encrypted data today and attempt to decrypt it in the future if sufficiently capable quantum computers become available. 

For AML records and other sensitive information with long retention periods, the relevant question is therefore whether current cryptographic protections will remain suitable throughout the expected data lifecycle. Because AML records can remain sensitive for years, financial institutions should assess whether current cryptographic protections will remain appropriate throughout the data lifecycle. A cryptographic inventory can therefore help financial institutions identify vulnerable algorithms, long-lived data and systems that may require migration before a formal regulatory deadline applies.

How AML Watcher Handles Compliance Data

Screening output can contain sensitive information about customers and other individuals. Match results may contain sanctions, PEP, adverse media and other risk information. Access to these records should therefore be restricted according to role and business need, with data protection controls applied throughout screening, investigation and case handling. 

AML Watcher’s sanctions screening and case management capabilities provide financial institutions with tools to review screening results, manage risk information and handle related compliance cases within an AML workflow. When assessing an AML technology provider, financial institutions should evaluate how the provider protects data at rest and in transit, manages access, retains and deletes records, manages encryption keys where applicable, and maintains audit records.

Request a demo to explore how AML Watcher can support the institution’s screening and financial crime compliance requirements.