Firms following the FATF Recommendations build a set of obligations that are usually treated as compliance work: customer due diligence, transaction monitoring, sanctions screening, record keeping, suspicious activity reporting and the travel rule for virtual asset transfers. Each of those obligations rests on infrastructure, and the security properties of that infrastructure determine whether the obligation is actually met or merely documented.
This article covers the cloud controls where the security requirement and the AML/CFT requirement are the same requirement, so that one implementation and one piece of evidence can answer both.
Log and record integrity
Record keeping obligations require that transaction and customer due diligence records be retained and available for a defined period, typically five years. The security requirement is the same statement with one word added: retained, available and unaltered.
Practical controls: write audit and transaction records to storage with object lock or equivalent write-once retention, held in an account that the producing workload cannot administer. Separate the identity that writes records from the identity that manages retention policy. Enable and verify integrity validation on the cloud audit trail itself. Confirm that deletion requires a quorum action rather than a single privileged credential, and that any deletion attempt alerts.
The test question we ask is short: which single credential, if compromised, could remove or rewrite the records you would need to answer a supervisory request? On most platforms an answer exists, and it is usually a deployment pipeline role that accumulated storage administration permissions.
Monitoring pipeline resilience
Transaction monitoring and sanctions screening are controls that must operate continuously. In cloud architectures they are usually event-driven pipelines, and event-driven pipelines fail in ways that are silent by design.
Assess the pipeline for completeness first: is there any transaction path that does not produce a monitoring event? Manual adjustments, internal transfers, corrections and administrative actions are the usual omissions. Then assess failure behaviour. If the screening service is unavailable, does the transaction block, queue for review, or proceed? Fail-open on sanctions screening is a control that does not operate under precisely the conditions an attacker would arrange.
Then assess observability of the control itself: dead letter queues that nobody reads, a consumer lag metric with no alert, and a retry policy that silently drops after exhaustion are all ways for monitoring to stop without anyone learning about it until an audit.
Access separation around AML functions
Segregation of duties is an AML control expectation and an access control problem. The specific separations worth enforcing technically rather than by policy:
- Staff who can approve a customer cannot alter the screening rules that approved them
- Staff who can close an alert cannot modify the alert record afterwards
- Engineers who deploy the monitoring service cannot approve customers or close alerts
- Nobody holds both the ability to move value and the ability to alter the record of it
In cloud terms this is a mapping exercise between application roles and cloud IAM roles, followed by a privilege graph analysis: a role that can modify another role's policy has every permission that role could ever be granted, and that path defeats a segregation model that looks correct on paper.
Data residency and transfer
Customer due diligence data frequently carries jurisdictional constraints, whether from data protection law, local financial regulation or a licence condition. Cloud makes residency easy to state and easy to violate incidentally — through a backup replicated to a secondary region, a managed service that processes in a different region, a log aggregation pipeline that ships everything to a single global bucket, or a support tool with global read access.
Enforce residency with policy controls at the organisation level rather than with configuration discipline in each account, and verify by inspecting where data actually lands rather than where the architecture intends it to.
Key management for retained records
Long retention periods and encryption interact awkwardly. A five-year record encrypted with a key that was rotated and destroyed after two years is not a retained record. Where customer-managed keys are used, confirm that the retention schedule for keys matches or exceeds the retention schedule for the data, that key deletion is subject to a waiting period and an alert, and that recovery has been tested.
Travel rule infrastructure
For virtual asset service providers, originator and beneficiary information must be transmitted with transfers, which means an integration with counterparty institutions over channels that carry personal data. Assess authentication of counterparties, transport security, storage of received data with the same protections as data you collected yourself, and behaviour when a counterparty cannot be reached or fails verification. The failure mode is again the interesting part: proceeding without the required information because the integration timed out is a documented breach waiting to be discovered.
Evidence, not assertions
Each control above should produce an artefact a reviewer can inspect: a policy document exported from the cloud provider, an access review record, a test result showing fail-closed behaviour, a retention configuration, an integrity validation report. Controls that operate correctly but produce no artefact will be treated as absent during a review, and rebuilding evidence retrospectively is substantially more expensive than emitting it as you go.
The most efficient sequencing we see is to define the evidence artefact first and then build the control to produce it. Firms that do it the other way round usually implement the control twice.
