Sistema de negociação de obrigações

Sistema de negociação de obrigações
(Por Jonathan Simon)
É fácil se distanciar de uma grande coleção de padrões ou de uma linguagem de padrões. Padrões são a abstração de uma ideia de forma reutilizável. Muitas vezes, a natureza muito genérica dos padrões que os tornam tão úteis também os torna difíceis de entender. Às vezes, a melhor coisa para ajudar a entender os padrões é um exemplo do mundo real. Não é um cenário planejado do que poderia acontecer; mas o que realmente acontece e o que vai acontecer.
Este capítulo aplica padrões para resolver problemas usando um processo de descoberta. O sistema que discutiremos é um sistema de negociação de títulos com o qual trabalhei durante dois anos desde o projeto inicial até a produção. Vamos explorar cenários e problemas que foram encontrados e como resolvê-los com padrões. Isso envolve o processo de decisão de escolher um padrão, bem como combinar e ajustar padrões para atender às necessidades do sistema. E tudo isso é feito levando-se em conta as forças encontradas em sistemas reais, incluindo requisitos de negócios, decisões de clientes, requisitos técnicos e de arquitetura, bem como integração de sistemas legados. A intenção desta abordagem é fornecer uma compreensão mais clara dos próprios padrões através da aplicação prática.
Construindo um sistema.
Um grande banco de investimento de Wall Street se propõe a construir um sistema de precificação de títulos em um esforço para simplificar o fluxo de trabalho de sua mesa de negociação de títulos. Atualmente, os corretores de títulos precisam enviar preços para um grande número de títulos para vários locais de negociação diferentes, cada um com sua própria interface de usuário. O objetivo do sistema é minimizar as minúcias de precificação de todos os seus títulos combinados com funcionalidades analíticas avançadas específicas do mercado de títulos em uma única interface de usuário encapsulada. Isso significa integração e comunicação com vários componentes em vários protocolos de comunicação. O fluxo de alto nível do sistema se parece com isso:
Fluxo de Alto Nível.
Primeiro, os dados de mercado entram no sistema. Os dados do mercado são dados sobre o preço e outras propriedades do título, representando o que as pessoas estão dispostas a comprar e vender o título no mercado livre. Os dados de mercado são enviados imediatamente ao mecanismo de análise que altera os dados. Analytics refere-se a funções matemáticas para aplicações financeiras que alteram os preços e outros atributos dos títulos. Estas são funções genéricas que usam variáveis ​​de entrada para adequar os resultados da função a um vínculo específico. O aplicativo cliente que será executado em cada desktop do comerciante configurará o mecanismo de análise por comerciante, controlando os detalhes da análise para cada título que o negociador estiver precificando. Uma vez que as análises são aplicadas aos dados de mercado, os dados modificados são enviados para vários locais de negociação onde os comerciantes de outras empresas podem comprar ou vender os títulos.
Arquitetura com padrões.
Com essa visão geral do fluxo de trabalho do sistema, podemos abordar alguns dos problemas de arquitetura que encontramos durante o processo de design. Vamos dar uma olhada no que sabemos até agora. Os traders precisam de um aplicativo muito responsivo nas estações de trabalho Windows NT e Solaris. Portanto, decidimos implementar o aplicativo cliente como um cliente thick Java devido à sua independência de plataforma e sua capacidade de responder rapidamente aos dados de entrada e de mercado do usuário. No lado do servidor, estamos herdando componentes C ++ legados que nosso sistema irá utilizar. Os componentes de dados de mercado se comunicam com a infra-estrutura de mensagens TIBCO Information Bus (TIB).
Estamos herdando os seguintes componentes:
Servidor de Feed de Preços de Dados de Mercado: Publica dados de mercado de entrada para o TIB. Mecanismo de análise: executa análises em dados de mercado de entrada e transmite os dados de mercado modificados para o TIB. Servidor de Contribuição: Executa toda a comunicação com os locais de negociação. As plataformas de negociação são componentes de terceiros não controlados pelo banco.
Subsistema de Dados de Mercado Legado.
Subsistema de Contribuição Legado.
Precisamos decidir como os subsistemas separados (cliente thick de Java, dados de mercado e contribuição) vão se comunicar. Poderíamos ter o cliente thick se comunicando diretamente com os servidores legados, mas isso exigiria muita lógica de negócios no cliente. Em vez disso, construiremos um par de gateways Java para nos comunicarmos com os servidores legados: o gateway de preços para dados de mercado, um gateway de contribuição para o envio de preços a locais de negociação. Isso alcançará um bom encapsulamento da lógica de negócios relacionada a essas áreas. Os componentes atuais no sistema são mostrados abaixo. As conexões marcadas como. • indicam que ainda não temos certeza de como alguns dos componentes se comunicarão.
O sistema e seus componentes.
A primeira questão de comunicação é como integrar o cliente thick Java e os dois componentes do servidor Java para trocar dados. Vejamos os quatro estilos de integração sugeridos neste livro: Transferência de Arquivos, Banco de Dados Compartilhado, Invocação de Procedimento Remoto e Mensagens. Podemos descartar o Banco de Dados Compartilhado imediatamente porque desejamos criar uma camada de abstração entre o cliente e o banco de dados e não queremos ter o código de acesso ao banco de dados no cliente. A transferência de arquivos também pode ser descartada, uma vez que a latência mínima é necessária para garantir que os preços atuais sejam enviados para os locais de negociação. Isso nos permite optar entre a Invocação de Procedimento Remoto ou o Envio de Mensagens.
A plataforma Java fornece suporte integrado para Invocação de Procedimento Remoto e Mensagens. A integração no estilo RPC pode ser obtida usando o Remote Method Invocation (RMI), o CORBA ou o Enterprise Java Beans (EJB). O Java Messaging Service (JMS) é a API comum para integração no estilo de mensagens. Portanto, ambos os estilos de integração são fáceis de implementar em Java.
Então, qual funcionará melhor para este projeto, Invocação de Procedimento Remoto ou Mensagens? Há apenas uma instância do Gateway de Precificação e uma instância do Contribution Gateway no sistema, mas geralmente muitos Clientes Claros conectam-se simultaneamente a esses serviços (um para cada comerciante de títulos que está conectado em um determinado momento). Além disso, o banco gostaria que este fosse um sistema genérico de preços que pode ser utilizado em outras aplicações. Portanto, além de um número desconhecido de Think Clients, pode haver um número desconhecido de outros aplicativos usando os dados de preços que saem dos Gateways.
Um Thick Client (ou outro aplicativo que usa os dados de precificação) pode facilmente usar o RPC para fazer chamadas para os Gateways para obter dados de preços e chamar o processamento. No entanto, os dados de preços serão constantemente publicados e determinados clientes estão interessados ​​apenas em determinados dados, portanto, pode ser difícil obter os dados relevantes para os clientes apropriados em tempo hábil. Os clientes podem pesquisar os Gateways, mas isso criará muita sobrecarga. Seria melhor que os Gateways disponibilizassem os dados aos clientes assim que estivessem disponíveis. Isso, no entanto, exigirá que cada Gateway monitore quais clientes estão ativos no momento e quais desejam dados específicos; então, quando um novo pedaço de dados se torna disponível (o que acontecerá várias vezes por segundo), o Gateway terá que fazer um RPC para cada cliente interessado para passar os dados para o cliente. Idealmente, todos os clientes devem ser notificados simultaneamente, portanto, cada RPC precisa ser feito em seu próprio encadeamento simultâneo. Isso pode funcionar, mas está ficando muito complicado muito rápido.
Mensagens simplifica muito este problema. Com o Messaging, podemos definir canais separados para os diferentes tipos de dados de preços. Em seguida, quando um Gateway receber um novo dado, ele adicionará uma mensagem contendo esses dados ao Publish-Subscribe Channel desse tipo de dados. Enquanto isso, todos os clientes interessados ​​em um determinado tipo de dados ouvirão o canal desse tipo. Desta forma, os Gateways podem enviar facilmente novos dados para quem estiver interessado, sem precisar saber quantos aplicativos de ouvinte existem ou quais são.
Os clientes ainda precisam ser capazes de invocar comportamentos nos Gateways também. Como há sempre apenas dois Gateways e o cliente provavelmente pode bloquear enquanto o método é chamado de forma síncrona, essas chamadas de cliente para gateway podem ser facilmente implementadas usando o RPC. No entanto, como já estamos usando o sistema de mensagens para comunicação entre o gateway e o cliente, as mensagens provavelmente são uma maneira igualmente boa de implementar a comunicação do cliente para o gateway.
Portanto, toda a comunicação entre os Gateways e os clientes será realizada por meio de mensagens. Como todos os componentes são escritos em Java, o JMS apresenta uma opção fácil para o sistema de mensagens. Isso está efetivamente criando um Message Bus ou uma arquitetura que possibilitará a integração de futuros sistemas com o sistema atual, com pouca ou nenhuma alteração na infra-estrutura do sistema de mensagens. Dessa forma, a funcionalidade de negócios do aplicativo pode ser facilmente usada por outro aplicativo desenvolvido pelo banco.
Componentes Java Comunicando com o JMS.
O JMS é simplesmente uma especificação e precisamos decidir sobre um sistema de mensagens compatível com o JMS. Decidimos usar o IBM MQSeries JMS porque o banco é uma "loja IBM", usando servidores de aplicativos WebSphere e muitos outros produtos IBM. Como resultado, usaremos o MQSeries, pois já temos uma infraestrutura de suporte e uma licença de site do produto.
A próxima pergunta é como conectar o sistema de mensagens do MQSeries ao servidor C ++ Contribution autônomo e aos servidores Market Data e Analytics Engine baseados no TIBCO. Precisamos de uma maneira de os consumidores do MQSeries terem acesso às mensagens do TIB. Mas como? Talvez pudéssemos usar o padrão Message Translator para traduzir mensagens TIB em mensagens do MQSeries. Embora o cliente C ++ para o MQSeries funcione como um Message Translator, usá-lo sacrificaria a independência do servidor JMS. E embora a TIBCO tenha uma API Java, o arquiteto e o gerente do cliente a rejeitaram. Como resultado, a abordagem do Message Translator deve ser abandonada.
A ponte do servidor TIB para o servidor MQSeries requer comunicação entre C ++ e Java. Poderíamos usar o CORBA, mas e as mensagens? Uma análise mais detalhada do padrão Message Translator mostra que ele está relacionado ao Channel Adapter no uso de protocolos de comunicação. O coração de um adaptador de canal é conectar sistemas sem mensagem a sistemas de mensagens. Um par de adaptadores de canal que conecta dois sistemas de mensagens é uma ponte de mensagens.
O objetivo de uma ponte de mensagens é transferir mensagens de um sistema de mensagens para outro. Isso é exatamente o que estamos fazendo com a complexidade adicional da comunicação intra-linguagem de Java para C ++. Podemos implementar o Messaging Bridge entre linguagens usando uma combinação de Channel Adapters e CORBA. Vamos construir dois servidores leves de adaptador de canal, um em C ++ gerenciando a comunicação com o TIB e um em Java gerenciando a comunicação com o JMS. Esses dois Adaptadores de Canal, que são os próprios Endpoint da Mensagem, se comunicarão entre si via CORBA. Como nossa escolha para o MQSeries, usaremos CORBA em vez de JNI, já que é um padrão da empresa. A ponte de mensagens implementa a tradução de mensagens efetivamente simulada entre sistemas de mensagens aparentemente incompatíveis e diferentes idiomas.
Tradutor de mensagens usando adaptadores de canal.
O diagrama a seguir mostra o design atual do sistema, incluindo os Gateways e outros componentes. Este é um bom exemplo de aplicação de padrões. Combinamos dois Channel Adapters com um protocolo sem mensagem para implementar o padrão Message Translator, usando efetivamente um padrão para implementar outro padrão. Além disso, alteramos o contexto do adaptador de canal s para vincular dois sistemas de mensagens a um protocolo de conversão de texto cruzado sem mensagem, em vez de conectar um sistema de mensagens a um sistema sem sistema de mensagens.
O sistema atual com os adaptadores de canal.
Estruturando Canais.
Uma chave para trabalhar com padrões não é apenas saber quando usar o padrão, mas também como usá-lo de maneira mais eficiente. Cada implementação de padrão deve levar em conta detalhes específicos da plataforma de tecnologia, bem como outros critérios de design. Esta seção aplica o mesmo processo de descoberta para encontrar o uso mais eficiente do Publish-Subscribe Channel no contexto do servidor de dados de mercado que se comunica com o mecanismo de análise.
Os dados de mercado em tempo real originam-se do feed de dados de mercado, um servidor C ++ que transmite dados de mercado no TIB. O feed de dados de mercado usa um canal de publicação separado para cada vínculo para o qual está publicando os preços. Isso pode parecer um pouco extremo, já que cada novo vínculo precisa de seu próprio novo canal. Mas isso não é tão grave, já que você não precisa criar canais no TIBCO. Em vez disso, os canais são referenciados por um conjunto hierárquico de nomes de tópicos chamados assuntos. Em seguida, o servidor TIBCO filtra um único fluxo de mensagens por assunto, enviando cada assunto exclusivo para um único canal virtual. O resultado é um canal de mensagens muito leve.
Poderíamos criar um sistema que publicasse em alguns canais e os assinantes pudessem ouvir apenas os preços em que estivessem interessados. Isso exigiria que os assinantes usassem um Filtro de Mensagens ou Consumidor Seletivo para filtrar todo o fluxo de dados por preços de títulos interessantes, decidindo se cada mensagem deve ser processado conforme é recebido. Dado que os dados de mercado são publicados em canais dedicados a títulos, os assinantes podem se registrar para atualizações de uma série de títulos. Isso permite que os assinantes "filtrem" seletivamente assinando canais e recebendo apenas atualizações de interesse, em vez de decidir depois que a mensagem é recebida. É importante observar que o uso de vários canais para evitar a filtragem é um uso não padronizado de canais de mensagens. No contexto da tecnologia TIBCO, no entanto, estamos realmente decidindo se implementamos ou possuímos filtros ou utilizamos a filtragem de canais incorporada ao TIBCO - em vez de usar tantos canais.
O próximo componente que precisamos projetar é o mecanismo de análise, outro servidor C ++ / TIB que modificará os dados de mercado e o retransmitirá para o TIB. Embora esteja fora do escopo do nosso desenvolvimento Java / JMS, estamos trabalhando em conjunto com a equipe do C ++ para projetá-lo, já que somos o principal 'cliente' do mecanismo de análise. O problema em questão é encontrar a estrutura de canal que retransmite de maneira mais eficiente os dados de mercado recém-modificados.
Como já temos um Canal de Mensagem dedicado por vínculo herdado do feed de preço de dados de mercado, seria lógico modificar os dados de mercado e retransmitir os dados de mercado modificados no Canal de Mensagem dedicado de vínculo. Mas isso não funcionará, já que as análises que modificam os preços dos títulos são específicas do trader. Se retransmitirmos os dados modificados no Canal de Mensagens, destruiremos a integridade dos dados, substituindo dados genéricos de mercado por dados específicos do trader. Por outro lado, poderíamos ter um tipo de mensagem diferente para dados de mercado específicos do comerciante que publicamos no mesmo canal, permitindo que os assinantes decidam em qual mensagem eles estão interessados ​​para evitar a destruição da integridade dos dados. Mas os clientes terão que implementar seus próprios filtros para separar as mensagens de outros comerciantes. Além disso, haverá um aumento substancial nas mensagens recebidas pelos assinantes, sobrecarregando-as desnecessariamente.
Existem duas opções:
Um canal por comerciante: Cada comerciante tem um canal designado para os dados de mercado modificados. Dessa forma, os dados originais do mercado permanecem intactos e cada aplicativo negociador pode ouvir o Canal de Mensagem de seus operadores específicos para as atualizações de preço modificadas. Um Canal por negociante por Obrigação: Crie um Canal de Mensagem por comerciante por título apenas para os dados de mercado modificados desse título. Por exemplo, os dados de mercado para o título ABC seriam publicados no canal "Bond ABC", enquanto os dados de mercado modificados para o negociador A seriam publicados no Canal de Mensagens "Trader A, Bond ABC", dados de mercado modificados para o comerciante B em "Trader B , Bond ABC ", e assim por diante.
Um canal por trader.
Um canal por vínculo por trader.
Existem vantagens e desvantagens para cada abordagem. A abordagem por ligação, por exemplo, usa muito mais o Message Channel. Na pior das hipóteses, o número de canais de mensagens será o número total de títulos multiplicado pelo número de operadores. Podemos colocar limites superiores no número de canais que serão criados, uma vez que sabemos que existem apenas cerca de 20 traders e eles nunca têm preço superior a algumas centenas de títulos. Isso coloca o limite superior abaixo do intervalo de 10.000, o que não é tão estranho comparado aos quase 100.000 Message Channel que o feed de preço de dados de mercado está usando. Além disso, como estamos usando o TIB e o Message Channel são muito baratos, o número de Message Channel s não é um problema grave. Por outro lado, o grande número de canais de mensagens pode ser um problema do ponto de vista gerencial. Toda vez que um título é adicionado, um canal para cada negociador deve ser mantido. Isso pode ser grave em um sistema muito dinâmico. Nosso sistema, no entanto, é essencialmente estático. Também possui uma infraestrutura para gerenciar automaticamente os Message Channel. Isso combinado com a arquitetura herdada de um componente legado usando uma abordagem semelhante minimiza a desvantagem. Isso não quer dizer que devamos fazer um número desnecessariamente excessivo de MessageScan. Em vez disso, podemos implementar uma abordagem arquitetônica que usa um grande número de canais de mensagens quando há um motivo.
E há uma razão neste caso que se resume à localização da lógica. Se implementarmos a abordagem por negociador, o mecanismo do Google Analytics precisa de lógica para agrupar os canais de entrada e saída. Isso ocorre porque os canais de entrada do Mecanismo do Google Analytics são por vínculo e os canais de mensagens de saída seriam por comerciante, exigindo que o Mecanismo do Google Analytics roteasse todas as entradas analíticas de vários títulos de um determinado negociante para um Canal de mensagens de saída específico do negociante. Isso transforma efetivamente o mecanismo de análise em um roteador baseado em conteúdo para implementar a lógica de roteamento personalizada para nosso aplicativo.
Seguindo a estrutura do Message Bus, o Mecanismo do Analytics é um servidor genérico que pode ser usado por vários outros sistemas no. Portanto, não queremos obscurecer a funcionalidade específica do sistema. Por outro lado, a abordagem per-bond funciona desde que a ideia de um negociante que detém a produção analítica dos preços dos títulos é uma prática aceita pela empresa. A abordagem por ligação mantém intacta a separação do canal de mensagens do feed de dados de mercado, enquanto adiciona vários outros canais de mensagens. Antes de chegarmos ao cliente, queremos que um roteador baseado em conteúdo combine esses vários canais em um número gerenciável de canais. Não queremos que o aplicativo cliente em execução na área de trabalho do trader esteja ouvindo milhares ou dezenas de milhares de canais de mensagens. Agora a questão é onde colocar o roteador baseado em conteúdo. Poderíamos simplesmente ter o adaptador de canal C ++ / TIB encaminhando todas as mensagens para o gateway de preços em um único canal de mensagem. Isso é ruim por dois motivos; estaríamos dividindo a lógica de negócios entre C ++ e Java, e perderíamos o benefício dos Message Channel s separados no lado do TIB, o que nos permitiria evitar a filtragem mais tarde no fluxo de dados. Analisando nossos componentes Java, podemos colocá-lo no gateway de preços ou criar um componente intermediário entre o gateway de preços e o cliente.
Em teoria, se persistíssemos na separação baseada em títulos dos Message Channel até o cliente, o Gateway de preços retransmitia as informações de preço com a mesma estrutura de canal que o gateway de preços e o mecanismo do Google Analytics. Isso significa uma duplicação de todos os canais TIB dedicados à ligação no JMS. Mesmo se criarmos um componente intermediário entre o gateway de preços e o cliente, o gateway de preços ainda terá que duplicar todos os canais no JMS. Por outro lado, implementar a lógica diretamente no gateway de preços nos permite evitar a duplicação do grande número de canais no JMS - o que nos permite criar um número muito menor de canais na ordem de um por trader. O Gateway de Preços registra-se através do Adaptador de Canal C ++ / TIB como um consumidor para cada ligação de cada operador no sistema. Em seguida, o gateway de preços encaminhará cada cliente específico apenas as mensagens relacionadas a esse comerciante em particular. Dessa forma, usamos apenas um pequeno número de Message Channel no final do JMS, enquanto maximizamos o benefício da separação no final do TIB.
O Fluxo de Dados de Mercado completo para o cliente.
A discussão do layout do Message Channel é um bom exemplo de como a integração de padrões é importante. O objetivo aqui era descobrir como usar efetivamente os canais de mensagens. Dizer que você usa um padrão não é suficiente. Você precisa descobrir como melhor implementá-lo e incorporar em seu sistema para resolver os problemas em questão. Além disso, este exemplo mostra as forças de negócios em ação. Se pudéssemos implementar a lógica de negócios em qualquer um dos nossos componentes, poderíamos ter seguido a abordagem por negociador e implementado uma abordagem geral mais simples com muitos menos canais.
Selecionando um canal de mensagens?
Agora que conhecemos a mecânica da comunicação entre os componentes Java / JMS e os componentes C ++ / TIBCO, e vimos alguma estruturação do Canal de Mensagens, precisamos decidir qual tipo de Canal de Mensagem JMS os componentes Java devem usar para se comunicar. Antes de podermos escolher entre os diferentes canais de mensagem disponíveis no JMS, vejamos o fluxo de mensagens de alto nível do sistema. Temos dois gateways (Preços e Contribuição) comunicando-se com o cliente. Os dados de mercado são enviados para o cliente a partir do Gateway de preços, que os envia para o Contribution Gateway. O aplicativo cliente envia uma mensagem para o gateway de preços para alterar as análises aplicadas a cada vínculo. O Contribution Gateway também envia mensagens para o aplicativo Cliente, transmitindo o status das atualizações de preços para os diferentes locais de negociação.
O fluxo de mensagens do sistema.
A especificação JMS descreve dois tipos de Canal de Mensagem, Canal Ponto-a-Ponto (Fila JMS) e Canal de Publicação-Assinatura (Tópico JMS). Lembre-se de que o caso de usar publicação-assinatura é permitir que todos os consumidores interessados ​​recebam uma mensagem, enquanto o caso de usar ponto-a-ponto é garantir que apenas um consumidor qualificado receba uma mensagem em particular.
Muitos sistemas simplesmente transmitiam mensagens para todos os aplicativos clientes, deixando que cada aplicativo cliente individual decidisse por si mesmo se processaria ou não uma determinada mensagem. Isso não funcionará para nosso aplicativo, pois há um grande número de mensagens de dados de mercado sendo enviadas para cada aplicativo cliente. Se transmitirmos atualizações de dados de mercado para um trader desinteressado, estaremos desnecessariamente desperdiçando ciclos de processadores de clientes decidindo se processamos ou não uma atualização de dados de mercado.
Inicialmente, os canais ponto a ponto soam como uma boa escolha, já que os clientes estão enviando mensagens para servidores únicos e vice-versa. Mas era um requisito de negócios que os operadores pudessem estar logados em várias máquinas ao mesmo tempo. Se tivermos um trader logado em duas estações de trabalho simultaneamente e uma atualização de preço ponto-a-ponto for enviada, somente um dos dois aplicativos cliente receberá a mensagem. Isso ocorre porque apenas um consumidor em um canal ponto a ponto pode receber uma mensagem específica. Observe que apenas o primeiro de cada grupo de aplicativos clientes de um comerciante recebe a mensagem.
Mensagens ponto-a-ponto para atualizações de preços.
Podemos resolver isso usando o padrão Recipient List, que publica mensagens para uma lista de destinatários pretendidos, garantindo que apenas os clientes na lista de destinatários recebam mensagens. Usando esse padrão, o sistema poderia criar listas de destinatários com todas as instâncias do aplicativo cliente relacionadas a cada comerciante. Enviar uma mensagem relacionada a um determinado operador, por sua vez, enviaria a mensagem para cada aplicativo na lista de destinatários. Isso garante que todas as instâncias do aplicativo cliente relacionadas a um determinado operador recebam a mensagem. A desvantagem dessa abordagem é que ela requer um pouco de lógica de implementação para gerenciar os destinatários e despachar mensagens.
Lista de Destinatários para Atualizações de Preços.
Mesmo que o ponto-a-ponto possa funcionar, vamos ver se existe uma maneira melhor. Usando Publish-Subscribe Channel s, o sistema pode transmitir mensagens em canais específicos do comerciante, em vez de canais específicos de aplicativos do cliente. Dessa forma, todos os aplicativos clientes processando mensagens para um único operador receberiam e processariam a mensagem.
Publicação-Assinatura de Mensagens para Atualizações de Preços.
A desvantagem de usar Publish-Subscribe Channel s é que o processamento exclusivo de mensagens não é garantido com os componentes do servidor. Seria possível que várias instâncias de um componente do servidor fossem instanciadas e cada instância processasse a mesma mensagem, possivelmente enviando preços inválidos.
Recordando o fluxo de mensagens do sistema, apenas uma única direção de comunicação é satisfatória com cada Canal de Mensagem. A comunicação servidor-cliente com publicação-assinatura é satisfatória enquanto a comunicação cliente-servidor não é e a comunicação cliente-servidor com ponto-a-ponto é satisfatória enquanto o servidor-cliente não é. Como não há necessidade de usar o mesmo Message Channel em ambas as direções, podemos usar cada Message Channel somente em uma direção. A comunicação de cliente para servidor será implementada com ponto a ponto, enquanto a comunicação servidor a cliente será implementada com publicação-assinatura. Usando essa combinação de Message Channel, o sistema se beneficia da comunicação direta com os componentes do servidor usando o sistema de mensagens ponto-a-ponto e a natureza multicast da publicação-assinatura sem nenhum dos inconvenientes.
Fluxo de mensagens com tipos de canais.
Solução de problemas com padrões.
Padrões são ferramentas e coleções de padrões são caixas de ferramentas. Eles ajudam a resolver problemas. Alguns pensam que os padrões são úteis apenas durante o design. Seguindo a analogia da caixa de ferramentas, isso é como dizer que as ferramentas são úteis apenas quando você constrói uma casa, não quando você a conserta. O fato é que os padrões são uma ferramenta útil em todo o projeto, quando bem aplicados. Nas seções a seguir, usaremos o mesmo processo de exploração de padrão que utilizamos na seção anterior para resolver problemas em nosso sistema atual.
Atualizações de dados de mercado piscando.
Os traders querem que as células da mesa pisquem quando novos dados de mercado são recebidos por um título, indicando claramente mudanças. O cliente Java recebe mensagens com novos dados que acionam uma atualização do cache de dados do cliente e, eventualmente, piscam na tabela. O problema é que as atualizações vêm com bastante frequência. A pilha de threads da GUI está ficando sobrecarregada e, eventualmente, congelando o cliente, já que ele não pode responder à interação do usuário. Vamos supor que o flash é otimizado e se concentrar no fluxo de dados das mensagens através do processo de atualização. Um exame dos dados de desempenho mostra que o aplicativo cliente está recebendo várias atualizações por segundo; algumas atualizações ocorreram com menos de um milissegundo de intervalo. Dois padrões que parecem ajudar a desacelerar o fluxo de mensagens são Agregador e Filtro de Mensagens.
Um primeiro pensamento é implementar um Filtro de Mensagens para controlar a velocidade do fluxo de mensagens, lançando as atualizações recebidas por um curto período de tempo após a mensagem de referência. Por exemplo, vamos dizer que vamos ignorar mensagens dentro de 5 milissegundos um do outro. O Filtro de Mensagens pode armazenar em cache a hora da última mensagem aceitável e rejeitar qualquer coisa recebida nos próximos 5 milissegundos. Embora outras aplicações possam não ser capazes de resistir à perda de dados de tal forma, isso é perfeitamente aceitável em nosso sistema devido à frequência de atualizações de preços.
Filtro de mensagens baseado em tempo.
O problema com essa abordagem é que nem todos os campos de dados são atualizados ao mesmo tempo. Cada título possui aproximadamente 50 campos de dados exibidos ao usuário, incluindo o preço. Percebemos que nem todo campo é atualizado em todas as mensagens. Se o sistema ignorar mensagens consecutivas, pode muito bem estar jogando dados importantes.
O outro padrão de interesse é o Agregador. O Agregador é usado para gerenciar a reconciliação de várias mensagens relacionadas em uma única mensagem, reduzindo potencialmente o fluxo de mensagens. O Agregador pode manter uma cópia dos dados de ligação da primeira mensagem agregada e, em seguida, atualizar apenas as mensagens sucessivas de campos novos ou alterados. Eventualmente, os dados de ligação agregados serão passados ​​em uma mensagem para o cliente. Por enquanto, vamos supor que o Agregador enviará uma mensagem a cada 5 milissegundos, como o Filtro de Mensagens. Mais tarde, vamos explorar outra alternativa.
Agregador com atualizações sucessivas parciais.
O Agregador, como qualquer outro padrão, não é uma bala de prata; tem suas vantagens e desvantagens que precisam ser exploradas. Um potencial menos é que a implementação de um Agregador reduziria o tráfego de mensagens em grande quantidade em nosso caso apenas se muitas mensagens estivessem chegando em um tempo relativamente curto em relação ao mesmo vínculo. Por outro lado, não conseguiríamos nada se o cliente Java receber apenas atualizações para um campo em todos os títulos de traders. Por exemplo, se recebermos 1000 mensagens em um período especificado com 4 títulos de interesse, reduziríamos o fluxo de mensagens de 1.000 para 4 mensagens durante esse período. Alternativamente, se recebermos 1000 mensagens no mesmo período com 750 títulos de interesse, teremos reduzido o fluxo de mensagens de 1.000 para 750 mensagens; relativamente pouco ganho para a quantidade de esforço. Uma análise rápida das atualizações de mensagens prova que o cliente Java recebe muitas mensagens atualizando campos do mesmo vínculo e, portanto, mensagens relacionadas. Então, Agregador é na verdade uma boa decisão.
O que resta é determinar como o Agregador saberá quando enviar uma mensagem que está agregando. O padrão descreve alguns algoritmos para o Agregador saber quando enviar a mensagem. Estes incluem algoritmos para fazer com que o agregador envie seu conteúdo após um determinado período de tempo, após todos os campos obrigatórios em um conjunto de dados terem sido concluídos, e outros. O problema com todas essas abordagens é que o agregador está controlando o fluxo de mensagens, não o cliente. E o cliente é o maior gargalo nesse caso, não o fluxo de mensagens.
Isso ocorre porque o Agregador está supondo que os consumidores de suas mensagens eliminadas (o aplicativo cliente, neste caso) são consumidores orientados a eventos ou consumidores que dependem de eventos de uma fonte externa. Precisamos transformar o cliente em um Consumidor de pesquisa ou em um consumidor que verifica continuamente as mensagens, para que o aplicativo cliente possa controlar o fluxo de mensagens. Podemos fazer isso criando um thread em segundo plano que percorre continuamente o conjunto de ligações e atualizações e exibe todas as alterações que ocorreram desde a última iteração. Dessa forma, o cliente controla quando as mensagens são recebidas e, como resultado, garante que elas nunca ficarão sobrecarregadas com mensagens durante os períodos de alta atualização. We can easily implement this by sending a Command Message to the Aggregator initiating an update. The Aggregator will respond with a Document Message containing the set of updated fields that the client will process.
The choice of Aggregator over Message Filter is clearly a decision based solely on the business requirements of our system. Each could help us solve our performance problems, but using the Message Filter would solve the problem at cost of the system data integrity.
Major Production Crash.
With the performance of the flashing fixed, we are now in production. One day the entire system goes down. MQSeries crashes, bringing several components down with it. We struggle with the problem for a while and finally trace it back to the MQSeries dead letter queue (an implementation of the Dead Letter Channel ). The queue grows so large that it brings down the entire server. After exploring the messages in the dead letter queue we find they are all expired market data messages. This is caused by “slow consumers, ” or consumers that do not process messages fast enough. While messages are waiting to be processed, they time out (see the Message Expiration pattern) and are sent to the Dead Letter Channel . The excessive number of expired market data messages in the dead letter queue is a clear indication that the message flow is too great – messages expire before the target application can consume them. We need to fix the message flow and we turn to patterns for help slowing down the message flow.
A reasonable first step is to explore solving this problem with the Aggregator as we recently used this pattern to solve the similar flashing market data control rate problem. The system design relies on the client application to immediately forward market data update messages to the trading venues. This means the system cannot wait to collect messages and aggregate them. So the Aggregator must be abandoned.
There are two other patterns that deal with the problem of consuming messages concurrently: Competing Consumers and Message Dispatcher . Starting with Competing Consumers , the benefit of this pattern is the parallel processing of incoming messages. This is accomplished using several consumers on the same channel. Only one consumer processes each incoming message leaving the others to process successive messages. Competing Consumers , however, will not work for us since we are using Publish-Subscribe Channel s in server-to-client communication. Competing Consumers on a Publish-Subscribe Channel channel means that all consumers process the same incoming message. This results in more work without any gain and completely misses the goal of the pattern. This approach also has to be abandoned.
On the other hand, the Message Dispatcher describes an approach whereby you add several consumers to a вЂ˜pool’. Each consumer can run its own execution thread. One main Message Consumer listens to the Channel and delegates the message on to an unoccupied Message Consumer in the pool and immediately returns to listening on the Message Channel . This achieves the parallel processing benefit of Competing Consumers , but works on Publish-Subscribe Channel s.
The Message Dispatcher in context.
Implementing this in our system is simple. We create a single JMSListener called the Dispatcher, which contains a collection of other JMSListener s called Performers. When the onMessage method of the Dispatcher is called, it in turn picks a Performer out of the collection to actually process the message. The result of which is a Message Listener (the Dispatcher) that always returns immediately. This guarantees a steady flow of message processing regardless of the message flow rate. Additionally, this works equally well on a Publish-Subscribe Channel s as it does on a Point-to-Point Channel s. With this infrastructure, messages can be received by the client application at almost any rate. If the client application is still slow to process the message after receiving them, the client application can deal with the delayed processing and potentially outdated market data rather than the messages expiring in the JMS Message Channel .
The crash discussed in this section and the fix using the Message Dispatcher is an excellent example of the limits of applying patterns. We encountered a performance problem based on a design flaw not allowing the client to process messages in parallel. This greatly improved the problem, but did not completely fix it. This is because the real problem was the client becoming a bottleneck. This couldn’t be fixed with a thousand patterns. We later addressed this problem by refactoring the message flow architecture to route messages directly from the Pricing Gateway to the Contribution Gateway. So patterns can help design and maintain a system, but don’t necessarily make up for poor upfront design.
Throughout this chapter, we have applied patterns to several different aspects of a bond trading system including solving initial upfront design problems and fixing a nearly job threatening production crash with patterns. We also saw these patterns as they already exist in third party product, legacy components, and our JMS and TIBCO messaging systems. Most importantly, these are real problems with the same types of architectural, technical and business problems we experience as we design and maintain our own systems. Hopefully reading about applying patterns to this system helps give you a better understanding of the patterns as well as how to apply them to your own systems.
Gregor Hohpe and Bobby Woolf.
From Enterprise Integration to Enterprise Transformation:
My new book describes how architects can play a critical role in IT transformation by applying their technical, communication, and organizational skills with 37 episodes from large-scale enterprise IT.

Sistemas de negociação de títulos.
Como os sistemas de negociação de títulos funcionam.
Primer do negócio de troca de obrigações.
O comércio de títulos usando sistemas eletrônicos é chamado de comércio eletrônico. Isso requer uma quantidade considerável de infra-estrutura de tecnologia da informação. Antes de explorar a tecnologia da informação, precisamos entender os fundamentos do negócio de negociação de títulos. Este artigo descreve os processos de negociação de títulos. Este é um tópico muito amplo e profundo; Neste artigo, vamos apenas dar uma olhada na superfície e obter entendimento suficiente para prosseguir com a exploração da tecnologia da informação nos próximos artigos.
O negócio de títulos.
O negócio de títulos tem muitas atividades, para simplificar, elas podem ser agrupadas em um dos quatro grupos de operações principais. Todas essas operações são suportadas pela tecnologia da informação e cada grupo está focado em um aspecto específico da negociação de títulos.
Básico básico do ciclo de vida.
Um título é um meio para uma organização legal levantar capital emitindo dívida. As organizações legais são governos, corporações, organizações supranacionais e outras. A dívida é comprada por investidores que se tornaram detentores de títulos. Os detentores de títulos recebem pagamentos de juros do emissor de obrigações em períodos definidos por um cronograma. O vínculo tem um prazo definido (o prazo de vencimento) e no final do prazo, o valor original de cada ação é devolvido ao detentor do vínculo. O valor original também é chamado de valor nominal.
O diagrama abaixo ajuda a ilustrar isso.
Os pagamentos de juros feitos em um título são chamados de pagamento de cupom. Este termo é histórico para quando um certificado de títulos realmente tinha cupons destacáveis ​​que deveriam ser apresentados ao emissor do título para receber o pagamento de juros.
Padrão.
Existe o risco de que o emissor do título não seja capaz de pagar alguns ou todos os pagamentos de juros ou o valor de face no vencimento para os compradores de títulos. Isso é chamado de risco de crédito. Se o emissor do título não cumprir o cronograma de títulos, o emissor do título não assumirá o compromisso.
Se o emissor de obrigações for inadimplente e estiver em garantia (ou seja, declarado falido), os detentores de obrigações podem receber uma porcentagem do valor nominal se a obrigação for classificada como dívida sénior. Se é uma dívida subordinada, então qualquer pagamento só acontece depois que a dívida sénior foi liquidada.
Mercado Primário.
Obrigações são emitidas no mercado primário; é aí que o emissor dos títulos recebe o capital dos compradores de títulos em troca da propriedade dos títulos. Um comprador de um título pode manter o título até o vencimento e receber o valor de face no vencimento mais os pagamentos de juros durante sua vida útil.
Secondary Market.
Um detentor de títulos pode optar por mudar o vínculo e para outro investimento financeiro. Isso é facilmente feito através da negociação do vínculo no mercado secundário. Os mercados secundários são onde os títulos são comprados e vendidos como commodities.
Em geral, o termo “negociação de títulos” refere-se à negociação no mercado secundário. O diagrama abaixo resume o comércio de títulos durante as fases do mercado e a duração de um título.
O Mercado de Obrigações Secundárias.
Um mercado tem clientes e comerciantes, os clientes vão ao mercado para obter bens por dinheiro enquanto os comerciantes vão ao mercado para vender bens com fins lucrativos. A este respeito, o mercado secundário não é diferente. Os bancos de investimento são os comerciantes e as empresas de investimento que gerenciam as pensões ou os fundos de gestão de patrimônio são os clientes. Esta é uma generalização dos participantes do mercado, mas é bom para o que precisamos para prosseguir. Nos mercados secundários, os termos sell-side, market-maker, comerciante ou revendedor identificam comerciantes. Os clientes são identificados pelos termos buy-side, tomador de mercado, cliente ou cliente. Nestes artigos, usaremos os termos revendedor / comerciante e cliente.
Os preços são expressos como uma porcentagem do par. Par é outro termo para o valor de face. Portanto, um preço de 100,00 é 100,00% do valor nominal do título. O diagrama abaixo mostra exemplos de situações para clientes que compram e vendem com revendedores. O revendedor define os preços que os clientes podem negociar. Em geral, o revendedor vai comprar baixo e vender alto. Nos exemplos, o comerciante está disposto a comprar a 99,5 e vender a 100,5. Isso significa essencialmente que, se o valor nominal da bonificação for de US $ 100, o revendedor está disposto a comprar em US $ 99,50 e vender em US $ 100,50. O preço que um negociante compra é o preço da oferta e o preço que o negociante vende é o preço de venda. O preço do pedido também é conhecido como o preço da oferta.
A diferença entre o preço de compra e venda é chamada de spread de compra e venda (também spread de oferta e oferta). Os spreads mais amplos são melhores para os revendedores, os spreads mais restritos são melhores para o cliente, mas o preço da oferta é sempre menor que o preço do pedido. Os negociantes sempre querem spreads mais amplos, enquanto os clientes sempre desejarão spreads mais restritos.
Geralmente, os negociantes não estão interessados ​​em manter títulos até o vencimento, eles estão interessados ​​em obter lucro de comprar em baixa e vender alto. Os clientes, em contraste, estão interessados ​​em manter um título até o vencimento ou, pelo menos, com o objetivo de receber os pagamentos de juros de um título e, tipicamente, reinvesti-los.
Avaliando um vínculo no mercado secundário.
Quanto vale um título pode ser calculado como seu valor nominal mais o restante dos pagamentos do cupom, descontados em relação ao tempo até o vencimento do título. Isso também é chamado de rendimento até o vencimento e representa o rendimento que você obteria se mantivesse o título até que ele amadurecesse.
No entanto, o rendimento até o vencimento não leva em conta o risco de crédito do emissor do título (ou seja, a probabilidade de inadimplência). Também não tem fator no risco devido a mudanças na taxa de juros; Em geral, à medida que as taxas de juros aumentam, os preços dos títulos caem e vice-versa. Em suma, o rendimento até o vencimento geralmente não é utilizado para o cálculo de preços no mercado secundário.
Na prática, há uma gama de técnicas usadas para precificar títulos no mercado secundário. Não vamos discutir essas técnicas, pois elas não são apropriadas neste nível de introdução. No entanto, existe um conceito fundamental que é comum a todas as técnicas de precificação; precificando um vínculo de outro. O diagrama abaixo ajuda a ilustrar isso. Isso mostra um exemplo típico em que os preços das obrigações corporativas são impulsionados por mudanças em um título de referência. Geralmente, o vínculo de referência é um vínculo governamental.
Normalmente, o preço dos títulos corporativos tem um spread fixo a partir do benchmark. À medida que o preço de referência muda, o mesmo acontece com o preço dos títulos corporativos. Técnicas de preços mais avançadas podem usar preços misturados ou rendimentos de benchmarks múltiplos para chegar ao preço da obrigação. Por enquanto, é suficiente que tenhamos uma apreciação de que os preços dos títulos podem impulsionar os preços dos outros títulos. Este é um conceito importante no preço das obrigações para negociação. Relacionamentos de preços como esse são a base para a maioria dos sistemas de precificação de títulos.
Liquidez do mercado secundário.
Os governos emitem obrigações para financiar a dívida pública. Para garantir que o valor dos títulos se sustente e que a dívida não seja vista como lixo, os governos colocam as obrigações de que os agentes mantenham os preços dos títulos líquidos no mercado secundário, cotando continuamente os preços de duas vias. Um preço de 2 vias é outro termo para preços de compra e venda. Isso coloca uma grande responsabilidade e risco financeiro possível aos revendedores para garantir que seus preços de títulos do governo sejam precisos para o mercado. Estes preços tornam-se muito sensíveis às mudanças nas taxas de juros e vice-versa. Essas obrigações asseguram que os preços dos títulos do governo sejam sempre líquidos, o que mantém a negociação de títulos secundários viável e estável. O benefício para os revendedores que assumem essas obrigações é que eles são capazes de participar dos leilões de dívida pública do mercado primário. A participação nesses leilões traz benefícios financeiros e de reputação para os revendedores.
Importância dos preços líquidos dos títulos do governo.
Em geral, os títulos são classificados como dívida pública ou corporativa. Os títulos do governo são emitidos pelos governos e têm um risco menor de inadimplência porque, em geral, os governos não vão à falência. Devido ao menor risco, eles também têm um pagamento de cupom menor. Isso segue o conceito de menor risco, menor recompensa.
Os títulos corporativos, em contraste, têm maior risco de inadimplência. Como tal, seus cupons são maiores do que um título governamental equivalente. O preço dos títulos corporativos é geralmente feito pelo preço dos títulos do governo. Uma única dívida pública pode estar dirigindo preços de títulos corporativos múltiplos. Como os preços dos títulos do governo mudam, há um efeito cascata sobre o preço dos títulos corporativos. Ao precificar os títulos corporativos sobre os preços líquidos do governo, os próprios títulos corporativos têm uma liquidez inerente.
A liquidez dos preços da dívida pública também é um fator importante para o crescimento econômico. A liquidez é um sinal de confiança no governo e sua estabilidade financeira.
Lucro que faz no mercado secundário.
Embora um revendedor possa lucrar com a compra baixa e alta, isso geralmente não está disponível para o cliente, pois os preços de compra e venda são definidos pelos revendedores. Algumas instituições comerciais tentam arbitrar os preços dos revendedores, mas isso é tipicamente muito difícil e requer investimento intensivo em tecnologia da informação, com retorno sobre o investimento um pouco inquantificável.
Estilos de Negociação de Obrigações.
Existem dois estilos de negociação no mercado secundário. Um revendedor que negocia com um cliente é chamado de negociante para cliente (D2C) ou comercial de empresa a cliente (B2C). Esta forma de negociação geralmente surge em títulos negociados a preços que são adaptados pelo revendedor para o cliente e ambos os lados concordam com o preço antes do acordo ser firmado.
Um revendedor também pode negociar diretamente com outros revendedores. Isso é referido como negociação de revendedor / revendedor (D2D), business-to-business (B2B) ou inter-dealer-broker (BID). Esta forma de negociação é de alta velocidade e implacável sem interação humana para concordar com os preços do comércio. Os preços cotados por um revendedor podem ser imediatamente negociados (ou agredidos) por qualquer outro revendedor. Por esta razão, a citação D2D deve ser mantida em progresso com os concorrentes; preços lentos podem significar que um distribuidor negocie fora do mercado e faça uma perda.
Normalmente, os mercados eletrônicos são divididos em categorias D2D ou D2C. Um revendedor exige diferentes projetos de sistemas para lidar com os dois paradigmas de negociação; O comércio D2C é mais sobre saber o cliente para fornecer preços precisos para o cliente. Negociação D2D é sobre o poder bruto do sistema de negociação do negociante.
Para referência, as obrigações de cotação do governo estão apenas nos mercados do D2D.
A negociação de títulos eletrônicos permite que clientes e revendedores negociem. No entanto, os dois lados precisam ser reunidos. É aqui que entram os vendedores; eles fazem o trabalho de fazer com que o cliente negocie com o revendedor. Embora grande parte do fluxo de trabalho de negociação seja realizado eletronicamente, ainda existem certos elementos que dependem de dinâmicas humanas simples. Colocando os clientes na loja & # 8220; & # 8221; é um desses.
O pessoal de vendas recebe comissão em uma base por comércio para os clientes que representam que executam negociações com o revendedor.
Mercados eletrônicos.
A negociação de títulos eletrônicos é hospedada por provedores de mercado eletrônico, chamados de Redes de Comunicação Eletrônica (ECNs). Estes também são denominados trocas. Existem ECNs que se especializam em negócios D2D ou D2C. Concessionários e clientes se conectam diretamente às ECNs e executam atividades de negociação via ECN. Os revendedores geralmente se conectam a um ECN por meio de uma API. A API permite que o revendedor receba dados de mercado disponíveis no ECN, envie pedidos (mercados D2D) ou responda às negociações do cliente (mercados D2C). Os clientes normalmente usam um aplicativo de software fornecido pelo ECN para visualizar os preços atuais no ECN e iniciar negociações. Em geral, as ECNs recebem uma pequena comissão por negociação executada. Um revendedor geralmente se conecta a múltiplas ECNs para ter a maior presença comercial eletrônica possível. Este é o senso comum, pois os locais mais acessados ​​por um revendedor aumentam as chances de negociação.
Estas são algumas das ECNs que existem hoje. Não é abrangente.
Assentamento.
As ECNs são aquelas em que as negociações são acordadas, mas a entrega real de dinheiro para títulos ou liquidação ocorre em câmaras de compensação. A liquidação ocorre nos intervalos de tempo padrão após a execução do comércio. O intervalo de tempo é uma convenção para a ligação, e. Os títulos do governo do euro se estabelecem numa base T + 2 (ou seja, 2 dias após a concordância do comércio). Alguns títulos se contentam com dinheiro, o que significa que eles negociam e se estabelecem no mesmo dia (T + 0).
As câmaras de compensação assumem o risco de contraparte de um negócio. Essencialmente, cada conterparty no comércio (o comprador e o vendedor) se instala com a câmara de compensação e não diretamente entre si. Caso um dos lados não pague ou entregue, a câmara de compensação garante que o outro lado do negócio receba o que é devido. Isso protege cada contraparte da inadimplência durante a liquidação comercial. A câmara de compensação se protege ao exigir pagamentos colaterais de cada contraparte para que haja alguma cobertura de quaisquer dívidas que possam surgir.
Ao fechar & # 8230;
Neste artigo, os processos e conceitos fundamentais usados ​​no negócio de negociação de títulos foram descritos. Com esse entendimento básico, a tecnologia da informação pode ser explorada e fará sentido o processo de negócios que cada parte da tecnologia de comércio eletrônico suporta.

Sistemas de negociação de títulos.
Como os sistemas de negociação de títulos funcionam.
Primer E-Trading.
A negociação eletrônica é essencialmente uma coleção de sistemas de tecnologia que compartilham informações sobre negociação de títulos. Precisamos entender essas informações para poder projetar os sistemas de tecnologia para suportá-las.
A informação pode ser dividida em 7 domínios funcionais. Cada domínio se concentra em um tipo específico de função e informações relevantes para o comércio eletrônico. As informações em todos os domínios são necessárias para negociação eletrônica. O diagrama abaixo mostra os 7 domínios das informações de comércio eletrônico.
Essa separação lógica das informações também define limites de responsabilidade funcional para a tecnologia da informação e fornece um guia de como uma organização pode alinhar o gerenciamento da tecnologia da informação; tipicamente equipes são formadas para suportar cada domínio (às vezes vários domínios).
Os dados e funções de um domínio são fornecidos por um ou mais sistemas que existem dentro do domínio. Os sistemas em si são geralmente uma composição de um ou mais serviços. Portanto, no nível mais baixo, o comércio eletrônico é uma grande coleção de serviços que podem ser agrupados como sistemas alinhados a um dos domínios funcionais. The diagram below helps to represent this statement.
Por simplicidade, suponha que cada domínio tenha apenas um sistema e que cada sistema seja composto por alguns serviços. Na prática, no entanto, pode haver vários sistemas em um domínio, por exemplo, o domínio de preços pode ter um sistema de preços diferente para títulos do governo e títulos corporativos. Embora cada revendedor tenha projetos de sistemas diferentes, os 7 domínios existirão em cada ambiente de revendedor.
Os domínios funcionais.
Os domínios funcionais separam informações de comércio eletrônico em grupos lógicos. Isso significa que cada domínio possui um conjunto de dados de informações distinto. Os conjuntos de dados podem ser generalizados conforme descrito na tabela abaixo. It may be helpful to refer to the terminology for definitions of any terms used in this table and further on in this article.
Essencialmente, isso resume todos os tipos de dados existentes no comércio eletrônico. Diferentes sistemas de revendedores podem ter refinamentos variados para os tipos de dados dentro de cada domínio, mas fundamentalmente os dados que fluem entre seus sistemas podem ser categorizados em um desses tipos de dados de domínio.
Relacionamentos de dados entre domínios.
Os sistemas dentro de cada domínio funcional precisam de dados dos outros domínios para funcionar corretamente. O diagrama abaixo mostra os relacionamentos lógicos de dados entre os domínios. Esta é uma visão simplificada, mas, em geral, os fluxos mostrados aqui são universais para todos os sistemas de comércio eletrônico.
Dados de referência e dados de mercado são fundamentais para todos os domínios. Os dados de referência fornecem os dados analíticos para precificação de um título, traduzindo entre os esquemas de identificação de títulos, bem como os dados de informações das contrapartes para a reserva. Os dados de mercado fornecem preços externos que são usados ​​como um mecanismo de comparação e controle para preços principais, cotações e pedidos.
Os sistemas de precificação precisam dos dados de referência de um título para calcular os dados do preço do título principal. Cálculos de preços mais sofisticados podem levar os dados de mercado como entradas adicionais ao calcular os preços dos títulos principais.
Os sistemas de cotações utilizam os preços básicos dos títulos e os utilizam como base para o cálculo de cotações para ECNs. As cotações são geralmente calculadas aplicando spreads bid-ask específicos da ECN nos preços dos títulos principais (ampliando os preços) e definindo uma quantidade para a qual a cotação é boa. Position data from the booking domain is used to assess the current position held in the bond and amend the quantities of the quote. A posição também pode ser usada para marcar o lado apropriado como axed. Os dados de mercado (melhores preços do mercado) são usados ​​citando os sistemas para fornecer limites para os preços de cotação ECN ou mesmo para substituir os preços de cotação ECN do negociante (isto é, usar o melhor preço de mercado como o próprio preço de cotação).
D2C negotiating systems handle the electronic negotiation work-flow between customers and the dealer. Quando um cliente inicia uma negociação, o revendedor precisa fornecer um preço para a quantidade do título que o cliente está propondo negociar. A cotação atual do título da ECN da negociação é geralmente o ponto de partida para o preço. Outros fatores são então considerados que irão alterar ainda mais o preço; a qualidade do cliente, a quantidade que o cliente está pedindo, os melhores preços atuais do mercado e a posição atual que o negociante detém no título são todos combinados em alguma função para alterar o preço de cotação de obrigação do sistema de cotação e enviá-lo para o cliente.
Os sistemas de negociação D2D são usados ​​para gerenciar cotações e ordens em ECNs do D2D. Em geral, esses sistemas usam algoritmos que ajustam constantemente os preços e as quantidades, comparando as cotações do sistema de cotações e os preços de dados de mercado. As informações de posição dos sistemas de domínio de reservas são usadas para controlar cotações e quantidades de pedidos. Os sistemas de negociação do D2D são os sistemas de negociação de alta frequência que realizam o comércio de algoritmos. Eles precisam ser altamente eficientes e operar nas latências mais baixas possíveis para garantir que os preços dos pedidos sejam mantidos atualizados com as mudanças nas condições do mercado.
Os serviços nos domínios.
Anteriormente no artigo, um domínio foi descrito como tendo um ou mais sistemas e cada sistema tem um ou mais serviços. São os serviços responsáveis ​​pela produção dos dados de um domínio. Em geral, há um serviço para cada tipo de dados, estes são os serviços de negócios. O diagrama abaixo ilustra os principais serviços comerciais que devem existir em cada domínio para produzir os dados que foram definidos nas seções anteriores. Esse diagrama se expande no diagrama anterior e também inclui os relacionamentos de dados entre os domínios. Isso não abrange serviços de infraestrutura (por exemplo, bancos de dados, serviços de conexão ECN, serviços de mensagens e outros), somente serviços relacionados a negócios.
Dependendo do design dos sistemas do revendedor, todos os serviços em um domínio podem pertencer a um sistema ou sistemas separados. No entanto, o que é constante é que as funções de cada serviço mostrado aqui serão atendidas por algum sistema no domínio. A função de cada serviço é descrita na tabela abaixo.
Ambientes
Tendo aprendido sobre todos os serviços que precisam existir, podemos agora discutir o conceito de ambientes de comércio eletrônico. Um ambiente de comércio eletrônico é uma coleção de serviços. A implantação de duplicatas dos mesmos serviços cria um segundo ambiente de comércio eletrônico. A maioria das instituições de negociação de títulos possui vários ambientes em execução paralelamente para diferentes usos. A tabela abaixo descreve os ambientes comuns que são implantados.
O conjunto de ambientes não se limita a esses, por exemplo, algumas organizações terão vários ambientes de teste. Ter diferentes ambientes é essencial para o bom funcionamento do comércio eletrônico de títulos. Sem isso, o ambiente de comércio eletrônico de títulos de produção estagnaria devido à falta de mudanças ou seria extremamente instável à medida que novas funcionalidades fossem testadas - na versão selvagem & # 8217; em vez de nas condições controladas de um ambiente de desenvolvimento e teste.
Environment cross-over.
Environment cross-over is a concept describing when systems from one environment are connected to those of a different one. Normalmente, isso ocorre quando alguns serviços não existem no ambiente e, para compensar isso, os serviços de outros ambientes são usados. Um exemplo clássico é o comércio da ECN; As ECNs, em geral, não possuem ambientes de desenvolvimento, apenas ambientes de teste e produção, portanto, o ambiente de desenvolvimento de um revendedor geralmente cruza o ambiente de teste ECN. O diagrama abaixo ilustra o cross-over do ambiente.
Para resiliência, geralmente há cross-over entre a produção ao vivo e ambientes de backup do revendedor e ECN. No entanto, apenas um ambiente está ativo em qualquer ponto no site.
Um ambiente é implantado em um local geográfico. Um revendedor que comercializa globalmente geralmente requer um ambiente de produção localizado em várias regiões geográficas. Para cada região que existe um ambiente de produção, há também um requisito para ambientes de backup, teste e desenvolvimento. Portanto, se um revendedor tiver 3 regiões de comércio global, o revendedor terá um total de 3 x 4 = 12 implantações dos serviços de e-trading. Portanto, o número de implantações necessárias é uma função dos ambientes e dos locais de negociação necessários. Gerenciar vários ambientes em vários locais pode se tornar muito demorado e complicado. Se a tecnologia de implantação não for fácil de trabalhar, o simples conceito de adicionar um novo serviço a um ambiente pode se tornar um processo tedioso, já que é necessário adicioná-lo a todos os ambientes em todos os locais.
Ao fechar & # 8230;
Este artigo apresentou conceitos que são universais para todos os ambientes de comércio eletrônico. Compreender isso é fundamental para qualquer profissional de tecnologia da informação ou analista de negócios que trabalhe com comércio eletrônico. This information forms part of the foundation that is needed to start investigating the services and infrastructure in more depth in the next articles.

Sistemas de Negociação: Projetando Seu Sistema - Parte 1.
A seção anterior deste tutorial analisou os elementos que compõem um sistema de negociação e discutiu as vantagens e desvantagens de usar um sistema desse tipo em um ambiente de negociação ao vivo. Nesta seção, construímos esse conhecimento examinando quais mercados são especialmente adequados para o sistema de negociação. Vamos, então, dar uma olhada mais profunda nos diferentes gêneros de sistemas de negociação.
O mercado acionário é provavelmente o mercado mais comum para o comércio, especialmente entre os novatos. Nessa arena, grandes jogadores como Warren Buffett e Merrill Lynch dominam, e as estratégias tradicionais de investimento em valor e crescimento são, de longe, as mais comuns. No entanto, muitas instituições investiram significativamente na concepção, desenvolvimento e implementação de sistemas de negociação. Investidores individuais estão aderindo a essa tendência, embora lentamente.
A grande quantidade de ações disponíveis permite que os investidores testem sistemas em muitos tipos diferentes de ações - tudo, desde ações de balcão extremamente voláteis (OTC) a blue chips não voláteis.
A eficácia dos sistemas de negociação pode ser limitada pela baixa liquidez de algumas ações, especialmente as questões de balcão e folha-de-rosa.
As comissões podem consumir lucros gerados por negócios bem-sucedidos e podem aumentar as perdas. OTC e ações de folha-de-rosa freqüentemente incorrem em comissões adicionais.
Os principais sistemas de negociação utilizados são aqueles que buscam valor - ou seja, sistemas que usam parâmetros diferentes para determinar se um título está subvalorizado em comparação com seu desempenho passado, seus pares ou o mercado em geral.
O mercado de câmbio, ou forex, é o maior e mais líquido mercado do mundo. Os governos, bancos e outras grandes instituições do mundo negociam trilhões de dólares no mercado forex todos os dias. A maioria dos traders institucionais no forex depende de sistemas de negociação. O mesmo vale para os indivíduos no forex, mas alguns negócios são baseados em relatórios econômicos ou pagamentos de juros.
A liquidez neste mercado - devido ao enorme volume - torna os sistemas de negociação mais precisos e eficazes.
Não há comissões neste mercado, apenas se espalha. Portanto, é muito mais fácil fazer muitas transações sem aumentar os custos.
Em comparação com a quantidade de ações ou mercadorias disponíveis, o número de moedas a negociar é limitado. Mas por causa da disponibilidade de "pares de moedas exóticas" - isto é, moedas de países menores - o intervalo em termos de volatilidade não é necessariamente limitado.
Os principais sistemas de negociação utilizados no forex são aqueles que seguem as tendências (um ditado popular no mercado é "a tendência é seu amigo"), ou sistemas que compram ou vendem em breakouts. Isso ocorre porque os indicadores econômicos geralmente causam grandes movimentos de preços de uma só vez.
Os mercados de ações, forex e commodities oferecem negociação de futuros. Este é um veículo popular para o sistema de negociação por causa da maior quantidade de alavancagem disponível e da maior liquidez e volatilidade. No entanto, esses fatores podem cortar os dois lados: eles podem amplificar seus ganhos ou amplificar suas perdas. Por esta razão, o uso de futuros é geralmente reservado para os operadores avançados de sistemas individuais e institucionais. Isso ocorre porque os sistemas de negociação capazes de capitalizar no mercado futuro exigem uma customização muito maior, usam indicadores mais avançados e demoram muito mais para serem desenvolvidos.
Cabe ao investidor individual decidir qual mercado é mais adequado ao sistema de negociação - cada um tem suas próprias vantagens e desvantagens. A maioria das pessoas está mais familiarizada com os mercados de ações e essa familiaridade facilita o desenvolvimento de um sistema de negociação. No entanto, o forex é comumente pensado para ser a plataforma superior para executar sistemas de negociação - especialmente entre os comerciantes mais experientes. Além disso, se um comerciante decidir capitalizar o aumento da alavancagem e volatilidade, a alternativa de futuros estará sempre aberta. Em última análise, a escolha está nas mãos do desenvolvedor do sistema.
O método mais comum de negociação do sistema é o sistema de acompanhamento de tendências. Em sua forma mais fundamental, esse sistema simplesmente espera por um movimento significativo de preços, depois compra ou vende nessa direção. Este tipo de sistema espera que esses movimentos de preços mantenham a tendência.
Média móvel de sistemas.
Frequentemente usado em análise técnica, uma média móvel é um indicador que simplesmente mostra o preço médio de um estoque durante um período de tempo. A essência das tendências é derivada dessa medida. A maneira mais comum de determinar a entrada e a saída é um cruzamento. A lógica por trás disso é simples: uma nova tendência é estabelecida quando o preço cai acima ou abaixo de sua média histórica de preço (tendência). Aqui está um gráfico que representa tanto o preço (linha azul) quanto o MA de 20 dias (linha vermelha) da IBM:
O conceito fundamental por trás desse tipo de sistema é semelhante ao de um sistema de média móvel. A ideia é que, quando uma nova alta ou baixa é estabelecida, é mais provável que o movimento do preço continue na direção da fuga. Um indicador que pode ser usado na determinação de fugas é um simples Bollinger Band & reg; sobreposição. Bollinger Bands & reg; mostra médias de preços altos e baixos, e breakouts ocorrem quando o preço atinge as margens das bandas. Aqui está um gráfico que traça o preço (linha azul) e Bollinger Bands & reg; (linhas cinza) da Microsoft:
Desvantagens dos sistemas de acompanhamento de tendências:
Tomada de Decisão Empírica - Ao determinar as tendências, há sempre um elemento empírico a considerar: a duração da tendência histórica. Por exemplo, a média móvel poderia ser nos últimos 20 dias ou nos últimos cinco anos, portanto, o desenvolvedor deve determinar qual é a melhor para o sistema. Outros fatores a serem determinados são os altos e baixos médios em sistemas de fuga.
Natureza atrasada - As médias móveis e os sistemas de fuga estarão sempre atrasados. Em outras palavras, eles nunca podem atingir a parte superior ou inferior de uma tendência. Isso inevitavelmente resulta em uma perda de lucros potenciais, que às vezes podem ser significativos.
Wipsaw Effect - Entre as forças do mercado que são prejudiciais ao sucesso dos sistemas de acompanhamento de tendências, este é um dos mais comuns. O efeito whipsaw ocorre quando a média móvel gera um sinal falso - ou seja, quando a média cai apenas no intervalo, então, de repente, inverte a direção. Isso pode levar a perdas massivas, a menos que técnicas eficazes de interrupção de perdas e gerenciamento de risco sejam empregadas.
Mercados Sideways - Sistemas de acompanhamento de tendências são, por natureza, capazes de ganhar dinheiro apenas em mercados que realmente fazem tendência. No entanto, os mercados também se movem para os lados, permanecendo dentro de um determinado intervalo por um longo período de tempo.
Pode ocorrer extrema volatilidade - Ocasionalmente, os sistemas de acompanhamento de tendências podem experimentar extrema volatilidade, mas o profissional deve manter seu sistema. A incapacidade de fazer isso resultará em falha garantida.
Basicamente, o objetivo do sistema de tendência de contração é comprar na baixa mais baixa e vender na máxima alta. A principal diferença entre este e o sistema de acompanhamento de tendência é que o sistema de tendência contrária não é autocorretivo. Em outras palavras, não há tempo definido para sair de posições, e isso resulta em um potencial de queda ilimitado.
Tipos de sistemas de tendência contrária.
Muitos tipos diferentes de sistemas são considerados sistemas de contra-tendência. A ideia aqui é comprar quando o momentum em uma direção começa a desaparecer. Isso é mais frequentemente calculado usando osciladores. Por exemplo, um sinal pode ser gerado quando os stochastics ou outros indicadores de força relativa caem abaixo de certos pontos. Existem outros tipos de sistemas de negociação de tendência de contração, mas todos eles compartilham o mesmo objetivo fundamental - comprar baixo e vender alto.
Tomada de Decisão Ética - Por exemplo, um dos fatores que o desenvolvedor do sistema deve decidir são os pontos nos quais os indicadores de força relativa desaparecem.
Volatilidade Extrema Pode Ocorrer - Esses sistemas também podem experimentar alguma volatilidade extrema, e a incapacidade de manter o sistema apesar dessa volatilidade resultará em falha garantida.
Downside Ilimitado - Como mencionado anteriormente, existe um potencial de downside ilimitado porque o sistema não é autocorretor (não há tempo definido para sair de posições).
Os principais mercados para os quais os sistemas de negociação são adequados são os mercados de ações, forex e futuros. Cada um desses mercados tem suas vantagens e desvantagens. Os dois principais gêneros de sistemas de negociação são os sistemas de acompanhamento de tendência e de contra-tendência. Apesar de suas diferenças, os dois tipos de sistemas, em seus estágios de desenvolvimento, exigem uma tomada de decisão empírica por parte do desenvolvedor. Além disso, esses sistemas estão sujeitos a extrema volatilidade e isso pode exigir alguma resistência - é essencial que o operador do sistema mantenha seu sistema durante esses períodos. Na próxima parte, daremos uma olhada mais de perto em como projetar um sistema de negociação e discutir alguns dos softwares que os operadores de sistema usam para facilitar suas vidas.

Obrigações de negociação: como são negociadas as obrigações?
Uma compreensão do mercado de títulos e da negociação de títulos é essencial para investimentos adequados. Como os títulos são negociados no mercado são confusos para a maioria das pessoas, mas são muito importantes para a economia e o nível de taxas de juros prevalecentes.
Importância das obrigações de negociação.
Os títulos de negociação ocorrem muitas vezes por dia e é uma parte importante dos mercados econômicos globais. O mercado de títulos é muito maior do que o mercado de ações e os bancos centrais realizam a política monetária nos mercados de títulos. Quando os compradores e vendedores estão negociando seus títulos, eles determinam os rendimentos dos vários tipos de títulos que estão negociando. Isso, por sua vez, define o preço do crédito na economia.
Joe e Suzy Q Público podem não entender a negociação de títulos, mas os rendimentos do rendimento do mercado de títulos estabelecem as taxas de juros sobre suas hipotecas, CPGs, empréstimos de carro e outros tipos de empréstimos ao consumidor.
As obrigações operam em qualquer lugar em que um comprador e vendedor podem chegar a um acordo. Ao contrário das ações negociadas publicamente, não existe um lugar central ou troca para negociação de títulos. O mercado de títulos é um & ldquo; over-the-counter & rdquo; market or OTC market, rather than on a formal exchange. Obrigações convertíveis, alguns futuros de obrigações e opções de obrigações são negociados em bolsas.
Obrigações de Negociação: Concessionários e Investidores.
Bond Dealers.
Enquanto os investidores podem negociar títulos negociáveis ​​entre si, a negociação geralmente é feita por meio de negociantes de títulos, ou mais especificamente, as mesas de negociação de títulos de grandes negociantes de investimentos.
Esses negociantes estão no centro de uma vasta rede de links de telefone e computador que conectam todos os jogadores interessados. Eles também têm comerciantes responsáveis ​​por saber tudo sobre um grupo de títulos e citando um preço para comprá-los ou vendê-los, ou & ldquo; fazer um mercado & rdquo; para títulos.
Os negociantes fornecem & ldquo; liquidez & rdquo; para os investidores de títulos, para que esses investidores possam comprar e vender títulos de forma mais fácil e com uma concessão limitada sobre o preço, mas os revendedores também podem comprar e vender entre si, diretamente ou anonimamente através de corretores de títulos.
Em todas as negociações de títulos, o objetivo é ter um spread entre o preço que os títulos são comprados e o preço em que são vendidos. Esse spread é como os negociadores de títulos fazem (ou perdem) dinheiro.
O comércio de títulos tornou-se muito lucrativo antes da crise de crédito, quando os negociantes de investimento usaram seu capital bancário para financiar enormes estoques de títulos e fazer negociação exclusiva. Isso não acabou muito, já que os preços dos títulos caíram durante a crise e os revendedores sofreram grandes perdas em seus estoques. Muitos bancos tiveram que ser resgatados pelos governos e é por isso que os reguladores bancários agora restringem severamente as atividades comerciais de propriedade.
Investidores de obrigações.
Os títulos de negociação também envolvem instituições financeiras, fundos de pensão, fundos mútuos e governos de todo o mundo.
Esses investidores de títulos, junto com os revendedores, compõem o mercado institucional & ldquo; & rdquo; where large blocks of bonds are traded. Um comércio envolvendo US $ 1 milhão de títulos seria considerado um pequeno ingresso no mercado institucional. Não existe um limite de tamanho neste mercado, onde podem ser realizados negócios de US $ 500 milhões ou US $ 1 bilhão por vez.
Também não há restrição de tamanho no mercado de varejo & ldquo; & rdquo; onde os investidores individuais compram e vendem títulos com as mesas de negociação de títulos dos negociantes de investimentos, mas o tamanho desses negócios geralmente é inferior a US $ 1 milhão.
Terminologia do mercado de títulos.
Aqui estão alguns dos conceitos-chave que um comerciante de títulos deve estar familiarizado para fazer seu trabalho:
A percentagem de juros a pagar numa caução no decurso de um ano. O interesse geralmente é pago semestralmente, embora também possa ser pago mensalmente, trimestralmente e anualmente.
The date the bond will be redeemed or paid off.
O preço cotado geralmente é baseado no vencimento do vínculo a um preço de par, ou 100,00.
O termo & ldquo; yield & rdquo; geralmente significa & ldquo; rendimento até a maturidade. & rdquo; O rendimento até o vencimento leva em consideração o pagamento do cupom e considera se o vínculo está em vencimento a um preço diferente ao preço atual.
O preço pelo qual o comerciante pagará uma caução.
O preço pelo qual o comerciante irá vender uma obrigação.
A diferença de preço entre o que o comerciante vai comprar uma obrigação e o preço pelo qual o comerciante irá vender uma obrigação. A diferença em títulos governamentais altamente liquidos e negociáveis ​​geralmente é de apenas alguns centavos.
Um ponto base é um centésimo de ponto percentual. Por exemplo, se um rendimento se move de 5,5% para 5%, moveu 50 pontos base.
Distribuídos pelos governos.
Os títulos do governo não-federal são muitas vezes cotados com base em um rendimento distribuído por um vínculo governamental comparável. Um vínculo corporativo com cupom e data de vencimento semelhantes poderia facilmente ser 100 pontos base maior em rendimento do que um título do governo federal. Os comerciantes costumam oferecer e oferecer em uma base de spread.
O que isso se refere são características especiais para títulos específicos. Por exemplo, um vínculo pode vir até 1 de junho de 2008, mas pode haver uma característica especial que permita ao emissor chamar & rdquo; o vínculo em uma data anterior, conhecida como data da chamada. Existem muitas outras características especiais.
Os governos federais da América do Norte mudaram-se para um sistema de leilões para vender seus títulos aos investidores. A maioria dos negociantes de títulos pode oferecer nos leilões e depois distribuir os títulos para os investidores.
A maioria dos outros governos e corporações usa um sistema diferente de distribuição de novas questões, nomeadamente oferecendo-os aos investidores através de negociantes de títulos. The bond dealers earn a commission for distributing the bonds to investors. A oferta pode ser baseada em preço fixo, ou com base em um spread de rendimento fixo para títulos do governo federal comparáveis.
Nos últimos anos, os títulos foram "lcd" baseados em livros, & rdquo; o que significa que os títulos são apresentados com um administrador central e não se mudam fisicamente a partir daí. Em vez disso, os negociantes e instituições têm contas estabelecidas com o administrador, e quando ocorre uma negociação de títulos, a conta do comprador é creditada com os títulos, enquanto a conta do vendedor é debitada. A maioria dos títulos governamentais e corporativos são baseados em livros e os investidores são desencorajados de ter a posse física dos títulos.
Por que as obrigações comerciais?
Um comerciante de títulos em um negociante de investimentos procura obter lucros em sua "business book & rdquo ;. Quanto mais dinheiro ele faz, maior será o seu bônus. É por isso que os comerciantes têm altos volumes de transações e ndash; porque quanto mais trocam, mais dinheiro ganharão.
Um comerciante de fundos de hedge negociará de forma semelhante a um negociante de investimento, mas usará mais & ldquo; alverage, & rdquo; ou emprestar dinheiro contra os títulos que o fundo possui. Hedge fund traders also make many trades to maximize their profits.
A & ldquo; Buy Side & rdquo; A corretora de títulos geralmente detém seus títulos por períodos mais longos, dada a natureza de longo prazo de seus portfólios. Insurance companies and pension funds have very long-term liabilities and need to always hold bonds.
Trading Bonds: Low Profile but Very Important.
A negociação de títulos é menor do que a negociação de ações, mas é mais importante. Bond dealers and bond investors alter their portfolios in light of changing market conditions to make a profit and/or maximize the return on their portfolios. O efeito global de toda essa atividade de mercado de títulos é o nível de taxas de juros em uma economia, que afeta quase todos os tipos de crédito e empréstimos.
Posts relacionados.
Acordo de obrigações / Emissão de obrigações: como é que vai?
Características do vínculo: o que são obrigações?
Junk Bonds: High-Yield Bonds, Credit Quality, and Risk.
Mais lidos
Três coisas as pessoas erradas sobre a economia de trickle-down.
O que é o Bitcoin?
A demanda do ETF do Canadá sobe após os fundos mútuos em 2017.
Como as taxas de juros afetam os títulos?
Nossos Patrocinadores.
Últimas postagens.
A demanda do ETF do Canadá sobe após os fundos mútuos em 2017.
O que é o Bitcoin?
Três coisas as pessoas erradas sobre a economia de trickle-down.
Royalties e Fideicomisso de renda.
by Uncle Pipeline.
Entendendo por que as taxas de juros mudam?
by Uncle Pipeline.
Quais são alguns dos riscos envolvidos?
Quais são alguns dos riscos envolvidos?
Derivativos & touro; Cobertura & bull; Obrigações e touro; Taxas de juros e bull; Dividendos
Inscreva-se para saber mais!
Fundada em 1996 por um grupo de gestores de carteiras, a The Financial Pipeline dedica-se a fornecer conhecimento financeiro e educação a todos e a qualquer pessoa que tenha interesse na área financeira. Todos os nossos artigos são selecionados e editados para precisão e imparcialidade. Nosso lema, "informação financeira para o resto de nós", & rdquo; fala por si.
Nosso objetivo é fornecer informações financeiras em todos os níveis para consumidores e investidores financeiros. Fizemos grandes esforços para garantir que nosso conteúdo seja facilmente acessível e acessível. Nós adaptamos nossos artigos a todos os níveis de conhecimento financeiro. Se você já viu e leu o suficiente sobre um assunto, passe para o próximo.
No Finpipe.
ENCONTRE-NOS AQUI.
Categorias.
&cópia de; Pipeline Financeiro de Copyright 2018. Todos os direitos reservados.

Sistemas de negociação.
Encontrar software de sistemas de negociação que atenda às suas necessidades é fácil com o bobsguide. De commodities e ações a sistemas de negociação de renda fixa, fornecemos as informações mais atualizadas e atualizadas do setor financeiro.
Sistemas Derivados.
O bobsguide torna fácil encontrar sistemas de comércio derivado. De kits de ferramentas para software de negociação de derivativos.
Veja produtos correspondentes.
Software relacionado a todos os aspectos de mercados financeiros, commodities, derivativos e câmbio para o.
Veja produtos correspondentes.
Commodities - Específicos de energia.
Produtos e serviços relacionados a todos os aspectos de commodities específicas de energia.
Veja produtos correspondentes.
Soluções de commodities.
Software e serviços para todos os aspectos do comércio de commodities, exceto energia.
Veja produtos correspondentes.
Redes de Negociação Eletrônica.
Software e serviços focados em conectar eletronicamente uma ou mais partes para o propósito.
Veja produtos correspondentes.
Sistemas de Ações.
Software e serviços focados na análise, negociação e execução de títulos patrimoniais.
Veja produtos correspondentes.
Trocas / ECNs.
Todas as bolsas e redes de comunicação eletrônica, incluindo: futuros, opções, commodities.
Veja produtos correspondentes.
Sistemas de Renda Fixa.
Sistemas de negociação que se concentram em alguns ou todos os títulos de renda fixa, incluindo corporativo, governo.
Veja produtos correspondentes.
Sistemas de Gestão de Liquidez.
O sistema de gestão de liquidez permite que as empresas gerenciem sua liquidez para a melhor execução, inteligente.
Veja produtos correspondentes.
Software e serviços focados em facilitar e gerenciar a execução de ordens de títulos.
Veja produtos correspondentes.
Portais de Negociação e Corretagem Online.
Serviços online que oferecem opções de negociação e corretagem para empresas e indivíduos.
Veja produtos correspondentes.
Componentes de Software para a Sala de Negociação.
Software versátil que permite aos usuários interagir em resposta a transações contratuais enquanto aderem.
Veja produtos correspondentes.
Sistemas para trocas.
Sistemas de intercâmbio financeiro e plataformas de negociação para fins de monitoramento e análise de valor.
Veja produtos correspondentes.
Informações relacionadas.
Como o Danske Bank usa terceiros para limpar dados para GDPR | Análise do Negócio.
19 de fevereiro de 2018.
8 fintechs disruptivos para aguardar em 2018.
12 de fevereiro de 2018.
O melhor software de gerenciamento de risco para 2018.
31 de janeiro de 2018.
O canivete suíço fintech se aproxima do Open Banking? | Análise do negócio.
30 de janeiro de 2018.
Anúncios relacionados da empresa.
A EQUI fortalece a diretoria com nova nomeação.
23 de fevereiro de 2018.
O IPC colabora com o GreenKey para trazer uma poderosa solução de reconhecimento de voz baseada em AI que converte voz em tempo real em dados utilizáveis ​​para os mercados financeiros.
23 de fevereiro de 2018.
Opções Oferece Nova Colocação Gerenciada Na Nasdaq Estocolmo.
23 de fevereiro de 2018.
Recursos relacionados
Whitepaper: a Trilha de auditoria consolidada.
07 de fevereiro de 2018.
O impacto da Fintech Disruptors em Corporate Banking.
06 de fevereiro de 2018.
Colher os benefícios da agilidade nos mercados de capitais.
14 de dezembro de 2017.
Eventos Relacionados.
Finovate Europe 2018.
06 de março de 2018.
A Trilha de Auditoria Consolidada (CAT): Tomando uma Abordagem Estratégica.
14 de março de 2018.
Conferência de Negociação EMEA 2018.
15 de março de 2018.
Empregos relacionados.
Desenvolvedor JavaScript - Interface de Usuário - Software de Negociação.
29 de janeiro de 2018.
Desenvolvedor Web.
18 de outubro de 2017.
Gestor de projeto.
18 de outubro de 2017.
Perguntas frequentes.
Procurando por um sistema de negociação?
No mundo digital acelerado de hoje, onde as velocidades de transação são medidas em milissegundos, as empresas exigem software de negociação que seja rápido, confiável e adaptado para atender às suas necessidades.
A negociação é um negócio competitivo e, ao encontrar o software de negociação correto, você pode obter uma vantagem. Na maioria dos casos, os sistemas de negociação simplificam e automatizam o processo de negociação, resultando em negociações rápidas e mais precisas e, muitas vezes, levando ao aumento da lucratividade.
O bobsguide apresenta uma coleção de opções de software de sistemas de negociação dos principais fornecedores de sistemas de negociação para ajudá-lo a escolher a melhor solução para sua empresa, variando de títulos de renda fixa a sistemas on-line de commodities e ações.
Que tipos de software de negociação online você tem?
Temos vários tipos de software de negociação disponíveis, cada um oferecendo funcionalidades especializadas. A melhor opção para uma empresa dependerá de seus requisitos específicos.
Separamos os sistemas de negociação disponíveis em diferentes categorias. Isso pode ajudá-lo a encontrar a opção mais adequada às suas necessidades:
Os sistemas de negociação para corretores geralmente estão relacionados aos mercados financeiro, de commodities, derivativos e câmbio. Eles são projetados para ajudar terceiros a fazer as melhores escolhas em seus clientes.
Os sistemas de comércio de commodities são projetados para uso em mercados onde produtos como alimentos, metais e energia são trocados, assim como qualquer outro material bruto ou primário.
As redes de comércio eletrônico são sistemas automatizados que compram e vendem pedidos a preços especificados. Eles geralmente são usados ​​por corretores, ajudando a estabelecer links para uma variedade de partes para negociações rápidas de segurança.
Os sistemas de ações são projetados para lidar com a compra e venda de ações da empresa. Dependendo do sistema, pode ser adequado para negociação nas principais bolsas de valores ou em mercados de balcão.
Em nossa seção de trocas / ECNs, você encontrará sistemas comerciais que funcionam em redes de comunicações eletrônicas. Estes incluem futuros, opções, commodities, finanças, ações e sistemas de negociação de valores mobiliários.
Os sistemas de renda fixa são projetados para trabalhar com investimentos que proporcionam um retorno regular. Estes podem incluir títulos corporativos, governamentais, hipotecários e garantidos por ativos em qualquer moeda.
Sistemas de gerenciamento de pedidos e sistemas de gerenciamento de execução - também conhecidos como sistemas de negociação OMS e EMS - facilitam e gerenciam títulos, geralmente através do protocolo FIX.
Portais de comércio e corretagem on-line fornecem soluções para empresas e indivíduos. Eles também são boas fontes de informações e relatórios de mercado.
Existem também vários componentes de software para a sala de negociação, que permitem aos usuários responder às transações contratuais e garantir que eles permaneçam dentro dos requisitos regulamentares.
Os sistemas de intercâmbio ajudarão no monitoramento e na análise das flutuações de valor de commodities, ações, títulos e derivativos.
Por que bobsguide?
Na bobsguide, reunimos uma vasta seleção de sistemas de comércio, que foram desenvolvidos por fornecedores de sistemas de negociação que são bem respeitados no setor. Cada sistema foi escolhido por sua capacidade de melhorar o fluxo diário de negócios no pregão, garantindo eficiência e confiabilidade sempre que possível.
Mas não estamos aqui apenas para ajudá-lo a adquirir software de sistema comercial. Também reunimos as últimas notícias e eventos de sistemas de comércio para mantê-lo atualizado com o setor, bem como várias oportunidades de carreira em torno da negociação de empregos para dar a você a oportunidade de promover sua própria posição no setor.
Para aproveitar ao máximo o que o bobsguide tem a oferecer, registre-se hoje. É grátis, rápido e simples e dá acesso aos nossos sistemas completos de cobrança, serviços, notícias e anúncios de eventos.
Insight entregue diariamente na sua caixa de entrada.
Nosso boletim informativo líder de mercado é uma fonte inestimável de notícias, insights e análises da indústria de tecnologia financeira.
19 de fevereiro de 2018.
12 de fevereiro de 2018.
12 de janeiro de 2001.
15 de fevereiro de 2018.
21 de fevereiro de 2018.
Conectando compradores e vendedores de tecnologia financeira globalmente.
Parte do Contentive Group Ltd.
Conectando compradores e vendedores de tecnologia financeira globalmente.
Parte do Contentive Group Ltd.
Conectando compradores e vendedores de tecnologia financeira globalmente.
Parte do Contentive Group Ltd.
Anúncios da empresa.
Diretório.
Eventos.
O bobsguide conecta compradores e vendedores de tecnologia financeira globalmente.
A bobsguide atrai mais de 70.000 compradores e vendedores de fintech todos os meses. Eles vêm até nós para obter as informações mais recentes de nossa plataforma, para buscar os melhores fornecedores por meio de nosso diretório de produtos de fintech, para encontrar novas funções de trabalho ou descobrir talentos digitais para seus negócios por meio de nossas listas de empregos, aprender sobre os principais eventos ao vivo e digitais e para baixar recursos úteis, como white papers e estudos de caso.