한 프롭 회사 챌린지 엔진은 평가 계좌가 활성화되었는지, 합격했는지 또는 위반되었는지를 결정하는 소프트웨어입니다.
거래, 계좌 잔액, 미실현 손익, 수수료 및 시간을 읽습니다. 이 계좌 상태를 프로그램 규칙과 비교합니다. 한계가 초과되면 엔진은 새로운 주문을 차단하거나, 포지션을 마감하거나, 계좌를 다른 단계로 이동시키거나, 지급 검토로 보낼 수 있습니다.
두 사람이 같은 규칙을 다르게 계산할 때까지는 간단하게 들린다.
$100,000 계좌를 고려해 보세요. 5% 일일 손실 한도가 있습니다. 바닥이 하루 종일 $95,000에 있나요? 거래자가 $2,000를 만들면 움직이나요? 미결제 손실도 포함되나요? 어떤 시간대가 하루를 끝내나요? 두 가격 업데이트 사이에 포지션이 한도를 초과하면 어떻게 되나요?
퍼센트는 쉬운 부분입니다. 정의, 타이밍 및 증거가 도전 엔진을 신뢰할 수 있게 만드는 요소입니다.
| 구성요소 | 역할 |
|---|---|
| 거래 플랫폼 | 주문을 수락하고 포지션, 채우기 및 계좌 가치를 기록합니다 |
| 챌린지 엔진 | 평가 규칙을 적용하고 계좌 상태를 변경합니다 |
| 트레이더 대시보드 | 진행 상황, 남은 손실 여유 및 규칙 기록을 보여줍니다 |
| CRM 및 백오피스 | 고객, 계좌 생애 주기, 리뷰 및 커뮤니케이션을 관리합니다 |
| 지급 워크플로우 | 자격을 확인하고, 분배를 계산하며, 지급 상태를 기록합니다 |
프롭 회사 챌린지 엔진이 작동하는 방식
저는 엔진을 메모리가 있는 이벤트 프로세서로 생각합니다.
모든 관련 이벤트는 순차적으로 발생합니다: 채우기, 가격 변경, 수수료, 스왑, 일일 초기화 또는 수동 잔액 수정. 엔진은 계좌 상태를 재구성하고 규칙을 평가하며 결정을 감사 로그에 기록합니다.
From trade event to account decision
The engine combines platform events with the active rule version. Each decision produces an account action and an audit record.
Account state + rule evaluator
Rebuild the account, then run every active rule against the same state.
Event ID, account snapshot, threshold, rule version, decision, action and timestamp.
순서는 중요합니다. 늦은 채우기는 잘못된 노출을 초래할 수 있습니다. 중복된 채우기는 같은 손실을 두 번 계산할 수 있습니다. 다른 시간대는 유효한 일일 리셋을 위반처럼 보이게 만들 수 있습니다.
신뢰할 수 있는 엔진은 따라서 네 가지가 필요합니다:
- 정규화된 이벤트. 기호, 타임스탬프, 수수료 및 계정 식별자는 하나의 일관된 형식을 사용해야 합니다.
- 권위 있는 계좌 상태. 잔액, 자본, 미개설 포지션, 최고 기록 및 일일 기준은 정의된 출처에서 나와야 합니다.
- 결정론적 규칙. 동일한 사건 이력은 항상 동일한 결과를 생성해야 합니다.
- 감사 추적. 회사는 어떤 사건이 통과 또는 위반을 촉발했는지, 그리고 어떤 규칙 버전이 활성화되었는지를 보여줄 수 있어야 합니다.
그러한 기초가 없는 대시보드는 경고를 표시할 수 있지만, 숫자가 어떻게 도출되었는지를 신뢰성 있게 설명할 수는 없습니다.
엔진이 계산해야 하는 규칙
대부분의 평가 프로그램은 익숙한 레이블을 사용합니다. 각 레이블 아래의 계산은 여전히 다를 수 있습니다.
수익 목표
이익 목표는 단계를 완료하는 데 필요한 결과를 정의합니다. 기본 버전에서는 $100,000에서 시작하는 계좌로 $108,000에 도달해야 할 수 있습니다.
엔진은 여전히 여러 질문에 대한 답이 필요합니다:
- 대상이 균형에 기반한 것인가요, 아니면 주식에 기반한 것인가요?
- 모든 포지션이 단계가 진행되기 전에 종료되어야 합니까?
- 수수료와 스왑이 포함되어 있습니까?
- 최소 거래 일수가 있나요?
- 하루에 많은 일이 목표에 도달한 후에도 일관성 규칙을 위반할 수 있나요?
저는 모든 리스크 규칙이 확인된 후에만 로직을 실행하는 것이 좋습니다. 트레이더는 자산이 손실 한도를 초과하는 동일한 가격 업데이트에서 목표에 도달했다고 해서 패스해서는 안 됩니다.
최대 일일 손실
일일 손실은 일반적으로 타이밍 오류에 가장 노출된 규칙입니다.
허용되는 일일 손실이 $5,000이라고 가정해 보겠습니다. 간단한 구현은 다음과 같습니다:
일일 바닥 = 시작 시 기준선 - $5,000
남은 방 = 현재 자본 - 일일 바닥
프로그램은 대신 시작 자본, 잔액과 자본 중 더 높은 값 또는 초기 계좌 크기의 고정 비율을 사용할 수 있습니다. 여기에는 미실현 손익, 수수료, 스왑 및 배당금이 포함될 수 있습니다. 플랫폼 시간대에서 리셋될 수 있으며, 트레이더의 지역 시간대에서는 아닐 수 있습니다.
공적인 규칙은 정확한 기준선과 공제를 설명해야 합니다. 엔진은 매 리셋 시 이를 저장해야 합니다.
최대 손실 및 드로우다운
A 정적 최대 손실은 고정된 바닥을 유지합니다. $100,000의 시작 계좌와 $10,000의 한도가 있을 때, 바닥은 $90,000로 유지됩니다.
A 추적 손실은 계좌가 새로운 최고치에 도달할 때 바닥을 올립니다:
추적 바닥 = 최고 수위 - 인출 허용량
최고 수위가 $106,000에 도달하고 수당이 $10,000이면, 바닥은 $96,000이 됩니다.
프로그램은 새로운 최고 수위를 생성하는 요소를 명시해야 합니다:
- 일간 주식;
- 일일 자산;
- 닫힌 잔액;
- 일일 마감 잔액.
바닥이 후행을 유지하는지, 초기 잔액에서 멈추는지 또는 다른 임계값에서 잠기는지를 명시해야 합니다. “10% 후행 손실”은 이러한 세부 사항 없이 불완전합니다.
거래 일수와 일관성
거래일은 하나의 문서화된 정의를 가져야 합니다. 포지션을 열고, 닫고, 야간 거래를 유지하는 것은 반드시 같은 방식으로 계산되지 않습니다.
일관성 규칙은 동일한 정밀도가 필요합니다. 만약 최고의 날이 총 이익의 40%를 초과할 수 없다면, 엔진은 테스트가 도전 중, 통과 순간, 또는 지불 요청 시에만 적용되는지를 알아야 합니다.
예를 들어, 트레이더가 총 $10,000의 이익을 가지고 있고 가장 좋은 날에 $4,800을 벌었습니다:
$4,800 / $10,000 = 48%
계정이 이익 목표를 초과할 수 있지만 여전히 40% 일관성 테스트에 실패할 수 있습니다. 프로그램에 따라 거래자는 가장 좋은 날의 일부를 잃는 것보다 다른 날에 더 많은 수익을 올려야 할 수도 있습니다.
거래 제한
포지션 크기, 금융 상품, 보유 기간, 뉴스 및 자동화 규칙은 구조화된 달력, 금융 상품 매핑 및 주문 데이터가 필요합니다. 조건의 문장이 자체적으로 주문을 중단할 수는 없습니다.
하나의 계정, 세 가지 다른 손실 한도
이 설명적인 계정을 사용하세요:
- 초기 잔고:
$100,000; - 현재 잔액:
$102,000; - 일 시작 시 잔액:
$102,000; - 기록된 최고 자본:
$106,000; - 현재 자산:
$97,200; - 일일 손실 한도:
$5,000; - 총 손실 충당금:
$10,000.
Which loss rule stops the account first?
The same $100,000 account can be safe or breached depending on current equity and the recorded high-water mark.
Daily loss
Start-of-day balance – $5,000
Static maximum loss
Initial balance – $10,000
Trailing drawdown
High-water mark – $10,000
Daily loss is the closest limit, with `$200` of room left.
고정 일일 기준선 아래에서, 일일 바닥은 $97,000입니다. 현재 자본은 위반 전에 단지 $200만 남아 있습니다.
정적 총 손실 하한은 $90,000로 유지되며, $7,200가 남아 있습니다. 그 규칙은 발동될 가능성이 없습니다.
하한선은 $96,000으로, $106,000의 최고 수치에 기반합니다. $1,200이 남습니다.
일일 규칙이 승리하는 이유는 남은 여유 공간이 가장 작기 때문입니다. 또 다른 $250의 부유 손실은 자본을 $96,950로 낮추고 계좌를 침해할 수 있지만, 여전히 정적 최대 손실 바닥보다 훨씬 위에 있습니다.
이것이 제가 헤드라인 백분율만으로 평가를 판단하지 않는 이유입니다. 활성 제약은 하루 동안 변할 수 있으며, 이는 거래자가 예상하는 규칙이 아닐 수 있습니다.
한계를 넘었을 때 일어나는 일
위반은 대시보드에서 색상 변경이 아니라 워크플로우입니다.
회사는 어떤 행동이 발생하고 어떤 순서로 진행될지를 결정해야 합니다:
- 계좌 상태 및 시장 이벤트를 기록하십시오.
- 새 주문을 거부합니다.
- 작업 주문 취소.
- 프로그램에서 요구하는 경우 열린 포지션을 닫습니다.
- 계정을 잠그거나 검토를 위해 표시하십시오.
- 트레이더와 운영 팀에 알리기.
- 가능한 분쟁을 대비하여 계산 및 규칙 버전을 보존하십시오.
두 가지 일반적인 실패 모드가 있습니다.
지연된 집행으로 인해 대시보드는 플랫폼이 여전히 주문을 수락하는 동안 위반을 감지합니다. 중복 집행의 경우, 재시도가 포지션을 두 번 종료하거나 상태 변경을 반복합니다. 동일한 위반 이벤트를 재생하는 것은 그 재정적 영향을 반복해서는 안 됩니다.
경고는 하드 리미트 이전에 도움이 될 수 있습니다. 예를 들어, 시스템은 거래자에게 일일 손실 용량의 70% 및 90%에서 알림을 보낼 수 있습니다. 그러나 경고 임계값은 실제 위반 규칙과 별도로 유지되어야 합니다.
자체 테스트를 받아야 할 엣지 케이스
대부분의 결함은 일반적인 폐쇄 거래 중이 아니라 경계에서 발생합니다.
| 상황 | 예상 행동 |
|---|---|
| 열린 P&L로 일일 재설정 | 다음 이벤트를 처리하기 전에 프로그램 시간대에서 정의된 기준선을 스냅샷으로 기록합니다. |
| 제한을 통한 가격 격차 | 첫 번째 사용 가능한 가격과 결과적인 자본을 기록하며, 임계점에서 허구의 거래는 기록하지 않습니다. |
| 부분 체결 및 연체 수수료 | 각 이벤트를 한 번 적용하고 수수료나 스왑이 도착한 후 재계산합니다. |
| 피드 중단 | 재연결 후 이벤트 순서를 보존하고 불완전한 데이터로 계정을 전달하는 것을 피합니다. |
| 수동 수정 | 저자, 이유, 타임스탬프 및 원래 결정에 대한 링크를 저장합니다. |
일광 절약 시간 변경, 유지보수 및 중복된 콜백은 동일한 테스트 패키지에 포함되어야 합니다. 재정렬된 이벤트는 올바른 규칙이 잘못된 결정을 내리게 만들 수 있습니다.
도전을 통과하는 것은 상태 전환입니다
수익 목표만으로는 계정을 승격시켜서는 안 됩니다.
변경하기 전에 active를 passed로, 확인하세요:
- 엄격한 규칙이 위반되지 않음;
- 대상은 요구되는 잔액 또는 자본 측정을 사용합니다;
- 모든 필수 거래일이 완료되었습니다;
- 일관성 조건이 만족됩니다;
- 프로그램에서 요구하는 경우 포지션이 종료됩니다;
- 계정에 해결되지 않은 데이터나 컴플라이언스 보류가 없습니다.
재시도는 다음 계정을 두 번 생성하거나 잘못된 규칙 템플릿을 연결해서는 안 됩니다.
무대 이력을 계속 표시하십시오: 계정 생성, 단계 통과, 자금이 지원된 계정 생성, 지급 자격, 지급 요청 및 지급 완료. 그 타임라인은 지원팀에게 계정이 어디에 막혀 있는지를 알려줍니다.
지급 작업 흐름이 작동하는 방식
도전 엔진은 자격을 설정합니다. 지급 워크플로우는 돈과 그에 대한 제어를 처리합니다.
실용적인 순서는:
- 요청된 성과 기간에 대한 적격성 스냅샷을 동결합니다.
- 필요한 경우 계좌에 개설된 포지션이 없는지 확인하십시오.
- 수수료 및 이전 지급 후 자격이 있는 이익을 재계산합니다.
- 거래자의 이익 분배를 적용합니다.
- 신원, 계정 소유권 및 남용 검사를 실행합니다.
- 요청을 승인하거나 거부하거나 수동 검토를 위해 전송하십시오.
- 지불 지침을 작성하십시오.
- 제공자 상태, 수수료 및 정산 참조를 기록하십시오.
- 프로그램 규칙에 따라 계정을 조정하세요.
적격 이익이 $6,000이고 거래자 몫이 80%인 경우, 총 지급액은:
$6,000 x 80% = $4,800
시스템은 어떤 성과 창이 $6,000을 생성했는지, 이전 지급금이 공제되었는지 및 남은 $1,200에 대한 상황을 보여줘야 합니다.
지불 상태도 조정이 필요합니다. 프로펀드 백 오피스에서 "승인됨"은 지불 제공자가 "지불함"을 의미하지 않거나 거래자가 "수령함"을 의미하지 않습니다.
위험 규칙과 남용 탐지는 서로 다른 시스템입니다
일일 손실 및 감소는 결정적입니다. 계좌는 정의된 임계값을 초과했거나 초과하지 않았습니다.
학대 감지는 일반적으로 확률적입니다. 공유 장치, 일치하는 주문, 비정상적인 지연, 조정된 계정 또는 신원 충돌이 신호를 생성할 수 있습니다. 신호는 그 자체로 증거가 아닙니다.
나는 두 가지 결정 경로를 분리할 것이다:
- 규칙 엔진: 게시된 프로그램 조건을 계산합니다.
- 남용 통제: 행동 점수 매기기 및 증거 수집.
- 수동 검토: 애매한 사례를 처리하고 최종 사유를 기록합니다.
자동 제어는 명확하게 정의된 작업을 차단할 수 있습니다. 약한 신호는 설명되지 않은 지급 거부가 되어서는 안 됩니다. 검토자는 점수뿐만 아니라 기본 주문, 타임스탬프, 장치 및 규칙 참조가 필요합니다.
도전 과제를 시작하기 전에 테스트할 것
나는 전체 이벤트 시퀀스를 재생하고 각 결과를 수작업 계산과 대조하여 확인할 것입니다.
테스트 팩에는 다음이 포함되어야 합니다:
- 보통 패스;
- 유동 손익으로 인한 일일 손실;
- 정적 및 후행 드로우다운 위반;
- 일중 트레일링 바닥을 움직이는 주식 최고치;
- 열린 포지션으로 매일 리셋;
- 한계까지의 가격 차이;
- 체결 후 게시된 수수료 및 스왑;
- 부분 채우기 및 거부된 주문;
- 중복되고 순서가 뒤바뀐 이벤트;
- 시장 데이터 중단 및 재연결;
- 동시 목표 및 손실 한도 이벤트;
- 이전의 하나 이상의 지급 후 지급;
- 수용된 항소 및 수동 계정 수정.
모든 경우에 대해 플랫폼 이벤트, 엔진 계산, 트레이더 메시지 및 백오피스 기록을 비교하십시오. 네 가지 모두 동일한 결과를 설명해야 합니다. 결정 지연 시간, 논란이 있는 위반, 성공적인 항소, 지급 시간 및 중복 작업을 추적하십시오.
프롭펌이 구성할 수 있어야 하는 것
규칙 목록은 예측 가능한 행동과 팀이 재현할 수 있는 계산보다 중요하지 않습니다.
챌린지 엔진을 선택하기 전에, 해당 회사가 다음을 구성할 수 있는지 확인하세요:
- 단일 단계, 다단계 및 직접 접근 프로그램;
- 이익 목표 및 최소 거래 일수;
- 일일 손실 기준선, 리셋 시간 및 포함된 비용;
- 정적, 장 마감 시 또는 장중 후행 손실 및 잠금 동작;
- 악기, 시간, 뉴스 및 포지션 크기 제한;
- 경고, 심각한 위반 및 계정 조치;
- 통과, 승진 및 지급 워크플로우;
- 규칙 버전, 이벤트 로그 및 수동 검토 권한.
또한 규칙 변경이 활성 계정에 얼마나 빨리 도달하는지 테스트하십시오. 새로운 조건은 이미 진행 중인 평가의 계산을 조용히 변경해서는 안 됩니다.
그 통합은 중요합니다. 왜냐하면 챌린지 엔진은 독립적으로 작동할 수 없기 때문입니다. 깨끗한 플랫폼 데이터, 시행 가능한 계정 제어 및 재무가 조정할 수 있는 지급 기록이 필요합니다.
