Governance, authorship, and accountability in software-defined finance
Introduction: Why “Code Is Law” Is the Wrong Question
Few phrases have done more damage to serious discussion of programmable finance than the slogan “code is law.” While it resonates with engineers, suggesting determinism, predictability, and freedom from arbitrary discretion, it collapses several fundamentally different concepts into one misleading idea.
Code does not create authority.
Code does not define legitimacy.
Code does not absolve responsibility.
What code does is execute rules with precision.
The real transformation underway is not that law is being replaced by software, but that law is increasingly expressed through software architectures rather than mediated solely through institutional processes. This raises a far more important question than whether blockchains can be regulated:
When financial activity is executed by software rather than institutions, who is authorised to define the rules, who implements them, and who remains accountable when things go wrong?
Answering this requires abandoning the idea of a single “financial system” and instead understanding finance as a layered, governed software stack.
Financial Infrastructure Is a Stack, Not a System
Traditional finance appeared institution-centric because institutions internally controlled every layer: identity, custody, execution, record-keeping, and compliance. That vertical integration made governance simple to conceptualise, if not always effective.
Software-defined finance breaks this integration apart.
In modern tokenized and blockchain-based environments, the components that together constitute a financial transaction are often operated by distinct actors, sometimes across jurisdictions. Ownership state may be recorded on a distributed ledger; eligibility rules may be enforced by smart contracts; identity verification may rely on state-issued credentials; compliance checks may be performed by specialised services; and user access may occur through interfaces provided by regulated institutions.
This architectural fragmentation is not accidental. It mirrors the evolution of other digital infrastructures, most notably the internet, where no single organisation controls the whole system, but governance nonetheless exists at multiple layers.
The implication is crucial: control has not disappeared; it has been redistributed.
And with redistribution comes the need for more explicit governance.
Writing Code Is Not the Same as Making Law
A recurring fear in public discourse is that engineers, protocol designers, or open-source communities are quietly assuming legislative power by encoding rules into financial software. This fear misunderstands both software authorship and legal authority.
Writing code confers capability, not legitimacy.
A developer may write a smart contract that enforces transfer restrictions, but that restriction only has legal force if it reflects an underlying legal entitlement. Similarly, an open-source protocol may enable settlement finality, but whether that finality is recognised in law depends on statutory frameworks and judicial interpretation.
This distinction is already visible in practice. The core protocol software underlying public blockchains such as Ethereum is written and maintained by global open-source contributors. Yet this software, by itself, creates no legal obligations. Legal responsibility arises only when regulated entities, issuers, custodians, exchanges, choose to deploy that software in legally significant contexts.
In other words: authority does not flow from authorship. It flows from deployment under law.
How Regulation Enters Software Systems
If law is not replaced by code, how does it become operational in software-defined finance?
The answer lies in a subtle but powerful shift: regulation increasingly defines conditions of execution rather than relying solely on post-hoc institutional supervision.
In traditional systems, a transaction could occur even if it violated a rule; enforcement followed later through audits, fines, or sanctions. In programmable systems, many regulatory constraints can be enforced before execution.
A tokenized security, for example, can be designed so that it transfers only between wallets that can cryptographically prove eligibility under applicable securities law. Jurisdictional restrictions, holding limits, or lock-up periods can be embedded directly into transfer logic. Identity requirements can be enforced without revealing personal data, using verifiable credentials rather than centralised databases.
This does not mean that regulators write smart contracts themselves. Rather, regulators define acceptable architectures and constraints, while regulated entities implement those constraints in software and remain legally accountable for their correct operation.
A clear real-world example is Switzerland’s legal recognition of ledger-based securities under the DLT Act. By explicitly acknowledging that rights and obligations may be enforced through technical systems rather than paper registries, Swiss law allows compliance to be expressed at the level of execution, while preserving legal enforceability and judicial oversight under FINMA supervision.
The law remains the source of authority. Software becomes the enforcement instrument.
Governance and Change: Why Immutability Is Not Absolute
Engineers are rightly drawn to immutability. In financial systems, however, absolute immutability is neither realistic nor desirable.
Courts reverse transactions.
Regulators impose freezes.
Fraud requires remediation.
Errors require correction.
As a result, any serious financial software system must confront a difficult design problem: how can rules be enforced deterministically while still allowing lawful intervention?
The answer lies in explicit governance mechanisms, upgrade paths, pause functions, multi-signature controls, and versioning frameworks, whose operation is itself subject to legal and regulatory constraints. Crucially, the power to change code is not an engineering afterthought; it is a regulated capability.
Who controls upgrade keys?
Under what legal authority can a contract be paused?
How are governance decisions audited?
These questions are already central to regulatory discussions around tokenized market infrastructure. The European Union’s DLT Pilot Regime, for example, explicitly conditions experimentation on the presence of identifiable operators who retain responsibility for system behaviour, even when execution is automated.
Here again, software does not weaken regulation. It forces it to be explicit.
Open Source, Regulation, and the Myth of Loss of Control
Another persistent misconception is that open-source financial software undermines regulatory authority because “anyone can run it.”
This confuses availability with legitimacy.
Open-source code can be inspected, audited, and reused by anyone, but lawful financial activity occurs only when that code is deployed within a regulated context. The same protocol may underpin both compliant and non-compliant systems; regulation governs use, not existence.
In fact, open-source infrastructure often strengthens oversight by reducing opacity. Unlike proprietary banking systems, where risk models, execution logic, and failure modes are hidden, open financial software exposes its assumptions directly. This makes architectural review possible in ways that traditional supervision rarely allowed.
From a systemic-risk perspective, fewer hidden states often mean fewer unpleasant surprises.
Accountability in a Fragmented System
If control is distributed, does accountability dissolve?
On the contrary: fragmentation often makes accountability clearer.
Each layer of the financial stack has identifiable operators with defined responsibilities. Governments define legal frameworks. Regulators specify constraints and approve architectures. Institutions deploy systems, interface with users, and remain liable for outcomes. Infrastructure providers operate components under contractual and regulatory obligations. Identity issuers vouch for specific facts, not entire profiles.
No single actor sees everything, but no actor is unaccountable.
This stands in sharp contrast to legacy systems, where concentrated power, opaque software, and discretionary intervention often obscured responsibility until after failure occurred.
Conclusion: Regulation Becomes Architectural, Not Optional
As financial services become increasingly software-controlled and modular, regulation does not disappear, but neither does it become automatic. The transition from institution-centric oversight to rule-based, executable governance introduces new possibilities for precision, prevention, and auditability, while also exposing weaknesses that legacy systems often obscured.
Fragmented architectures do not inherently guarantee accountability. When governance is poorly defined or legal alignment is absent, responsibility can diffuse across layers, jurisdictions, and actors, producing enforcement gaps rather than clarity. Early failures in decentralized systems demonstrate this risk clearly. Yet these failures are not evidence that regulation is incompatible with programmable finance; they are evidence that accountability must be deliberately designed, rather than assumed to emerge from institutional form alone.
Similarly, while software-defined systems make control surfaces more visible, they can also concentrate power through upgrade authorities, administrative keys, or foundation-led governance. The difference is not that power disappears, but that it becomes legible. This legibility enables regulators to focus on real points of authority, who can intervene, who can alter rules, and under what conditions, rather than relying on implicit trust in institutional intermediaries.
The central shift, therefore, is not from regulation to deregulation, nor from institutions to code, but from retrospective supervision to architectural constraint. Law continues to define legitimacy, accountability, and enforcement. Institutions remain responsible and licensed. Software executes rules, but it does not define them. Where this alignment is achieved, compliance can become more precise, less invasive, and more resilient than in purely institutional systems.
Regulation in software-defined finance succeeds not by resisting fragmentation, but by governing it, through explicit rule-setting, visible authority, and enforceable accountability. The challenge ahead is not whether regulation can adapt, but whether architectures will be designed to make regulatory intent enforceable by default.
In that sense, regulation is not weakened by finance becoming infrastructure. It becomes inseparable from it.
At Parowls, we help organisations translate this shift into practical governance and infrastructure decisions.
