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.
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.
The benefits of this type of a modern architecture over traditional message-based or API-based architectures are:
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:
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.
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:
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.
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.