Unhosted Wallet Risk Policy for VASPs and Payment Teams

FATF targeted reporting in 2026 keeps pressure on stablecoins, unhosted wallets, and P2P risk. The point is not to ban every self-custody wallet. The point is to manage risk before value moves.

An unhosted wallet can belong to a good customer, a scam victim, a broker, a sanctions evader, or a mule. The policy has to sort cases without pretending ownership is always visible.

Separate deposits, withdrawals, refunds, OTC settlements, merchant payouts, treasury transfers, and token allocations.

Each flow needs its own data requirements, risk triggers, approval limits, and customer message. A one-page rule for every wallet will either block good business or miss bad flow.

For low-value, low-risk activity, a wallet check and basic customer context may be enough. For higher value or elevated indicators, require additional review.

Triggers should include sanctions evidence, scam exposure, mixer exposure, darknet exposure, stolen-funds indicators, fresh-wallet behavior, unusual volume, and mismatch between customer story and wallet activity.

Do not force false certainty. If ownership cannot be verified, record that fact and decide under policy.

Possible actions are allow with monitoring, request more information, pause, limit amount, reject, or escalate. The worst action is pretending an unverified wallet is verified because the customer said so in chat.

Customers do not need detector detail. They need to know what is required to proceed.

Use plain messages: additional wallet information is needed, the transfer is under review, the wallet cannot be accepted under policy, or the user must provide a different address. Keep internal evidence separate from customer-facing text.

The policy must prove that the business identified unhosted wallet risk, assigned controls by flow, trained staff, kept records, reviewed exceptions, and improved thresholds when evidence changed.

That is the difference between a paper policy and an operating control.