V15-028 Blockchain: Saved by The Enterprise

Distributed Ledger Technology: Saved by the Enterprise | July 2017
Blockchain:
Saved by the Enterprise
V15:028
July 2017
www.tabbgroup.com
2017 The TABB Group, LLC. All Rights Reserved. May not be reproduced by any means without express permission | 1
Introduction
Blockchain, otherwise known in capital markets as Distributed ledger technology (DLT) could potentially change the most funda-
mental underpinnings of capital markets: the transaction. DLT provides much needed functionality by embedding processing logic
directly into contracts, decentralizing the trust needed for smooth risk transference, and bringing consensus-driven verification to
transactions.
DLT will have a tremendous positive impact on operational efficiency and cost overheads. DLT will also enable workflows to be
created that will transform virtually all economic activity. However, standards and protocols are still being defined. Reference archi-
tectures are being contemplated and undergoing many rigorous proofs of concept. And there are now numerous production level
projects under way to bring the benefits of DLT to capital markets. Significant challenges remain given the complex technological
ecosystem that is at the core of capital markets. For DLT to transform this ecosystem it will need to operate within that ecosystem.
The capital markets industry has an incredibly high governance and oversight burden. It is not enough for a technology to be revolu-
tionary; it must be stable, reliable, and resilient as well. DLT is rapidly evolving and improving every day. It is being driven forward at
a rapid pace found more in Silicon Valley than on Wall Street, which is a refreshing change in an industry that is often slow to adopt
new technological trends (see cloud computing). However, for capital markets to fully embrace the technology, DLT providers need
to also embrace enterprise technology technology and data resources that are available and shared across an enterprise, creat-
ing an ecosystem of functionality. An enterprise being defined at minimal as an entire company or across a technology ecosystem
such as capital markets. Traditional databases, data processing pipelines, and their surrounding operational infrastructure will
bring a much-needed systems integration and stability to DLT and give it the operational resiliency and surety of operation that can
allow for the rapid adoption that the industry craves.
We interviewed senior executives in capital markets responsible for DLT initiatives and DLT providers to explore DLTs current and
future place in finance. This provided a view into an industry juggling the risk of disruptive innovation with a legacy of rigorous
operational requirements, but also an industry that recognizes the clear benefits that DLT will bring to capital markets and other
economic workflows.
Use Cases
The opportunities for blockchain to transform workflow across all economic activity is tremendous and thus the number of use cases
to be considered is virtually endless. Capital markets however, is focusing on a number of use cases to explore to identify where to
begin to see benefit from the technology. We have seen some largely manual workflows such as syndicated finance focused upon
as a near greenfield opportunity for proof of concept. Given this space is largely manual there are not high system demands in
terms of data nor integration and its a good place to obtain a win.
More complex use cases however are in focus because that is where the real value resides. Lets list a few:
Use Cases Description

Reporting and Reconciliation This use case is perhaps the largest opportunity area for DLT. DLT
will essentially eliminate the need for reconciliation as there will need
to be consensus or validation of the trade at the time of execution.
Billions of dollars in post trade processing costs could be eliminated.
Financial Instruments as Smart Contracts A derivatives contract could be constructed and then coded to
enable automatic payment, clearing and settlement. All contractual
terms could be pre-programmed. Terms such as quantity, quality,
delivery, etc. Price would be obtained from a market data feed via
an oracle. And on and on all automatically managed by the terms
coded within the smart contract.
Reference Data Management Reference data management is a complex and still significantly man-
Corporate Action Issuance ual task. Corporate action issuance via DLT will enable a database
of record of data changes and then automatically update reference
data databases via a smart contract, resulting in more accurate
reference data and significant cost savings.
Account transfers including tracking activity in customer accounts Automated account maintenance via smart contracts tied to DLT
and margin accounts managed trading activity.
Tracking supply provenance in physical markets Example: CME trading digitalized precious metals from the Royal
Mint, using DLT.
And many, many, more. Each of the use cases above could fill a full research report and this is a very partial list.
A beneficial aspect to any use case however is that the data within the chain will become data of record due to that data being
validated or agreed with a consensus mechanism at the time of the transaction. Therefore, there should be significant benefit to the
audit-ability and lineage of all data that comes from DLT. Virtually every firm struggles with issues associated with data audit and
lineage and the growth of DLT will have a tremendous positive impact.
As the use cases become more impactful there then becomes materially data and integration challenges to enable those use cases
to come into being.
DLT and Enterprise Tech:

A Necessary Marriage
Two fundamental realities of DLT that are pervasive throughout capital markets include:
1. DLTs core value propositions of standardized, automated transaction workflows and real-time,
consensus-drive validation of transactions could radically transform capital markets.
2. DLTs are not yet enterprise ready for high demand use cases.
To launch as rapidly as possible from idea to product, DLTs have been developed in a vacuum. They are currently missing enter-
prise necessities such as the scheduling, resiliency, failover, extract transform and load (ETL), integration fabrics, and operational
controls that capital markets CIOs require for production systems. Simply developing the first release of these features let alone
getting them to the needed state of maturity could take years.
Distributed ledger platforms did not evolve from the world of enterprise. The companies that are creating them are lean-and-mean
startups where the focus has been on getting to production and the race Distributed ledger platforms have started away from the
to traction. The most senior of these companies have but a few years of enterprise so there is no notion of working with a scheduler or
platform life under their belts. The industry is too young for maturity to be real-time interactions with reference databases or with report-
a possibility, so the platforms that exist are missing the tooling and sur- ing systems. All of this doesnt exist.
rounding ecosystems to properly integrate into capital markets enterprise Chief Architect of a major market utility
systems.
Capital markets firms wanting to extract value from DLT now are now contemplating a pressing question:
What is the best way to take DLT from proof of promise to enterprise-grade delivery?
There are three possible paths firms can take:

1. Wait for the DLT providers to bring enterprise readiness to their own products
2. Perform the heavily lifting of integrating DLT into their enterprise infrastructures themselves
3. Enable long-established providers of enterprise technology to unlock the potential of DLT
Firms could wait for the DLT providers themselves to deliver an enterprise-grade solution, but there is a challenge of prioritization
as those providers must first focus on development of the DLT value propositions. Many DLT providers have a great deal of work to
do on their core technology, so it could be a while before they are able to focus on the needed downstream integrations. Of the pro-
viders we interviewed, a number of DLT providers recognized the need for an enterprise grade solution, however, only one appears
to be taking an enterprise technology approach to the development of a distributed ledger environment. Although this companys
focus on an enterprise-grade system was refreshing, one provider is not enough to counter an industry trend. Capital markets firms
cannot wait the length of time required for this option. They fear missing the boat of achieving the benefits of DLT, but are more
apprehensive about going live on a distributed ledger platform that is not properly integrated in their environment. The former risks
the future of their business; the latter opens them to an untenable level of operational and regulatory risk. Maturity will need to be
value additive that is sourced from other technologies.
Capital markets firms themselves could do this work as they have in the past, but most firms presently do not have the expertise,
resources, or capital to do such a heavy lift. The lack of resources is exacerbated by the recent deep cuts of staff, talent, and budget
across technology within capital markets. The strong, recent trend of outsourcing technology whenever possible has left firms that
once had great expertise in rapid integrations in need of a solution from outside their walls. Thus, we see a number of consortium
and opensource efforts established to not only develop DLT but to also work on the needed, associated enterprise requirements.
Hyperledger, R3 and Ethereum are seen as the primary focus of consortium/opensource work. While these groups are feverishly
working on use cases and proofs of concept along with production deployments, and it should be noted those efforts are making
real progress, that work is not done with an eye to replace the entirety of the rest of the enterprise technology stack within capital
markets. In numerous instances the work being done is to integrate to existing enterprise services which is critical to the success of
DLT. Existing enterprise technologies are now seen as accelerators to enable DLT to happen.
Enterprise Technology Platforms

Come to the Rescue
The most realistic option is for the tried-and-true traditional providers of enterprise technology to not only enter the DLT ecosystem,
but to also become the core enabling technology structure to unlock the potential of DLT. These firms are known entities already
trusted across many industries for their ability to design, build, and manage shared IT infrastructure. And they have hundreds to
thousands of deployments across capital markets, with inroads in nearly every firm and department.
These enterprise offerings bring more than their reputation they also bring their platforms. Traditional relational databases, big
data storage systems, real-time analytics systems, distributed job schedulers/managers, and business intelligence platforms are all
needed to bridge the divide between DLTs entrepreneurial innovation and the customer bases demand for robust infrastructure.
These enterprise technology companies will offer DLT the stability, interoperability, and operational support that the space is
currently lacking. Current DLT providers can be left to what they do best:
The interesting question is when do large database vendors start to
providing the next generation of distributed ledgers that could revolution-
move up the stack like they have in other places, so that they can be in
a position to win network opportunities that drive demand for storage
ize a multi-billion dollar market. And the big, enterprise technology firms
and data management systems. can use their suite of trusted platforms to ensure that the ensuing disrup-
Founder and CEO, DLT provider tion is a positive force for change rather than a more operational risk than
the market can currently handle.
Integration:
The Once and Future King
The capital markets industry is complex with layers upon layers of transaction-based workflows that must synchronize to deliver the
overall value proposition. Integration has always been and always will be the king of business and technology concerns within cap-
ital markets. Over the past five years or so there has been big data adoption in capital markets to remove data silos and integrate
many varied data sources in order to improve both oversight and alpha generation.
DLT is new. It is innovative and disruptive, with the potential to replace many of the systems and integrations that are currently have
in place. In fact, some envision that in the future every transaction, whether what is being exchanged is risk, data, or physical com-
modities, will be represented on chain and managed in distributed ledgers.
Although DLT can powerfully transform each workflow, it also reduces the existing complexity of interconnected workflows. If every
transactional workflow was replaced with a DLT tomorrow, there would still be a need for the resulting DLTs to interact with each
other and with the surrounding ecosystem of capital markets. And not all legacy workflows are all being replaced tomorrow, or this
year, or perhaps even this decade. DLT is going to have to interact nicely with existing systems for years to come if not for eternity.
These integrations and co-existence of DLTs and legacy workflows is a series of interconnected integration challenges. In exploring
these integration issues, it is clear that the careful, tailored application of existing enterprise technology platforms is the best way to
rise to meet the challenges at hand.
The Reality of Many Chains

The ecosystem of capital markets is not one that lends itself to a single chain. Different products, asset classes, and geographies are
the most obvious causes of different chains. However, there are other drivers, such as distributed ledgers being created specifically
for different partnerships or consortiums.
Furthermore, it is not just the trading of financial instruments that are managed by a distributed ledger; it is any financial transac-
tion. This means that each new type of transaction could have a different chain, even if the asset tracked in the chain is the same, or
at least fungible. This of course means there isnt going to be only one chain provider. (See Exhibit 1).
Take, for example Exhibit 1 above, the theoretical life of a US Treasury 10 Year Note. One day, the 10 Year could be traded on a
distributed ledger rather than in a central limit order book or via phone brokers. So, a firm could buy a 10 Year Note on ledger #1.
The firm now has the bond in its inventory and a week later can put up the bond as capital with its clearing firm in order to trade
more foreign exchange by example. Distributed ledgers can also be used to track the transactions surrounding putting up capital
for margin, so now the same 10 Year Note is represented in a new ledger, #2. Although the firm is trading in and out of the foreign
exchange, there could be a need to increase capital, and if the trading is not lucrative, the clearing firm might have to sell the 10
Year Note that was put up for capital to pay for losses in foreign exchange trading. Now, chain #1 needs to indicate a change in
ownership of the 10 Year Note and chain #2 needs to indicate that it is no longer available as posted capital.
Chains #1 and #2, as well as any other chain that ends up being part of the overall workflow must be coordinated. And this collabo-
ration may even need to coordinate across different ledger technologies from different providers.
There will be a need to retire assets from one chain and create new assets in another. There will also be a need to link chains to-
gether so that multiple chains can be tied together to show provenance. At the very least, firms will need to be able to look across
multiple distributed ledgers to get a desk, division, and firm-wide view of assets held. Clearing firms and regulators will need to do
something similar, but across multiple ledgers and multiple customer firms.
Coordinating these many chains, and the associated meta-data, is a data management and analysis problem that can be solved
with the proper applications of existing enterprise ETL systems and business analysis platforms. These systems are already integrat-
ing the many layered and intertwined workflows within capital markets and they can continue to be leveraged as distributed ledgers
replace these workflows.
ETL must be leveraged to bring the salient information from each chain into a centralized analysis and reporting platform. Each
block in every ledger needs to be mapped to internal stores of metadata in order for the transactions to have the richness of infor-
mation needed to properly manage them.
Tracking provenance, cause, and resulting state from transaction to transaction, hoping from chain to chain, requires insight that
only comes from the data mining and repeated application of business logic that existing business analytics have spent years tailor-
ing to the needs of capital markets. Over the last few years, these business analytics platforms have made it possible to do tradition-
al online analytical processing on higher transaction volumes, which is a new feature that could greatly help managing a multitude
of constantly updating distributed ledgers.
The Data from DLTs

If the engine of distributed ledgers is data and workflow standardization, as well as transaction validation and consensus, then the
exhaust is clean data. Capital markets firms have been craving and striving for clean data around their transactions for decades.
Immediately verified, well-defined transactions lower the risk of out trades and remove a great amount of operational risk from front
offices.
DLT wont be replacing traditional databases, but The more transactions that occur on a DLT the better data a transaction participant
there are advantages of it. It is our take that people has. More good data means both less dirty data and more data in general. Data
will use enterprise databases and theyll use block-
around transactions is fantastic as it provides firms with more data to use for future
chain and theyll have to interact.
alpha generation, better insight into the markets for risk management, and the needed
Senior Executive, DLT provider
information for deeper insight into governance.
However, additional data has a downside. To use the increasing amounts of data, firms need to be able to capture, retain, and
analyze this data. And the data must be reliable because once the data is available for oversight it always needs to be available for
oversight. Transactions need to be mined and incorporated into pre-trade risk controls, live calculations for capital requirements,
research platforms for alpha generation, as well as regulatory reporting workflows.
Large scale, reliable transactional databases are already prevalent in capital markets and can be used to great effect when paired
with DLTs. Each block in the chain can be mined for the relevant, clean data and stored and/or linked to greater amounts of related
data in a database.
The resulting data from transactions must be stored and available for end of period analysis, but static representations of the data
are not the sole use. Risk analysis, oversight, and alpha generation all have real-time components and all need insight into transac-
tions as they occur. Data stores and analysis platforms that already leverage stream processing are going to be in high demand. A
necessary requirement of DLTs going live in capital market enterprises is the ability to immediately recognize, capture, and process
a new transaction in the ledger and stream the resulting data into real-time analytics. Otherwise, DLTs would be stationary in an
otherwise fast-moving industry.
Avoiding DLTs
Becoming the New Data Silos
In recent years, capital markets technology had been focused on integrating data sources, removing barriers between data sets,
and combining data stores into vast lakes. Unifying data, standardizing access, and building advanced, combined data analytics
have helped with operational efficiency, regulatory oversight, and increased alpha generation. There is still much to do, but the
focus on enterprise-wide data management has resulted in greater revenue.
Silo has now become a four-letter word in IT departments throughout capital markets. A silo means a cost inefficiency; silo means
the possibility of errant behavior going uncaught; silo means untapped potential; and it also means a CDO or a CIO is not doing
his or her job.
However, is the distributed ledger a silo to contend with? Although many DLT vendors wants to provide THE DLT solution to capital
markets, the reality is they are all competing to be one of many DLT solutions that will eventually have to be integrated if the industry
is to achieve its desired efficiencies. How will this integration occur? Can disparate chains, all similar in functionality and principal,
but different in implementation and detail work together in harmony?
Careful planning and architecture is needed to make sure that as a firm joins chains and uses them throughout its transaction
stacks that the data contained in the chains is accessible to the people, tools, and reporting systems that need insight into transac-
tions data and the metadata surrounding them.
The (Re)New(ed) Need for

Enterprise Data Management
Enterprise data management (EDM) is about having trust and confidence in your data. DLTs provide consensus-driven validation
of transaction data, which provides trust and confidence. However, distributed ledgers do not remove the need for EDM; instead,
distributed ledgers allow the focus of EDM to shift to providing much needed value to users of the trusted data.
The needs of the data found in a chain are diverse and numbered. Business analysts want to treat transactions, or clusters of
transactions as business objects. Regulatory officers must combine transactions with communication logs, market data, and other
sources to perform automated governance and oversight. Quantitative analysts need to perform repetitive, distributed research on
the transactions as time series data. Risk managers have to incorporate transactions from many ledgers and from markets without
ledgers into a global view of market risk and capital utilization. And this is just skimming the surface.
With so many different functional needs and data merging requirements for the transactions in a DLT, it does not make sense for
every workload to interact directly with the ledger. A basic API is not going
This isnt the same data store that youd want to do analytics ore
to be considered adequate. Rather, efficiency will demand that users have
reporting on. So, we can stream the data out of the platform that
access to the data they want when they want it, in the format and store can then be put in alternative data stores. And this way you can feed
that best suits their needs. different databases and data store types.
Senior Executive, DLT provider
Rather than thinking of a chain as a data source for direct interaction by
the users, firms can envision chains as a series of transactions that can
be fed into already existing data workflows. Since the chain is an immutable log of all transactions, it can be the golden index of
transactional truth that purpose-driven data stores can be built from and synchronized with in order to provide each use of the data
a custom-tailored ecosystem that best fits the users needs.
With DLT, the primary focus of EDM shifts to providing the structure and store to the transaction data for each use cases appli-
cation. Traditional, heavily used relational and transactional databases can be populated from the DLT, but also purpose-built,
more niche data stores can be used as needed. If DLTs provide easily accessible integration for ETL tools and/or are given replay
capability, EDM can focus on setting up new data stores as needed, populating them from the chain, synchronizing them as the
chain updates, and tearing down the data stores when no longer in use. The existence of data and application ecosystems become
at will allowing for the bursting of capacity and functionality while using the distributed ledger to ensure data accuracy and
completeness (see Exhibit 2, next page).
This gives software developers great freedom and should accelerate their productivity, but also puts a new burden on data man-
agement: the creation, destruction, management, and coordination of multiple parallel data stores that are all representing the
same data in different ways. More likely than not, capital market firms will be relying on their enterprise tech partners to provide the
solution to this new challenge.
Chains Are Not Databases

Although chains are immutable data stores, it is important to remember that they are not databases and should not be treated as
such. Chains are implementations of a schema, but are naturally limited in their capacity. They cannot be modified, grown, and
expanded by each user on the chain. Such modification must take place off the chain.
The rule of thumb is do not put data on chain if it does not need to be on chain. So, if the data is not needed to perform, index,
define, validate, and confirm a transaction then it is not on the chain. This is no different than current transaction messages used in
capital markets. Whether it be FIX, SWIFT, or any other protocol, the transaction message itself is missing much of the data used to
make sense of the transaction and needed for further context.
There is one primary difference, though. Transaction records currently shared in the industry are intended to be stored in each par-
ticipants data store of choice. Each participants primary data store is one that is custom tailored and integrated with the rest of the
participants systems to make it easy to join the transaction with all the surrounding data that is needed for additional context and
oversight.
DLT, however, dictates the primary data store of the transaction. To ensure that participants are referencing a valid version of each
transaction, they need to refer to the chain. The chain necessarily cannot hold all the data needed to make sense of each transac-
tion.
First, each block of the chain is constrained in size. This size can vary from chain to chain, but the amount of data each block can
hold is purposely kept small for both performance and consideration of future space needs. Chains have higher utility to the industry
if each block can be processed quickly and if they are optimized to store more transactions at the sake of storing data per transac-
tion.
Second, each participant on the chain has different data needs for every transaction. The data that is kept on chain is tiny com-
pared to the related data that each participant tracks about every transaction (see Exhibit 3).
This in turn, is compared to the data that the regulator needs to relate to the transaction. And each of the counterparties needs
a larger amount of data to add the proper context to each transaction. It would be impractical for each chain to serve all of these
different data needs. The result is that each user of a chain needs to join every transaction with, often times many different related
data sets. Querying the chain results in querying many other data types across other data stores.
To tie the necessary reference, related, and metadata to each transaction, every firm will need to manage the chains they partici-
pate on as yet another data store to be integrated into their data lakes. There is a plethora of tools that make similar integration of
traditional transactional, relational, and columnar data stores nearly trivial. Enterprise technology providers need to add DLT to the
list of integrations they empower in short order.
Innovation
from the Enterprise Providers
Enterprise technology providers will become more than the workhorses that bring acceptability to the disruptors. There will be
plenty of room for them to innovate as well. In fact, the enterprise providers that provide the most innovative products that address
the integration problems mentioned above will most likely become the industry leader in the ecosystems and tooling surrounding
the DLTs.
As the integration problems outlined above highlight, distributed ledgers enable, verify, and validate transactions. They define the
transaction workflow and the immediate, necessary transaction data. However, they do not contain all the data that is needed. In
fact, the blocks in a distributed ledger do not have the capacity to hold the data that each participant in the transaction needs. This
means each block in a distributed ledgers chain becomes a unique hash that indexes into a larger, off chain data store.
There are two primary ways that DLT providers provide connectivity from their chains into the bigger, more traditional data stores.
1. Shipping a specific database to their customers and requiring its use

2. Defining an API that their DLT will call and the participant in the DLT must implement
Although both options allow for traditional enterprise databases and the tools that surround them, TABB Group found that most
capital markets participants we spoke with preferred the second option. Furthermore, they feel that this preferred option is gaining
traction.
This is a preferred option because it allows them to leverage currently existing enterprise relationships and installed/supported plat-
forms, support multiple ledgers from multiple providers, and avoid the introduction of new data silos to their environments.
The approach of implementing a set of required functionalities and data schemas to back a distributed ledger is also a boon to the
providers of enterprise technology platforms. It allows them to enter the DLT arena in ways that service multiple customers and DLTs
without the requirement of potentially limiting partnerships.
The second option also leaves room for enterprise technology providers to innovate in ways that use DLT and blockchain to further
drive their licensing and professional services sales. The provider that makes integration between different ledgers and unchanged,
legacy workflows work the smoothest and can also bring the most value in knowledge and tools to space will be able to win over
more and more customers.
The easier it is for people to use their existing enterprise platforms to onboard DLTs the faster the entire space will grow. The result-
ing rising tide will raise the boats of enterprise technology providers and DLT startups.
Every time a new technology that drives the use of enterprise tech platforms, such as relational databases, workflow management
systems, etc. gains traction in a market, the enterprise technology providers adapt by moving down the chain of value add, creating
integrations between their existing platforms and the new technology. This allows them to realize new revenue sources as well as
expands sales of the old. It should be expected that the same will eventually happen in DLT/blockchain.
Mind the Gaps (Dont Avoid Them)

DLT is spreading rapidly through the capital markets. Its ability to decentralize trust, standardize workflows by embedding the pro-
cessing in the contracts, and bring automate consensus to transactions has the potential to enact profound change to the markets
underpinnings.
However, DLT is in its infancy. Reference architectures are still being designed, standards and protocols are just now being defined,
and proofs of concept are barely underway. The gaps that exist between DLTs current state and the dreams of its potential cus-
tomers are natural. The press coverage might heavily favor revolution, but the reality of technological change leans more heavily
toward evolution. DLT has the incredible potential to bring high value to the market, but it will only realize its potential at the pace
the market requires with the help of traditional enterprise technology.
DLT is also just one part of the change cycle in which capital markets currently finds itself. It goes hand-in-hand with big data, cloud
computing, and mobile access, but only DLT so tightly couples business logic and technology to improve the most fundamental
underpinnings of the industry: the transaction.
DLT comes complete with its entrepreneurial, start-up mindset. Its a mindset that capital markets need a healthy dose of to drive
needed change. However, the stability of enterprise has its place too. For DLT to move from infancy to maturity at the pace being
demanded by the market, the two technology stacks (and mindsets) must come together and merge the best from both worlds.
Distributed ledger technology is disruptive and forward moving, but it needs the surety, consistency, scalability, and resiliency of
enterprise technology if it is going to succeed.
Conclusion
DLTs will fundamentally revolutionize how transactions are managed in capital markets. Indeed, it will revolutionize how we think
about trading in the future. They will distribute transaction verification, bringing consensus and trust to transactions of all sorts.
Moreover, DLT will provide significant automation and integration opportunities to the markets. Thus, enabling real changes to
workflow. Workflow, that will be more reliable, faster, auditable and extensible. DLT is also a badly needed technological upgrade
to outdated, inefficient transaction-based workflows. However, the revolution will only go as far as DLT enterprise readiness will
allow. DLT does not change the fact that the capital markets are built upon the complex interoperability of layer upon layer of work-
flows.
The industry desperately needs benefits and upgrades that DLT could bring to the market, but DLT needs to be ready for the
enterprise. If capital markets are not careful in their rush to adoption, they could outpace DLT enterprise readiness, which increases
risk and turns complexity in to confusion. However, if enterprise technology providers can integrate DLT into their trusted, reliable
offerings, DLT will mature from promise to productivity in a fast, safe and effective manner, giving capital markets the benefits they
crave.
About
TABB Group
TABB Group is the international research and consulting firm focused exclusively on capital markets, founded on the inter-
view-based research methodology developed by Larry Tabb. Since 2003, TABB Group has been helping business leaders gain a
truer understanding of financial markets issues to develop actionable roadmaps and approaches to future growth. By accurately
assessing their customer base, competition, and key market opportunities, TABB Group works with senior industry leaders to make
critical decisions about their business. For more information, visit www.tabbgroup.com.
TABB Groups FinTech Research Practices

TABB Groups FinTech research practice is specifically designed to help financial institutions understand the latest spending trends,
strategies, and solutions that are critical to achieving best practices in financial services technology, data, analytics and technical
infrastructure. The practice also helps technology and data solution sales and marketing organizations understand specific require-
ments and uses cases within financial services and capital markets firms.
FinTech Team
Primary Analysts:
Terry Roche
troche@tabbgroup.com
Terry Roche is responsible for the FinTech practice at TABB Group. Prior to his current role, Roche was Chief Operating Officer at NYSE Tech-
nologies. He previously held a number of executive positions at Thomson Reuters and Reuters, including Managing Director and Global Head
of Elektron Real Time and Platform, and Global Head of Strategic Business for Focus Group Accounts. Roche also held a number of senior
positions at HSBC that included Global Head of Market Data, Head of Global Middleware, and Commercial Director for Fixed Income e-Com-
merce. Roche is an industry veteran with 30 years experience.
Terry Roche Monica Summerville Dayle Scher

Head of FinTech Research Senior Analyst Senior Analyst
troche@tabbgroup.com msummerville@tabbgroup.com dscher@tabbgroup.com
www.tabbgroup.com
New York
+ 1.646.722.7800
London
+ 44 208 133 5022

V15-028 Blockchain: Saved by The Enterprise

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

V15-028 Blockchain: Saved by The Enterprise

Uploaded by

Copyright:

Available Formats

Distributed Ledger Technology: Saved by the Enterprise | July 2017

Use Cases Description

DLT and Enterprise Tech:

There are three possible paths firms can take:

Enterprise Technology Platforms

The Reality of Many Chains

The Data from DLTs

The (Re)New(ed) Need for

Chains Are Not Databases

1. Shipping a specific database to their customers and requiring its use

Mind the Gaps (Dont Avoid Them)

TABB Groups FinTech Research Practices

Terry Roche Monica Summerville Dayle Scher

You might also like