Accountability should sit with the platform operator for governance failures, and with the relevant business or compliance owners for control design and escalation. Regimes such as KYC and AML expect firms to know who their customers are, preserve records, and respond to suspicious activity. If no team owns lifecycle decisions, abuse persists.
Why This Matters for Security Teams
Hosted wallets change the accountability model because the operator often controls key custody, transaction workflows, screening logic, and escalation paths, while the customer may only see a user-facing interface. That makes this issue less about a single fraud event and more about governance failure across onboarding, monitoring, and response. KYC and AML obligations still apply, and the organisation that benefits from the service usually carries the burden of knowing who is using it, what activity is expected, and when to stop it. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because accountability depends on clear control ownership, evidence, and escalation. NHIMG’s Ultimate Guide to NHIs also shows why lifecycle blind spots matter, with only 20% of organisations having formal offboarding and revocation processes for API keys. In practice, many security teams encounter illicit use only after suspicious activity has already moved through weak ownership boundaries, rather than through intentional preventive governance.
How It Works in Practice
Accountability for hosted wallets usually splits across three layers. First, the platform operator owns the technical and operational controls: identity verification, wallet creation, monitoring, sanctions screening, transaction limits, key management, and record retention. Second, compliance or financial crime teams own rule setting, alert triage, suspicious activity escalation, and regulatory reporting. Third, business owners own the product decisions that determine whether risk is accepted, reduced, or blocked. If any one layer is missing, the control chain fails.
A practical accountability model should include:
- Named control owners for KYC, AML, sanctions screening, and wallet lifecycle decisions.
- Clear triggers for freezing, limiting, or closing wallets when risk signals emerge.
- Documented evidence of review, approval, and escalation for high-risk accounts.
- Logging that supports investigations, audits, and regulatory requests.
- Periodic testing of whether policy matches actual operational behaviour.
This is where identity and NHI governance intersect. Hosted wallets often depend on service accounts, API keys, and automation that act on behalf of the business, so weak NHI control can undermine financial crime controls even when customer checks look strong. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that wallet abuse is often enabled by machine identity failures as much as by user fraud. For broader control design, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a solid reference for accountability, auditability, and monitoring. These controls tend to break down when wallet operations are outsourced across product, engineering, and compliance teams because no single function owns end-to-end intervention authority.
Common Variations and Edge Cases
Tighter wallet controls often increase friction and operational overhead, requiring organisations to balance faster onboarding against stronger abuse prevention. That tradeoff becomes more visible in hosted custody models, embedded finance, and cross-border platforms where the operator may rely on third-party infrastructure or regulated partners. Current guidance suggests accountability cannot be outsourced away entirely, even when screening or custody components are shared, because the platform still controls the customer experience and the risk decision path.
There is no universal standard for this yet, but practitioners generally treat the operator as accountable for:
- Who can open and use the wallet.
- How suspicious activity is detected and escalated.
- Whether records are complete enough for audits and investigations.
- How quickly access is restricted once abuse is suspected.
Edge cases include non-custodial user interfaces, delegated wallet programs, and automated treasury tooling. In those environments, the question is not whether the organisation touched the funds, but whether it set and enforced the rules that made abuse possible. If automation initiates transfers or updates policy, then NHI governance becomes part of financial crime governance, not a separate technical concern. For that reason, teams should align wallet lifecycle controls with the broader principles in Ultimate Guide to NHIs and review how identity-dependent workflows map to KYC and AML duties. Where regulators expect traceability, unclear ownership usually becomes the first weakness exposed during an investigation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight define who is accountable for illicit-wallet risk. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit events support investigations into suspicious wallet activity. |
| OWASP Non-Human Identity Top 10 | Wallet platforms often rely on service accounts and API keys that need NHI governance. |
Log wallet actions, reviews, and escalations so illicit finance cases can be reconstructed.
