1.
국내 시장에서 FX API가 이슈인기 이슈인가 봅니다. 서울외국환중개 대표의 인터뷰중 일부입니다.
중개력 강화를 뒷받침하기 위한 시스템 개발과 확대 노력도 이어갈 계획이다. 올해부터는 국내은행 등과 연계해 API의 도입 활성화를 추진하고 있다. API란 은행들의 트레이딩(거래) 시스템과 서울외국환중개의 중개 시스템 서버 간 전산을 연결해 실시간 외환시장 거래 동향을 알 수 있고 서버 간 거래도 할 수 있게 만든 시스템이다. 시중은행은 API를 통해서 시장의 호가를 실시간으로 받아 고객에게 가격을 제공하고 거래가 들어오면 이에 따라 발생한 포지션을 상황에 따라 자동으로 헤지를 할 수 있어 거래의 정확성과 편의성을 높일 수 있다. 정 대표는 “시중은행 등 최근 일부 국내기관과 API 계약을 체결하고 있다”며 “앞으로 API를 통한 거래가 자리를 잡는다면 서울 외환시장 거래량도 함께 늘어날 것”이라고 기대했다.
서울외국환중개 대표 “코로나에도 작년 4% 성장…中시장 본격 진출 검토”중에서
일반적으로 기관접속을 위한 FIX Protocol을 공개합니다. 그렇지만 외국환중개의 FIX Protocol흔 현재 비공개입니다. 여의도에서 KRX 거래를 위한 FIX와 비교하면 큰 틀에서 비슷합니다. 다만 다른 점은 Quote입니다. 대부분의 즈권사는 FIX를 통하여 시세서비스를 제공하지 않지만 서울외국환중개의 FIX는 호가서비스를 제공합니다. Central Limit Orderbook이기 때문에 정확히 말하면 Market Data Message를 지원합니다.
시야를 해외로 돌리면 어떨까요? 우연히 무척 흥미운 서비스를 발견하였습니다.
Connect to 90+ FX Markets:One API to All of FX
FX와 관계하는 금융회사, ECN의 서비스를 체계적으로 정리하여 검색서스를 제공합니다. 예를 들어서 FIX는 어떤 버전을 지원하는지, 어떤 유형의 거래인지, 거래하는 상품은 무엇인지를 확인하실 수 있습니다. 예를 들어 오랜 역사를 가진 FXAll을 보면 아래와 같습니다.
물론 해외제휴선을 결정할 때 기술적인 면을 고려하는 비중은 적습니다. 딜러의 판단이 중요합니다. 가격이나 체결 등이 중요해 보입니다.
혹시나 하는 마음에 FX회사들이 제공하는 FIX Protocol이 궁금해집니다. 검색해보니까 Connectivity To Forex ECN: FXall, Hotspot, Currenex에서 FXALL과 HOTSPOT의 문서를 찾을 수 있었습니다.
2.
위 자료를 보니까 URL이 재미있습니다. DTCProtocol… 무슨 의미인지 궁금해졌습니다. DTC는 Data And Trading Communication의 약자입니다. Data and Trading Communications Protocol을 보면 DTC Protocol을 개발한 이유가 나옵니다.
These are the basic objectives of the DTC protocol:
It is the purpose of the DTC protocol to define a common set of messages and fields within those messages, and establish clear procedures for working with these messages and fields in order to create reliable and plug-and-play interoperability between Clients and Servers for the communication of financial market data and trading messages.
The header of each message contains the message type, the same as FIX messages.
The message types and fields for trading related messages should be the same or similar to FIX where possible and appropriate.
The DTC Protocol needs to be simple and should not get out of control with excessive number of messages and fields. Although it will grow as needed. It is for this reason, that managed order types like trailing stops should not be adopted by the standard DTC Protocol implementation.Clients and Servers can define their own custom messages between each other where the DTC Protocol does not meet their requirements.
The content of each message is based upon the purpose of the message.
The DTC Protocol supports any kind of connectivity method. Typically this will be the Internet but can work over any reliable communications network. It can use an encrypted or not encrypted connection. The protocol is simply a layer on top of the transport and encryption layers.
The DTC Protocol supports Client and Server identification with authentication. Just because the Client and the Server support the same protocol, does not mean that each side has to talk to each other. For example, if the server requires a license key from the Client, the server can deny the connection if the license key is not valid.
The DTC Protocol supports dynamic connections where the Server to connect to can change dynamically. Multiple connections are supported.
DTC Protocol은 FIX Protocol도 지원하는 Simple Binary Encoding(SBE), Google Protocok Buffers(GPB), JSON Encoding을 지원합니다.
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.
큰 틀에서 보면 FIX Protocol과 비슷합니다 그럼에도 차이가 있습니다.
FIX is regarded as a high overhead protocol for market data. FAST is a solution to this, but it technically is complex to implement.
For some users FIX is not easily implemented and used. Data and Trading service providers know that many of their customers will have difficulty using FIX.
Over an authenticated TCP/IP connection, FIX has unnecessary fields like the Sender Comp ID, Target Comp ID and checksum.
FIX is not a strict standard. Although a Client and the Server may implement FIX, they are not automatically compatible with each other unless they follow a specific FIX implementation they agree upon.
FIX does not have messages for historical price data. And also FIX is not efficient with historical data transport. Whereas DTC, has full support for historical price data in the most efficient way possible.
The DTC Protocol is very efficient and requires minimal network bandwidth when using binary encoding.
왜 이런 프로토콜을 만들었을까요? DTC Protocol을 만든 회사는 Sierra Chart입니다. 고객용 트레이딩시스템으로 유명한 회사입니다. 그래서 혹 이런 고민을 하지 않았을까 추측을 해봅니다.
“FIX와 같은 범용인 프로토콜이면서 일반투자자이 필요로 하는 정보까지를 제공해주는 프로토콜이 가능할까?”
이런 추측을 하는 이유는 개발된 Message입니다. DTC Messages and Procedures을 보면 Order tracking, including open orders and historical orders, Account balance tracking, Symbol definitions and discovery, Historical financial data 등입니다. 일반 투자자를 위한 트레이딩시스템 – 한국의 HTS를 포함하여 – 이 제공하는 기능들입니다.
Authentication and Connection Monitoring Messages
ENCODING_REQUEST ENCODING_RESPONSE LOGON_REQUEST LOGON_RESPONSE LOGOFF HEARTBEAT Market Data Messages
MARKET_DATA_FEED_STATUS MARKET_DATA_FEED_SYMBOL_STATUS MARKET_DATA_REQUEST MARKET_DEPTH_REQUEST MARKET_DATA_REJECT MARKET_DEPTH_REJECT MARKET_DATA_SNAPSHOT MARKET_DEPTH_SNAPSHOT_LEVEL MARKET_DEPTH_UPDATE_LEVEL MARKET_DATA_UPDATE_TRADE MARKET_DATA_UPDATE_BID_ASK MARKET_DATA_UPDATE_LAST_TRADE_SNAPSHOT MARKET_DATA_UPDATE_TRADE_COMPACT MARKET_DATA_UPDATE_SESSION_VOLUME MARKET_DATA_UPDATE_OPEN_INTEREST MARKET_DATA_UPDATE_SESSION_SETTLEMENT MARKET_DATA_UPDATE_SESSION_HIGH MARKET_DATA_UPDATE_SESSION_LOW MARKET_DATA_UPDATE_SESSION_OPEN Order Entry and Modification Messages
SUBMIT_NEW_SINGLE_ORDER SUBMIT_NEW_OCO_ORDER SUBMIT_FLATTEN_POSITION_ORDER CANCEL_REPLACE_ORDER CANCEL_ORDER Trading Related Messages
OPEN_ORDERS_REQUEST ORDER_UPDATE OPEN_ORDERS_REJECT HISTORICAL_ORDER_FILLS_REQUEST HISTORICAL_ORDER_FILL_RESPONSE HISTORICAL_ORDER_FILLS_REJECT CURRENT_POSITIONS_REQUEST POSITION_UPDATE CURRENT_POSITIONS_REJECT Account List Messages
TRADE_ACCOUNTS_REQUEST TRADE_ACCOUNT_RESPONSE Symbol Discovery and Security Definitions Messages
EXCHANGE_LIST_REQUEST EXCHANGE_LIST_RESPONSE SYMBOLS_FOR_EXCHANGE_REQUEST UNDERLYING_SYMBOLS_FOR_EXCHANGE_REQUEST SYMBOLS_FOR_UNDERLYING_REQUEST SYMBOL_SEARCH_REQUEST SECURITY_DEFINITION_FOR_SYMBOL_REQUEST SECURITY_DEFINITION_REJECT SECURITY_DEFINITION_RESPONSE Account Balance Data Messages
ACCOUNT_BALANCE_REQUEST ACCOUNT_BALANCE_REJECT ACCOUNT_BALANCE_UPDATE Logging Messages
USER_MESSAGE GENERAL_LOG_MESSAGE Historical Price Data Messages
HISTORICAL_PRICE_DATA_REQUEST HISTORICAL_PRICE_DATA_RESPONSE_HEADER HISTORICAL_PRICE_DATA_REJECT HISTORICAL_PRICE_DATA_RECORD_RESPONSE HISTORICAL_PRICE_DATA_TICK_RECORD_RESPONSE
Sierra Chart의 비지니스모델을 국내에서 적용해보죠. Sierra Chart는 트레이딩시스템을 개발공급합니다.
Sierra Chart is a professional desktop Trading and Charting platform for the financial markets, supporting connectivity to various exchanges and backend trading platform services.
한국으로 말하면 HTS를 개발공급하는 회사입니다만 차이점이 있습니다. 증권사나 선물사에 SI방식으로 공급하는 플랫폼이 아니라 독립플랫폼으로 여러 증권사나 선물사와 거래할 수 있는 시스템입니다. 코스콤이 운용하는 서비스중 STPHub가 있습니다. Buy Side와 Sell Side사이세ㅓ FIX Message를 중계하는 서비스입니다. 비슷한 형식으로 DTCHubd를 만들어보면 어떨까요?
DTC를 지원하는 Desktop 혹은 Mobile App <--> DTCHub DTC Server <--> 증권사 및 선물사 DTC Server <---> HTS 플랫폼 <---> 한국거래소 혹은 해외FCM
이상의 구조에서 시세서비스는 증권사에 의존하지 않고 독립적으로 구축합니다. DTC Service중 Data Service는 서비스회사가, Trading Service는 증권사, 선물사가 제공하는 방식입니다. 참고로 GlobalTrading이 제공하는 트레이더용 FIX입문서를 첨부합니다. 비교해서 살피시면 좋을 듯 합니다.
