Blog

Tranche 2

What Seven-Year AML/CTF Record Keeping Requires at Enterprise Scale

Seven years is a core retention period, but the clock does not start at the same point for every record. What a defensible records schedule has to define.

Seven years is the figure everyone remembers. The part that causes problems is what the seven years runs from, because the Act sets several record-keeping obligations with different trigger points. A schedule that says keep everything for seven years has not answered the question it appears to answer.

When does the clock actually start?

The AML/CTF Act contains multiple record-keeping obligations with different trigger points. Section 116, for example, requires reporting entities to keep records reasonably necessary to demonstrate compliance with Part 1A, and to retain them until seven years after the record is no longer relevant to those obligations. Other customer and transaction records carry their own retention rules.

The enterprise mistake is to write a single instruction to keep everything for seven years without defining what the seven years runs from. That sentence passes a policy review and gives the records team nothing to implement.

This matters most in long customer relationships. A document created at onboarding may remain relevant well beyond its original date, and the statutory retention period may begin from a later event than the one that created the record. A retention rule keyed to creation date will therefore dispose of some records too early and hold others long past any need.

What should a records schedule define?

Six things per record class, and the schedule is only usable once all six are present.

FieldWhy it is needed
Record classDefines what is being governed
Legal basisIdentifies the obligation the retention serves
Creation eventWhen the record comes into existence
Retention triggerWhat starts the clock, which is often not creation
System of recordWhere the authoritative copy lives
Authorised disposal processWho may delete, and on what approval

The retention trigger is the column most often left implicit, and it is the one that determines whether the schedule is correct. The system of record column tends to expose the second problem, which is the same evidence existing in three places with no agreement on which one governs.

Evidence and accessibility, not storage technology. Neither the Act nor AUSTRAC guidance creates a universal rule that AML/CTF records must be held in an immutable system, or that spreadsheets automatically fail regulatory scrutiny. Claims of that kind go beyond the current requirements and are usually made by someone selling a system.

What AUSTRAC does expect is that reporting entities make and keep records demonstrating how obligations are met. Its guidance points to records such as governance decisions, risk assessments, training registers, customer due diligence evidence, programme reviews and independent evaluation reports.

The practical question is whether the organisation can show the correct record, its context and its integrity when asked. Context and integrity are the two that trip people up, because a document produced without the policy that applied at the time, or without a reliable account of whether it has been altered, answers less than it appears to.

Why do spreadsheet-only environments become fragile?

A spreadsheet can be an entirely appropriate tool for a narrow task. The difficulty is relying on spreadsheets as the primary evidence architecture at enterprise scale, where a predictable set of weaknesses appears.

Unclear ownership and competing versions. Manual changes with no reliable decision history. Weak linkage between a customer, the screening result and the final decision. Inconsistent access controls across shared drives.

Then the ones that surface only under review: difficulty proving which policy or risk model applied at the time, poor support for ongoing monitoring and alert history, and slow retrieval when an assurance team samples a large number of files.

Those are operational and evidentiary risks. None of them is a statement that a spreadsheet is unlawful, and the distinction matters because overstating the position is what makes compliance advice easy to dismiss.

The useful internal test is not what tool is in use but how many people could produce the same answer from it. If one person maintains the file and only that person can explain its structure, the control depends on an individual rather than on a process, and that is true whatever the file format.

How should the audit trail be designed?

Around decisions, not documents alone. A defensible customer record should let someone reconstruct the decision that was made.

That usually means preserving the information collected, the verification source, the beneficial owners identified, the screening result, the potential-match review, the risk rating, any enhanced due diligence, the approval or escalation, monitoring events, and material changes across the relationship.

The record should also identify who performed or approved each step and when. Time stamps and version histories are useful control features precisely because they make reconstruction easier, even where the law prescribes no particular technical format. That is the honest case for them, and it is a strong enough case without inventing a rule.

Who needs to agree on this?

More functions than usually do. Compliance, legal, information security and technology should agree the system of record for each material evidence type, rather than each assuming a different answer.

They also need to define access permissions, backup arrangements, legal holds, data migration controls and deletion rules. Deletion is the one most often missing, and an organisation that cannot dispose of records on an authorised basis tends to keep everything indefinitely, which creates its own privacy and discovery exposure.

Our Tranche 2 checklist sets out the record-keeping standard alongside the rest of the programme obligations.

What happens when a system is replaced?

The audit trail breaks quietly. If an AML/CTF platform is replaced, the migration plan has to preserve historical evidence for the required retention period.

Exporting only current customer status, while losing prior alerts, decisions or the policy context that applied at the time, leaves a system that looks complete and cannot answer a question about a decision made two years ago.

Treat migration as a records event with its own sign-off, not as a technology project with a data-transfer task attached. The test is whether a sample of pre-migration decisions can still be reconstructed after the cutover.

The same applies to a change of policy or risk model rather than of system. If the risk rating methodology changes, decisions made under the previous version still need the previous version available to be understood. Keeping superseded policies alongside the records they governed is part of the retention obligation rather than a housekeeping preference.

Where does technology fit?

Screening and monitoring records, review decisions and reporting form part of an enterprise AML/CTF audit trail, and centralising them makes evidence more consistent and considerably faster to retrieve than ad hoc local files. Retrieval speed is a real assurance concern rather than a convenience, because a control whose evidence takes days to assemble is fragile even when the evidence exists.

The organisation still needs a wider records-management framework covering programme governance, training, regulatory reports, legal records and other evidence that sits outside any screening platform. The Tranche 2 hub covers the rest.

Important information

This article provides general information about Australia's AML/CTF framework and does not constitute legal advice. Whether an obligation applies depends on the designated services provided and the circumstances of the business.

Retention periods and their trigger points depend on the specific obligation and the record in question, so build your schedule on advice about your own obligations rather than on a single headline period. Reporting entities remain responsible for meeting their obligations under the AML/CTF Act, the Rules and applicable AUSTRAC guidance, and the Act is on legislation.gov.au.

FAQ

Common questions.

Does everything have to be kept for seven years from creation?
Not necessarily from creation. The Act contains multiple record-keeping obligations with different trigger points. Section 116, for example, requires records reasonably necessary to demonstrate compliance with Part 1A to be kept until seven years after the record is no longer relevant to those obligations. Other customer and transaction records have their own rules.
Are spreadsheets non-compliant for AML/CTF records?
No. Neither the Act nor AUSTRAC guidance creates a universal rule that records must sit in an immutable system, or that spreadsheets automatically fail regulatory scrutiny. Those claims go beyond the current requirements. The question is whether the organisation can show the correct record, its context and its integrity when asked.
Do records have to be time-stamped or immutable?
There is no universal rule requiring that. Time stamps and version histories are useful control features because they make reconstruction easier, but they are a design choice for managing risk rather than a prescribed technical format.
What should a records schedule actually define?
For each record class, the legal basis, the creation event, the retention trigger, the system of record and the authorised disposal process. Writing keep everything for seven years without defining what the seven years runs from is the common enterprise mistake.
What happens to the audit trail if we replace our AML platform?
The migration plan has to preserve historical evidence for the required retention period. Exporting only current customer status, while losing prior alerts, decisions or the policy context that applied at the time, breaks the audit trail even though the current data looks complete.

See MemberCheck against your own risk data.

Book a walkthrough with our compliance team and screen a real case in the first session.