무역 및 청산 시스템

한 걸음 더 나아.
timothyloh에 액세스하려면 보안 검사를 완료하십시오.
왜 CAPTCHA를 완료해야합니까?
보안 문자를 작성하면 귀하가 사람임을 증명하고 웹 사이트에 일시적으로 액세스 할 수 있습니다.
앞으로이를 방지하기 위해 무엇을 할 수 있습니까?
집과 같이 개인적인 연결을 사용하는 경우 장치에서 안티 바이러스 검사를 실행하여 맬웨어에 감염되지 않았는지 확인할 수 있습니다.
사무실 또는 공유 네트워크에있는 경우 네트워크 관리자에게 네트워크를 통해 잘못 구성된 장치 또는 감염된 장치를 검색하도록 요청할 수 있습니다.
Cloudflare Ray ID : 3cf1790cae9559c6 & 황소; 귀하의 IP 주소 : 78.109.24.111 & bull; 실적 & amp; Cloudflare의 보안.

무역 및 시장.
Office 정보 & raquo;
거래 및 시장 부서는 공정하고 질서 정연하며 효율적인 시장을위한 표준을 수립하고 유지 관리합니다. 본 부는 중개인 - 딜러, 자기 규제 기관 (증권 거래소, FINRA 및 청산 기관 등) 및 이전 에이전트와 같은 주요 증권 시장 참가자를 규제합니다.
최신 보도 자료.
빠른 링크.
최근 보고서 및 간행물.
부문 정보 및 리소스.
1934 년 증권 거래법 ( "증권 거래법"또는 "법")은 증권 시장과 브로커 및 딜러가 운영되는 방식을 통제합니다. 이 절은 법 및 그 규칙의 중요한 조항 중 일부를 포함합니다. 브로커 - 딜러가 등록해야하는지 여부 및 등록 방법에 대한 정보는 물론 브로커 - 딜러가 준수해야하는 재무 표준 및 행동 규범을 확인할 수 있습니다.
"국가 증권 거래소"는 1934 년 증권 거래법 제 6 조에 따라 SEC에 등록 된 증권 거래소입니다. SEC에 등록 된 거래에 대한 정보, 규칙 적용 및 기타 지침은 여기에서 찾을 수 있습니다.
이체 에이전트는 소유권의 변경 사항을 기록하고 발급자의 보안 소유자 레코드를 유지하며 취소 및 발급하고 배당을 배포합니다. 전송 에이전트는 발행 회사와 보안 소유자 사이에 서 있기 때문에 효율적인 전송 에이전트 작업은 보조 거래를 성공적으로 완료하는 데 중요합니다. SEC 규정 및 규정은 증권 거래의 신속하고 정확한 통관 및 결제를 용이하게하고 유가 증권 및 자금의 안전을 보장하기위한 것입니다. 이전 에이전트 등록, 검사 및 규칙에 대한 정보는 여기에서 찾을 수 있습니다.
도드 - 프랭크 법 (Dodd-Frank Act)은 장외 시장 스왑 시장을 규제하기위한 포괄적 인 틀을 마련했습니다. 이 법의 Title VII는 SEC와 Commodity Futures Trading Commission (CFTC) 사이의 스왑에 대한 규제 권한을 분담합니다. (CFTC 링크) 법에 따라 SEC는 (1) 단일 보안 또는 (2) 융자 또는 (3) 좁은 그룹에 기반한 스왑으로 정의되는 "보안 기반 스왑"에 대한 권한을가집니다 또는 (4) 단일 발행자 또는 좁은 기반 보안 지수의 유가 증권 발행인과 관련된 사건. 등록, 규칙 및 보안 기반 스왑 엔티티에 대한 정보는 여기에서 찾을 수 있습니다.

거래 및 결제 시스템
본 출원은 2000 년 2 월 29 일자로 출원 된 임시 출원 60 / 186,082의 이익을 주장한다.
발명의 분야
본 발명은 하나 이상의 증권 거래 시스템을 청산 시스템에 연결시키는 연결 시스템에 관한 것이다. 보다 구체적으로 말하면, 연결은 정보 구동이 가능 해짐에 따라 정보가 네트워크를 따라 신속하게 전달되는 이벤트 중심적입니다.
발명의 배경.
범위와 거래 역학의 증권은 엄청난 폭이 있습니다. 범위 내에서 증권은 자연스럽게 기존 주식 및 채권을 포함하지만 사실상 모든 금융 상품의 훨씬 더 광범위한 개념을 가지고 있습니다. 예를 들어 유가 증권에는 농산물과 같은 유형 상품에 대한 선물이 포함됩니다. 그러나 미래는 오늘 금리에서 주식, 주식 지수, 외화 및 공해권에 이르기까지 다양한 유형의 무형 자산을 다루게 될 것입니다. 증권에는 선물 이외의 소위 "파생 상품"도 포함될 수 있습니다. 모든 종류의 옵션. 우리는 금융 상품을 근본적인 안보, 상품, 재화 또는 서비스와 상관없이 거래소에서 돈으로 구입하거나 판매 할 수있는 수단으로 정의합니다. 교환은 시장이 그러한 도구를 위해 만들어진 곳이라면 무엇이든 할 수 있습니다.
거래의 메카니즘 또한 엄청나게 복잡합니다. 거래는 일반적으로 "장외 시장"( "장외 시장") 시장으로 알려진 네트워크를 통해 "열거 된 경우"또는 "미등록"인 경우 공식 교환으로 이루어질 수 있습니다. 공식 교환의 경우와 일부 네트워크의 경우 거래 메커니즘에서 중요한 역할은 "정보 센터"또는이 공개에서 동의 시스템 인 "클리어링 시스템"에 의해 수행됩니다. 교환 및 보안 유형에 따라 정확한 역할 클리어링 시스템의
대부분의 주식은 영업일 기준 3 일 이내에 증서를 수령해야하는 "일반적인 방법"으로 판매됩니다. 모든 보안 거래가 판매자로부터 구매자에게 주식 인증서를 물리적으로 이전해야만하는 경우 매우 비효율적입니다. 중개 회사는 한 고객 (X 씨)에 대해 뉴욕 증권 거래소 (New York Stock Exchange) 100 주를 판매 할 수 있으며 나중에는 다른 고객 인 Y 씨 (Y 씨)에게 100 주를 매입 할 수 있습니다. Mr. X의 100 주를 구매자에게 전달할 수 있으며 Y 주식은 판매자로부터의 인도를 수락함으로써 얻을 수 있습니다. 그러나 X 씨의 주식을 Y 씨에게 양도하고 Y 씨 판매자에게 X 씨의 구매자에게 직접 100 주를 전달하도록 지시하는 것이 훨씬 쉬울 것입니다. 이 경로는 중개 회사의 고객 인 X 씨와 Y 씨가 증권을 거리 이름으로 사용하는 경우 특히 유용합니다. 그렇다면 100 개의 주식은 이동 될 필요가 없으며 소유권을 IBM의 책에서 변경할 필요가 없습니다.
이 프로세스는 중개 회사, 은행 및 기타 금융 기관의 회원 인 청산 시스템을 통해 더욱 원활해질 수 있습니다. 하루 동안 회원들이 한 거래 기록은 곧 그곳으로 보내집니다. 하루가 끝나면 거래의 양측이 일관성을 유지하는지 확인한 다음 모든 거래를 철회합니다. 각 회원은 수령 또는 수령 할 순 금액과 함께 수령 할 순 유가 증권 목록을받습니다. 매일 각 회원은 다른 여러 회사가 아닌 정보 센터에 정착합니다.
브로커는 거리 이름으로 유가 증권을 보유하고 청산 시스템을 사용함으로써 이동 작업 비용을 줄일 수 있습니다. 그러나 더 많은 작업을 수행 할 수 있습니다. 인증서가 거의 완전히 고정 될 수 있습니다. 예금 신탁 회사 (DTC)는 회원사 (브로커, 은행 등)가 소유 한 유가 증권의 전산화 된 기록을 유지함으로써 인증서를 고정합니다. 회원의 주식 증서는 DTC에서 자신의 계좌로 입금되며, 인증서는 발급 회사의 장부에있는 DTC로 이전되며, 이후에 회원이 인출하지 않는 한 그 이름으로 등록됩니다. 가능할 때마다 한 회원은 간단한 계좌 개설을 시작하여 하나의 계좌에 대변을 기입하고 다른 계좌는 관련된 주식에 대해 차변에 기입하여 유가 증권을 다른 사람에게 "전달"합니다.
선물 계약 거래는 보통 주식 거래보다 복잡합니다. 투자자가 주식 매입을 원할 경우, 그의 중개인은 단순히 투자자가 증권 거래소를 통해 다른 개인과 주식을 매매 할 수있는 중개자 역할을합니다. 그러나 선물 거래에서 정보 센터는보다 적극적인 역할을합니다.
투자자가 선물 포지션을 수립하기 위해 중개인과 접촉하면 중개 회사는 선물 거래소 바닥에있는 회사의 상인에게 주문을 연결합니다. 각 증권의 전문가 또는 마켓 메이커와 관련된 주식 거래와는 달리, 미국의 대부분의 선물 거래는 각 계약의 "트레이딩 피트"에서 플로어 트레이더들 사이에서 발생합니다. 거래의 반대쪽을 기꺼이 받아들이는 상인이 위치해 있으면 거래가 기록되고 투자자에게 통보됩니다.
이 시점에서 반제 시스템이 사진을 입력합니다. 장기 및 단기 거래자들이 서로 계약을 체결하는 대신, 정보 센터는 긴 포지션의 계약자와 짧은 포지션의 계약자가됩니다. 클리어링 시스템은 상품을 긴 위치로 전달하고 단시간에 배달을 지불해야합니다. 그 결과 정보 센터의 위치는 0이됩니다. 이렇게하면 청산 시스템이 길거나 짧은 각 상인의 거래 파트너가됩니다. 각 계약의 측면에서 수행 할 수있는 정보 센터는 모든 상인이 선물 계약의 의무를 지키지 않아 상처를 입을 수있는 유일한 당사자입니다. 선물 계약이 즉각적인 주식 거래처럼 쉽게 보장 될 수없는 미래의 성과를 요구하기 때문에 이러한 배치가 필요합니다.
또한, 1과 2는 선물 거래에서 청산 시스템의 역할을 설명합니다. 무화과. 1은 정보 센터가 없을 때 어떤 일이 일어날지를 보여줍니다. 긴 포지션 101의 트레이더는 선물 포지션 105를 단기 포지션 111에 지불 할 의무가 있으며, 포지션 111의 트레이더는 증권 또는 증권 또는 상품 115를 인도 할 의무가 있습니다. 무화과. 도 2는 청산 시스템 (121)이 중개자가되어 계약의 각면에 대한 거래 파트너로서 어떻게 작용 하는지를 도시한다. 클리어링 하우스의 위치는 중립입니다. 각 거래마다 길게 125와 짧은 포지션 131이 필요합니다.
클리어링 시스템을 통해 거래자는 쉽게 포지션을 청산 할 수 있습니다. 투자자가 현재 계약 기간이 길고 자신의 지위를 취소하고자하는 경우 투자자는 중개인에게 계약의 짧은 쪽을 입력하여 자신의 지위를 마감하도록 지시합니다. 이것을 역전 거래라고합니다. 거래소는 투자자의 장단점을 뽑아 넷 포지션을 0으로 줄입니다. 정보 센터와의 제로 넷 포지셔닝은 원래의 길거나 짧은 위치에서 성숙 될 필요성을 제거합니다.
계약에 대한 미결제는 미결 된 계약 건수입니다. (장기 및 단기 포지션은 별도로 계산되지 않으므로 미결제가 장기 계약 또는 단기 계약의 수 중 하나로 정의 될 수 있음을 의미합니다.) 청산 시스템의 위치는 0으로 결정되므로 미결 고객 계산에 포함되지 않습니다. 계약이 거래를 시작할 때 미결제는 0입니다. 시간이지나면서 점진적으로 더 많은 계약이 체결되면 미결제가 증가합니다. 그러나 거의 모든 상인은 계약 만기일 이전에 직위를 청산합니다.
상품을 실제로 가져 가거나 납품하는 대신, 시장 참여자는 사실상 위에서 언급 한 역 거래에 들어가 원래 위치를 취소함으로써 계약상의 이익 또는 손실을 실현합니다. 실제 배달을하게되는 계약 분율은 상품 및 계약 활동에 따라 1 % 미만에서 3 % 사이로 추정됩니다.
예를 들어, 11 월에 열린 미결제의 전형적인 패턴에서, 12 월 인도 계약은 만기와 가깝고 미결제는 상대적으로 작다. 대부분의 계약은 이미 취소되었습니다. 다음 몇 개의 만기는 중요한 관심사입니다. 마지막으로, 가장 먼 성숙한 계약은 거의 공개되지 않았기 때문에 최근에는 이용이 가능하고 거래 된 참가자는 거의 없습니다. 1 월 또는 2 월이 가장 가까운 만기일 인 다른 계약의 경우 미결제는 가장 가까운 계약에서 가장 높습니다.
실제로, 거래자는 단순히 기본 상품의 선물 가격에 베팅합니다. 시간 0에서 계약을 체결하고 시간 t에서이를 닫거나 되돌리는 긴 상인에 의해 실현 된 총 이익 또는 손실은 F t - F 0 기간 동안의 선물 가격의 변화 일뿐입니다. 대칭 적으로, 짧은 상인은 F 0 - F t를 벌어 들인다.
이익이나 손실이 거래자에게 발생하는 과정을 마킹이라고합니다. 거래의 초기 실행시, 각 상인은 "초기"또는 "성과"마진을 포함하는 마진 계좌를 개설합니다. 증거금은 상인이 선물 계약의 의무를 이행 할 수 있는지 확인하는 재무부 청구서와 같이 현금 또는 가까운 현금 증권으로 구성된 보안 계좌입니다. 선물 계약의 양 당사자 모두 손실에 노출되어 있기 때문에 둘 다 마진을 제시해야합니다. 일례로 옥수수 계약은 1138.75 달러 (부셸 당 2.2775 달러 × 계약 당 5,000 부셸)이다. 예를 들어, 옥수수의 초기 마진이 10 % 인 경우 상인은 마진 계좌에 대해 계약 당 $ 1,138.75를 게시해야합니다. 이자 수익 증권을 게시하는 것이 초기 마진을 만족시킬 수 있기 때문에 요구 사항은 상인에게 상당한 기회 비용을 부과하지 않습니다. 초기 마진은 일반적으로 계약 총액의 5 %에서 15 % 사이로 설정됩니다. 가격 변동이 심한 자산에 대한 계약서는 더 높은 이윤을 요구합니다.
선물 계약 거래가 이루어지는 날에는 선물 가격이 오르거나 떨어질 수 있습니다. 거래소가 모든 이익과 손실을 실현할 때까지 기다리는 대신, 정보 센터는 모든 직위가 매일 발생하는 이익을 인식하도록 요구합니다. 옥수수의 선물 가격이 오르면 청산 시스템은 상승 액에 대한 장기 포지션의 증거금 계좌에 크레딧을 적용합니다. 반대로, 짧은 포지션의 경우 정보 센터는 보류 된 각 계약의 증거금 계좌에서이 금액을받습니다. 이 매일의 정착을 마킹이라고합니다. 계약의 만기일이 손익 실현을 규율하지 않는다는 것을 의미합니다. 시장에 마킹하면 선물 가격이 변함에 따라 수익금이 즉시 상인의 증거금 계좌로 적립됩니다.
상인이 일일 마킹을 통해 시장에 지속적으로 손실을 입히면 마진 계좌가 유지 보수 또는 변동 마진이라고하는 임계 값 아래로 떨어질 수 있습니다. 계정 값이이 값 아래로 떨어지면 상인은 마진 콜을받습니다. 예를 들어, 옥수수의 유지 보수 마진이 5 %라면 마진 콜은 초기에 게시 된 10 % 마진이 약 절반으로 하락하여 계약 당 569 달러가 될 것입니다. 새로운 자금이 증거금 계좌로 이체되어야합니다. 그렇지 않으면 중개인은 해당 지위에 필요한 마진을 충족시키기에 충분한 상인의 지위를 마감합니다. 이 절차는 클리어링 시스템의 위치를 ​​보호합니다. 여백 계정이 소진되기 전에 위치가 닫힙니다. 상인의 손실은 보상되며, 정보 센터는 영향을받지 않습니다.
납기일의 선물 가격은 해당 날짜의 상품 현물 가격과 같습니다. 성숙 계약에서 즉각적인 인도를 요구하면 당일의 선물 가격은 현물 가격과 동일합니다. 두 경쟁 소스의 상품 가격은 경쟁 시장에서 동일하게 유지됩니다. 투자자는 직접 구매, 현물 시장 또는 선물 계약의 긴면을 입력하여 상품의 인도를받을 수 있습니다. 이를 수렴 속성이라고합니다.
시간 0의 계약에서 장기 계약을 맺고 만기까지 그 포지션을 유지하는 투자자 (시간 T)의 경우 모든 일일 결제 금액의 합계는 F T - F 0입니다. 여기서 F T는 계약 만기일의 선물 가격입니다. 그러나 융합으로 인해 만기의 선물 가격 F T는 현물 가격 P T와 동일하므로 총 선물 이익도 P T - F 0으로 나타낼 수 있습니다. 따라서 만기까지 보유한 선물 계약의 이익은 기본 자산의 가치 변동을 추적합니다.
대부분의 선물 시장은 계약이 만기 전에 취소되지 않은 경우 특정 밀 등급 또는 외화 금액을 명시한 실제 상품 인도를 요구합니다. 배달 된 상품의 품질이 다를 수있는 농산물의 경우, 청산 시스템 또는 교환 시스템은 선물 계약의 일부로 품질 표준을 설정합니다. 어떤 경우에는 계약이 고등 또는 저급 상품으로 결제 될 수 있습니다. 이러한 경우 품질 차이를 조정하기 위해 배달 된 상품에 프리미엄 또는 할인이 적용됩니다.
일부 선물 계약은 현금을 요구합니다. 예를 들어 주식 인덱스 선물 계약이 있습니다. 여기에서 기본 자산은 Standard & amp; Poor 's 500 또는 뉴욕 증권 거래소 지수. 색인에있는 모든 주식의 배달은 분명히 비실용적입니다. 따라서 계약은 만기일에 인덱스가 달성 한 금액과 동일한 금액의 "인도"를 요구합니다. 마킹에서 시장으로의 모든 일일 정산의 합계는 만기일 T의 주가 지수의 가치 인 ST-F 0의 총 이익 또는 손실을 실현하는 긴 포지션에서 결과를 낳습니다. F 0은 원래 선물 가격입니다 . 현금 결제는 자산의 현금 가치가 선물 가격과 교환하여 짧은 위치에 의해 제공되는 것이 아니라 자산의 현금 가치를 제외하고 실제 인도를 모방합니다.
선물 마진은 주식 마진과 다릅니다. 앞서 논의 된 주식에 대한 증거금 요건은 본질적으로 소유 할 증권에 대한 계약금입니다. 증거금을 거래하는 투자자는 철저한 소유주의 모든 권리와 특권을 갖습니다. 선물 계약의 경우에는 그렇지 않습니다. 주식을 구입할 때, 새로운 소유주는 의결권을 통제하고, 선물 계약의 경우에는 가격 위험 만 이양됩니다. 또한 시장 진출을 위해 선물 계약에 대한 엄청난 담보가 필요하지 않습니다. 선물 마진은 양 당사자가 의무를 다할 수 있도록하는 성과 채권입니다.
정보 센터는 선물 거래에서 중요한 역할을합니다. 청산 시스템은 선물 계약의 양측을 보장합니다. 정보 센터는 불이행 위험을 제거 할뿐만 아니라 배달되는 제품의 품질을 보장합니다. 대부분의 상품 선물 계약에는 특정 품질 수준이 있으며, 청산 시스템은 적절한 품질의 상품이 인도되도록합니다.
정보 센터는 또한 승자와 패자 간의 일일 현금 흐름 교환을 용이하게합니다. 선물 계약의 매수인과 매도자가 적절한 담보를 제공하는지 확인합니다. 보았 듯이 청산 시스템은 브로커가 구매자와 판매자 모두에게 초기 증거금 요구를 부과하고 구매자와 판매자의 계정을 매일 시장화하며 구매자와 판매자 모두에게 일일 유지 마진 요건을 부과해야합니다.
따라서 거래소는 선물 거래에서 적어도 네 가지 중요한 역할을 수행합니다.
1. 은행. 청산 시스템은 이익과 손실의 교환을 제공합니다.
2. 경위. 정보 센터는 좋은 제품 인도를 보장합니다.
3. 보험자. 청산 시스템은 각 상인이 계약을 존중할 것을 보장합니다.
4. 유동성 유지자. 청산 시스템은 "거래 역전"을 용이하게합니다.
옵션 거래는 거래소, 카운터 및 구매자와 판매자간에 직접 발생합니다. 옵션이 거래되는 많은 다양한 교류가 있습니다. 가장 활발한 옵션 거래소는 시카고 보드 옵션 거래소 (CBOE), 미국 증권 거래소 (AMEX), 시카고 무역위원회 (CBOT), 필라델피아 증권 거래소 (PHLX), 시카고 상품 거래소 (CME) 및 태평양 증권 거래소 (PSE).
옵션 거래는 주식 거래와 유사합니다. 예를 들어, Q 씨가 Compaq에서 통화 옵션을 구매하기로 결정하면 그는 브로커에게 전화를 걸어 자신의 소망을 진술합니다. 브로커는이 주문을 적절한 옵션 교환기에 알리며, 이 거래는 Compaq에서 콜 옵션을 판매하고자하는 투자자 또는 마켓 메이커와 거래가 이루어지는 곳에서 이루어집니다.
옵션 클리어링 코퍼레이션 ( "OCC")은 옵션 거래 기록을 유지하며 주요 정보 센터 중 하나입니다. OCC는 여러 거래소 (CBOE, AMEX, NYSE, PHLX 등)가 소유하고 지원합니다. 따라서 OCC는 매우 신용있는 회사입니다. 선물 거래소 (clearinghouses)와 마찬가지로 OCC는 모든 옵션 계약을 발행하고 계약의 양측을 보장합니다. 따라서 옵션 구매자는 옵션 작성자의 신용 위험을 평가할 필요가 없습니다. 또한 모든 옵션 계약에는 재판매를보다 쉽게 ​​해주는 표준화 된 기능이있어 옵션 계약의 유동성을 향상시킵니다. OCC는 옵션 거래와 관련된 모든 거래를 처리하고 옵션 작가 (즉, 판매자)에 증거금 요구 사항을 부과합니다.
OCC는 구매자와 작가가 언제든지 자신의 직책을 종료 할 수있게합니다. 구매자가 나중에 동일한 계약서 작성자가되면 구매자가 계약서를 다른 사람에게 "판매"한다는 의미이므로 OCC 컴퓨터는이 투자자 계정에 상쇄되는 위치를 기록하고 두 항목을 모두 취소합니다. 월요일에 계약을 맺은 다음 화요일에 판매하는 투자자를 생각해보십시오. 컴퓨터는 투자자의 순 위치가 0이며 두 항목을 모두 제거합니다. 두 번째 거래는 초기 거래에서 투자자의 지위를 마감하는 역할을하기 때문에 종가 매매입니다. 따라서 판매를 중단하면 구매자는 옵션을 판매하지 않고 판매 할 수 있습니다. 이 프로세스는 선물 거래에서 "역방향 거래"와 동일한 목적으로 사용되며 시장 유동성을 촉진합니다.
옵션 권리 보유자가 옵션을 행사할 때, OCC는 옵션 의무를 잘 수행 할 수있는 옵션을 작성한 고객이있는 회원사를 준비합니다. 회원사는 계약 이행을 위해 해당 옵션을 작성한 고객을 선택합니다. 선택한 고객은 작성된 각 콜 옵션 계약의 행사 가격과 동일한 가격으로 주식 100 주를 제공하거나 작성된 각 풋 옵션 계약의 행사 가격으로 100 주를 구매해야합니다.
분명히, 증권 거래는 다수의 청산 시스템에 의해 효율적인 후속 조치에 방해가됩니다. 서로 다른 정보 센터의 많은 기능의 공통점은 수많은 청산 시스템을 결합하여 다양한 교환이나 심지어 다른 유형의 교환 (예 : 선물 및 옵션 교환 거래)을 지원할 수 있음을 나타냅니다. 따라서, 기능의 중복과 관련된 비 효율성이 존재한다.
또한 여러 개의 클리어링 하우스가 존재한다는 것은 단일 고객의 담보 또는 여백을 많은 클리어링 시스템에서 사용할 수 있어야한다는 것을 의미합니다. 이 마진 중복은 고객 마진의 합계 금액이 여러 클리어링 하우스가 부담하는 총 위험 금액을 초과하는 경우에도 발생합니다.
또한 교환기와 청산 시스템 간의 통신 기술은 배치 방식으로 구성되는 경우가 많습니다. 거래에 대한 정보는 일일 1 회 또는 선택한 요일 (예 : 시간 또는 분) 후에 전달됩니다. 이러한 의사 소통의 지연은 많은 비효율을 초래할 수 있습니다. 예를 들어 정보 센터에보고되지 않은 거래가 고객의 지위의 위험을 감소시키는 경우 청산 시스템은 과도하게 담보로 제공되며 정보는 고객에게 전달 될 때까지 다른 거래를 지원할 수있는 담보가 제공되지 않을 수 있습니다. 정보 센터. 반대로, 거래가 고객의 지위의 위험을 증가 시키면, 청산 시스템은 일정 기간 보증되지 않을 것입니다. 의사 소통이 지연되면 실제 비용으로 위험이 증가 할 수 있습니다. 위험의 예로는 거래의 한쪽에있는 누군가가 판매 된 대금을 지불하거나 전달할 수 없기 때문에 발생하는 배달 또는 위험이 있습니다.
따라서 여러 금융 거래를 연결하고 다양한 증권을 거래하는 시스템이 단일 청산 시스템에 연결되는 시스템이 필요합니다. 또한 청산 시스템에 대한 거래 정보의 즉각적인 전달이 필요합니다.
발명의 요약.
상기를 고려하여, 본 발명은 금융 상품을 거래하는 시스템을 금융 상품의 거래를 청산하는 시스템에 링크시키는 시스템 및 방법을 제공한다.
본 발명의 제 1 양상에서, 연결 시스템은 적어도 하나의 거래 시스템과 청산 시스템을 연결하는 네트워크를 포함한다. 외부 인터페이스는 거래 시스템을 네트워크에 연결하는 한편 반제 인터페이스는 반제 시스템을 네트워크에 연결합니다. 송신기 모듈은 네트워크를 따라 적어도 하나의 종류의 금융 상품의 거래 정보를 거래 시스템으로부터 청산 시스템으로 전송한다. 그 전송은 선택적으로 외부 인터페이스에서 거래 정보의 도착과 동시에 발생합니다. 다른 실시 예에서, 둘 이상의 거래에 관한 정보는 번들링 된 후 청산 시스템으로 전송 될 수있다.
본 발명의 일 실시 예에서, 연결 시스템의 적어도 하나의 거래 시스템은 복수의 거래 시스템이다. 다른 실시 예에서, 연결 시스템에 의해 관리되는 적어도 하나의 종류의 금융 상품은 복수 종류의 금융 상품이다. 본 발명의 다른 실시 예에서, 링크 시스템에 포함 된 송신기 모듈에 의한 거래 정보의 송신은 거래 알고리즘 또는 소거 알고리즘의 선택과는 독립적으로 발생한다.
본 발명의 제 2 양상은 거래 시스템 및 청산 시스템을 결합하기위한 컴퓨터 화 된 방법을 포함한다. 네트워크는 적어도 하나의 거래 시스템과 청산 시스템을 연결합니다. 이 방법은 트레이딩 시스템을 외부 인터페이스에서 네트워크에 연결하고 클리어링 시스템을 클리어링 인터페이스에서 네트워크에 연결합니다. 이 방법에서 거래 정보의 전송은 거래 시스템에서 청산 시스템으로 네트워크를 따라 발생합니다. 이 전송은 외부 인터페이스에서 거래 정보가 도착할 때와 동시에 선택적으로 발생합니다. 거래 정보는 적어도 한 종류의 금융 상품 거래를 포함합니다.
본 방법의 일 실시 예에서, 적어도 하나의 거래 시스템은 복수의 거래 시스템이다. 다른 실시 예에서, 컴퓨터 화 된 방법에 관련된 적어도 하나의 종류의 금융 상품은 복수 종류의 금융 상품이다. 다른 실시 예에서, 컴퓨터 화 된 방법으로 거래 정보를 전송하는 것은 거래 알고리즘 또는 청산 알고리즘의 선택과 독립적으로 발생한다. 앞서 언급했듯이 금융 상품에는 증권, 주식, 채권, 상품, 선물, 금리 파생 상품, 통화, 통화 파생 상품, 유형 상품과 같은 상품, 무형 상품과 같은 상품 및 서비스가 포함됩니다. 본 발명은 근본적인 권리에 관계없이 모든 금융 상품에 대한 거래 및 청산 시스템 간의 이벤트 주도 무역 연결을 포함합니다.
다음의 도면 및 바람직한 실시 예의 상세한 설명은 본 발명의 이들 및 다른 특징 및 이점을보다 명확하게 설명 할 것이다.
도면의 간단한 설명.
무화과. 도 1은 구매자 (긴 포지션)와 판매자 (짧은 포지션) 간의 선행 금융 상품 거래 (상품과 같은)를 도시한다.
무화과. 도 2는 청산 시스템의 개입 후에 구매자 (긴 위치)와 판매자 (단 축 위치) 간의 선행 거래를 도시 한 도면.
무화과. 도 3은 단일 클리어링 시스템에 모두 네트워크화 된 복수의 트레이딩 시스템 및 그들의 외부 인터페이스의 블록도이다.
무화과. 도 4는도 3에 도시 된 동일한 블록도이다. 3), 단 하나의 거래 시스템과 그 외부 인터페이스의 세부 사항을 보여준다;
무화과. 도 5는 거래 시스템으로부터 외부 인터페이스를 통해 정보 센터로 전송 된 정보의 흐름도.
무화과. 도 6은 외부 거래 인터페이스로부터 청산 시스템으로 레코드를 전송하는 전송 메카니즘을 도시한다. 과.
무화과. 도 7은 클리어링 인터페이스의 동작 및 클리어링 하우스의 외부 인터페이스 및 다운 스트림 시스템에 대한 링크의 상세한 흐름도이다.
무화과. 도 8은 거래의 부분 매칭을위한 흐름도이다.
본 발명의 바람직한 실시 예의 상세한 설명.
무화과. 도 3은 다수의 트레이딩 시스템의 호스트 서버 (201A-AC), 트레이딩 시스템의 각각의 외부 인터페이스 (205AD) 및 클리어링 하우스 (215)의 클리어링 인터페이스 (213)에 대한 외부 인터페이스 (205AD)의 네트워크 또는 링키지 . 클리어링 시스템 (215) 자체는 다양한 방식으로 연결 장치에 연결될 수 있으며, 그 중 하나가 아래에서 논의 될 것이다. 편의상 그러나 제한을 제안하지 않고 나중의 수치는 하나의 거래 시스템과 하나의 외부 인터페이스 만 묘사 할 수 있습니다. (거래 시스템은 하나 이상의 외부 인터페이스를 가질 수있다. "외부 인터페이스"는 때로는 외부 거래 인터페이스라고 불릴 수있다.
I. 외부 (무역) 인터페이스.
무화과. 도 4는도 1에 도시 된 동일한 시스템의 블록도를 도시한다. WAN (265)에 의해 링크되지만, 하나의 거래 시스템 및 그것의 호스트 서버 (201) 및 하나의 외부 인터페이스 ( "EI") (205)와의 명확성을 위해 도시되어있다. 외부 인터페이스의 일 실시 예의 클리어링 시스템 (215)에 대한 링크와 관련된 외부 인터페이스 (205)의 내부 상세가 도시되어있다. 일 실시 예에서 외부 인터페이스는 실제로 MQ 시리즈 소프트웨어 (251) 및 DEC (235)를 사용하는 IBM 메인 프레임 인 2 대의 컴퓨터의 커플 링이다. 이 실시 예에서, IBM 메인 프레임은 트레이딩 시스템으로부터 클리어링 시스템으로 정보를 송신하기위한 송신기 또는 송신기 모듈이다. 또한 현재 외부 무역 인터페이스 수신기 245가 있습니다. 운영 체제는 MVS이며 COBOL 언어로 운영되는 것이 바람직합니다. 당업자에게 명백한 바와 같이, 다른 메인 프레임 또는 다른 컴퓨터 및 다른 운영 시스템이 사용될 수있다. 간단히 말해서 외부 인터페이스는 다음 세 가지 유형의 데이터 전송을 지원합니다. 정리 트랜잭션에 대한 위치 트랜잭션 (메시지 기반), 지우기 시스템에 보낸 위치 트랜잭션, 지우기 세션 레코드 (파일 기반) 조정 일련 번호 및 계약 볼륨 레코드 (파일 기반)를 표시하기 위해 클리어링 시스템에 전송 된 조정 파일은 각 시리즈 또는 계약의 총 구매 수량을 포함하는 조정 파일의 레코드를 조정합니다. 이 중 가장 자주 전송되는 것은 거래 거래입니다.
A. 외부 인터페이스 아키텍처.
무화과. 도 5는도 4의 정보 흐름을 도시한다. 4 시스템에 대해 자세히 설명합니다. 외부 인터페이스 아키텍처는 주로 위치 기반 트랜잭션 레코드의 중요성을 반영하여 메시지 기반입니다. 저장 및 예문 전송 ( "SAFT") 메카니즘 (231)이 사용될 것이다. SAFT 수신기 (235)는 호스트 계측 시스템 (221)의 SAFT 송신기 (241)에 의해 송신 된 위치 트랜잭션 레코드를 수신하기 위해 외부 인터페이스 (205)상에서 실행될 것이다. SAFT는 레코드를 새 파일에 기록합니다. 외부 인터페이스 Trade Receiver EI_TRD (245)는 위치 트랜잭션 정보 파일을 판독하여 새로 도착한 레코드를 추출하고, 이들 중 하나 이상을 하나의 메시지로 패킹하고, 메시지 시퀀스 번호를 할당하고, 이들을 MQSeries 미들웨어를 사용하여 컴퓨터에 의해 전송 대기열에 전달한다 251. 메시지를 트리거하는 트랜잭션의 수는 사용자의 필요에 따라 선택 될 수있다. 모든 거래가 개별적으로 전송되거나 (폴링) 더 큰 수를 묶어서 처리를 위해 전달할 수 있습니다. (MQSeries, a product of the IBM Corp. of Armonk, N. Y., is discussed in greater detail below.) In one embodiment, the external interface Trade Receiver 245 can also be manually triggered and can resend messages to the clearing system starting with a defined sequence number. After the messages are queued in the external trading interface, MQSeries 251 will transport the position transaction records 255 to a corresponding MQSeries queue (not shown) running at the clearing system 215 .
The reconciliation file sent to the clearing system 215 mentioned above is generated as follows. This reconciliation file is created during the batch of the trading system host 201 . A batch mainline calculates the total traded quantities for each contract, writes them to a reconciliation file and creates an “End-of-Session” (or “End-of-Day”) record which contains the last sent sequence number of the position transaction messages previously sent to the clearing system. Afterwards this file is sent from the trading system host 201 to the external interface 205 by another batch step via DECNET copy. All records from this file are forwarded, of course, by the external interface trade receiver 245 process to the MQSeries message queue 251 .
In one embodiment “End-Of-Session” information and “Contract Volume” data will be sent in one file with “End-Of-Session” information being the first record. This file will be transferred after all position transaction records have been sent, generally at the end of a trading day.
In one particular embodiment, the operations architecture can offer several additional features. First, the start/stop of the SAFT receivers 235 on the external interface 205 is included in the operations menu of the trading system host 221 . Second, the external interface trade receiver process 245 is started automatically during the usual external interface startup. In addition, a menu item is added to the host menu to start and stop external interface trade receiver manually. In one embodiment a start record number can be provided to the external interface trade receiver process to handle retransmit requests. Third, the trading system host 221 initiates the clearing system reconciliation file transfer during the daily batch procedure of the trading system. This batch step copies the reconciliation file to the external interface and starts a process that reads the reconciliation file and forwards all records to the message queue in MQSeries 251 . Fourth, a menu item is available on the trading system host 221 to allow a manual re-initiation of the clearing system reconciliation file transfer. Finally, during the DECNET copy and the forwarding of the reconciliation file to the clearing system 261 a log file is generated that allows verifying the successful execution of the file transfer. A menu item is available in the trading system operations menu to access this log file.
In another embodiment, the system will also support combination/spread orders and trades. Combination/spread orders/quotes are entered with a price differential and the two legs are matched as individual orders/quotes which include the execution price. Combination spread orders can be identified as combination orders in the position transaction record, but in this embodiment the legs cannot be linked.
무화과. 8 is a flow chart 800 for partial matching of a trade. As shown at block 802 , at least one offer to buy a financial instrument and at least one offer to sell the financial instrument partially matched at a trading computer system to generate the trade, with the partial matching comprising fully matching one of the offer to buy or the offer to sell and partially matching the other of the offer to buy or the offer to sell so that a remainder of the trade is unmatched. As shown at block 804 , the fully matched one of the offer to buy or the offer to sell is transmitted from the trading computer system to the external trading computer system separately from the remainder of the trade. As shown at block 806 , at least one trade is received by the external trading computer system from the trading computer system, the at least one trade received comprising the fully matched one of the offer to buy or the offer to sell. As shown at block 808 , the external trading computer system counts a number of trades received from the trading computer system. As shown at block 810 , the external trading computer system determines whether the number of trades equals the selectable number of trades. As shown at block 812 , the external trading system sends to the clearing system via the network the at least one trade received, including the fully matched one of the offer to buy or the offer to sell, when it is determined that the selectable number of trades have been received. As shown at block 814 , the trading computer system matches the remainder of the trade. As shown at block 816 , the trading computer system transmits to the external trading computer system the matched remainder of the trade. As shown at block 818 , the external trading computer system receives the matched remainder of the trade. As shown at block 820 , the matched remainder of the trade is sent to the clearing system separately from the fully matched one of the offer to buy or the offer to sell.
B. Data Transport to the Network.
The transport mechanisms used to send position transaction records from the External Interface to the clearing system is preferably based on MQSeries 271 using TCP/IP and is depicted in FIG. 6. The process of linking, and transmitting data from, the external interface 225 to the network 265 and thereby to the clearing system 261 will now be discussed in greater detail. An external interface server 225 attached to the trading system host provides a single exit or terminal point from the trading system to the clearing system 261 . Very generally, software on the trading system will transmit position data to the clearing system for clearing processing. A sequence number is assigned to each position transaction record. The external interface will deliver position transaction records as MQSeries messages from the trading system. Additionally, during batch processing, the interface will transfer a file record by record to the clearing system transmitting total traded quantities and the last sent sequence number in the position transaction records.
MQSeries 271 , message-oriented middleware, or other middleware can be employed in more than one function. The middleware will send position transaction records to the clearing system. The middleware will ensure all records are delivered even after a connection failure. All trades will be forwarded in a peer-to-peer configuration that will require a transmission queue 275 on the External Interface and a remote queue 281 on the clearing system 261 . The MQSeries provides an application programming interface known as MQI 285 . The components on the external interface 225 will use MQI to perform execution functions.
In addition to the message-based transmission of position transactions over MQSeries 271 , a reconciliation file is preferably sent also via MQSeries by distributing the records of the file into several MQSeries Messages 291 . This reconciliation file provides the clearing system with the total traded quantities per contract and the last sent sequence number.
C. Position Transaction Records.
The preferred normal processing of position transaction records is as follows in detail. The sending SAFT 241 process forwards the position transaction records from the Trading System host 221 to the External Interface 225 where the receiving SAFT 235 stores them in a file. At a configurable and selectable interval, which can be every single transaction) but more typically is several transactions, e. g., 10, a process on the External Interface 225 reads all newly arrived position transaction records and forwards them via a transmitter module using MQ Series middleware 271 to the clearing system 261 . The External Interface process will store up to a maximum number of position transaction records into an MQSeries Message 291 and will place the message into the queue 275 using the MQI API (“Applications Programming Interface”) 285 . This maximum number has to be specified.
One embodiment accounts for several anomalies. If the message cannot be passed successfully to MQSeries 271 an error will be formatted and the external interface process exits. This is considered to be a serious error and has to be solved by normal MQSeries operations with manual intervention. If the clearing system 261 does not successfully receive a record, retransmission requests will be manually triggered by the clearing system. The clearing system 261 will communicate to the host trading system 221 a starting message sequence number to retransmit. The trading system will manually configure the External Interface 225 process to send messages at a starting retransmission message sequence number until the end of the available messages. This manual intervention could cause the interface to transmit duplicate position transaction records to the clearing system when subsequent records have already been sent. The retransmission process will use the normal processing logic.
II. Clearing Interface.
The clearing interface is the interface on the clearing system side of the network from the trading system to the clearing system 261 and is part of the clearinghouse. The clearing interface is comprised of the functionality to receive input from the trading system and convert that input to enriched output that can be used by the remainder of the clearing system.
A. Overview of the Clearing Interface.
The trading system 221 provides trade data to the clearing system 261 for clearing processing. This data is sent as position transactions in POSTRN format using MQSeries from the External Interface 225 to the clearing interface in the clearing system. POSTRN format is the format used by the trading system indexed by sequence number and contains position transactions for the current trading day. From these position transactions the clearing interface re-creates the messages in the appropriate format. This format will be referred to as “TREX” format and is the trade record format containing trade information for both the buy side and sell side of a trade for transfer to the clearing system downstream systems. Other formats could be used, but these formats are established and are the best way known presently.
무화과. 7 depicts the scope of the clearing interface 301 . 무화과. 7 shows the link to the external interface 225 , three main processing components 305 , 311 , 315 and related databases and files of the clearing interface, and the downstream link 321 to the remainder of the clearing system.
The clearing interface consists of three main processing components, each of which will be described in detail below. Briefly, however, a technical processing component 305 receives 331 messages in queues from the MQ Series 333 containing POSTRN, end-of-session and contract volume records from the external interface 225 . This component also converts 341 regular fields from ASCII to EBCDIC and computational fields (binary coded numbers) from little endian to big endian format, performs a consistency check 345 on the message sequence number, and finally stores the records into a receipt database 351 . “ASCII” refers to the American National Standard Code for Information Interchange, the preferred character set used by the trading system and external interface. “EBCDIC” refers to the Extended Binary Coded Decimal Interchange Code, the preferred character set used by the clearinghouse.
A functional processor 311 performs a functional validity check 351 of the clearing firm and matches 355 the buy and sell sides belonging to one trade. This component also accumulates the contract volumes 361 , and performs the necessary conversions 365 form the POSTRN format to the TREX format. The functional component also performs a completeness check of the matching activities at the end of the session.
The third and final main processing component is an end-of-day processing component 315 that checks the trading system contract volumes 371 against the volumes accumulated during the day by the functional component. This component also performs the necessary conversions 375 for accumulated volume and contract volumes from one format, such as JVR 1 , to the volume transfer format, such as the BOTCC format. In some embodiments, no conversion is necessary.
B. Interface Communications.
The input interface between the external interface 225 and the clearing interface 301 is realized through the use of MQSeries 333 , as previously discussed. The clearing interface passes on trade records to the clearinghouse downstream systems 321 also using MQSeries 323 . The core interface process sends one composite TREX record containing the buy and sell sides of a trade within a single MQSeries message. Messages are sent after successfully matching orders belonging to one transaction identifier and enriching the resulting trade.
The communication between the processes 305 , 311 , 315 of the clearing interface will preferably use transient data queues, e. g. 381 A, B, C. One queue is required for communication between the technical component 305 , sometimes herein called the “input interface”, and the functional component 311 , a second queue is required for communication between the technical component 305 and the end-of-day component 315 . Processing in the functional component 311 and the end-of-day component 315 is triggered by data arriving in the transient data queue and will continue until the queue is empty. Recovery capability is preferably available to ensure data consistency at all times during the processing. This includes data in queues 323 , 333 from and to MQSeries, the transient data queues 381 A, B, C and the databases. Read and write processes from and to the MQSeries queues and the transient data queues are synchronized with the database updates so that in case of a failure all input and output channels can be rolled back to a defined and consistent position.
C. Detailed Architecture.
1. Technical Component.
In the preferred embodiment the technical component 305 performs all technical processing of the clearing interface 301 and in one embodiment is an IBM 9672 mainframe. The operating system in this embodiment is OS/390. Other mainframes or other computers, and other operating systems, from other vendors can be employed, as will be apparent to those of skill in the art. This includes interacting with MQSeries 333 to receive the data sent by external interface 225 , performing technical conversion of the data 341 and storing it in the receipt log 351 . The technical component also verifies that all trade records sent are received by performing a consistency check 345 on the sequence number. The database management system in one embodiment is DBMS available from IMS, employing a virtual sequential access methodology.
During the trading day as was discussed the sending process on the external interface 225 forwards all newly arrived position transaction records via MQ Series 333 to the clearing interface 301 in bursts at defined transaction intervals. At the end of the trading day as was also discussed, when the trading system is in batch processing, that system sends an end-of-session record and contract volume records. These may include a daily volume for an actively traded contract at an end of a trading day. As described below, the system may also check to see whether the daily volume corresponds to an accumulated volume corresponding to the actively traded contract.
The end-of-session record is a single record in a single MQSeries message. The contract volume records are packaged in groups just like the position transaction records.
On the clearing interface 301 the incoming messages from the MQ Series 333 are obtained from the MQSeries queue one by one until all messages of a burst have been read and the depth of the queue is zero. Each message obtained from the queue is stored 335 in the receipt log 351 as individual records before the next message is taken out of the queue. For each record in the message the data is passed to the technical conversion process 341 for conversion and storage 335 in the receipt log 351 (the original MQSeries message is not stored). In case the message received contains position transaction records, the messages passed on to the consistency check 345 before writing it to the database.
비. Technical Conversion.
The messages received, as was seen, are in ASCII format with embedded computational fields in DEC binary, little endian format. Regular fields, i. e., fields that contain plain alphanumeric characters, are converted to change each ASCII character to the corresponding EBCDIC character.
Computational fields on the trading system hardware (in one embodiment, DEC) are stored in a different byte order—least significant first—than on the clearing system hardware (in that embodiment, IBM)—most significant first. Therefore, the bytes have to be swapped into the right order to ensure the value is interpreted correctly by the clearinghouse system 321 . Of course, the little endian to big endian conversion is necessary only for messages containing position transactions. The end-of-session message and the contract volume messages do not contain computational fields.
기음. Consistency Check.
Each position transaction record sent by the external interface 225 has a unique sequence number that is continuously incremented by one for each record. The consistency check 345 verifies that the sequence number of the current record is one greater than the sequence number of the previous record received. If a sequence number is missing, manual intervention at both the trading system and the clearing system) is necessary to resolve the problem. In case of a duplicate sequence number the second record is ignored. The consistency check, however, is only performed for messages containing position transactions and for end of session messages. When the end-of-session message is received, the sequence number of the last position transaction record received is checked against the last sequence number sent that is contained in the end-of-session message. When a contract volume message is received, no consistency checking takes place.
All records that pass the consistency check 345 , are stored 335 in the receipt log 351 . In performing this functionality, the technical component, of course, functions as a storage device and is sometimes herein called that. A duplicate sequence number does not result in error processing, the second record is skipped and a warning message is displayed to the operators. In case a sequence number received is greater than the last sequence number plus one (i. e., a sequence number is missing: seq n +1 <seq n+1 ) or if the sequence number in the end-of-session message is not equal to the last received sequence number, the consistency check fails. An error message 347 is displayed to the operators 395 and the processing ends. However, records from the same message processed successfully before the error are stored in the receipt log 351 . Manual intervention on both the sending and the receiving sides (i. e., the trading system and the clearing system) is necessary to resolve the problem.
All records that pass the consistency check (or for which no consistency check is performed, i. e., volume records) are written to the receipt log 351 by a store operation 335 by the technical component, i. e., storage device as mentioned above. This database stores all messages that were successfully received 331 and converted 341 . Each record is stored with an initial status of unmatched. The status is later used, as will be seen, by the matching functionality to keep track of the position transaction records partially or fully matched. After each record is stored, processing continues with the conversion of the next record in the message.
For position transaction messages the following messaging logic is invoked. Due to the fact that the sequential input file used by the external interface 225 to create the messages for the clearing interface 301 is written by multiple posting processes running on the host trading system, transactions belonging to the same trade generally do not arrive in sequence but are mixed with transactions from other trades. The technical component 305 of the clearing interface levels out this disorder by keeping track of the received transaction numbers. After defined intervals (at the latest when the MQSeries queue is empty), records with one or more transaction identifiers are passed on to the functional processing component 311 so that component can perform its processing.
A selection algorithm can render this transferring process more efficient. For example, suppose records with transaction identifiers are received in the following order: ‘1’, ‘2’, ‘3’, ‘1’, ‘4’, ‘2’, ‘1’, ‘1’, ‘3’, ‘4’, ‘4’, ‘3’, ‘1’, ‘5’, ‘2’, ‘6’, ‘3’, ‘4’, ‘5’. A defined interval for this example could be selected as every fifth new (i. e., previously not occurred) transaction identifier. In this example records with the transaction identifier ‘1’ are passed on when ‘5’ occurs for the first time; all other records are held back. When ‘6’ arrives, records with identifier ‘2’ are passed on and so forth. With such an algorithm the likelihood of having already received all trades belonging to the same transaction identifier is significantly higher compared to an algorithm where every change (i. e. a defined interval of “one”) in the transaction identifier triggers passing on records with the previous identifier. If transmission occurs without such an algorithm, the transmission is said to be independent of the algorithm.
The end-of-session message is also sent to the functional processing component 311 . However, the contract volume record is sent to the end-of-day (or session) processing component 315 for contract balancing processing. As mentioned above, this will typically include daily volumes and a check on the accumulated volume.
2. Functional Component.
The functional component or “functional processor” 311 performs all intra-day functional processing, ensuring that all trade data required is made available to the clearinghouse downstream systems. This includes functionally validating 351 , matching 355 and enriching 365 the position transaction data received and stored by the technical component 305 . Enriched TREX records are then passed on to the clearinghouse downstream systems 321 via MQSeries 323 .
The processing in the functional component 311 is triggered by a transaction identifier sent from the technical component. All position transaction records with that identifier are retrieved from the receipt log 351 so that processing is done for one trade at a time. After a record has passed the functional validation 351 it is put in a buy or sell table for matching 355 . If the message from the technical shell signifies the record is an end-of-session message, the normal functional processing is skipped and a matching completeness check is performed.
에이. Functional Validation.
Trades to be cleared in the clearing house systems need to be associated with a valid clearing firm. In one embodiment the reference data between the trading system and the clearing system is not automatically synchronized but requires manual procedures. Conceivably, therefore, a new clearing firm is set up in the trading system, admitted to trading, when it is not set up in the clearing system. Accordingly, position transactions from clearing firms unknown to the clearing system could be transmitted. The clearinghouse downstream systems 321 would reject and drop such transactions.
To prevent the loss of position transactions the clearing firm of an incoming transaction is validated 351 against the clearing system reference data 385 . If the clearing firm is not found in the reference data, this transaction is flagged as an error. Manual intervention is required to update the reference data 385 and trigger the reprocessing of the transaction by the functional component 311 . If the clearing firm validation fails (i. e., the firm is not found in the clearing system reference data 385 ), then an error message 391 is displayed to the operators 395 and the transaction is written back to the receipt log 351 marked as an error. Other transactions belonging to the same trade identifier are not changed but normal processing continues for them.
If the clearing firm validation 351 is successful then the transaction is put into either the buy or the sell table. Each table is an internal memory table that is used during the matching process 355 . The trading system POSTRN format keeps long and short positions of a position transaction rather than the execution quantity. Therefore the execution quantity is calculated from the transaction long and short quantities before the record is put into the buy or sell table for matching. For regular trades, adding the absolute values of both quantities gives the execution quantity. In one embodiment Table 1 provides an overview of, and trading algorithm for, the different possibilities of buy or sell and open or close transactions and the resulting trade quantity.
The trading system in one embodiment assigns a unique transaction identifier to all orders that are part of one matching transaction (i. e., match at one price). This is true for the time-price priority matching algorithm as well as for the pro-rata matching algorithm. However, in this embodiment the trading system does not perform counterparty assignment. During the re-matching 355 by the clearing interface 301 the assignment of the opposing broker (counterparty assignment) is performed for all orders belonging to one matching transaction. The process of re-matching is also referred to as “trade generation” in the following discussion.
The matching or closing algorithm in one embodiment of the clearing interface processes the buy and sell tables based on the first-in-first-out rule (FIFO). As long as there are buy and sell records left in the tables the algorithm always completely executes the smaller quantity and partially executes the bigger quantity. Partially executed records remain in the buy and sell tables respectively for the following match. If buy and sell quantities are the same, both are executed fully.
For example, a transaction received from the trading system consisting of three buy position transaction records with quantities of 20, 5 and 15 and two sell position transaction records with quantities of 15 and 25 would create the trades depicted in Table 2.
For each match 355 the receipt log 351 is updated with the new status of the involved position transaction records (fully matched or partially matched) and the remaining quantity. As a result, the receipt log gives an exact picture of the matching process at any time. Each generated trade is passed on to the enrichment process 365 for conversions and formatting of the composite TREX record. Since there is no guarantee that the external interface 225 sends all position transaction records belonging to one transaction identifier before records of another transaction identifier are sent, it is possible that buy or sell position transaction records remain in the table without any matching opposite records. These records are matched 355 when the remaining position transaction records belonging to that transaction identifier are received later on within the same trading day. While this description focuses primarily on matching trades, one side with the other, the system will work as well, or even more efficiently, for recording and clearing completed trades, including both buy and sell sides of each trade.
The accumulated contract volume database 361 is used to accrue the volume of the current trading day for each actively traded contract. After each trade generation, the accumulated volume for the contract is increased by the quantity of the trade. At the end of the day the volume accumulated in this way is compared to the volume reported by the trading system, as will be discussed later. The accumulated contract volume database 361 also keeps statistics on the total number of buy and sell transactions. Every time a buy or a sell record is completely matched (i. e., it has no remaining quantity) the number of buy or sell transactions, respectively, in the database is increased by one.
기음. Trade Enrichment.
Trade enrichment 365 refers to actions that convert the generated trade from the POSTRN format used by the trading system in one embodiment to the composite TREX format used at the clearinghouse in that embodiment. Some fields can be copied as is, while others need to be calculated or derived from other fields. The following sections explain specific, more complex conversions and mappings in detail. Of course, the scope of the invention is not limited by the formats, conversion processes and references to types of individuals (e. g. “market maker”) employed in any particular embodiment. Different trading systems and clearing systems other than the specific embodiment described will have different individual characteristics.
Required Reference Data.
Table 3 provides an overview of the reference data fields that are required for the enrichment processes.
As mentioned earlier, although the activities of the trading system of one embodiment involve futures and options securities, including derivative instruments on commodities, the scope of the invention, in particular the kinds of securities, is not limited by that embodiment. As an example, a put may be thought of as a service or a right, to sell a certain number of shares at a certain price. Any other service or right that can be reduced to an amount of money may also be bought or sold on an exchange, provided there is an amount of trading sufficient to support a market. The invention is meant to include trade links between trading and clearing systems for any such goods or services.
In contract conversion the trading system security identifier is converted to clearing system commodity code conversion. In addition, the contract expiration date and the strike price (for options only) are converted. In the trading system securities are identified by a four character alphanumeric field. That field is converted to the clearinghouse commodity code, usually a two digit alphanumeric value stored in a five character alphanumeric field.
In the trading system the expiration date is in YYMM format where YY is a year offset from the reference year 1980. For example, a contract that expires in September 2000 is formatted with an expiration date of 2009. In the clearinghouse system the expiration date is in YYMMDD format where DD is always 00. Accordingly, the 2009 from the example is converted to 20000900.
Strike price conversion (for options) is very complex. In the trading system the strike price is in the fraction display format, a plain number of up to six digits. To interpret the number correctly it is required to know the fraction type of that particular security. For example, a strike price of 617 represents 61⅞ if the security's fraction type is eighths, but it is 6 17/32 if the security's fraction type is thirty-seconds. The clearinghouse system strike price format is similar to the trading system fraction display format but has leading zeros and—depending on the fraction code—trailing zeros. Also, the fraction value might have a different number (e. g., 4/8 is represented as 5, ⅞ as 8). The strike prices from the example above are represented as 0000618 and 0006170, respectively.
If both the trading system fraction type and the clearing system fraction code have the same base or tick size (e. g., both are eighths) then the strike price can be separated into an integer part and a fraction remainder and the clearinghouse strike price can be formatted accordingly. If the fraction types have the same absolute minimum tick value but different tick interpretations (e. g., a fourth of thirty-seconds and a half of sixty-fourth) the trading system fraction display format must be converted into raw ticks first (495 and 209, respectively, in the above example). At this point, the same conversion rules as for the trade price apply (see below).
Trade Price Conversion.
Trade prices in the trading system are stored as raw ticks, where the minimum tick value is the smallest fractional unit. If, for example, a security is traded a in fourth of thirty-seconds, the smallest fractional unit is one-hundred-and-twenty-eighths. A price of 6 17/32¼ is then represented as 837 (=[6*32+17]4+1). If a security is traded in eighths, the smallest fractional unit is eight. A price of 5⅞ is then represented as 47 (=5*8+7).
If both the trading system fraction type and the clearing system fraction code have the same minimum tick value (e. g., both are eighths) then the clearinghouse trade price can be calculated from the ticks by integer division and modulo division (remainder). In the second example above an integer division returns the whole number (47 div 8=5) and modulo division returns the fraction remainder (47 mod 8=7). Now the whole number and the fraction with the information in the reference data are used to populate the clearing system trade price field with 00000058 (as mentioned in the previous section, for eighths ⅞ are represented by an 8).
If the fraction types do not have the same absolute minimum tick value (e. g., thirty-seconds and eighths) the conversion is not supported. When new commodities are set up, the minimum tick value for the clearinghouse commodity code must be the same as for the corresponding trading system security.
Trade Time Conversion.
The time of a trade transaction is in trading system time. This system time has a defined offset from local time of a specific city where the clearing system in one embodiment is located. The offset is used to convert the transaction time of a trade to that city's local time. In order to be flexible and allow for changes of the offset time (e. g., different start or end date for daylight savings time) the offset value has to be configurable. Note that the transaction date is not changed during the conversion, but is always the date of the trading system business day on which the trade was executed (also referred to as “trade date”).
Extraction of Specific Fields.
The clearinghouse downstream systems 321 require the clearing fields “Account Number”, “CTI”, “Origin” and “Exchange Fee” to be populated. The clearing interface 301 extracts the values of these fields from the trading system free form text fields “Text” and “Customer”. In detail the procedure is as follows. The ten left-most characters in the field “Text” provide the account number; the remaining fields are cut off and are disregarded. The first character of the field “Customer” provides the CTI (customer type indicator) code as entered by the trader. The second and third character of the field “Customer” provide the origin code as entered by the trader. The fourth and fifth character of the field “Customer” provide the exchange fee type. In each case the data was entered by the trader. These text fields are only passed through from the trading system and no additional validation is performed. As the text fields are only filled for orders while remaining empty for quotes, the clearing interface populates the clearing system clearing fields with default values for quotes as described in the following section.
Defaults for Quotes.
For quotes the trading system sends the fields “Account Number”, “Origin”, “CTI” and “Exchange Fee” to the clearinghouse blank. The fields “Origin” and “CTI” will be populated based on the default mapping shown in the following tables; they are different for options and futures. The fields “Account Number” and “Exchange Fee” remain blank and are not filled. The field “O/C”, the open/close indicator (quotes are always closing transactions in the trading system) is not filled as it is not required for clearing quotes by the clearing system.
Table 4 shows the quote default mappings for futures.
Table 5 shows the same detail for options.
Assignment of Clearinghouse Record ID.
Each generated trade receives a clearing system record identifier, a number between 60,000 and 74,999 in one embodiment. This number is specific to each clearing firm and to options and futures separately. It is incremented by one for each new trade of a clearing firm in options and futures respectively and continues from one trading day to the next. Once the last trade identifier of 74,999 has been assigned to an options or futures trade of a firm, the number for that firm in options or futures is rolled over to 60,000 and starts again.
디. Store and Send.
After the generated trade has been completely enriched 365 the resulting composite TREX record is written to the TREX log or OIA (Office of Investigations and Audits) log 390 database and at the same time the record is sent to the clearinghouse downstream systems 321 via MQSeries 323 .
이자형. Matching Completeness Check.
At the end of the trading day during the batch processing the trading system sends an end-of-session message indicating that all position transactions have been sent. At this time all position transactions will have undergone the matching process 355 described. If only matched records are found in the receipt log 351 , all position transaction have been processed successfully. A specially formatted composite TREX record is sent to indicate the end-of-session to the clearinghouse downstream systems 321 . In case there are still unmatched records found in the receipt log 351 , an error message 391 is displayed to the operators 395 . The accumulated contract volume 361 for the contract of the order is adjusted to reflect the missing volume. The contract balancing processing in the end-of-day component will, as will be discussed below, take this error into account. The specially formatted composite TREX record is also sent in the error case. Manual intervention is necessary to solve the problem. While the TREX format is preferred, other formats may be used.
3. End-of-Day or End-of-Session Component.
The end-of-day (or end-of-session) component or “end-of-day processor” 315 is responsible for end-of-day functional processing ensuring that all volume data required is made available to the clearinghouse downstream systems 321 .
에이. Contract Balancing.
During the batch processing the trading system sends contract volume messages via MQSeries 333 to be used in contract balancing. These messages carry up to a defined number of records (in one embodiment ten, but the number can be changed by agreement of all system users) that contain the volume for each actively traded contract. This volume is checked 371 against the corresponding contract volume accumulated by the functional component from the individual trades during the day. Each contract that is verified successfully, i. e., where the volume transmitted from the trading system matches the volume accumulated during the day from the individual trades generated, is passed on to volume enrichment 375 . However, if a discrepancy between the volumes is detected, an error message 401 is displayed to the operators 395 , further processing for the faulty contract is skipped and the processing continues with the following contracts. Manual procedures are required to resolve the problem.
비. Volume Enrichment.
The contract volumes accumulated during the day and the contract volumes received at the end of the day are in trading system format and require enrichment 375 . For processing by the clearinghouse downstream systems 321 they are converted to clearing system format and stored in the volume transfer file 405 . Most fields can be copied as is. The contract conversion is performed with the process described above under “Trade Enrichment” 365 except for the expiration date conversion. This conversion is not necessary as the expiration date is received in normal YYMMDD format and not necessarily in a proprietary trading system format. From the above description of the embodiments of the present invention, the advantages of the invention are clear. Multiple financial trading systems can be linked to a single clearing system. Multiple kinds of financial instruments can be cleared in a single clearing system, or if desired, more than a single clearing system. In both cases, the invention allows for more rational amounts of collateral and margin. Finally, the more immediate communication of trading information permits more immediate clearing of the transactions, together with attendant resulting benefits, including more appropriate amounts of margin.
The steps of the methods recited herein can be performed in any order consistent with the recited acts. While particular embodiments of the present invention have been and will be shown and described, modifications may be made. In particular, individual mention has been made of specific items of hardware, e. g., mainframe computers, specific forms of software and various kinds of networks. Individual mention has also been made of specific trading systems, clearing systems, types of financial instruments, and trading information. The invention is not limited to the use of these specific components and other specific matters that are exemplary only, but includes all equivalents of those components and matters. For example, the networks described may be private or proprietary, or can include the public Internet. In addition, while certain preferred data formats are described, other data it formats and conversions may also be used.
While the invention has been described with reference to specific embodiments, the description is illustrative of the invention and not to be construed as limiting the invention. Various modifications and applications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined in the appended claims, including all equivalents.

Systems Trading.
TRADING SYSTEMS – WHAT and WHY?
Trading systems are generally computer software programs which issue buy and sell signals based upon price, volume or other empirical data. By analyzing real-time price data and comparing such data to pre-set pattern recognition inputs, or by running said data thru mathematical algorithms generally compiled by the system provider himself, trading signals are generated and then run through an auto-execute applet in order to effect the trades thus indicated.
Because such systems are computer based, they are not liable to human input and thus don’t carry the tendency to second guess the pre-set parameters, hesitate to execute indicated trades, or simply miss signals because the trader is distracted for any reason.
They are thus incapable of straying from the trading discipline set into the system at its outset.
In short, they are significantly less liable to the human frailty inherent in any trader’s psyche.
Because computers aren’t subject to distraction or fatigue or hesitation, they offer a more disciplined approach to trading volatile markets while also possessing the added advantage they are able to make trading decisions 24 hours per day, seven days per week often for weeks on end. Additionally, because the developmental stage is where the decision-making process is defined, tested and refined, subsequent decisions are made with split-second efficiency far beyond the capability of any human trader.
This defining, testing and refining process often goes on for years and in some cases even decades to come up with the end result. That being said, hypothetical results do offer investors the ability to evaluate key performance statistics such as:
Current year-to-date return Average return Average winning trade.
Maximum drawdown Average drawdown Average losing trade.
Systems Trading Products Affiliated with Dorman Trading.
Select from one of two specially selected futures trading system providers:
Collective2.
Dorman Trading, LLC Clearing Members: CME, CBOT, COMEX, NYMEX, ICE-US, Eris Exchange. Non-Clearing Member: Eurex.
Registered Futures Commission Merchant | Registered CFTC | NFA Member. All content © 2016 Dorman Trading, LLC.
거래 선물 및 옵션에는 손실 위험이 있습니다. Futures trading is not appropriate for all investors.
Copyright © 2016. All market data is provided by Barchart Market Data Solutions. Futures: at least 10 minute delayed. 정보는 '있는 그대로'제공되며 거래의 목적이나 조언이 아닌 정보 제공의 목적으로 만 제공됩니다. To see all exchange delays and terms of use, please see disclaimer.