Teams all over the world, including in Australia, are already experimenting with coding prescriptive rules in legislation, regulation and policy. Beyond just ‘regtech’, the approach of coding the rules on which our society runs promises better results and new opportunities for the public as well as regulators and companies looking to make compliance easier.
The Prime Minister made waves recently at his annual address to the Australian Public Service when he declared a personal fondness for ‘regtech’ and said that he hoped we will see “within the next decade… legislation written in [computer] code”.
Well, in this instance, we don’t need to wait a decade. In fact, the future is now. Teams all over the world, including in Australia, are already experimenting with coding prescriptive rules in legislation, regulation and policy. Beyond just ‘regtech’, the approach of coding the rules on which our society runs promises better results and new opportunities for the public as well as regulators and companies looking to make compliance easier.
Why should we do this?
For the uninitiated, ‘regtech’ refers to software that make it easier for companies to comply with their various regulatory requirements. Companies and government departments have to continually translate the relevant legislation, laws or rules into software and machine consumable languages — code — and this allows them to use digital systems and platforms to automate some of their compliance obligations. For example, banks routinely develop systems which automate or assist with the recording and reporting of large transactions to help them comply with anti money-laundering and counter-terrorism financing laws.
The private sector is currently investing heavily in regtech because it will save them money by reducing compliance costs. Deloitte Access Economics estimates that Australian federal, state and local government rules and regulations cost $27 billion a year to administer, and $67 billion a year to comply with. So it’s no surprise that the private sector is enthusiastic in looking for new solutions in this space.
However, making laws and other rules machine consumable could also be used to deliver a host of benefits for governments and the community.
Rules as Code would enable better, faster, more transparent services
Firstly, legislation isn’t a scintillating read — it’s drafted for precision of meaning, not readability or accessibility. This means that anyone outside of the legal industry (and many people within it) can find laws difficult to understand. If we publish machine-consumable version of our laws, we can build systems and services to make them easier to understand and apply.
An excellent example is the ATO’s eTax offering. By coding its taxation rules, the government has created an easier and more efficient way for us to lodge tax returns, and has even automated certain aspects of the process by enabling ‘prefills’ via integrations with banks and insurers. Also in the world of taxation, the French government has used its coded taxation rules to build a series of ‘simulators’ to help French taxpayers understand how tax laws apply to them.
We can take this approach with other systems and services, and use coded rules to deliver services that are not only faster, but fairer and more transparent. That is, we can use coded rules to build automated or semi-automated systems that deliver a result, an explanation of the rules applied to get to the result, and all inputs and evidence considered. It’s essential that decisions be transparent and explainable, especially for governments, whether those decisions are made by a person or a machine.
Rules as Code would eliminate needless duplication
Secondly, it would be far more efficient. Currently, we have numerous businesses each coding their own version of the same laws. This creates the risk that translations will be incorrect or misinterpreted. In contrast, a single government-provided and assured translation, made available via Application Programming Interfaces (‘APIs’, which make it possible for machines to speak with one another and transact) would cut down on this needless duplication. Regulators would be able to see the rules being consumed, and the community would have certainty that the rules being used by automated systems were the correct interpretation (or even certified to be correct). A single set of government-assured coded rules would also be a boon to the private sector. They wouldn’t have to devote resources into translating the rules into a form their systems could use — saving money, increasing productivity and profits and, therefore, increasing the tax base.
What’s more, individuals, small businesses and startups could use the APIs as well, removing expensive barriers to competition and creating a more even playing field. For example, at this year’s GovHack, one team used the eligibility rules from ServiceNSW’s cost of Living Service, coded by the Digital.NSW Rules as Code project, to create an education support tool to guide parents through the available rebates and services from kindergarten to high school. And they did this in a single weekend.
As a bonus, when the rules or laws change, the code can be amended and the linked systems would be updated automatically. Everyone wins.
Rules as Code would give us a new way to model and test laws
Thirdly, if our laws are machine consumable, we can take a whole new approach to testing them, and modelling different legislative approaches.
Specifically, we can use coded rules to rapidly test proposed rulesets against dozens, hundreds or thousands of test scenarios to see if they will operate as intended — what’s known in the software world as ‘regression’ testing. We can also model more efficiently — try out different options, and see which gets us closer to the desired effect.
Of course, this ability is only useful if there’s an opportunity to change the rules. If the ruleset is contained in legislation that has already been enacted, it’s going to be more difficult to amend them. This means that we need to rethink how we draft rules. It won’t be sufficient to draft and pass legislation, and circle back to do the translation — we have to draft the code and the human-readable text at the same time, and allow them to influence each other.
In this respect, we can learn a great deal from our antipodean cousins in New Zealand. The “Better Rules” work being done by the New Zealand Government has shown that unless we modernise how we draft policy and legislation, then we will miss the opportunity to make fundamentally better rules in the first place.
As our Kiwi colleagues are currently ably demonstrating, effective test driven regulation and legislation means firstly assembling a multidisciplinary group of policy, drafting and rules consumers (service designers and developers) to understand and agree the purpose, concept and logic behind a piece of legislation with an accompanying coded ruleset. By collocating with drafters and coders, this group can then simultaneously co-draft human and machine readable versions of the rules for testing — with humans and machines. This allows for more holistic modelling of impacts, and provides and the opportunity to test the coded rules with end users (regulated entities, service providers, etc.) before publication.
Ideally, if dealing with a legislation ruleset, the draft legislation would be published for consultation together with an API enabling access to the draft coded rules, and stakeholders could test the rules and use the code to inform their submissions. Once enacted by Parliament, the machine readable form (the API) could be publicly available immediately. Regulated entities could link their systems to the ruleset instantly, reducing the time and cost to implement and reducing the risk of mistranslation or variability in interpretations.
We still need human-readable rules
Of course, this doesn’t mean that we should only write legislation or policy rules in code. Humans still need to be able to read and interpret rules. Further, machines can’t do nuance or interpretation. They only deal with absolutes. The rules we can currently code effectively are prescriptive — black or white, yes or no. Many of our laws are not prescriptive, but require subjective perspectives and nuance, consideration of the various circumstances of the case. That is, we need humans — administrators, regulators, lawyers, judges — to interpret and apply them.
Even in those scenarios, coded rules can help — by automating the black and white aspects of the question, we can escalate the parts that require nuance for human consideration.
This will allow us to dedicate our human resources to the difficult and complex work, leaving the process-driven drudgery to our robot friends.
How do we do this well?
We need to be open
As a society, we’ve put a lot of effort in making sure our laws are available to everyone — we publish them on websites in full, such as legislation.gov.au, and make them available for use and reuse. We need to do the same for our coded rules. The code needs to be visible and inspectable — if our rules have an error, we want and need to know. We also need to make it easy to use — it can’t be proprietary or expensive to adopt. So it has to be open, and based on an open source platform.
We can learn from the world of encryption, where the community ensures that new algorithms are thoroughly inspected, tested and debated. This means some are eventually cracked but, ultimately, the most robust implementations survive.
We need standards
We need to establish standards or users are going to run into problems with interoperability. We need to think about minimum standards for the logic of legislation so that all legislation as code APIs behave predictably, regardless of the platforms used. Such a standard does not yet exist, and most ‘rules as code’ platforms focus entirely on the translation of rules into code rather than taking a born digital approach to rules in the first place. Worse, most current platforms don’t allow for easy and consistent API access to the rules independent from business logic, which limits the reusability of rules.
It is also worth noting that everytime we encode government rules in yet another business system, we are contributing to the complexity. Ideally we would have api.legislation.gov.xx available where government is the authority of those rules so the rest of us can simply consume from government.
We need a multidisciplinary approach
Right now, there are very few lawyers who can code, and there are precious few coders that can grapple with public policy and laws. The principles of service design have also yet to enter law school curriculums. One day, that may change, as law schools are currently busy training the next generation of tech-enabled lawyers. But for now, the only way to get the necessary skills in the drafting room is to be multi-disciplinary — take the drafters, the coders, the policy experts and the designers and have them work together to create the rulesets.
Where to start?
We should begin in logical areas where strong prescriptive rules exist already. Financial institutions have led the way, and there is a lot of existing work that can be used to forge ahead quickly.
There are many regulatory frameworks where strict rules apply — for example, building codes, food safety, logistics. Ultimately, the only way to eat an elephant is one bite at a time. We just need to make a start, and keep building.
It’s here we’ll start running into some resourcing problems. To learn to code rules well, we need to experiment. We’ll need to devote some time and money to trying different approaches. We’ll need to be able to fail, and fail safely. This will require a shift in approach and in risk tolerance from most governments.
This is a new discipline, and we’re going to have a skill shortage. Of course, this is hardly unusual. Whenever new technologies are developed, we have to build the skills in the work to use them — we’ve done it with everything from shipbuilding to cyber security, and we can do it here. The challenge will be finding the resourcing to provide the right people with the time and space to learn.
We don’t have all the answers yet. But we mean to find them, and at the very least it promises to be an interesting journey.