Instant vs Market изпълнение на сделки

[alphaomega]

И при двата метода за изпълнение на поръчките се предполагат следните две неща:
1. Брокера е честен спрямо клиентите си
2. Брокера наистина изнася нашата поръчка на пазара или в най-лошия случай в брокер от по-високо ниво (Introducing Broker)

Ако обаче това не е така, което е вярно в повечето случаи, то тогава и при двата метода за изпълнение на поръчки клиента е прецакан повече или по-малко съгласно честността или по-скоро наглоста на неговия брокер.

Следователно двете понятия за двата вида изпълнение на сделки са само теоретични понятия, които са много далеко от реалната практика. Какво в действителност се случва на практика може да се разбере само ако търговската стратегия се направи на робот, и след това в него се вгради милисекунден логер, който да записва какво точно се случва с изпълнението на поръчката милисекунда по милисекунда.

Аз мога да направя такъв логер който да проследява в детайли и да записва изпълнението на всяка една пазарна поръчка. Даже преди време мислех да правя такъв логер със същата идея да го вградя във всичките ми системи за да видя дали брокерите ми прилагат номера със асиметричния слипидж.
Даже го бях нахвърлял като идея какви опции да включва, но после нещо се захванах да реализирам други идеи и направо забравих за това. Сега ти като ме подсети и ще взема най после да го напиша този логер.

Основната идея е да се записват за всяка една поръчка следните неща:

1. Последна актуална цена непосредствено преди подаване на поръчката.
2. Цена на която е изпълнена поръчката.
3. Разликата между цената на подаване и цената на изпълнение (Слипидж).
4. Време за изпълнение на поръчката.

После вече от тези данни като се натрупа достатъчно информация (брой сделки) може да се извадят и средните стойности и да се направи статистика за:

1. Средно време за изпълнение.
2. Среден размер на положителния и отрицателния слипидж.
3. Процент на положителния слипидж.

И вече от това можем да си правим изводите със колко точно ни прецаква брокера (средна загуба на сделка) и също кои брокери ни прецакват най много.

[Mateev]

Написването на такъв един логер съвсем не е проста задача, и ти ще се убедиш в това, когато започнеш да го правиш Иначе ако беше нещо само с 10-20 реда код, досега отдавна да съм го направил. Да, ама възможните събития, които могат да се случат след подаването на поръчката, са много на брой. И всяко едно от тях трябва да се прихване, да се проанализира и да се изведе Output в текстови файл. Също така кода на един такъв логер трябва да може да работи както под МТ4, така и под МТ5, като трябва да се отчита разликата между възможностите на двете системи и между съобщенията за грешка, които могат да се генерират. Като цяло иска си код за всяка една възможна грешка, както и доста време за тестване, защото някои грешки е много трудно да бъдат изкуствено предизвикани. А те трябва да бъдат изтествани, защото все някога ще се случат, и ако кода не може да ги обработва по правилния начин, ще стане много кофти ситуация.

Приветствам те, ако решиш да се захванеш с тази задача, и после да публикуваш сорс-кода на твоето решение. Аз бих направил същото, но напоследък времето ми е заето с един или друг проблем във фирмите, които управлявам. Все пак те са 5-6 на брой и аз като Изпълнителен директор съм единственият човек, който има правото да взема окончателни решения при гасенето на един или друг пожар (проблеми в бизнеса). Та напоследък се появиха доста такива и аз от повече от месец не съм имал свободното време да напиша поне един програмен ред с код. Игра на случайности - понякога с месеци наред фирмите ми нямат нужда от мене и аз направо скучая пред компютъра, а друг път като започне някаква черна поредица, та не ми оставя капка спокойствие и свободно време по повече от месец. Сега съм в такъв черен период, и затова активността ми във форума е минимална.

Иначе да - логера трябва да записва три неща:
1. Какво е събитието, което се е случило
2. Време на това събитие с точност 1 милисекунда, а ако може - с точност 1 микросекунда
3. Последна цена, която е активна за това време на настъпване на събитието

Допълнителна екстра ще е ако се записва още информация по отношение на самата сделка - посока, размер, лотове, Magic, sl, tp, промяна (стара и нова стойност, разлика) както и ако се води статистическа информация за тези параметри, която информация да съдържа всички статистически параметри (count, sum1, sum2, sum3, sum4. first, last, min, max, average, 4 начални момента, 4 централни момента, както и всякакви следствия на тези моменти, като например мю, sigma, variance, dispersion, standard deviation, и любимия на мене и Минков доверителен интервал с неговите Standard Error, както и долна и горна граница). Специално за тези статистически изследвания мога да ти дам готов клас, от който можеш да си правиш колкото си искаш обекти за анализ на статистиката на един или друг параметър, стойностите на който се срещат многократно. Този клас е основополагащ - използвам го под път и над път и извличам от него всякаква полезна информация. Ще ти го дам и на тебе да го вложиш в логера. От това само можем да спечелим - аз, ти и всички останали.

[Zagorka]

И за какво е цялото това нещо, след като регулираните брокери вадят тази информация на показ? Просто ги попитайте за тази информация. Мисля, че законово са длъжни да я публикуват, става дума за слипиджа, времето за изпълнение на сделката и т.н. Има един кипърски брокер тук в България, който дори записва насрещната страна по сключената сделка.
А дори и да запишете в скрипта си последната цена на графиката, при пазарното изпълнение тя е в дата фийда, а не на графиката. И тъй като не съм програмист, нямам идея дали директно може да се изкара от ценовия поток последната цена.
Съвсем скоро един бг брокер при подадена от мен поръчка за покупка и последна цена, която виждам на графиката ми я изпълни с 9 пипса по-нагоре. Но и в онзи момент имаше голяма волатилност, а и знаете как е лятото с тази ниска ликвидност, един да влезе и цената отпрашва в същата или другата посока.

Забравих още една разлика да спомена, която е и най-важната. При instant лимитът на buy поръчка например е зададен на 1.2020 и пазарът отваря на 1.2030. Брокерът изпълнява на 1.2020, на цената, която е зададена, а не на първата пазарна възможна цена. Така може да си прибере 10 пипса за него.

В обратния случай, ако има стоп на 1.2020 при къса и пазарът отвори на 1.2010, ами сори, първата пазарна цена е 1.2010 и там ви се изпълнява стопа, което води до допълнителни загуби за клиента.
Така че и двата вида изпълнение имат както плюсове, тъй и минуси. От вас зависи каква стратегия ще изберете, за да сложите една вертикална чертичка на минуса, за да стане плюс.

[emoyambol]

В крайна сметка според мен най-важно е бързото изпълнение на поръчката. Да големия спред или слипидж не е приятен, но по-добре да влезеш на време, отколкото хич. Разбира се, понякога е добре, ако идеята ни не се реализира.

[Mateev]

И за какво е цялото това нещо, след като регулираните брокери вадят тази информация на показ? Просто ги попитайте за тази информация. Мисля, че законово са длъжни да я публикуват, става дума за слипиджа, времето за изпълнение на сделката и т.н. ......

Моите съболезнования, но явно живееш в дълбока самозаблуда. На това разчитат и брокерите - че повечето трейдери са като тебе и на практика не осъзнават какво точно се случва на милисекундно ниво.

В действителност точно там се случват събитията, посредством които брокерите обират клиентите си. Най-масовото е да се направи закъснение от определен брой милисекунди и в рамките на това закъснение да се натрупат няколко ценови тика, от които брокера да избере за клиента този, който му нанася най-голяма вреда. Това нещо се детектира само със софтуер.

Например закъснението, с което твоите интернет пакети пътуват до брокера и обратно е само 50 милисекунди, но отговора на твоите заявки за търговска операция винаги закъснява с 550 милисекунди. За ръчния трейдер това изглежда като моментално изпълнение, но в действителност брокера е настроил сървъра си да изчаква 500 милисекунди преди да ти върне потвърждение за отваряне/затваряне на позиция. През тези 500 милисекунди прелитат няколко тика и брокера подбира този от тях, който ще нанесе най-голяма вреда на клиента. Това му действие средностатистически създава допълнително ПМО на брокера с размер, по-голям от размера на спреда. Така брокера на практика се сдобива с удвояване че и с утрояване на спреда, но за ръчните трейдери това остава незабелязано.

В същото време това невинно на пръв поглед действие на брокера е в състояние да убие всяка една търговска стратегия, ПМО-то на която е по-малко от 3 пъти спреда. Търгуващите с роботи го виждат това нещо, защото на тестовете стратегията им продължава да е добра, а в същото време на търговския сървър тя се изхитрява да губи. Ръчните трейдери не го виждат този факт. Те така или иначе в повечето случаи играят случайно, и освен това нямат статистическо мислене, така че тези единични събития въобще не им правят впечатление. В действителност тези действия на брокера ускоряват фалита на ръчните трейдери, особенно на тези, които праскат големи лотове.

[Mateev]

На практика и при двата метода за изпълнение на поръчки брокера е в състояние да натресе на клиента допълнителен слипидж посредством даването на най-лошата възможна цена от този времеви прозорец, с който той закъснява сделките. А ако тази най-лоша цена не устройва брокера, той просто връща Requote и това може да го направи 1000 пъти подред. Комплекта от едно или повече Requote също създава за брокера допълнително ПМО, което за клиента изглежда като допълнителни разходи.

Всичко това няма как да бъде разбрано от ръчния трейдер. Самия Metatrader не логва коректно тези събития, пък и дори да ги логваше, никой ръчен трейдер не си прави труда да анализира тези логове. Иначе ако логовете ги имаше и трейдера ги анализираше, щеше бързо бързо да открие, че реалните разходи за брокера (спред + слипидж) средностатистически са много по-големи от това, което се делегира на WEB страницата на брокера.

Написването на такъв милисекунден логер е единственият възможен начин да се детектират скритите хватки на дадения брокер. И тъй като честността (наглостта) на различните брокери е различна, то тогава ние се нуждаем от инструмент за детектиране на тази честност (наглост). Такъв инструмент за детектиране се явява именно милисекундния логер, който следи потока от ценови тикове и как се наместват събитията около сделката в този поток. Има два момента от време:
1. Заявка за извършване на търговска операция
2. Потвърждение от брокера за това, че операцията е извършена.

Между тези два момента от време е имало както закъснение, така и няколко прелетели ценови тикове. Логера ще знае закъснението, ще знае и цените на тиковете, и ще може да провери по кой от всичките тикове се потвърждава сделката. И най-важното - логера ще е наясно с разхода за брокера, който ще е равен на средностатистическата разлика от цената по т.2 минус цената по т.1. Тази средностатистическа разлика при някои брокери може да е по-малко от 1 пип, а при други - цели 5-6 пипа.

[alphaomega]

На практика и при двата метода за изпълнение на поръчки брокера е в състояние да натресе на клиента допълнителен слипидж посредством даването на най-лошата възможна цена от този времеви прозорец, с който той закъснява сделките. А ако тази най-лоша цена не устройва брокера, той просто връща Requote и това може да го направи 1000 пъти подред. Комплекта от едно или повече Requote също създава за брокера допълнително ПМО, което за клиента изглежда като допълнителни разходи.

Всичко това няма как да бъде разбрано от ръчния трейдер. Самия Metatrader не логва коректно тези събития, пък и дори да ги логваше, никой ръчен трейдер не си прави труда да анализира тези логове. Иначе ако логовете ги имаше и трейдера ги анализираше, щеше бързо бързо да открие, че реалните разходи за брокера (спред + слипидж) средностатистически са много по-големи от това, което се делегира на WEB страницата на брокера.

Написването на такъв милисекунден логер е единственият възможен начин да се детектират скритите хватки на дадения брокер. И тъй като честността (наглостта) на различните брокери е различна, то тогава ние се нуждаем от инструмент за детектиране на тази честност (наглост). Такъв инструмент за детектиране се явява именно милисекундния логер, който следи потока от ценови тикове и как се наместват събитията около сделката в този поток. Има два момента от време:
1. Заявка за извършване на търговска операция
2. Потвърждение от брокера за това, че операцията е извършена.

Между тези два момента от време е имало както закъснение, така и няколко прелетели ценови тикове. Логера ще знае закъснението, ще знае и цените на тиковете, и ще може да провери по кой от всичките тикове се потвърждава сделката. И най-важното - логера ще е наясно с разхода за брокера, който ще е равен на средностатистическата разлика от цената по т.2 минус цената по т.1. Тази средностатистическа разлика при някои брокери може да е по-малко от 1 пип, а при други - цели 5-6 пипа.

Към момента моите изводи относно концепцията за логера са следните:

1. Смятам че засичането и логването на рекотиранията не е необходимо просто защото никой качествен брокер в днешно време не прилага рекотирания. Всички брокери които се рекламират като "NDD/ECN/DMA" просто изпълняват пазарните поръчки на първата налична цена (поне така твърдят те самите). Ако брокера ви прилага рекотиранията - сменете си брокера!

2. Ако дадена позиция е затворена в следствие на активиран прикачен Stop Loss или Take Profit в тези случаи не може да се засече времето за изпълнение защото тези събития се случват на сървъра на брокера.

3. Абсолютното време за изпълнение на поръчките е доста относително и зависи от много фактори. Разстояния между сървърите, скорост на връзките и др. Понякога може да има забавяне над средното но то да не е по вина на брокера. Общо взето е невъзможно да се докаже причината. Това което нас реално най много ни интересува не е времето а е разликата между сумарния положителен слипидж и сумарния отрицателен.

Сега написах малко код, първо за логване при отварянето на пазарни поръчки понеже това е по лесно, а после ще направя функция и за затварянето. Логера работи идеално. Записва всички изпълнени пазарни поръчки в реално време във CSV формат и във отделен файл за всеки брокер и номер на сметка.

От там вече просто си вадим данните в Excel и си ги анализираме както си искаме. Прецених че така е най добре и няма смисъл на този етап да се занимавам да правя специален интерфейс който да ги показва тези неща на графиката в MT4....

Ето първата бета версия какво записва:

Последните две колони в дясно показват това което ни интересува - за всяка поръчка дали e изпълнена със положителен или отрицателен слипидж.

[Mateev]

Концептуално е най-добре да се направи специален логващ експерт, който ще се занимава само с милисекундно логване и с нищо друго. Експерта ще ползва милисекунден таймер и веднъж на всяка една милисекунда ще проверява всички тикове по всички финансови инструменти (това вече съм го реализирал), както и всяка една промяна по всяка една позиция или отложен ордер (това тепърва трябва да го пиша). На базата на проверените тикове може да записва на диска тикова история (това вече е написано), а на базата на проверените тикети да записва всяка една промяна по тях.

Аз лично си го представям в паметта да се държи един масив от записи (records) с всички тикети - както исторически, така и активни към момента. Структурата на един запис ще включва всички полета, които поддържа MetaTrader, както и една камара допълнителни полета, които ще съхраняват липсващата в MetaTrader информация. Тази информация ще се набавя милисекунда по милисекунда и ще се ъпдейтва в съответното поле на съответния запис. Физическия запис на диск може да става периодично или само при затваряне на експерта. Периодичния запис е желателен, но самото бавене на диска за времето на записа може да предизвика пропускане на някоя важна милисекунда.

Допълнителните полета в един запис, които ги няма МетаТрадер, са приблизително следните:
1. Наш собствен тикет, който се присвоява на всяко едно желание за сделка. Тази сделка може дори да не се осъществи, но за нея трябва да остане запис в базата с данни.
2. Ако сделката се осъществи, започваме да работим с тикета на MetaTrader.
3. Желана цена, по която сме подали заявката за отваряне на позиция.
4. Време на подаване на заявката за отваряне на позиция.
5. Брой Requote, докато заявката за търговска операция най-после се изпълни.
6. Време на реалното отваряне на позицията.
7. Цена на реалното отваряне на позицията.
9. Open, High, Low, Close, Average и Count като цени и време на микробарчето, което се е образувало от прелетелите тикове докато чакаме отварянето на позицията.
10. Точки от 3 до 9 ги има като полета и за събитието "Затваряне на позиция"
11. Ако се изпълни събитието "Активиране на ордер" или "Активиране на стоплос или тейкпрофит", то тогава се записват:
-а. Време на активирането
-б. Желана цена съгласно ордера
-в. Реална цена на активирането от страна на сървъра
-г. Имало ли е такава цена в потока от котировки, или активирането е направено по "измислена" цена

Най-голямото прегрешение на един брокер е да активира/изпълни ордер или позиция по цена, която не е съществувала в потока от котировки. Това е ярко доказателство за измама, предизвикана от ръчно дилинговане или още по-лошото - предизвикана от ръчна редакция на някой тикет със задна дата. Точно поради тази причина логера трябва да следи състоянието на всички тикети - стари и нови, за да може да детектира една такава измама от типа ръчно редактиране със задна дата. Такава една ръчна редакция може да промени всяко едно поле на тикета, което означава, че нашия логер трябва да следи всички полета, а не само двете цени. Трябва да се следи и за изчезването на цели тикети (просто е бил изтрит), както и за появата от нищото на нови тикети (бил е добавен в историята на ръка).

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

[Mateev]

И още нещо:
Тъй като в даден тикет е възможно във времето да има няколко на брой промени по различни негови полета, то за да може това да се логне е най-добре да въведем понятието "Версия на тикета". Тоест отваряме още едно поле и в него записваме версия номер 1. Когато настъпи някаква промяна в което и да е поле от тикета, ние просто копираме стария тикет в нов запис, слагаме версия номер 2, слагаме новия таймщамп с точност от 1 милисекунда, и чак тогава във втора версия променяме съответното поле така, както го е променил търговския сървър.

По този начин на процедиране в нашата база с данни всеки един тикет може да има неограничен брой версии, и всяка една от тях ще се съхранява, защото носи в себе си информация за някаква промяна по някое от полетата на този тикет. Ето това всъщност е и причината аз да искам да се поддържа база данни в паметта, а не елементарно логване в текстови файл, което е нецелесъобразно за целите, които си поставяме. Да, най-накрая нашата база с данни ще я запишем на диск, но докато тя стои в паметта, лесно и бързо ще можем да създаваме нови версии на тикетите и да правим промени по всички тикети от цялата история.

Трябва да знаете, че сървъра на брокера НЕ ПОДДЪРЖА стари версии на състоянието на всеки един тикет. Тоест ако брокера на ръка реши да редактира някой тикет, старата информация изчезва безвъзвратно, и така не остава никакво доказателство за тези неправомерни действия. И ако ние нямаме логер, който да ги детектира, посмъртно няма да можем да докажем, че брокера е направил кражба от нас.

Едно време, когато имах брокер, ми се е налагало със задна дата да редактирам ордери и позиции на клиенти. Причината беше излъчване на ценова игла (spike) и след това заличаване на щетите, нанесени от тази игла на клиентите. Тогава всъщност осъзнах, че наличието на такъв инструмент в административната конзола на сървъра може лесно да се използва и за користни цели, особено при клиенти, които имат хиляди на брой сделки в историята си. Също така интерфейса позволява стар тикет да се прехвърли от един клиент на друг, което автоматично означава, че от клиентска гледна точка може да се наблюдава изчезване на печеливши исторически тикети или обратното - поява от нищото на губещи исторически тикети. Точно това мое познание сега ме кара да планирам един толкова сложен логер - ами аз просто знам какво може да направи един некоректен брокер, и единствената ми защита срещу такъв брокер е именно този логер.

[Mateev]

И последно и няма повече да пиша по въпроса за логера:

Другата важна задача на логера, освен да логва тикове и да следи за промяна на тикети, е да натрупва статистическа информация за важни за трейдера цифрови редици. Например за средния спред на даден финансов инструмент или за средните РЕАЛНИ разходи за брокера при сключване на сделка - спред, слипидж и т.н.

Това допълнително изискване не е чак толкова страшно, ако човек има готов статистически клас. Аз имам такъв и дори доколкото си спомням съм публикувал неговия сорс код. Наличието на такъв клас позволява за секунди обект от него да се добави да следи и натрупва каквато си поискаме статистическа информация за който си поискаме параметър от нашия експерт. В случая с логера е добре да се следи, натрупва и записва статистическа информация за следното:
1. Спред по финансови инструменти, дни от седмицата и часове от денонощието
2. Микрогапове по финансови инструменти, дни от седмицата и часове от денонощието
3. Време за реакция на брокера по дни от седмицата и часове от денонощието (колко бави изпълнението на търговските операции)
4. Разходи за брокера по инструмент, дни от седмицата и часове от денонощието (спред + суап + слипидж + комисионни + дребни хватки)

Както сами виждате ще има няколко стотин обекта на нашия статистически клас, от които в реално време ще извличаме и ще показваме на екрана най-важните за нас статистики. Например Min, Max и Average Spread, Average разходи за брокера, Min, Max и Average време за реакция на брокера и т.н. Ако толкова ни е мерак, можем и да записваме стойностите на тези статистики на диск (класа го може), за да може следващия път да не започваме статистиката от нула, а да ползваме вече натрупаната стара такава.

Тука му е мястото да ви кажа и за един софтуерен трик, за който може и да не сте се досетили. Един експерт работи в 2 нишки. Едната нишка е тази, която ни се предоставя на нас за да пишем кода си в събитията OnTick и OnTimer. В тази нишка ние 1000 пъти в секундата ще проверяваме за нови тикове или за нови промени по тикетите - исторически или активни. В тази нишка обаче не е редно да извършваме дискови операции за запис/четене, защото това може да доведе до голямо забавяне и до пропускане на една или повече милисекунди от логването.

Хитроста се състои в това за дискови операции да използваме друга нишка, която да върви паралелно с нашата и операциите по нея да не забавят логването в милисекундната нишка. По принцип МТ не ни предоставя възможност да създаваме други нишки, или поне доскоро беше така, но ние можем да се изхитрим да ползваме нишка, която вече съществува. Това е нишката на основната графика, която се визуализира на дисплея. В тази нишка се изпълняват само операциите по дисплейване и операциите по изчисляване на индикаторите, тъй като те са част от дисплейващия процес. Ако обаче ние прехвърлим файловите си операции в индикатор, то тогава ние ще сме се сдобили с втора нишка, работеща паралелно с нашата милисекундна нишка. Да, понякога файловите операции могат да предизвикат временно притрепване или дори замръзване на дисплейващата част, но нова няма да попречи на работата на милисекундната ни нишка.

Това е само идея, която все още не съм я пробвал, но има всички шансове за успех.