<aside> 💡 For a brief overview of the Account Aggregator (AA) Ecosystem and Framework, take a look at this blog post.
</aside>
In finance, when two companies got together to discuss sensitive topics like investments, mergers, and acquisitions, they would use a data room. The two transacting parties used to meet in the data room and bring all of their official documents. After studying the details and striking a deal, the counterparties would each leave with their own data. There would be no copying of files or leakage of proprietary information.
Can the same thing be established for the AA world? Consider two counterparties: A and B. Imagine that A has an algorithm which is able to accurately assess a person’s creditworthiness based on their bank transactions. Imagine that B wishes to get a loan but does not wish to share all of their bank transactions with anybody else.
Is it possible to engineer a virtual data room such that A brings the code, B brings the data, and the only thing that is exchanged is the output of the algorithm? Can it be made possible for A to run their code on some data without revealing their precious code, at the same time that B is able to share their data for analysis without revealing the data itself?
In the past, companies have attempted to solve this problem, but perhaps it is worth reimagining this product in the context of Account Aggregators. After all, AAs will make it easy to share data, and much of that data will be of a sensitive nature.
Knox provides a secure, cloud based code execution environment to Financial Information Users (FIU) without the need to ever access/process/store customers' financial information (FI), within their own premises. FIUs can remotely upload custom functions in JavaScript or Python, and directly execute on the FI data provided by Financial Information Providers (FIP).
We propose the addition of a new regulated entity within the AA framework, viz. the Virtual Data Room Provider (VDRP). In extension to this, we also propose new endpoint additions to the ReBIT API specifications and some miniscule enhancements to a couple of the existing AA Rest endpoints. We have also laid out additions to data and encryption flows.
We also propose guidelines around which regulatory and audit policies maybe formulated. We recommend (and have also implemented) a "No Data Persistence" policy and strict security controls around what kind of data can be returned in the output of the function execution. Knox implements and enforces a strict Boolean only JSON output format (True/False answers only), thus ensuring no data leaks. This also in some ways solves the Data Governance problem statement to some extent. Knox also ensures that the output of a function is transient in nature.
The introduction of a new entity to the ecosystem will ensure trust, security, transparency and accountability by way of regulation and audits and enforcement of data persistence policies for VDRPs. This results in considerable benefits to both the FIUs and the Customers:
Proposed Guidelines for Policy and Regulations
GitHub - Mock Account Aggregator
<aside> 💡 A huge shoutout to Saurabh Panjwani, Volunteer at iSPIRT Foundation, for mentoring us and providing valuable feedback.
</aside>