FIX 프로토콜 작동 방식 3월 7, 2022 – Posted in: Forex trading

도입

주식시장의 거래 역사는 창사 이래 극적으로 변화해 왔다. 최초의 증권 거래소는 약 400년 전에 나타났습니다. 그 당시 거래는 구두로 이루어졌고, 무역 규칙은 이제 막 시작되었다. 그러나 세계는 가만히 있지 않았고, 시대에 발맞춰 증권 거래소는 그 당시 이용할 수 있었던 모든 가능한 기술적 도구들을 떠맡았다.

그러므로, 19세기 중반에, 교환으로부터 어느 정도 떨어진 곳에서 무역 응용 프로그램들이 전신선을 연결했다. 그리고 전화기가 그를 대신했다. 그리고 마침내 무역상들의 첫 번째 거래 요청이 인터넷의 통신을 통해 전달되는 순간이 왔다.

공정하게 말하면, 전화를 통한 거래는 현대에도 일부 중개업소에서 여전히 일어나고 있다. 그리고 그 중 특정 부분이 거래를 할 수 있는 유일한 보장된 방법입니다. 또한 최초의 교류가 시작된 이후 21세기 초까지 교류 거래의 영역에 대한 직접 거래가 구두로 진행되었다. 이러한 거래층은 주식 구덩이라고 불렸고, 비슷한 주제의 할리우드 영화에서 우리에게 친숙한 광경이었다.

FIX 프로토콜 기록

가장 오래된 디지털 거래 프로토콜 중 하나는 FIX 프로토콜이다. 금융 정보 프로토콜 또는 금융 교환 프로토콜을 의미하며, 두 가지 정의가 모두 있습니다. FIX 프로토콜 명세서는 1992년 충실도 투자와 살로몬 형제 간의 주식 거래에 대한 정보를 제공하기 위해 만들어졌다. 중개업자와 투자펀드는 거래소에서 거래하는 과정이 빨라지기를 원했다. 그 결과는 어떤 주요 조직도 통제하지 못하는 정보를 전자적으로 전송하기 위한 개방형 표준이다. 오늘날 FIX는 다른 나라의 금융 시장 참여자들이 그들의 상품을 연결하기 위해 사용하는 산업 표준이 되었다. 당초 이 통신 규약은 위에서 언급한 두 거래소 간에만 사용됐고, 이를 SBX(살로몬 형제 거래소)라 부르며 주식 거래에만 활용됐다. 그 후, 이야기가 전해지듯이, 그들의 발명의 중요성을 깨달은 이 회사들의 지도자들은 골드만 삭스와 퍼트먼의 개발에 동참하겠다고 제안했다. 프로토콜에 현재 이름이 지정되었습니다.

처음에 이 프로토콜은 17개의 메시지 유형과 103개의 태그만 지원했다. 이 아이디어는 매우 성공적이어서 1995년까지 모든 미국 증권사의 70% 이상이 이 프로토콜을 사용했다. 이는 비용 절감, 비용 절감, 거래 오류 감소 등의 이유였다. 결국 휴대폰으로 거래할 때는 인적 요인이 매우 큰 영향을 끼친다. 시간이 지남에 따라 프로토콜은 상당히 확장되었다. 파생상품, 채권, 환전 등에 대한 지원이 추가됐다. 현재 FIX 사양은 168개의 메시지, 7,868개의 태그를 기술하고 있으며 모든 등급의 증권에 적용됩니다. 1998년에 FIX 프로토콜과 그 규격의 개발뿐만 아니라 관련 기술의 개발도 FIX 프로토콜 Ltd 컨소시엄으로 이관되었다. 이 컨소시엄은 나중에 FIX 무역 커뮤니티로 이름이 바뀌었다. 270개 이상의 주요 금융 기관이 현재 이 조직의 회원이다.

FIX 프로토콜 작동 방식

FIX 프로토콜은 TCP를 통해 실행됩니다. 현재 FIX 프로토콜 모델은 세션 또는 제어 수준(세션 생성, 데이터 전송 작업)과 애플리케이션 수준(데이터 콘텐츠 설명)의 두 가지 수준으로 정의되어 있습니다. 제어 계층은 연결 열기 및 닫기, 손실된 메시지 복구와 같은 FIX 세션의 기본 매개 변수를 담당합니다. 응용 프로그램 계층은 요청, 실행, 거부, 시장 데이터 및 상태 정보 요청과 같은 데이터의 송수신 기능을 제어합니다. 프로토콜 자체는 텍스트, 즉 ASCII 테이블의 문자를 사용합니다. 이는 꼬리표=값(꼬리표=값 또는 열쇠=값) 형식의 전통적인 표현과 XML(FIXML) 표현의 두 가지 표현으로 구분됩니다. 최신 버전은 현재 5.0이지만 가장 일반적인 버전은 4.2와 4.4이다. 서로 다른 브로커와 거래소는 서로 다른 버전의 프로토콜을 사용할 수 있으며, 때로는 동시에 여러 개의 프로토콜을 사용할 수도 있습니다..

통사론 태그=값

메시지는 다음과 같습니다:

8=FIX.4.2 | 9=178 | 35=D | 34=1234567 | 49=TESTER | 56=PHLX | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 54=1 | 167=FUT | 55=MSFT | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |

세로 막대로 구분된 일부 부분으로 구성된 텍스트 문자열입니다. 이러한 부분을 필드라고 합니다. 또한 각 부품은 부호가 같은 키-값 쌍으로 구분됩니다. 기호의 오른쪽이 열쇠이고 왼쪽이 값이다. FIX 사양에서는 키를 태그라고 합니다. 태그는 항상 필드 이름에 대한 포인터인 양의 정수입니다. 모든 필드 이름과 가능한 값은 특정 교환에 대한 설명서에 설명되어 있습니다. 이러한 필드 대부분은 표준이며 모든 교환의 BOM에서 찾을 수 있습니다. 또한 특정 교환 내에서만 정의되고 의미를 갖는 사용자 정의 필드도 있습니다. 일반 FIX 프로토콜 사양에서 표준 필드에 대한 설명을 찾을 수 있는 경우 사용자 지정 필드를 교환 FIX 프로토콜 사양에서 설명해야 합니다. 필수 필드, 선택 필드 및 조건부 필수 필드도 있습니다(메시지에 다른 필드가 있는 경우에 따라 필요). SoH(헤드 시작) 기호는 필드 사이의 구분 기호로 사용됩니다. 실제로 보이지 않으므로 이 예에서는 세로 막대로 대체됩니다. 유니코드 인코딩에서 이 문자는 “\u0001” 코드를 가집니다. 다시, 메시지가 필드로 분할되는 동안 세 가지 구성요소를 추가로 정의합니다:

헤더(메시지 헤더)
본문(메시지 본문)
메시지 강사(체크섬)

FIX 버전 1.1과 FIX 버전 5.0에서 헤더에는 5개의 필수 필드와 하나의 선택적 필드가 포함되어 있습니다: 8(BeginString), 9(BodyLength), 35(MsgType), 49(SenderCompID), 56(DestComppID), 1128 (ApplVerID – 가 존재한다면 6번째 위치에 있어야 합니다). 메시지에는 관리 및 적용의 두 가지 주요 그룹이 있습니다. 관리 메시지는 FIX 세션의 기본 사항을 처리합니다. 세션을 시작하고 종료할 수 있을 뿐만 아니라 누락된 메시지를 복원할 수 있습니다. 신청 메시지는 영장의 요청 또는 영장의 현재 상태 및 후속 집행에 대한 정보와 같은 무역 관련 정보의 송수신과 관련이 있습니다..

다음 메시지를 분석합니다.

8=FIX.4.2 – BeginString. 프로토콜 버전이 사용됩니다. 이 메시지의 필드를 구문 분석하는 데 적용할 규칙을 트레이더 프로그램에 알려줍니다.
9=190 – BodyLength. 메시지 본문 길이는 헤더를 포함하여 178바이트입니다. 태그 35(포함)부터 태그 10(포함)까지의 문자 수로 계산됩니다. SoH 스플리터도 고려됩니다.
35=D – MsgType. 메시지 유형. 이 경우, D는 무역 요청을 하는 것을 의미합니다. 예를 들어, 35=V 필드는 계측기에 대한 시장 데이터가 수집되었음을 나타냅니다.
34=1234567 – MsgSeqNum. 메시지 번호. MsgSeqNum 메시지가 전송된 순서에서 1이 다를 경우, 서버는 오류를 반환하고 메시지를 처리하지 않습니다.
49=SenderCompID. 보낸 사람거래소에서 발급한 아이디입니다. 사용자 이름일 수도 있고 브로커가 메시지를 보낸 경우 브로커의 이름일 수도 있습니다.
56=PHLX – TargetCompID. 보낼 수신자 ID입니다. 교환소에서 발행하기도 합니다.
52=20071123-05:30:00.000 – SendingTime.000. 메시지를 보낸 날짜 및 시간입니다.
11=ATOMNOCCC9990900 – ClORDID. 브로커 거래 시스템의 응용 프로그램 번호입니다.
54=1 – 측면. 자산 구매 작업
167=FUT – SecurityType. 그 자산은 미래다.
55=MSFT – 기호. Microsoft 프로모션. 티커는 교환마다 다를 수 있습니다.
38=15 – OrderQty. 거래량은 15필트 또는 계약입니다.
40=2 – OrdType. 제한된 가격, 제한된 주문.
44=15 – 가격. 구매 가격 – 15
59=0 – TimeInForce. 지원 마감일은 근무일 마감입니다.
10=128 – CheckSum. 메시지 체크섬항상 메시지의 마지막 필드입니다. 특수 공식을 사용하여 계산되며 프로토콜 사양에 설명되어 있습니다. 체크섬 필드 문자를 제외한 메시지 내 모든 문자의 ASCII 값을 합산하여 설정합니다. 그런 다음 값을 256으로 나누고 구획의 나머지를 취한다. 체크섬은 항상 3자여야 합니다. 즉, 계수가 22이면 숫자 앞에 0 – “022”가 더해진다.

이 메시지를 일반적으로 설명하면 15개 계약의 개수로 마이크로소프트 주식선물을 만기일이 15일로 마감된 상한가 15에 매수하는 행위다.

FIX의 유연성을 높이기 위해 프로토콜에는 사용자 정의 필드인 사용자 정의 필드가 포함되어 있습니다. 이들은 협력 금융 조직 간의 데이터 전송에 사용됩니다. 5000에서 9999까지의 태그 번호는 사용자 지정 필드를 위해 예약되었으며 표준의 공식 웹사이트에서 예약할 수 있다. 이 숫자들은 나중에 사용되었고, 20,000에서 39,999까지 새로운 간격이 할당되었다..

FIXML 통사론

구문에 대한 작업은 1998년에 시작되었으며 첫 번째 버전은 1999년에 출시되었다. 태그로 인코딩된 메시지와 의미상 동일하지만 XML 구문 분석 기술을 사용합니다. FIXML 형식의 작업에 대한 새로운 애플리케이션은 다음과 같습니다:

<FIXML>

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>

</Order>

</FIXML>

XML 형식에서 코드의 특정 블록은 소위 태그(프로토콜 자체에서 사용되는 태그가 아닌 다른 태그)로 프레임이 만들어진다. 예를 들어, <FIXML> 상위 순서 태그가 있습니다. 임의의 태그는 코드나 메시지의 특정 부분을 잘라내고 같은 태그로 닫지만 왼쪽 가장자리 안에는 슬래시 문자가 있습니다. 따라서, 언급된 태그는 다음과 같이 블록을 닫습니다: </FIXML.

다음, 이 태그 안에 다음 태그가 있습니다:

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>.

여기에 태그 이름 – 순서가 표시되고, 중괄호 안에는 추가 정보(동일한 필드, 구문 태그 = 값과 키 = 값 쌍)가 있습니다.

이 경우:

ClOrdID=”123456″ – 브로커 거래 시스템에서 주문 ID

Side=”2″ – 판매 주문서

TransactTm=”2001-09-11T09:30:47-05:00″ 트랜잭션 날짜 및 시간

OrdType=”2″ – 클레임 유형 – 주문 제한

Px=”93.25″ – 구입 또는 판매할 자산의 가격

Acct=”26522154″ – 사용자 계정 번호

이전 XML 태그와 마찬가지로 XML 태그는 슬래시 – </Order>로 닫힙니다.

XML 태그를 여는 것과 닫는 것 사이의 내용을 태그 본문이라고 합니다. 따라서 주문 태그는 FIXML 태그의 본문입니다. 본문으로 주문 태그에는 두 개의 태그가 더 있습니다. Instrmt 및 OrdQty.

다음 태그:

여기서 이것이 닫히는 동시에 닫히는 것을 볼 수 있는데, 그 끝에는 사선이 있습니다. 태그에 아무도 없고 별도의 프레임 태그를 만드는 의미가 없는 경우가 이에 해당합니다. 이 태그에는 도구의 눈금, ID 등에 대한 정보가 포함되어 있습니다.

<OrdQty Qty=”1000″/> 태그에서 트랜잭션 볼륨에 대한 정보를 볼 수 있으며 본문 없이 닫는 태그이기도 합니다.

FIXML은 일반적으로 트레이딩이 아닌 백오피스 및 애플리케이션 클리어 작업에 사용됩니다.

FIX 회기하다.

이전의 예에서는 애플리케이션 계층에 대해 설명했습니다. 사양은 클라이언트와 교환 간의 세션 수준을 담당하는 특수 필드 유형을 정의합니다.

35=A – 로그온. 연결 시 교환 시스템에 대한 사용자를 인증하는 데 사용됩니다. 이 메시지가 먼저 전송되고 데이터 세션 시작 부분에 교환 신호를 보냅니다. 성공적으로 제출하면 회신 메시지가 도착합니다. 연결에 실패하면 오류가 반환됩니다.
35=5 – 로그아웃. 이 메시지는 서버에서 권한을 해제하고 교환과의 거래 세션을 닫는 데 사용됩니다.
35=0 – 심장 박동. 심박수, 혹은 맥박. 이 메시지는 연결 양쪽에서 서로 보내지며 양쪽이 메시지를 받고 보낼 준비가 되었음을 나타냅니다. 하트비트 빈도는 첫 번째 로그온 메시지에서 설정됩니다.
35=1 – 테스트 요청. 이 메시지는 테스트 메시지이며 상대방이 설정된 기간 내에 하트비트 메시지를 보내지 않았을 때 전송됩니다. 이 메시지에 응답하지 않으면 세션이 닫힙니다.
35=2 – 요청 다시 보내기. 이 메시지는 누락된 정보가 있을 경우 메시지를 다시 보내달라는 요청입니다.
35=3 – 거부 또는 거부합니다. 이전 메시지의 형식이 잘못되었거나 실행할 수 없는 경우 상대방이 보냅니다.
35=4 – 시퀀스 재설정 또는 메시지 전송 시퀀스를 재설정합니다. 그것은 두 가지 형태를 가질 수 있다.

– 123=”Y” – 지정된 값의 GapFillFlag 태그가 있습니다. 관리 메시지를 다시 보내는 경우 무시하는 요청을 나타냅니다.

– MsgSeqNum 카운터를 0으로 설정하는 데 사용됩니다.

FIX API를 개선하기 위한 기능 향상으로 FAST 구현

대량의 FIX 데이터는 처리 지연이 심하여 거래자들이 효과적인 거래 전략을 개발할 가능성이 낮아졌다. 이 같은 문제를 깨달은 직후 상황을 바로잡기 위한 첫걸음이 내디뎠다. FAST 프로토콜의 목적은 대량의 데이터 전송을 허용하여 정보 수집의 지연을 방지하는 것이었다. FAST (스트리밍에 맞게 변형된 FIX) FIX 프로토콜이 네트워크 프레젠테이션을 최적화하기 위해 개발한 기술 표준이다. 기본적으로 FIX 프로토콜의 바이너리 포맷이며 트랜잭션과 시장 환경에 대한 많은 양의 정보를 컴팩트한 형태로 전송할 수 있다. 이를 통해 전송 지연이 적은 고속 거래 시스템에 사용할 수 있다. FAST는 패서디나에 있는 캘리포니아 공과대학교에서 개발되었습니다. 현재 FAST 1.2의 최신 버전입니다. 가장 일반적인 응용은 중개업자의 거래 시스템을 우회하여 거래소에 직접 연결하는 것입니다. FAST 프로토콜은 표준화된 시장 정보 배포 프로토콜이며 세계에서 가장 널리 사용됩니다. 이전에, 모든 인터넷 트래픽은 지난 세기에 개발된 전송 제어 프로토콜 (TCP) 시스템에 기반을 두었다. TCP는 패킷 전달을 승인해야 하는 소켓 연결이다. 큰 파일과 메시지를 각각 패킷의 원본 및 대상 주소를 포함하는 1500바이트 패킷으로 나눕니다. 송신자는 송신된 패킷이 성공적으로 배달되었는지 확인을 기다린 후 다음 패킷을 전송합니다. 전송이 실패하거나 전송 신호가 지정된 시간 내에 도착하지 않으면 패킷이 더 낮은 속도로 다시 전송됩니다. 그리고 원하는 만큼 할 수 있습니다. 속도가 기하급수적으로 내려가면서, 배달이 성공했다는 신호가 올 때까지요. 전송에 실패할 때마다 귀중한 밀리초가 손실되기 때문에 사소한 회선 문제라도 데이터 속도에 심각한 영향을 미칠 수 있다는 것이 명백해진다. 따라서 FAST는 해결 방법을 도입했습니다. 시스템이 지속적으로 패킷을 모니터링하고 메시지를 수신하여 회선상의 문제를 즉시 감지하고 다음 전송 속도를 약간 낮췄지만 안정적으로 설정합니다. 이 방법을 사용하면 성능 저하를 확인하는 데 시간이 걸리지 않으므로 대부분의 경우 패킷을 다시 보낼 필요가 없습니다. 일부 교환에서 연결 인터페이스는 두 가지 유형의 연결을 통해 구현된다: UDP와 TCP. UDP 소켓의 모든 데이터를 전송하는 것은 의미가 없으며, 그러한 연결은 전달의 확인을 요구하지 않으며 패킷은 단순히 사라질 것이며, 어느 쪽도 그것에 대해 알지 못할 것이다. 따라서 대부분의 데이터는 UDP 소켓을 통해 전송되며 전송되지 않은 데이터 집합만 TCP를 통해 전송된다. 빠르게 움직이는 시장에서, 재전송과 관련된 지연은 종종 바람직하지 않으며, 기회를 놓치거나 나쁜 거래를 초래합니다.

FAST 작동 방식

이미 알고 있듯이 FIX 프로토콜은 키 = 값 쌍으로 구성된 일련의 필드입니다. 문자열 형식이 기본적으로 중복될 뿐만 아니라 각 메시지에는 필드 이름 및 “=” 문자와 같은 중복 요소가 있을 수 있습니다. FAST는 전체 메시지 구조를 설명하는 템플릿을 사용하여 중복을 제거합니다. 이 방법을 암시적 태그 지정이라고 합니다. 전송된 데이터의 FIX 태그는 “추적”일 뿐이므로 태그 = 값의 구문은 다음과 같이 변경됩니다.

템플릿은 연산자와 함께 구조화된 필드 세트를 설명합니다.
메시지의 필드 시퀀스는 템플릿의 태그 시퀀스와 일치합니다.
데이터 변경 사항만 메시지에 전송됩니다.

각 태그 값은 바이트 단위로 고정된 길이를 가집니다. 특정 필드의 길이와 필드가 메시지에 배치된 순서를 알면 메시지에서 이러한 필드의 값을 식별하는 것이 어렵지 않습니다. 따라서 템플릿을 사용하면 중복 문자를 전송할 필요 없이 데이터 자체만 직접 전송할 수 있습니다. 이 인코딩을 단순 이진 인코딩 또는 SBE라고 합니다. 그러므로 메시지 인코딩과 디코딩은 문자 프로토콜보다 대기 시간이 훨씬 짧다. 해당 필드는 메시지에서 고정된 위치에 있으므로 원하는 값에 훨씬 쉽게 액세스할 수 있습니다. 메시지 시작에 상대적인 간격띄우기 및 값 길이만 알면 됩니다. 태그 및 FIXML과 달리 SBE 메시지는 자체 설명이 되지 않습니다. 메시지를 제어하는 템플릿을 식별하기 위해 최소 헤더가 있는 데이터만 네트워크를 통해 전송됩니다. 메시지 구조를 설명하는 메타데이터(템플릿)는 주 통신 채널 외부에서 교환됩니다. 필요한 템플릿을 받은 후, 거래 서버는 연결된 세션의 프레임워크 내에서 어떤 형식으로 클라이언트에 데이터를 보낼지 알게 됩니다. 그러므로 데이터를 전송하기 전에, 시스템은 미래에 그들과 어떻게 소통할 것인가에 대해 서로 동의하게 된다. 메시지 스키마는 일반적으로 XML 형식으로 전송됩니다. 원하는 수의 메시지 템플릿을 포함할 수 있습니다. 템플리트는 메시지를 구성하는 필드를 설명합니다. 또한 스키마는 여러 필드에서 재사용할 수 있는 단순하고 복잡한 데이터 유형 목록을 제공합니다.

FIX 프로토콜을 위한 다양한 언어의 개방형 구현

Java – QuickFIX/J – http://www.quickfixj.org/

.NET/C# – QuickFIX/N – http://quickfixn.org/

FIX 메시지의 무료 온라인 분석기- FIX Parser – https://fix.aprics.net/

FAST를 위한 개방형 언어 구현

For C – FPL의 참조 구현- www.fixprotocol.org/fastdownload

For C# – FPL의 참조 구현 – www.fixprotocol.org/fastdownload

Java л д code – OpenFAST – www.openfast.org

www.sourceforge.net/projects/openfastdotnet/

C++ – QuickFAST – www.quickfast.org

Golang – goFAST – www.github.com/co11ter/goFAST

기타 프로토콜 FIX 인코딩

FIX 커뮤니티는 또한 FIX 프로토콜과 다음과 같은 다른 데이터 직렬화 프로토콜 간의 표준 매핑을 개발하였다:

JSON
Google (Protocol buffers)

|ASN.1

FIX/FAST 프로토콜 응용 영역

약어는 원칙적으로 정확히 두 단어와 함께 발생한다. 무역 거래소에서 다양한 금융 정보를 얻는 데 사용됩니다. 금융상품(가격, 볼륨 등), 시세, 모든 거래, 지수 및 모든 비개인 애플리케이션에 대한 정보 표. 거래소에 따라 수집된 데이터 집합이 달라질 수 있습니다. 기본 FIX/FAST는 다음과 같습니다.

거래를 위한 개인 상인들
프로그래머들이 이 기술을 기반으로 제품을 만듭니다. 예를 들어 FIX API Trading 플랫폼, 서로 다른 교환, 거래 시스템, 데이터 수집 시스템 및 통계와 같은 커넥터가 있습니다.
교환 간의 정보 교환
다양한 정보 기관에 대한 최신 데이터 확보

가장 일반적인 용도는 고주파 트레이더들이 직접 시장 접근(DMA)을 통해 다른 시장 참여자들에 비해 우위를 점하는 것이다. 이 프로토콜은 거래소, 은행, 외환중개사가 거래 생태계에 접목시킬 수 있다. 흔히 알려진 자료에 따르면 암호화폐 거래소는 이 기술을 사용하지 않는다. 역사적으로 이들 거래소는 시장 정보를 얻기 위해 WebSocket 연결을, 트레이더들의 거래 서버에 직접 연결을 제공하기 위해 거래 작업을 수행하기 위해 HTTP rest API 연결을 주로 사용한다. WebSocket 기술이 여전히 TCP 연결과 비슷한 속도라면 HTTP rest API는 많은 손실을 입는다.