안녕하세요. 김형준입니다. 아래와 같이 7월 세미나를 개최하였습니다.
자본시장 IT 사랑방 7월 세미나를 알립니다.
1.일시: 2013년 7월 31일 늦은 7시
2.장소: 주택건설회관 6층 대회의실
3.주제:: Exture+의 시세 및 주문프로토콜과 새로운 매매제도 설명
4.발표자: 트레이딩컨설팅그룹 이음 대표 김형준(블로그 운영자)
5.발표내용:2014년 3월로 예정인 Exture+가 사용하는 시세 및 주문 프로토콜과 관련한 자료들이 나왔습니다. 이미 증권사를 통하여 배포되었고 설명회도 실시하였습니다. 다만 한국거래소와 코스콤이 일반투자자를 대상으로 설명회를 하지 않기때문에 7월세미나는 API와 DMA 트레이더를 위한 프로토콜 설명회 형식으로 개최합니다. 또한 알고리즘트레이딩 관리방안을 도입하기로 하였기때문에 이 또한 설명하고 토론하는 자리로 기획하였습니다.
2.
어제 7월 세미나를 하였습니다. 신청자는 20여분이 넘었지만 참석자는 12분이었습니다. 회의실에 의자를 놓느라 고생을 했는데 아쉽네요.(^^) 어제와 같은 자리는 KRX Exture+를 추진하는 쪽이 일반투자자를 대상으로 공개설명회이어야 합니다. KRX의 프로토콜 조차도 홈페이지에 올리지 않는 상황이니까 공개설명회를 기대하는 것은 무리일 듯 합니다.
자료를 준비하면서 2012년 1월를 보니까 Exture+를 추진하면서 쟁점이 되었던 것이 여럿 있었음을 확인하였습니다.
이중에서 2013년 7월 1일자로 보포한 문서를 보면 프로토콜과 관련한 부분은 마무리되었지만 매매제도중 정정취소규정과 관련한 부분은 불명확하더군요. 그래서 프로토콜과 관련한 부분 및 사전주문위험관리와 관련한 항목을 주로 설명하였습니다. 프로토콜을 설명할 때 주로 주문체출방식, 주문접수순서, 주문응답방식을 소개하였습니다. KMAP 1.0과 달라진 부분을 설명하였습니다. 가장 이해하기 힘들었던 부분은 주문응답방식을 변경하면서 FEP접수부분을 뺀 이유입니다.
주문접수가 사라진 Exture+의 프로토콜?에서 설명한 바와 같습니다. 주문제출을 Sync에서 Async로 변경하였기 때문은 아닌 듯 합니다. 그렇다고 Latency 단축을 목적으로 하기 때문에 삭제했다는 주장도 이해가 쉽지 않습니다. 증권사 IT 혹은 트레이더가 주문체결 레이턴시를 측정할 때 사용할 수 있는 값은 FEP접수시간,매매체결접수시간입니다. 이중에서 FEP접수시간이 빠지면 증권사나 트레이더가 시간분석을 할 수 없습니다. 여의도에 돌아다니는 괴담이 많습니다. 레이턴시 경쟁을 하면서 “KRX가 특정한 증권사의 FEP세션을 더 빠르게 처리한다”,”KRX가 부산IDC의 주문을 지연처리한다”는 괴담입니다. 이런 이유로 증권사가 문의하면 답변은 항상 같습니다.
“절대로 그럴 수 없다.”
“그럴 수 없다”는 말보다 제도로 증명하는 것이 훨씬 신뢰를 높힙니다. 그것이 레이턴시 투명성입니다. Exture+은 레이턴시 투명성에서 보면 최악입니다. 물론 증권사에 FEP모니터링서비스를 제공하고 있기때문에 보완재가 있다고 할 수 있습니다. 그러나 이 또한 증권사 FEP세션에 대한 통계값일 뿐입니다. KRX 시장평균이나 타사와 비교값등을 제공하지 않습니다. FEP접수라는 전문을 만들어 체결로 내려주거나 ‘회원호가 확인’ 전문을 보완하여 FEP접수시간을 추가해주면 됩니다.
또하나 궁금한 점이 있었습니다. KMAP 1.0에 있었지만 KMAP 2.0을 설명하면서 빠진 부분이 MR입니다. 아마도 매매체결시스템중 주문접수하여 매매체결로 호가를 넘겨주는 부분으로 보입니다.여러 FEP에서 받은 호가를 전산적인 방식으로 줄을 세워서 매매체결로 넘길 듯 합니다. 이 때 어떻게 줄을 세우는지 궁금합니다. FIFO방식으로 호가처리를 합니다. 이를 위해 FEP에서 접수한 호가의 순서를 정해야 합니다. 이 때 규칙입니다.
Pre-Trade Risk와 관련한 부분중 영향도가 가장 큰 부분은 ‘과다호가접수제한’입니다. 영어로 표현하면 Message Throttling입니다. CFTC가 만든 권고안중 일부입니다.
Execution Throttles: If a particular algorithm or group of algorithms receives too many fills over a specified period of time, it will disable that algorithm (or group) and prevent it from placing new orders until there is human intervention to verify that the system is functioning properly.
Message Throttles: If a particular algorithm or group of algorithms sends too many messages in a specified period of time, it will disable that algorithm (or group) and prevent it (them) from placing new orders until there is human verification that the system is functioning properly.
FIX의 권고안입니다.
Runaway Checks:The purpose of this type of check is to identify the scenario where a client’s trading algorithm has stopped working correctly and/or is no longer under control of the client. One fundamental check is for trading systems to evaluate historical client trading patterns and order, cancel/replace rates for a given client. Significant differentials from historical trading patterns often are a good indicator of a potentially serious fault on the client side OMS or black box trading engine. Specific examples of metrics to compare are:
-The ratio of order cancels or cancel/replaces to new orders is unusually high relative to the client’s historical trading patterns.
-The ratio of orders to executions is unusually high.
-Multiple orders being created over a short period of time with the same details.
-Trading patterns indicating the algorithm may have gone into a loop (e.g. repeatedlysending an order and then canceling it).
Throttling과 관련한 규제는 줄어들지 않을 듯 합니다.현재는 단위시간당 호가건수만을 규제하지만 FIX처럼 호가대 취소비율를 규제할 수도 있습니다. Throttling Algorithm이 중요합니다. 또한 FEP의 기능으로 정의할지, 매매시스템의 기능으로 정의할지도 정해야 합니다.
3.
다시한번 귀한 시간을 내서 참석해주신 분들에게 감사를 드립니다. 뒷풀이까지 함께 하신 분들에게도 인사를 전합니다. 8월 사랑방은 ‘NoSQL와 어플리케이션로그’라는 주제로 해보려고 합니다. 발표할 수 있는 분들을 찾고 있습니다. 저에게 추천을 해주시면 좋겠습니다. 어제 세미나를 했던 목적은 KRX가 Exture+를 추진하면서 만든 KRX Market Access Protocol 2.0을 설명하고자 함이었습니다. 어제 참석을 못했더라도 자료가 필요하신 분은 아래로 신청을 해주세요. KRX가 회원사에 배포한 자료는 보내드리겠습니다.
