Sistema de alocação de comércio

Processamento pós-comercialização.
O que é "Processamento pós-comercialização"
O processamento pós-negociação, após a conclusão do comércio, passa pelo processamento pós-negociação, onde o comprador e o vendedor comparam os detalhes do comércio, aprovam a transação, alteram os registros de propriedade e providenciam a transferência de valores mobiliários e dinheiro. O processamento pós-comercial é especialmente importante em mercados que não são padronizados, como o mercado de venda livre (OTC).
BREAKING 'Processamento pós-comercialização'
O processamento pós-comercial é importante porque verifica os detalhes de uma transação. Os mercados e os preços se movem rapidamente, então, no momento em que as transações devem ser executadas rapidamente. Uma vez que muitas negociações de valores mobiliários são feitas por telefone de um partido para outro, a habilidade de erros e erros humanos existe. O processamento pós-comercial permite que o comprador e o vendedor de valores mobiliários verifiquem detalhes do comércio ou classem os erros.

Sistema de alocação de comércio
Este pedido reivindica o benefício da data de depósito do pedido provisório dos EUA Ser. No. 60 / 215,158 intitulado "Atribuição Comercial", arquivado em 30 de junho de 2000.
ANTECEDENTES DA INVENÇÃO.
Nos mercados de negociação de ações e outros instrumentos financeiros, um comerciante pode comprar e vender instrumentos em nome de diversos clientes e / ou carteiras de investimentos. Quando um comerciante transa um comércio, o número de instrumentos negociados pode não satisfazer uma demanda de negociação pendente para os clientes ou carteiras. Em tal situação, pode haver necessidade de alocar os instrumentos que são negociados entre os clientes ou carteiras em espera. A alocação manual de um comércio pode ser um processo complexo e demorado. Consequentemente, a alocação automatizada de computadores de um comércio é desejável. Uma solução para alocar um instrumento negociado é incluir funcionalidade em um Sistema de Gerenciamento de Ordem (OMS) para realizar alocação de comércio. No entanto, nas OMS existentes, as características de alocação de comércio podem ser insuficientes ou inadequadas. Uma solução para este problema é modificar o software OMS para adicionar recursos de alocação desejados. Como uma questão prática, tal modificação pode não ser viável. Por exemplo, o código de software para uma OMS pode estar sob controle de um fornecedor e não modificável, ou uma rede comercial pode incluir uma variedade de OMSs diferentes e, devido a custos ou outras preocupações, a modificação de cada OMSs pode não ser possível. Consequentemente, as soluções de alocação de comércio baseadas em não-OMS são desejáveis.
SUMARIO DA INVENÇÃO.
Em geral, em um aspecto, a invenção possui um método implementado por computador para alocar um comércio de instrumentos financeiros entre um grupo de carteiras. O método inclui receber uma mensagem descritiva de um comércio de um instrumento financeiro. A mensagem pode incluir um identificador de instrumento financeiro e um tamanho do comércio. Uma coleção de carteiras é então identificada com base em uma correspondência entre as classes de risco associadas às carteiras e a classe de risco do instrumento financeiro negociado. O comércio é então alocado entre cada uma das carteiras com base em uma relação alvo associada a cada carteira.
Em geral, em outro aspecto, a invenção possui um sistema de distribuição de comércio que inclui um sistema de computador com uma interface de rede sobre a qual as mensagens podem ser trocadas com um sistema de gerenciamento de pedidos. O sistema de computador também é acoplado a um primeiro banco de dados que armazena dados que associam carteiras com classes de risco e relações de destino. Um segundo banco de dados armazena instruções para configurar o sistema para receber mensagens de sistemas de gerenciamento de pedidos. Cada mensagem pode incluir um identificador de instrumento financeiro, um tamanho do comércio e um identificador de classe de risco. As instruções também configuram o processador para consultar o primeiro banco de dados para determinar as carteiras que estão associadas à classe de risco identificada de um comércio específico, bem como para determinar uma relação de destino para cada uma das carteiras. O processador aloca o comércio entre cada uma das carteiras com base nos índices alvo.
As implementações podem incluir um ou mais dos seguintes recursos. Uma relação alvo pode ser calculada para cada carteira com base no capital disponível em cada carteira e capital disponível em outras carteiras na mesma classe de risco. As carteiras podem incluir portfólios multi-estratégia. Um portfólio multi-estratégia está associado a duas ou mais classes de risco e, em correspondência, duas ou mais razões alvo. A alocação a um portfólio multi-estratégia pode ser baseada no índice alvo da classe de risco correspondente ao do instrumento negociado.
Um comércio pode ser alocado em múltiplos de um tamanho de lote predeterminado. A alocação pode resultar na geração de uma coleção de mensagens (por exemplo, uma para cada carteira que recebe uma alocação do comércio). Cada mensagem identifica uma parte do comércio atribuído a uma das respectivas carteiras. As mensagens comerciais geradas pelo sistema de gerenciamento de alocação podem então ser enviadas para um sistema de gerenciamento de portfólio.
As implementações também podem incluir instalações para corrigir negócios (e, correspondentemente, alocações de comércio). A correção de um comércio pode incluir o recebimento de dados de correção comercial no sistema de gerenciamento de alocação. Os dados de correção comercial identificam um comércio previamente alocado que deve ser corrigido. Um banco de dados de histórico de alocação de comércio pode ser consultado para identificar os índices alvo que foram usados ​​para alocar o comércio anteriormente alocado. As mensagens de correção comercial podem ser geradas para cada carteira envolvida na alocação anterior, de modo a alterar as alocações anteriores. As mensagens de correção comercial podem ser enviadas para um sistema de gerenciamento de portfólio. O sistema de gerenciamento de portfólio também pode manter uma contabilidade dos instrumentos financeiros em cada carteira e livre capital associado a cada carteira. Múltiplos sistemas de gerenciamento de pedidos podem ser conectados ao sistema de gerenciamento de alocação usando uma interface de rede padrão e protocolo de troca de mensagens (por exemplo, o protocolo FIX, um protocolo XML ou outro protocolo). Outros sistemas (por exemplo, sistemas de reconciliação contábil e de portfólio) também podem ser conectados ao gerenciador de alocação.
Os detalhes de uma ou mais formas de realização da invenção são apresentados nos desenhos anexos e a descrição abaixo. Outras características, objetos e vantagens da invenção serão evidentes a partir da descrição e desenhos e das reivindicações.
DESCRIÇÃO DOS DESENHOS.
FIG. 1 é um diagrama de arquitetura do sistema de alocação.
FIG. 2 é um diagrama de arquitetura do gerenciador de alocação.
DESCRIÇÃO DETALHADA DA INVENÇÃO.
O Gerenciador de Alocação (AM) é um componente de sistema de negociação que pode alocar automaticamente um comércio de um instrumento financeiro entre múltiplas carteiras de investimento. Por exemplo, um comerciante pode comprar 100 ações de uma ação "MYSTOCK" (um ticker fictício de ações) e o Allocation Manager pode alocar automaticamente 60 ações desse comércio para uma primeira carteira e as 40 ações restantes em uma segunda carteira. O gerente de alocação pode alocar um comércio entre múltiplas carteiras usando a classificação atribuída ao comércio e associada a cada carteira. Na implementação descrita aqui, o Allocation Manager realiza a alocação comercial com base em uma classificação de risco (uma "classe de risco") que pode refletir uma estratégia de investimento associada a um portfólio. Outras classificações também podem ser usadas (por exemplo, classificações baseadas no comércio ou tamanho do portfólio, classificações baseadas em volume comercial, classificações de segmentos do setor, etc.).
O Gerenciador de alocação pode ser implementado como um componente de "middleware" que funciona como uma interface entre outros componentes do sistema comercial. FIG. 1 mostra uma arquitetura exemplar do sistema comercial em que o Allocation Manager 110 é implementado como um componente de middleware que, entre outras coisas, controla o fluxo de dados relacionados ao comércio entre um ou mais sistemas de gerenciamento de pedidos (OMSs) 101 (três OMSs mostrados), um sistema de gerenciamento de portfólio 102, um sistema contábil 103 e um sistema de reconciliação comercial 104. Cada um desses sistemas 101 a 104 é discutido com mais detalhes, abaixo. À medida que os dados que se comunicam entre os sistemas 101 a 104 atravessam o Gerenciador de Alocações 110, o Gerenciador de Alocação 110 pode alterar esses dados para realizar operações de alocação de comércio que dividem o comércio entre múltiplas carteiras. Por exemplo, o Gerenciador de alocação pode receber dados da OMS 101, indicando que ocorreu um comércio por trezentas ações da ação MYSTOCK e, com base em uma classificação atribuída a essa negociação, pode alocar as trezentas ações em duas ou mais carteiras. Outras operações relacionadas a negociações alocadas também são realizadas pela AM 110.
O Gerenciador de alocação comunica com outros sistemas 101 a 104 sobre as interfaces de mensagens 111 a 114. Interfaces 111 - 114 podem ser interfaces baseadas em software implementadas por chamadas de procedimentos de aplicativos de software, interfaces baseadas em mensagens que comunicam dados entre diferentes sistemas de computador ou outros tipos de interfaces de programação de aplicativos (APIs). Em algumas implementações, uma ou mais das interfaces 111 - 114 e sistemas 101 - 104 e 110 podem ser implementadas em um único computador, enquanto que em outras implementações, uma ou mais das interfaces 111 a 114 podem acoplar computadores diferentes em uma Área Local Rede (LAN) ou outra conexão de rede. Embora as interfaces 111 a 114 sejam separadas logicamente, os dados trocados em cada uma dessas interfaces podem ser transmitidos através de um mesmo dispositivo de interface física. Os dados trocados pelas interfaces 111 a 114 podem estar no formato FIX. O FIX é um protocolo de troca de dados usado na indústria comercial para comunicar dados relacionados ao comércio. As interfaces 111 a 114 também podem incluir APIs alternativas ou adicionais. Por exemplo, o protocolo FIX pode ser complementado, substituído ou encapsulado dentro de transferências de dados baseadas em linguagem de marcação extensível (XML) que podem ser usadas para trocar dados pelas interfaces 111 a 114. Os componentes do sistema comercial 101 - 114 e suas respectivas interfaces 111 - 114 para o Gerenciador de alocação são detalhados abaixo:
Sistemas de gerenciamento de pedidos (OMSs) e OMS-AM Interface.
Order Management Systems (OMSs) 101 interage com comerciantes para executar negócios, atribuir classificações a esses negócios e gerencia o fluxo de negócios entre comerciantes. O Gerenciador de alocação pode interagir com uma ou mais mensagens OMS 101 através de mensagens FIX e / ou outras mensagens da API trocadas pela interface 111. As comunicações da API não-FIX podem ser usadas para acessar dados AM que não são acessíveis pelo protocolo FIX (como as porcentagens de alocação de comércio padrão do Allocation Manager), enquanto as mensagens FIX podem ser usadas para enviar informações do Gestor de Alocações sobre negócios checados. As comunicações da API não-FIX podem ser implementadas usando consultas de banco de dados com base na linguagem de consulta estruturada (SQL), no protocolo Java ™ Database Connectivity Protocol (JDBC) ou no protocolo Open Database Connectivity (ODBC). Outros protocolos de acesso a dados também podem ser usados.
OMSs 101 podem ser construídos usando componentes comercialmente disponíveis. Por exemplo, a estrutura baseada em El-Trader Java / CORBA da InfoReach, Inc. pode ser usada para criar uma OMS. O Gerenciador de alocação pode receber mensagens FIX da OMS detalhando negócios cheios. O Gerenciador de alocação aloca os negócios checados de acordo com as regras de negócios (explicado abaixo). Uma vez que o comércio é alocado, um grupo de mensagens FIX é enviado para o sistema de gerenciamento de portfólio 102 detalhando cada percurso alocado do comércio. Ao enviar e receber essas mensagens FIX, o Gerenciador de alocação pode usar o mecanismo FIX da InfoReach, Inc. Este mecanismo FIX consiste em uma coleção de pacotes de classe Java reutilizáveis ​​que fornece uma implementação multi-usuário e multi-threaded do protocolo FIX.
Sistema de gerenciamento de portfólio (PMS) e interface PMS-AM.
O Sistema de Gerenciamento de Carteira (PMS) 102 recebe mensagens FIX identificando trocas alocadas do Gerenciador de Alocação (AM). Um único comércio inserido no OMS 101 e comunicado ao AM 110 como uma única mensagem pode resultar em várias mensagens FIX sendo formadas no AM e enviadas para o PMS pela AM. Cada uma das mensagens deste grupo identifica uma parte do comércio original (uma "perna" desse comércio) alocado a um portfólio específico. O PMS 102 pode ser implementado usando componentes comercialmente disponíveis.
Sistema de contabilidade (AS) e AS-AM Interface 113.
O Sistema de Contabilidade (AS) 103 pode acompanhar o capital livre e outros dados relevantes para determinadas carteiras. Estes dados podem ser trocados entre AS e AM em uma interface 113. Os dados fornecidos pelo AS ao AM podem ser usados ​​para estabelecer as posições de capital do início do dia para cada carteira, bem como para transferir outras informações financeiras e de conta entre AS e AM. O Sistema de Contabilidade pode ser implementado usando software de contabilidade de terceiros, como o sistema de conta Genebra produzido pela Advent Software, Inc. O sistema de contas de Genebra é um sistema de contabilidade de carteira para investidores globais. O Sistema de Contabilidade de Genebra oferece acesso aberto a dados através do protocolo ODBC (Microsoft Open Database Connectivity) e permite o uso de ferramentas de relatórios baseadas em SQL padrão do setor para acessar dados. Em um sistema baseado em Genebra e, dependendo dos dados de classificação ou de outros dados exigidos por uma implementação AM particular, os dados trocados pela interface 113 podem incluir dados relacionados a contabilidade, atividade de conta, avaliação, estoque, razão, gerenciamento, festas, preços, extrato e dados do histórico de transações.
Sistema de reconciliação (RS) e RS-AM Interface.
O sistema do Sistema de Reconciliação (RS) 104 fornece dados de reconciliação de conta para o Gerenciador de Alocação. Os dados de reconciliação podem ser usados, por exemplo, para determinar instrumentos de negociação específicos para bloquear. Os dados do instrumento bloqueado podem ser comunicados à AM sobre a interface 114 e podem ser encaminhados para as OMS 101 pela AM. O RS pode ser implementado usando software de terceiros. Por exemplo, o software Recon, disponível da Financial Models Company, Inc., pode ser usado. A Recon é uma aplicação baseada em computador comercialmente disponível que pode trabalhar com os sistemas de gerenciamento de portfólio de outras partes e pode automatizar a reconciliação de transações, participações e / ou saldos de caixa entre gestores de investimentos, detentores, corretores / revendedores e / ou entre fontes internas.
Recon pode receber dados de uma variedade de Prime Brokers e agregar esses dados para construir uma visão de comércio abrangente que será comparada aos registros do Accounting System 103 para detectar quebras comerciais. Se uma ruptura comercial for encontrada, o Recon enviará dados para o Gerenciador de Alocações, indicando trocas quebradas. O Gerenciador de alocação pode usar esses dados para determinar o bloqueio imposto em vários instrumentos.
Execução Exemplar do Gerenciador de alocação.
FIG. 2 mostra uma implementação baseada em arquitetura Common Broker Architecture (CORBA) de um Gerenciador de alocação. O CORBA é um componente de software independente do fornecedor e arquitetura de mensagens e infra-estrutura que as aplicações de computador podem usar para trabalhar em conjunto através de redes. Uma arquitetura de software baseada em CORBA, juntamente com o uso dos padrões associados do Protocolo de Interoperabilidade da Internet (IIOP), pode facilitar a comunicação entre o programa independente do tipo de computador, sistemas operacionais, linguagem de programação e rede em uso por cada programa. A implementação de AM 200 partições funcionalidade entre um servidor 220 e um componente de cliente 210. O componente do servidor 220 processa dados relacionados ao comércio enquanto o componente do cliente 210 pode interagir com o componente do servidor para monitorar a operação do servidor 220 e para configurar a operação do servidor (por exemplo, fornecendo dados, estabelecendo limites, etc.). O uso de uma arquitetura baseada em CORBA, bem como o particionamento da funcionalidade AM entre componentes distintos do servidor e do cliente, é opcional. Podem ser utilizadas outras arquiteturas de software (por exemplo, uma arquitetura Microsoft COM Distributed COM ou COM + ou uma arquitetura proprietária).
O Gestor de Alocações inclui um banco de dados 222 que fornece um depósito central para os dados comerciais recebidos das OMSs e para os dados do diário sobre os negócios alocados gerados pelo Gerenciador de Alocações. Os dados no banco de dados 222 também podem servir como um repositório para porcentagens de alocação calculadas, para posições de instrumentos intra-dia e para dados utilizados para auditar operações de gerenciador de alocação para detectar erros e quebras de comércio. O banco de dados 222 pode ser um banco de dados na memória (por exemplo, uma estrutura de dados na memória RAM), pode ser um banco de dados relacional (por exemplo, um Oracle 8i, Informix, Microsoft SQL Server ou outro banco de dados relacional), ou pode ser implementado usando outro funções de armazenamento e recuperação de dados.
O Gerenciador de alocação 110 pode usar o banco de dados 222 para rastrear uma série de itens de dados diferentes. Esses itens de dados são usados ​​para executar, corrigir e alterar negócios, bem como para operações, administração, manutenção e provisionamento (OAMP) e geração de relatórios. Os dados rastreados no banco de dados 222 podem incluir dados relacionados a (i) negociações alocadas; (ii) substituir (por exemplo, todas as transações que fornecem índices de alocação externos à aplicação AM, (iii) porcentagens de metas baseadas em cada combinação única de portfólio e risco, (iv) fechar dados que identificam negócios que resultam em uma situação de bloqueio; v) dados de exceção que identificam situações de exceção (por exemplo, quando uma substituição causa uma posição longa e curta no mesmo instrumento em fundos (ou Classes de Risco) ou quando a reconciliação com o Prime Broker contém uma interrupção comercial (ou seja, Saídas de Quantidade e Não Sabe)); (vi) dados de alteração (incluem dados sobre todas as negociações canceladas, bem como as negociações corrigidas. Os cancelamentos e correções estão vinculados usando um número de identificação de referência).
Exemplos de dados que podem ser usados ​​pelo Gerenciador de alocação e que podem ser armazenados no banco de dados 222 seguem:
Porcentagem de alocação: um campo de porcentagem de porcentagem de alocação contém dados que identificam os rácios de alocação comercial usados ​​pelo gerente de alocação para alocar um comércio. Tamanho de alocação: um campo de dados de tamanho de alocação contém dados que identificam uma série de ações ou contratos alocados para uma carteira e Classe de Risco. Identificador AM - O campo de dados do identificador AM contém um identificador atribuído às pernas de um comércio que são formadas pelo Gerenciador de Alocação durante o processo de alocação de um comércio original para várias carteiras (cada perna alocada recebe uma ID AM exclusiva que, em conjunto com uma OMS ID, pode ser usado para criar um registro exclusivo. Indicador de Compra / Venda - O Indicador de Compra / Venda identifica o lado de uma transação. Os valores podem incluir, por exemplo, Comprar, Vender, Vender Curto e Capa Curta. Cancelar / Identificar corretamente - Este campo identifica se a transação é um cancelamento ou um correto. O campo é gerado por uma Ferramenta de Alteração de Comércio (TAT). Comentários - Quando um comércio é inserido com uma porcentagem de alocação de substituição, um comerciante pode ser solicitado a inserir um motivo para O campo de comentário contém o motivo inserido e pode ser fornecido ao Gerenciador de Alocações para revisão e / ou para o processamento de decisão. Porcentagem Padrão - O campo Porcentagem Padrão contém uma porcentagem de alocação padrão que O Gerente de Alocação teria aplicado a um comércio substituído se o comércio não tivesse sido substituído. Entidade - Este campo identifica a informação da entidade proprietária associada a um fundo. Fundo - O campo do Fundo captura a estrutura do fundo e indica se faz parte do fundo Multi-estratégia ou se é uma estratégia independente (por exemplo, obrigações convertíveis, arbitragem de risco e valor relativo). Instrumento - O campo do instrumento contém o símbolo no qual o comércio foi feito. Última atualização: o campo Última Atualização identifica uma data em que as porcentagens de destino foram alteradas pela última vez. Tipo de bloqueio: o tipo de bloqueio imposto pelo gerente de alocação em um determinado comércio. Os valores podem incluir Hard Lock, Soft Lock e Queue. Identificador OMS - O identificador OMS é passado em uma mensagem FIX para o Gerenciador de alocação. É um identificador exclusivo atribuído a uma troca por uma OMS. Tamanho da ordem - Fornece o tamanho de um comércio original. Este campo não contém quantidades atribuídas. Percentagem de substituição - A porcentagem de substituição é a porcentagem de alocação inserida externamente que substitui as regras de alocação e arredondamento do Gerenciador de alocação. Classe de Risco - O campo Classe de Risco identifica uma associação de classificação de risco com um comércio ou portfólio. Por exemplo, a Classe de Risco pode indicar que uma troca deve ser alocada entre carteiras de títulos convertíveis ou entre carteiras de arbitragem de risco. Subtotal - O campo Subtotal contém o total agregado de porcentagens para a Classe de Risco específica. Identificador do terminal - O identificador do terminal identifica um terminal comercial do qual o comércio foi inserido em uma OMS. Este elemento de dados é passado para o Gerenciador de Alocações através da mensagem FIX. No caso de uma alteração ou correção, o identificador de terminal pode conter o nome da máquina em que a porcentagem de destino foi alterada. Tempo: vários parâmetros de tempo diferentes podem ser registrados, incluindo, entre outros, o horário do sistema em que as porcentagens alvo foram alteradas; o tempo que uma transação foi inserida no sistema OMS ou uma mudança foi inserida; um momento em que um comércio foi preenchido. Data de comércio - A data de negociação indica a data em que uma operação foi preenchida. Identificador de usuário - O identificador de usuário é um identificador (por exemplo, um nome de login) do usuário que inseriu o comércio na OMS. Isso é passado para o Gerenciador de alocação por uma mensagem FIX.
O banco de dados 222 pode conter dados adicionais ou alternativos. Além disso, os campos de dados anteriores podem estar logicamente inter-relacionados em registros de banco de dados e podem aparecer em locais diferentes (ou seja, em diferentes registros de banco de dados e em diferentes tipos de registro).
O AM processa os dados recebidos dos sistemas 101 a 104, bem como os dados no banco de dados 222 usando regras de negócios. Cada regra de negócios inclui lógica usada para controlar uma operação de alocação. O exemplo de regras comerciais aqui contidas implementa um esquema de alocação de comércio pelo qual os negócios podem ser alocados com base em porcentagens de metas para operações de abertura e índices de fechamento para posições de fechamento. Uma AM pode validar o lado do comércio e também a posição do instrumento que está sendo negociado e determinar se o comércio é uma transação de abertura ou encerramento. Um AM também pode determinar o identificador do tipo de comércio (por exemplo, comprar, vender, vender curto, cobrir curto e curto contra a caixa). As negociações podem ser alocadas entre uma ou mais carteiras e classes de risco sujeitas à discrição do comerciante.
Uma AM pode alocar negócios entre múltiplas carteiras com base em posições de capital livre em cada carteira. Essas posições de capital livre são usadas para calcular porcentagens de metas que determinam como um comércio particular é alocado entre múltiplas carteiras e classes de risco. O capital livre em uma carteira pode ser subdividido em função de uma ou mais classes de risco associadas à carteira. Os dados de capital livre podem ser obtidos automaticamente, por exemplo, por uma transferência de dados através da interface 113 entre o AM e o AS 103. Em algumas implementações, dados de capital gratuitos também podem ser inseridos manualmente através de uma interface do Gerenciador de Alocação.
Uma AM também pode aceitar negociações de substituição da OMS. Um comércio de substituição contém alocações especificadas pelo comerciante de um instrumento negociado entre várias Classes de Risco; a AM atribui um comércio de substituição de acordo com os dados de alocação recebidos (ou seja, operações de substituição podem ser usadas para inibir a funcionalidade de alocação automática do Gerenciador de alocação). Ao processar um comércio de substituição (bem como durante o processamento de transações sem substituição), o Gerenciador de alocação pode implementar funções de validação para determinar se a alocação do instrumento negociado resulta em uma condição de erro (por exemplo, uma posição longa e curta no mesmo instrumento em fundos). Os dados relativos a uma troca substituída podem ser registrados com uma bandeira indicando que a troca foi substituída. Além das anulações, uma AM também pode processar correções, emendas e cancelamentos de negócios. O Gerenciador de alocação pode atualizar seu banco de dados de posições de portfólio ao cancelar ou corrigir uma negociação.
As negociações podem ser alocadas a carteiras de investimento específicas com base em uma classe de risco associada ao comércio e com carteiras específicas. Em alguns casos, um determinado portfólio de investimentos pode estar associado a múltiplas classes de risco diferentes. Da mesma forma, uma única classe de risco pode ser associada a múltiplas carteiras diferentes. Na descrição a seguir, as regras de negócios (ou seja, a lógica de negócios) e os processos que podem governar um processo de alocação comercial são descritos adicionalmente.
Um comércio pode ser alocado entre carteiras em uma classe de risco com base em um conjunto de índices alvo. Os índices de destino referem-se aos índices em que as posições podem ser abertas nas várias carteiras associadas a uma classe de risco particular. Essas proporções podem ser atualizadas sob demanda (isto é, em tempo real) ou a intervalos predeterminados (por exemplo, no final de cada mês ou trimestre). Para cada classe de risco, uma série de índices de metas determinando como os negócios atribuídos a essa classe de risco estão divididos entre carteiras de investimento. A relação alvo para uma determinada combinação de classe de risco e portfólio é definida como:
T a r g e t R a t i o = Capital disponível no portfólio + Classe de risco Combinação de capital livre total em classe de risco.
Os índices de metas para uma classe de risco particular podem ser calculados com base no capital livre disponível em cada carteira de investimento que é um membro dessa classe de risco. Os rácios para cada soma de classe de risco para 100%, garantindo assim que um comércio seja completamente alocado entre os relevantes carteiras.
Na divulgação que se segue, as operações do Gerenciador de Alocações são explicadas usando as seis carteiras exemplares descritas na tabela a seguir:
Os dados em um banco de dados Allocation Manager podem ser usados ​​para identificar uma ou mais classes de risco (por exemplo, uma classe de risco "Arbitragem de Risco" (RA) ou uma classe de risco "Long Converts" (LC) associada a cada uma dessas carteiras. Além disso, o Gerenciador de alocação pode rastrear os valores de capital gratuitos disponíveis em cada portfólio. A tabela a seguir identifica um conjunto de carteiras de exemplo e sua (s) classe (s) de risco, bem como o valor de capital livre para cada combinação de classe de risco / portfólio:
O Gestor de Alocação pode determinar a classe de capital livre total por risco da seguinte forma:
Capital livre total na classe de risco de arbitragem de risco (RA) = 100 + 120 + 300 + 60 = 580 Capital livre total na classe de risco de conversão longa (LC) = 200 + 80 + 400 + 40 = 720.
Para as carteiras associadas à classe de risco da RA, o Gerenciador de alocação calcula os índices alvo conforme indicado na tabela a seguir:
Para as carteiras associadas à classe de risco LC, o Gerenciador de alocação calcula as seguintes proporções alvo:
Qualquer combinação única de portfólio e classe de risco pode ter zero capital livre disponível. Nesse caso, uma relação alvo não precisa ser calculada para o portfólio, pois uma porcentagem padrão de zero pode ser usada. O Gerenciador de alocação usa os índices de metas calculados mais recentes para alocar novos negócios. O Gerenciador de alocação também pode manter um histórico de todas as atualizações para os índices de destino em um banco de dados. Esta informação de histórico pode ser usada, por exemplo, se uma alocação de comércio anterior deve ser revertida devido a um erro ou outra razão para a alteração de uma negociação anterior.
Cada carteira pode incluir um ou mais instrumentos negociáveis. Por exemplo, um instrumento negociável pode ser uma ação pública ou privada. Para cada instrumento negociado em cada carteira, o portfólio pode conter uma posição que seja longa (& gt; 0), curta (& lt; 0) ou plana (= 0) em relação a esse instrumento. Um comércio alocado pode criar uma posição de abertura (ou seja, uma posição longa ou curta) ou uma posição de fechamento em um fundo específico. A atribuição de um comércio pode variar de acordo com o tipo de posição criada.
Atribuindo posições de abertura.
Se um comércio cria uma posição de abertura, o Gerenciador de alocação aloca o comércio usando os índices de destino disponíveis (a menos que seja substituído de outra forma). Uma posição de abertura é definida como um comércio que faz com que uma posição plana ou longa vá mais longa ou uma posição plana ou curta para diminuir. Por exemplo, se a classe RA do LUX-MS tiver uma posição plana em relação ao estoque MYSTOCK (um ticker fictício de ações), um comércio para comprar 100 ações de uma bolsa de classe RA MYSTOCK criará uma posição de abertura para MYSTOCK no Carteira LUX-MS. Uma posição de abertura também ocorre onde, por exemplo, uma negociação é feita para vender 300 ações da MYSTOCK para LUX-MS que contém uma posição curta (& # 8722; 100 partes) em MYSTOCK. O valor da alocação em uma posição de abertura, portanto, será calculado da seguinte forma:
Razão de destino = A relação de posição de abertura, conforme definido na seção anterior TradeVolume = Quantidade de ação de instrumento da OMS.
Os negócios podem ser alocados em todas as classes de risco associadas à estratégia dada do comércio. Em algumas implementações, podem existir exceções a este esquema geral de alocação. Uma possível exceção é uma substituição. Uma substituição é um caso especial em que o comerciante decide alocar um comércio usando diferentes porcentagens de alocação das porcentagens padrão contidas no Gerenciador de alocação. Por exemplo, uma substituição permite que um comerciante aloque 100% de um comércio de abertura em um estoque MYSTOCK da classe RA para CAY-MS em vez de permitir que o Gerenciador de alocações divida o comércio de acordo com as porcentagens alvo da AM. Os dados inseridos pelo comerciante na OMS, e comunicados ao Gerenciador de alocação através de uma mensagem FIX, podem ser usados ​​para instruir o Gerenciador de alocação para executar esta alocação de casos especiais. Esse processamento de casos especiais é discutido em maior detalhe, abaixo.
Atribuindo posições de fechamento.
Uma posição de fechamento é definida como uma troca que diminui uma posição longa ou curta. Se a posição for plana, o próximo comércio, independentemente de ser uma venda curta ou uma compra, será uma posição de abertura. Se um comércio cria uma posição de fechamento em um portfólio, esse comércio pode ser alocado com base na posição atual de um portfólio nesse instrumento em relação à posição em todos os fundos. Exemplos de uma posição de fechamento incluem:
Um comércio é feito para vender 100 ações da classe de risco da RA Stock MYSTOCK na carteira LUX-MS quando a carteira LUX-MS contém uma posição longa da MYSTOCK de 200 ações. Um comércio é feito para comprar 100 ações da MYSTOCK para a carteira LUX-MS quando a carteira LUX-MS contém uma posição curta de MYSTOCK de 300 ações (& # 8722; 300 ações).
O fechamento de uma posição em um fundo em relação à posição total em todos os fundos com classes de risco similares garante que, como um cargo é fechado, todos os fundos se aproximam de uma posição plana no instrumento específico. Esta abordagem distribui o risco associado à posição de fechamento em fundos.
Se o comércio criar uma situação em que a posição passará de longo para curto ou de curto para longo, é referido como cruzando o limite zero ou um comércio de fronteiras. Nessa situação, o Gerenciador de alocação pode primeiro fechar (aplainar) a posição, usando as regras de posição de fechamento e, em seguida, abra uma nova posição usando as regras das posições de abertura.
Para uma posição de fechamento, a relação de fechamento é calculada da seguinte forma:
CloseRatio = [CurrentRiskClassPosition TotalRiskClassPosition]
CurrentRiskClassPosition = posição atual por carteira, classe de risco e instrumento antes do comércio TotalRiskClassPosition = posição total por classe de risco e instrumento antes da negociação.
O valor do compartilhamento de alocação pode ser derivado pelo Gerenciador de Alocação por uma multiplicação da CloseRatio pelo número de compartilhamentos no comércio (ou seja, volume comercial). A equação é:
Por exemplo, assumindo que as atuais posições em MYSTOCK são detidas pelos seguintes fundos:
Uma transação para vender 1500 ações da MYSTOCK será uma transação de posição de fechamento e será alocada da seguinte forma:
Se a transação tivesse envolvido uma venda de 1000 ações, os valores da ação alocada seriam iguais aos números "# 8722; 133.333, # 8722; 200, # 8722; 600 e" 66.667 ", respectivamente. Em algumas implementações, os compartilhamentos devem ser alocados em montantes inteiros e, em alguns casos, em lotes de tamanho específico (por exemplo, a alocação pode ser em unidades de 100 partes e múltiplos; Allocation Manager may invoke a set of rounding rules to avoid unwanted allocations of fractional shares and unwanted odd-lot allocations. Rounding rules are discussed further, below.
Allocating Across Risk Classes.
In some implementations, an Allocation Manager may incorporate functionality to allocate trades across Risk Classes (e. g., a particular trade may be allocated across both the RA and LC risk classes). To do so, the Allocation Manager may separate an original trade into multiple trades designated for each Risk Class and then process the trades according to the prescribed allocation percentages.
For a multi-risk class trade (i. e., a multi-strategy trade), the different risk classes, and a percentage allocation of the trade into the different risk class, may be specified by a trader at an OMS interface. FIX message parameters may be used to communicate this risk class allocation from the OMS to the Allocation Manager. For example, the OMS may create a delimited string in a FIX message's custom field to identify the risk classes requested. Allocation Manager can parse this risk class identification string and create an allocation for each risk class identified. Other FIX custom data elements describing the selected risk class allocation would be delimited similarly. When a trade is allocated among multiple risk classes, FIX sequence numbers (i. e., the sequence numbers contained in the ExecID and ExecRefID) fields can be generated to track each of the allocated legs. In addition, operations to determine, validate, and handle allocation errors, as well as other transaction processing, may be repeated on a per-Risk Class basis. For example, Cancels and correct operations will be repeated for each of the different risk classes.
Allocation of a trade may cause a round lot trade to be broken into fractional shares (and contracts) and into odd lots. The Allocation Manager may avoid allocation by fractional shares or into odd lots using rounding rules. Rounding rules may be specific to certain types of instruments, risk classes, etc. For example, allocated equities may be rounded to a lot size of 100 shares, while options and futures may be rounded to 1 contract. In some cases, these limits are fixed, while in others they are user-definable (e. g., a user may set the minimum lot rounding size through a graphical user interface).
Target and Closing Ratios.
The Allocation Manager ensures that target ratios and closing ratios add to 100% for each Risk Class. Rounding may result in a in which the sum of the target or closing ratios per Risk Class is not 100%. The Allocation Manager may implement rules to adjust ratios to 100%. The following are a set of example adjustment rules:
1. Calculate the difference between 100% and the sum of the rounded ratios. 2. Add the difference to the Entity, Fund, Risk Class with the greatest ratio (target or closing). 3. If two or more ratios are equal, the difference may be applied to one or more of those funds in a pre-designated order. For example, if both Multi-strategy funds (CAY-MS and LUX-MS) have equal ratios, the CAY-MS fund may receive the difference. If a Multi-strategy fund is not involved then a single strategy fund (e. g., CAY-RA, CAY-LC, LUX-RA, or LUX-LC) can receive the difference.
The following example illustrates application of the target ratio rounding rules. Each table demonstrates how the Allocation Manager application would allocate a trade based on the given free capital and position information.
Given the current free capital figures:
In this case, the sum of the rounded target ratios does not equal 100%, but rather 99.9%. The rounding rules may result in the additional 0.1% being added to the CAY-RA portfolio because the fund possesses the greatest amount of free capital (i. e., the fund possesses the greatest rounded target ratio).
Assume that LUX-RA portfolio receives a $1000 infusion of capital and the CAY-RA portfolio receives a $800 infusion of capital. The target ratios would adjust as follows:
In this case, the sum of the rounded target ratios does not equal 100%, but rather 99.9%, and the LUX-RA/RA fund and the CAY-RA/RA fund have the same amount of free capital (and rounded target ratios). In this case, assuming that precedence is given to the Cayman Island funds (CAY-RA, CAY-LC, CAY-MS), the Allocation Manager adds the additional 0.1% to the CAY-RA fund.
If an additional $980 were added to the LUX-MS/RA portfolio (i. e., the Risk Allocation portion of the multi-strategy LUX-MS portfolio), the ratios would be calculated as follows:
In this case, the sum of the rounded target ratios does not equal 100%, but rather 99.9%. In addition, the LUX-RA fund, the LUX-MS/RA fund, and the CAY-RA fund all have the same amount of free capital (and rounded target ratios). In this case, the Allocation Manager may add the additional 0.1% to the LUX-MS/RA fund (assuming that Multi-Strategy funds have priority over risk-allocation-only funds).
When Allocation Manager receives an opening trade that produces a fractional or odd lot allocation, the Allocation manger can employ rules to calculate the number of shares to apply to the respective funds. For example, the following rules may be used:
Allocation_Amount=The Allocation 13 Amount value is the number of shares determined to be allocated to a particular portfolio and risk class. The Accocation_Amount value may be derived by multiplying the trade volume by the target ratio for an opening position or the close ratio for a closing position Round, LotSize=Round, LotSize represents a function that will round the Allocation Amount according to the minimum allowable rounding size (this size may be predetermined or configurable).
This opening position calculation is repeated for each portfolio having a risk class that matches the relevant trade's risk class. For example, assume that there is an opening trade of 1000 shares in MYSTOCK which is in the RA risk class, and that the current target ratios are as follows:
For a lot rounding size of 100, the Allocation Manager can allocate the trade as follows:
LUX-RA/RA=Round, 100 [0.172*1000]=172, round to 200.
LUX-MS/RA=Round, 100 [0.207*1000]=207, round to 200.
CAY-RA/RA=Round, 100 [0.518*1000]=518, round to 500.
CAY-MS/RA=Round, 100 [0.103*1000]=103, round to 100.
The allocated trades sum to 1000 shares, which equals the trade amount.
In some cases, rounding the trades to lot sizes may result in under-allocation or over-allocation of a trade. For example, for a trade of 1200 shares of MYSTOCK, the following results may be obtained:
LUX-RA/RA=Round, 100 [0.172*1200]=206.4, round to 200.
LUX-MS/RA=Round, 100 [0.207*1200]=248.4, round to 200.
CAY-RA/RA=Round, 100 [0.518*1200]=621.6, round to 600.
CAY-MS/RA=Round, 100 [0.103*1200]=123.6, round to 100.
The allocated trades sum to 1100, but the trade was for 1200. Differences arising between the allocated volume and the trade volume on an opening position will be applied to the portfolio and risk class with the greatest amount of free capital. If free capital is not updated in real time, the portfolio and risk class with the highest target ratio on an opening position may be considered to have the highest amount of free capital. In such a case, CAY-RA/RA will receive 100 shares of MYSTOCK to equate the allocation to the trade. CAY-RA/RA will, therefore, receive 700 (600+100) shares total.
Trades of less than a round lot can be allocated to the fund with the greatest amount of free capital. If several funds have equal target ratios, the trade may be allocated based on the above preference mechanism (other preference mechanisms can also be used).
Closing position trades may be rounded to the nearest unit. For example, assuming the current positions for MYSTOCK are as follows:
A transaction to sell 1000 shares of MYSTOCK will be a closing position transaction and will be allocated as follows:
Funds may, therefore, contain odd lots, but the risk in closing a position will be evenly disbursed to the funds in relation to the current amount of risk held by the fund. This proportionally reduces the position in each portfolio to zero, without creating a long and short position between portfolios. For example, if the MYSTOCK transaction were a sell of 1490, the allocation would be:
This allocation would produce the following ending positions:
If two or more funds have the same position and closing ratio, differences in rounding may be allocated using rules that prioritize particular portfolios and/or risk classes.
In some implementations, closing transactions may be rounded using minimum rounding lot sizes. Special allocation rules may need to be applied when odd lot position exists in one or more of the funds (this situation may occur on an opening position as well when the positions are short). Assume, e. g., that the current positions for MYSTOCK are as follows:
A transaction to sell 1000 shares of MYSTOCK is a closing position transaction and can be allocated as follows:
CAY-RA/MS=[30/1000]*−1000=−30, round to 0.
As a result, the overall collection of portfolios being managed will contain long and short positions within the same risk class. This is shown in the following table:
This creation of both long and short positions may be considered erroneous. An validation procedure may be used to automatically rectify this allocation error by applying the short position to the long position to thereby flatten both positions.
Zero Boundary Transactions.
Zero Boundary transactions are trades that cause an instrument's position to move from long to short or short to long.
When a trade (e. g., a sell transaction) results in change from a long to a short position, that trade is processed by the Allocation Manager as if it consists of both a closing transaction and an opening transaction. The closing portion of the transaction reduces the position in each fund to zero (i. e., flat). The opening portion of the transaction in accordance with the rules explained above. Similarly, a buy transaction that results in a change from a short to a long position is treated as consisting of both a closing transaction and an opening transaction. The closing transaction increases the position in each fund to zero (i. e., flat). The opening transaction then creates a long position.
Amendments and Overrides.
An amendment to an allocated trade may be performed by a Trade Amendment Tool (TAT). The Trade Amendment Tool may be a facility of the OMS, or may be implemented as a separate system. To effect an amendment, a correction message is sent from the TAT to the Allocation Manager. The correction message may include a reference ID to identify the originally entered trade that is to be corrected. Allocation Manager can use the reference ID to match the correction to multiple allocated trades and submit a cancel message to the Accounting System. The correction may be allocated according to the original allocation percentages which may be obtained from a database storing a history of allocation percentages. When a correction changes the instrument, strategy, or quantity, the positions stored in Allocation Manager are correspondingly changed. If the user wishes to edit the percentages of the allocated legs, a trade can be canceled and a new trade entered through the TAT.
When an override is entered, Allocation Manager executes validation routines to ensure that the override does not create an allocation error. If an error is created, the override may be automatically rejected. In some implementations, security features (e. g., password limited access) may restrict access to the TAT. For example, the TAT may be available to operations personnel, but not to traders.
Allocation Manager may accept overrides from OMS without applying the allocation and rounding rules. Validation of the override data may take place in OMS while Allocation Manager may determine if the trade meets required validation criteria. If the validation criteria are met, Allocation Manager will update its intra-day positions and send the trade to the risk management system.
In some implementations, amendments and corrections may be automatically generated or electronically received at an interface from, e. g., an interface to another broker's system (an external broker interface). Electronic amendments may be transmitted to the Allocation Manager on an intra-day basis. When a modification or correction message is received at an external broker interface, that message may be processed at the OMS. The OMS processing may include, e. g., locating the OMS ID that was assigned to the original trade. The original trade's data may be updated in the OMS database and a FIX message may be transmitted to the Allocation Manager to amend the trade. At the Allocation Manager, the electronic amendment message can be matched to the multiple allocated trades (using the OMS ID) and cancel messages generated for each allocated trade. The cancel messages are transmitted from the Allocation Manager to the Accounting System.
Allocation exceptions may occur for a number of different reasons. When an allocation exception occurs, the Allocation Manager may “hard lock” the affected instrument. A hard lock prevents or limits further processing of trades in the affected instrument until the exception condition is resolved. Hard locks may be applied when, e. g., an override causes a long and short position in the same instrument across funds (or Risk Classes) or when reconciliation with an external broker contains a trade break. Processing of these two exceptions are discussed in greater detail in the following sections.
Override Allocation Error.
Overrides are received from the OMS system and may occur for a variety of reasons. For example, overrides may be used to re-align the risk in a given portfolio and risk class with a current amount of free capital. This may occur, for example, following a large infusion of cash into a single fund that distorts the risk of a given position relative to the overall fund.
Overrides may be for either buys or sells and may be on either opening or closing positions. Overrides are sent from the OMS to the Allocation Manager as FIX messages containing data that specifically marks these messages as overrides. Processing of these override messages will, in general, bypass Allocation Manager allocation and rounding rules. When processing an override message, Allocation Manager determines if the override is valid relative to the current position of the instrument in a particular risk class. The override is valid if it does not create a long and short position in the same instrument across funds. If the override is valid, then the Allocation Manager will adjust its intra-day positions for this instrument and submit the trade to the portfolio management system 102 . If the override is invalid then Allocation Manager will flag the trade as an exception and reject the trade. Rejected trades must be investigated, fixed, and re-entered into TAT. Since this “trade” is not a cancellation or correction of a trade stored in Accounting System 103 , it may be processed as a new trade. In some implementations, this trade may be flagged as an amendment, thus permitting it to pass through the Allocation Manager without being subject to a lock queue.
Rejected trades automatically create a lock and all trades in the particular instrument subsequent to the lock are queued. The locked trade and subsequent trades (in the same instrument) are not submitted to TPOS because subsequent allocations are based on the correct allocation of the locked trade (opening and closing trades are allocated differently). By locking on the instrument regardless of the Entity and Risk Class, the system protects the integrity of the allocations considering that the user may have entered the override trade's Risk Class incorrectly. The rejected trade is stored allowing operations to investigate the error and re-enter the trade through TAT. Only trades entered into TAT can pass by the locked queue since they possess an amendment flag that indicates that they are meant to amend a trade. In this case, an allocated Accounting System trade is not being cancel/corrected, but rather a new trade is being entered as an amendment to correct the rejected trade. This “amendment” will be submitted to TPOS if it is valid (i. e., does not create an error condition).
When a rejected trade has been amended, operations will open the Lock Window and remove the instrument from the list of locked instruments. This action will automatically release in sequential order the queued trades for that instrument. The positions will be updated and the trader will process the allocations as intended.
Users may be notified via a standard mail API of an override allocation error. The e-mail addresses of the recipient(s) can be stored in the Allocation Manager database.
Trade breaks are caused when the reconciliation with a Prime Broker returns discrepancies. Trade breaks may be determined based on daily reports generated by the Reconciliation System and which containing trade breaks determined from the previous day's data. When the report is received, it is uploaded to the Allocation Manager with a flag indicating that trade breaks are to be created. Based on data in the Reconciliation System report(s), a lock on a particular instrument is created. Subsequent trades in the locked instrument may be queued in the order that they are received until the lock is removed. In general, a lock is removed following resolution of the trade discrepancy that resulted in the lock. If the trade requires an amendment, the user will use TAT to cancel/correct the trade. A lock may be removed when Allocation Manager receives a new Reconciliation System report. The new report can update trade breaks, thereby, removing a previous day's lock. User may be notified via a standard mail API of a soft lock situation. The e-mail addresses of the recipient(s) will be stored in the Allocation Manager database.
Gaps within the allocation process may exist despite the implementation of hard locks. A first type of gap involves trade breaks. Trade breaks may be detected, e. g., the day after a break occurs. However, following a trade break, and prior to its detection, an incorrect trade may be allocated based on a current target or closing ratios. This trade will then impact the positions within the funds that it was allocated to. Subsequent trades in the same instrument will be allocated according to the new position percentages in the case of a closing transaction. If the previous trade was incorrect the closing transactions throughout the day will be improperly allocated. If there is a large volume of trades in the affected instrument, there may be difficulties in canceling trades subsequent to the break and reentering them after the trade correction is made. The Allocation Manager can include OAMP functionality allowing impacted transactions to be determined and enabling the generation of a report that isolates the impacted trades. This process helps to mitigate allocations based on inaccurate position data.
The second gap type occurs where the incorrect trade is identified on the day of its occurrence and is corrected using the TAT application. Although the trade can be cancelled and corrected, subsequent trades may have been allocated based on the assumption that the preceding trades (and, therefore, positions) were correct. Subsequent trades in the same instrument will be allocated according to an erroneous position in the case of a closing transaction.
End of Day Processing.
At the end of the trading day, Allocation Manager can forward to the Reconciliation System a position file containing all instrument positions as of the close of the trading day. This position file may be compared to a position file generated by the Accounting System. A comparison of these different position files can be used to ensure that the Accounting System has received all allocated trades from Allocation Manager. If the position files disagree, operations can research the discrepancies and resolve the differences before the next day open.
Allocation Manager (and the various systems that Allocation Manager ultimately interfaces with) can include functionality to track and identify unique trades. Trade tracking information can be used for other operations such as trade cancellation and correction. Each trade received from a particular OMS 101 can include a unique trade identifier that, in part, can be used by Allocation Manager to track trades. However, because OMS may independently assign trade identifiers, the Allocation manager may need to add additional identifier information to the OMS identifier (or may replace the OMS supplied identifier) to ensure that trade identifiers are unique across all trades from all OMSs. This helps to ensure that the particular OMSs from which a trade originated can be identified as trades flow through, e. g., the Accounting System 103 , Portfolio Management System 102 , and other trading systems. Furthermore, for allocated trades, additional information is added to the OMS identifier so that each allocated portion of the trade can be tracked. This additional information may be a “leg” identifier that, in combination with the OMS identifier, is unique for every allocated portion (i. e., for each allocated trade sent to the other trading systems 102 – 103 )
The invention may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Apparatus of the invention may be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor; and method steps of the invention may be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output. The invention may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits).
A number of embodiments of the present invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, the current FIX message system does not support convertible bonds. FIX may be modified, or a different protocol substituted, so that the Allocation Manager can interpret convertible bond data. Accordingly, other embodiments are within the scope of the following claims.

Trade Allocation Module (TAM)
The automatic allocation of trades can be configured for client accounts to distribute equally, weighted or by specifying custom rules. The custom allocations grid is used to create rules at client/account/symbol/side/country/custodian granularity, or any combination, with a “closest match” algorithm ensuring the correct rule takes effect. They can also be set to automatically pair off trades fitting pairing criteria. These rules can be updated dynamically throughout the day should there be a need to.
The counterparty fee engine allows the set up and maintenance of the commission structure and regulatory fees needed for each client. Rules can be set up with asset class/account/country granularity, or any combination.
Trades can be aggregated for the same client, symbol and direction through trade bunching. This will create a parent trade which can be allocated and use the fee structure as if they were a single trade with the click of a button.
The Split Commission functionality in TAM allows to simply calculate and charge commission fees across multiple trades with the same client, stock and direction as if it were a single trade, all at the click of a button.
An important part of the middle office workflow is notifying your client or custodian of trades and allocations. TAM makes it simple to generate such reports in a wide range of formats including CSV, PDF and html email. Exports formatted for common custodians such as BNY Melon and Pershing come as part of the vanilla product. The Genesis Report Designer allows for simple creation and maintenance of reports.
Client static underpins most middle-office functionality, with TAM you have the ability to easily set up and maintain client static via the GUI, or source from another system if desired. TAM has been designed to have minimal mandated fields to make the systems integration process simple.
Trades can be sourced from flat file or a feed, manually or programmatically. Using Genesis gateway adapters (for example Kafka, MQ, FIX) it is simple to set TAM up to receive trades from any OEMS in real-time. Trades can also be inserted via CSV, either manually by users of the system, or programmatically (for example when receiving via SFTP). CSV formats are simple to configure, with a focus on minimal mandated fields to make the process simple.
As with all Genesis products, it is simple to define user roles and permissions to ensure functionality is only performed by user who are authorized to do so.

Alocação de ativos.
O que é 'Atribuição de ativos'
A alocação de ativos é uma estratégia de investimento que visa equilibrar o risco e a recompensa mediante a distribuição dos ativos de uma carteira de acordo com os objetivos de um indivíduo, tolerância ao risco e horizonte de investimento. As três principais classes de ativos - ações, renda fixa e caixa e equivalentes - têm diferentes níveis de risco e retorno, então cada um se comportará de forma diferente ao longo do tempo.
BREAKING DOWN 'Atribuição de ativos'
Os investidores podem usar diferentes alocações de ativos para diferentes objetivos. Alguém que está economizando para um carro novo no próximo ano, por exemplo, pode investir seu fundo de poupança de automóveis em uma combinação muito conservadora de caixa, certificados de depósito (CD) e títulos de curto prazo. Outra economia individual para a aposentadoria que pode ser décadas de distância tipicamente investe a maioria de sua conta de aposentadoria individual (IRA) em ações, já que ele tem muito tempo para enfrentar as flutuações de curto prazo do mercado. A tolerância ao risco também é um fator chave. Alguém que não se preocupe em investir em ações pode colocar seu dinheiro em uma alocação mais conservadora apesar de um longo horizonte de tempo.
Alocação de ativos baseada em idade.
Em geral, as ações são recomendadas para períodos de espera de cinco anos ou mais. As contas do caixa e do mercado monetário são apropriadas para objetivos a menos de um ano de distância. As obrigações ficam em algum lugar intermediário. No passado, os assessores financeiros recomendaram subtrair a idade de um investidor de 100 para determinar quanto deve ser investido em ações. Por exemplo, uma criança de 40 anos seria investida em ações em 60%. As variações da regra recomendam subtrair a idade de 110 ou 120, uma vez que a expectativa de vida média continua a crescer. À medida que os indivíduos abordam a idade da aposentadoria, as carteiras geralmente devem passar para uma alocação de ativos mais conservadora, de modo a ajudar a proteger ativos que já foram acumulados.
Alcançando Alocação de Ativos através de Fundos de Ciclo de Vida.
Os fundos de investimento de alocação de ativos, também conhecidos como ciclo de vida ou data-alvo, são uma tentativa de fornecer aos investidores estruturas de portfólio que abordem a idade do investidor, o apetite de risco e os objetivos de investimento com uma repartição adequada das classes de ativos. No entanto, os críticos dessa abordagem apontam que chegar a uma solução padronizada para alocar ativos de portfólio é problemática porque os investidores individuais precisam de soluções individuais.
O Fundo Vanguard Target Retirement 2030 seria um exemplo de um fundo de data-alvo. A partir de 2018, o fundo tem um horizonte temporal de 14 anos até o acionista esperar chegar a aposentadoria. Em 30 de junho de 2018, o fundo possui uma alocação de 74% de ações e 26% de títulos. Até 2030, o fundo mudará gradualmente para um mix mais conservador de 50/50, refletindo a necessidade do indivíduo para uma maior preservação do capital e menos risco. Nos anos seguintes, o fundo se move para 67% de títulos e 33% de ações.

Processamento pós-comercialização.
O que é "Processamento pós-comercialização"
O processamento pós-negociação, após a conclusão do comércio, passa pelo processamento pós-negociação, onde o comprador e o vendedor comparam os detalhes do comércio, aprovam a transação, alteram os registros de propriedade e providenciam a transferência de valores mobiliários e dinheiro. O processamento pós-comercial é especialmente importante em mercados que não são padronizados, como o mercado de venda livre (OTC).
BREAKING 'Processamento pós-comercialização'
O processamento pós-comercial é importante porque verifica os detalhes de uma transação. Os mercados e os preços se movem rapidamente, então, no momento em que as transações devem ser executadas rapidamente. Uma vez que muitas negociações de valores mobiliários são feitas por telefone de um partido para outro, a habilidade de erros e erros humanos existe. O processamento pós-comercial permite que o comprador e o vendedor de valores mobiliários verifiquem detalhes do comércio ou classem os erros.