How should crypto compliance teams prepare for rules that focus on function rather than whether a service is custodial or decentralised?

Why function-based rules change the compliance work

Function-based rules shift the analysis from “what is the service called?” to “what does it actually do?” That matters because the same product can look non-custodial in one deployment and still perform transfer, exchange, safekeeping, or control functions in another. For compliance teams, the practical task is to classify activity, not branding, then align the control environment to the functions regulators can attribute to the operator.

This is especially important where products combine user-facing decentralised components with centrally run services, admin tooling, treasury operations, or routing logic. A label such as “decentralised” may be legally relevant context, but it does not remove obligations if the operator still has meaningful involvement in value movement, access, or control.

How to map products to the activity they perform

The cleanest approach is to build a product-function inventory that sits underneath legal and compliance review. Each product, feature, and operating model should be mapped to the specific activities it enables, including transfer, exchange, custody-like safeguarding, wallet administration, settlement support, or control over transaction flow. That map should be revisited whenever governance changes, code paths change, or a new feature changes who can initiate, approve, or reverse activity.

• Document the real operating roles, not just the protocol architecture.
• Separate user-controlled actions from operator-controlled actions.
• Identify where an operator can pause, route, aggregate, screen, or block activity.
• Update the classification memo before launch and after material product changes.

Teams should also preserve the rationale for each classification decision. If the team later needs to show why a function was treated as in scope or out of scope, it should be able to point to the activity analysis, the operating model, and the approval path, not a marketing description.

Controls that need to follow the function, not the label

Once a service is mapped by function, the control stack should follow the highest-risk activity the service performs. If the product supports value transfer or exchange, the team should expect transaction monitoring, sanctions screening where required, record retention, escalation handling, and clear ownership for investigations. If the service touches safekeeping or control, governance around keys, approvals, recovery, and exception handling becomes part of the compliance design, even if the product is technically presented as self-custodial.

For teams working in broader digital-asset and payments environments, the same logic appears in control frameworks that tie obligations to business purpose and access paths rather than product labels, such as NIST Cybersecurity Framework 2.0, ISO/IEC 27001:2022 Information Security Management, and SOC 2 Trust Services Criteria (AICPA). Those sources are not crypto-specific rules, but they reinforce the same operational principle: controls should match the actual service behaviour and the accountability model around it.

Why this becomes a risk issue during launches and redesigns

Function-based regimes create risk when teams assume that architecture alone determines exposure. A service can move from lower-risk to higher-risk treatment through feature creep, administrative privilege growth, outsourcing, or changes in how value is routed, even if the front-end description stays the same. That means launch reviews and change management are not administrative extras, they are the points where misclassification risk is most likely to surface.

Legal, compliance, product, and engineering should therefore share one operating picture. If the team cannot explain the service’s control points, the business function it performs, and who can influence customer value, it is not ready to rely on a custodial or decentralised label as a defence.

Practitioner Guidance

What to prioritise: Start with a product-function matrix that is reviewed by legal and compliance before launch, then again whenever routing, admin access, or settlement logic changes. The review should ask whether the operator can initiate, block, reverse, or materially influence value movement.

What to verify: Evidence should show the actual operating model, not just the protocol design. Retain decision memos, feature-change assessments, escalation paths, and the controls used for monitoring, screening, and recordkeeping so the classification can be defended later.

Decision rule: If the service can meaningfully affect transfer, exchange, safekeeping, or control over value, treat it as compliance-relevant until counsel confirms otherwise. A decentralised label should reduce scrutiny only when the operating facts support that conclusion.

Practitioner takeaway: The teams that stay ahead of function-based rules treat classification as a living control, because the compliance answer can change as soon as the product’s real operating behaviour changes.

Related resources from NHI Mgmt Group

• How should crypto compliance teams handle FATF’s function-based approach when deciding whether a service counts as a VASP?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• How should security teams govern Active Directory service accounts?