The FUTURE OF IBOR: Leveraging blockchain as the fabric for alpha generation and investment support

  • 1349

    The FUTURE OF IBOR: Leveraging blockchain as the fabric for alpha generation and investment support

    Legacy systems can constrain an investment manager’s ability to provide a comprehensive and transparent view of the alpha process, hampering an effective response to mitigate alpha leaks. But as new technologies such as blockchain emerge, there is a significant opportunity for investment managers to refine their investment operations and enhance straight-through processing (STP). However, a number of open questions still remain on how a blockchain-based Investment Book of Record (IBOR), recording all position, transaction and non-investment data, could enhance front-office value and alpha generation. In this article, Joshua Satten and Chirag Shah examine how innovative technology can help firms redefine their investment architecture and operations to move ahead of rising competition.

    A holistic IBOR provides the foundation for investment managers to fully enhance the entire investment process for the purpose of alpha generation. In concert with alpha generation and portfolio optimization within a master IBOR architecture, investment managers must consider three core factors:

    1)  The capabilities to support required research, portfolio construction, trade execution and clearing, analytics and pricing, risk, compliance, collateral management and regulatory reporting.

    2)  The current vendor landscape offering an IBOR, combining an order management system (OMS) and IBOR products, or accounting and IBOR products (as balanced against proprietary engineering).

    3)  The integration of emergent technologies that balance cloud computing, fintech and return on investment (ROI).

    Technology integration is especially important. Any target architecture model (TAM) considering both vendor applications and emergent technologies should do so in a complementary and consecutive manner. Immersing a single firm into parallel transformation programs of future-state innovation potential, current-state front-office requirements and near-term cost-cutting endeavors can lead to “analysis paralysis,” and either distract people away from their day-to-day responsibilities or dilute and prolong an execution strategy central to a firm’s ability to operate. Meanwhile, front-office businesses are sub-optimally supported. Development occurs in a fragmented manner causing loss of time, money and opportunity.

    Figure 1

    NEW TECHNOLOGY

    Based on the nature and focus of current implementations, enhancing outdated systems can easily consume existing IBOR strategies aiming to alleviate present operational challenges and address future expected investment support. Envisioning the alpha process and its supporting infrastructure without legacy infrastructure constraints can serve as an incredibly useful construct to understand where firms should direct their focus.

    In an unconstrained scenario, the underlying foundation of an IBOR is trade- and non-trade-based position and transaction data that functions as a single source of truth across the enterprise. Multiple investment functions and front-office businesses facing different ledgers (i.e., any trade, accounting or custody books of record) would effectively collaborate through the use of a single common, interoperable ledger maintained on a near real-time basis.

    Conceptually, this behavior paints IBOR as an ideal application for a shared distributed ledger of transactions and positions. Functionally, this is where blockchain technology is increasingly applied across many other use cases.

    Similar to the premise of a distributed ledger, a blockchain’s core value is the ability to maintain an append-only book of record that, for all intents and purposes, is immutable. Here, the network (which can be public with open access or private with permissioned access) is jointly maintained, allowing participants to either agree to transactions and supporting metadata (simultaneously recorded), or dispute them on the basis of a consensus approach defined by the network’s participants. They may also choose to process and orchestrate other business events as they are published through the network by other participants based on pre-defined business logic in a “smart contract,” or code that resides on the shared ledger (updating the common database of transaction and related metadata accordingly).

    Figure 2

    Blockchain

    Blockchain-based technologies are widely positioned as the future infrastructure of financial markets. Many vendor-led consortiums are assessing the opportunities and practical implications of such technologies to traditional banking and asset issuance business models. The focus of these initiatives is primarily on post-trade settlement and simplifying the trade lifecycle. In addition, some initiatives center on the origination and operational support of more esoteric and/or less standardized financial products like private equity and syndicated loans.

    Still, blockchain could have significant value when applied to interoperable networks within a company. The potential lies in utilizing blockchain with the dual intent of: (1) establishing an optimized, fully-functioning IBOR platform; and (2) providing a foundation for enterprise digital transformation. The resulting empowerment to the alpha process, alleviation of business-as-usual (BAU) support from infrastructure technology, as well as transparency and speed of communication are a perpetually valuable combination.

    Further, the currently known potential of blockchain would best be constructed in a multi-faceted approach whereby each independently useable architectural value of blockchain is set up in specific phases.

    Figure 3

    Under this approach, a private distributed ledger–an all-encompassing distributed database that is shared across the enterprise–becomes the core of the company in general, and more specifically, the investment process. At a minimum, all transactions and events driving the creation of and updates to position data are maintained in this distributed IBOR. However, for this to occur, the organization needs to define the underlying transaction and block protocol. This would primarily include identifying the optimal symbolic representation of a transaction and establishing permissions throughout the organization.

    Each of the functional groups across business lines encompassed within the reference architecture would be participants (via internal network nodes) over a private or permissioned network that spans multiple geographies for multi-jurisdictional firms and provide dynamic views of risk, holdings and performance. These nodes would act to validate, append and add investment and non-investment data in real time. They would also be proactively launched to enable regulators, key investors and the like to access data as appropriate, thus eliminating most investor and regulatory reporting needs, as well as a vast majority of related technical, operational and compliance checks.

    Smart contract protocols would be programmed within the blockchain as captured within transaction coding to automate executed logic through the blockchain. It can be further enhanced by using a digital signature to prove who sent the message. The result is getting as close as possible to a combination of real-time information exchange, agreement and multi-ledger persistence and updates across networks. This would require evolutionary steps for documentation execution, agreement, information management and reconciliations across different asset classes and products in the capital markets. It also opens the door for future usage of robotic process automation (RPA) and meaningful machine learning.

    Figure 4

    Some other suggested guidelines for an IBOR blockchain would include:

    • Creating unique addresses for asset classes or sub-types for easier categorization
    • Ensuring transaction “smart contracts” that manage across the latest versions, transaction hashes, version chain and transaction states
    • Disallowing the creation of multiple child versions from single parents (since a distributed ledger by itself won’t solve this problem)
    • Establishing a unique ID generation mechanism outside of blockchain that can be referenced or tracked from the outside world to allow seamless integration with
      existing platforms
    Figure 5

    CONSIDERATIONS FOR USE

    How do I want to communicate with the companies I work with across business lines and data standards?

    • Log-on to specific data platforms
    • Integrate via files and messages
    • Let central utility do the data interchange, transformations and collation
    • Buy market data, distribute market data through vendors
    • Let central body, self-regulatory bodies and regulators read data
    • Build point-to-point custom integrations
    • Let operations deal with it
    • Increased scalability
    • Defined read and write permissions
    • Increase cyber-security
    • Less reconciliations and verifications

    Lastly, the theoretical future would bring with it a differentiated IBOR-distributed ledger for each financial company. The boundaries and needs would be defined by: (a) underlying business entity types, (b) investment types managed, (c) operating locations and geographies, (d) existing collective proprietary and vended system architecture, (e) data needs and (f) the desire for automation. This means the industry can create effective decentralized networks through the secure connection of these different proprietary distributed databases (i.e., a network of interoperable networks). The implication of this architecture to most currently performed reconciliations and confirmations is staggering.

    Though application is limited, a private internal enterprise-applied blockchain would likely have lower bandwidth demands on nodes related to consensus algorithms compared to public, intercompany network ledgers. Nevertheless, the criteria for adding transactions to the chain are based on a consensus that may utilize smart contract functionality. Besides mechanisms for consensually applying, accepting and appending information, open APIs would also be required to allow various functional groups to query the blockchain for transaction or position-level information.

    The underlying value

    An investment manager implementing this approach could leapfrog over the restrictions of current IBOR solutions by simplifying investment operations and directly enabling the speed, insight and transparency of their alpha process. In the context of the investment process described earlier, this approach has significant benefits as immutability and consensus-driven agreement processes drive advances in security, speed and scalability. Where transaction data can be utilized for transaction cost analysis and performance attribution, it can be done on a real-time basis while enhancing collaboration and communication between portfolio managers, traders, and performance and risk teams. Conversely, from an operational perspective, reconciliatory processes would begin to disappear. However, new transactions would only be added if firms follow the defined rules for adding and appending information or transactions to a blockchain.

    Logically fitting a blockchain within a firm’s infrastructure and correlating its optimal function require the use of other technologies (such as HTML5 container applications and machine learning) to truly innovate the core operation and functionality of an IBOR. A new paradigm is also emerging around the intersecting relationship within many asset management firms and banks on the following:

    1. New technologies

    2. Venture capital investments

    3. Operational needs

    4. The desire to differentiate investment management perceptions and investment performance growth among investors

    For example, blockchain startup deals rose for the third straight quarter in Q1 2017, according to CB Insights.1 Further, blockchain startup funding jumped from $90 million to $141 million in Q1.

    Figure 6

    CURRENT IBOR VENDOR LANDSCAPE

    While there is certainly an opportunity to take advantage of new technology in the future, many firms are currently utilizing a combination of proprietary applications and vendor packages to optimize their investment process.

    Historically, vendors developed platform-as-a-service (PaaS) and software-as-a-service (SaaS) IBOR-centric products in support of the investment process with a niche focus on specific asset classes, geographical markets, pre-trade portfolio construction and analytics, post-trade operations and accounting, or a combination of these areas. Typically, this software was developed to support a particular type of financial entity, asset class or geography, given that many were developed with a key lead client in mind, and then subsequently abandoned. Over time, the collective web of interconnected systems needed to support the investment process grows to an overwhelmingly complex and slow technical iceberg with limited utility to the front officeóthe functional area it was designed to support in the first place.

    As a result, firms that want an aggregate view of the alpha process must piece information together from a combination of such systems’ opening the door to errors and inaccuracy. The information therein can be latent, stunted, unreconciled or incomplete for front-office use. Most IBOR implementations tend to focus on simplification within middle- and back-office operations where the interaction model with the front office is still largely based on a batched flush-and-refill process that runs at the start or end of a business day.

    In-house systems

    With multiple systems in place and a reliance on position views based on accounting book of record (ABOR) and trading book of record (TBOR), information accuracy and timeliness becomes an issue, while consistent real-time, front-to-back position information remains elusive. Organizational silos, as well as product fit with traded asset classes, continue to be key drivers for the compartmentalization of such solutions. In some instances, for large asset managers in particular, that can lead to front-office optimization initiatives that aim to streamline the functionality of more than 50 operational systems on a single platform.

    The in-house development of transaction-based position management systems is an alternative trade. These platforms, which leverage cloud-based data warehouse solutions to maintain consistency and timeliness, better position firms to determine and amend alpha leaks. Achieving such architecture enables higher-value business benefits such as strategy-level P&L views, better risk reporting, enhanced collateral optimization, unified trade blotters across asset classes, consolidated broker exposures and improved performance attribution. Examples of platforms that have been industrialized and resold in the marketplace include Bank of New York’s Eagle platform, Northern Trust’s Omnium platform (first developed by Citadel Technology) and BlackRock’s Aladdin platform.

    IBOR solutions and similarly functioning, specialized products for the front office include those from vendors such as Charles River, Bloomberg, IHS Markit Thinkfolio and BlackRock’s Aladdin. Other solutions such as Murex, Misys and Calypso can provide front-to-back investment operations support with potential emphasis on areas such as OTC and structured products.

    Operational optimization is certainly a necessary first step. However, it is imperative to tie the benefits of an IBOR implementation directly to the front-office alpha process. It is also necessary to ensure the system architecture can evolve to meet future computing and data model demands. Given the state of the current IBOR implementation landscape, this presents a huge opportunity for many (even the most successful managers) to track and improve alpha generation and preservation. The goal is to retain and enable investment in their technology and operations infrastructure to directly add value to the front office.

    Firms with mature data governance and warehouse capabilities will see a more immediate advantage in executing on their target operating and architectural models. An increasingly frequent best-of-breed environment with complementary products has emerged at many of the larger global asset managers. Such an environment includes a combination of different vendors providing equity front-office support, investment compliance, fixed income front-office support, data and analytics and back-office and accounting support. This type of technical architecture can be an impediment where it introduces latency and fragmented, disjointed views of an IBOR. In such multi-vendor scenarios, firms need to keep operational risk top of mind and continually evaluate how best to enhance alpha generation.

    CONCLUSION

    Blockchain presents a huge opportunity for many, even the most successful managers, to improve alpha generation and preservation, especially where utilized as the basis for IBOR and enterprise architecture. The goal is to retain, enable and enhance value in the investment operations infrastructure and directly deliver it to the front office.

    Legacy technology constraints that have hindered transparency in the alpha process will not become constraints in the future. Over the past few years, cloud-based platforms and services have increasingly become mainstream. Artificial intelligence platforms are moving closer to maturity, while newer technologies, such as blockchain, continue to evolve in labs. Meanwhile, computing and storage costs continue to rapidly decrease, lowering the barriers for new fintech entrants to innovate and build new business models that leverage open source and emerging technologies.

    References

    1. CB Insights, (Blockcahin Startup Investment Bounces Back,) https://www.cbinsights.com/blog/blockchain-bitcoin-startup-funding/?utm_source=CB+Insights+Newsletter&utm_campaign=c7cbb00a50-MonNL_5_1_2017&utm_medium=email&utm_term=0_9dc0513989-c7cbb00a50-87759717

    The Authors
    Joshua Satten

    Joshua Satten is a Director for Sapient Global Markets’ FinTech Practice. In this role, Joshua leads business development and market strategy with specialties in fintech, OTC operations and business architecture. His fintech oversight includes areas related to robo-advisory, blockchain, machine learning and venture capital. He built his career managing and growing full lifecycle trading operations across OTC derivatives and other structured products, combining business architecture, leadership and strategic planning skills, while focusing on globally balanced, sustainable growth across the front, middle and back offices, IBOR and OMS development, fund setup, design, reconciliations, and audit and control. He is an active industry participant and speaker having participated in and chaired working groups with ISDA, ISITC and SIFMA AMF on fintech; derivative and collateral operational processes; Dodd-Frank, EMIR and MiFID II regulatory impact; and OTC clearing and operational efficiency.

    Chirag Shah

    Chirag Shah leads the FinTech Practice for Sapient Global Markets as Vice President, Technology. He brings diverse experience in startup, high-growth and turnaround environments in both the technology and financial sectors. Chirag spent more than 20 years on the buy-side leading several large cross-functional teams in building innovative business platforms. He has a deep understanding of the investment management lifecycle and has engineered trading, research and analytics platforms across all asset classes. He advises capital markets clients on strategy and technology to successfully embrace digital transformation fueled by next-generation technologies such as cloud, cognitive computing and blockchain.

    Leave a Comment