Compliance has always involved translation. Firms take broad regulatory expectations and convert them into policies, controls and workflows that fit their business. It is a process that is often slow, expensive and open to interpretation. But what if that translation step could disappear altogether?
The idea of machine-readable regulation promises a future where regulatory requirements can be consumed directly by technology, allowing firms to respond to rule changes faster and with greater consistency. It is an ambitious vision, but one that raises equally ambitious questions. Can legal obligations really be turned into executable rules without losing the nuance that regulation depends on? And would it make compliance more effective, or simply shift complexity elsewhere?
Bhavin Shah and Pooja Shah, CEO and director of product and client solutions at Sherlocq, as financial services become increasingly digital, an old question has gained new urgency: can regulation itself become machine-readable? Can the rules be expressed in a form that software can read, interpret, and act on directly, rather than something compliance teams must decode by hand every time?
The duo detail that at first glance the idea sounds ambitious.
“Regulations are full of legal nuance, contextual judgment, and principles never intended to be interpreted by software,” they said. “Yet regulators, technology firms, and financial institutions are increasingly exploring ways to turn regulatory obligations into structured rules that computers can process. The concept sits at the heart of the next generation of RegTech and could fundamentally change how organisations approach compliance.”
Evgeny Likhoded, Corlytics president, stressed there is a growing temptation to talk about machine readable regulation as if the goal is to turn law into software. “That may be the end-state for a narrow subset of rules, but it is not the right place to start,” he said.
In financial services, he believes the more practical opportunity is simpler and much more powerful – regulation, in his view, should first become machine-classifiable.
He said, “Before asking whether every obligation can be converted into executable logic, we should ask whether the rulebook can clearly identify, at source, what kind of regulatory statement each provision is. Is it a binding obligation, a prohibition, a permission, guidance, an example, a definition or a reporting requirement?”
That distinction, he makes clear, may sound basic – but in practice is often one of the biggest sources of compliance friction.
Likhoded continued, “Firms spend huge amounts of time converting regulatory text into internal obligation registers. Lawyers, compliance teams, consultants and vendors all read the same source material and classify it manually. They decide what is binding, what is guidance, what applies to the firm, what requires controls, what needs evidence, what has changed, and who owns it.”
The result, the Corlytics president makes clear, is expensive, slow and inconsistent.
“Too much compliance effort is spent decoding the structure of the rulebook, rather than managing the risks the rulebook is meant to address. So the better starting point is, can a regulation be published in a way that machines, firms and supervisors can understand it consistently from the source?”
Truly machine-readable regulation
What would truly machine-readable regulation look like? Here, Likhoded is clear that truly machine-readable regulation would not simply be a PDF with better formatting, nor would it only be legal text converted into code after publication.
“It would be a regulation published as a structured package: human-readable text, machine-readable metadata, stable identifiers, version history, links between obligations and guidance, and, where appropriate, executable logic,” he added.
The first and most feasible layer, he stresses, would be source tagging. Each provision could be tagged at the paragraph or clause level with basic metadata, with legal status, norm type, scope, actor, action, effective date, related guidance, and whether judgment is required.
Likhoded added that a rule can be binding even if it is not quantifiable. Requirements to act fairly, he said, take reasonable steps, avoid foreseeable harm, maintain appropriate systems and controls, or act in a client’s best interests may all require judgment. But they are not merely “soft” guidance, he makes clear, they are real obligations.
Therefore, a machine-readable rulebook for Likhoded should distinguish between two separate questions.
He explained, “First, what is the legal force of the provision? Is it a rule, guidance, definition, example, principle, direction, permission or prohibition? Second, how computable is it? Is it deterministic, calculable, data-dependent, workflow-based, principle-based, judgment-required or non-executable? That distinction would be a major improvement. The first use case is not full automation. It is navigation and clarity.”
A firm should be in his view able to ask a number of key questions. These include showing all binding obligations, showing all guidance linked to this rule, showing all reporting requirements with deadlines, showing all provisions that changed that quarter, showing all principle-based obligations requiring human judgment and showing all principle-based obligations applying to this type of firm, activity or product.
Likhoded remarked, “That alone would make regulatory change management materially easier. It would reduce interpretive drift, where every firm and vendor builds a slightly different view of the same rulebook. The end-state could include executable rules, APIs, validation tools and test cases, but the first step is more modest. Regulation should become classifiable before it becomes executable, which is both more feasible and less risky.”
Machine-readable regulation extends well beyond simply publishing legislation in a digital format. Bhavin and Pooja argue that the concept is often misunderstood because it combines several distinct ambitions under a single label.
At its most basic, it means regulations are digitally structured so software can identify provisions, track amendments and connect related rules. “This is largely a solved problem and most regulators already do it,” they explain.
A more advanced model allows machines to evaluate regulatory obligations themselves. Rather than simply reading legislation, systems can assess structured rules made up of defined conditions, thresholds and outcomes. As Shah and Shah put it, obligations become a logical framework where, for example, “If a transaction is above this amount and involves this type of counterparty, then this reporting obligation applies.” They describe this as the area “where most serious work is happening today.”
The furthest-reaching vision is also the most controversial: fully executable regulation, where code itself becomes the authoritative rule rather than the legal text. According to Shah and Shah, this raises “deep questions about legitimacy and the rule of law,” meaning it is unlikely to become the norm for most regulation.
Instead, they argue that genuinely machine-readable regulation is more likely to combine multiple layers. These include human-readable legal text as the authoritative source, structured regulatory logic defining obligations and thresholds, standardised data definitions to ensure consistent interpretation, and machine-executable components capable of validating compliance or generating regulatory reports automatically.
They note that elements of this approach are already emerging in practice. The UK’s Digital Regulatory Reporting initiative has demonstrated that regulatory requirements can be translated into formats that machines can both interpret and execute, while the EU’s European Single Electronic Format has required listed companies to tag annual reports using Inline XBRL, making disclosures directly searchable and analysable.
The ultimate objective, they conclude, is “not just digitising compliance; it is creating a shared language between regulators and the firms they regulate.”
Can obligations be translated?
Can regulatory obligations be translated into executable rules without losing context or judgment?
Regulatory obligations cannot all be treated equally when it comes to automation. According to Likhoded, the key distinction is that obligations exist on a spectrum rather than falling into a single category.
Highly prescriptive requirements, such as filing reports within set deadlines, maintaining capital ratios or collecting mandatory onboarding information, are well suited to executable rules. Because they rely on defined thresholds, dates and calculations, translating them into machine logic can “reduce ambiguity and improve consistency.”
The challenge comes with principle-based obligations, including requirements to act fairly, take reasonable steps or prevent foreseeable harm. These, Likhoded argues, “are not well-suited to simple automation” because they depend on context, professional judgment and supporting evidence. Attempting to reduce them to rigid pass-or-fail rules risks creating false certainty.
That does not mean they cannot be machine-readable. Instead, Likhoded believes these obligations should be structured rather than automated. A machine-readable layer can identify “the actor, the duty, the affected customer or market, the related guidance, the concepts requiring judgment, and the evidence a firm should be able to produce.”
A provision requiring firms to take “reasonable steps to prevent foreseeable customer harm”, for example, can be tagged as a binding obligation that is principle-based, requires human review and must be supported by evidence such as risk assessments and escalation records. “That data is extremely valuable,” he says, because it tells firms that an obligation is legally binding while also signalling that it is “not a simple automated pass/fail check.”
For Likhoded, the real challenge lies in governance rather than technology. If regulators incorrectly classify a binding obligation as guidance, “that is not a harmless metadata error,” he warns. It has the potential to affect “controls, accountability and enforcement.”
To avoid that, the legal text should remain authoritative, while machine-readable tags should include version histories, effective dates and links back to the legal provision from which they derive their authority. There should also be “a clear distinction between official regulator-approved tags and third-party or AI-suggested tags.”
Artificial intelligence can accelerate the process, particularly for existing rulebooks. It can identify obligations, detect legal language and generate “first-pass metadata”, but, as Likhoded stresses, “AI should propose, not certify.” His preferred hierarchy is clear, “Human-authored law, regulator-approved tags, AI-assisted suggestions, [and] firm-specific interpretation and implementation.” In other words, AI can help organise regulation, but “legal judgment” should remain firmly in human hands.
For Bhavin and Pooja, this question is the point where the debate becomes genuinely hard, and as such deserves more than a quick answer.
They argue that whether regulation can be translated into executable rules depends entirely on the nature of the obligation. Some requirements lend themselves naturally to automation, while others lose much of their meaning when translated into code.
But much regulation, they state, deliberately relies on judgment. “Terms such as “reasonable steps,” “appropriate controls,” “effective governance,” and “fair treatment of customers” are intentionally flexible. This is not sloppy drafting; it is a deliberate and useful feature,” they said.
They detail that a standard like “reasonable security measures” can stretch to cover new threats and technologies that a precise, fixed specification would have frozen out. “Open-ended wording lets a small body of rules govern an unpredictable world,” they stated succinctly.
In the view of the Sherlocq duo, translating such an obligation into hard code forces a choice at every one of these soft terms.
“You either pin the vague word down to a specific checklist, which imports an interpretation the law never actually made and then bakes it in as if it were authoritative, or you leave a gap where human judgment must step back in. The first option creates false certainty. The second means the regulation is only partly machine-readable, with judgment still required at exactly the points that matter most,” they said.
For them, there is a further subtlety. “Much of what makes legal interpretation work lives outside the rule itself: the purpose behind it, past decisions, regulatory guidance, industry norms, and the basic principle that rules shouldn’t be read to produce absurd results,” they remarked.
“A faithful encoding would need to capture not just the words of a rule but this surrounding judgment, and that is precisely the part that resists being reduced to logic. Encode the letter of a rule while losing its purpose, and you can produce systems that are confidently, traceably wrong: compliant with the code, but in breach of the intent,” stated Bhavin and Pooja.
For the pair, the honest answer is that “some obligations translate perfectly, many cannot, and the dangerous cases are the ones that look encodable but aren’t.” The future therefore lies in a hybrid model.
Routine, objective requirements can be codified and automated, while more subjective obligations are supported by structured guidance, decision frameworks and evidence requirements that preserve regulatory discretion. In that model, “machines handle consistency and efficiency; humans remain responsible for interpretation, oversight, and accountability.”
They also stress the importance of distinguishing between regulation that is machine-readable and regulation that is machine-executable. The former means expressing obligations in a structured format that computers can understand; the latter allows systems to make decisions and take actions automatically. “The difference matters,” they conclude, “because not every obligation that can be automated should be.”
Would it improve compliance outcomes?
Would machine-readable regulation improve compliance outcomes or create new risks?
Likhoded believes machine-readable regulation has the potential to deliver meaningful compliance benefits, provided the focus is on improving clarity rather than pursuing automation for its own sake.
The most immediate gains, he argues, are practical. Structured regulation would make it easier for firms to distinguish binding obligations from guidance, examples and supervisory expectations, while also improving regulatory change management by showing not just that a rule has changed, but how it has changed – whether through “a new obligation, amended guidance, revised definition, changed deadline, expanded scope or corrected classification.”
It would also reduce duplication by giving firms and vendors a common regulatory foundation instead of forcing each organisation to build its own obligation map from scratch. For smaller firms in particular, better source tagging could make complex rulebooks significantly easier to navigate, even if it “would not remove the need for judgment.”
Likhoded also sees significant benefits for both RegTech and supervisory technology. Once obligations are structured, they can be linked directly to controls, policies, evidence, ownership and assurance processes, allowing both firms and regulators to monitor implementation more consistently.
However, he is equally clear that machine-readable regulation introduces new risks if implemented poorly. One of the biggest is “false precision” – where structured tags make regulatory requirements appear more definitive than they really are.
Misclassification presents another danger: if a binding obligation is labelled as guidance, firms may under-control it; if guidance is treated as a legal obligation, organisations may over-comply and incur unnecessary costs.
He also warns against “automation bias”, where people begin to accept a system’s conclusion without questioning whether it is fair, reasonable or aligned with regulatory intent, and against “systemic error”, where flaws in a widely adopted machine-readable layer could spread across the entire market. Over-structuring principles, meanwhile, risks encouraging box-ticking at the expense of regulatory judgment.
For Likhoded, the key safeguard is understanding the distinction between “machine-readable” and “machine-final.” A structured rule can indicate that an obligation is binding, principle-based, requires judgment, is supported by guidance and “cannot be fully automated.” That is fundamentally different, he argues, from declaring “the machine has determined that the firm is compliant.”
Rather than publishing fully executable law, Likhoded expects regulators to focus on producing official metadata that makes regulation easier to navigate and implement. The journey should be incremental: “First, make regulation classifiable. Then make it queryable. Then make selected provisions computable. Only then make narrow categories executable.”
Ultimately, he argues, machine-readable regulation “should not begin by trying to replace lawyers, compliance officers or supervisors.” Its greatest near-term value lies in providing better regulatory infrastructure – through structured obligations, linked guidance, version control and auditability – so that, as he concludes, “the most valuable near-term version of machine-readable regulation is not a machine that decides every compliance question.
It is a rulebook that can finally tell us what kind of rule we are looking at.” In financial services, he adds, “that would already be a serious and very helpful upgrade.”
The Shah duo believe machine-readable regulation could materially improve compliance, but only if it is designed to support human decision-making rather than replace it.
Among the most immediate benefits, they point to greater consistency. Today, different firms often interpret the same rule in different ways, creating unnecessary variation in compliance outcomes. Shared definitions and structured regulatory logic would reduce that ambiguity so that “the same standard applies to every case, rather than depending on which analyst happened to review it.”
The pair also argue that machine-readable regulation could dramatically accelerate regulatory change. Instead of lengthy implementation projects involving legal analysis, policy rewrites and systems updates, structured rule changes could be distributed in formats that technology can consume directly.
They also see benefits in higher-quality regulatory data, more consistent reporting and continuous monitoring, allowing firms to identify potential breaches in real time rather than through periodic reviews. Standardising obligations would also reduce duplicated effort across the industry, enabling compliance teams to focus on higher-value risk management rather than manual interpretation.
Beyond these operational gains, Shah and Shah highlight a less obvious advantage: “the very act of translating a rule into structured logic tends to expose ambiguities and contradictions that prose review glosses over.” In other words, designing regulation to be machine-readable can make it clearer for people as well as machines.
The opportunities, however, are matched by significant risks. The most important is “false certainty.” Converting an intentionally flexible legal standard into a precise algorithm can quietly embed one interpretation as though it were definitive. “The interpretation someone chose when writing the code becomes invisible and unquestioned every time the system runs,” they warn, describing this as “the subtlest risk, and the most important.”
Other concerns include firms gaming rigid threshold-based rules, errors being replicated at scale through automated systems, and an over-reliance on technology that turns compliance into “a tick-box exercise focused on satisfying the machine rather than understanding what the rule is for.”
They also raise questions around accountability – such as who bears responsibility when an automated compliance decision proves wrong – as well as the danger that overly structured regulation could become less adaptable to emerging products, risks and legal developments. Increased automation, they add, inevitably brings greater cybersecurity and operational resilience challenges.
Rather than framing the future as a choice between humans and machines, Shah and Shah argue that compliance will become increasingly hybrid. Objective requirements, such as thresholds, reporting formats and eligibility calculations, are likely to become structured and executable, while more subjective concepts such as fairness, reasonableness and good faith “will stay in human hands, with machines assisting rather than deciding.”
They argue that the purpose of machine-readable regulation is “not to replace human judgment at all.” Instead, it is to remove the manual burden of locating rules, checking thresholds and compiling reports, allowing compliance professionals to concentrate on “weighing context, exercising discretion, and making the difficult, decisive calls that no system should make on its own.”
The critical design principle, they conclude, is transparency: systems must make it explicit where regulation has been encoded into fixed logic and where judgment remains essential, creating “a transparent, auditable bridge between legal obligations and day-to-day compliance” rather than presenting coded interpretations as though they were the law itself.
For the RegTech industry, this is a major opportunity, claims Bhavin and Pooja. “The firms that can translate regulatory intent into structured, transparent, accountable processes will help shape the next generation of regulation.”
The Sherlocq duo concluded, “The question is no longer whether machine-readable regulation is possible; early pilots have shown that it is. The real question is which parts, by whom, and with how much candour about everything the code leaves out. Get that right, and regulation could become one of the most important developments in compliance since RegTech itself emerged: transforming regulation from something organisations merely interpret into something they can interact with, test, and operate in near real time.”
No longer a concept
Aurimas Bakas, CEO and co-founder of Copla, argues that machine-readable regulation is no longer a theoretical concept-it is already operating in production. He points to DORA’s ICT third-party reporting requirements as one of the clearest examples, where firms submit information through a defined data model with fixed fields, controlled taxonomies and validation rules.
For Bakas, this demonstrates the core principle of machine-readable regulation: “the obligation and the data schema are designed together.” Because the structure is established before information is submitted, regulators can process large volumes of data without relying on manual document review.
The benefits are clear in practice. A structured DORA register allows supervisors to identify concentration risks across providers, understand which entities rely on particular subcontractors and detect incomplete submissions at scale. “Validation caught what manual review would have missed,” Bakas says, highlighting how structured reporting can improve both regulatory oversight and data quality.
However, he argues that DORA also reveals the limits of machine readability. Structured systems work best when obligations involve facts that can be clearly mapped into fields, such as provider identity, supported functions, contract details or criticality classifications.
The challenge comes when regulation requires interpretation. Determining whether an arrangement supports a “critical or important function”, for example, requires contextual judgment that a data model cannot fully capture. “Machine-readability works where the obligation reduces to structured fact and degrades where it depends on interpretation,” Bakas explains.
The wider lesson, he argues, is that successful machine-readable regulation cannot be created by simply taking existing legal text and converting it into data fields afterwards. Instead, regulatory obligations need to be designed with their underlying data structures from the beginning. DORA succeeded because its technical standards developed the data model alongside the regulatory requirement itself.
For Bakas, “the sequence matters more than the technology.” The future of machine-readable regulation depends not just on better tools, but on regulators designing rules in a way that preserves their meaning when translated into structured formats.
By Daniel Willis, Editor of RegTech Analyst
Copyright © 2026 RegTech Analyst
Copyright © 2018 RegTech Analyst
