Bitcoin Derivatives Overview

Several exchanges based in or outside of the U.S. have begun to offer trading in bitcoin derivatives. TeraExchange completed the first bitcoin derivative trade on a regulated exchange in the U.S. on October 8, 2014 with its Bitcoin Non-Deliverable Forward (NDF) contracts. More recently, LedgerX has submitted applications to become the first regulated bitcoin options exchange in the U.S. Additionally, some exchanges are based outside of the U.S. but may have significant customer bases in the U.S. Bitcoin derivatives offered on these exchanges include futures, forwards, and options.

TeraExchange Non-Deliverable Forwards

TeraExchange is a CFTC-registered Swap Execution Facility (SEF) operating in the U.S. that offers a central limit order book platform to provide real-time pre-trade price transparency. The firm offers several short-term, cash-settled bitcoin forward contracts based on its proprietary bitcoin price index, called Terabit. On the settlement date of the contract, the difference between the contract price and the price as determined by the Terabit index on that particular date on the agreed notional amount is exchanged between the two counterparties.

NADEX Binary Options

The North American Derivatives Exchange, or NADEX for short, is currently offering short-term binary option contracts that are also based on TeraExchange’s Terabit bitcoin price index. In this case, a bitcoin binary option contract is simply a bet on whether the Terabit index will be above or below a certain price at a specified date and time. The contracts will always settle at either $100 or $0, and the profit or loss on the contract is the different between the amount paid for the contract and the settlement amount. NADEX is not currently registered with the CFTC and as such, these binary options contracts are not regulated at the current time.

LedgerX Options

LedgerX has more recently announced that they intend to offer fully collateralized, physically settled bitcoin options for the institutional market. Unlike NADEX, LedgerX’s platform will not become active until the CFTC has approved their application for registration as a SEF. Until then, the full terms of the firm’s bitcoin options contracts may not be known.

Publicly Disseminated Data

Rule Description

The CFTC’s Part 43 rule mandates that the SDRs disseminate certain trades to the public in near real-time. This rule applies only to the OTC swap market, however, TeraExchange’s bitcoin NDF products fall under the CFTC’s broad definition of a swap. Therefore, data pertaining to these trades are expected to be publicly disseminated. Many other products across several different asset classes also fall under the CFTC’s broad definition of swap, and we are able to analyze these data as well.

Credit and Rates Data Profiling

As a precursor to conducting any kind of analysis on the publicly disseminated data associated with the Bitcoin NDF trades executed by TeraExchange, it is first helpful to understand how other trades are generally being reported. To do this, a simple profiling script was run on a month’s worth of trades at each SDR for both the Credit and Rates asset classes. Bloomberg, CME, and the DTCC currently allows for the reporting of trades in the Credit and Rates asset classes, while ICE allows trades in the Credit asset class to be reported to their SDR but not trades in the Rates asset class. The first important data profiling metric used to better understand these trades across SDRs and asset classes is the percentage of null values in each data element in these data. In this way it can be determined which data elements are generally being populated and which data elements are not, regardless of what is or is not required by the CFTC’s Part 43 rule governing these data.

To demonstrate the results of this data profiling, I have selected a subset of the analysis for each asset class that shows the major discrepancies in how the trades are being reported across the SDRs. It can be inferred that any data elements not shown in the subsets are being consistently reported across the SDRs. These discrepancies include both how often the data elements in these data are being populated as well as the naming of the data elements. It can be stated as a generalization that each SDR routinely uses a different naming convention to represent the same data element. In some cases only a slight difference exists while in other the naming of the data elements in each SDR’s data varies widely. However, it is more insightful to focus on the population of the data elements in these data.

Beginning with the Credit asset class, there are several data elements that are populated inconsistently across the SDRs. The most noticeable cases of this are when two of the SDRs are populating a data element 100% of the time while the third SDR is not, as is the case with the ‘action’ or ‘message type’ data element. The conclusion here is that the data element can and should always be populated with a value to improve data quality. Another general insight that can be inferred from the data profiling of the Credit asset class is something as simple as that when the notional amount field is populated, the notional currency data element should also be populated and vice versa. CME and the DTCC both adhere to this rule in their data. However, this is not the case in BSDR’s trade data. In BSDR’s data the ‘notional currency amount 1’ data element is null 85.4% of the time, while the ‘notional currency 1’ data element is always populated. As you can see, this data profiling can reflect business rules that should apply to these data across SDRs as well as point out possible errors in the data.

Taking a look next at the Rates asset class, we observe similar inconsistencies in these data. Once again, the ‘action’ or ‘message type’ data element is populated 100% of the time in two of the SDR’s data but not in the third SDR. Additionally, we can extract a general business rule from these trade data that applies specifically to the Rates asset class. The payment frequency data element that applies to the first leg of the swap is always populated in BSDR and CME’s data. This reflects the rule that the payment frequency data element pertaining to the first leg of the swap should always be populated. However, 12.2% of the time this data element is null in the DTCC’s data and the rule is not followed appropriately. The complete subsets for both the Credit and Rates asset classes can be seen in the tables below.

Bitcoin NDF Trades

We will now transition and take a closer look at only the publicly disseminated trade data pertaining to TeraExchange’s Bitcoin NDF trades. These trades are currently being reported to CME’s SDR under the Commodity asset class. The first observation to be made here is that, quite frankly, these Bitcoin NDF products are rarely ever being traded. This is despite the fact that these products have been available now for almost a full year. In fact, according to these data the only Bitcoin NDF trades that have ever been executed on TeraExchange’s platform occurred on the very first day of trading: October 8, 2014. Although this leaves little data to analyze, only two trades to be exact, we can make the assumption that future Bitcoin NDF trades would be reported in the same way. This allows for comment on the individual data elements and what they tell us about the trades.

The first thing we look at is the ‘Product’ data element and notice that in both cases it is populated with this value: NDF-01WUSDXBT-OTC. This value implies that in both cases TeraExchange’s 1-week Bitcoin NDF is the product being traded. This also means that each swap was due to expire in 1 week’s time, which is confirmed by the maturity date of October 15, 2014. A few other things we can infer from these trade data are that the product is cash-settled in USD and is based on a fairly standard notional amount of $500,000. In short, these data elements pertaining to the two Bitcoin NDF trades are fairly basic and cleanly populated. The only slightly confusing thing to notice is that both trades have a fixed payment of $337 even though the final payment should be based on TeraExchange’s Terabit index. Perhaps this value is meant to represent some other term of the swap and should be reported a bit differently. Finally, one more thing to note is that the ‘End-User Exception’ data element is not populated, but should be according to the CFTC’s Part 43 rule.

Data Comparison

In comparing how the trade data pertaining to the two Bitcoin NDF trades look in comparison to the results produced by profiling the Credit and Rates trade data, there are no astute observations to be made at the current time. As only two Bitcoin NDF trades have thus far been executed, there simply is not enough data available to make any worthy comparisons. At best, the information described in the previous section can serve as a guide to understanding the terms of TeraExchange’s Bitcoin NDF contracts. These are fairly simple contracts with a limited number of specified terms, which many other products being actively traded are much more complex in nature.