Hoje passei pela lista de motivos de rejeição de pedidos da GRVT, principalmente porque entender os modos de falha normalmente diz mais sobre as restrições reais de design de um sistema do que a documentação do caminho feliz.
A GRVT documenta um conjunto bastante extenso de categorias de rejeição. Rejeições relacionadas a margem, quando um pedido faria uma conta ficar abaixo da margem exigida. Proteção contra self-trade, impedindo que uma conta faça match contra seus próprios pedidos em repouso. Proteção para market makers, um mecanismo especificamente para market makers evitarem serem explorados durante uma volatilidade repentina. Violações de limite de tamanho de posição, quando um pedido faria uma posição ultrapassar o que é permitido.
O que considero notável é a enorme especificidade dessas categorias, e não uma resposta genérica de "pedido rejeitado". Proteção contra self-trade e proteção para market makers, especificamente, não são verificações básicas de validação; são mecanismos de proteção que abordam cenários reais de negociação que participantes experientes de fato enfrentam.
Essa granularidade importa, na prática, para qualquer pessoa que esteja construindo um sistema automatizado em cima da GRVT. Uma rejeição genérica não lhe diz nada acionável. Um motivo específico diz exatamente o que ajustar: reduzir o tamanho, cancelar um pedido conflitante, esperar a volatilidade se estabilizar, antes de reenviar.
Ainda estou verificando se essas categorias mapeiam para um esquema fixo de códigos de erro numéricos, ou se elas são principalmente strings descritivas com as quais um cliente precisaria fazer pattern match.
@grvt_io #grvt
A GRVT documenta um conjunto bastante extenso de categorias de rejeição. Rejeições relacionadas a margem, quando um pedido faria uma conta ficar abaixo da margem exigida. Proteção contra self-trade, impedindo que uma conta faça match contra seus próprios pedidos em repouso. Proteção para market makers, um mecanismo especificamente para market makers evitarem serem explorados durante uma volatilidade repentina. Violações de limite de tamanho de posição, quando um pedido faria uma posição ultrapassar o que é permitido.
O que considero notável é a enorme especificidade dessas categorias, e não uma resposta genérica de "pedido rejeitado". Proteção contra self-trade e proteção para market makers, especificamente, não são verificações básicas de validação; são mecanismos de proteção que abordam cenários reais de negociação que participantes experientes de fato enfrentam.
Essa granularidade importa, na prática, para qualquer pessoa que esteja construindo um sistema automatizado em cima da GRVT. Uma rejeição genérica não lhe diz nada acionável. Um motivo específico diz exatamente o que ajustar: reduzir o tamanho, cancelar um pedido conflitante, esperar a volatilidade se estabilizar, antes de reenviar.
Ainda estou verificando se essas categorias mapeiam para um esquema fixo de códigos de erro numéricos, ou se elas são principalmente strings descritivas com as quais um cliente precisaria fazer pattern match.
@grvt_io #grvt