In this section, we introduce zkABS, a platform based on zkLedger that aims to reduce the information asymmetry in the market. In our use case, zkABS is used as a model to share loan electronic records among distrusting participants in a secure and confidential way without compromising the independent verifiability of the data. We argue that the securitization industry would benefit from this technology in order to allow all market participants, including investors, to join the ledger while preserving confidential information. zkLedger could allow investors and issuers to interact on the same decentralized digital platform and get access to near-real time updates about ABS products’ performance while preserving the confidentiality of the underlying loan-level data.
Architecture and governance system
This paper does not intend to recommend any DLT architecture for the securitization industry as this would be an ambitious separate problem to address for each step of the securitization lifecycle, but rather, to provide a simplified architecture and governance system and analyze the benefits for market participants. Such a simplified architecture would have the following components:
A permisioned ledgerDue to the sensitive nature of the information disclosed and the types of participants involved in the securitization market, we adopted the framework of a permissioned ledger with a consensus protocol for append-only information which globally orders all valid transactions. Financial institution consortia are considering the use of permissioned ledgers as they offer efficiency and security. Under these settings, the consortium is responsible for operating the ledger, validating transactions and granting access to new entrants. In zkABS, participants cannot equivocate (assuming the consensus model is sound), therefore the information in the ledger is secure and publicly verifiable by participants. By “publicly” verifiable, we imply that anyone with the permission to access zkABS and get a full copy of the ledger can verify the inputs and outputs. Figure 3 illustrates zkABS’s permissioned distributed ledger architecture for an ABS product issued by an SPV and backed by auto-loans from the Originator. Each participant in zkABS has two dimensions of flexible settings: write/read permissions and privacy settings.
Read/Write permissionsParticipants that contribute to building and updating asset-backed securities (e.g. the SPV and Servicer) have modification rights to update loan-level payments, pool-level performance and rating information. Other participants have read-only rights.
Append permission: the SPV has the right to create new loan ID and append initial information to the ledger.
Edit permission: the Servicer has the right to update information of current loans using a checkpoint system. At regular intervals defined by the system (e.g. near-real time), all the cryptographic commitments are updated and re-posted in the ledger with initial order preserved. Reposting the complete set of commitments to the ledger guarantees that no one can see which loan data points have been updated. Each checkpoint is recorded in the system as an immutable time-stamped log.
Read permission: read permissions are given to Rating Agencies, Investors, Regulators and Auditors of Issuers and Investors in order to perform their data analysis. They act as observatory nodes in the network.
Privacy and Selective Visibility zkLedger introduces the concept of selective visibility. Each participant has access to either loan-level data (loan-level basis access) or asset pool-level data (aggregate basis access). In zkABS, the SPV, Servicer, Auditors and Regulators have access to loan-level data (read access for the Auditors and Regulators and write access for the SPV and servicer), while investors and rating agencies have only read access to asset pool-level data. This is for illustrative purpose and it is possible to have different privacy settings for each actor within a specific category. For instance, certain investors could get loan-level data access in exchange for a premium charge.
Near-real time updates We want to caution the reader about the notion of real-time updates. Often times, proposed blockchain solutions include the promise of delivering real-time information to market participants. This raises privacy concern and security vulnerability as real-time updates might leak transaction contents. For instance, if an investor monitors the performance of an ABS product every second, he could identify which loan in the pool was updated and reconstruct loan-level records. To preserve tuneable privacy, we introduce the concept of near-real time updates. In near-real time settings, the frequency of information release allows for multiple loan-level data points to be updated before they get published in the platform, therefore maintaining the privacy of the loan-level data. In the securitization market, loan-level data updates follow a cyclical pattern which depends on the type of underlying asset backing these securities: an auto-loan typically has monthly payments while a credit card loan has a revolving structure and could be paid back any day. In addition, investors may have different needs depending on their risk profile: central banks and traditional banks usually invest in AAA Tranches with very low default rate and are therefore usually focused on monthly updates. Hedge funds and private holders who may invest in riskier tranches and short-term investments may be interested in more frequent updates about loan performance. Near-real time should therefore be taken as a broad and flexible definition. In our use case, we take the case of auto-loan ABS, which have monthly payments. Originators offer consumers usually two payment dates (beginning or end of month), therefore near-real time frequency is defined as biweekly. As the platform scales and hosts multiple asset classes with different payment collection cycles (credit card loans, revolving loans etc.) and multiple types of investors, near-real time could be defined as daily.
Industry-wide platformIn our use-case, we focus on one underlying asset class: auto-loans. As the platform grows, zkABS’s flexible privacy settings could host multiple originators and ABS asset classes (e.g. credit card loans, receivables, etc.) on the same platform while maintaining loan-level data privacy among competing originators and issuers. Since zkABS is used as a means to store loan-level records, the data storage required is reasonable (e.g. the number of loans in an asset-backed security is typically constant until maturity). Therefore, the scalability limitations of zkLedger would not be an issue. zkABS could host all the participants of the US securitization market, and thus power a new type of decentralized digital platform with online analytics and benchmarking tools for the industry.
Smart contractsA “smart contract” refers to transactional terms and conditions embedded in computer code which allow automatic execution of the relevant transaction once precise conformity with those terms and conditions has been established (Dong et al. 2018). When used in conjunction with blockchain technology, the code itself is replicated across multiple nodes and, therefore, benefits from the security, permanence and immutability that a blockchain offers (Dong et al. 2018). A simple example of a smart contract is the automatic payment of monthly interests on a loan when the due date arises. The goal of this paper is to focus on zkLedger application to reduce asymmetry of information among participants rather than to address the potential efficiency and security gains of automating the business logic of the securitization process. zkABS architecture currently does not have a smart contract layer due to the lack of legal framework surrounding their application and the ongoing research on privacy-preserving smart contracts. However, we can imagine that a smart contract layer could be added later in order to automate and bring on-chain several steps of the securitization lifecycle, such as collecting loan payments directly from the consumer, identifying non-performing loans, pricing and rating security. As mentioned in “The inefficiencies of the securitization market” section, zkLedger is agnostic to the DLT used and could be implemented as a set of smart contracts on top of an existing DLT which already has a smart contract layer and then could easily link other smart contracts into zkABS. A smart contract layer could reduce operational errors and speed up data processing, particularly at the Servicer level.
Near-real time analytics about loan performance for investors
In this section, we focus on a particular use case for zkLedger: the potential for investors to get access to publicly verifiable near-real time analytics about asset-pool performance, without compromising individual loan data.
Near-real time analytics tools Currently, there are no available solutions on the market that enable investors to get near-real time performance dataFootnote 10. As we discussed in “Introduction” section, investors have to perform cumbersome data standardization and offline analysis to price risk and perform benchmarking for this type of securities. In addition, they do not get asset pool performance updates in a timely manner, which can result in suboptimal investment decisions and a lack of liquidity in the secondary market (Sindle et al 2017). With zkABS, financial information about each individual loan is stored and updated in near-real time on zkABS decentralized platform. This information includes loan principal, annual payments, delinquency rates, credit scores, remaining term to maturity and other information (see Fig. 4 for a sample of loan-level records for an auto-loan) and serves as a base for issuers to disclose periodic information to investors and regulators (e.g. offering prospectus, TRACE reports).
This information is highly sensitive and issuers may not have the incentive to disclose such data at individual loan-level in near-real time to investors. Further, investors may not want to see the loan-level data points and consumer information in clear form as they would become subject to data privacy regulationsFootnote 11.
Through our interviews, we confirmed that investors would be interested in getting timely updates about the performance of ABS products at the asset pool level (aggregate basis as opposed to loan-level basis) and may be willing to pay a premium for this kind of ABS offering. There is currently no solution in the market that would enable issuers to provide publicly verifiable timely information at pool level, without revealing loan-level information.
If they adopt zkABS, the issuers’ incentive to include investors in their blockchains may change. With zkABS, issuers can hide sensitive loan-level data on their blockchain and still allow investors to perform analytics on the hidden data in order to get secure aggregate balances and ratios about the performance of their ABS products.
As shown in Fig. 5, investors see a hidden view of the ledger and cannot track loan performance at loan-level, thus zkABS protects the issuers/SPV’s proprietary and sensitive data such as borrower names and individual loan performance. However, investors can still perform analytics on the hidden data at the pool level as in Fig. 6, which allows them to monitor the performance of their loans and improves their ability to price risk efficiently and independently. It allows investors to build their own queries at any point of time. For instance, an investor could query trends about loan default in Texas for one particular asset class instead of waiting for the servicer reports. All queries (sum, mean, correlation, etc) are interactive and the party that the investor is trying to query must exchange information with the investor otherwise he cannot query the table, another form of information control for issuers and servicers.
Pricing efficiency zkABS allows multiple SPVs to join the same platform, which will push for data standardization and provide investors with easy-to-compare near-real time information across issuers and related asset-backed securities. As pointed out in the Structured Finance Industry Group’s report (Sindle et al 2017), this could fundamentally improve pricing efficiency and deepen the securitization market: “security pricing could become more accurate with a potential narrowing of spreads as investors gain the ability to make near-real time assessments of security values by tracking shifting patterns in loan-level payments. The pool disclosure–the loans, with their performance and yields–in the security’s offering documentation could also be automatically and almost instantly updated to reflect the very latest portfolio performance.” (Sindle et al 2017) Compared to another permissioned blockchain with the right access rights, zkLedger provide investors the ability to perform anonymized analytics that are publicly verifiable, which provides additional security, transparency and reduces asymmetry of information in the market.