Observations from a blockchain PoC research project in Private Equity Fund Administration

Earlier this year Mainspring undertook a 3-month proof-of-concept (PoC) to get hands-on with our research of blockchain technologies.

As a Fund Administrator, Mainspring holds the books of record for a client’s fund, independent of the fund’s investment manager, undertaking the accounting and reporting of the fund’s performance.  In addition, Mainspring provides administration services for operating the fund which are largely event driven and typically follow a defined workflow process, such as: making a new investee company investment; effecting a drawdown of monies from investors; or distributing a return of funds to investors.

The purpose of the PoC was to assess the suitability of private distributed ledger technology for Mainspring to enable clients to initiate specific workflows on the administration system (on the blockchain) and extend transparency and real-time access to fund managers and their trusted third parties to Mainspring’s data.

The typical method today for running workflows and sharing access with third parties (fund managers, suppliers) is via a central database operated and maintained by one party (Sql, Oracle, SAP…) with permission-based access for third parties to interact and view with the workflow processes.  The PoC was intended to compare this method with distributed ledger technologies to get hands-on practical exposure and move beyond assessing the technology based on reading datasheets and high-level discussions at networking events.

The PoC was developed on Ethereum using the Solidity programming language and hosted in Microsoft Azure.  We chose Ethereum for two reasons, firstly we were drawn to Ethereum because we believed it had the largest non-cryptocurrency implementation of blockchain technologies and secondly because Ethereum’s Smart Contracts appear ideally suited to creating and running a workflow process.  We chose the Solidity programming language as we believed it to be the largest Ethereum developer community and we chose Microsoft Azure as it offered a specific Ethereum Proof-of-Concept hosted environment for ease of getting started.

The PoC focused on a single workflow process, related to the set-up of a new investor through the creation, input, review and approval of a new investor application form.  The application form had predefined input fields and field validations and stages for review and approval with related work queues, and the PoC had multiple application forms.

Learning from the PoC

  1. The Ethereum Solidity developer toolset was/is immature, requiring ‘hacks’ and workarounds to what would be common developer approaches in Java or other mature programming languages. It reminded the research team of developing business critical VoIP applications in the period 2001/5 when the applications were reliant on Microsoft Windows NT4.  In that case the operating system and soundcards that had been bundled with PC’s were not ‘ready’ for VoIP.
  2. In of itself, the Microsoft Ethereum blockchain was costly for holding data records. We determined that we would need to do a specialist analysis of data costs per workflow use-case, with each digit/character under review similar to the UX designer considering each ‘click’ and thereby determining the total data expected and worst case per completed workflow instance.
  3. How to handle the requirements of GDPR and in particular the investor’s right to “be forgotten.” Once data is on the blockchain it is immutable so cannot be erased, and is likely therefore that such data will need to be held outside or hashed on the distributed ledger.
  4. Design decisions are required for how to incorporate AML/KYC regulatory requirements for investor onboarding and ongoing monitoring. In its simplest form hold summary status on the blockchain (Pass/Review/Review), need to determine whether to extend further for workflow collaboration with the Client for query management, document retention, reference agency results.

Other learning

We considered including holding personal data ‘off blockchain’ with a unique reference that is shared with clients which would also help reduce costs of operating the blockchain.  This however results in a split of the data for the workflow with a portal held in a traditional database and is self-defeating.  Perhaps this is a necessary compromise for cost and GDPR and provides enough value to move the rest of the workflow ‘on blockchain’.

The operation of a workflow with clients on a genuinely shared single source of the truth is catchy, however it’s not compelling.  As fund administrator our service and responsibility is to hold and maintain the books of record for a private equity fund and fund manager but we do so already via an internal single source of the truth, being FIS’s Investran system.  Introducing a common workflow cannot dilute, nor have any perception of diluting, that responsibility.

Perhaps locking down the Fund Administrator’s workflows to ensure clarity of responsibility but enabling fund managers to independently innovate the workflow or create their own workflows off the data would drive sufficient value, for example by reducing the demands for shadow bookkeeping or enhancing collaboration/access to data for internal compliance teams.

Extending nodes beyond the Fund Administrator <-> Fund Manager relationship might be interesting to drive value for Mainspring, our fund manager clients and respective stakeholders.  Giving access to data to third parties, for example extending a node to the FCA Regulator to see assets under custody would provide a real-time view instead of via completing quarterly returns.  For fund managers perhaps extending data at their control, to their auditors or investors.

In private equity the infrequency of other interested parties access requirements however doesn’t feel like enough and it’s unrealistic to the think we can develop a common platform for all PE reporting.