HedgeTerminal 패널을 이용하여 MetaTrader 5로 양방향 매매와 포지션 헤징하기, 파트 1

목차

• 들어가며
  • 이 문서에서 다루는 것은 무엇인가?
  • 이 문서를 제대로 읽는 법
  
  
• 챕터 1. 양방형 매매 정리론
  • 1.1. 양방향 매매를 MetaTrader 5로 다루기
  • 1.2. 주문 페어링하기 - 헤징과 통계의 기초
  • 1.3. MetaTrader 5 순 포지션과 HedgeTerminal 포지션 간의 관계
  • 1.4. 양방향 매매를 구현하기 위한 알고리즘 요구조건
  
  
• 챕터 2 헤지 터미널 설치, 첫 기동
  • 2.1. 헤지터미널(HedgeTerminal) 설치
  • 2.2. 3단계 설치 설치 다이어그램 및 예상가능한 문제
  • 2.3. HedgeTerminal과 친구 되기, 첫 기동
  • 2.4. 금융 작업 헤징 및 계산
  • 2.5. 원 클릭 매매
  • 2.6. 손절매 및 이익 실현, 추적 손절매(트레일링 스탑)
  • 2.7. 리포트 생성하기
  • 2.8. 통화 스왑 프레젠테이션
  • 2.9. 마지막 줄
  • 2.10. HedgeTerminal 테이블의 외관 변경시키기
  • 2.11. 아직 구현하지 못한 계획들
  
  
• 챕터 3 헤지 터미널의 본네트 밑에 있는 것 사양 및 작동 원리
  • 3.1. 글로벌 및 로컬 컨투어 정보 본문, 전달, 및 보존
  • 3.2. 글로벌 및 로컬 정보 저장하기
  • 3.3. 손절매 및 이익 실현 레벨 주문 시스템의 문제와 OCO 주문
  • 3.4. OCO 주문이 양방향 포지션 보호 문제를 해결할 수 있을까?
  • 3.5. 주문 초기화용 링크 보관하기
  • 3.6. HedgeTerminal 작업의 한계
  • 3.7. 거래 페어링 및 행동 판단 메커니즘
  • 3.8. 거래 분리 및 연결 - 주문 산술의 기초
  • 3.9. 주문 및 매매 가상화
  • 3.10. 주문 가리기 메커니즘
  • 3.11. 적응 메카니즘
  • 3.12. 퍼포먼스와 메모리 사용
  
  
• 마치며

들어가며

지난 18개월 동안 MetaQuotes는 MetaTrader 4 및 MetaTrader 5 플랫폼을 통합 거래 생태계로 통합하는 전면적인 작업을 수행했습니다. 이제 두 플랫폼 모두 외부 개발자이 개발한 다양한 제품을 제공하는 앱 마켓인 Market을 공유하게 되었습니다. 양측 플랫폼의 컴파일러도 일체화 되었습니다. 그러한 작업의 결과, 양측 플랫폼 모두 MQL5를 기반으로 하는 공통 컴파일러와 하나의 프로그래밍 언어(사용 중인 플랫폼에 따라 다른 기능 세트가 있는 MQL)를 갖는 형태가 되었습니다. 코드 베이스(Code Base)에 있는 오픈 소스 코드들도 전량 수정되었으며 일부는 새 컴파일러와 호환되도록 조정되었습니다.

일련의 과정은 매매 파트만 빼고 양측 플랫폼을 하나로 만든 과정입니다. MetaTrader 4와 MetaTrader 5의 매매 모델은 매매 환경의 대부분이 공유되는데도 불구하고 여전히 근본적으로 호환되지 않습니다. MetaTrader 4는 주문 시스템을 통해 매매 포지션의 개별 관리를 용이하게 합니다. 이는 4버전에서 양방향 매매를 간단하고 쉽게 만들어주는 특수한 프로그램이기도 합니다. 한편 MetaTrader 5 측은 순 포지션의 합산을 나타내는 주문 시스템에 초점을 두고 있습니다. 5버전의 주문들은 단순히 금융 자산을 매수하거나 매도하기 위한 명령에 지나지 않습니다.

두 플랫폼의 성질 차이는 수많은 토론과 논쟁의 근원이 되었습니다. 하지만 뾰족한 결론은 나지 않았습니다. 불행히도 MetaTrader 5가 출시된 이후 MetaTrader 4와 같이 트레이더의 의무를 양방향 포지션으로 제시할 수 있는 단일 작업 솔루션이 만들어지지 않았습니다. 다양한 솔루션들이 수많은 문서에서 제안되었지만, 그 중 어느 것도 대규모로 편리하게 사용할 수 있을 만큼 유연하지 않았습니다. 더군다나, 이러한 제안 중에서 고려해야할 것이 많은 거래소 거래 모델에 적합하지 않았습니다.

이 문서가 MetaTrader 플랫폼의 4번째와 5번째 버전의 팬 사이의 해묵은 논쟁을 해결할 것입니다. 이는 철저한 프로그램 사양의 형태로 보편적인 솔루션을 제공하고 본 사양에 의해 구현된 정확한 프로그램 솔루션을 제공할 것입니다. 이 문서에서는 MetaTrader 4에서와 같이 양방향 포지션으로 트레이더의 의무를 보여줄 수 있는 시각 패널과 가상화 라이브러리 HedgeTerminal에 대해 설명합니다. 동시에 HedgeTerminal의 기본 모델은 매매 주문 체결의 특성을 고려합니다. 즉, 장외 외환거래 시장과 중앙 집중식 거래소(예: Moscow Exchange의 파생 상품 섹션에서의 파생 상품 증권 거래) 모두에서 성공적으로 구현될 수 있습니다.

HedgeTerminal은 MetaTrader 5 내의 새로운 완전 기능 트레이딩 터미널입니다.. 가상화 메커니즘을 통해 현재 포지션의 표시를 변경하여 트레이더 또는 트레이딩 봇이 개별 매매 포지션을 관리할 수 있도록 합니다. 포지션의 수나 방향은 중요하지 않습니다. 저는 지금 가상화에 대해 이야기하고 있다는 사실을 강조하고 싶습니다. 가상화는 트레이더의 의무 표시를 변환시키는 특정 메커니즘이지, 트레이더의 질적 특징을 변화시키는 것이 아닙니다.

가상화는 트레이더의 금융 활동의 결과를 왜곡하는 것이 아니라 일련의 활동을 다른 방식으로 표현하는 것입니다. HedgeTerminal은 MetaTrader 5 트레이딩 환경과 MQL5 프로그래밍 언어에 기반을 두고 있습니다. 이 터미널은 새로운 거래 정보를 터미널로 가져오는 것이 아니라 현재 거래 환경을 다른 각도에서 볼 뿐입니다. 즉, HedgeTerminal은 본질적으로 MetaTrader 5이며 기본 응용 프로그램입니다. 이 둘을 굳이 구분할 수는 있지만 굳이 따지자면 HedgeTerminal은 작은 MetaTrader 5 응용 프로그램 중 하나라고 봐야 더 적합할 것 같습니다.

HedgeTerminal과 그 가상화의 가능성은 세 가지 패러다임을 기반으로 합니다.

1. 개념적으로, 포지션 표현을 독립적인 양방향 매매 트랜잭션으로의 완전 전환 보장이 가능합니다. 위의 말은 즉 거래소 매매를 위해 설계된 플랫폼을 포함한 일부 외부 거래 플랫폼에서 양방향 포지션을 관리하는 수단이 있다는 사실을 증명합니다.
2. 사용자 레벨의 MetaTrader 5의 트레이딩 모델은 서로간에 단방향 주문 링크를 생성할 수 있게 해줍니다. 계산에 따르면 특정 방식으로 설계된 링크는 충돌에 강합니다. 또한 양방향 트랜잭션은 이력이 훼손되거나 불가항력적인 상황이 발생하더라도 수정될 수 있고, 제대로 된 재무 결과를 산출할 수 있습니다.
3. MQL5의 고급 API를 사용하면 MQL5와 MetaTrader 5 터미널 사이에 ID 기호를 넣을 수 있습니다. 풀어 쓰자면, MQL5는 MetaTrader 5의 거의 모든 것을 액세스 할 수 있다는 것입니다. 예를 들어, HedgeTerminal과 같은 MetaTrader 5 터미널 내부에 나만의 터미널을 만들 수 있다는 것입니다.

이 문서에서는 그러한 기반 알고리즘과 HedgeTerminal의 작동 방식에 대해 알아볼 것입니다. 일관된 양방향 거래를 보장하는 사양과 알고리즘도 이 문서에서 자세히 설명합니다. HedgeTerminal을 사용하기로 결정했던지 아니면 자신의 거래 알고리즘을 관리하기 위해 자체 라이브러리를 만들기로 결정했던지 간에 관계 없이 이 문서와 후속편에서 꽤나 유용한 정보들을 얻을 수 있을 것입니다.

이 문서는 딱히 프로그래머들만을 초점으로 두고 쓰이지 않았습니다. 설령 당신이 프로그래밍 경험이 없더라도 충분히 이해가능할 것입니다. 이 문서에서는 딱히 MQL 소스코드를 위주로 설명하지 않기 때문입니다. 모든 소스 코드는 작동 원리와 데이터 구성을 도식적으로 나타내는 다이어그램, 표 및 그림으로 대체되었습니다. 프로그래밍 원칙을 잘 이해하더라도 코드의 일반적인 패턴을 분석하는 것보다 보는 것이 훨씬 쉽다는 것을 제 경험으로 알 수 있습니다.

이 문서의 두 번째 부분에서는 Expert Advisors와 HedgeTerminalAPI 시각화 라이브러리의 통합에 대해 이야기하고 프로그래밍이 포함될 것입니다. 그러나 그 경우에도 특히 초보 프로그래머를 위해 코드의 인식을 단순화하기 위해 모든 작업이 수행되었습니다. 예를 들어, HedgeTerminal은 객체 지향 애플리케이션이지만 클래스와 같은 객체 지향 구성은 사용되지 않습니다.

이 문서를 제대로 읽는 법

이 문서는 꽤 깁니다. 문서가 길어진 것의 장점으로는, 여러분이 이 주제에 대해 생각날만한 어지간한 질문에 대한 해답이 전부 이 문서 안에 들어있다는 것이고. 단점으로는 필요할 때마다 원하는 자료만 짚고 넘어가고싶은 사용자가 상당히 많은데, 이 문서에서는 자료를 전부 총체적으로 짚고 넘어간다는 것이 있습니다. 책들과 마찬가지로 모든 챕터의 짧은 요약본을 첨부할 것이니 그걸 보시고 그 챕터를 읽을지 말지 선택하시면 됩니다.

• 챕터 1, 파트 1. 양방향 트레이딩 조직의 이론. 이 장은 HedgeTerminal의 주요 아이디어를 포함합니다. 양방향 거래 구성에 대한 심층적인 정보를 원하지 않는다면 이 장으로 HedgeTerminal 운영의 일반적인 원칙을 이해하기에 충분합니다. 이 챕터는 모든 독자에게 추천드립니다.
  
  
• 챕터 2, 파트 1. HedgeTerminal 설치, 첫 번째 실행 이 장에서는 HedgeTerminal의 시각적 패널 실행 및 설정에 대해 설명합니다. HedgeTerminal의 시각적 패널을 사용하지 않을 생각이라면 이 장을 건너뛸 수 있습니다. 그러나 HedgeTerminalAPI 라이브러리를 사용하려는 경우 이 장의 섹션 2.1 및 2.2를 꼭 읽으시기 바랍니다.. HedgeTerminal 인스톨러를 집중으로 다룹니다. 설치 프로그램은 모든 HedgeTerminal 제품의 공통 구성 요소입니다.
  
  
• 챕터 3, 파트 1. HedgeTerminal의 본네트 아래에서 벌어지는 일. 작동의 사양 및 원리. 이 장에서는 HedgeTerminal의 내부 배열, 알고리즘 및 내부 데이터 구성을 강조합니다. 양방향 거래에 관심이 있는 독자들은 이 장에서 유익한 정보를 얻을 수 있습니다. 자체 가상화 라이브러리를 개발하고 많은 봇을 동시에 사용하는 전문 알고리즘 트레이더에게도 이 장이 유용하다는 것을 알 수 있습니다.
  
  
• 챕터 1, 파트 2. HedgeTerminal와 그 내부 패널, 그리고 Expert Advisor 간의 소통. 이 챕터는 알고리즘 매매를 전문적으로 다루는 분들이 특히 관심가지실만한 내용을 다루고 있습니다. HedgeTerminal 라이브러리와 거래 봇의 아키텍처를 사용하는 일반적인 작업 원칙을 설명합니다.
  
  
• 챕터 2, 파트 2. API HedgeTerminal에 대한 문서. HedgeTerminalAPI 라이브러리의 기능 사용에 대한 문서를 포함합니다. 이 챕터는 때때로 참조할 수 있는 문서 목록으로 활용될 목적으로 작성되었습니다. 쓸 데 없는 토론과 과도한 텍스트가 없습니다. 이 장에는 함수, 구조 및 열거형의 프로토타입과 사용에 대한 간단한 예만 포함되어 있습니다.
  
  
• 챕터 3, 파트 2. 비동기성 거래 작업의 기본. HedgeTerminal은 비동기성 작업을 사용합니다. 이 챕터에서 비동기성 작업을 사용하는 경험을 쌓을 수 있습니다. 이 챕터를 통해 독자는 HedgeTerminal을 사용할 계획이 있건 없건간에 유용한 정보를 얻어갈 수 있습니다.
  
  
• 챕터 4, 파트 2. MetaTrader 환경에서 멀티스레딩의 기본. 이 장에서는 멀티스레딩이 무엇인지, 어떻게 배열하는지, 어떤 데이터 구성 패턴을 사용할 수 있는지 설명합니다. 챕터 3처럼 모든 MetaTrader 유저라면 멀티스레딩에 대한 정보를 얻어갈 수 있습니다.

이 문서가 부디 쭉 다 읽을 만큼 재미있게 느껴지기를 바랍니다.

챕터 1 양방향 매매 정리론

1.1. 양방향 매매를 MetaTrader 5로 다루기

"모스크바 거래소 파생상품 시장의 사례를 통한 환율의 가격 책정 원칙" 문서에서는 시장 참여자의 환율 형성 및 재무 결과 계산 방법의 뉘앙스를 자세히 설명합니다. 모스크바 거래소의 가격 책정 및 계산은 FOREX 거래에서 허용되는 개념 및 계산 방법과 크게 다릅니다.

전반적으로 교환 가격의 형성은 더 복잡하며 Forex 및 MetaTrader 4 터미널에서 거래할 때 숨겨진 중요한 세부 정보가 많이 포함되어 있습니다.

예를 들어 MetaTrader 4에서는 트레이더의 주문을 체결한 딜이 숨겨져 있지만 MetaTrader 5에서는 이러한 정보를 열람 가능합니다. 반면 MetaTrader 5의 자세한 거래 정보가 언제나 필요한 것은 아닙니다. 이는 경험이 적거나 미숙한 프로그래머들에게는 혼동을 줄 수도 있습니다. 예를 들어 MetaTrader 4에서 체결된 주문의 가격을 찾으려면 "Price" 열에서 해당 값을 조회하기만 하면 됩니다. MQL4 프로그래밍 언어에서는 OrderOpenPrice() 함수를 호출하기만 하면 됩니다. MetaTrader 5에서는 주문을 체결한 모든 딜을 찾은 다음 이를 검토하고 가중 평균 가격을 계산해야 합니다. 바로 이 가격이 주문 체결의 가격입니다.

MetaTrader 5에서는 매매 환경을 확장해서 표현하다보니 정보를 분석하기 위해 추가적인 노력이 필요한 상황이 발생합니다. 이는 합리적인 의문을 들게 합니다.

MetaTrader 4에서처럼 MetaTrader 5에서도 거래 프로세스를 간단하고 명확하게 만들고 필요한 모든 거래 세부 정보에 편리하게 액세스할 수 있는 방법이 있습니까? MetaTrader 4와 같은 간단한 방법으로 MetaTrader 5를 사용하여 양방향 교환 거래를 주선하는 방법이 있다면? - 답은: "있습니다"!

이것이 어떻게 가능한지 이해하기 위해 MetaTrader 4 및 MetaTrader 5 터미널의 기능 다이어그램을 참조하십시오.

1번 그림. MetaTrader 4와 MetaTrader 5의 기능

보시다시피 "MetaTrader 5" 집합에는 "MetaTrader 4" 부분집합이 포함되어 있습니다. MetaTrader 4에서 가능한 모든 것이 MetaTrader 5에서 수행될 수 있음을 의미하지만 그 반대는 아니라는 의미입니다. MetaTrader 5의 새로운 기능은 필연적으로 거래 정보 표시의 양과 복잡성을 증가시킵니다. 이 어려움은 MetaTrader 5 환경에서 작동하는 특별 보조 프로그램에 위임할 수 있습니다. 이러한 프로그램은 터미널 기능을 동일한 수준으로 유지하면서 복잡성을 처리할 수 있습니다. 그런 프로그램들 중 하나인 HedgeTerminal이야말로 본 챕터의 하이라이트입니다.

HedgeTerminal은 MetaTrader 5 터미널 내부의 본격적인 매매 터미널입니다. HedgeTerminal은 MetaTrader 5 매매 환경을 사용하고 MQL5 언어를 이용하여 구축한 편리한 그래픽 인터페이스를 지니고 있습니다. HedgeTerminalUltimate패널 및 독립 알고리즘 (Expert Advisor, 스크립트, 인디케이터)과의 상호작용을 위한 HedgeTerminalAPI 특수 인터페이스 등.

MetaTrader 4는 양방향 포지션 또는 잠금 주문을 사용할 수 있는 기능을 제공합니다. MetaTrader 5에도 그러한 기능이 있지만 명시적이지는 않습니다. 이 기능은 어떤 애드온 프로그램, 즉, HedgeTerminal을 사용하여 활성화할 수 있습니다. HedgeTerminal은 MetaTrader 5을 기반으로 두고 모든 기능을 가짐과 동시에, MetaTrader 4의 주문과 유사하게 매매 및 주문 정보를 수집하여 사용합니다.

이러한 포지션은 전체 또는 부분 잠금 주문일 수 있습니다(활성화된 롱 포지션과 숏 포지션이 동시에 존재할 때). 그런 포지션들을 유지하는 것 자체가 HedgeTerminal의 목적은 아닙니다. HedgeTerminal의 주요 목표는 거래 정보들을 쉽게 분석, 관리 및 액세스할 수 있는 통합 그룹(포지션)으로 통합하는 것입니다. HedgeTerminal에 양방향 포지션이 존재할 수 있는 이유는 이것이 매우 편리하기 때문입니다. 여러 트레이더가 하나의 계정에서 거래하거나 둘 이상의 전략이 사용되는 경우 분할 거래 조치를 마련해야 합니다.

또한 부분 주문 실행, 포지션 롤오버, 변동 마진 계산, 통계 및 기타 여러 가지와 같은 거래소 거래에서 많은 뉘앙스를 고려해야 합니다. HedgeTerminal은 이러한 문제를 해결하기 위해 개발되었습니다. HedgeTerminal은 유저나 Expert Advisor에게 MetaTrader 4와 비슷하면서도 교환 환경에서 정상작동하는 고레벨 인터페이스를 제공합니다.

1.2. 주문 페어링하기 - 헤징과 통계의 기초

매매 기법과 알고리즘을 일관되게 관리할 수 있으려면 어떤 매매 행위가 어떤 알고리즘에 해당하는지 확실히 알아야 합니다. 제가 "확실히"라는 단어를 강조한 이유는, 만약에 아주 미약한 수준이라도 실수할 확률이 있다면, 늦으나 빠르나 포지션 관리에 문제가 생길 것이기 때문입니다. 결과적으로 통계가 어지럽혀지고, 한 계좌로 여러 알고리즘을 관리한다는 발상 자체가 망가집니다.

매매 활동의 안정적인 분리는 이하의 두 가지 기본 가능성을 기반으로 합니다.

1. 두 매매 주문을 함께 결합 또는 "페어링"하여 둘 중 어느 주문이 개별 (가상) 포지션을 개방하고 있으며, 어느 쪽이 해당 포지션을 청산 중인지 언제건 알아낼 수 있어야합니다.
2. 페어링용 주문을 분석하는 알고리즘은 완전히결정론적이어야 하며 모든 프로그램 모듈에 대해 통합되어야 합니다.
   

알고리즘 결정론에 대한 두 번째 요구 사항은 아래에서 자세히 고려됩니다. 이제 전자에 집중해봅시다.

주문이란 매수나 매도를 하라는 명령입니다. 주문이란 매직 넘버와 주문 번호, 필요한 가격, 개봉 조건과 같은 주요 정보 외에도 더 많은 정보 "필드"를 포함하는 개체입니다.

MetaTrader 5의 이러한 필드 중 하나는 "Order Magic"입니다. 이는 "매직 넘버"라고도 하는 개별 고유 번호로 이 주문을 표시할 수 있도록 트레이딩 봇 또는 Expert Advisor에 사용되는 지정된 필드입니다. 이 필드는 수동 거래에서 사용되지 않지만 거래 알고리즘에서는 매우 중요합니다. 거래 알고리즘이 이 필드의 값을 분석할 때 문제의 주문이 해당 주문 또는 다른 알고리즘에 의해 배치되었는지 항상 확인할 수 있기 때문입니다.

예시를 들여다 봅시다. 익숙한 롱 포지션을 개설한 후 얼마 후 청산해야 한다고 가정해 보겠습니다. 그를 위해서 우리는 2개의 주문을 해야합니다. 먼저 것으로는 이 롱 포지션을 개방할 것이고, 두번째 것으로 청산할 것입니다.

2번 그림. 순 포지션을 형성하는 주문들

마켓에 보내는 순간 두번째 주문의 "Order Magic" 필드에 첫번째 주문의 매직넘버를 적으면 어떻게 될까요?

나중에 이 주문의 필드를 읽었을 때 값이 첫 번째 주문의 번호와 같으면 두 번째 주문은 첫 번째 주문과 관련이 있고 반대, 즉 청산 주문이라고 확실히 말할 수 있습니다.

도표 상 페어링은 다음과 같이 보입니다.

3번 그림. 주문 페어링

두 번째 주문에는 첫 번째 주문에 대한 링크가 포함되어 있으므로 이러한 주문은 페어링이라고 할 수 있습니다. 새 포지션을 개방하는 첫 번째 주문은 개시 또는 개방 주문이라고 불립니다. 두번째 유형의 주문은 청산이라고 불립니다.

이러한 주문 쌍을 포지션이라고 할 수 있습니다. MetaTrader 5의 "포지션" 개념과의 혼동을 피하기 위해 이러한 쌍을 이루는 포지션을 양방향, 헤징 또는 HedgeTerminal 포지션이라고 부릅니다. MetaTrader 5 포지션은 순 포지션 혹은 MetaTrader 5 클래식 포지션이라 불릴 것입니다.

보시다시피 HedgeTerminal 포지션의 수와 방향은 클래식 포지션과 달리 어느쪽일 수도 있습니다. 다른 주문에서 참조하지 않는 실행된 주문이 있는 경우 어떻게 합니까? 이러한 주문은 활성 양방향 포지션으로 표시될 수 있습니다. 실제로 이 주문에 대한 링크가 포함된 반대 주문이 들어오면 첫 번째 주문을 청산하는 주문이 됩니다. 이러한 주문은 쌍을 이루어 청산된 양방향 포지션을 만들 것입니다. 두 주문의 양은 동일하고 방향이 반대이기 때문입니다.

자 이제 HedgeTerminal에서는 포지션이란 어떤 의미인가 정의해봅시다.

실행된 주문이 다른 주문에서 참조되지 않는 경우 HedgeTerminal은 해당 주문을 활성 양방향 포지션으로 취급합니다.

하나의 실행된 주문이 다른 실행된 주문에 의해 참조되는 경우 이러한 두 개의 주문이 쌍을 이루어 HedgeTerminal에서는 하나의 통합된 과거 또는 청산된 양방향 포지션으로 간주됩니다.

실제로 HedgeTerminal의 페어링 주문은 모든 주문이 최소 하나의 딜을 생성하는데 교환 거래에서는 그런 딜이 많을 수 있기 때문에 더욱 복잡한 편입니다. 일반적으로 거래 프로세스는 다음과 같이 나타낼 수 있습니다. 트레이더는 MetaTrader 5 터미널을 통해 새 포지션을 개방하도록 주문합니다. 거래소는 하나 이상의 딜을 통해 이 주문을 실행합니다.

딜에는 주문들과 유사하게 추가 정보를 위한 필드가 있습니다. 이러한 필드 중 하나에는 거래가 체결된 기준으로 주문 ID가 포함됩니다. 이 필드에는 특정 거래가 속한 주문에 대한 정보가 포함됩니다. 반대로 알아보는 것은 불가능합니다. 이 주문 자체는 어떤 거래들이 이 주문에 속하는지 알 수 없기 때문입니다. 이는 주문할 때 어떤 거래가 주문을 체결할지 그리고 주문이 체결되긴 할 것인지 확실히 알 수 없기 때문에 발생합니다.

이러한 방식으로 행동의 인과관계 또는 결정론이 관찰됩니다. 거래는 주문을 참조하고 주문은 서로를 참조합니다. 이러한 구조는 단일 링크드 리스트로 나타낼 수 있습니다.

개시 주문 소속으로 체결된 거래는 MetaTrader 5에서 클래식 포지션을 생성하고 반대로 청산 주문에 속하는 거래는 이 포지션을를 청산합니다. 아래 그림에서 이런 쌍을 나타냈습니다.

4번 그림. 주문, 거래 및 교환 간의 관계 다이어그램

관계의 방향은 트레이더의 행동 기록으로 결정론적 시스템인 HedgeTerminal을 구축하는 데 매우 중요한 요소이기 때문에 이 다이어그램에 대한 자세한 분석으로 다시 돌아가겠습니다.

1.3. MetaTrader 5 순 포지션과 HedgeTerminal 포지션 간의 관계

HedgeTerminal의 관점에서 볼 때 동일한 볼륨을 가진 두 개의 반대 주문은 두 개의 다른 포지션이 될 수 있습니다. 이 경우 순 포지션은 0이 됩니다. 이것이 HedgeTerminal이 MetaTrader 5에서 개방된 실제 순 포지션에 대한 정보를 사용하지 않는 이유입니다. 따라서 HedgeTerminal의 포지션은 MetaTrader 5의 포지션과 연결되지 않습니다. 현재 순 포지션이 확인되는 유일한 순간은 HedgeTerminal이 시작되는 순간 뿐입니다. 반대 활성 포지션의 총 거래량은 실제 순 포지션 값과 동일해야 합니다.

그렇지 않은 경우 프레임의 경고 느낌표가 HedgeTerminal에 나타나 HedgeTerminal의 포지션과 MetaTrader 5의 포지션이 같지 않음을 나타냅니다. 이 비대칭은 HedgeTerminal의 효율성에 영향을 미치지 않지만 더 정확한 작업을 위해서는 제거해야 합니다.

대부분의 경우 사용자가 제외된 주문 ExcludeOrders.xml 파일을 편집하는 동안 오류가 발생할 때 나타날 수 있지만 서버의 주문 및 거래 내역이 손상되어도 이 표시가 나타날 수 있습니다. 어쨌든 이러한 불일치는 ExcludeOrders.xml 파일을 통해 구현된 제외 메커니즘으로 제거할 수 있습니다.

1.4. 양방향 매매를 구현하기 위한 알고리즘 요구조건

양방향 거래를 구현하는 알고리즘에는 다소 빡빡한 요구 사항이 부과됩니다. HedgeTerminal을 개발할 때에는 반드시 이 요구 사항들이 충족되어야합니다. 그렇지 않으면 HedgeTerminal이 스토캐스틱방식으로 작동하는 프로그램으로 바뀌어버립니다. 프로그램은 "동일한 확률로 작동하거나 작동하지 않을 수 있는 또 다른 솔루션"이 될 것입니다.

다음은 개발을 위해 지정된 몇 가지 요구 사항입니다.

1. 트레이더들의 양방향 포지션의 표현은 신뢰할 수 있어야 합니다. HedgeTerminal에서 구현된 모든 아이디어는 비즈니스 로직에 모호함이나 잠재적 오류를 초래해서는 안 됩니다. 만약 어떠한 자산이나 기회가 이 조건들을 만족시키지 못한다면 얼마나 편하건 간에 관계 없이 그 발상은 사용되지 않을 것입니다.
2. 모든 알고리즘은 가능한 한 MetaTrader 5 거래 환경을 기반으로 해야 합니다. 파일에 추가 정보를 저장하는 것은 반드시 필요한 경우에만 허용됩니다. 가상화 알고리즘은 거래 환경에서 대부분의 정보를 받아야 합니다. 이 속성은 대부분의 변경 사항이 서버를 통해 전달되므로 전 세계 어느 지점에서나 액세스할 수 있고, 그 결과로 전체 안정성 수준을 향상시킵니다.
3. 거래 환경 변환에 대한 모든 작업은 백에서 수행되어야 합니다. API HedgeTerminal 라이브러리의 복잡한 구성 및 초기화가 필요하지 않아야 합니다. 사용자는 "즉시" 응용 프로그램을 시작하고 예상한 결과를 받을 수 있어야 합니다.
4. HedgeTerminal 시각 패널은 가능한 한 MetaTrader 5 인터페이스에 일체화되어야하며, MetaTrader 4 및 5의 모든 사용자에게 친숙한 양방향 포지션 작업을 위한 간단하고 이해하기 쉬운 시각 도구를 제공해야 합니다. 즉, 시각 패널은 누구에게나 직관적이고, 명료하며, 단순해야 합니다.
5. HedgeTerminal의 시각적 패널은 알고리즘 트레이더의 높은 요구 사항을 고려하여 설계되어야 합니다. 예를 들어 패널을 구성할 수 있어야 하고 사용자가 모양을 변경할 수 있어야 하며 사용자 지정 모듈을 추가할 수도 있어야 합니다.
6. 외부 Expert와의 상호 작용을 위해 직관적이고 간단한 API(프로그램 인터페이스)를 제공해야 합니다. 외부 Expert와 HedgeTerminal 알고리즘 간의 상호 작용의 프로그램 부분은 사용자 정의 Expert와 MetaTrader 4/5 시스템 기능의 프로그램 상호 작용의 기존 표준과 완벽하게 맞아야 합니다. 실제로 HedgeTerminal API는 MetaTrader 4 및 MetaTrader 5 API의 하이브리드인 것으로 보입니다.
7. HedgeTerminal은 교환 주문 실행의 모든 뉘앙스를 고려하여 교환 환경에서 안정적인 작업을 보장해야 합니다. HedgeTerminal은 표준 문서 모스크바 거래소 파생상품 시장의 예를 통한 교환 가격 책정 원칙"을 기반으로 작성되었습니다. 이 문서는 원래는 HedgeTerminal에 대한 긴 문서의 일부였으며 나중에 볼륨 때문에 여러 독립 문서로 분할되었습니다. HedgeTerminal은 이 문서에서 논의된 발상을 프로그램으로 구현시킨 산물이라고 말할 수 있습니다.

이러한 아이디어 중 많은 부분이 서로 연결되어 있지 않습니다. 예를 들어, 거래소 거래에 반영되어야 하는 거래소 정보의 풍부함과 이러한 정보 표현의 단순성과 양립하기 어려운 면이 있습니다.

또 다른 숙제는 초보자 트레이더가 쉽게 사용할 수 있는 동시에 전문 알고리즘 트레이더에게 광범위한 기회를 제공할 수 있는 패널을 만드는 것이었습니다. 그럼에도 불구하고 결과를 평가하면 이러한 상호 배타적인 속성이 HedgeTerminal에서 성공적으로 구현되었음을 알 수 있습니다.

챕터 2. 헤지터미널(HedgeTerminal) 설치와 첫 기동

2.1. 헤지터미널(HedgeTerminal) 설치

우리는 이미 HedgeTerminal에서 실행된 모든 주문이 포지션으로 간주된다는 것을 알고 있습니다. 포지션은 청산된 기록 포지션을 만드는 두 쌍의 주문 또는 오픈 또는 활성 포지션을 만드는 언바운드 주문으로 구성될 수 있습니다.

HedgeTerminal이 설치되기 전에 거래 계좌에 여러 행동이 있었고 매매 내역에 체결된 주문이 많이 포함된 경우 HedgeTerminal의 관점에서 이러한 모든 주문은 링크가 생성되지 않았기 때문에 개방 포지션이 됩니다. 계좌 내역에 체결된 주문이 2~3개 포함되어 있어도 상관 없습니다. 수천 개의 포지션이 있다면 HedgeTerminal은 수천 개의 오픈 포지션을 생성할 것입니다. 그 포지션들로 뭘 할 수 있는가? 이러한 주문은 HedgeTerminal을 통해 시작 주문에 대한 링크가 포함된 반대 주문을 배치하여 "청산할" 수 있습니다. 그래도 단점이 있습니다. HedgeTerminal을 설치할 시점에 그런 포지션들이 너무 많으면 중개 수수료와 슬리피지 비용이 지불되기 때문에 트레이더가 망해버릴 여지가 존재합니다.

이를 피하기 위해 HedgeTerminal은 설치 초기에 전용 설치 마법사를 시작합니다. 여기에서 이 문제에 대한 다양한 솔루션이 제안됩니다. HedgeTerminal을 실행하고 이 마법사를 호출하여 작업을 자세히 설명하겠습니다. MetaTrader 5 Market에서 HedgeTerminalDemo를 다운로드하여 설치하십시오.

HedgeTerminalUltimate와 유사하게 Expert Advisor 형식을 가지고 있으며 "Navigator" 폴더에 있는 아이콘을 무료 차트로 끌어다 놓기만 하면 실행됩니다.

이 아이콘을 드래그하면 차트에서 Expert Advisor를 시작하도록 제안하는 표준 창이 나타납니다.

5번 그림. 기동 전 HedgeTerminal 창

이 단계에서 "Allow AutoTrading" 플래그를 설정하면 EA가 거래 조치를 수행할 수 있습니다. HedgeTerminal은 자체 매매 논리가 없기 때문에 당신의 주문을 따르지만 거래를 실행하려면 여전히 허가가 필요합니다.

모든 Expert Advisor가 거래를 시작하려면 MetaTrader 5에서 거래할 수 있는 개인 권한과 함께 Expert Advisors를 통한 거래에 대한 일반 권한이 패널에서 활성화되어야 합니다.

6번 그림. 자동화 매매 활성화상태

HedgeTerminal은 사용자가 길고 복잡한 구성을 피할 수 있도록 설계되었습니다.

그렇기 때문에 사용 가능한 모든 설정이 특수 XML 텍스트 파일에 포함되어 있습니다. HedgeTerminal에서 유일한 외적 패러미터는 다음 설정 파일의 실제 이름입니다.

7번 그림. HedgeTerminal 패널 설정창

이러한 설정의 특성과 변경 방법은 나중에 설명합니다.

"켜기"를 누르면 설치 프로세스 시작을 제안하는 헤지 터미널 설치 마법사가 시작됩니다. 설치 과정은 MetaTrader 4 및 MetaTrader 5 터미널의 공유 디렉토리에 몇 개의 파일을 만드는 것입니다.

HedgeTerminal은 다음과 같은 파일을 설치할 수 있는 권한을 요청합니다.

8번 그림. 설치 시작 다이얼로그

일부 파일을 컴퓨터에 설치하지 않으려면 "취소"를 누르십시오. 이 경우 HedgeTerminal은 작업을 마칩니다. 설치를 계속하려면 "확인"을 누르십시오.

이어질 대화 상자의 모양은 HedgeTerminal을 실행하는 계정에 따라 다릅니다. 거래 계정에서 거래가 체결된 적 없는 경우 HedgeTerminal은 작업을 완료합니다.

과거에 계좌를 체결한 적 있는 경우 HedgeTerminal은 다음 대화 상자를 표시합니다.

9번 그림. HedgeTerminal의 최초 실행을 감지하는 대화 상자

위 그림에서 HedgeTerminal은 5개의 활성 주문을 식별했습니다. 당신의 경우 그 수는 다를 것입니다(계정 수명 동안 체결된 주문의 총 수와 같을 가능성이 큽니다). 이런 주문들은 HedgeTerminal의 관점에서는 청산 주문과 쌍을 이루지 않으며 활성 포지션입니다.

HedgeTerminal에는 몇가지 옵션이 있습니다.

1. HedgeTerminal에서 다음 주문 제외: "HedgeTerminal에서 이 주문들을 숨길 수 있습니다... 주문을 숨기시려거든 '예'를 누르고 다음 단계로 가십시오". 이 옵션을 선택하고 "예"를 누르면 HedgeTerminal은 해당 목록을 지정된 목록에 넣은 다음 재정 결과와 총 순 포지션 기여도에 대한 체크를 중단합니다. 이러한 주문들은 현재 개방되어있는 순 포지션이 없는 경우에만 목록에 포함될 수 있습니다. 최소한 하나 이상의 기호에 대하여 개방된 포지션이 있는 경우 HedgeTerminal은 기존 포지션을 닫도록 제안하는 추가 대화 상자를 보여줍니다.
2. 주문을 그대로 두고 필요한 경우 나중에 종료: "나중에 수동으로 종료할 수 있습니다... 나중에 이 주문을 수동으로 청산하려면 '아니요'를 클릭하세요. 이 경우 반대 방향으로 5번의 거래를 시행해야 합니다.". 이 경우 "아니요"를 누르면 HedgeTerminal은 이 모든 주문을 실행한 후 "활성" 탭(즉, 활성 포지션으로)에 반영합니다. 나중에 이러한 주문은 HedgeTerminal 패널을 통해 다른 주문과 함께 청산할 수 있습니다. 그 후에 그들은 청산된 포지션으로 바뀌고 "History" 탭(과거 포지션)으로 이전됩니다. 이러한 주문이 많은 경우에는 체결된 모든 주문을 다시 청산하고 중개 수수료를 지불하는 것보다 숨기는 것이 좋습니다.
3. 설치를 중지할 수 있습니다. "아직 준비가 되지 않았다면 취소를 누르십시오. 이 경우 HedgeTerminal은 작업을 마칩니다". 이 옵션을 선택하고 "취소"를 누르면 HedgeTerminal이 작업을 중지합니다.

HedgeTerminal이 설치될 때까지 활성 포지션이 없으면 이 단계에서 설치가 중지됩니다.

두 번째 옵션을 선택했으며, 현재 하나 또는 여러 개의 개방 포지션이 있는 경우 HedgeTerminal은 해당 포지션를 닫도록 제안하는 추가 대화 상자를 호출합니다.

10번 그림. 순 포지션을 자동으로 청산하도록 제안하는 다이얼로그

체결된 모든 주문이 제외된 주문 목록에 포함될 때 HedgeTerminal은 모든 기존 포지션을 청산해야 합니다. 순 포지션이 없는 경우 다음 주문은 새 순 포지션을 초기화합니다. 이 경우 방향과 양은 HedgeTerminal에서와 동일하며 HedgeTerminal의 총 포지션과 순 포지션의 비동기화를 방지합니다.

HedgeTerminal은 자동으로 모든 순 포지션을 청산할 수 있습니다: "The HedgeTerminal은 모든 활성 포지션을 자동으로 청산할 수 있습니다". 그래도 좋다면 "확인"을 누르십시오. 이 경우 포지션을 닫으려고 시도하고 성공하면 작업을 완료합니다. 어떤 이유로건 포지션을 청산할 수 없는 경우 수동 포지션 청산 다이얼로그로 이동합니다. 수동 포지션 청산을 선택한 경우, "수동으로 포지션을 청산하려면 '취소'를 클릭하십시오", "취소"를 누르십시오.

수동 포지션 청산 다이얼로그는 이전 다이얼로그에서 수동 청산 유형을 선택했거나 자동 포지션 청산이 불가능한 경우 호출됩니다.

11번 그림 순 포지션을 수동으로 청산하길 권하는 다이얼로그

이 시점에서 모든 활성 포지션을 MetaTrader 5를 통해 수동으로 닫거나 "취소"를 눌러 설치를 취소해야 합니다. 모든 포지션을 청산했다면 "재시도"를 누르십시오.

2.2. 3단계 설치 설치 다이어그램 및 예상가능한 문제

설치 프로세스를 최대한 단순화하면 다음 세 단계로 좁힐 수 있습니다.

1. HedgeTerminal을 설치하기 전에 MetaTrader 5 터미널에서 현재 활성화된 모든 순 포지션을 닫으십시오.
2. 차트에서 HedgeTerminal을 실행하고 설치 마법사 창이 뜨면 "예"를 눌러 설치를 시작합니다. 이 경우 HedgeTerminal은 작동에 필요한 모든 파일을 설치합니다.
3. 다음 창이 나타나면 두 번째 옵션을 선택하고 "예"를 누르십시오. 이 경우 HedgeTerminal이 실행될 때 활성 포지션이 나타나지 않으며, 청산이 필요한 활성 포지션이 없기 때문에 과거에 체결된 주문에 대한 정보가 ExcludeOrders.xml 파일로 자동 전송됩니다.

이를 설명하는 가장 간단한 방법은 다음과 같습니다. Hedge Terminal을 실행하기 전에 모든 포지션을 닫고 HedgeTerminal 설치 마법사에서 "예"를 두 번 누르십시오.

설치 마법사의 전체 패턴은 아래 다이어그램에 나와 있습니다. 질문에 답하고 설치를 올바르게 수행하는 데 도움이 됩니다.

12번 그림. 설치 마법사

설치가 올바르게 수행되지 않았거나 컴퓨터에서 HedgeTerminal을 삭제해야 하는 경우 어떻게 해야합니까? 설치가 잘못된 경우 설치된 파일을 전부 삭제하면 됩니다. 이를 위해 MetaTrader용 프로그램이 공유 정보를 저장하는 폴더로 이동합니다(일반적으로 c:\Users\<당신의_유저_네임>\AppData\Roaming\MetaQuotes\Terminal\Common\Files\에 있습니다). 모든 계정에서 HedgeTerminal 설치에 대한 정보를 삭제하려면 그 디렉토리에서 "HedgeTerminal" 폴더를 찾아 삭제하십시오. 특정 계정에 대해서만 HedgeTerminal 설치에 대한 정보를 삭제하려면 \HedgeTerminal\Brokers 디렉토리로 이동하여 " 브로커 이름 - 계정 번호". 이 폴더를 지우십시오. 다음에 이 계정에서 HedgeTerminal이 시작되면 설치 마법사가 다시 시작됩니다.

HedgeTerminal에서 이미 작동하는 계정에 연결된 터미널에 설치. HedgeTerminal이 이미 작동 중인 계정에 연결된 터미널에 HedgeTerminal을 설치해야 하는 경우가 있습니다. 이미 알고 있듯이 설치 프로세스는 시스템 파일 생성 및 구성으로 구성됩니다. 이러한 모든 파일이 이미 다른 컴퓨터에서 생성되고 올바르게 구성되어 있으면 HedgeTerminal을 설치할 필요가 없습니다. 법칙대로 이 파일들은 c:\Users\<당신의_유저_네임>\AppData\Roaming\MetaQuotes\Terminal\Common\Files\HedgeTerminal 디렉토리에서 찾아볼 수 있습니다. 이 폴더를 컴퓨터의 같은 포지션으로 옮기기만 하면 됩니다. 디렉토리를 복사한 후 HedgeTerminal을 다시 실행합니다. 모든 파일이 있고 구성되어 있으므로 설치 마법사가 호출되지 않습니다. 이 경우 활성 포지션은 다른 터미널 및 컴퓨터의 디스플레이와 유사합니다.

HedgeTerminalAPI 설치 및 테스트 모드에서 라이브러리 사용. HedgeTerminal은 시각 패널과 프로그램 기능 라이브러리인 HedgeTerminalAPI로 구현됩니다. 라이브러리에는 HedgeTerminalAPI를 실시간으로 처음 실행할 때 호출되는 유사 설치 마법사가 포함되어 있습니다. 라이브러리를 이용하여 파일을 설치하는 방법도 비슷합니다. 아무 함수나 처음 호출하면 Expert가 설치 시작을 권하는 관련 MessageBox를 불러옵니다. 이 경우 사용자는 동일한 작업을 수행해야 합니다. HedgeTerminalAPI를 호출하기 전에 모든 포지션을 청산하고 3단계를 거쳐 설치를 수행해야 합니다.

테스트 모드에서 라이브러리를 시작할 때 HedgeTerminal을 설치할 필요가 없습니다. 테스트 모드에서 Expert는 새로운 가상 계정으로 작업할 때마다 시작하므로 이전에 실행한 주문 및 설치 파일을 숨길 필요가 없습니다. 라이브러리의 Settings.xml 파일에 저장된 설정은 관련 함수를 호출하여 문법적으로 정의할 수 있습니다.

2.3. HedgeTerminal과 친구 되기, 첫 기동

HedgeTerminal이 작업에 필요한 모든 파일을 설치한 후 차트에서 실행되고 해당 패널이 표시됩니다.

13번 그림. HedgeTerminal 첫 기동시의 모습

모든 기존 주문이 숨겨져 있으므로 활성 포지션이 표시되어있지 않습니다. 상단 패널에는 왼쪽에 HedgeTerminal 메뉴의 버튼과 패널 상태를 표시하는 전용 아이콘이 있습니다. 버튼에는 다음과 같은 기능이 있습니다.

•  - 패널 데모 버전이 출시되었음을 나타냅니다. 이것은 실제 계정에 대한 거래를 지원하지 않으며 AUDCAD 및 VTBR* 심볼용에서만 포지션을 표시합니다. 이 모드에서는 포지션 기록도 마지막 10개의 청산된 포지션으로 제한됩니다.
•  - HedgeTerminal의 포지션과 MetaTrader 5의 총 순 포지션과 같지 않음을 나타냅니다. 이것은 심각한 오류는 아니지만 제거해야 합니다. HedgeTerminal 설치가 제대로 되었다면, 이 문서에서 실수를 처리하는 방법에 대해 설명하는 섹션을 참조하십시오.
•  - 아이콘은 매매가 불가능함을 나타냅니다. 이 아이콘 위로 마우스를 가져간 다음 팝업 도움말에서 문제가 무엇인지 확인합니다. 가능성: 서버에 연결되지 않았습니다. Expert Advisor 매매가 금지 되어있습니다. MetaTrader 5에서는 Expert Advisors와의 매매가 허용되지 않습니다.
• - 거래가 허용되었음을 나타내는 아이콘 HedgeTerminal은 매매 행위를 할 수 있습니다.

이제 HedgeTerminal이 실행되고 작업 준비가 되면 여러 거래를 수행하고 표시되는 방식을 확인하십시오. 외환거래에서 HedgeTerminal이 시작되면 AUDCAD 심볼에서 매매 행동이 실행됩니다. 이 경우에만 HedgeTerminal 설치가 성공할 수 있으므로 개방된 순 포지션이 없어야 합니다. 어떤 이유로든 그렇지 않은 경우 모든 활성 포지션을 청산하십시오.

모스크바 거래소에 연결된 계정에서 HedgeTerminal이 시작되면 VTBR* 그룹의 선물 중 하나(예: VTBR-13.15 또는 VTBR-06.15)에서 거래를 실행해야 합니다. 예시로 표준창 "NewOrder"를 통해 현재가로 AUDCAD를 0.4 랏만큼 매수합니다. 잠시 후 주문과 이를 실행한 매매가 터미널의 주문 내역에 나타납니다.

14번 그림. MetaTrader 5의 기존 주문과 그에 속하는 딜

활성 포지션 탭에는 0.4랏에 상응하는 롱 포지션이 포함됩니다:

15번 그림. MetaTrader 5 내 활성 순 포지션

동시에 HedgeTerminal은 과거 주문을 활성 포지션으로 표시합니다.

16번 그림. HedgeTerminal 내 활성 양방향 포지션과 그 딜

보이듯이 HedgeTerminal의 한 포지션이 MetaTrader 5의 1개의 순 포지션에 해당하므로 결과는 동일합니다.

주문 외에도 HedgeTerminal의 포지션에는 이 포지션을 실행한 매매가 포함되어 있다는 점에 유의하십시오(이를 보려면 를 눌러 포지션 스트링을 최대화하십시오).

활성 포지션의 일부를 숨길 수 있습니다. 이를 위해 "Vol." (볼륨, Volume) 필드에 새 볼륨 값을 입력하기만 하면 됩니다. 새 볼륨은 현재 볼륨보다 작아야 합니다. 현재 볼륨과 새 볼륨 간의 차이는 과거 포지션을 형성하고 과거 포지션의 해당 탭에 표시되는 새 주문으로 처리됩니다. 이 필드에 0.2 값을 입력한 다음 Enter 키를 누릅니다. 언젠가는 활성 포지션의 거래량이 0.2가 될 것이고 과거 포지션 탭은 0.2랏(0.4 - 0.2 = 0.2) 만큼의 거래량을 가진 첫 번째 과거 거래를 보여줄 것입니다.

17번 그림. HedgeTerminal 내 과거 양방향 포지션

활성 포지션의 절반을 청산했습니다. 과거 및 활성 포지션의 일반적인 재무 결과는 터미널의 결과와 동일합니다.

이제 나머지 활성 포지션을 청산할 것입니다. 이를 위해 HedgeTerminal에서 포지션을 청산하는 버튼을 누르십시오:

18번 그림. HedgeTerminal 내 양방향 포지션 청산 버튼

이 버튼을 누른 후 나머지 포지션은 반대 순서로 청산되고 과거 포지션 탭으로 옮겨져야 합니다. 이렇게 하면 활성 포지션(MetaTrader 5와 HedgeTerminal 모두)이 모두 청산됩니다.

2.4. 금융 작업 헤징 및 계산

이 섹션에서는 몇몇 양방향 포지션를 예로 사용하여 HedgeTerminal을 다루는 방법을 설명하겠습니다.

자 그러니까 지금은 활성 포지션이 없습니다. AUDCAD에 0.2 랏 만큼 새로운 롱 포지션을 개방하겠습니다. 이를 위해서는 "새 주문" 다이얼로그를 열고 해당 주문을 하는 것으로 충분합니다. 포지션이 개방되면 반대 포지션으로 잠금하십시오. MetaTrader 5 터미널을 통해 0.2랏을 매도하십시오.

이번에는 HedgeTerminal과 MetaTrader 5 터미널 창에서 거래 결과가 다릅니다. HedgeTerminal은 두 개의 포지션을 표시합니다.

19번 그림. HedgeTerminal 반대 양방향 포지션들 (잠금)

MetaTrader 5에는 아예 존재하지 않습니다.

20번 그림. MetaTrader 5 내 활성 순 포지션의 부재

결과를 들여다 봅시다. 4건의 딜이 체결되었습니다. 아래 스크린샷에서는 빨간 테두리로 그려져있습니다.

21번 그림. MetaTrader 5 내 체결 딜의 결과

이 딜들을 테이블에 넣습니다.

타입	방향	매매가	볼륨	수익, pips
매수	진입	0,98088	0,2
매도	퇴장	0,98089	0,2	1
매수	진입	0,98207	0,2
매도	퇴장	0,98208	0,2	1

1번 테이블. MetaTrader 5 터미널에 거래 표시하기.

4건의 거래로 2 포인트를 얻었다는 것을 명확히 볼 수 있습니다. 1랏을 거래할 때 1포인트의 가치는 대략 0,887달러입니다. 따라서 재무 결과는 포지션당 0.18달러(0,887*0,2*1) 또는 두 포지션 모두 34센트입니다. "수익(Profit)" 열은 이 결과가 정확함을 보여줍니다. 순이익은 34센트입니다.

이제 HedgeTerminal에서 결과를 살펴보십시오.

 

22번 그림. 과거 HedgeTerminal 양방향 포지션의 결과

처음에는 크게 다른 것처럼 보입니다. 두 개의 양방향 포지션에 대한 결과를 계산해 보겠습니다.

방향	진입 가격	퇴장 가격	수익, pips	수익, 미국 달러
매수	0,98088	0,98208	0.00120	21,28
매도	0,98089	0,98207	-0.00118	-20,92

2번 테이블 HedgeTerminal의 포지션 표시

이들의 차이는 0.34$(21,28$ - 20,92$)이며 이는 순거래에서 얻은 결과와 정확히 동일합니다.

2.5. 원 클릭 매매

HedgeTerminal은 독특한 관리 시스템을 채용했습니다. 이것은 활성 포지션 필드에 직접 입력한 값을 기준으로 삼습니다. 다른 방법은 딱히 없습니다.

예를 들어, 활성 포지션에 손절매를 배치하려면 손절매 필드에 필요한 값을 입력한 다음 Enter 키를 누르십시오.

23번 그림. 테이블에 직접 손절매 레벨 입력하기

마찬가지로 트레이더는 거래량을 수정하거나 이익 실현을 배치하거나 레벨을 수정하고 초기 코멘트을 변경할 수 있습니다.

일반적으로 HedgeTerminal의 포지션 라인은 MetaTrader 4/5의 포지션 디스플레이와 유사합니다. 포지션이 있는 테이블의 열은 MetaTrader 터미널에서 사용되는 동일한 이름과 값을 갖습니다. 다른 점도 있습니다. 따라서 HedgeTerminal의 포지션에는 두 개의 코멘트가 있는 반면 MetaTrader의 포지션에는 하나의 코멘트만 있습니다. 즉, HedgeTerminal의 포짓션은 두 개의 주문으로 구성되며 각 주문에는 고유한 설명 필드가 있다는 의미입니다. HedgeTerminal은 기술 정보를 저장하기 위해 이러한 주석을 사용하지 않기 때문에 개시 및 종료 주석으로 포지션을 생성할 수 있습니다.

HedgeTerminal은 기본적으로 표시되지 않는 열을 추가할 수 있는 기능을 제공합니다. 예를 들어, 해당 포지션을 개방한 Expert Advisor의 이름을 적어두는 열도 가능합니다. Settings.xml 파일 구성에 관한 섹션에서는 이를 수행하는 방법을 설명합니다.

2.6. 손절매 및 이익 실현, 추적 손절매(트레일링 스탑)

헤지 터미널을 사용하면 손절매 및 이익 실현 레벨으로 포지션을 청산할 수 있습니다.

어떻게 발생하는지 보려면 활성 포지션에 손절매 및 이익 실현 레벨을 도입한 다음 해당 레벨 중 하나가 트리거될 때까지 기다리십시오. 우리의 경우엔 이익 실현이 트리거 되었습니다. 포지션을 청산하고 과거 거래 목록으로 옮겼습니다.

24번 그림. 과거 양방향 포지션과 손절매 및 이익 실현 레벨

녹색 이익 실현 레벨은 이익 실현이 트리거되었고 해당 레벨에 의해 포지션이 청산되었음을 나타냅니다. 이익 실현 외에도 포지션에는 포지션이 활성화되었을 때 사용되었던 손절매 레벨에 대한 정보가 담겨있습니다. 마찬가지로 손절매 레벨이 트리거되면 손절매 셀이 분홍색으로 강조 표시되고 이익 실현은 색 없는 채로 남게 됩니다.

HedgeTerminal은 이익 실현을 지원하며 향후 버전에서는 손절매를 이월하는 논리를 포함하는 특정 사용자 지정 모듈을 작성할 수 있습니다. 현재 HedgeTerminal에 있는 추적 손절매(트레일링 스탑) 작업은 MetaTrader 터미널의 추적 손절매과 다릅니다. 활성화하려면 해당 포지션의 손절매 셀에 손절매 레벨을 입력해야 합니다. 손절매가 배치되면 가격 옵션을 따라 기호로 표시된 셀에 플래그를 지정할 수 있습니다.

25번 그림. HedgeTerminal에서의 추적 손절매 주문

플래그를 심은 후, HedgeTerminal은 현재 매매가와 손절매 레벨 사이의 거리를 고정시킵니다. 만약 매매가가 상승하면 손절매도 동일한 거리를 유지하기 위해 상승합니다. 추적 손절매는 HedgeTerminal이 작동 중일 때만 작동하고 종료 시 청산됩니다.

HedgeTerminal에서 손절매는 역지정가 매수및 역지정가 매도 주문으로 구현됩니다. 손절매가 배치될 때마다 활성 포지션과 연결된 매직 번호가 있는 주문도 배치됩니다. 이 보류 주문이 MetaTrader 터미널에서 삭제되면 HedgeTerminal의 손절매 레벨이 사라집니다. 보류 중인 주문의 가격을 변경하면 HedgeTerminal에서 손절매에 변화가 생깁니다.

이익 실현은 조금 다르게 작동합니다. 이것은 가상에서 처리되며, 브로커로부터 트리거 레벨을 숨깁니다. HedgeTerminal이 이익 실현에 의해 자율적으로 포지션을 청산한다는 의미입니다. 따라서 이익 실현이 트리거되도록 하려면 HedgeTerminal을 작동 순서로 유지해야 합니다.

2.7. 리포트 생성하기

HedgeTerminal을 사용하면 Microsoft Excel과 같은 타사 통계 분석 프로그램 파일에 양방향 포지션에 관한 정보를 저장할 수 있습니다.

현재 HedgeTerminal에는 분석 및 통계 수집 시스템이 없기 때문에 이 기능이 특히 중요합니다. 현 시점에서는 리포트 저장 형식은 CSV(Comma-Seperated Values) 확장자 하나만 지원됩니다. 이게 어떻게 굴러가는지 봅시다. CSV 파일에 양방향 포지션을 저장하려면 HedgeTerminal을 시작한 후 메뉴에서 "CSV 리포트 저장" 옵션을 선택하십시오.

26번 그림. "CSV 리포트 저장" 메뉴를 통해 리포트 저장

메뉴에서 해당 지점을 선택한 후 HedgeTerminal은 CSV 형식으로 두 개의 파일을 생성합니다. 그 중 하나는 활성 포지션에 대한 정보로 구성되고 다른 하나는 완료된 과거 포지션에 대한 정보로 구성됩니다. 두 개의 다른 파일이 생성되는 이유는 각각 다른 열 집합이 있기 때문입니다. 또한 활성 포지션의 수는 지속적으로 변동할 수 있으므로 별도로 분석하는 것이 더 편리합니다. 생성된 파일들은 상대경로 .\HedgeTerminal\Brokers\<브로커명 - 계정번호> \. 에서 열람 가능합니다. 해당 디렉토리에는History.csv 및 Active.csv 파일이 있어야 합니다. 첫 번째 항목에는 과거 포지션에 대한 정보가 포함되어 있고 두 번째 항목에는 활성 포지션에 대한 정보가 포함되어 있습니다.

파일은 분석을 위해 통계 프로그램에 로드할 수 있습니다. Microsoft Excel을 예로 사용하여 이 절차를 살펴보겠습니다. 엑셀을 실행하고 "데이터" --> "텍스트로부터"를 선택하십시오. 나타난 데이터 내보내기 마법사에서 구분 기호가 있는 모드를 선택합니다. 다음 창에서 구분 기호로 세미콜론을 선택합니다. "다음"을 누르십시오. 다음 창에서 부동 소수점 숫자 표현의 일반 형식을 변경합니다. 그렇게 하려면 "세부 정보"를 누르십시오. 나타나는 창에서 정수 및 소수 부분의 구분 기호로 마침표 문자를 선택합니다.

27번 그림. 마이크로소프트 엑셀 CSV 만들기

"ОК"를 누르고 그 다음 "Finish"를 누르십시오. 나타나는 테이블에는 활성 포지션에 대한 정보가 포함됩니다.

28번 그림. 엑셀로 내보낸 활성 포지션 정보

과거 포지션 데이터는 같은 방식으로 다음 시트에 로드할 수 있습니다. 열 수는 HedgeTerminal의 실제 열 수와 일치합니다. 만약 어떤 열이 HedgeTerminal 패널에서 삭제된다면 그 열은 리포트에 포함되지 않습니다. 이것은 필요한 데이터만을 기반으로 리포트를 작성하는 편리한 방법입니다.

프로그램의 이후 버전에서는 리포트를 XML 및 HTML 형식으로 저장할 수 있습니다. 추가로 HTML에 저장된 리포트는 완료된 양방향 포지션으로 구성되지만 MetaTrader 5의 표준 HTML 리포트와 유사합니다.

2.8. 통화 스왑 프레젠테이션

통화 스왑은 평가 날짜가 다른 동일한 금액에 대한 두 가지 양방향 전환 거래의 조합입니다.

간단히 말해서, 스왑은 순 포지션을 형성하는 두 통화를 보유하기 위해 지불하는 이자율의 차이를 발생시키는 파생 작업입니다.

MetaTrader 5에는 순 포지션 이력이 없습니다. 대신 과거 주문, 과거 딜, 그리고 청산된 과거 순 포지션들이 있습니다. 과거 포지션이 없기 때문에 스왑은 과거 포지션을 청산하는 주문에 할당됩니다.

 

29번 그림. 독립 트랜잭션으로서의 통화 스왑

스왑을 순 포지션 연장의 결과로 나타나는 독립적인 파생 상품으로 표현하는 편이 더 정확할지도 모릅니다.

현재 버전의 HedgeTerminal은 스왑 표현을 지원하지 않지만 차기 버전에서는 이러한 옵션을 제공합니다. 스왑은 과거 포지션 탭에 별도의 과거 포지션으로 표시됩니다. 스왑 식별자는 발생한 순 포지션의 식별자와 일치합니다. 스왑에는 통화 쌍의 이름과 재무 결과가 포함됩니다.

2.9. 마지막 줄

MetaTrader와 유사하게 HedgeTerminal은 거래 테이블의 전체 계정에 대한 공통 특성을 가진 마지막 행을 표시합니다. 활성 및 과거 포지션 테이블의 경우 이러한 특성과 해당 값이 아래에 나열되어 있습니다.

잔고(Balance) – 총 잔고. MetaTrader 내 활성 포지션 창에서 유사한 값 "Profit"과 동일합니다. 이는 개방 포지션으로 인한 변동 손익은 고려하지 않습니다.
변동 손익(Floating P/L) – 변동 이득/손실 이것은 현재 활성화된 모든 포지션의 이익을 합한 것과 같습니다.
증거금(마진) – 계정 잔액에서 약정 자금이 차지하는 비율을 백분율로 표시합니다. 최소 0%에서 100%까지 이어집니다. 보증금의 부담 정도를 나타냅니다.
총 손익(Total P/L) – 청산된 포지션에 대한 모든 이익과 손실의 합계를 포함합니다.
포지션:# - 과거 포지션의 수를 표시합니다.

마지막 줄을 올바르게 표시하려면 시스템에 "Arial Rounded MT Bold" 글꼴을 추가해야 합니다.

2.10. HedgeTerminal 테이블의 외관 변경시키기

앞에서 언급했듯이 HedgeTerminal에는 Expert 실행 창에 단 하나의 외부 패러미터만 사용하고 있습니다. 만약 설정 파일이라면 이 이름입니다. 이것은 HedgeTerminal 설정을 Expert 설정 창에 배치할 수 없기 때문입니다. 그런 류가 너무 많은데다가 창 하나에 넣기엔 필요 이상으로 상세하기 때문입니다. 이것이 모든 설정이 지정된 구성 파일 Settings.xml에 저장되는 이유입니다. 출시된 모든 HedgeTerminal 버전에 대해 자체 설정 파일이 있을 수 있습니다. 이는 실행된 모든 HedgeTerminal 버전을 개별적으로 구성할 수 있는 기회를 제공합니다.

HedgeTerminal은 현재 설정의 시각 창을 통해 이 파일을 편집하는 것을 허용하지 않습니다. 따라서 HedgeTerminal의 동작을 변경하는 유일한 방법은 파일을 수동으로 편집하는 것입니다. 설정 파일은 기본적으로 최적의 방식으로 구성되어 있으므로 대부분의 경우 내용을 수정할 필요가 없습니다. 그러한 편집이 필요할 수 있는 상황이 있을 수 있습니다. 이러한 편집은 패널 모양을 미세 조정하고 사용자 정의하는 데 필요합니다. 예를 들어 파일을 편집한 경우 불필요한 열을 삭제하거나 반대로 기본적으로 표시되지 않는 열을 추가할 수 있습니다.

이 파일의 내용을 보고 사용자 정의하는 방법을 살펴보겠습니다. 그렇게 하려면 HedgeTerminal이 파일을 설치한 디렉토리에서 이 파일을 찾으십시오. 이 디렉토리는 이전에 언급한 대로 c:\Users\<당신의_유저_이름>\AppData\Roaming\MetaQuotes\Terminal\Common\Files\HedgeTerminal에서 찾아볼 수 있습니다. Settings.xml 파일은 그 안에 있을 것입니다. 아무 텍스트 편집기를 꺼내서 여십시오.

<!--This settings valid for HedgeTerminal only. For settings HedgeTerminalAPI using API function and special parameters.-->
<Hedge-Terminal-Settings>
        <!--This section defines what columns will be showed on the panel.-->
        <Show-Columns>
                <!--You can change the order of columns or comment not using columns.-->
                <!--You can change the value of 'Width' for a better scaling of visual table.-->
                <!--You can change the value of 'Name' to install your column name.-->
                
                <!--This columns for tab 'Active'-->
                <Active-Position>       
                        <Column ID="CollapsePosition" Name="CollapsePos." Width="20"/>
                        <!-- Unset this comment if you want auto trading and want see name of your expert:
                        <Column ID="Magic" Name="Magic" Width="100"/>-->
                        <Column ID="Symbol" Name="Symbol" Width="70"/>
                        <Column ID="EntryID" Name="Entry ID" Width="80"/>
                        <Column ID="EntryDate" Name="Entry Date" Width="110"/>
                        <Column ID="Type" Name="Type" Width="80"/>
                        <Column ID="Volume" Name="Vol." Width="30"/>
                        <Column ID="EntryPrice" Name="EntryPrice" Width="50"/>
                        <Column ID="TralStopLoss" Name="TralSL" Width="20"/>
                        <Column ID="StopLoss" Name="S/L" Width="50"/>
                        <Column ID="TakeProfit" Name="T/P" Width="50"/>
                        <Column ID="CurrentPrice" Name="Price" Width="50"/>
                        <Column ID="Commission" Name="Comm." Width="40"/>
                        <Column ID="Profit" Name="Profit" Width="60"/>
                        <Column ID="EntryComment" Name="Entry Comment" Width="100"/>
                        <Column ID="ExitComment" Name="Exit Comment" Width="100"/>
                </Active-Position>
                <!--This columns for tab 'History'-->
                <History-Position>
                        <Column ID="CollapsePosition" Name="CollapsePos." Width="20"/>
                        <!-- Unset this comment if you want auto trading and want see name of your expert:
                        <Column ID="Magic" Name="Magic" Width="100"/>-->
                        <Column ID="Symbol" Name="Symbol" Width="70"/>
                        <Column ID="EntryID" Name="Entry ID" Width="80"/>
                        <Column ID="EntryDate" Name="Entry Date" Width="110"/>
                        <Column ID="Type" Name="Type" Width="40"/>
                        <Column ID="EntryPrice" Name="Entry Price" Width="50"/>
                        <Column ID="Volume" Name="Vol." Width="30"/>
                        <Column ID="ExitPrice" Name="Exit Price" Width="50"/>
                        <Column ID="ExitDate" Name="Exit Date" Width="110"/>
                        <Column ID="ExitID" Name="Exit ID" Width="80"/>
                        <Column ID="StopLoss" Name="S/L" Width="50"/>
                        <Column ID="TakeProfit" Name="T/P" Width="50"/>
                        <Column ID="Commission" Name="Comm." Width="40"/>
                        <Column ID="Profit" Name="Profit" Width="50"/>
                        <Column ID="EntryComment" Name="Entry Comment" Width="90"/>
                        <Column ID="ExitComment" Name="Exit Comment" Width="90"/>
                </History-Position>
        </Show-Columns>
        <Other-Settings>
                <Deviation Value="30"/>
                <Timeout Seconds="180"/>
                <!-- If your computer is not fast enough - set a value 'Milliseconds' greater than 200, such as 500 or 1000. -->
                <RefreshRates Milliseconds="200"/>
        </Other-Settings>
</Hedge-Terminal-Settings>

-->

이 파일에는 HedgeTerminal의 동작과 모양을 설명하는 xml 마크업 언어로 작성된 특수 문서가 포함되어 있습니다.

편집을 시작하기 전에 가장 먼저 해야 할 일은 파일이 실수로 손상된 경우에 대비하여 백업 복사본을 만드는 것입니다. 파일은 계층 구조를 가지며 서로 묶인 여러 섹션으로 구성됩니다. 주요 섹션은 <Hedge-Terminal-Settings> 라고 하며 두 개의 주요 하위 섹션인 <Show-Columns> 및 <를 포함합니다. 기타 설정>. 이름에서 알 수 있듯이 첫 번째 섹션은 표시되는 열과 조건부 너비를 조정하고 두 번째 섹션에는 패널 자체 및 HedgeTerminalAPI 라이브러리에 대한 설정이 있습니다.

열의 이름과 사이즈 바꾸기. <Show-Columns> 섹션을 참조하고 그 구조를 살펴보겠습니다. 기본적으로 이 섹션에는 "활성" 탭의 활성 포지션 테이블과 "기록" 탭의 과거 포지션 테이블에 대한 두 개의 열 세트가 있습니다. 이 셋들에 있는 열은 이렇게 생겼습니다.

<Column ID="Symbol" Name="Symbol" Width="70"/>

-->

열에는 식별자(ID="Symbol"), 열 이름(Name="Symbol") 및 조건부 너비(Width="70)가 포함되어야 합니다. ").

식별자에는 열의 고유한 내부 이름이 포함됩니다. HedgeTerminal에 이 열을 표시하는 방법과 그 안에 배치할 값을 묻는 메시지가 표시됩니다. 식별자는 변경할 수 없으며 HedgeTerminal에서 지원해야 합니다.

열 이름은 열이 테이블에 표시될 이름을 정의합니다. Name="통화 쌍"과 같이 다른 이름으로 이름이 변경된 경우 다음 단계에서 HedgeTerminal을 시작하면 기호를 표시하는 열의 이름이 다음과 같이 변경됩니다.

30번 그림. HedgeTerminal 패널에서 열 이름 변경

이 속성을 사용하면 모든 열의 이름이 기본 언어(예: 러시아어)로 표시되는 패널의 현지화된 버전을 만들 수 있습니다.

 

31번 그림. HedgeTerminal 패널 현지화

다음 태그는 열의 조건부 너비를 포함합니다. 문제는 그래픽 엔진이 자동으로 테이블 크기를 패널이 실행되는 창의 너비에 맞춰 정렬한다는 것입니다. 창이 넓을수록 각 열이 더 넓어집니다. 컬럼의 너비를 정확하게 설정하는 것은 불가능하지만 컬럼의 기본 너비를 설정하여 비율을 지정할 수 있습니다. 기본 너비는 창 너비가 1280픽셀일 때 열 너비(픽셀)입니다.

디스플레이가 더 넓으면 열의 실제 크기가 더 큽니다. 균일한 크기 조정이 작동하는 방식을 보려면 기호 열의 너비를 240 조건부 픽셀로 설정합니다(Width="240"). 그런 다음 파일을 저장하고 패널을 재설정합니다.

32번 그림. 심볼 열의 너비는 240픽셀로 설정됩니다.

심볼 열의 너비가 많이 커졌습니다. 그러나 다른 열("Entry ID" 및 "Entry Date")의 너비를 줄여서 너비를 늘린 것입니다.

다른 열은 이제 더 나빠 보이고 마지막 값은 허용된 너비에 맞지 않습니다. 열의 크기는 각 열에 가장 적합한 크기를 찾아 신중하게 변경해야 합니다. 표준 설정은 대부분의 디스플레이에 대해 정확한 값을 가지며 일반적으로 크기를 변경할 필요가 없습니다.

열 삭제. 열 크기 및 헤더 변경 외에도 열을 추가하거나 삭제할 수 있습니다. 예를 들어 목록에서 "Symbol" 열을 삭제해 보겠습니다. 이렇게 하려면 Settings.xml 파일의 열 태그(노란색으로 강조 표시됨)를 주석 처리하기만 하면 됩니다.

<Column ID="CollapsePosition" Name="CollapsePos." Width="20"/>
<!-- Unset this comment if you want auto trading and want see name of your expert:
<Column ID="Magic" Name="Magic" Width="100"/>-->
<!--<Column ID="Symbol" Name="Symbol" Width="70"/>-->
<Column ID="EntryID" Name="Entry ID" Width="80"/>

-->

xml에서 지정된 태그 <!-- 코멘트 내용 -->은 주석의 역할을 수행합니다 . 주석 처리된 열은 태그에 있어야 합니다. 파일의 변경 사항이 저장되고 HedgeTerminal이 다시 실행된 후 과거 포지션에 대한 열 집합이 변경됩니다. 기호를 표시하는 열은 포함하지 않습니다.

33번 그림. 활성 포지션 테이블에서 심볼 열 삭제

한 번에 여러 열을 삭제할 수 있습니다.

기호 이름과 이익 크기를 제외한 모든 열을 주석 처리한 다음 차트에서 HedgeTerminal을 다시 실행해 보겠습니다.

34번 그림. HedgeTerminal 패널에서 주요 열 삭제하기

보시다시피, HedgeTerminal 테이블이 크게 줄었습니다. 열에 포지션 관리 요소가 포함되어 있는 경우가 있으므로 열을 삭제할 때는 주의해야 합니다. 우리의 경우 포지션을 반전하고 거래를 볼 수 있는 열이 삭제되었습니다. 활성 포지션 테이블에서 "수익" 열도 삭제할 수 있습니다. 그러나 이 열에는 청산 포지션의 버튼이 포함되어 있습니다. 이 경우엔 청산 버튼이 없어 포지션이 청산되지 않습니다.

열 추가 및 Expert 별칭 표시. HedgeTerminal이 열과 함께 작동하도록 프로그래밍된 경우 열을 편집하고 추가하여 열을 삭제할 수 있습니다. 이후로 유저는 원하는 열을 만들고 원하는 패러미터를 계산할 수 있습니다. 이러한 열은 외부 인디케이터 iCustom의 인터페이스와 xml로 작성된 확장 모듈과의 상호 작용 매니페스트를 통해 연결할 수 있습니다.

아직 현재는 이러한 기능은 없으며 HedgeTerminal에서 지원하는 열만 사용할 수 있습니다. 패널에서 지원하지만 기본적으로 설정에 표시되지 않는 유일한 열은 Expert의 매직 번호가 포함된 열입니다.

포지션은 직접 하는 것 뿐만 아니라 봇을 사용하여 개방할 수 있습니다. 이 경우 포지션을 연 봇의 식별자를 모든 포지션에 표시할 수 있습니다. Expert Advisor의 번호를 포함하여 주석 처리된 열 태그가 이미 설정 파일에 있습니다. 코멘트를 제거해봅시다.

<Column ID="Magic" Name="Magic" Width="100"/>

-->

변경 사항을 저장하고 패널을 재기동합시다.

35번 그림. HedgeTerminal 테이블에 Magic 열 추가하기

위 그림에서 볼 수 있듯이 "Magic"이라는 열이 등장했습니다. 포지션을 개설한 Expert Advisor의 식별자입니다. 포지션이 수동으로 열렸으므로 식별자가 0입니다. 일반적으로 봇에 의해 열린 포지션에는 0이 아닌 식별자가 포함됩니다. 이 경우 해당하는 Expert의 매직 번호가 열에 표시됩니다.

번호 대신 Expert Advisors의 이름을 보는 것이 더 편리하지않습니까. HedgeTerminal가 지원하는 옵션입니다. ExpertAliases.xml 파일에서 가져온 EA의 별칭(이름)을 해당 매직 넘버 대신 표시합니다.

만약 "ExPro 1.1"이라는 이름의 Expert가 있고, 매직 넘버 123847를 가지고 매매하고 있을 경우 <Expert-Aliases> 섹션의 ExpertsAliases.xml 파일에 다음의 태그를 남겨두는 것으로 족합니다.

<Expert Magic="123847" Name="ExPro 1.1"></Expert>

-->

이제부터 봇이 새 포지션을 개방하면 이름이 다음과 같이 변경됩니다.

36번 그림. Magic 열에 Expert의 이름 표시하기

봇의 수도, 봇의 이름 수도 무제한입니다. 여기서 유일한 조건은 숫자가 달라야 한다는 것입니다.

나머지 HedgeTerminal 세팅. 현재 사용 가능한 비주얼 패널의 모든 설정에 대해 설명했습니다. 다음 섹션 <Other-Settings>에는 터미널의 내부 작업을 정의하는 설정이 포함되어 있습니다. 프로그램 호출 라이브러리 HedgeTerminalAPI는 이러한 설정을 기본값으로 사용합니다. 그러나 Expert Advisor는 특수 Set... 함수를 사용하여 이러한 설정의 현재 값을 변경할 수 있습니다. 이러한 설정의 값을 얻으려면 Expert가 특별한 Get... 함수를 호출하기만 하면 됩니다. 설정이 있는 태그에 대해 더 자세히 설명하겠습니다.

<Deviation Value="30"/>

-->

최소 가격 변동 단위로 요구 가격과의 극단 편차 값을 포함합니다. 따라서 소수점 다섯 번째 자리까지 인용된 EURUSD 쌍의 경우 0,0003 포인트가 됩니다. RTS 지수 선물의 경우 가격 변경의 최소 단계가 10포인트이므로 이 값은 300포인트가 됩니다. 가격 편차가 더 크면 가격을 청산하거나 변경하는 주문이 실행되지 않습니다. 이것은 원하지 않는 슬리피지로부터 보호하기 위한 것입니다.

<Timeout Seconds="180"/>

-->

이 태그에는 서버에서 허용되는 최대 응답 값이 포함됩니다. HedgeTerminal은 비동기성 모드에서 작동합니다. 즉, HedgeTerminal은 서버로부터 응답을 받기를 기다리지 않고 거래 신호를 서버에 보냅니다. 대신, HedgeTerminal은 주문이 성공적으로 접수되었다는 사실을 가리키는 일련의 사건을 제어합니다. 사건은 아예 발생하지 않을 수도 있습니다. 이것이 HedgeTerminal이 서버 응답을 기다리는 대기 시간 초과 기간을 설정하는 것이 중요한 까닭은 바로 이런 것입니다. 그 시간 동안 응답이 없으면 작업이 취소되고 HedgeTerminal은 해당 포지션의 차단을 해제하고 작업을 계속합니다.

대기 시간 초과 기간은 단축되거나 연장될 수 있습니다. 기본값은 180 초입니다.

실제 거래에서는 이 제한에 도달하거나 확장되지 않는다는 점을 이해하는 것이 중요합니다. 거래 신호에 대한 응답은 빠르게 돌아오고 대부분은 150~200밀리초 이내에 실행됩니다.

HedgeTerminal의 작업과 비동기성 작업의 특성에 대한 자세한 내용은 이 문서의 세 번째 섹션인 "HedgeTerminal의 본네트 아래"에서 보실 수 있습니다.

<RefreshRates Milliseconds="200"/>

-->

이 태그는 패널 업데이트 빈도를 설정합니다. 여기에는 두 개의 후속 패널 업데이트 사이의 시간(밀리초)이 포함됩니다. 이 값이 작을수록 패널 업데이트 빈도가 높아지고 더 많은 CP 리소스가 사용됩니다. 프로세서가 그다지 강력하지 않고 200밀리초(기본값)의 업데이트 빈도를 처리할 수 없는 경우 태그를 편집하여 최대 500밀리초 또는 1000밀리초까지 늘릴 수 있습니다.

이 경우 CP 부하가 크게 떨어집니다. 100밀리초 미만의 값은 권장하지 않습니다. 업데이트 빈도를 높이면 CP 로드가 비선형적으로 증가합니다. 업데이트 빈도가 단말기의 불연속성을 정의한다는 것을 이해하는 것이 중요합니다. 일부 동작은 이 타이머에 의해 정의되며 특정 속도로 발생합니다.

2.11. 아직 구현하지 못한 계획들

HedgeTerminal은 이 프로그램의 중요하지 않긴하지만 새로운 기능을 추가할 수 있는 유연한 아키텍처를 가지고 있습니다. 현재 이러한 기능은 구현되지 않았지만 향후 수요가 있을 경우 나타날 수 있습니다. 이하가 주요 아이디어입니다.

색 구성표 및 스킨 사용. HedgeTerminal은 자체 그래픽 엔진을 사용합니다. 이것은 직사각형 레이블이나 일반 텍스트와 같은 그래픽 기본 요소를 기반으로 합니다. 이미지 파일에 기반한 그래픽은 전혀 사용하지 않습니다. 이것은 HedgeTerminal에 표시되는 모든 요소의 색상, 크기 및 글꼴을 변경할 수 있는 기회를 제공합니다. 이런 식으로 스킨의 형태로 글꼴과 색 구성표에 대한 설명을 쉽게 만들고 HedgeTerminal을 시작할 때 로드하여 모양을 변경하는 것이 쉽습니다.

맞춤형 추적 손절매(트레일링 스탑) 모듈 연결. 모든 Expert, 그리고 HedgeTerminal은 본질적으로 Expert이며 특정 프로그램 인터페이스(함수 iCustom( ))의 계산을 시작할 수 있습니다. 임의의 패러미터 세트에 따라 달라지는 인디케이터 계산을 호출할 수 있습니다. 추적 손절매(트레일링 스탑)는 현재 가격에 따라 새 가격 레벨을 배치하거나 이전 가격 레벨을 유지하는 알고리즘입니다. 이 알고리즘과 그 가격 레벨은 인디케이터로 구현될 수 있습니다. 패싱된 패러미터에 문제가 없다면 HedgeTerminal은 이런 인디케이터를 호출하고 필요한 가격 레벨을 계산할 수 있습니다. HedgeTerminal은 추적 손절매를 전송하는 메커니즘을 처리할 수 있습니다. 이런 식으로 모든 HedgeTerminal 유저는 추적 손절매를 관리하는 자신만의(가장 특이한 모듈도 포함) 모듈을 작성할 수 있습니다.

포지션 테이블에 새 열 추가하기 여기에는 사용자 정의 열이 포함됩니다. HedgeTerminal 테이블은 새 열을 추가할 수 있도록 설계되었습니다. 새 열 추가는 HedgeTerminal 내에서 프로그래밍하고 iCustom() 인터페이스를 통해 익숙한 방식으로 구현할 수 있습니다. 포지션 라인의 모든 셀은 패러미터(예: 시가 또는 이익실현 레벨)를 나타냅니다. 이 패러미터는 인디케이터로 계산할 수 있는데, 이것이 말하는 바는 인디케이터가 무제한으로 작성되어 각 인디케이터가 포지션에 대한 일부 패러미터를 계산할 수 있음을 의미합니다. 전달 패러미터가 이러한 지표에 대해 조정되면 HedgeTerminal의 테이블에 사용자 정의 열을 무제한으로 추가할 수 있게 됩니다.

확장 모듈 연결. 다른 계산 알고리즘은 커스텀 인디케이터 호출 메커니즘을 통해 계산할 수 있습니다. 예를 들어, 보고 시스템에는 예상 수익 및 샤프율(Sharpe Ratio)과 같은 많은 계산 패러미터가 포함됩니다. 이러한 패러미터의 대부분은 계산 블록을 커스텀 인디케이터로 이동하여 받아볼 수 있습니다.

거래 복사, 다른 계정에서 거래 수신 및 전송. HedgeTerminal은 본질적으로 포지션 관리자입니다. 주요 기능이 이미 구현되었기 때문에 이것은 쉽게 거래 복사기의 기반이 될 수 있습니다. 이러한 복사기는 양방향 MetaTrader 4 포지션을 MetaTrader 5 터미널에 복사하는 중요한 기능을 갖습니다. 복사기는 MetaTrader 4에서와 같이 이러한 포지션을 양방향으로 표시하고 모든 포지션을 개별적으로 관리할 수 있습니다.

리포트 및 통계. 주가 차트 및 "요약" 탭. 양방향 포지션 계산을 통해 모든 전략 또는 트레이더의 결과에 대한 기여도를 분석할 수 있습니다. 통계와 함께 포트폴리오 분석을 수행할 수 있습니다. 이 보고서는 MetaTrader 5의 보고서와 크게 다를 수 있으며 추가할 수 있습니다. Summary 탭의 보고서에는 예상 수익, 최대 손실, 이윤 계수 등과 같이 일반적으로 허용되는 패러미터 외에 다른 패러미터도 포함됩니다. 후자의 이름과 값은 커스텀 확장 모듈에서 얻을 수 있습니다. 그림의 익숙한 대차대조표 대신 커스텀 캔들스틱 교환차트 형태의 주가차트를 사용할 수 있습니다.

열 정렬. 일반적으로 표 머리글을 누르면 행이 오름차순 또는 내림차순으로 정렬됩니다(두 번째 누를 때). 이 옵션은 HedgeTerminal 현 버전에서는 사용할 수 없는 딜 필터나 열 커스텀 셋 등과 정렬기능이 연결되어있기 때문에 지금은 사용할 수 없습니다. 나중 버전에는 이 옵션이 추가될 것입니다.

이메일, ftp를 통해 매매 리포트 보내기. 푸시 알림. HedgeTerminal은 시스템 기능을 사용하여 이메일, ftp 파일 및 푸시 알림을 보낼 수 있습니다. 예를 들어 하루에 한 번 html 보고서를 작성하여 리스트에 있는 유저들에게 보낼 수 있습니다. HedgeTerminal은 Expert Advisors의 관리자이고 다른 EA의 모든 매매를 인식하고 있기에, 다른 Expert Advisors의 매매 행위를 기록해서 유저들에게 보내는 것이 가능합니다. 예를 들어, EA 중 하나가 새 포지션을 개방하면 HedgeTerminal은 특정 Expert가 새 포지션에 진입했음을 알리는 푸시 알림을 사용자에게 보낼 수 있습니다. HedgeTerminal은 또한 항목의 방향, 날짜, 시간 및 볼륨을 지정합니다. EA 자체는 구성할 필요가 없으며 별칭 파일에 이름을 추가하는 것으로 충분합니다.

정규식을 통한 포지션 필터링. 이것은 계획된 개발 예정 기능 중 가장 강력한 기능입니다. HedgeTerminal의 작업을 완전히 새로운 수준으로 끌어올릴 것입니다. 정규식은 과거 및 활성 포지션을 필터링하는 데 사용할 수 있으므로 이 필터의 요구 사항을 충족하는 포지션만 표시됩니다. 정규식은 활성 및 과거 포지션 테이블 상의 전용 콘솔에서 결합 및 입력할 수 있습니다. 이것은 이 콘솔이 HedgeTerminal의 향후 버전에서 어떻게 보일지입니다:

37번 그림. 차후 HedgeTerminal 버전에서의 리퀘스트 콘ㅅ솔

정규식은 포지션에 대한 통계 계산이 뒤따르는 필터링 포지션에 대해 매우 유연한 조건을 형성할 수 있습니다. 예를 들어, AUDCAD 기호로만 과거 포지션를 표시하려면 "심볼" 셀에 "AUDCAD" 기호를 입력하면 됩니다. 조건들은 서로 결합시킬 수도 있습니다. 예를 들어, 어떤 봇에 의해 체결된 AUDCAD에 의한 포지션은 2014년 9월 1일부터 2014년 10월 1일까지의 기간 동안 표시될 수 있습니다. 해당 셀에 조건을 입력하기만 하면 됩니다. 필터에 결과가 표시되면 "Summary" 탭의 보고서가 새 필터 조건에 따라 변경됩니다.

정규식은 소수의 단순 연산자로 구성됩니다. 그러나 함께 사용하면 매우 유연한 필터를 만들 수 있습니다.

콘솔에서는 아래 연산자가 필요하고 충분합니다.

= 연산자 - 완전히 같음 AUDСAD라는 단어가 "심볼" 필드에 입력되면 이 하위 문자열을 포함하는 모든 기호(예: AUDCAD_m1 또는 AUDCAD_1)를 찾을 수 있습니다. 즉, 내부 삽입 연산자가 사용된다는 의미입니다. 완전 일치를 의미하는 "="는 식이 완전히 같아야하므로 AUDCAD를 제외한 모든 심볼이 제외됩니다. AUDCAD_m1이나 EURUSD는 배제될 것입니다.

> 연산자 - 지정된 수치보다 큰 값만 표시.

< 연산자 - 지정된 수치보다 작은 값만 표시.

! 연산자 – 논리적 부정. 지정된 값과 같지 않은 값만 표시.

| 연산자 - "OR" 논리. 한 줄에 두 개 이상의 조건을 동시에 부여하는 것을 가능케 함. 동시에 기준을 충족하려면 하나 이상의 조건을 충족하면 충분합니다. 예를 들어 정규식 콘솔의 "Entry Order"에 입력한 "> 10106825|=10106833" 식은 주문 식별자가 10106825보다 크거나 10106833 와 같은 값을 찾아서 돌려줄 것입니다. 

& 연산자 - "AND" 논리. 동시에 한 행에 둘 이상의 조건을 지정할 수 있으며 각각이 모두 충족되어야 합니다. "Entry Order" 셀에 입력한 정규식 >10106825&<10105939"는10106825보다 크거나 10105939보다 작은 식별자가 달린 모든 포지션을 찾아 돌려줍니다. 식별자가 이 두 숫자 사이에 존재하는 포지션(예: 10106320)은 필터링됩니다.

특수 명령을 사용하여 포지션 수정 및 관리. 볼륨 또는 손절매 및 이익 실현 수준을 반영하는 셀에 추가 기호를 입력할 수 있습니다. 이것은 보다 복잡한 포지션 관리를 가능하게 합니다. 예를 들어, 현재 포지션 양의 절반을 닫으려면 "볼륨" 필드에 활성 포지션에 해당하는 값 "50%"를 입력합니다.

손절매 및 이익 실현 레벨을 배치하는 대신 "1%"와 같은 값을 해당 셀에 입력할 수 있습니다. HedgeTerminal은 자동으로 손절매 및 이익 실현 레벨을 계산하여 진입 가격에서 1%의 떨어진 곳에 배치됩니다. 이 셀에는 접미사 "p"가 있는 숫자를 입력할 수 있습니다. 예를 들어, "200p"는 " 손절매 및 이익 실현 레벨을 포지션 진입 가격에서 200포인트 떨어진 곳에 배치"라는 주문을 의미합니다. 앞으로 "Volume", 열에서 볼륨 앞에 마이너스를 넣으면 해당 기호 뒤에 지정된 값만큼 볼륨이 닫힙니다. 예를 들어, 볼륨이 1.0인 포지션이 있고 볼륨의 일부(예: 0.3)를 청산하고 싶다면 볼륨 셀에 "-0.3"을 입력하면 됩니다.

챕터 3. HedgeTerminal의 본네트 밑에서. 작업 원칙 및 사양

3.1. 글로벌 및 로컬 컨투어 정보 본문, 전달, 및 보존

HedgeTerminal의 모습과 거래 과정은 친숙한 MetaTrader 4와 비슷합니다. 이는 MetaTrader 5를 통해 제공되는 거래 정보를 패널에 보다 편리하게 표시할 때 가상화 및 데이터 표시의 변환으로 인해 가능합니다. 이 장에서는 이러한 가상화를 생성할 수 있는 메커니즘과 그룹 데이터 처리 메커니즘에 대해 설명합니다.

아시다시피, HedgeTerminal은 여러 다른 제품으로 표현됩니다. 그 중 주요 기능은 시각적 패널과 프로그램 인터페이스가 있는 라이브러리입니다. 후자는 외부 Expert Advisor에서 양방향 포지션의 관리를 구현할 수 있게 하며 또한 HedgeTerminal 시각적 패널에 통합합니다. 예를 들어, EA의 활성 포지션은 패널에서 바로 청산할 수 있습니다. Expert Advisor가 정보를 입수하고 그에 따라 처리합니다.

분명히 그러한 구조에는 Expert Advisors 간의 그룹 상호 작용이 필요합니다. 패널은 본질적으로 Expert Advisor이기에 패널 역시 발생하는 모든 거래 행위에 대해 인지하고 있어야 합니다. 반대로, HedgeTerminal 라이브러리를 사용하는 모든 Expert Advisor는 수동으로 실행되는 거래 작업(제3자 프로그램 또는 HedgeTerminal 패널 사용)에 대하여 인지해야 합니다.

일반적으로 거래 행위에 대한 정보는 거래 환경에서 받아볼 수 있습니다. 예를 들어 어떤 유저가 새 포지션을 개방하게되면 총 주문의 수가 변경됩니다. 마지막 주문을 참조하면 포지션이 개방된 심볼과 볼륨을 알 수 있습니다. 주문과 거래에 대한 정보는 서버 상에 저장됩니다. 서버 상에 저장되기 때문에 트레이딩 계정에 연결된 터미널이라면 어디에서건 그 정보를 열람할 수 있는 것입니다. 이 정보는 모든 사람이 사용할 수 있고 글로벌 커뮤니케이션 채널을 통해 배포되므로 글로벌이라고 불리기도 하는 것입니다. 거래 서버와의 통신에는 "요청 - 응답" 형식이 있습니다.

그렇기 때문에 이러한 커뮤니케이션은 글로벌 컨투어로 표현될 수 있습니다. "컨투어(Contour)" 란 그래프 이론에서 나온 개념입니다. 간단히 말해서 컨투어란 서로 상호 작용하는 몇 개의 노드가 있는 청산된 선입니다. 이 정의로는 충분하지 않을 수 있지만 정확한 설명은 수학자에게 맡기겠습니다. 우리에게 중요한 것은 거래 프로세스를 청산된 일련의 행동으로 제시하는 것입니다.

필요한 모든 정보를 글로벌 컨투어를 통해 전달할 수 있는 것은 아닙니다. MetaTrader 5는 이 정보가 명시적으로 존재하지 않는 것 외에 이러한 정보 전달도 지원하지 않기 때문에 정보를 넘기기 어렵습니다. 거래 행동의 시퀀스는 다음과 같습니다.

1. 트레이더가 매수 주문을 합니다.
2. 그 주문은 일정 시간이 지나면 체결됩니다.
3. 거래 환경에 변화가 생깁니다. 체결된 주문은 과거 주문 이력으로 넘어갑니다. 심볼의 포지션이 변동합니다.
4. 트레이더 또는 Expert Advisor는 거래 환경의 변화를 감지하고 다음에 취해야할 행동에 대한 결론을 내립니다.

첫번째 행동과 네번째 행동 사이에는 시간이 지나갑니다. 이게 큰 영향을 미칠 수 있습니다. 딱 한 명의 트레이더가 그 계정에서 거래하는 경우엔 어떤 행동들이 취해졌는지 알 수 있고, 서버에서 적절한 응답을 기다리게 됩니다. 만약 여러 트레이더나 Expert Advisor가 그 계정에서 동시에 거래하게된다면 관리 에러가 발생할 수 있습니다.

예를 들자면 두번째 트레이더가 아까의 첫번째와 네번째 단계 사이에 기존 포지션을 청산하는 주문을 할 수 있습니다. 문제의 소지가 보이시나요? 이 두번째 주문은 첫 주문이 체결되었을 때 이루어집니다. 다시 말하면, 포지션 청산 주문이 두 번 보내진다는 의미입니다.

이 예는 트레이더가 계정에서 단독으로 수동으로 거래하고 동기식 주문 방법을 사용하는 경우에는 거의 불가능해 보입니다. 이 계정에서 여러 봇이 거래하고 독립적인 거래 작업을 수행하는 경우 이러한 오류가 발생할 가능성이 높습니다.

HedgeTerminal은 비동기 모드로 작업하고 여러 Expert의 동시 병렬 작업을 보장하는 포지션 관리자이므로 이러한 실수가 벌어질 가능성이 적지않습니다. 이를 피하기 위해 HedgeTerminal은 각 비동기화된 카피들 (HedgeTerminalAPI 라이브러리건 시각 패널이건 관계 없이) 사이의 행동을 로컬 컨투어(Local Contour) 메커니즘을 통해 ActivePositions.xml 파일을 멀티스레딩 읽기/쓰기 처리함으로서 동기화합니다. ActivePositions.xml 파일과의 상호 작용은 HedgeTerminal의 가장 중요한 부분인 로컬 컨투어의 핵심입니다. 이 메커니즘은 아래에 설명되어있습니다.

간단한 방법으로 HedgeTerminal의 작업은 아래 그림과 같이 로컬 및 글로벌 컨투어와의 협력으로 이어집니다.

38번 그림. 글로벌 및 로컬 컨투어 사이의 정보 교환을 간략화한 도식

HedgeTerminal의 모든 거래 작업(다이어그램의 레이블 start )은 ActivePositions.xml에 특수 태그를 작성하여 추가 변경을 차단하는 것으로 시작됩니다.

포지션 블록이 설정되고 로컬 컨투어가 성공적으로 전달된 후 HedgeTerminal은 거래 주문을 서버로 보냅니다. 예를 들자면, 포지션을 청산하기 위한 카운터 주문이 있습니다. 얼마 후 주문이 체결되고 거래 환경이 변화합니다. HedgeTerminal은 이 변화를 처리하고 글로벌 컨투어가 성공적으로 전달되고 주문이 체결되는 것을 감지합니다. 이후 포지션 차단을 해제하고 초기 상태로 돌아갑니다(다이어그램의 레이블 finish).

때때로 주문이 체결될 수 없는 상황이 있습니다. 이 경우 HedgeTerminal도 포지션 블락을 해제하고 MetaTrader 5 터미널의 로그에 실패 원인을 기록합니다.

실제 정보 교류 패턴은 더 복잡합니다. 이미 언급했듯이 하나의 MetaTrader 5 터미널에서 여러 HedgeTerminal 카피를 실행할 수 있습니다. 이 카피들은 라이브러리거나 시각 패널이거나 상관없습니다. 모든 사본은 리스너와 라이터의 역할을 할 수 있습니다. HedgeTerminal이 거래 행동을 할 때 지정된 xml 태그의 레코드를 사용하여 포지션 변경을 차단하기 때문에 이건 라이터입니다. 나머지 다른 모든 HedgeTerminal 카피들은 주기적으로 ActivePositions.xml 파일을 읽고 차단 태그를 가로질러 발생한 포지션 변경을 차단하기때문에 리스입니다.

이 메커니즘은 독립적인 스레드 간에 정보를 퍼뜨리는 것을 보장합니다. HedgeTerminalAPI 라이브러리를 사용하여 여러 패널과 Expert 간의 병렬 작업을 용이하게 합니다.

다중 스레드간 협력 상황에서 HedgeTerminal의 작업을 보여주는 현실적인 다이어그램을 봐주십시오.

39번 그림. HedgeTerminal 카피들 간의 정보 교환 패턴을 거의 현실에 가깝게 도식화한 것

이런 데이터 구조는 상당히 효율적입니다. ActivePositions.xml 파일을 읽고 쓰는 작업은 일반적으로 1밀리초 미만이 소요되는 반면 주문을 보내고 실행하면서 글로벌 컨투어를 전달하는 데는 최대 150-200밀리초가 소요될 수 있습니다. 이러한 값들 간의 스케일 차이를 보려면 다이어그램을 살펴보십시오.

녹색 사각형의 너비는 로컬 컨투어를 통과한 시간을 나타내고 파란색 사각형의 너비는 거래 주문 체결 시간을 나타냅니다.

40번 그림. 파일에 기록하는 타임 스케일 및 주문 체결에 필요한 시간

보시다시피, 녹색 사각형은 수직선처럼 보입니다. 현실에서는 스케일 간의 갭은 훨씬 큽니다.

읽기 및 기록의 빠른 작업은 Expert 간의 복잡한 데이터 교환 및 분산된 고주파 거래 시스템 생성을 용이하게 할 수 있습니다.

3.2. 글로벌 및 로컬 정보 저장하기

일반적으로 HedgeTerminal에서 사용하는 모든 거래 정보는 두 부분으로 나눌 수 있습니다.

• 로컬 정보. 이것은 컴퓨터 파일에 저장되고 로컬 컨투어를 통해서만 전달됩니다.
• 글로벌 정보. 이 정보는 거래 서버에 저장됩니다. 글로벌 정보는 글로벌 컨투어를 통해 전달되며 계정에 연결된 모든 터미널에서 사용할 수 있습니다.

주문, 거래 및 계정에 대한 정보는 글로벌 정보에 속합니다. 이 정보는 HistoryOrderGetInteger() 또는 AccountInfoInteger()와 같은 MetaTrader 5의 특정 함수를 통해 사용할 수 있습니다. HedgeTerminal은 주로 이 정보를 활용합니다. HedgeTerminal이 다음의 정보를 표시하는 것은 그것이 이유입니다.

• HedgeTerminal의 실질, 과거 포지션들
• 과거 현재 주문들의 손절매
• 과거 포지션에서 실행된 이익 실현 레벨
• 활성 포지션에 대한 코멘트, 과거 포지션에 코멘트.
• 활성 및 과거 포지션의 다른 모든 속성은 로컬 정보 목록에 포함되지 않습니다.

이러한 모든 속성은 글로벌이므로 다른 컴퓨터에서 실행되는 HedgeTerminal의 모든 카피에서 공통된 단 하나만이 존재합니다. 예를 들어, 한 양방향 포지션이 터미널 중 하나에서 청산되면 이 포지션이 다른 컴퓨터에서 개방되더라도 HedgeTerminal에서 청산될 것입니다.

글로벌 데이터 외에도 HedgeTerminal은 작업에 로컬 정보를 사용합니다. 로컬 정보는 한 대의 컴퓨터에서만 사용할 수 있습니다. 이 정보는 이하 속성의 기초입니다.

• 활성 포지션들의 이익 실현 레벨
• 트리거 되지 않은 과거 포지션들의 이익 실현 레벨.
• 활성 포지션의 외향 코멘트.
• 양방향 포지션 변경을 차단하는 서비스 플래그.

트리거되지 않은 이익 실현 레벨은 HistoryPositions.xml 파일에 저장됩니다. 나머지 로컬 정보는 ActivePositions.xml 파일에 저장됩니다.

로컬 데이터 저장소는 이익 실현 주문을 배치하면 컴퓨터에서 실행되는 HedgeTerminal 사본에서만 볼 수 있음을 의미합니다. 당신을 제외하고는 그 누구도 이 레벨에 대해 알지 못할 것입니다.

3.3. 손절매 및 이익 실현 레벨 주문 시스템의 문제와 OCO 주문

MetaTrader 5와 MetaTrader 4에는 손절매 및 이익 실현 레벨의 개념이 존재합니다. 이것은 보호적인 정지입니다. MetaTrader 4와 마찬가지로 일정 수준의 손실(손절매, StopLoss) 또는 이익(이익실현, TakeProfit)에 도달하면 포지션을 청산합니다. 그러나 MetaTrader 4에서는 이러한 정지는 각 미결 주문에 대해 개별적으로 활성화됩니다. MetaTrader 5에서 이러한 정지는 전체 집계 순 포지션에 대해 작동합니다.

여기서 문제는 순 포지션이 Expert, 특히 HedgeTerminal의 양방향 포지션과 연결되지 않는다는 점입니다. 즉, 일반 손절매 및 이익 실현 레벨은 양방향 포지션에 사용할 수 없지만 이러한 레벨은 별도의 보류 주문으로 표시될 수 있습니다. 롱 포지션이 개방되어 있는 경우 두 개의 보류 주문이 각각 손절매 및 이익 실현 작업을 구현합니다. 그 중 하나는 이 포지션의 시가보다 높은 지정가 매도이고 다른 하나는 이 가격보다 낮은 역지정가 매도입니다.

실제로 오픈 후 가격이 주문의 지정가 매도에 도달하면 이 주문은 이익으로 포지션을 청산하고, 가격이 역지정가 매도 주문에 도달하면 손실로 포지션을 청산합니다. 유일한 단점은 하나의 주문이 체결된 후 두 번째 주문이 청산되지 않고 가격이 방향을 바꾸면 첫 번째 주문 다음에 두 번째 주문이 체결될 수 있다는 것입니다.

해당 지점에 포지션이 없기 때문에 두 번째 주문을 발동하면 이전 포지션을 청산하는 대신 새 순 포지션이 열립니다.

아래 그림은 롱 포지션에서 보호 역지정가를 사용하는 경우 이 문제가 부각됩니다.

41번 그림. 역지정가 매도 및 지정가 매도 주문을 통한 손절매 및 이익실현 에뮬레이션

이러한 불일치를 피하기 위해 교환 거래에서 OCO 주문 ("하나가 다른 하나를 취소합니다")이 사용됩니다.

이들은 서로 연결된 두 개의 보류 중인 주문이므로 한 주문이 실행되면 다른 주문이 취소됩니다. 이 예에서 한 주문이 트리거된 후 두 번째 주문은 거래 서버에 의해 취소되므로 새 포지션이 열리지 않으며 이것이 바로 우리가 찾고 있는 것입니다. 이 유형의 주문 작업은 아래 다이어그램에 나와 있습니다.

42번 그림. 손절매 및 이익실현의 OCO 주문

MetaTrader 5는 OCO 주문을 지원하지 않습니다. 3개의 주문을 묶음으로 사용할 수 없으므로 손절매와 이익 실현의 역할을 동시에 하는 주문은 적합하지 않습니다. 두 주문 쌍을 사용할 수 있습니다! 따라서 손절매 또는 이익실현이 될 수 있습니다. 

실제로 새로운 양방향 포지션을 초기화하는 실행된 주문과 연결된 보류 주문(예: 손절매)이 배치된 경우 그러한 구성은 안전합니다. 두 번째 보류 주문은 없으며 새로운 양방향 포지션을 열 수 없습니다. 실제로 세 가지 시나리오만 있을 수 있습니다.

• 보류 중인 주문은 브로커 또는 사용자에 의해 어떤 이유로 취소됩니다.
• 보류 중인 주문이 트리거됩니다.
• 보류 중인 주문은 실행되지 않습니다.

다른 시나리오는 없습니다. 보류 중인 주문이 취소되면 손절매 및 이익 실현을 취소하는 것과 같습니다. 보류 중인 주문이 트리거되면 해당 포지션이 닫힙니다. 주문이 실행되지 않으면 손절매가 배치된 양방향 포지션이 활성 상태로 유지됩니다.

보류 중인 주문이 트리거될 때 HedgeTerminal이 비활성화된 경우에도 나중에 시작될 때 트리거를 처리하고 이 주문에 의해 포지션이 청산되었음을 이해할 수 있습니다. 매직 넘버가 있는 필드에 청산 주문이 일반 주문인지, 이익 실현인지 손절매인지를 나타내는 특수 서비스 정보가 포함된 경우 손절매 또는 이익 실현에 의해 포지션이 청산되었는지 확인할 수 있습니다. 링크와 서비스 정보가 매직넘버가 있는 필드에 저장되는 방식은 다음 절에서 자세히 설명한다.

두 개의 실제 보호 정지 장치를 동시에 사용할 수 없기 때문에 HedgeTerminal을 설계할 때 절충안이 만들어졌습니다.

HedgeTerminal의 양방향 포지션은 손절매의 역할을 하는 BuyStop 및 SellStop의 실제 주문에 의해 보호됩니다. 이익 실현 레벨은 가상이며 한 컴퓨터에서 실행되는 HedgeTerminal 사본 레벨에서 지원되며 글로벌 레벨에서는 사용할 수 없습니다.

손절매 레벨은 높은 레벨의 트리거링 안정성이 필요한 레벨이므로 선택됩니다. 이익 실현이 작동하지 않으면 치명적이지 않고 계정이 마진 콜로 닫히지 않는 반면 트리거되지 않은 손절매는 계정 파산으로 이어질 수 있습니다.

그럼에도 불구하고 포지션을 추적하는 방법을 선택할 수 있는 알고리즘적 기회가 있습니다. 실제 손절매와 가상 이익 실현 또는 가상 손절매와 실제 이익 실현 중에서 선택할 수 있습니다. 손절매 및 이익 실현 레벨도 가상일 수 있습니다. 현재 이 기능은 구현되지 않았지만 필요할 경우 나타날 수 있습니다.

이익 실현 레벨의 가상화는 크게는 아니지만 일반적인 안정성을 낮춥니다. 이익 실현 레벨은 로컬로 배포되며 모든 HedgeTerminal 사본에서 사용할 수 있습니다. 이익 실현을 실행하려면 라이브러리 또는 HedgeTerminal 패널을 사용하는 Expert Advisor로서 HedgeTerminal의 실행 중인 복사본이 하나 이상 있으면 충분합니다. 여러 개의 HedgeTerminal 복사본이 실행 중인 경우 그 중 하나만 이익 실현을 실행합니다. 양방향 포지션에 차단 태그를 넣는 것은 처음입니다. 이러한 의미에서 HedgeTerminal의 인스턴스는 데이터 쓰기 및 읽기의 다중 스레드 모드에서 서로 경쟁합니다.

사용자의 경우 HedgeTerminal 패널을 통해 수동으로 거래하거나 EA의 가상화 라이브러리를 사용하는 경우 이익 실현 작업은 손절매 작업과 다르지 않습니다. 이러한 레벨 간의 모든 사실적 차이는 HedgeTerminal 뒤에 숨겨져 있습니다. 트레이더는 "이익 실현" 및 "손절매"를 입력하는 것으로 충분합니다. 이러한 레벨은 동시에 표시되며 레벨 중 하나의 트리거에 대해 동일한 색상 표시 경고가 나타납니다.

3.4. OCO 주문이 양방향 포지션 보호 문제를 해결할 수 있을까?

OCO 주문을 통해 실제 손절매 및 이익 실현 레벨을 동시에 사용할 수 있습니다. 이 주문들은 양방향 거래를 조직하는 데에 전부 쓰일 수 있는게 사실일까요? 아래는 그것들의 특성입니다. 우리는 이미 OCO 주문이 다른 주문이 실행될 때 한 주문을 취소할 수 있다는 것을 알고 있습니다.

손절매와 이익실현은 컴퓨터에서 HedgeTerminal이 실행될 필요가 없는 실제 주문이 될 수 있기 때문에 양쪽에서 우리의 양방향 포지션을 보호할 것으로 보입니다. 문제는 교환 주문 실행에서 부분 주문 체결을 고려해야 한다는 것입니다. 이 속성은 응용 프로그램의 비즈니스 논리를 파괴할 수 있습니다. 간단한 예를 살펴보겠습니다.

1. 10개 계약의 롱 포지션이 오픈됩니다. 손절매 및 이익 실현 레벨을 구현하는 두 개의 연결된 OCO 주문이 배치됩니다.
2. 이익 실현 레벨에 도달하면 SellLimit 주문이 부분적으로 실행됩니다. 10개 계약 중 7개가 이에 의해 청산되었고 나머지 3개는 롱 포지션으로 열린 상태를 유지했습니다.
3. Stop Loss 레벨을 구현한 Sell Stop 주문은 연결된 Sell Limit 주문이 부분적으로만 실행되어 취소됩니다.
4. 세 계약의 포지션에는 더 이상 보호 정지가 없습니다.

이 시나리오는 아래 그림에 나와 있습니다.

43번 그림. 보호 정지의 부분 실행

OCO 명령이 부분 실행을 설명하고 보호 정지 해제를 방지할 수 있도록 설계될 수 있다는 이의가 있을 수 있습니다. 두 개의 OCO 주문 볼륨을 상호 연결할 수 있습니다. 이 경우 부분 실행이 확실히 예상됩니다. 그러나 이것은 순 거래에 사용되는 주문 시스템의 복잡한 논리를 복잡하게 만듭니다.

여기서 주요 문제는 OCO 주문이 부분 실행을 고려하더라도 MetaTrader 4와 동일한 기회를 제공할 수 없다는 것입니다. 예를 들어, 이익 실현 및 손절매 레벨으로 보류 중인 주문을 하는 것은 어려울 것입니다. 그 이유는 두 개의 상호 연결된 주문이 시작 주문의 트리거를 고려할 수 없기 때문입니다.

MetaTrader 4와 유사한 포지션을 관리할 수 있는 진정으로 다재다능한 알고리즘을 작성하려면 OCO 주문이 다음과 같은 특성을 가져야 합니다.

1. 모든 연결된 주문은 연결된 주문의 실행 정도에 따라 볼륨을 조정해야 합니다. 예를 들어 이익 실현이 10개의 컨택 중 7개를 실행한 경우 연결된 손절매는 볼륨을 10에서 3(10 - 7 = 3)으로 변경해야 합니다.
2. 연결된 각 주문은 초기화 주문 실행의 양을 고려해야 합니다. 트레이더가 BuyLimit 유형의 보류 주문을 넣고 손절매 및 이익 실현으로 주문 형태로 보호하는 경우 BuyLimit이 전체 거래량을 실행한다는 것을 반드시 의미하지는 않습니다. 이러한 경우는 또한 쌍을 이루는 주문에 의해 처리되어야 합니다.
3. 취소 조건 외에 짝을 이루는 주문에는 발동 조건이 추가로 있어야 합니다. 연결된 추가 주문이 트리거될 때만 트리거될 수 있습니다. 즉, OCO 주문에는 두 주문에 대한 링크가 있어야 합니다. 첫 번째 링크는 트리거링이 현재 주문을 활성화하는 주문에 대한 것입니다. 두 번째 링크는 트리거가 현재 주문을 취소하는 주문입니다. 이러한 메커니즘을 사용하면 보류 중인 초기화 순서가 있는 포지션을 만들 수 있습니다.

이러한 메커니즘은 나타나더라도 경험이 제한된 사용자에게는 매우 복잡합니다. 적합성이 의심가기 시작합니다. 현재 HedgeTerminal에서 사용되는 것과 같은 클라이언트 측 가상화가 사용하기 더 쉽습니다.

OCO 주문의 대안으로 MetaQuotes는 특정 거래 주문의 보호를 보장하는 특정 알고리즘 이익 실현 및 손절매 레벨을 도입할 가능성을 고려할 수 있습니다. 물론 이것은 합리적인 커널을 가지고 있지만 이론 일뿐입니다. 이러한 알고리즘 레벨은 최종 사용자에게 즉시 사용할 수 있는 간단한 보호 메커니즘을 제공하는 거래 서버 측에서 구현 및 구성의 주요 부분을 숨길 수 있습니다.

요약하자면, MetaTrader 5 플랫폼에서 OCO 주문을 통합하는 관점에 대한 우리의 작은 담론:

OCO 주문은 주문이 부분적으로 실행될 때 효과적이지 않으며 플랫폼의 일반 사용자에게는 충분히 신뢰할 수 없고 너무 복잡합니다. 

3.5. 주문 초기화용 링크 보관하기

이 섹션에서는 다른 주문에 대한 링크의 내부 저장 및 이들 간의 바인딩 메커니즘에 대한 자세한 설명을 해보겠습니다. 앞에서 언급했듯이 "Order Magic" 필드에는 주문한 Expert Advisor의 식별자가 포함됩니다. 이는 모든 트레이더가 MQL5 프로그래밍 언어를 사용하여 이 필드에 정수 값을 입력할 수 있음을 의미합니다. 이러한 경우 새 포지션을 초기화하는 주문에 기존 주문의 식별자와 일치하는 Expert Advisor의 식별자가 포함될 때 충돌이 가능합니다. 이 경우 주문에 대한 잘못된 링크가 나타납니다.

상인이 "1", "7" 또는 "100"과 같이 0에 가까운 EA에 대한 식별자와 주문 번호를 사용하는 경우 "10002384732"와 같은 숫자보다 훨씬 크면 이러한 충돌을 피할 수 있습니다. 트레이더들이 그것을 염두에 둘 것이라고 믿는 것은 오히려 순진할 것입니다. 이것이 HedgeTerminal이 특별한 방식으로 주문에 대한 링크를 저장하는 이유이므로 충돌 가능성이 매우 낮고 알고리즘이 모호성을 허용하지 않으며 충돌이 나타날 경우 자동으로 충돌을 제거합니다.

링크를 저장하는 "Order Magic" 필드는 64비트를 사용합니다. 너비로 인해 이 필드는 매우 긴 숫자를 사용할 수 있습니다. 실제로 주문 식별자의 작업 범위는 훨씬 작습니다. 이를 통해 헤지 터미널은 필요에 따라 이 필드의 더 높은 자릿수를 안전하게 사용하여 특별한 방식으로 주문에 대한 링크를 형성할 수 있습니다. HedgeTerminal이 시작 주문에 대한 링크를 저장하는 방법을 보여주는 체계를 참조하십시오.

44번 그림. HedgeTerminal에 초기화 순서에 대한 링크를 저장하는 패턴

필드(63)의 맨 위 숫자는 항상 1로 표시됩니다. 이것은 모든 주문에 대해 매우 빠른 반복을 가능하게 합니다. 분명히 다음 숫자가 1이 아니면 주문에 다른 주문에 대한 링크가 포함될 수 없으며 건너뛸 수 있습니다. 게다가, 가장 높은 자리에 1의 값을 할당하면 매직 넘버가 매우 커져서 주문 식별자의 작업 범위와 HedgeTerminal의 링크 작업 범위 사이의 거리를 증가시켜 충돌 가능성을 최소화합니다.

HedgeTerminal은 다음 세 비트를 서비스 정보로 채울 수 있습니다. 주문 식별자와 달리 HedgeTerminal은 이 필드에 주문 식별자를 뒤집어서 저장합니다. 처음에는 더 높은 숫자를 채우고 그 다음에는 그림 44에서 파란색 화살표 방향 SI (서비스 정보)가 가리키는 작은 숫자를 채웁니다. 이러한 저장 방식은 서비스 정보 및 주문 식별자의 범위를 절반으로 만듭니다. 필요한 경우 구성을 변경할 수 있습니다. 서비스 정보의 크기는 주문 식별자를 저장하는 숫자를 통해 늘릴 수 있습니다. 이 정보를 통해 청산 주문 유형을 식별할 수 있습니다.

요점은 MetaTrader 4의 활성 주문이 이익 실현 또는 손절매로 청산될 수 있다는 것입니다. 고정 이익 또는 손실로 주문이 청산되는 특정 가격 레벨입니다. MetaTrader 5에서 이익 실현 및 손절매는 순포지션에만 적용할 수 있으며 짝 주문에는 적합하지 않습니다. 일반 보류 주문만이 이익실현 및 손절매 주문의 역할을 할 수 있습니다.

HedgeTerminal에서 이러한 주문에는 이것이 이익 실현 또는 손절매 주문인지 여부를 지정하는 특수 식별자가 할당됩니다. 매직넘버가 트레이딩 서버에 저장됨에 따라 해당 트레이딩 계정에 접속한 모든 트레이더가 서비스 정보를 이용할 수 있게 됩니다. 이렇게 하면 서로 다른 컴퓨터에서 실행되는 여러 HedgeTerminal 사본에도 트리거된 주문 유형에 대한 정보가 표시되고 청산된 포지션에 대한 정보가 올바르게 표시됩니다.

주문식별자에 대한 참조정보는 0 ~ 59 자릿수로 저장됩니다. 이 정보는 파란색 화살표 방향 순서 id, 오른쪽에서 왼쪽으로 이어지는 숫자정보를 활용하여 저장됩니다. 할당된 저장공간을 측정하려면 한 해 동안 모스크바 거래소에 보내진 모든 주문의 범위를 저장하는데에 필요한 양을 계산해야합니다.

2013년 6월 13일자 내 브로커의 보고서에는 10 789 965 471 식별자가 있는 주문이 포함되어 있습니다. 이 숫자는 64자리 중 33.3297비트 (log2(10 789 965 471)) 또는 34를 사용합니다. 2014년 9월 25일까지 접수된 주문 중 하나의 식별자는 13 400 775 716입니다. 이 숫자는 33.6416 비트를 사용합니다. 1년 4개월 만에 26억 건의 주문을 했음에도 불구하고, 식별자의 크기는 0.31263비트만 증가하여 1개 주문도 되지 않습니다. 나는 주문 식별자의 크기가 59자리가 되기 전에 태양이 죽을 것이라고 주장하지는 않지만 이것이 빠르면 몇 백만 년 이내에 일어날 것이라고 나는 꽤 확신합니다.

HedgeTerminal은 링크를 공개적으로 저장하지 않습니다. 이를 위해 OrderMagic 필드를 암호화하여 상위 숫자는 그대로 유지합니다. HedgeTerminal의 코드는 가변 길이 키에서 작동하는 특수 암호화 기능에 의해 구현된 가역적인 숫자 재배열을 기반으로 합니다. 이러한 암호화 후 서비스 정보와 주문 식별자는 서로 혼합되어 특수 마스크 아래 숨겨져 출구에서 1과 0의 균등한 분포를 나타냅니다. 암호화는 두 가지 이유로 발생합니다. 우선, 숫자 재정렬은 링크와 주문 식별자가 중복될 확률을 줄인 다음 외부의 고의적이거나 무작위적인 영향으로부터 HedgeTerminal의 내부 알고리즘을 보호합니다.

이 절차는 절대적으로 안전하고 가역적이며 충돌이 발생하지 않습니다. 이는 트레이더가 Expert Advisors를 사용하여 수행하는 작업과 관계없이 내부 HedgeTerminal 알고리즘의 신뢰성에 영향을 미치지 않음을 보증합니다. 복잡한 전용 알고리즘 없이는 이러한 링크를 관리하는 것이 실제 상황에서 불가능하기 때문에 이는 매우 중요합니다.

동시에 링크 제어에만 국한된다면 비즈니스 로직의 실패는 불가피합니다. 다음 섹션에서는 이러한 알고리즘에 대한 자세한 설명에 전념하는 이유를 설명합니다. 이 실패를 방지하기 위해 암호화도 사용됩니다. 이 제한의 동전의 반대는 HedgeTerminal 포지션을 관리하는 데 이것을 사용하는 것 외에 다른 방법이 없다는 것입니다.

3.6. HedgeTerminal 작업의 한계

링크 저장 구조의 특성으로 인해 HedgeTerminal은 9223372036854775808 에서 18446744073709551615까지의 숫자를 사용하여 주문에 대한 링크를 균등하게 저장합니다. 64자리 필드가 긴 유형의 부호가 있는 숫자로 표시되는 경우 음수 값이 됩니다. 여기에서 HedgeTerminal 작업에 대한 세 가지 제한 사항이 발생합니다.

첫 번째 제한 사항은 HedgeTerminal과 함께 작동하는 거래 봇에 관한 것입니다. 이것은 엄격하지 않으며 권장 사항으로 취급될 수 있습니다.

HedgeTerminal과 함께 작업하는 거래 봇 또는 Expert Advisor에는 값을 초과하지 않는 식별자(Expert의 매직 넘버)가 있어야 합니다. 9223372036854775808.

실제로 일반 Expert Advisors는 5-6자리를 초과하는 식별자가 매우 드물게 사용되기 때문에 이러한 제한을 겪지 않을 것입니다. Expert의 가장 일반적인 식별자는 "12345" 또는 이와 유사한 것입니다. 이 제한은 다른 주문에 대한 링크와 같은 서비스 정보를 매직 넘버에 저장하는 봇에 적용될 수 있습니다. HedgeTerminal은 이러한 Expert와 호환되지 않으며 함께 작동할 수 없습니다.

어떤 이유로 언급된 한계를 초과하면 충돌 가능성이 0으로 나타납니다. 후자는 그러한 범위에서 우연의 일치가 매우 희박하기 때문에 매우 작습니다. 이 경우에도 HedgeTerminal은 알고리즘을 사용하여 이 충돌을 해결할 것입니다. 이렇게 하면 링크를 해독하고 이 링크를 기존 주문과 비교하고 이 주문을 다른 주문과 페어링하기에 적합한지 분석하는 데 시간이 더 걸리기 때문에 작업 속도가 느려집니다. 따라서 이를 피하려면 음수 부호가 있는 긴 숫자를 사용하지 않는 것이 좋습니다.

두 번째 제한은 어렵지만 브로커와 HedgeTerminal이 다음에 연결될 거래소에만 해당됩니다.

주문 식별자는 0에서 2^59 또는 576 460 752 303 423 488 사이의 숫자를 사용해야 합니다.

이는 주문 식별자를 저장하는 데 64자리 대신 59자리만 사용되기 때문에 굳이 말 할 필요도 없습니다. 브로커가 이 값보다 큰 주문 식별자를 사용하는 경우 작업에서 헤지 터미널을 사용할 수 없습니다.

세 번째 제한은 포지션 표현 방식에서 따릅니다.

HedgeTerminal은 다른 포지션 관리 시스템과 호환되지 않습니다. 이는 포지션 청산 기능이 있는 외부 트레이딩 패널과 호환되지 않으며 함께 사용할 수 없습니다.

3.7. 거래 페어링 및 행동 판단 메커니즘

지금까지 우리는 HedgeTerminal에서의 포지션 표현과 그 링크의 구조를 자세히 살펴보았습니다. 바인딩된 주문을 관리하는 알고리즘 설명에 대해서는 논의하지 않습니다. 예를 들어, 다른 여러 주문에서 두 개의 주문을 선택했는데 이를 연결해야 합니다. 주문에 대한 링크가 고유해야 하고 하나의 주문에서만 소유해야 한다는 규칙에 의존하지 않으면 가능한 모든 상황을 세 그룹으로 나눌 수 있습니다.

1. 주문은 다른 주문에서 참조되지 않습니다.
2. 주문은 하나의 주문에 의해 참조됩니다.
3. 두 개 이상의 주문이 주문을 참조합니다.

첫 번째 그룹은 어렵지 않습니다. 그러한 명령은 개방 포지션으로 간주됩니다. 한 쌍의 주문이 청산된 포지션을 만들기 때문에 세 번째 그룹도 매우 간단합니다. 세 번째 그룹의 경우 어떻게 해야할까요? 주문이 다른 두 주문에서 참조되는 경우 어떻게 됩니까? 그 중 첫 번째 주문과 연결되어야 하는 것은 무엇이며 두 번째 주문은 어떻게 될까요? 페어링 프로세스를 순차적 프로세스로 제시하면 이 질문에 쉽게 답할 수 있습니다.

1. 다른 주문에 대한 링크가 포함되지 않은 주문을 발견했습니다. 활성 주문(포지션) 섹션으로 전송되고 그 후 주문에 대한 반복이 계속됩니다.
2. 그런 다음 첫 번째 주문을 참조하는 또 다른 주문을 발견합니다. 그런 다음 참조된 주문이 활성 주문 섹션에서 검색됩니다. 참조된 주문이 이 섹션에 있으면 현재 주문과 쌍을 이루고 둘 다 과거 포지션의 형태로 완전한 거래 섹션으로 전송됩니다.
3. 추가 반복 중에 1번 항목에 설명된 주문에 대한 링크가 포함된 주문이 하나 더 있습니다. 그런 다음 참조된 주문이 활성 주문 섹션에서 검색됩니다. 이번에는 요청한 주문이 이 섹션에서 완료된 거래 섹션으로 이월되어 검색에 실패합니다. 현재 주문에서 참조하는 주문을 찾을 수 없으므로 링크에도 불구하고 현재 주문은 활성 주문이며 활성 포지션이 있는 섹션으로 전달됩니다.

주문 식별자가 일관된 방식으로 채워지고 목록이 시간별로 정렬되므로 순차적 반복을 수행할 수 있습니다. 따라서 초기화 순서는 동일한 링크를 포함하는 다른 주문의 수에 관계없이 링크가 포함된 첫 번째 순서와 쌍을 이룹니다. 초기화 주문에 대한 링크가 포함된 다른 모든 주문은 활성 개시 포지션 목록에 포함됩니다.

이미 언급했듯이 이러한 반복을 실행하는 알고리즘은 완전히 결정론적이고 일관적이어야합니다. HedgeTerminal은 작업에서 이러한 반복 알고리즘을 사용합니다. 사실 이것은 단순한 반복이 아니라 첫 번째 거래의 순간부터 수행된 모든 거래 행위의 반복입니다. 효과적으로, HedgeTerminal은 출시될 때마다 처음부터 현재 순간까지 일련의 거래 행동을 일관되게 구축합니다. 그 덕분에 현재 포지션 표현은 출시 시점의 소급 거래의 결과입니다.

이력의 모든 주문에 대한 반복이 순차적으로 수행되기 때문에 거래 행위도 순차적으로 수행해야 합니다. HedgeTerminal에서 주문 실행 방식을 결정합니다. 예를 들어, 손절매에 의해 보호되는 활성 양방향 HedgeTerminal 포지션은 닫혀야 합니다. 우리는 그러한 양방향 포지션이 본질적으로 활성 포지션을 개시하는 실행된 주문과 손절매 주문으로 작동하는 보류 중인 주문 매수 정지 또는 매도 정지라는 두 가지 주문으로 구성된다는 것을 알고 있습니다. 이러한 포지션을 청산하려면 보류 중인 주문을 삭제하고 동일한 볼륨의 카운터 오더로 활성 양방향 포지션을 청산해야 합니다. 따라서 두 가지 거래 작업을 수행해야 합니다. HedgeTerminal은 모든 거래 주문을 비동기식으로 실행합니다.

이 방법으로 주문을 동시에 실행할 수 있습니다. 즉, 첫 번째 주문은 보류 중인 주문을 취소하고 두 번째 주문은 카운터 주문을 실행하여 포지션을 닫을 수 있습니다. 그러나 이것은 행동의 결정론을 뒤엎을 것이고 HedgeTerminal은 그것을 수행할 수 없습니다. 어떤 이유로 보류 중인 주문이 취소되지 않고 카운터 주문에 의해 포지션이 청산되지 않으면 포지션이 청산되고 손절매가 여전히 존재하기 때문에 모호성이 있습니다. 결국 손절매를 구현하는 주문은 새로운 양방향 포지션을 트리거하고 생성할 수 있습니다. 그런 일이 일어나서는 안 됩니다. 이것이 헤지 터미널이 손절매를 취소하고 성공적인 취소 후에 카운터 오더를 하는 이유입니다. 카운터 오더가 실행되지 않거나 두 번째 단계에서 부분적으로 실행되지 않을 가능성이 있습니다. 그러나 이 경우 부분적으로 실행된 카운터 오더가 활성 포지션의 일부를 청산하므로 모호성이 제거됩니다. 이것은 일반적인 상황입니다.

HedgeTerminal에 의해 구현된 보다 복잡한 일련의 작업이 있습니다. 이전과 유사한 예를 사용하지만 이번에는 포지션의 일부를 청산합니다. 이는 HedgeTerminal이 세 가지 작업을 수행해야 함을 의미합니다.

1. 손절매 주문으로 작용한 보류 주문을 삭제합니다.
2. 양방향 포지션의 볼륨의 일부를 닫는 카운터 주문을 실행합니다.
3. 활성 포지션의 나머지 부분을 보호하는 새 볼륨으로 새 손절매를 배치합니다.

이러한 모든 작업은 작업의 결정론을 방해하지 않도록 일관되게 실행됩니다. 당연하게도 예상할 수 있는 것은 동시 주문으로 인한 주문 실행 속도의 증가이지만, 이 경우 거래 작업의 순차적 실행이 보장되지 않고 모호함이 발생할 수 있습니다. 순차 주문 처리는 모호성을 의미하지 않습니다.

3.8. 거래 분리 및 연결 - 주문 산술의 기초

순차적 주문 처리로는 충분하지 않습니다. 여기서 두 가지 사항에 유의해야 합니다.

• 하나의 주문에는 여러 거래가 포함될 수 있습니다. 이러한 거래의 수는 무작위일 수 있습니다.
• 부분 주문 실행 및 청산 주문의 양이 시작 주문의 양과 같지 않을 수 있는 보다 일반적인 경우를 고려하는 것도 중요합니다.

주문은 동시에 여러 거래에 의해 실행될 수 있으며 부분적으로 실행될 수 있습니다. 왜 이런 일이 일어날 수 있는지 모르겠다면 "모스크바 거래소 파생상품 시장의 사례를 통한 환율 가격 책정 원칙" 거래소 가격 책정에 대한 설명 전용 문서를 참조하십시오. "왜 청산 주문량이 개시 주문량과 같지 않을 수 있습니까?"라는 질문이 있습니다. 답변이 필요합니다. 이 경우 우리는 무엇을 할 수 있습니까?

실제로 활성 포지션의 부분적 청산 기회를 가정한다면 그들의 양은 같지 않을 수 있습니다. 50계약의 거래량으로 활성 포지션을 개설하고 20계약의 거래량으로 카운터 오더로 포지션의 일부를 청산하면 활성 포지션은 두 부분으로 분할됩니다. 첫 번째 부분은 카운터 주문으로 20개 주문의 볼륨으로 새로운 과거 포지션을 만들 것이고 두 번째 부분은 볼륨이 줄어들고 30개 계약이 될지라도 여전히 열려 있습니다.

부분 포지션 청산의 이 알고리즘은 HedgeTerminal에서 구현됩니다. HedgeTerminal 패널의 "Volume" 필드에 새 볼륨 값이 입력되면 부분 청산가 발생합니다. "기록" 폴더에 새 포지션이 표시되고 현재 포지션의 볼륨이 새 값과 동일합니다. HedgeTerminal은 청산 주문의 양이 시작 주문의 볼륨보다 큰 경우에도 상황을 처리할 수 있습니다! 이러한 상황은 어떤 이유로 HedgeTerminal이 청산 주문의 잘못된 볼륨을 배치하거나 브로커가 시작 주문에 포함된 여러 거래를 백핸드로 취소하고 실행된 볼륨이 더 작은 것으로 변경되는 경우 발생할 수 있습니다.

거래량의 잠재적 차이를 고려하려면 주문과 관련된 모든 거래의 총 거래량 계산을 기반으로 하는 범용 알고리즘을 사용해야 합니다. 이 경우 모든 것을 결정하는 것은 주문이 아니라 거래입니다. 주문량은 거래량입니다. 실행된 주문의 가격은 거래의 평균 가격입니다.

HedgeTerminal은 주문을 서로 연결하거나 나누는 알고리즘을 사용합니다. 그것은 거래의 더하기와 빼기를 기반으로 합니다. 그것의 작업은 과거 포지션의 다음 형성과 함께 초기화 및 청산 주문 간의 거래를 통합하는 것을 기반으로 합니다.

이 알고리즘이 작동하는 방식을 이해하기 위해 과거 포지션을 만들기 위해 쌍을 이루는 데 필요한 두 가지 주문이 있다고 가정해 보겠습니다. 두 주문 모두 동일한 수의 거래를 갖고 있고 실행된 볼륨도 동일합니다. 단순성을 위해 거래 수는 세 자리입니다.

주문 #1 (인 주문)	볼륨 (10/10)
거래 #283	3
거래 #288	2
거래 #294	5

3번 테이블. 1번 주문과 그 거래들

주문 #2 (아웃 주문)	볼륨 (10/10)
거래 #871	1
거래 #882	3
거래 #921	6

4번 테이블. 2번 오더와 그 거래들

거래량들과 볼륨을 합칩시다.

5번 테이블. 주문들 한 데 뭉치기

각 열에서 두 개의 마지막 주문(294번 및 921번)을 선택합니다. 일반적으로 서로 같은 레벨에 있을 수 없습니다(이 예와 같이).

거래량이 가장 적은 거래를 선택하십시오. 이것은 볼륨 5인 294번 거래입니다. 반대 거래 921번을 둘로 나눕니다. 첫 번째 거래는 거래량 294번(5 계약)와 같고 두 번째 거래에는 1계약(6계약 – 5계약 = 1계약)의 나머지 거래량이 포함됩니다. 비슷한 볼륨의 볼륨 921번의 첫 번째 부분과 볼륨 5의 거래 294번을 결합합니다.

6번 테이블. 볼륨 빼기

과거 포지션의 거래를 포함하는 새 열로 통합된 부분을 전송합니다.

이것은 녹색으로 강조표시됩니다. 활성 포지션의 초기 열에 볼륨 1이 있는 거래 #921의 나머지 부분을 그대로 둡니다. 이것은 회색으로 강조표시됩니다.

7번 테이블. 딜 분할 및 이행

우리는 두 주문의 거래를 통합하고 과거 포지션으로 옮기는 첫 번째 단계를 밟았습니다. 간단한 형식으로 일련의 작업을 반영해 보겠습니다.

8번 테이블. 딜 분할 및 이행 1단계

거래량 294번은 과거 포지션 섹션으로 완전히 이월되었습니다. 거래가 완전히 파기되었습니다. 따라서 거래는 분할되어 과거 주문 섹션으로 이월되었습니다. 그렇기 때문에 다음 단계에서 볼륨 2와 함께 다음 288번 거래를 진행할 수 있습니다. 921번 거래는 여전히 존재하며 거래량은 거래의 나머지 두 번째 부분과 같습니다. 다음 단계에서 이 볼륨은 288번 거래 볼륨 과 상호 작용합니다.

두 번째 단계에서 288번 및 921번 거래로 절차를 반복합니다. 이번에는 921번 거래량 (1 계약)의 나머지 거래량은 과거 주문 열에 도달한 후 288번 거래량과 통합됩니다. 288번 거래의 나머지 볼륨은 1 계약과 동일하며 활성 포지션 열에 남아 있습니다.

 

9번 테이블. 딜 분할 및 이행 1-2 단계

288번 및 882번 거래로 똑같이 반복해줍니다.

10번 테이블. 딜 분할 및 이행 1-3 단계

같은 방식으로 4, 5 단계를 시행합니다.

11번 테이블. 딜 분할 및 이행 1-5 스텝

V 단계 후 청산 주문의 양은 시작 주문 거래의 양과 절대적으로 동일합니다. 과거 포지션의 열로 이월된 거래는 완전한 과거 거래가 됩니다. 활성 포지션의 나머지 거래는 활성 포지션이 됩니다. 이 경우 활성 포지션의 열에 거래가 남아 있지 않습니다. 이것은 그러한 통합 후에 활성 포지션이 더 이상 존재하지 않음을 의미합니다. 새로운 과거 포지션이 나타나고 활성 포지션의 모든 거래가 포함될 것입니다.

거래가 이월된 후 많은 거래가 부분으로 분할되어 여러 라인을 차지하게 됩니다. 이를 피하기 위해 거래를 통합/분할하는 알고리즘에 거래 수집 옵션을 추가할 수 있습니다. 동일한 식별자를 가진 거래의 볼륨을 다음으로 간단히 통합합니다.

12번 테이블. 같은 레벨 내 딜 통합

통합 후 거래 수와 거래량은 초기 거래 및 거래량과 완전히 일치합니다. 이것은 볼륨이 처음에 일치했기 때문에 발생합니다. 볼륨이 다르면 통합 절차 후 거래의 볼륨이 달라집니다.

이 알고리즘은 개시 및 청산 주문에 대해 동일한 수의 거래가 필요하지 않기 때문에 보편적입니다. 이 속성을 기반으로 하는 또 다른 예가 있습니다.

13번 테이블. 각기 다른 수의 딜들과 주문들 합치기

우리가 볼 수 있듯이 명령을 하나의 과거 포지션으로 통합하는 데 성공했습니다. 거래 건수는 다르지만 거래량은 다시 일치했습니다.

이제 청산 주문의 총량(12개 계약)이 개시 주문의 거래량(22개 계약)보다 작다고 상상해 보십시오. 이 경우 통합은 어떻게 될까요?

14번 테이블. 각기 다른 양의 주문들 합치기

우리가 볼 수 있듯이 두 번째 단계에서 청산 주문의 거래량은 0과 같지만 시작 주문에는 볼륨이 4인 321번 거래 및 볼륨이 6인 344번 거래 이렇게 두 개 더 포함되어 있습니다. 활성 주문 거래를 초과했습니다. 이 초과분은 활성 양방향 포지션으로 존재합니다. 그러나 녹색 열로 이월된 거래와 함께 새로운 과거 포지션이 있습니다. 12 계약의 초기 및 종료 볼륨이 다시 일치했습니다.

청산 주문의 양이 개시 주문보다 큰 경우, 이번에는 청산 주문의 측면에 있지만 초과도 있습니다.

15번 테이블. 각기 다른 양의 주문들 합치기

보시다시피, 볼륨 4의 초기 주문과 볼륨 6의 청산 주문은 두 포지션을 만듭니다. 첫 번째는 볼륨 4의 과거 포지션이며 초기 주문의 625번과 청산 주문의 719번, 720번을 거래합니다. 두 번째 포지션은 이러한 주문의 초과 거래입니다. 여기에는 2권의 719번 거래가 포함되어 있습니다. 이 거래와 주문은 HedgeTerminal 패널의 "활성" 탭에서 활성 포지션을 만듭니다.

거래 및 주문은 알고리즘에 의해 과거 및 활성 포지션으로 나눌 수 있습니다. 볼륨은 다를 수 있습니다. 가장 중요한 것은 알고리즘이 동일한 양의 진입 및 퇴장으로 과거 포지션을 형성함으로써 개시 및 청산 주문의 양을 함께 모을 수 있다는 것입니다. 이는 이러한 볼륨이 같지 않아 포지션의 비대칭을 유발하는 포지션 표현의 오류가 없는 상황의 불가능성을 보장합니다.

첫 번째 예에서 브로커가 청산에 포함된 거래를 취소했다고 가정해 보겠습니다.

16번 테이블. 과거 이력의 딜 삭제 시뮬레이션

6개 계약의 새로운 순포지션입니다. 취소된 거래의 양과 같습니다. 이 경우 Hedge Terminal의 알고리즘이 어떻게 작동하는지 봅시다.

17번 테이블. 표현 엄밀성 복구하기

보시다시피 2단계에서는 6계약(3+2+1)을 초과합니다. 이 초과분은 활성 포지션으로 바뀌므로 양방향 포지션의 볼륨과 방향은 순 포지션의 볼륨과 방향과 같습니다.

요약하면, 우리는 거래 통합 알고리즘이 과도한 언바운드 거래로 인해 과거 포지션에서 시작 및 청산 주문의 양의 평등을 보장한다고 말할 수 있습니다. 이 초과 거래는 활성 양방향 포지션을 만들어 MetaTrader 5의 순 포지션을 HedgeTerminal의 모든 활성 포지션의 순 포지션과 동일하게 만듭니다.

이 메커니즘은 소급적으로 그리고 실시간 모드에서 모두 작동하며 이는 거래 조치 취소에 대한 브로커의 조치와 상관없이 MetaTrader 5의 순 포지션과 함께 헤지 터미널의 순 포지션을 생성한다는 것을 의미합니다. 순포지션 변경 및 거래 취소에 대한 조합은 터미널의 순포지션과 HedgeTerminal의 순포지션 간의 비대칭을 일으키지 않기 때문일 수 있습니다.

부분 포지션 청산의 메커니즘은 이 알고리즘이 서로 다른 볼륨을 결합하는 기능을 기반으로 합니다. 이 알고리즘은 설정이 필요 없는 자체 적응 시스템으로 안정적인 작동을 보장하는 HedgeTerminal의 가장 중요한 부분 중 하나입니다.

3.9. 주문 및 매매 가상화

HedgeTerminal의 모든 주문과 거래에는 해당 식별자가 있는 실제 프로토타입이 있습니다. 그럼에도 불구하고, HedgeTerminal의 관점에서 하나의 주문은 활성 포지션을 만들 수 있으며 동시에 과거 포지션의 일부가 될 수 있습니다. MetaTrader 5의 거래 및 주문은 분리할 수 없는 개체입니다. 플랫폼의 주문은 보류 중이거나 실행될 수 있습니다. 거래는 또한 일정한 볼륨을 가지며 항상 실행되는 트랜잭션입니다.

HedgeTerminal에서는 동일한 주문과 거래가 서로 다른 양방향 포지션에 있을 수 있습니다. 동일한 거래 또는 주문이 활성 및 과거 포지션이 될 수 있습니다. 즉, HedgeTerminal의 주문과 거래는 여러 가상으로 나뉩니다. 이 데이터 표현은 MetaTrader 5의 데이터 표현과 크게 다릅니다. 그러나 이 표현을 통해 유연하고 거래 정보의 소급 변경에 적응하고 주문과 거래를 함께 가져올 수 있습니다.

3.10. 주문 가리기 메커니즘

HedgeTerminal 설치를 설명하는 섹션에서 주문을 숨기는 메커니즘에 대해 언급했습니다. HedgeTerminal은 일부 주문을 무시할 수 있습니다. HedgeTerminal에 대해 존재하지 않는 주문 또는 거래의 경우 지정된 파일 ExcludeOrders.xml에 해당 식별자를 입력하면 충분합니다.

하나의 기호에 대해 여러 개의 판매 또는 구매 주문을 실행했다고 가정해 보겠습니다. 총 매도 주문량은 총 매수 주문량과 같습니다. 이렇게 하면 우리가 얼마나 많은 주문을 가지고 있더라도 그들의 총 포지션은 0과 같습니다. 이러한 주문의 식별자가 ExcludeOrders.xml 파일에 없는 경우 HedgeTerminal은 각 주문을 양방향 포지션으로 표시합니다. 주문들의 총 포지션은 0이 될 것입니다. 따라서 MetaTrader 5의 순 포지션이 0이면 순 포지션에 설정된 이 주문의 기여는 단순히 무시할 수 있습니다.

이제 t 순간에 S 기호에 0 순포지션이 있고 주문 세트 <가 있다고 가정해 보겠습니다. N 이 시간까지 이 기호에서 실행됩니다. 이 기호에는 포지션이 없기 때문에 N 주문 세트의 총량은 미미합니다. 실제로 포지션이 없기 때문에 이러한 주문은 총 순포지션에 기여하지 않으므로 주문 수와 볼륨은 관련이 없습니다. 즉, 이러한 주문은 단순히 무시할 수 있으며 양방향 포지션으로 나타낼 필요가 없습니다.

이것은 HedgeTerminal이 설치 순간에 사용하는 바로 그 메커니즘입니다. 설치 시점 t 순 포지션이 없는 경우 HedgeTerminal은 주문 N 세트를 포함합니다. 예외 목록. 순 포지션이 없기 때문에 그들의 총량과 수는 관련이 없습니다. HedgeTerminal 설치 순간에 순 포지션이 있으면 순 포지션이 청산될 때까지 단순히 설치되지 않습니다. 설치 후 새 주문은 순 포지션의 상태를 변경합니다. 이 상태는 HedgeTerminal에서 양방향 포지션의 순 볼륨과 동기화됩니다.

겉보기에, 우리는 예외 목록에 HedgeTerminal이 실행될 때까지 실행된 주문을 넣지 않고 빠져나갈 수 있었습니다. 동시에 설치 시점까지 많은 주문이 있을 수 있으며 HedgeTerminal의 관점에서 모든 주문이 양방향 포지션이 되며 총 볼륨 캡이 MetaTrader 5의 순 볼륨과 다릅니다. .

은폐 명령의 메커니즘은 계정 이력의 손상에 효과적일 수 있습니다. 이것이 작동하는 방식입니다. 주문 내역이 있다고 가정해 보겠습니다. 이 계정에서 HedgeTerminal이 시작되면 모든 주문을 반복하고 이를 기반으로 양방향 포지션을 구축합니다. 개설 시점부터 모든 주문을 사용할 수 있고 이러한 주문에 대한 데이터가 손상되지 않은 경우 이러한 주문의 순 포지션은 MetaTrader 5의 순 포지션과 일치합니다. 분명히 HedgeTerminal의 순 포지션은 이러한 주문의 합계와 같습니다. 이것은 아래 다이어그램에 설명되어 있습니다.

45번 그림. 완전 이력 다이어그램

이력의 일부가 누락되거나 주문에 대한 정보가 올바르지 않을 수 있습니다.

하나의 주문만 누락되었거나 여러 주문이 누락된 경우 중요하지 않으며 계정 내역의 시작 또는 중간에 정보가 누락된 경우 관련이 없습니다. 이러한 계정에서 실행되는 HedgeTerminal의 순 포지션은 사용 가능한 모든 주문의 순 포지션과 같습니다. 주문의 순 포지션은 이력의 누락된 부분 때문에 터미널의 실제 순 포지션과 동일하지 않습니다. 이 상황은 B 다이어그램에 나와 있습니다.

46번 그림. 일부 오염된 이력

HedgeTerminal의 순 포지션을 MetaTrader 5의 실제 순 포지션과 동기화하기 위해 어떤 주문이 사라지거나 손상되었는지 굳이 알 필요는 없습니다. 이러한 순 포지션 간의 차이를 계산하기만 하면 됩니다. 위의 예에서 MetaTrader 5 단말기에 5계약의 매수 포지션이 열려 있습니다. HedgeTerminal에서 이는 8 계약에 대한 총 매수 포지션에 해당합니다. 8 BUY – 5 BUY = 3 BUY이기 때문에 이 두 포지션의 차이는 3계약이 됩니다.

계약 차액이 계산된 후에는 차액과 동일한 거래량으로 해당 매수 또는 매도 주문을 해야 합니다. 이 예에서는 3개의 계약을 구매하는 주문을 해야 합니다. 주문이 실행되면 HedgeTerminal은 활성 포지션 탭에 이를 표시하고 총 순포지션은 3계약 증가하고 11계약 구매와 동일하게 됩니다.

MetaTrader 5의 포지션도 증가하여 8개의 계약을 체결하게 됩니다. ExcludeOrders.xml 목록에 이 주문의 식별자를 입력한 다음 터미널을 다시 시작해야 합니다. 따라서 주문 식별자가 101162513이면 다음 태그가 파일에 작성되어야 합니다.

<Orders-Exclude>
        ...
        <Order AccountID="10052699" ID="101162513"></Order>
</Orders-Exclude>

-->

HedgeTerminal을 다시 시작하면 이 양방향 포지션이 사라집니다. 이런 식으로 MetaTrader 5의 순 포지션은 HedgeTerminal의 순 포지션과 일치하고 구매 계약을 5번 만듭니다. 설명된 작업 순서는 아래 다이어그램에 나와 있습니다.

47번 그림. 데이터 엄밀성 복구 다이어그램

사라진 포지션의 재무 결과는 HedgeTerminal 통계에 기록되지 않습니다. 불행히도 숨겨진 양방향 포지션은 거래 통계에 포함되지 않습니다.

실제로 역사의 일부를 사용할 수 없거나 손상된 상황은 거의 없습니다. 대부분의 MetaTrader 5 사용자가 사용해야 하는 상황을 겪지 않을지라도 그러한 메커니즘은 제자리에 있어야 합니다. 결국 HedgeTerminal의 프로그램 오류 가능성도 배제되지 않습니다. 이 경우에도 이러한 오류를 해결할 수 있는 신뢰할 수 있는 도구가 있어야 합니다.

3.11. 적응 메카니즘

우리는 HedgeTerminal이 MetaTrader 5의 네트 환경에서 양방향 포지션을 나타낼 수 있도록 하는 메커니즘을 고려했습니다. 이러한 메커니즘 중 세 가지가 있습니다.

1. 딜 순차 반복
2. 거래를 나누고 모으는 메커니즘;
3. 주문 가리기 메커니즘.

이러한 메커니즘 각각은 문제를 해결하고 레벨에서 모호성과 오류를 방지할 수 있습니다. 이러한 문제와 해결 방법을 테이블로 가져오도록 합시다. 첫 번째 열에는 바인딩의 문제와 가능한 오류가 포함되어 있고 두 번째 열에는 이를 해결하는 메커니즘이 포함되어 있습니다.

양방향 거래 조직 및 두 번째 열에서 발생하는 문제, 오류, 모호성을 해결하는 메커니즘.	에러 수정 메커니즘
개시 주문에 대한 링크의 오류; 링크 충돌; Expert의 긴 마법 숫자; 기록에서 주문 삭제 거래 작업 실행 오류.	주문에 대한 순차 반복. 행동의 결정론.
볼륨 오류; 다른 볼륨의 주문 일치 부분 주문 실행; 기록에서 거래 삭제 더 작은 볼륨을 더 큰 볼륨으로 덮습니다.	거래를 분할하고 일치시키는 메커니즘.
실행된 주문이 많은 계정에 HedgeTerminal을 설치합니다. 손상된 역사; 주문 작업에서 HedgeTerminal의 버그.	주문 가리기 메커니즘.

18번 테이블. 가능한 오류 및 제거 메커니즘

링크 저장 시스템과 함께 세 가지 메커니즘 모두 안정적인 데이터 표현을 보장합니다. 기본적으로 이러한 메커니즘은 예상치 못한 실패의 모든 가능한 경우를 다루고 HedgeTerminal의 순 포지션과 MetaTrader 5의 순 포지션의 일치를 보장합니다.

3.12. 퍼포먼스와 메모리 사용

HedgeTerminal은 엄밀하게는 객체 지향 어플리케이션입니다. 아키텍처의 기반이 되는 OOP 원칙으로 인해 터미널은 스토리지에 대한 효율성이 높고 요구 사항이 낮습니다. 리소스를 소모하는 유일한 작업은 차트에서 터미널을 실행하는 순간 컴퓨터 메모리에서 주문 및 거래 내역을 추출하는 것입니다.

필요한 모든 트랜잭션이 메모리에서 추출된 후 터미널은 이 작업에 소요된 시간과 메모리 사용량을 알려주는 메시지를 인쇄합니다. Intel i7 프로세서가 탑재된 컴퓨터에서 20,000개 이상의 거래가 포함된 계정에서 HedgeTerminal 패널을 실행하는 데 30초도 걸리지 않았으며 118Mb의 RAM이 필요했습니다.

2014.11.20 16:26:19.785 hedgeterminalultimate (EURUSD,H1)       We begin. Parsing of history deals (22156) and orders (22237) completed for 28.080 sec. 118MB RAM used.

-->

HedgeTerminalAPI 라이브러리는 트랜잭션의 그래픽 표현이 필요하지 않기 때문에 훨씬 더 빠르게 작동하고 훨씬 적은 메모리를 사용합니다. 다음은 동일한 계정에서 실행한 결과입니다.

2014.11.20 16:21:46.183 TestHedgeTerminalAPI (EURUSD,H1)        We are begin. Parsing of history deals (22156) and orders (22237) completed for 22.792 sec. 44MB RAM used.

-->

간단한 계산은 프로그램 유형에 따라 한 포지션을 추출하는 데 1에서 1.26밀리초가 걸린다는 것을 보여줍니다. 하나의 트랜잭션을 저장하려면 (22,156개의 거래 + 22,237개의 주문) / 44Mb = 1Kb의 RAM이 필요합니다. 하나의 트랜잭션에 대한 추가 그래픽 표현을 저장하는 데는 대략 (118Mb – 44Mb) * 1024 / (22,156개의 거래 + 22237개의 주문) = 1.71Kb의 메모리가 필요합니다.

코드 프로파일링은 대부분의 시간이 주문 분석 블록 하나에 사용된다는 것을 보여줍니다. 후자의 주요 부분은 시스템 함수 호출입니다. 향후 버전에서는 이 블록이 최적화되어 출시 시 효율성을 10-15% 높일 수 있습니다.

마치며

지금까지 시각 패널 HedgeTerminal으로 작업할 때 중요한 점에 대하여 다뤄보았습니다. 이는 유연한 설정의 가능성을 담은 새로운 패널 클래스를 만드는 예시를 통하여 이루어졌습니다.

그 계획 및 사양은 양방향 트레이딩의 조직 원칙에 대하여 핵심적인 아이디어를 제공했습니다. 만약 당신만의 가상화 라이브러리를 미래에 만들 예정이라면, 이 문서의 두 번째 챕터를 참조하시면 라이브러리 설계에 도움이 될 것입니다.

교환 체결의 특징으로 인해 거래 과정의 핵심과 주문을 양방향 포지션으로 나타내는 점에 대한 이해를 필요로 합니다. 이 문서에서 거래 및 주문의 가상화 없이는 그러한 표현이 불가능하다는 것을 보여드렸습니다. 가상화는 실행된 거래의 양을 "중단"하고 실제 주문을 복제하여 하나의 주문이 여러 트랜잭션의 일부가 될 수 있도록 하는 메커니즘입니다.

거래 환경을 이용한 이러한 조작은 다소 과감합니다만, 가상화에 필요한 정보의 대부분은 거래 서버에 저장되므로 그러한 표현도 신뢰할 수 있다고 할 수 있습니다.