Um desafio de prop firm é o software que determina se uma conta de avaliação está ativa, foi aprovada ou foi violada.
Ele lê negociações, saldo da conta, lucro e perda abertos, taxas e tempo. Compara o estado da conta com as regras do programa. Quando um limite é ultrapassado, o mecanismo pode bloquear novas ordens, fechar posições, mover a conta para outro estágio ou enviá-la para revisão de pagamento.
Parece simples até que duas pessoas calculem a mesma regra de maneira diferente.
Considere uma $100,000 conta com um limite de perda diária de 5%. O limite fica em $95,000 o dia todo? Ele se move depois que o trader ganha $2,000? As perdas abertas contam? Qual fuso horário encerra o dia? O que acontece se uma posição ultrapassa o limite entre duas atualizações de preço?
A porcentagem é a parte fácil. A definição, o tempo e as evidências são o que tornam um motor de desafios confiável.
| Componente | Seu trabalho |
|---|---|
| Plataforma de negociação | Aceita ordens e registra posições, preenchimentos e valores de conta |
| Mecanismo de desafio | Aplica as regras de avaliação e altera o status da conta |
| Painel do trader | Mostra o progresso, espaço de perda restante e histórico de regras |
| CRM e back office | Gerencia o cliente, ciclo de vida da conta, revisões e comunicação |
| Fluxo de trabalho de pagamento | Verifica elegibilidade, calcula a divisão e registra o status do pagamento |
Como funciona um motor de desafio de firma de prop
Eu vejo o motor como um processador de eventos com memória.
Todo evento relevante entra em sequência: um preenchimento, uma alteração de preço, uma comissão, uma troca, um reset diário ou uma correção manual de saldo. O mecanismo reconstrói o estado da conta, avalia as regras e registra a decisão em um log de auditoria.
From trade event to account decision
The engine combines platform events with the active rule version. Each decision produces an account action and an audit record.
Account state + rule evaluator
Rebuild the account, then run every active rule against the same state.
Event ID, account snapshot, threshold, rule version, decision, action and timestamp.
A sequência é importante. Um preenchimento tardio pode gerar a exposição errada. Um preenchimento duplicado pode contar a mesma perda duas vezes. Diferentes fusos horários podem fazer um reinício diário válido parecer uma violação.
Um motor confiável, portanto, precisa de quatro coisas:
- Eventos normalizados. Símbolos, timestamps, taxas e identificadores de conta devem usar um formato consistente.
- Uma conta autoritativa. O saldo, patrimônio, posições em aberto, marca d’água e base diária devem vir de fontes definidas.
- Regras determinísticas. O mesmo histórico de eventos deve sempre produzir o mesmo resultado.
- Um rastreamento de auditoria. A empresa deve ser capaz de mostrar qual evento acionou uma aprovação ou violação e qual versão da regra estava ativa.
Um painel sem essas bases pode mostrar um aviso, mas não pode explicar de forma confiável como o número foi alcançado.
As regras que o motor tem que calcular
A maioria dos programas de avaliação utiliza rótulos familiares. O cálculo sob cada rótulo ainda pode variar.
Meta de lucro
Uma meta de lucro define o resultado necessário para concluir uma etapa. Uma versão básica pode exigir uma conta que comece em $100,000 para alcançar $108,000.
O motor ainda precisa de respostas para várias perguntas:
- O alvo é baseado em equilíbrio ou patrimônio?
- Devem todas as posições ser fechadas antes que a fase passe?
- As comissões e swaps estão incluídos?
- Existe um número mínimo de dias de negociação?
- Um grande dia pode violar uma regra de consistência mesmo após o alvo ser alcançado?
Eu prefiro que a lógica de passagem seja executada apenas após todas as regras de risco terem sido verificadas. Um trader não deve passar porque o patrimônio atingiu a meta na mesma atualização de preço que ultrapassou o limite de perda.
Perda máxima diária
A perda diária é geralmente a regra mais exposta a erros de tempo.
Suponha que a perda diária permitida seja $5.000. Uma implementação simples é:
Piso diário = Linha de base do início do dia - $5.000
Quarto restante = Patrimônio atual - Piso diário
Um programa pode, em vez disso, usar o capital inicial, o maior entre o saldo e o capital, ou uma porcentagem fixa do tamanho inicial da conta. Pode incluir P&L aberto, comissões, swaps e dividendos. Pode ser reiniciado no fuso horário da plataforma em vez do horário local do trader.
A regra pública deve descrever a linha de base exata e as deduções. O motor deve armazená-las a cada reinicialização.
Perda máxima e drawdown
Uma perda máxima estática mantém um piso fixo. Com uma conta inicial de $100,000 e um limite de $10,000, o piso permanece $90,000.
Um drawdown em trailing eleva o piso quando a conta atinge um novo recorde:
Piso de acompanhamento = Marca de alta - Permissão de redução
Se o nível mais alto da água atingir $106,000 e a concessão for $10,000, o piso se torna $96,000.
O programa deve especificar o que cria uma nova marca de nível máximo:
- ações intradiárias;
- equidade de fim de dia;
- saldo encerrado;
- saldo de fim de dia.
Também deve indicar se o piso continua seguindo, para no saldo inicial ou trava em outro limite. “10% de drawdown em trailing” está incompleto sem esses detalhes.
Dias de negociação e consistência
Um dia de negociação deve ter uma definição documentada. Abrir uma posição, fechar uma e manter uma operação durante a noite não contam necessariamente da mesma forma.
As regras de consistência precisam de precisão igual. Se o melhor dia não pode exceder 40% do lucro total, o mecanismo precisa saber se o teste se aplica durante o desafio, no momento da aprovação ou apenas quando um pagamento é solicitado.
Por exemplo, um comerciante tem $10,000 em lucro total e fez $4,800 no melhor dia:
$4.800 / $10.000 = 48%
A conta pode estar acima de sua meta de lucro, mas ainda assim falhar no teste de consistência de 40%. Dependendo do programa, o trader pode precisar ganhar mais em outros dias em vez de perder parte do melhor dia.
Restrições de negociação
Tamanho da posição, instrumento, período de manutenção, notícias e regras de automação precisam de calendários estruturados, mapeamento de instrumentos e dados de pedidos. Uma frase nos termos não pode interromper um pedido por si só.
Uma conta, três diferentes pisos de perda
Use esta conta ilustrativa:
- saldo inicial:
$100,000; - saldo atual:
$102,000; - saldo inicial do dia:
$102,000; - maior patrimônio registrado:
$106,000; - patrimônio atual:
$97,200; - limite de perda diária:
$5,000; - provisão para perda total:
$10,000.
Which loss rule stops the account first?
The same $100,000 account can be safe or breached depending on current equity and the recorded high-water mark.
Daily loss
Start-of-day balance – $5,000
Static maximum loss
Initial balance – $10,000
Trailing drawdown
High-water mark – $10,000
Daily loss is the closest limit, with `$200` of room left.
Sob uma linha de base diária fixa, o limite diário é $97,000. O patrimônio atual tem apenas $200 restantes antes da violação.
O limite de perda total estático permanece em $90,000, deixando $7,200. Essa regra não está próxima de ser acionada.
O piso de arrasto é $96,000, com base na marca d'água alta de $106,000. Isso deixa $1,200.
A regra diária vence porque tem o menor espaço restante. Outra $250 de perda flutuante levaria o capital a $96,950 e violaria a conta, embora ainda permaneça bem acima do limite de perda máxima estática.
É por isso que não julgo uma avaliação apenas com base nas porcentagens do título. A restrição ativa pode mudar durante o dia, e pode não ser a regra que um trader espera.
O que acontece quando um limite é ultrapassado
Uma violação é um fluxo de trabalho, não uma mudança de cor em um painel.
Uma empresa deve decidir quais ações ocorrem e em que ordem:
- Registre o estado da conta e o evento de mercado que o acionou.
- Rejeitar novos pedidos.
- Cancelar ordens de trabalho.
- Feche as posições abertas se o programa exigir.
- Bloqueie a conta ou marque-a para revisão.
- Notifique o trader e a equipe de operações.
- Preserve a versão do cálculo e da regra para uma possível disputa.
Existem dois modos de falha comuns.
Com a aplicação tardia, o painel detecta uma violação enquanto a plataforma ainda aceita pedidos. Com a aplicação duplicada, uma nova tentativa fecha uma posição duas vezes ou repete uma alteração de status. Repetir o mesmo evento de violação não deve repetir seu efeito financeiro.
Os avisos podem ajudar antes do limite rígido. Por exemplo, o sistema pode notificar o trader em 70% e 90% da capacidade de perda diária. Mas um limite de aviso deve permanecer separado da regra de violação real.
Casos extremos que merecem seus próprios testes
A maioria dos defeitos aparece nas fronteiras em vez de durante uma negociação fechada ordinária.
| Situação | Comportamento esperado |
|---|---|
| Redefinição diária com P&L aberto | Capturar a linha de base definida no fuso horário do programa antes de processar o próximo evento |
| Gaps de preço através de um limite | Registrar o primeiro preço disponível e o patrimônio resultante, não uma negociação fictícia no limite |
| Preenchimentos parciais e taxas atrasadas | Aplicar cada evento uma vez e recalcular após a chegada de comissões ou swaps |
| Interrupção de feed | Preservar a ordem dos eventos após a reconexão e evitar passar uma conta a partir de dados incompletos |
| Correção manual | Armazenar o autor, razão, carimbo de data/hora e link para a decisão original |
As mudanças de horário de verão, manutenção e chamadas duplicadas pertencem ao mesmo pacote de teste. Um evento reordenado pode fazer uma regra correta produzir a decisão errada.
Superar um desafio é uma transição de estado
O objetivo de lucro sozinho não deve promover uma conta.
Antes de mudar active para passed, verifique:
- nenhuma regra rígida é violada;
- o alvo utiliza a medida de saldo ou patrimônio exigida;
- todos os dias de negociação necessários estão completos;
- as condições de consistência estão satisfeitas;
- as posições são fechadas se o programa exigir;
- a conta não possui dados não resolvidos ou retenção de conformidade.
As tentativas não devem criar a próxima conta duas vezes ou anexar o modelo de regra incorreto.
Mantenha o histórico do estágio visível: conta criada, estágio concluído, conta financiada criada, elegível para pagamento, solicitação de pagamento e pagamento concluído. Essa linha do tempo informa o suporte onde uma conta está travada.
Como funciona o fluxo de pagamento
O mecanismo de desafio estabelece a elegibilidade. O fluxo de pagamento lida com o dinheiro e os controles ao seu redor.
Uma sequência prática é:
- Congelar uma captura de elegibilidade para o período de desempenho solicitado.
- Confirme que a conta não possui posições em aberto, se necessário.
- Recalcular o lucro elegível após taxas e pagamentos anteriores.
- Aplique a parte do lucro do trader.
- Executar verificações de identidade, titularidade de conta e abuso.
- Aprovar, rejeitar ou enviar o pedido para revisão manual.
- Criar a instrução de pagamento.
- Registrar o status do provedor, taxas e referência de liquidação.
- Ajuste a conta de acordo com as regras do programa.
Se o lucro elegível for $6,000 e a participação do trader for 80%, o pagamento bruto é:
$6.000 x 80% = $4.800
O sistema deve mostrar qual janela de desempenho gerou os $6,000, se pagamentos anteriores foram deduzidos e o que acontece com os $1,200 restantes.
O status do pagamento também precisa de reconciliação. "Aprovado" no back office da empresa de prop não significa "pago" pelo provedor de pagamento ou "recebido" pelo trader.
As regras de risco e a detecção de abuso são sistemas diferentes
A perda e a redução diária são determinísticas. A conta ou ultrapassou o limite definido ou não ultrapassou.
A detecção de abuso é geralmente probabilística. Dispositivos compartilhados, pedidos correspondentes, latência incomum, contas coordenadas ou conflitos de identidade podem criar sinais. Um sinal não é prova por si só.
Eu manteria os dois caminhos de decisão separados:
- Mecanismo de regras: calcula as condições do programa publicado.
- Controles de abuso: pontuar comportamento e coletar evidências.
- Revisão manual: lida com casos ambíguos e registra a razão final.
Controles automáticos podem bloquear ações claramente definidas. Um sinal fraco não deve se tornar uma rejeição de pagamento inexplicável. Os revisores precisam das ordens subjacentes, carimbos de data/hora, dispositivos e referências de regras, não apenas uma pontuação.
O que testar antes de lançar um desafio
Eu repetiria sequências completas de eventos e verificaria cada resultado em relação a um cálculo manual.
O pacote de teste deve incluir:
- um passe comum;
- perda diária causada por P&L flutuante;
- violações de drawdown estático e de trailing;
- um máximo de ações que move um piso de acompanhamento intradiário;
- um reinício diário com posições abertas;
- uma diferença de preço através do limite;
- comissões e trocas postadas após uma execução;
- preenchimentos parciais e pedidos rejeitados;
- eventos duplicados e fora de ordem;
- uma interrupção de dados de mercado e reconexão;
- um evento de alvo simultâneo e limite de perda;
- um pagamento após um ou mais pagamentos anteriores;
- um recurso aceito e correção manual de conta.
Para cada caso, compare os eventos da plataforma, o cálculo do motor, a mensagem do trader e o registro do back-office. Todos os quatro devem descrever o mesmo resultado. Acompanhe a latência de decisão, as violações contestadas, os recursos bem-sucedidos, o tempo de pagamento e as ações duplicadas.
O que uma empresa de prop deve ser capaz de configurar
A lista de regras importa menos do que o comportamento previsível e um cálculo que a equipe pode reproduzir.
Antes de selecionar um motor de desafios, verifique se a empresa pode configurar:
- programas de estágio único, múltiplo e de acesso direto;
- meta de lucro e dias mínimos de negociação;
- linha de base de perda diária, tempo de redefinição e custos incluídos;
- comportamento de trailing drawdown e bloqueio estático, de fim de dia ou intradiário;
- instrumento, tempo, notícias e restrições de tamanho de posição;
- avisos, violações graves e ações na conta;
- fluxo de trabalho de passagem, promoção e pagamento;
- versões de regras, registros de eventos e permissões de revisão manual.
Também teste quão rapidamente uma mudança de regra chega a contas ativas. Novos termos não devem reescrever silenciosamente o cálculo para uma avaliação já em andamento.
Essa integração é importante porque o motor de desafios não pode operar isoladamente. Ele precisa de dados limpos da plataforma, controles de conta aplicáveis e um registro de pagamento que o financeiro possa conciliar.
