Jak technicky na AOS obchodující na konci seance?

kompNa tomto webu se rozpoutala poměrně zajímavá diskuse ohledně technického zpracování obchodů na konci obchodního dne. Pojďme se tedy podívat, jak to řeším já, přidám i nějaké ty tipy pro ty z Vás, co chtějí udělat něco podobného a nakonec naznačím, kterými cestami byste se neměli vydat, protože nikam nevedou. Mám s tím několikaleté zkušenosti, doufám, že to někomu může pomoct.

Jestliže někdo obchoduje libovolnou strategii s prováděním příkazů na konci obchodního dne, potřebuje udělat v zásadě tři věci:

  1. Sesbírat potřebná data pro výpočet obchodních pravidel
  2. Vypočítat potřebné identifikátory a zjistit, co zobchodovat
  3. Provést obchody

Zbytek článku bude věnovaný tomu, jak realizovat strategii “90%”, ale u dalších strategií obchodujících za EOD ceny to bude úplně podobné.

Sesbírání potřebných dat

Není žádná legrace obchodovat strategie, které vyžadují pro svůj provoz kvanta dat. Například strategie “90%” obchoduje koš akcií z indexu SP100, a tak potřebuje každý den v závěru obchodování mít k dispozici data 100 různých akcií. Tato data můžete získat:

  1. Od svého brokera, což bývá typicky nejlevnější varianta. Například IB poskytuje přes API streamovaná data, která lze pro tento účel použít. Jejich natažení “někam” už si ale budete muset zajistit sami; a pokud chcete, aby to bylo spolehlivé, bude to vyžadovat programování.
  2. Od třetí strany. Například IQFeed, který používám já je vynikajícím poskytovatelem nezávislých tickových dat. I tady samozřejmě budete potřebovat získaná data někam uložit.

Poměrně zajímavý přístup je rovněž používat free historická data (z YAHOO jsou celkem přesná) a placená data z aktuálního obchodního dne. Třebaže to přidává složitost aktuálnímu zpracování, zase se tím vyhnete nutnosti stahovat kvanta dat od brokera v čase, kdy jej nemáte nazbyt.

Co nedělat: Rozhodně nepoužívejte delayed data z free datových zdrojů. Bývají typicky opožděna o 15 až 20 minut oproti reálu, a na burze není nic staršího než 20 minut stará data.

Výpočet potřebných identifikátorů a kandidátů na obchod

Pokud máme k dispozici data, můžeme vypočítat indikátory. V případě strategie “90%” půjde o následující indikátory:

  1. Jednoduchý klouzavý průměr s periodou 200 (SMA200), na něj bude tedy třeba posledních 200 zavíracích cen dané akcie.
  2. Jednoduchý klouzavý průměr s periodou 5 (SMA5).
  3. Relative strength indicator s periodou 2 (RSI2).

Jestliže potřebujeme 200 zavíracích cen od 100 akcií, selským rozumem dojdeme k číslu 20000 údajů, které bude třeba zpracovat. A protože na výstupu bude vždy akcie a 3 indikátory, půjde o 400 ((3+1)*100) údajů na výstupu.

V této fázi obyčejně trader používá jeden či více z následujících řešení:

  1. Microsoft Excel,
  2. Nástroje třetí strany, jako je XLQ,
  3. Nástroje vlastní, jako je kód ve VBA, vb.NET, Javě atd.
  4. Kombinace předchozích

A kde se skladují data? Je to úplně jedno, počínaje textovými soubory, přes XML soubory až po relační databáze je možné použít prakticky jakoukoli perzistenci.

Mimochodem, v diskusi zazněly názory ohledně toho, kolik vteřin je ještě akceptovatelných na oněch 300 výpočtů (3 indikátory pro 100 akcií), ale věřte, že to je úplně jedno. Někdo tvrdí, že to “dá” za vteřinu, jiným to trvá asi 5 vteřin, u mě cca 4 vteřiny. Není ale třeba tento výpočet přespříliš optimalizovat; mnohem více vteřin bude trvat samotné obchodování.

Co nedělat: Rozhodně nepoužívejte knihovny třetích stran pro výpočet indikátorů, pokud jim nerozumíte a pokud je patřičně neotestujete. Vadné knihovny mohou buď počítat něco jiného, nebo dokonce končit s chybami a to byste asi nechtěli.

Obchodování

Paradoxně nejtěžší část z hlediska systému. Proč je nejtěžší?

  1. K obchodování je třeba znát historii předchozích obchodů (např. kvůli přikupování) a stav účtu (např. kvůli marginu).
  2. API brokerů může být složité, špatně navržené nebo může komunikovat asynchronně.
  3. Mělo by se nejprve prodávat a potom nakupovat.
  4. Je třeba to stihnout do konce obchodní seance.
  5. Ale zase je třeba to udělat co nejpozději, ideálně za zavírací ceny nebo co nejdříve před zavřením burzy.

Obecně lze říct, že tady jsou pouze 3 možné přístupy, jak na to:

  1. Vše mít automatizované,
  2. Vše mít ruční
  3. Mít poloautomat, který něco připraví a zbytek se potvrzuje “ručně”.

Co nedělat: Ruční a poloautomatické obchodování. Když totiž o něco půjde, a Vy budete chtít uzavřít 6 pozic a novou otevřít, spletete se a uděláte chybu. A podle zákona schválnosti … (asi víte, co se stane, ne?)

Moje postřehy

Excel je dobrý na testy, ale špatný na obchody. XLQ je dobré. IB API je špatné, ale typicky nebudete mít jinou možnost. IQFeed je dobrý. Vlastní řešení jsou tak dobrá, jak dobře je napíšete. Plánovač úloh ve Windows je spolehlivý. Windows XP jsou špatná, Windows 2008 jsou dobrá. Jednojádra a 2GB paměti jsou špatné, vícejádra a 4 GB paměti jsou dobrá. Domácí počítače jsou špatné, virtuální servery jsou dobré. TWS je špatná, IB Gateway je dobrá. Příkaz LIMIT je špatný, příkaz MARKET je dobrý.

Nemám patent na rozum, takže můžete některé věci dělat jinak Mrkající veselý obličej. Postřehy v diskusi jsou vítány.

Příspěvek byl publikován v rubrice Software se štítky , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

66 komentářů u Jak technicky na AOS obchodující na konci seance?

  1. Djm napsal:

    Díky za technický čánek. Já bych k tomu měl jeden dotaz. Nebylo zde zmíněno použití softwaru RightEdge pro exekuci příkazů u IB.
    Zajímalo by mě, zda je toto také možná varianta, nebo tudy cesta nevede? Program RightEdge na první pohled vypadá jako skvělé prostředí pro vývoj a testování strategií, ale zajímala by mě tvá zkušenost ohledně napojení RightEdge na data z IB a následnou exekuci příkazů přes IB.
    Touto cestou bych se nejraději vydal, ale nevím jestli v tom není nějaký háček.

    • admin napsal:

      RE bohužel neumí obchodovat na konci obchodní seance ;-(

      • Djm napsal:

        V čem je tam konkrétně problém, že to RightEdge nedokáže? Nedalo by se to vyřešit tím, že bych trochu slevil ze svách nároků, že chci přesně za close a příkaz bych exekuoval o něco dříve, například ve 21:58 ?

        • admin napsal:

          Jistě, to bys ale musel jet na minutovém grafu. A počítat indikátory z grafů denních. To už to v tom C# nebo VB.NET můžeš rovnou napsat celý, ne?

          • Djm napsal:

            Jo už rozumím. Je to teda tim, že v 21:59 RE ještě nemá close cenu pro dnešní den. To bych tedy musel krmit streamovanými daty z IB a nějak přiohnout výpočet indikatorů tak, aby se jako Close dneška chápala aktuální cena. A exekuci příkazů neprovádět ve funkci BarClosing, ale v OnTick v osudovou minutu před koncem. Tak tady je teda na zvážení, zda není lepší si na to napsat vlastní utilitu..

            • admin napsal:

              Tak, přesně. A pokud RE má reagovat na OnTick při portfoliu 100 ks akcií, tak jde k zemi do pár minut, tzn. toto je nepoužitelné.

              • Ondrej napsal:

                A co tedy presne dela ten RE skript ktery jsi sem daval?

                • admin napsal:

                  Tern skript, co jsem sem dával dělá úplně přesně to, co bys čekal, s jednou výjimkou – lze jej použít pouze pro backtest, nikoli pro obchodování. Má totiž v kódu EnableTradeOnClose=true

  2. Kolous napsal:

    Ahoj, přidám svou trošku do mlýna. Práci s daty řeším následujícím způsobem. V předstihu načtu do bufferu předchozích 199 dnů z Yahoo. Pár minut před desátou začnu streamovat živá data data z TWS. 21:59 udělám snapshot a ten připojím k předtím staženým dat, tím získám vše co pro výpočet potřebuji v přesně stanovený čas. Co se týče té sekundy na výpočet, tak to „netvrdím“ ale je to tak, jedna iterace prohnaná profilerem: „Elapsed time is 0.068824 seconds.“ (Čtyři roky starej notebook) Ale máš pravdu, že tohle je úplně fuk ;-)

    • admin napsal:

      Heterogenní zdroj dat, to může fungovat, pokud Ti načítání z YAHOO funguje spolehlivě, tak proč ne.

      Asi každý měříme něco trochu jiného, já totiž počítám i zápis vypočítaných dat do databáze (FireBird), ale ono je to fakt v reále úplně jedno. Když se podíváš sem: http://winpes.cz/wp-content/uploads/2014/07/vysledky-2014-06.xlsx třeba na AIG a T tak jasně vidíš, že to burza vypořádává klidně s 15 vteřinovým zpožděním. Čili důležité je, aby se to do 16:00:00 stihlo.

    • misch napsal:

      Řeším to podobně. I když zatím jen něco přes týden, tzn. zkušenosti z praxe jsou to pramalé. Předem si (kdykoli během dne) nechám dotáhnout historická data z Yahoo a uložím je do databáze. Šlo by to i přes IB histdata API, ale neskutečně mě nebaví hlídat si „pacing violation“, tož tak :).

      Před koncem obchodní sesssion už jen zapnu SW který si natáhne tu historii, z IB začne streamovat data, a v oblíbených 21:59 si to všechno spočte, zaeviduje nový stav a vygeneruje požadavky na trade.

      Akorát mám oddělenou samotnou obchodovací část, tzn. chvíli po těch 21:59 se mi vlastně jen v databázi objeví nové signály, a vzápětí si je převezme obchodní SW a začne je posílat do IB.

      Zatím, vzhledem k té týdenní době, to provozuju jen na demu, abych vychytal mouchy. Řekl bych, že víc práce než s tímhle konkrétním samotným jednoduchým AOSem je s tou omáčkou okolu (hlídání chybových stavů, zaseklé komunikace, toho že jsou k dispozici všechna data, atd.).

      • misch napsal:

        No, a úplně jsem zapoměl „adminovi“ poděkovat. Jsem rád, že po opuštění jistého fóra nacházím jeho inspirativní příspěvky nově v tomhle blogu. Obchodování za market-on-close jsem vždycky v backtestech viděl jako dost podstatný zádrhel, a ejhle, ono to (skoro) jde :-o.

      • admin napsal:

        Oddělena obchodní čast je správně, taky to tak mám ;-)

    • Joystick napsal:

      Jak řešíte počítání SMA a RSI když dojde ke splitu akcí? Jsem ve fázi, kdy si natahuji do excelu historická data a připravuji si výpočet indikátorů. A koukám, že zrovna na zkušebním vzorku APPL mi to nevychází. A ejhle, 6.6.14 byl split. V pátek se končilo za 645,57 a v pondělí se otevřelo za 93.88. Co s tím?

      • piftik napsal:

        idealne je tahat si data adjustovane o splity. yahoo bohuzial adjustuje jak o splity tak aj o dividendy.

        • admin napsal:

          Ta adjustace o dividendy není zase až takový problém pro tuto strategii …

          • foglik napsal:

            Přesně tak, mám udělaný BT jenom na AdjClose. Proto taky stahuju historická data pro SMA a RSI každý den znovu – nepoužívám databázi s tím, že by se denně dopnila jen historická data za včerejšek. Navíc denně aktualizuji svoji „průměrnou“ cenou a pokud se odchýlí od SMA o x%, pak na mě excel zabliká, že se něco dělo.

            Jediný „technický“ problém jsem zaznamenal s GOOG a GOOGL:)

            • piftik napsal:

              dalsia z moznosti je mat databazu iba neadjustovanych cien a vedla toho databazu splitov a dividend. adjustovanu cenu si potom dopocitas sam.

            • Joystick napsal:

              Jestli jsem to dobře pochopil, tak indikátory počítáš z AdjClose, ale do deníku jako nákupní a prodejní ceny počítáš Close cenu, je to tak? Nebo do deníku počítáš taky s AdjClose?

              • foglik napsal:

                Hele, podívej se na páteční Close a AdjClose a pak si odpověz proč jsou stejné:) Následně si z toho odvodíš, proč používám jak pro BT, tak pro výpočet indi AdjClose.

                Co se týče nějakého deníku – soráč, ale nikdy jsem nebyl v tomto směru moc pořádný a žádný deník(y) nevedenu, ať se jedná o jakýkoliv instrument nebo strategii (jediný deník je pro mě broker´s statements), přestože dlouholetí prodejci kurzů zdůrazňují, že bez kvalitního vedení deníku v podstatě nelze uspět nedejbože vůbec existovat.

                • Joystick napsal:

                  S deníkem máš určitě pravdu, ale pakliže jsem ve fázi testování a nemám zatím žádný účet u brokera, tak deník je jediné v čem mohu něco zjistit.

                  Jinak na páteční ceny jsem koukal, tentokrát jsou opravdu stejné, ale vetšinou to o nějaké „drobné“ lítá. Tak nevím, která cena je blíže reálnému obchodu. Když nakoupím za MOC, která cena to bude?

  3. Kolous napsal:

    Samotného mě překvapilo, jak to funguje spolehlivě. Byl to takový pokus, protože vyžádání aktuální ceny u jedné akcie se občas protáhlo až na 4 sekundy. A podle výsledků testování data sedí.

    Tak to jo, měřil jsem průchod čistě výpočetní části strategie.

    Jediné, co nevím jak ošetřit jsou zkrácené obchodní dny (svátky jsem pořešil), má to někdo nějak ošéfované?

    A ještě jeden dotaz…data ukládáš do databáze, ty využíváš čistě jen pro další dny? Počítáš teda další dny z dat 21:59? Pokud je používáš pro backtesty řešíš pak adjustaci?

  4. Ondrej napsal:

    Rad bych poprosil o radu, nedari se mi spravne pocitat RSI, SMA(200) a SMA(5) v XLQ

    K datu 25.8.2014 dava Stockfetcher nasledujici data (pro AAPL):
    RSI(2) – 99,97
    SMA(200) – 83,23
    SMA(5) – 100,91

    V XLQ mam nastavene tyto formule s nasledujicimi vysledky:
    RSI(2) – 96,5
    (=xlqxhRSI) symbol AAPL, Date Ref. 0, source IB
    SMA(200) – 72,1
    (=xlqhSMAX) symbol AAPL, Date Ref. -200, Source IB
    SMA(5) – 96,07
    (=xlqhSMAX) symbol AAPL, Date Ref. -5, Source IB

    Poradite mi kde muzu delat chybu? Diky moc

    • admin napsal:

      Byla tam dividenda. Udělej si soupec se zavíracími cenami, ať vidíš, z čeho to ten excel vlastně počítá.

    • foglik napsal:

      Proto mám rád, když přesně vím, co mi excel dělá, a proto jsem systém vytvářel bez přidaných (cizích) prvků.

      XLQ v default nastavení (typicky po instalaci) „tahá“ Close ceny – řešením je přepnout na Adj Close – pak ti to bude počítat dobře.

      • Ondrej napsal:

        Dekuji, ale stale je tam nejaka chyba.
        Hodil jsem pod sebe 200 Adj Close a vydelil soucet cislem 200, porad jsem ale na hodnote 82,81 , zatimco Stockchart uvadi 83,23.

        Spise me ale trapi rozdily v RSI, vetsinou je rozdil oproti SF okolo 1 bodu, nekdy ale 4. Je nejaky rozdil i v pocitani RSI v XLQ oproti SF?

        Diky

  5. Ondrej napsal:

    Zeptam se jinak, muzete mi prosim poradit jaky vypocet RSI v XLQ pouzivate pri obchodovani 90% systemu?
    XLQ nabizi vypocet intradenni:
    ‚=xlqxiRSI(„Symbol“,“Date Ref.“, „No of Periods“,“Source“)
    historicke:
    ‚=xlqhRSI(„Symbol“,“Date Ref.“,“Source“)

    ‚=xlqxhRSI(„Symbol“,“Date Ref.“, „No of Periods“,“Source“)
    tento mi funguje na datech od yahoo s prodlevou, s IB dava uplne jine hodnoty nez Stockfetcher

    Jak to mate nakonfigurovane vy?

    Dekuji

    • foglik napsal:

      XLQ nepoužívám už dlouho, takže si to už nepamatuju a tady neporadím, ale podle toho co píšeš si nejprve ujasni, jaký výsledek chceš vůbec vidět.

      Jinak mě ještě napadá – u TWS – netaháš data náhodou ze Simu?

      Yahoo je zpožděné cca 20 min., takže tady máš jedinou šanci, zobchodovat to za MOO – pak stačí počkat, až bude součástí yahoo historických dat dnešek a stáhnout to všechno.

      Jinak všude možně čtu, jak chtějí všichni obchodovat tuto strategii a hned druhým dechem brečí, že nejsou programátoři… Já taky ne, přestože se spousta lidí zasměje, dneska jsem sice celý den :(, ale napsal funkci pro počítaní Wilders RSI v Pythonu – takže asi tak…

    • piftik napsal:

      ja som pouzival xlqxhRSI na backtesty s historickymi datami z Yahoo.
      no a prave ten rozdiel medzi historickymi cenami z IB a Yahoo (a tym padom aj rozdielnym RSI hodnotam) ma dohnal k sucasnemu stavu – historicke data z Yahoo, intraday data z IB a vlastna VBA funkcia na pocitanie RSI z tejto zmesi dat pre zive obchodovanie.

      • piftik napsal:

        Este si daj pozor na nastavenie XLQ. V Settings pre IB chces mat „Return Backfill only for RTH“ a „Ignore Afterhours Data“ nastavene na Yes.

        • Ondrej napsal:

          Diky za rady, IB mam ostry ucet. Zatim obchoduji manualne, ale ac nejsem vyvojar, na vlastni aplikaci jiz pracuju – ale je pravda ze profesne mam k vyvoji hodne blizko. Na MOO jsem si delal backtesty, neni to dramaticky horsi nez MOC, ale horsi to je.

    • admin napsal:

      No, já používám jako zdroj dat IQFeed, ovšem to je cca 80 USD měsíčně, tak nevím, jestli by Ti to k něčemu bylo, když jsi ve fázi testování…

      • foglik napsal:

        Nemám to ověřeno, protože se mě to netýká, ale nemá náhodou IQFeed pro majitele XLQ nějaký levnější balík dat? Mám pocit, že jsem to kdysi četl.

        • admin napsal:

          Tuším že jo, ale já mám kromě základníého balíku dat ještě … aha, to vlastně nechci prozradit, to bych dal indícii, co obchoduju a je to tajný ;-)

          • Ondrej napsal:

            Testuju bojem, to na me plati nejvic, takze naostro… Jinak u clanku o zdrojich dat jsi psal ze live data od brokera nejsou vzdy z ruznych duvodu nejvhodnejsi. Mozna nejen me by zajimalo jake jsou to podle tebe napr. duvody? Proc se vyplati si priplatit za IQFeed? Diky

  6. Joystick napsal:

    Mohu se zeptat, v čem programujete ty „své“ části pro live obchod? Je to ve formě skriptů nebo jsou to klasické aplikace s GUI? V čem jsem kdysi něco dělal bylo Visual Studio, tak nevím jestli je toto na to vhodné (i když by to asi taky mělo jít).

  7. foglik napsal:

    VBA for excel, Python – bez GUI. Přestože má python podporu, mimo jiného, pro QT, zbytečná práce – k čemu by bylo dobré, chci aby to obchodovalo, ne abych na to mohl „čučet“.

  8. Ivo napsal:

    Ahoj všem, jelikož nejsem programátor, tak asi budu muset najít nějakou jinou cestu. Dala by se tato strategie event obchodovat přes MT4? Díky za názory. Přeji úspěšný den.

    • Ondrej napsal:

      Jestli to myslis vazne, tak si muzes AOS nechat napsat a do te doby obchodovat manualne. Ja to taky tak delam, neni to zase tak velky problem – VPS na ktery se muzu pripadne pripojit i VNC klientem z mobilu, na nem bezi XLQ ktery mi vyhodnocuje potencialni nakupy i hlida nakoupene tituly. O pul 10 si kandidaty predpripravim v TWS a pak je 21:59 bud zrusim nebo provedu, podle aktualnich dat z XLQ.
      Pravda, dlouhodobe se to delat neda, AOS uz mam temer hotovy.

  9. Pingback: Strategie “90%”–servisní info | Akcie

  10. Alexis John napsal:

    Tokyo is 13 hours ahead of the New York time, hence keeping a track of the TSE

    Holidays and opening time is important.

    http://www.profitconfidential.com/tokyo-stock-exchange-tse-holidays-schedule/

  11. Petr napsal:

    Zdravím…hledám jak automaticky řešit splity přes IB API, nikde nic nemůžu najít, tady je aspoň zmínka, tak se zkusím zeptat. Víte někdo, jestli IB API umí reportovat split? Yahoo uvádí Last Split Date a Last Split Factor, ale na IB API nic takového nemůžu najít. Řeším to hlavně kvůli tomu, že pokud jsem v pozici a dojde ke splitu, IB API mi začne reportovat jinou velikost otevřené pozice. A nevím jak automaticky rozhodnout, že to není chyba. Můžu samozřejmě scrapnout Yahoo, nebo nějakou heuristikou odhadnout, že došlo ke splitu, ale rád bych to měl řešené nějak korektně. Případně jestli se můžu zeptat, jak máte tohle ošetřené? Díky.

    • myk napsal:

      Mě zatím napadlo jen stahovat data yahoo a porovnnávat odchylky Close a Adj Colse za předchozí den a pokud je rozdíl větší než nějakej trigger, tak poslat alert.

      • Honza napsal:

        Pokud vim, trapi te pripad, kdy mas nakoupene pozice a ty musis upravit pocet kusu u sebe v databazi, abys pri prodeji neprodal vice/mene kusu, nez strategie po splitu/reverse splitu ma.

        Mrkni na quandl – ten posila i probehle splity a divi, ale jak moc je to spolehlive, to nevim.

  12. Petr napsal:

    No jasně, to je ta heuristika…já bych třeba zkoumal podíl, jestli je celočíselný, to samé můžu odhadovat u pozice, jestli se mi velikost v databázi a od IB liší o celočíselný násobek, ale přijde mi na rok 2017 dost primitivní a nespolehlivá technika.

    • admin napsal:

      Ale jak jinak, že? Já třeba srovnávám data z více zdrojů a když se liší, hodí mi to vykřičník a já už to doladím ručně. lepší metoda mě nenapadá.

    • misch napsal:

      Pozor, ten násobek nemusí být jen celočíselný. Jednak existuje i reverse split, a navíc některé splity probíhají v kuriózních poměrech, třeba 5:4 (viz třeba Heico (HEI, https://www.splithistory.com/hei/))

      • Petr napsal:

        To je pravda, i když by mě zajímalo, kolik teda dostanu akcií po splitu, když mám nějaké nesoudělné číslo.

        Honza: Koukal jsem na ten quandl, mají i nějaká neplacená data, kde by to mohlo být, ale rovnou u nich píšou, že nezaručují spolehlivost a denní aktualizace. Každopádně to fakt vypadá na nutnost ruční práce, což mě dost štve. Taková blbost :)

        admin: Tak IB ta split data určitě někde elektronicky mají, poslat je na API je to nejmenší, jen to prostě nikdo nepovažoval za důležité aby to naimplementoval. Ale existuje na to hlasování, tak kdo chce, může přidat hlas zde https://www.interactivebrokers.com/en/index.php?f=2493&sid=5934 . Jen tam visí od roku 2010, tak to asi jen tak neudělají.

  13. nemozny napsal:

    „K obchodování je třeba znát historii předchozích obchodů (např. kvůli přikupování) a stav účtu (např. kvůli marginu).“
    Můžete mi někdo říct, jak tohle u IB řešíte? Když obchoduju „90tku“, tak OK, tam nejsou SL a veškeré příkazy děla AOS. Ale když chci zadat SL, jak ošetřím, když pozici zavřelo IB?
    Našel jsem v API:
    string OrderRef [get, set]
    The OrderRef is a user-customizable string that can be set from the API or TWS and will be associated with an order for its lifetime.

    Tohle ale funguje jen v GUI! V API OrderRef vrací jen execDetails a Execution class, ale cituji:
    Provides the executions which happened in the last 24 hours.

    Ve skutečnosti od následující půlnoci není šance získat OrderRef přes API.
    To neexistuje žádný způsob, jak identifikovat UZAVŘENÉ pozice?

    • admin napsal:

      „Ve skutečnosti od následující půlnoci není šance získat OrderRef přes API.
      To neexistuje žádný způsob, jak identifikovat UZAVŘENÉ pozice?“

      Já osobně execDetails pouštím jednou denně po skončení seance, výsledkem je u mě soubor s proběhlými obchody a ten mám pak k dispozici nadosmrti. Navíc IB posílá po každém proběhlém obchodu e-mail.

      Stav účtu můžu vidět okamžitě pomocí RequestAccountUpdates.

      Kombinací toho všeho mám perfektní přehled. Ještě jsem nezažil, že by mi to nestačilo.

      • nemozny napsal:

        Aha, nějak mi nedošlo, že uzavření pozice je taky operace.. heh.
        Takže ty mi říkáš, že je šance, že když pustím execDetails než budu obchodovat, tak by mi měl vrátit snad i OrderRef pro pozice uzavřené SL ten konkrétní den?
        Po uzavření burzy už to asi nepotřebuju, protože kontroluju stav Orderu (remaining = 0, state != inactive). Jedině pro kontrolu balance na účtu.
        Na EClientSocket::reqAccountUpdates jsem se zrovna díval, ale nenabyl jsem dojmu, že by moje dilema úplně řešil. Jedině v kombinaci reqAccountUpdates a spárování podle volume s pozicemi v DB bych dokázal říct, co se stalo. Ale teda preferoval bych raději ten OrderRef.
        Z pohledu IB chápu, že je to jedno, pozice se uzavřela a tím to hasne. Ale já bych tak nějak rád věděl, proč se tak stalo a kde se ta pozice vzala.

        • admin napsal:

          hmm … řekl bych skoro, že Ty budeš mít jiný problém, a to zjistit uzavření pozice CO MOŽNÁ NEJDŘÍVE poté, co j tomu došlo, nemám pravdu?

          • nemozny napsal:

            No, pokud bych obchodoval 5min bary, tak ano, ale zatím jsem z výsledků intradenního obchodování spíš zklamaný.
            Běžím na živých datech strategii na futures (zatím které se obchodují 3AM – 15PM CT) Larry Williamse „nakup long, když close > open + 0.7 * (high[1] – close[1])
            a za několik malých ztrát dokáže pak udělat balík na jednom obchodu, ale nejsem úplně přesvědčený, že se ta expozice kapitálu vyplatí. Přestože když uzavřu na konci seance vs neuzavřu je ve výsledku téměř stejný profit, takže vlastně EOD expozice je nulová.
            Na EOD obchodování potřebuju jen prostě zjistit, jestli pozice ještě existuje nebo ne.

            • admin napsal:

              reqAccountUpdates a porovnat. V tom nevidím problém.

              • nemozny napsal:

                To by asi stačilo.
                Každopádně v execDetails uzavřené pozice jsou a OrderRef tam je také – „orderRef“:“MUJSELL“.
                Jsem happy, díky za konzultaci!

                Info: execDetails: [1,{„conId“:118089500,“symbol“:“ABBV“,“secType“:“STK“,“expiry“:““,“strike“:0,“right“:““,“multiplier“:
                „“,“exchange“:“DRCTEDGE“,“currency“:“USD“,“localSymbol“:“ABBV“,“tradingClass“:““},{„orderId“:2147483647,“execId“:“000180
                37.5987eb87.01.01″,“time“:“20170807 08:00:00″,“acctNumber“:“DU364444″,“exchange“:“DRCTEDGE“,“side“:“SLD“,“shares“:“100″
                ,“price“:71.1,“permId“:455398217,“clientId“:0,“liquidation“:0,“cumQty“:300,“avgPrice“:71.033333,“orderRef“:“MUJSELL“,“ev
                Rule“:““,“evMultiplier“:null}]

              • nemozny napsal:

                Abych objasnil své počínání – prostě si jen snažím usnadnit život. Uzavření pozic totiž dělám jako updateMany operaci.
                V pseudo SQL:
                UPDATE Positions SET Sold = 1 WHERE OrderRef == MUJSELL
                Takto uzavřu např. Scale 1 až 4 u 90tky současně.

Napsat komentář

Vaše emailová adresa nebude zveřejněna.