Self-hosted wallet due diligence for Australian VASPs

Classify the wallet before calling it self-hosted

Establish whether a person controls the wallet directly or a custodian controls it for them. Consider the wallet address and network, destination tag or memo, counterparty disclosures, public registration records, reliable blockchain attribution and the customer's explanation. Record the source, date, confidence and limitations of each result.

A wallet can look self-hosted because no provider is identified even when an offshore or embedded custodian controls it. Conversely, a customer using a hardware or software wallet may control the keys personally. If the evidence is inconclusive, record the uncertainty and apply the policy for an unverified or higher-risk classification rather than forcing a definitive label.

Identify the payer, payee and wallet controller

For an outgoing transfer, collect and verify the payer information required by the travel rule and collect the payee's full name and tracing information. Determine whether the receiving self-hosted wallet is controlled by the payee. For an incoming transfer, obtain the payer information and tracing information and, if not already held, the payee's full name before making the assets available. The beneficiary institution's policies must describe how it identifies the payer and verifies who controls the sending wallet.

Keep the concepts separate. The customer, payer, payee, wallet controller, beneficial owner and person funding the fiat leg may be different people. A declaration from the account holder is useful evidence but should not automatically override contradictory transaction, device, payment or blockchain information.

Use proportionate proof-of-control measures

Never ask for or store a seed phrase, private key, recovery code or signing secret. Proof should demonstrate control without transferring control to the VASP or exposing credentials. Define which methods are accepted for each risk tier and how replay, copied screenshots, address poisoning and compromised devices are addressed.

• Compare a customer-supplied address with reliable transaction and account data and check for a known custodian attribution.
• Use a cryptographic signed-message challenge on a supported chain where it can be performed safely and the result is independently verified.
• Use a controlled micro-transfer or challenge transaction where cost, privacy, network and operational risks are acceptable.
• Obtain corroborating wallet screenshots or device evidence only where useful, then assess authenticity and minimise unnecessary personal data.
• Escalate third-party ownership, multisignature arrangements, smart-contract wallets, privacy-enhancing protocols and conflicting evidence for a method tailored to the actual control model.

Assess on-chain and off-chain risk together

Consider reliable wallet and transaction exposure, including sanctions, scams, ransomware, darknet markets, child exploitation, terrorism financing, mixers, higher-risk decentralised exchanges and unregistered providers. Look at proximity, direction, timing, value, confidence, asset and chain rather than treating any distant exposure as conclusive.

Combine that result with the customer's profile, purpose, expected activity, source of funds, device and IP information, fiat funding, linked accounts, counterparties and jurisdictions. A clean blockchain score does not resolve identity fraud or mule activity; a risk label requires investigation before it becomes a customer, transfer or reporting decision.

Make and preserve the transfer decision

Record whether the wallet was verified, the controller, method and evidence; the payer and payee information; transaction hash and network; asset and amount; blockchain results; identified risk; investigation; approver; and release, hold, reject or exit decision. Link the decision to any customer-risk update, enhanced CDD or SMR review without exposing restricted suspicious-matter information to unauthorised personnel.

The future unverified-self-hosted-wallet report scheduled for 31 March 2029 does not replace an SMR. If the current facts create reasonable grounds for a relevant suspicion, apply the current SMR process and deadline. Review the control design before 2029 so the business can identify reportable transfers, retain required fields and avoid a last-minute data gap.