Who is accountable when a regulated broker launches crypto services under MiCA?

Accountability boundaries when a regulated broker enters MiCA-covered crypto activity

MiCA changes the question from “can the firm launch?” to “who can prove the launch was governed, controlled, and supervised?” For a regulated broker, accountability must be explicit across business ownership, control ownership, and exception handling, because crypto services can create new permissioning, custody, disclosure, and operational oversight obligations. Under EU-level crypto governance expectations, vague shared responsibility usually becomes a documentation and escalation failure before it becomes a technical one. In practice, firms often discover the gap only after they need to evidence a decision, not when they approve the service scope.

Regulated firms should treat this as a governance problem with operational consequences. The accountable individuals need to be named before go-live, because regulators tend to examine whether the service was approved by someone with authority, whether controls were supervised by someone who understood the risk, and whether exceptions were routed to someone who could stop or constrain the service. That is especially important where the crypto offering sits alongside legacy brokerage activity and inherits multiple oversight chains. For broader control structure and accountability framing, NIST Cybersecurity Framework 2.0 is useful as a reference point for governance ownership and oversight discipline.

How accountability should be structured across service ownership, controls, and exceptions

The cleanest model is to separate decision rights rather than collapse them into one role. Service accountability should sit with the person or function that can approve scope, product change, customer eligibility, and regulatory disclosures. Control accountability should sit with the owner of the operating controls that keep the service within policy, including monitoring, approvals, recordkeeping, and access constraints. Exception accountability should sit with the function that can assess deviations, approve temporary waivers, and trigger remediation or suspension when the risk becomes unacceptable.

That separation matters because crypto services often fail at the seams between front-office ambition and back-office control. If the same team both launches and self-certifies the control environment, the firm may miss conflicts, under-test the process, or normalise workarounds. If exceptions are informal, the firm loses an auditable trail of why a risk was accepted and for how long. If escalation is unclear, staff may treat control failures as operational noise rather than reportable governance issues.

• Named service owner: accountable for launch scope, customer-facing commitments, and business rationale.
• Named control owner: accountable for control design, testing, and evidence that the service stays within approved limits.
• Named exception authority: accountable for approving, time-bounding, and reviewing departures from policy.

In a regulated environment, accountability should also cover evidence retention, because the firm must later show who made the decision and on what basis. NIST SP 800-53 Rev. 5 Security and Privacy Controls is relevant here because it reinforces the need for control ownership, auditing, and accountability around enforced safeguards. This guidance breaks down when the broker cannot map decision rights to named individuals, or when the crypto service depends on informal approval chains that are not independently evidenced.

Where MiCA accountability gets harder in brokerage-led crypto launches

There is a genuine tradeoff here: tighter accountability improves auditability and supervision, but it also increases coordination overhead across compliance, operations, risk, and technology. The hardest cases are not the obvious ones. They are hybrid services where crypto execution, custody-like handling, outsourcing, or client asset movements touch more than one control domain and no single team can legitimately claim end-to-end ownership. In those cases, the firm needs a clear lead accountable owner, not a committee that diffuses responsibility.

One common edge case is shared enterprise control frameworks. Guidance-vs-consensus point: many firms assume a general operational risk owner is sufficient, but for MiCA-related launches that is often not enough unless that person can also evidence control supervision and escalation authority. Another edge case is delegated execution through third parties. Outsourcing does not remove accountability from the broker; it changes the evidence the broker must maintain about oversight, review, and intervention rights. The same principle applies where product, compliance, and security each “own” part of the launch but nobody owns the full exception path.

Practically, the accountable structure should be tested against failure, not org charts. If a control fails on day two, there must be one named person who can decide whether to pause the service, one who can document the remediation, and one who can explain why the issue was not caught earlier. That is the standard regulators usually care about most.

Practitioner Guidance

What to prioritise: Identify one accountable lead for the service and separate owners for the control environment and exception handling. If those roles are not named before launch, the firm is already creating an audit and escalation weakness.

What to verify: Verify that each owner can actually exercise authority, not just carry a title. The broker should be able to show who approved scope, who reviewed the operating controls, and who is empowered to halt the service when a material breach or control failure occurs.

Common mistake: Treating compliance sign-off as equivalent to accountability. Compliance can advise and challenge, but it does not replace a named owner who accepts operational responsibility for the service and its exceptions.

Practitioner takeaway: MiCA accountability is strongest when decision rights are explicit, evidenceable, and enforceable; if the firm cannot name the person who can stop the service, it has not really assigned accountability.

Related resources from NHI Mgmt Group

• How should regulated brokers prepare IAM controls before offering crypto services under MiCA?
• Who is accountable for AI agent actions under regulated environments like DORA?
• What fails when a regulated crypto issuer cannot secure its MiCA passport on time?
• Who is accountable when MiCA enforcement cites negligence in a crypto issuer?