The accountable party is the entity that can control the platform and implement compliance measures. For centralized exchanges and custodial services, that is usually the regulated operator. For DeFi protocols, regulators increasingly look for identifiable governance entities, legal wrappers, or development teams that can change the system. If there is a responsible entity, enforcement will usually focus there.
Why This Matters for Security Teams
travel rule and KYC failures are not just policy gaps; they create a direct line from technical control failures to enforcement, licensing risk, and frozen counterparties. For centralized exchanges and custodial platforms, the accountable party is usually the regulated operator because it controls onboarding, transaction monitoring, and recordkeeping. For DeFi, the question is harder because regulators now examine who can change the protocol, operate the front end, or govern upgrades. That is where accountability usually lands.
The practical test is control, not branding. If a team can change smart contracts, route user activity, or set compliance thresholds, it can usually be held responsible for compliance outcomes. That logic aligns with the FATF Recommendations and with the broader control expectations reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls. In the NHI context, this is similar to asking who can actually govern secrets, policies, and system behaviour rather than who merely claims neutrality. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames the same issue: enforceability follows control, not architecture labels.
In practice, many security teams encounter accountability only after regulators, banks, or auditors have already decided the system had a responsible operator.
How It Works in Practice
Accountability typically follows the party that can implement and evidence compliance controls. For a centralized exchange, that means the legal entity that performs customer due diligence, sanctions screening, travel-rule messaging, wallet risk checks, and suspicious activity escalation. For custodial services, it also includes the entity that holds keys, controls withdrawal policy, and maintains audit logs. Under FATF Recommendations, the core question is whether the obliged entity can identify counterparties and transmit required originator and beneficiary information.
For DeFi protocols, enforcement often focuses on the parts of the stack that are not actually decentralized in an operational sense. That may include a foundation, core developers, multisig signers, governance token controllers, or the operator of a hosted interface. If those actors can pause contracts, upgrade code, filter transactions, or block access by jurisdiction, they may be treated as accountable. In that sense, protocol governance becomes a compliance control surface, not just a technical design choice. NHIMG’s DeepSeek breach and Schneider Electric credentials breach show the same pattern in adjacent domains: once operational control exists, accountability quickly attaches to the entity that can change behaviour, not the one that claims to be passive.
- Identify the legal entity, governance body, and technical operators that can modify compliance-relevant behaviour.
- Map onboarding, screening, travel-rule transmission, and records retention to specific control owners.
- Document who can upgrade code, change front ends, or alter wallet policies.
- Keep evidence that controls operated at the time of each transaction or customer event.
This guidance breaks down when control is intentionally distributed across anonymous contributors and no party can reliably enforce or evidence compliance.
Common Variations and Edge Cases
Tighter compliance attribution often increases operational burden, requiring organisations to balance decentralization claims against the reality of who can intervene. The hard cases are hybrid structures: a protocol may be “decentralized” on-chain but still have a foundation, a UI operator, or a development company that can affect user access. Current guidance suggests regulators will look through labels and evaluate effective control, but there is no universal standard for this yet. That means responsibility can shift depending on jurisdiction, product design, and whether a responsible party has the ability to implement AML/KYC controls in practice.
Another edge case is non-custodial software versus hosted services. A pure code repository may be less likely to be treated as the obliged entity, while a managed interface, relay service, or transaction router may inherit more risk because it mediates user action. Teams should also watch for governance tokens and upgrade keys, because they can convert “community” decisions into attributable control. The eIDAS 2.0 — EU Digital Identity Framework is not a crypto AML rule, but it reflects the broader policy direction toward identifiable, accountable digital actors. In practice, the safest assumption is that if a party can shape user identity, transaction flow, or system upgrades, it may be treated as responsible for the compliance outcome.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity ownership matters when deciding who controls compliance-capable NHI components. |
| OWASP Agentic AI Top 10 | A-04 | Autonomous systems need clear accountability for actions that alter user-facing behavior. |
| CSA MAESTRO | GOV-01 | Governance controls determine who can modify protocol behavior and compliance outcomes. |
| NIST CSF 2.0 | GV.RR-02 | Governance roles clarify who is responsible for policy execution and outcomes. |
| NIST AI RMF | GOVERN | AI governance principles help attribute responsibility where systems can act independently. |
Assign each operational identity to a accountable owner and review whether it can enforce policy changes.
Related resources from NHI Mgmt Group
- Who is accountable when a VASP fails to exchange accurate Travel Rule information during a virtual asset transfer?
- How should crypto exchanges balance onboarding speed with KYC, AML screening, and Travel Rule obligations?
- Who is accountable when Travel Rule compliance fails in a VASP workflow?
- Who is accountable for Travel Rule compliance in a crypto business?
