Without clear regulatory frameworks, banks face more uncertainty around product design, customer protection, and control ownership. The article shows that Andorra’s earlier legal framework gave Morabanc room to test digital asset services with more confidence. In less defined environments, institutions usually move more slowly, limit the service scope, and spend more effort proving that controls are adequate.
Why unclear rules slow banks down, even when the product idea is sound
When banks enter stablecoin or crypto services without a clear regulatory framework, the biggest friction is not just legal ambiguity, it is operational uncertainty. Teams have to decide what the product is, who owns the controls, how customer protections work, and how much risk the bank is willing to absorb before launch. That uncertainty usually translates into narrower offerings and slower approvals.
In practice, the bank cannot rely on a simple “build first, clarify later” approach. Product design has to account for custody, settlement, disclosures, complaints handling, reconciliation, and monitoring, all while the institution is trying to prove that the service fits within banking obligations. Where the legal baseline is clearer, those questions are easier to answer and the control model is easier to defend.
The same pattern shows up in broader digital asset governance. Clearer rules tend to reduce internal debate about whether the bank is acting as a custodian, broker, facilitator, or technology provider. That matters because the classification determines which controls, approvals, and evidence the bank must maintain before it can safely offer the service.
What changes when the framework is missing
Without a defined rule set, the bank has to make assumptions about customer treatment, transaction oversight, asset segregation, and incident response. Those assumptions can differ by jurisdiction, product type, and distribution model, so the service often ends up being launched with tighter scope than the business originally wanted.
It also increases the burden of proving control adequacy. A bank may need to document why its safeguards are sufficient even where supervisory expectations are still evolving. For digital asset services, that usually means more legal review, more governance sign-off, and more conservative decisions about what the bank will and will not support.
For readers wanting a broader governance reference point, NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives shows how defined obligations change control ownership, auditability, and review expectations. The same governance logic applies when a bank is trying to launch a regulated digital asset service in a still-maturing environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organizational Context | Clarifies why product scope and accountability matter when rules are unclear. |
| GV.RM — Risk Management Strategy | Banks must set appetite for regulatory and customer-protection uncertainty. | |
| Recommendation — Define the service boundary and accountable owners before approving launch. Align the product decision to explicit risk appetite and escalation thresholds. | ||
| CIS Controls v8 | 17 — Incident Response Management | Crypto services increase the need for tested response and customer-impact handling. |
| 4 — Secure Configuration of Enterprise Assets and Software | Operational controls must be provable when the regulatory baseline is unsettled. | |
| Recommendation — Test response playbooks for custody loss, fraud, and service interruption scenarios. Harden and document the service configuration that supports customer asset handling. | ||
| DORA | IPT — Information and Communication Technology Risk Management | Digital asset services depend on strong resilience, control ownership, and evidence. |
| Recommendation — Map the service to ICT risk controls and keep evidence for supervisory review. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Customer protection hinges on how strongly the bank verifies customers for digital asset access. |
| Recommendation — Set identity assurance requirements that match the service's fraud and access risk. | ||
Practitioner Guidance
What to verify: Before approving a stablecoin or crypto service, confirm whether the bank can name the accountable control owner for custody, customer protection, monitoring, and incident handling. If those responsibilities are split across legal, compliance, operations, and technology without a clear decision model, the launch will usually stall or stay artificially narrow.
Decision rule: If the regulatory position is ambiguous, default to the smallest service scope that can still be governed cleanly, then expand only after the bank can evidence control ownership, disclosures, and operational readiness. That approach is usually safer than trying to justify a broad offering on interpretive assumptions.
What practitioners underestimate: The hard part is often not the asset itself, but the bank’s ability to prove why its controls are adequate to supervisors, auditors, and customers. In practice, the strongest launch programs are the ones that can explain the service model, the control boundary, and the residual risk in plain terms.
Practitioner takeaway: Clear regulation does not just reduce legal risk, it shortens the path to a defensible operating model; without it, banks usually respond by narrowing scope, slowing launch, and over-investing in governance evidence.
Related resources from NHI Mgmt Group
- What happens when mobile apps send user data to centralized AI services without clear controls?
- What happens when banks try to deliver digital banking services without a coherent partner ecosystem?
- What happens when banks expand digital services without updating identity verification and fraud controls?
- How should banks govern stablecoin pilots without creating control blind spots?
