A self-hosted wallet is a technology and control arrangement, not a risk rating. The user or another non-provider party controls the relevant keys, but the transaction can still involve a known customer, an unknown beneficiary, a smart contract, a merchant, a DAO treasury, a scam, a sanctioned address, or another regulated service whose address has not been identified. Treating all self-hosted wallet activity as either prohibited or low risk hides those differences and can produce controls that are both ineffective and unnecessarily restrictive.
A better framework classifies the transaction, gathers available evidence, applies risk-based controls, and records what remains uncertain. It must also respect the technical reality that address ownership is not always provable and that signing a message demonstrates control of a key, not the identity or lawful status of every party behind it. This guide describes a practical workflow for hosted services and managed interfaces. Legal requirements differ by jurisdiction and should be confirmed with qualified counsel.
Define the counterparty types you can actually distinguish
Create clear categories such as customer-controlled self-hosted wallet, third-party self-hosted wallet, identified hosted service, unidentified hosted service, smart contract, merchant, protocol treasury, bridge, mixer or privacy service, and unknown. Do not force ambiguous addresses into a false binary of VASP or unhosted. Store confidence and evidence for each classification. The same address may interact through several roles over time, so classifications should be dated and reviewable.
Define what evidence supports each category. Customer declaration, message signing, small-value proof transactions, address attribution, counterparty confirmation, prior verified use, and transaction behavior all answer different questions. A signature can show that the customer controls a key at a moment in time; it does not prove beneficial ownership of funds, exclusive control, or the identity of a third-party beneficiary. Policies should state those limits so reviewers do not overstate assurance.
Ask why the transfer is occurring
Purpose provides context for risk. Collect a proportionate reason for significant or unusual transactions: personal custody, payment, investment, protocol use, treasury movement, transfer to another service, gift, business expense, or other purpose. Link the stated purpose to expected customer activity and the destination type. Avoid a free-text box that no one reviews. Use structured values with a controlled explanation field and escalation rules.
Purpose should be tested against observable facts. A withdrawal described as personal custody may immediately enter a high-risk service; a claimed merchant payment may go to a newly created address that receives many unrelated customer deposits; a protocol interaction may call a different contract than the one displayed. Inconsistency is a reason to investigate, not automatic proof of wrongdoing. Record the evidence, ask targeted questions, and make a decision under defined policy.
Combine identity, wallet, and transaction evidence
The risk view should combine customer due diligence, account history, device and access signals, address screening, transaction graph, asset and chain risk, destination classification, amount, velocity, and behavioral patterns. No single signal should silently dominate. A low-risk customer can initiate a high-risk transaction, and a new wallet can be legitimate. Conversely, a familiar address may become risky after compromise or a new designation. Use a rule set that can explain which facts drove the outcome.
Screen at appropriate points: when an address is saved, before a withdrawal, when a deposit is credited, and through periodic rescreening where required. For smart-contract interactions, examine the called contract, function, routed assets, and relevant counterparties rather than screening only the outer address. For cross-chain transfers, link source and destination legs when possible. Record unsupported visibility so a clean result is not mistaken for complete coverage.
Apply proportionate control tiers
Define graduated outcomes instead of one universal response. A low-risk transaction may proceed with standard screening. Moderate risk may require address confirmation, additional purpose information, a cooling period, or enhanced monitoring. High risk may require source-of-funds evidence, senior approval, reduced limits, or denial. A confirmed prohibited party or legally restricted transaction requires the response specified by applicable law and policy. The thresholds and authority for each tier should be documented and tested.
Controls should match the product’s capabilities. A custodial service can hold or reject a withdrawal before broadcast. A non-custodial interface may be able to deny a managed route, block a relayer, or display a warning, but not stop direct contract calls. Describe the control accurately in customer communications and internal reporting. Where prevention is impossible, monitoring, investigation, reporting, and future access decisions may still be relevant. Technical limits do not justify pretending that a control exists.
Handle Travel Rule and counterparty uncertainty
The workflow should determine whether the transfer is subject to originator and beneficiary information requirements and whether another service provider is involved. Counterparty discovery may reveal that an address believed to be self-hosted belongs to a hosted service, or vice versa. Use address attribution, customer input, directories, and direct confirmation, with confidence levels. When classification remains uncertain, apply the jurisdictional exception policy rather than guessing.
For a customer’s own wallet, collect only the evidence and data required by the applicable rule and risk. For a third-party wallet, beneficiary information and relationship may be relevant. Build privacy safeguards because linking identity to blockchain addresses creates sensitive data. Do not publish personal data on-chain. Separate the Travel Rule message from transaction execution, record exceptions, and preserve the basis for the counterparty decision.
Design a fair review and correction process
Self-hosted wallet controls can create false positives that block legitimate personal custody, payments, or protocol participation. Give reviewers access to the underlying evidence rather than a score alone. Provide customers with a controlled way to correct an address selection, clarify purpose, or submit relevant information. Avoid requiring excessive personal data that does not address the identified risk. Decisions should be consistent across similar cases and protected from arbitrary override.
Measure false positives, review time, customer abandonment, repeated address disputes, and rule performance. Segment outcomes by chain, asset, provider, and scenario. A rule that blocks nearly every smart contract may be technically simple but analytically weak. Tune it through documented governance. Where a transaction is rejected, retain the decision evidence and communicate without exposing sensitive models or accusing the customer of misconduct without support.
Monitor the framework as technology changes
Account abstraction, smart accounts, multi-party computation, session keys, paymasters, bridges, privacy tools, and delegated execution can change what “wallet control” means. Review the framework when new architectures are supported. Update address-proof methods and avoid assuming that one signature scheme works for every chain or contract wallet. Product teams should flag new execution paths before launch so compliance can design controls around the actual transaction.
Governance should receive a residual-risk view: volumes by counterparty class, unknown-rate trends, high-risk exposure, exceptions, control outages, and unsupported assets. Independent testing should sample both approved and rejected transactions. FATF’s updated guidance discusses peer-to-peer activity, unhosted wallets, and risk-based measures, providing a useful primary baseline for this framework:
Document rationale and residual uncertainty
Every material decision should show the facts available, the classification assigned, the control applied, and what remains unknown. Use a confidence field rather than converting uncertain attribution into a definitive label. When an approval depends on customer information, record the question and response. When a denial depends on blockchain evidence, retain the relevant snapshot and rule version. This record supports consistent review, later rescreening, and fair correction if better information appears. It also helps governance distinguish accepted technical uncertainty from a broken control or missing data source.
Conclusion
Self-hosted wallet risk is best managed through classification, evidence, context, and proportionate outcomes. The framework should distinguish customer-controlled wallets, third parties, smart contracts, services, and unknowns rather than assigning one risk level to all unhosted addresses.
State what each proof establishes, integrate on-chain and customer evidence, protect linked identity data, and provide a review path. As wallet technology changes, revisit the assumptions. A transparent, technically accurate framework is more defensible than either blanket prohibition or blanket trust.