외환API와 Reject 메시지

1.
외환API. 기재부가 API라는 표현을 사용한 이유가 무엇인지 알 수 없지만 OpenAPI와 같은 표현들이 각광을 받으면서 기재부도 무언가 디지탈흐름에 편승하는 느낌을 주기 위해 사용하지 않았을까 합니다. 외환API는 서울외국환중개나 한국자금중개같이 외국환중개회사들이 제공하는 FIX 서비스입니다. 서울외국환중개가 FIX 서비스를 제공하고 있고 자금중개는 차세대프로젝트를 하면서 관련한 서비스를 제공할 계획입니다.

지난 몇 달동안 외환API와 관련한 작업을 하였습니다. 모 은행이 진행하는 FX 프로젝트에 참여하여 외환API와 관련한 FIX 시스템을 개발하는 업무로 자체로 보유하고 있는 ZeroFIX를 서울외국환중개의 FIX 규격에 맞추고 Kx Platform과 연결할 수 있도록 하였습니다. 원래 ZeroFIX는 자체적으로 HiperM이라는 메시징미들웨어를 사용합니다. HiperM을 적용하였던 부분을 걷어내고 Kx Platform이 제공하는 Messaging 개념을 도입할 계획었습니다.

kdb+를 금융업무에 적용해보며 느낀 점에서 소개하였던 Technical Whitepaper C API for kdb+를 판단하여 쉽게 끝낼 수 있는 업무로 이해했습니다.혹시나가 역시나였습니다. 문서가 제공한 방법이 현실에서 먹히지 않았습니다. Pub/Sub와 관련하여 문서가 제공한 가이드입니다.

위에서 핵심은 .u.sub 함수입니다. 이 함수를 지원하지 않더군요. 위 함수를 사용하려면 관련한 q 라이브러리가 있어야 하는데… Kx Platform은 문서와 완전히 다른 구조를 택하고 있었습니다. 오히려 AquaQ라는 회사가 제공하는 Tor라는 플랫폼을 보면 관련한 라이브러리가 있습니다.

pubsub.q

우여곡절을 겪었지만 가장 단순한 방식으로 문제를 해결하여 개발을 하였습니다.

2.
이번에 작업을 하면서 서울외국환중개가 배포한 SMB FIX API Streaming v1.03을 살폈습니다. 외국환중개시스템이 복잡하지 않기때문에 FIX 메시지도 복잡하지 않습니다. FIX Protocol 4.4를 기반으로 하여 Session Message는 Logon, Logout, TestRequest, Heartbeat, ResendRequest, SequenceReset,Reject를 지원하고 Application Message는 MarketDataRequest, MarketDataSnapshotFullRefresh, MarketDataRequestReject, NewOrder, OrderCancelRequest, OrderCancelReject, OrderStatusRequest,ExecutionReport를 지원합니다.

문서를 보면서 가장 이상했던 점은 Reject 메시지입니다. 문서상의 Reject 정의입니다.

A reject message is sent when one party receives a malformed FIX message. The reject message contains a reference to the malformed message, along with a description of the invalid field.

FIX Protocol 4.4를 보면 Reject와 관려난 메시지에 두 종류가 있습니다. Reject <3> message – FIX 4.4 – FIX Dictionary입니다.

FIX 4.4 : Reject <3> message

The Reject <3> message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. MsgType <35>=&) which successfully passes de-encryption, CheckSum <10> and BodyLength <9> checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.

또다른 Reject 메시지는 Business Message Reject message – FIX 4.4 – FIX Dictionary입니다.

FIX 4.4 : Business Message Reject message

The Business Message Reject message can reject an application-level message which fulfills session-level rules and cannot be rejected via any other means. Note if the message fails a session-level rule (e.g. body length is incorrect), a session-level Reject <3> message should be issued.

같은 Reject이지만 세션 메시지인지, 어플리케이션 메시지인지 구분에 따라 용도를 달리합니다. 예를 들어서 “58=Field 88 missing” 와 같은 오류가 거부처리한다고 할 경우 FIX Protocol 4.4를 따르면 Business Reject를 사용하여야 합니다. 그런데 SMBS 규격에서는 위 Reject 메시지들이 하나로 합쳐서 Session 메시지로 사용하고 있습니다. 사실 문제는 아닙니다. 서로 협의하여 정하면 문제가 없습니다. 다만 두가지 Reject를 구분하는 FIX를 운용하는 회사가 그렇지 않은 회사와 연결하고자 할 때 업무와 연결한 부분에 수정이 필요합니다.

어플리케이션 메시지중 Order Cancel/Replace Request message – FIX 4.4 – FIX Dictionary을 사용하지 않은 점이 특징이었습니다. 정정주문이 없는 주문… 참 이상한 시스템입니다. 아니면 이상한 시장입니다.

Leave a Comment

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.