Simple Cross-regulatory Compliance in Corda

In this blog you will learn how to implement multiple, coinciding regulatory requirements in your CorDapp (Corda Distributed Application). With minimal code, your CorDapp can adjust constraints based on the geographical region (or other parameter) of the participants.

Enterprise blockchain developers are often tasked with taking existing business processes and transforming them to a DLT workflow to increase efficiency and improve security. Corda is unique because a CorDapp has a design pattern which allows rapid analogy between its underlying code, and real-world legal agreements; through the use of States, Contracts, and Flows.

Reminder: A ‘state’ represents a share fact on ledger, a ‘contract’ is a set of rules (agreed upon by all users of the CorDapp) that governs any modification to the ‘state’, and a ‘flow’ is the program logic which orchestrates business processes and proposes/accepts transactions (state changes) on behalf of a party.

When developing on Corda, requisite stages of legal agreements are often enforced through constraints in the contract. For example, take the case of a prescription drug CorDapp which allows issuance of an on-ledger digital asset representing a shipment of prescription drugs — Rx.

Single Regulatory Framework

A real world (simplified) agreement might include the following composite STAGES (incl. regulatory reqs):

1. Issuer (Rx manufacturer) creates details of a production — Rx name, qty, price, chemical compounds, date, batch/sort code, etc.
2. — Begin regulatory requirements
   a) Sample of batch/sort code is signed as inspected by government health agency.
   b) Issuer makes sure the quantity being requested by a purchaser meets national requirements in regards to, minimums/maximums for controlled substance sale/transport.
   c) National drug enforcement agency is informed of sale transactions involving QTY greater than x.
   — End regulatory requirements
3. Purchaser (distributor) signs acceptance of the shipment details and takes possession.

Here is one possible Corda contract excerpt encompassing this business process- // STAGE X corresponds to the above real world stages:

Cross-Regulatory Framework

Using the above example, it’s easy to imagine deploying several “Regional” or “National” CorDapps to handle individual regulatory requirements between counter-parties. However, with Corda’s contract based constraints it’s very simple to branch or join various business requirements — to correctly model multiple, distinct regulatory processes.

Here we have the previous real world (complex) agreement with the composite STAGES, but now with multiple regulatory branches:

1. Issuer (Rx manufacturer) creates details of a production — Rx name, qty, price, chemical compounds, date, batch/sort code, etc
2. — Begin regulatory requirements
   RegionA || RegionB || RegionC
   — End regulatory requirements
3. Purchaser (distributor) signs acceptance of the shipment details and takes possession.

Note: in this example we are using Regional boundaries; but in the same way, other distinguished properties can be used to specify distinct requirements. For instance a business vertical, or time-window etc.

Here is one possible Corda contract excerpt implementing the necessary regional considerations— // STAGE X corresponding to the above real world stages.

STAGE 1 and STAGE 3 remain the same as the single case above so we will focus on STAGE 2 contained in verifySale() , the logic called when the command is of type DrugCommands.SellDrug:

And the definition of the Region enum utilized on line 19 is of the form:

@CordaSerializable
public enum Region {
    EU,
    NA,
    APAC;

    static Region getValue(CordaX500Name x500Name) {
        String country = x500Name.getCountry();
        if (country.equals("UK")) return EU;
        else if (country.equals("US")) return NA;
        else return APAC;
    }
}

Taking a look at STAGE 2 containing the regulatory branching, the concerning parties are pulled from the output state and assigned a Region (by whatever necessary category logic — in this case just hardcoding a single member country per region). Our simple mock CorDapp makes some assumptions such as ‘A manufacturer is the initial owner when bringing a drug on ledger’ and ‘Only the manufacturer can be the seller’. This simplifies our transacting parties, to one manufacturer and one NEW owner , to better illustrate the technique. However, realize that with a few small tweaks you can handle additional complexities.

Next in the code, the Regions are placed in a Set as a quick way to filter distinct, and finally, we apply the union of all regional constraints involved (Set<Region> r parameter) via the sub-call to regionalSalesChecks().

In regionalSalesChecks you model each individual regulatory process.

As the earlier single-framework example had only stages:
2a, 2b, 2c

Region.EU would have:
2a, … , 2x;

Region.NA would have:
2a, … , 2y;

Region.APAC would have:
2a, … , 2z

— where x, y, z represent any number of discrete regulator processes.

It’s as easy as that! Welcome to conformance! ?

This guide was a quick-start to provide ONE option towards addressing regulatory compliance with Corda through the use of Contracts. However, with the flexibility of Corda, you have many additional options to explore depending on the relationship/agreements between your transacting parties.

For instance, you may also want to leave ownership of compliance to each individual node. This could simplify navigation of complex regulatory spaces, as each participant will only need to attend to the regulations that directly affect their interests. In that case, regional checks could be removed from the contract and implemented at the flow level.

In reference to our example, imagine a manufacturer (Region.NA) and a purchaser (Region.APAC). The manufacturer could run checks in the InitiatingFlow against NA compliance before signing, and the purchaser would override the checkTransaction() method of their ResponderFlow for APAC compliance before counter-signing.

You can learn how to implement these additional strategies and discover more flexible design practices through the free online Corda training.

Want to learn more about building awesome blockchain applications on Corda? Be sure to visit https://corda.net, check out our community page to learn how to connect with other Corda developers, and sign up for one of our newsletters for the latest updates.

— Anthony Nixon is a Developer Evangelist at R3, an enterprise blockchain software firm working with a global ecosystem of more than 350 participants across multiple industries from both the private and public sectors to develop on Corda, its open-source blockchain platform, and Corda Enterprise, a commercial version of Corda for enterprise usage.

Follow Anthony on Twitter and Linkedin.