In October 2017, Elixirr Partner Dieter Halfar led a research project to investigate the potential of using blockchain technology to challenge the current liability management industry in South Africa. Dieter worked with a dedicated team from Curo Fund Services (Curo) to explore, first-hand, whether distributed ledger technology (DLT) could be used to replace the need for a Transfer Agency (TA) and associated industry infrastructure, complexity and cost within the Collective Investment Scheme (CIS) fund market.
Inspired by Curo’s own market research into distributed ledger technology, combined with insights gathered from several market-leading TA technology providers and current fund administration clients, Curo commissioned the development of a TA Proof-of-Concept (POC) built on a private permissioned Ethereum network. The POC design objective was simple:
Demonstrate the feasibility of tokenisation and trading of unit trusts on a blockchain.
The tokenised representation of units in issue had to be transferable to interested parties for purchase and redemption in fiat currency, with unit ownership verifiable on the blockchain.
Dieter and the team from Curo selected ConsenSys, the New York headquartered, global enterprise development and Ethereum blockchain consulting firm as the development partner of choice. Dieter led a project team consisting of Curo and ConsenSys developers over a period of four weeks to design, build and test a limited functionality POC aimed at demonstrating the feasibility and potential benefits of a decentralised TA blockchain solution. The POC was quickly and successfully completed by mid November 2017.
The initial POC solution enabled an investor to view their portfolio information, select a fund, make a one- off investment, perform a phase-in purchase and redeem units through a one-off withdrawal or recurring withdrawal plan. Investment management companies were empowered to view fund events and investor transaction details, display and search a portfolio investor unit registry, update fund details and track current fund valuations, cashflow forecasts and fund balances in real-time.
The POC was deployed on a globally distributed, multi-node, cloud-based architecture utilising the Quorum Ethereum client due to its suitability as a private, permissioned network of choice in financial services and related industry applications.
This whitepaper serves as an interim deliverable highlighting the key insights and learnings that the project team collectively generated. It is the intention of this paper to generate constructive discussions within the South African investment fund industry, the broader South African blockchain community and beyond. This is in the interest of advancing our collective understanding and acceptance of blockchain as a simpler, more efficient and cost-effective future alternative to the fund distribution infrastructure and business model of today.
We would like to invite readers to engage us in conversation and to actively participate in the development of future phases of this initiative. Thank you for reading, we do hope that you find this paper informative and useful.
This whitepaper serves as an interim deliverable highlighting the design principles, key insights and learnings that the project team (consisting of Curo Fund Services, development partner ConsenSys, and Elixirr Partner Dieter Halfar) collectively generated from a research project aimed at exploring the potential of using blockchain technology to challenge the current liability management industry within the CIS fund market in South Africa.
Using Curo’s own research findings alongside insights gathered from client interviews and several market- leading transfer agency solution providers, Dieter led a project for the design, development and evaluation of a TA proof of concept (POC) built on a private permissioned Ethereum network. The POC would be focused on demonstrating the feasibility of tokenising and trading unit trusts on a blockchain. The tokenised representation of units in issue had to be transferable to interested parties for purchase and redemption in fiat currency, with unit ownership verifiable on the blockchain.
The purpose of this whitepaper may be summarised as follows:
- To provide a brief overview of the current transfer agency ecosystem, specifically explaining the role of key participants and describing the critical ecosystem interactions, current TA challenges and potential opportunities that an alternative blockchain solution may offer.
- To present an overview of the Blockchain POC application design components and key features developed.
- To describe the logical solution architecture and discuss the components of the technical deployment as built.
- To discuss key findings, risks and challenges identified, immediate next steps and critical activities on the future execution roadmap.
It is the intention of Elixirr, Curo and ConsenSys, through the development and demonstration of real-world, practical application and the open distribution of insights and learnings, to advance the collective industry understanding and acceptance of blockchain as a simpler, more efficient and cost-effective future alternative to the fund distribution infrastructure and business model of today.
Transfer agency & the ecosystem today.
The asset management industry is generally accepted as a complex, integrated ecosystem of independent participants, including asset managers, fund and liability administrators, intermediaries and distributors, custodian banks, paying agents and industry authorities. Participants are required to interface and collaborate daily, ensuring the execution of a carefully sequenced and often resource intensive set, of process activities.
To maintain industry competitiveness and legislative compliance, responsible participants have been forced to keep pace with industry evolution, accepting that unfortunately, change is the only real constant.
For most incumbents, this reality has translated into a historic accumulation of incremental changes and layering of product, service and process developments over time, resulting in a legacy of complex, inefficient technology platforms and business operating models.
Traditionally, asset managers and investment management companies responded to the increase in complexity and cost by electing to outsource operational components such as asset and liability administration to specialist intermediaries such as fund administrators and transfer agencies.
Despite the cost efficiencies delivered through outsourcing, given the relentless and accelerating pace of regulatory change, proliferation of alternative products and shifting investor expectations, industry participants have recently started to question the sustainability and relevance of their current practices, technology platforms and operating models.
As a prime example, Fundchain, a Luxembourg based industry consortium, concluded a distributed ledger “SMART-TA” experiment at the end of 2016 and purported to having demonstrated the potential of using blockchain technology to significantly simplify the current fund distribution model, whilst also citing the potential blueprint for an innovative, more efficient and smarter transfer agency of the future
THE TRANSFER AGENCY ECOSYSTEM, CURRENT CHALLENGES & OPPORTUNITIES
Today, a transfer agency fulfils the role of a specialist intermediary and deals with the complexity of ensuring the collaboration of numerous industry participants, as well as the coordination and timely execution of high-risk, often manual operational processes.
A TA brings together two investment administration eco-systems: the first being the fund managers and fund administrators, the second being the investors, distributors and intermediaries. In addition, transfer agents are required to interact with service providers and participants such as industry regulators, banks, tax authorities, paying agents and messaging gateways.
To deal with all this complexity and risk, transfer agencies have had to develop a wide array of competencies and a rich catalogue of services. These include, but are not limited to, new fund/ client onboarding and management, identification, verification and registration of investor and distributor entities, automated bulk and individual manual transaction processing, including cash and unit settlement and reconciliation.
In addition, transfer agents also typically support critical services such as investor servicing, correspondence, fee calculation and processing, tax liability management and operational fund and regulatory reporting.
Coupled with the accelerating pace of industry changes and ever-increasing client expectations, it seems obvious as to why the precarious role of a transfer agency is often cited as challenging and in desperate need of renovation.
Reinventing the current TA model requires an understanding of the key functions, interactions, fund distribution participants and challenges present in the transfer agency ecosystem today. A high-level overview of the current key TA functions, challenges and potential solutions, as they relate to the use of distributed ledger technology, is therefore, presented below.
NEW FUND MANAGEMENT
The new fund management process defines the asset manager’s mandate as well as the process parameters associated with the registration, marketing and distribution of the fund, detailing the rules of engagement for all stakeholders involved.
For example, the fund mandate describes investor eligibility, minimum and maximum investor contributions, asset allocation limits, fund fee class structures and product or wrapper characteristics. In addition, the new fund management process is responsible for the dissemination of fund data to industry participants, executing the distribution of mandatory reports both internally to the fund management company itself as well as to external participants.
The key participants and processes are:
The fund manager, who proposes the nature and composition of the fund; as well as the intended strategy and target market. The fund manager consolidates the fund information in an agreed format, for each industry stakeholder, and disseminates the static data through an agreed interface and form, such as email, fax, paper hardcopy and secure file transfer (e.g. XML or equivalent ISO20022 compliant format). Recipients may include transfer agents, regulatory bodies, fund data publishers, third party fund administrators and investment platform providers.
The regulators, who set the rules within which the fund can operate and ensure that participants operate within their legislative constraints and provide the necessary approvals during the fund set- up and launch processes.
While the logic behind the process is straightforward, the inherent risks and costs are largely driven by the reliance on human intervention, errors introduced due to manual processing and the consequent lack of consensus on fund static data as required by all industry participants.
Typically, fund data is repeatedly copied by the fund manager through a tedious re-mapping of data into participant specific formats, and then distributed for each recipient to independently receive and use.
Disparity of fund information poses a real risk to the industry, with tangible impact to those responsible for transaction processing i.e. rework, claims and penalties, and investor reimbursements, with other participants suffering damage to both reputation and trust.
Initial research and findings from client insights support the idea that the new fund management process could greatly benefit from the automated, real-time, secure distribution and synchronisation of standardised fund static data between each participant, where data distributed is immutable, verified and committed as a single source of the truth through guaranteed consensus between all stakeholders and where all permissioned participants are able to locally access and reference an identical data set from a single distributed ledger.
Entity registration refers to the onboarding process of identifying, verifying and screening individual and institutional investors, distributors and intermediaries and the entity account creation within the transfer agency system.
The process is typically designed to ensure compliance with regulations related to the observance of good practice in client and service provider conduct, financial intelligence and reporting (e.g. AML, KYC, FATCA etc.) The key participants and processes are:
The entity, including individuals, institutions, intermediaries and distributors wishing to establish a relationship with a fund manager either directly or, on behalf of, an investor through the submission of an application form and supporting entity verification and identification documents.
The fund manager, who is accountable to ensure the execution of compliance checks to identify, verify, screen and risk-rate the entity prior to onboarding. Often this function would be performed by the transfer agent under an outsource agreement.
The transfer agent whom, depending on the scope of the outsource agreement with the fund manager, is responsible for the execution of the compliance checks and the creation and approval of an entity account within the core transfer agency system.
Industry data brokers or utilities supporting the compliance process through the provision of personal information verification and compliance screening data services to the transfer agency or fund manager.
Despite advances made in the use of input management technology, the entity registration process remains costly and labour intensive. This is due to the inevitable human effort required to manually match and verify submission documents.
Importantly, the KYC/AML process often requires entities to repeatedly resubmit documentation, since very few fund managers can recognise entity dealings between federated product lines or disparate business units, nor effectively leverage indexed and stored content across the organisation, or those stored with a transfer agent, to avoid the need for repeating the compliance process.
Transfer agencies are often challenged by the complexity of managing an entity registration process out of context to investor service portals and channels developed by fund managers, due to a lack of seamless and real-time data and process integration leading to low levels of service transparency, inconsistent user channel experience and potential for data disparities arising due to errors in synchronising fund manager and transfer agency entity records.
Failure to perform adequate entity verification and compliance screening is simply not an option, since control failure can result in significant financial penalties, sanctions, fraud and operational losses.
It is therefore not difficult to foresee the potential benefits of creating a single, common legal entity ledger, where a primary entity record is stored, verified, maintained and automatically distributed for local use to any permissioned system participant, regardless of the entity’s origination channel, product line, business unit, distribution platform or intermediary relationship.
This however, risks breaching legislation like the Protection of Personal Information Act (POPI Act) or similar acts in other jurisdictions (e.g. General Data Protection Regulation – GDPR). Even if personal information was kept off chain, a single identifier on chain could be used to glean transaction data linked to an individual or company.
The proposed solution therefore is to use multiple account numbers (addresses) on chain, linked to a single identity. These can be generated deterministically through a seed and are called Hierarchical Deterministic (HD) wallets in the blockchain world.
In addition to the above, all amounts transferred can be shielded on chain using various techniques.
The combination of shielded amounts and HD wallets provides full confidentiality, whilst also maintaining a single identity on the blockchain.
Practically, the broker or agent onboarding an investor would run through a full KYC process with the investor. The KYC data would be maintained by the broker or agent.
When an investor invests into a fund, the broker or agent would send the KYC data as well as the data required to identify the investors transaction on the blockchain to the Fund Management Company via a private encrypted transaction.
All KYC data would be maintained by the broker/ agent (e.g. update of residential address etc.) and updates communicated to all management companies where the investor has holdings via private encrypted transactions.
Transaction processing follows fund setup and entity registration. The level of automation in investor dealing depends greatly on the source format of the investment instruction.
Instructions received in an electronic format, such as an XML file structured to meet the ISO20022 standard, typically enables a transfer agent to load and process investor instructions automatically, whilst email correspondence and image attachments require a more labour-intensive process of receipt, indexing and manual capturing of instructions.
Manual capturing is mostly associated with those direct individual retail investors and brokers still relying on paper-based application and instruction management. Due to the value and volume of processing, institutional investors and intermediaries typically prefer the use of secure file transfer or message integration mechanisms.
Transaction processing requirements vary, but typically include the processing of subscriptions, additions, redemptions or withdrawals, switches, transfers, estate late, cessions, static data updates, income distributions, fee, rebate and accrual payments.
The key participants and processes are:
The transfer agent, responsible for the receipt, indexing, capturing, validation, execution, monitoring and reconciliation of a transaction instruction. The transfer agent is also responsible for the creation and liquidation of units triggered by the various transaction types to fulfil client instructions.
To determine the number of units involved in the transaction, the transfer agent also receives, verifies and applies NAV pricing provided by fund accounting. In addition, the transfer agent is typically responsible for cash settlements and collections, performing these functions directly or in partnership with a third party paying agent. The transfer agent also performs the process of forecasting to assist the fund manager with cash position and liquidity management, specifically supporting the fund cash and asset allocation process.
The custodian, who approves/instructs deposits and withdrawals on a fund’s call account to manage cash balances as per the information provided by the transfer or paying agent.
The portfolio manager, who trades based on the actual cash position or forecasts provided by the transfer agent, appropriately maintaining asset class proportions and minimums/maximums as per the approved fund mandate.
The fund accountant, who strikes a NAV periodically as stipulated by the fund manager’s requirements.
The NAV is provided to the fund manager and transfer agent, who validate the NAV and subsequently disseminates it to the market directly or via third party distributors (e.g. pricing houses). The fund accountant also calculates income distributions on a periodic basis as per the mandated distribution schedule of the fund. These distributions are also sent to the fund manager and transfer agent. Once received, the transfer agent performs validation checks and applies the declared income to the unit holders.
Regulators, who govern the rules related to transaction processing, including the definition of standards and control requirements related to suspicious transaction monitoring, investor screening, and reporting.
Transaction processing is a high-risk undertaking. Risks and issues are primarily due to the inherent complexity of managing the timely interaction between multiple participants within the fund distribution ecosystem.
Errors, ranging from incorrect NAV or income distribution application as received from fund accounting, processing of ineligible transactions and incorrect changes to ownership records due to disparities in fund or entity static data, errors calculating and reporting investor and fund liabilities, over/under fund cash forecasting, unreconciled inward or outward payments and control failures in verifying and executing payment collection data, can all result in significant and irrecoverable losses with both financial penalty and reputational implications.
A transfer agent’s transaction processing operations department is typically expensive to run and maintain due to the reliance on skilled staff, requirement for continuous training and education in compliance and industry matters and a need to manage staff turnover. This is typically higher than other industries due to the risks, repetitive nature and limited scope of duties available.
Given the scale and scope of regulations and processes that govern and manage the current fund distribution model, unravelling and re-engineering the transfer agent’s ecosystem may seem like a daunting prospect. However, the sequence of detailed transaction activities and rules governing participant interactions and process controls are all grounded in logic.
Smart contracts may be programmed to execute process logic in real-time, written to substitute the tasks currently performed by a transfer agent. These tasks include the creation and maintenance of the fund unit ownership registry, maintaining investor and fund cash balances, in the form of digital wallets, the automation of investor compliance screening, the verification and application of unit pricing and the execution, matching and settlement of investor and fund cash/unit allocations.
The combination of a distributed ledger and Ethereum smart contracts have the potential to disrupt the role of a transfer agent, automating all transaction processing activities and decentralising the oversight and control of the fund distribution model to the remaining participants, specifically, principal actors such as fund managers, distributors and supervisory entities.
This represents a significant simplification of the ecosystem, reducing cost and promising significant improvements in investor experience.
Reporting encompasses the distribution of investor statements, notifications and contracts, daily fund unit and cash flow accounts, the calculation and reporting of intermediary/distributor fees and dissemination of fund and investor transaction activity and holdings data to fund managers and supervisory entities such as regulators, tax authorities and industry bodies.
The key participants and processes related to Reporting are:
Transfer agents, who offer investors, distributors/ intermediaries and fund managers a range of reports and distribution channels. Transfer agents are typically contracted by fund managers to perform the extraction, formatting and dissemination of bulk data files to a third party correspondence agent for physical statement distribution directly to investors and/or support the use of digital channels such as e-statement correspondence engines, online investor portals, XML, SWIFT or ISO 20022 compliant message integration services and APIs.
Fund managers, who are held accountable by industry participants for the effective and accurate distribution of investor and fund related data. Depending on the services contracted with a transfer agent, a fund manager may choose to execute selected reporting duties themselves, although, in this case, fund managers may be reliant on the effective extraction, assurance and formatting of source data directly from the transfer agent.
Supervisory entities, auditors and industry authorities requiring the submission of mandatory reports in support of ensuring the effective governance and monitoring of industry compliance to legislated rules of conduct and performance standards.
Transfer agents and fund managers are required to produce and disseminate a large variety of reports in service of many different industry participants.
Despite the adoption of digital distribution channels, investor self-service portals and data integration services, the manual effort to extract, transform, assure and format core TA system data remains high.
In all cases, the centralised management of data, by the transfer agent, creates dependency in the reporting process, placing a heavy reliance of the efficiency and availability of the transfer agent in extracting and formatting a large variety of industry reports. The requirement for dynamic and individualised reports, increased levels of data access and real-time availability has placed an enormous burden on transfer agents. The persistence of data on the blockchain could liberate the fund distribution industry from its dependency on a transfer agent and associated constraints.
The execution of distributed consensus algorithms and local verification of every smart contract executed by every node on the network, ensures the continuous integrity and validity of every transaction committed, without the need for centralised monitoring and QA.
Every network participant (e.g. investor, intermediary/ distributor, fund administrator, fund manager, regulatory and tax authority, paying agent and custodian or trustee bank) could, if authorised through policy, independently view and verify all data, resulting in more efficient oversight of the entire ecosystem, whilst offering the opportunity to streamline or eliminate many of the operational reporting processes performed by fund managers or other participants today.
Design approach & features developed.
The project team, led by Dieter, set out to design, build and test a POC aimed at demonstrating the feasibility and potential benefits of a decentralised TA blockchain application. To achieve this objective within the four week project time, the project team agreed to focus the initial development on the delivery of four essential transfer agency capabilities.
This included proving that an Ethereum blockchain application could:
Persist and disseminate fund static data between all participants in the ecosystem,
Create and maintain a unique investor digital ID linked to all related investor transactions,
Automate selected transaction processes using smart contracts and,
Report investor and fund specific information using a combination of data stored directly on and off the blockchain.
To adequately demonstrate the basic end-to-end functionality of a TA, a decision was made to develop a front-end investor application, representative of a typical distribution platform interface for use by an individual investor, agent, or intermediary/distributor, with a second application serving as the user interface for a fund manager.
Both these applications would be able to interact with the underlying, distributed Ethereum smart contracts and operating environment through the Ethereum application programmable interfaces (API’s).
THE INVESTOR APPLICATION
The investor application acts as a simple transaction origination, investor servicing, reporting and account maintenance application, offering the investor the ability to initiate and report transaction activity and view selected portfolio information. This was achieved through the development of a browser-based web interface, offering the basic capabilities of a typical unit trust trading and investor services platform. The investor user interface was designed to present the investor with the following four application components:
The Portfolio Overview menu presents the investor with selected portfolio data. This view allows the investor to monitor overall portfolio performance and view total contributions and withdrawals since the start of the portfolio. Additionally, the investor can view total portfolio income distribution and fees payable to date.
Specific field names include:
- Portfolio Start Date
- Current Portfolio Valuation
- Annualised Portfolio Growth
- Available Cash
- Contributions made to date
- Income Distributed
- Withdrawals made to date
- Fees incurred to date
Figure 1: Investor Portfolio Overview
In addition, the investor is able to view current portfolio holdings. Holdings data is presented in tabular format, displaying the individual fund manager and fund descriptions, total value per fund and the number and value of individual units held.
All the Portfolio Overview data elements persist directly on the blockchain, maintained within dedicated investor contract accounts, setup to manage the storage and maintenance of portfolio data.
Figure 2: Investor Portfolio Holdings
The Transact menu presents the investor with the investment and withdrawal transaction forms.
The investor can select the desired fund manager and fund from a dropdown menu and enter a contribution or withdrawal amount. The application estimates the number of units affected, based on the last unit NAV on record – these estimations are for information only, since the final and confirmed number of units affected, will only be known post the cents per unit or net asset value (NAV) per unit application.
Figure 3: Investor Transaction Form
A phase-in investment and withdrawal transaction is also supported.
For the purposes of the POC, the project team simplified the phase-in construct to a simple linear value distribution over time. A phase-in transaction is initiated, using a smart contract, to distribute the total
transaction amount, in equal portions, over a defined number of weeks.
Transactions submitted prior to NAV injection and pricing application are recorded by the system as pending transactions.
NAV injection and the application of pricing to pending transactions occur at end-of-day. Once the pricing is complete, all pending transactions are
updated with the actual number of units affected and recorded as confirmed.
Investment instructions are settled net of initial investment fees.
For the purposes of the POC, a smart contract was set to allocate a fixed percentage fee of 3% as an initial investment fee. In addition, an annual service fee of 1% is calculated and applied daily.
CASH SETTLEMENT & BALANCES
In the interest of significantly reducing settlement and liquidity risk, the project team conceptualised the use of tokenised fiat currency on the blockchain. This would be achieved using digital wallets. Both the investor and fund manager were issued with a primary virtual cash account. Additional cash accounts were maintained at investor level for the purposes of reflecting income distribution payments, initial investment and daily service fee deductions and balances.
Cash settlement occurs only once NAV application is complete. A smart contract controls the instant reconciliation and settlement of units and cash. In addition, daily investor and fund cash allocation is performed, net of total investments and withdrawals and virtual cash balances updated.
In all cases, individual investor transactions are always recorded on the blockchain and reported as such. For the purposes of testing and demonstrating the functionality of the POC, the system clock speed was increased, completing a 24hr cycle every 30 seconds.
Figure 4: Investment Management Company Transaction History Log
The Transaction History menu presents the investor with a tabular report showing all historic investment and withdrawal transactions. Pending transactions are labelled as such through the transaction type identifier field. A unique blockchain transaction ID is created and displayed for each transaction committed to the network.
Fields include the Transaction Type, Date, Manco name, Fund Name, Number of Units, Unit Price and Total Value.
Like Portfolio and Holdings data elements, investor transaction data persist directly on the blockchain.
However, for the purposes of reporting transactions during the POC, data is queried from every block committed and stored in an external reporting database.
Note that the blockchain retains all historical transaction data, and the decision to write data into an external reporting database was made in consideration of potential performance impacts on the client node as transaction volume increases over time.
The Personal Information menu presents the investor with the ability to update personal contact details.
For simplicity, the investor is limited to updating name, email and mobile number fields.
Each investor is represented on the blockchain through a unique blockchain ID. This ID is used as the primary key in a linked investor database, maintained outside the blockchain for purposes of data privacy.
Transactions on the blockchain are easily identified using the same investor ID. In addition, the Personal Information view offers a basic overview of the investor KYC status.
Considering the focus of the POC, a design decision was made to exclude KYC/AML and related investor compliance management functionality from the initial POC.
Rather, the POC would work on the principle of placing investor identification, verification and risk rating responsibilities directly with the investor, distributor or intermediary themselves prior to registering on the blockchain POC.
The investor application was therefore developed with the assumption that registered investors are pre-screened prior to onboarding. The decision to decouple initial investor onboarding activities from the POC has some distinct advantages for most large retail and institutional investor platforms, enabling these network participants to deploy their own, bespoke, digital onboarding and investor servicing front-end applications. This is typical of asset management houses and distributors who wish to directly manage a unified investor service experience across product portfolios and services.
In these instances, integration to the blockchain network would be achieved using web services.
To ensure ongoing compliance, the POC investor application was developed to monitor specific changes in investor profile data, specifically applying basic rules to confirm the maintenance of a valid KYC/AML and risk status. Non-compliant investors would not be allowed to transact on the blockchain.
Figure 5: Investor Personal Information Overview
THE FUND MANAGER APPLICATION
The POC required the ability for a fund manager to monitor investor transaction activity, manage fund data, view fund unit registry details, view fund cash balances, and report fund performance. The fund manager user interface was designed to present the fund manager with the following five application components:
The Fund Data menu presents the fund manager with a fund data form.
The form is used to capture several descriptive fund data fields, such as: the fund name, type, objective, asset manager, benchmark etc.
Each fund descriptive dataset is committed to the blockchain network and stored with a unique blockchain address ID. This allows network participants to query fund data directly from the distributed ledger and ensures that all network participants have consensus regarding the validity of the data, avoiding data disparities.
In addition, this eliminates the need for participants to rely on external messaging rails, interconnecting participants through the synchronised distributed ledger.
Updates to fund data applied, by the fund manager, are automatically disseminated through the network in real-time.
Figure 6: Investment Management Company Fund Data Sheet
The Unit Registry menu presents the fund manager with a tabular report depicting the beneficial ownership information for each fund. Individual investor unit balances are reported at fund level, including investor name, surname and fund name.
The Transaction History menu presents the fund manager with a tabular report showing all historic investment and withdrawal transactions, as well as critical fund events, such as NAV injection and application.
Pending investment and withdrawal transactions are initially identified as pending instructions through a description identifier.
Once NAV injection and application has been processed, an instruction is settled and indicated as such. The unique blockchain transaction ID is displayed for each transaction as committed to the network.
Fund manager transaction history data is queried directly from the blockchain and written to an external reporting database, supporting analytics and avoiding potential performance impacts on the client node.
The Fund Cash menu presents the fund manager with the ability to view the cash call account balance and cash flow forecast for the next reporting period for each fund. A minimum cash balance is also indicated.
Pending transactions due within a 7-day period are automatically reported.
Figure 7: Investment Management Company Fund Data Sheet
The Fund Performance menu presents the fund manager with a graphical representation of fund NAV over time. NAV history data persist directly on the blockchain. However, in line with the applied reporting approach, data is written to an external reporting database.
This research project was conceptualised with the intent to explore the potential of using blockchain technology to challenge the current liability management industry within the CIS fund market in South Africa. The project team posed the question as to whether it would be possible to reduce or eliminate the need for a traditional transfer agency (TA), related industry infrastructure and associated complexities and cost, using a private, permissioned Ethereum network.
RESULTS & INSIGHTS
The findings of this research project were based on the direct learnings gathered during the design, development and testing of the TA POC.
In addition, numerous interviews and debriefing discussions yielded additional insights, yet also additional questions that require resolution prior to offering a definitive answer to the exam questions posed.
The project team however, believes that the POC solution developed, sufficiently illustrated the potential of blockchain technology to replace many of the core functions and controls currently provided for by traditional transfer agency service providers.
Of interest was the versatility of Ethereum smart contracts, providing the flexibility to script complex business logic into the blockchain operating environment, including many of the transaction processing rules and controls required to effectively manage industry requirements.
In addition, the relative ease with which the Ethereum network was quickly deployed, developed, tested and integrated into a typical web-based front-end, is testimony to the maturity of Ethereum as a practical, real-world application development environment.
It is clear from this experience, that Ethereum adoption
is not only supported by a growing public application marketplace, but also by
a vibrant enterprise-focussed development and consulting community.
The POC also assisted the project team to gather several blockchain design and implementation insights and critically, assist the team in understanding the potential for future benefits to be realised.
What follows is a summary of key insights as related to the key POC capabilities developed and tested.
The blockchain network extended between all permissioned participants within the blockchain ecosystem, connecting and synchronising ledger entries across the network.
The POC achieved seamless data exchange between client nodes, facilitating the distribution of fund static data, pricing information and events logs, as well as performing the synchronisation of historic and real-time individual investor, intermediary and distributor transaction instructions without the need for traditional industry messaging gateways.
The native Quorum message transport and transaction manager ensured fast, seamless and secure information exchange. The TA ecosystem of the future, may not require the services of traditional, proprietary industry gateways and routers to interconnect participants.
In addition, this POC demonstrated the ability to significantly increase the levels of end-to-end process integration and automation through the combination of modern design and development approaches in combination with Ethereum blockchain technology, resulting in far higher levels of integration between the front, middle and back office, yielding significant improvements in straight- through-processing.
The POC demonstrated the potential to significantly improve the investor, intermediary/distributor and fund manager experience.
Due to the distributed, real-time processing capability of a private, permissioned blockchain network, every new instruction or state change transaction received by any of the participants, is immediately and automatically broadcast across the network using the Ethereum peer-to- peer messaging channel and made available for processing.
Once a block is validated and committed to the blockchain, all the associated block transactions are considered immutable by all participants. This avoids batching of records and the need for any post-trade reconciliation activities, since ledger entries are synchronised between parties in real time.
In addition, the POC has illustrated the ability for transaction instructions to be acknowledged in real-time by all network participants, leading to the immediate calculation and reporting of cashflow forecasts to the fund manager, whilst also updating relevant investor transaction logs, indicating pending transactions.
Once unit NAV prices are applied, the investor transaction is instantly confirmed, units transferred, new ownership verified, and unit balances updated across the entire network.
The transaction is validated on the blockchain by all participants, including the fund manager, who is now able to commence the process of cash netting and allocation earlier, with more certainty.
Investor service quality is significantly improved due to the shortened transaction turnaround-time, elimination of information disparity between parties that historically led to processing errors, and the reduction or complete elimination of rework.
Time taken to resolve processing exceptions, if present, significantly reduces due to all affected parties on the network having visibility of the exception in real-time and having the ability to commit edits or new inputs and perform verification of the corrected entries.
Real-time update and notification of beneficiary ownership changes between all interested parties is now possible. This means that intermediaries, distributors and fund managers can oversee the instant creation, issuance and liquidation of units for investment and withdrawal, since units are allocated or withdrawn to/from the respective client ID on the blockchain in real-time.
This POC clearly demonstrated the capability to create and store a unique investor ID on the blockchain and the ability to link all subsequent investor activities e.g. transactions, status verifications, static data updates and events to the relevant investor blockchain ID.
This formed an immutable investor record of account and illustrated how the blockchain natively supports the ability to reconstruct a complete audit trail of all state transitions, ensuring that data lineage and integrity can be proven.
In addition, the POC demonstrated how the blockchain can support direct data discovery and extraction without the need to first perform historic data loads into an external database.
The verification of every smart contract executed by every node on the network ensured the continuous integrity of investor transactions and the validity of every transaction committed, without the need for centralised monitoring and QA.
Every network participant (e.g. investor, intermediary/ distributor, fund administrator, fund manager, regulatory and tax authority, paying agent and custodian or trustee bank) could in future, if authorised through policy, independently view and verify every investor transaction resulting in more efficient oversight of the entire eco-system, whilst offering the opportunity to streamline or eliminate many of the operational processes performed by network participants today.
For example, when a fund manager requests or completes static data changes to currently traded funds (e.g. create a new fund, update a fund description details, amend minimum investment values, set an investment cap, change fee class structures etc.) all permissioned network participants are able to simultaneously receive, verify and store the data, reducing data handling efforts and potential for errors, therefore avoiding many of the data disparities between industry participants that occur today.
Such a change can remove complexity and cost from the industry, since the effective dissemination and reconciliation of fund data and related information between current network participants is considered a significant pain point today.
Today, intermediaries and distributors do not share individual investor records with any other network participant. Instead, intermediaries typically perform all liability sub-accounting activities internally, aggregating investor transactions to the network as a single transaction with the intermediary recorded as the beneficial owner.
In return, the intermediary is required to manage all aspects of individual investor unit allocation, ownership registry, investor maintenance and service activities. In a blockchain network this could change.
The POC demonstrated how on the blockchain, all individual investor transactions are directly executed with unit/cash balances updated and stored on the distributed ledger. All permissioned participants have the ability to query the unique investor ID associated with any of the related investor’s transactions.
In addition, each participant has the ability to reference or map this unique investor ID back to additional, private investor data held in an external database, owned and managed by each participant.
This feature of the blockchain could significantly streamline the role of intermediaries. Intermediaries may in future choose to execute all investor sub-accounting transactions directly on the blockchain, whilst additional private entity information is stored in an internal CRM system or database.
This effectively outsources sub-accounting to the blockchain with the potential impact of reducing operational back office complexity related to the internal management of investor unit subscription, redemption and ownership registry activities.
In this model, intermediaries could still benefit from performing intra or end-of-day transaction netting between pooled investors on the blockchain. As well as control bulked investor transaction execution queuing and release, through invoking the need for multiple transaction signatories on each.
This POC allowed the project team to explore the potential of instant asset delivery versus payment.
With the tokenisation of both units and a virtualised settlement currency, every investor transaction has the unit subscription/redemption transaction and cash settlement fully synchronised in real-time.
In the interest of limiting the scope of the project, the POC pre-funded a digital currency wallet manually, simulating the tokenisation of fiat currency.
In future iterations, the solution would be designed to make use of an external investor trading account, typically held by a paying agent or bank, and the tokenisation of fiat currency onto the blockchain.
Both the paying agent/bank and the fund manager’s custody/trustee will settle in tokenised currency.
In this event, the blockchain would, once NAV unit pricing and investor cash balances are confirmed, be able to execute real-time settlement and reconciliation of both cash and unit balances between the investor, paying agent/ bank and fund manager on a single distributed ledger, providing instant and validated transfer of ownership and payment.
This may have far reaching consequences in eliminating any remaining form of industry settlement risk, reducing overall liquidity requirements and significantly improving participant experience. Although investor forward-pricing policies currently avoid exposure associated with daily NAV movements, some fund managers currently still allow trade execution based on forecasted investor cash flows.
In the event where settlement does not occur, funds may potentially trade into an overdrawn position, requiring corrective action by the fund manager.
CHALLENGES & RISKS
During the research, development and testing of the POC, several challenges and issues were discussed as being central to the successful development and near-term launch of a decentralised, TA blockchain application.
What follows is a summary of the three initial, yet important challenges and risks identified:
GPL LICENSES & THE RISKS TO IP
This POC was built on a private permissioned Ethereum network using Quorum, a modified variant of the standard Go Ethereum (Geth) client.
Quorum was specifically developed by JP Morgan to provide the financial services industry a permissioned implementation of Ethereum, supporting transaction and contract privacy. Quorum, like public Ethereum, has been open- sourced under a GPL/LGPL license.
Although the GPL (General Purpose Licence) ensures that the platform is free to use in perpetuity, encouraging industry experimentation, the GPL licence also presents challenges to long-term enterprise development and adoption. Under the GPL licence agreement, all development done, or changes made under a GPL license must also be licensed under GPL.
This raises several legitimate concerns, especially if you are an organisation wanting to protect the privacy of your work and benefit from the commercialisation of it.
Under GPL, in the event a developer changes or enhances a GPL-licensed application and subsequently shows the code to any other entity outside of the firm, the GPL will automatically grant all rights to the code to the public. The presence of GPL source code within derived work also prohibits a developer from collecting a fee for the application, potentially placing any commercial value of such a project at risk.
This risk has been identified by the Enterprise Ethereum Alliance and the Quorum working group has begun the process of documenting the Enterprise Ethereum specific protocols to open the door for alternative Enterprise blockchain clients to be developed.
These blockchain clients will be fully compatible with Quorum, but will be based on a more enterprise friendly open source license (e.g. Apache 2.0).
DECENTRALISED ENTERPRISE APPLICATIONS
Decentralized Enterprise Applications, especially in a regulated environment, present several challenges. Some of these challenges are technical and others are non-technical:
In a productionised version of this POC, the investors personal information would need to be shared across the distributed ledger while remaining compliant to the Protection of Personal Information Act (POPI Act).
Because of the time constraints in the POC a full enterprise KYC solution was not built, however a proposed solution is discussed in depth in the section titled Entity Registration.
Newness of this technology. The Enterprise Ethereum Alliance was only formed in Feb 2017. Although the Ethereum technology is well tested on the Public Network, permissioned networks across multiple organisations are relatively new. The specifics of permissioned networks (different consensus mechanisms, confidential transactions and private channels) are not as well tested.
To mitigate this risk, it is proposed that in a production system:
- The best, and most tested consensus mechanism for permissioned networks be used. For the POC the network ran on RAFT consensus, although the IBFT consensus mechanism is newer and may be better suited for this type of network. IBFT is also being tested in some large semi-public permissioned networks (e.g. Alastria)
- The design of the system be based on the EEA protocol standards and not the blockchain client capabilities. I.e. If a feature is available in a blockchain client but not part of the standard, then don’t include that feature. This will future proof the network and allow newer clients to come online if they are shown to be better.
The legal framework under which the blockchain system would run is of key concern.
Currently one of the assumptions in most of the legal frameworks around financial markets is that one company operates the underlying transactional system or ledger.
In this case, there will be blockchain nodes at the fund administrator, fund management company, the investor platforms and the regulator/s.
Each node will be able to process transactions and will keep a full record of the ledger. New regulations will need to be established splitting the responsibility for ‘ownership’, the transfer of that ownership and the operation of the underlying distributed ledger.
It is recommended that the following steps be taken when implementing this in production:
- Start with a small ecosystem (a single fund management company)
- Once the above has been proven, engage with the regulator and have a regulatory sandboxed environment setup for this system.
REVENUE & GOVERNANCE MODEL
The blockchain may be described as a new generation internet protocol, allowing developers to build decentralised applications on top of this public, open-source infrastructure.
However, unlike the public blockchain infrastructure, where commercial value is mainly captured in the underlying protocol layer, through pay-to-use tokens (e.g. bitcoin), private blockchains, built for business, typically have no commercial value associated with the direct tokenisation of assets onto the blockchain.
Instead, private and permission blockchains are built to either displace existing components of an internal technology stack, or disrupt a central industry trust agent, such as a transfer agency in this case.
As such, the remaining participants in the fund distribution model must reconsider the revenue and cost model for the transfer agency service, now fulfilled by a decentralised blockchain application. The first important decision to make involves the question of ownership.
The revenue and cost distribution model agreed within a permissioned consortium, where all participants jointly contribute to the maintenance and development of the application through a membership fee or shareholders agreement, would be significantly different to that of a third party service partner (i.e. a technology firm offering the transfer agency blockchain as a service).
In the latter example, the service partner may choose to recover infrastructure costs from each participant in the network, proportional to their transaction volumes processed. Alternatively, infrastructure nodes directly hosted and maintained by ecosystem participants, may be rewarded much like public bitcoin miners receive block rewards in lieu of the contribution they make to processing transactions.
Lastly, a scalable, decentralised TA application will require a high level of participant collaboration to operate effectively. For example, like public blockchain communities, participants within the permissioned network will be required to reach a majority consensus before any improvements or changes can be made.
Unless all network participants support a client node software update, the blockchain network will be at risk of creating a hard fork. Uncooperative minority participants may be left running older software, creating interoperability issues and breaking backwards compatibility.
Further research is required to test and validate several workable governances and voting frameworks able to ensure the continuous and reliable collaboration between participants within the network.
Despite the significant progress made in validating the capabilities of the blockchain, due to the limited scope and time of this initial POC, several functional capabilities and areas of interest remained untested. These elements present the most logical future extension of any research project. What follows is a summary of the critical next steps and areas of interest for further analysis.
These recommendations should not be considered an exhaustive or final list of requirements, but rather as the next logical steps and progression within a longer-term iterative development process.
The initial POC excluded the calculation and reporting of investor tax liabilities. Given the ability to report transaction history, investor holdings, as well as individual fund and overall portfolio gains, tax calculations are theoretically possible outside of the application.
However, in line with the objective of decentralising all transfer agency functional capabilities onto the blockchain, the next phase of analysis should include the automation of taxation into several new smart contracts, specifically catering for interest withholding tax (IWT), dividend withholding tax (DWT) and capital gains tax (CGT).
The inclusion of a tax authority node, built to support the oversight role of the revenue service may be of interest in addition to individual investor and intermediary/distributor tax reporting services through the investor application interface.
BESPOKE INVESTOR CLASS STRUCTURES
Currently the POC as built includes only one fee class per fund. Furthermore, the fee class was standardised across all the funds, testing the ability of a smart contract in calculating and deducting only an initial investment fee and an annual management fee, accrued daily. It is envisioned that multiple fee classes should be enabled.
Parameterisation of the fee structures should be possible. Potential exists to pass a set of fund fee class variables, sourced from the investor off- blockchain profile, to a smart contract designed to apply the fee variables upon receiving an investor’s transaction instruction request.
INVESTORS INCOME DISTRIBUTION & FEE MANAGEMENT
The POC simulated the dealings of a single investor only. Future analysis should enable the setup and maintenance of multiple individual retail and institutional investors.
Each investor should be allocated a single virtual currency wallet, providing the required funding for investment subscriptions, collecting redemption payments and distribution of income, as well as supporting disbursements related to commissions and fees payable to intermediaries/distributors.
Each investor profile should allow for the linking of an intermediary/distributor and the associated commission wallet creation for each of the nominated intermediaries/distributors.
The development of income distribution should be completed, correctly applying income factors and distribution valuations for each applicable fund class based on the number of units held.
Fee payments, should be setup to collect from individual investor wallets and distribute directly into linked intermediary/distributor wallets, automatically reconciling and settling payments in real-time.
LOGICAL SOLUTION ARCHITECTURE & TECHNICAL DEPLOYMENT
The TA POC has been built on a private permissioned Ethereum network using Quorum, a modified variant of the standard Go Ethereum (Geth) client. Quorum was specifically developed to provide the financial services industry a permissioned implementation of Ethereum.
The logical architecture of the POC as built includes several key components, namely:
• Ethereum Quorum & RAFT
• Smart Contracts
• Integration Services & Web Presentation Layer
• Node Computing, Storage and Network Infrastructure
ETHEREUM QUORUM & RAFT
Quorum adds the following features to Go Ethereum:
• Additional consensus mechanisms. Proof of Work (POW) is not suited for permissioned Ethereum networks. Quorum currently supports RAFT and IBFT. The POC was built using RAFT consensus. RAFT is a well-established consensus mechanism used in many non- blockchain applications. RAFT allows leader election through voting. It performs well in a permissioned network.
• Private data channels. Many enterprise use cases require the ability to transfer data privately across the network. Quorum has an additional layer called Constellation which allows private contracts to be deployed and private transactions to be run against those contracts. A transaction needs to be marked privateFor, and then only the nodes included in the privateFor list will receive the encrypted payload of the transaction. All other nodes will ignore the transaction.
• Confidential data. Quorum supports the ability to shield transactions on the blockchain. This means that while all nodes can see a transaction and confirm its validity, only specified accounts will be able to identify the details of the transaction (e.g. asset type, amount etc.).
The project team adopted the ERC-20 Token Contract standard for the tokenisation of units and cash and to manage the creation, transfer and redemption of unit ownership and funds between network participants, in this instance represented by the investor and fund manager.
Smart contracts were written in Solidity and tested using Truffle automated test cases prior to deployment.
INTEGRATION SERVICES & WEB PRESENTATION LAYER
The web browser application integrates with the underlying Ethereum smart contracts on the local node using Web3.JS APIs.
NODE COMPUTING, STORAGE & NETWORK INFRASTRUCTURE
The project team provisioned a cloud-based Ethereum environment using deployment tools built for Quorum.
Microsoft Azure was chosen as the target deployment environment. In total, four virtual machines were provisioned to support three blockchain client nodes, and one blockchain utility node.
The utility node supported the ConsenSys private block explorer application and administration console. In addition, the utility node also hosted the web server. Because this was a POC, the webserver ran off a single node, but in a production environment, each node would typically have their own back office integration.
A Mongo database was used for the storage of off-blockchain data, e.g. investor personal data, as well as support for the hosting of several data tables utilised for reporting purposes.
Machine specification were standard DS1_v2 Azure VMs with Ubuntu v16.04.
For demonstration purposes, the nodes were initialised in 4 different regions, namely East US, Northern and Western Europe and Southeast Asia.
HI, WE’RE ELIXIRR. IT’S NICE TO MEET YOU.
Elixirr is a different type of consultancy – we help our clients change the game in their industries. Everyone’s talking about the future, a new digital world, but few are doing anything about it that’s working.
Our strategic and operational advice combines fresh perspectives and unrivalled insight from our global innovation ecosystem with practical and effective methods of making change happen in practice. We put our money where our mouth is and aren’t afraid to link our fees to the successful delivery of your milestones.
We work alongside leading entrepreneurs, venture capital firms and startups, as well as the labs of the established tech giants, across Silicon Valley, London, Tel Aviv and China. This adds to our ability to bring strategic insights and practical approaches for transforming business models and creating operational advantage for our clients.
Feel free to get in touch if you’d like to find out more about how we can help you explore blockchain opportunities within your business. We’d love to hear from you.
About Curo Fund Services
Curo Fund Services, is a proudly South African Investment Administration service provider located in Cape Town, focused on providing a wide range of cost effective outsource investment administration solutions for institutional asset management clients.
Curo Fund Services has been in operations for more than a decade, is one of the largest providers in the South African market with over R2.2 trillion in assets under administration and has a well-established track record with some of South Africa’s largest asset management houses as clients.
ConsenSys is a global formation of technologists and entrepreneurs building the infrastructure, applications, and practices that enable a decentralized world. The consulting arm works with governments, non-profits, enterprises, startups, and partners to educate, ideate, and facilitate the adoption of Ethereum. ConsenSys operate across six continents to help test, build, and deploy public or private blockchain solutions.
ConsenSys Solutions also works to further the ecosystem as a founding member of the Enterprise Ethereum Alliance, the Blockchain for Social Impact Coalition, Decentralized Identity Foundation, and Accounting Blockchain Coalition.