Crossing the trust boundary with DLT pt2: The Company

In the last article, “Crossing the trust boundary with DLT pt1: Consortiums”, I looked at some fairly well understood topics on the trust model of consortiums.

In this article I will explore how Distributed Ledger Technology (DLT) can be exploited in a single organisation. There are not too many obvious use cases for the single organisation due to the theoretical absence of trust boundaries. However, they are worth looking at as they present a potentially easier route to apply DLT successfully. It is easier to realise business case benefits through change, if you only have one organisation to change. Also, and often overlooked, each DLT implementation requires a standard data model between participants. Again this is easier in one company than between companies.

Before we delve into a single organisation it is worth looking at two distinct forms of trust:

1. Behaviour trust - Where another party is trusted to behave in a particular way based on past experience

2. Intention trust - Where there is confidence in another party’s intentions and therefore there is no reason to have excessive walls up.

So what does a trust boundary look like inside an organisation? The natural place to start would be where you have business processes crossing legal entity boundaries. Here you might use the term semi-trusted as you would hope that each legal entity is motivated such that the group will succeed. In other words, there is high Intention trust. However, local priorities and process variations may cause business to be conducted in a slightly different way. Combined with a potential lack of regular interaction with those in other legal entities could cause there to be low Behaviour trust (see Half life of trust ).

Another example is in an organisation that has to share data across a Chinese wall. These are used where two teams in the same legal entity (even the same office) are engaged by the same client but the Regulator requires they do not share confidential information. For example an equity trading desk and an M&A team working on assets of the same company. Here Behaviour trust may be high but it is critical that Intention trust is low.  

When there is low trust of either or both there is a trust boundary that DLT can offer a solution to. One natural objection to using DLT in an organisation would be why not use a distributed database available to all teams in the organisation? The answer is two fold:

1. Politics and ownership, or

2. Business logic around how changes are applied

The next example should help demonstrate those two factors in action.

REFERENCE DATA - GOLDEN SOURCE

Sometimes described as “the third rail” of IT projects, Reference data consolidation programmes have a nasty habit of hurting those that touch them. In some cases they actually increase the application landscape rather than reducing it. There are lots of reasons for this, but commonly cited are the need to maintain control and ownership over their own data store, or they require control over how changes to the actual data are applied.

To maintain control and ownership, it is usually easier to maintain separate copies and run reconciliations than to give up control, especially around structural changes. In a centralised model, a change request is exactly that, a request, and usually prioritised against everyone else’s. Leading to internal politics around who prioritises what (a classic case of Not Invented Here Syndrome) and trust issues.

The latter is about how changes to the data itself are applied. If you are running a data store with many feeds from across the organisation you are largely in control of updates to the data. In the distributed database model (or central database with API access) updates to the data have to happen centrally to avoid chaos and maintain trust of the data

DLT offers remediations to both of these problems. On the point of control and ownership, when you run a node of the ledger that is your node as opposed to API / feed access to a far off database. However, it gets very interesting when you look at how updates to the data are carried out. In the case of corporate actions, imagine how the change in a dividend date propagates throughout the organisation. Smart contracts can control exactly who has to approve it before it becomes added to the ledger. Some low impact updates may be passed straight through, others may require a complex approval process. On chain logic such as this is available in DAML on the Digital Asset Platform and can make this type of non-trivial business process a reality.

Interestingly using something similar to the governance capability in Cordite on the Corda platform, structural changes to the process can be democratised as well, allowing a more efficient management method.

While not being common, single company use cases for DLT are interesting as they have a shorter time to deliver the value.