O post é adequado para aqueles que estão começando a negociação quantitativa, bem como para aqueles que têm alguma experiência com a área.
Ele também analisa os diferentes tipos de mecanismos de backtesting, bem como o cenário de software que implementa essas abordagens.
Por fim, discutimos os pormenores de um sistema de backtesting orientado por eventos, um tópico que já abordei frequentemente no QuantStart em posts anteriores.
Um backtest é a aplicação de regras de estratégia de negociação a um conjunto de dados históricos de preços. Isto é, se definirmos um conjunto de mecanismos de entrada e saída de uma carteira de ativos e aplicarmos essas regras aos dados históricos de preços desses ativos, podemos tentar entender o desempenho desta "estratégia de negociação" que poderia ter sido alcançada no passado.
Uma vez foi dito que
Os backtests, em última análise, nos ajudam a decidir se vale a pena negociar um conjunto de regras de estratégia. Isso nos fornece uma idéia de como uma estratégia poderia ter se saído no passado. Essencialmente, isso nos permite filtrar regras de estratégia ruins antes de alocar qualquer capital real.
É fácil gerar backtests. Infelizmente, os resultados dos backtests não são resultados de negociação ao vivo. Eles são, em vez disso, um modelo da realidade. Um modelo que geralmente contém muitas suposições.
Existem dois tipos principais de backtest de software - os sistemas
Quando se desenha um software de backtesting, há sempre um trade-off entre precisão e complexidade de implementação.
Há muitas armadilhas associadas ao backtesting. Todas elas dizem respeito ao fato de que um backtest é apenas um modelo da realidade.
Há algumas questões mais sutis com backtesting que não são discutidas com tanta frequência, mas ainda são incrivelmente importantes para considerar.
Muita coisa foi escrita sobre os problemas com backtesting.
Um For-Loop Backtester é o tipo mais direto de sistema de backtesting e a variante mais frequentemente vista em postagens de blogs quant, puramente por sua simplicidade e transparência.
Essencialmente, o sistema For-Loop itera em cada dia de negociação (ou barra OHLC), executa algum cálculo relacionado ao preço (s) do ativo (s), como uma média móvel do fechamento, e depois vai longo ou curto de um ativo particular (muitas vezes no mesmo preço de fechamento, mas às vezes no dia seguinte).
Aqui está o pseudo-código para tal algoritmo:
for each trading bar:
do_something_with_prices();
buy_sell_or_hold_something();
next_bar();PythonCopy
Como pode ver, o projeto de tal sistema é incrivelmente simples, o que o torna atraente para obter um primeiro olhar sobre o desempenho de um determinado conjunto de regras estratégicas.
For-Loop backtesters são simples de implementar em quase qualquer linguagem de programação e são muito rápidos de executar.
A principal desvantagem dos backtesters For-Loop é que eles são bastante irreais. Eles geralmente não têm capacidade de custo de transação a menos que especificamente adicionados. Normalmente as ordens são preenchidas imediatamente no mercado com o preço do ponto médio. Como tal, muitas vezes não há contabilização de spread.
Há uma reutilização mínima de código entre o sistema de backtesting e o sistema de negociação ao vivo.
For-Loop backtesters são propensos a Look-Ahead Bias, devido a bugs com a indexação.
For-Loop backtesters realmente deve ser utilizado apenas como um mecanismo de filtragem. Você pode usá-los para eliminar as estratégias obviamente ruins, mas você deve permanecer cético de forte desempenho. Mais pesquisas são muitas vezes necessárias.
Os backtesters orientados por eventos estão na outra extremidade do espectro. Eles são muito mais semelhantes às implementações de infraestrutura de negociação ao vivo. Como tal, eles são muitas vezes mais realistas na diferença entre o desempenho de negociação backtested e ao vivo.
Tais sistemas são executados em um grande loop que procura continuamente por eventos de diferentes tipos na fila de eventos.
Quando um determinado evento é identificado, ele é encaminhado para o módulo apropriado (s) na infraestrutura, que lida com o evento e, em seguida, potencialmente gera novos eventos que voltam para a fila.
O pseudo-código para um sistema de backtesting orientado por eventos é o seguinte:
while event_queue_isnt_empty():
event = get_latest_event_from_queue();
if event.type == "tick":
strategy.calculate_trading_signals(event);
else if event.type == "signal":
portfolio.handle_signal(event);
else if event.type == "order":
portfolio.handle_order(event);
else if event.type == "fill":
portfolio.handle_fill(event)
sleep(600); # Sleep for, say, 10 minsPythonCopy
Como você pode ver, há uma forte dependência do módulo de gerenciamento de carteira. tal módulo é o
Há muitas vantagens em usar um backtester orientado por eventos:
Embora as vantagens sejam óbvias, há também algumas desvantagens significativas em relação à utilização de um sistema tão complexo:
Nesta seção, consideraremos o software (open source e comercial) que existe para sistemas For-Loop e Event-Driven.
Para os backtesters do For-Loop, as principais linguagens de programação / softwares usados incluem Python (com a biblioteca Pandas), R (e a biblioteca quantmod) e MatLab.
O mercado de sistemas orientados por eventos é muito maior, uma vez que os clientes/usuários desejam frequentemente que o software seja capaz de realizar testes de retorno e negociação ao vivo em um único pacote.
As ofertas comerciais caras incluem Deltix e QuantHouse.
Quantopian é um exemplo de uma configuração madura baseada na web para backtesting e negociação ao vivo.
Os quants institucionais também constroem frequentemente o seu próprio software interno, devido a uma combinação de restrições regulamentares, relações com os investidores/relatórios e auditabilidade.
Os quants de varejo têm a escolha entre usar a abordagem
Em termos de software de código aberto, existem muitas bibliotecas disponíveis. Eles são principalmente escritos em Python (por razões que eu descreverei abaixo) e incluem Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) e QSTrader (o próprio backtester do QuantStart
Um dos aspectos mais importantes, no entanto, é que não importa qual peça de software você use, ele deve ser emparelhado com uma fonte igualmente sólida de dados financeiros.
Enquanto o software cuida dos detalhes para nós, ele nos esconde de muitos detalhes de implementação que muitas vezes são cruciais quando desejamos expandir a complexidade de nossa estratégia de negociação.
Apesar de ter formação como desenvolvedor de software quantitativo, não estou pessoalmente interessado em
Deveríamos interessar-nos apenas no que funciona.
Python é uma linguagem de programação extremamente fácil de aprender e é muitas vezes a primeira linguagem com a qual as pessoas entram em contato quando decidem aprender programação.
Ele possui algumas bibliotecas excepcionais de aprendizado de máquinas (ML) em NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 e Statsmodels.
É ótimo para a construção de sistemas de backtesting For-Loop e Event-Driven. de fato, é talvez uma das únicas linguagens que permite diretamente pesquisa de ponta a ponta, backtesting, implantação, negociação ao vivo, relatórios e monitoramento.
Talvez sua maior desvantagem seja que é bastante lento de executar quando comparado a outras linguagens como C ++. No entanto, o trabalho está sendo realizado para melhorar este problema e, ao longo do tempo, o Python está se tornando mais rápido.
R é um ambiente de programação estatística, em vez de uma linguagem de programação de primeira classe (embora alguns possam argumentar o contrário!).
Ele é amplamente usado para backtesting For-Loop, muitas vezes através da biblioteca quantmod, mas não é particularmente adequado para sistemas orientados por eventos ou negociação ao vivo.
O C++ tem uma reputação de ser extremamente rápido. Quase toda a computação científica de alto desempenho é realizada em Fortran ou C++. Esta é sua principal vantagem. Portanto, se você está considerando negociação de alta frequência ou trabalhando em sistemas legados em grandes organizações, então o C++ provavelmente será uma necessidade.
Infelizmente, é doloroso para a realização de pesquisa de estratégia. devido a ser tipado estaticamente, é bastante complicado carregar, ler e formatar dados facilmente em comparação com Python ou R.
Apesar de sua idade relativa, foi recentemente modernizado substancialmente com a introdução do C++11/C++14 e outros refinamentos de padrões.
Você também pode querer dar uma olhada em Java, Scala, C #, Julia e muitas das linguagens funcionais.
Resposta: Sim!
É uma grande experiência de aprendizagem para escrever o seu próprio sistema de backtesting Event-Driven. em primeiro lugar, ele força você a considerar todos os aspectos de sua infraestrutura de negociação, não apenas passar horas mexer em uma estratégia particular.
Mesmo que não acabe por usar o sistema para negociação ao vivo, ele lhe fornecerá um grande número de perguntas que você deve estar perguntando aos seus fornecedores comerciais ou FOSS backtesting.
Por exemplo: Como é que o seu sistema de vida atual difere da sua simulação backtest em termos de:
Embora os sistemas orientados por eventos não sejam rápidos ou fáceis de escrever, a experiência pagará enormes dividendos educacionais mais tarde em sua carreira de negociação quântica.
Como é que se escreve um sistema assim?
A melhor maneira de começar é simplesmente baixar o Zipline, QSTrader, PyAlgoTrade, PySystemTrade etc. e tentar ler a documentação e o código.
Rob Carver, da Investment Idiocy também apresenta sua abordagem para construir tais sistemas para negociar futuros.
Lembre-se de que você não precisa ser um especialista no dia # 1. Você pode levá-lo devagar, dia após dia, módulo por módulo. Se você precisar de ajuda, você sempre pode entrar em contato comigo ou com outros blogueiros quant. Veja o final do artigo para o meu e-mail de contato.
Agora vou discutir os módulos que são frequentemente encontrados em muitos sistemas de backtesting orientados por eventos.
Este é o lugar onde todos os dados de preços históricos são armazenados, juntamente com o seu histórico de negociação, uma vez que estiverem em funcionamento.
Em vez disso, usamos um banco de dados ou sistema de arquivos de primeira classe, como PostgreSQL, MySQL, SQL Server ou HDF5.
Idealmente, queremos obter e armazenar dados de nível de tick, pois isso nos dá uma idéia dos spreads de negociação.
Devemos sempre estar cientes de lidar com ações corporativas (como divisões de ações e dividendos), viés de sobrevivência (deslistamento de ações), bem como rastrear as diferenças de fuso horário entre várias bolsas.
Os indivíduos e as empresas de retalho podem competir aqui, uma vez que muitas tecnologias de base de dados de qualidade de produção são maduras, gratuitas e de código aberto.
Há ainda muitos mercados e estratégias que são muito pequenos para os grandes fundos estarem interessados.
O módulo de estratégia de negociação em um sistema orientado por eventos geralmente executa algum tipo de mecanismo preditivo ou de filtragem em novos dados de mercado.
Ele recebe dados de barra ou tick e, em seguida, usa esses mecanismos para produzir um sinal de negociação para longo ou curto de um ativo.
95% da discussão quant blog geralmente gira em torno de estratégias de negociação. Eu pessoalmente acredito que deveria ser mais como 20%. Isso é porque eu acho que é muito mais fácil aumentar os retornos esperados reduzindo custos através de um gerenciamento de risco adequado e dimensionamento de posição, em vez de perseguir estratégias com
O "coração" de um backtester orientado por eventos é o sistema de gestão de carteiras e ordens. É a área que requer mais tempo de desenvolvimento e testes de garantia de qualidade.
O objectivo deste sistema é passar da carteira actual para a carteira desejada, minimizando o risco e reduzindo os custos de transacção.
O módulo reúne as capacidades de estratégia, risco, dimensionamento de posições e execução de ordens do sistema.
A principal vantagem de usar um sistema tão complexo é que permite que uma variedade de instrumentos financeiros sejam tratados sob uma única carteira. Isso é necessário para carteiras de estilo institucional com hedging.
A separação da gestão de riscos em seu próprio módulo pode ser extremamente vantajosa.
Em particular, o módulo de risco pode adicionar coberturas para manter a neutralidade do mercado. Pode reduzir os tamanhos das ordens devido à exposição do setor ou aos limites de ADV. Pode vetar completamente uma negociação se o spread for muito amplo ou as taxas forem muito grandes em relação ao tamanho da negociação.
Um módulo de dimensionamento de posição separado pode implementar a estimativa de volatilidade e regras de dimensionamento de posição, como alavancagem de Kelly.
No entanto, essa é provavelmente a maior diferença entre como as instituições e alguns comerciantes de varejo pensam sobre sua negociação. Talvez a maneira mais simples de obter melhores retornos seja começar a implementar o gerenciamento de risco e o dimensionamento de posição desta maneira.
Na vida real, nunca temos a garantia de conseguir um mercado cheio no ponto médio!
Devemos considerar questões transacionais como capacidade, spread, taxas, slippage, impacto no mercado e outras preocupações de execução algorítmica, caso contrário, nossos retornos de backtesting provavelmente serão muito exagerados.
A abordagem modular de um sistema orientado por eventos permite-nos trocar facilmente o BacktestExecutionHandler com o LiveExecutionHandler e implantar no servidor remoto.
Também podemos facilmente adicionar várias corretoras utilizando o conceito OOP de
Uma questão a ser conhecida é a de
As quantidades de retalho podem e devem utilizar as sofisticadas técnicas de reporte utilizadas pelas quantidades institucionais. Tais ferramentas incluem
As melhorias incrementais consistentes devem ser feitas a esta infra-estrutura. Isso pode realmente enchance retornos a longo prazo, simplesmente eliminando bugs e melhorando questões como a latência do comércio. Não fique simplesmente fixado em melhorar a "maior estratégia do mundo" (WGS).
O WGS acabará por se corroer devido ao
A otimização das infra-estruturas pode ser mais "aborrecida" do que o desenvolvimento de estratégias, mas torna-se significativamente menos aborrecida quando os rendimentos são melhorados!
A implantação num servidor remoto, juntamente com um acompanhamento extensivo deste sistema remoto, é absolutamente crucial para sistemas de nível institucional.
Um sistema robusto deve ser implantado remotamente na nuvem ou co-locado perto de um exchange. Banda larga doméstica, fontes de energia e outros fatores significam que a utilização de um desktop/laptop doméstico é muito pouco confiável.
Os principais problemas ao considerar uma implantação remota incluem; monitoramento de hardware, como CPU, RAM / swap, disco e I / O de rede, alta disponibilidade e redundância de sistemas, um plano de backup e restauração bem pensado, registro extensivo de todos os aspectos do sistema, bem como integração contínua, testes de unidade e controle de versão.
Lembre-se da Lei de Murphy. Se pode falhar, falhará.
Existem muitos fornecedores que oferecem implementações de nuvem relativamente simples, incluindo Amazon Web Services, Microsoft Azure, Google e Rackspace.
Infelizmente, não há "solução rápida" no comércio de quantidades.
Talvez um grande obstáculo para iniciantes (e alguns quantos intermediários!) seja que eles se concentram demais na melhor
É também vale a pena investir muito tempo em sua infraestrutura de negociação. Passe tempo em questões como implantação e monitoramento. Sempre tente reduzir os custos de transação, pois a lucratividade é tanto sobre a redução de custos quanto sobre a obtenção de receita comercial.
Eu recomendo escrever o seu próprio sistema de backtesting simplesmente para aprender. Você pode usá-lo e continuamente melhorá-lo ou você pode encontrar um fornecedor e, em seguida, fazer-lhes todas as perguntas que você descobriu quando você construiu o seu próprio.
Por fim, sempre leia, aprenda e melhore. Há uma riqueza de livros didáticos, revistas comerciais, revistas acadêmicas, blogs quant, fóruns e revistas que discutem todos os aspectos da negociação. Para ideias de estratégia mais avançadas, recomendo SSRN e arXiv - Quantitative Finance.