Subscribe to Ex Machina to receive new posts directly to your inbox.
Collect this post as an NFT.
Over 2.6k subscribers
As more and more of our transactions take place within environments that are digital from end-to-end, the easier it is for us to embed regulations directly into the code that these environments are made of. To do that we will need to build governance modules into our digital public infrastructure.
This is a link-enhanced version of an article that first appeared in the Mint. You can read the original here.
Laws and regulations describe the constraints within which a society functions. They do so, in part, to provide structure and predictability to our interactions. The more complex and inter-dependent our social and commercial circumstances, the greater is our reliance on these systems of legal ordering.
As our world becomes more digital, the greater is our need to try and embed the regulations to which we are subject directly into the digital systems that enable our interactions. We can already begin to see early signs of what this might look like in the ways our stock markets and digital payments ecosystems operate, given that their digital workflows already implement underlying regulatory architectures designed to ensure the safety of participants and the certainty of their transactions. The more we integrate digital technologies into our daily lives, the easier it should be for us to define through code the regulations to which different aspects of society are subject.
The Beckn protocol—that has featured previously in this column—is a digital ecosystem for commerce. It is designed to enable interoperable digital workflows across a broad range of commercial transactions. Buyers of goods and services can use the open digital networks that Beckn enables to consume commercial resources that sellers have made available on it. In doing so, it offers an alternative to the vertically integrated digital platforms we have grown accustomed to.
But more importantly, since it describes end-to-end digital workflows for commercial interactions, the Beckn protocol offers us the opportunity to embed regulations pertaining to the commercial transactions performed on it directly into the code of the digital ecosystem. How would that work? Before we go there, let’s quickly refresh ourselves on how Beckn works.
Commercial transactions have three basic components—discovery, ordering and fulfilment. Beckn describes these components using digital protocols. Sellers can use the discovery protocols to catalogue the various products and services that they currently have on offer, making them discoverable so that they can be accessed by potential buyers.
Once a buyer has decided what she wants, she can use the ordering protocols to select it and agree to the commercial terms for its procurement. It is at this point that the fulfilment protocols take over, allowing the goods and services to be supplied in accordance with the agreed terms.
Beckn also addresses any post-fulfilment issues that may arise. It can take care of situations where the goods are found defective or the services were not performed satisfactorily by allowing customers to raise grievances and eventually either reverse the transaction or receive compensation.
This is a digital system that makes it possible for small businesses and local shopkeepers to sell their products to hyper-local customers who can choose from what is available, and, using the ordering and fulfilment protocols, purchase what they want and have it delivered to their doorstep. Payments can be made using India’s digital payment infrastructure, while fulfilment initiates another commercial workflow that is itself enabled by Beckn using the same discovering-ordering-fulfilment protocols that are applied to delivery services.
As good as this is, in order for it to be a truly comprehensive digital solution, one additional layer is required. All commercial transactions are constrained by different laws, which means that in order to fully describe these commercial constructs, we need our protocols to account for all these regulatory constraints.
Broadly speaking, regulations fall into one of two buckets. The first authorises a person to perform a given activity. For instance, no one can operate a vehicle without a driver’s licence, just as no one can sell a pharmaceutical drug unless they are registered as a pharmacist. If we are to digitally describe a commercial transaction that involves either the operation of a motor vehicle or the sale of a pharmaceutical drug, we need to make sure that these transactions can only proceed if the persons performing them have the required permissions in place. In other words, if the transaction involves the sale of pharmaceutical drugs, the protocol must confirm that the drugs are being dispensed by a registered pharmacist. If the customer is being offered a ride, the protocol should confirm that the taxi driver holds a valid driving licence.
The second category of regulation pertains to the transaction itself. Certain types of transactions can only be performed with permission and subject to such restrictions of time and geography as prescribed by the regulator. In such circumstances, for the transaction to proceed, the protocol should be designed so that it can confirm such authorisation. For instance, if a musical performance is only permissible under a licence obtained from a copyright society, the protocol should not allow the transaction to proceed if such a licence is not in place.
What we need is for the protocol to signal whether a person is authorised to perform the transaction and whether the transaction can take place under law. If we can do that, we will have programmatically embedded regulatory constraints into a digital workflow. Designed well, this governance module will be capable of describing a wide range of commercial arrangement and the regulations that apply to them.
