Libra Crypto Office, a primer

In advance of the Super Bowl of Blockchain — Consensus 2018 — I wanted to write a short primer for those who might not know Libra all that well. Below I describe a bit about the three layers of the Libra Crypto Office platform and the thinking that underpins each layer. If you’re an enterprise with lots of crypto transactions and looking to convert that data into audit-ready information and reporting, feel free to swing by kiosk #40 at Consensus for a demo! Note: the platform is in production, we have lots of paying customers and we’re processing millions and millions of transactions a month. Come check it out!

Layer One. “Connectivity as a Service”

Core to our business model is the thesis that rather than every enterprise building and maintaining the on and off ramps to the crypto ecosystem, this should be a service for which any enterprise can subscribe.

Consider, every week we see at least one new crypto exchange and that’s accelerating thanks to “exchange-in-a-box” software providers — and that doesn’t even consider all the new decentralized exchanges coming online (i.e. AirSwap, EverMarkets etc.).

Further, as of last week there were ~135 active crypto exchanges, hundreds of public and private blockchains to connect to…at least 50 banks in crypto…50 wallets with some level of traction…and of course the ever-growing number of OTC providers that want to drop you files. The *weekly* growth across all of these data venues is absolutely staggering.

Seriously, can individual enterprises really build up and maintain ecosystem connectivity with any level quality and consistency?

To solve for this issue, Libra has built (and continues to build) an institutional-grade post-trade connectivity service led by an engineering team made up of professionals who have designed and deployed this exact type of infrastructure for the biggest financial institutions in the world. Reducing the initial and ongoing cost and complexity of connectivity is one of our core value propositions.

Layer Two. “Data Management as a Service”

The next layer up in the stack automates the normalization of crypto data. Look, distributed and decentralized data is expensive to manage. Not just to find, but also to extract and then bring into the form and format required to execute downstream computational and processing tasks.

Because no one can tell data venues the naming conventions of any crypto data element (i.e. name, ticker, pair etc.) the ecosystem is rife with data duplicates, errors and omissions. After you’re done reading this piece, click here to read our last blog on this topic which includes a couple examples and high-level industry statistics.

So, considering all the data inconsistencies, how does an enterprise consistently and economically manage the reconciliation processes required to create audit-ready management reporting?

Libra solves for this issue in two ways. First, by creating our Libra Reference Data service which provides a universal taxonomy for our data management layer. As transactions are executed and continuously brought into our system, all data elements are evaluated relative to our existing data mappings. To the extent the element has been previously mapped, it’s normalized to the appropriate identifier and made available for processing. If the data element is brand spanking new, or if there’s any sort of discrepancy, it’s flagged for further evaluation and classification.

Second, we’ve implemented enterprise-grade software practices to extract and test data on an ongoing basis. For example, we automatically capture/retry in case of messaging failure. We hold data at multiple checkpoints, in fault tolerant storage, with full auditing and encryption in transit and at rest. Finally, we automate the handling of invalid data and exchange API timeouts, periods of data unavailability, as well as the subsequent management of out-of-order transactions to satisfy audit requirements for prior period P&L revisions.

As the permutations of crypto assets accelerate and the venues where an enterprise can transact diversifies, having automated data management processes and common taxonomies — including the ability to spot and quickly communicate updates to risk managers — is critical. Libra provides this service today, based on the millions of transactions that cross our platform, and we look forward to making this data available to front office systems.

Layer Three. “Business Process Modules”

At this point, the data is clean and for some customers we now export it, via API, to downstream systems (i.e. Advent Geneva etc.). However, for many customers we take the data and move it into our modules for processing. For example, customers use our accounting module, which executes the matching of the gains and losses, to create trade-level P&L’s — at a consolidated and very shortly sub-account level.

For this layer, essentially we provide modules to automate business processes that are either brand new to crypto (OTC Crypto Trade Reconciliation) or are just different enough that existing software or practice doesn’t really get the job done (Balance Management).

Currently, we organize our modules across the following functions and customers should expect additional modules and deeper capability per module as business process requirements mature: Business, Operations and Finance.

There you have it, a primer on the Libra Crypto Office platform. If you’re an enterprise — the platform is not directly available to individuals yet — looking to grow your crypto business and require a middle and back office software and data services to help you transform your crypto transactions to audit-ready information and reporting, please give us a look at www.libra.tech or drop me a note at [email protected].