IAB: Fragen zur TWS Trader Workstation

Kann mir jemand sagen ob bei IAB auch Depotgebühren oder anderes für Aktien erhoben werden? Oder berechenen die lediglich ihre Tradingcommissions für Aktienan- und verkauf, so wie sich mir das auf deren Website erschliesst?

@ drum [#102]

Ist doch eigentlich ganz nett erklärt.
IB's Dienste orientieren sich an den Anforderungen von professionellen Tradern und Investoren und setzen diesbezüglich auch eine gewisse Handelsaktivität seitens der Kunden voraus, welches sich in bestimmten Kommissionen, Marktdaten Gebühren und anderen Gebühren niederschlägt. Diejenigen Kunden, welche weniger als die monatliche Mindestkommission generieren (siehe Tabelle), werden für die Differenz zwischen ihrer tatsächlichen Kommission und IB's Mindestkommissionsbetrag entsprechend aufkommen müssen.

Neben den Mindestkommissionen werden dem Kunden zusätzlich die von den jeweiligen Börsen erhobenen Marktdatengebühren weitergereicht. Dies geschieht bei all jenen Märkten, für welche sich der Kunde entschieden hat. Kunden die US Non-Professional Echtzeit Daten abonnieren bekommen die Mindestkommission von USD 10 (oder USD Equivalent) erlassen, wenn Sie monatlich eine Kommission von USD 30 (oder USD Equivalent) oder mehr generieren.
http://www.interactivebrokers.com/de/accounts/fees/minimumDeposits.php?ib_entity=de

@ AAA [#103]

Ok, danke! Also tatsächlich keine Depotgebühren erkennbar!

@ AAA [#103]

danke für die gute Erklärung, anzumerken sei noch das die Echtzeit-Daten soweit ich das verstehe aber Snapshots sind, alle 0.7 sec wird upgedatet; IB ist halt Broker und kein Datenlieferant. Dies für alle die zum Beispiel Software wie NinjaTrader, MetaStock, Investoxx, TradeStation usw. an die TWS dranhängen wollen, auch der Backfill ist eingeschränkt!

Beste Grüße

Roti

@ Roti [#105]

IAB als Broker liefert Backfilldaten nur bis 1sec "Bar's", also hier werden Ticks immer zusammen gefasst.

Das mit den 0,7sec stimmt nicht mehr. Intern arbeitet die TWS jetzt wohl mit dem Speed des FIX Interfaces von 150Messages/sec. IAB liefert aber extern per TWS-API nur bis 50Messages je Sekunde an externe Applikationen (z.B. NinjaTrader, MetaStock, Investoxx, TradeStation,... ).
Bei guter INET Verbindung und schnellem IAB Server liefert IAB so auchmal 4 Ticks pro Sekunde für ein Symbol(ok... real waren es über 10 im T&S der Börse).

IAB erfaßt zumindest das reale Volumen, die Tagessummen der gelieferten Ticks stimmen recht gut mit den Schlusswerten der Börsen. (Viele API Programme sind aber nicht in der Lage, die IAB Messages der API "richtig" zu dekodieren. IAB macht einen Unterschied, ob sich Preis&Volumen oder nur das Volumen zum gleichen "Lastkurs" ändert oder gleichbleibt und liefert verschiedene Nachrichten die man dann mit eigenem "Lastpreispuffer" richtig auswerten muss. Programme die das nicht beachten zählen das Volumen FALSCH oder haben zuviele/zuwenig Ticks mit falschen Preisen !!!)

Wichtiger ist aber (für mich) im realen Handel bekommt man stets aktuelle Preis mit recht konstanter Geschwindigkeit. Auch im schnellen Markt kann man so real handeln, denn was nützen "alle" Ticks die wegen Überlastung der Übertragungsstrecke sich ansammeln und alle "garantiert" hinterenander ankommen... Dann habe ich sekundenlang keinen aktuellen Kurs, nur weil erst alle alten bei mir eintrudeln müssen. Im Backfill ist das zwar sehr gut, aber im realen Handen unbrauchbar. VWD/TPRT machen das so... für den RT Handel ungeeignet.

-> Wer mit IAB 50 oder mehr Symbole mit Kursticker im API offen hat, darf sich nicht wundern, warum per API das Ordern plötzlich mal 1sec länger dauert...

-> IAB ist zum Handeln gut bis sehrgut, die Gebühren / Kosten sind ok. Backfill-Datenfeeds gibt es bessere.
Separate Realtimedatenfeeds gibt es ein paar auch günstig und besser sind, aber die Gefahr von unkalkulierbar verzögerten Datenfeeds ist größer wie die Variante von IAB zumindest jede Sekunde "einen" aktuellen Kurs zu haben.

-> IAB mit manueller TWS ist gut und sicher. Ich wage aber die Behauptung, das nur ein Drittel der Programme mit TWS-API Anbindung "sicher" sind. (mit offenen Orders Ausschalten und wieder einschalten, vom Programm erzeugte Positionen mit manuellen Orders in der TWS abgleichen, Orders von fremden/weiteren API-Programmen beachten...)

-> IAB-TWS mit mehreren externen API Programmen kann zu sehr seltsamen Effekten führen, weil jeder "alles" machen kann. Kein seriöses Programm will absichtlich den Account oder andere Programme ungewollt beeinflussen, aber es passiert. Das ist der "Preis" des offenen einfachen API. PAT's ist da restriktiver, API bekommt man nur selektiv freigeschaltet und zahlt die "Prüfung". J-Trader gilt so im prof. Umfeld aber auch als sehr sicher, weil eben weniger Risikopotential in der Nutzung weiterer Programme liegt.

=> IAB ist günstig für alle, die Wissen was sie tun und sich notfalls selbst helfen können. Daten-/Order-/Depotgebühren... alles ok, man muss aber das Gesamtpaket lieben um glücklich zu sein:)

@ TimeTrade [#106]

Mit welchem der APIs hast Du denn die besten Erfahrungen gemacht? Ich meine in bezug auf Stabilität, nicht Komfort. Eine simple, robuste DLL, am besten ohne die TWS im Hintergrund zu benötigen, scheint ja leider nicht verfügbar zu sein.

@ Livetour [#107]

Ich nutze seit Jahren bis heute das IAB-TWS API auf Socketebene, also nur TWS ohne weitere DDE/DLL/ActiveX. Es ist sicher, reconnectfähig und "überschaubar".
IAB FIX hab ich auch auf einem Accout, ist aber nur schneller und mein Programm benötigt die TWS weiter zur LIVE-Accoutabfrage.

Einen Broker mit purer FIX Schnittstelle habe ich nicht selbst. Da gibt es dann die Lösung, dass man kein Programm vom Broker mehr auf dem Rechner hat und alles in eine kleine DLL packen kann. Selbst Reuters und Bloomberg nutzen aber lieber eine "LocalAPI".

Stabilität kommt nicht aus der API sondern aus dem, was man draus macht. Der Komfort kommt dann von ganz allein, denn was sicher ist, ist meist auch einfach und verständlich nachvollziehbar.

Ich habe nun einige Jahre ein Programm/DLL von @Osten genutzt. War gut, aber etwas kompliziert seine Orders erst in binäre Strukturen zu packen und zu übergeben. Restart war möglich, auch ohne Datenbank, weil Brackets im Infofeld die Daten quasi bei IAB speichern. Problem waren aber immer nachvollziehbar automatisierbare Reaktionen auf schnelle Teilfills und Richtungsänderungen/Orderänderungen mitten in Teilfills.

@Osten hat das Problem jetzt in seinem neuen Gemeinschaftsprojekt sicher gelöst und hat ein Positionsmanagement mit Orderinterface entwickelt, was sogar als simple DLL läuft. Selbst ein TradeStation Script kann sich jetzt auf das Erzeugen von simplen Orders mit oder ohne Pyramiden/gestuften Stops beschränken und sagen:

-ich will gestuft 5 Long mit geteiltem Stop 4/1:
LimitEntry(3,4000) LimitEntry(2,3950) ExitStop(-4,3800) ExitStop(-1,3700)

-und dann gestuft drehen auf -4 Short mit geteiltem Stop 2/2:
LimitEntry(-3,4600) LimitEntry(-1,4650) ExitStop(2,4800) ExitStop(2,4850)

Der Trick an der Sache ist, es funktioniert IMMER, egal wie die aktuelle Position im Markt ist. Teilfills, Restart, Wiederholte Orderaufgabe,... wird alles sauber gehandelt und in echte IAB Brackets aufgeteilt. Es gibt also nie ungesicherte Orders (wenn man das aktiviert und mit Stops arbeitet, bzw. wenigstens ganz weite Notstops nutzt).

LiveKurse und "LivePosition" lassen sich per DLL und/oder Event abfragen.
TS Scripts in Easylanguage werden plötzlich ganz einfach, kein Problem mehr mit der Angst vor Doppelorders nach Restart zu bekommen.
Systeme werden viel einfacher, denn sie sagen nur noch wohin sie odern wollen, also z.B. Long 5. Was vorher war / aktuell ist muss man hier nicht mehr beachten. Bei Neustart einfach das letzte Signal nochmal errechnen und wieder Long 5 sagen(wenn schon +5 dann passiert nichts, sonst wird die passende Gegenorder/Zielorder/Absicherung in den Markt gegeben).
Schnelle Systeme werden einfacher, weil diese nur noch aus LiveTicks/LiveBars Signale erzeugen müssen und diese egal ob Fill oder Wartestellung von Orders jederzeit ändern können(Preis/Size/Stufen..). Manuell würde man bei vielen gestuften Brackets garnicht mehr über schauen, ob denn nun jede Stufe korrekt abgesichert ist, wenn man Sizeänderungen selbst machen wollte ohne zu irgend einem Zeitpunkt über-/unterabgesichert zu sein.
"Optimierte" Orderänderungen sind billiger wie ständiges löschen & neuaufgeben aller Orders mit neuen Werten. Manuell oder mit externen Signalen ist das nicht zu machen, da kümmert man sich ja besser um den Markt.

Wie gesagt, sowas ist für mich Stabilität und durchaus mit IAB sicher erreichbar.
Zum Glück paart da jetzt sogar Sicherheit mit Komfort:)

@ TimeTrade [#108]

Danke für Deine ausführliche Antwort. In bezug auf Stabilität hatte ich noch gar nicht an Aufgaben wie gestaffelte Orders o. ä. gedacht, sondern erst mal "nur" an die programmiertechnische Stabilität. Wenn ich mir zum Beispiel ansehe, wie man unter ActiveX eine T&S-Zeile abfragt, dann stellt man zunächst den Request und holt sich die Antwort dann in zwei unterschiedlichen Events ab, von denen noch nicht klar ist, wer in welcher Reihenfolge antwortet. Es kann auch sein, daß sich ein dritter Event meldet, nämlich im Falle eines Fehlers. Ein Fehler kann aber auch auftreten, ohne daß sich überhaupt ein Event meldet, was man dann auch irgendwie abfragen muß, z. B. durch einen eigenen Timeout.

All das läßt sich natürlich durchaus handhaben. Aber es stimmt schon skeptisch, wenn ein nicht unerheblicher Teil der eigenen Programmierung aus Workarounds besteht, die sich auf undokumentierte Features verlassen, von denen man nicht weiß, ob sie in der nächsten IAB-Release überhaupt noch gelten.

Genauso wenig überzeugend finde ich, daß die Programmierbasis ausgerechnet über ein Java-Programm realisiert wird. (Global2 liest hier hoffentlich nicht mit. :) Die Kommunikation mit IAB läuft also beispielsweise über: Eigene Anwendung -> ActiveX-Control -> Java-TWS. Von diesen drei Instanzen würde ich die zwei letzteren am liebsten ersatzlos streichen.

Aber wie dem auch sei. Ich werde dann mal die Socket-Ebene ausprobieren. Danke für den Tip.

@ Livetour [#109]

..."Eigene Anwendung -> ActiveX-Control -> Java-TWS"...
Ich verzichte auf das ActiveX-Control, dies bringt schon sehr viel im Sinne der Versionsunabhängigkeit.
IAB liefert für die Socketkommunikation zwar alles in JAVA & CPP, aber leider ohne stabiles eigenes Multithreading. Das muss man selber schreiben, weil man sonst nicht ohne Aufwand in einem Event auf einen anderen (z.B. eine bestimmte Zeit) warten kann. Für Delphi bietet sich die PASCAL Umsetzung der Socketkommunikation von HHSSOFTWARE an. Läuft stabil im Hintergrund und konvertiert schon alles in passende Daten/Aufzählungstypen.
IAB liefert ja mittlerweile IMMER eine Ferigmeldung für alle Anfragen, früher fragte man die Orders an, bekam dann alle per Event, aber wann schluss war, das musste man raten oder per Trick mit einer kodierten Antwort auf eine Dummymessage lösen... IAB macht das nun von sich aus sicher mit "After" Messages.

Das mit den T&S hast du gut erkannt, und wurde von mir ja auch schon erwähnt, das bei IAB eben "alles" geht. Die Grundfuntionalität hat dabei etwas gelitten. Man kann alles selbst machen, oder man nimmt lieber etwas, was andere in mühevoller Kleinarbeit etwas "menschenfreundlicher" gemacht haben. @Osten hat wohl zuzweit mit das gesamte letzte Jahr daran gearbeitet, eine narrensichere und sehr schnelle Lösung zu schaffen.

Ob du dir das auch komplett selbst antun willst, das musst du entscheiden. Ich werde mir das nicht antun, denn das Orderinterface samt restartfähigem Positionsmanagment gibt es für kleines Geld zu kaufen. Man ersetzt quasi das "dumme ActiveX" gegen ein direktgekoppeltes HIGH-Level-Funktionsinterface. Ich werde meinen Kunden zukünftig wohl diese Lösung empfehlen und einbauen.

Ich mache zwar alles per IAB, war bei neuem aber auch einfach nur zu faul, meine Software die sehr direkt mit IAB verbunden war zum Probieren einfach mal auf ein neues API umzustellen. Ein HIGH-Level-API hat den Vorteil, das es möglich ist, andere Broker oder Datenquellen zu nutzen, ohne das die Handelssoftware das unbedingt mit bekommen muss. @Osten liefert z.B. zum Test einen eigenen Broker, welcher quasi als "Börse" mit Hilfe eine T&S-Tickdatenbank historische Backtests ermöglicht und dabei auch als Datenquelle für die Ticks dient. Papertrading von IAB ist ja immer nur LIVE... Tickbasiertes Playback für eigene Systeme mit echter Accoutsimulation hat sonst ja nur TS mit Globalserver und das ist auf Tickbasis unerträglich langsam...

Das IAB API ist gut, aber es braucht noch "etwas" drumherum um es sinnvoll zu nutzen und sich dabei auf das Wesentliche konzentrieren zu können. Eine zu "feste" Bindung an eine Broker hat auch Nachteile, das habe ich selbst erlebt, weil dann eben die vielen kleinen Workarounds und undokumentierte Features (die sich meist an vielen Stellen verteilt haben) stören.

Aus meiner Sicht ist eine Zwischenschicht also sinnvoll. Funktional und oder als Klassenkonzept, das ist egal. Eine DLL mit ein paar HIGH-LEVEL-Funkionen ist für exterene Programme/Scripts die beste Lösung.
Ein public Klassenkonzept mit von "CustomAPI..." abgeleiteten Broker, Daten, Account... ist für integrierte Applikationen sicher das sauberte, nur nehme ich dann hier lieber wieder eine Quelltextabhängigkeit in den Datenstrukturen und Events in Kauf, als das ganze nochmals über "Interfacees" zu kapseln. Ist Geschamckssache, aber mir ist da Speed wichtiger als absolut gesichterte & saubere objektorientierte Kapselung.

API Design & Nutzungskonzept ist harte stupide Grundlagenarbeit, um die ich mich selbst am liebsten drücke ;)

@ TimeTrade [#110]

Die Komponente von HHS Software ist mir auch schon aufgefallen. Irgendwo fand ich auch den Hinweis, daß irgendwer eine einzige kompakte C-DLL geschrieben hat. Unter der angegebenen Adresse auf SourceForgeNet war allerdings noch nichts downzuloaden.

Ich glaube, ich werde es "mir selbst antun", nicht weil ich glaube, daß ich es unbedingt besser könnte, sondern weil es vorteilhaft ist, soviel wie möglich des Systems zu kennen und zu kontrollieren.

Trotzdem: Du sagst, Osten verkauft mittlerweile seine Software? Gibt es dazu Informationen im Web?