Двигатель проп-фирмы — это программное обеспечение, которое определяет, активен ли оценочный счет, пройден ли он или нарушен.
Он читает сделки, баланс счета, открытую прибыль и убыток, сборы и время. Он сравнивает это состояние счета с правилами программы. Когда лимит превышен, движок может блокировать новые ордера, закрывать позиции, переводить счет на другой этап или отправлять его на проверку выплаты.
Это звучит просто, пока два человека рассчитывают одно и то же правило по-разному.
Рассмотрим счет на сумму $100,000 с дневным лимитом убытков 5%. Сидит ли пол ограничений на уровне $95,000 весь день? Двигается ли он после того, как трейдер зарабатывает $2,000? Учитываются ли открытые убытки? В каком часовом поясе заканчивается день? Что происходит, если позиция пересекает лимит между двумя обновлениями цен?
Процент — это простая часть. Определение, время и доказательства — вот что делает движок проверки надежным.
| Компонент | Его задача |
|---|---|
| Торговая платформа | Принимает заказы и регистрирует позиции, заполняет и учитывает значения счетов |
| Движок вызовов | Применяет правила оценки и изменяет статус счета |
| Панель трейдера | Показывает прогресс, оставшуюся возможность убытка и историю правил |
| CRM и бэк-офис | Управляет клиентом, жизненным циклом счета, обзорами и коммуникацией |
| Процесс выплат | Проверяет право на выплату, рассчитывает долю и записывает статус платежа |
Как работает система испытаний проп-фирм
Я думаю о движке как о процессоре событий с памятью.
Каждое соответствующее событие входит в последовательность: заполнение, изменение цены, комиссия, своп, ежедневный сброс или ручная коррекция баланса. Двигатель восстанавливает состояние счета, оценивает правила и записывает решение в журнал аудита.
От торгового события к решению по счету
Движок сочетает события платформы с активной версией правила. Каждое решение приводит к действию по счету и записи аудита.
Состояние счета + оценщик правил
Восстановите счет, затем примените каждое активное правило к тому же состоянию.
Идентификатор события, снимок аккаунта, порог, версия правила, решение, действие и отметка времени.
Последовательность имеет значение. Поздняя заливка может привести к неправильной экспозиции. Дублированная заливка может учесть одну и ту же потерю дважды. Разные временные зоны могут сделать действительную ежедневную сброс выглядящей как нарушение.
Надежный двигатель, следовательно, нуждается в четырех вещах:
- Нормализованные события. Символы, временные метки, сборы и идентификаторы аккаунтов должны использовать один последовательный формат.
- Авторитетный отчет о состоянии счета. Баланс, собственный капитал, открытые позиции, максимальные значения и ежедневная база должны поступать из определенных источников.
- Детерминированные правила. Одна и та же история событий всегда должна приводить к одному и тому же результату.
- Аудиторский след. Фирма должна иметь возможность показать, какое событие вызвало пропуск или нарушение, и какая версия правила была активна.
Панель управления без этих основ может показывать предупреждение, но она не может надежно объяснить, как было получено это число.
Правила, которые двигатель должен учитывать при расчете
Большинство программ оценки используют знакомые метки. Однако расчеты под каждой меткой могут различаться.
Целевая прибыль
Цель по прибыли определяет результат, необходимый для завершения этапа. Базовая версия может требовать счет, который начинается с $100,000, чтобы достичь $108,000.
Двигателю все еще нужны ответы на несколько вопросов:
- Цель основана на балансе или капитале?
- Должны ли все позиции быть закрыты перед тем, как этап пройдет?
- Включены ли комиссии и свопы?
- Существует ли минимальное количество торговых дней?
- Может ли один большой день нарушить правило последовательности, даже после достижения цели?
Я предпочитаю, чтобы логика проходила только после того, как каждое правило риска было проверено. Трейдер не должен проходить, потому что капитал достиг цели на том же обновлении цены, которое нарушило лимит убытка.
Максимальный ежедневный убыток
Ежедневные потери, как правило, являются правилом, наиболее подверженным ошибкам времени.
Предположим, что разрешенная ежедневная потеря составляет $5,000. Простая реализация выглядит следующим образом:
Ежедневный минимум = Базовый уровень на начало дня - 5 000 долларов
Оставшаяся комната = Текущий капитал - Ежедневный уровень
Программа может вместо этого использовать начальный капитал, больший из баланса и капитала, или фиксированный процент от первоначального размера счета. Она может включать открытые прибыли и убытки, комиссии, свопы и дивиденды. Она может сбрасываться в часовом поясе платформы, а не в местном времени трейдера.
Общественное правило должно описывать точную базу и вычеты. Двигатель должен сохранять их на каждом сбросе.
Максимальные потери и просадки
Статический максимальный убыток устанавливает фиксированный уровень. С начальным счетом $100,000 и лимитом $10,000 уровень остается $90,000.
Технический трейлинг-стоп поднимает уровень поддержки, когда счет достигает нового максимума:
Текущий уровень = Высокая отметка - Допуск на снижение
Если уровень высоких вод достигает $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.
Какое правило убытка остановит счет первым?
Один и тот же счет в $100,000 может быть безопасным или нарушенным в зависимости от текущего капитала и зафиксированной максимальной отметки.
Ежедневные потери
Начальный баланс – 5,000 долларов
Статический максимальный убыток
Начальный баланс – $10,000
Трейлинг-дроунд
Высокая отметка – $10,000
Ежедневный убыток – это ближайший лимит, с оставшимися `$200` в запасе.
При фиксированном ежедневном базовом уровне, ежедневный минимум составляет $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.
Статус оплаты также требует сверки. "Одобрено" в бэк-офисе проп-фирмы не означает "оплачено" платежным провайдером или "получено" трейдером.
Правила риска и обнаружение злоупотреблений — это разные системы
Ежедневные убытки и просадки являются детерминированными. Счет либо пересек заданный порог, либо нет.
Обнаружение злоупотреблений обычно является вероятностным. Общие устройства, совпадающие заказы, необычная задержка, скоординированные аккаунты или конфликты идентичности могут создавать сигналы. Сигнал сам по себе не является доказательством.
Я бы оставил два пути принятия решений отдельными:
- Двигатель правил: вычисляет условия опубликованной программы.
- Контроль за злоупотреблениями: оценка поведения и сбор доказательств.
- Ручная проверка: обрабатывает неоднозначные случаи и фиксирует окончательную причину.
Автоматические системы контроля могут блокировать четко определенные действия. Слабый сигнал не должен становиться необъяснимым отказом в выплате. Рецензенты нуждаются в исходных заказах, временных метках, устройствах и ссылках на правила, а не только в оценке.
Что протестировать перед запуском вызова
Я бы воспроизвел полные последовательности событий и проверил каждый результат с помощью ручного расчета.
Тестовый пакет должен включать:
- обычный пропуск;
- ежедневные потери, вызванные плавающей P&L;
- статические и запаздывающие нарушения убытков;
- максимум акций, который перемещает внутридневной траловый пол;
- ежедневный сброс с открытыми позициями;
- разница в цене через предел;
- комиссии и свопы, опубликованные после выполнения;
- частичные исполнения и отклоненные заказы;
- дублированные и несогласованные события;
- прерывание рыночных данных и повторное подключение;
- одновременное событие целевого и предельного убытка;
- выплата после одной или нескольких предыдущих выплат;
- принятая апелляция и ручная корректировка счета.
В каждом случае сравните события платформы, расчеты двигателя, сообщения трейдера и записи бэк-офиса. Все четыре должны описывать один и тот же результат. Отслеживайте задержку принятия решений, спорные нарушения, успешные апелляции, время выплаты и дублирующие действия.
Что должна уметь настраивать проп-фирма
Список правил имеет меньшее значение, чем предсказуемое поведение и расчет, который команда может воспроизвести.
Перед выбором движка для задач проверьте, может ли компания настроить:
- одноступенчатые, многоступенчатые и программы прямого доступа;
- целевая прибыль и минимальное количество торговых дней;
- базовая линия ежедневных убытков, время сброса и включенные расходы;
- статическое, конечное или внутридневное следящее снижение и поведение блокировки;
- инструмент, время, новости и ограничения по размеру позиций;
- предупреждения, серьезные нарушения и действия с аккаунтом;
- передача, продвижение и выплата;
- версии правил, журналы событий и разрешения на ручной обзор.
Также проверьте, насколько быстро изменение правила достигает активных аккаунтов. Новые условия не должны тихо переписывать расчёт для оценки, уже находящейся в процессе.
Это интеграция важна, потому что движок задач не может работать в изоляции. Ему нужны чистые данные платформы, исполняемые контрольные счета и запись о выплатах, которую финансы могут согласовать.
