Modern regulatory frameworks like FinSA contain two fundamentally distinct types of legal content: procedural obligations that sequence actions across actors and time, and substantive rules that define the conditions under which those actions apply or are modified. Translating these into operational practice has historically depended on legal interpretation, internal guidelines, and manual compliance checks, introducing latency, inconsistency and audit risk. "Rules as Code" addresses this by expressing legal norms directly in formal, machine-readable languages, enabling automated reasoning over statutory text rather than merely documenting it.

While BPMN is highly effective for mapping the procedural journey of a law, showing the sequence of events and "who does what", it often struggles with the dense, conditional logic found in substantive legal rules. Without a secondary standard, a messy "spaghetti" of branching gateways for every tiny legal condition results, rendering diagrams unreadable. To maintain clarity, DMN (Decision Model and Notation) is used to offload complex "if-then" criteria into a structured table, keeping the BPMN diagram clean and focused only on the workflow steps. The conditions and outputs in each table cell are written in FEEL (Friendly Enough Expression Language). FEEL is side-effect free, deterministic and strongly typed, properties that make it well suited for encoding legal rules, since it guarantees that the same input fact pattern always produces the same prescribed output. Together, these standards transform static legislation and regulation into an executable blueprint that regulated parties can use to ensure both procedural compliance and accurate substantive outcomes.

DNS integrates elegantly with a BPMN process. The evaluation of a legal condition is handed over to a DMN decision table and which returns an output, such as a client segment, an applicable conduct rule set or a waiver flag, directly into the process flow. This architecture has a significant secondary benefit: the DMN table becomes a standalone, independently testable artefact. Regulators, auditors, or counterparties can verify the decision logic against the statutory text without needing to trace through an entire process diagram. As regulatory change occurs, such as a FinSO amendment adjusting an asset threshold, only the affected DMN rule row requires updating, leaving the surrounding BPMN process intact. The result is a compliance infrastructure that is modular, auditable and amenable to version control in exactly the same way as software code.