Um sistema de gerenciamento de pedidos (OMS) é um software que acompanha os pedidos de negociação desde o momento em que alguém decide negociar até que o resultado chegue às contas. Ele registra o que foi solicitado, verifica se o pedido é permitido, o envia para execução e acompanha tudo o que acontece com ele depois.
Cada pedido levanta três perguntas, e o OMS é onde as respostas estão: O que pretendíamos negociar? O que realmente foi negociado? O que ainda precisa de ação?
O que foi pretendido e o que realmente foi negociado muitas vezes diferem. Imagine um pedido para comprar 1.000 ações. As primeiras 400 ações são compradas, e então o comprador pede para cancelar o restante. Enquanto esse pedido está a caminho, outras 150 ações são compradas. O pedido acaba sendo marcado como “Cancelado”, ainda assim 550 ações foram adquiridas. Um bom OMS mostra toda a história por trás desse status de uma palavra, e este guia explica como.
Em resumo:
- Uma OMS é o registro central de ordens de negociação: o que foi solicitado, para quem e o que aconteceu com isso.
- Ele verifica cada pedido antes de enviá-lo, depois rastreia confirmações, negociações executadas, alterações e cancelamentos.
- Ele não executa negociações por conta própria. Corretores e bolsas fazem isso, e o OMS mantém o registro correto.
- A sua história com marcação de tempo é um dos principais registros que as empresas e os reguladores usam para reconstruir qualquer pedido posteriormente.
O que é um sistema de gestão de pedidos?
Nos mercados financeiros, um OMS gerencia ordens para ações, títulos, moedas, derivativos e outros instrumentos. O nome é compartilhado com software que lojas online usam para processar entregas, mas um OMS de negociação é uma ferramenta diferente com um trabalho diferente.
Pense nisso como o livro de registro e a mesa de controle para pedidos. Qualquer negociação passa por estágios semelhantes, seja começando com um gestor de fundos fazendo um grande pedido para um fundo de pensão ou com alguém clicando em “Comprar” em um aplicativo de negociação. Em empresas profissionais, o OMS é o sistema que organiza esses estágios. Em um aplicativo de negociação para consumidores, as mesmas funções geralmente ocorrem dentro da plataforma do corretor, fora da vista.
Principais características de um OMS de negociação
- Captura de pedido: registra a conta, instrumento, direção de compra ou venda, quantidade, tipo de ordem, preço e quanto tempo a ordem permanece válida.
- Verificações pré-negociação: confirma que a ordem é permitida, que a conta pode arcar com isso e que respeita os limites de negociação.
- Roteamento: envia pedidos aprovados para um corretor, um sistema de execução ou um local de negociação.
- Rastreamento de pedidos: mantém um registro ao vivo de confirmações, preenchimentos, alterações e cancelamentos.
- Manutenção de posição: atualiza as participações e o caixa à medida que as negociações entram, para que o próximo pedido seja verificado com base em números atualizados.
- Alocação: divide uma grande ordem executada entre as contas para as quais foi feita, quando necessário.
- Registro de auditoria: armazena um histórico com marcação de tempo de cada evento, para que qualquer pessoa possa reconstruir posteriormente exatamente o que aconteceu.
- Transferência pós-negociação: passa os resultados para os sistemas de contabilidade e operações.
Alguns produtos OMS são aplicações independentes. Outros estão integrados em uma plataforma de negociação maior.
Termos-chave em inglês simples
| Termo | O que significa |
|---|---|
| Ordem | Uma instrução para comprar ou vender uma quantidade específica de um instrumento |
| Local de negociação | Um lugar onde as ordens são combinadas, como uma bolsa de valores |
| Execução | Uma negociação que executa toda ou parte de uma ordem |
| Execução parcial | Apenas parte da quantidade foi negociada até agora |
| Quantidade em espera | A parte de uma ordem que ainda está aguardando para ser negociada |
| Ordem de mercado | Uma ordem para negociar o mais rápido possível ao melhor preço disponível |
| Ordem limite | Uma ordem que pode ser negociada apenas ao preço declarado ou melhor |
| Duração da ordem | Quanto tempo a ordem permanece ativa, por exemplo, por um dia ou até ser cancelada |
| Confirmação | Confirmação da parte receptora de que aceitou a ordem |
| Alteração | Um pedido para mudar uma ordem, como seu preço ou quantidade |
| Cancelamento | Um pedido para parar a quantidade que ainda não foi negociada |
| Cancelamento pendente | Um cancelamento foi solicitado, mas ainda não confirmado; a ordem ainda pode ser negociada |
| Rejeitado | A ordem foi recusada, seja pelos próprios controles da empresa ou pela parte receptora |
| Expirado | A ordem atingiu o final de seu tempo em vigor sem ser totalmente negociada |
| Alocação | Dividindo uma ordem executada entre várias contas |
| Liquidação e compensação | As etapas após uma negociação que confirmam quem deve o quê e, em seguida, trocam os valores mobiliários e o dinheiro |
Como funciona um sistema de gerenciamento de pedidos, passo a passo
Where the OMS sits
Orders go out through the OMS; confirmations and fills come back to it; results go on to the back office. Shown from a fund manager’s point of view. In a trading app, the broker runs the OMS.
- Order sourceInvestor, fund manager, algorithm or app
- OMSRecords, checks and tracks the order
- ExecutionBroker, EMS or smart order router
- Trading venueExchange or other venue matches orders
- ↑ Confirmations and fills flow back to the OMS
- Post-tradeThe OMS passes results to the back office, which works with clearing and settlement
1. O pedido foi feito
Um pedido pode vir de uma pessoa, de um sistema de gerenciamento de portfólio, de um algoritmo de negociação ou de outro programa conectado por meio de uma API (uma interface de software). O OMS precisa primeiro saber exatamente o que está sendo solicitado.
“Comprar 1.000 XYZ a $25” não é suficiente por si só. O OMS também precisa saber para qual conta o pedido é, qual instrumento exato é destinado (o mesmo ticker pode existir em vários mercados), a moeda e por quanto tempo o pedido permanece válido. Um pedido de um dia expira no final do dia de negociação; um pedido bom até cancelar continua válido até ser preenchido ou cancelado, embora muitos corretores definam um período máximo.
A OMS dá à ordem um identificador. Cada preenchimento, alteração e cancelamento posterior está vinculado a esse identificador. Sem esse vínculo, a equipe de operações poderia receber uma negociação válida e não saber a qual instrução ela pertence.
2. O pedido é verificado
Antes que qualquer coisa seja enviada, a OMS realiza verificações pré-comercial, seja por conta própria ou através de serviços de risco e conformidade conectados. As verificações típicas abrangem:
- se a conta pode negociar este instrumento,
- se tem dinheiro suficiente ou margem (dinheiro emprestado do corretor),
- se o tamanho e o preço estão dentro dos limites,
- se o instrumento está em uma lista restrita, por exemplo, porque a empresa possui informações confidenciais sobre a companhia.
A contagem de pedidos abertos também. Uma conta pode ter dinheiro suficiente para um pedido, mas não para dois pedidos semelhantes feitos ao mesmo tempo. Boas verificações levam em conta os pedidos que ainda estão aguardando, não apenas as negociações que já aconteceram.
As verificações de conformidade também podem ser realizadas após uma negociação, para confirmar que o resultado permaneceu dentro das regras. Quando uma verificação falha antes de uma negociação, a rejeição deve indicar o motivo. “Instrumento não permitido para esta conta” pode ser resolvido em minutos. “Pedido falhou” faz com que alguém tenha que vasculhar os registros.
3. O pedido foi enviado e confirmado
Os pedidos aprovados vão para seu destino: um corretor, um sistema de gerenciamento de execução, um roteador de pedidos inteligente ou uma conexão direta com um local.
Enviar um pedido e tê-lo aceito são dois eventos separados. O OMS registra sua própria submissão e, em seguida, aguarda que o outro lado a confirme ou a rejeite. Se um grande pedido for dividido em pedidos “filhos” menores, o OMS mantém esses pedidos vinculados ao “pai” original, para que possa verificar se os pedidos filhos nunca somam mais do que o pai.
Os pedidos viajam entre sistemas como mensagens, frequentemente através de uma API de negociação ou do protocolo FIX, que é o padrão da indústria. O OMS lê essas mensagens e atualiza o status e as quantidades de cada pedido.
4. Preenchimentos, alterações e cancelamentos são monitorados
Um preenchimento aumenta a quantidade comprada ou vendida e pode deixar parte da ordem ainda em funcionamento. Uma alteração pede para mudar a ordem. Um cancelamento pede para parar qualquer coisa que ainda não tenha sido negociada.
Nem uma alteração nem um cancelamento entram em vigor no momento em que são enviados. Até que a outra parte o confirme, o pedido original pode continuar a ser negociado. A especificação de estado de ordem FIX, que muitos sistemas de negociação seguem, possui um status separado de “cancelamento pendente” exatamente por esse motivo. Também permite que uma ordem cancelada contenha negociações executadas. O status sozinho não informa quanto foi negociado; as quantidades informam.
5. Os resultados vão para os sistemas pós-negociação
Uma vez que a negociação é concluída, o OMS passa os preenchimentos, detalhes da conta e identificadores para os sistemas de back-office. A equipe de operações então verifica esses registros em relação às confirmações de corretores, locais e empresas de compensação.
Para um gestor de fundos que comprou ações para vários portfólios ao mesmo tempo, este também é o momento em que a quantidade executada é alocada a cada portfólio de acordo com regras pré-acordadas.
Executar um comércio não é o mesmo que liquidá-lo. Nos mercados de valores mobiliários, a liquidação é a troca real de valores mobiliários e dinheiro, gerenciada pela infraestrutura de compensação e liquidação. O OMS fornece detalhes de conta e alocação usados nesse processo; ele não detém os ativos nem completa a liquidação em si. As ações dos EUA, por exemplo, se liquidam um dia útil após o comércio (T+1).
Exemplo: um pedido parcialmente preenchido que é cancelado
Aqui está a ordem da introdução em detalhes. É um exemplo hipotético: comprar 1.000 ações da XYZ com um limite de $25, válido para o dia. A conta começa sem ações da XYZ, todas as verificações são aprovadas e as taxas são deixadas de fora.
- O corretor aceita a ordem. 400 ações são negociadas a $24.98, e 600 ainda estão em andamento.
- O comprador pede para cancelar o restante. O cancelamento está agora pendente.
- Antes de ser confirmado, 150 ações a mais estão sendo negociadas a $24,99.
- O corretor confirma o cancelamento das 450 ações restantes.
Follow the cancellation
An illustrative buy order for 1,000 shares. A cancellation stops the remaining quantity; it does not reverse existing fills.
Order status: Canceled
- Shares filled
- 550
- Still working
- 0
- Canceled
- 450
The remaining 450 shares are canceled. The 550 shares already bought remain in the account. No quantity is still working.
Read the complete sequence
- First fill: 400 shares trade at $24.98. Another 600 are still working.
- Cancel requested: a cancellation is pending. The 600 remaining shares can still execute.
- Another fill: 150 more shares trade at $24.99 before cancellation is confirmed. Filled quantity is now 550; 450 remain working.
- Cancel confirmed: those 450 shares are canceled. The final result is 550 bought, 450 canceled and none working.
O resultado final:
- Comprado: 550 ações
- Cancelado sem negociação: 450 ações
- Ainda trabalhando: 0 ações
- Custo total: (400 × $24,98) + (150 × $24,99) = $13.740,50
- Preço médio: $13,740.50 ÷ 550 ≈ $24.9827
As ações canceladas não desempenham nenhum papel no preço médio, porque nunca foram negociadas. O cancelamento também não desfaz as 550 ações já compradas.
Se o comprador ainda quiser 1.000 ações no total, a lacuna restante é de 450. Alguém que olhasse apenas para o primeiro preenchimento e enviasse uma nova ordem de 600 acabaria com 1.150 ações se essa ordem fosse totalmente preenchida.
Se o comprador nunca tivesse pedido para cancelar, as ações não preenchidas simplesmente teriam expirado ao fechamento, porque esta era uma ordem de dia.
Sistemas reais podem rotular esses passos de maneira diferente ou pular algumas mensagens intermediárias, mas as quantidades sempre têm que somar: preenchido + ainda em andamento + cancelado (ou expirado) devem igualar a quantidade atual do pedido, incluindo quaisquer emendas.
OMS vs EMS e outros sistemas de negociação
Vários sistemas podem gerenciar o mesmo pedido, e um produto pode combinar várias funções.
| Sistema | Principal função | Pergunta que responde |
|---|---|---|
| PMS (sistema de gestão de portfólio) | Rastreia portfólios e decide o que comprar ou vender, por exemplo, ao reequilibrar | O que devemos negociar? |
| OMS | Registra pedidos, realiza verificações, rastreia status e entrega resultados para operações | O que foi solicitado, para qual conta e qual é o status? |
| EMS (sistema de gestão de execução) | Dá aos traders ferramentas para trabalhar com pedidos no mercado, frequentemente com dados ao vivo e algoritmos | Como devemos executar este pedido agora? |
| OEMS | Combina funções de OMS e EMS em um único sistema | Ambas as opções acima, em um só lugar |
| Roteador de ordem inteligente | Escolhe onde enviar um pedido com base em regras de roteamento | Qual local deve receber este pedido? |
| Motor de correspondência | Combina ordens de compra e venda dentro de um local de negociação | Quais ordens podem negociar entre si? |
| Back office | Cuida da contabilidade, registros e reconciliação | Todos os registros estão corretos? |
Uma maneira simples de lembrar a diferença: o PMS decide o que negociar, o OMS acompanha o que foi pedido e para quem, e o EMS gerencia como isso é executado. O roteador de ordens inteligente decide onde enviá-lo, e o motor de correspondência emparelha compradores com vendedores dentro do local.
Quem usa um sistema de gerenciamento de pedidos?
Gestores de ativos, fundos de pensão e fundos de hedge (o “lado comprador”) usam um OMS para transformar decisões de investimento em ordens controladas. Eles frequentemente negociam em nome de muitos portfólios ao mesmo tempo, então as regras de alocação e as restrições de investimento são centrais.
Bancos e corretores (o “lado da venda”) recebem ordens de clientes e as enviam para os mercados. Seu OMS precisa lidar com grandes volumes de ordens, limites em nível de cliente e uma clara separação entre as ordens dos clientes e as próprias negociações da empresa.
Empresas de negociação proprietária negociam seu próprio dinheiro e usam gerenciamento de ordens juntamente com suas estratégias e controles de risco.
Investidores de varejo geralmente não veem um OMS pelo nome. Quando você faz um pedido em um aplicativo de negociação, no entanto, os sistemas do corretor realizam os mesmos passos: eles registram seu pedido, verificam seu saldo, enviam o pedido para o mercado e atualizam sua conta conforme os preenchimentos chegam. Quando um aplicativo mostra um pedido como “parcialmente preenchido” ou “cancelamento pendente”, você está vendo os mesmos estados de pedido que um OMS rastreia.
Uma breve história: de chamadas telefônicas a pedidos eletrônicos
Antes da negociação se tornar eletrônica, muitos pedidos eram feitos por telefone ou escritos em bilhetes de papel, e a equipe acompanhava os preenchimentos manualmente. À medida que a negociação eletrônica se espalhou na década de 1990, as empresas precisavam de uma linguagem comum para enviar pedidos entre sistemas. O protocolo FIX surgiu de um projeto de 1992 entre a Fidelity Investments e a Salomon Brothers para trocar informações de pedidos de ações eletronicamente, e mais tarde se tornou um padrão da indústria. FIX é a linguagem compartilhada; o OMS é um dos principais sistemas que a utiliza.
Por que as empresas usam um sistema de gerenciamento de pedidos
Menos erros manuais
Uma quantidade ou preço digitado incorretamente pode ser extremamente caro. Em dezembro de 2005, um trader da Mizuho Securities em Tóquio fez um pedido para vender 610.000 ações a 1 iene em vez de 1 ação a 610.000 ienes, mais de 40 vezes o número de ações que a empresa, J-Com, havia emitido. Um aviso apareceu na tela, mas o trader o ignorou. As tentativas da Mizuho de cancelar foram então bloqueadas por uma falha no sistema da Bolsa de Valores de Tóquio. A perda eventualmente atingiu cerca de 40 bilhões de ienes. Um tribunal mais tarde ordenou que a bolsa pagasse parte disso, mas considerou a Mizuho parcialmente responsável devido a falhas em sua própria gestão de pedidos.
A lição para qualquer OMS: um alerta que pode ser ignorado não é suficiente. Limites de tamanho e preço que realmente bloqueiam uma ordem são o que impede esse tipo de erro antes que chegue ao mercado.
Uma fonte de verdade
Os traders, gerentes de risco, equipe de operações e clientes todos precisam da mesma resposta para “o que aconteceu com este pedido?” Quando cada preenchimento, alteração e cancelamento atualiza um registro central, ninguém precisa juntar a história a partir de e-mails, planilhas e telas separadas.
Controles consistentes
Limites e restrições são aplicados a cada pedido da mesma forma, seja ele originado de uma pessoa, um algoritmo ou uma API. As regras são configuradas uma vez, em vez de serem lembradas por cada trader.
Um rastreamento de auditoria completo
As empresas de trading devem ser capazes de mostrar, muitas vezes anos depois, exatamente o que aconteceu com cada ordem: quem a inseriu, quando foi alterada, para onde foi enviada e o que foi negociado.
Os reguladores dependem desses registros. Nos Estados Unidos, o Rastro de Auditoria Consolidado da SEC é projetado para acompanhar ordens em ações e opções listadas durante todo o seu ciclo de vida, desde a origem até o roteamento, modificação, cancelamento e execução. Regras em outras regiões, como a MiFID II na União Europeia, estabelecem seus próprios requisitos de manutenção de registros. Os mesmos registros são utilizados em revisões de melhor execução, que verificam se as ordens dos clientes foram executadas nas melhores condições razoavelmente disponíveis.
Uma OMS não torna uma empresa compatível por si só, mas produz muitos dos dados dos quais as equipes de conformidade dependem. É por isso que uma boa OMS mantém um histórico completo em vez de sobrescrever o estado anterior de um pedido.
O que pode dar errado na gestão de pedidos
A conexão cai após um pedido ser enviado
A OMS envia um pedido, mas a conexão falha antes que uma confirmação chegue. O pedido pode ou não ter chegado ao seu destino. Simplesmente reenviá-lo poderia duplicar a posição. Um processo de recuperação seguro primeiro verifica o status do pedido com o outro lado e, enquanto isso, mostra à equipe que o resultado está indefinido.
Uma mensagem repetida torna-se um comércio repetido
Quando as conexões se recuperam, os sistemas às vezes reenviam mensagens anteriores. O OMS deve reconhecer que um preenchimento reproduzido é o mesmo negócio que já registrou, não um novo. Se um local posteriormente corrige ou cancela (“anula”) um negócio, essa alteração é armazenada como um novo registro, para que o original permaneça visível.
O sistema perde o controle do que já foi preenchido
O exemplo mais conhecido de problemas na execução de ordens é a Knight Capital. Em 1º de agosto de 2012, um defeito no roteador de ordens automatizado da empresa a deixou incapaz de reconhecer quando as ordens haviam sido executadas. Ela continuou enviando novas ordens. Nos primeiros 45 minutos de negociação, enviou mais de 4 milhões de ordens enquanto tentava atender apenas 212 ordens de clientes, negociou mais de 397 milhões de ações e perdeu mais de $460 milhões. A SEC descobriu posteriormente que a empresa não possuía controles adequados para limitar as ordens que enviava e as posições que acumulava.
O componente com defeito era um roteador em vez de um OMS, mas a lição se aplica a qualquer sistema de gerenciamento de pedidos. Sempre saiba quanto já foi negociado e tenha limites rígidos que parem o sistema quando os números deixarem de fazer sentido.
O comércio está certo, mas a conta está errada
Uma negociação ao preço certo ainda pode causar uma perda se for registrada na conta errada. É por isso que mudanças em alocações e contas geralmente requerem permissões, uma razão registrada e uma revisão, e por que os registros de pedidos devem ser regularmente reconciliados com os dados do back-office.
Sinais de um OMS bem construído
Seja você avaliando um sistema, usando um no trabalho ou apenas querendo saber como é um “bom” sistema, estas são as situações que separam um OMS confiável de um frágil:
| Situação | O que um OMS bem construído faz |
|---|---|
| Um pedido excede o limite de uma conta | Bloqueia ou envia para aprovação e registra o motivo |
| Um pedido é parcialmente preenchido e, em seguida, cancelado | Mantém as quantidades preenchidas e em trabalho visíveis até que o cancelamento seja confirmado |
| A conexão cai após um pedido ser enviado | Verifica o status real do pedido antes de enviar qualquer coisa novamente |
| Uma mensagem de execução chega duas vezes | Reconhece o duplicado e não conta a negociação duas vezes |
| Uma alocação é alterada após a negociação | Requer permissão e mantém o histórico de mudanças |
| Alguém pergunta o que aconteceu com um pedido antigo | Reconstrói a instrução original, cada alteração e cada preenchimento |
Um sistema construído para um tipo de negócio, como um gestor de fundos de ações, pode também precisar de um trabalho significativo para lidar com outros instrumentos, como moedas ou derivativos.
