Almost all of us have been a beneficiary at some point of credit reporting systems. These are in place not only in the United States, but also around the world—to varying levels of sophistication. In these systems, both consumers and businesses have a simple and fairly effective vehicle for credit risk assessment and decision making. 

While it looks simple enough on the surface, there is a lot going on under the hood. Every transaction must be reported or furnished to the credit bureaus so that these entities can then maintain a score and history of every consumer and business. For example, in the U.S., when you open a line of credit with a credit card company (i.e., a data furnisher), the total credit limit, the payments you make, missed payments, monthly balances, and your delinquencies are all reported to the three primary credit bureaus using the Metro2 format of data reporting. These bureaus then compute a total credit score and other summary information. They also are required by law to provide this information to you for free once a year, upon request.

As you can imagine, all of this information exchange is being performed using technology that necessitates data transfers from one party to the other. As a result, both consumer and business data is in multiple databases and file systems at the same time—not only between companies, but also within a company across different departments. This is a huge compliance and security risk, and substantial investment is being made to mitigate risks to the consumers. When this happens within an enterprise, it leads to reduced ability to innovate quickly and poor customer experiences across channels.

In this post, we will discuss how to streamline this infrastructure using modern technology like Daml smart contracts and distributed ledger protocols such as Canton. We will also show that blockchains are an optional component of this modernization. Daml also has a finance library that makes it easy to model events and workflows for the most complex of financial instruments.

We will focus on streamlining operations and data transfers internal to any financial institution. We will also show how regulatory and compliance reporting can also be easily simplified. As the collaboration mechanisms become clear, then including external entities will be a logical extension. In the United States, this will include the three credit bureaus.

Our use case

Let’s consider a credit card company. As a credit card lifecycle executes from new card issuance, to payments, to closure or delinquency, the company, as a furnisher, needs to aggregate and send the data to the credit bureaus.

In a typical enterprise, the systems that issue cards are different from payment processing systems and line of credit systems. A separate fraud detection system is also maintained. There is an elaborate messaging and API-based architecture in place to manage all this collaboration and information exchange. In the absence of modern messaging, companies also rely on data file transfers.

As you can see, every customer transaction results in multiple information transfers within the enterprise. Every application or module is specialized and therefore maintains their own record of the transactions that are regularly synced with the other systems as needed. As a result, there are inherent latencies and risks with this kind of legacy architecture. These lead to high overheads.

Technologies such as Daml smart contracts can mitigate all of these expensive data transfers and reconciliations, resulting in a simplified reporting and audit process.

The updated conceptual architecture will look something like this:

As seen in the illustration, each application has access to their individual copy of the virtualized golden source. The golden source is maintained not by putting everything in a single repository, but through a comprehensive mechanism of disclosures according to the privacy rules. 

It must be noted that both the golden source and the individual data stores can be either virtual or physical in nature. An enterprise can decide which mechanism is best suited for them. 

• When the individual data stores are physical, the Canton distributed ledger protocol keeps them in sync. This is also the reason why a permissioned blockchain is not needed to provide physical privacy boundaries. 
• When the data stores are virtual (which is typically the case for different applications within an enterprise), the golden source is physical, and the individualized stores are virtual. 

The benefits of this type of a modern architecture over traditional message-based or API-based architectures are:

1. The golden source is automatically maintained. There is no need for offline data transfers and aggregations. The location of this golden source is immaterial: It can be maintained on any cloud or the storage infrastructure of choice. In both API- and messaging-based architectures, there is a duplication of data at each end of the communication.
2. Only the relevant parties have access to the data they are entitled to, and each party only has access to the contracts that they are a party to. With the built-in disclosures, rights, and obligations guarantees of Daml, no party not eligible to view a contract can do so. This pushes much of the software plumbing required to check access privileges under the hood, thus simplifying the architecture and better meeting compliance requirements.
3. There is no requirement to have a blockchain for any component of this architecture. Trusted parties in a permissioned environment can reap all the benefits of a blockchain without the ensuing proof of work or stake requirements. This simplifies the landscape tremendously.
   
   

Reporting

So far we’ve seen how a golden source of transaction data can be maintained to the desired level of privacy granularity between different applications. Now let’s see how the reporting to the bureaus can be similarly streamlined.

We do this by making the reporting application an Observer party to the transactions. Observers see the contracts but cannot take an action if none has been defined for them. It follows that every transaction that needs to be reported to the credit bureaus is now available in the virtual contracts store of the reporting application. There are no ETLs needed and no reconciliations. The data is of the highest quality, is fully consistent, and is available in real time. If the data furnisher (our hypothetical credit card company) decides to send the data to the bureau in real time, now they can do so without any additional overhead in three steps:

1. Pull the contracts after a specified date (e.g., since last transmission) from the smart contract store of the reporting application.
2. Convert them to the desired Metro2 or other format.
3. Transmit (when external entities are onboarded to the network, this 3rd step will become redundant).
   
   

Practical implementation

Below is how this entire process will be written in Daml. Each application has a right to make a transaction on the customer contract only when it’s time for them (this is done using the controller keyword), and the resulting contracts are visible only to the signatories, controllers, and observers of those contracts. By controlling who these parties are, we can control the disclosures and protect privacy. Keep an eye out for these various parties as you read the sample below. 

Keep in mind this is an illustrative—but fully functional—model. So if something does not align with your processes, you can always tailor this. We have kept it simple so that it’s easy to understand the power of this new technology paradigm.

First, we define an EnterprisePlatform contract where the company can onboard a customer to create the CustomerRelationship contract. A contract called ReportCustomerRelationship is also created that is automatically visible to the reporting application. This has been created to show you how we can control the disclosures. For example, if we had additional data elements in the CustomerRelationship contract that we did not want seen by the reporting application, then creating a separate ReportCustomerRelationship contract achieves that purpose.

In this way, the real-time reporting of this new customer relationship is automatically achieved without the need for any reconciliations and data transfers.There is no need to transfer data to or from anyone.

We see that the customer has a right to request a spend transaction on their customer relationship. This is because they have been declared as a controller. Customers do that by using a function defined as Transact. These functions are called choices in Daml, and only the controllers can exercise these choices. 

When a TransactionRequest is received, it is first seen by the CreditAuthorization system. Once the auth is provided, the transaction automatically goes to the FraudSystem to enable a real-time fraud check. 

At no point is any data transfer needed between any of the systems. 

Only when the FraudSystem approves the transaction is the customer transaction successful. At the same time, a record of this transaction is automatically sent to the Reporting Application, again enabling real-time reporting without latencies or reconciliations.

In the example above, you can see that limited information can be shared in the contracts that are destined for different parties. This means that a granular privacy mechanism can be applied while defining the business process flow itself. This is a tremendous boost for compliance and security, as all of this is done under the hood, rather than being left to implementations of different applications.

Physical segregation and privacy of data

In addition to these zero-latency and reconciliation benefits, there is another key advantage. Sometimes, physical segregation of data between parties may be required. For example:

1. The fraud detection system of an enterprise may not want the contracts containing data about decisions to be stored in the same smart contracts store that other applications use. They may want their data to be physically segregated. Regulations sometimes require it.
2. Similarly, if the applications are processing transactions from different countries, then data domicile requirements may require the data for each jurisdiction to be separate. These requirements are also often mandated by government regulations.

Traditionally, addressing these requirements have meant separate data stores, expensive reconciliations, and large latencies and errors in analytics and reporting. However, these requirements are easily addressed using the Daml smart contracts architecture along with the Canton distributed ledger. An added advantage is that this architecture also does not require a separate blockchain.

In this case, we let the fraud detection application exist on a separate Canton domain. This just means that their information is physically segregated, and only the data that needs to be shared with other applications is available to the applications on the left. The Canton interoperability protocol pushes these automatic syncs and privacy concerns under the hood. Thus, we don’t have to write ETLs or implement any other elaborate mechanisms to maintain the golden source of data, ensure privacy requirements, or worry about compliance data breaches.

Conclusion

The data and process architecture described in this blog is a game changer for enterprises. It is already in use at large financial services institutions including Broadridge, the Hong Kong Exchange, Goldman Sachs, and the Australian Securities Exchange, among others. 

The promise of minimal reconciliations and zero latencies in making the right data available to the right party is an exciting one. There is now also a Daml Finance library that makes it easy to model complex lifecycle events of financial instruments. Learn more at daml.com.