In a previous blog post, we explored how to build a regulated operation capable of supporting and sustaining a Distributed Ledger Technology (DLT) ecosystem. We covered the fundamentals: from designing value-delivering processes, to building value-protecting controls, to establishing the governance and oversight mechanisms required by regulators.
But once you’ve built all of that… how do you know when you’re done?
Defining “Done” in a Regulated Context
Before we answer that, we need to define what “done” actually means. In a regulated environment, “done” is never final. But there is usually a first significant milestone—a threshold that indicates you’ve reached a level of operational maturity sufficient to meet initial regulatory expectations.
While this varies depending on your jurisdiction and business model, a common benchmark is when you can credibly convince regulators that your operation poses minimal harm to the local economy.
In the UK’s Digital Securities Sandbox (DSS), for example, this is roughly equivalent to passing Gate 2—an important checkpoint where your operational, legal, and risk management capabilities are scrutinised. Outside the DSS, this level of maturity often aligns with preparing an initial application for one of the various designations or licences needed to handle digital assets.
So what does this look like in practice?
It typically means you can demonstrate the following:
- Your risk register covers the full landscape—across business, operational, financial, and governance domains.
- Your process catalogue articulates all activities—both routine operations and emergency actions.
- Your control library brings residual risk within the boundaries of your board-defined appetite.
The third item—controls design—was the focus of our previous post. Let’s now look at the first two.
1. Testing Risk Register Coverage: Finding the Hazards
One of the most powerful ways to test the completeness of your risk register is to walk through the rest of your operational model, searching for hazards.
But what exactly is a hazard?
That’s a tricky one. Hazards are difficult to define in abstract terms, but modellers usually know one when they see one. Essentially, a hazard is any source of potential risk. It can stem from people, systems, dependencies, or even structural asymmetries in your design.
Here are a few examples to illustrate:
- A stakeholder group with only one member — introduces key personnel risk.
- A legacy or experimental piece of technology — increases the risk of failing to meet operational resilience standards.
- A highly sensitive data field — carries a risk of loss, leakage, or unauthorised access.
Once you’ve identified a set of hazards across your operating model, the next step is to check that each is addressed by at least one risk in your register.
Note that this is not a simple one-to-one mapping. Hazards and risks have a many-to-many relationship. A single hazard may give rise to multiple risks (e.g., technology fragility may lead to downtime, data loss, and reputational impact), and a single risk may stem from several hazards (e.g. a risk about critical IT infrastructure may cover several systems in the Applications dimension).
This exercise is qualitative, but it’s an excellent tool for surfacing blind spots—especially when reviewing new designs or preparing for regulatory engagement.
2. Using State Diagrams to Validate Risk and Process Coverage
Another effective way to demonstrate the completeness of your risk register and process catalogue is to use state diagrams.
In any DLT ecosystem, key entities move through successive states. This includes not just users, but also infrastructure elements like nodes, operators, or tokens.
Take the example of a Participant in your ecosystem. At any given time, they could be in one of several states:
- Off-boarded
- Applying
- Active
- Suspended
- Appealing
Each state is part of a lifecycle, and each transition between states is either triggered by a process or the result of a risk occurring.
Let’s map a few transitions:
- A sales process moves a Participant from Off-boarded to Applying.
- The application process moves them from Applying to Active (or back to Off-boarded if rejected).
- A breach of rulebook obligations may trigger a suspension.
- An appeals process could either restore their active status or eject them from the ecosystem.
These transitions are not just business logic—they are opportunities to identify missing processes or risks.
In the example above, we uncovered at least two processes and one risk, simply by tracing the state transitions of a single entity. This approach becomes even more valuable when applied to more complex actors, such as:
- Nodes (e.g., Unregistered, Registered, Syncing, Active, Validating, Suspended)
- Tokens (e.g., Issued, Locked, Tradable, Burned)
- Operators (e.g., Pending Approval, Live, Suspended)
By building out these state models and mapping which risks and processes govern the transitions, you can ask the all-important question: Have we captured everything that matters?
Bringing It All Together with RegDefy
At RegDefy, we’ve embedded these principles into our platform from day one.
- The risk register and process catalogue are two of our core 11 dimensions.
- Our modelling engine flags hazards in your digital twin and shows which ones aren’t yet covered by any risks—surfacing potential gaps.
- The Concepts module lets you define state diagrams for any entity in your ecosystem and assign both risks and processes to transitions.
This creates a traceable, auditable structure where every risk is justified, every process has a purpose, and every transition is controlled. And when a regulator asks, “How do you know you’re ready?”—you have the evidence to show them.
Because ultimately, “done” isn’t a feeling. It’s a demonstrable state of readiness.
Final Thoughts
In regulated DLT ecosystems, operational maturity isn’t an abstract goal. It’s a threshold you need to cross—one that signals to regulators and stakeholders that you’re serious, structured, and safe.
By combining hazard identification, state modelling, and comprehensive risk/process coverage, you can make that case with confidence.
