Storing KYC in a CRM: what Australian law allows

The honest answer is mostly do not. A general customer relationship management system is built for sales access, not least privilege, which makes it a poor home for identity documents and customer due diligence evidence. Keep a compliance status flag in the CRM so staff know whether they can proceed, and hold the underlying evidence in a controlled system with a proper access record.

TL;DR:

• A CRM is built for broad sales access, which makes it a poor home for identity documents and customer due diligence evidence; keep those in a controlled system with its own access record.
• The AML/CTF Act requires CDD records to be kept until seven years after the business relationship ends (section 111), while APP 11 requires reasonable steps to destroy or de-identify personal information once it is no longer needed, unless a law requires it to be kept.
• CRM systems should only hold a status flag and a reference to the evidence stored securely elsewhere, not the full documents themselves.
• AUSTRAC expects sensitive records, such as details of customer identification, to be stored securely with access limited to authorised staff; encryption, role-based access and automated retention are practical ways to show it.
• A typical workflow involves collecting and verifying identity documents, storing them in a vault, then updating only the status in the CRM for operational use.

Table of Contents

• What Australian law requires for KYC records and retention
• Privacy Act duties and APP 11 pull the other way
• Why general-purpose CRMs are a poor place for KYC documents
• What belongs in the CRM and what belongs in a vault
• Technical and organisational controls the vault needs
• The workflow from intake to long-term retention
• Applied example: status in the CRM, evidence in the vault
• An implementation checklist for compliance officers
• Why segregating KYC data is the pragmatic answer, not the strict one
• Putting the vault and CRM pattern into practice
• Sources
• FAQ

What Australian law requires for KYC records and retention

The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) sets out what reporting entities must record and how long they must keep it. Records of customer due diligence must be kept until seven years after the business relationship ends, or after an occasional transaction is completed (section 111), and transaction records for seven years from when they are made (section 107). AUSTRAC’s record keeping guidance adds that sensitive records, such as details of customer identification, should be stored securely with access limited to authorised staff. That is a long window for any document to sit inside a system that was never designed to manage retention schedules.

KYC information itself has a specific meaning. Under the AML/CTF Act, it is information that gives reasonable grounds to establish the matters in section 28(2), such as who the customer is, or that lets the entity identify or assess the customer’s money laundering or terrorism financing risk. That is broader than a scanned licence, and section 111 separately requires records of the analysis and decisions behind each customer.

The Act also allows collection and verification work to be carried out by someone other than the reporting entity itself.

• Section 37 lets an agent of the reporting entity collect and verify KYC information on its behalf.
• Section 37A lets it rely on another person’s collection and verification under a written agreement or arrangement, which must be assessed regularly (section 37B).
• Section 38 covers reliance in other circumstances, case by case, where the entity has reasonable grounds to believe reliance is appropriate given the risk.

For firms using an agent, a settlement partner or a related entity to collect identity documents, these sections, covered in our CDD reliance checklist, determine who remains responsible for the underlying evidence and who can simply rely on someone else’s verification. That responsibility does not disappear because the documents happen to sit in a shared CRM.

Privacy Act duties and APP 11 pull the other way

Australian Privacy Principle 11 requires an APP entity to take reasonable steps to protect personal information from misuse, interference and loss, and to destroy or de-identify personal information once it is no longer needed for any authorised purpose. Under the Australian Privacy Principles, that destruction duty has an exception where a law requires the information to be retained, which is exactly the position an AML/CTF reporting entity is in. AUSTRAC’s guidance adds that every reporting entity must comply with the Privacy Act, even a small business.

One retention period, two opposing pressures: the AML/CTF Act requires CDD records to be kept until seven years after the business relationship ends, while APP 11 pushes firms to destroy or de-identify personal information as soon as it is no longer needed. A system that cannot tell the difference between these two clocks will tend to either over-retain personal information well past its purpose or under-retain records a supervisor expects to see.

The OAIC’s guide to securing personal information sets out practical steps for securing information and for destroying or de-identifying it appropriately. Reconciling the two obligations means running a retention and de-identification workflow that is scoped specifically to the legal minimum, rather than leaving identity documents in a general system indefinitely because nobody set a deletion date.

A few scenarios make the tension concrete.

• A licence photo attached to a CRM contact record stays visible to every staff member with access to that record, long after the transaction has settled.
• A CRM export used for a marketing list or a data migration can carry identity documents along with it, with no record of who saw the export.
• A CRM integration that syncs contact records to a third-party tool can replicate identity documents into a system the compliance team has never audited.

Why general-purpose CRMs are a poor place for KYC documents

A CRM exists to give sales and service staff broad access to customer records, which is the opposite of the least-privilege model that identity documents need. Identity documents attached to a CRM record are visible to every user who can open that record, get replicated into exports and integrations, and are difficult to delete on a defined retention schedule. That is a Privacy Act exposure as much as an AML one, and it tends to show up in a handful of predictable ways.

1. Visibility is too broad. Most CRMs grant access at the record or team level, not at the document level, so a passport scan attached to a client file is visible to anyone who can open that file.
2. Exports carry documents with them. A CSV export, a backup or a data migration typically pulls attached files along with contact fields, spreading identity documents into places nobody is tracking.
3. Integrations replicate data silently. A CRM connected to a marketing platform, an accounting tool or a helpdesk can sync attachments as a side effect of syncing contact records.
4. Deletion is manual and error-prone. Few CRMs let you set a legally precise retention date on an individual attachment, so deletion depends on someone remembering to do it.
5. Audit trails are shallow. Standard CRM activity logs rarely capture who viewed a specific attachment, when, and why, which leaves little to show a supervisor asking about access history.

Pro Tip: Search your CRM for file attachments with extensions like .jpg, .png and .pdf on contact or deal records before you do anything else. What you find will tell you how big the problem already is.

What belongs in the CRM and what belongs in a vault

The fix is not to abandon the CRM. It is to be precise about which pieces of information belong there and which do not. The CRM is the tool your staff already use to manage a relationship and decide what to do next, so it should hold just enough to support that decision, nothing more. Our comparison of three CRM compliance architectures covers how vendors build the link between the two, and secure client intake covers tagging documents by retention purpose as they arrive.

• In the CRM: a compliance status flag (verified, pending, escalated), the date it was last updated, the next required action and the permission it unlocks (proceed, hold, escalate to enhanced due diligence).
• In the vault: copies of identity documents where you keep them (AUSTRAC does not require copies, and you can record their details instead), verification results, biometric and liveness data, sanctions and PEP screening outcomes, beneficial ownership records and the full audit trail behind each determination.
• Between the two: a pointer or reference identifier only, never the document itself, so the CRM can link to the record without holding a copy of it.

This is the pointer pattern: the CRM answers “can this person proceed?” in one glance, while the vault holds everything a supervisor would need to see if they asked how that answer was reached.

Technical and organisational controls the vault needs

A vault is only as good as the controls wrapped around it. AUSTRAC and the OAIC do not prescribe a technical architecture, but secure storage, restricted access and defensible retention point to a sensible baseline.

• Encryption in transit and at rest, with keys managed separately from the data they protect.
• Role-based access control, so only staff with a genuine need can open a CDD record, and administrator accounts require multi-factor authentication.
• Tamper-evident audit trails that record who accessed or changed a record and when, exportable in a form a supervisor can review.
• Retention automation keyed to the legal dates, such as seven years after the business relationship ends for CDD records, not to a staff member’s memory.
• Deletion or de-identification workflows that produce proof, so the firm can show a record was disposed of correctly rather than simply asserting it.
• Secure ingestion at the point of capture, including a hash of the document, metadata about how and when it was collected, and a chain of custody from collection through to officer approval.

Pro Tip: Ask any vendor how they prove a document was deleted, not just that it was deleted. A retention workflow without proof of deletion is a policy on paper, not a control.

The workflow from intake to long-term retention

Separating the CRM from the vault only works if staff follow a consistent sequence, with clear ownership at each step.

1. Collection: the collector, who may be an agent under section 37, or a third party relied on under section 37A or 38, gathers identity documents and customer information at onboarding.
2. Verification: the verifier checks the information against reliable and independent sources, as the firm’s AML/CTF policies set out, and records the method used.
3. Officer approval: a compliance officer reviews the verification outcome and approves the determination before the customer relationship proceeds.
4. Vaulting: the approved evidence, screening results and reasoning are stored in the vault with a timestamp and an audit entry.
5. Status update: a single status flag, verified, pending or escalated, is pushed to the CRM so operational staff know whether to proceed.
6. Ongoing monitoring: re-screening and periodic review update the vault record, with the CRM status refreshed only when the outcome changes.
7. Retention and disposal: the vault applies the retention period (for CDD records, seven years after the relationship ends) and executes deletion or de-identification once it lapses, generating a disposal record.

Where an agent or a relied-on third party has done the original collection, the vault should hold the reliance documentation itself, not just the outcome, so the firm can demonstrate it met its obligations under sections 37, 37A or 38 if asked.

Applied example: status in the CRM, evidence in the vault

AML Guard’s REX integration follows this pattern: it pushes compliance status indicators so agency staff can see whether a listing is clear to proceed, and never pushes the underlying CDD data into the CRM. The evidence stays in AML Guard, with a tamper-evident audit trail, which is the same separation this guide describes.

• Status indicators only move into REX; the underlying CDD evidence stays in AML Guard.
• AML Guard keeps an 8-year tamper-evident audit trail, above the Act’s seven-year minimum.
• An officer approves each determination before customer due diligence proceeds, so the platform automates the lookups without automating the judgement.
• Guided program documents (the risk assessment and AML/CTF policies, with the compliance action plan and training manual generated alongside) come from the same underlying answers, which keeps them consistent for a supervisor’s review.

An implementation checklist for compliance officers

Untangling identity documents from a CRM is a project, but it does not need to start with a large system change.

1. Immediately, stop new uploads of identity documents to the CRM and pause any integration that could be replicating them elsewhere.
2. This week, search existing CRM records for attached files and tell staff why the practice is changing.
3. This month, stand up or configure a vault for customer due diligence evidence and map each CRM record to a vault pointer.
4. Before go-live, set retention automation to the legal minimum and update internal procedures to reflect the new split.
5. Ongoing, schedule periodic audits, retrain staff each time the process changes and test that deletion proofs are actually produced when a record’s retention period lapses.

Pro Tip: Run one deletion test before you rely on the workflow for real records. A retention rule that has never actually deleted anything is unproven, whatever the settings say.

Why segregating KYC data is the pragmatic answer, not the strict one

Segregating status from evidence is not bureaucratic caution; it is the simplest way to meet both frameworks. AUSTRAC requires CDD records to be kept until seven years after the relationship ends, and APP 11 requires reasonable steps to destroy or de-identify personal information once no law requires it to be kept. A CRM that holds both status and documents makes it hard to apply the right clock to each record.

Smaller firms without dedicated compliance infrastructure sometimes keep a scanned document in a client file temporarily during onboarding. That is a manageable short-term risk only if the document is moved into a controlled system within days and the CRM copy is deleted, not a permanent filing method. AUSTRAC expects sensitive records to be stored securely with access limited to authorised staff, which a shared CRM record rarely achieves.

Putting the vault and CRM pattern into practice

Reporting entities that want this separation without building it themselves have a direct option. AML Guard runs customer due diligence, screening and evidence storage in one controlled platform with a tamper-evident audit trail, and pushes only compliance status indicators into REX, never the underlying CDD data.

• Identity verification, screening and beneficial ownership evidence stay in a controlled vault, with the CRM showing status only.
• Guided program documents help keep the risk assessment, policies and training consistent for supervisory review.
• A transaction party can pay for their own check, and each eligible CDD check fee earns a credit against that calendar month’s AML Guard subscription, capped at the subscription fee.

If your team is still deciding whether to fix an existing CRM habit or start with the right structure, take a look at AML Guard’s features, check the pricing page for the plan that fits your firm, or book a demo to see the vault and status pattern configured for your workflow.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Record keeping overview | AUSTRAC
• Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth)
• Read the Australian Privacy Principles | OAIC
• Initial CDD for individuals | AUSTRAC

FAQ

Is KYC a legal requirement in Australia?

Yes. Reporting entities covered by the AML/CTF Act must carry out customer due diligence and keep the resulting records until seven years after the business relationship ends. This applies to the Tranche 2 sectors now in scope, including real estate, legal, accounting, and trust and company service providers.

What is the best software for KYC?

There is no single best system for every firm, since needs vary by sector, volume and risk profile. Look for a platform that separates compliance status from CDD evidence, applies retention rules automatically, and keeps a tamper-evident audit trail rather than relying on a general CRM to do all three.

What are the 5 stages of KYC?

Definitions vary slightly across guidance, but a common version covers customer identification, verification of that identity, risk assessment, ongoing monitoring, and record keeping. The AML/CTF Act frames these as connected obligations rather than a strict numbered sequence.

What documents are required for KYC in Australia?

The exact documents depend on the customer type and the reporting entity’s AML/CTF policies, but the underlying requirement is to collect information that provides reasonable grounds to establish the required matters. AUSTRAC’s guidance on initial CDD for individuals says you are not required to keep copies of the documents you verify against, and can instead record their details.

Recommended

• AML/CTF Compliance Checklist for Real Estate Agents: What You Need Before 1 July 2026
• Tranche 2 customer due diligence in Australia
• AML/CTF Program Documents for Tranche 2
• What Is an AML/CTF Program? A Plain-English Guide for Property Professionals