Who is accountable when a DeFi protocol has identifiable controllers but still lacks strong AML controls?

If identifiable controllers exercise control or sufficient influence, the protocol can fall within the same compliance expectations as other regulated virtual asset businesses. That can include licensing, customer due diligence, sanctions screening, transaction monitoring, and Travel Rule obligations where applicable. Having control creates responsibility, even if the protocol also uses decentralised technology.

Why This Matters for Security Teams

When a DeFi protocol has identifiable controllers, the accountability question stops being theoretical and becomes a governance, AML, and enforcement issue. Regulators and counterparties tend to look past the interface and ask who can change rules, approve upgrades, control treasury functions, or influence user flows. If those actors are known, the protocol may be expected to meet the same baseline obligations as other regulated virtual asset businesses, including sanctions screening, customer due diligence, and monitoring for suspicious activity.

This matters because decentralised architecture does not eliminate control risk. It can actually make it harder to show where decision-making sits, which controls are preventive versus after-the-fact, and whether compliance is designed into the operating model. Guidance from the FATF Recommendations — AML and KYC Framework remains central here, because AML obligations are driven by function and influence, not branding. In practice, many security teams encounter this only after a protocol has already scaled user activity without clear control ownership or meaningful monitoring.

How It Works in Practice

Accountability usually follows the people or entities that can exercise effective control, even where the protocol logic is on-chain. That means compliance teams, legal counsel, and security leads need to map who can deploy contracts, pause systems, upgrade logic, manage admin keys, set fee rules, or direct operational responses. Those control points are often treated as technical details, but they are also evidence of governance and responsibility.

In a mature operating model, the following questions should be answerable:

• Who is the controller, operator, or controlling group in practice?
• What AML controls exist at onboarding, transfer, and transaction-review stages?
• Are sanctions and wallet-risk checks performed before exposure to the protocol?
• Is there a defined process for filing suspicious activity reports where required?
• Can control changes be audited, challenged, and approved with clear accountability?

For control design, security teams can borrow from the structure of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, auditability, configuration management, and monitoring. That does not make a DeFi protocol compliant by itself, but it gives a practical control lens for identifying where decision rights live and where evidence must be retained. The key point is that AML accountability is not satisfied by code transparency alone; there must be governance over who can act, how actions are reviewed, and how exceptions are escalated. These controls tend to break down when admin authority is dispersed across multisigs, external contributors, and fast-moving upgrade paths because no single party can reliably evidence control ownership.

Common Variations and Edge Cases

Tighter AML governance often increases operational overhead, requiring organisations to balance decentralised product design against traceable accountability and review. That tradeoff becomes sharper when a protocol is partially decentralised but still has identifiable controllers, because the presence of a DAO-style label does not automatically remove responsibility. Current guidance suggests that substance matters more than labels, but there is no universal standard for this yet across all jurisdictions.

Edge cases usually appear in three places. First, a protocol may have a foundation, developer group, or governance committee that cannot directly move funds but can shape outcomes through upgrades and parameter changes. Second, compliance controls may exist only at the front end while the smart contract layer remains open, which can weaken the overall AML posture. Third, cross-border activity can create conflicting expectations, especially where one jurisdiction treats the actors as virtual asset service providers and another focuses on local facilitation or control.

For this reason, accountability analysis should be revisited whenever governance changes, a treasury function is added, or new execution privileges are introduced. Practitioners should also test whether evidence exists for KYC, sanctions screening, and transaction monitoring decisions rather than assuming the protocol’s architecture is self-explanatory. If the protocol can be changed, paused, or promoted by identifiable controllers, regulators will usually expect someone to own the compliance answer.

Related resources from NHI Mgmt Group

• Why do passwordless logins still need strong access controls?
• What should organisations do when IGA controls are strong but audits still fail?
• Why do strong customer authentication controls still fail against authorised fraud?
• Who is accountable for access drift when protocol-specific controls create exceptions?