Embed Size (px)
Citation preview
BCT: The Blockchain TerminalProviding Real-time Validation, Security And Compliance For Hedge Funds,
Wealth Management And Cryptocurrency Trading
February 26, 2018
Abstract
The Blockchain Terminal (“BCT”) delivers a powerful set of tools and services tothe wealth management industry, making use of blockchain technology to deliver cut-ting edge applications that have been created by a diverse community of developers,while also enabling real-time compliance enforcement and ad hoc audits. The BCTplatform provides a robust layer of security and functionality to familiar tools, and ca-pabilities that advance the current strategies of traditional investment managers, andalso supports the complexities of cryptocurrency markets. Emerging cryptocurrency-focused investment funds enjoy sophisticated platform tools for both front andback office operations along with the added value and assurance of a complianceframework that provides security for investors across this rapidly emerging asset class.
The central distinguishing feature of BCT is a hybrid ledger that integrates both aprivate and a public, permissioned blockchain to enable its core services. This hybridledger is anchored to the broader Ethereum blockchain, which can be freely used andaddressed by BCT applications, a set of modular productivity tools and services thatare supported by the Blockchain Terminal Foundation. Developers on this platformhave easy access to production-tested infrastructure, with embedded compliance andbroader distribution enabled by BCT’s comprehensive business strategy. The BCTis a high-availability network device that securely journals compliance entries fora hedge fund’s Chief Compliance Officer, and is also a desktop terminal for use byhedge fund traders, analysts, portfolio managers, and operations staff. All installedhardware devices on a firm’s network are configured to a private ledger that improvesthe overall integrity of critical data through consensus. This journaled data interactswith the global BCT permissioned ledger to provide an external anchor for internalactivity that can be observed and verified by external constituents, including auditorsand regulators without compromising confidentiality. The supporting BCT tokenfacilitates the functions of this platform and enhances the convenience of the BCTas a showcase mechanism for a new generation of best-of-breed applications for theindustry.
1
Draft v1.4
ContentsDisclaimer 4
Glossary of Terms and Names 5
1 Introduction: The Motivation 8
2 The Blockchain Terminal Solution 102.1 Cryptocurrency Investment Systems . . . . . . . . . . . . . . . . . . . . . . 112.2 Reference Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Identified Constituents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 The BCT Ledger 143.1 The BCT Ledger Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 BCT Ledger Technology and Architecture . . . . . . . . . . . . . . . . . . 16
3.2.1 Transaction Capture and Synchronization . . . . . . . . . . . . . . 163.2.2 Conceptual Network Architecture . . . . . . . . . . . . . . . . . . . 17
3.3 BCT Ledger Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.1 Identity-Based Authentication and Authorization . . . . . . . . . . 193.3.2 Registration of Canonical Structures and Ontologies . . . . . . . . . 203.3.3 Native Programming Model . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Ledger Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Attestation to the Ethereum Blockchain . . . . . . . . . . . . . . . . . . . 233.6 The BCT Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Blockchain Terminal: Hedge Fund Applications 244.1 Hedge Fund System Innovation . . . . . . . . . . . . . . . . . . . . . . . . 264.2 The Demand for Blockchain Terminal Applications . . . . . . . . . . . . . 26
4.2.1 Hedge Fund Interest in Cryptocurrencies and Blockchain Technology 274.3 Blockchain Terminal Application Categories . . . . . . . . . . . . . . . . . 30
5 ComplianceGuard – The Cornerstone BlockchainTerminal Application 305.1 ComplianceGuard Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.1 Journal Fund Activities and Propagate Alerts . . . . . . . . . . . . 315.1.2 Facilitate Audit of Transactions and Alert Resolutions . . . . . . . 31
5.2 ComplianceGuard Integration . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Blockchain Terminal Development Environment . . . . . . . . . . . . . . . 325.4 Blockchain Terminal Community . . . . . . . . . . . . . . . . . . . . . . . 325.5 Future Developer Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2
Draft v1.4
6 The BCT Token Allocation and Use 336.1 Token Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 BCT Token Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.1 BCT as a Unique Token for the Hedge Fund Industry . . . . . . . . 356.2.2 Subscription and Use of Third Party Apps . . . . . . . . . . . . . . 356.2.3 Token Commissions and Fees . . . . . . . . . . . . . . . . . . . . . 36
7 Phased Implementation Plan 36
Appendices 38A The Blockchain Terminal Foundation . . . . . . . . . . . . . . . . . . . . . 38B Blockchain Terminal Architecture . . . . . . . . . . . . . . . . . . . . . . . 39
B.1 Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B.3 Service Tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B.4 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.5 Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B.7 Logging and Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.8 Monitoring and Process Management Interface . . . . . . . . . . . . 41B.9 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B.10 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42B.11 Native DNS and NSLookup . . . . . . . . . . . . . . . . . . . . . . 42
C BCT User Story Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42C.1 Example 1 – Core Blockchain Terminal Functionality . . . . . . . . 42C.2 Example 2 – Audit and Compliance . . . . . . . . . . . . . . . . . . 43
List of Figures1 Conceptual BCT Ledger Network Architecture. Source, CG Blockchain, 2018. . . . . . 182 Flow diagram of processes in a hedge fund, with BCT’s position clearly outlined. Built
with data sourced from: Thompson and Associates [2010] . . . . . . . . . . . . . . 253 External investment going into select distributed ledger technology initiatives and deriva-
tives, 2013 to 2017 (in US$ millions). Source (Aite [2017]). . . . . . . . . . . . . . . 284 Crypto Funds by inception year, and strategy: Cryptocurrencies and blockchain tech-
nology are taking the marketplace by storm. To truly understand the market fit of theBCT solution, it is important to first recognize the growing importance of technologywithin the hedge fund industry in general—along with recognizing the particular gapthere is in tools to analyze this new asset class. Source (AutonomousNext [2017]). . . . 29
3
Draft v1.4
5 Simplified token lifecycle showing its many different stages and relevant constituents.Note that the public ERC20 token is bound in its complete utility to the BCT networkand has the sole purpose of representing entitlement to services provided using the nativeBCT Token. Source, CGBlockchain, 2018. . . . . . . . . . . . . . . . . . . . . . . 34
DisclaimerThis white paper does not constitute an offer to sell or a solicitation of an offer to
purchase any securities of any nature whatsoever, nor do the contents of the presentationconstitute legal, tax or business advice.
Certain statements in this white paper constitute forward-looking statements, andare subject to change. When used in this white paper, the words “may,” “will,” “should,”“project,” “anticipate,” “believe,” “intend,” “expect,” “continue” and similar expressions orthe negatives thereof are generally intended to identify forward-looking statements. Suchforward-looking statements, including the intended actions and performance objectives ofthe Company, involve known and unknown risks, uncertainties and other important factorsthat could cause the actual results, performance or achievements of the Blockchain Terminalto differ materially from any future results, performance or achievements expressed orimplied by such forward- looking statements. No representation or warranty is made as tothe Blockchain Terminal, future performance or such forward-looking statements, and allsuch statements speak as of the date hereof, and are subject to change.
4
Draft v1.4
Glossary of Terms and Names• Application Programming Interface (API) – A set of clearly defined methods
of communication between various software components.
• BCT Application Store – The CG Blockchain source for subscriptions, tools, andservices to customize the terminal work environment.
• BCT Ledger – A hybrid private/public permissioned, decentralized, immutableblockchain ledger that enables the BCT.
• BCT Token (AKA Native BCT Token) – A native work token for BCT toenable core services.
• Blockchain Terminal – Also called BCT, a hardware device that provides accessto a robust ecosystem of tools and services for the management of traditionaland cryptocurrency assets. It enhances capabilities for the wealth managementcommunity and for sophisticated investors in the traditional and cryptocurrencymarketplaces and integrates with existing software and data sources.
• Blockchain Terminal Foundation (the Foundation) – A Cayman Islands-based non-profit foundation developing BCT and indirectly issuing BCT tokens andmanaging product advancements.
• Blockchain Terminal Framework and API – Public documented libraries andan application/programming interface that provide core tools for developers workingand interacting with BCT.
• CG Blockchain and HF Blockchain – New York-based technology developmentcompanies creating BCT software and hardware solutions and the ComplianceGuardapp, as well as applications for use on BCT.
• Chief Compliance Officer (CCO) – Responsible for overseeing and managingregulatory compliance issues for an organization.
• ComplianceGuard – The cornerstone application of Blockchain Terminal. CCOscan use ComplianceGuard to record logbooks onto a private, time-stamped blockchain,creating an immutable record of all events and data.
• Cryptocurrency – Digital asset and medium of exchange that uses both distributedconsensus and cryptography to secure transactions and control the creation ofadditional units.
• Domain Name System (DNS) – A hierarchical decentralized naming system forcomputers, services, or resources connected to the Internet or a private network, ittranslates common domain names to the numerical IP addresses needed for locatingand identifying computer services and devices with the underlying network protocols.
5
Draft v1.4
• Hash – A one-way cryptographic function that encodes data into a small fixedsize-size packet.
• Merkle Tree, Merkle Root, etc – A hash tree in which every “leaf” node islabeled with a hash of a data block, and every non-leaf node is labeled with thehash of the labels of its child nodes. Named for the inventor, Ralph Merkle (Merkle[1980]).
• NSlookup – A program that lets an Internet server administrator or user enter ahost name (e.g., “whatis.com”) and find an IP address.
• Order Management System/Execution Management System (OMS/EMS)– Systems focused on facilitating and managing the order execution of securities, aswell managing internal order flow and/or routing orders to one or more parties.
• Practical Byzantine Fault Tolerance – The term is derived from the Byzan-tine Generals’ Problem where actors must agree on a concerted strategy to avoidcatastrophic system failure, but some of the actors are unreliable.
• Proof of Authority (PoA) – The right to validate based on reputation so that,once earned, there is high incentive to remain reputable in the system.
• Proof of Existence (PoE) – This protocol inserts a cryptographic signature ofdata, typically a one-way-function using a standard algorithm like SHA256, into theblockchain as evidence of the data being stored.
• Proof of Stake (PoS) – An alternative consensus mechanism alternative to PoW,which trusts input based on the stake that the creator owns in the system. While itwould save energy used for processing, the balance of incentives can become unstable.
• Proof of Work (PoW) – A proof that is difficult (costly and time-consuming) toproduce but easy for others to verify. PoW uses a great deal of computing capacity,which increases the cost and the environmental footprint.
• Public ERC20 BCT Token – An ERC20-compliant subscription token issued bythe Foundation to access BCT services.
• Redundant Array of Independent Disks (RAID) – A data storage virtualiza-tion technology that combines multiple physical disk drive components into one ormore logical units for the purposes of data redundancy, performance improvement,or both.
• Reference Implementation – The standard from which all other implementationsand corresponding customizations are derived.
6
Draft v1.4
• SNMPv3 – Simple network management protocol for collecting and organizinginformation about managed devices on networks and for modifying that informationto change device behavior, now at version 3.
• Sandbox – A testing environment that isolates untested code changes and outrightexperimentation from the production environment or repository, Only after thedeveloper has fully tested the code changes in their own sandbox should the changesbe checked back into and merged with the repository and thereby made available toother developers or end users of the software.
• Service Level Agreement (SLA) – a contract between a service provider and enduser that defines the level of service expected from the service provider specificallydefining what the customer will receive.
• Smart contract – A computer protocol intended to digitally facilitate, verify, orenforce the negotiation or performance of a contract. Smart contracts allow theperformance of credible transactions without third parties. These transactions aretrackable and irreversible.
• Token – A cryptographically verifiable entitlement to digital resources that can beexchanged for products or services.
• Turing Completeness – A system is Turing complete if within it a program canbe written that will find an answer to a given problem, irrespective of runtime ormemory use; traditionally a system is called Turing complete, or computationallyuniversal, if it can be used to simulate any single-taped Turing machine and givenenough tape, a Turing machine could compute any program.
7
Draft v1.4
1 Introduction: The MotivationThe financial crash of 2008 and increasingly frequent cases of fraud within investment
management industries have made high finance and alternative asset classes top headlines.Significant wealth accrued in some sectors since the last recession has been the subject ofincreased scrutiny, as fund managers seem to stand as a class apart. Clients and investors,meanwhile, pay steep management fees even as the performance of their investments in bothtraditional funds and new alternative vehicles slips. With frequent headlines describingmassive frauds filling the news cycles—from Madoff to the recent US$1billion breach of thePunjab National Bank in Mumbai—the ability to make secure and attestable transactionsdirectly and with absolute confidence is quickly becoming the expected security standard.This new world of compliance and consumer protection adds complexity to routine trans-actions and requires stepping beyond the status quo in order to move forward to raise capital
Blockchain appeared in the wake of the financial crisis as the underlying technologyto enable “A Peer-to-Peer Electronic Cash System” in the form of cryptocurrencies likebitcoin and ether (Nakamoto [2008]). While the cryptocurrencies dominated the news, thebreakthrough distributed ledger technology of blockchain jumped the chasm of adoptabilityand has emerged as the innovation that could upend business models and open a new eraof transparency and decentralization for a wide range of industries including investmentmanagement.
Investment managers, specifically hedge fund managers, and managers working inal- ternative investments, are constrained by investor mandates. The execution of theirfiduciary responsibilities in compliance with these mandates is opaque and difficult totrack, making adherence to constraints and proper handling of exceptions difficult todemonstrate. Even when compliance is demonstrated, the attestation requirements ofaccountants, auditors, counterparties, partners, and investors are burdensome and incon-sistent.
With an ingenious combination of cryptography and mathematics, blockchain-basedtransactions are verified, cleared, and stored in a block that is linked to the precedingblock. The result is a chain that provides an immutable record. Blockchain Terminal(BCT)—a creation of the developers at CG Blockchain in partnership with FactSet, a globalprovider of integrated financial information, analytical applications, and industry-leadingservices—leverages the power of blockchain technology in order to bring the security, assur-ance and immutable trust demanded by the operators of hedge funds, wealth managemententerprise, and cryptocurrency trading. The use of smart contracts in the BCT networkallows audits in real time, while applications that create privacy features can assert thetruth of the record while protecting the privacy of the participants.
8
Draft v1.4
A broad community of developers has created a catalog of BCT applications thatpresent an array of powerful new tools enabling ad hoc audits and delivering transactionaltransparency and real-time compliance assurance. Using the BCT, investment man-agers can assure a robust layer of security and functionality to their advancing businessstrategies. At the same time, the BCT introduces capabilities for effective managementof the complexities of cryptocurrency markets and across a rapidly emerging new asset class.
The central and distinguishing feature of BCT is the use of a hybrid distributedledger system, one that utilizes the advantages of both private and a public permissionedblockchains. The established Ethereum platform, distinguished by its use-tested andreliable capacity for running smart contracts without downtime, fraud, or interference, isthe anchor for the modular productivity tools and services that are offered for the BCTand supported by the Blockchain Terminal Foundation (the Foundation).1
BCT developers have access to a production-tested infrastructure, embedded compli-ance, and broad distribution that are part of the comprehensive business strategy. Thenetwork devices related to BCT—which can be used by a Chief Compliance Officer, oras a desktop terminal for use by traders, analysts, portfolio managers, and operationsstaff—securely journal entries with compliance assured. The private ledger assures thatthe overall integrity of critical internal data is maintained using the consensus of theblockchain, and it interacts with the permissioned ledger to provide an unalterable recordof transaction activity that can be observed and verified by external constituents, includingauditors and regulators.
BCT technology provides a secure record of hedge fund execution and operationalactivities. With blockchain as the foundation of an application framework, the wealthmanagement and software developer communities can use simple tools that create trans-parency for the benefit of investors and core stakeholders. Data that supports complianceis immutably stored during the normal course of business and can be retrieved and au-dited as needed, providing near real-time verification of adherence to compliance mandates.
The platform will reduce compliance burdens while improving technology standardsand choices for new and incumbent hedge funds. The core features and benefits of BCTinclude:
• Universal standardized audit – BCT time-stamps all transactions onto theimmutable, distributed ledger. Notes and documentation are also recorded in asecure and tamper-proof environment. Review can be real time and potentiallyproblematic activities are highlighted.
1 See a description of the Foundation below.
9
Draft v1.4
• Robust tooling – A simple interface allows for identifying and selecting froma catalog of carefully curated applications that support a broad range of front,middle, and back office investment lifecycle activities. Applications are built on acompliance framework and meet stringent standards for completeness, ease-of- use,secure operation, and user support.
• Native support for cryptocurrency as an asset class – Professional tools andinformation sources help connect the traditional hedge fund industry with the rapidlyexpanding investment opportunities in the cryptocurrency space.
• Support for third-party application development – BCT developers and es-tablished software vendors benefit from a productive, advanced, effective environment.The open distribution channel reaches existing and new customers with powerfultools to address both traditional and cryptocurrency assets, while meeting the mostcurrent compliance requirements.
The Blockchain Terminal Foundation (the Foundation) is Cayman Island-based and isresponsible for many of the key processes and foundational requirements of the BCT (seeAppendix A). Foundation responsibilities include oversight of BCT development programs,and issuance, subscription and management of the BCT token. The Foundation alsomaintains the hosting environment for the permissioned ledger systems.
Community connections will be cultivated by the Foundation through meet-ups, eventsand tutorial sessions to enhance and improve both developer and user experience.
2 The Blockchain Terminal SolutionWhether addressing traditional asset classes or exploring opportunities offered by the
cryptocurrency community, users can be confident of the quality of curated BCT applica-tion offerings. The BCT interface enables institutional-grade operations, decision support,and gateways to execution. Browsing the application catalog, viewing and contributinguser reviews, managing application subscriptions, administering terminal user accounts,and engaging with user support are all easy to accomplish.
The technical solutions and cultivated vendor relationships that large hedge funds havedeveloped to deliver the technology and compliance requirements of their operations arecomplemented by the BCT functionality. Expanded operational performance of existingsystems made possible by BCT applications that have demonstrated superior utility andpainless integration with the underlying compliance framework.
The seamless compliance of the BCT is implemented through:
10
Draft v1.4
• Dual blockchain architecture – The BCT ledger consists of both a private (local)blockchain and a permissioned (global) blockchain. Confidentiality of sensitive data(e.g. accounts, positions, trades, securities, orders, strategies, etc.) is maintained byrecording only to the local blockchain, while the permissioned global ledger recordscore BCT services and aggregates time-stamped hashes from individual ledgers.
• Robust application development framework and API – The BCT and theFoundation will pursue ongoing platform and application development with es-tablished vendor communities and third-party developers and promote expandingadoption of the technology across the industry.
2.1 Cryptocurrency Investment Systems
In the traditional hedge fund environment, the BCT provides a mechanism for legit-imizing hedge fund manager operations, and, significantly, implementing cryptocurrencystrategies. For funds pursuing cryptocurrency as an asset class, it is critically important toemploy an advanced class of tools for legitimizing and providing transparency to operations.Funds that seek to maximize returns from participation in this new investment opportunityare struggling with a patchwork of vendors, technology solutions, and manual processes,but little institutional support. Calculating unrealized gains, for example, is a challengebecause exchange liquidity is not uniform across all assets, making calculations difficult.Likewise, marks taken across exchanges may not represent prices available when a fund isable to move its assets to a given venue in a timely fashion. In this challenging environment,enhancing existing systems with powerful new tools becomes even more important forboth the fund and its investors.
2.2 Reference Implementation
The BCT reference implementation is a self-contained server delivering integratedplatform software installed on a desktop terminal. When connected to a local area network,it serves as a node that creates the replication and consensus required for the privatedistributed ledger that stores account, trade, security master, position, and other fund-specific transaction data.
The tools that the reference implementation makes available include:
• An institutional-grade market data information platform.
• The ComplianceGuard application for providing alerts and ensuring immutability ofcompliance alert events and their resolutions.
• An order management system and execution management system (OMS/EMS)environment that is able to address both traditional and cryptocurrency assetclasses.
11
Draft v1.4
Technical features of the BCT system include:
• A self-contained server – Network-attached and part of a COO’s office or datacenter. A RAID storage configuration maintains the core private ledger and otherkey elements used locally by BCT applications running locally.
• User desktop terminals – A security-hardened compact desktop system installedat one or more workstations accessible to staff and traders. It presents a small-footprint with large monitor real estate and keyboard, as well as USB ports toaccommodate hardware wallets and peripherals.
• Anticipated components – Mobile, tablet, and other component choices areexpected as part of the system, enabling remote access to critical information.
2.3 Identified Constituents
The perspectives of users will be codified and extended into enterprise permissionsframeworks and audit systems. User roles to be considered include:
• External auditor – A party tasked with review of a hedge fund’s private transactionlog for the purpose of auditing a hedge fund’s transactional record.
• BCT roles:
– Global administrator – Foundation staff member that ensures the functionand integrity of the BCT permissioned network.
– Approval generator – Validates applications before releasing them to theuser community.
– Vendor – Third party provider of applications or scheduled services.
• User roles:
– User – Anyone who interacts with BCT applications.– BCT Administrator – Responsible for overseeing account and service man-
agement of a hedge fund’s installed systems.– CCO – Responsible for enforcing fund strategy mandates and regulatory
constraints.– Investment analyst – Provides research and identifies opportunities for in-
vestment and strategic development.– Operations – Responsible for the execution of complex trades and reconcilia-
tion of positions, as well as the sourcing of supporting documentation.– Portfolio manager – Manages a hedge fund portfolio and its allocations to
investment opportunities therein.– Trader – Responsible for the execution of trades with a specific counterparty.
12
Draft v1.4
2.4 Design Principles
Both the BCT and its supporting framework conform to the following guiding principlesand requirements:
• Security – Confidentiality, integrity, and availability of constituent data are critical.Information storage must ensure confidentiality and consistency, and provide for easeof access and audit. Data should be validated and verified according to establishedstandards and within the context of a legitimate purpose of use. Applications anddata stored by the platform should accommodate business continuity and disasterrecovery planning.
• Identity – Strong authentication and authorization for provisioned resources isrequired. Flexible credential management will allow roles and permissions for agiven hedge fund to have natural extension and mapping to supported roles of BCTapplications. Credentials, authentication, and authorization decisions should have noglobal impact or applicability, and only be recognized and enforced at the hedge fundwhere credentials are established. The global permissioned features of the platformare to be maintained by the Foundation.
• Integration – BCT applications are not expected to run in isolation. They makeuse of enterprise data, including reports and feeds from systems that may notbe available for subscription or management on the BCT. These integrations aresupported through a rich set of interfaces (APIs) that provide near-real-time dataaccess and subsequent analysis. BCT applications should be adaptable to enterpriseinfrastructure and a central administrator should be able to identify and assignenterprise user directories, storage, data stores, and message bus alternatives topackaged BCT offerings, allowing hedge funds to leverage BCT applications onexisting infrastructure and platform investments that support robust SLAs.
• Open Community and Open Source – BCT and the Foundation are committedto the development of best-of-breed applications and promotion of the technologiesand techniques that make the platform possible. The BCT actively works withand promotes open source blockchain architectures as legitimate, decentralizedalternatives for its constituents in seeking access to more traditional venues. The BCTuses its own token and, through the use of a standards-backed wallet infrastructure,provides a free and open channel for the use of other tokens on its platform whereand whenever possible. Interactions and use of other tokens on the BCT areenvisioned to be managed by the user who owns those tokens, not the BCT, theFoundation or validators of its network. BCT development is community drivenand the ComplianceGuard application’s core elements are open source. Wheneverpossible, subsequent core developments will also be open source. BCT and theFoundation use and promote open source software and open communication channels
13
Draft v1.4
for input; whenever possible, BCT will encourage its vendors and developers to dothe same.
3 The BCT LedgerThe introduction of bitcoin (Nakamoto [2008]) and the subsequent rise of blockchain
distributed ledger architecture created a revolution of digital asset ownership and multi-party trust. Cryptocurrency users and exchanges secure transactions using distributedledgers, effectively replacing the model of trusted central authorities with decentralizednetworks of unknown actors who can nevertheless be trusted to validate transactions usingconsensus algorithms based on cryptographic proofs.
In spite of the increasing viability of distributed ledger approaches, global capitalmarkets, hedge funds, traders, and asset managers continue to rely on traditional auditprocedures to provide confidence among stakeholders and regulators. The BCT ledgerapproach provides a mechanism for any permissioned party with access to private fundtransaction data to attest to the legitimacy of a fund’s actions with certainty and reasonedauthority.
The immutable records created in blockchain-based systems streamline data verificationand transactions, and can be assured by comparing derived hashes within the blockchainledger. The blockchains can be implemented in a number of ways, requiring either publicor private consensus. Private, permissioned blockchains are commonly used to establishtrust in business-to-business relationships. R3 Corda (Hearn [2016]) and the HyperledgerProject (Cachin [2016]) are recent examples of enterprise blockchain implementationsthat employ private, permissioned chains. Global accounting firms, including Deloitte(Andersen [2016]), PwC (Diemers and Koster [2016]), KPMG (Brown [2017]), and EY(Crawford and Meadows [2017]), have identified the utility of using blockchain-based notaryservices that have the potential to enable timely and fully automated financial audits thatare seamless, error-free, and tamper-proof.
In the hedge fund environment, managers require security for the most sensitive data(e.g., accounts, balances, and positions). However, many permissioned ledger implementa-tions do not use consensus mechanisms. They are unable to resolve the fundamental issueof trust without assistance from a third party.2
Because they require secure identity services, existing systems are only as secure andvaluable as their participants. Key management, especially for a global ledger, can require
2 In the most robust implementations, permissioned ledgers achieve consensus using the practicalByzantine fault tolerance algorithm [PBFT] (Castro et al. [1999]) or a Proof of Authority consensus,where principal actors vote on data validity.
14
Draft v1.4
extensive identity management and overhead cost in order to credential parties at varioushedge funds and among other constituents. Roles and permissions are difficult to addafter a smart contract has been created to govern blockchain activity, and private keysare bound to a user wallet. The addition of new users raises concerns about appropriateaccess to legacy data, while removing users must assure that access to blockchain datahas been restricted. Given the circulation of employees among financial enterprises, a pastemployee with credentials to a global permissioned ledger might see an opportunity to usethose credentials in a different venue.
3.1 The BCT Ledger Elements
Cryptographically enabled by the native BCT token, the BCT ledger, while observedas one logical entity, is comprised of two separate but related blockchain ledgers:
1. A private local ledger supporting the storage of sensitive data, hosted within a hedgefund; and
2. A private global ledger where the aggregated hashes of each constituent hedge fund’sprivate ledger data are posted at fixed intervals.3
This model of interaction follows a common practice for anchoring the mechanism oftwo chains using Proof of Existence (Araoz [2013]).4 This approach allows informationstored to the BCT ledger to be private, but also externally auditable. The BCT ledgerreliably captures activities that support the alert and audit functions that hedge fundsrequire for conformance to the mandates of regulatory and internal authorities.
BCT assures near total privacy using the global ledger in conjunction with a hedgefund’s own private ledger. Because the privacy of the global ledger is never fully assumed,mechanisms used for storing data on the global ledger make extensive use of zero knowl-edge proofs in cases where journaled entries could be readily identifiable (Green [2014]),(Green [2017]). A blockchain notary service secured by the Ethereum network providesauditability. In this way, the proprietary BCT dual ledger approach is tethered to a publicsource of distributed trust that both maintains confidentiality and security, and providestransparency.
As a third layer of attestation, the BCT Ledger’s global blockchain will be anchored tothe public Ethereum blockchain to provide for added security, consistency and integrity.This process is explained with detail in the Attestation to the Ethereum Blockchain section.
3 Note that the private global ledger is not the public Ethereum network, but an additional component.4 See formal definition in Glossary
15
Draft v1.4
3.2 BCT Ledger Technology and Architecture
Both the private ledger hosted by a hedge fund, and the permissioned global ledgerwill be implemented using Ethereum compatible technology, which supports over US$98billion5 in value. This will provide native support for both smart contracts and use oftokens that meet the ERC20 token standard that is commonly used across a multitudeof Ethereum public blockchain projects. This established blockchain technology opensaccess to a robust community of supporters and developers who readily understand thetransformative nature of the technology, and the opportunity to migrate to a proprietaryblockchain exclusively enabled by a native BCT token. In the meantime, bringing an openEthereum-anchored blockchain to the hedge fund industry will provide both the BCT andthe broader cryptocurrency community a decentralized ledger technology with a vibrantplatform for the development of powerful and innovative applications.
3.2.1 Transaction Capture and Synchronization
The BCT private ledger will be hosted on-site as an isolated node or closed network ofBCT devices operating on the hedge fund’s network. It will be integrated into the existingOrder Management System and Execution Management System (OMS/EMS) of the hedgefund, for the purpose of performing transaction and event capture.
The open specification of the BCT ledger allows integrators and developers to customizesolutions for a hedge fund’s specific requirements. As transactions and events, includingcompliance alerts, are generated, representations of these structures are sent as messagesto a subscribing queue. A listener to that queue is tasked with hashing all transactions andevents within a fixed time interval and forwarding the data to the global private ledger,together with associated hashes. These hashes are in effect branches of a Merkle tree,whose Merkle root can sufficiently represent all data received over that scheduled intervalto the BCT private blockchain for processing.
The approach appends Merkle roots of associated transactions to the private ledgercomponent, providing for flexibility in dealing with common variances in transaction andevent volumes. In this way, the BCT private ledger will avoid issues of block formationand consensus overhead when dealing with high frequency transactions, acting on as manytransactions within a minute as some other strategies may generate over the course of aday, or longer.
The queue in the hedge fund centers that process transactions and generate eventscontinuously attempts to publish journaled hashes to the private chain. Regular timingintervals are established using negative acknowledgement (NAK) messages to both the
5 Cryptocurrency Market Capitalizations, see (https://www.coindesk.com/ethereum-price/),(https://coinmarketcap.com/) and (https://coinmarketcap.com), accessed Jan. 19, 2018
16
Draft v1.4
private and global ledgers should no transaction data appear within a scheduled journalwindow. Journaling a hash of an NAK message to the private or global blockchain isan implicit mechanism for demonstrating that the publication mechanism is runningconsistently, even if transactions and events are not being generated by the hedge fund’sinvestment or operations activities. This regular timing interval commits a hash to theprivate ledger and, subsequently, to the BCT’s global ledger. The queue is critical toreconciling transactional integrity for a given period and eliminates the need for pullingtransactions and events from outside the immediate window of interest to perform areconstruction of hashes being used for validation.
A staff role of “event listeners” to monitor inbound queued transactions and eventsfor persistence and journaling against the private blockchain of the BCT ledger is astandard practice. These event listeners are tasked with originating notifications and alertsassociated with specific message characteristics, including embedded object definitionsand ontologies that may be serialized for reference on the BCT ledger.
The BCT global ledger uses a closed process of collecting transaction and event hashesfrom each BCT private ledger. This critical component does not require active inboundqueuing, as throttling to the block creation and consensus latency are already accommo-dated by integration within the hedge fund’s transaction environment. Scheduling andNAK messages are still used heavily in the journaling of private blockchain activity to theglobal ledger to allow for ease of correlation between observed blockchain hash entries andthe private blockchain hashes from which they are derived.
Infrastructure integration is both critical and sensitive. The Foundation will rigorouslyassess providers before endorsing preferred vendors for these software packages and services.
3.2.2 Conceptual Network Architecture
Figure 1 provides a conceptual view of the current construct of the BCT networkarchitecture. Each participating hedge fund establishes a virtual private network (VPN)connection to the BCT operating network. The connection to BCT global ledger nodesrestricts network visibility allowing the hedge fund network to see only the global ledgernode instance responsible for its journal activity.
The Foundation operates core global ledger services; however, as the pool of interestincreases with the expansion of the BCT architecture and network, other authorities,including regulators, auditors, and prime brokers may all be potential candidates to serveas global ledger nodes.
17
Draft v1.4
Figure 1: Conceptual BCT Ledger Network Architecture. Source, CG Blockchain, 2018.
18
Draft v1.4
3.3 BCT Ledger Features
The BCT ledger architecture will have three component features leveraged across bothprivate and global execution contexts:
1. An identity-based authentication and authorization framework – this willbind enterprise-validated identities from a directory service to roles and permissionssaved on the blockchain
2. A registration service – this will represent canonical data models and ontolog-ical structures against those models, which are used to support both applicationintegration through a standard message bus and the application of deterministic ornon-deterministic logic
3. A native programming model – for the constraining behaviors associated withrelationships established on the blockchain, which, in the case of BCT implementation(using an Ethereum blockchain), is provided by the popular Solidity smart contractprogramming language
3.3.1 Identity-Based Authentication and Authorization
While public, permissionless blockchains work without need for user identity, BCT willoperate using a role-based identity service that is assured by an established web-root oftrust in order to create a layer of transaction accountability. Within the BCT private andglobal chain architectures there will only be two types of identity that require management:the Foundation, as the identity providing governance over the global ledger and each hedgefund itself, in providing authority over the governance of its own private blockchain.
Each BCT device on a local hedge fund network will generate a local key pair duringconfiguration. If only a single BCT is running locally, transactions will be journaledbetween the private and public key of the same keypair. All BCT transactions on a localhedge fund network will be trusted using the same web-root of authority for that hedgefund implementation; the local peer-to-peer ledger network is secured using standardpublic key encrypted protocols that permit for peer-to-peer connections.
All user identity functions will be relegated to applications on the BCT, which throughuse of BCT framework and APIs, will be federated back to the hedge fund’s own identitymanagement infrastructure (e.g., Active Directory, OpenLDAP, etc.) or a locally providedimplementation of a lightweight directory access protocol (LDAP) server implemented onthe BCT local server. BCT users will not have broader blockchain identities that existoutside the scope of the hedge fund itself. A local system administrator or the hedge fund
19
Draft v1.4
CCO will manage registrations.6 All transaction activities performed in the scope of auser account will be journaled through the compliance interface of the supported BCTapplication. This allows reasonable separation of a BCT (in its role as a journaling nodeon the local hedge fund network), and the identity of a user who may be logging into aspecific service provided by the BCT.
The hedge fund’s local web-root of trust certificate will be propagated to the globalledger environment to authenticate a hedge fund-based network node attempting to journalan interaction with the global BCT ledger.
Applications will be encouraged to use the BCT framework provisioning policies toensure that enterprise roles and permissions can continue to be audited centrally by ahedge fund systems administrator. To the extent that an application allows for a globalidentity enrollment using a third-party verification service, the BCT application frameworkwill have the ability to disable these mechanisms to ensure strict compliance with electronicdevice usage policies that the hedge fund may have in place.
3.3.2 Registration of Canonical Structures and Ontologies
A BCT user, the hedge fund CCO or designee, or a BCT vendor may register canonicalstructures and ontologies against the private ledger and vendors may also register to theglobal ledger to support integration and interactions with applications. This will occurin the context of a notary service in which BCT tokens can be used to submit data as apermanent anchor to the target ledger.
Traditional transaction activity is built upon regulatory standards. In the same way,the BCT ledger encourages the introduction and reuse of various common domain objectsand behaviors that can be stored, serialized, and parsed. These objects include standardcategories: accounts, securities, strategies, locations (custodians), positions, orders, trans-actions, balances, and prices. Concepts from FIXML (CME-Group [2017]) and FpML(FpML [2015]) can be similarly adapted to registration on either ledger.
The BCT framework and API will provide a simple standard for applications designedto address and store domain objects. Each object will form a collection that persists tothe private ledger so that it may be referenced by applications that utilize the data. Anadministrator can easily audit data and quickly set references to individual collectionentries as being invalid if necessary. Integrated processes may add to collections, butcannot modify existing data; and the collections are immutable. The BCT ledger will offer
6 If users anticipate engagement with environments where OFAC/AML considerations weigh heavily,the diligence for registration protocols will fall to the individual application providers in conjunction withthose parties seeking subscription; the BCT is not envisioned as a counter-party, custodian, facilitator, orbeneficiary of any transaction on its system.
20
Draft v1.4
Turing completeness by executing smart contracts and embedding them in transactionsthat occur between the fund and itself (in the case of a private ledger), or the fund andthe BCT. The ledger will also guarantee that only objects that are built to an acceptedstandard, as referenced in registered domain models and supporting ontologies, can beused in applications and shared in application-supported integration. Governance andgeneral reference to these models will be enforced by the Foundation.
The collections may be used in many ways:
Security master validation – A collection of firm-traded securities built from a user’ssource system of record as a trading security master includes:
• An application that performs trade capture audits.
• Automatic validation of trades processed through the BCT framework and API, forensuring integrity against user’s known security master.
• CCO notifications will be triggered should a trade address a security that wasnot previously traded. This will validate its specific trading guidance for industry,geographic, custody and specific concentration.
• Option for CCO to auto-add new securities to transaction log or suspend integratedfeed, pending review.
Price validation
• A collection of prices is kept for each security in the security master collection.
• An application performs retrospective profit-and-loss over a given strategy, byretrieving price as of a given date.
• CCO receives an alert when a price for a specific date does not exist.
• CCO receives alert when a price exists, and the price has not changed for a specifiedinterval of consecutive days.
• The CCO asks an operations analyst to provide a reason for the price discrepancy.A new as-of price is added to the security’s price collection. All applications usingthe price collection are automatically updated.
Balance reconciliation
• A collection of balances of securities for each user strategy is kept.
• Reconciliation on a morning-by-morning basis ensures positions in custody matchstated positions/balances of the fund.
21
Draft v1.4
• Trade breaks are recorded prior to reconciliation.
• Reconciliation resolutions can be journaled and maintained adjacent to repairedposition data.
• Applications using the data API can be updated.
3.3.3 Native Programming Model
A native programming model runs a collection of smart contracts on the underlyingnetwork of the BCT’s private and global blockchains. The smart contracts are maintainedby the Foundation and operate through the use of BCT tokens. The BCT reference systemhas two contract operations available that write a hash to the public Ethereum blockchainvia the BCT ledger:
• Object enrollment – A one-time process that proves the structure of a domainobject or ontology on a network. This includes real-world validation of domainobjects and ontologies and saving associated component references to the Ethereumblockchain operating as a global ledger, via a BCT token contract.
• Request for notary record – A catch-all operation used to create a verifiabletimestamp of data entry and also to notify other parties of an event. This is executedby submitting a hash of the data and a timeout for other parties to sign it. BCTthen notifies the appropriate parties.
Similarly, the BCT reference implementation only offers two operations to read datafrom the BCT Ledger:
• Verify object – A verification algorithm that checks the validity of the domainobject and ontology registration records on the Ethereum blockchain. The BCTaddress queries the private or global blockchain as the verification request searchesfor and returns matching object enrollment records.
• Search notary data – BCT searches for the hash of notarized data from a validrole. Users can ensure information has not been altered as of the moment it wasnotarized.
These operations are foundational, and can be called for by executing transactions withBCT tokens sent to either components of the BCT ledger. They are the basic buildingblocks. The complete BCT platform permits the message-based integration and validationof transactional data that is fundamental to the compliance-forward architecture of theBCT platform.
Incentives to write applications that use the BCT ledger will include integratedsubscriptions. It is anticipated that the private and global ledgers will be open andaccessible to developers for the performance of direct interactions using BCT tokens tosupport smart contracts.
22
Draft v1.4
3.4 Ledger Consensus
The BCT ledger will be operated through two mechanisms of consensus: Proof ofAuthority (Czaban [2017]) and Proof of Work.
1. Proof of Authority (PoA)A mechanism common in enterprise blockchain implementations, PoA does notrequire nodes to solve arbitrarily difficult problems or to prove veracity in appendingtransactions. Instead, it is given permission (the “authority”) to make these additions.The private chains implemented by the BCT ledger, and created by nodes installedat the location of each hedge fund, employ PoA. At present, the BCT ledger’s globalblockchain will also use a PoA approach.7
2. Proof of Work (PoW)The PoW mechanism by which the public Ethereum blockchain achieves consensusis work intensive by design. The transition to a Proof of Stake—authority based ontokens held—will reduce intense power requirements of PoW based networks. TheEthereum network nodes are responsible for competing to generate the solutions tocryptographic-based challenges that earn tokens for appending data onto blocks andonto the Ethereum distributed ledger.
Just as the private, hedge fund-maintained blockchains of the BCT ledger will beanchored to the BCT global chain using Proof-of-Existence (PoE), the BCT ledger journalshashes to the public Ethereum distributed ledger, thereby establishing a layer of trust andaccountability. The PoW consensus of the public Ethereum ledger provides the integrity ofthe broader BCT network’s attestation to the validity and non-repudiation of its operations.
There is currently no governance model for PoA; however, the Foundation anticipatesdevelopment of a suitable model.
3.5 Attestation to the Ethereum Blockchain
The Blockchain Terminal will bridge the multiple layers of blockchain self-attestationto the broader immutability of the public Ethereum network. At scheduled intervals, aPoE client process from the operating nodes that supervise the construction of the ledger(and do not append transactions), will submit a Merkle root to the Ethereum network for
7 As the number of participants in the BCT ecosystem increase to include other stakeholders withinterest in the data of the public ledger, the distribution of this ledger may transition to another consensusmechanism, such as Proof of Work or Proof of Stake.
23
Draft v1.4
all transactions against the global ledger occurring within the timeframe.
The PoE hash can be identified and used for verification of the internal consistency ofthe BCT global ledger for the period. An outside observer could identify the transactionwritten to the Ethereum ledger, and use that Merkle root for verification of the internalconsistency of the BCT global ledger for the corresponding period.
3.6 The BCT Tokens
Two BCT tokens co-exist in the BCT ecosystem. The native BCT token powers theBCT ledger; and an ERC20-compliant BCT token created in the public Ethereum networkand available from time of launch represents subscription and entitlement to the servicesprovided by the native BCT Token. Together, the two tokens secure integrity and provideincentive for the correct functioning of the BCT platform. The native BCT token willbe issued by the Foundation through a subscription smart contract that will credit thepublic ERC20 BCT tokens with native BCT tokens one-to-one. The Foundation will bethe beneficiary of this smart contract and will hold it in escrow until the native BCTtokens are exhausted. Participants in the BCT community use the BCT token to:
• Request or commit domain objects and ontologies to the BCT Ledger.
• Request or commit a PoE to the BCT ledger.
• Access applications on the BCT platform (either one-time use or subscription).
• Enable core services of the BCT platform and capture fees and commissions for theFoundation.
The BCT permissioned ledger is strongly centralized, making entitlement to the robustpublic Ethereum network the most secure choice. Because holders of the BCT Token willuse the BCT and its services, they will be pre-disposed to use established investment inprocesses, software, and hardware. This practice provides personal and institutional cybersecurity and will ensure the control and preservation of their entitlement to BCT servicesusing off-line cold storage methods, which the public ERC20 BCT token will support.
4 Blockchain Terminal: Hedge Fund ApplicationsThe Blockchain Terminal application platform will operate across a number of different
devices and offer a standardized storefront for application developers and third-partyvendors on which to publish and distribute user applications. Hedge fund users will haveaccess to institutional-grade data and execution for cryptocurrency trading. The curatedcollection of applications can be acquired using BCT tokens.
24
Draft v1.4
ComplianceGuard is the cornerstone application and reference architecture for de-velopment on the BCT platform. A breakthrough innovation in the asset managementindustry, the application is the immutable ledger that supports compliance-related serviceson the BCT platform, and provides a greatly improved level of attestation for transactionalactivities performed within a hedge fund.
In addition to compliance, the features and functionality of the Blockchain Terminalenable broad interaction with a number of standard hedge fund information flows anddecision-making processes, as shown in Figure 2.
Figure 2: Flow diagram of processes in a hedge fund, with BCT’s position clearly outlined. Built withdata sourced from: Thompson and Associates [2010]
25
Draft v1.4
4.1 Hedge Fund System Innovation
BCT has been designed from the ground up to bridge interactions between cryptographicassets, their blockchains, and a hedge fund industry operating within a complex globalregulatory environment. Interactions with these core data flows and constituents willposition BCT applications to create innovation in a number of systems within traditionalhedge fund infrastructure, including:
• Order management and execution management systems (OMS/EMS) –EMS is layered above the OMS, and algorithms will generate multiple orders acrossvenues and over a period of time. Applications are designed to display marketdata and provide users with robust algorithms for addressing a variety of marketenvironments or enacting specific strategies in order to provide complete and efficientaccess to traditional and cryptocurrency trading destinations with the purpose oftransacting orders.
The BCT serves as an overlay to existing or arranged connectivity for the fundor user. The BCT may enlist applications on its platform that bring their ownconnectivity to the BCT system so as to provide differentiated trading and executionservices. In these instances, the BCT serves as a distribution platform and therelationship between application provider and user is apart from the terminal.
• Portfolio management systems (PMS) – Provide asset managers and buy-sideteams with everything required to manage their funds including portfolio analyses,order management, compliance, risk management, reporting, and middle officesolutions.
• Safety and compliance solutions – For convenience, compliance with cyber-security best practices, and ease of use, the BCT will support wallets (hardware andsoftware based) native to the Ethereum ecosystem that can be linked to electronicidentities and can be used to generate an assured audit trail and track and trace thechain of events, authorizations and modifications.
The BCT token will permit the development of entries that create a PoE entry,allowing individuals and companies to prove the existence of a certain document,transaction, audit, or right at any given point in time.
4.2 The Demand for Blockchain Terminal Applications
BCT is positioned at the crossroads of two burgeoning areas in the hedge fund industry:increased demand for technology and increased interest in both cryptocurrencies andblockchain technology. Pressed by its frequent failure to outperform the market in past
26
Draft v1.4
years, the industry is turning to technology, and increasingly cryptocurrency and blockchainsolutions, as a means to regain its previous strength.
4.2.1 Hedge Fund Interest in Cryptocurrencies and Blockchain Technology
A September 2017 survey of hedge fund managers by BarclayHedge revealed that 24%of hedge funds either currently invest in cryptocurrency or plan to invest within the nextsix months (BarclayHedge [2017]). One study of 120 private fund advisors reported that,“The findings are consistent with anecdotal evidence suggesting that the returns attain-able through crypto investments have no short-term match in legacy systems” (Kaal [2017]).
The related blockchain technology industry has seen a dramatic increase in investmentsin recent years. A report from the AITE Group explains that blockchain technology “ispoised to give businesses a lower operational base, greater automation, and faster deliverytimes” (Aite [2017]). Other research has reported that “blockchain technology plays aprimary role in front office and investment functions, in the securing of crypto assets, butalso in private investment fund managers’ attempts to satisfy the growth expectations ofclients” (Kaal [2017]).
The staggering price fluctuations of cryptocurrencies are one indicator of the surgeof interest in this market. Also striking is a sudden increase in the number of hedgefunds devoted to cryptocurrencies and blockchain technology over the past year (see figure3). A total of 17 crypto hedge funds were reported in existence between the years 2011and 2016. As of November 2017, that number had multiplied to a total of 99 new funds(AutonomousNext [2017]).
27
Draft v1.4
Figure 3: External investment going into select distributed ledger technology initiatives and derivatives,2013 to 2017 (in US$ millions). Source (Aite [2017]).
28
Draft v1.4
Figure 4: Crypto Funds by inception year, and strategy: Cryptocurrencies and blockchain technologyare taking the marketplace by storm. To truly understand the market fit of the BCT solution, it isimportant to first recognize the growing importance of technology within the hedge fund industry ingeneral—along with recognizing the particular gap there is in tools to analyze this new asset class. Source(AutonomousNext [2017]).
29
Draft v1.4
4.3 Blockchain Terminal Application Categories
The BCT will provide support for three different types of application architecture:
1. Contained applications – executed in the runtime scope of BCT hardware andits local resources.
2. Metered applications – listed for subscription and use within the BCT, butnot executed in the runtime scope of the BCT and its local resource. They arehosted independent of BCT hardware, while still registered for use with local APIs.These applications will rely on BCT infrastructure for integration and for leveragedplatform components such as logging, persistence, and identity management. Meteredapplication registration, billing, and support will be managed from the BCT afterinstallation.
3. Linked applications – while displayed on the BCT store, they will not be integrated.These applications may be registered with the BCT for product placement. Whenusers select a linked application, they will be brought to a different online location.These curated applications will be promoted to BCT users.
Each application available in the BCT store will be validated, tested, and approved bythe Foundation prior to being listed for subscription.
5 ComplianceGuard – The Cornerstone BlockchainTerminal Application
Already deployed at 17 hedge funds, ComplianceGuard is a secure tool for recordingCCO logbooks. Developed using BCT contained architecture, it demonstrates the best-practice use of the BCT framework and the BCT ledger.
Functionally, ComplianceGuard is integrated with the hedge fund’s OMS/EMS torecord all transactions on the BCT ledger. ComplianceGuard provides real-time transactionmonitoring, and visibility into instances of concern for both regulatory and mandate-specific compliance. It also enables immediate remote ad hoc audits of transactional data,should compliance issues arise.
ComplianceGuard alerts are propagated from alerts generated through the pre-tradeand post-trade compliance rules specified at the OMS/EMS application.
5.1 ComplianceGuard Features
ComplianceGuard journals fund activities, propagates alerts, stores compliance alertresolutions, and facilitates audit of alert resolutions.
30
Draft v1.4
5.1.1 Journal Fund Activities and Propagate Alerts
Fund activities are collected via mechanisms established during the installation andintegration process. As transactions are processed, transaction data is committed to theBCT and hashes are placed on the BCT private ledger. Transaction data also includesalerts that are configured at the side of the OMS/EMS. These alerts are distributed toparties determined by the CCO, and may include internal staff and external constituents,including limited partners (e.g., investors, fund of fund managers, and regulators).
For the purpose of journaling against the global ledger, and to eliminate the need forthe BCT global administrator to observe the employment actions of constituent hedgefunds, BCT tokens do not use pseudonymous public keys. Journaling between the privateand global ledger is performed by a service of the Foundation that provides a connectionbetween a Foundation client and the network of a hedge fund. In this credentialed connec-tion, the BCT process reads transaction blocks from the hedge fund private ledger andwrites the hash root of those blocks to the global ledger. Confidentiality is secured as noMerkle roots associated with hedge fund private ledgers are individually identifiable nordo they reveal any proprietary information.
Journal entries are available for review by CCOs or their designees in order to addressalerts regarding irregularities or issues detected as the result of the compliance parametersconfigured in a hedge fund’s OMS/EMS system. Responses include the comments andother supporting documentation that help establish accountability for the activity that oc-curred and are subsequently journaled to the BCT private ledger using the CCO application.
5.1.2 Facilitate Audit of Transactions and Alert Resolutions
ComplianceGuard users are able to access the private and global components of theBCT ledger and, with access to transactions from that hedge fund’s private ledger, it ispossible to identify applicable hashes. An auditor is able to combine these identified hashesand scan the global ledger for the root hash. By necessity, the hash on the global ledgerwill occur with a slight delay in relation to the last private transaction hash being observed.The auditor of the global ledger simply looks for related hashes on the global ledger onthe approximate end-date of a specific fund’s transaction chain to receive verification thatall transactions have been hashed to the global ledger and that the private ledger has notbeen altered.
This audit approach preserves privacy and eliminates the need for permissions on theBCT global ledger. All parties can see public hash data of a given hedge fund, but onlyan authorized user for a specific fund can verify the integrity of that data using the dataof the private ledger.
31
Draft v1.4
Similarly, alert resolutions are posted in the transaction window as they are made andtheir hashes are captured on the hedge fund private ledger and added in the calculatedhash to the global ledger. In this way, all CCO logbook actions can be verified as havingbeen made in the period.
5.2 ComplianceGuard Integration
ComplianceGuard is pre-installed on BCT devices and works in a standalone orAPI-integrated mode. In standalone mode, CCOs or their designees are responsible foruploading transactions to the ComplianceGuard application. BCT vendors and integra-tors are available to facilitate direct integration with transaction processing and reportgenerating systems of hedge fund users.
Through the example of ComplianceGuard, the Foundation encourages the develop-ment of a broad community of application developers. Additional specifications of BCTarchitecture are detailed in Appendix A.
5.3 Blockchain Terminal Development Environment
The BCT application development environment will be available for permissioned useraccess, and will provide users access to a “sandbox” environment in which to upload code,manage supporting components and configuration, package applications for considerationand submission to the Foundation, and provide supporting information for marketing andprice.
Developers who are satisfied with the execution of their code in their local developmentenvironment may package and share applications with BCT systems on their local network.
To make a BCT application available to users outside their firm, it must first besubmitted to the Foundation for approval. The staff and the community will evaluatesubmissions for correctness and compatibility. A robust workflow facilitates the applicationsubmission and developer interaction process. Issues can be tracked and managed, andcomments and feedback are shared between the developer and the BCT staff. When allidentified issues are addressed, the submitted application can be released for general accessor subscription in the broader BCT community.
5.4 Blockchain Terminal Community
Preferred integration and development partners are identified that can assist, augment,or develop on behalf of interested parties. The Foundation actively supports the BCT
32
Draft v1.4
development community with information, tutorials, meet-ups, and online venues for inter-action with both new and experienced members, and also sponsors meetings, committees,and events.
5.5 Future Developer Value
The open BCT community process for capturing, sharing, vetting, prioritizing, andperforming platform improvements will contribute to the rapid and ongoing evolution ofBCT as a platform. Every new application deployed provides an opportunity to engageand understand the value of shared features that will support the users, extend to newapplications and markets, and be helpful for the developer community as a whole.
6 The BCT Token Allocation and UseWith BCT hardware running in seventeen hedge funds that have approximately US$1.8
billion in assets under management provides access to the industry and creates theopportunity to validate the market and provide immediate utility to the BCT token.
33
Draft v1.4
Figure 5: Simplified token lifecycle showing its many different stages and relevant constituents. Notethat the public ERC20 token is bound in its complete utility to the BCT network and has the sole purposeof representing entitlement to services provided using the native BCT Token. Source, CGBlockchain,2018.
34
Draft v1.4
6.1 Token Allocation
The Foundation will accrue balances of tokens through the normal course of use of theBCTs in the form of fees and commissions associated with the use of applications on theplatform. Balances will be allocated against Foundation goals for the BCT and associatedpriorities. The volume of tokens distributed to the constituents, total supply, time-line,use of proceeds, conditions of release, and milestones will be forthcoming.
6.2 BCT Token Utility
The BCT token can be used to:
• Request or commit domain objects and ontologies to the BCT ledger.
• Request or commit a PoE to the BCT Ledger.
• Access applications on the BCT platform (in the capacity of either one-time use orsubscription).
• Enable core services of the BCT platform and capture fees and commissions for theFoundation.
6.2.1 BCT as a Unique Token for the Hedge Fund Industry
The BCT token is built on a foundational understanding of the compliance nuances towhich hedge funds must adhere. These stringent regulatory requirements impose significantconstraints when choosing a technology provider to deal with sensitive data.
The BCT team and the Foundation are uniquely qualified as trusted partners. Thisdistinction is recognized by compliance officers, and has made BCT the only trustedoption for the hedge fund industry. This trust, which comes from decades of experiencein top positions of respected financial services firms, bridges the chasm between thecryptocurrency community and the hedge fund industry in a way that no other group ispositioned to accomplish.
6.2.2 Subscription and Use of Third Party Apps
Subscriptions to use applications on the BCT will be denominated in BCT tokens.In some cases, applications in the BCT may have undergone an ICO or have a nativetoken and may additionally require their own token for the provision of service. Users ofthe BCT terminal will be responsible for acquiring necessary application-native tokens.Subscription or service transactions in native BCT token may incur a fee, payable in nativeBCT token to the Foundation.
35
Draft v1.4
6.2.3 Token Commissions and Fees
No BCT tokens will be issued after the initial token generation event. Users of theBCT will incur commissions and fees payable in BCT tokens to a verifiable account ownedby the Foundation, and backed by a simplified Proof of Authority consensus. They cansubsequently be returned to circulation as part of the scheduled Phased ImplementationPlan or after a specified period of time has passed. Funds may acquire tokens throughdirect transaction with the Foundation.
7 Phased Implementation PlanPhase I – Design and initial deployment (Phase I is complete)
• Deployment of terminals loaded with a lightweight on-line version of applications forresearch and data analytics; will only be accessible using BCT tokens.
• Development of basic integrations with ComplianceGuard and third party implemen-tations.
• Candidate architecture and reference application released in the form of the Compli-anceGuard application.
• Documentation and resources released for community review.
Phase II – Engagement (Phase II is in process: post-ICO, 0-12 Months)
• Full store integration of platform applications.
• Road show introducing BCT at developer events.
• Developer support site introduction: public repositories, API documentation, exam-ples, and public communication channels.
• FinTech incubation and promotion of application developers for Blockchain Terminalplatform.
• Allocation of subsidies from the Foundation to incentivize development.
• Community involvement and open review of platform considerations for the develop-ment of a terminal-based solutions.
• Enrollment of key constituents into working groups tracked by a centralized projectmanagement office (PMO).
• All stakeholders have the opportunity to join a working group.
36
Draft v1.4
Phase III – Promotion (Phase III is ongoing: 12 months and beyond)
• Expansion of subscription and accounting features.
• Continuous improvement of the platform.
• Expansion of the BCT community.
BCT implementation scheduling may be subject to change as emergent platformpriorities, resources, and broader community involvement are considered.
37
Draft v1.4
Appendices
A The Blockchain Terminal Foundation
The BCT is both a blockchain-based solution for promoting the development of applica-tions with an embedded, standardized compliance functionality, and an ecosystem for thedevelopment and promotion of cryptocurrency assets and blockchain-based technologies.The Foundation is a Cayman Island-based entity that, together with CG Blockchain andHF Blockchain, manages advancements of the Blockchain Terminal and the adequateallocation of related funds.
Initially, the BCT global ledger network will be strongly centralized; however, itspermissioned state provides opportunities to broaden and diversify the validators on thenetwork. Qualified participants may include auditors, regulators, and service providerswho share interest in maintaining the integrity of the BCT global ledger. The Foundation,which is chartered as part of this project initiative, is responsible for the following high-levelgovernance and coordination functions for the BCT and its ledger network:
• Token generation event and token distribution – governs and initiates thetoken generation event and token distribution.
• Program development – provides support for the program and oversight for theBCT application approval process; manages the workflow associated with candidateapprovals and listings in the BCT application catalog, and conducts conferences,presentations, and meet-ups to provide vendor and developer support.
• Community organization – develops consensus and provides organization forthe BCT community by encouraging and promoting innovation and effective dis-tribution of applications and services to both traditional and emerging investmentmanagers; identifies and endorses preferred vendors and partners for the development,deployment, integration, and maintenance of BCT applications.
• Application interoperability – provides governance for domain models and on-tologies made available to the global ledger; operates and maintains object enrollmentand notary features of smart contracts on the global ledger.
• Global ledger integrity – maintains the hosting environment and configuration ofpermissioned network features including the web-root of trust for VPN connectivitywith hedge funds and provides support for information security across BCT globalledger nodes.
• Escrow service – provides subscription access to the native BCT token using thepublic ERC20 BCT token via a smart contract that locks the public BCT tokenon the public Ethereum network. An oracle observing the public escrow releases
38
Draft v1.4
native BCT Tokens in a 1:1 correspondence to the sender. The smart contract onthe BCT permissioned global ledger receives BCT native tokens and reverses thisprocess obviating any system risk associated with keeping BCT tokens allocated onthe BCT through the use of conventional hardware or software products.
B Blockchain Terminal Architecture
The architecture of the application development platform provides a framework forstandardized development and implementation that lends consistency of user experienceto applications available for the BCT. It will also enforce and constrain the behavior ofapplications hosted by BCT devices that draw data from the private and global ledgers.
B.1 Language Support
BCT applications can be authored in a number of languages. Java, Scala, Python, andJavaScript are the initially supported languages that will have API bindings.
B.2 Interface
Interface guidelines will be provided for user experience with the Blockchain Terminal.Application authors are free to use any UI framework of their choosing, although HTML5,CSS 3.0, and support for responsive device access are encouraged.
B.3 Service Tier
The Service Tier of the application environment will provide stable, managed access to:
• Manage accounts, authenticate/authorize users, set permissions for applicationfeatures, and assign user roles that use these permissions.
• Read and store data to components of the BCT ledger or the public Ethereumnetwork.
• Intercept integration feeds of the core BCT compliance application, thereby gettingnear real-time order, transaction, security, pricing, and other data integrated withBlockchain Terminal hardware.
• Create permissioned synchronous and asynchronous integrations that leverage BCT’sprivate chain for creating immutable, private ledger entries.
• Access time and DNS functionality.
• Manage scheduled tasks.
• Observe and manage application statuses.
39
Draft v1.4
B.4 Integration
Integration with data from the Blockchain Terminal devices will be supported usingthree primary modes:
1. REST/RESTful services – provide ease of integration for the purpose of inter-acting with the application environment and integrated feeds using a synchronousmechanism.
2. Publish and subscribe messaging – based on AMQP, this integration approachallows developers to define publish and subscription channels for integrating theirapplication to receive events asynchronously or in near-real time. Publish andsubscribe messaging channels can be used to create an event bus-based sharingbetween BCT metered and contained applications.
3. WebSockets protocol – allows for reactive event modeling from the BCT device.
Each integration model will use native Blockchain Terminal authentication, authorization,and logging. This provides a simple mechanism for developing robust applications andintegrating them into a compliance-vetted environment.
B.5 Persistence
BCT applications may write to components of the BCT ledger, enterprise databasefacilities, or to their own storage. Applications may also read from the BCT Ledger oraccess public blockchains, or call web services and oracles.
B.6 Security
Security on the BCT platform is defined in terms of identity management, authentica-tion, authorization, and resilience:
• Identity – The local system administrator manages user identity. BCT devicescan be integrated with one or more local identity providers on the hedge fundnetwork, including Active Directory and LDAP. By specifying the correct search keyor user credentials, the BCT API will provide authentication and authorization usingenterprise credentials. Roles defined for users in the BCT framework and API canbe written back to primary enterprise identity management systems for the purposeof a federated and full audit.
In the absence of integration to an enterprise system, the BCT environment willmaintain its own LDAP directory implementation, providing a lightweight mechanismfor user, group, permission, and role management across the BCT framework andAPI-integrated applications. This environment will be similarly queried as an LDAP
40
Draft v1.4
provider from the broader enterprise. User entries are supported as X500 namedentities, and certificates are specified as X509v3 compatible.
• Authentication – will be performed against the API using username/credentialpairings. Credentials can include passwords, public key certificates, and mobiletokens.
• Authorization – authenticated user authorization occurs against the full BCT rolebase.
• Resilience – the local LDAP provider can be backed up to a standby instancehosted on either another BCT device or separate LDAP server.
B.7 Logging and Audit
Application logging will follow standard, ISO-compliant formats with info, error,and other logging levels as part of the framework. It will include support for buildinginternal logging chains, which can be used to reconstruct application behavior, for auditingpurposes.
B.8 Monitoring and Process Management Interface
All applications running on the Blockchain Terminal device will be monitored andrestarted from a global administration console available through the Blockchain Terminal.Process Monitoring will enable system administrators to easily identify applications inuse, tokens spent by each application (to better manage budget), and extract basic logsassociated with system-events associated with their running.
SNMP8 datagrams can be trapped and integrated through the monitoring interfaceinto standard log capture tools and analyzed by network and infrastructure products.
B.9 Scheduling
The Blockchain Terminal development environment will have a scheduling interfacethat can be used by developers to schedule jobs, including reports, feeds, and emailassociated with specific application tasks. Scheduled tasks can be exposed to the time andmonitoring interfaces and can be journaled as a ComplianceGuard event to ensure tasksrun when scheduled with sensitivity to other application dependencies.
8 Simple Network Management Protocol
41
Draft v1.4
B.10 Time
The Blockchain Terminal will use a timestamp authority (TSA) server to offer a secure,reliable, time source. This feature will be available to all running applications, whetheron or off Blockchain Terminal and enables true synchronization of internally generatedblock headers and other compliance events. Timestamp authority is preferable over nativesystem time, which can fall out of sync.
B.11 Native DNS and NSLookup
The Blockchain Terminal development environment will provide native DNS andNSLookup to ensure that internal services do not hit external network servers, therebypreventing DNS-based attack vectors for hosted applications.
C BCT User Story Examples
C.1 Example 1 – Core Blockchain Terminal Functionality
BCT vendor submits application for approval – A “vendor” is a developer ortraditional application developer interested in the BCT as a distribution environment foran existing or newly developed tool.
Using the BCT framework and APIs, the vendor completes testing of the applicationin the local development environment and prepares to upload the application to a BCTdevice in the vendor’s possession. The new application is not available outside of theimmediate local network of the vendor’s device. The BCT developer administrators haveprovided a checklist of considerations that are part of the application approval process. TheFoundation has provided additional support in the form of conferences and presentationsto the developer’s local fin-tech meetup.
The vendor enters the developer sandbox environment, uploads the new applicationand is provided an IP address for local shell access to the runtime environment for theapplication. A system administrator can help with the installation of necessary tools tothis sandbox environment.
Once fully configured, vendor visits the sandbox management console that allowssubmission of the configured application to the Foundation. Additional information regard-ing the application description, supporting links, and documentation is included in thesubmission. Upon approval, vendors receive notice that the application has been postedto the BCT.
Hedge fund user browses and selects application – A hedge fund employeereceives a BCT. As part of the setup process, the hedge fund’s BCT administrator has
42
Draft v1.4
configured the device settings to integrate with the hedge fund’s enterprise active directoryserver, allowing use of the same credentials used for other systems accessed at the hedgefund. Hedge fund user roles allow browsing and subscription to applications on the BCTplatform.
Hedge fund users can browse a curated application directory and make selections froma number of categories. A global application search allows for further exploration on thebasis of basic and advanced filters that allow use of criteria such as category, description,author, price, and last update.
If a search identifies an application of interest, the user can view details about theapplication, including its description and past comments and reviews offered by otherBCT users. Prices are clearly listed for installation and monthly support, as applicable.
Because the terminal is configured as an enterprise terminal, should a hedge fund usersubscribe to an application both the hedge fund BCT administrator and a designee ofthe CCO are notified. The user is informed that the request to add the application is inprocess, and that a status notification will arrive by email.
The hedge fund BCT administrator receives CCO approval of the subscription. Bylogging into the local administrative environment it is possible to view all active users ac-counts belonging to the hedge fund and to approve the installation. The administrator canremotely install, remove, and update software on all system BCTs from this environment.
If the selected application is a BCT contained application, no integrations with othersystems or support from a BCT vendor or development partner is needed to help withthe installation. Upon approval from the administrator, the selected application is clonedfrom the BCT application registry to the user’s BCT and the application is available tofor immediate use.
C.2 Example 2 – Audit and Compliance
Hedge fund CCO views private ledger transaction log and annotates CCOlogbook – ComplianceGuard assists hedge funds in navigating the complexities of regula-tory compliance by bridging the fiduciary requirements of CCOs with the objectivity andneutrality of external auditing authorities. In order to verify transaction activities, CCOsmust view and annotate transaction logs using the BCT private ledger. The BCT platformensures that CCOs maintain transactional log records on a private ledger and then providesthe means for external auditors to validate using hashed data journaled to the global ledger.
43
Draft v1.4
For example, the manager of a hedge fund takes a number of employees and the CEOof another company out to dinner. The next day, the hedge fund’s CCO opens Compli-anceGuard’s Compliance Officer Log Book and enters all the entertainment expenses.
By entering the receipt and declaration into ComplianceGuard’s blockchain, the CCOensures that the data trail has been entered into the BCT ledger. If no alerts are generated,the CCO can be sure that external regulations and internal standards are not breachedand that the gifts to this particular CEO do not surpass a certain limit.
External auditor is notified of compliance alerts – There are three alert levelsin ComplianceGuard, the most serious of which is also sent outside the fund, promptingan external audit. The BCT tools for a retrospective review of a firm’s financial records inresponse to a compliance alert provide the oversight needed to detect (and even prevent)fraud or malfeasance. The auditor is required to document whether or not the event thattriggered the alert was determined to be an issue of Critical Accounting Matters (CAM).
For example, an algorithm used by ComplianceGuard flags a trade as having breacheda compliance issue. An alert is sent to the CCO. Since the volume of the trade was large,the issue is serious and an alert notification is also sent to the hedge fund’s auditingpartner. The auditing partner contacts the hedge fund’s CCO requesting informationabout the potential compliance breach. The BCT alert system ensures that potential forfraud is prevented.
External auditor can be granted access and use the double attestationmethod to verify the integrity of notarized data – ComplianceGuard verifies theintegrity of data in a way that is similar to the double attestation method commonlyused by external auditors. In the standard method of double attestation, an auditorassesses the authenticity of a document and then declares its authenticity by attachingthe document to the signature of the verifying personnel. The process requires submittingoriginal documents, along with copies, to authorized employees who verify and sign/stamp.
ComplianceGuard facilitates double attestation with exactitude. When an externalauditor arrives on the site, the CCO grants access to execute a function in Compliance-Guard that compares the hashes stored in the CCO’s hard drive to the hashes stored onthe ledger that the external auditor has access to.
Finding that the two sets of hashes align properly, the auditor can be certain thatthe hedge fund’s private ledger transaction log data is valid. The auditor is then able toproceed with confidence that the fund’s data has not been tampered with or altered.
44
Draft v1.4
ReferencesAite. Is blockchain a good fit?: A disciplined approachin post-trade, 2017. URL https://aitegroup.com/report/blockchain-good-fit-disciplined-approach-post-trade.
Nicolai Andersen. Blockchain technology: A game changer in accounting?,2016. URL https://www2.deloitte.com/content/dam/Deloitte/de/Documents/Innovation/Blockchain_A%20game-changer%20in%20accounting.pdf.
Manuel Araoz. Proof of existence, 2013. URL https://proofofexistence.com/.
AutonomousNext. Crypto fund list segmentation, 2017. URL https://next.autonomous.com/cryptofundlist.
BarclayHedge. Fundmanagersurvey, 2017. URL https://www.barclayhedge.com/research/hedge-fund-manager-survey/2017/2017-10a.html?btg_trk=BH-HOMEPAGE.
Tom Brown. Real use cases for blockchain and distributed ledger technologies in the assetmanagement sector, 2017. URL https://assets.kpmg.com/content/dam/kpmg/xx/pdf/2017/07/blockchain-brochure.pdf.
Christian Cachin. Architecture of the hyperledger blockchain fabric, 2016. URL https://www.zurich.ibm.com/dccl/papers/cachin_dccl.pdf.
Miguel Castro, Barbara Liskov, et al. Practical byzantine fault tolerance. In OSDI,volume 99, pages 173–186, 1999.
CME-Group. Cme clearport api - fixml message specification, 2017. URLhttps://www.cmegroup.com/confluence/display/EPICSANDBOX/CME+ClearPort+API+-+FIXML+Message+Specification.
Crawford and Meadows. Blockchain technology as a platform for dig-itization, 2017. URL http://www.ey.com/Publication/vwLUAssets/EY-blockchain-technology-as-a-platform-for-digitization/$FILE/EY-blockchain-technology-as-a-platform-for-digitization.pdf.
Peter Czaban. Proof-of-authority chains, 2017. URL https://github.com/paritytech/parity/wiki/Proof-of-Authority-Chains.
Diemers and Koster. Five propositions to transform the financial services sector, 2016. URLhttps://www.pwc.ch/en/publications/2016/tp_blockchain_5_theses_en.pdf.
FpML. Financial products markup language, 2015. URL http://www.fpml.org/.
45
Draft v1.4
Matthew Green. Zero knowledge proofs: An illustrated primer.,2014. URL https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/.
Matthew Green. Zero knowledge proofs: An illustrated primer part 2.,2017. URL https://blog.cryptographyengineering.com/2017/01/21/zero-knowledge-proofs-an-illustrated-primer-part-2/.
Mike Hearn. Corda: A distributed ledger, 2016. URL https://docs.corda.net/_static/corda-technical-whitepaper.pdf.
Kaal. Blockchain innovation for private investment funds, 2017. URL https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2998033.
R.C Merkle. Protocols for public key cryptosystems. In Proc. 1980 Symposium on Securityand Privacy, IEEE Computer Society, pages 122–133. IEEE Computer Society, 1980.
S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. URL https://bitcoin.org/bitcoin.pdf.
Thompson and Associates. Technology solutions for hedge funds, 2010. URL http://www.thompson-and-associates.com/end-to-end.htm.
46
