Guest post by Vidyasankar Ramalingam, Senior Consultant at Atos, a global leader in digital transformation with over 110,000 employees in 73 countries and annual revenue of over € 11 billion.
Reconciliation is a natural process that must be run periodically to ensure that parties to a transaction have the same view of the data. Inherent to this process are the characteristics of cost and latency because processes must be run to process and match large amounts of data, across multiple entities and applications with disparate technology and process infrastructures. In addition, and unfortunately, trade breaks and process errors are still not prevented unless they are performed with the same latency as well.
In this post we will:
- Show how we can minimize and even eliminate reconciliation using DLT and Daml smart contracts.
- Dispel a common privacy myth of lack of privacy by showing that Daml & DLT allow for granular, sub-transaction level privacy between organizations and applications.
Current business scenario
Traditionally, any entity – application or organization – has communicated with another entity using an “exchange of data” – either through APIs, or by file transfers. For example, investment and the custodian banks in the settlement value chain maintain their own databases with the transaction details, account level details, customer data and other reference data.
They rely on messaging architectures to carry the data sent from their counterparty, Central Securities Depository and sub custodians to do reconciliation. However, this architecture only serves to update multiple copies of the original data and does not provide any single golden source of truth.
Hence reconciliation must be carried out. The reconciliation can be at a bilateral level or multilaterally based on the number of parties involved in the settlement value chain. This is an error prone process with high effort and cost involved. Also, there is a lack of trust on the data used for reconciliation. Every party maintains its own parallel set of storage and data access infrastructures.
We considered 4 participants in the settlement value chain, Bank A, Bank B, CSD and a Central Bank. Bank A and Bank B does the transaction on behalf of their clients. CSD issues the shares to Bank A and Central Bank issues the money (Central Bank Money) to Bank B. Bank B (Buyer) initiates the DVP proposal transaction to the Bank A (Seller). Once the Seller accepts the DVP proposal, the Seller settles the shares initiating the atomic swap of shares and cash between the Buyer and the Seller.
In the current model, post the settlement of the trades the banks receive MT 535 and MT 536 SWIFT messages to denote the transaction settled and the corresponding change in the account holdings.
The banks would then compare the data from their database against the messages through the reconciliation process. The complexity of the reconciliation is bound to increase when there are more parties involved. Ex: Bank A and Bank B utilize a sub custodian to process their transactions.
Similarly, reconciliation also need to be carried out with respect to the movement of the cash.
The same data has been stored across multiple parties leading to a highly time consuming and expensive reconciliation process.
Our experiment with distributed ledgers to reduce reconciliation
We chose Daml, a smart contract based multi-party workflow language created by Digital Asset to replicate the settlement value chain.
The goal was twofold:
- Can we eliminate the need for reconciliation?
- Can we maintain privacy in ensuring that the data isn’t visible to all the participants of the chain - only visible to those who are supposed to see it?
Each participant was modeled as a Daml party, which is a built-in type in Daml. This allows the participants to avoid having to deal with the underlying ledger complexities in their business applications.
Next, we defined Daml smart contracts that represented the business rules and the business workflow that was defined between our participants. These contracts also served to model the underlying workflow. The participants of the distributed ledger each shared the smart contracts – business rules only, no data. And they exercised actions on these smart contracts to progress their workflow. The permissions to exercise actions were defined in the Daml smart contracts and enforced by the Daml runtime.
The most interesting outcome of this experiment was that each participant saw only the data it was privy to thus guaranteeing the data privacy requirements. The Daml runtime also does not allow the data visible by one participant to be out of sync with the data seen by another participant, even if they “see” different data elements depending on their privacy settings. That’s because the global state is a combination of the data contained at each of these Daml parties, and it can be verified at any time through cryptographic methods. This situation however, never arises because of the way the data is constantly verified and synced between participants. In effect, you can assume that real time reconciliation and synchronization is happening behind the scenes rather than the business applications doing external, post facto reconciliation.
Each participant thus relies on the so called “shared ledger” which still provides full privacy and confidentiality. This creates an authoritative and validated record to eliminate the need for external reconciliation efforts. In addition, one of the big advantages of using this approach is that the participants have access to real time data as it happens - a golden source.
This eliminates the need for sending MT 535 / MT 536 or the equivalent 20022 messages, which can be replaced by the real time updates to the participants. It can also remove the need for trade data enrichment, reconciliations and even the resolution of conflicts or disputes between the counterparties.
Our experiment, and also several visible projects in this space, showed that Distributed Ledger Technology (DLT) using Daml provides a great solution for the reconciliation issues and reduces the operation cost. It also solves the challenge of maintaining the privacy of data by custodians, like the customer information, collateral data and other specific information. The transactions which are just Over the Counter (OTC) agreed between two participants are visible only to the designated participants in the network. That’s because, Daml segregates the data with respect to participants and it is shared only if needs to be on a need to know basis.
Market-wide rules, encoded in Daml, are shared with all market participants, but the actions taken by participants and their data are private. Hence, during a Settlement Transaction for a T2S specific market regulation the data is shared only across the participants who need to know. E.g., movement of shares from Bank A to Bank B is visible to the respective banks and the CSD. Similarly, the movement of cash from Bank A to Bank B is visible to the respective banks and the Central Bank. This ensures that the participant who is not part of a particular transaction, doesn’t have access to view the data.
The CSD has access only to the movement of the Shares across participants and not the Cash legs.
Conclusion:
Financial Institutions face challenges in reconciliation due to inadequate information and communication mismatch due to timing with the parties in a settlement value chain. This reconciliation is costly and often causes undesirable latencies in executing business processes.
In fact, business processes are often built around these latencies. Daml, by bringing in the solution to access real time data eliminates reconciliation thereby reducing operational risk, cost, delays and inefficiencies. Daml not only solves the inter-company reconciliation issues, it also solves intra-company reconciliation. In addition, by being portable across ledgers and by exposing a common API, Daml allows for a simpler overall architecture which ensures that business and technology teams can operate as a single unit to bring best in class products to market much quicker.