Avoid a single label for every service
AUSTRAC provides a virtual-asset service provider industry page and separate guidance on designated services and transitional rules. The term virtual assets does not explain every business activity or when each obligation applies. Start with the actual service, parties and role. This guide helps organise that review. It does not determine whether a token, wallet arrangement or platform function is captured. Nor does it assume all new reporting duties began together. Read current service and transition guidance before making an individual decision.
The service range is wider than exchange
AUSTRAC’s overview lists exchange between money and virtual assets, exchange between virtual assets, arrangements for those exchanges, and safekeeping. It also covers specified transfer roles and financial services connected with participating in an offer or sale. This explains why a platform’s service inventory matters: the scope is wider than a simple cash-to-crypto shop. A new custody or transfer feature may change the relevant service. Apply the actual designated-service conditions and transitional rules rather than infer scope from the product’s marketing label.
- Exchange
Describe what is exchanged and who arranges it.
- Custody
Identify any safekeeping role.
- Transfer
Identify the transfer role and current transition conditions. The product name does not settle scope.
Map features to actual services
Read this visual with the source conditions and explanation in this section.
Separate evidence questions. An answer to one does not settle the others.
Worked example: a new wallet feature
Imagine a platform adds a feature that changes how customer value moves to an external wallet. The example team records the new process before relying on its earlier service assessment. It identifies the provider role, information available and unresolved questions about the destination. The feature may require a different analysis from the existing product. The example does not decide the classification or impose a rule for every external wallet. It shows why a software change can require a fresh service and control review.
Keep technical evidence understandable
The example team stores a readable explanation alongside relevant transaction references and system information. A reviewer should be able to understand the business event without decoding an internal engineering label. If a technical tool supplies a risk indicator, record its limits and the human decision made from it. This is a proposed evidence practice, not an endorsement of any tracing vendor. A technical association is not automatically proof of identity, ownership or wrongdoing. Keep the conclusion proportionate to the information actually available.
Control the transition work
A useful transition register names the service, current source, applicable date and owner of the implementation work. It separates a future obligation from a control already operating. Test training, data capture and reporting handovers against that register. This is an example project method rather than a complete legal timetable. Check the current legislation and AUSTRAC guidance to establish whether a staged or deferred rule applies. A completed transition register does not establish that a platform is registered, authorised or compliant.