Today, we will briefly review the DTC Protocol. Finally, I will discuss some of my personal experiences with the protocol, as I did author a DTC client DLL plugin for Zorro.
Overview
The Data and Trading Communications Protocol is an unlicensed public-domain protocol, as developed and published by the engineers at Sierra Chart. Using this protocol, a client and a server would exchange financial messages, such as:
- Logon, authorization, heartbeats, and logoff
- Market data, including market depth
- Order placements, modifications, and cancellations, including OCO orders
- Order tracking, including open orders and historical orders
- Market position tracking
- Account balance tracking
- Symbol definitions and discovery
- Logging
- Historical financial data
In addition, any server has the option of supporting custom messages for any purpose.
Encodings
A DTC server can pick and choose which encodings it will support. There are five encodings to choose from:
- Binary Encoding
- Messages consist of fixed-size structs. This is quite easy to implement in C/C++, and very low bandwidth.
- Binary w/ Variable Length Strings Encoding
- Similar to the standard binary encoding, but the strings can have variable length. This has the advantage of minimum bandwidth, and the disadvantage that it is a little complicated to implement. Also, the bandwidth reduction will only affect strings, so this reduction will have zero effect on numerical data such as market data or historical data. This could be implemented in C/C++.
- JSON Encoding
- Every message is a JSON object. This is the option with maximum bandwidth, since all messages are in plain text. I cannot recommend this encoding at all, since a more compact version exists.
- Compact JSON Encoding
- This is the JSON encoding where the bandwidth is reduced, particularly for market data and historical data. If you must use JSON, consider this encoding over the non-compact version. Perhaps this can be useful for Javascript applications, where binary data is not particularly practical to manipulate.
- Google Protocol Buffers
- A proto2 file and a proto3 file are available to generate message classes in C++, C#, Java, Dart, Go, and Python, and that’s just the officially supported languages. These classes can be used to serialize and deserialize data to and from a binary socket stream. I suspect that this method is fairly efficient with bandwidth but adds some processing overhead. This can be a good choice if backwards compatibility, minimal code maintenance, maximum language compatibility, and low bandwidth are all high priorities.
Connections
DTC officially supports connectivity via:
- TCP Socket
- Web Socket
These sockets can be encrypted or unencrypted, as the server sees fit. The general recommendation is to use TLS 1.2 encryption, as of this writing.
My Experiences with the DTC Protocol
I wrote a DTC client in C++. It was a DLL broker plugin for the Zorro Trading Automaton. Other than some challenges related to running background threads from a DLL (which I will not discuss here), the protocol has been fairly easy to work with.
I was motivated to write a DTC client in the first place because Sierra Chart has a fully integrated DTC server. This is useful because Sierra Chart can connect to many data/trading services.
I was slightly disappointed to learn that Sierra Chart’s DTC server does not support the full spectrum of message types. For example, the Symbols for Underlying Request is not supported, so I cannot list out all available symbols for a given option or future.
How to Rapid-Prototype a DTC Client or DTC Server
If you want to try out the DTC protocol today, I have good news for you: You can prototype your DTC clients and DTC servers by testing it out with a copy of Sierra Chart.
I did mention that DTC has an integrated server, but you can also use it as a DTC Test Client.
In conclusion, you can make a prototype DTC client by connecting it to Sierra Chart, and a prototype server by serving Sierra Chart. After this, you should feel free to re-use the client or server in any application you see fit.
Hi,
This is bit of a complex question that requests an opinion.
I was the owner and funder of a full features SelfClearing B/D named ex24. It operated 24/7 trading Section 12 securities. It was fully self contained with a Trading Platform and a settlement. It ran beautifully for 2 years. But the SEC had placed ex24 between a rock and a hard place by limiting us to Section 12s but then effectively limiting us to a max of 99 shares imposing the Round Lot Rule which to escape, we would have to become a market maker. ex24 failed. I lost almost $10 million
Now comes Regulation Crowdfunding which the SEC just permitted issuers to raise up to $5 mil per year.
The problem with Reg CF is, after a one year hold by the REG CF IPO investor, the there is no centralized trading venue for Price Discovery or Trade execution.
Of course, ex24 could do all of that. But I dont know where the SEC would stand on ex24 once again holding cash( ex24 held a usable user cash) and the Investors Crowdfunded Securities. It would probably be a long, costly process without a certain outcome.
Since every CF-IPO has a Transfer Agent, if ex24. could provide a trading platform that was able to access the Transfer Agents stock records, then Users could sign on the an ex24 Trading system to trade the p1 year past CF-IPO investors shares.
I could make ex24 a Transfer Agent but that would make access to the market of all CF securities a barrier to entry. It would probable be a broader market if ex24 could offer an API set to all of the CF Transfer Agent.
ex24 would hold no funds. That, of course is a big issue at a SCBD. requiring a Special Reserve Account for the Exclusive Benefit of Customers. Instead, ex24 would handle no money, and no shares instead offering its service at an annual subscription fee. If a Buyer executed a trade they would have two days to ach or Zell the payment to the Transfer agent.
So finally the question. Do you thing the DTC protocol would facilitate this concept.
Thanks
Jim
Jim,
I am not in the broker-dealer business, so I cannot comment on any of that. Maybe this is a better question for the engineers at Sierra Chart, since 1) they invented the protocol, and 2) they hinted that they might want to get into the BD business themselves.
Andrew
Dear sirs
I am interested to know if you provide real time data for trading the stock of Eurobank Ergasias Holdings S.A. which is listed in the Athens stock exchange and if you provide real time data for the rest of the stocks of the FTSE Large Cap of the Athens Stock Exchange. If you do, I would like to connect the data with the Sierra chart trading platform.
Kind regards
John
John,
Direct exchange implementations are very expensive to implement (easily 5-6 figures) and are difficult to justify only to trade one ticker symbol.
If you are serious, contact me via email: andrew@vitaltrades.com
Andrew
Hi Andrew,
I’m testing our plugin and it does a really good job but I noticed that I can’t have acces to CME, NYSE and EUREX futures data. I went to SierraChart website and it says that it’s not possible to have access to real-time data from the above exchanges via the DTC protocol. Is there another way to get the data to Zorro?
Thanks
I have funds sent on DTC Server to Server from UBS AG to BOFA. Funds are on ECB. Fed slots are bottlenecked currently. However, US Bank has a Fed slot open and We have US Bank account.
Can they complete the download, even though the DTC Server to Server paperwork list BOFA as the Receiving Bank. Is there a collaboration that BOFA and US Bank can have so USBank can complete this without me having to go back to UBS and have them switch the Receiving Bank to US Bank?