The Two Sides of Custody Services and Distributed Technologies

In this article, Solution Architect Virendrasinh Gohil and Business Integration Architect Paul Lashmet explore two types of distributed technologies and the fit-for-purpose of each to external and internal facing business scenarios of custody services in the financial services industry.

This post first appeared in TabbForum

Custody in Context

The primary role of the custodian bank is asset protection. This includes safe keeping of physical assets, protecting virtual assets, shielding against fraudulent transactions, protection against credit defaults, and satisfying all regional regulatory reporting requirements. They are also responsible for servicing those assets by rendering regular financial valuations, applying corporate events and actions, paying taxes, and covering other administrative obligations.

When the custody of assets are transferred from one party to another as part of a trade, it is the custodian’s responsibility to keep track of the proper exchange of monies and assets through a ledger called a Custodian Book of Record (CBOR). All CBORs across all transferring parties must be reconciled and matched against the records held by the depositories (e.g.: Central Securities Depository, International Central Securities Depository, etc.). One out of sync CBOR assumes that a party failed to deliver the promised security or cash within a specific time frame (i.e.: the trade fails).

The European Union's Central Securities Depository Regulation (CSDR) codifies this in a provision called “settlement discipline”. If there is a failure in settlement, then cash penalties are levied across the participating parties. The reconciliation of CBORs helps to identify who is at fault, which is especially difficult when there are multiple parties within a given train of transactions.[1]

Multifaceted Business Dynamics

The custodian operates within a complex ecosystem of market participants and needs to rely on and execute a number of complex and inter-dependent services. These services include safekeeping, clearing, settlement, asset servicing, account and ledger maintenance, foreign exchange (FX) trading, collateral management, etc. The market participants who provide and support these services are also varied - there are some who provide a number of these as bundled products and there are others who provide and support specific services as specialized offerings. For example, proxy voting and corporate events processing are two services which are offered by many participants as specialized offerings.

Changes in market dynamics, technological advances, and a new generation of service providers have provided the clients of custodians more leeway in the construction of their end-to-end business models. They have done so by mixing and matching blocks of services that are sourced from a variety of incumbent service providers, business disruptors, and new in-house solutions.

In response, custodians, which often reside as a single line of business (LOB) under a group umbrella, have enriched their traditional custody business models with the financial expertise that their sibling LOBs bring to the table as a way to keep as much business “in-house” as possible. For example, cross border asset transfers provide an opportunity to bake FX and cash settlement services into custody provisions for additional revenue. Similarly, fund and asset managers investing in foreign funds and assets need the support of the right mix of global and direct (local and regional) custody.

Clients are looking for the best mix of services that will benefit their end-to-end regional and global business models. This means that the custodians must provide the right mix of services to get the biggest share of a client’s business as possible.

The External and Internal Faces of Custody Services

Custodians strike a fine balance between their primary role of (i) asset protection and (ii) providing new integrated services that help secure additional business on those assets. The former fronts a complex ecosystem of external parties while the latter is a customer centric and cross functional collaboration between internal LOBs.

What both scenarios have in common are the basic aims of distributed technology: to support a lot of people providing or consuming multiple services through a myriad of systems across many locations. However, a distributed technology platform that fits one scenario may not fit the purpose of the other.

Below we describe two types of distributed technologies and the fit each has with the external and internal facing requirements of custody services:

  1. Distributed Ledger Technology (DLT) to address external facing requirements; and

  2. Distributed cache to satisfy internal facing multifaceted business dynamics.

Tech Glitch Trade Fails

According to the European Securities and Markets Authority (ESMA), the six month moving average of failed trades between June 2017 through 2019 was about 3% of value of trades in the bond market and 6% in the equity markets.[2] For the bond market, that adds up to about $136B alone[3], and it’s been reported that big investment banks have to each deal with about 10,000 failed trades every day, which are as likely to be caused by tech glitches or paperwork problems as a default.[4]

There are a myriad of ways that CBORs get out of sync and tens of thousands of trades fail. One party might have a hiccup in a trade feed, another party might manually mis-key a trade amendment, or another party’s disaster recovery center may not have replicated data properly during an outage. “Tech glitch” trade failures like these are introduced when data is independently maintained by participating parties. DLT along with Smart Contracts mitigates those scenarios.

DLT and Smart Contracts

DLT, for the purposes of this post, is a collection of electronic ledgers (software programs) that are distributed as nodes across a network of participants with data updates managed by Smart Contracts. Smart Contracts are programs that are persisted throughout the DLT that, based on agreement between all participating financial institutions, determine which nodes can perform what transactions throughout the life cycle of a trade.

Once an action takes place, all nodes simultaneously interact with each other to create non-editable (immutable) chains of records. In this way, the electronic ledgers (or CBORs) of all participating parties are kept in sync, so the “tech glitch” scenarios described above would not occur. An example of DLT in this space is the planned replacement of the Clearing House Electronic Subregister System (CHESS) with DLT by the Australian Securities Exchange (ASX).

The purpose of DLT, for this post, is to mitigate data mismatches between CBORs across a complex ecosystem of external parties. In that case, immutability is a critical fit-for-purpose feature of DLT because it secures and protects the data that is shared across an open network (the Internet) against malicious and erroneous amendments.

However, when applied within a single organization, the immutability of DLT adds unnecessary processing overhead (latency) because the data security and governance of internal networks are already addressed. The internal facing requirements of a modern custody business model is an on-demand customer experience play that requires events to be executed in microseconds which is better addressed by distributed cache.

Success Equals Positive Customer Experience

Custodians bake in a variety of financial services into their custody offerings, including account operations, FX, securities lending, collateral management, clearing, settlement, asset servicing etc. to provide a one-stop shopping experience to their clients. The success of this modern custody business model is dependent on a seamless, accurate, immediate, and positive client experience and therefore, custodian time is no longer measured in days but in microseconds. If a delayed FX transaction negatively affects a client, not only is the client not satisfied, the custodian is not acting in the best interest of the investor.

Providing a seamless, immediate, and positive client experience requires on-demand delivery of high quality real-time data. This is a challenge because disparate platforms are not natively interoperable, causing delays. The data architecture employed by each LOB may address their unique requirements but they were not designed to address the cross functional nature of collaborative business models. Centrally managed data services and repositories that are shared across businesses addresses the interoperability issue but it doesn’t address on-demand real-time data requirements due to network latency and processing limitations of traditional databases. Those requirements can be addressed with distributed cache.

Distributed Cache and APIs

Cache is Random Access Memory (RAM) data storage and is located where an application processes data (like a CPU). As opposed to connecting to the physical data storage of a database, the locality of cache makes it the fastest way for an application to read and write data. The downside is that cache doesn’t have the data storage capacity of databases, so high data volume requirements are not always fully addressed. Distributed cache, however, meets the low latency, high throughput, and data volume requirements of modern custody business models.

Distributed cache is a system that pools together the RAM of multiple networked computers into a single data cache and grows beyond the memory limits of a single machine by linking together multiple machines for higher capacity and increased processing power. APIs are used to segregate the complexity of data extraction. They enable the output to be customized based on the requesting system and ensure that only valid consumers can access the data based on entitlements. APIs act like data pipes that are extended to each requesting system, supplying data on demand and in near real time.

This distributed technology paradigm suffices the on-demand nature of internal facing multifaceted business dynamics.

Continue the Conversation

There are a number of other technology architectures that could be applied to the internal and external facing custody services scenarios described above. It comes down to each organization to determine what works best for them. The purpose of this post is to describe two types of fit-for-purpose distributed technologies, using custody services as a business example. But the pros and cons of DLT and distributed cache and the variety of use cases to which they can be applied is much more than can be written about here.

We selected custody services because the related business model has changed so dramatically in the past few years and continues to do so. We explained how DLT addresses the external facing aspects of the custody business, bringing order to a complex ecosystem of external parties and how distributed cache enables on-demand customer centric cross functional collaboration between internal LOBs.

The fit-for-purpose application of distinct technology paradigms to diverse business models is a fascinating subject especially when stories start to overlap into a complex matrix of use cases. Feel free to reach out to either or both of us to build on this conversation.

Authors' Note:

Footnotes

[1] Brown Brothers Harriman. “CSDR: Failure Will Soon Come at a Cost” January 2020.

[2] European Securities and Markets Authority. ESMA Report on Trends, Risks and Vulnerabilities (2019)

[3] DealLogic. “International European DCM Volume Q4 2019” $136B derived as 3% of deal value between 3Q 2017 and 3Q 2019

[4] FT.com “Traders across Europe face up to the cost of failed trades” (January 2020)

•  •  •

Virendrasinh Gohil is a Solution and Technology Architect in global banking with strong domain expertise in investment/corporate banking and securities services. He has solved a number of complex trading and settlement challenges with comprehensive low latency and high throughput technology solutions that are fit-for-purpose as well as innovative. He leads innovation groups within one of the world's largest multinational banks and has incubated the adoption of Distributed Ledger Technologies, machine learning, as well as other cutting edge technology paradigms.

Paul Lashmet is a business integration architect with expertise in orchestrating global strategic programs across the financial business landscape. His company, North Castle Integration, creates opportunities for business integration, optimization, and new revenue streams by matching business challenges with fit for purpose innovative technologies in artificial intelligence and data integration.