Стандартное виденье комиссии: количество $ за 1 мио проторгованного объема, также заданного в USD (например, $50 за 1 мио USD (round trip)).
Иное: количество процентов от изменения цены ФИ (например, 0.005% - комиссия равна профиту ФИ от изменения его цены на 0.005%).

Оба варианта равнозначны и вычисляются так (на примере):

Code: Select all

Commission = MajorPrice * (50 / 10^6) * Lots * ContractSize = SymbolPrice * 0.005% * Lots * TickValue / Point.

//MQL4:
CommissionPips = CommissionUSD * GetMajorAsk(Symb) * MarketInfo(Symb, MODE_LOTSIZE) / (MarketInfo(Symb, MODE_TICKVALUE) * 100000); // комиссия в пипсах, GetMajorAsk("CHFJPY") = CHFUSD_Ask
CommissionPips = CommissionUSD * MarketInfo(Symb, MODE_ASK)  / (MarketInfo(Symb, MODE_POINT) * 100000);                            // комиссия в пипсах


Следствием второй формулировки является утверждение: чтобы отбить комиссию (безубыток) нужно иметь один и тот же (верно для любого ФИ) относительный (по цене) профит.

В данном случае не учитывается работа аггрегатора (вне MT4) ~ 100ms. Итого среднее время постановки/удаления ордера ~ 350мс, минимальное ~ 200мс.

Очень грубо на пальцах:

Помимо маркет-мейкерских ценозадающих алгоритмов связанных между собой почти нулевым latency (крупные банки), на ценообразование влияют и другие участники рынка: аггрегаторы, хэдж-фонды, инвест-банки,..., физ. лица. Каждый из них может выставить лимитные заявки в стакан, которые тем или иным участникам рынка будут видны. Речь идет о spot-FOREX - децентрализованном рынке.

Изначально аггрегаторы создавались "под себя" с целью централизации spot-FOREX для отлова арбитража. Затем они стали использоваться и для других торговых стратегий. Самые известные аггрегаторские технологии - CURRENEX и Integral. Есть и другие, но они в своем маркетинг-продвижении не достигли высот вышеупомянутых.

Любой грамотный участник рынка сильно желает объединения как можно большего количества участников - это дает серьезные ценовые преимущества (вплоть опять же до арбитража). Особенно лакомой идеей является объединение рарозненной институциональной ликвидности с сильно разобщенной ретэйл-ликвидностью.

Аггрегаторы работают через три схемы: прайм, "траяна" и независимо. Первые две схемы необходимы для нивелирования перекосов позиций во время торговли в аггрегаторе. Третья схема позволяет также автоматически работать с перекосами, но при этом не пользоваться сторонними услугами, которые стоят немалых доп. комиссий.

Написание своего аггрегатора - задача не из простых. Но произвести различно рода анализы преимуществ аггрегации довольно просто. Ниже представлена такая попытка.

Изучение поведения каждого ФИ, сравнительный анализ различных фидов, особенности ценообразования - осознанный подход к рынку и торговле в целом.

Для начала аггрегируем прямо на MT4 несколько довольно неплохих ECN/STP и STP-фидов: ATC (FXCM), Pepperstone-RAZOR, Pepperstone-EDGE, RVD-Integral, RVD-Currenex и FXOPEN ECN (latency у всех примерно одинаковый).
Вот так это выгдядит:


Далее собираем различного рода статистику. В приложенном файле можно найти в качестве примера два (LP и символ) HTML-отчета и файлы данных (за 11.07.2012 - среда) с Mathcad-файлами визуализации, из которых одним движением создаются любые интересуемые подобные HTML-отчеты по каждому фиду и символу.

Постарался дать емкие описания в отчетах, поэтому привожу только несколько выборочных графиков различных характеристик.



Одно из важных исследований - сравнение фидов. Его оценка по спредам - классическая и недалекая (от трейдинга). Есть другие методики, самая верная из которых - оценка влияния каждого фида (при добавлении его в аггрегацию) на максимальную потенциальную прибыльность ФИ (в фиде могут быть фэйковые цены, по которым не будет исполнения, но учесть данное обстоятельство не представляется возможным).


Файл: Data+Analyse.

P.S. Появление цены на определенном ценовом уровне - вероятностное событие.

А в чем идея ? Покупать у одного брокера с одновременной продажей у другого, и этим ограничится, или есть еще какой-то смысл ? Что означает "LP" ?

Представлены конкретные характиристики сравнения разных фидов и особенностей каждого ФИ (Mathcad-файл надо было смотреть, который уже удалили с обменника).
LP - Liquidity Provider.

Реквоты в состоянии внести столь существенную разницу в результатах стратегии на реале и тестере (по тем же историческим данным), что становится большой проблемой адекватная настройка и оценка стратегии на истории.

Есть несколько путей решения такой проблемы:
1. Внести случайную составляющую по реквотам в тестере.
2. Создать фильтр истории, который бы позволил сделать историю наименее реквотной.

Первый вариант на самом деле плох, т.к. анализ статистики реквотов показывает, что они не носят случайный характер. Такой подход сильно исказит правильное представление о торговой стратегии.

Второй подход значительно разумнее. Причины реквот, как правило, Fake-Price, малый объем и высокий latency (LP). На данный момент решение пока такое:
1. Фильтруем каждый (от разных LP) тиковый поток по длительности тика и объему.
2. Аггрегируем все отфильтрованные тиковые потоки в одну, как следствие, наименее реквотную историю.

Огромное значение имеет правильная статистика проскальзываний и реджектов.

Проскальзывания:
Stop-приказы (включая StopOut) исполняются, очевидно, в основном с отрицательным проскальзыванием: (месячная статистика)


Limit-приказы, очевидно, исполняются с положительным проскальзыванием. И может создаться ошибочное представление о замечательности их использования, если вы будете учитывать статистику проскальзываний без учета реджектов.

В статистику проскальзываний лимитников следует добавить гипотетические отрицательные проскальзывания лимитников: если был реджект, считать ценой исполнения следующую за лучшей в стакане (MarketDepth). Такая методика позволяет оценить реальную заслугу положительных проскальзываний и дает возможность выработать порог выставления лимитников по цене ХУЖЕ текущей, чтобы результаты тестера приближались к реалу.

Entry-приказы (лимитники по цене хуже текущей): (недельная статистика)


Для всех видов приказов для правильной оценки проскальзываний нужно учитывать не только зависимость проскальзывания от количества ордеров (Orders count), но и от их объема.

Реджекты:
В статистике реджектов необходимо обязательно иметь данные по среднему времени продолжительности цены, по которой произошел реджект. Эти данные позволяют адекватно настраивать фильтр истории, о котором идет речь в посте выше.

P.S. Конечно, желательно по каждому символу иметь отдельную статистику. А также строить 3D-диаграммы, где доп. ось - время суток. Однако, это представляется крайне проблемным желанием на практике, т.к. при реализации подобного каждому столбцу в диаграмме будет соответствовать очень малое количество ордеров. А это значит, что стат. значимость такой диаграммы будет стремиться к нулю. Поэтому подобное реализуется только при хотя бы десятках тысяч ордеров.

Закономерности:
Профитная ТС использует закономерности и проторговывает их. Но нужно ли учитывать результаты торговли ТС там, где используемых закономерностей точно нет? Для большинства стратегий закономерности разрушаются при выходе новостей.

Оптимизация входных параметров ТС призвана к более четкой настройки на искомые закономерности в прошлом, с надеждой их сохранения в будущем. Очевидно, если исключить из истории места, где точно нет закономерностей (которые ищутся/настраиваются), то можно получить более адекватные результаты при оптимизации.

По этой причине перед оптимизацией для большинства ТС огромное значение имеют следующие шаги:
- выявить на истории участки, где точно нет желанных закономерностей. Самое простое - новости. Их определить даже автоматически довольно просто - через анализ исходного цВР.
- заложить в ТС закрытие всех поз перед найденными участками, бездействие на них и некоторое время (может быть входным параметром) после.

Критерии оптимизации:
Основаная часть критериев оптимизации - "средняя температура по больнице". Очень важна оценка в каждом одиночном прогоне ТС динамики изменения критерия. Поэтому доверительные интервалы критериев имеют особую значимость. Доверительный интервал можно вычислять по классике - СКО.

В приложении MT4-скрипт, вычисляющий проторгованный оборот.

Работает также и для кривосчитающих (TrueCommission = FALSE) комиссию брокеров.

В приложении MT4-советник, который собирает (дописывает в файл) статистику реджектов. Реджекты описываются строчкой следующего вида (на примере):

Code: Select all

2012.09.14 21:21:15 3296(2)ms. 1898804512 BuyLimit = 1.31062 EURUSD Ticks = 2 ShiftAvg = 1.50 ShiftByTime = 0.33 VolumeByTime = 0.20 PriceByTime = 1.310623 FillTime = 21:21:15


- Время (торгового сервера) окончания соответствующего режджекта.
- Длительность реджекта характеризуемого по ID лимитного приказа. В скобках - номер реджекта для данного ID.
- ID лимитного приказа.
- тип лимитного приказа (Limit - лимитный отложенный ордер, TP - TakeProfit открытой позиции).
- ценовой уровень лимитного приказа на момент окончания реджекта.
- Имя символа.
- Ticks - количество тиков (изменений соответствующей лимитному приказу цены) во время реджекта.
- ShiftAvg - среднее (в пипсах) ценовое превосходство тика над выставленным уровнем лимитного приказа.
- ShiftByTime - средневзвешенное (в пипсах) по времени (длительность реджекта) ценовое превосходство тика над выставленным уровнем лимитного приказа.
- VolumeByTime - средневзвешенный (в лотах) по времени (длительность реджекта) объем лимитного приказа.
- PriceByTime - средневзвешенный по времени (длительность реджекта) ценовой уровень лимитного приказа.
- FillTime - время (торгового сервера) полного исполнения лимитного приказа. Выводится не всегда, и нужно для сравнения со временем реджекта.

Советник запускается один раз в MT4-терминале (на любом символе). Желательно на VPS. По собранным данным можно оценить качество исполнения брокером лимитных приказов, особенности наступления реджектов и выявить явно технические проблемы на стороне брокера.

Данные по отлично исполненным без реджектов лимитным приказам не собираются.

P.S. Неравенство значения PriceByTime и ценового уровня лимитного приказа на момент окончания реджекта обозначает отсутствие блокировки модификации лимитного приказа на момент его акцептирования - техническая ошибка брокера.