Machine learning in trading strategies

Machine Learning e Automated Trading O Big Short (eu gosto) Buscando estratégias de negociação com backtests rentáveis ​​- UPDATE Eu tive algumas conversas muito interessantes desde que eu ofereci o meu quadro de negociação intraday não público em troca de informações sobre estratégias rentáveis, é por isso que eu deseja estender indefinidamente essa chamada inicialmente limitada no tempo. Note que não estou procurando idéias estratégicas. Eu tenho muitos desses eu mesmo. O desafio não está em apresentar uma idéia, mas em escolher o caminho certo e testá-lo até o fim, quando você sabe que funciona ou não. O fator crítico aqui é o tempo. Então, o que eu estou essencialmente negociando é o tempo que eu investi no desenvolvimento de uma estrutura de negociação intraday sólida contra o tempo que você investiu no desenvolvimento de uma estratégia de negociação lucrativa. Pode ser uma estratégia de ações, ETF, futuro ou opção. Todas as discussões e informações trocadas serão mantidas em sigilo. É claro que estou aberto a discutir idéias, mas, por favor, não espere que eu as teste para você e não reclame se eu as implementar sem pedir sua aprovação. Chamada de propostas Buscando estratégias de negociação com backtests rentáveis ​​Até 15 de junho estou aceitando propostas de estratégias de negociação promissoras sobre ações, moedas e índices de ações / títulos / commodities. A estratégia deve ser rentável em backtesting e ter um índice de sharpe anualizado de pelo menos 1,0. No dia 1º de julho, as duas estratégias mais promissoras serão selecionadas e seus autores poderão escolher uma das seguintes opções: 1) Obter uma cópia completa e gratuita da estrutura comercial aprimorada e não-pública baseada em R que desenvolvi e usei desde 2012 e que os autores podem usar para negociação ao vivo suas estratégias com Interactive Brokers. (A versão pública simplificada pode ser baixada aqui) 2) Estabelecer um acordo de cooperação no qual me comprometerei a implementar sua estratégia em R e negociá-la por no máximo três meses. Todas as negociações individuais serão compartilhadas com os autores quando ocorrerem. Além disso, o código R específico da estratégia (não o código da estrutura de negociação) será entregue aos autores da estratégia. O que enviar: Uma descrição por escrito da estratégia mais uma lista de negociações mais as séries de tempo de retorno do código backtest ou R / octave / python executável que calcula diretamente as séries de tempo de retorno do backtest, juntamente com o conjunto de dados completo de preços usado no backtest. Enviar para o meu e-mail disponível na seção de contato Atualização do R R Intraday Trading Framework Finalmente eu encontrei o tempo para fazer isso. Muito atrasado. A estrutura agora é executada com as versões mais recentes (unix) do IB TWS / GW (versão 9493 e superior). Isso por si só requereu uma reescrita parcial de várias funções do excelente, mas agora um pouco desatualizado, pacote IBrokers R, de Jeff Ryan. Além disso, a configuração padrão para o comércio do EURUSD foi atualizada, de modo que agora é fácil executar a estratégia simulada de exemplo. Basta clonar o repositório git em sua máquina local. github / censix / INTRADAY-PartAB e siga o README. Algo sobre Hardware Eu ainda sou fã de possuir meu próprio metal. Claro, fazer coisas com imagens de máquina configuráveis ​​na nuvem é popular porque você não precisa passar pelo incômodo de gerenciar seu próprio hardware, mas isso não é um problema para grandes organizações, onde centenas / milhares de usuários precisam ser mantidos feliz a um custo mínimo. Então a nuvem não é apenas uma solução para um problema de pessoas que precisam gerenciar a escala, mas ao mesmo tempo estão tentando vender essa solução para o indivíduo que está lá fora, que, vamos encarar isso, realmente não precisa disso. Enfim, como eu disse, sou fã de ter meu próprio metal. O hardware de baixo custo barato pode ajudar muito se você tiver tempo para configurá-lo adequadamente. Um desktop RAM de 16 a 64 Gb com uma ou até duas GPUs fará praticamente qualquer coisa que você precisar. Parece que as estratégias de backtesting usam muito mais recursos de computação do que a negociação ao vivo real, e é por isso que você pode configurar e executar uma estratégia intradiária de qualquer laptop decente com confiança, enquanto para o backtesting e pesquisa você realmente quer o monstro CPU GPU de RAM acima ou um pequeno pequeno supercomputador de sua preferência, como descrevi recentemente aqui. Puro R Intraday trading framwork Full download available Eu fiz INTRADAY-PartA. tar. gz e INTRADAY-PartB. tgz disponível para download. censix / downloads. html Encontrando relações entre ativos que podem ser usados ​​para arbitragem estatística Em vez de se concentrar em prever direção de preço e volatilidade de preço com modelos não lineares derivados de métodos de aprendizado de máquina, uma alternativa seria tentar descobrir relações de preço exploráveis ​​entre ativos do mesma classe e reagem (comércio) quando ocorre o erro de cálculo, ou seja, fazem arbitragem estatística. De certa forma, isso é de alguma forma mais fácil do que tentar prever preços, já que a única coisa que uma pessoa precisa fazer é encontrar um relacionamento relativamente estável, linear ou não linear entre um grupo de pelo menos dois ativos e assumir que, do tempo de sua detecção, essa relação continuará por algum tempo no futuro. Negociar sob essa hipótese é, então, um processo muito reativo que é acionado por movimentos de preço que divergem significativamente da relação modelada. Par tradicional O comércio e a negociação de ativos em um relacionamento VECM (Vector Error Correction Model) são bons exemplos para o statarb usando modelos lineares. Então, por que não usar uma rede neural simples de uma camada ou até mesmo um RBM para descobrir uma relação de preço não linear entre dois ativos não cointegrados e se esse processo de descoberta for bem-sucedido, troque-o de maneira semelhante a um par clássico. As coisas se tornam ainda mais interessantes quando grupos com mais do que apenas dois ativos são considerados. Este seria então o equivalente não linear de um VECM. Seleção de Recursos Amplitude vs. Profundidade Digamos que temos um alvo de predição de timeseries univariado que pode ser do tipo regressão ou classificação, e temos que decidir quais recursos de entrada selecionar. Mais concretamente, temos um grande universo de timeseries que podemos usar como entradas e gostaríamos de saber quantos nós deveríamos escolher (largura) e também quanto tempo atrás nós queremos procurar por cada um (profundidade). Há um espaço bidimensional de escolhas, delimitado pelos quatro casos extremos a seguir, sob a suposição de que temos um total de N series e podemos, no máximo, olhar para K timesteps: (1) escolher apenas uma série e lookback um timestep, (2) seleciona apenas uma série e cronometra K timesteps, (3) escolhe N series e lookback one timestep, (4) escolhe N series e lookback K timesteps. A escolha ideal provavelmente não será uma delas, já que (1) e (2) podem não conter informações previsíveis suficientes e (3) e especialmente (4) não serão viáveis ​​devido a contstraints de computação ou conterão muito ruído aleatório. A maneira sugerida de abordar isso é começar pequeno em (1), ver qual é o desempenho obtido e aumentar o tamanho do espaço de entrada, seja em amplitude ou em profundidade, até atingir um desempenho de previsão satisfatório ou até que você tenha esgotado seus recursos de computação e precisam abandonar toda a abordagem :( ou comprar um novo (farm of) desktop (s) :) Usando Autoencodificadores Empilhados e Máquinas Boltzmann Restritas em R 12 de fevereiro de 2014 Autoencodificadores Empilhados (SAs) e Máquinas Boltzmann Restritas ( RBMs) são modelos muito poderosos para aprendizado não supervisionado. Infelizmente, no momento em que escrevo, parece que não há implementações diretas de R disponíveis, o que é surpreendente, já que os dois tipos de modelos já existem há algum tempo e R tem implementações para muitos outros tipos de modelos de aprendizado de máquina. Como solução alternativa, os SAs poderiam ser implementados usando um dos vários pacotes de redes neurais de R com bastante rapidez (nnet, AMORE) e RBMs, bem, alguém teria que escrever uma boa implementação de R para eles. Mas, dado que o treinamento de ambos os tipos de modelo requer muitos recursos computacionais, também queremos uma implementação que possa fazer uso das GPUs. Então, no momento, a solução mais simples que parece ter é usar Theano. Ele pode usar GPUs e fornece implementações de autoencodificadores e RBMs empilhados (denoising). Além disso, o código Python / Theano para várias outras variantes mais exóticas da Máquina Boltzmann está flutuando na rede também. Podemos usar o rPython para chamar essas funções do Python de R, mas o desafio são os dados. Obter grandes conjuntos de dados entre o R e o Python sem usar a serialização ascii que o rPython implementa (muito lento) precisa ser resolvido. Uma implementação pelo menos igualmente potente dos autoencodificadores que suportam o uso da GPU está disponível através do framework Torch7 (demo). No entanto, as funções Torch7 são chamadas usando lua e chamá-las de dentro de R, em vez disso, requer algum trabalho no nível C. Em conclusão: Use Theano (Python) ou Torch7 (lua) para treinar modelos com suporte a GPU e escreva os modelos treinados para arquivar. Em R, importe o modelo treinado do arquivo e use para previsão. Atualização de 25 de abril de 2014: A solução agradável a seguir Chame o Python de R a Rcpp deve nos aproximar um passo do uso de Theano diretamente de R. Quais freqüências para o comércio. January 13, 2014 Ao tentar encontrar padrões de mercado exploráveis ​​que poderiam ser negociados como um comerciante de varejo, uma das primeiras perguntas é: Quais frequências de negociação devem ser observadas? Mensal Semanalmente Diário Ou intradiário em qualquer lugar entre 5 segundos a 1 hora Ao realizar pesquisas em todas essas escalas de tempo, isso se torna uma questão importante a ser respondida. Eu e outros observamos que parece haver uma relação simples entre frequência de negociação e quantidade de esforço necessário para encontrar uma estratégia lucrativa que seja puramente quantitativa e tenha um risco aceitável. Resumindo: quanto mais baixa (mais lenta) for a frequência com a qual você deseja negociar, mais inteligente será sua estratégia lucrativa. tradefreqvssmartness Como exemplo, poder-se-ia olhar para a (muito) alta frequência do espectro, onde as estratégias de mercado baseadas em matemática realmente muito simples podem ser muito lucrativas, se você conseguir estar perto o suficiente do mercado. Tomando um grande salto para o domínio da frequência diária, está se tornando muito mais difícil encontrar estratégias quantitativas que sejam lucrativas e ainda sejam baseadas em matemática bastante simples. Negociar em intervalos semanais e mensais, usando métodos quantitativos simples ou apenas indicadores técnicos é uma receita muito boa para o desastre. Assim, supondo por um momento que essa relação é realmente verdadeira e também considerando que podemos e queremos usar técnicas sofisticadas de aprendizado de máquina em nossas estratégias de negociação, podemos começar com uma janela de frequência semanal e trabalhar em direção a freqüências mais altas. A negociação semanal não precisa ser automatizada e pode ser feita a partir de qualquer interface de corretagem baseada na web. Poderíamos desenvolver uma bolsa de estratégias, usando dados históricos publicamente disponíveis em combinação com nosso algoritmo de aprendizado favorito para encontrar padrões de mercado negociáveis ​​e depois executar a estratégia manualmente. Nessa escala, todo o esforço deve ser feito para encontrar e aperfeiçoar a estratégia quantitativa, e muito pouca necessidade de pensamento deve ser colocada na execução comercial. Esforço de automação comercial: 0. Estratégia inteligente exigida: 100 A negociação diária deve ser automatizada, a menos que você possa realmente dedicar uma parte fixa do seu dia ao monitoramento dos mercados e à execução de negociações. A integração de algoritmos de aprendizado de máquina com negociações diárias automatizadas não é uma tarefa trivial, mas pode ser feita. Esforço de automação comercial: 20, Estratégia inteligente exigida: 80 Em escalas de tempo intraday, variando de minutos e segundos a sub-segundos, o esforço que você terá que empreender para automatizar seus negócios pode estar em qualquer lugar na faixa entre 20 e 90. Felizmente a escala de tempo torna-se o mais burro que sua estratégia pode ser, mas é claro que um conceito relativo é um idiota. Esforço de automação comercial: 80, Inteligência de estratégia exigida: 20 Quais recursos usar. Feito à mão versus aprendido 10 de dezembro de 2013 Em um ponto do projeto de um sistema de aprendizado (de máquina), você inevitavelmente se perguntará quais são os recursos para alimentar seu modelo. Existem pelo menos duas opções. O primeiro é usar recursos feitos à mão. Esta opção normalmente lhe dará bons resultados se os recursos forem bem planejados (isso, é claro, é uma tautologia, já que você só os chamaria de bem projetados se eles lhe dessem bons resultados). O design de recursos manuais requer conhecimento especializado sobre o campo ao qual o sistema de aprendizagem será aplicado, ou seja, classificação de áudio, reconhecimento de imagem ou em nosso caso de negociação. O problema aqui é que você pode não ter nenhum conhecimento especializado (ainda) e será muito difícil passar por aqui ou levar muito tempo ou, muito provavelmente, ambos. Portanto, a alternativa é aprender os recursos dos dados ou, em outras palavras, usar o aprendizado não supervisionado para obtê-los. Um requisito aqui é que você realmente precisa de muitos dados. Muito mais do que você precisa para recursos feitos à mão, mas, novamente, ele não precisa ser rotulado. O benefício, no entanto, é claro. Você realmente não precisa ser um especialista no campo específico para o qual você projeta o sistema, ou seja, comércio e finanças. Então, enquanto você ainda precisa descobrir qual subconjunto dos recursos aprendidos será melhor para o seu sistema de aprendizado, isso também é algo que você teria que fazer com os recursos feitos à mão. Minha sugestão: tente criar alguns recursos criados por você mesmo. Se eles não se apresentarem e você tiver bons motivos para acreditar que é possível obter melhores resultados do que aqueles que está obtendo, use métodos de aprendizado não supervisionados para aprender recursos. Você pode até criar um sistema híbrido que usa recursos projetados e aprendidos juntos. Por que eu uso ferramentas Open Source para construir aplicações comerciais 19 de novembro de 2013 Quando comecei a investigar minha própria negociação automatizada, eu tinha três requisitos sobre o conjunto de ferramentas que eu queria usar. 1) Eles devem custar o mínimo possível para eu começar, mesmo que isso significasse que eu tivesse que fazer muita programação e customizações eu mesmo (isso custaria tempo) 2) Deveria haver uma comunidade de pessoas com ideias afins por aí usando essas mesmas ferramentas para um propósito similar. 3) As ferramentas devem permitir que eu vá tão fundo nas entranhas do sistema quanto necessário, mesmo que no começo o meu objetivo fosse mais descobrir o básico. Eu não queria me encontrar em uma situação onde, dois anos depois, eu precisaria mudar para um conjunto diferente de ferramentas, só porque as que eu tinha começado não me permitiram fazer o que eu queria por causa de problemas com fontes fechadas e licenciamento restritivo. Como resultado, decidi escolher o R ​​como meu idioma preferido para o desenvolvimento de algoritmos comerciais e comecei a usar o Interactive Brokers, já que eles fornecem uma API para fazer interface com o sistema de corretagem. Embora existam muitas ferramentas comerciais interessantes que se conectam ao IB Trader Workstation e algumas podem ser usadas para negociação automatizada, nenhuma delas oferece o mesmo poder, flexibilidade e suporte da comunidade que o projeto R. tem. Além disso, o R tem realmente um repositório incrível de pacotes estatísticos e de aprendizado de máquina gratuitos e muito avançados, algo essencial para criar algoritmos de negociação. Copyright copy Censix 2013 - 2015Curso de Aprendizagem para Negociação de Máquinas Este curso apresenta aos alunos os desafios do mundo real de implementar estratégias de negociação baseadas em aprendizado de máquina, incluindo as etapas algorítmicas desde a coleta de informações até ordens do mercado. O foco está em como aplicar abordagens de aprendizado de máquina probabilísticas às decisões de negociação. Consideramos abordagens estatísticas como regressão linear, Q-Learning, KNN e árvores de regressão e como aplicá-las às situações reais de negociação de ações. Este curso é composto por três mini-cursos: Nota importante Este curso aumenta as dificuldades no final. Os projetos no final 1/3 do curso são desafiadores. Esteja preparado. Informações sobre o instrutor Tucker Balch, Ph. D. Professor, Computação Interativa na Georgia Tech Designer de Curso CS 7646 CS 7646 Instrutor: Primavera 2016, Outono 2016 David Byrd Research Cientista, Centro de Tecnologia de Mídia Interativa na Georgia Tech CS 7646 Instrutor: Verão de 2016 CS 7646 Diretor TA: Primavera 2016, outono 2016 Syllabi e cronograma para semestres específicos Textbooks, Software amp Outros recursos Usaremos os seguintes livros didáticos: Para Mini-curso 1: Python for Finance por Yves Hilpisch amazon (opcional) Para Mini-curso 2: What Hedge Funds Really Do por Romero e Balch amazon ( obrigatório) Para Mini-curso 3: Machine Learning por Tom Mitchell (opcional) Compre-o para 218.00 em: amazon Compre uma versão em brochura para 61.78. AVISOS IMPORTANTES: 1) Eles só enviam para os EUA 2) Demora 3 semanas para imprimir o livro. Se você fizer pedidos de fora dos EUA, eles aceitarão seu dinheiro tranquilamente, mas nunca enviarão o livro: versão mais barata no mcgraw hill Compre uma versão internacional em brochura para 19.10. Não tenho certeza sobre a confiabilidade desta empresa: Pré-requisitos / Co-requisitos internacionais Todos os tipos de alunos são bem-vindos Os tópicos de Aprendizado de Máquina podem ser revisados ​​para estudantes de Ciências, enquanto partes de finanças serão revisadas para estudantes de finanças. No entanto, mesmo que você tenha experiência nesses tópicos, descobrirá que os consideramos de uma maneira diferente da que você poderia ter visto antes, em particular com um olho na implementação para negociação. Se você responder não às seguintes perguntas, pode ser benéfico atualizar seu conhecimento do material de pré-requisito antes de tomar CS 7646: Você tem um conhecimento prático de estatísticas básicas, incluindo distribuições de probabilidade (como normal e uniforme), cálculo e diferenças entre média, mediana e modo Você compreende a diferença entre média geométrica e média aritmética Você tem fortes habilidades de programação Faça este quiz compinvesti-prog-quiz se você gostaria de ajudar a determinar a força de suas habilidades de programação. Para quem é este curso: O curso destina-se a pessoas com forte experiência em programação de software e conhecimento de nível introdutório sobre práticas de investimento. Um pré-requisito primário é um interesse e entusiasmo sobre o mercado de ações. Software bem usado: Para concluir as tarefas de programação, você precisará de um ambiente de desenvolvimento com o qual esteja familiarizado. Usamos o Unix, mas você também pode trabalhar com ambientes Windows e Mac OS. Você deve baixar e instalar um conjunto de módulos Python em seu computador (incluindo NumPy, SciPy e Pandas). OMSCS: Usaremos o Udacity para vídeos de palestras. Entre aqui usando sua conta GT: GT-Udacity Login (vídeo de instrução) Nota. NÃO faça o login usando sua conta Udacity pessoal, caso você tenha uma. Vá para o curso em Udacity (ou navegue pelos Meus Cursos): udacity / course / viewer / c-ud501 Se você tiver problemas para acessar o conteúdo Udacity, por favor, compartilhe seu problema via e-mail com gtech-supportudacity Usaremos T-Square para ALL submissões: T-Square (escolha o local do curso apropriado) Usaremos o Piazza para interação e discussão: Outono de 2016 Piazza forum A: 90 e acima B: 80 e acima C: 70 e acima D: 60 e acima F: abaixo de 60 Estudantes o passe / falha do curso deve ganhar pelo menos 75 para passar. O curso não pode ser tomado como auditoria. Veja o programa semestral para pesos de atribuição. Requisitos técnicos mínimos Navegador e velocidade de conexão: uma versão atualizada do Chrome ou Firefox é altamente recomendável. Também suportamos o Internet Explorer 9 e as versões para desktop do Internet Explorer 10 e superior (não as versões do metrô). 2 Mbps recomendados no mínimo velocidade de download de 0,768 Mbps. Hardware: Um computador com pelo menos 4 GB de RAM e velocidade de CPU de pelo menos 2,5 GHz. Para desenvolvimento e teste de código, essas três configurações funcionarão com PC: Windows XP ou superior com as atualizações mais recentes instaladas Mac: OS X 10.6 ou superior com atualizações mais recentes instaladas Linux: Qualquer distribuição recente que tenha os navegadores suportados instalados Para realizar testes on-line (proctortrack) você precisará de um: PC: Windows XP ou superior com as atualizações mais recentes instaladas Mac: OS X 10.6 ou superior com as atualizações mais recentes instaladas O Linux NÃO é suportado. Horário de atendimento a ser determinado. Plágio Na maioria dos casos, espero que todo o código enviado seja escrito por você. Apresentarei algumas bibliotecas na classe que você tem permissão para usar (como pandas e numpy). Caso contrário, todo código-fonte, imagens e anotações fornecidas por você devem ter sido criados somente por você. Políticas de Classe Para alunos aprovados / reprovados: sua nota geral deve ser de 75 ou mais para obter uma nota de aprovação. A comunicação oficial é por email: Usamos piazza para discussões, mas não é um canal de comunicação oficial. Todas as comunicações oficiais para você serão enviadas via t-square para o seu endereço de e-mail oficial do GT. Da mesma forma, você deve comunicar itens importantes para nós por e-mail também. Responsabilidades do aluno: Esteja ciente dos prazos publicados na programação. Leia o seu email GT todos os dias. Comece a trabalhar em projetos, mesmo que eles não estejam abertos em t-square. Período do concurso: Após a liberação de um projeto, você tem 7 dias para contestar a nota. Depois disso, os projetos não serão reavaliados. Você deve ter um problema muito específico com um argumento convincente a respeito de porque sua nota está incorreta. Exemplo argumento convincente: O TA tirou 10 pontos porque eu estava faltando um gráfico, mas o gráfico é visível na página 5. Exemplo argumento não convincente: Eu acho que deveria ter conseguido mais pontos, por favor regrade meu projeto. Processo de concurso de notas: Envie um email ao seu TA sobre a situação. Política atrasada: As atribuições vencem às 23h55, hora do Leste, na data de vencimento da tarefa. Atribuições recebidas após as 23h55 são consideradas atrasadas. As tarefas podem ser entregues até um dia depois com uma penalidade de 10. Atribuições com mais de 24 horas de atraso não serão aceitas. Não há período de carência para atribuições já um dia inteiro de atraso. Agendamento de exames: os exames serão realizados em dias específicos em horários específicos. Se houver um problema de emergência ou outro que exija a alteração da data de um exame, será necessário que seja aprovado pelo Deão dos alunos. Você pode solicitar isso aqui: deanofstudents. gatech. edu (em Recursos - gt Class Absences) Este post detalha o que eu fiz para fazer aprox. 500k de negociação de alta freqüência de 2009 a 2010. Desde que eu estava negociando de forma totalmente independente e já não estou executando o meu programa Irsquom feliz em contar tudo. Minha negociação foi principalmente em contratos de futuros Russel 2000 e DAX. A chave do meu sucesso, acredito, não estava em uma equação financeira sofisticada, mas sim no design geral do algoritmo, que unia muitos componentes simples e usava o aprendizado de máquina para otimizar a máxima lucratividade. Você não precisa saber nenhuma terminologia sofisticada aqui, porque quando eu configurei meu programa, tudo foi baseado na intuição. (Andrew Ngrsquos incrível curso de aprendizado de máquina ainda não estava disponível - btw se você clicar nesse link yourquoll ser levado ao meu projeto atual: CourseTalk, um site de revisão para MOOCs) Primeiro, eu só quero demonstrar que o meu sucesso não foi simplesmente o resultado de sorte. Meu programa fazia de 1000 a 4000 negociações por dia (meio longo, meio curto) e nunca ocupava posições de mais do que alguns contratos por vez. Isso significava que a sorte aleatória de qualquer negociação em particular era muito rápida. O resultado foi que eu nunca perdi mais de 2000 em um dia e nunca tive um mês perdido: (EDIT. Esses números são depois de pagar comissões) E herersquos um gráfico para lhe dar uma noção da variação diária. Note que isso exclui os últimos 7 meses porque - à medida que os números pararam de subir - perdi minha motivação para entrar neles. Meu histórico de negociação Antes de configurar meu programa de negociação automatizado, a Irsquod tinha 2 anos de experiência como um comerciante de dia inteiro. Isso foi em 2001 - eram os primórdios do comércio eletrônico e havia oportunidades para que os economistas cumprissem um bom dinheiro. Eu só posso descrever o que eu estava fazendo como se fosse jogar videogames / jogos de azar com uma suposta vantagem. Ser bem-sucedido significa ser rápido, ser disciplinado e ter uma boa capacidade intuitiva de reconhecimento de padrões. Eu consegui ganhar cerca de 250 mil, pagar meus empréstimos estudantis e ter dinheiro sobrando. Ganhar Nos próximos cinco anos, eu lançaria duas startups, adquirindo algumas habilidades de programação ao longo do caminho. Não seria até o final de 2008 que eu voltaria a negociar. Com o dinheiro acabando com a venda da minha primeira startup, a negociação oferecia esperanças de algum dinheiro rápido enquanto eu descobria o meu próximo movimento. Em 2008, eu estava em muitos dias negociando futuros usando software chamado T4. A Irsquod queria algumas teclas de atalho de entrada de pedidos customizadas, então depois de descobrir que o T4 tinha uma API, aceitei o desafio de aprender C (a linguagem de programação necessária para usar a API) e segui em frente e desenvolvi algumas teclas de atalho. Depois de molhar os pés com a API, logo tive aspirações maiores: queria ensinar o computador a trocar por mim. A API forneceu um fluxo de dados de mercado e uma maneira fácil de enviar pedidos para a troca - tudo o que eu tinha que fazer era criar a lógica no meio. Abaixo está uma imagem de uma janela de negociação T4. O que foi legal é que quando eu comecei meu programa trabalhando eu pude assistir o comércio de computador exatamente nesta mesma interface. Assistir ordens reais entrando e saindo (por conta própria com meu dinheiro real) era ao mesmo tempo emocionante e assustador. O design do meu algoritmo Desde o início, meu objetivo era configurar um sistema de tal forma que eu pudesse estar razoavelmente confiante de que Irsquod ganharia dinheiro antes de fazer qualquer negociação ao vivo. Para conseguir isso, eu precisava construir uma estrutura de simulação de negociação que simulasse a negociação ao vivo, com a maior precisão possível. Enquanto a negociação no modo ao vivo exigia atualizações do mercado de processamento transmitidas pela API, o modo de simulação exigia a leitura das atualizações do mercado a partir de um arquivo de dados. Para coletar esses dados, configurei a primeira versão do meu programa para simplesmente conectar-me à API e registrar as atualizações do mercado com registros de data e hora. Acabei usando 4 semanas de dados de mercado recentes para treinar e testar meu sistema. Com uma estrutura básica em vigor, ainda tinha a tarefa de descobrir como criar um sistema comercial lucrativo. Acontece que meu algoritmo se dividiria em dois componentes distintos, que Irsquoll exploraria alternadamente: Prevendo movimentos de preços e Fazendo negócios lucrativos Prevendo movimentos de preços Talvez um componente óbvio de qualquer sistema de negociação seja prever onde os preços se moverão. E o meu não foi exceção. Eu defini o preço atual como a média do lance interno e da oferta interna e estabeleci a meta de prever onde o preço estaria nos próximos 10 segundos. Meu algoritmo precisaria apresentar essa previsão momento a momento ao longo do dia de negociação. Criando indicadores de otimização de amplificadores Criei um punhado de indicadores que provaram ter uma capacidade significativa de prever movimentos de preços de curto prazo. Cada indicador produziu um número que foi positivo ou negativo. Um indicador era útil se, na maior parte dos casos, um número positivo correspondesse ao aumento do mercado e um número negativo correspondesse à queda do mercado. Meu sistema me permitiu determinar rapidamente a capacidade preditiva de qualquer indicador, por isso pude experimentar muitos indicadores diferentes para ver o que funcionava. Muitos dos indicadores tinham variáveis ​​nas fórmulas que os produziam e eu consegui encontrar os valores ideais para essas variáveis ​​fazendo comparações lado a lado dos resultados obtidos com valores variáveis. Os indicadores que foram mais úteis foram todos relativamente simples e foram baseados em eventos recentes no mercado em que eu estava negociando, bem como nos mercados de títulos correlacionados. Fazendo previsões precisas de movimentação de preços Ter indicadores que simplesmente previam um movimento de preços para cima ou para baixo não era suficiente. Eu precisava saber exatamente quanto movimento de preço era previsto por cada valor possível de cada indicador. Eu precisava de uma fórmula que convertesse um valor de indicador em uma previsão de preço. Para conseguir isso, acompanhei as movimentações de preço previstas em 50 buckets que dependiam do intervalo em que o valor do indicador caiu. Isso gerou previsões exclusivas para cada bucket que eu era capaz de representar graficamente no Excel. Como você pode ver, a mudança de preço esperada aumenta à medida que o valor do indicador aumenta. Com base em um gráfico como esse, consegui fazer uma fórmula para ajustar a curva. No começo eu fiz esse ajuste manualmente, mas logo escrevi um código para automatizar esse processo. Note que nem todas as curvas do indicador tinham a mesma forma. Observe também que os buckets foram distribuídos logaritmicamente para distribuir os dados de maneira uniforme. Por fim, observe que os valores dos indicadores negativos (e suas previsões de preços descendentes correspondentes) foram invertidos e combinados com os valores positivos. (Meu algoritmo tratado para cima e para baixo exatamente da mesma forma.) Combinando indicadores para uma única previsão Uma coisa importante a considerar era que cada indicador não era totalmente independente. Eu não pude simplesmente somar todas as previsões que cada indicador fez individualmente. A chave era descobrir o valor preditivo adicional que cada indicador tinha além do que já estava previsto. Isso não era difícil de implementar, mas significava que, se eu estivesse adaptando vários indicadores ao mesmo tempo, teria que ser cuidadoso ao mudar um, o que afetaria as previsões de outro. A fim de ajustar todos os indicadores ao mesmo tempo, configurei o otimizador para percorrer apenas 30 do caminho em direção às novas curvas de previsão com cada passe. Com esse salto de 30, descobri que as curvas de previsão se estabilizariam em poucas passagens. Com cada indicador nos dando agora uma previsão adicional de preços, eu poderia simplesmente adicioná-los para produzir uma única previsão de onde o mercado estaria em 10 segundos. Por que prever preços não é suficiente Você pode pensar que com essa vantagem no mercado eu era de ouro. Mas você precisa ter em mente que o mercado é composto de ofertas e ofertas - não apenas um preço de mercado. Sucesso na negociação de alta frequência se resume a obter bons preços e não é tão fácil. Os seguintes fatores dificultam a criação de um sistema lucrativo: com cada negociação, tive que pagar comissões tanto para meu corretor quanto para a bolsa. O spread (diferença entre oferta mais alta e oferta mais baixa) significava que se eu simplesmente comprasse e vendesse aleatoriamente, Irsquod estaria perdendo uma tonelada de dinheiro. A maior parte do volume do mercado era de outros bots que só fariam uma troca comigo se achassem que tinham alguma vantagem estatística. Vendo uma oferta não garante que eu poderia comprá-lo. No momento em que minha ordem de compra chegou à bolsa, era muito possível que essa oferta tivesse sido cancelada. Como um pequeno participante do mercado, não havia como competir sozinho com a velocidade. Construindo uma simulação de negociação completa Então eu tive uma estrutura que me permitiu backtest e otimizar os indicadores. Mas eu tive que ir além disso - eu precisava de um framework que me permitisse fazer backtest e otimizar um sistema de negociação completo no qual eu estava enviando pedidos e me posicionando. Neste caso, o Irsod deve ser otimizado para PampL total e, em certa medida, PampL médio por negociação. Isso seria mais complicado e, de certa forma, impossível modelar exatamente, mas eu fiz o melhor que pude. Aqui estão alguns dos problemas que eu tive que lidar: Quando um pedido foi enviado para o mercado em simulação eu tive que modelar o tempo de latência. O fato de meu sistema ter visto uma oferta não significa que ela poderia comprá-la imediatamente. O sistema enviaria o pedido, aguardaria aproximadamente 20 milissegundos e somente se a oferta ainda estivesse lá era considerado como um negócio executado. Isso era inexato porque o tempo real de atraso era inconsistente e não relatado. Quando eu fiz lances ou ofertas, tive que olhar para o fluxo de execução de negociação (fornecido pela API) e usá-los para avaliar quando meu pedido seria executado. Para fazer isso direito eu tive que rastrear a posição do meu pedido na fila. (Itrsquos um sistema first-in first-out). Novamente, eu não pude fazer isso perfeitamente, mas eu fiz uma melhor aproximação. Para refinar minha simulação de execução de pedidos, o que fiz foi extrair meus arquivos de log da negociação ao vivo pela API e compará-los aos arquivos de log produzidos pela negociação simulada no mesmo período de tempo. Consegui obter minha simulação ao ponto de ser bastante precisa e, para as partes que eram impossíveis de modelar exatamente, certifiquei-me de, pelo menos, produzir resultados que fossem estatisticamente semelhantes (nas métricas que julguei importantes). Fazendo negócios lucrativos Com um modelo de simulação de pedidos, agora eu poderia enviar ordens no modo de simulação e ver um PampL simulado. Mas como meu sistema saberia quando e onde comprar e vender? As previsões de mudança de preço eram um ponto de partida, mas não toda a história. O que eu fiz foi criar um sistema de pontuação para cada um dos 5 níveis de preço na oferta e oferta. Estes incluíram um nível acima da oferta interna (para uma ordem de compra) e um nível abaixo da oferta interna (para uma ordem de venda). Se a pontuação em qualquer nível de preço estiver acima de um certo limite, isso significa que o meu sistema deve ter um lance / oferta ativa - abaixo do limite, então qualquer pedido ativo deve ser cancelado. Com base nisso, não era incomum que meu sistema exibisse um lance no mercado e o cancelasse imediatamente. (Embora eu tentei minimizar isso como itrsquos irritante para quem olha para a tela com olhos humanos - inclusive eu.) As pontuações de nível de preço foram calculadas com base nos seguintes fatores: A previsão de movimento de preço (que discutimos anteriormente). O nível de preços em questão. (Níveis internos significavam que grandes previsões de movimentação de preço eram necessárias.) O número de contratos na frente do meu pedido na fila. (Menos foi melhor.) O número de contratos por trás do meu pedido na fila. (Mais foi melhor.) Essencialmente, esses fatores serviram para identificar os locais mais lentos para oferecer / oferecer. A previsão do movimento de preços, por si só, não era adequada porque não levava em conta o fato de que, ao fazer uma oferta, eu não era preenchido automaticamente - só fui preenchido se alguém me vendesse lá. A realidade era que o simples fato de alguém me vender a um certo preço mudava as probabilidades estatísticas do negócio. As variáveis ​​usadas nesta etapa foram todas sujeitas a otimização. Isso foi feito exatamente da mesma maneira que eu otimizei as variáveis ​​nos indicadores de preço, exceto neste caso eu estava otimizando para a linha de fundo PampL. O que meu programa ignorou Quando negociamos como seres humanos, muitas vezes temos emoções e vieses poderosos que podem levar a decisões menos que ótimas. Obviamente, não queria codificar esses vieses. Aqui estão alguns fatores que meu sistema ignorou: O preço que uma posição foi inserida - Em um escritório comercial, é muito comum ouvir conversas sobre o preço em que alguém é comprido ou curto, como se isso pudesse afetar sua futura tomada de decisão. Embora isso tenha alguma validade como parte de uma estratégia de redução de riscos, ela realmente não tem relação com o curso futuro dos eventos no mercado. Portanto, meu programa ignorou completamente essa informação. Itrsquos o mesmo conceito como ignorar os custos irrecuperáveis. Indo curto vs. saindo de uma posição longa - Tipicamente um trader teria critérios diferentes que determinam onde vender uma posição comprada versus onde ir short. No entanto, da minha perspectiva de algoritmos, não havia razão para fazer uma distinção. Se meu algoritmo esperava um movimento descendente, a venda era uma boa ideia, independentemente de ser atualmente longa, curta ou plana. Uma estratégia improvisada - Esta é uma estratégia comum em que os comerciantes comprarão mais ações no caso de haver uma troca original contra eles. Isso faz com que o preço médio de compra seja menor e isso significa que quando (ou se) a ação girar, o seu estoque será definido para recuperar seu dinheiro rapidamente. Na minha opinião, esta é realmente uma estratégia horrível, a menos que o seu Warren Buffet. Você entendeu que você está indo bem porque a maioria de seus negócios será vencedores. O problema é quando você perde você perde grande. O outro efeito é que torna difícil julgar se você realmente tem uma vantagem no mercado ou está apenas tendo sorte. Ser capaz de monitorar e confirmar que meu programa realmente tinha uma vantagem era um objetivo importante. Como meu algoritmo tomava decisões da mesma forma, independentemente de onde ele entrasse em uma negociação ou se era atualmente longo ou curto, ocasionalmente ele fazia parte (e tomava) de algumas grandes negociações perdedoras (além de algumas grandes negociações vencedoras). Mas, você não deve pensar que não havia qualquer gerenciamento de risco. Para gerenciar o risco, impus um tamanho máximo de posição de dois contratos por vez, ocasionalmente aumentado em dias de alto volume. Eu também tinha um limite máximo de perda diária para proteger contra condições inesperadas de mercado ou um bug no meu software. Esses limites foram aplicados no meu código, mas também no backend por meio do meu corretor. Aconteceu que nunca encontrei problemas significativos. Executando o algoritmo A partir do momento em que comecei a trabalhar no meu programa, demorei cerca de 6 meses antes de chegar ao ponto de rentabilidade e comecei a executá-lo ao vivo. Embora, para ser justo, uma quantidade significativa de tempo foi aprender uma nova linguagem de programação. Enquanto trabalhei para melhorar o programa, vi um aumento nos lucros para cada um dos próximos quatro meses. Toda semana eu reciclaria meu sistema com base nas 4 semanas anteriores de dados. Descobri que isso estabelecia o equilíbrio certo entre captar tendências comportamentais recentes do mercado e garantir que meu algoritmo tivesse dados suficientes para estabelecer padrões significativos. Como o treinamento começou a tomar mais e mais tempo, eu o dividi para que pudesse ser executado por 8 máquinas virtuais usando o amazon EC2. Os resultados foram então reunidos na minha máquina local. O ponto alto da minha negociação foi em outubro de 2009, quando fiz quase 100k. Depois disso, continuei a passar os próximos quatro meses tentando melhorar meu programa, apesar do lucro reduzido a cada mês. Infelizmente, a essa altura, acho que Irsquod implementou todas as minhas melhores ideias, porque nada do que eu tentei parecia ajudar muito. Com a frustração de não poder fazer melhorias e não ter senso de crescimento, comecei a pensar em uma nova direção. Eu enviei um e-mail para 6 diferentes empresas de negociação de alta frequência para ver se eles estão interessados ​​em comprar meu software e me contratar para trabalhar para eles. Ninguém respondeu. Eu tive algumas novas idéias de inicialização que eu queria trabalhar, então eu nunca dei continuidade. ATUALIZAÇÃO - Eu postei isso no Hacker News e tem recebido muita atenção. Eu só quero dizer que eu não defendo ninguém tentando fazer algo assim agora. Você precisaria de uma equipe de pessoas realmente inteligentes com uma variedade de experiências para ter qualquer esperança de competir. Mesmo quando eu estava fazendo isso, acredito que era muito raro que os indivíduos alcançassem o sucesso (embora eu já tivesse ouvido falar de outros.) Há um comentário no topo da página que menciona estatísticas manipuladas e se refere a mim como um investidor seria ldquogleefully pick offrdquo. Este é um comentário bastante infeliz que simplesmente não se baseia na realidade. Deixando isso de lado, alguns comentários interessantes: news. ycombinator / itemid4748624 ATUALIZAÇÃO 2 - Irsquove postou um FAQ de acompanhamento que responde a algumas perguntas comuns sobre o recebimento de traders sobre este post.