Co Interactive brokers API nově umí a jak to využít

Když jsem před lety začínal používat Interactive Brokers jako svého hlavního brokera (poté, co jsem odešel od Patrie), byl jsem v sedmém nebi. Měl jsem pocit, že tento broker a jeho promakané API zvládnou úplně všechno. Už jsem starší a zkušenější a vím, že to není pravda, občas mě ale i tak něco překvapí. Právě dnes jsem například zjistil, že IB API neumělo, ale už umí …

podmínky v objednávce!

Jinými slovy – přes API, stejně jako v TWS můžete takové objednávky pohodlně naklikat. Lze tak například vytvořit objednávku, která mi (při splnění podmínek) otevře obchod na SPY dnes v 15:45:00, a následně na ni navázat související objednávku, která mi SPY v 16:00:00 zase třeba zavře. A to celé poslat do platformy den předem nebo během noci, rána.

Pozn.: Aby nedošlo k matení pojmů: „přidružené“, neboli „dceřinné“ objednávky, které se navážou na hlavní objednávku a realizují teprve po realizaci hlavní objednávky, ty API uměla už dávno. Ale podmíněné objednávky – to ne, to je záležitost poslední doby.

Jak na to?

Tohle bude pochopitelně u každé implementace API trochu jiné, ale princip zůstává podobný:

  1. Vytvoří se objednávka
  2. Ta se neodešle
  3. Na objednávku se „navěsí“ jedna nebo více podmínek
  4. A pak se to odešle!

Ukázak kódu v mém oblíbením Visual Basicu:

Code Snippet
    Dim mktorder As Order = MarketOrder(„SPY“, 100)
mktParent.OrderId = increment(wrapperImpl.nextOrderId)
mktParent.Transmit = False
mktParent.ConditionsCancelOrder = False
‚což znamená, že po splnění podmínky bude objednávka VYPLNĚNA
mktParent.Conditions.Add(TimeCondition(„20170302 16:00:00“, False, False))
socketClient.placeOrder(mktParent.OrderId, USStock(Stock), mktParent)

Podmínkou přitom může být v zásadě to, co je uvedeno v okně „Create condition“ na záložce „Conditional“ v okně objednávky. Tedy toto:

Podmínky se navíc dají kombinovat (tedy např. čas jen větší než xxx a zároveň cena je vyšší než yyy).

Co z toho?

Nuže, máme k dispozici určitou schopnost platformy, kterou lze nově ovládat programově, a ne už pouze ručně. Je tedy dostupná pro AOS, alespoň u Interactive Brokers. To znamená, že pokud ji bude někdo obchodovat s využitím API, nemusí se bát překlepů.

Je třeba zdůraznit, že podmínečné objednávky visí na serveru IB, to znamená, že budou fungovat i při vypnuté platformě!

Abych byl konkrétnější a alespoň naznačil, jak tuto skutečnost využívám já, popíšu:

  1. Mám koš akcií. Obrovský. Je v něm 988 tickerů.
  2. Na tomto koši dělám nějaké výpočty, které trvají. Ale mě to nevadí, protože se mohou dělat přes noc.
  3. Ráno (našeho času) vím, které akcie z koše budu chtít ten den při otevření burzy koupit (eventuálně prodat). Strategii úplně neprozradím, ale můžete si představit, že by šlo třeba o párové obchodování.
  4. Akcie chci držet určitou dobu. Zase, neprozradím, ale představte si, že by šlo třeba o strategii obchodující opening range (mezi 15:30 – 16:00 našeho času).

A tuto strategii mohu kdykoliv během dne naklikat do platformy, ale můžu ji rovněž naprogramovat, protože na to je API. Báječné.

Mám v šuplíku několik kandidátů na obchodování tohoto typu. Už se těším na to, jak je budu testovat.

Využijete podobnou vlastnost platformy taky? Nebo jsou Vaše strategie koncipovány spíše na obchodování v závěru seance (jako je „devadesátka“)?

Příspěvek byl publikován v rubrice Nezařazené. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

19 komentářů u Co Interactive brokers API nově umí a jak to využít

  1. Juraj napsal:

    Ahoj, dik za zaujimavy clanok. Z „advanced orders“ vyuzivam predovsetkym adjusted to trail, nastavenie BE po dosiahnuti ceny a nasledny trail. Technicka otazka: mas napisanu vlastnu implementaciu oficialneho api alebo pouzivas nieco verejne dostupne? Pamatam si, ze kedysi si v zdrojakoch spominal https://github.com/krs43/ib-csharp ale ten uz je 100 rokov za horizontom :)

    • admin napsal:

      Well, víceméně používám tu referenční implementaci s tím, že je mírně upravená. Úpravy jsou třeba v logování, jinak nic dramatického. Pořád ale trvám na tom, že to API je od začátku zastaralé a měli by udělat nějakou modernější verzi, klidně i třeba souběžně s tou starou. Budeme doufat, třeba se někdy dočkáme.

      „adjusted to trail“ to jsem neznal, díky za tip.

  2. Honza napsal:

    Mne osobne by se libilo vyuzit tuhle featuru spolu se zvysenou volatilitou v zacatcich obchodni seance. Cena akcie v prvnich par minutach lita klidne o desetiny dolaru, takze napadem by bylo pres noc vyfiltrovat vhodne akcie, ty v prvnich XY vterinach sledovat, aby se urcil spread mezi nakupni a prodejni cenou a pak:
    a) nahodit limitni prikaz na levny nakup a pote na prodej akcii.
    b) nahodit limitni prikaz na prodej jiz nakoupenych akcii a pak opetovny nakup

    Dulezitou fazi by byl samotny vyber akcii, ktere se takhle zobchoduji. Jednou z moznosti je napriklad vyuzit akcie drzene devadesatkou, ktere oteviraji se ziskem. Nastat by tak mohly tri situace:
    1) akcie je v zisku, posle se prikaz na prodej, ktery se ale neprovedet, protoze cena jde uz od zacatku nahoru a cela akce konci
    2) akcie je v zisku, posle se prikaz na prodej a pote prikaz na nakup, ktery se ale neprovedet, protoze cena jde nahoru a tak jsme 90tce ukradli akcie a mozna zmensili zisk?
    3) akcie je v zisku, posle se prikaz na prodej, pote nakup (mozna se to jeste parkrat zopakuje) a pote skoncime ve stavu, kdy 90tce vratime vypujcene akcie.

    Zakladni otazkou tedy je, kolik z techto obchodu by zustalo nedokoncenych (scenar c.2) a zda by celkovy zisk vydelal na ukracene zisky 90tky z predcasne prodanych akcii.

    Druhou moznosti muze byt nakupovani akcii, ktere bychom v pripade nedokonceneho prodeje vyuzili dale jako je pouziva 90tka – tj na vyssim timeframu. Takze bychom vybirali akcie pod RSI10, nad SMA200 a v pripade, ze se nestihnou prodat, tak bychom je zaradili do 90tky.

    Otazkou je, jak tohle cele testovat, protoze je potreba mit alespon minutova data z (napriklad) prvnich 30ti minut obchodnich dni pro vybrane akcie. Dalo by se proto par mesicu stahovat tickova data (napr z http://www.nasdaq.com/symbol/biib/time-sales?time=1), na kterych se udelaji zakladni testy a pak se koupi nejaky balik dat pro dlouhodobejsi backtest. Druhou otazkou je velikost uctu, na kterem by cela tahle sranda davala smysl, kvuli komisim.

    Takze treba tak..

    • admin napsal:

      I ty kujóne, uvažuješ docela podobně jako já. Jen – proč se omezovat na akcie z SP100, že?

    • merlinx napsal:

      napapá mě, uplatňují se tyto limit příkazy i pre/after marketu? Pokud ano, tak se i pár obchodů může vykonat ještě před otevřením burzy..

    • myk napsal:

      Já jsem tuhle strategii prodeje po open testoval 4 měsíce empiricky, sice na opcích, ale to je jedno. Intuitivně jsem se snažil po částech odprodávat když šla cena up už dopoledne.

      Fungovalo to dobře před zvolěním Trumpíka v říjnu a listopadu. Tehdy trh v dopoledních hodinách vyrostl a pak korigoval. Takže se mi povedlo několik akcií, které gapnuly up prodat dopoledne výrazně lépe než za kolik by byly při close.

      Od voleb už to tak úžasné není, naopak jsem prodal několik tickerů výrazně hůře, než kdybych počkal. Taky se mi stalo, že jsem prodal scale 3 nebo 4, abych dokoupil za levněji, ale levněji už nebylo naopak ty opce mi pak chyběly před close, kdybych je neprodal ráno, profit byl násobně větší.

      Celé to má dva problémy:
      – mělo by se nějak chytat maximum po open, ale jak? Obávám se, že nějaký čas na zákaldě backtestu je nesmysl. Co jsem vysledoval, některé akcie měly gap nahoru a pak už jen rostly, některé gapnuly, pak přišla korekce a nějaké lokální maximum přišlo až třeba za 2-3 hodiny
      – vychytat low na dokup taky není easy, někdy jde cena níž, ale ne výrazně, takže jsem se rozhodoval, jestli prodanou pozici zase dokoupit a jít znovu do rizika, když to kleslo o pár dolarů

  3. Honza napsal:

    Rekl bych, ze ze zacatku je lepsi s malym kapitalem vsazet na vetsi zajete spolecnosti s delsi historii, plus omezenim poctu akcii se zlevni i historicka data na testovani. Casem by ale urcite stalo za to pokryt vetsi plochu.

  4. Ales napsal:

    Omlouvám se za vybočení z tématu, ale zajímalo by mne, jestli jste reagovali na změnu subscripce u IB platnou od 1.března.Já jsem nechal zatím vše beze změny, tudíž bych měl mít od 1.března opožděná některá data. Dnes jsem si udělal čas a chvíli sledoval data po otevření burzy a jeví se mi to tak, že SPY, VXX a jiné odvozené tickery jsou bez zpoždění, ostatní se zpožděním cca 5 min. U devadesátky mi včera AOS nakoupilo v 21.59.02 akcie INTC za 35,90.

    • SuperMuf napsal:

      Ahoj, a čeho se ty změny od 1.3. měly týkat? Nezaznamenal jsem žádnou takovou informaci. Používám NASDAQ (Network C/UTP) a NYSE (Network A/CTA) každý za 1.5 USD/měs. Jak zmiňuješ, 5 minut jsou hodně zpožděná data – to už je jepší to streamovat přes GOOGLE api. IB by u těchto subskripcí měl garantovat „near real-time“.

      • Ales napsal:

        Přikládám jen úvod emailu od IB:

        Dear Client,

        Effective Wednesday March 1, 2017, IB will be terminating a market data service you’ve subscribed to and offering a variety of other services with different features and costs as a replacement. Details regarding this change are provided below and we recommend that you elect a replacement service prior to this termination date if you wish to continue receiving live quote feeds.

        What is changing and why?
        The service being terminated for your account U****418 is the U.S Securities & Futures Value Bundle for Non-Professionals.1 This service is being terminated due to a recent regulatory initiative requiring that U.S. stock quote feeds provide the consolidated National Best Bid & Offer (NBBO) from all market centers trading National Market

        • SuperMuf napsal:

          Hmm zajímavé.. no já používám zmíněné balíčky (v non-pro) verzi.. tzn 0.01USD/snapshot a cap je 1.5USD, pak streamed. Každopádně mám check který kontroluje reálné transakční ceny s cenami za které si AOS „myslí“ že nakoupil a pokud se liší tak je updatuje v databázi. Zatím jsem neznamenal žádné výrazné odchylky (pouze +- setiny dolaru).

  5. SuperMuf napsal:

    Good news everyone! Nové api už (konečně) nativně podporuje Python! Takže od teď už není třeba žádný IbPy a podobné wrappery.

    • admin napsal:

      To je super. Ale pod kapotou je stále stejný IB nedomyšlený koncept socketů, asynchronních zpráv a jiných nepěkností. Kluci z IB by to API měli vážně přepsat.

    • myk napsal:

      Nemáš prosím nějakej příklad kódu, kterej by udělal nějakej request a počkal na data?

      Já to zkouším celej den vydolovat z toho jejich Testbed examplu, ale jsem lamer, takže mi to nejde.:(

      • Myk napsal:

        Tak jsem to Python API rozchodil, ale musel jsem si upravit zdroják API, aby to bylo jednodušeji použitelné.

        Mimochodem, od verze 9.72.12 byla přidána funkce reqSecDefOptParams,
        která vrací expirace a striky opcí. (Před tím to šlo dolovat složitěji z reqContractDetails, ale s touhle funkcí je to komfortnější).

  6. Ales napsal:

    Jen poznámku k tomu poslednímu příkladu, ale omlouvám se předem jako neznalec Pythonu. Pokud má Python nějaký ekvivalent přepínače jako case v Delphi příp.Pascalu (nebo se dá nějak nahradit) pak je zbytečné používat smyčku a zpoždění. Mám svoji vlastní komponentu pro API psanou v Pascalu a s jejím použitím pak zpracovávám odpověď od IB např. do tabulky jednoduše viz zlomek kodu v Delphi:

    procedure TAOS.SockTickPrice(Sender: TObject; DataId: Integer;
    TickType: TIABTickType; Price: Double; AutoExecute: Integer);

    begin
    case DataId of
    0..100:
    case TickType of
    ttBid: Grid.Cells[2,DataId-IDobch+1]:=Format(‚%4.2f‘,[Price]);
    ttAsk: atd.

    Dík za upozornění na funkci reqSecDefOptParams.

    • myk napsal:

      Nevím, jak je to v ostatních jazycích, ale u toho pythonu jsem řešil to, že wrapper nefunguje dokud se nespustí smyčka EClient.run(), která čte message queue. Jenže tak jak to mají v template aplikaci je ta smyčka nekonečná. Ten druhej příklad proto spustí EClienta v samostatným threadu a hlavní program posílá requesty a v tý smyčce čeká na odpověď. Nějaká forma smyčky je podle mě nutná, protože jinak ten main skončí dřív, než od TWS přijde odpověď.
      Samozřejmě že tu vrácenou message může zpracovat už funkce ve wrapperu, tořeší ten první příklad. Ale mě šlo to, abych dokázal poslat třeba sell ordery a počkat si na jejich vyplnění.

  7. Ales napsal:

    Už tomu trochu rozumím.Já nepoužívám žádné šablony od IB, pouze jsem se jimi inspiroval, zejména v C++ . Komponenta kterou používám běží ve vlastním threadu a zjednodušeně řečeno hlavní program posílá přes ni požadované příkazy a v jejích eventech zpracovává odpovědi od IB.

    Je samozřejmě jedno, v jakém jazyce vytvářím a posílám sockety na TWS, resp. na IB Gateway (to výhradně používám). Když chci otevřít nějaký order, pošlu na IB socket s příkazem PLACE_ORDER (tj. tuším kód 3) a příslušnými parametry. Jakmile je třeba prodejní příkaz proveden a může to být třeba za několik dní (když použiji limitní příkaz a GTC), přijde od IB socket s ORDER_STATUS (též kód 3), který je zpracován v odpovídajícím eventu komponenty a zobrazen v hlavním programu.Tak se dozvím potřebné údaje o plnění. Jsou další eventy kde se dají zjistit podrobnosti exekuce vč. komisí. Nepotřebuji tedy žádnou čekací smyčku. A domnívám se, že by to mělo být obdobně řešitelné i v Pythonu.Ale samostatný thread, jak píšeš, to samozřejmě vyžaduje.

    Čekací smyčku používám snad jen u snapu aktuálního kurzu akcie nebo opce což jednoduše v Delphi provedu vytvořením časovače s příslušným čas. limitem a příkazem repeat Application.ProcessMessage until Výsledek or CASLIMIT.

Napsat komentář

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