What mistakes do crypto businesses make when preparing for Australia’s Travel Rule and AML reforms?

Why This Matters for Security Teams

Australia’s travel rule and broader AML reforms are not just a policy update for compliance staff. They change how crypto businesses identify customers, capture counterparty data, approve transfers, and keep evidence for later review. If those controls are bolted on late, the organisation usually ends up with gaps between legal obligations, product design, and operational reality. That creates exposure in onboarding, transaction screening, and investigations, especially where high-volume flows or wallet-to-wallet transfers are involved.

The practical risk is that teams focus on a filing deadline instead of the control design needed to support it. Good implementation requires data governance, escalation paths, and systems that can preserve the provenance of transaction decisions. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it maps cleanly to logging, access control, auditability, and information handling expectations that underpin a defensible AML programme.

In practice, many crypto businesses discover their Travel Rule weaknesses only after a counterparty request, suspicious transaction review, or regulator query exposes missing data and inconsistent records, rather than through intentional control testing.

How It Works in Practice

Preparation should start with a data flow map of every transfer path where the Travel Rule or AML obligations may apply. That means identifying where originator and beneficiary information is collected, who validates it, where it is stored, how long it is retained, and which systems can block or release a transaction if data is incomplete. The most common implementation mistake is assuming the compliance team can define this in isolation. In reality, product, engineering, operations, legal, and financial crime teams all need a shared operating model.

A practical build-out usually includes:

• Rules for when transfer data must be collected, enriched, screened, or shared.
• Verification steps for self-hosted wallets and other higher-risk transfer types.
• Clear handling for unverified or partially verified transfers, including escalation and rejection paths.
• Retention controls so the business can evidence decisions, not just move funds.
• Counterparty due diligence so information sharing is reliable across VASPs and other obligated entities.

The AML side should be aligned to the FATF Recommendations — AML and KYC Framework, because Travel Rule implementation without a broader risk-based AML model tends to produce inconsistent outcomes. FATF guidance is particularly important where firms need to distinguish routine transfers from higher-risk activity, and where local reform timelines are still being operationalised.

Teams also need technical controls that make compliance repeatable. That includes identity-linked transaction records, access restrictions on casework data, tamper-evident audit logs, and monitoring that flags when required information is missing or altered. These controls tend to break down when transfer architecture is fragmented across multiple wallets, third-party processors, and loosely governed manual exception workflows because no single system owns the full compliance decision.

Common Variations and Edge Cases

Tighter compliance controls often increase onboarding friction and operational overhead, requiring organisations to balance faster customer experience against stronger verification and recordkeeping. That tradeoff becomes more visible in crypto businesses serving both retail users and institutional counterparties, where the same rule set may not fit every product path.

Best practice is evolving on self-hosted wallet verification, especially where ownership proof is indirect or where customers use multiple wallets. Some firms overcompensate by applying rigid checks to every transfer, which can create unnecessary delays and false positives. Others go too far in the opposite direction and accept weak evidence because they want to preserve conversion rates. Neither approach is sustainable if the business cannot explain its risk decisions later.

Another edge case is cross-border activity. Australian reform may be the trigger, but firms often also have to consider how foreign VASP counterparties, local privacy obligations, and internal AML thresholds interact. The right answer is not always full automation. In higher-risk cases, current guidance suggests a hybrid model where automation handles standard flows and trained staff review exceptions, especially when source-of-funds issues, sanctions concerns, or unusual wallet behaviour appear.

For organisations with agentic or automated transaction workflows, the identity and approval of the system itself becomes part of the control picture. If an automated workflow can trigger release, block, or enrichment actions, its permissions and audit trail need governance as carefully as a human operator’s.

Related resources from NHI Mgmt Group

• Who is accountable for ensuring crypto monitoring controls meet travel rule and AML requirements?
• Why do KYC, KYB, AML screening, and Travel Rule controls need to work together in crypto payments?
• How should crypto exchanges balance onboarding speed with KYC, AML screening, and Travel Rule obligations?
• How should crypto businesses implement Travel Rule compliance in customer apps without causing excessive user drop-off?