Un arbitrage difficile : y a-t-il de la vie sur Mars ? - page 9

Nouveau commentaire
 

pour plus de clarté, nous devons écrire un indicateur simple, qui montrerait sur un graphique sous forme de lignes horizontales colorées Aska et Bids des paires prédéfinies dans ses paramètres et leurs synthétiques (par exemple, sur les Euribucks et 2 Yen mentionnés précédemment)...


et vous verrez tout d'un coup et clairement !

 

C'est dommage... Les opportunités se présentent assez souvent mais mon API n'a pas le temps de se connecter alors que je suis assis à 8ms de ping vers le site.

Je devrais probablement mettre le robot API directement sur le pad...

Cela représente un bénéfice de 2 pips - le coût d'environ 1 pip sur trois paires, soit 0,1 lot, peut rapporter une livre.

Le temps d'exécution de la démo est d'environ 16 ms(GetTickCount), ou du moins c'est ce qu'il semble pour un ordre (cela prend déjà en compte le trafic).

... Je vais essayer de paralléliser les commandes, c'est-à-dire de les envoyer de manière asynchrone peut gagner quelque chose

Et c'est seulement quelques minutes ....

 
Est-ce que cela a un sens d'essayer d'attraper une situation d'arbitrage avec le moins de dérapage possible et d'effectuer un ping en microsecondes ? Bien sûr, c'est la meilleure option, mais... Je pense que quelqu'un l'a fait pour nous, c'est certain (ceux qui paient des milliers et des dizaines de milliers de dollars par mois pour des interconnexions optiques) et a presque certainement enlevé le maximum de liquidités disponibles au moment de la situation d'arbitrage... Mais encore une fois "MAIS" ... Les positions sont "verrouillées" - c'est-à-dire ouvertes dans une couverture multidevises ! Elles peuvent donc rester en place aussi longtemps qu'elles le souhaitent sans augmenter le drawdown dû au montant de leur spread à l'ouverture ... et y restera sûrement jusqu'à une situation de renversement (lorsque l'offre et la demande deviennent inverses et que la position totale clôturera dans le noir même en tenant compte du slippage, des swaps, des commissions et autres frais ... ! ! )
 
SLAWIK:
Est-ce que cela a un sens d'essayer d'attraper une situation d'arbitrage avec le moins de dérapage possible et d'effectuer un ping en microsecondes ? Bien sûr, c'est la meilleure option, mais... Je pense que quelqu'un l'a fait pour nous, c'est certain (ceux qui paient des milliers et des dizaines de milliers de dollars par mois pour des interconnexions optiques) et a presque certainement enlevé le maximum de liquidités disponibles au moment de la situation d'arbitrage... Mais encore une fois "MAIS" ... Les positions sont "verrouillées" - c'est-à-dire ouvertes dans une couverture multidevises ! Elles peuvent donc rester en place aussi longtemps qu'elles le souhaitent sans augmenter le drawdown dû au montant de leur spread à l'ouverture ... et y restera sûrement jusqu'à une situation de renversement (lorsque l'offre et la demande deviennent inverses et que la position totale clôturera dans le noir même en tenant compte du slippage, des swaps, des commissions et autres frais ... ! ! )
Si l'on doit capturer des brochets au lieu de plancton (pépins simples), que ce soit par kilos. Et les kilos / par heure ne sont pas observés. Les risques de non-exécution (exécution intempestive) réduisent tous les efforts à zéro, voire à zéro. Le mieux qu'il puisse faire est de minimiser l'écart grâce à une sélection intelligente de paires de devises spécifiques pour ouvrir des positions multidevises à un moment précis. Mais en règle générale, la priorité stupide accordée aux "Majors" et les économies réalisées sur les coûts de conversion du dépôt dans la paire de devises (vous devez payer pour cela !) conduisent à une victoire primitive du schéma "toujours ouvrir sur les Majors et garder le dépôt en dollars". La difficulté de rattraper des pips sur un "arbitrage complexe" n'en vaut pas la peine. Il vaut mieux créer un agrégateur pour négocier avec plusieurs courtiers simultanément (avec sélection dynamique du "meilleur" courtier pour chaque transaction) - pas beaucoup plus de travail, mais beaucoup plus de poissons d'arbitrage. Mais il y a un autre problème - la compensation des lots entre les courtiers, mais il est soluble, bien que pas facile et avec des coûts.
 
le plancton est mesuré en kilogrammes ... Pas par heure, mais par jour - stable.13
 
SLAWIK:
le plancton se mesure exactement en kilogrammes... mais pas par heure, mais par jour -- de façon constante.

Plancton est encaissé ? Ou s'agit-il d'un test/démo ?

--

"Ce n'est pas vraiment ce dont ça a l'air..." ;)

 

Eh bien, le commerce entre différents fournisseurs impliquant la compensation est wooooo ! (il faut beaucoup d'argent)...

.... Vous avez besoin d'un compte auprès d'une banque de compensation avec des fournisseurs de liquidités (par exemple, RaboBank)... .... passe un accord personnel avec chacun d'eux ... ....write multi-level API ( commun à tous les fournisseurs ) ...

.... Les fournisseurs se désistent parfois et il faut en trouver d'autres... etc... etc...

 
SLAWIK:

La seule façon de le faire est d'ouvrir un compte dans une banque de compensation où se trouvent également des comptes de fournisseurs... ....faire un contrat personnel avec chacun d'eux ... écrire une API à plusieurs niveaux (commune à tous les fournisseurs) ...

...les fournisseurs se retirent occasionnellement et il faut en trouver de nouveaux... etc...

Rien de tout cela n'est nécessaire. Tout devrait être là, dans l'agrégateur, et en pilotage automatique. L'essence est la même. Je vais montrer un exemple élémentaire (unique), et l'utiliser pour expliquer.

Supposons que nous (notre TS) ouvrons une transaction BUY sur EURJPY via l'agrégateur. L'agrégateur reçoit une demande, cherche/trouve le meilleur courtier au moment présent et commande au terminal approprié (courtier A) d'envoyer cette demande. L'ordonnance est satisfaite en conséquence (en cas de succès). Lorsque cette transaction est clôturée (contre-ordre de VENTE), dans le cas général, un courtier complètement différent(B) pourrait être "meilleur". Un problème de LOC entre courtiers se pose : le négociant a fermé toutes les transactions, il n'y a pas de problème, mais l'agrégateur a deux ordres opposés chez différents courtiers(A-bay, B-sell). C'est un problème - il faut les fermer d'une manière ou d'une autre. La solution consiste à créer la liste de tous ces lots et à surveiller en permanence les cotations de tous les courtiers bloqués afin de trouver des moments de "quasi-arbitrage" (idéalement de véritable arbitrage, c'est-à-dire avec un profit) pour la contre-fermeture de ces ordres (tout en respectant l'égalité des volumes, bien sûr). C'est tout le nettoyage.

Avec un grand nombre de courtiers sur l'agrégateur et un trading intensif multidevises, il n'y a rien à faire, tout doit être automatisé, et la vélocité est une priorité.

Il n'est pas facile de programmer correctement tous ces éléments dans le monde réel, mais c'est tout à fait possible.

 

Nous avons donc ouvert des positions dans différentes maisons de courtage... (Si nous ouvrions des lots et qu'une des ventes aux enchères décidait d'annuler ceux qu'elle avait (par exemple des lots prétendument " non marchands "...) et alors que faire... ? nous négocions sans compensation ... c'est-à-dire virtuellement - sans couverture en espèces des transactions (comme ce serait le cas dans le cadre d'une négociation avec compensation - le garant de la liquidité)


ou dans l'une des cuisines avec un slippage d'environ 70 pips ! (comme JTX par exemple qui l'aime même avec l'api... et beaucoup d'autres font de même...)

c'est-à-dire que le seul moyen d'y parvenir est de changer le système... c'est-à-dire qu'il n'y a pas beaucoup de choix parmi les sociétés de courtage avec une bonne exécution (et encore moins avec une API ouverte).

 
SLAWIK:

Nous avons donc ouvert des postes dans différents docs... ( Loki ) et que l'une des ventes aux enchères décide d'annuler celles qu'elle a (par exemple les chats prétendument "non marchands" ...) et alors quoi ... ? nous négocions sans compensation ... c'est-à-dire virtuellement - sans couverture en espèces des transactions (comme ce serait le cas dans la négociation avec compensation - le garant de la liquidité)


ou dans l'une des cuisines avec un slippage d'environ 70 pips ! (comme ils le font par exemple sur le JTX, même selon l'api).


Alors ne faites pas un agrégateur. C'est tout. ;) Mona pense qu'une des épaules de "l'arbitrage complexe" que votre cuisine ne peut pas défaire. Ou glisser dans 70 pips. C'est facile.

12345678910
Nouveau commentaire