Tokenisation

What Is Tokenisation?

AUSTRAC explains tokenisation as replacing a card number for example a primary account number with a unique reference number for one or more links in a value transfer chain. AUSTRAC notes tokenisation reduces fraud and data security risks associated with card payments, but allows the ordering institution to trace the payment back to the cardholder.

Critically, AUSTRAC treats a tokenised reference as falling within the definition of “card number” for travel rule purposes. This means that where a transfer is a merchant payment, a refund of a merchant payment, or an ATM withdrawal of money, an institution can satisfy its travel rule card number obligation by passing a tokenised reference provided that reference still allows the card issuer to trace the payment back to the payer’s card.

Tokenisation is not a bypass of the travel rule. It is a permitted representation of the card number within the travel rule framework. The traceability function must remain intact regardless of whether a raw card number or a token is used.

How Tokenisation Works in a Card Payment Transfer Chain

In a typical tokenised card payment, the actual card number is replaced at the point of transaction by a token generated by a payment network or card scheme. This token travels through the value transfer chain  from the merchant acquirer (beneficiary institution) to the card issuer (ordering institution)  in place of the underlying card number.

The card issuer retains the mapping between the token and the original PAN. This means that if any institution in the chain receives a request from law enforcement, a regulator, or another institution for information about the payment, the card issuer can de-tokenise the reference and identify the cardholder.

This architecture is why AUSTRAC recognises tokenised references as satisfying the card number requirement. The security benefit of not exposing the raw PAN across the chain is preserved, and the compliance requirement of traceability back to the payer is also met.

Understanding this mechanism matters for your AML/CTF program design, because the policies and procedures governing travel rule compliance need to account for how card identifiers actually flow through your systems whether as raw card numbers or as tokens.

Where Tokenisation Fits in the Travel Rule Framework

The travel rule generally requires ordering institutions to include payer and payee identity information in transfer messages. For merchant payments, refunds of merchant payments, and ATM withdrawals, AUSTRAC substitutes this requirement with the card number – which can be a tokenised reference.

This means tokenisation is directly relevant to:

• Ordering institutions (card issuers): Must include the card number or tokenised reference in the transfer message for qualifying card-based transfers. The token must preserve the ability to trace back to the payer’s card.
• Intermediary institutions: Will generally receive the card number or tokenised reference when processing a merchant payment, refund, or ATM withdrawal. Must pass it on through the chain and monitor for missing information using a risk-based approach documented in their AML/CTF policies.
• Beneficiary institutions: Must receive the card number or tokenised reference from ordering and intermediary institutions for merchant payments and refunds. Must maintain policies enabling them to provide relevant information to other institutions in the value transfer chain within three business days, and must keep records of individual transactions related to value transfer services.

It is also worth noting that tokenisation of assets is a separate concept. AUSTRAC states that transfers of tokenised shares are subject to the travel rule, and stablecoins are also subject to the travel rule even where they meet the definition of a derivative. The tokenisation discussed in this term relates specifically to card payment tokenisation, not asset tokenisation.

Examples of Tokenisation in Practice

• Example 1 – Smartphone wallet payment: A customer pays using a smartphone wallet (such as a mobile pay app). The merchant and acquirer process a tokenised reference instead of the underlying card number. The transfer message passing from the merchant acquirer back to the card issuer carries the token rather than the PAN. The card issuer can de-tokenise and identify the payer if required.
• Example 2 – Merchant refund: A merchant refund is processed back to the same tokenised reference used for the original payment. The token travels back through the value transfer chain, and the card issuer applies the refund to the original cardholder’s account by mapping the token to the underlying account.
• Example 3 – ATM withdrawal with tokenised card: A cardholder uses a digital card stored on a device to make an ATM withdrawal. The ATM and the processing network handle the transaction using the tokenised reference rather than the physical card number. The transfer message must still carry the card number or tokenised reference as required under AUSTRAC’s travel rule rules.

Legal and Regulatory References

• AML/CTF Act 2006 (Cth), sections 65(2), 66(2) and 66A(10).
• AML/CTF Rules, sections 8–6 and 8–8.
• AUSTRAC travel rule guidance explaining tokenisation in the merchant payment context and confirming that a card number can include a tokenised reference.
• AUSTRAC guidance on when the travel rule does not apply (merchant payment conditions and card number definition).
• FATF Recommendation 16 (updated June 2025) and AUSTRAC’s transition guidance to new global travel rule standards.

Best Practices for Managing Tokenisation Under the Travel Rule

1. Maintain traceability at all times

Ensure the tokenised reference can be traced back to the underlying cardholder relationship when required for investigations or enquiries. This is the fundamental compliance requirement. If your token mapping is managed by a third-party payment processor, confirm contractually that you can access that mapping within the timeframes required for AUSTRAC enquiries and institution-to-institution information requests.

2. Treat token data as sensitive

Even though tokenisation reduces risk, your access controls, retention policies, and incident response procedures should still treat payment identifiers including tokens carefully. A token in the wrong hands can be used to probe a payment system even if it cannot directly reveal a card number. Your ML/TF risk assessment should reflect the residual risk associated with token data.

3. Align assurance activities to travel rule monitoring obligations

AUSTRAC indicates monitoring for missing information can be done through sampling and assurance activities appropriate to business size and risk. Include tokenised card identifiers in that assurance where relevant. If a transfer message arrives without any card reference where one is expected, that is a missing information issue regardless of whether the expected identifier was a raw PAN or a token.

4. Document token handling in your AML/CTF policies

Your AML/CTF program should explicitly describe how your business handles tokenised card references – how they are received, stored, passed on, and retrieved for enquiry purposes. Generic policy language that refers only to “card numbers” without addressing tokens creates ambiguity that can become a compliance gap during an AUSTRAC review.

5. Distinguish card tokenisation from asset tokenisation

Teams working across both card payments and digital assets need to be clear that these are different concepts under AUSTRAC’s framework. Card tokenisation is a permitted representation of a card number within the travel rule. Asset tokenisation such as tokenised shares or stablecoins is a separate area with its own travel rule treatment. Conflating the two in training or policy documents creates avoidable confusion.

6. Train staff on tokenisation’s compliance scope

Staff involved in payment operations, compliance monitoring, or AML training programmes need to understand that tokenisation does not reduce or remove travel rule obligations and it changes how the card identifier is represented. This distinction should be embedded in role-specific training.

Common Challenges

Teams think tokenisation removes compliance obligations. AUSTRAC treats tokenised references as part of the card number concept for travel rule purposes. The obligation to include the card number in the transfer message applies whether the identifier is a raw PAN or a token. Misunderstanding this leads to monitoring gaps and incorrect policy design.

Inconsistent retention of token links across systems, leading to avoidable traceability gaps. Where payment processing is split across multiple platforms or third-party providers, the mapping between tokens and underlying card accounts can become fragmented. This is a common finding in AML health checks for businesses operating card payment services.

Policies that address card numbers but not tokenised references. Many AML/CTF programs were written before tokenised payments became widespread. If your policies refer only to card numbers without addressing tokens, there is a documentation gap that needs to be closed.

Confusing card tokenisation with virtual asset tokenisation. These are distinct concepts under AUSTRAC’s framework. Mixing them in staff training or policy documents creates confusion about which obligations apply in which context.

How Tranche 2 Consultants Can Help

Tranche 2 Consultants can review your payment identifiers, token handling, record-keeping design, and assurance testing approach to ensure your travel rule controls remain both secure and auditable. Our AML/CTF Program service ensures your policies explicitly address tokenised card references — not just raw card numbers — so your documentation reflects how payments actually flow through your systems. Where gaps exist, our AML Health Check identifies them before AUSTRAC does, and our AML Training ensures your team understands that tokenisation changes how the card identifier is represented, not whether the travel rule applies.

Concluding Remarks

Tokenisation is a security control that sits comfortably inside the travel rule framework because it preserves traceability while reducing exposure of card numbers. Your job is to keep the traceability chain intact. That means documenting how tokens are handled, ensuring your systems can retrieve the underlying cardholder mapping when needed, and confirming your AML/CTF policies reflect tokenised payment flows not just raw card numbers.