유동성 브릿지는 주문이 실패하기 시작할 때까지는 추상적으로 들리는 용어 중 하나입니다.
거래 플랫폼이 활성화되었고, 클라이언트는 거래를 시작할 수 있으며, 유동성 공급자는 연결이 준비되었다고 말하지만, 진짜 질문은 여기서 시작됩니다: 왜 이 주문이 거부되었는가, 왜 금의 슬리피지가 확대되었는가, 왜 EUR/USD는 헤지되었지만 암호화폐는 그렇지 않았는가, 왜 백오피스는 한 가격을 보여주고 LP 보고서는 다른 가격을 보여주는가?
거래 플랫폼과 외부 유동성 사이의 공간이 바로 브릿지가 중요한 이유입니다. 외환 유동성 브릿지는 중개인의 거래 플랫폼을 유동성 제공자, 집계기, 프라임 브로커, 거래소 또는 내부 실행 로직에 연결합니다. 가격을 이동시키고, 주문을 외부로 전송하며, 체결 결과를 다시 받아오고, 거래, 리스크, 지원 및 재무 팀이 무슨 일이 있었는지 이해할 수 있도록 충분한 기록을 유지합니다.
새로운 중개인에게 브리지는 항상 별도로 구매해야 하는 것이 아닙니다. 많은 화이트 라벨 또는 턴키 설정에서는 이미 제공업체 스택의 일부입니다. 하지만 운영자는 여전히 그것이 무엇을 하는지 이해할 필요가 있습니다. 왜냐하면 실행 문제는 처음에는 “브리지 문제”처럼 들리지 않기 때문입니다. 그것들은 고객 불만, 거부된 거래, 혼란스러운 보고서 또는 설명되지 않은 노출처럼 들립니다.
다리의 위치
기본 거래 스택은 네 개의 이동하는 요소로 구성됩니다:
- 거래 플랫폼: 고객이 가격을 보고, 주문을 하고, 포지션을 관리하는 곳입니다.
- 유동성 공급자 또는 집계기: 실행 가능한 가격과 외부 체결이 어디서 오는지.
- 브리지: 그들 사이의 흐름을 번역하고, 라우팅하며, 매핑하고, 로그를 기록하고, 제어하는 미들웨어.
- 백오피스 및 위험 도구: 브로커가 노출, 그룹, 실행 결과, 클라이언트 활동 및 보고서를 모니터링하는 곳입니다.
브리지는 유동성 공급자와 동일하지 않습니다. LP는 가격 책정 및 실행을 제공합니다. 브리지는 중개인의 플랫폼에서 그 연결이 어떻게 사용되는지를 결정합니다.
브리지 vs 유동성 공급자 vs 집계기
이 용어들은 판매 전화에서 혼합되어 사용되지만, 같은 의미가 아닙니다.
| 계층 | 기능 | 스스로 해결하지 못하는 것 |
|---|---|---|
| 유동성 공급자 | 합의된 조건에 따라 가격을 제공하고 주문을 실행함 | 플랫폼 통합, 클라이언트 그룹 규칙, 전체 보고 워크플로우 |
| 유동성 집계기 | 여러 LP의 가격을 결합하고 가장 좋은 이용 가능한 견적을 선택할 수 있음 | 브로커 정책, 클라이언트 세분화, 내부 위험 결정 |
| 유동성 브리지 | 플랫폼을 LP 또는 집계기에 연결하고, 기호를 매핑하며, 라우팅 규칙을 적용하고, 주문을 전송하며, 체결을 수신함 | 약한 유동성 관계, 열악한 위험 정책, 잘못된 클라이언트 커뮤니케이션 |
| 거래 플랫폼 | 트레이더에게 차트, 주문 티켓, 계정 보기 및 거래 관리 기능을 제공함 | 유동성 인프라에 연결되지 않는 한 외부 실행 로직 |
간단히 말하면: LP는 시장을 제공하고, 플랫폼은 거래자 인터페이스를 제공하며, 브리지는 이들 간의 대화를 처리합니다.
브로커가 실제로 브리지가 필요할 때
브로커는 일반적으로 외부 실행, 자동화된 헤징 또는 폐쇄형 플랫폼 설정이 제공하는 것보다 가격 책정 및 라우팅에 대한 더 많은 제어가 필요할 때 브리지 기능이 필요합니다.
일반적인 사례:
- 브로커는 MT4, MT5 또는 다른 플랫폼을 사용하며 하나 이상의 LP에 연결하고자 합니다.
- 중개인은 A-북 또는 하이브리드 모델을 운영하며 선택된 클라이언트 흐름을 외부로 라우팅해야 합니다.
- 중개인은 서로 다른 마크업, 기호, 레버리지 또는 라우팅 규칙을 가진 여러 클라이언트 그룹을 보유하고 있습니다.
- 브로커는 하나의 유동성 공급원이 가격 책정을 중단하거나 주문을 거부하기 시작할 경우 장애 조치를 원합니다.
- 중개인은 지원, 거래 및 위험 검토를 위한 자세한 실행 로그가 필요합니다.
- 중개인은 나중에 더 많은 자산 클래스나 유동성 출처를 추가할 계획입니다.
브로커가 내장된 유동성을 갖춘 완전 관리형 화이트 레이블 설정을 사용하는 경우, 운영자는 별도의 브리지를 소유할 필요가 없을 수 있습니다. 그러나 주문이 어떻게 라우팅되는지, 가격이 어떻게 설정되는지, 실행 품질이 어떻게 보고되는지에 대한 가시성은 여전히 필요합니다.
일상 운영에서 다리의 제어 사항
브리지는 단순한 파이프가 아닙니다. 실시간 중개에서는 고객이 즉시 알아차리는 여러 가지에 영향을 미칠 수 있습니다.
가격 피드
브리지는 LP 또는 집계자로부터 가격을 받아 거래 플랫폼으로 보냅니다. 가격 책정이 불안정하거나 오래되었거나 너무 넓거나 잘못 매핑된 경우, 트레이더는 이를 빠르게 확인할 수 있습니다.
좋은 운영자는 모니터링합니다:
- 인용 가동 시간
- 기호와 세션으로 확산
- 가격 차이와 오래된 틱
- 플랫폼 가격과 LP 가격의 차이
- 심볼별 이슈, 특히 시장 개장 및 뉴스 이벤트 관련
기호 매핑
기호 매핑은 지루하게 들리지만, 그것이 깨질 때까지입니다.
플랫폼은 기호를 XAU/USD라고 부를 수 있고, LP는 이를 XAUUSD라고 부를 수 있으며, 다른 장소에서는 계약 크기나 소수점 차이가 있을 수 있습니다. 브리지는 주문 크기, 가격 정확도, 스왑, 마크업 및 보고가 일치하도록 기호를 올바르게 매핑해야 합니다.
잘못된 매핑은 잘못된 노출, 거부된 주문, 나쁜 P&L, 또는 해결하는 데 몇 시간이 걸리는 지원 사례를 생성할 수 있습니다.
마크업 및 그룹
브로커는 종종 고객 그룹, 금융 상품, 계좌 유형, 지역 또는 전략 프로필에 따라 마크업을 적용합니다. 브리지는 이러한 규칙을 적용하거나 라우팅하는 데 도움이 될 수 있습니다.
위험은 과도한 설계입니다. 너무 많은 그룹과 예외가 실행 진단을 어렵게 만듭니다. 중개자는 각 그룹이 존재하는 이유와 규칙의 소유자가 누구인지 알아야 합니다.
라우팅 및 헤징
하이브리드 모델에서는 모든 주문이 자동으로 외부로 전달되는 것은 아닙니다. 일부 흐름은 내부화될 수 있고, 일부는 헤지될 수 있으며, 일부는 노출이 기준을 초과한 후에만 전달될 수 있습니다.
이 다리는 다음과 같은 규칙을 지원할 수 있습니다:
- 선택된 LP로 경로 특정 기호를 전달합니다.
- 특정 고객 그룹에만 헤지하십시오.
- 더 큰 티켓을 외부로 라우팅합니다.
- 주요 유동성 공급자가 거부할 경우 백업 유동성을 사용하십시오.
- 얇은 유동성이거나 뉴스가 있는 동안 라우팅을 변경하세요.
중요한 점: 브리지는 규칙을 실행하지만, 중개인은 정책을 정의해야 합니다.
실행 보고서
이 브리지는 간단한 지원 질문에 답하기 위해 충분한 데이터를 보유해야 합니다: 이 주문에 무슨 일이 발생했나요?
유용한 로그에는 다음이 포함됩니다:
- 플랫폼에서 주문 타임스탬프
- 다리로 보낸 시간
- LP에 전송된 시간
- LP 응답 시간
- 요청된 가격
- 채워진 가격
- 거부 사유
- 부분 채우기 세부정보
- 슬리피지
- 클라이언트 그룹 및 라우팅 규칙
이 경로 없이는 팀들이 추측하게 됩니다.
다리 프로젝트가 잘못되는 곳
대부분의 브리지 문제는 극적인 기술 실패가 아닙니다. 이들은 출시 후 비용이 많이 드는 작은 불일치입니다.
기호 설정이 급하게 진행됩니다.
브로커는 팀이 제대로 테스트할 수 있는 것보다 더 많은 도구를 추가합니다. 금속, 지수, 암호화폐 CFD 및 합성 기호는 종종 추가적인 주의가 필요합니다.
모두가 지연 시간에 대해 이야기하지만, 아무도 거부를 모니터링하지 않습니다.
낮은 지연 시간이 중요하지만, 빠른 거부는 여전히 실패한 거래입니다. 체결 비율, 거부 사유 및 슬리피지 분포는 종종 헤드라인 지연 시간 숫자보다 더 많은 정보를 제공합니다.
라우팅 규칙이 너무 똑똑해진다.
복잡한 규칙 집합은 데모에서는 강력해 보일 수 있지만 클라이언트 불만 시 설명하기가 불가능해질 수 있다.
보고서가 일치하지 않습니다.
플랫폼 보고서, LP 명세서, 브리지 로그 및 백오피스 숫자는 일치해야 합니다. 그렇지 않으면 재무 및 거래 부서가 스택에 대한 신뢰를 잃게 됩니다.
페일오버는 가정된 것이지 테스트된 것이 아닙니다.
백업 유동성은 팀이 주요 피드가 중단되거나 거부되거나 공격적으로 확대될 때 어떤 일이 발생하는지를 테스트한 경우에만 유용합니다.
브리지 또는 유동성 기술 제공자에게 물어볼 것
제공업체를 선택하기 전에, 시스템이 압박을 받을 때 어떻게 작동하는지를 드러내는 질문을 하십시오.
연결성
- 어떤 플랫폼이 직접 지원되나요?
- 다리 연결이 FIX, 독점 API, 게이트웨이 또는 플러그인을 통해 이루어지나요?
- 여러 LP 또는 집계기와 연결할 수 있나요?
- 기호는 어떻게 매핑되고 검증되나요?
- 위험한 다운타임 없이 구성 변경을 할 수 있나요?
실행
- 주문은 어떻게 전달되나요?
- 부분 채우기가 지원되나요?
- 거절은 어떻게 처리되고 보고되나요?
- 다른 클라이언트 그룹이 서로 다른 라우팅 규칙을 가질 수 있나요?
- 브로커가 기호별 또는 그룹별 마크업을 설정할 수 있나요?
- 빠른 시장이나 누락된 견적이 발생하면 어떻게 됩니까?
모니터링
- 견적, 체결, 거부, 지연 및 LP 상태에 대한 실시간 대시보드가 있나요?
- 팀이 기호, LP, 계정 그룹 및 클라이언트별로 실행을 필터링할 수 있나요?
- 견적 간격, 높은 거부율 또는 비정상적인 슬리피지에 대한 알림이 제공되나요?
- 로그는 지원 및 컴플라이언스 검토를 위해 내보낼 수 있습니까?
위험 및 운영
- 다리에서 A-book, B-book 및 하이브리드 라우팅을 지원할 수 있나요?
- 노출 임계값이 헤지 주문을 유발할 수 있나요?
- 독성 또는 고주파 흐름을 다르게 경로 지정할 수 있나요?
- 누가 라우팅 규칙을 변경할 수 있으며, 모든 변경 사항이 기록되나요?
- 시스템이 전체 재구성 없이 성장을 지원할 수 있나요?
지원 및 소유권
- 누가 실행 사건을 조사합니까?
- 생산 문제에 대한 응답 시간은 얼마입니까?
- 24/5 또는 24/7 지원이 있나요?
- 업그레이드는 어떻게 테스트되나요?
- 브로커가 나중에 LP 또는 플랫폼을 변경하면 어떻게 되나요?
답변이 판매 자료보다 더 중요합니다. 좋은 브리지 제공자는 “깊은 유동성”과 “낮은 지연 시간”뿐만 아니라 거부, 엣지 케이스 및 로그에 대해 이야기하는 데 편안해야 합니다.
출시 후 메트릭 브로커가 주목해야 할 사항
다리가 활성화되면 매일 소수의 숫자를 추적하세요.
| 지표 | 중요성 |
|---|---|
| 호가 가용성 | 가격이 고객이 거래하기에 충분히 안정적인지 보여줌 |
| 평균 및 백분위 실행 시간 | 평균은 이상치를 숨기고; 백분위는 고통스러운 사례를 보여줌 |
| 체결 비율 | 주문이 실제로 실행되는지, 단순히 전송되는지를 보여줌 |
| 기호 및 LP별 거부율 | 고객이 불만을 제기하기 전에 약한 경로를 식별하는 데 도움을 줌 |
| 슬리피지 분포 | 시장 상황에 따라 실행이 공정하고 예측 가능한지를 보여줌 |
| 세션별 스프레드 | 롤오버, 뉴스 또는 유동성이 낮은 상황에서 나쁜 가격을 감지하는 데 도움을 줌 |
| 기호 및 그룹별 노출 | 헤지 규칙이 브로커의 위험 모델과 일치하는지를 보여줌 |
| 보고서 불일치 | 플랫폼, 브릿지, LP 및 백오피스 수치가 일치하지 않는 위치를 보여줌 |
월간 보고서를 기다리지 마세요. 인수활동이 활발할 때 실행 문제는 빠르게 복합적으로 발생합니다.
다리의 소유가 필요하신가요?
항상 그렇지는 않습니다.
간편한 출시를 위해, 내장된 유동성 연결 기능을 갖춘 화이트 라벨 또는 턴키 공급자를 사용하는 것이 별도의 브리지 계약을 관리하는 것보다 더 실용적일 수 있습니다. 이는 공급업체 조정을 줄이고 지원 소유권을 명확하게 만듭니다.
브리지 스택의 더 많은 부분을 소유하는 것은 다음과 같은 경우에 의미가 있습니다:
- 브로커는 여러 유동성 관계를 가지고 있습니다.
- 중개인은 라우팅 및 헤징에 대한 더 깊은 제어를 원합니다.
- 중개인은 경험이 풍부한 거래 또는 리스크 팀을 보유하고 있습니다.
- 중개인은 플랫폼을 이전하거나 독점 인프라를 추가할 계획입니다.
- 실행 품질은 핵심 경쟁 우위입니다.
많은 신규 중개인에게 더 안전한 방법은 관리된 설정으로 시작하여 실제 유동성이 어디에서 오는지를 배우고, 비즈니스가 충분한 거래량과 팀 용량을 갖추었을 때만 복잡성을 추가하는 것입니다.
