Clarus Financial Technology

Identifying Customer Block Trades in the SDR Data

In the post-reform World, it typically pays to revisit some concepts time and again. Therefore, I’m going to take another look at block trading this week.

Something I missed

This is something I wish I had known about before writing my first blog on block trading last month! There is a No-Action Relief Letter (14-118) relating to block trading. The implications from this “NARL” and what we can see in the data are quite significant.

It’s not the easiest thing to read, but fortunately footnote 13 is fairly straight-forward in it’s language – reproduced below:

13.“The Division notes that while block trades may not be facilitated through a SEF’s Order Book functionality, pursuant to this no-action letter, SEFs are permitted to use RFQ functionalities to facilitate the execution of a block trade. Also the Division notes that a block trade executed through a SEF’s RFQ functionality pursuant to this no-action relief would not be subject to the minimum participant requirement set forth in §37.9(a)(3). Finally, the Division notes that trades above the minimum block size may occur on the SEF’s Order Book however they will not receive treatment as block trades and will not be afforded a reporting time delay.”

What this means for the SEFs:

  1. The D2D SEFs (who are all running Order Books) therefore process trades of block size in an almost identical manner to non-block orders. There is no private negotiation of these orders outside of their Order Books, but their sizes are “capped” at the block threshold in the subsequent SDR reporting.
  2. The two big D2C SEFs (Tradeweb and Bloomberg) run RFQ platforms as opposed to an Order Book facility. This allows market participants trading in block size to send an RFQ to a single dealer if they so wish.
  3. We understand that the number of RFQs sent to a single dealer (let’s call them RFQ1) may be a significant portion of block trading activity (the alternative being an RFQ to 2,3 or more dealers), but we do not have actual data on the split.

But intriguingly, there is also an impact on the data!

Block Trading and the Data

Given the above, we can now deduce that a D2D SEF cannot designate a trade done through their Order Book as a “Block Trade”. Therefore all trades reported at the “Capped” threshold but not designated Block have been transacted on a D2D SEF.

Equally, only an RFQ venue can designate a trade as a “Block Trade”. Fortunately for us, the two RFQ venues (Bloomberg and Tradeweb) actually report to two different SDRs. This means that we can deduce that all Block Trades reported to the DTCC SDR were transacted on Tradeweb, and all Block Trades reported to the BSDR were transacted on BSEF (which we knew already…).

Clarus and Capped Trades

Our SDRView app already splits out capped trades – those trades that are above the notional threshold to qualify as potential block trades. We can then drill-down into this subset to identify those transacted on Bloomberg, those on Tradeweb and those on D2D venues.

The Data

Well, this cut of data sure presents a different perspective to the one we saw in our previous blog. Yes, D2C (a.k.a RFQ) venues have been seeing increases in Block volumes, but we can now also be confident that D2D venues have also seen increases in large trades.

The most neutral way to identify this trend is to look at trade numbers above the cap sizes. Here we see that the D2D share of these large trades has actually increased since 2014:

Where does the market choose to transact Block Trades?

Showing that:

Average Block Trade Sizes

This new view of the world also allows us to directly compare average block trade sizes on Bloomberg and Tradeweb. Each venue publishes their Block Volumes (available in SEFView) and we now know the trade counts on each venue for these trade types.

Average Block Trade sizes across the RFQ platforms

Showing:

And Average Trade Sizes Overall

As a little segue, it’s worth noting that the capped notional works out at around $110k DV01 per trade (this is smaller for 3y and 4y and bigger for longer maturities).

Comparing the total block sizes on Tradeweb and Bloomberg with what is reported as the capped amount to the SDR reveals that blocks are typically twice as large as this threshold. So on the whole, they really are impressively large size on RFQ platforms.

However, we can also use trade count data from SDRView, coupled with total volumes on SEFView, to look at some Average trade sizes per SEF. This is achievable because Tradition and Tulletts both publish trade numbers, whilst BSEF reports to their own SDR – giving us another trade number to work with.

Therefore, Average Trade Size by venue looks like this:

Average trade size per SEF shows that it is still easier to get large size done at a D2D/CLOB venue

RFQ vs CLOB

This little look into average trade sizes got me thinking about real liquidity and what it means. Previously, I assumed that because D2C venues are trading more and more large tickets, that they were trying to compete with D2D-type business.

However, it looks to be more a market choice between what type of execution venue you want to trade your big tickets across. Do you want to revert to old-school bilateral channels to keep your banker happy – and trade RFQ? Or do you risk information leakage in a post-trade name give-up protocol, embodied by the D2D SEFs running CLOBs?

My previous blog suggested that the market is choosing RFQ as their preferred protocol. However, now that we can infer a more granular reading of the SDR data, this may not actually be the case.

Remember that for both Bloomberg and Tradeweb, some of this business will be Compression and IMM Roll related – portfolio maintenance exercises simply not offered by the CLOB venues.

But also, if we look at the pure split in terms of trade numbers in block trades, the following chart shows a very slight trend towards CLOBs:

Is the market veering towards a CLOB preference? Hard to tell at the moment

This chart highlights my final points:

Stay informed with our FREE newsletter, subscribe here.

Exit mobile version