브로커가 “유동성이 연결되어 있다”고 말할 때, 나는 한 가지 질문을 한다: 팀이 거래 플랫폼에서 주문이 이루어지는 회사까지의 경로를 그릴 수 있는가?
다이어그램에 LP / bridge / aggregator라는 레이블이 붙은 상자가 하나 있다면, 설정이 아직 이해되지 않은 것입니다. 이러한 계층은 하나의 상업 패키지로 제공될 수 있지만, 서로 다른 작업을 수행합니다.
- A 유동성 공급자, 또는 LP는 실행 가능한 가격과 사용 가능한 크기를 제공합니다. 합의된 실행 조건에 따라 주문을 수락, 거부 또는 체결합니다.
- A 유동성 집계기는 여러 출처에서 가격과 깊이를 수집합니다. 결합된 보기를 구성하고 어떤 출처가 주문을 충족할 수 있는지 결정합니다.
- A 유동성 브리지는 브로커의 플랫폼을 외부 또는 내부 실행과 연결합니다. 메시지를 변환하고, 기호를 매핑하며, 브로커의 라우팅 규칙을 적용하고 실행 결과를 반환합니다.
가장 간단한 유용한 설명은 다음과 같습니다: LP는 유동성을 제공하고, 집계기는 여러 출처에 대한 접근을 조직하며, 브리지는 그 실행 스택을 중개의 플랫폼에 연결합니다.
| 질문 | 유동성 공급자 | 집계기 | 브리지 |
|---|---|---|---|
| 가격은 어디에서 오나요? | LP는 자신의 가격 또는 상위 가격을 인용합니다 | 연결된 출처에서 받은 가격을 결합합니다 | 선택된 가격 스트림을 플랫폼에 전달합니다 |
| 누가 깊이를 공급하나요? | LP | 아무도; 사용 가능한 LP 깊이를 결합합니다 | 아무도; 구성된 데이터를 보유하고 적용합니다 |
| 누가 LP 중에서 선택하나요? | 브로커의 다른 LP들 사이에서는 아닙니다 | 집계 및 라우팅 논리 | 브리지가 주문을 구성된 경로로 보냅니다 |
| 누가 거래 플랫폼에 연결하나요? | 때때로 직접 | 때때로 번들된 제품의 일부로 | 이것이 브리지의 핵심 역할입니다 |
| 누가 외부 주문을 채우나요? | 선택된 LP 또는 장소 | 여러 채우기를 조정할 수 있습니다 | 보고서를 수신하고 플랫폼에 다시 매핑합니다 |
각 레이어가 위치하는 곳
“`html레이어가 연결되는 방법
EUR/USD · 설명적인 외부 실행
거래 플랫폼
가격과
거래 결과 표시
브리지
메시지를
플랫폼으로 변환
집계기
인용을 비교하고
소스를 선택
유동성 제공자
가격을 제공하고 채우기
세 가지 소스, 하나의 가격 흐름. 집계기가 LP 인용을 비교합니다. 브리지가 선택된 흐름을 플랫폼으로 전달합니다.
100,000 EUR 구매. 브리지가 주문을 변환합니다. 집계기는 이 예에서 가장 적합한 요청과 충분한 크기를 가진 LP A로 라우팅합니다.
LP A가 1.08420에서 주문을 채웁니다. 실행 보고서는 집계기와 브리지를 통해 반환됩니다. 플랫폼은 거래를 업데이트합니다.
인용은 유동성 제공자로부터 집계기와 브리지를 거쳐 거래 플랫폼으로 흐릅니다. 주문은 반대 방향으로 이동합니다. 채우기 보고서는 선택된 제공자로부터 반환됩니다.
퀏은 유동성 출처에서 거래 플랫폼으로 이동합니다. 주문은 반대 방향으로 이동합니다. 실행 보고서는 그런 다음 동일한 경로를 통해 반환됩니다.
그 깔끔한 도표에는 두 가지 일반적인 변형이 있습니다.
먼저, 하나의 LP를 사용하는 브로커는 그 공급자에게 브리지를 직접 연결할 수 있습니다. 집계할 것이 없습니다.
둘째, 하이브리드 브로커는 일부 클라이언트 흐름을 내부화할 수 있습니다. 브리지 또는 연결된 리스크 엔진은 집합체 또는 LP에 필요한 헤지 만을 전송할 수 있습니다. 따라서 클라이언트 주문과 외부 헤지는 항상 같은 크기이거나 일대일 쌍이 아닙니다.
유동성 공급자가 하는 일
LP는 가격을 제공하고 정의된 실행 가능한 크기 뒤에 있습니다. FX 및 CFD에서 공급자는 은행, 비은행 시장 조성자, 프라임-오브-프라임, 중개인, 거래소 또는 상류 유동성에 접근할 수 있는 다른 거래 상대방일 수 있습니다.
라벨만으로는 저에게 거의 아무것도 알려주지 않습니다. 나는 알고 싶습니다:
- 어떤 악기와 세션을 포함하는지;
- 각 깊이 수준에서의 매도 및 매수 가격;
- 최소 및 최대 주문 크기;
- 가격이 확정되어 있는지 아니면 마지막 확인을 거치는지;
- 채우기, 부분 채우기 및 거부 동작;
- 마진, 담보 및 신용 조건;
- 수수료 및 기타 실행 비용;
- 뉴스, 롤오버 및 시장 갭 동안 성능이 어떻게 변화하는지.
LP는 모든 주문에 대해 긴축된 스프레드를 보장하지 않습니다. 주문서의 상단에서 견적이 긴축될 수 있지만, 작은 사이즈만을 제한할 수 있습니다. 다음 레벨은 몇 포인트 떨어져 있을 수 있습니다.
일부 FX 제공업체는 마지막 확인을 사용하며, 이는 거래 요청을 받은 후 최종 가격 또는 유효성 검사를 수행함을 의미합니다. 그 결과는 수용 또는 거부가 될 수 있습니다. 해당 정책은 LP 또는 장소 관계에 속합니다. 집계기와 브리지는 응답을 정확하게 기록해야 하지만, 제공업체의 수용 규칙을 만들지는 않습니다.
유동성 집계기가 하는 일
집계자는 여러 LP 또는 장소에서 스트림을 수신하고 이를 하나의 사용 가능한 보기로 정규화합니다.
각 기호는 다음과 같을 수 있습니다:
- 최고의 매도호가와 매수호가를 비교하세요;
- 여러 출처에서 깊이를 결합하다;
- 오래된, 유효하지 않거나 사용할 수 없는 인용을 제거하십시오;
- LP 크레딧 및 크기 제한을 존중하십시오;
- 대량 주문을 가격 수준에 따라 나누기;
- 가격, 깊이, 대기 시간 및 체결 이력을 기반으로 경로를 선택하십시오;
- 정책이 허용하는 경우 거부 후 다른 소스로 이동하십시오.
집합체는 유동성을 생성하지 않습니다. 세 개의 연결된 공급자가 모두 자신의 견적을 철회하면, 결합된 장부는 여전히 비어 있습니다. 모든 공급자가 스프레드를 넓히면, 집합은 어제의 스프레드를 유지할 수 없습니다.
그러나 이는 하나의 출처에 대한 의존도를 줄일 수 있습니다. 한 LP는 소규모 EUR/USD 주문에 대해 최상의 가격을 제공할 수 있는 반면, 다른 LP는 대규모 주문에 대해 더 많은 깊이를 제공합니다. 집계기는 이러한 차이를 드러내고 둘 다 사용할 수 있습니다.
가격 집계는 주문 집계와 동일하지 않습니다
가격 집계는 들어오는 견적에서 복합 가격 또는 책을 만듭니다.
주문 집계는 주문이 전달되기 전에 주문을 결합하거나 순서를 정리합니다. 이는 중개인의 위험 및 실행 스택의 다른 곳에서 발생할 수 있습니다. 두 기능은 기술을 공유할 수 있지만, 서로 다른 질문에 대답합니다.
이 구별은 하이브리드 모델에서 중요합니다. 브로커는 고객에게 여러 LP 스트림에서 구축된 가격을 보여주고, 일부 포지션을 내부화하며, 순 노출만 외부로 전송할 수 있습니다. 집계된 가격을 보는 것은 모든 고객 거래가 외부 LP에 도달했다는 것을 증명하지 않습니다.
유동성 브릿지가 하는 일
브리지는 거래 플랫폼과 선택한 실행 경로 간의 통합 및 제어 계층입니다.
그의 책임에는 다음이 포함될 수 있습니다:
- 플랫폼 메시지를 FIX 또는 다른 API 형식으로 변환;
- 부지를 단위 또는 계약 수량으로 변환하기;
- 매핑 기호, 소수점 및 계약 크기;
- 가격 스트림을 올바른 플랫폼 그룹으로 전송;
- 마크업 또는 실행 설정 적용;
- LP, 집계기 또는 내부 주문서로 주문 라우팅;
- 부분 체결, 거부 및 연결 해제를 처리합니다;
- 외부 실행 ID를 플랫폼 주문에 매핑하기;
- 조정을 위한 타임스탬프 및 로그 보존.
브리지는 중개인의 구성을 실행합니다. 스스로 비즈니스 모델을 결정하지 않습니다. 여전히 누군가 외부화할 흐름, 허용된 경로 및 기본 연결이 실패했을 때 무엇이 발생하는지를 정의해야 합니다.
이것이 또한 다리가 약한 유동성을 복구할 수 없는 이유입니다. 한 유동성 공급자가 주문을 거부한 후 주문을 다른 경로로 우회할 수 있지만, 다음에 가능한 가격은 더 나쁠 수 있거나 사용할 수 없을 수 있습니다. 페일오버는 탄력성을 향상시키지만, 동일한 실행 조건을 보장하지는 않습니다.
모든 세 가지 레이어를 통한 EUR/USD 주문
브로커의 위험 정책이 €750,000 EUR/USD 매수 주문을 외부로 전송한다고 가정합니다. 사용 가능한 매도 측은 다음과 같습니다:
| 출처 | 요청 | 사용 가능한 크기 |
|---|---|---|
| LP A | 1.08420 | €300,000 |
| LP B | 1.08422 | €500,000 |
| LP C | 1.08425 | €1,000,000 |
[Custom HTML block: Aggregated liquidity order sweep – paste 02-aggregated-order-sweep.html here.]
브리지는 플랫폼 주문을 수신하고, 심볼과 볼륨을 확인한 후, 구성된 외부 경로로 전송합니다.
집계기는 LP A가 가장 좋은 매도 호가를 가지고 있지만 전체 금액을 채울 수 없음을 봅니다. €300,000를 LP A에 보내고 나머지 €450,000를 LP B에 보냅니다.
거래량 가중 평균 가격은:
(€300,000 x 1.08420 + €450,000 x 1.08422) / €750,000 = 1.084212
두 개의 채움이 집계기를 통해 반환됩니다. 브리지는 이를 원래 플랫폼 주문에 매핑하고 결합된 결과를 보고합니다.
이 예시는 역할을 분리합니다. 실제 실행은 지연 시간, 가격 변동, 수수료, 마크업, 마지막 조회, 부분 체결 및 LP 특정 최소 크기도 포함할 수 있습니다.
제품 이름이 이 혼란을 초래하는 이유
한 공급업체는 집계를 포함하는 “브리지”를 판매할 수 있습니다. 다른 공급업체는 전체 제품을 집계기로 부를 수 있지만, 플랫폼 커넥터, 리스크 규칙 및 보고서도 제공합니다. LP는 브로커에게 하나의 가격 스트림을 보여주기 전에 여러 상류 소스를 집계할 수 있습니다.
상업적 라벨은 논리적 질문을 변경하지 않습니다:
- 누가 실행 가능한 견적을 제공하고 외부 체결을 수행합니까?
- 누가 여러 출처를 결합하고 순위를 매깁니까?
- 플랫폼 주문을 번역하고 중개인의 경로를 적용하는 사람은 누구입니까?
- 무엇이 발생했는지를 증명하는 로그는 누구의 소유인가요?
저는 공급업체에게 지연 주장에 대해 논의하기 전에 이러한 책임을 명확히 할 것을 요청합니다. 소유권이 불분명한 빠른 시스템은 주문이 이의 제기될 때 즉시 느려집니다.
브로커에게 필요한 설정은 무엇인가요?
하나의 LP와 간단한 외부 경로
한 개의 LP에 직접 연결된 다리면 충분할 수 있습니다. 이것이 가장 작은 아키텍처이지만, LP는 여전히 단일 의존성 포인트로 남아 있습니다.
유동성을 위해 경쟁하는 여러 LP
브로커는 가격과 깊이를 비교하기 위한 집계 로직이 필요합니다. 또한 집계된 경로와 거래 플랫폼 간의 브리지 또는 동등한 커넥터가 필요합니다.
하이브리드 실행 모델
브로커는 내부화, 헤지 또는 각 노출을 경로로 설정할지 결정하는 위험 규칙과 플랫폼 연결성이 필요합니다. 외부 경로에 여러 출처가 있을 때 집계기가 중요합니다.
관리되는 화이트 라벨 스택
브리지 및 집계 레이어는 포함될 수 있으며 중개인에게는 대부분 보이지 않습니다. 이는 통합 작업을 줄이지만, 운영자는 여전히 실행 보고서, 거부 사유, 라우트 상태 및 사건 소유권을 받아야 합니다.
퀘드코드의 턴키 브로커리지 솔루션은 거래 플랫폼과 유동성, 거래, 리스크 관리 및 백오피스 인프라를 결합합니다. 또한 사전 연결된 유동성과 다른 LP를 연결할 수 있는 옵션을 지원합니다. 브로커에게 실질적인 질문은 어떤 부분이 제공자에 의해 관리되고 어떤 통제가 브로커의 손에 남는가입니다.
공통 실행 문제는 누구의 소유입니까?
| 증상 | 조사를 여기서 시작하세요 | 이유 |
|---|---|---|
| 단 하나의 LP만 인용 중지 | LP 연결 및 집계기 | 출처 상태 및 오래된 인용이 제거되었는지 확인 |
| 모든 클라이언트 가격이 잘못된 소수 사용 | 브리지 또는 플랫폼 매핑 | 기호 정의가 잘못 번역되고 있음 |
| 대량 주문이 여러 가격에 체결 | 집계기 및 LP 깊이 | 주문이 여러 수준 또는 출처를 초과했을 수 있음 |
| 주문이 인용에 도달한 후 거부됨 | LP 응답, 그 다음 경로 정책 | 거부 이유 및 재시도 허용 여부 확인 |
| 플랫폼과 LP의 볼륨이 다름 | 브리지 로그 및 중개인 위험 정책 | 외부 헤지가 순 netted, 분할 또는 부분 체결되었을 수 있음 |
| 플랫폼은 체결을 보여주지만 재무는 일치하지 않음 | 브리지, 집계기 및 LP 실행 ID | 체인은 추적 가능한 식별자 세트를 필요로 함 |
모든 사례를 “LP 문제”라고 부르는 것은 시간을 낭비하는 것입니다. 모든 사례를 “브리지 문제”라고 부르는 것도 마찬가지입니다. 상태가 변경될 때까지 플랫폼에서 외부로 주문 ID를 따라가세요.
[Internal link: Broker Reports Don’t Match]
레이어별 모니터링할 메트릭
유동성 공급자
- 기호 및 세션별로 확산 및 사용 가능한 깊이;
- 충족, 부분 충족 및 거부율;
- 적용 가능한 경우 마지막 수용;
- 주문 크기에 따른 슬리피지 및 응답 시간;
- 담보 사용 및 상대방 노출.
집계기
- 각 LP의 최적 가격 및 실행된 거래량에 대한 기여도;
- 복합 스프레드 및 깊이;
- 오래된 인용 삭제;
- 주문당 사용된 소스의 수;
- 우회, 청소 및 경로 집중화.
다리
- 지연 시간을 라우팅하는 플랫폼;
- 매핑 및 검증 거부;
- 전송되거나 중복된 메시지;
- 연결 가동 시간 및 장애 조치 이벤트;
- 비교할 수 없는 플랫폼 및 외부 실행 ID.
종단 간 실행 품질은 여전히 가장 중요합니다. 브로커는 요청된 가격과 체결된 가격, 슬리피지 분포, 체결 비율 및 주문 크기와 시장 조건에 따른 거부를 비교해야 합니다. 건강한 평균은 롤오버 또는 높은 변동성 동안 부진한 결과를 숨길 수 있습니다.
내가 지키는 구별
제공자는 인용과 채우기를 소유합니다. 집계자는 여러 출처가 어떻게 조회되고 사용되는지를 결정합니다. 브리지는 중개인의 플랫폼과 정책으로 해당 실행 경로가 작동하도록 합니다.
모든 세 가지를 하나의 계약으로 묶더라도 그 책임을 항상 명확히 해 두십시오. 그렇게 해야 브로커가 어떤 레이어를 변경해야 할지, 어떤 팀에 연락해야 할지, 어떤 로그가 거래를 설명해야 할지를 알 수 있습니다.
