You probably collect more customer data than you need to. Here's what to do about it.

Let me ask you a few questions that might be uncomfortable to sit with:

• When you onboard a new customer, do you keep a copy of their passport or driver's licence? Or do you record what you verified?
• When you use biometric face-matching to confirm identity, do you have the customer's consent for that?
• Does your privacy policy outline what you collect, how you use it and why?
• Are there customer records sitting in folders that contain personal information you collected years ago but don't actually need anymore?
• If a regulator asked you to demonstrate that every piece of personal data you collected was reasonably necessary for your AML/CTF obligations, could you?

If any of those made you wince, you're not alone. Australia's AML/CTF reforms, combined with updated guidance from the Office of the Australian Information Commissioner (OAIC), have clarified something that many reporting entities have been struggling with for years: collecting more data than you need isn't just unnecessary. It's a compliance problem.

The good news is that fixing it is more manageable than it sounds. I'll outline some practical things you can do to manage it, but first: I want to outline what's recently changed in Australia and why the Privacy vs AML/CTF dilemma just got a whole lot simpler.

Collect only what's necessary

Under the Privacy Act 1988 and the Australian Privacy Principles (APPs), you're only permitted to collect personal information that is "reasonably necessary" for your functions or activities. That's not a vague suggestion. It's a legal threshold.

The OAIC's updated guidance confirms that AML/CTF obligations must be balanced with the requirements of the Privacy Act, including the APPs. Compliance with the AML/CTF regime requires collecting and verifying personal information that is proportionate to the ML/TF risk the customer presents. Privacy obligations cap how much you can collect for that purpose.

In plain terms: the data you collect should match the risk. Low-risk customer, lower-risk data collection. High-risk customer, more thorough. You should never collect everything, just in case.

The test under APP 3.2 is objective: would a reasonable, properly informed person agree the collection is required? In the AML/CTF context, that means your actual obligations under the Act and AUSTRAC's guidance set the floor, not the ceiling.

If you've been running every single customer through the same maximum-data-capture process regardless of their risk profile, that's where the problems start.

One of the principles we built BNDRY around was privacy-by-design, where we give our customers the tools to reduce their data collection risk by capturing and verifying details directly from the customer. One of the biggest risks facing companies today is what we call PII-proliferation, where personally-identifiable-information (PII) is captured in one system, verified in another, recorded in another, copies stored, copies sent… your customer's sensitive data can quickly become a huge data breach and compliance risk. Design your customer data processes to solve this problem at the time of data collection, and not by doing expensive and time consuming privacy audits or file clean ups.

Storing Customer Data is not the same as Storing Evidence

A lot of reporting entities have been keeping copies of identity documents, passports, licences, Medicare cards and so on, as part of their customer due diligence (CDD) records. It feels thorough. It feels like evidence. It's now; in most cases, more than the law requires and could be in breach of the APP.

As Allens noted in their March 2026 analysis of the OAIC guidance: from 31 March 2026, retaining copies of identity documents to comply with AML/CTF requirements is no longer justified. But that doesn't mean you abandon collecting and verifying customer information altogether.

The amended Act does not require reporting entities to keep copies of identity documents used during the CDD process. It requires records of what was done to identify the customer, and what identifying information the customer presented.

That distinction matters. You need to record that you verified identity, what information you were presented with, and how you verified it. You don't need the document itself or a photocopy of it. Keeping it now means storing more personal data than necessary, which creates its own Privacy Act exposure under APP 11. That provision requires you to protect personal information and to destroy or de-identify it when you no longer need it.

If you're still building a filing system full of driver's licence and passport scans that date back to 2021, this process is worth reviewing.

‍

Biometrics: consent is required, and so is a fallback

Facial recognition and liveness detection have become standard in identity verification. They're useful: they confirm the person holding the phone matches the document and make spoofing harder. But they collect biometric information, which is sensitive information under the Privacy Act, and the OAIC has been clear on what that means.

The OAIC expects consent to be obtained for biometric ID verification for KYC purposes. Organisations need to consider alternatives where consent is not provided.

Two things follow from that. First, if biometric verification is built into your onboarding flow without a meaningful consent step, you have a problem. The customer needs to understand what you're capturing and agree to it. Second, you need an alternative pathway. If a customer declines biometrics, you can't simply refuse to onboard them. You need another way to verify identity that doesn't require biometric data. Oftentimes, this will require a trained team member to run the customer through a manual verification process. You'll still need to record and store your evidence, but the tools and approaches you use as part of any fallback process will be different.

This isn't about making digital systems or biometrics harder to use. It's about having a clear legal basis when you do use them. Consent is the cleanest path.

The data you're holding that you shouldn't be

Beyond documents and biometrics, there's a broader question about what happens to personal data after your compliance checks are complete, and whether it ends up somewhere it shouldn't.

Here's a scenario that plays out regularly: a customer is onboarded, KYC is completed, identity documents are captured, risk ratings are set. Then that same data ends up in a general share drive or folder, accessible to the sales team, the marketing team and anyone with a login. AML/CTF data and any PII collected specifically for compliance purposes shouldn't be mixed in with general business data. Records must be retained for seven years after the end of a customer's relationship with the entity. That retention obligation means the data needs to be kept. It also needs to be kept securely, in a system with appropriate access controls, away from where it can be casually accessed or misused.

APP 11 makes this clear: you must take reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification or disclosure. And when you no longer need it, you must destroy or de-identify it.

The good news? BNDRY's data retention policies have been designed with both AML/CTF and the Australian Privacy Principles in mind. Making it easy to meet both obligations without complex process and system redesign.

What "tipping off" means for your privacy processes

When you build your privacy compliance processes, giving customers access to their personal data on request and notifying them about what you've collected, those processes need to avoid an AML/CTF conflict.

When implementing privacy compliance measures, including transparency obligations and responding to personal information access requests, organisations must ensure this doesn't create a "tipping off" risk. That means not disclosing the existence of any investigations or Suspicious Matter Reports (SMRs) to the customer.

In practice: if a customer submits a subject access request asking what personal information you hold about them, your response needs careful design. You can acknowledge what KYC data you hold. You cannot confirm or deny whether you've submitted an SMR. This is an area where your privacy processes and your AML processes need to be designed together, not as separate workstreams.

‍

What a compliant program actually needs to do

A compliant approach to customer data in the current environment needs to cover several things:

• Collect to the risk level. What you collect should match the customer's ML/TF risk and the service you're providing. Running every customer through maximum-data-capture KYC when the risk doesn't justify it creates exposure.
• Record verification outcomes, not documents. Keep a record of what you verified and how. Don't default to retaining copies of identity documents.
• Get consent for biometrics, and have a fallback. Build a clear consent step into any biometric verification flow. Provide an alternative for customers who decline.
• Keep compliance data separate. AML/CTF personal data belongs in a secure, access-controlled environment, not in your general share drives.
• Delete or de-identify on schedule. After the seven-year retention period, or earlier if you no longer need the data, clean it up. Accumulating personal data past its use-by date is itself a risk.
• Design SMR processes into your privacy responses. Your processes for responding to customer data requests need to account for the possibility that an SMR exists and that disclosing it is prohibited.

None of this requires a complete rebuild, but it does require systems that were designed for these requirements rather than adjusted to fit them after the fact.

Where BNDRY comes in

BNDRY was built around the problem this article describes. The platform handles document collection, data extraction, identity verification and biometric checks through a configurable onboarding flow that includes consent steps. After verification, it records what's required: extracted data fields, verification outcomes, risk assessments. It doesn't default to retaining full document copies for the sake of it.

Sensitive PII is stored in an encrypted, access-controlled vault, separate from general business data, with audit trails for every access event. Retention policies can be configured to flag or destroy records at the end of their required retention period.

Because AML/CTF data stays in its own environment with defined access controls, a compliance record doesn't end up visible to people it shouldn't reach.

If your current system was built to collect everything and store it indefinitely, or doesn't separate compliance data from your share drives, it's working against you on the privacy side of the ledger.

Where things stand

The AML/CTF reforms and the OAIC's updated guidance have confirmed something that was always the case: collecting more customer data than you need is a liability, not a safeguard. The obligation is to collect proportionately, verify properly, store securely, and delete when the time comes.

The businesses getting this right have systems where the right data is collected, stored where it belongs, and removed when it should be.

‍

Further reading:

• OAIC - Privacy guidance for reporting entities under the AML/CTF Act
• Allens - Key privacy takeaways from the OAIC's updated AML/CTF guidance (March 2026)
• AUSTRAC - AML/CTF Reform

‍