BRPI0618751A2 - sistema e método para requisição direta de cotação - Google Patents

Abstract

SISTEMA E MéTODO PARA REQUISIçãO DIRETA DE COTAçãO. A presente invenção refere-se aos sistemas e métodos descritos que se referem a permitir uma negociação de contratos de câmbio ("FX") de balcão ("OTC") em um mecanismo de equilíbrio e compensação centralizado. Os sistemas e métodos descritas permitem transações anónimas, compensação centralizada, liquidação eficiente e a provisão de mecanismos de gerenciamento de risco/seleção de crédito para diminuição de risco, redução de custo de transação e melhoria da liquidez no mercado de FX. Em particular, as modalidades descritas aumentam a velocidade de execução facilitando o crescimento de demanda para negociação algorítmica, aumento de transparência de preço, diminuição de custo de negociação, negociação de consumidor com consumidor, e alocações de ativo automatizadas, negócios recorrentes, bem como eficiências de compensação e liquidação.

Description

Relatório Descritivo da Patente de Invenção para "SISTEMA E MÉTODO PARA REQUISIÇÃO DIRETA DE COTAÇÃO".

REFERÊNCIA A PEDIDOS RELACIONADOS

Este pedido reivindica o benefício segundo o 35 U.S.C. § 119(e) do Pedido Provisório U.S. N9 de Série 60/738.246, depositado em 18 de no- vembro de 2005, o qual é desse modo incorporado como referência. Nota de Direitos Autorais

Uma porção da descrição deste documento de patente contém material o qual está sujeito a uma proteção de direitos autorais. O proprietá- rio dos direitos autorais não faz objeção à reprodução em fac-símile por qualquer um documento de patente ou da exposição de patente, conforme ela aprece no arquivo de patente do Patent and Trademark Office ou nos registros, mas se reserva todos os direitos autorais que sejam. Antecedentes

Bolsas de Futuros, referidas aqui também como uma "Bolsa", tal como a Chicago Mercantile Exchange Inc. (CME), provêem um mercado em que futuros e opções sobre futuros são negociados. Futuros é um termo usado para designação de todos os contratos cobrindo a compra e a venda de instrumentos financeiros ou mercadorias (commodities) físicas para entrega futura em uma bolsa de futuros de mercadoria. Um contrato de futuros é um acordo de obrigação legal para compra ou venda de uma mercadoria em um preço especificado em um tempo futuro predeterminado. Cada contrato de futuros é padronizado e especifica mercadoria, qualidade, quantidade, data de envio e liquidação. Uma opção é o direito, não a obrigação, de vender ou comprar o instrumento subjacente (neste caso, um contrato de futuros) em um preço especificado em um tempo especificado.

O mercado de câmbio é o maior e mais líquido mercado finan- ceiro no mundo, representando mais de 1,2 trilhões de dólares de transa- ções por dia. Também conhecido como forex ou FX, o negócio de moeda tipicamente envolve a compra simultânea de uma moeda enquanto se vende uma outra moeda. As moedas tipicamente são negociadas em pares, tal como dólar americano/iene japonês (USD/JPY) ou euro/dólar americano (EUR/USD), ou através de índices de moeda, tais como CME$INDEX(TM).

De modo a capitalizar no mercado de câmbio, a CME também oferece produtos futuros de FX1 isto é, contratos de futuros em que o instru- mento financeiro subjacente é uma transação de moeda estrangeira, além de produtos de futuros baseados em outras mercadorias e instrumentos fi- nanceiros. Contudo, os futuros de FX não são os únicos mecanismos por meio dos quais as moedas estrangeiras podem ser negociadas. Por exem- plo, o mercado interbancário de FX é uma rede global dos bancos mundiais sem uma localização centralizada para negociação. Muito do negócio é con- duzido por telefone ou eletronicamente de banco para banco. O mercado de FX é um mercado de 24 horas por dia durante a semana comercial de FX. O dia começa na Ásia, estende-se pela Europa e, então, para as horas de negociação do dia dos Estados Unidos. As moedas são negociadas por todo o mundo, o dia inteiro, da manhã de segunda (horário de tarde de domingo de Chicago/Nova York) na Nova Zelândia/Ásia para fechamento da semana comercial na tarde de sexta-feira em Chicago/Nova York.

"De Balcão" ("OTC") é o termo freqüentemente usado para refe- rência a instrumentos de negociação de moeda os quais não são classifica- dos como um instrumento de "futuros", conforme definido acima e não nego- ciados em uma bolsa de futuros, tal como a CME, isto é, o que não é um contrato de futuros é um contrato de OTC. Esses contratos de OTC incluem contratos "a termo", isto é, acordos privados entre compradores e vendedo- res, isto é, contratos bilaterais para a entrega futura de uma mercadoria a um preço acordado. Enquanto os contratos de futuros são regulados pela Commodity Futures Trading Commission ("CFTC"), os contratos a termo ou de OTC não são regulados assim, tornando-os mais flexíveis e um dispositi- vo atrativo para certos investidores e certos mercados.

Os especuladores são ativos nos mercados de FX, já que são atraídos para as oportunidades que as condições de mercado voláteis e mu- táveis criam. Uma multidão de forças econômicas tem impacto sobre as mo- edas do mundo. Algumas das forças em ação incluem diferenciais de taxa de juros, crescimento de suprimento de dinheiro doméstico, taxas compara- tivas de inflação, intervenção de banco central e estabilidade política. Em tempos de incerteza global, algumas moedas podem se beneficiar do status percebido de "vôo para segurança". Ou1 se um panorama econômico de um país for percebido como forte por forças de mercado, sua moeda poderá ser mais firme do que a moeda de um outro país, em que condições econômicas ou políticas são vistas com cautela.

Os negociadores de FX incluem governos, corporações e admi- nistradores de fundos fazendo negócio com países estrangeiros, que preci- sam trocar uma moeda por uma outra, e especuladores que buscam lucrar de movimentos de preço nos mercados.

Os mercados de câmbio altamente líquidos e voláteis oferecem oportunidades para especuladores a cada dia. A maioria dos especuladores tende a se concentrar nos assim denominados "principais" ("majors"), os quais são as moedas mais ativamente negociadas e incluem o dólar ameri- cano, o euro, o iene japonês, a libra inglesa, o franco suíço, o dólar australi- ano e o dólar canadense.

Enquanto o mercado de FX de OTC oferece vantagens tais co- mo menos regulamentação e mais flexibilidade de produto, a bolsa de futu- ros de CME oferece seus próprios benefícios, tais como equilíbrio e com- pensação centralizados e anônimos, bem como otimização de eficiência e mecanismos de gerenciamento de risco/seleção de crédito não disponíveis nos mercados de OTC presentes. Portanto, seria vantajoso ser capaz de negociar produtos de FX de OTC através dos mesmos mecanismos usados para a negociação de contratos de futuros, de modo a se garantirem estes mesmos benefícios e proteções.

Assim sendo, há uma necessidade de sistemas e métodos para se permitir que produtos de FX de OTC sejam negociados em um ambiente de equilíbrio e compensação, tal como o ambiente utilizado pela bolsa de futuros de CME.

Breve Descrição dos Desenhos

A Figura 1 descreve um diagrama de blocos de um sistema de exemplo para negociação de instrumentos de FX de OTC de acordo com as modalidades descritas.

A Figura 2A mostra um diagrama de blocos mais detalhado do sistema da Figura 1 de acordo com uma modalidade.

A Figura 2B mostra um diagrama de blocos mais detalhado do sistema da Figura 1 de acordo com uma modalidade alternativa.

A Figura 3 mostra uma exibição em tela de exemplo e uma de- terminação de preço.

A Figura 4 mostra um fluxo de mensagem de negócio de exem- plo para uma funcionalidade de RFQ Dirigida para uso nas modalidades descritas.

As Figuras 5A a 5G descrevem diagramas de blocos de um sis- tema de Margem Cruzada de Contraparte Central Híbrido Flexível ou Garan- tia Cruzada de acordo com uma modalidade.

A Figura 6 descreve um diagrama de blocos de um sistema de exemplo para negociação de instrumentos de FX de OTC tendo um sistema de requisição para cotação dirigida de acordo com as modalidades descritas.

A Figura 7 descreve um diagrama de blocos de uma modalidade de um servidor de requisição para cotação dirigida para uso com o sistema da Figura 6.

A Figura 8 descreve um diagrama de blocos de um sistema de exemplo para negociação de instrumentos de FX de OTC tendo um sistema de requisição para cotação dirigida de acordo com uma modalidade alternativa.

Descrição Detalhada dos Desenhos e Modalidades Presentemente Preferidas

Os sistemas e métodos descritos se referem a permitir uma ne- gociação de contratos de câmbio ("FX") de balcão ("OTC") em um mecanis- mo centralizado de equilíbrio e compensação, tal como aquele do sistema de bolsa de futuros da Chicago Mercantile Exchange Inc. ("CME") (a "Bolsa").

Os sistemas e métodos descritos permitem transações anônimas, compen- sação centralizada, liquidação eficiente e a provisão de mecanismos de ge- renciamento de risco/seleção de crédito para diminuição de risco, redução de custos de transação e melhoria da liquidez no mercado de FX. Em parti- cular, as modalidades descritas aumentam a velocidade de execução facili- tando uma demanda crescente para negociação algorítmica, transparência de preço aumentada, custo menor de negociação, negociação de consumi- dor para consumidor e alocações de ativo automatizadas, negócios recorren- tes bem como eficiências de compensação e liquidação.

A Figura 1 mostra um diagrama de blocos de um sistema de e- xemplo 100 para negociação de instrumentos de FX de OTC de acordo com as modalidades descritas. O sistema 100 é essencialmente uma rede 102 acoplando participantes de mercado 104, 106, incluindo negociantes 104 e criadores de mercado (operadores intermediários) 106 com a Bolsa 108. A- qui, a frase "acoplado com" é definida para significar conectado diretamente a ou conectado indiretamente através de um ou mais componentes interme- diários. Esses componentes intermediários podem incluir componentes ba- seados em hardware e em software. Ainda, para esclarecer o uso nas rei- vindicações pendentes e desse modo prover uma nota ao público, as frases "pelo menos um dentre <A>, <B>, ... e <N>" ou "pelo menos um dentre <A>, <B>, ... <N>, ou combinações dos mesmos" são definidas pelo Requerente no sentido mais amplo, substituindo quaisquer outras definições implicadas aqui anteriormente ou a partir deste ponto, a mesmo que expressamente assegurado pelo Requerente ao contrário, para significar um ou mais ele- mentos selecionados a partir do grupo compreendendo A, B, ... e N, quer dizer, qualquer combinação de um ou mais elementos A, B, ... ou N, incluin- do qualquer elemento sozinho ou em combinação com um ou mais dos ou- tros elementos os quais também podem incluir, em combinação, elementos adicionais não listados. A Bolsa 108 provê as funções de equilíbrio 110 de transações de compra/venda, compensação 112 daquelas transações, liqui- dação 114 daquelas transações e gerenciamento de risco 116, dentre os participantes de mercado 104, 106 e entre os participantes de mercado e a Bolsa 108, bem como uma funcionalidade de requisição para cotação 118, conforme é discutido em maiores detalhes abaixo. As Figuras 2A e 2B mos- tram diagramas de blocos mais detalhados da arquitetura lógica do sistema 100 da Figura 1. Em particular, a Figura 2A mostra um diagrama de blocos do sistema 100 de acordo com uma modalidade, na qual a Bolsa 108 é in- terconectada com um segundo mercado de FX para se permitir que os parti- cipantes de mercado de FX façam transações pela Bolsa, conforme descrito aqui. Nesta modalidade, o segundo mercado de FX é provido pela Reuters.

A Figura 2B mostra um diagrama de blocos do sistema 100 de acordo com uma segunda modalidade na qual a Bolsa 108 ainda provê uma conectivida- de para os participantes de mercado de FX existentes.

Embora as modalidades descritas se refiram à negociação de instrumentos de FX de OTC, os mecanismos e métodos descritos aqui não estão limitados a isto e podem ser aplicados a qualquer produto de OTC.

Tipicamente, a Bolsa 108 provê uma "câmara de compensação", a qual é uma divisão da Bolsa 108 através da qual todos os negócios feitos devem ser confirmados, equilibrados e liquidados a cada dia, até compensa- ção ("offset") ou entrega. A câmara de compensação é um adjunto para a Bolsa 108 responsável pela liquidação de contas de negócio, compensação de negócios, coleta e manutenção de fundos de título, regulamentação de dados de negociação de entrega e relatório. Essencialmente mitigando cré- dito. A compensação é o procedimento através do qual a Câmara de Com- pensação se torna o comprador de cada vendedor de um contrato de futu- ros, e vendedor para cada comprador, também referido como "novação" e assume responsabilidade pela proteção de compradores e vendedores quanto a uma perda financeira ao assegurar uma performance em cada con- trato. Isto é efetuado através do processo de compensação, por meio do qual as transações são equilibradas. Um membro de compensação é uma firma qualificada para compensar negócios através da Câmara de Compen- sação. No caso da câmara de compensação da CME, todos os membros de compensação não especificamente designados como membros de Classe B são considerados membros de compensação de Classe A. Na CME, há três categorias de membros de compensação: 1) membros de compensação de CME, qualificados para compensarem transações para todas as mercadori- as; 2) membros de compensação de IMM1 qualificados para compensarem apenas negócios para apenas mercadorias de IMM e IOM; e 3) membros de compensação de Classe B de IMM1 unicamente limitados para a condução de uma arbitragem proprietária em moedas estrangeiras entre um banco aprovado de Bolsa único e o IMM que deve ser garantido por um ou mais membros de compensação de CME ou de IMM não de banco de Classe A.

Note que um "membro" é um criador de mercado/negociador registrado junto à Bolsa. Conforme será discutido abaixo, nas modalidades descritas, uma nova classe de membro de compensação pode ser introduzida para fins de negociação de FX de OTC, exclusivamente ou em conjunto com outros pro- dutos de CME, isto é, futuros, conforme descrito aqui. Será apreciado que essas classificações são dependentes de implementação.

Nas modalidades presentemente descritas, a Bolsa 108 assume um papel adicional como o intermediário central em transações de FX de OTC, isto é, a Bolsa 108 se tornará o comprador para cada vendedor e o vendedor para cada comprador, e assumirá responsabilidade pela proteção de compradores e vendedores de perda financeira ao assegurarem uma per- formance em cada contrato, conforme é feito em transações de futuros. Con- forme usado aqui, o termo "Bolsa" 108 se referirá aos mecanismos centrali- zados de compensação e liquidação, sistemas de gerenciamento de risco, etc., conforme descrito abaixo, usados para negociação de futuros, incluindo os melhoramentos descritos para facilitação de transações de FX de OTC. Ao assumir este papel intermediário e empregando mecanismos de seleção de crédito e gerenciamento de risco, as partes previamente não capazes de negociarem FX de OTC, porque, por exemplo, elas foram excluídas por cré- dito, agora podem negociar de forma na anônima. Em mercados de FX de OTC anteriores, os bancos eram o único lado de venda para transações. As modalidades presentemente descritas permitem que os negociadores tomem posições de lado de venda ou de compra e o lado de venda não está mais limitado a bancos.

Embora as modalidades descritas sejam descritas com referên- cia à CME, será apreciado que estas modalidades são aplicáveis a qualquer Bolsa 108, incluindo aquelas as quais negociam em títulos de capital e ou- tros títulos. A Câmara de Compensação de CME compensa, liquida e garan- te todas as transações equilibradas em contratos de CME ocorrendo através de suas instalações. Além disso, a Câmara de Compensação de CME esta- belece e monitora as exigências financeiras para membros de compensação e porta certos privilégios de compensação em conjunto com as bolsas rele- vantes.

Como um intermediário, a Bolsa 108 porta uma certa quantidade de risco em cada transação que ocorre. Para esta finalidade, mecanismos de gerenciamento de risco protegem a Bolsa através da Câmara de Com- pensação. A cápsula de calibração estabelece obrigações de performance de nível de compensação (margens) para todos os produtos de CME e esta- belece exigências mínimas de obrigação de performance para consumidores de produtos de CME. Uma obrigação de performance, também referida co- mo margem, é o fundo que deve ser depositado por um consumidor com seu criador de mercado, por um criador de mercado com um membro de com- pensação ou por um membro de compensação com a Câmara de Compen- sação, para fins de garantir o criador de mercado ou a Câmara de Compen- sação contra uma perda em contratos de futuros abertos ou opções. Isto não é um pagamento à prestação em uma compra. A obrigação de performance ajuda a garantir a integridade financeira de criadores de mercado, membros de compensação e da Bolsa como um todo. A Obrigação de Performance para uma Câmara de Compensação se refere ao depósito em dólar mínimo o qual é requerido pela Câmara de Compensação de membros de compen- sação de acordo com suas posições. Manutenção ou margem de manuten- ção se refere a uma soma, usualmente menor do que a obrigação de per- formance inicial, a qual deve permanecer no depósito na conta do consumi- dor para qualquer posição em todos os tempos. A margem inicial é a quanti- dade total de margem por contrato requerida pelo criador de mercado, quan- do uma posição de futuros for aberta. Uma queda em fundos abaixo deste nível requer um depósito de volta para os níveis de margem iniciais, isto é, uma chamada de obrigação de performance. Se um título de capital de con- sumidor em qualquer posição de futuros cair para ou abaixo do nível de ma- nutenção por causa de uma ação de preço adversa, o criador de mercado deverá emitir uma chamada de obrigação de performance/margem para res- tauração do título de capital do consumidor. Uma chamada de obrigação de performance, também referida como chamada de margem, é uma demanda por fundos adicionais para se levar a conta de consumidor de volta para o nível inicial de obrigação de performance sempre que movimentos de preço adversos fizerem com que a conta vá abaixo da manutenção. Conforme será discutido abaixo, uma funcionalidade adicional é provida na modalidade des- crita para a provisão de gerenciamento de risco para transações de FX de OTC.

As contas de membros individuais, firmas de compensação e consumidores não membros fazendo negócio através de CME devem ser portadas e garantidas para a Câmara de Compensação por um membro de compensação. Conforme mencionado acima, em toda transação equilibrada executada através das instalações da Bolsa, a Câmara de Compensação é substituída como o comprador para o vendedor e o vendedor para o com- prador, com um membro de compensação assumindo o lado oposto de cada transação. A Câmara de Compensação é uma divisão de operação da Bolsa 108, e todos os direitos, obrigações e/ou responsabilidades da Câmara de Compensação são direitos, obrigações e/ou responsabilidades de CME. Os membros de compensação assumem plena responsabilidade financeira e de performance por todas as transações executadas através deles e todas as posições que eles portarem. A Câmara de Compensação, lidando exclusi- vamente com membros de compensação, mantém cada membro de com- pensação responsável para cada posição que portar, identidade de se a po- sição está sendo portada para a conta de um membro individual, para a con- ta de um consumidor não membro ou para a própria conta do membro de compensação. Inversamente, como o lado contrário de toda posição, a Câ- mara de Compensação é mantida responsável para os membros de com- pensação para a liquidação líquida de todas as transações nas quais ela foi substituída como provido pelas Regras. Conforme será explicado abaixo, estes mecanismos serão aumentados de modo a lidarem com transações de FX de OTC. Mais informação sobre a minimização do risco para a Bolsa 108, enquanto de modo similar se minimiza o encargo sobre os membros, apro- ximando a exigência de obrigação de performance ou margem requisitada tão proximamente quanto possível das posições reais da conta em qualquer dado tempo e melhorando a acurácia e a flexibilidade dos mecanismos os quais estimam as exigências de obrigação de performance pode ser encon- trada nos Pedidos de Patente U.S. a seguir, todos os quais sendo incorpora- dos como referência aqui: Pedido de Patente. U.S. N° de Série 11/030,815, "SYSTEM AND METHOD FOR

ACTIVITY BASED MARGINING", (Referência Legal N°4672/410), deposita- do em 7 de janeiro de 2005, agora Patente U.S. N°;

Pedido de Patente U.S. Ne de Série 11/030,796, "SYSTEM AND METHOD FOR EFFICIENTLY USING COLLATERAL FOR RISK OFFSET", (Referência Le- gal N°4672/417), depositado em 7 de janeiro de 2005, agora Patente U.S. N°:

Pedido de Patente U.S. Ne de Série 11/030,833, "SYSTEM AND METHOD FOR ASYMMETRIC OFFSETS IN A RISK MANAGEMENT SYSTEM", (Referên- cia Legal N°4672/418), depositado em 7 de janeiro de 2005, agora Patente U.S. N° :

Pedido de Patente U.S. Ne de Série 11/030,814, "SYSTEM AND METHOD FOR DISPLAYING A COMBINED TRADING AND RISK MANAGEMENT GUI DISPLAY", (Referência Legal N°4672/419), depositado em 7 de janeiro de 2005, agora Patente U.S. N°;

Pedido de Patente U.S. Nq de Série 11/031,182, "SYSTEM AND METHOD FOR FLEXIBLE SPREAD PARTICIPATION", (Referência Legal Ne4672/420), de- positado em 7 de janeiro de 2005, agora Patente U.S. N°;

Pedido de Patente U.S. N9 de Série 11/030,869, "SYSTEM AND METHOD FOR HYBRID SPREADING FOR RISK MANAGEMENT", (Referência Legal N°4672/421), depositado em 7 de janeiro de 2005, agora Patente U.S. N°; e

Pedido de Patente U.S. N° de Série 11/030,849, "SYSTEM AND METHOD OF MARGINING FIXED PAYOFF PRODUCTS", (Referência Legal N°4672/507), depositado em 7 de janeiro de 2005, agora Patente U.S. N9_.

Nos presentes mercados de FX de OTC1 liquidez e acesso a preço são fragmentados criando ineficiências para participantes do mercado. Essa fragmentação é devido, em parte, à confiança tradicional em um crédi- to de contraparte bilateral que compartimentaliza a negociação, bem como o papel de legado de bancos como criadores de mercado para negociado- res/firma não bancários. O mercado compensado centralmente para FX de OTC provido pelas modalidades descritas permite acesso à melhor preço, acesso igual para todos os segmentos de mercado, e lado de compra e lado de venda, bem como eficiências operacionais, conforme será discutido.

Em uma negociação bilateral, os compradores e vendedores consumam negócios por si mesmos. Os vendedores devem aceitar o crédito de cada comprador, os compradores enviam um pagamento diretamente para cada vendedor e os compradores devem aceitar a capacidade de cada vendedor de desempenhar o contrato. Se qualquer parte desejar fechar um negócio antes da entrega, ela deve negociar exclusivamente com sua con- traparte original. Essa negociação bilateral cria ineficiências para o lado de compra de FX. Por exemplo, uma negociação bilateral cria um preço inefici- ente pelo fato de o mercado consistir em múltiplas contrapartes negociando e a exibição de posições de abertura e fechamento com o mesmo banco. Ainda, uma negociação bilateral cria um uso ineficiente de garantia, por e- xemplo, pode haver exigências para se colocar uma margem em vários ban- cos e cria um risco operacional excessivo, por exemplo, múltiplas relações de confirmação de departamento administrativo.

A liquidação de negócio de FX atual utiliza o Banco de Liquida- ção Ligado Contínuo ("CLS"). Antes da disponibilidade do Banco de CLS, as liquidações de negócio de FX resultavam em pagamentos de moeda sepa- rados entre contrapartes de negócio, as quais incorriam em um risco elevado de que uma parte poderia não pagar, especialmente tendo em vista diferen- ças de fuso-horário, também conhecido como "Risco Herstaat". O Banco de CLS elimina o risco de liquidação 'temporal' pela liquidação de ambos os lados de pagamentos de moeda duplos por entrega versus pagamento, des- se modo mitigando o Risco Herstaat em liquidações diárias.

Um Processamento Direto ("STP") provê os benefícios de redu- ção de erros durante o processamento, aceleração de processamento de negócio, gerenciamento de risco em tempo real, alocações de conta automa- tizadas, e eficiências de equipe de departamento administrativo. Contudo, nos presentes mercados de FX de OTC, os benefícios de STP são limitados pela falta de padronização e entrega em tempo real de afirmações de negó- cio eletrônico e confirmações de negócio.

As modalidades descritas oferecem custo reduzido de acesso a mercado e, desse modo, melhor acesso a melhor preço, custos de suporte de infra-estrutura menores e execução de negócio mais fácil e menos dis- pendiosa, transparência de preço e volume, transferência de risco eficiente, padronização de STP e preços auditáveis e avaliação ao preço de mercado (mark-to-market).

Em particular, as modalidades descritas caracterizam execução e compensação de FX de OTC centralizados através de uma plataforma de equilíbrio e compensação centralizada acessada, por exemplo, através de criadores de mercado primários/compensação direta. Os sistemas e méto- dos descritos podem ser usados por participantes institucionais nos merca- dos de FX de OTC, tais como bancos, gerenciadores de ativos, firmas de negociação alavancada (fundos de hedge, CTAs, firmas de propriedade (prop firms), etc.) e/ou programa de moeda e gerenciadores de sobreposi- ção. Os sistemas e métodos descritos podem suportar produtos de FX de OTC, tais como Spot (entrega imediata), swap (conversão) de entrega a termo de FX e instrumentos de opções de FX. Os sistemas e métodos des- critos utilizam uma tecnologia de equilíbrio de negócio bem como métodos de interação baseados em interface gráfica de usuário ("GUI") e interface de programa aplicativo ("API"). Ainda, um novo processo de requisição para cotação é provido. Nas modalidades descritas, a compensação ocorre atra- vés da câmara de compensação de Bolsa, tal como a Câmara de Compen- sação de CME. Liquidações diárias ainda podem ocorrer utilizando o banco de CLS, mas com eficiências adicionadas, as quais serão discutidas abaixo. Um gerenciamento de risco com garantia também é provido, conforme será discutido abaixo. Ainda, os protocolos de STP de OTC são suportados.

As modalidades descritas provêem valor para o lado de compra de transações de FX de OTC. Em particular, os sistemas e métodos descri- tos se dirigem à demanda de consumidor por eficiências de mercado de FX aumentadas, pré-negócio, negócio e pós-negócio. Por exemplo, as modali- dades descritas provêem acesso a negociação de linhas e limites, bem co- mo preço de FX auditado e publicado e dados de volume. Ainda, um acesso ao melhor preço é provido, bem como anonimato de negócio, velocidade de execução melhorada, acesso a um grupo de liquidez primária, e acesso a múltiplos produtos de FX. Além disso, um STP em tempo real é provido co- mo é um gerenciamento de negócio eficiente/posição através de uma rede ("netting") multilateral. Ainda, todos os estilos de negociação são acomoda- dos, tais como negociação algorítmica, negociação de GUI/Teclado e nego- ciação baseada em requisição para cotação ("RFQ").

No lado de venda, as modalidades descritas ainda provêem va- lor para bancos. Por exemplo, elas permitem a capacidade de estender as atividades de corretagem além dos limites de relações de crédito bilateral, por exemplo, negociação com novos consumidores, estendem a negociação com os consumidores existentes, etc. Ainda, um acesso aumentado à liqui- dez de FX e acomodação de vários estilos de negociação também são pro- vidas. Além disso, o acesso a um gerenciamento de risco em tempo real e STP é provido juntamente com crédito e mitigação de risco de liquidação.

Em pelo menos uma das modalidades descritas, um modelo de mercado híbrido pode ser provido, o qual equilibra um equilíbrio de livro de pedidos de limite central de bolsa e negociação bilateral do mercado de OTC com acesso e compensação eletrônicos expandidos anônimos. Alternativa- mente, outras modalidades podem prover subconjuntos desta funcionalidade.

As modalidades descritas suportam um ou mais dos tipos de instrumento de FX a seguir: entrega a termo, entrega imediata e swaps. Entrega a termo se refere a contratos de entrega a termo de FX que expiram diariamente começando a partir de amanhã, isto é, do dia após a data de transação, e valendo por dois anos, para cada par de moeda. Uma "Entrega Imediata" se refere à entrega a termo que expira em dois dias após a data de transação. Um swap é essencialmente uma margem de lucro (spread) temporal, isto é, a aquisição (venda) simultânea de contrato(s) em um mês de entrega próximo (primeira base ("leg")) e a venda (aquisição) de um nú- mero igual de contrato(s) em um mês de entrega distante do mesmo contra- to (segunda base), onde a primeira base é uma Entrega Imediata e a segun- da base é uma Entrega a Termo mais distante.

Em uma modalidade, vários produtos de swap são oferecidos, incluindo Entrega Imediata frente ao seguinte (37 no total, assumindo que o dia declarado ou o dia seguinte após o qual não seja um feriado em qualquer moeda):

• Amanhã - Tom Next (T/N)-· - O Swap o qual tem uma pri- meira base de Entrega a Termo expirando amanhã e a próxima base de En- trega a Termo como "Entrega Imediata"

• O dia depois de amanhã - Spot Next (S/N)

• Entregas a termo de Swap em uma semana, duas semanas, 3 semanas

• Mensalmente entregas a termo de Swap de 1 mês a 24 me· ses

• · Exceto se esta data for em um fim de semana ou um feriado

em qualquer moeda, ir para a data da semana precedente a qual não seja um feriado em qualquer moeda.

• Exceto se a data de validade de entrega a termo for a última data do mês, então, ir para a última data da semana do enésimo mês se- guinte o qual não é um feriado em qualquer moeda.

• Entregas a termo de Swap nas datas 8 IMM pelos próximos dois anos.

• Swap Datado Interrompido - Qualquer Swap o qual não seja um dos Swaps predefinidos acima.

Será apreciado que outras combinações de produto também po- dem ser oferecidas. Ainda, as modalidades descritas utilizam instrumentos de Rola- gem Diária, onde o símbolo de contrato usado pelos consumidores para re- ferenciarem um dado Swap ou Entrega Imediata não muda, de dia para dia, mas as bases de Swap realmente mudam a cada dia, isto é, as referências temporais no instrumento são tratadas com relativas à data de transação ao invés de serem expressas em forma absoluta, desse modo necessitando de um conjunto de símbolo significativamente aumentado para se referenciá- las:

• Da perspectiva do negociador, símbolos de contrato para instrumentos eletronicamente equilibrados são "genéricos" - mensagens de

cumprimento incluem as datas de validade e os preços de cada base;

• Definições de instrumento, portanto, incluiriam símbolos de contrato como "USDSPYSP" para Entrega Imediata e "USDJPY1M" para especificação de swap de entrega a termo, um mês.

A cada dia, novos instrumentos são usados:

• Entrega a termo para a data de 2 anos

• Todos os instrumentos de swap são renovados com novas

bases.

As datas de validade apropriadas para contratos eletronicamente equilibrados são atribuídos pelo sistema em um tempo de equilíbrio e provi- dos para o usuário nas mensagens de entrada de pedido/cumprimento de escritório de operações para cada base. Para uma Requisição para Cotação Direta ("RFQ Dirigida" ou "DRFQ"), discutida em maiores detalhes abaixo, os usuários podem introduzir as bases desejadas para uma RFQ Dirigida usan- do contratos genéricos, com as datas de validade requisitadas. Por exemplo, um usuário desejando fazer uma RFQ para uma entrega a termo direta, isto é, uma ordem para comprar ou vender apenas um tipo específico de contra- to, com uma data de validade específica deve ser capaz de especificar isso, sem ter que especificar um contrato único que esteja associado internamen- te àquela data de validade.

Com referência à Figura 3, em uma modalidade, o preço de ba- se de Entrega Imediata é o ponto médio entre a oferta para compra/pergunta no mercado de Entrega Imediata ou negociado por último em um período de tempo específico; o outro preço de base de Entrega a Termo é feito com ba- se no preço de Entrega Imediata mais o diferencial (por exemplo, "30" é um diferencial de 0,0030 entre Entrega Imediata e a base de Entrega a Termo).

Se o ponto médio entre a oferta para compra/pergunta no mer- cado de Entrega Imediata atual for vencida, uma informação de liquidação poderá ser usada. Se o mercado de entrega imediata não for líquido e ne- nhum dado de mercado estiver sendo produzido atualmente, os consumido- res serão mantidos atualizados com fontes secundárias para minimização de resultados inesperados quando o preço de base chegar. Uma regra de co- mércio de ter os mercados de Entrega Imediata regulamente cotados por criadores de mercado pode ser provida.

Para alguns mercados, o Swap não usa a Entrega Imediata para aquele mercado, mas, ao invés disso, um mercado associado. Isto é realiza- do fazendo-se um cálculo recíproco (1/preço atual) da entrega imediata, ou um ponto médio de entrega imediata naquele mercado associado.

Nas modalidades descritas, para fins de determinação da data de validade, convenções de data de validade são empregadas. Por exemplo, a conversão de data de validade para entrega imediata para USD/CAD em um dia comercial e para todos os outros é de dois dias comerciais. Uma data de validade é válida para um par de moedas se for um dia comercial bancá- rio para ambas as moedas do par. Uma negociação pode ocorrer fisicamen- te em qualquer dia de semana. Contudo, para uma negociação ocorrendo em qualquer dado dia de semana, a regra para se levarem em consideração feriados quando da determinação da data de validade para uma negociação de "entrega imediata" naquele dia de semana difere, dependendo da moeda na qual o feriado ocorre. Para feriados em USD, você precisa apenas de um dia de trabalho inteiro antes de poder liquidar um negócio de entrega imedia- ta. Por exemplo, quarta-feira, quatro de julho (dia da independência dos Es- tados Unidos), um feriado de USD; uma negociação de entrega imediata segunda-feira em USD/JPY tem data de validade de quinta-feira (porque quarta-feira é um feriado de USD); uma negociação de entrega imediata ter- ça-feira em USDJPY também tem data de validade de quinta-feira (porque você precisa de apenas um dia de trabalho de USD). Para feriados em ou- tras moedas além de USD, dois dias de trabalho completos antes de uma liquidação podem ser requeridos. Por exemplo, quarta-feira sete de dezem- bro (Dia de Pearl Harbor), um feriado de JPY; uma negociação de entrega imediata de segunda-feira em USD/JPY tem uma data de validade de quinta- feira (porque quarta-feira é um feriado de JPY); uma negociação de entrega imediata de terça-feira em USD/JPY tem uma data de validade de sexta-feira (porque quarta-feira é um feriado de JPY e você precisa de dois dias de tra- balho completos em JPY).

Nas modalidades descritas, um suporte para os instrumentos listados na Tabela 1 é provido. Será apreciado que as propostas para venda de instrumento podem variar e são dependentes de implementação. Em par- ticular, o Livro de Pedido de Limite Central ("CLOB") suportarão Entrega Imediata e/ou entregas a termo de Swap padronizadas. O mecanismo de RFQ Dirigida, discutido em maiores detalhes abaixo, suportará Entrega Ime- diata, Entregas a Termo (qualquer data de até 2 anos), entregas a termo de Swap (casos padronizados), swaps de data interrompida, ou combinações dos mesmos. Tabela 1

<table>table see original document page 19</column></row><table> Nas modalidades descritas, três pares de moedas terão um mercado secundário para a listagem alternada (por exemplo, um contrato de ¥/$ e um contrato de $/¥ existirão, como mercados separados completamen- te):

• lene japonês

• Franco suíço

• Dólar canadense

Instrumentos diretos de entrega a termo serão cotados em termos de uma moeda apenas (por exemplo, uma entrega a termo de $/¥ é cotada em JPY, não em USD). Os instrumentos de Swap serão cotados em diferencial.

Nas modalidades descritas, há dez pares de moedas, mas ape- nas seis com swaps definidos. Os tamanhos de contrato serão em unidades de um milhão da moeda de base. Os instrumentos são divididos flutuados em décimos, não quartos nem em uma tabela de divisão de flutuação variá- vel(VTT).

Com respeito a uma rolagem de data de validade diária, os usu- ários precisam ser notificados apenas que a data de validade mudou para a Entrega Imediata e Swaps, ao invés de que a mudança é para cada instru- mento. Em uma modalidade, os usuários são notificados quanto ao que são as datas de validade atuais para cada instrumento. Os participantes podem requisitar datas de validade para cada instrumento a partir do mercado.

Um novo indicador (indicador) na mensagem de dados de mer- cado de Definição de Instrumento (Instrument Definition) é provido (o MO, em-oh), o qual está disponível para uso neste mercado. Um uso de exemplo poderia ser na situação em que cada instrumento foi listado individualmente. Este indicador poderia mudar diariamente para muitos destes instrumentos, conforme indicado pelos indicadores "Negociáveis" ("Tradable") na tabela acima.

Em uma modalidade, qualquer uma das entregas a termo Iista- das, embora não em um livro de pedido de limite central, pode ser negociada através do sistema de RFQ Dirigida (citado abaixo). Os negociadores tam- bém podem suar o sistema de RFQ Dirigida para criarem dinamicamente um mercado de Swap de data interrompida consistindo naqueles Swaps não predefinidos (isto é, aqueles os quais têm uma base de entrega a termo não padronizada). Estes mercados também não estão em um livro de pedido de limite central.

Será apreciado que as definições e convenções de instrumento precedentes são dependentes de implementação e modificações adequadas para a acomodação de instrumentos e convenções alternativos são contem- plados aqui. Por exemplo, embora seja vantajoso utilizar uma simbologia de produto existente e padrões de instrumento no mercado de FX de hoje em dia, outra simbologia ou padrões, não disponíveis ou desenvolvidos mais tarde também poderão ser usados, com os sistemas e métodos descritos.

Para facilitação da compensação de produtos de FX de OTC usando-se o mecanismo de compensação e liquidação, as modalidades descritas caracterizam uma nova classe de membro de compensação para bancos e criadores de mercado primários, além dos membros de Câmara de compensação existentes. A participação em Bolsa existente pode ser usada para negociação neste novo mercado também. Ainda, para as modalidades descritas, apenas usuários institucionais terão permissão para usarem a pla- taforma (sem varejo). Firmas de compensação terão que garantir que seus consumidores se adéqüem aos critérios estabelecidos para acesso. Estes critérios podem ser baseados em capitalização. O mesmo grupo de risco único será usado para o sistema de salvaguarda. Em modalidades alternati- vas, os participantes de mercado podem ser definidos diferentemente.

Com respeito ao acesso de mercado, uma autorização pode ser requerida antes de uma entrada de pedido poder ocorrer. Uma autorização deve ocorrer no nível de granularidade de Pseudônimo de Assinante (locali- zação de origem do pedido), bem como o TraderID (originador de pedido) e/ou a Conta (entidade em nome da qual o pedido está sendo submetido), mas pode afetar o processo de registro. Em uma modalidade, uma autoriza- ção ocorre por TraderID e/ou Conta. Em uma modalidade, uma autorização é para o mercado inteiro, ao invés de granular para par de moedas.

A aplicação de uma contraparte central para transações de FX de OTC permite que uma funcionalidade adicional seja oferecida aos partici- pantes de mercado de FX de OTC. Em uma modalidade, um arranjo de li- quidação é provido, o qual permite que várias posições de FX sejam arran- jadas para liquidação em conjunto para liquidação, ao invés de separada- mente liquidadas, desse modo se reduzindo o número de transações de li- quidação e os custos de transação associados. As transações individuais ainda são acompanhadas e reportadas pelo número real de transações de liquidação, por exemplo, aquelas enviadas para CLS, são reduzidas. Em uma outra modalidade, uma garantia é provida, a qual permite que o valor da conta de FX de uma entidade, o que pode mudar de valor através de débitos e créditos, mas não baseado no movimento real de valor, seja usado contra a exigência de margem daquela entidade de sua conta de negociação de futuros, desse modo se simplificando as exigências de margem e reduzindo o encargo geral.

Em uma modalidade, conforme descrito na Figura 2A, a CME provê uma funcionalidade de compensação e liquidez enquanto um mercado em separado, tal como Reuters, provê uma funcionalidade de equilíbrio e acesso a entidades de lado de venda, tais como bancos. Em uma modalida- de alternativa, conforme descrito na Figura 2B, a CME provê uma funcionali- dade de equilíbrio, compensação e liquidação. Será apreciado que a divisão de funcionalidade em admissão, processamento e completação de uma da- da transação é dependente de implementação.

De modo a se implementar um FX de OTC dentro de mecanis- mos de compensação e liquidação de Bolsa, uma funcionalidade de merca- do adicional é necessária, tal como: uma funcionalidade de agente de equilí- brio; uma funcionalidade de vigilância, controle de mercado e registro; uma funcionalidade de RFQ; uma funcionalidade de dados de mercado; uma fun- cionalidade de dados de negócio; uma funcionalidade de relatório de com- pensação/negócio/processamento direto ("STP"); uma funcionalidade de ho- norário; e uma funcionalidade de departamento de operações/distribuição.

Em particular, o agente de equilíbrio conecta-se a pedidos late- rais de venda e de compra para negócios completos. Em uma modalidade, o agente de equilíbrio utiliza um algoritmo de equilíbrio de primeiro a entrar, primeiro a sair ("FIFO") para transações de Entrega Imediata e um algoritmo de equilíbrio de FIFO com Criador de mercado Líder para transações de Swap de Entrega a Termo. Nesta modalidade, uma proteção de criador de mercado simples é provida para transações de Swap de Entrega a Termo. Uma cotação em massa também é permitida com transações de Swap de Entrega a Termo.

Em uma modalidade, futuros específicos são providos para mer- cador de swap de entrega a termo. Em particular, aproximadamente 10 a 20 Criadores de mercado são almejados para mercados de Swap de entrega a termo, através de todos os mercados. Uma cotação de base para swaps é feita em uma base diferencial, dado o preço de entrega imediata derivado e o diferencial de swap.

Em uma modalidade, a alocação respeitará o tamanho de con- trato de unidade de base de moeda de 1 milhão (isto é, um negócio de pro- dutos em unidades de base de 1 milhão). Não é requerido o agente de equi- líbrio que tenha controles de crédito, nem é requerido que ele acompanhe a posição de negociadores. Os negociadores devem conhecer as datas de entrega/validade de todos os cumprimentos de base. Isto pode ser realizado através da notificação de cumprimento/de uma mensagem de dados de mercado de criação de instrumento diária, ou de algum outro meio eletrônico padronizado.

Os negociadores precisam obter notificações de cumprimento de base com preços imediatamente após um equilíbrio. Assim sendo, mensa- gens de base de entrada de pedido de volta para o negociador para swaps de entrega a termo devem refletir uma base de Entrega Imediata, com sua data de validade associada e uma base de entrega a termo genérica, com sua data de validade associada. Isto é verdadeiro independentemente de as mensagens serem geradas como resultado de um equilíbrio eletrônico, ou um negócio em bloco baseado em RFQ Dirigida. Ainda, mensagens de base de entrada de pedido de volta para o negociador para contratos de Entrega Imediata devem refletir o contrato de Entrega Imediata genérico e sua data de validade associada, independentemente de as mensagens serem gera- das como resultado de um equilíbrio eletrônico, ou um negócio em bloco de RFQ Dirigida. Além disso, mensagens de base de entrada de pedido de vol- ta para o negociador para entrega a termo direta devem refletir a entrega a termo direta genérica e sua data de validade associada. Note que essas mensagens podem ser apenas o resultado de uma execução do negócio em bloco de RFQ Dirigida, uma vez que uma entrega a termo direta não será eletronicamente equilibrada.

O Agente de Negociação deve produzir uma informação sobre um negócio quanto se um dado lado foi o pedido agressor (isto é, o pedido não restante). Isto é para fins de funcionalidade de honorário, discutido abai- xo.

Uma funcionalidade de implicado, conforme discutido em maio- res detalhes abaixo, também pode ser provida.

O agente de equilíbrio pode suportar um ou mais dos tipos de pedido a seguir, ou combinações dos mesmos:

• Pedidos de Cumprir e Anular ("FAK") e Limite;

• RFQ para quantidade estará disponível para aqueles merca- dos os quais são negociados em um livro de pedidos de limite central; Pedidos de Parada e Lógica de Preço de Parada;

• Tipos de pedido de Válido Até ser Cancelado ("GTC");

• Tipos de pedido de Válido Até o Dia ("GTD");

• Negócios em bloco;

O agente de equilíbrio também pode prover um relatório de cumprimento consolidado (departamento de operações, departamento admi- nistrativo e dados de mercado).

O Relatório de Evento de Equilíbrio/Negócio para Compensação pode precisar incluir uma informação sobre a margem (spread) inteira. Isto requererá o uso da mensagem de D1 (bem como M1) a partir de Agente de Equilíbrio para Compensação ou uma nova interface/mensagem em conjun- to. Veja a Seção abaixo sobre Compensação/Liquidação para maiores in- formações. Em uma modalidade, o mercado operará em uma negociação contínua toda semana (24 horas por 5,5 dias), com uma rolagem de data de negociação existente diariamente:

• Mercados abrem às 11:45 AM horário de Chicago no domin- go para uma data de negócio de segunda-feira. Não pode haver uma rola- gem de data de negócio às 4:00 PM no domingo;

• Os mercados fecham semanalmente às 4:00 PM na sexta-

feira;

• Não há janela de manutenção de 4:00 PM a 5:00 PM. Não pode haver um estado de abertura tipo de IOP;

• O corte para o próximo dia de negociação ocorre as 4 PM horário de Chicago (5PM horário de Nova York);

• Os mercados abrem em quase todos os feriados normais;

• Todos os pedidos permanecem em livro. Na rolagem de data de negócio, as bases daquele Swap são redefinidas (talvez como um mer- cado inteiramente novo, mas com o mesmo Símbolo de ID Exter- no/Contrato); e

• Se houver um interesse em aberto em um mercado de Swap ou Entrega Imediata na rolagem de data de negócio, os pedidos permanece-

rão acionáveis naquele mercado "genérico", mas se negociados terão novos instrumentos de entrega a termo de base.

A funcionalidade de Vigilância, Controle de Mercado e Registro provê serviços de auditoria, segurança e autenticação. Em uma modalidade, ferramentas de gerenciamento de pedido são providas, tal como o FirmSoft de CME, o qual é uma ferramenta de gerenciamento de pedido baseada em navegador, que provê visibilidade em tempo real para pedidos praticáveis e cumpridos, através de múltiplos IDs de firma, no banco de dados de Geren- ciamento de Pedido CME® Globex®. Acessível através do portal de CME (via a internet) ou através de uma conexão de produção com a plataforma CME Globex, o CME FirmSoft provê um acesso importante aos pedidos praticá- veis e cumpridos durante falhas de sistema.

O Centro de Controle Globex ("GCC") deve ter capacidades atu- ais providas com Eagle/Ghost para Vigilância de Mercado.

a. Status/Cancelamento de Pedidos Praticáveis

b. Status de Cotações em Massa

c. Status/Fracasso de Negócios

d. Status de Blocos

e. Mais:

1. Vigilância por data de validade;

2. Agente deve usar uma instância de Ghost única para ser capaz de desempenhar um status através de Mercado de FX ou outros mer- cados de CME;

3. Status sobre requisições e respostas de RFQ Dirigida pode ser feito da mesma forma que as RFQs são atualmente, mas com uma in- formação sobre partes disponíveis;

4. Diferenças em termos & convenção entre o negociador final & GCC precisam ser levadas em consideração para todas as ferramentas (instrumentos genéricos, datas de validade, etc.).

O sistema pode ter disponível para auditoria os relatórios a se- guir:

• Atividade de Pedido & negócio - geral e por mercado

• Atividade de requisição e resposta de RFQ Dirigida - geral e por mercado

• Uma atividade de um dado criador de mercado no acima.

A Bolsa controlará os números de conta que são autorizados neste mercado e para cada novo participante um número de conta único é criado.

O conjunto de dados de registro que deve ser coletado para este mercado é similar aos dados existentes para outros mercados:

1. Nome de batismo

2. Sobrenome

3. Data de Nascimento

4. N9 de Inscrição Social

5. Telefone Comercial 6. Fax de trabalho (obrigatório) 7. E-mail (obrigatório) 8. Telefone Celular 9. Cidade de Nascimento 10. Escola Secundária 11. I D(s) de Negociador autorizadas 12. Ns de Conta (nova adição, mas veja abaixo parte TeIeStat) 13. Interfaces usadas a. iLink 2 b. EOS c. negociador Globex d. Firmsoft e. Mercado de FX 14. Tipo de Contato a. Técnico b. Mercado c. Admin. Primário de Firma d. Admin. Secundário de Firma 15. TeIeStat a. Pergunta de Segurança b. Resposta de Segurança c. Endereço de Negócio i. Cidade ii. País iii. Estado d. Tag 50/ Sub ID de Remetente e. Ne de Combinações de Firma e Conta 16. Assinatura de Contato Autorizada 17. Representação e Acordo de Firma de Compensação a. Nome de firma de compensação b. assinatura de funcionário c. nome de funcionário

d. cargo

e. data

18. Representação e Acordo de Consumidor

a. nome de consumidor

b. assinatura de funcionário

c. nome impresso de funcionário

d. cargo

e. data

O Mercado de FX pode requerer uma política de negócio de erro que será administrada pelo Centro de Controle Globex ("GCC"). As ferra- mentas de negociação de erro existentes podem ser usadas. O GCC deve ter capacidades atuais providas por ETP mais, como uma informação sobre a margem (spread) será passada para compensação, o sistema de ETP de- ve permitir uma inquisição com base neste critério.

A Câmara de Compensação proverá a cada dia os preços de liquidação de fim de dia mais economicamente apropriados que se precisa que sejam determinados para contratos em aberto, sem necessidade de o- perações ou suporte de GCC.

As modalidades descritas também caracterizam uma funcionali- dade de Requisição para Cotação Dirigida ("RFQ" Dirigida ou "DRFQ"). Em particular, esta funcionalidade permite requisições anônimas e privadas para cotação, isto é, o destinatário de requisição não está ciente da identidade do requisitante, mas respostas ainda são roteadas de volta unicamente para o requisitante. Em mercados prévios de FX de OTC, as transações eram bila- terais, devido à necessidade de gerenciamento de risco de crédito, e, portan- to, as partes de transação eram conhecidas umas pelas outras, desse modo sufocando algumas transações em potencial. As partes precisavam conhe- cer umas às outras de modo a avaliarem o risco de crédito, etc. Nas modali- dades presentemente descritas, o mecanismo de compensação centralizado armazena temporariamente/amortece/regula este risco de crédito para as partes, conforme foi descrito acima, e permite que as partes em transação permaneçam anônimas, com o mecanismo de compensação atuando como intermediário e amortecedor/armazenador/regulador de risco. Ainda, nos sistemas de RFQ anteriores, as requisições poderiam ser dirigidas para cria- dores de mercado em particular, mas as respostas para eles, isto é, cota- ções acionáveis, eram difundidas de volta para o mercado geralmente, au- mentando o risco/a exposição do respondente. No sistema de RFQ Dirigida descrito, as requisições são tornadas anônimas e então roteadas para todos os criadores de mercado ou, alternativamente, apenas para um subconjunto apropriado de criadores de mercado, com base em perfis de interesse dos criadores de mercado e/ou parâmetros da requisição (discutidos em maiores detalhes abaixo). Respostas/cotações acionáveis então são roteadas de vol- ta apenas para o requisitante, ao invés de para o mercado inteiro, desse modo se limitando a exposição de cotações acionáveis e reduzindo a expo- sição do(s) respondente(s). A natureza automatizada do sistema descrito permite que as transações de requisição/cotação ocorram em paralelo e em passo com o mercado real no qual os produtos subjacentes estão sendo ne- gociados através dos mecanismos disponíveis para todos os negociantes, desse modo não inibindo a participação de participantes no mercado. Embo- ra as modalidades descritas possam ser descritas com respeito a instrumen- tos de FX, será apreciado que estas modalidades não estão limitadas a isso e podem ser utilizadas com outros instrumentos, tais como futuros ou ins- trumentos de opções.

Em uma modalidade, a funcionalidade de RFQ Dirigida opera conforme se segue:

1. Um requisitante quer negociar uma quantia específica de um instrumento em particular através de uma RFQ Dirigida. Em uma modalida- de, a comunicação de RFQ Dirigida inclui tamanho, preço, lado (opcional), quantia de referência, produto (par de moedas), data de entrega e Tempo de Vida ("TTL"):

a. O tamanho específico pode ser de até a unidade inteira ($1) não estando restrito pelo "tamanho de contrato";

b. Uma RFQ Dirigida tem uma faixa de quantidade mínima e máxima, definida pelo par de moedas e pelo tipo de produto. O mínimo pode ser menor do que o tamanho do contrato (1 milhão);

c. O departamento de operações deve ser capaz de exibir a quantidade requisitada em termos de quantia de referência;

d. O negócio é de tudo ou nada entre duas contrapartes - cumprimentos parciais ou não possíveis (mas podem ser possíveis em mo- dalidades alternativas);

e. Em uma modalidade, qualquer participante de mercado pode submeter uma RFQ Dirigida;

f. Em uma modalidade, o requisitante pode especificar um lado de venda ou um lado de compra com o sistema ocultando esta informação dos criadores de mercado;

2. Uma RFQ Dirigida publicamente distribuída é difundida para todos ou, alternativamente, um subconjunto de participantes de mercado;

a. Esta RFQ Dirigida inicial tem uma funcionalidade de auto- cancelamento conhecida como Tempo de Vida (TTL), a qual é introduzida pelo requisitante;

b. O TTL é a parte da RFQ Dirigida pública e é enviado sobre dados de mercado;

c. Após o TTL inicial expirar, a RFQ Dirigida é cancelada;

i. Em uma modalidade, todas as Respostas de RFQ Dirigida as quais não foram aceitas são canceladas;

ii. Em uma modalidade, não mais Respostas de Entrega Imedi- ata são aceitas;

3. A comunidade de negociação responde à RFQ pública com uma Resposta de RFQ Dirigida (novo tipo de resposta);

a. Qualquer participante de mercado pode responder à RFQ Dirigida;

b. Cada cotação pode ter uma funcionalidade de autocancela- mento conhecida como Tempo de Vida ("TTL");

c. O TTL é introduzido pelo respondedor como parte da Res- posta de RFQ Dirigida; d. Respostas expiradas recebem mensagens de cancelamento;

e. Os respondedores também podem cancelar suas cotações em qualquer momento.

4. Um sistema de RFQ Dirigida gerencia todas as Respostas de RFQ Dirigida que ele recebe;

a. Estas respostas não são colocadas no livro de pedidos pú- blico, mas são enviadas para o requisitante original apenas;

b. Apenas o originador de RFQ Dirigida pode observar as Res- postas de RFQ Dirigida, juntamente com o TTL associado a cada resposta;

c. Cada cotação é anônima - contendo apenas o preço e o T- TL. Em uma modalidade, se a requisição é uma requisição de lado de com- pra ou de lado de venda pode ser omitido;

5. O originador de RFQ Dirigida pode selecionar a partir de dentre qualquer uma das cotações ativas neste livro de pedido privado;

a. Uma vez que uma cotação seja aceita, o sistema de RFQ Dirigida então automaticamente envia um pedido de Negociação Negociada Privadamente ("PNT")/em Bloco para a quantia de referência exata, em no- me das duas partes;

b. Todas as outras cotações são imediatamente canceladas. Cancelar mensagens para todos os outros respondentes;

c. A RFQ Dirigida em si é "cancelada" e não mais Respostas de RFQ Dirigida serão aceitas para ela;

6. Ambas as partes recebem relatórios de negócio de iLink & Compensação normais, sujeito às exigências de Consolidar Cumprimento abaixo;

a. o sistema opcionalmente atualizará o volume de mercado e outras estatísticas de dados de mercado, com base nas regulagens de con- figuração apropriadas.

O parâmetro de Time To Live (Tempo de Vida) ("TTL") pode ser especificado como um tempo absoluto de expiração, tal como um tempo re- gulado, ou um tempo relativo, por exemplo, uma duração medida a partir de alguma referência ou origem comum. Em uma modalidade, atrasos de transmissão na DRFQ ou em respostas a ela, são considerados na compu- tação da janela de TTL e determinando quando respostas são apropriada- mente recebidas ali. Em uma modalidade, a receptores de Sistema de Posi- cionamento Global ("GPS") ou alguma outra forma de referência de tempo universal, tal como uma referência de tempo de rede, por exemplo, um pro- tocolo de tempo de rede ("NTP"), em cada ponto de transmissão, pode ser usado para a provisão de uma sincronização de tempo acurada e uma de- tecção de atraso de transmissão. Alternativamente, o sistema pode ignorar atrasos de transmissão, baseando-se em um mecanismo de manutenção de tempo central como o árbitro final.

Em modalidades em que as RFQs Dirigidas são rateadas para apenas um subconjunto selecionado de criadores de mercado, a seleção pode ser com base em uma informação de perfil de negociador e/ou criador de mercado conhecida pelo sistema. Um roteamento seletivo desse modo minimiza o tráfego de cotação. Em um ambiente de roteamento de difusão e seletivo, incentivadores podem ser colocados em funcionamento para enco- rajar os criadores de mercado destinatários a responderem à RFQ Dirigida. Incentivos podem incluir descontos de honorário de negociação ou outros incentivos. Alternativamente, penalidades podem ser implementadas para penalização de criadores de mercado destinatários que falharem em res- ponder. Penalidades podem incluir multas, honorários de negociação au- mentados, restrições de negociação ou outras penalidades.

O mecanismo de RFQ Dirigida gerencia todo o tráfego de RFQ Dirigida através do sistema. Em uma modalidade, requisições esperadas são recebidas e um número de identificação único é gerado e associado à requi- sição, tal como em um registro de evento. Por exemplo, as mensagens/os pacotes de requisição tendo uma estrutura de dados em particular podem ser recebidos em um armazenamento em buffer, o qual mantém a requisição para processamento subseqüente. Um contador ou um outro gerador de número então gera um valor único o qual é concatenado ou associado de outra forma à requisição, tal como ao ser inserido na estrutura de dados. A RFQ Dirigida é então empurrada para o mercado, isto é, difundida para os criadores de mercado, para todos ou um subconjunto do mesmo, utilizando- se o número de identificação no lugar da informação de identificação de ori- ginador/requisitante para a identificação da RFQ Dirigida. Por exemplo, os vários dados da estrutura de dados de requisição podem ser copiados em uma nova mensagem e ter uma estrutura de dados similar incluindo o núme- ro de identificação único, mas omitindo a informação de identificação de ori- ginador/requisitante. O sistema central mantém um banco de dados de refe- rência cruzada/registro de eventos dos números de identificação de RFQ Dirigida e da identidade de requisitante associada, de modo a associar e rotear respostas apropriadamente, por exemplo, ao mesmo tempo em que uma mensagem de requisição anônima é gerada, os dados são armazena- dos no banco de dados de referência cruzada. Este banco de dados pode ser mantido em uma memória ou um outro dispositivo de armazenamento de dados.

Em uma modalidade, as Respostas de RFQ Dirigida podem ter um TTL associado, o qual se estende além da expiração da Requisição de RFQ Dirigida original. Isto é aceitável, e as Respostas de RFQ Dirigida as quais ainda não expiraram são plenamente executáveis em relação ao origi- nador de RFQ Dirigida.

Em uma modalidade, o sistema de RFQ Dirigida é gerenciado através de um processo de servidor central. No evento de uma situação "em andamento" (tal como uma Resposta de RFQ Dirigida ser cancelada ou expi- rar de outra forma enquanto a aceitação do originador de RFQ está "vindo"), qualquer que seja a requisição que for processada primeiramente pelo servi- dor central de RFQ Dirigida vencerá. Outros mecanismos de proteção de coerência de transação também podem ser providos.

Também podem ser providos mecanismos para se permitir que os requisitantes gerenciem requisições de RFQ Dirigida pendentes e os res- pondedores gerenciem respostas pendentes. Isto permitiria que um requisi- tante, por exemplo, acompanhasse quais RFQs Dirigidas estão ativas, quan- to tempo elas têm de vida, o status de resposta presente, etc. Para respon- dedores, os mecanismos permitem que eles saibam quais cotações acioná- veis ainda estão vivas e quanto tempo elas têm de vida. Isto permitiria, por exemplo, que um respondedor gerenciasse respostas para múltiplas RFQs Dirigidas para o mesmo produto, de modo a não expô-las em demasia. Por exemplo, uma interface de programa aplicativo ("API") pode ser provida, a qual permite que requisitantes e/ou respondentes acessem e/ou modifiquem os bancos de dados internos/tabelas mantidos pelo sistema de DRFQ para gerenciamento de requisições e respostas e seus TTLs associados, confor- me será descrito. A API pode ser uma interface de comando e de controle simples a qual recebe mensagens de comando/controle, executa o comando contido ali e envia de volta uma mensagem de resposta para o remetente com base nisso. Alternativamente, a API pode ser uma interface baseada na web provendo um aplicativo de cliente interativo rico em mídia seguro permi- tindo as tarefas de gerenciamento descritas.

A Figura 4 mostra um fluxo de mensagem comercial de exemplo para a funcionalidade de RFQ Dirigida das modalidades descritas. Será a- preciado que outros protocolos de envio de mensagem também podem ser usados para a obtenção da funcionalidade descrita. Ainda, será apreciado que a mídia pela qual o tráfego de envio de mensagem de RFQ Dirigida flui é dependente de implementação e pode incluir redes sem fio e com fio, re- des acessíveis privadas e publicamente, ou combinações das mesmas.

Em resposta a uma RFQ Dirigida, pode haver múltiplas respos- tas de várias partes interessadas. Estas respostas podem ser geradas de forma substancialmente simultânea ou por uma janela de tempo conforme as várias partes receberem e reagirem à RFQ Dirigida. Ainda, a transmissão da RFQ Dirigida bem como das respostas a isto pode estar sujeita a várias Ia- tências de rede entre e dentre o sistema descrito e as partes em transação. Ainda, cada resposta pode incluir parâmetros diferentes, incluindo um TTL diferente. Em uma modalidade, a RFQ Dirigida é combinada com a primeira resposta, a qual se adéqua aos parâmetros de requisição, isto é, às exigên- cias comerciais especificadas pelo originador de requisição e todas as outras respostas são rejeitadas. Esta combinação pode ser realizada automatica- mente pelo sistema ou, alternativamente, as respostas podem ser rateadas de volta para o originador que, então, seleciona a resposta que ele deseja negociar com base em critérios de sua escolha. Em uma modalidade, o ori- ginador pode selecionar uma resposta desejada com base pelo menos no preço, onde o sistema então automaticamente seleciona dentre as respostas disponíveis naquele preço através dos mecanismos descritos abaixo. Será apreciado que muitos mecanismos de equilíbrio/seleção diferentes podem ser utilizados variando de sistemas plenamente automatizados a sistemas plenamente manuais, e todos esses sistemas são contemplados aqui.

Em uma modalidade alternativa, o servidor central de RFQ Diri- gida pode manter um livro de pedidos privado em nome do originador, o qual é mantido, por exemplo, até o TTL da RFQ Dirigida expirar. Podem ser pro- vidos mecanismos os quais equilibram os parâmetros de cada resposta em relação aos parâmetros/às exigências da RFQ Dirigida, de modo a combina- rem a(s) resposta(s) ótima(s) com a requisição. Por exemplo, uma "janela de oportunidade" pode ser definida, na qual há permissão para as respostas se acumularem antes de uma avaliação daquelas respostas e combinação para a ótima. Esses fatores considerados na combinação de requisições com respostas podem incluir o preço, a quantidade, o TTL (da requisição e/ou da resposta), ou combinações dos mesmos. Uma vez que a "janela de oportu- nidade" se feche, todas as respostas subseqüentes são rejeitadas, mesmo se elas puderem ser melhores do que uma resposta aceita. Em uma modali- dade, a "janela de oportunidade" pode ser dinâmica e pode ser baseada na última resposta expirando a qual se adéqüe a um ou mais dos parâmetros de requisição. Alternativamente, a "janela de oportunidade" pode ser definida de forma estática ou pode ser definida por um parâmetro da RFQ Dirigida em si, em uma base de transação por transação, tal como pelo TTL da RFQ Dirigida. Tipicamente, o requisitante desejará um TTL longo nas respostas, para se permitir a melhor seleção de cotações, enquanto o respondedor que- rerá um TTL curto na resposta, para minimização da exposição/do risco. Uma vez que a janela se feche, o servidor central avalia as respostas rece- bidas e toma o melhor preço, o qual combina com as exigências de origina- dor (conforme declarado na RFQ Dirigida). O sistema então pode executar um negócio em bloco em nome de ambas as partes para se completar a transação. Em uma modalidade, múltiplas respostas as quais ligam o melhor preço ou de outra forma se adéquam às exigências podem estar sujeitas a uma seleção por Primeiro a Entrar, Primeiro a Sair, ou outro mecanismo de arbitragem, tal como round-robin. Uma vez que a transação esteja comple- tada, notificações de cumprimento são enviadas de volta para ambas as par- tes, etc.

Dadas as latências de transmissão citadas acima, uma dada resposta pode chegar ao sistema depois de uma resposta gerada mais tarde ou perder o TTL de uma dada RFQ Dirigida, e pode, portanto, perder uma oportunidade de equilíbrio, dependendo das latências de transmissão no sistema. Em uma modalidade, uma lógica é incluída para avaliação de res- postas, com base no tempo em que elas são geradas e no tempo em que elas são realmente recebidas, para mitigação das discrepâncias "em anda- mento" e manter de outra forma a coerência entre as RFQs Dirigidas e as respostas a isto, garantindo uma oportunidade igual aos participantes de mercado e minimizando uma retransmissão de requisições e respostas.

Em uma modalidade, as transações de RFQ Dirigida ocorrem fora do livro de pedidos central normal. Em uma modalidade alternativa, uma RFQ Dirigida em particular pode ser permitida para combinar em relação a um livro de pedidos central em que um pedido adequado está presente.

Em uma modalidade, respostas condicionais a uma RFQ Dirigi- da podem ser suportadas, permitindo que um respondedor anexe condições a sua resposta/cotação acionável. Uma combinação dos fatores de resposta com requisição em qualquer que sejam as condições especificadas é encon- trada, além de outros fatores.

Em uma modalidade alternativa, uma cotação indicativa também é suportada, permitindo que os criadores de mercado publiquem cotações indicativas para o mercado e convidem RFQs Dirigidas de partes interessa- das, antes da emissão de cotações acionáveis.

A Figura 6 descreve um diagrama de blocos de um sistema de exemplo 600 para negociação de instrumentos de FX de QTC tendo um ser- vidor de requisição para cotação 118 de acordo com as modalidades descri- tas. Será apreciado que o servidor de DRFQ 118 pode ser integrado com uma bolsa 108 ou separado dela. Ainda, o servidor de DRFQ 118 pode ser implementado em hardware, em software ou em uma combinação dos mes- mos, e ainda pode ser implementado como um ou mais dispositivos discre- tos e/ou programas de software interconectados através de uma rede com fio e/ou sem fio. O sistema 600 inclui o servidor de DRFQ 118 acoplado a uma bolsa 108, tal como a Chicago Mercantile Exchange descrita acima. O servidor de DRFQ 118 ainda é acoplado a uma pluralidade de participantes de mercado, tais como negociadores 104 e criadores de mercado 106, tal como através de conexões de rede, com fio ou sem fio, entre o servidor de DRFQ 118 e terminais e/ou um software de aplicativo de terminal usado pe- los participantes de mercado 104, 106, para participarem no mercado. Será apreciado que as interconexões entre o servidor de DRFQ 118 e os partici- pantes de mercado 104, 106 podem ser implementadas através da bolsa 108. Em uma modalidade, os participantes de mercado 104, 106 executam uma interface de aplicativo de cliente a qual se comunica com o servidor de DRFQ 118 usando um protocolo de comunicações definido para a imple- mentação da funcionalidade descrita. Esta interface de aplicativo de cliente pode ser integrada com um outro software de participante de mercado usado para negociação na bolsa 108 ou pode ser separada dali, tal como uma in- terface baseada na web. O protocolo de comunicações pode incluir um pro- tocolo proprietário, um protocolo não-proprietário, por exemplo, baseado em TCP/IP, ou combinações dos mesmos, e pode caracterizar protocolos de segurança para proteção das comunicações e detecção/correção de erro e protocolos de qualidade de serviço ("QOS") para garantia de comunicações confiáveis e expedientes. Será apreciado que a funcionalidade descrita pode ser implementada como um hardware e/ou lógica de programa de computa- dor/software no servidor 118, nos terminais nos participantes de mercado 104, 106, na bolsa 108 ou através de uma combinação dos mesmos.

Como um exemplo operacional, em uma modalidade, uma pri- meira entidade, tal como um negociador 104, envia uma DRFQ para o servi- dor de DRFQ 118 (rotulada A). Por exemplo, o negociador 104 utiliza sua interface de aplicativo para gerar uma mensagem de DRFQ incluindo os pa- râmetros especificados de acordo com uma estrutura de dados definida por sistema, e transmitir uma mensagem de DRFQ para o servidor de DRFQ 118 utilizando o protocolo de comunicações definido por sistema, o qual po- de incluir a segurança da mensagem de DRFQ, tal como pela encriptação dela. A DRFQ A identifica o primeiro negociador 104, especifica um instru- mento, tal como um instrumento de FX em particular, que o primeiro negoci- ador 104 está interessado em negociar, o horário e a data em que a requisi- ção foi gerada e/ou transmitida, e, em uma modalidade, especifica um tempo de vida para a requisição. A DRFQ A ainda pode especificar se o primeiro negociador 104 está interessado em comprar ou vender o instrumento espe- cificado. Um segundo negociador 104 também envia uma DRFQ para o ser- vidor de DRFQ 118 (rotulada B), identificando o segundo negociador 104 e especificando um instrumento, um tempo de vida opcional e uma indicação opcional de compra ou venda. Será apreciado que as DRFQs AeB ainda podem especificar uma outra informação necessária para a realização da funcionalidade descrita e que essa informação é dependente de implemen- tação. Mediante o recebimento das DRFQs A e Β, o servidor de DRFQ 118 pode enviar um reconhecimento (não descrito) de volta para os primeiro e segundo negociadores 104 para confirmação do recebimento do DRFQs A e B.

Mediante o recebimento das DRFQs A e Β, o servidor de DRFQ 118, conforme será descrito em maiores detalhes abaixo, registra o horário/a data de recebimento, torna anônimas as DRFQs AeB, determina uma ou mais outras entidades, tais como outros participantes de mercado 104, 106, para os quais transmitir as DRFQs AeB tornadas anônimas, e as transmite para eles. Em particular, o servidor de DRFQ 118 remove a identidade do negociador requisitante 104 da DRFQ A, B, enquanto mantém a capacidade de correlação de quaisquer respostas de volta para o negociador requisitan- te 104. Por exemplo, o servidor de DRFQ 118 pode gerar um código de iden- tificação único para a DRFQ A, B e registrar aquele código de identificação em um registro de eventos/banco de dados de referência cruzada associado à identidade do negociador requisitante 104. O código de identificação então é substituído pela DRFQ A, B para a identidade do negociador requisitante 104, de modo que o negociador requisitante 104 possa ser identificado ape- nas a partir da DRFQ A, B usando-se a referência cruzada mantida pelo ser- vidor de DRFQ 118.

Uma vez tornado anônimo, o servidor de DRFQ 118 então identi- fica um ou mais outros participantes de mercado, tais como os criadores de mercado 106, que estariam interessados na cotação para o instrumento es- pecificado na DRFQ A, B. Em uma modalidade, a DRFQ A, B tornada anô- nima pode ser difundida para todos os participantes de mercado 104, 106 ou para os criadores de mercado 106. Em uma modalidade alternativa, o servi- dor de DRFQ 118 pode manter perfis de interesse para cada um dos partici- pantes de mercado 104, 106 os quais especificam que aqueles participantes 104, 106 estão interessados em negociar. Estes perfis de interesse podem ser mantidos pelos participantes de mercado 104, 106 em si, tal como em tempo real. Com base nestes perfis de interesse, o servidor de DRFQ 118 seleciona um ou mais participantes de mercado 104, 106 a receberem a DRFQ A, B tornada anônima. No exemplo da Figura 6, a DRFQ A tornada anônima pode ser enviada para os primeiro e segundo criadores de mercado 106 (rotulados C e D), enquanto a DRFQ B pode ser enviada apenas para o terceiro molde 106 (rotulado E). Em uma modalidade, se a DRFQ A, B espe- cificar a intenção de comprar ou vender do negociador requisitante 104, este indivíduo poderá ser removido antes da transmissão da DRFQ A, B tornada anônima para os participantes de mercado selecionados.

O servidor de DRFQ 118 ainda pode notar o tempo de vida ("T- TL") especificado para cada DRFQ A, B. Conforme foi discutido acima, o TTL determina por quanto tempo a requisição em particular será mantida "viva", isto é, qual é a janela de tempo pela qual as respostas à requisição serão consideradas. O TTL pode ser especificado como uma expiração ab- soluta, por exemplo, 10:05 p.m., 18 de abril de 2006, ou pode ser especifica- da como uma duração medida a partir de uma origem em particular, por e- xemplo, 1 hora a partir do horário do tempo de transmissão da requisição (especificado na requisição) ou 1 hora a partir do recebimento da requisição pelo servidor de DRFQ 118. Como uma alternativa para a especificação do TTL na DRFQ em si, o TTL pode ser automaticamente especificado pelo servidor de DRFQ 118, tal como TTL padrão, o qual pode ser usado, por exemplo, quando a DRFQ falhar em especificar o TTL ou completamente no lugar de uma DRFQ de TTL especificado. Conforme será descrito em maio- res detalhes abaixo, uma vez que o TTL decorra ou expire de outra forma, a DRFQ associada expira, isto é, a janela de oportunidade para recebimento de cotações aciònáveis em resposta à requisição é fechada, em uma moda- lidade, um processo de servidor monitora todos os TTLs das requisições e respostas pendentes e determina quando elas expiram. Por exemplo, cada TTL pode ser usada para a regulagem de um contador mantido por uma es- trutura de dados a qual é diminuída pelo processo de servidor em um inter- valo definido. Quando o valor de contador é determinado para ser zero, o processo de servidor gera um alerta ou alarme para indicar que o TTL em particular expirou. Este alerta/alarme pode disparar outros processos de ser- vidor os quais implementam a funcionalidade descrita. Em uma modalidade, a expiração do TTL pode fazer com que o servidor 118 transmita notifica- ções de cancelamento para todos os participantes de mercado para os quais a DRFQ associada foi enviada, ou, alternativamente, para aqueles partici- pantes de mercado 104, 106 os quais ainda não responderam com uma co- tação acionável em resposta a isto. As cotações aciònáveis recebidas antes da expiração do TTL, mas não aceitas antes de uma expiração podem ser canceladas ou aceitas, conforme descrito abaixo. Quando a cotação acioná- vel é cancelada, uma mensagem de cancelamento pode ser enviada de vol- ta para o participante de mercado de origem 104, 106. As cotações aciòná- veis recebidas após uma expiração do TTL podem ser rejeitadas ou permiti- das, conforme será descrito abaixo. As respostas portando cotações acioná- veis as quais estão em trânsito no momento em que o TTL expira, por e- xemplo, "em andamento", podem ser permitidas ou outros algoritmos podem ser empregados para se garantir uma operação razoável, a qual leva em conta tais situações, por exemplo, cotações acionáveis tendo sido gera- das/transmitidas antes da expiração do TTL podem ser aceitas. Quando o tempo de transmissão pode ser utilizado como a base de aceitação de cota- ções acionáveis, mecanismos podem ser implementados para se garantir uma certeza que não existem mais transmissões "em andamento", tal como um tempo de corte absoluto.

Uma vez que os participantes de mercado em particular 104, 106 recebam as DRFQs tornadas anônimas C, D, E, eles as avaliarão para determinarem se querem ou não responder com uma cotação acionável. Se assim for, os participantes de mercado 104, 106 enviarão uma resposta de volta para o servidor de DRFQ 118. A resposta (rotulada F, G, H) pode inclu- ir uma cotação acionável e identificar a DRFQ à qual a cotação acionável é em resposta, tal como ao especificar o código de identificação único da DRFQ em particular C, D, Ε, o que permitirá que o servidor de DRFQ 118 associe a resposta ao originador de DRFQ. Alternativamente, um participan- te de mercado 104, 106 pode ignorar a DRFQ, se não tiver interesse em responder para dizer que ele não estará provendo uma cotação acionável, ao invés de simplesmente ignorar a DRFQ, tal como prover uma informação de volta para o servidor de DRFQ 118 que a DRFQ foi pelo menos recebida.

A resposta F, G, H pode especificar ainda um TTL para a cota- ção acionável, similar ao TTL para a DRFQ, especificando por quanto tempo a cotação permanecerá válida. O TTL de resposta serve para mitigação da exposição do participante de mercado 104, 106 pela limitação do intervalo de vida pelo qual a cotação acionável pode ser aceita pelo originador de DRFQ. Como com o TTL de requisição, o TTL de resposta pode ser especi- ficado na resposta ou pode ser especificado automaticamente pelo servidor 118, tal como por um valor padrão em situações em que nenhum TTL é es- pecificado. O TTL pode ser especificado como um tempo absoluto ou espe- cificado relativamente tal como por uma duração específica medida a partir da origem, ou o TTL pode ser especificado com base em um evento, tal co- mo com base na expiração do TTL de requisição.

Se o TTL da resposta expirar antes da aceitação da cotação a- cionável associada, a cotação acionável poderá ser cancelada. Em uma si- tuação como essa, uma mensagem de cancelamento pode ser transmitida de volta para o originador de resposta para informá-lo que sua cotação não foi aceita antes da expiração do TTL. Caso a resposta seja recebida após seu TTL ter expirado, a resposta poderá ser rejeitada com uma mensagem adequada enviada de volta para o originador. Em uma modalidade, o TTL de requisição pode ser ignorado desde que haja uma resposta cujo TTL ainda não expirou.

Em uma modalidade, um participante de mercado 104, 106 pode cancelar explicitamente ou rescindir uma cotação acionável previamente submetida, desde que a requisição de cancelamento seja recebida antes da aceitação daquela cotação. Mecanismos ainda podem ser providos de modo a se considerar um cancelamento o qual foi enviado antes, mas recebido subseqüentemente, para aceitação da cotação acionável. Por exemplo, o tempo de transmissão e recebimento pode ser analisado para se determinar quando o cancelamento foi enviado e uma aceitação da cotação pode ser cancelada, se a cotação acionável tiver sido apropriadamente cancelada.

Uma vez que cotações acionáveis sejam recebidas pelo servidor de DRFQ 118, elas devem ser processadas em relação às DRFQs associa- das para se determinar se elas são aceitáveis ou não para o requisitante de DRFQ. Em uma modalidade, cada resposta/cotação acionável recebida pelo servidor de DRFQ 118 está associada ao originador de DRFQ, tal como por uma referência cruzada ao identificador de DRFQ e pela identificação da entidade de origem. A cotação acionável então é encaminhada para o origi- nador de DRFQ para revisão (rotulado I, J). Conforme descrito, as respos- tas/cotações acionáveis são enviadas apenas para o originador de DRFQ, ao invés de para o mercado inteiro. Isto minimiza a exposição do originador da cotação acionável ao restringir quem no mercado pode vê-lo. Em uma modalidade, as cotações acionáveis são tornadas anônimas antes do envio do originador de DRFQ. A cotação acionável é encaminhada juntamente com o TTL associado, de modo que o originador de DRFQ saiba quanto tempo ele tem para tomar uma decisão. Se o originador de DRFQ desejar aceitar a cotação, ele poderá retornar uma mensagem de aceitação de volta para o servidor de DRFQ 118. Alternativamente, o servidor de DRFQ 118 pode combinar automaticamente cotações acionáveis aceitáveis e aceitar aquela cotação com base nos aplicativos especificados no DRFQ em si.

Nesta modalidade, enquanto as cotações acionáveis podem ser encaminha- das de volta para o originador de DRFQ para fins de informação, a aceitação daquelas cotações é automaticamente manipulada. Ainda em uma outra modalidade alternativa, o originador de DRFQ pode especificar se ele quer rever especificamente e aceitar a cotação ou confiar no servidor de DRFQ 118 para fazê-lo automaticamente. Quando o originador de DRFQ pode res- ponder com uma aceitação a uma cotação acionável, mecanismos podem ser implementados para se lidar com questões "em andamento", tal como quando uma aceitação é enviada antes de uma expiração do TTL de cota- ção acionável, mas recebida após uma expiração da mesma ou quando a aceitação é enviada antes do recebimento de um cancelamento da cotação acionável, mas recebida após o cancelamento da mesma. Esses mecanis- mos asseguram um mercado razoável, o qual operará de uma maneira defi- nida/certa, não ambígua de acordo com as expectativas dos participantes de mercado.

Em modalidades em que o servidor de DRFQ 118 pode automa- ticamente aceitar cotações acionáveis, essa aceitação pode ser baseada em se a cotação acionável é a primeiramente recebida de múltiplas cotações acionáveis recebidas, Quando a primeira cotação acionável não satisfaz completamente a DRFQ, o servidor 118 pode permitir cumprimentos parci- ais, aceitando as cotações acionáveis na ordem em que elas são recebidas, até que a DRFQ inteira seja satisfeita. De novo, mecanismos podem ser im- plantados para se garantir que uma cotação acionável enviada antes, mas recebida depois de uma outra cotação seja aceita primeiramente. Alternati- vamente, o servidor de DRFQ 118 pode acumular várias cotações acioná- veis por uma janela de tempo. Mediante o fechamento desta janela de opor- tunidade, o servidor 118 pode então avaliar e aceitar uma ou mais cotações acionáveis as quais mais bem se adéqüem aos parâmetros da DRFQ. Nesta modalidade, a DRFQ ainda pode especificar critérios para aceitação com o servidor 118 determinando o grau até o qual os critérios são satisfeitos pelas cotações acionáveis recebidas. Estes critérios podem incluir tempo de vida de requisição, quantidade, preço máximo, preço mínimo, pedido de compra, pedido de venda, ou combinações dos mesmos. Quando mais de uma cota- ção acionável se adéquam aos critérios, o servidor 118 pode alocar aceita- ção dentre uma ou mais daquelas cotações. O servidor 118 ainda pode noti- ficar cada participante de mercado quanto a se sua cotação foi aceita ou não.

Uma vez que uma ou mais cotações acionáveis sejam aceitas, em resposta à DRFQ, a cotação acionável é enviada para uma bolsa, tal como a CME, para ser equilibrada e completada.

Conforme os participantes de mercado 104, 106 podem ter múl- tiplas DRFQs concorrentes e cotações acionáveis pendentes em qualquer dado tempo, são providas funções de gerenciamento para se permitir que os participantes de mercado 104, 106 acompanhem DRFQs penden- tes/concorrentes e/ou cotações acionáveis e cancelem ou modifiquem de outra forma aquelas DRFQs pendentes e/ou cotações acionáveis. Por e- xemplo, o servidor 118 pode prover uma informação em tempo real mos- trando o status pendente de uma DRFQ e todas as cotações acionáveis re- cebidas em resposta a isto, mostrando os respectivos TTLs e uma compara- ção/avaliação em tempo real das respostas, conforme medido em relação a cada outra e à DRFQ. Ainda, ao originador da DRFQ ou cotação acionável pode ser permitido estender o TTL, se assim desejar.

Conforme foi discutido, questões de coerência existem quando requisições e respostas a isto são caracterizadas por um período de expira- ção, tal como um TTL, conforme descrito. Atrasos de transmissão ou outro processamento podem causar questões de "em andamento" quando mensa- gens enviadas antes de uma expiração chegarem depois, ou mensagens, tais como mensagens de aceitação e de cancelamento, se cruzarem em trânsito. Os mecanismos para proteção de coerência no mercado e manu- tenção de expectativas dentre os participantes 104, 106 de um mercado de- finido, certo, consistente e não ambíguo podem ser estabelecidos para mi- nimização ou eliminação de problemas de coerência. Por exemplo, um pro- tocolo de reconhecimento pode ser implementado requerendo um recebi- mento de uma mensagem a ser reconhecida na janela de tempo definida.

Quando um remetente falha em receber o reconhecimento apropriado, ele assumirá uma falha de transmissão e reenviará sua mensagem. Ainda, re- dundâncias também podem ser adicionadas para se garantir um processa- mento na ordem apropriada, ou compensarem de outra forma um recebi- mento fora de ordem. Toda esta informação ainda pode ser registrada para a provisão de um acompanhamento de automaticamente permitindo uma ava- liação post-mortem de uma operação inesperada, de falhas, etc.

O servidor de DRFQ 118 em conjunto com a bolsa 108 então elimina a necessidade de relações bilaterais entre os participantes de mer- cado e amortece o risco de perda com respeito aos instrumentos sendo ne- gociados dentre os participantes de mercado.

A Figura 7 descreve um diagrama de blocos de uma modalidade de um servidor de requisição para cotação dirigida ("DRFQ") 118 para uso com o sistema da Figura 6. O servidor de DRFQ 118 inclui um receptor de requisição 202 acoplado a uma rede (não descrita) e operativo para receber uma requisição para cotação de um participante de mercado, conforme des- crito acima, um transmissor de requisição 214 acoplado ao receptor de re- quisição 202 e a rede operativa para transmitir a requisição para cotação para pelo menos um subconjunto da pluralidade de participantes de merca- do, sem a identificação do originador de requisição, um receptor de resposta 216 acoplado à rede e operativo para receber pelo menos uma resposta a partir de pelo menos um dos participantes de mercado identificando a requi- sição para cotação e incluindo uma cotação acionável em resposta a isto, e um transmissor de resposta 222 acoplado ao receptor de resposta 216 e operativo para transmitir pelo menos uma resposta exclusivamente para o originador de requisição. Em uma modalidade, o transmissor de resposta 222 ainda pode tornar anônimas as respostas/cotações acionáveis, antes de enviá-las para o originador de requisição. Em uma modalidade alternativa, em que o DRFQ especifica uma intenção de comprar ou vender, o transmis- sor de requisição 214 ainda pode transmitir a requisição sem a identificação da intenção. Em uma modalidade, o receptor de resposta 216 ainda é opera- tivo para receber um cancelamento da cotação acionável e evitar uma acei- tação da cotação acionável em resposta a isto, quando o cancelamento for recebido antes de uma aceitação.

Em uma modalidade, o servidor de DRFQ 118 inclui um ou mais processadores (não descritos), uma ou mais memórias (não descritas) e/ou outros meios de armazenamento acoplados a um ou mais processadores em uma interface dé rede (não descrita) acoplada a um ou mais processadores e à rede e operativa para facilitação das comunicações entre eles. Cada um dentre o receptor de requisição 202, o transmissor de requisição 214, o re- ceptor de resposta 216 e o transmissor de resposta 222 pode ser implemen- tado em hardware, software/lógica ou uma combinação dos mesmos. Por exemplo, o servidor 118 ainda pode incluir uma primeira lógica armazenada na memória e executável pelo(s) processador(es) para o recebimento de uma primeira comunicação compreendendo uma requisição para cotação através da rede a partir de um dos participantes de mercado, conforme des- crito acima, uma segunda lógica acoplada à primeira lógica, armazenada na memória e executável pelo(s) processador(es) para a transmissão de uma segunda comunicação compreendendo a requisição para cotação através da rede para pelo menos um subconjunto dos outros participantes de mercado, sem a identificação do originador de requisição, uma terceira lógica armaze- nada na memória e executável pelo(s) processador(es) para o recebimento de pelo menos uma terceira comunicação compreendendo uma resposta através da rede a partir de pelo menos um outro participante de mercado, a resposta identificando a requisição para cotação e incluindo uma cotação acionável em resposta a isto, e uma quarta lógica acoplada à terceira lógica, armazenada na memória e executável pelo(s) processador(es) para trans- missão através da rede de uma quarta comunicação que compreende a res- posta exclusivamente para o originador de requisição. Conforme foi descrito acima, o servidor 118 pode ser implementado em hardware, software ou uma combinação dos mesmos, ainda, embora vários componentes sejam discutidos em termos de suas funções discretas, será adicionalmente apre- ciado que uma ou mais das funções descritas podem ser implementadas em um componente único ou qualquer função pode ser realizada por múltiplos componentes discretos, ou combinações dos mesmos, e ser dependentes de implementação.

O servidor 118 ainda inclui, como uma lógica armazenada na memória e executável pelo(s) processador(es), ou de outra forma como um hardware/software ou uma combinação dos mesmos, um seletor de entidade 212 acoplado ao receptor de requisição 202 e ao transmissor de requisição 214 e operativo para a identificação de um ou mais dos outros participantes de mercado, em resposta à requisição para cotação os quais podem estar interessados na provisão de uma cotação. Em uma modalidade, o seletor de entidade pode manter um perfil de interesse para cada um dos participantes de mercado, onde o seletor de entidade identifica para quais participantes de mercado enviar a DRFQ, com base no perfil de interesse do participante de mercado associado.

Conforme foi descrito, o servidor de DRFQ 118 torna anônimas as DRFQs, antes de enviá-las para os participantes de mercado interessa- dos. Em uma modalidade, o servidor 118 inclui um registro de identificação de requisição 210 acoplado ao receptor de requisição 202 e ao transmissor de resposta 222, onde o receptor de requisição 202 ainda é operativo para armazenar uma identificação do originador de requisição em relação à requi- sição para cotação no registro de identificação de requisição 210, e o trans- missor de resposta 222 ainda é operativo para associar as respostas recebi- das ao originador de requisição com base na identificação armazenada no registro de identificação de requisição 210 e transmitir a resposta com base nisso. O registro de identificação de requisição 210 pode ser implementado na memória ou em um outro meio de armazenamento e pode incluir um ban- co de dados, uma tabela ou outra(s) estrutura(s) de dados adequados para a implementação da funcionalidade descrita. Em uma modalidade, o servidor de DRFQ 118 pode incluir, como uma lógica armazenada na memória e e- xecutável pelo(s) processador(es), ou de outra forma como um hardwa- re/software ou uma combinação dos mesmos um identificador de requisição 208 acoplado ao receptor de requisição 202, ao transmissor de requisição 214 e ao transmissor de resposta 222, onde o identificador de requisição 208 é operativo para a geração de um código de identificação único que não tem uma relação externamente discernível com o originador de requisição e criar uma relação entre o código de identificação único, a requisição para cotação e o originador de requisição, onde o transmissor de requisição 214 ainda é operativo para transmitir o código de identificação único juntamente com a requisição para cotação, e ainda onde as respostas/cotações acionáveis re- cebidas em resposta a isto incluem o código de identificação único, o trans- missor de resposta 222 ainda sendo operativo para transmitir as respostas para o originador de requisição, com base no código de identificação único a partir da resposta e na relação provida pelo identificador de requisição 208. Em uma modalidade, o identificador de requisição 208 pode incluir um gera- dor de número, tal como um gerador de número randômico, e ainda pode ser acoplado ao registro de identificação 210 para o armazenamento dos códi- gos de identificação únicos em relação às identidades dos originadores de DRFQ associados. Alternativamente, o identificador de requisição 208 pode gerar ou atribuir códigos de identificação únicos com base em eventos tais como horário/data do recebimento da requisição, com base em uma codifi- cação de um ou mais dos parâmetros da requisição, tal como uma encripta- ção ou prova dos mesmos, ou combinações dos mesmos.

Conforme foi descrito acima, as DRFQs e/ou respostas a isto podem especificar um TTL. O servidor 118 inclui, como uma lógica armaze- nada na memória e executável pelo(s) processador(es), ou de outra forma como um hardware/software ou uma combinação dos mesmos, um Proces- sador de Expiração de Resposta 220 para processamento dos TTLs das re- quisições e respostas, conforme foi descrito acima. Os processadores 206, 220 registram os TTLs das requisições e respostas e monitoram o TTL para determinarem quando eles expiram. Em uma modalidade, os processadores 206, 220 podem manter requisições, respostas e seus TTLs associados em uma tabela ou uma outra estrutura de dados adequada, onde a estrutura de dados ainda inclui um valor decrementado, o qual é inicializado como o valor de TTL e subseqüentemente decrementado em intervalos regulares pelos processadores 206, 220, até eles atingirem um valor zero ou negativo signi- ficando a expiração dos mesmos. Mediante a expiração, os processadores 206, 220 realizam as ações descritas, tal como cancelamento das requisi- ções e/ou respostas e/ou envio de mensagens de cancelamento/expiração para as entidades apropriadas. Em modalidades caracterizando um TTL pa- drão, para qualquer uma das requisições ou respostas, o processador apro- priado 206, 220 pode especificar o TTL padrão a ser usado. As operações do processador de expiração de requisição e resposta 206, 220 ainda po- dem implementar os mecanismos de coerência descritos acima. Por exem- plo, em uma modalidade, onde as respostas ainda são caracterizadas por horário de transmissão e um horário de recepção diferente do horário de transmissão, o processador de expiração de requisição e/ou resposta 206, 220 ainda pode incluir um processador de sincronização (não descrito) aco- plado ao receptor de resposta 216 e/ou ao receptor de requisição 202 para compensação da diferença entre o horário de transmissão e o horário de recepção.

O servidor 118 ainda inclui, como uma lógica armazenada na memória e executável pelo(s) processador(es), ou de outra forma como hardware/software ou uma combinação dos mesmos, um processador de equilíbrio 226 acoplado ao receptor de requisição 202 e ao receptor de res- posta 216 e operativo para determinar uma aceitação das cotações acioná- veis, as quais são recebidas em resposta às DRFQs enviada para os partici- pantes de mercado. Conforme descrito, o processador de equilíbrio 226 po- de aceitar cotações com base em instruções do originador de DRFQ, pode aceitar cotações automaticamente pela comparação da DRFQ em relação às cotações acionáveis recebidas ou com base em algum outro critério, tal co- mo em uma base de primeira recebida ou na melhor combinação, ou uma combinação dos mesmos. Em uma modalidade em que o originador de DRFQ pode avaliar e aceitar uma ou mais das cotações acionáveis, um re- ceptor de aceitação 224 é provido como uma lógica armazenada na memó- ria e executável pelo(s) processador(es), ou de outra forma como um hard- ware/software ou uma combinação dos mesmos, o que é acoplado ao pro- cessador de equilíbrio 226 e operativo para receber a aceitação do origina- dor de DRFQ. O receptor de aceitação 224 também pode ser acoplado ao processador de expiração de resposta 220 para se determinar se a aceita- ção foi recebida antes da expiração do TTL da cotação acionável. Em uma modalidade, se a aceitação for recebida tarde demais, a aceitação poderá ser rejeitada e uma mensagem apropriada enviada de volta para o originador de DRFQ.

Em modalidades as quais provêem uma aceitação automática das cotações acionáveis, o servidor 118 pode permitir que a DRFQ ainda especifique pelo menos um critério para aceitação de uma cotação acionável em resposta a isto. O processador de equilíbrio 226 então determinaria o grau até o qual os critérios são satisfeitos pela(s) cotação acionável (cota- ções acionáveis) recébida(s). Os critérios podem incluir tempo de vida de requisição, quantidade, preço máximo, preço mínimo, pedido de compra, pedido de venda, ou combinações dos mesmos. Quando múltiplas cotações acionáveis são recebidas, o processador de equilíbrio 226 pode determinar qual daquelas cotações acionáveis mais bem satisfaz à DRFQ. Em uma mo- dalidade, o processador de equilíbrio 226 pode alocar a DRFQ dentre múlti- plas cotações acionáveis as quais mais bem combinam com os critérios es- pecificados.

O processador de equilíbrio 226 ainda pode enviar notificações para aqueles participantes de mercado 104, 106 cujas cotações não foram aceitas informando-os disto.

O servidor de DRFQ 118 ainda inclui, como uma lógica armaze- nada na memória e executável pelo(s) processador(es), ou de outra forma como um hardware/software ou uma combinação dos mesmos, um trans- missor de bolsa 228 acoplado ao processador de equilíbrio 226 e operativo para transmitir a requisição para cotação e a(s) cotação acionável (cotações acionáveis) para uma bolsa mediante aceitação, conforme descrito. Além disso, em uma modalidade, o servidor de DRFQ 118 ainda inclui como uma lógica armazenada na memória e executável pelo(s) pro- cessadores) ou de outra forma como um hardware/software ou uma combi- nação dos mesmos um gerenciador de requisição 204 e/ou um gerenciador de resposta 218. O gerenciador de requisição 204 permite que originadores de DRFQ gerenciem múltiplas DRFQs pendentes, por exemplo, para se permitir que eles cancelem uma DRFQ pendente ou modifiquem seu TTL, ou outro parâmetro, tais como os critérios de aceitação os quais definem uma cotação acionável aceitável. O gerenciador de requisição 204 e/ou o geren- ciador de resposta 218 podem ser implementados como uma API, tal como uma API baseada na web, para a qual os participantes de mercado usam um aplicativo de cliente, tal como um navegador da web, para interagirem.

O servidor de DRFQ 118 ainda pode incluir, como uma lógica armazenada na memória e executável pelo(s) processador(es) ou de outra forma como um hardware/software ou uma combinação dos mesmos um gerenciador de risco 230, o qual monitora todas as DRFQs pendentes e co- tações acionáveis pendentes, juntamente com as identidades dos participan- tes associados. O gerenciador de risco 230 pode computar em um tempo real ou uma outra base as várias exposições/riscos de perda de cada parti- cipante, computar exigências de margem, identificar anomalias de negocia- ção ou irregularidades, tal como uma fraude ou uma atividade ilegal, ou combinações das mesmas. O gerenciador de risco 230 pode reportar estes dados para os participantes de mercado e/ou para a bolsa ou o operador do servidor de DRFQ 118.

A Figura 8 descreve um diagrama de blocos de um sistema de exemplo 800 para negociação de instrumentos de FX de OTC tendo um sis- tema de requisição para cotação dirigida de acordo com uma modalidade alternativa. Cada caixa descrita na Figura 8 representa um computador es- pecífico, ou um conjunto de computadores realizando uma função única, conforme descrito. O sistema 800 opera como se segue:

1. Um Requisitante de DRFQ 802 envia uma nova requisição para cotação para o Servidor de DRFQ 808. Isto poderia ser uma RFQ para tamanho (quantidade), preço ou ambos.

a. O Servidor de DRFQ 808 aceita a Requisição de DRFQ do Requisitante de DRFQ 802 e responde com uma mensagem de reconheci- mento (não descrita) diretamente de volta para o Requisitante de DRFQ 802.

b. Se o Requisitante de DRFQ estivesse mal informado ou se ele de outra forma fosse inválido (devido a uma definição ou a um sincro- nismo de instrumento/mercado), o Servidor de DRFQ 808 poderia rejeitar a Requisição com uma mensagem de rejeição enviada de volta para o Requi- sitante (não-descrito).

2. O Servidor de DRFQ 808 publica publicamente uma DRFQ anônima, todos os participantes de mercado recebem esta mensagem atra- vés das interfaces de Dados de Mercado de CME. A DRFQ tem um identifi- cador único, o qual o Servidor de DRFQ 808 pode usar para mapeamento dele de volta para a Requisição de DRFQ original.

3. Vários participantes de mercado 804, 806 podem responder com Respostas de DRFQ acionáveis. Esta Resposta de DRFQ cumprirá a Requisição de DRFQ e usará o identificador único como uma referência.

4. O Servidor de DRFQ 808 através de uma consulta ao Requisitante de DRFQ 802 ou via algum meio de registro em livro normali- zado/algorítmico, determina a melhor Resposta de DRFQ e equilibra os dois lados da transação.

a. OPCIONAL: 4 segmentos e mensagem abaixo mostram o Servidor de DRFQ 808 enviando a consulta para o Requisitante de DRFQ 802. Isto poderia ser a melhor Resposta de DRFQ combinando com o Re- quisitante de DRFQ original 802 ou poderia ser o conjunto inteiro de Respos- tas de DRFQ. Em qualquer caso, são dados anônimos. O Requisitante de DRFQ 802 então pode escolher qual Resposta de DRFQ usar para a transação.

b. OPCIONAL: Os critérios de seleção algorítmicos poderiam ser melhor preço, melhor tamanho, melhor tempo, ou alguma regulagem ali.

Ele também poderia ter um recurso de Criador de mercado o qual permitiria a certos Respondedores de DRFQ 804, 806 prioridade em relação a outros. 5. O Servidor de DRFQ 808 enviará um reconhecimento para os Respondedores de DRFQ 804, 806, deixando cada um conhecer o status de sua Resposta de DRFQ. Ele poderia ser cancelado, no caso em que não se adequasse aos critérios de seleção.

6. O Servidor de DRFQ 808 tendo ambos os lados da transa- ção à mão criará um negócio em Bloco e o enviará para o Agente de Nego- ciação 810.

7. O Agente de Negociação 810 envia mensagens de Notifica- ção de Cumprimento de FIX (prática normal/atual) para as duas partes asso- ciadas ao negócio.

8. O Agente de Negociação 810 então envia a informação de negociação para os Sistemas de Compensação 812 mediante o que os pro- cessos de CME de compensação normais tomam efeito.

Em uma modalidade, proteções de Cotação de Massa e criador de mercado associado são suportadas para um fluxo de negociação de RFQ Dirigida. Quando proteções de criador de mercado são disparadas, um me- canismo baseado em RFQ Dirigida ou CLOB, as Cotações de Massa e os mercados de CLOB existentes seriam cancelados e, adicionalmente, quais- quer respostas de RFQ Dirigida ativas seriam imediatamente canceladas pelo sistema.

Em uma modalidade, as proteções de criador de mercado inclu- em aquelas providas pelo agente de negociação Falcon da CME e incluem proteções especificadas na Tabela 2 abaixo.

Tabela 2

10. O Falcon provê uma proteção de criador de mercado melhorada.

10.1 O Falcon restringe o número de cumprimentos, o número de ne-

gócios equilibrados ou o número de contratos ocorrendo em um intervalo de tempo definido por CME.

10.1.1 O tempo de restrição é definido no Nível de Grupo.

10.1.2 A Proteção de Criador de mercado se aplica ao COTADORES EM MASSA apenas.

10.1.3 A Proteção de Criador de mercado (Proteção de MM) se aplica a Cotações em Massa entrando e Cotações em Massa ficando apenas.

10.1.4 A Proteção de Criador de mercado se aplica a cada lado de uma Cotação separadamente.

Nota: a Proteção de Criador de mercado não se aplica a Pedidos submetidos por um Criador de mercado.

10.1.5 O intervalo de tempo definido por CME (variável N) é introduzi- do através de FAS e é aplicado ao Nível de Grupo.

10.1.5.1 A variável N é a única aplicada a Produtos elegível para Cota- ções em Massa.

10.1.5.2 A variável N é baseada em um batimento cardíaco estabelecido de Agente de Negociação.

10.1.5.3 O batimento cardíaco começará randomicamente na partida 10.1.5.3.1 O batimento cardíaco começará ao mesmo tempo para cada grupo

10.1.5.4 A variável N pode ser mudada em uma base em tempo real 10.1.5.4.1 A mudança de variável N ocorre no fim do período N atual.

10.1.5.5 A variável N é mantida para COTADORES EM MASSA no Nível de Grupo.

10.1.5.6 N se reinicializa no fim do N período de tempo, independente- mente de uma ação de mercado ocorrer ou não (execução/entrada de cota- ção, etc.).

10.1.5.7 Uma regulagem/reinicialização de Cotadores em Massa uma Proteção de MM para Y entram no período de tempo N em andamento. No- ta: nenhum relógio de tempo N único para MQ.

10.1.5.8 A variável N é mantida no nível de milissegundos ssSSSS.

10.2 O Falcon realiza três mecanismos de proteção aplicados no Ní- vel de Grupo para COTADORES EM MASSA: Nova Proteção de Cumpri- mento (X), Proteção de Execução (Y), Proteção de Quantidade (Z). 10.2.1 Nova Proteção de Cumprimento (X)- Falcon acompanha as e- xecuções de nova cotação por lado de nova cota para todos os instrumentos em um Grupo para um COTADOR EM MASSA.

10.2.1.1 Uma contagem começa em 1 para um Grupo quando uma exe- cução corre para um novo lado de cotação.

10.2.1.1.1 O tamanho das execuções e o número de execuções não afe- tam a contagem para o lado de cotação de instrumento específico.

10.2.1.1.2 Cancelar/Substituir executado e novas Cotações em Massa o- correndo no período de tempo N para um lado de cotação de instrumento

em um grupo incrementam a contagem em 1.

10.2.1.2 Os incrementos de contagem para 1 para um Grupo para toda execução ocorrendo em relação a uma nova cotação em um lado de cotação para um grupo de instrumento no intervalo de tempo N.

Nota: uma nova cotação é definida uma modificação de uma cotação existente ou uma cotação introduzida após um cumprimento total para um instrumento.

10.2.1.3 Uma Nova Proteção de Cumprimento (X) é determinada pelo COTADOR EM MASSA e é modificável no FAS.

10.2.1.3.1 Regular a Nova Proteção de Cumprimento para zero desativa a proteção.

10.2.1.4 A contagem X é reiniçializada a cada vez em que um novo inter- valo de tempo N começa.

10.2.1.5 Cancelamentos de Cotação em Massa não têm impacto sobre o valor de X.

10.2.1.6 A Proteção de MM é disparada quando X for maior ou igual ao valor X definido por COTADOR EM MASSA.

10.2.2. Execução de Proteção (Y) - Falcon acompanha o número total de execuções por lado de cotação para todos os instrumentos em um Grupo para um COTADOR EM MASSA.

10.2.2.1 Uma contagem começa em 1 para um Grupo, quando uma exe- cução ocorre para um lado de cotação.

10.2.2.2 A contagem é incrementada em 1 para um Grupo para toda exe- cução ocorrendo em relação a uma cotação em um lado de cotação para um instrumento (no Grupo) no intervalo de tempo N.

10.2.2.3 A Proteção de Execução (Y) é determinada pelo COTADOR EM MASSA e é modificável no FAS. 10.2.2.3.1 A regulagem da Proteção de Execução (Y) para 0 desativa a proteção.

10.2.2.4 A contagem Y é reinicializada a cada vez em que um novo inter- valo de tempo N começa.

10.2.2.5 Cancelamentos de Cotação em Massa não têm nenhum impacto sobre o valor de Y.

10.2.2.6 A Proteção de MM é disparada quando Y é maior do que ou i- gual ao valor Y definido por COTADOR EM MASSA.

10.2.3 Proteção de Quantidade (Z) - Falcon soma a quantidade total de negócios executados por lado de cotação para todos os instrumentos em um Grupo para um COTADOR EM MASSA.

10.2.3.1 Uma agregação começa para um Grupo quando uma execução o- corre para um lado de cotação.

10.2.3.2 A soma aumenta para um Grupo pelas quantias de quantidade de negócio ocorrendo em relação às cotações em um lado de cotação para um instrumento (no Grupo) no intervalo de tempo N. [Nota: quantidade em instrumento, não totais de base de instrumento].

10.2.3.3 A Proteção de Quantidade (Z) é determinada pelo COTADOR EM MASSA e é modificável em FAS.

10.2.3.3.1 Uma regulagem da Proteção de Quantidade (Y) para 0 desativa a proteção.

10.2.3.4 A soma Z é reinicializada a cada vez em que um novo intervalo de tempo N começa.

10.2.3.5 Cancelamentos de Cotação em Massa não têm nenhum impacto sobre o valor de Z.

10.2.3.6 A Proteção de MM é disparada quando Z é maior do que ou i- gual ao valor de quantidade Z definido por COTADOR EM MASSA.

10.3 Criadores de mercado determinam os valores X, Y1 e Z no Nível

de Grupo.

10.3.1 O agente Falcon mantém os valores X1 Υ, Z definidos por MM no Nível de Grupo.

10.3.2 Os valores X1 Y1 Z são introduzidos e mantidos através do FAS no Nível de Grupo.

10.3.3 Os valores Χ, Υ, Z são modificáveis em uma base em tempo re- al.

10.3.3.1 As mudanças não tomam efeito até o final do período de tempo N.

10.3.4 O Tipo de dados de X, Y1 e Z é de posição comprada.

10.3.5 Os valores de X, Y, e Z podem estar entre 0 e um valor máx.

10.3.6 X, Y, e Z não podem ser negativos.

10.3.7 Se a Proteção de Cumprimento não for maior do que X, ou o 10 número de execuções for maior do que Z, ou a quantidade de contratos ne- gociados é igual a ou maior do que Y por Grupo no intervalo N, a Proteção de MM é disparada.

10.3.7.1 Quando a Proteção de MM é ativada, Falcon cancela as Cota- ções para todos os instrumentos no Grupo para SenderCompID de COTA-

DOR EM MASSA.

10.3.7.1.1 As entradas Cotação na mensagem de Cotação de Massa as quais disparam uma Proteção de MM são canceladas e adicionadas ao campo de Número de Cancelamentos Aceitos. Cancelar/Substituir Entradas de Cotação são contadas apenas uma vez.

10.3.7.1.2 A Entrada de Cotação a qual dispara a Proteção de MM gera uma execução.

10.3.7.1.3 Qualquer quantidade remanescente é cancelada e adicionada ao campo de Número de Cancelamentos Aceitos.

10.3.7.2 Falcon envia uma mensagem de Confirmação de Cancelamento de Cotação em Massa com um Status de Cotação de F.

10.3.7.3 A Proteção de MM não é cumprida quando as variáveis Χ, Υ, Z são encontradas em um equilíbrio médio.

10.3.7.4 A Proteção de MM é disparada após a cotação a qual faz com que a variável X, Y ou Z para disparo completar um processo de combina- ção.

10.3.7.5 As mensagens de Cotação em Massa as quais disparam uma Proteção de MM retornam um Ack antes da mensagem e cancelamento. 10.3.8 Quando uma Proteção de MM é disparada, Falcon não aceita quaisquer novas Cotações em Massa para um COTADOR EM MASSA no Grupo disparado.

10.3.8.1 Falcon rejeita Cotações em Massa para o COTADOR EM MAS- SA no Grupo.

Código de Rejeição de Mensagem e Texto de Razão denotarão que uma Proteção de MM foi iniciada.

Código de Rejeição de Mensagem = 00

Texto de Razão de Mensagem = ""

10.3.8.1 O Falcon aceita Cotações no Grupo disparado, se a Tag de indica- dor de inicialização de Proteção de Criador de mercado 9773 tiver sido reini- cializado Y em uma mensagem de Cotação em Massa pelo COTADOR EM MASSA.

10.3.8.1.1 O valor recebido a partir do COTADOR EM MASSA é ecoado de volta para o COTADOR EM MASSA.

10.3.8.1.2 Se o valor do indicador de reinicialização for N e a Proteção de MM estiver em vigor, Falcon envia a rejeição a seguir:

Status de cotação = 5

Código de rejeição = 98

Texto de Razão = "Proteção de Criador de mercado"

10.3.8.1.3 Após o COTADOR EM MASSA submeter a regulagem de indi- cador de Reinicialização de Proteção para Ύ', eles podem continuar a intro- duzir Cotações em Massa com o indicador regulado de volta para 'N'.

10.3.8.2 Falcon aceita Cotações no Grupo disparado, se o Tag de indica- dor de reinicialização de Proteção de Criador de mercado 9773 tiver sido regulado para Y para o COTADOR EM MASSA pelo GCC via FAS.

10.3.8.3 A Proteção de MM é disparada se uma mensagem de Cotação em Massa de entrada contiver mais de 110 cotações inválidas.

10.3.8.3.1 Se mais de 110 cotações em uma mensagem de Cotação em Massa forem inválidas, o Falcon rejeita a mensagem inteira e cancela todas as cotações ficando no Grupo para o COTADOR EM MASSA.

10.3.8.3.1.1 Rejeição e cancelamento ocorrem se o indicador de Proteção de MM estiver ligado ou desligado.

10.3.8.3.1.2Mensagem de Confirmação de Cancelamento de Cotação em Massa conforme se segue: CanceLStatus = "F", Reject_Code = 00, Rea- son_Text = " "

10.3.8.3.1.3Falcon continuará a rejeitar Cotações em Massa até o COTA- DOR EM MASSA receber um indicador de reinicialização de Proteção em uma Mensagem de Cotação em Massa.

10.3.8.3.1.4As Mensagens de Cotações em Massa subseqüentes antes de uma reinicialização serão rejeitadas e enviada uma Mensagem de Confirma- ção de Cotação em Massa com um Status de Cotação de 5. Código de Rejeição de Mensagem = 98

Texto de Razão de Mensagem = "Proteção de Criador de mercado"

10.3.8.4 No caso de um agente Falcon reiniciar, novas mensagens de MassQuote são aceitas, independentemente do indicador de Reinicialização de Proteção.

10.3.8.5 O Falcon não reinicializa um status Proteção de Criador de mer- cado status quando da introdução do estado de fechamento ou pausa.

10.3.8.6 O Falcon não reinicializa uma Proteção de Criador de mercado no último fechamento programado de uma semana comercial.

10.3.8.7 A Proteção de MM está ligada se Χ, Υ, Z tiverem valores presentes.

10.3.8.8 A Proteção de MM está desligada se X e Y e Z tiverem valores 0.

10.3.8.9 O valor padrão de Proteção de MM é 0 para XeYeZ.

10.4 Por dois períodos de tempo N, a exposição de pior caso para um Cotador em Massa é duas vezes a variável X ou Y ou Z menos 2 daquela variável.

10.5 O Falcon executa ACKs para as cotações MQ antes de um Can- celamento quando a Proteção de MM for disparada.

Nas modalidades descritas, a funcionalidade de Dados de Mer- cado assegura que dados de mercado sejam comunicados de forma eficien- te e acurada para os participantes de mercado. Todos os dados de mercado para estes mercados podem ser em termos nacionais, isto é, expressos co- mo o valor de face dos instrumentos subjacentes nos quais os derivativos são negociados, mas outras representações podem ser usadas.

Os dados de mercado para o Livro de Pedidos de Limite Central podem incluir:

• A profundidade de mercado na mensagem de Topo de Livro MA (e mensagem de Topo de Livro Implicado MY) em 5.

• Cumprimentos consolidados.

• Margens (spreads) e bases e/ou quantidades de spread.

Os dados de mercado para RFQ Dirigida podem incluir:

• A mensagem de requisição (e uma mensagem de expira- ção);

• O cumprimento e um preço de cumprimento.

Nos sistemas descritos, as cotações e atualizações de livro de pedidos são anônimas e os Negociantes não podem anunciar diretamente suas cotações.

As estatísticas de mercado podem incluir:

• Volume de atualização, alto, baixo, último do livro de pedidos de limite central;

• Para negociações em bloco neste mercado, as estatísticas de dados de mercado, tais como o volume geral, alto, baixo e último serão atualizadas com base nas regras existentes (estas regras são definidas na regulagem de recurso de EOS 2.0 RFC/Blocos);

• Para RFQ Dirigida.

Nas modalidades descritas, para negócios de Swap, dados de mercado para bases de Entrega Imediata e Entrega a Termo Direta são dis- seminados. Para mercados recíprocos, aqueles os quais usam uma Entrega Imediata de um outro mercado associado, estes dados de mercado devem ser arredondados de alguma forma.

Nas modalidades descritas, a funcionalidade de Dados de Ne- gociação assegura que dados de negociação e de pedido sejam comunica- dos de forma eficiente e acurada para os participantes de mercado.

Notificações de cumprimento consolidado precisam ser distribuí- das imediatamente após um equilíbrio, independentemente fórum em que o equilíbrio ocorreu: • Notificação para o departamento de operações;

• Notificação para a câmara de compensação;

• Notificação para a firma de compensação do proprietário do negócio (conta);

• Notificação para um sistema de departamento administrativo de negociante (questão em aberto);

• Notificação para dados de mercado (condicional em fórum);

Cumprimento Consolidado:

• Front-end - enviar apenas uma única notificação de cumpri- mento por pedido de agressor, por nível de preço, independentemente do número de contrapartes;

• Isto poderia ser realizado através de uma modificação nas mensagens existentes de FIX de iLink (e no modelo de envio de mensagem em geral) ou através de uma agregação de mensagem no departamento de operações;

• Back-end - similar à consolidação de departamento de ope- rações, havendo apenas uma única notificação por pedido de agressor, por nível de preço, independentemente do número de contrapartes e dos negó- cios individuais envolvidos. Pode ser crítico para esta porção do Cumprimen- to Consolidado que as regras de consolidação combinem exatamente com as regras de departamento de operações.

As notificações de cumprimento devem incluir:

• Swaps de Entrega a Termo - o Swap com o diferencial, a base de Entrega Imediata com sua data de validade associada, e a base de entrega a termo com sua data de validade associada.

o Isto requererá o uso da mensagem D1 (bem como da M1) a par- tir do Agente de Equilíbrio para Compensação, ou uma nova interfa- ce/mensagem em conjunto. D1 e M1 são mensagens de negócio enviadas pelo agente de negociação para as organizações de compensação e relató- rio. Veja a seção abaixo sobre Compensação/Liquidação para maiores in- formações;

• Contratos de Entrega Imediata - o contrato de Entrega Ime- diata genérico e sua data de validade associada;

• Entrega a Termo Direta - a entrega a termo direta genérica e sua data de validade associada.

Nas modalidades descritas, uma informação de contraparte po- de não ser incluída na notificação de cumprimento:

• Para o departamento de operações;

• Para a firma de consolidação.

Um relatório de negociação mantém o preço e a data de negócio original para convenção de mercado em dinheiro de equilíbrio. Um relatório de negociação atualmente é feito através de FIX ML e TREX, enquanto os padrões de indústria em FX de OTC são tais como TOF1 TWIST & SWIFT. Nas modalidades descritas, a compensação suporta mensagens de negoci- ação nestes principais formatos de FX de OTC. Em uma modalidade, Dea- IHub ou um serviço similar pode ser usado para conversão de um formato de CME de origem para um daqueles padrões de FX de OTC.

Um relatório de negociação é feito em uma quantia de referên- cia, ao invés de na quantidade do contrato, usando-se ML de FIX como um formato de CME de origem.

Nas modalidades descritas, a funcionalidade de Compensa- ção/Relatório de Negociação/STP essencialmente realiza as funções de ne- gociação da Bolsa. A Compensação lida com toda a criação e modificação de instrumento para o Agente de Equilíbrio. Conforme citado acima, os sím- bolos de contrato de Swap não mudam diariamente. Em uma modalidade, a cada dia os preços de liquidação de fim de dia economicamente mais apro- priados para contratos em aberto precisam ser determinados, de modo a marcar as posições em aberto para o mercado. Liquidações diárias resulta- rão em um ganho/uma perda não realizada. Entregas pendentes, perdas não realizadas serão garantidas (ao invés de um uso de banco diário daquela quantia de marca para mercado).

As exigências de garantia são baseadas em:

• A quantia exata de ganho/perda não realizado até agora;

• A perda razoavelmente provável máxima pelo próximo dia comercial, conforme determinado por SPAN de acordo com parâmetros que foi regulado; e

• Exigências de CLS para capital em relação a obrigações de liquidação esperadas;

O relatório de liquidação/negócio contém uma informação sobre o spread negociado, bem como as bases diretas (com a ligação implicada entre as bases e spread presente):

• A compensação opcionalmente comprimirá negócios, com base em uma necessidade de cliente/CLS (note que isto não é uma pré- liquidação, já que esta zeraria uma compra & venda, ao passo que uma compressão não);

• Uma compensação opcionalmente comprimirá negócios, com base em uma necessidade de cliente/CLS;

• Esta pré-liquidação ou compressão pode ser feita em um nível de granularidade por moeda;

• Todas as liquidações serão feitas através de um Banco de Liquidação Ligado Contínuo (CLS);

• Para posições em aberto normais com a convenção de data de validade de dois dias, nós estaremos enviando transações para CLS en- tre 4 e 5 pm horário de Chicago - precisa validar em relação às práticas de OTC existentes;

• As linhas de tempo de ciclo de compensação e ligação nor- mal não serão afetadas e permanecerão 7 pm para completação de toda atividade pós-negócio antes do segundo dia antes da data de validade; e • Relatórios de liquidação são gerados para cada firma de compensação enumerando cada atividade específica de conta.

Em uma modalidade alternativa, um suporte para crédito bilate- ral, Desistências, Preço Médio (APS) e Entrada de Linha Única de Spreads Diferenciais (SLEDS) é provido.

As modificações de número de Conta pós-negócio não são per- mitidas neste mercado.

Para Relatório de Compensação/Negociação, conforme mencio- nado acima, as modalidades descritas podem usar uma de várias opções, as quais são dependentes de implementação:

1. Pré-liquidar cada lado por negócio; ou

2. Pré-liquidar cada lado por data de negócio.

A Câmara de Compensação de CME pode liquidar diretamente através de CLS para cada firma de compensação. Se aquela firma de com- pensação tiver instruções válidas de CLS para uma dada conta, a CME po- derá compensar através de CLS para o nível de conta.

Nas modalidades descritas, a funcionalidade de Honorário per- mite que a Bolsa cobre honorários de transação e de outra forma obtenha uma compensação pelo uso dos mecanismos de negociação providos. A funcionalidade de Honorário contabiliza negociação e outras atividades e apropriadamente obtém uma compensação das partes em transação.

Para fins de Honorários, isto será uma nova classe de partici- pante de mercado.

O sistema terá a capacidade de cobrar honorários pelo seguinte:

• Ligações de quantidade discreta; e/ou

• Pedidos de agressor.

Toda quantidade é em termos de referência.

Este mercado será um "Pagamento" versus "Compartilhamento de Receita".

Os atributos ou qualidades de um Criador de mercado, para fins de Honorários apenas, podem ser definidos nos termos a seguir:

• SubscriberAIias - de onde o pedido está vindo (isto é, um segmento especializado ("desk"));

• TraderID - de quem a ordem está vindo;

• Conta - de quem é este pedido.

O arquivo de compra/venda de Compensação deve incluir o in- dicador de 'pedido de agressor', bem como uma informação sobre de que produto este negócio era uma parte (especificamente, no caso de um Swap, o arquivo de compra/venda tipicamente apenas inclui as bases, sem uma referência ao spread).

Há o potencial para honorários negativos.

A funcionalidade de Honorário lida com o novo tipo de transação o qual é o negócio em Bloco resultante de uma RFQ Dirigida, a qual é dife- rente de um Bloco normal ou uma transação de Ex-Pit.

Em uma modalidade, uma estrutura de honorário variável pode ser provida, na qual os honorários variam como uma função do risco da transação e/ou da parte de negociação.

A funcionalidade de Departamento de Operações/Distribuição das modalidades descritas inclui as interfaces, por exemplo, as Interfaces de Programa Aplicativo ("APIs"), a GUI, etc., as quais permitem o recebimento de pedidos, RFQs Dirigidas, etc. a partir dos participantes de mercado e a disseminação de dados de negócio e mercado para os participantes de mer- cado.

Os dados de acesso e de mercado para um Vendedor de Soft- ware Independente ("ISV") e Departamentos de Operações Proprietários no Livro de Pedidos de Limite Central ("CLOB") e RFQ Dirigida estarão disponí- veis através de APIs:

• Em uma modalidade, a CME distribuirá este novo mercado através de iLink 2.0, uma API de dados de mercado de CME, apenas, com os melhoramentos de API requeridos para englobar os novos tipos de pedi- do e este mercado; e

• Este mercado usará a infra-estrutura de dados de mercado

existente.

Um acesso de API será tornado disponível para qualquer enti- dade aprovada, conforme determinado pelo Mercado dé FX:

• O Mercado de FX deve ser capaz de evitar que departamen- tos de operações e centros de dados o acessem (por exemplo, EBS);

• ISVs também podem ser permitidos para a criação de aces- so para usuários autorizados (isto é, ISVs de mercado de OTC) via um pro- cesso de registro operado por GCC. Estes mercados geralmente não estão disponíveis para todos os negociantes na rede de ISV;

Um departamento de operações pode assumir uma de três for- mas:

• Lidar com Reuters, usando as interfaces de CME existentes (i-

Link 2.0 API atualizado, enlace com Compensação descrito acima, dados de mercado);

• Desenvolvimento de novo produto, interno ou através de uma dependência de joint venture; ou

• Atualização e departamento de operações de CME existente (EOS/GL/CME.com).

Em uma modalidade, o departamento de operações é baseado em navegador, ao invés de um aplicativo independente. O departamento de operações deve conhecer as definições de produto plenas, em tempo real, inclusive as datas de validade para mercados de Entrega Imediata e de Swap. Também pode ser permitido que os ISVs criem acesso para usuários autorizados (isto é, ISVs de mercado de OTC). Este sistema geralmente não está disponível para todos os negociantes na rede de ISV.

O sistema de Distribuição/Departamento de Operações empre- gado aqui opcionalmente poderia se conformar às recomendações de Cum- primento Consolidado mencionadas acima. Em uma modalidade, o sistema tem a capacidade de entregar esta informação nos formatos de indústria re- queridos atualmente usados no espaço de FX de OTC. Em uma modalidade, uma funcionalidade de negociação adicional é provida para as partes em transação. Por exemplo, em uma modalidade, Spreads Implicados em Moe- das são providos. Esta função permite implicar/interpolar um preço em um de múltiplos mercados inter-relacionados com base em dados de preço (su- ficientes) conhecidos nos mercados remanescentes. Os mercados inter- relacionados de exemplo são: taxa de entrega imediata/taxa de swap, entre- ga a termo direta; moeda cruzada (A/B, B/C, A/C) (através de ou dentro de linhas de produto), por exemplo, dólar/iene - iene/euro - dólar/euro; e entre datas interrompidas. No caso de um pedido entrando para um mercado de swap na moeda A/B, o swap é interropido em duas bases de entrega a ter- mo para o referido par de moedas. Estas bases podem ser usadas para im- plicar em um interesse em aberto em mercados recíprocos ou naqueles mercados de entrega a termo usando uma moeda específica.

Em uma outra modalidade, proteções de Evitação de Equilíbrio Intrafirma são providas para se evitar que uma entidade em particular faça uma transação com ela mesma. O sistema impede firmas ou negociantes de se equilibrarem em qualquer um dos mercados de livro de pedidos de limite central. Isto pode ser realizado usando-se uma informação sobre o pedido no negociador, desk, ou nível de firma de granularidade. Quando um pedido de agressor está equilibrando o livro restante e o pedido oposto foi julgado como não sendo equilibrável, há várias opções: o pedido de agressor é can- celado antes de qualquer equilíbrio ocorrer; ou o pedido de agressor se equi- libra normalmente e qualquer pedido restante que ele tentar equilibrar, o qual seja julgado não combínável, é cancelado imediatamente. Em qualquer ca- so, mensagens apropriadas de cumprimento e cancelamento são enviadas para as partes envolvidas, por operações normais daquelas ações (cance- lamento de pedido e negócio).

Em uma outra modalidade, uma Passagem Universal é provida, a qual permite que as partes permutem (swap) taxas de juros entre moedas em que a câmara de compensação assume o risco de crédito/mecanismo de transferência de fundos.

Em uma outra modalidade, descrita na Figura 5A, uma Margem Cruzada de Contraparte Central Híbrida Flexível ou Garantia Cruzada é su- portada. Em particular, processos de margem cruzada ou garantia de um investimento especulativo ("bucket") e de dois investimentos especulativos são combinados em um processo otimizado único. Uma Margem Cruzada ou Garantia Cruzada permite uma redução nas exigências de quantia de mar- gem ou de garantia para negociação no OTC ou em mercados de derivativos negociados em bolsa. Esta redução é possível porque um risco avaliado é reduzido, quando posições de compensação (compensação (offset) de risco ou"Disseminável") são livradas pelos mesmos "membros de compensação" afiliados ou firmas participantes de mercado nas organizações de compen- sação de contraparte centrais participantes.

Na presente modalidade, ambos os processos de margem cru- zada ou garantia de um investimento especulativo e de dois investimentos especulativos são combinados em um processo otimizado e único pela com- binação da 'Abordagem de Um Pot' e da 'Abordagem de Dois Pots' para su- portar transações de compensação de derivativos de OTC e negociados em bolsa. Processo 1: a Abordagem de Um Pot é inicialmente obtida com duas ou múltiplas partes de parceria. Processo 2: a Abordagem de Dois Pots é obtida com uma ou múltiplas partes de parceria com posições elegíveis de offset de risco após o processo 1 ser feito.

Com referência às Figuras 5B e 5C, a Abordagem de Um Pot é descrita:

• Participantes de Escopo de Transações de Compensação: membros de compensação de bolsa ou contrapartes no mercado de OTC

• Múltiplos contratos ou produtos de todos os tipos (OTC e negociados em bolsa) em bolsas diferentes ou contrapartes.

• Toda Atividade de Margem Cruzada = Conta Conjunta de Margem Cruzada/garantia

o Identificado com uma Origem Separada em Margem Cruzada

o É separada de uma compensação normal de participante em respectivas organizações de compensação, entidades ou contrapartes.

• Apenas ALLOW (PERMITEM) Negócios Elegíveis de Mar- gem Cruzada/Garantia para Compensação nas Contas Conjuntas de Mar- gem Cruzada/Garantia

o Negócios executados nas Contas de Margem Cruzada

o Posições podem ser transferidas entre uma Conta de Com- pensação normal e uma Conta de Compensação de Margem Cruza- da/Garantia.

o Registros de Posição/Dados Separados são submetidos pa- ra a Origem de processo de Margem Cruzada.

• Liquidação bancária ou garantia apenas Dedicada às Contas Conjuntas de Margem Cruzada

o Negociado como Origem em Separado

o Separar Contas Bancárias, Fios (Wires), Transações, etc.

Com referência à Figura 5D, a Abordagem de Dois Pots é des- crita:

• Transações de Organizações Participantes de Compensação = Ocorre em cada Org. de Compensação + Risco de Offset = 2 Pot

• Nenhuma Conta Conjunta de Margem Cruzada

o Nenhuma separação de Conta de Compensação Primária de Membro de Compensação em respectivas organizações de compensação

o Manter Garantia nas Mesmas Contas de Firma Separadas

• Cada Organização Participante calcula suas Exigências de PB, Offset e Offset Compartilhado, Ganho & Informação de Garantia de Per- da

o Posições permanecem em cada origem de organização de participante

o Nenhuma necessidade de transferência de posição para conta de Margem Cruzada

o Nenhum relatório de Submissão de Mudança de Posição em Separado (PCS) é necessário

• Transação transparente o Por exemplo,

• CME oferece crédito em contratos elegíveis de margem cru- zada para compensação (offset) de posições nas organizações de compen- sação opostas

• Org. de Compensação Oposta oferecerá créditos em suas posições.

o Nenhuma Liquidação Bancária Dedicada para Fins de Mar- gem Cruzada • Nenhuma Conta Bancária, Fio (Wire), Transação em Sepa- rado, etc.

• As transações se tornam parte de transações bancárias atuais

Na abordagem de Abordagem de Dois Pots, os offsets de mar- gem cruzada são calculados conforme se segue:

1. Dar toda uma margem (spreading) em intramercadoria interna.

2. Dar toda uma margem (spreading) em intermercadoria interna.

3. Olhar para as posições de delta de margem cruzada em ou- tras organizações de compensação para ver se spreads adicionais poderiam ser formados a partir das posições de delta remanescentes de CME.

4. Alocar Crédito de Spread Priorizado para cada Organização de Compensação

• isto é, um programa de margem cruzada de múltipla organi- zação.

• atribuir prioridade das quantias de crédito de spread do mais alto para o mais baixo com base na informação de outras organizações de compensação participantes.

• calcular a alocação de spread com base na prioridade.

A Figura 5E mostra o processo de se lidar com posições que não foram originalmente compensadas. A Figura 5F mostra como uma mar- gem cruzada utiliza uma margem de margem X que não foi compensada. A Figura 5G demonstra como uma margem cruzada equilibra posições de risco absoluto similar em duas ou mais organizações de compensação.

Alocação de Poupança em Base Proporcional:

• Margem Cruzada com organizações múltiplas,

o Alocação de Suas Posições e Margem necessárias

o Alocações otimizarão as reduções de margem de membros

As quantias são primeiramente alocadas a produtos com melhores correlações Se igualmente correlacionados, as alocações são baseadas pró-rata nas quantias de margem submetidas por cada organização de compensação

<table>table see original document page 71</column></row><table>

A abordagem de 2 pots oferece as vantagens de: a flexibilidade no gerenciamento de garantia não é afetada usando-se a abordagem de "Dois Pots"; evita complexidades legais e operacionais de estabelecimento de manutenção de Contas de margem conjuntas em um ambiente de mar- gem cruzada de organização de compensação múltipla; a capacidade de penhorar uma garantia de margem para fins de liquidez não é afetada; e não há um impacto operacional exceto na realização de um acompanhamento de auditoria.

Em uma outra modalidade, uma cotação de bases de swap, u- sando-se o ponto médio no mercado de entrega imediata é provida, com uma manipulação de erro em que o mercado de entrega imediata não é Ii- quido. Em particular, conforme usado aqui, "Entrega Imediata" se refere ao dia no qual os negócios acordados hoje são realmente realizados. Nos mer- cados de câmbio, a entrega imediata usualmente é de dois dias úteis à fren- te; então, para negócios concluídos na quinta-feira, a entrega imediata é sexta-feira; para negócios concluídos na sexta-feira, a entrega imediata é na terça-feira (a menos que feriados bancários intervenham). Um negócio de entrega imediata é uma simples troca de dois volumes de moeda ocorrendo dois dias úteis à frente - em outras palavras, com uma data de validade de entrega imediata. As taxas de câmbio comumente cotadas na mídia são ta- xas de entrega imediata - as taxas acordadas em negócios de entrega ime- diata do dia. O termo "Direta/Entrega a termo" se refere a uma bolsa de En- trega a Termo simples e dois volumes de moeda em que a data de validade é qualquer data além da entrega imediata. A taxa para o negócio é normal- mente cotada como um prêmio ou um desconto ('prêmio negativo') no topo da taxa de entrega imediata atual. Assim, a fórmula para a taxa negociada (a taxa especificando a relação entre os dois volumes) é:

Taxa Negociada = Taxa de Entrega Imediata + Prêmio, ou Taxa Negociada = Taxa de Entrega Imediata - Desconto. Em um negócio de swap, um volume de uma moeda é trocado por um volume de uma segunda moeda. Após um período acordado, a tran- sação é revertida. É possível que os volumes na segunda 'base' da transa- ção difiram da primeira. Por exemplo, um negócio poderia especificar que na entrega imediata:

O Banco A pague 5.000.000 de dólares americanos ao Banco B O Banco B pague 7.565.000 francos suíços ao Banco A (Taxa 1,5130)

e que três meses mais tarde:

O Banco B pague 5.000.000 de dólares americanos ao Banco A

O Banco A pague 7.565.000 francos suíços ao Banco B(Taxa 1,5060).

A diferença nas taxas da segunda moeda para as duas bases do

negócio de swap surge de diferenças nas taxas de depósito para as duas moedas, e expectativas sobre variações nas taxas de entrega imediata.

Em uma modalidade, o sistema descrito:

• Dará um preço de uma Entrega Imediata e de uma Entrega a Termo em termos absolutos (isto é, a taxa); e

• Dará um preço de Swap em termos diferenciais..

Quando um negócio em um Swap ocorre, o sistema tem o diferencial acor- dado entre a base de Entrega Imediata e a de Entrega a Termo. Neste pon- to, o sistema ancora a Entrega Imediata para a transação no ponto médio entre a oferta para compra/pergunta no mercado de Entrega Imediata atual.

Adicionalmente, quatro mecanismos alternativos para como atri- buir os preços de base para os Swaps de FX de CME são providos, se não houver preços de ofertas para venda/pergunta para uma dada moeda na Entrega Imediata de FX de CME:

1. Usar as páginas de FX de entrega imediata de contribuinte de Reuters (tais como EUR=, JPY=, CAD=, GBP=, CHF=, AUD=) e tomar a média das cotações de oferta para venda e compra de entrega imediata no momento do negócio;

2. Usar Cotações de Terminal de Negociação de Reuters (tal- vez utilizando uma informação de GFX de CME) para as moedas alvos e calcular a média da oferta para venda e proposta para compra de entrega imediata para usar na atribuição de preços de base de SWAP;

3. Usar a combinação de Cotações de Terminal de Negociação de Reuters para suas moedas fortes e recursos de entrega imediata de GFX de CME para as moedas fortes de EBS;

4. Usar preços de futuros de moeda de CME (oferta para com- pra/proposta para venda em CME Globex) para o mês de contrato próximo (mais ativo) e usar os pontos de entrega a termo de Reuters (ou uma combi- nação de pontos de entrega a termo de Reuters e Bloomberg) para as datas de IMM para retirada da oferta para contra/proposta para venda de entrega imediata sintético para tomada de preço de preços de base de SWAP de CME. Simplesmente calcular a média de oferta para venda/proposta para compra destes preços de entrega imediata sintéticos para atribuição de pre- ços de base de SWAP de CME. Isto pode ser similar a planos de operações de piso de negociação de CME para uso em uma versão análoga desta téc- nica para a regulagem de preços de liquidação de futuros de FX de CME para os meses de expiração durante o período de rolagem de uma semana pelo uso dos próximos preços de contrato de futuros de FX de CME mais ativamente negociados deferidos em segunda e pontos de entrega a termo de volta para o preço de liquidação de futuros de FX de CME. As operações de piso de negociação de CME têm um programa que poderia possivelmen- te ser modificado para retorno de oferta para compra e perguntas de entrega imediata dos preços de futuros de FX de CME; ou

5. Usar o último preço no mercado de Entrega Imediata, atra- vés de uma certa idade. Se o último preço de entrega imediata era antigo demais, este preço de entrega imediata seria parado pelo "preço de liquida- ção diário" usado para a determinação de ganhos e perdas não realizados (assim, nunca com mais de 24 horas de idade). Contudo, o número 4 acima poderia funcionar como uma alternativa para qualquer tempo em que não haja uma entrega imediata e, se não houver ofertas para compra e propos- tas para venda de futuros em CME Globex, então, poderia ser parado pela última entrega imediata e, se não houvesse nenhum último preço de entrega imediata naquele dia, poderia ser mais parado pelo último preço de Iiquida- ção diário.

Portanto, pretende-se que a descrição detalhada precedente seja considerada como ilustrativa, ao invés de limitativa, e que seja entendi- do que são as reivindicações a seguir, incluindo todos os equivalentes que se pretende que definam o espírito e o escopo desta invenção.

Claims (88)

1. Método de negociação de instrumentos financeiros dentre uma pluralidade de entidades participando em um mercado, o método com- preendendo: o recebimento de uma requisição para cotação de uma primeira entidade da pluralidade de entidades, a requisição para cotação identifican- do a primeira entidade e especificando um interesse na negociação de um primeiro instrumento; a transmissão da requisição para cotação para pelo menos um subconjunto da pluralidade de entidades sem a identificação da primeira en- tidade; o recebimento de pelo menos uma resposta a partir de pelo me- nos uma segunda entidade do subconjunto, pelo menos uma resposta identi- ficando a requisição para cotação e incluindo uma cotação acionável em resposta a isto; e a transmissão de pelo menos uma resposta exclusivamente para a primeira entidade.

2. Método, de acordo com a reivindicação 1, em que o subcon- junto compreende a pluralidade inteira de entidades.

3. Método, de acordo com a reivindicação 1, que ainda compre- ende o incentivo do subconjunto a responder à requisição para cotação transmitida.

4. Método, de acordo com a reivindicação 1, em que o subcon- junto compreende pelo menos um formador de mercado.

5. Método, de acordo com a reivindicação 1, em que a transmis- são de pelo menos uma resposta ainda inclui a transmissão de pelo menos uma resposta para a primeira entidade sem a identificação de pelo menos uma segunda entidade.

6. Método, de acordo com a reivindicação 1, que ainda compre- ende a identificação de pelo menos uma segunda entidade da pluralidade de entidades em resposta à requisição por cotação, pelo menos uma segunda entidade sendo identificada como estando interessada na provisão de uma cotação para o primeiro instrumento, o subconjunto incluindo pelo menos uma segunda entidade.

7. Método, de acordo com a reivindicação 6, que ainda compre- ende a manutenção de um perfil de interesse para cada uma da pluralidade de entidades, em que a identificação é baseada no perfil de interesse de pe- lo menos uma segunda entidade associada.

8. Método, de acordo com a reivindicação 1, que ainda compre- ende: o registro de uma identificação da primeira entidade em relação à requisição para cotação; e a associação de pelo menos uma resposta à primeira entidade com base no registro; em que a transmissão de pelo menos uma resposta é baseada nisso.

9. Método, de acordo com a reivindicação 1, que ainda compre- ende: a geração de um código de identificação única não tendo ne- nhuma relação com a primeira entidade; a criação de uma relação entre o código de identificação único, a requisição para cotação e a primeira entidade; e em que a transmissão da requisição para cotação ainda inclui a transmissão do código de identificação único juntamente com a requisição para cotação, e ainda em que pelo menos uma resposta inclui o código de identificação único, a transmissão de pelo menos uma resposta para a pri- meira entidade sendo baseada no código de identificação único de pelo me- nos uma resposta e na relação.

10. Método, de acordo com a reivindicação 1, que ainda com- preende a manutenção do anonimato da primeira entidade com respeito a pelo menos o subconjunto da pluralidade de entidades.

11. Método, de acordo com a reivindicação 1, que ainda com- preende a eliminação da necessidade de uma relação bilateral entre a pri- meira entidade e pelo menos uma segunda entidade.

12. Método, de acordo com a reivindicação 1, que ainda com- preende o armazenamento temporário do risco de perda com respeito ao primeiro instrumento entre a primeira entidade e pelo menos uma segunda entidade.

13. Método, de acordo com a reivindicação 1, em que a requisi- ção para cotação ainda especifica um período de tempo o qual pode expirar, o método ainda compreendendo determinar quando o período de tempo ex- pirou.

14. Método, de acordo com a reivindicação 13, em que o período de tempo é especificado pela primeira entidade.

15. Método, de acordo com a reivindicação 13, em que o período de tempo é especificado automaticamente.

16. Método, de acordo com a reivindicação 13, que ainda com- preende o cancelamento da requisição para cotação mediante a expiração do período de tempo.

17. Método, de acordo com a reivindicação 13, que ainda com- preende o cancelamento da cotação acionável mediante a expiração do pe- ríodo de tempo.

18. Método, de acordo com a reivindicação 13, que ainda com- preende a rejeição de pelo menos uma resposta quando pelo menos uma resposta for recebida subseqüentemente à expiração do período de tempo.

19. Método, de acordo com a reivindicação 13, que ainda com- preende a especificação do período de tempo como um ponto específico no tempo.

20. Método, de acordo com a reivindicação 13, que ainda com- preende a especificação do período de tempo como a decorrência de uma duração especificada medida a partir de uma origem definida.

21. Método, de acordo com a reivindicação 1, em que a cotação acionável ainda especifica um primeiro período de tempo, o qual pode expi- rar, o método ainda compreendendo determinar quando o primeiro período de tempo expirou.

22. Método, de acordo com a reivindicação 21, em que o primei- ro período de tempo é especificado por pelo menos uma segunda entidade.

23. Método, de acordo com a reivindicação 21, em que o primei- ro período de tempo é automaticamente especificado.

24. Método, de acordo com a reivindicação 21, que ainda com- preende determinar se a cotação acionável foi aceita e cancelar a cotação acionável mediante a expiração do primeiro período de tempo, quando a co- tação acionável não tiver sido aceita antes da expiração do primeiro período de tempo.

25. Método, de acordo com a reivindicação 24, que ainda com- preende a transmissão de uma mensagem de cancelamento para pelo me- nos uma segunda entidade em resposta ao cancelamento.

26. Método, de acordo com a reivindicação 21, que ainda com- preende a rejeição de pelo menos uma resposta quando pelo menos uma resposta for recebida subseqüentemente à expiração do primeiro período de tempo.

27. Método, de acordo com a reivindicação 21, que ainda com- preende a especificação do primeiro período de tempo como um ponto es- pecífico no tempo.

28. Método, de acordo com a reivindicação 21, que ainda com- preende a especificação do primeiro período de tempo com o decorrer de uma duração especificada medida a partir de uma origem definida.

29. Método, de acordo com a reivindicação 21, em que a requi- sição para cotação ainda especifica um segundo período de tempo, o qual pode expirar, o método ainda compreendendo determinar quando o segundo período de tempo expirou e permitir a aceitação da cotação acionável desde que o primeiro período de tempo não tenha expirado.

30. Método, de acordo com a reivindicação 1, que ainda com- preende receber um cancelamento da codificação e impedir a aceitação da cotação acionável em resposta a isso quando o cancelamento for recebido antes da aceitação.

31. Método, de acordo com a reivindicação 1, que ainda com- preende a determinação da aceitação da cotação acionável.

32. Método, de acordo com a reivindicação 31, em que a determi- nação ainda compreende o recebimento da aceitação da primeira entidade.

33. Método, de acordo com a reivindicação 31, em que a deter- minação ainda compreende a aceitação automática da cotação acionável.

34. Método, de acordo com a reivindicação 33, que ainda com- preende a aceitação automática da cotação acionável de uma primeira de pelo menos uma resposta a ser recebida.

35. Método, de acordo com a reivindicação 33, que ainda com- preende a aceitação automática da melhor cotação acionável de todas de pelo menos uma resposta a ser recebida.

36. Método, de acordo com a reivindicação 31, em que a requi- sição para cotação ainda especifica pelo menos um critério para aceitação de uma cotação acionável em resposta a isto, a determinação ainda com- preendendo determinar um grau até o qual pelo menos um critério é satisfei- to pela cotação acionável de pelo menos uma resposta recebida.

37. Método, de acordo com a reivindicação 36, em que pelo me- nos um critério inclui pelo menos um dentre tempo de vida de requisição, quantidade, preço máximo, preço mínimo, ordem de compra, ordem de ven- da, ou combinações dos mesmos.

38. Método, de acordo com a reivindicação 36, que ainda com- preende o recebimento de uma pluralidade de respostas a partir de uma plu- ralidade de segundas entidades do subconjunto, cada uma da pluralidade de respostas identificando a requisição para cotação e incluindo uma cotação acionável em resposta a isto, a determinação ainda compreendendo deter- minar pelo menos uma das cotações acionáveis da pluralidade de respostas a qual mais bem satisfaça a pelo menos um critério.

39. Método, de acordo com a reivindicação 38, em que a deter- minação ainda compreende determinar pelo menos duas das cotações acio- náveis da pluralidade de respostas que mais bem satisfaçam a pelo menos um critério, o método ainda compreendendo a alocação de aceitação dentre pelo menos duas cotações acionáveis.

40. Método, de acordo com a reivindicação 39, que ainda com- preende a notificação da segunda entidade associada a cotações acionáveis não aceitas que as cotações acionáveis não aceitas não foram aceitas.

41. Método, de acordo com a reivindicação 31, que ainda com- preende o envio da requisição para cotação e da cotação acionável para uma bolsa mediante aceitação.

42. Método, de acordo com a reivindicação 1, em que a requisi- ção para cotação ainda especifica uma intenção da primeira entidade de comprar ou vender o primeiro instrumento, a transmissão da requisição para cotação ainda compreendendo a transmissão da requisição para cotação sem a identificação da intenção.

43. Método, de acordo com a reivindicação 1, que ainda com- preende permitir que a primeira entidade gerencie uma pluralidade de requi- sições para cotação pendente concorrentemente.

44. Método, de acordo com a reivindicação 1, que ainda com- preende permitir que pelo menos uma segunda entidade gerencie uma plu- ralidade de cotações acionáveis concorrentes.

45. Método, de acordo com a reivindicação 1, em que pelo me- nos uma resposta ainda é caracterizada por tempo de transmissão e tempo de recebimento diferente do tempo de transmissão, o método ainda compre- endendo uma compensação da diferença entre o tempo de transmissão e o tempo de recepção.

46. Método, de acordo com a reivindicação 1, em que a plurali- dade de entidades é acoplada a uma rede, o recebimento de uma requisição para cotação ainda compreendendo o recebimento de uma requisição para cotação através da rede, a transmissão da requisição para cotação ainda compreendendo a transmissão da requisição para cotação através da rede, o recebimento de pelo menos uma resposta ainda compreendendo o rece- bimento de pelo menos uma resposta através da rede, e a transmissão de pelo menos uma resposta ainda compreendendo a transmissão de pelo me- nos uma resposta através da rede.

47. Sistema para negociação de instrumentos financeiros dentre uma pluralidade de entidades acopladas com uma rede e participando em um mercado, o sistema compreendendo: um receptor de requisição acoplado à rede e operativo para re- ceber uma requisição para cotação de uma primeira entidade da pluralidade de entidades, a requisição para cotação identificando a primeira entidade e especificando um interesse na negociação do primeiro instrumento; um transmissor de requisição acoplado ao receptor de requisi- ção e à rede e operativo para transmitir a requisição para cotação para pelo menos um subconjunto da pluralidade de entidades, sem a identificação da primeira entidade; um receptor de resposta acoplado à rede e operativo para rece- ber pelo menos uma resposta de pelo menos uma segunda entidade do subconjunto, pelo menos uma resposta identificando a requisição para cota- ção e incluindo uma cotação acionável na resposta a ela; e um transmissor de resposta acoplado ao receptor de resposta e operativo para transmitir pelo menos uma resposta exclusivamente para a primeira entidade.

48. Sistema, de acordo com a reivindicação 47, em que o trans- missor de resposta ainda é operativo para transmitir pelo menos uma res- posta para a primeira entidade sem a identificação de pelo menos uma se- gunda entidade.

49. Sistema, de acordo com a reivindicação 47, que ainda com- preende um seletor de entidade acoplado ao receptor de requisição e ao transmissor de requisição e operativo para a identificação de pelo menos uma segunda entidade da pluralidade de entidades em resposta à requisição para cotação, pelo menos uma segunda entidade sendo identificada como estando interessada na provisão de uma cotação para o primeiro instrumen- to, o subconjunto incluindo pelo menos uma segunda entidade.

50. Sistema, de acordo com a reivindicação 49, em que o seletor de entidade é adicionalmente operativo para manter um perfil de interesse para cada uma da pluralidade de entidades, em que o seletor de entidade identifica pelo menos uma segunda entidade com base no perfil de interesse de pelo menos uma segunda entidade.

51. Sistema, de acordo com a reivindicação 47, que ainda com- preende um registro de identificação de requisição acoplado ao receptor de requisição e ao transmissor de resposta, em que o receptor de requisição é adicionalmente operativo para armazenar uma identificação da primeira enti- dade em relação à requisição para cotação no registro de identificação de requisição e o transmissor de requisição ainda é operativo para associar pe- lo menos uma resposta à primeira entidade com base na identificação arma- zenada no registro de identificação de requisição e transmitir pelo menos uma resposta com base nisso.

52. Sistema, de acordo com a reivindicação 47, que ainda com- preende um identificador de requisição acoplado ao receptor de requisição, ao transmissor de requisição e ao transmissor de resposta, em que o identi- ficador de requisição é operativo para gerar um código de identificação único não tendo nenhuma relação com a primeira entidade e criar uma relação entre o código de identificação único, a requisição para cotação e a primeira entidade, em que o transmissor de requisição ainda é operativo para trans- mitir o código de identificação único com a requisição para cotação, e ainda em que pelo menos uma resposta inclui o código de identificação único, o transmissor de resposta ainda sendo operativo para transmitir pelo menos uma resposta para a primeira entidade com base no código de identificação único a partir de pelo menos uma resposta e da relação.

53. Sistema, de acordo com a reivindicação 47, que ainda com- preende um gerenciador de risco acoplado ao receptor de requisição e aò receptor de resposta e operativo para armazenar temporariamente um risco de perda com respeito ao primeiro instrumento como entre a primeira enti- dade e pelo menos uma segunda entidade.

54. Sistema, de acordo com a reivindicação 47, em que a requi- sição para cotação ainda especifica um período de tempo o qual pode expi- rar, o sistema ainda compreendendo um processador de expiração de requi- sição acoplado ao receptor de requisição e operativo para determinar quan- do o período de tempo expirou.

55. Sistema, de acordo com a reivindicação 54, em que o perío- do de tempo é especificado pela primeira entidade.

56. Sistema, de acordo com a reivindicação 54, em que o perío- do de tempo é automaticamente especificado pelo processador de expiração de requisição.

57. Sistema, de acordo com a reivindicação 54, em que o pro- cessador de expiração de requisição ainda é operativo para cancelar a re- quisição para cotação mediante a expiração do período de tempo.

58. Sistema, de acordo com a reivindicação 54, em que o pro- cessador de expiração de requisição ainda é operativo para cancelar a cota- ção acionável mediante a expiração do período dé tempo.

59. Sistema, de acordo com a reivindicação 54, em que o pro- cessador de expiração de requisição ainda é operativo para rejeitar pelo me- nos uma resposta, quando pelo menos uma resposta for recebida subse- qüentemente à expiração do período de tempo.

60. Sistema, de acordo com a reivindicação 54, em que o perío- do de tempo é especificado em um ponto específico no tempo.

61. Sistema, de acordo com a reivindicação 54, em que o perío- do de tempo é especificado com o decorrer de uma duração especificada medida a partir de uma origem definida.

62. Sistema, de acordo com a reivindicação 47, em que a cota- ção acionável ainda especifica um primeiro período de tempo o qual pode expirar, o sistema ainda compreendendo um processador de expiração de resposta acoplado ao receptor de resposta e ao transmissor de resposta e operativo para determinar quando o primeiro período de tempo expirou.

63. Sistema, de acordo com a reivindicação 62, em que o primei- ro período de tempo é especificado por pelo menos uma segunda entidade.

64. Sistema, de acordo com a reivindicação 62, em que o primei- ro período de tempo é especificado automaticamente pelo processador de expiração de resposta.

65. Sistema, de acordo com a reivindicação 62, em que o pro- cessador de expiração de resposta é operativo para determinar se a cotação acionável foi aceita e cancelar a cotação acionável mediante a expiração do primeiro período de tempo, quando a cotação acionável não tiver sido aceita antes da expiração do primeiro período de tempo.

66. Sistema, de acordo com a reivindicação 65, em que o trans- missor de resposta ainda é operativo para transmitir uma mensagem de cancelamento para pelo menos uma segunda entidade em resposta ao can- celamento.

67. Sistema, de acordo com a reivindicação 62, em que o pro- cessador de expiração de resposta ainda é operativo para rejeitar pelo me- nos uma resposta quando pelo menos uma resposta for recebida subse- qüentemente à expiração do primeiro período de tempo.

68. Sistema, de acordo com a reivindicação 62, em que o primei- ro período de tempo é especificado como um ponto específico no tempo.

69. Sistema, de acordo com a reivindicação 62, em que o primei- ro período de tempo é especificado com o decorrer de uma duração especi- ficada medida a partir de uma origem definida.

70. Sistema, de acordo com a reivindicação 62, em que a requi- sição para cotação ainda especifica um segundo período de tempo, o qual pode expirar, o sistema ainda compreendendo um processador de expiração de requisição acoplado ao receptor de requisição e ao processador de expi- ração de requisição e operativo para determinar quando o segundo período de tempo expirou e permitir a aceitação da cotação acionável, desde que o primeiro período de tempo não tenha expirado.

71. Sistema, de acordo com a reivindicação 47, em que o recep- tor de requisição ainda é operativo para receber um cancelamento da cota- ção acionável e impedir a aceitação da cotação acionável em resposta a is- to, quando o cancelamento for recebido antes da aceitação.

72. Sistema, de acordo com a reivindicação 47, que ainda com- preende um processador de equilíbrio acoplado ao receptor de requisição e ao receptor de resposta e operativo para determinar a aceitação da cotação acionável.

73. Sistema, de acordo com a reivindicação 72, que ainda com- preende um receptor de aceitação acoplado ao processador de equilíbrio e operativo para receber a aceitação da primeira entidade.

74. Sistema, de acordo com a reivindicação 72, em que o pro- cessador de equilíbrio ainda é operativo para automaticamente aceitar a co- tação acionável.

75. Sistema, de acordo com a reivindicação 74, em que o pro- cessador de equilíbrio ainda é operativo para automaticamente aceitar a co- tação acionável de uma primeira de pelo menos uma resposta a ser recebi- da.

76. Sistema, de acordo com a reivindicação 74, em que o pro- cessador de equilíbrio ainda é operativo para automaticamente aceitar a me- lhor cotação acionável de todas de pelo menos uma resposta a ser recebida.

77. Sistema, de acordo com a reivindicação 72, em que a requi- sição para cotação ainda especifica pelo menos um critério para aceitação de uma cotação acionável em resposta a isso, o processador de equilíbrio ainda operativo para determinar um grau até o qual pelo menos um critério é satisfeito pela cotação acionável de pelo menos uma resposta recebida.

78. Sistema, de acordo com a reivindicação 77, em que pelo menos um critério inclui, pelo menos um, dentre tempo de vida de requisi- ção, quantidade, preço máximo, preço mínimo, pedido de compra, pedido de venda, ou combinações dos mesmos.

79. Sistema, de acordo com a reivindicação 77, em que o recep- tor de resposta recebe uma pluralidade de respostas de uma pluralidade de segundas entidades do subconjunto, cada uma da pluralidade de respostas identificando a requisição para cotação e incluindo uma cotação acionável em resposta a isso, o processador de equilíbrio ainda sendo operativo para determinar pelo menos uma das cotações acionáveis da pluralidade de res- postas a qual mais bem satisfaz a pelo menos um critério.

80. Sistema, de acordo com a reivindicação 79, em que o pro- cessador de equilíbrio ainda é operativo para determinar pelo menos duas cotações acionáveis da pluralidade de respostas que mais bem satisfazem a pelo menos um critério e alocar uma aceitação dentre pelo menos duas co- tações acionáveis.

81. Sistema, de acordo com a reivindicação 80, em que o pro- cessador de equilíbrio ainda é operativo para notificar a segunda entidade associada às cotações acionáveis não aceitas que as cotações acionáveis não aceitas não foram aceitas.

82. Sistema, de acordo com a reivindicação 72, que ainda com- preende um transmissor de bolsa acoplado ao processador de equilíbrio e operativo para transmitir a requisição para cotação e a cotação acionável aceita para uma bolsa mediante uma aceitação.

83. Sistema, de acordo com a reivindicação 47, em que a requi- sição para cotação ainda especifica uma intenção da primeira entidade para um dentre comprar ou vender o primeiro instrumento, o transmissor de re- quisição sendo operativo ainda para transmitir a requisição para cotação sem a identificação da intenção.

84. Sistema, de acordo com a reivindicação 47, que ainda com- preende um gerenciador de requisição acoplado ao receptor de requisição e operativo para permitir que a primeira entidade gerencie uma pluralidade de requisições para cotação concorrentemente pendentes.

85. Sistema, de acordo com a reivindicação 47, que ainda com- preende um gerenciador de resposta acoplado ao receptor de resposta e operativo para permitir que pelo menos uma segunda entidade gerencie uma pluralidade de cotações acionáveis concorrentes.

86. Sistema, de acordo com a reivindicação 47, em que pelo menos uma resposta é ainda caracterizada por tempo de transmissão e um tempo de recebimento diferente do tempo de transmissão, o sistema ainda compreendendo um processador de sincronização acoplado ao receptor de resposta e operativo para compensação da diferença entre o tempo de transmissão e o tempo de recebimento.

87. Sistema para negociação de instrumentos financeiros dentre uma pluralidade de entidades acopladas a uma rede e participando em um mercado, o sistema compreendendo: um meio para recebimento de uma requisição para cotação atra- vés da rede de uma primeira entidade da pluralidade de entidades, a requisi- ção para cotação identificando a primeira entidade e especificando um inte- resse em negociar um primeiro instrumento; um meio para transmissão da requisição para cotação através da rede para pelo menos um subconjunto da pluralidade de entidades sem a identificação da primeira entidade; um meio para recebimento da, pelo menos uma, resposta atra- vés da rede de pelo menos uma segunda entidade do subconjunto, pelo me- nos uma resposta identificando a requisição para cotação e incluindo uma cotação acionável em resposta a isto; e um meio para transmissão através da rede de pelo menos uma resposta exclusivamente para a primeira entidade.

88. Sistema para negociação de instrumentos financeiros dentre uma pluralidade de entidades acopladas a uma rede e participando em um mercado, o sistema compreendendo um processador, uma memória acopla- da ao processador e uma interface de rede acoplada ao processador e à rede e operativa para facilitar as comunicações entre eles, o sistema ainda compreendendo: uma primeira lógica armazenada em uma memória e executável pelo processador para receber uma primeira comunicação compreendendo uma requisição para cotação através da rede a partir de uma primeira enti- dade da pluralidade de entidades, a requisição para cotação identificando a primeira entidade e especificando um interesse na negociação de um primei- ro instrumento; uma segunda lógica acoplada à primeira lógica, armazenada na memória e executável pelo processador para a transmissão de uma segunda comunicação compreendendo a requisição para cotação através da rede para pelo menos um subconjunto da pluralidade de entidades, sem a identi- ficação da primeira entidade; uma terceira lógica armazenada na memória e executável pelo processador para receber pelo menos uma terceira comunicação compreen- dendo uma resposta através da rede a partir de pelo menos uma segunda entidade do conjunto, a resposta identificando a requisição para cotação e incluindo uma cotação acionável em resposta a isto; e uma quarta lógica acoplada à terceira lógica, armazenada na memória e executável pelo processador para transmitir através da rede uma quarta comunicação compreendendo a resposta exclusivamente para a pri- meira entidade.