Uma arbitragem dura - existe vida em Marte? - página 9

 

para maior clareza, precisamos escrever um indicador simples, que mostre em um gráfico na forma de linhas horizontais coloridas Aska e Lances de pares predefinidos em suas configurações e seus sintéticos (por exemplo, no Euribucks mencionado anteriormente e 2 ienes)...


e você verá tudo de uma vez e com clareza!

 

Que chatice... As oportunidades surgem com frequência suficiente, mas meu API não tem tempo para fazer o login mesmo estando eu sentado em um ping de 8ms no site

Eu provavelmente deveria colocar o robô API diretamente sobre a almofada.

Isso seria um lucro de 2 pips - o custo de cerca de 1 pip em três pares que é 0,1 lote pode ganhar uma libra

o tempo de execução da demonstração é de aproximadamente 16 ms(GetTickCount), ou pelo menos é assim que parece para 1 ordem (isto já leva em conta o tráfego)

... Tentarei paralisar as ordens, ou seja, enviá-las de forma assíncrona pode ganhar algo

E são apenas alguns minutos ....

 
Faz sentido tentar pegar uma situação de arbitragem com o mínimo deslizamento possível e ping em microssegundos?! É claro que esta é a melhor opção MAS... Acho que alguém o fez por nós com certeza (aqueles que pagam milhares e dezenas de milhares mensalmente por conexões cruzadas em ótica ...) e quase certamente tiraram a máxima liquidez disponível no momento da situação de arbitragem ... Mas, novamente "MAS" ... As posições são "trancadas" - ou seja, abertas em uma sebe com várias moedas! Assim, elas podem ficar lá o tempo que quiserem sem aumentar o saque devido ao valor de seu spread na abertura ... e certamente ficará lá até uma situação de reversão (quando a pergunta e a oferta se invertem e a posição total se fecha no preto mesmo levando em conta o deslize, as trocas, as comissões e outras taxas ... ! ! )
 
SLAWIK:
Faz sentido tentar pegar uma situação de arbitragem com o mínimo deslizamento possível e ping em microssegundos?! É claro que esta é a melhor opção MAS... Acho que alguém o fez por nós com certeza (aqueles que pagam milhares e dezenas de milhares mensalmente por conexões cruzadas em ótica ...) e quase certamente tiraram a máxima liquidez disponível no momento da situação de arbitragem ... Mas, novamente "MAS" ... As posições são "trancadas" - ou seja, abertas em uma sebe com várias moedas! Assim, elas podem ficar lá o tempo que quiserem sem aumentar o saque devido ao valor de seu spread na abertura ... e certamente ficará lá até uma situação de reversão (quando o pedido e a licitação se tornam inversos e a posição total se fechará no preto, mesmo levando em conta deslizamentos, trocas, comissões e outras taxas ... ! )
Se formos pegar lúcio em vez de plâncton (pips simples), que seja por quilos. E quilos / por hora não é observado. Os riscos de não-execução (execução inoportuna) reduzem todos os esforços a zero, se não a menos. O melhor que o esquema pode fazer é minimizar o spread devido à seleção inteligente de pares de moedas específicos para abrir posições de múltiplas moedas em um momento específico no tempo. Mas como regra geral, a estúpida prioridade de spread para o "Majors" mais a economia nos custos de conversão do depósito no par de moedas (você tem que pagar por isso!) leva a uma vitória primitiva do esquema "sempre aberto no Majors e manter o depósito em dólares". O incômodo de pegar pips em "arbitragens complexas" não vale o esforço. Melhor criar um agregador para negociar com vários corretores simultaneamente (com seleção dinâmica do "melhor" corretor para cada negócio) - não muito mais trabalho, mas muitas vezes mais peixe de arbitragem. Mas há outro problema - a compensação de lotes entre corretores, mas é solvível, embora não seja fácil e com custos.
 
o plâncton é medido em quilogramas ... Não por hora, mas por dia - estável.13
 
SLAWIK:
o plâncton é medido exatamente em quilogramas ... embora não por hora, mas por dia -- consistentemente.

O plâncton é descontado? Ou é um testador/demo?

--

"Não é realmente o que parece..." ;)

 

Bem, o comércio entre diferentes fornecedores envolvendo clearing é wooooo! (você precisa de muito dinheiro)...

.... você precisa de uma conta em um banco de compensação com provedores de liquidez (por exemplo, RaboBank)... .... fazer um acordo pessoal com cada um deles ... ....... Escrever API multinível ( comum a todos os fornecedores ) ...

Os fornecedores do site .... ocasionalmente desistirão e precisarão encontrar novos... etc... etc...

 
SLAWIK:

A única maneira de fazer isso é abrir uma conta em um banco de compensação onde também existem contas de fornecedores... .... fazer um contrato pessoal com cada um deles ... escrever um API multinível ( comum a todos os fornecedores ) ...

...os fornecedores ocasionalmente desistirão e precisarão encontrar novos... etc....

Nada disso é necessário. Tudo deve estar ali mesmo no agregador, e no piloto automático. A essência é a mesma. Vou mostrar um exemplo elementar (único), e usá-lo para explicar.

Suponha que nós (nosso TS) abrimos uma transação de compra de EURJPY através do agregador. O agregador recebe uma solicitação, procura/define o melhor corretor no momento atual e comanda o terminal apropriado (corretor A) para enviar esta solicitação. O pedido é satisfeito de acordo (se bem sucedido). Quando este comércio fecha (contra-venda) no caso geral, um corretor(B) completamente diferente pode ser "melhor". Surge um LOC entre corretores: o negociante tem todas as negociações fechadas, não há problema, mas o agregador tem duas ordens opostas em corretores diferentes(A-bay, B-sell). Isto é um problema - eles precisam ser fechados de alguma forma. A solução é criar a lista de todos esses lotes e monitorar constantemente as cotações de todos os corretores bloqueados, a fim de encontrar momentos de "quase arbitragem" (idealmente realmente arbitragem, ou seja, com lucro) para o contra-fechamento dessas ordens (respeitando a igualdade de volumes, é claro). Tudo isso é clareira.

Com um grande número de corretores no agregador e uma intensa negociação em múltiplas moedas não há nada a fazer, tudo precisa ser automatizado, e a velocidade é uma prioridade.

Não é fácil programar todas essas coisas corretamente no mundo real, mas é bem possível.

 

Assim, abrimos posições em diferentes corretoras. (Se abrirmos lotes e um dos leilões decidisse cancelar aqueles que tinha (por exemplo, lotes alegadamente "não de mercado" ...) e então o que fazer ...? negociamos sem compensação ... ou seja, virtualmente - sem cobertura em dinheiro das negociações (como seria o caso no caso de negociação com compensação - o garantidor da liquidez)


ou em uma das cozinhas com um deslizamento de cerca de 70 pips! (como JTX, por exemplo, gosta mesmo com api... e muitos outros fazem o mesmo...)

ou seja, a única maneira de fazer isso é mudar o sistema... ou seja, não há tanta escolha entre corretoras com boa execução ( e ainda menos com api aberta )

 
SLAWIK:

Assim, abrimos posições em diferentes docs... ( Loki ) e um dos leilões decidiu cancelar aqueles que tem ( por exemplo, supostamente "não-mercado" Gatos ...) e então o que ...? negociamos sem compensação ... ou seja, virtualmente - sem cobertura em dinheiro das negociações (como seria o caso na negociação com compensação - o garantidor da liquidez)


ou em uma das cozinhas com um deslizamento de cerca de 70 pips! (como fazem, por exemplo, no JTX, mesmo de acordo com a api)


Então, não faça um agregador. É isso aí. ;) Mona acha que um dos ombros da "arbitragem complexa" que sua cozinha não pode desfazer. Ou escorregar em 70 pips. Fácil.