How can we eliminate reconciliation in financial markets?

Reconciliation is a natural process that must be run periodically to ensure that parties to a transaction have the same view of the data.

'Helvetica Neue', Helvetica, Arial, sans-serif

DAML Driven Blog

DAML Driven

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:
<ul>
<li>Show how we can minimize and even eliminate reconciliation using DLT and DAML smart contracts.</li>
<li>Dispel a common privacy myth of lack of privacy by showing that DAML &amp; DLT allow for granular, sub-transaction level privacy between organizations and applications.</li>
</ul>
&nbsp;
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.&nbsp;
The goal was twofold:
<ol>
<li>Can we eliminate the need for reconciliation?</li>
<li>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?</li>
</ol>
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.&nbsp;&nbsp;
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.
<img src="https://hub.daml.com/hubfs/image2.png" alt="image2" width="1280" style="width: 1280px;">The Central Bank has access only to the movement of the Cash across participants and not the Shares.
<img src="https://hub.daml.com/hubfs/atos%20pic%202.png" alt="atos pic 2" width="974" style="width: 974px;">
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.
<a href="https://docs.daml.com/getting-started/installation.html" rel=" noopener">Download the DAML SDK now</a>!

<html>
 <head></head>
 <body>
 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. 
 </body>
</html>

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.

module_15571537756151858

module_1557431396199392

module_1563914750727231

DLint : Expert help writing DAML

DLint analyzes your code while you’re typing it, looking for issues and making suggestions on how you might care to improve it. It’s highly configurable (you can turn warnings off and on with granular scope control).

DAML Engineering Blog

Engineering Notes

For developers of all skill levels, it’s a constant challenge to keep in mind the myriad of ways the code we write could be better. For DAML developers it’s not different. We wish to produce programs that are elegant, efficient, readable by others ... the list goes on. With each PR, we look to our code reviewers to advise us on (at least) the most obvious improvements we could make. This is especially true for DAML newcomers. One of our main goals with DAML is to make developers extremely productive, and to make it easy for them to build high quality and secure code. The faster a developer gets feedback, the more productive they are. Relying on code review has an unfavorable feedback latency and getting full value can be "hit and miss". Wouldn't it be ideal if, while programming, you had an expert at your shoulder offering advice? With the linting features we are integrating into the DAML IDE, the developer gets that advice as they type. DLint analyzes your code while you’re typing it, looking for issues and making suggestions on how you might care to improve it. It’s highly configurable (you can turn warnings off and on with granular scope control). The suggestions are easy for programmers of all levels to understand and where it makes sense, provides suggested code. Taking advantage of it is very easy and its use improves code quality! The image below shows DLint in action. The IDE is warning that it found a block of duplicated code (suggesting an improved version would “factor out” the common block into a function).
<img src="https://hub.daml.com/hubfs/main.png" alt="main" width="1051" style="width: 1051px;">Here’s another example of the sort of thing it can do. Given this function,
<img src="https://hub.daml.com/hubfs/negate.png" alt="negate" width="1083" style="width: 1083px;">DLint provides the following suggestion:
<img src="https://hub.daml.com/hubfs/foldr.png" alt="foldr" width="1084" style="width: 1084px;">
The suggestion here is that we replace our multi-equation recursive function with a one line version using the idiomatic standard library function foldr. 
This is an engineering note, so now let’s get a little into how it's implemented.
DLint is achieved by the adaption and integration of <a href="https://ndmitchell.com/">Neil Mitchell</a>'s celebrated HLint package. HLint is a venerable program with over 15+ years of active development and HLint's use by the Haskell community is ubiquitous. The integration is made possible by the fact that we wrote the DAML IDE in Haskell and that the DAML compiler <a href="https://www.youtube.com/watch?v=mQulFrOp0Rg">uses the GHC stack "under the hood"</a>.
We do a lot of cool open source work at DA. Part of getting this functionality into the IDE means submitting lots of updates to upstream <a href="https://github.com/ndmitchell/hlint">hlint</a> (to use the <a href="http://hackage.haskell.org/package/ghc-lib-parser">ghc-lib-parser</a> package). Also, check out the <a href="https://github.com/digital-asset/ghcide">ghcide project</a> where we're contributing parts of this technology to the Haskell community! DAML itself is completely open source <a href="https://github.com/digital-asset/daml">here</a>.
We are super proud of how the DAML IDE is coming along. Try the new DLint features for yourself! You can download the DAML SDK <a href="https://docs.daml.com/getting-started/installation.html">here</a> and <a href="https://github.com/shayne-fletcher-da/lint-demo">this git repository</a> will give you a quickstart exploring some of DLint’s capabilities.

<html>
 <head></head>
 <body>
 For developers of all skill levels, it’s a constant challenge to keep in mind the myriad of ways the code we write could be better. For DAML developers it’s not different. We wish to produce programs that are elegant, efficient, readable by others ... the list goes on. With each PR, we look to our code reviewers to advise us on (at least) the most obvious improvements we could make. This is especially true for DAML newcomers. One of our main goals with DAML is to make developers extremely productive, and to make it easy for them to build high quality and secure code. The faster a developer gets feedback, the more productive they are. Relying on code review has an unfavorable feedback latency and getting full value can be "hit and miss". Wouldn't it be ideal if, while programming, you had an expert at your shoulder offering advice? With the linting features we are integrating into the DAML IDE, the developer gets that advice as they type. DLint analyzes your code while you’re typing it, looking for issues and making suggestions on how you might care to improve it. It’s highly configurable (you can turn warnings off and on with granular scope control). The suggestions are easy for programmers of all levels to understand and where it makes sense, provides suggested code. Taking advantage of it is very easy and its use improves code quality! The image below shows DLint in action. The IDE is warning that it found a block of duplicated code (suggesting an improved version would “factor out” the common block into a function). 
 </body>
</html>

For developers of all skill levels, it’s a constant challenge to keep in mind the myriad of ways the code we write could be better. For DAML developers it’s not different. We wish to produce programs that are elegant, efficient, readable by others ... the list goes on. With each PR, we look to our code reviewers to advise us on (at least) the most obvious improvements we could make. This is especially true for DAML newcomers. One of our main goals with DAML is to make developers extremely productive, and to make it easy for them to build high quality and secure code. The faster a developer gets feedback, the more productive they are. Relying on code review has an unfavorable feedback latency and getting full value can be "hit and miss". Wouldn't it be ideal if, while programming, you had an expert at your shoulder offering advice? With the linting features we are integrating into the DAML IDE, the developer gets that advice as they type. DLint analyzes your code while you’re typing it, looking for issues and making suggestions on how you might care to improve it. It’s highly configurable (you can turn warnings off and on with granular scope control). The suggestions are easy for programmers of all levels to understand and where it makes sense, provides suggested code. Taking advantage of it is very easy and its use improves code quality! The image below shows DLint in action. The IDE is warning that it found a block of duplicated code (suggesting an improved version would “factor out” the common block into a function).

Release of DAML SDK v0.13.23

DAML SDK Release Notes

Release Notes

<h2>
<a id="user-content-daml-integration-kit" class="anchor" href="#daml-integration-kit" aria-hidden="true"></a>DAML Integration Kit</h2>
<ul>
<li>The reference implementation can now spin up multiple nodes, either scaling
a single participant horizontally or adding new participants. Check the CLI <code>--help</code> option.</li>
<li>The test tool now runs the double spend test on a shared contract in a
multi-node setup (as well as single-node).</li>
<li>The test tool can now run all semantic test in a multi-node setup.</li>
</ul>
<h2>
<a id="user-content-daml-standard-library" class="anchor" href="#daml-standard-library" aria-hidden="true"></a>DAML Standard Library</h2>
<ul>
<li>
BREAKING CHANGE The <code>(/)</code> operator was moved out of the <code>Fractional</code> typeclass into a separate <code>Divisible</code> typeclass, which is now the parent class of <code>Fractional</code>. The <code>Int</code> instance of <code>Fractional</code> is discontinued, but there is an <code>Int</code> instance of <code>Divisible</code>. This change will break projects that rely on the <code>Fractional Int</code> instance. To fix that, change the code to rely on <code>Divisible Int</code> instead. This change will also break projects where a <code>Fractional</code> instance is defined. To fix that, add a <code>Divisible</code> instance and move the definition of <code>(/)</code> there.</li>
</ul>
<h2>
<a id="user-content-daml-assistant" class="anchor" href="#daml-assistant" aria-hidden="true"></a>DAML Assistant</h2>
<ul>
<li>The HTTP JSON API is now integrated with the
assistant and distributed with the SDK. It can either be launched
via <code>daml json-api</code> or via <code>daml start</code>. You can find more information in the
<a href="https://github.com/digital-asset/daml/blob/master/ledger-service/http-json/README.md">README</a>.</li>
<li>The <code>daml.yaml</code> file now supports an additional field
<code>build-options</code>, which you can use to list cli options you want added to
invocations of <code>daml build</code> and <code>daml ide</code>.</li>
</ul>
<h2>
<a id="user-content-json-api" class="anchor" href="#json-api" aria-hidden="true"></a>JSON API</h2>
<ul>
<li>
BREAKING CHANGE The <code>/contracts/search</code> request payload must use
<code>"%templates"</code> in place of <code>"templateIds"</code> to select which templates' contracts are
returned. See <a href="https://github.com/digital-asset/daml/issues/2777">issue #2777</a>.</li>
</ul>
<h2>
<a id="user-content-daml-compiler" class="anchor" href="#daml-compiler" aria-hidden="true"></a>DAML Compiler</h2>
<ul>
<li>
BREAKING CHANGE Move the DAML-LF produced by generic template instantiations closer to the surface syntax. See the documentation on <a href="https://docs.daml.com/app-dev/daml-lf-translation.html#template-types" rel="nofollow">How DAML types are translated to DAML-LF</a> for details.</li>
</ul>

The developer’s choice for building smart contracts

Be Productive

Grow your Solution

Choose your Platform