Sistema de confirmação do comércio eletrônico

Sistema de confirmação de comércio eletrônico
De acordo com a SEC Rule 10b-10, as corretoras são obrigadas a fornecer uma comunicação escrita ao cliente de corretagem para cada transação de corretagem executada em nome desse cliente na conta de corretagem do cliente. A comunicação escrita é chamada de Confirmação de Comércio ou Confirmação de Comércio.
Os Confirmações de Comércio geralmente fornecem ao cliente os seguintes detalhes relacionados ao seu comércio de corretagem:
Lateral - Comprar ou Vender A Segurança específica Comprada ou Vendida A Quantidade Comprada ou Vendida O Preço de Execução Comercial O Mercado ou Câmbio em que a operação foi executada A Capacidade na qual a corretora atuou em nome do cliente - como Corretora ou como Agente. Principal Montante da transação Todas as Comissões, Juros acumulados ou outros encargos de taxas na transação O Valor Líquido ou a transação - este é o valor a ser pago ou recebido pelo cliente e é igual ao Valor do Principal + ou - qualquer Comissão associada, Juros ou taxas O número da conta de corretagem do cliente O tipo de conta do cliente - Dinheiro, Margem, Curto, DVP Qualquer outra descrição de segurança especial ou divulgações comerciais exigidas conforme necessário. Por exemplo, para negociações de títulos de renda fixa, a confirmação pode fornecer descrições de segurança adicionais relativas ao Rendimento ao Vencimento ou Rendimento à Chamada. Outros regulamentos exigem que a empresa divulgue se o comércio era uma venda curta, solicitada ou não solicitada, e se o preço de transação indicado pelo cliente fosse um preço médio.
Confirmação Confirmar.
Existem várias opções disponíveis para a corretora para entrega de confirmações comerciais ao cliente corretor. As opções incluem:
O Sistema Postal dos Estados Unidos - USPS Electronic Delivery.
A entrega através do sistema postal dos EUA é o método tradicional de entrega de comércio confirma ao cliente corretor. As confirmações de "cópias rígidas" ou de troca de papel são impressas pela empresa de corretagem - ou pelo seu fornecedor de confirmação designado - e enviadas para o cliente utilizando o fluxo postal dos EUA.
A confirmação do comércio é a comunicação comercial oficial da empresa de corretagem para seu cliente. Após o recebimento da confirmação de comércio, o cliente espera efetuar o pagamento de quaisquer títulos adquiridos. É, portanto, do melhor interesse da corretora acelerar a entrega da confirmação comercial ao cliente. A entrega mais rápida da confirmação comercial aos resultados do cliente é um recebimento mais rápido do pagamento do cliente.
Para minimizar a quantidade de tempo entre a impressão da confirmação do comércio e a sua recepção pelo cliente de corretagem - as empresas de corretagem podem utilizar os sites de impressão distributiva. Os sites de impressão distributiva são centros de impressão que são geograficamente dispersos em todos os estados desatados e / ou em outros países ou regiões. Os clientes de corretagem recebem confirmações de comércio impressas no site de impressão distributiva mais próximo do endereço de correspondência.
Os registros de confirmação de comércio para transações executadas em nome de um cliente são transmitidos eletronicamente para o centro de impressão distributiva mais próximo da residência do cliente. A confirmação do comércio do cliente é impressa no local de impressão local e depositada no sistema de correspondência local. Isso reduz o tempo de trânsito entre o centro de impressão e o cliente.
Por exemplo, um cliente de corretagem que reside em San Diego, Califórnia, receberia sua confirmação do site de impressão distributiva em Los Angeles. Na outra costa, um cliente em East Rutherford, Nova Jersey pode receber sua confirmação do site de impressão distributiva em Nova York.
Entrega eletrônica de confirmações comerciais.
Para acelerar o processo de entrega de confirmação, as empresas de corretagem geralmente utilizam métodos eletrônicos de entrega, tais como:
As confirmações de envio de fax para clientes são um processo tedioso que exige tempo para a geração da (s) confirmação (ões) de comércio e o envio por fax da (s) confirmação (ões) para os múltiplos clientes da empresa. Como tal, as confirmações de envio de fax geralmente não são o método preferido para confirmar a entrega e, normalmente, apenas são utilizadas em circunstâncias especiais ou pedidos de serviço ao cliente.
Confirmação de ID são confirmações de comércio eletrônico geradas pelo Sistema de Entrega Institucional (ID) da Depository Trust Company. Com o consentimento do cliente, as corretoras podem substituir a confirmação de identificação pela confirmação enviada por correio e ainda satisfazer a regra SEC 10b-10.
Para receber uma ID Confirme que o cliente de corretagem deve ser um membro do Sistema de Identificação do Depositário. A grande maioria dos membros de identidade são grandes instituições financeiras - tais como fundos mútuos, companhias de seguros, planos de pensão, etc. Portanto, a confirmação de confirmação de identidade não é um método de entrega viável para os clientes de varejo da corretora - que geralmente não atendem aos grandes requisitos de capital que são necessários para se tornarem membros do Sistema ID.
A confirmação da confirmação da entrega via e-mail é uma alternativa relativamente nova para a indústria de corretagem. Esta alternativa resultou tanto do tremendo crescimento da negociação de valores mobiliários na Internet quanto da recente aprovação da SEC deste novo método de entrega.
Normalmente, o cliente corretor recebe um e-mail de sua corretora alertando-os para a criação de uma nova confirmação comercial. O e-mail contém um link de hipertexto que direciona o cliente para a imagem eletrônica da confirmação de comércio no site da empresa. O cliente então usa seu navegador da Web para ver a confirmação do comércio.
As regras SEC exigem que, se a confirmação de e-mail não for visualizada pelo cliente dentro de um período de tempo designado, uma confirmação de papel seja gerada e enviada ao cliente através do Sistema Postal dos EUA.
Com o consentimento do cliente, a corretora pode substituir o e-mail confirmado pela confirmação por correspondência e ainda satisfazer a regra SEC 10b-10.

Interpretação:
Confirmação e Afirmação de Negociações de Valores; Coincidindo.
COMISSÃO DE SEGURANÇA E CÂMBIO.
17 CFR PARTE 241.
(LANÇAMENTO NO 34-39829; NÚMERO DE ARQUIVO S7-10-98)
CONFIRMAÇÃO E AFIRMAÇÃO DE NEGOCIOS DE VALORES MOBILIÁRIOS; COINCIDINDO.
AGÊNCIA: Comissão de Valores Mobiliários.
AÇÃO: Liberação Interpretativa; Pedido de comentários.
RESUMO: A Securities and Exchange Commission ("Commission") está publicando sua interpretação de que um "correspondência" e "quot; serviço que compara informações de comércio de títulos de um corretor e o cliente do corretor é uma função de agência de compensação. A Comissão também está solicitando comentários sobre duas abordagens possíveis para fornecer alívio isento do regulamento completo da agência de compensação para fornecedores de confirmação de comércio eletrônico qualificado ("ETC") que se enquadram na interpretação da agência de compensação da Comissão porque fornecem um serviço de correspondência .
DATAS: A interpretação contida na Seção III desta versão é efetiva (insira a data de publicação no Federal Register).
Os comentários devem ser enviados em ou antes (inserir data 60 dias após a publicação no Federal Register).
ENDEREÇOS: As pessoas interessadas devem enviar comentários em triplicado a Jonathan Katz, Secretário, Comissão de Valores Mobiliários, 450 5th Street, N. W., Washington, DC 20549-6009. Os comentários podem ser enviados eletronicamente no seguinte endereço de e-mail: rule-commentssec. gov. Todas as letras de comentários devem se referir ao Arquivo No. S7-10-98; este número de arquivo deve ser incluído na linha de assunto se o E-mail for usado. Todos os comentários recebidos estarão disponíveis para inspeção pública e cópia na Sala de Referência Pública da Comissão, 450 5th Street, NW, Washington, DC 20549. As cartas de comentários enviadas eletronicamente serão postadas no site da Internet da Comissão (sec. gov).
PARA MAIS INFORMAÇÕES CONTATO: Jerry W. Carpenter, Diretor Adjunto; Jeffrey Mooney, advogado especial; ou Theodore R. Lazo, advogado; em 202 / 942-4187, Escritório de Gestão e Controle de Riscos, Divisão de Regulação do Mercado, Comissão de Valores Mobiliários, Washington, D. C. 20549.
INFORMAÇÃO SUPLEMENTAR:
Recentemente, a Bolsa de Valores de Nova York ("NYSE"), a Associação Nacional de Concessionários de Valores ("NASD") e a Junta de Regulamentação de Valores Mobiliários ("MSRB") (coletivamente "SROs") apresentaram mudanças nas regras propostas nos termos da Secção 19 (b) do Securities Exchange Act de 1934 ("Exchange Act") 1 para alterar as suas regras relativas ao processamento pós-negociação de transacções executadas pelos seus membros. Os SROs & # 146; as regras atuais exigem que seus membros do corretor-comerciante usem as instalações de um depositário de valores mobiliários 2 para confirmação eletrônica e afirmação de transações onde o corretor oferece entrega versus pagamento ("DVP") ou recebimento versus pagamento (& quot , RVP ") 3 privilégios para o cliente (" regras de confirmação SRO "). 4 Como uma questão prática, as regras de confirmação do SRO exigem que os intermediários utilizem o sistema de entrega institucional ("ID & quot;)" da Corporação Depositário Trust ("DTC") porque é o único serviço de confirmação / afirmação oferecido por um depósito de valores mobiliários. 5 De acordo com as alterações propostas às regras de confirmação do SRO, os intermediários serão autorizados a usar entidades que não sejam agências de compensação registradas para a confirmação e afirmação de transações RVP / DVP, desde que as entidades sejam vendedores ETC qualificados conforme definido pelo SRO regras. Um intermediário de fornecedor de ETC qualificado apenas transmitirá informações entre as partes para uma troca e as partes confirmarão e confirmarão a precisão das informações.
A Comissão entende que o próximo passo na evolução do processamento pós-comercial será o desenvolvimento de serviços de correspondência. & quot; Matching & quot; é o termo usado para descrever o processo pelo qual um intermediário reconcilia as informações comerciais do corretor e do cliente para gerar uma confirmação confirmada, que é usada para liquidar o comércio.
A Comissão é de opinião que a correspondência constitui uma função de agência de compensação na acepção da definição da agência de compensação nos termos da Secção 3 (a) (23) da Lei de Câmbio. 6 Especificamente, a correspondência constitui "comparação de dados respeitantes aos termos de liquidação de transações de valores mobiliários". A Comissão conclui que a correspondência está tão intimamente ligada ao processo de liquidação e liquidação que é diferente, não só em grau, mas também diferente em espécie, do processo atual de confirmação e afirmação. O objetivo deste lançamento é buscar comentários sobre o conceito de proporcionar alívio de isenção, quer através do registro como agências de compensação sujeitas a requisitos reduzidos ou através da concessão de uma isenção condicional de registro para fornecedores ETC qualificados que ofereçam um serviço correspondente.
A. Processo de Confirmação e Afirmação.
O processo de confirmação / afirmação refere-se à transmissão de mensagens entre corretores, investidores institucionais e bancos depositários sobre os termos de uma negociação executada para o investidor institucional. Como os negócios de investidores institucionais envolvem montantes de dinheiro maiores, montantes maiores de títulos, mais festas e mais etapas entre a entrada de ordens e a liquidação final, os negócios institucionais geralmente são mais complexos que as transações de varejo.
1. Confirmação usando o sistema ID.
Os componentes típicos do "lado do cliente" A solução de um comércio institucional sob as atuais regras de confirmação do SRO está ilustrada na Figura 1. 7.
Normalmente, um comércio institucional começará com o gerente de investimento da instituição fazendo uma ordem com o corretor. Depois que o intermediário executa o comércio, o corretor avaliará a instituição dos detalhes de execução. Isso é comumente referido como notificação de execução (passo 1 da Figura 1). A instituição então aconselha o corretor em relação à forma como o comércio deve ser alocado entre suas contas (passo 2 da Figura 1). 8 O corretor envia os dados comerciais para DTC (passo 3 da Figura 1).
Em seguida, a DTC adiciona a transação ao banco de dados comercial do ID, atribui um número de controle de ID e encaminha uma confirmação eletrônica para a instituição, o corretor, o agente de liquidação da instituição e outras partes interessadas (por exemplo, administradores, administradores de planos, ou bancos correspondentes) (passo 4 da Figura 1). A instituição analisa a confirmação de precisão. Se for preciso, a instituição ou o seu agente de afirmação designado afirma o comércio através do sistema ID (passo 5 da Figura 1). O DTC gera uma confirmação confirmada e o envia ao corretor e ao agente de liquidação da instituição (passo 6 da Figura 1). 9 Neste ponto, o comércio é enviado para o sistema de liquidação do DTC (por exemplo, o sistema de identificação não é um sistema de liquidação na medida em que nenhum dinheiro ou valores mobiliários se movem através dele) e deve ser autorizado pela parte obrigada a entregar os valores mobiliários (ou seja, a parte vendedora) ou o agente de liquidação antes da liquidação (etapas 7 e 8 da Figura 1). & quot; Quality Control & quot; envolve o monitoramento e produção de DTC de vários relatórios para reguladores e usuários do sistema de identificação que mostram coisas como quando uma confirmação foi enviada e a afirmação foi recebida (passo 9 da Figura 1).
2. Confirmação usando um fornecedor de ETC qualificado.
Sob as mudanças de regras SRO propostas, um fornecedor ETC qualificado pode ser usado para o processo de confirmação / afirmação. O corretor comercial envia dados comerciais para o fornecedor ETC qualificado que gera e envia uma confirmação para a instituição (etapas 3 e 4 da Figura 1). Depois de rever a confirmação, a instituição envia uma afirmação ao corretor através das instalações do fornecedor ETC qualificado (passo 5 da Figura 1). Em algum momento desse processo, o fornecedor ETC qualificado encaminha a confirmação para DTC em um formato de sistema ID para que DTC possa atribuir um número de controle ID ao comércio. DTC envia a confirmação com o número de controle de volta para o fornecedor de ETC qualificado, e o fornecedor de ETC qualificado fornece o número de controle para o corretor e a instituição. Após o recebimento da afirmação da instituição, o vendedor ETC qualificado envia a confirmação confirmada com o número de controle ID para DTC no formato do sistema ID. Nesse processo, um fornecedor ETC qualificado apenas transmite informações entre as partes para o comércio e as partes verificam a precisão da informação.
Os componentes da liquidação do lado do cliente de um comércio institucional através de um "correspondência" O sistema está ilustrado na Figura 2.
& quot; Matching & quot; é o termo que é usado para descrever o processo pelo qual um intermediário compara a submissão de dados comerciais do corretor (passo 2 da Figura 2) com as instruções de alocação da instituição (passo 1 da Figura 2) para determinar se as duas descrições do comércio concordam . 10 Se os dados comerciais e as instruções de alocação da instituição coincidem, uma confirmação confirmada é produzida (passo 3 da Figura 2). Isso eliminaria as etapas separadas de produzir uma confirmação (passo 4 da Figura 1) para a instituição revisar e afirmar (passo 5 da Figura 1). Neste ponto, o comércio entra no processo de liquidação do DTC, mas deve ser autorizado pelo agente da parte de entrega antes da liquidação (etapas 4 e 5 da Figura 2). 11.
III. CORRESPONDÊNCIA COMO FUNÇÃO DA AGÊNCIA DE CLEARING.
A seção 3 (a) (23) (A) do Exchange Act define uma agência de compensação amplamente como "qualquer pessoa que atue como intermediária na realização de pagamentos ou entregas ou ambas em conexão com transações em valores mobiliários ou que forneça facilidades para comparação de dados relativos aos termos de liquidação de transações de valores mobiliários, para reduzir o número de liquidações de transações de valores mobiliários ou para a alocação de responsabilidades de liquidação de títulos. & quot; 12 A Seção 17A do Exchange Act e a Regra 17Ab2-1 exigem que qualquer pessoa que se envolva em qualquer dessas funções inscreva-se na Comissão como uma agência de compensação ou obtenha uma isenção do registro. 13.
Com base na linguagem, finalidades e políticas da Seção 3 (a) (23) e 17A, a Comissão conclui que um intermediário que captura informações comerciais de um comprador e um vendedor de valores mobiliários e realiza uma reconciliação ou correspondência independente dessa informação é fornecendo instalações para a comparação de dados dentro do escopo do Exchange Act, seção 3 (a) (23). 14 Como resultado, o intermediário está executando uma função de agência de compensação. Consequentemente, sob esta interpretação, apenas uma entidade que é registrada como uma agência de compensação ou está isenta de tal registro pode fornecer um serviço correspondente.
O histórico legislativo das alterações aos actos de valores mobiliários de 1975 ("Emendas de 1975") apoia esta interpretação estatutária 15, incluindo os fins de estabelecer um sistema nacional de apuramento e liquidação e o alcance da autoridade concedida à Comissão. Além disso, considerar um serviço de correspondência como uma função de agência de compensação é consistente com os propósitos do regulamento do Exchange Act do sistema de liquidação e liquidação. O Congresso considerou o sistema de apuramento e liquidação no início da década de 1970 como inadequado e, nas Alterações de 1975, dirigiu a Comissão para facilitar o desenvolvimento de um sistema nacional de liquidação e liquidação melhorado. O Congresso articulou os objetivos deste sistema nacional na Seção 17A do Exchange Act, 16 e deu à Comissão a autoridade e a responsabilidade de regular, coordenar e direcionar as operações de todas as pessoas envolvidas no processamento de transações de valores mobiliários para o objetivo de um sistema nacional para a pronta e exata liquidação e liquidação de transações de valores mobiliários. 17 O Congresso especificamente se recusou a abordar os méritos de qualquer sistema particular ou a ditar a forma de um sistema nacional de liquidação e liquidação. 18 Em vez disso, o Congresso reconheceu que "técnicas de processamento e comunicação de dados" envolvidos nos processos de liquidação e liquidação continuariam a evoluir. 19 Como resultado, a Comissão recebeu ampla autoridade sobre o sistema de liquidação e liquidação e um amplo poder discricionário para determinar quais atividades se enquadram na função da agência de compensação que desencadeia o requisito de registro como agência de compensação.
De fato, o processo de liquidação e liquidação para os negócios institucionais evoluiu dramaticamente. Quando as emendas de 1975 foram promulgadas, o processamento de negócios institucionais foi realizado diretamente entre o corretor e a instituição com pouca ou nenhuma automação. Os SROs & # 146; as regras que exigem o uso da confirmação eletrônica e a afirmação de negócios institucionais foram adotadas em resposta ao aumento da complexidade dos negócios institucionais e à necessidade de automatizar o processo. Hoje, o volume de negócios institucionais cresceu até certo ponto que agora representam uma grande parte da atividade de negociação nos mercados de valores mobiliários dos EUA. 20 Devido ao aumento do volume e da complexidade dos negócios institucionais, praticamente todos eles são processados ​​por meio de sistemas eletrônicos.
A correspondência é inextricavelmente interligada com o processo de liquidação e liquidação. Um fornecedor que fornece um serviço de correspondência irá comparar ativamente as informações de comércio e alocação e emitirá a confirmação confirmada que será usada na liquidação da transação. 21 Além disso, o correspondente aborda duas áreas que a Comissão e o setor de valores mobiliários consideram crítico para manter um sistema de liquidação e liquidação sólida: redução de erros e redução da quantidade de tempo de liquidação.
Conforme mencionado acima, a combinação combina certas etapas no processo de confirmação e afirmação e, portanto, pode ajudar a reduzir erros. A combinação efetiva também será crítica em qualquer esforço para encurtar o ciclo de liquidação. 22 Ao mesmo tempo, o correspondente concentra o risco de processamento na entidade que desempenha correspondência em vez de dispersar esse risco de forma mais ampla para os corretores e seus clientes institucionais. Em particular, a correspondência elimina um passo de afirmação separado que permitiria a detecção de erros que poderiam atrasar a liquidação ou fazer com que o comércio falhasse. 23.
Por conseguinte, a Comissão considera que uma entidade que fornece correspondência teria um impacto significativo no sistema nacional de liquidação e liquidação. A desagregação da capacidade de um sistema de correspondência para comparar com precisão as informações comerciais de centenas de instituições e corretores envolvendo milhares de transações e milhões de dólares de valores mobiliários podem resultar em uma falha sistêmica generalizada no sistema nacional de liquidação e liquidação . 24 Sem qualquer autoridade reguladora sobre os vendedores correspondentes, a Comissão teria apenas capacidade limitada de se proteger contra tal falha. O Congresso concedeu à Comissão o poder amplo de estabelecer um sistema de regulamentação centralizado sobre o sistema nacional de liquidação e liquidação, a fim de evitar que tal situação ocorra. 25 Dado o importante papel desempenhado pelos serviços de correspondência e o alcance da definição, a Comissão considera que alguma forma de regulamentação é adequada para assegurar o apuramento e a liquidação rápidos e precisos de valores mobiliários. 26.
IV. POSIÁTICAS APROXIMAÇÕES REGULADORAS.
Mesmo que os serviços de correspondência se enquadrem na definição de agência de compensação, a Comissão considera preliminarmente que uma entidade que limita as funções da agência de compensação ao fornecimento de serviços de correspondência não precisa estar sujeita à totalidade da regulamentação da agência de compensação. A Comissão dispõe de ampla autoridade isenta nos termos da Secção 17A. A Secção 17A (b) (1) autoriza a Comissão a isentar (condicional ou incondicionalmente) qualquer agência de compensação de qualquer disposição da Seção 17A se a Comissão considerar que essa isenção é consistente com o interesse público, a proteção dos investidores e os propósitos de Seção 17A.
Duas abordagens alternativas podem fornecer uma estrutura regulatória apropriada para entidades que oferecem facilidades de correspondência: registro limitado ou isenção condicional. De acordo com qualquer abordagem, apenas os requisitos regulamentares que a Comissão considere necessários e adequados para alcançar os objetivos da Seção 17A serão aplicáveis ​​a uma entidade que forneça uma facilidade de correspondência. 27 A alternativa de registro limitado é uma "escala de trás" abordagem, que registraria o provedor de serviços de correspondência como uma agência de compensação, ao mesmo tempo que fornece isenções dos requisitos da agência de compensação individual. A alternativa de isenção condicional é um "bloco de construção" abordagem, que isentaria a entidade do registro da agência de compensação sujeita às condições apropriadas. 28 De acordo com qualquer das abordagens, a Comissão publicaria para comentar um aviso do pedido do vendedor de ETC qualificado para registro limitado ou isenção condicional, incluindo os termos propostos do registro ou isenção, antes de aprovar o pedido. 29.
A Comissão solicita aos comentadores & # 146; As opiniões sobre se o registro limitado da agência de compensação ou a isenção condicional do registro da agência de compensação é a melhor alternativa para regular os fornecedores de ETC qualificados que fornecem serviços de correspondência. Uma ou ambas as alternativas propostas fornecem um método prudente para garantir a segurança e a solidez do sistema nacional de liquidação e liquidação de transações de valores mobiliários e o desenvolvimento contínuo de mecanismos de apuramento vinculados e coordenados sujeitos a padrões uniformes? Em termos gerais, quais os requisitos da agência de compensação de acordo com a Seção 17A (b) seriam necessários e adequados para serviços de correspondência e quais não? Existem outras alternativas pelas quais a Comissão poderia manter a supervisão da correspondência por vendedores ETC qualificados que assegurem a segurança e solidez do sistema nacional de liquidação e liquidação?
Lista de assuntos em 17 CFR Part 241.
Alteração do Código de Regulamentos Federais.
Pelas razões expostas no preâmbulo, o Capítulo 17 do Título 17 do Código de Regulamentos Federais é alterado conforme estabelecido abaixo:
PARTE 241 - LANÇAS DE INTERPRETAÇÃO RELATIVAS À LEI DE TROCA DE VALORES MOVIMENTOS DE 1934 E REGRAS E REGULAMENTOS GERAIS.
A parte 241 é alterada adicionando a versão nº 34-39829 e a data de lançamento de 6 de abril de 1998 à lista de lançamentos interpretativos.

Sistema de confirmação de comércio eletrônico
um mecanismo de interface de dados que lê os arquivos de dados e os campos de dados;
um motor correspondente acoplado ao mecanismo da interface de dados que corresponde aos campos de dados selecionados nos arquivos de dados e atribui um status ao comércio com base nos campos de dados enviados; e um banco de dados acoplado ao mecanismo correspondente que armazena os dados de comércio resultantes para confirmar o comércio se todos os detalhes principais nos dois arquivos de dados coincidirem.
correspondência indicando que todos os campos de dados correspondem;
incomparável indicando que os campos de dados principais correspondem, mas pelo menos um outro campo de dados não;
pendente indicando que um ou mais campos de dados principais não correspondem;
alegado indicando que a contra-parte alegou ter feito um comércio; e cancelou indicando que o comércio foi retirado.
envio de dados do comerciante, incluindo diferentes campos de dados relacionados ao comércio através de uma interface eletrônica;
envio de dados do contador, incluindo diferentes campos de dados relacionados, ao comércio através de uma interface eletrônica;
comparando os campos de dados enviados pelo comerciante e pelo contador para determinar quais campos correspondem;
confirmando o comércio se determinados campos de dados corresponderem.
inserindo campos de dados em um registro de dados contido em um arquivo de dados, em que a apresentação dos dados do comerciante e os dados do contador são realizados enviando o arquivo de dados; e traduzindo os campos de dados no arquivo de dados para um formato de dados padrão para um tipo de comércio específico.
correspondência indicando que todos os campos de dados correspondem;
incomparável indicando que os campos de dados principais correspondem, mas pelo menos um outro campo de dados não;
pendente indicando que um ou mais campos de dados principais não correspondem;
alegado indicando que uma contraparte apresentou o comércio; e cancelou indicando que o comércio foi retirado.
alterando o acordo mestre para permitir a confirmação eletrônica;
conectando eletricamente o comerciante e o contador a um motor correspondente;
envio de dados do comerciante, incluindo campos de dados diferentes relativos a uma troca para o mecanismo correspondente;
envio de dados do contador, incluindo diferentes campos de dados relacionados ao comércio com o motor correspondente; e confirmando o comércio, combinando determinados campos de dados.
uma interface de dados para ler dados do comerciante, incluindo diferentes campos de dados relacionados aos dados do comércio e do contador, incluindo diferentes campos de dados relacionados ao comércio através de uma interface eletrônica;
um meio de correspondência para comparar os campos de dados enviados pelo comerciante e a parte contadora para determinar quais campos correspondem; e um meio de confirmação para confirmar o comércio se determinados campos de dados corresponderem.
ADVOGADO DOCKET NO. 02045461 SISTEMA DE CONFIRMAÇÃO DE NEGOCIAÇÃO ELETRÔNICA.
ANTECEDENTES DA INVENÇÃO.
O comércio tradicional de commodities ou instrumentos financeiros, como ações e 12 títulos, ocorreu em mercados onde os comerciantes oferecem diversos produtos a preços diferentes. Essas negociações foram realizadas usando sinais de mão e o papel foi usado para finalizar o 14 contrato comercial real. Com o advento dos computadores, os negócios mais complexos e mais rápidos podem ser feitos integrando o poder de computação. Além disso, o crescimento da Internet 16 e outros sistemas de comunicações eletrônicas mudou o campo de negociação para além do comércio. Com a crescente complexidade da economia, uma maior diversidade de 18 produtos financeiros básicos podem ser oferecidos, incluindo derivativos.
As derivadas são definidas como um contrato financeiro cujo valor depende dos valores de um ou mais ativos subjacentes ou índices de valores de ativos. Atualmente, os derivativos são negociados em patentes.
ADVOGADO DOCKET NO. 02045461 intercâmbios tradicionais que podem incluir futuros ou opções em commodities que variam de 2 barrigas de porco a preços cambiais. Recentemente, os derivados também foram negociados no mercado de venda livre (OTC) definido pelas transações por grandes instituições financeiras, como 4 bancos comerciais ou companhias de seguros. Esses derivativos podem incluir swaps, opções, limites, andares, corredores, etc. derivados de taxas de juros, moedas estrangeiras, ações e 6 outras commodities ou instrumentos financeiros.
Os derivados da bolsa são estruturados com termos padrão, como tamanho do contrato, 8 vencimento, data de validade, etc., estabelecidos por uma troca como a Chicago Board of Trade.
Além disso, os negócios de derivativos de câmbio e seus dados de suporte são enviados a uma câmara de compensação de terceiros para liquidação. Em contraste, os derivados OTC são mais flexíveis porque nenhum dos termos comerciais de um derivado OTC é padronizado. Além disso, 12 a liquidação do comércio ocorre diretamente através das partes comerciais, já que nenhuma casa de compensação de terceiros existe por causa da diversidade de diferentes derivativos.
14 Uma marlina emergente de produtos derivados é no campo da energia. Com a desregulamentação da indústria de energia, há uma diversidade muito maior de 16 geradores de energia com diferentes tipos de fontes de energia, como gás natural, petróleo, eletricidade e energia solar. Com fontes de energia tão diversas e fornecedores, um marlcet tem axisen 18 na negociação das commodities de energia entre esses produtores. Vários instrumentos financeiros e físicos derivados, tais como swaps, opções ou spreads, foram formulados por vários players no mercado de energia. Os jogadores neste mercado variam de patentes tradicionais.
ADVOGADO DOCKET NO. 02045461 empresas comerciais para empresas de energia. Como muitos mercados financeiros, a tecnologia faz 2 acessos ao mercado de derivativos de energia sem receita muito maior.
Os comerciantes no mercado de energia OTC geralmente concordam com preços e termos com 4 outros contadores comerciais para um determinado tipo de derivativo em um produto energético, como um swap de gás natural. Este tipo de comércio envolve certos termos comuns, como 6 condições de pagamento e pagamento. O comércio pode ser feito diretamente com uma contraparte, ou por telefone, ou mais recentemente, através de uma plataforma eletrônica como a Internet.
Esses negócios 8 são registrados pelos comerciantes em seus cadernos comerciais e os dados comerciais são inseridos diretamente nos sistemas de captura de dados comerciais da empresa. Esses sistemas geram documentos de confirmação e dados de resumo relacionados ao comércio.
Como outros derivados OTC, os derivados de energia não possuem um sistema uniforme de confirmação de termos uma vez que um comércio é feito entre as partes.
Assim, quando um comércio é feito, as partes devem confirmar os termos do comércio. Ambos os comerciantes registram os 14 detalhes do comércio em um caderno comercial e insere os dados diretamente no sistema de captura comercial da empresa. O sistema de captura comercial da empresa imprime a confirmação de 16 documentos que são revisados ​​e enviados para a outra parte. Isso normalmente ocorre ao enviar por fax os documentos de confirmação para a outra parte. A clerk then checks the terms of 18 the received confirmation documents against the recorded alleged trade in the trade noteboolc and the data output of the receiving party's own trade capture system.
Information such as the buyer and seller, purchase or sale, product, instrument, delivery point, price, delivery terms, etc. must match. After a clerk reviews the trade, any PATENT.
ATTORNEY DOCKET NO. 02045461 discrepancies must be reported to the trading counter party and a reconciliation must be 2 made based on the recorded information. When it is confirmed that the information is accurate, the contracts are then signed and exchanged. Thus, the amount of time 4 necessary for confirming the trade takes much longer then the trade itself.
Even a trade which is correctly executed by both parties can take days to be fully confirmed. Errors 6 prolong the process.
However, other errors are possible since clerlcs must examine and confirm numerous trades with often different forms for each derivative product. The confirmation problems resulting in much greater costs and decreased efficiencies. In fact, 1.
% of derivatives trades contain errors at the time of entry into a trade capture system. Many OTC derivatives are governed by a model Master Agreement endorsed by the 12 International Swaps and Derivatives Association ("ISDA"). While the master agreement does make certain reconciliation more efficient, it must be modified for each specific 14 OTC derivative product and the terms must still be manually examined in order to settle the trades.
16 Thus, there is a need for an automated confirmation system for OTC.
derivative products. There is yet another need for a system which can standardize confirmation of 18 OTC derivatives. There is a need for a confirmation system which allows the rapid entry and processing of trade data. There is also a need for a system which allows a user to summarize trades for a certain period to determine which trades have' irregularities.
ATTORNEY DOCKET NO. 02045461 There is a further need for a trading confirmation system which will match data relating 2 to fields and categorize the trades to determine which trades are confirmed.
Another aspect is a method of electronically confirming trading of financial 16 products, which include data fields that are agreed upon between a trader and a counter party. Trader data is submitted, including different data fields relating to the trade via an 18 electronic interface. Counter party data is submitted including different data fields relating to the trade via an electronic interface. The data fields submitted by the trader and the counter party are compared to determine which fields match. The trade is confirmed if certain data fields match.
ATTORNEY DOCKET NO. 02045461 Another aspect is a method of electronically confirming trades of financial 2 products between a party and a counter party having a master agreement goveniing the trades of the financial products. The master agreement is amended to allow electronic 4 confirmation. The trader and the counter party are both connected electronically to a matching engine. Trader data, including different data fields relating to a trade, is 6 submitted to the matching engine. Counter party data, including different data fields relating to the trade, is submitted to the matching engine. The trade is confirmed by 8 matching certain data fields.
It is to be understood that both the foregoing general description and the following detailed description axe not limiting but are intended to provide further explanation of the invention claimed. The accompanying drawings, which axe 12 incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the method and system of the invention.
Together 14 with the description, the drawings serve to explain the principles of the invention.
BRIEF DESCRIPTION OF DRAWINGS.
16 These and further aspects and advantages of the invention will be discussed more in detail hereinafter with reference to the disclosure of preferred embodiments, and in 18 particular with reference to the appended Figures wherein:
FIG. 1 is a block diagram of a confirmation system for electronic trades of financial products according to one example of the present invention;
ATTORNEY DOCKET NO. 02045461 _'7_ FIG. 2 is a block diagram of the back office system which is part of the system of 2 FIG. 1 and includes a matching engine which matches submitted trade details to confirm the trades;
4 FIG. 3 is a diagram of the database tables which represent trades submitted to the system;
6 FIG. 4A-4D is a flow diagram of the process performed by the matching engine in FIG. 2;
8 FIG. 5 is a confirmation surnrrlary screen which is a user interface to the confirmation system of FIG. 1;
FIG. 6A is a trade details screen accessed for pending trades which is a user interface to the confirmation system of FIG. 1;
12 FIG. 6B is a trade details screen accessed for matched or canceled trades which is a user interface to the confirmation system of FIG. 1;
14 FIG. 6C is a trade details screen accessed for unmatched trades which is a user interface to the confirmation system of FIG. 1;
16 FIG. 6D is a trade details screen accessed for alleged trades which is a user interface to the confirmation system of FIG. 1;
18 FIG. 7A is a file upload log screen which is a user interface to the confirmation system of FIG. 1;
FIG. 7B is a message log screen which is a user interface to the confirmation system of FIG. l;
ATTORNEY DOCKET NO. 02045461 _g_ FIG. 7C is an audit log screen which is a user interface to the confirmation system 2 of FIG. 1;
FIG. 8A is a reports screen of trade status which is a user interface to the 4 confirmation system of FIG. 1;
FIG. 8B is a reports screen of specific broken fields for trades which is a user 6 interface to the confirmation system of FIG. 1;
FIG. 9 is a data mapping screen which is a user interface to the confirmation 8 system of FIG. 1;
FIG. 10 is a data mapping details screen which. is a user interface to the confirmation system of FIG. l;
FIG. 11 is a new confirmation screen which is a user interface to the confirmation 12 system of FIG. l;
FIG. 12 is a file upload screen which is a user interface to the confirmation system 14 of FIG. 1;
FIG. 13A is an administration screen for defining counter parties which is a user 16 interface to the confirmation system of FIG. l;
FIG. 13B is an administration screen for defining default values which is a user 18 interface to the confirmation system of FIG. 1; and FIG. 13C is an administration screen for changing default values which is a user interface to the confirmation system of FIG. 1.
ATTORNEY DOCKET NO. 02045461 DESCRIPTION OF THE PREFERRED EMBODIMENT.
2 While the present invention is capable of embodiment in various forms, there is shown in the drawings and will hereinafter be described a presently preferred 4 embodiment with the understanding that the present disclosure is to be considered as an exemplification of the invention, and is not intended to limit the invention to the specific 6 embodiment illustrated.
FIG. 1 shows a block diagram of a confirmation system 10 which is an exemplary 8 embodiment of the present invention. The confirmation system 10 has a processing system 12 which typically resides at a third party service provider. The processing system 12 is typically provided by a third party vendor independent from the trader and the counter party. An example of such a third party is Intercontinental Exchange which 12 offers confirmation services for energy related derivative products. The processing system 12 may also reside with a trader or a counter party. Both the trader and the 14 counter party agree in advance as part of a Master Agreement that the processing system 12 serves as confirmation of trades between them.
16 The processing system 12 has a matching engine 14 having a central processor 16.
A confirmation program 18 is stored on the matching engine 14 and is run by the central 18 processor 16. The processing system 12 has an external data input 20 which is connected to trading computers such as computers 22, 24, 26 and 28. The processing system 12 may be part of an intranet including the trading computers 22, 24 and 26 and thus may reside with the same trading firm. Alternatively, the trading computers 22, 24, 26 and 28 PATENT.
ATTORNEY DOCKET NO. 02045461 may be computers coupled to the processing system 12 via the Internet in the case of day 2 traders or other trading firms who use the processing system 12 to confirm their trades.
As will be explained, each of the computers 22, 24, 26 and 28 have different software for 4 the submission of trade data to the processing system 12. Of course, it is to be understood that computers 22-28 are merely shown as examples and there can be 6 numerous computers which submit trade data to the processing system 12.
Over the counter trades involving derivatives such as a crude oil swap in the financial oil market are made between a trader and another trader termed a counter party.
Such a trade involves two trading entities entering a contract for crude oil that is to be settled against an agreed upon price index such as Platt's. The trade between the trader and the counter party may be made via telephone or over a secure Internet connection via 12 a trading program such as the trading platform offered by Intercontinental Exchange. Of course, other ways to conduct trades may be used. Once the trade is agreed upon 14 between the trader and the counter party, the details of the trade such as the type of energy product, price, date, etc. are logged by the trader and the counter party. In a 16 trading firm, back office systems may be run on a back office computer 30 which also interfaces with other internal systems such as accounting in order to track the trade. The 18 back office computer 30 may be connected to trading computers such as trading computer 28. In order to confirm that the trade is a legitimate trade, the details of the trade understood by both the trader and the counter party must be the same.
Once the details are matched together, the trade is settled and considered executed.
ATTORNEY DOCKET NO. 02045461 The data for the trade as understood by both the trader and the counter party is 2 entered separately via the trading computers 22, 24, 26 and 28, which each represent a different means of communication of data to the processing system 12. The data from the 4 trading computers are sent to a data interface module 40 of the processing system 12 via a secure interface using SSL and 128 bit encryption. Of course, other alternative or 6 additional security measures may be employed. The matching program 18 on the processing system 12 classifies the trade in one of five different categories based on the 8 consistency of the data with that submitted by the counter party using a data processing module 42 coupled to the interface module 40. The data from the trades acre stored in a database module 44 which is coupled to the data processing module 42.
The data fields relating to a trade of a specific type of product may be codified, 12 for example, by International Swaps and Derivatives Association ("ISDA").
Typically the data in a trade includes price, trade date, counter party, settlement terms, payment 14 instructions and delivery terms. Some of the data fields are specific to the product type and marlcet. For example, for crude oil swaps in the financial market, specific terms may 16 include a provision for common pricing. The product identification is a number assigned by the processing system 12 assigned to the product type. Certain data fields are 18 classified as key which represent data that are used for first level matching of the trade.
The key fields include price, quantity, total quantity, counter party, trade date and product identification for all products. Certain data fields are classified as required which is a field for which a user must submit a data value. For example a required field is the price PATENT.
ATTORNEY DOCKET NO. 02045461 in a crude oil swap. The required data fields are used for second level matching of the 2 trade. Certain data fields are classified as information only which represents data that is supplied for informational purposes only, such as the broker for a crude oil swap. The 4 program 18 also allows a system administrator to manage the authorized users to access the data and view summaries of the trades. A user may view trades, submit data 6 regarding trades, edit, cancel, confirm and dispute trades through the program 18 via the computers 22, 24, 26 and 28 in FIG. 1..
8 The program 18 allows a user to submit data relating to a trade through one of the computers 22, 24, 26 and 28 and that trade will be categorized and allow a user to add additional information or edit inconsistent information to finalize any trades which do not have the initial agreement of the parties. The five categories of submitted trades are 12 matched, alleged, unmatched, pending and canceled. A matched trade is the desired end result of a submitted trade which indicates that all data fields are matched exactly and all 14 counter parties agree with the trader. An unmatched trade is one in which the key data fields match, but secondary fields such as required and information fields do not match 16 between the trader and the counter party. A pending trade is a trade where one or more of the key data fields does not match between the trader and the counter party. UMA.
18 cancelled trade are those trades initially submitted, but then withdrawn by the trader. An alleged trade is a trade that a counter party alleges to have made with the trader, but the trader does not have an exact match of the data fields for the trade.
ATTORNEY DOCKET NO. 02045461 Thus, the program 18 allows a user to quickly review matched trades and identify 2 trades which have problems such as unmatched terms or disagreement by the counter party. By identifying such disputed trades with an indicator in the matched category, the 4 counter party and user may reconcile the conflict and correct the data using the program 18. Greater efficiency in the reconciliation process is gained by both identifying 6 problematic trades and also identifying the specific terms which are in conflict.
In this example, the processing system 12 may interface with a user via a user 8 computer 46 which may be a personal computer with an Internet browser program with the capability of running HTML and JavaScript. The user is thus presented with a web interface displayed on the user computer 46 to perform the functions of the program 18.
With proper authorization, the user computer 46 allows a user to control the above 12 functions, as well as generate reports of data relating to trades confirmed by the program 18. Of course, it is to be understood that any of the other trading computers 22, 24, 26 14 and 28 may also be capable of running the user interface via a web browser program.
FIG. 2 is a block diagram of the components of the processing system 12. The 16 data interface module 40 has two data interfaces 52 and 54, which are an XML interface 52 and a tab delimited file interface 54 via the HTTPS protocol: Of course, other types of 18 data interface protocols such as SOAP may be used to input data into the processing system 12. Other delimiters, such as commas, may also be used to separate data fields in flat file.
ATTORNEY DOCKET NO. 02045461 Data from users may be entered through four different input mechanisms: a 2 webpage on an Internet connected computer such as trader computer 22; a dedicated webpage with tab delimited file upload capability such as trader computer 24;
an 4 automated tab delimited file via a HTTPS capable computer such as trader computer 26;
and an XML application programming interface (API) on a connected computer such as 6 trader computer 28. The data interface module 40 also has an XML API module 56 and an e-mail notification interface 58. The XML API module 56 and e-mail notification 8 interface 58 provides output mechanisms based on requests from a user. The XML API.
interface provides an XML response mechanism for requests received via the XML.
interface 52. The e-mail notification interface 58 provides responses to requests based on specific events within the system. These responses notify the user of events within the 12 system 12 that affect specific data objects associated with the addressee of the e-mail notification.
14 The Intenlet connected computer 22 may be connected directly to the interface module 40. The user logs in and a webpage is displayed with a data entry form.
The user 16 fills out the data on the webpage and transmits the data. The data is then received on the XML interface 52. This method allows users to submit the data fields of one trade at a 18 time.
The second computer 24 allows access to a webpage which has the necessary XML script to allow uploading of a single tab delimited file. The tab delimited file may be in the user's proprietary data format and can contain records of data fields reflecting PATENT.
ATTORNEY DOCKET NO. 02045461 many trades. Thus, a separate tab delimited file may be written for all trades for the day, 2 or all trades of a particular market or product. The data contents in tab delimited file are then read by the processing system 12 via the tab delimited interface 54, as will be 4 described below.
The third computer 26 contains a file upload agent which includes an HTTPS.
6 compatible posting agent such as an Open Source tool, CURL. As explained above, the tab delimited file may contain data fields relating to any number of trades.
8 program is used to periodically check a given directory on the computer 26, read any updated tab delimited files in the directory, and securely post it to the processing system 12 using SSL. This is a 128 bit encryption in this example, but other security protocols may be used. The sent tab delimited files are input into the file upload interface 54.
12 The fourth computer 28 has an XML API which accepts trade data and fields in the standaxd format which will be described below. This standard format allows the data 14 to be input into the XML interface 52. The use of an XML API is preferred because it allows the user and the counter party to submit trade information in real time as the trades 16 are entering into their back office systems, such as on computer 30. In this example, the XML API on the computer 28 is based on XML format messaging to allow users to use 18 the platform and development language of their choice.
The API on the computer 28 may use XML over the HTTP or HTTPS to enable transmission of data over the Internet to the processing system 12. The data scheme becomes a binding contract between the user and the counter party if both parties match PATENT.
ATTORNEY DOCKET NO. 02045461 all required fields of the trade, as will be detailed below. In order to use the HTTPS.
2 protocol, the user registers a digital certificate with the owner of the processing system 12 and handles cookies sent from the processing system 12.
4 Alternatively, the API may use XML messaging over HTTPS to enable transmission of data over the Internet to the processing system 12. The XML.
format 6 message uses stored libraries to facilitate protocol handling and to interface with XML.
The body of the XML message contains mandatory information intended for the ultimate 8 recipient of the message.
The data processing module 42 includes an Internet web server cluster 60, a weblogic application server cluster 62, a trade mapping engine 64, and an e-mail server 66. The application server cluster 62 may include a server to store the trade matching 12 engine 14 that is based on Oracle 8i, but other kinds of software and hardwaxe which have database functionality may be used. The processing module 42 is protected by a 14 flrewall 70 which is interposed between the Internet web server cluster 60 and the interface module 40. The firewall 70 protects the Internet web server cluster 60 from 16 unauthorized data from unidentified computers. The firewall 70 in this example is a Checkpoint firewall, but other types of firewalls may be used.
18 A second firewall 72, which is preferably a Checkpoint firewall, connects the Internet Web Cluster 60 with the processing module 42 and the database module 44 to protect data stored in them. The database module 44 includes a primary database server 74 and a backup database server 76 that access the database using shared storage. The PATENT.
ATTORNEY DOCKET NO. 02045461 database servers 74 and 76 supporting the database include the data described below 2 which relate to trade information and confirmation data. This data includes internal identification and submission company identification for each company and trader using 4 the system 10. The primary and backup database servers 74 and 76 support the Oracle databases in the preferred embodiment with a Sun Cluster to manage the cluster of 6 database server 76 with the primary database server 74 and the shared storage.
In this example, the Internet web server cluster 60 includes Microsoft Internet 8 Information servers which act as a gateway into the core components of the processing module 42. The Internet web server cluster 60 is used to store and send HTML.
pages which are used to build the graphical user interfaces for the confirmation program 18.
The weblogic server cluster 62 is responsible for hosting the XML web services from the 12 XML interfaces 52 and 54. The cluster 62 also receives uploaded tab delimited files, parses XML and converts the inputs to Java objects. The server cluster 62 also interfaces 14 with the database module 42 via an interface 78. The interface 78 in this example is a JDBC connection pool, but it is to be understood that other connections may be used.
16 As will be explained below, the program has a standard format for the needed data field for a trade of a particular set of markets and products. This standard may be, 18 for example, set by Intercontinental Exchange through the XML interface 52.
This standard format is the native language of the confirmation system 10. Users may use different field and data formats through the tab delimited file input interface 54. If data is PATENT.
ATTORNEY DOCKET NO. 02045461 input in a different field and data format than the system standard, the mapping engine 64 2 converts the submitted data to the standard format.
The foundation of the matching engine 14 consists of a database design 4 supporting the definition of products and trades. The matching engine 14 employs a rules based model enabling the matching process for any defined product. FIG. 3 is a chart of 6 a database design 100 having the tables which support the products and trades. These tables include a CODE TYPE table 102, an ECONFIRM PRODUCT MASTER table 8 104, a TRADE DETAIL table 106, a TRADE table 108, a CODE TYPE XREF table 110, a FIRM PRODUCT table 112, a PRODUCT DEFAULT table 114, a TRADE TYPES table 116 and a MARKET TYPE table 118. Each of the tables 102-118 have different data fields which support the products and trades.
12 These tables provide the primary functions supporting the rule based architecture of the matching engine 14. The CODE TYPE table 102 maintains the values of all trade 14 components identified by the business for all the products within the system 10. The PRODUCT MASTER table 104 defines the detailed information for all associated 16 products by identifying the product value with the components defined in the CODE TYPE table 102. The TRADE DETAIL table 106 defines the components of the 18 trade which includes the association of the trade to the user's trade values defined using the CODE TYPE table 102. The TRADE table 108 provides the header information for the trade and identifies the TRADE primary key and the user's trade identification. The trade primary key is the association key used within all other tables. The PATENT.
ATTORNEY DOCKET NO. 02045461 CODE TYPE XREF table 110 identifies the available product components defined in 2 the CODE TYPE table 102 to the associated market type defined in the MARKET TYPE table 118. The FIRM PRODUCT table 112 provides the definition of 4 the product which includes the common definition of the product used by the system 10.
The PRODUCT DEFAULT table 114 provide the user default values for each product 6 component and identifies the association between the component (XML TAG) identifier in the CODE TYPE table 102 and the component value identified in the CODE TYPE.
8 table 102. The TRADE TYPES table 116 provides the definition of specific trade types and associated market types. The MARKET TYPE table 118 provides the definition of each market type supported by the system 10.
The PRODUCT MASTER table 104 defines the primary product category. The 12 matching process utilizes the customer defined rules stored in the PRODUCT.
table 104 as matching criteria for trades between two companies. This matching process 14 occurs within the database of the matching engine 14 after the trade validation process.
The basis of the matching engine 14 revolves around the identification of the 16 XML tag. The XML tag provides the definition of each product characteristic and identifies the matching criteria used by the matching engine 14. Each product includes 18 one or more characteristics that define the matching criteria. These characteristics, or XML tags, define the make up of the matching components of each product and support the matching criteria of each trade. The product definition and matching criteria reside within the PRODUCT MASTER table 104. The table 104 includes a PATENT.
ATTORNEY DOCKET NO. 02045461 PRODUCT MASTER ID field which is the primary, unique identification of the 2 product master component. A PRODUCT ID field is the product associated with the product component. An XML TAG ID field identifies the component or components of 4 the product master. A DETAIL ID field identifies a default or standard value for the component. A PART OF PRODUCT FG field defines the products which default to 6 the product master value as defined in DETAIL ID. A PART OF KEY FG field identifies the primary matching criteria that comprises the main components of the trade.
A MATCH REQUIRED FG field defines the secondary components of the matching criteria that determines the final and more detail components of the trade. An IS REQUIRED FG field identifies components required within the product definition.
The complete definition of the components relies on the unique relationship 12 between the product definition and the CODE TYPE table 102. The CODE.
table 102 provides a single physical object supporting a large number of logical objects with 14 the same internal attributes, such as the component definitions. The CODE.
TYPE table 102 provides a common definition and identification for these components. For the 16 architecture of the system 10, the CODE TYPE table 102 supports the definition of the XML tabs, as well as the components and the component values. The CODE TYPE.
18 table 102 supports the component values as most component values consist of predefined values. Therefore, the values of the XML tag, components and component values consist of the same structure and correlation to the CODE TYPE table 102.
ATTORNEY DOCKET NO. 02045461 The CODE TYPE table 102 includes a correlation of the XML tags and 2 components. The CODE TYPE table 102 includes a CODE TYPE ID field which correlates with the XML TAG TD and DETAIL ID defined below. UMA.
4 CODE TYPE ID field includes a XML TAG ID field which is the identifier corresponding with the component and identifying the component type and a 6 DETAIL ID field which is the identifier of the CODE TYPE corresponding with the value of the component. A SHORT NAME field is the short description or identification 8 of the code type defining the component or component value. A LONG NAME.
field is the complete description or name of the component or component value.
The trade validation process reviews submitted trade details and determines the validity of the trade details utilizing predefined criteria. The CODE TYPE and 12 CODE TYPE XREF tables 102 and 110 provide the mechanism for the predefined criteria as it identifies the valid codes or component values for each associated market 14 type. This association structure provides validation levels using the market type, as currently performed, or other potential criteria. Other potential criteria includes product 16 or trade type. The supporting components within the validation criteria revolve around the XML TAG ID and CODE TYPE ID fields in the CODE TYPE table 102.
18 The rules definition process consists of defining the product, product components, and product default values. The product definition includes the product name and entries within the FIRM PRODUCT table 112. The product components correlate the defined product with the multiple components or multiple entries within the PATENT.
ATTORNEY DOCKET NO. 02045461 PRODUCT MASTER table 104. Each entry defines the component and component 2 attributes, including the matching criteria. The matching criteria identifies the key components, match components, and required components, as well as the components 4 comprising the product master and the default values of the product master components.
The rules definition details the matching criteria for the matching process.
6 The matching process associates two distinct trades from two separate companies identifying a successful transaction between two companies. The matching process 8 includes a key match and a component match. The key match identifies a subset of potential matching trades using the product components identified with a value of 'Y' in the PART OF KEY FG field of the PRODUCT MASTER table 104. These trades with matching key components identify unmatched trades and define a subset of potential 12 matching trades. The completed match between two distinct trades successfully match when all components of the product and trades match on the components with a 'Y' in 14 the MATCH REQUIRED FG field of the PRODUCT MASTER table 104. These components match the XML TAG ID and DETAIL ID of the PRODUCT MASTER.
16 and TRADE DETAIL tables 104 and 106, based on the product and market type.
The matching process must match all components identified as 18 MATCH REQUIRED and PART OF KEY fields in the PRODUCT MASTER table 104 and contain matching values for each of these components for two trades.
For trades matching this criteria, the first two trades, identified by the date/time component of PATENT.
ATTORNEY DOCKET NO. 02045461 TRADE DATE, comprise a matched trade. The following sections are identified by the 2 step by step process of the matching engine 14.
FIGS. 4A - 4D show a flow diagram of the process followed by the matching 4 engine 14 and the processing system 12. The beginning of the user upload process is performed in step 122, where external validation provides initial user feedback 6 identifying valid trade components using the information accessed from the PRODUCT MASTER and the CODE TYPE tables 104 and 102. This process also 8 prepares the trade components for transfer to the matching engine 14.
The processing system 12 then identifies the transfer of the company trade from the XML format to the database structure in step 124. This transfer utilizes an obj ect structure and uses Oracle's Advanced Queuing for performance to submit data to the 12 Oracle database. The matching engine 14 reads the trade object from the queue and begins processing the queue using the TRADE ACTION attribute of the trade object.
14 The TRADE ACTION values are either 'CANCEL' or 'SUBMIT' which identify the cancel action or insert action respectively.
16 The matching engine 14 determines if the trade action value is 'CANCEL', identifying the trade object as a cancel request from the customer in step 126. If the trade 18 object is a cancel request, the processing continues to step 128, which starts the cancel process, defined in FIG. 4C. If the trade status value is not 'CANCEL', processing continues to step 130.
ATTORNEY DOCKET NO. 02045461 The other valid trade action is 'SUBMIT', which indicates the trade is either an 2 insert or update trade request. The matching engine 14 determines whether the trade exists, defined by the trade date and the customer's trade number in step 130.
If the trade 4 exists, the request is an update trade request and the processing continues to step 132, which is an update trade routine that is continued in FIG. 4D. Otherwise, the trade does 6 not exist and the matching engine 14 continues to step 134 which provides additional validation, defines the Trade ID field and sets the initial trade status to pending. While 8 processing the trade action, the engine 14 inserts the appropriate trade values into the TRADE table I08 and the TRADE DETAIL table 106 and continues to step 136.
The initial matching process in step 136 identifies a subset of trades which match on a primary subset of components, identified as key values within the 12 PRODUCT MASTER table 104. This process identifies all trades with matching key values, using the current trade object as the match source and all stored trades with a 14 status of pending or unmatched. All target trades that match the source trade on these values are considered unmatched with the source trade. The process sets an internal flag 16 distinguishing the subset of target trades from other trades only for this matching transaction and continues to step 13 8. The matching engine 14 uses the 18 PRODUCT MASTER table 104 and identifies all components identified as 'MATCH REQUIRED' which match between the source and subset of the target trades in step 138. The process then continues with step 140 which loops to FIG. 4B.
ATTORNEY DOCKET NO. 02045461 The matching engine 14 then determines if the matching process consists of key 2 matches, unmatched or component matches, matched, in step 142. If any of the 'MATCH REQUIRED' components do not match, as specified by the 4 PRODUCT MASTER table 104, then the source trade is unmatched with the subset target trades and processing continues to step 144. The matching engine 14 determines if 6 the target trades are currently unmatched with other trades in step 144. If the target trades are currently unmatched, the source trade is unmatched with the unmatched group 8 and the source trade receives a MatchID value of the target trades in step 146. If the target trade or trades do not have a MatchID setting, then the matching engine generates a new MatchID in step 148. The matching engine 14 then proceeds to step 150, which sets the MatchID for the trades and sets the status to unmatched for the trades.
12 If all components match based on the settings in the PRODUCT MASTER table 104, source trade and identified target trades in step 142, the matching engine 14 14 determines whether there is more than one match in step 152. There can only be one target trade and one source trade of a match; thus if there is more than one matching trade 16 in step 152, the matching engine 14 identifies the earliest trade based on the trade date as the target trade in step 154 and then continues processing to step 156. If there is only one 18 target trade, processing continues to step 156.
The matching process supports matches with both pending and unmatched target , trades. The matching engine 14 determines the current status of the target trade and manages the disposition of the target trade based on the status. The matching engine 14 PATENT.
ATTORNEY DOCKET NO. 02045461 determines whether the trade is matched with an unmatched trade in step 156.
If the 2 status is pending i. e. no match with an unmatched trade is determined in step 156, the matching engine 14 branches to step 158 which identifies a new MatchID using an Oracle 4 sequence. If the target trade is unmatched, i. e. a match with an iumnatched trade is determined in step 158, then the matching engine 14 starts the disposition process for the 6 unmatched target trade and the trades unmatched with the target trade in step 160.
The disposition process begins with step 160, which determines the depth of the 8 unmatched trade. The matching engine 14 determines if there are other trades identified as unmatched trades between the submitting compan,'_es of the source and target trades in step 160. If there are not other umnatched trades between these two companies, the matching engine 14 performs the preliminary steps of the matching process between the 12 trades and cleans up the remaining unmatched trade. The matching module identifies the partner to the target trade, resets the status to pending and resets the MatchID of the 14 partner to zero (0) in step 162. The matching engine 14 then identifies the existing MatchID of the target trade as the new MatchID of the matched trade between the source 16 trade and the target trade in step 164.
If there are other unmatched trades between these two companies in step 160, the 18 matching engine 14 identifies anew MatchID by generating it using an Oracle sequence in step 166. Following steps 158, 164 and 166, the matching engine 14 continues processing in step 168, which creates the match association. In step 168, the matching engine 14 performs the final match by setting the MatchID for both the source and target PATENT.
ATTORNEY DOCKET NO. 02045461 _27_ trade and sets the status of the source and target trade to matched. The transaction is 2 committed and processing passes back to the trade process.
FIG 4C identifies the steps associated with processing a cancel request from the 4 customer trade submission from step 128 of FIG. 4A. The matching engine 14 validates the trade as a potential cancel prospect, determining if the trade is a matched trade in step 6 170. If the trade is a matched trade, the trade is not canceled by the matching engine 14, as both counter parties of the matched trade must approve the cancellation of a matched 8 trade. If the trade is matched, the processing continues to step 172, which writes an error to a message log table stored in the database 74 and proceeds to the next trade. If the trade is not a matched trade in step 170, the processing begins the cancellation process.
The cancellation process consists of resetting the status of the source trade and 12 potential unmatched trades. The matching engine 14 determines if the trade is unmatched in step 174. If the status of the trade is not unmatched, the status of the source trade is set 14 to canceled in step 176 and the routine branches to process the next trade.
If the trade is umnatched in step 174, the processing determines the fate of the paxtner(s) of the source 16 trade by identifying the depth of the unmatched trades, determining if there are other trades identified as unmatched between the submitting companies of the source trade in 18 , step 178. If there are not other unmatched trades between the companies, the trades are canceled and cleaned up. The cancellation of the trade is performed in step 180 which sets the status of the source trade to canceled and resets the value of the MatchID to zero (0). The matching engine 14 then proceeds to step 182 which identifies the partner PATENT.
ATTORNEY DOCKET NO. 02045461 trades) of the source trade from the other company, resets the MatchID to zero (0) and 2 resets the status of the trade to pending.
If there are other trades between the submitting companies in step 178, the status 4 of the source trade is reset to canceled and the MatchID is reset to zero (0) of only the source trade in step 184. Upon completion of the cancellation process in steps 182 or 6 184, the processing terminates and begins processing the next trade.
FIG 4D identifies the steps associated with an update trade request from the 8 customer trade submission. Step 132 identifies the entry point of the update process from FIG. 4A and begins by identifying the status of the trade as matched in step 186. If th. e trade status is matched, as identified by step 186, the trade cannot be updated, since the update may change a component required by the matching criteria and is not supported 12 by both parties of the trade. If the trade is matched, the processing continues to step 188 which writes an error to the message log and exits to the matching routine to process the 14 next trade.
If the status is not matched, the matching engine 14 updates the trade process and 16 the identification of the affected trades of the transaction. The matching engine 14 determines if the trade is unmatched in step 190. If the trade status is not unmatched the 18 status is reset to pending in step 192 and the processing routine exits to process the next trade. If the source trade status is unmatched in step 190, the matching engine 14 determines if there are other trades identified as unmatched between the submitting companies of the source trade in step 194. If there are no other unmatched trades PATENT.
ATTORNEY DOCKET NO. 02045461 between the companies, the matching engine 14 performs the update and clean up of the 2 identified trades. The update of the source trade is performed by setting the status of the source trade to pending and resetting the value of the MatchID to zero (0) in step 195.
4 The matching engine 14 then identifies the partner trades) of the source trade from the other company, resets the MatchID to (0) and resets the status of the trades to pending in 6 step 196.
If there are other trades between the submitting companies, the matching engine 8 14 resets the status of the source trade to pending and resets the MatchID.
to zero (0) of only the source trade in step 198. Upon completion of the update process in steps 196 or 198, the processing returns back to the main engine for the actual update of the component values and re-entry to the matching process.
12 FIG. 5 shows a summary screen 200 of the program which is displayed after a user logs in and proper authorization is received. The slunlnary screen 200 has a menu 14 bar 202. The menu bar 202 has an administration menu option 204, a data mapping menu option 206, a confirm summary menu option 208, a new confirmation menu option 16 210, a logs menu option 212, a file upload menu option 214, a reports menu option 216, a help menu option 218 and a log out menu option 220. Activating the various menu 18 options 204-220 provides functionality in the matching process described above. The menu options 204-220 are displayed on many of the subsequent screens and will be numbered the same for consistency. The help menu option 218 activates various help files while the log out menu option 220 exits the program.
ATTORNEY DOCKET NO. 02045461 The summary screen 200 and subsequent screens also have a title bar 222 which 2 displays the menu title of the screen. The title bar 222 has a company selection box 224 which allows a user to select different subsidiaries for which summaries of trades are to 4 be displayed on the trade screen.
After the matching process takes place, the program allows additional 6 functionality. Logging in or selecting the summary menu option 208 from any screen results in the display of the summary screen 200 which enables a user to display the results of the matching engine in accordance with all of the trades which have been compared using the above process..The summary screen 200 also has a filter bar 252, a status tab section 254 and a surmnary table 256. The filter bar 252 has a drop down market type box 262, a product box 264, a counter party box 266, a trade identification 12 box 268, a delivery location box 270, a breaks box 272, a date type box 274, a date drop down box 276, a search button 278 and a reset button 280. By selecting the arrows in a 14 box, a pull down menu with the stored options for a particular box such as the different types of markets or products in the market type box 262 and product type box 264 are 16 displayed. A user may thus define search criteria for trades using the pull down menus with the boxes 262-276. The user may specify a particular counter party or display trades 18 of all counter parties using the counter party box 266. The user may fmd a single trade by entering the trade identification number in the trade ID box 268. The user may search by a particular delivery location or select all delivery locations in the delivery location box 270. The user may search by broken fields after a first query is made by selecting a PATENT.
ATTORNEY DOCKET NO. 02045461 list of unmatched fields from the breaks box 272. The user may select from a date type 2 field as the date of the trade in the trade type box 274. The user may also select a range of dates for the date type selected in the trade type box 274 by entering date information 4 in the trade date box 276.
Once the user has defined the search parameters and has clicked the search button 6 278, the details of the trades that satisfy these criteria are displayed in the summary table 256. A new search may be run by selecting the reset button 280 which clears the search 8 ° fields in boxes 262-276. The trades which meet the criteria the user selects from the filter bar 252 are fiuther separated by their status. Trades of the same status that meet the selected criteria are displayed in the summary table 256 by selecting tabs 282-290 in the status tab section 254. Thus, the status tab section 254 has a matched tab 282, an 12 unmatched tab 284, a pending tab 286, a canceled tab 288 and an alleged tab 290.
Selecting any of these tabs 280-290 will display data relating to all trades that satisfy the 14 search criteria and all trades of that status. As explained above, selecting the matched tab 282 will display all trades in the summary table 256 that have all matchable fields 16 matched and both trader and counter party are in agreement with the confirmation details.
The confirmation details agreed and match upon depend on the particular product.
18 Selecting the unmatched tab 284 will display all trades in the summaxy table 256 that have all key fields matched and one or more of the non-key fields unmatched.
Selecting the pending tab 286 will display all trades in the summary table 256 that do not have all key fields matched. The counter party for the confirmed pending trades will see PATENT.
ATTORNEY DOCKET NO. 02045461 those trades under their alleged trades. Selecting the canceled tab 288 will display all 2 trades in the summary table 256 that have been chosen by the user to be canceled.
Selecting the alleged tab 290 will display all trades in the summary table 256 which have 4 been alleged to the user by the counter party. These trades are displayed to the counter party as pending if the counter party accesses the program.
6 The summary table 256 has various information from data fields which may be displayed relating to the selected trades under the status of the selected tabs 282-290. In this example, the summary table 256 has all matched trades (from selecting tab 282) which are of the market type physical power (selected from box 262), of all product types (selected from box 264), with. Palo Verde as a delivery location (selected from box 270) and for the dates between March 25, 2002 to April 25, 2002 (selected from box 276).
12 The summary table 256 has a headings row 292 which displays different types of information. Different trade rows 294 under the headings row 292 represent different 14 trades and the information from.
the data fields relating to those trades.
The information in the headings row 292 depends on the market selected.
16 In the example in FIG. 5, the information displayed in each of the trade rows 294 is specific to the physical power market and includes a message column 296, an internal 18 identification number cohunn 298, a trade date column 300, a product traded cohunn 302, a reference price column 306, a buy/sell selection column 308, a counter panty column 310, a start and end date column 312, a quantity column 314, a total quantity column 316, a price column 318, a date column 320, and a notes column 322. These data fields are PATENT.
ATTORNEY DOCKET NO. 02045461 selected to provide the best overview of the trade details. Of course, other data fields 2 such as delivery location may be displayed in the summary table 256.
The user may view the message column 296 to determine whether any flags are 4 indicated for a specific trade. These flags indicate whether a trade is disputed, click and confirmed, novated or cleared. A disputed trade is a transaction where all data fields are 6 matched but one of the parties does not agree that the trade occurred. UMA.
click and confirmed trade is a trade that one user chooses to accept the trades alleged to them, and 8 then clicks on the screen to confirm, rather than submitting the actual matching data through the matching engine 14. When. user clicks to confirm the trade, a match to the alleged trade is generated by the system 12, and the trade moves in its pair to the matched status. A novated trade is a trade that has been processed through the matching engine 12 14, deemed matched, and passed on to a clearing house such as the LCH. UMA.
novated trade cannot be disputed or canceled. A cleared trade is a trade that is sent into the 14 system 12 and noted as cleared. This trade, once matched, will be processed and sent on to a clearing house.
16 The notes column 322 contains various icons which indicate various comments that are electronically associated with the page. An icon with a pencil indicates that a no 18 comments have been attached to the trade, an icon with a pad and pencil indicates that the comment has been read and an icon with a pencil inside a notebook indicates that the comments have not been read. The information in the summary table 254 may be imported to a spread sheet by selecting an export button 324. A split screen button 326 PATENT.
ATTORNEY DOCKET NO. 02045461 provides a user with the option of splitting the screen and displaying a second summary 2 table 256 for purposes of comparisons.
All of the data fields relating to a trade may be displayed by selecting the trade 4 identification of a trade in the rows 294 of the summary table 256 in FIG.
shows a pending trade details screen 350 that is displayed on selecting a specific pending 6 trade from the screen 200 in FIG. 5. The pending trade details screen 350 has the title bar 222 and an alleged trade details table 352. The alleged trade table 352 has a status 8 column 354, a data field column 356 and a value column 358. The data field column 356 lists all of the data fields relating to the trade that is displayed if a pending trade is selected from the summary table 256 in FIG. 5. The values of the data fields from the user (trader) are displayed under the value column 358. The user may view the status 12 column 3 54 to determine the matching significance of a particular data field. For example, a PM flag (PM) indicates that only one value is applicable for that product in 14 that data field. Fields with the PM flag represent data that is derived from the product master values, for example, reference price or quantity unit. Such fields will 16 automatically be designated by the data values from the product master. In addition, other fields which have default values will be assigned the default value initially.
18 A K flag indicates the data field is a Key field and required for first level matching. These fields include buyer, seller, price or quantity. An R flag indicates the field is Required for second level matching such as payment from or pricing frequency.
An I flag indicates that the data field is for informational purposes only such as the broker PATENT.
ATTORNEY DOCKET NO. 02045461 or trader identity. Finally, an * indicator on any flag indicates the data field is required 2 for submission.
Arrow buttons 360 and 362 allow a user to move to the previous or next trade in 4 sequence and display the details of that trade in the trade table 352. An edit button 364 allows a user to edit the details of the trade by selecting a new value in the value column 6 358 for any data field under the data field column 354. A cancel button 366 allows a user to cancel pending trades which are submitted. Selecting the cancel button 366 will result 8 in a pop-up screen aslcing the user to confirm the cancellation.
is a trade details screen 370 accessed for matched or canceled trades.
The trade details screen 370 displays all values of both sides of the trade for each of the data fields. The trade details screen 370 has the title bar 222 and a user trade table 372 12 and a counter party table 374. The user trade table 372 has a status column 376, a data field column 378 and a value column 380. The counter party table 374 has a value 14 column 382 that corresponds with the data fields listed in the data field column 378. All matchable required fields will match between the parties on the screen 370 in the case of 16 a matched trade. As in the case of the details screen 350 in FIG. 6A, the user may view the status column 376 for a flag to determine the matching significance of a particular 18 data field. A user may scroll to the next or previous trade using arrow keys 360 and 362.
The matched trade details screen 370 allows a user to dispute a trade via a dispute button 384. The dispute button 384 is not present if the trade is canceled. By selecting the dispute button 384, the user may elect to flag the matched trade as in dispute between PATENT.
ATTORNEY DOCKET NO. 02045461 the parties. An indicator of a disputed trade will then be displayed in the summary table 2 254 in FIG. 5.
FIG. 6G is a trade details screen 390 accessed for unmatched trades. The trade 4 details screen 390 displays all values of the trade for the user and any other parties for each of the data fields. The trade details screen 390 has the title bar 222, a user trade 6 table 392 and a counter party table 394. The user trade table 392 has a status column 396, a data field column 398 and a value column 400. The counter party table 394 has a 8 value columns for each alleged trade which may match the trade in the user trade table 392. In this case there are three alleged value columns 402, 404 and 406 each of which have values corresponding with the data fields listed in the data field column 398. All matchable required fields will match between the parties on the screen 370 in the case of 12 a matched trade. As in the case of the details screen 350 in FIG. 6A, the user may view the status column 396 for a flag to determine the matching significance of a particular 14 data field. A user may scroll to the next or previous trade using arrow keys 360 and 362.
The data values that do not match between the two tables 392 and 394 will be 16 highlighted as shown in a row 408 which is the pricing frequency data field. In the preferred embodiment, such values will be placed in a signifying color. Of course it is to 18 be understood that other signifying symbols may be used such as bolding, underlining, flashing, etc. The details screen 390 also allows a user to edit the unmatched trades via the edit button 364 and the cancel button 364 as explained above.
ATTORNEY DOCKET NO. 02045461 FIG. 6D is a trade details screen 410 accessed for pending trades. The trade 2 details screen 410 displays all values of the pending trade for the user.
The trade details screen 410 has the title bar 222 and a user trade table 412. The user trade table 412 has a 4 status column 414, a data field column 416 and a value column 418. As in the case of the details screen 350 in FIG. 6A, the user may view the status column 414 for a flag to 6 determine the matching significance of a particular data field. A user may scroll to the next or previous trade using arrow keys 360 and 362. The details screen 410 also allows 8 a user to print the screen and corresponding data fields by selecting a print button 420.
The user may also confirm the trade without submitting his or her own trade details by selecting a confirm button 422.
Returning to the menu selections of any screen such as the screen 200 in FIG.
5, 12 selecting the logs menu option 212 allows a user to display a log screen 450 shown in FIG. 7A. The log screen 450 has the menu bar 202, a title bar 222, a log tab section 452 14 and a filter bar 454. The log tab section 452 has a file upload log tab 456, a message log tab 458 and an audit tab 460. The logs may be filtered by adjusting a date range box 462 16 in the filter bar 454. The logs each provide various information relating to the trades processed by the program. In FIG. 7A, the log tab 456 is selected and displays a file 18 upload summary table 464.
The file upload summary table 464 has a heading row 466 and rows of files 468 that have been uploaded in the selected date range. The rows of files 468 are updated by the date parameters selected in the date range box 462 by selecting a search button 470.
ATTORNEY DOCKET NO. 02045461 The heading row 466 has a date/time column 472, a file name column 474, a status 2 column 476, a total records column 478, a pass column 480 and a fail column 482. The date and time column 472 displays when the file was uploaded into the system.
The file 4 name column 474 displays the file name of the uploaded file. As explained above, a file may have the data fields for multiple numbers of trades. Such a file has different records 6 with the data fields for each of the different trades. The status column 476 indicates whether the matching engine 14 has completed its processing of the trade or not. The 8 total records column 478 displays the total number of trades stored in the file. The pass column 480 displays the nlunber of records in the file that are compliant with the input data standards, while the fail column 482 displays the number of records in the file that are corrupted or not compliant. By selecting the fail column 482, the program will 12 display a pop up window with the identification number of each record that failed and the reason for the failure.
14 A message log screen 490 which is shown in FIG. 7B is displayed by selecting the message log tab 458. The menu bar 202, title bar 222, log tab section 452 and filter bar 16 454 are the same as in FIG. 7A. A message log summary table 492 is displayed. The message log summary table 492 has a heading row 494 and rows of messages 496 which 18 have been received in the selected date range. The rows of messages 496 are updated by the date parameters selected in the date range box 462 by selecting the search button 468.
The heading row 494 has an expansion column 500, a message column 502, a reference ID column 504, a date column 506, a type column 508 and a code column 510. The PATENT.
ATTORNEY DOCKET NO. 02045461 message column 502 displays messages related to errors generated by the system due to 2 actions such as upload, cancel, etc. The reference ID column 504 displays the trade reference identification number of the message. The date column 506 displays the date 4 and time when the message was received from the system. The type column 508 displays an internal system tracking number and the code column 510 displays an internal 6 reference code for use in troubleshooting errors. The expansion column 500 allows a user to expand the details of the trade by displaying additional values in the columns 8 when a plus is selected or simply the message text when a minus is selected.
An audit log screen 520 which is shown. in FIG. 7C is displayed by selecting the audit log tab 460. The menu bar 202, title bar 222 and log tab section 452 are the same as in FIG. 7A. A filter bar section 522 with a trade ID box 524 is displayed. By entering 12 the trade identification number, a specific trade may be displayed by selecting a search button 526. An audit summary table 528 has a heading row 530 and rows of actions 532 14 which have been taken relating to the trade with the selected identification number. The audit data displayed allows a user to follow the life cycle of each trade that is in the 16 program. The heading row 530 has date/time column 540, a trade status column 542, a trade action colulnrl 544 and a detail column 546. The date time column 540 displays the 18 date and time of the trade action. The trade status column 542 displays whether the trade is matched, unmatched, pending or canceled. The trade status cohlmn 544 describes the action taken to the trade. The details column 546 provides further information that is useful in following the cycle of the trade through the system.
ATTORNEY DOCKET NO. 02045461 Returning to the menu selections of any screen such as the screen 200 in FIG.
5, 2 selecting the reports menu option 216 allows a user to display a report screen 550 shown in FIG. 8A. The report screen 550 has a manager's view tab 552, a breaks tab 554 and a 4 filter section 556. FIG. 8A shows the manager's view tab 552 selected which displays a summary of the number of trades in each market type and their status. The report screen 6 550 has a date type box 558 that allows selection of values of particular date fields in conjunction with a date range selection box 560. A search button 562 activates the 8 program to screen trades satisfying the date and type parameters from the filter section 556.
and display relevant data on a report table 564.
In this example, the table 564 has a header row 566 and rows 568 representing different market types. The table 564 has a matched column 570, an unmatched column 12 572, a pending column 574, an alleged column 576, a canceled column 578 and a totals column 580. The rows 568 show the numbers of each types of trades in columns 14 580 which are referenced to the particular market type during the selected time period. UMA.
bottom totals row 582 shows the total number of each column type. An export button 16 584 allows the user to export the data to a spreadsheet. By selecting a particular number entry in any of the rows 568, the program will display the confirmation summary screen 18 200 as shown in FIG. 5.
Selecting the breaks tab 554 causes a breaks report screen 586 to be displayed as shown in FIG. 8B. The breaks report screen 586 displays the number of trades of each market type that have broken or unmatched data values. An additional counter party PATENT.
ATTORNEY DOCKET NO. 02045461 filter box 588 is in the filter section 556 that allows a user to filter by a specific counter 2 party or to select all. The search button 562 activates the program to screen trades satisfying the date and counter party parameters from the filter section 552 and display 4 relevant data on a report table 590.
In this example, the table 590 has a header row 592 and a data field column 6 with entries representing different data fields. The table 590 also has a series of columns 596 each of which represents a particular market type. A series of rows 598 show the 8 numbers of each trade of a particular market type having a broken or unmatched data field in the data field column 594. The bottom totals row 582 shows the total number of trades in each broken data type. By selecting the particular number, the program will display the confirmation summary screen 200 as shown in FIG. 5.
12 Returning to the menu selections of any screen such as the screen 200 in FIG. 5, selecting the data mapping menu option 206 allows a user to convert data values to the 14 standard used by the system 10 via a data mapping screen 600 shown in FIG.
9. Once the data is converted using the data mapping screen 600, the matching process shown in FIG.
16 4 may be initiated. The data mapping screen 600 has a filter section 602 and a summary table 604. The summary table 604 displays the data field mapping which is established 18 on the data mapping details screen as will be explained below. The filter section 602 has a market type box 606 and a field box 608. The market type box 606 allows a user to select a market type from the types stored in the database. The field box 608 allows a PATENT.
ATTORNEY DOCKET NO. 02045461 user to select fields such as delivery location, counter party, pricing frequency etc. A.
2 search button 610 when selected will filter the data selected in the filter section 602.
The summary table 604 has a heading row 620. The heading row 620 has a field 4 name column 622, a system value column 624 and a user value column 626. The data fields entered in the columns 622, 624 and 626 may be sorted ascending or descending by 6 clicking on the column headings. In order to add a new mapped value, the user may select the market type and field via the boxes 606 and 608 and by selecting a map it 8 button 628.
Once the map it button 628 is selected, a data mapping details screen 650 is displayed as shown in FIG. 10. The data mapping details screen 650 has a filter section 652 which has a market type selection box 654, a field selection box 656 and a search 12 button 658. The screen 650 also has a summary table 660. The summary table 660 has a standard data value box 662, a user data value box 664, and various market type 14 selections 666. The summary table 660 includes a map it button 668.
The user selects one field using the field selection box 656 and the market type 16 box 654 and selects the search button 656. After the user selects the field, the standard data value box 662 is updated and provides a list of all of the standard data values for the 18 chosen field. The user selects the desired standard value, and enters the user value in the user data value box 664. The entering of a user value activates various market type selections 666 and the user may select the market types for which the field applies by checking the boxes appearing next to each market type listed. These values are mapped PATENT.
ATTORNEY DOCKET NO. 02045461 to each other such that the user value is now the equivalent of the selected system value 2 by selecting the map it button 668.
The summary table 660 has a mapped value table 670 which shows the result of 4 the mapped value. The mapped value table 670 has a heading bar 672 which has a matching area 674 that displays a user type column 676, a standard value column 678, 6 and a market type column 680. Each successive row 682 displays the user value that is mapped to the system value and the market type. Each row 682 has a check box 684 and 8 the user value and the market type. The value may be deleted by checlcing the check box 684 and selecting a delete button 686. The user may return to the data mapping screen 600 in FIG. 9 by selecting the done button 688 Returning to the menu selections of any screen such as the screen 200 in FIG.
5, 12 selection of the new confirmation menu option 210 allows a user to submit confirmation information on a confirmation submission screen 700 shown in FIG. 11. The submission 14 screen 700 represents the submission of trade data through a web enabled computer such as the computer 22 in FIG. 1. Once the trade data is submitted via the submission screen 16 700, the matching process described in FIG. 4 is performed to confirm the submitted trade.
18 A selection area 702 has a market type box 704, a product box 706, a counter party box 708 and an action box 710. The market type box 704 and product box have pull down lists that allow a user to select the desired market and product. The counter party box has a pull down list which includes all known counter parties for the PATENT.
ATTORNEY DOCKET NO. 02045461 user to select. The action box 710 allows the user to define the trade action as either 2 buying or selling.
After selecting a certain type of trade, a data table 720 is populated with various 4 data values. The data table 720 has a fields column 722 and a user values column 724.
The data table 720 has data rows 726 for each data field with the selected trade and a 6 value for that data field. Each data field has a flag (PM, K, R, I or *) which signifies its importance to the matching process as explained above in FIG. 6A. Of course other 8 indicators such as type style or color may be used to designate the status of the fields.
Certain fields such as a data field 730 which is the payment terms of the trade.
have a pull dorm menu with listed potential options for payment terms. The user may select a value from the list or enter his or her own value for the field which accepts 12 unique values. Once a user has insured that values have been entered in all required fields, he or she may submit the trade data for confirmation by the matching engine by 14 selecting a submit button 732. The user may close the screen 700 by selecting a close button 734.
16 Retluning to the menu selections of any screen such as the screen 200 in FIG. 5, selection of the file upload menu option 214 allows a user to upload files via a file upload 18 screen 750 as shown in FIG. 12. The file upload screen 750 represents the submission of trade data via a tab delimited file uploaded through a web enabled computer such as the computer 24 in FIG. 1. As explained, above, such a file must be written in a format with PATENT.
ATTORNEY DOCKET NO. 02045461 different trades in separate records that may be converted by the system to the system 2 format.
The file upload screen 750 has an upload area 752. The upload area 752 has file 4 selection boxes 754 and browse buttons 756. The selection boxes 754 and browse buttons 756 may be used to access the files stored on the computer or another networlced 6 computer. As may be seen in this example, up to three different files may be uploaded simultaneously; but it is to be understood that different numbers of files may also be 8 uploaded. Once the files are selected, an upload button 758 is selected to send the files to the. system.:
. Returning to the menu selections of any screen such as the screen 200 in FIG. 5, selection of the administration menu option 204 allows an administrative user to manage 12 the system via an administrative screen 800 as shown in FZG. 13A. The administrative screen 800 includes a counter party filter tab 802, a default values tab 804, a users tab 14 806, a parents tab 808 a companies tab 810, a products tab 812 and a data values tab 814.
By selecting the user tab 806, a screen is presented to allow the user to associate a 16 company name with system users, enter user data, add new users, set parameters for use such as the permissible market types for trades submitted by a user. The user screen may 18 also be used to activate and deactivate users authorized for access to the system 10 as well as set passwords for those users.
By selecting the parents tab 808, a screen is displayed to allow the administrative user to change data relating to parent companies. By selecting the companies tab 810, a PATENT.
ATTORNEY DOCKET NO. 02045461 screen is displayed to allow the administrative user to change data relating to the 2' companies allowed to trade. By selecting the products tab 812, a screen is displayed to allow an administrative user to change data relating to the products associated with the 4 system. By selecting the data values tab 814, the administrative user may change the data values associated with the system.
6 By selecting the counter party filter tab 802, the screen 800 is displayed with a filter bar 816 and a summary table 818. Before trade data is accepted from a counter 8 party, a counter party filter must be set up via the screen 800 that allows confirmations between various counter parties and traders. The filter bar 814 has a market type box 820 that allows the selection of a particular market type to classify counter parties. The summary table 818 has a user settings column 822, a counter party settings column 824, a 12 user set counter party to column 826, a company name column 828, a counter party has user set to column 830. Once the marlcet type is selected via the market type box 820, a 14 list of companies (counter parties) will be listed in the summary table 818. The user settings column 822 is used to hide fields containing economic values that are sent to the 16 counter party for which the user does not have a match and which appear as alleged trades. This functionality is used to protect fields such as price, quantity, total quantity, 18 start date, end date, etc. from being seen by a counter party a user may not be familiar with. Similarly, the setting column 824 is a read only column which displays whether the counter party has hidden these details. Both the user and the counter party must leave the PATENT.
ATTORNEY DOCKET NO. 02045461 respective settings columns 822 and 824 as not hidden in order for both to view price, 2 volume and trade durations fields from the alleged screens.
The user set counter party to column 826 is used to enable or disable confirmation 4 of trades with the counter party. The counter party has user set to column 828 is read only and shows the status that the counter party has designated the user to either enable or 6 disable confirmation of trades via the system. In order to confirm trades both the user and the counter party must set the columns 826 and 828 to yes or enable.
8 A check all button 832 enables a user to check all the boxes at the same time. UMA.
clear all button 834 enables a user to clear the checks from all the boxes at the same time.
A save button 836 allows a user to save the settings for the counter parties shown in the summary table 818.
12 The capability to change data information in the display shown in FIG. 13A.
depends on the user's status. If a user has an administrative level clearance, more values 14 may be changed via the tabs 802-814. If a user is a normal user, a screen such as the default values screen 850 shown in FIG. 13B is displayed. The default values screen 850 16 in FIG. 13B only has the counter party filter tab 802, the default values tab 804 and the users tab 806. Since the user in this example is only a normal user the parents tab 808, 18 the companies tab 810, the products tab 812 and the data values tab 814 in FIG. 13A are not displayed. By selecting the counter party filter tab 802, a display similar to the one in FIG. 13A is displayed. By selecting the default values tab 804 in either FIG.
13A or 13B, a default values screen 850 is displayed as shown in FIG. 13B. The default values screen PATENT.
ATTORNEY DOCKET NO. 02045461 850 allows a user to enable default values for certain fields in trades of a certain market 2 type or counter party. The default values screen 850 has a filter bar 852 with a market type box 854 and a product box 856. By selecting a market type box 854 and a product 4 box 856, a user may display all counter party information and default values in a summary table 860.
6 The summary table 860 includes a counter party column 862 and various other columns of field values 864 that represent different data values for the selected market 8 type and product. The summary table 860 has other rows 866 each of which represents different counter parties that trade in the market 'type and product. The rows 866 each have a selection box 868. By checking the selection box 868, a user may select a clear button 870 to clear out all of the values for the selected row for the counter party. A user 12 may also select a check all button 872 to check all of the rows 866. A user may clear all the checks by selecting a clear all button 874.
14 Certain fields in the summary table 860 such as a settlement frequency field 880 have "none" entered. In order to enter values, a user may select the field 880 which 16 causes a pop up window 890 as shown in FIG. 13 C to be displayed. The pop up window 890 has a filter. bar 892 with a market type box 894 and a product box 896 which will 18 initially have the selected market type and product from the default data screen 850 in FIG. 13B. The pop up window 890 will have selection boxes 898 that correspond to the fields that were selected from FIG. 13B. Each selection box 898 has a pull down list 900 which lists different default values. A user may select a default value or enter another PATENT.
ATTORNEY DOCKET NO. 02045461 value in the box 898. The default values will be initially selected to none until changed 2 by the user.
A show all button 902 allows a user to display other fields that may have default 4 values set up for the particular product and market. The entered default values may be saved via a save button 904 and the pop up window 890 may be closed via a close button 6 906.
It will be apparent to those skilled in the art that various modifications and 8 variations can be made in the method and system of the present invention without departing fram the spirit or scope of the invention. Thus, the present invention is not limited by the foregoing descriptions but is intended to cover all modifications and variations that come within the scope of the spirit of the invention and the claims that 12 follow.

Electronic trading confirmation system.
Images.
Classificações.
H — ELECTRICITY H02 — GENERATION; CONVERSION OR DISTRIBUTION OF ELECTRIC POWER H02J — CIRCUIT ARRANGEMENTS OR SYSTEMS FOR SUPPLYING OR DISTRIBUTING ELECTRIC POWER; SYSTEMS FOR STORING ELECTRIC ENERGY H02J3/00 — Circuit arrangements for ac mains or ac distribution networks H02J3/008 — Circuit arrangements for ac mains or ac distribution networks involving trading of energy or energy transmission rights G — PHYSICS G06 — COMPUTING; CALCULATING; COUNTING G06Q — DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR G06Q40/00 — Finance; Insurance; Tax strategies; Processing of corporate or income taxes G06Q40/04 — Exchange, e. g. stocks, commodities, derivatives or currency exchange Y — GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS Y04 — INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS Y04S — SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i. e. SMART GRIDS Y04S10/00 — Systems supporting electrical power generation, transmission or distribution Y04S10/50 — Systems or methods supporting the power network operation or management, involving a certain degree of interaction with the load-side end user applications Y04S10/58 — Financial aspects Y — GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS Y04 — INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS Y04S — SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i. e. SMART GRIDS Y04S50/00 — Market activities related to the operation of systems integrating technologies related to power network operation and communication or information technologies Y04S50/10 — Energy trading, including energy flowing from end-user application to grid.
Descrição.
This application claims priority from provisional application No. 60/343,437 filed Dec. 21, 2001 and provisional application No. 60/338,803 filed Nov. 13, 2001. The contents of both applications are hereby incorporated by reference.
FIELD OF INVENTION.
This invention relates to a system and method of clearing trades on an electronic exchange and more specifically to a system and method which matches known information offered by a trader and a counter party to confirm a trade.
BACKGROUND OF INVENTION.
Traditional trading of commodities or financial instruments such as stocks and bonds has taken place in markets where traders offer various commodities at different prices. Such trades were performed using hand signals and paper was used to finalize the actual trading contract. With the advent of computers, more complex and faster trades may be made by integrating computing power. Additionally, the growth of the Internet and other electronic communications systems has moved the realm of trading beyond the trading floor. With the increasing complexity of the economy, a greater diversity of financial commodity products may be offered including derivatives. Derivatives are defined as a financial contract whose value depends on the values of one or more underlying assets or indices of asset values. Presently, derivatives are traded in traditional exchanges which can include futures or options in commodities ranging from pork bellies to currency prices. Recently, derivatives have also been traded in the over-the-counter (OTC) market defined by transactions by large financial institutions such as commercial banks or insurance companies. Such derivatives can include swaps, options, caps, floors, corridors, etc. derived from interest rates, foreign currencies, equities and other commodities or financial instruments.
Exchange derivatives are structured with standard terms such as contract size, maturity, expiration date, etc. set by an exchange such as the Chicago Board of Trade. Additionally, trades of exchange derivatives and their supporting data are sent to a third party clearing house for settlement. In contrast, OTC derivatives are more flexible because none of the business terms of an OTC derivative are standardized. In addition, the settlement of the trade occurs directly through the trading parties as no third party clearing house exists because of the diversity of different derivatives.
One emerging over-the-counter market of derivative products is in the field of energy. With deregulation of the power industry, there is a much greater diversity of power generators with different types of energy sources such as natural gas, oil, electricity and solar. With such diverse energy sources and suppliers, a market has arisen in trading the commodities of energy between such producers. Various financial and physical derivative instruments such as swaps, options or spreads have been formulated by various players in the energy market. Players in this market range from traditional trading firms to energy companies. Like many financial markets, technology makes accessibility to the over-the-counter energy derivative market far greater.
Traders in the OTC energy market typically agree to prices and terms with another trading counter party for a particular type of derivative in an energy product such as a natural gas swap. This type of trade involves certain common terms such as settlement and payment terms. The trade may be made directly with a counter party, or by phone, or more recently, via an electronic platform such as the Internet. Such trades are recorded by the traders on their trade notebooks and trade data is entered directly into their company's trade data capture computer systems. These systems generate confirmation documents and summary data relating to the trade.
Like other OTC derivatives, energy derivatives do not have a uniform confirmation system of terms once a trade is made between the parties. Thus, when a trade is made, the parties must confirm the terms of the trade. Both the traders record the details of the trade in a trade notebook and enter the data directly into their company's trade capture system. The company's trade capture system prints confirmation documents which are reviewed and sent to the other party. This typically takes place by faxing the confirmation documents to the other party. A clerk then checks the terms of the received confirmation documents against the recorded alleged trade in the trade notebook and the data output of the receiving party's own trade capture system. Information such as the buyer and seller, purchase or sale, product, instrument, delivery point, price, delivery terms, etc. must match. After a clerk reviews the trade, any discrepancies must be reported to the trading counter party and a reconciliation must be made based on the recorded information. When it is confirmed that the information is accurate, the contracts are then signed and exchanged. Thus, the amount of time necessary for confirming the trade takes much longer then the trade itself. Even a trade which is correctly executed by both parties can take days to be fully confirmed. Errors prolong the process.
However, other errors are possible since clerks must examine and confirm numerous trades with often different forms for each derivative product. The confirmation problems resulting in much greater costs and decreased efficiencies. In fact, 18% of derivatives trades contain errors at the time of entry into a trade capture system. Many OTC derivatives are governed by a model Master Agreement endorsed by the International Swaps and Derivatives Association (“ISDA”). While the master agreement does make certain reconciliation more efficient, it must be modified for each specific OTC derivative product and the terms must still be manually examined in order to settle the trades.
Thus, there is a need for an automated confirmation system for OTC derivative products. There is yet another need for a system which can standardize confirmation of OTC derivatives. There is a need for a confirmation system which allows the rapid entry and processing of trade data. There is also a need for a system which allows a user to summarize trades for a certain period to determine which trades have irregularities. There is a further need for a trading confirmation system which will match data relating to fields and categorize the trades to determine which trades are confirmed.
SUMMARY OF THE INVENTION.
These needs and others may be met by the present invention, which has an aspect that is a system of determining the status of trades between a trader and a counter party, based on an electronic submission of a data file representing details in data fields of a trade by the trader and a second data file representing details in data fields of the trade by the counter party. The system has a data interface engine which reads the data files and data fields. A matching engine is coupled to the data interface engine and matches selected data fields in the data files and assigns a status to the trade based on whether the data fields submitted matches. A database is coupled to the matching engine which stores the resulting trade data to confirm the trade if all of the key details in the two data files match.
Another aspect is a method of electronically confirming trading of financial products, which include data fields that are agreed upon between a trader and a counter party. Trader data is submitted, including different data fields relating to the trade via an electronic interface. Counter party data is submitted including different data fields relating to the trade via an electronic interface. The data fields submitted by the trader and the counter party are compared to determine which fields match. The trade is confirmed if certain data fields match.
Another aspect is a method of electronically confirming trades of financial products between a party and a counter party having a master agreement governing the trades of the financial products. The master agreement is amended to allow electronic confirmation. The trader and the counter party are both connected electronically to a matching engine. Trader data, including different data fields relating to a trade, is submitted to the matching engine. Counter party data, including different data fields relating to the trade, is submitted to the matching engine. The trade is confirmed by matching certain data fields.
It is to be understood that both the foregoing general description and the following detailed description are not limiting but are intended to provide further explanation of the invention claimed. The accompanying drawings, which are incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the method and system of the invention. Together with the description, the drawings serve to explain the principles of the invention.
BRIEF DESCRIPTION OF DRAWINGS.
These and further aspects and advantages of the invention will be discussed more in detail hereinafter with reference to the disclosure of preferred embodiments, and in particular with reference to the appended Figures wherein:
FIG. 1 is a block diagram of a confirmation system for electronic trades of financial products according to one example of the present invention;
FIG. 2 is a block diagram of the back office system which is part of the system of FIG. 1 and includes a matching engine which matches submitted trade details to confirm the trades;
FIG. 3 is a diagram of the database tables which represent trades submitted to the system;
FIG. 4A-4D is a flow diagram of the process performed by the matching engine in FIG. 2 ;
FIG. 5 is a confirmation summary screen which is a user interface to the confirmation system of FIG. 1;
FIG. 6A is a trade details screen accessed for pending trades which is a user interface to the confirmation system of FIG. 1;
FIG. 6B is a trade details screen accessed for matched or canceled trades which is a user interface to the confirmation system of FIG. 1;
FIG. 6C is a trade details screen accessed for unmatched trades which is a user interface to the confirmation system of FIG. 1;
FIG. 6D is a trade details screen accessed for alleged trades which is a user interface to the confirmation system of FIG. 1;
FIG. 7A is a file upload log screen which is a user interface to the confirmation system of FIG. 1;
FIG. 7B is a message log screen which is a user interface to the confirmation system of FIG. 1;
FIG. 7C is an audit log screen which is a user interface to the confirmation system of FIG. 1;
FIG. 8A is a reports screen of trade status which is a user interface to the confirmation system of FIG. 1;
FIG. 8B is a reports screen of specific broken fields for trades which is a user interface to the confirmation system of FIG. 1;
FIG. 9 is a data mapping screen which is a user interface to the confirmation system of FIG. 1;
FIG. 10 is a data mapping details screen which is a user interface to the confirmation system of FIG. 1;
FIG. 11 is a new confirmation screen which is a user interface to the confirmation system of FIG. 1;
FIG. 12 is a file upload screen which is a user interface to the confirmation system of FIG. 1;
FIG. 13A is an administration screen for defining counter parties which is a user interface to the confirmation system of FIG. 1;
FIG. 13B is an administration screen for defining default values which is a user interface to the confirmation system of FIG. 1; e.
FIG. 13C is an administration screen for changing default values which is a user interface to the confirmation system of FIG. 1.
DESCRIPTION OF THE PREFERRED EMBODIMENT.
While the present invention is capable of embodiment in various forms, there is shown in the drawings and will hereinafter be described a presently preferred embodiment with the understanding that the present disclosure is to be considered as an exemplification of the invention, and is not intended to limit the invention to the specific embodiment illustrated.
FIG. 1 shows a block diagram of a confirmation system 10 which is an exemplary embodiment of the present invention. The confirmation system 10 has a processing system 12 which typically resides at a third party service provider. The processing system 12 is typically provided by a third party vendor independent from the trader and the counter party. An example of such a third party is Intercontinental Exchange which offers confirmation services for energy related derivative products. The processing system 12 may also reside with a trader or a counter party. Both the trader and the counter party agree in advance as part of a Master Agreement that the processing system 12 serves as confirmation of trades between them.
The processing system 12 has a matching engine 14 having a central processor 16 . A confirmation program 18 is stored on the matching engine 14 and is run by the central processor 16 . The processing system 12 has an external data input 20 which is connected to trading computers such as computers 22 , 24 , 26 and 28 . The processing system 12 may be part of an intranet including the trading computers 22 , 24 and 26 and thus may reside with the same trading firm. Alternatively, the trading computers 22 , 24 , 26 and 28 may be computers coupled to the processing system 12 via the Internet in the case of day traders or other trading firms who use the processing system 12 to confirm their trades. As will be explained, each of the computers 22 , 24 , 26 and 28 have different software for the submission of trade data to the processing system 12 . Of course, it is to be understood that computers 22 - 28 are merely shown as examples and there can be numerous computers which submit trade data to the processing system 12 .
Over the counter trades involving derivatives such as a crude oil swap in the financial oil market are made between a trader and another trader termed a counter party. Such a trade involves two trading entities entering a contract for crude oil that is to be settled against an agreed upon price index such as Platt's. The trade between the trader and the counter party may be made via telephone or over a secure Internet connection via a trading program such as the trading platform offered by Intercontinental Exchange. Of course, other ways to conduct trades may be used. Once the trade is agreed upon between the trader and the counter party, the details of the trade such as the type of energy product, price, date, etc. are logged by the trader and the counter party. In a trading firm, back office systems may be run on a back office computer 30 which also interfaces with other internal systems such as accounting in order to track the trade. The back office computer 30 may be connected to trading computers such as trading computer 28 . In order to confirm that the trade is a legitimate trade, the details of the trade understood by both the trader and the counter party must be the same. Once the details are matched together, the trade is settled and considered executed.
The data for the trade as understood by both the trader and the counter party is entered separately via the trading computers 22 , 24 , 26 and 28 , which each represent a different means of communication of data to the processing system 12 . The data from the trading computers are sent to a data interface module 40 of the processing system 12 via a secure interface using SSL and 128 bit encryption. Of course, other alternative or additional security measures may be employed. The matching program 18 on the processing system 12 classifies the trade in one of five different categories based on the consistency of the data with that submitted by the counter party using a data processing module 42 coupled to the interface module 40 . The data from the trades are stored in a database module 44 which is coupled to the data processing module 42 .
The data fields relating to a trade of a specific type of product may be codified, for example, by International Swaps and Derivatives Association (“ISDA”). Typically the data in a trade includes price, trade date, counter party, settlement terms, payment instructions and delivery terms. Some of the data fields are specific to the product type and market. For example, for crude oil swaps in the financial market, specific terms may include a provision for common pricing. The product identification is a number assigned by the processing system 12 assigned to the product type. Certain data fields are classified as key which represent data that are used for first level matching of the trade. The key fields include price, quantity, total quantity, counter party, trade date and product identification for all products. Certain data fields are classified as required which is a field for which a user must submit a data value. For example a required field is the price in a crude oil swap. The required data fields are used for second level matching of the trade. Certain data fields are classified as information only which represents data that is supplied for informational purposes only, such as the broker for a crude oil swap. The program 18 also allows a system administrator to manage the authorized users to access the data and view summaries of the trades. A user may view trades, submit data regarding trades, edit, cancel, confirm and dispute trades through the program 18 via the computers 22 , 24 , 26 and 28 in FIG. 1.
The program 18 allows a user to submit data relating to a trade through one of the computers 22 , 24 , 26 and 28 and that trade will be categorized and allow a user to add additional information or edit inconsistent information to finalize any trades which do not have the initial agreement of the parties. The five categories of submitted trades are matched, alleged, unmatched, pending and canceled. A matched trade is the desired end result of a submitted trade which indicates that all data fields are matched exactly and all counter parties agree with the trader. An unmatched trade is one in which the key data fields match, but secondary fields such as required and information fields do not match between the trader and the counter party. A pending trade is a trade where one or more of the key data fields does not match between the trader and the counter party. A cancelled trade are those trades initially submitted, but then withdrawn by the trader. An alleged trade is a trade that a counter party alleges to have made with the trader, but the trader does not have an exact match of the data fields for the trade.
Thus, the program 18 allows a user to quickly review matched trades and identify trades which have problems such as unmatched terms or disagreement by the counter party. By identifying such disputed trades with an indicator in the matched category, the counter party and user may reconcile the conflict and correct the data using the program 18 . Greater efficiency in the reconciliation process is gained by both identifying problematic trades and also identifying the specific terms which are in conflict.
In this example, the processing system 12 may interface with a user via a user computer 46 which may be a personal computer with an Internet browser program with the capability of running HTML and JavaScript. The user is thus presented with a web interface displayed on the user computer 46 to perform the functions of the program 18 . With proper authorization, the user computer 46 allows a user to control the above functions, as well as generate reports of data relating to trades confirmed by the program 18 . Of course, it is to be understood that any of the other trading computers 22 , 24 , 26 and 28 may also be capable of running the user interface via a web browser program.
FIG. 2 is a block diagram of the components of the processing system 12 . The data interface module 40 has two data interfaces 52 and 54 , which are an XML interface 52 and a tab delimited file interface 54 via the HTTPS protocol. Of course, other types of data interface protocols such as SOAP may be used to input data into the processing system 12 . Other delimiters, such as commas, may also be used to separate data fields in flat file.
Data from users may be entered through four different input mechanisms: a webpage on an Internet connected computer such as trader computer 22 ; a dedicated webpage with tab delimited file upload capability such as trader computer 24 ; an automated tab delimited file via a HTTPS capable computer such as trader computer 26 ; and an XML application programming interface (API) on a connected computer such as trader computer 28 . The data interface module 40 also has an XML API module 56 and an e-mail notification interface 58 . The XML API module 56 and e-mail notification interface 58 provides output mechanisms based on requests from a user. The XML API interface provides an XML response mechanism for requests received via the XML API interface 52 . The e-mail notification interface 58 provides responses to requests based on specific events within the system. These responses notify the user of events within the system 12 that affect specific data objects associated with the addressee of the e-mail notification.
The Internet connected computer 22 may be connected directly to the interface module 40 . The user logs in and a webpage is displayed with a data entry form. The user fills out the data on the webpage and transmits the data. The data is then received on the XML interface 52 . This method allows users to submit the data fields of one trade at a time.
The second computer 24 allows access to a webpage which has the necessary XML script to allow uploading of a single tab delimited file. The tab delimited file may be in the user's proprietary data format and can contain records of data fields reflecting many trades. Thus, a separate tab delimited file may be written for all trades for the day, or all trades of a particular market or product. The data contents in tab delimited file are then read by the processing system 12 via the tab delimited interface 54 , as will be described below.
The third computer 26 contains a file upload agent which includes an HTTPS compatible posting agent such as an Open Source tool, cURL. As explained above, the tab delimited file may contain data fields relating to any number of trades. The cURL program is used to periodically check a given directory on the computer 26 , read any updated tab delimited files in the directory, and securely post it to the processing system 12 using SSL. This is a 128 bit encryption in this example, but other security protocols may be used. The sent tab delimited files are input into the file upload interface 54 .
The fourth computer 28 has an XML API which accepts trade data and fields in the standard format which will be described below. This standard format allows the data to be input into the XML interface 52 . The use of an XML API is preferred because it allows the user and the counter party to submit trade information in real time as the trades are entering into their back office systems, such as on computer 30 . In this example, the XML API on the computer 28 is based on XML format messaging to allow users to use the platform and development language of their choice.
The API on the computer 28 may use XML over the HTTP or HTTPS to enable transmission of data over the Internet to the processing system 12 . The data scheme becomes a binding contract between the user and the counter party if both parties match all required fields of the trade, as will be detailed below. In order to use the HTTPS protocol, the user registers a digital certificate with the owner of the processing system 12 and handles cookies sent from the processing system 12 .
Alternatively, the API may use XML messaging over HTTPS to enable transmission of data over the Internet to the processing system 12 . The XML format message uses stored libraries to facilitate protocol handling and to interface with XML. The body of the XML message contains mandatory information intended for the ultimate recipient of the message.
The data processing module 42 includes an Internet web server cluster 60 , a weblogic application server cluster 62 , a trade mapping engine 64 , and an e-mail server 66 . The application server cluster 62 may include a server to store the trade matching engine 14 that is based on Oracle 8 i, but other kinds of software and hardware which have database functionality may be used. The processing module 42 is protected by a firewall 70 which is interposed between the Internet web server cluster 60 and the interface module 40 . The firewall 70 protects the Internet web server cluster 60 from unauthorized data from unidentified computers. The firewall 70 in this example is a Checkpoint firewall, but other types of firewalls may be used.
A second firewall 72 , which is preferably a Checkpoint firewall, connects the Internet Web Cluster 60 with the processing module 42 and the database module 44 to protect data stored in them. The database module 44 includes a primary database server 74 and a backup database server 76 that access the database using shared storage. The database servers 74 and 76 supporting the database include the data described below which relate to trade information and confirmation data. This data includes internal identification and submission company identification for each company and trader using the system 10 . The primary and backup database servers 74 and 76 support the Oracle databases in the preferred embodiment with a Sun Cluster to manage the cluster of database server 76 with the primary database server 74 and the shared storage.
In this example, the Internet web server cluster 60 includes Microsoft Internet Information servers which act as a gateway into the core components of the processing module 42 . The Internet web server cluster 60 is used to store and send HTML pages which are used to build the graphical user interfaces for the confirmation program 18 . The weblogic server cluster 62 is responsible for hosting the XML web services from the XML interfaces 52 and 54 . The cluster 62 also receives uploaded tab delimited files, parses XML and converts the inputs to Java objects. The server cluster 62 also interfaces with the database module 42 via an interface 78 . The interface 78 in this example is a JDBC connection pool, but it is to be understood that other connections may be used.
As will be explained below, the program has a standard format for the needed data field for a trade of a particular set of markets and products. This standard may be, for example, set by Intercontinental Exchange through the XML interface 52 . This standard format is the native language of the confirmation system 10 . Users may use different field and data formats through the tab delimited file input interface 54 . If data is input in a different field and data format than the system standard, the mapping engine 64 converts the submitted data to the standard format.
The foundation of the matching engine 14 consists of a database design supporting the definition of products and trades. The matching engine 14 employs a rules based model enabling the matching process for any defined product. FIG. 3 is a chart of a database design 100 having the tables which support the products and trades. These tables include a CODE_TYPE table 102 , an ECONFIRM_PRODUCT_MASTER table 104 , a TRADE_DETAIL table 106 , a TRADE table 108 , a CODE_TYPE_XREF table 110 , a FIRM_PRODUCT table 112 , a PRODUCT_DEFAULT table 114 , a TRADE_TYPES table 116 and a MARKET_TYPE table 118 . Each of the tables 102 - 118 have different data fields which support the products and trades.
These tables provide the primary functions supporting the rule based architecture of the matching engine 14 . The CODE_TYPE table 102 maintains the values of all trade components identified by the business for all the products within the system 10 . The PRODUCT_MASTER table 104 defines the detailed information for all associated products by identifying the product value with the components defined in the CODE_TYPE table 102 . The TRADE_DETAIL table 106 defines the components of the trade which includes the association of the trade to the user's trade values defined using the CODE TYPE table 102 . The TRADE table 108 provides the header information for the trade and identifies the TRADE primary key and the user's trade identification. The trade primary key is the association key used within all other tables. The CODE_TYPE_XREF table 110 identifies the available product components defined in the CODE_TYPE table 102 to the associated market type defined in the MARKET_TYPE table 118 . The FIRM_PRODUCT table 112 provides the definition of the product which includes the common definition of the product used by the system 10 . The PRODUCT_DEFAULT table 114 provide the user default values for each product component and identifies the association between the component (XML_TAG) identifier in the CODE_TYPE table 102 and the component value identified in the CODE_TYPE table 102 . The TRADE_TYPES table 116 provides the definition of specific trade types and associated market types. The MARKET_TYPE table 118 provides the definition of each market type supported by the system 10 .
The PRODUCT MASTER table 104 defines the primary product category. The matching process utilizes the customer defined rules stored in the PRODUCT_MASTER table 104 as matching criteria for trades between two companies. This matching process occurs within the database of the matching engine 14 after the trade validation process.
The basis of the matching engine 14 revolves around the identification of the XML tag. The XML tag provides the definition of each product characteristic and identifies the matching criteria used by the matching engine 14 . Each product includes one or more characteristics that define the matching criteria. These characteristics, or XML tags, define the make up of the matching components of each product and support the matching criteria of each trade. The product definition and matching criteria reside within the PRODUCT_MASTER table 104 . The table 104 includes a PRODUCT_MASTER_ID field which is the primary, unique identification of the product master component. A PRODUCT_ID field is the product associated with the product component. An XML_TAG_ID field identifies the component or components of the product master. A DETAIL_ID field identifies a default or standard value for the component. A PART_OF_PRODUCT_FG field defines the products which default to the product master value as defined in DETAIL_ID. A PART OF_KEY_FG field identifies the primary matching criteria that comprises the main components of the trade. A MATCH_REQUIRED_FG field defines the secondary components of the matching criteria that determines the final and more detail components of the trade. An IS_REQUIRED_FG field identifies components required within the product definition.
The complete definition of the components relies on the unique relationship between the product definition and the CODE_TYPE table 102 . The CODE_TYPE table 102 provides a single physical object supporting a large number of logical objects with the same internal attributes, such as the component definitions. The CODE_TYPE table 102 provides a common definition and identification for these components. For the architecture of the system 10 , the CODE_TYPE table 102 supports the definition of the XML tabs, as well as the components and the component values. The CODE_TYPE table 102 supports the component values as most component values consist of predefined values. Therefore, the values of the XML tag, components and component values consist of the same structure and correlation to the CODE_TYPE table 102 .
The CODE_TYPE table 102 includes a correlation of the XML tags and components. The CODE_TYPE table 102 includes a CODE_TYPE_ID field which correlates with the XML_TAG_ID and DETAIL_ID defined below. A CODE_TYPE_ID field includes a XML_TAG_ID field which is the identifier corresponding with the component and identifying the component type and a DETAIL_ID field which is the identifier of the CODE_TYPE corresponding with the value of the component. A SHORT_NAME field is the short description or identification of the code type defining the component or component value A LONG_NAME field is the complete description or name of the component or component value.
The trade validation process reviews submitted trade details and determines the validity of the trade details utilizing predefined criteria. The CODE_TYPE and CODE_TYPE_XREF tables 102 and 110 provide the mechanism for the predefined criteria as it identifies the valid codes or component values for each associated market type. This association structure provides validation levels using the market type, as currently performed, or other potential criteria. Other potential criteria includes product or trade type. The supporting components within the validation criteria revolve around the XML_TAG_ID and CODE_TYPE_ID fields in the CODE_TYPE table 102 .
The rules definition process consists of defining the product, product components, and product default values. The product definition includes the product name and entries within the FIRM_PRODUCT table 112 . The product components correlate the defined product with the multiple components or multiple entries within the PRODUCT_MASTER table 104 . Each entry defines the component and component attributes, including the matching criteria. The matching criteria identifies the key components, match components, and required components, as well as the components comprising the product master and the default values of the product master components. The rules definition details the matching criteria for the matching process.
The matching process associates two distinct trades from two separate companies identifying a successful transaction between two companies. The matching process includes a key match and a component match. The key match identifies a subset of potential matching trades using the product components identified with a value of вЂ˜Y’ in the PART_OF_KEY_FG field of the PRODUCT_MASTER table 104 . These trades with matching key components identify unmatched trades and define a subset of potential matching trades. The completed match between two distinct trades successfully match when all components of the product and trades match on the components with a вЂ˜Y’ in the MATCH_REQUIRED_FG field of the PRODUCT_MASTER table 104 . These components match the XML_TAG_ID and DETAIL_ID of the PRODUCT_MASTER and TRADE_DETAIL tables 104 and 106 , based on the product and market type.
The matching process must match all components identified as MATCH_REQUIRED and PART_OF_KEY fields in the PRODUCT_MASTER table 104 and contain matching values for each of these components for two trades. For trades matching this criteria, the first two trades, identified by the date/time component of TRADE_DATE, comprise a matched trade. The following sections are identified by the step by step process of the matching engine 14 .
FIGS. 4A-4D show a flow diagram of the process followed by the matching engine 14 and the processing system 12 . The beginning of the user upload process is performed in step 122 , where external validation provides initial user feedback identifying valid trade components using the information accessed from the PRODUCT_MASTER and the CODE_TYPE tables 104 and 102 . This process also prepares the trade components for transfer to the matching engine 14 .
The processing system 12 then identifies the transfer of the company trade from the XML format to the database structure in step 124 . This transfer utilizes an object structure and uses Oracle's Advanced Queuing for performance to submit data to the Oracle database. The matching engine 14 reads the trade object from the queue and begins processing the queue using the TRADE_ACTION attribute of the trade object. The TRADE_ACTION values are either вЂ˜CANCEL’ or вЂ˜SUBMIT’ which identify the cancel action or insert action respectively.
The matching engine 14 determines if the trade action value is вЂ˜CANCEL’, identifying the trade object as a cancel request from the customer in step 126 . If the trade object is a cancel request, the processing continues to step 128 , which starts the cancel process, defined in FIG. 4C . If the trade status value is not вЂ˜CANCEL’, processing continues to step 130 .
The other valid trade action is вЂ˜SUBMIT’, which indicates the trade is either an insert or update trade request. The matching engine 14 determines whether the trade exists, defined by the trade date and the customer's trade number in step 130 . If the trade exists, the request is an update trade request and the processing continues to step 132 , which is an update trade routine that is continued in FIG. 4D . Otherwise, the trade does not exist and the matching engine 14 continues to step 134 which provides additional validation, defines the Trade ID field and sets the initial trade status to pending. While processing the trade action, the engine 14 inserts the appropriate trade values into the TRADE table 108 and the TRADE_DETAIL table 106 and continues to step 136 .
The initial matching process in step 136 identifies a subset of trades which match on a primary subset of components, identified as key values within the PRODUCT_MASTER table 104 . This process identifies all trades with matching key values, using the current trade object as the match source and all stored trades with a status of pending or unmatched. All target trades that match the source trade on these values are considered unmatched with the source trade. The process sets an internal flag distinguishing the subset of target trades from other trades only for this matching transaction and continues to step 138 . The matching engine 14 uses the PRODUCT_MASTER table 104 and identifies all components identified as вЂ˜MATCH_REQUIRED’ which match between the source and subset of the target trades in step 138 . The process then continues with step 140 which loops to FIG. 4B .
The matching engine 14 then determines if the matching process consists of key matches, unmatched or component matches, matched, in step 142 . If any of the вЂ˜MATCH_REQUIRED’ components do not match, as specified by the PRODUCT_MASTER table 104 , then the source trade is unmatched with the subset target trades and processing continues to step 144 . The matching engine 14 determines if the target trades are currently unmatched with other trades in step 144 . If the target trades are currently unmatched, the source trade is unmatched with the unmatched group and the source trade receives a MatchID value of the target trades in step 146 . If the target trade or trades do not have a MatchID setting, then the matching engine 14 generates a new MatchID in step 148 . The matching engine 14 then proceeds to step 150 , which sets the MatchID for the trades and sets the status to unmatched for the trades.
If all components match based on the settings in the PRODUCT_MASTER table 104 , source trade and identified target trades in step 142 , the matching engine 14 determines whether there is more than one match in step 152 . There can only be one target trade and one source trade of a match; thus if there is more than one matching trade in step 152 , the matching engine 14 identifies the earliest trade based on the trade date as the target trade in step 154 and then continues processing to step 156 . If there is only one target trade, processing continues to step 156 .
The matching process supports matches with both pending and unmatched target trades. The matching engine 14 determines the current status of the target trade and manages the disposition of the target trade based on the status. The matching engine 14 determines whether the trade is matched with an unmatched trade in step 156 . If the status is pending i. e. no match with an unmatched trade is determined in step 156 , the matching engine 14 branches to step 158 which identifies a new MatchID using an Oracle sequence. If the target trade is unmatched, i. e. a match with an unmatched trade is determined in step 158 , then the matching engine 14 starts the disposition process for the unmatched target trade and the trades unmatched with the target trade in step 160 .
The disposition process begins with step 160 , which determines the depth of the unmatched trade. The matching engine 14 determines if there are other trades identified as unmatched trades between the submitting companies of the source and target trades in step 160 . If there are not other unmatched trades between these two companies, the matching engine 14 performs the preliminary steps of the matching process between the trades and cleans up the remaining unmatched trade. The matching module identifies the partner to the target trade, resets the status to pending and resets the MatchID of the partner to zero (0) in step 162 . The matching engine 14 then identifies the existing MatchID of the target trade as the new MatchID of the matched trade between the source trade and the target trade in step 164 .
If there are other unmatched trades between these two companies in step 160 , the matching engine 14 identifies a new MatchID by generating it using an Oracle sequence in step 166 . Following steps 158 , 164 and 166 , the matching engine 14 continues processing in step 168 , which creates the match association. In step 168 , the matching engine 14 performs the final match by setting the MatchID for both the source and target trade and sets the status of the source and target trade to matched. The transaction is committed and processing passes back to the trade process.
FIG. 4C identifies the steps associated with processing a cancel request from the customer trade submission from step 128 of FIG. 4A . The matching engine 14 validates the trade as a potential cancel prospect, determining if the trade is a matched trade in step 170 . If the trade is a matched trade, the trade is not canceled by the matching engine 14 , as both counter parties of the matched trade must approve the cancellation of a matched trade. If the trade is matched, the processing continues to step 172 , which writes an error to a message log table stored in the database 74 and proceeds to the next trade. If the trade is not a matched trade in step 170 , the processing begins the cancellation process.
The cancellation process consists of resetting the status of the source trade and potential unmatched trades. The matching engine 14 determines if the trade is unmatched in step 174 . If the status of the trade is not unmatched, the status of the source trade is set to canceled in step 176 and the routine branches to process the next trade. If the trade is unmatched in step 174 , the processing determines the fate of the partner(s) of the source trade by identifying the depth of the unmatched trades, determining if there are other trades identified as unmatched between the submitting companies of the source trade in step 178 . If there are not other unmatched trades between the companies, the trades are canceled and cleaned up. The cancellation of the trade is performed in step 180 which sets the status of the source trade to canceled and resets the value of the MatchID to zero (0). The matching engine 14 then proceeds to step 182 which identifies the partner trade(s) of the source trade from the other company, resets the MatchID to zero (0) and resets the status of the trade to pending.
If there are other trades between the submitting companies in step 178 , the status of the source trade is reset to canceled and the MatchID is reset to zero (0) of only the source trade in step 184 . Upon completion of the cancellation process in steps 182 or 184 , the processing terminates and begins processing the next trade.
FIG. 4D identifies the steps associated with an update trade request from the customer trade submission. Step 132 identifies the entry point of the update process from FIG. 4A and begins by identifying the status of the trade as matched in step 186 . If the trade status is matched, as identified by step 186 , the trade cannot be updated, since the update may change a component required by the matching criteria and is not supported by both parties of the trade. If the trade is matched, the processing continues to step 188 which writes an error to the message log and exits to the matching routine to process the next trade.
If the status is not matched, the matching engine 14 updates the trade process and the identification of the affected trades of the transaction. The matching engine 14 determines if the trade is unmatched in step 190 . If the trade status is not unmatched the status is reset to pending in step 192 and the processing routine exits to process the next trade. If the source trade status is unmatched in step 190 , the matching engine 14 determines if there are other trades identified as unmatched between the submitting companies of the source trade in step 194 . If there are no other unmatched trades between the companies, the matching engine 14 performs the update and clean up of the identified trades. The update of the source trade is performed by setting the status of the source trade to pending and resetting the value of the MatchID to zero (0) in step 195 . The matching engine 14 then identifies the partner trade(s) of the source trade from the other company, resets the MatchID to (0) and resets the status of the trades to pending in step 196 .
If there are other trades between the submitting companies, the matching engine 14 resets the status of the source trade to pending and resets the MatchID to zero (0) of only the source trade in step 198 . Upon completion of the update process in steps 196 or 198 , the processing returns back to the main engine for the actual update Of the component values and re-entry to the matching process.
FIG. 5 shows a summary screen 200 of the program which is displayed after a user logs in and proper authorization is received. The summary screen 200 has a menu bar 202 . The menu bar 202 has an administration menu option 204 , a data mapping menu option 206 , a confirm summary menu option 208 , a new confirmation menu option 210 , a logs menu option 212 , a file upload menu option 214 , a reports menu option 216 , a help menu option 218 and a log out menu option 220 . Activating the various menu options 204 - 220 provides functionality in the matching process described above. The menu options 204 - 220 are displayed on many of the subsequent screens and will be numbered the same for consistency. The help menu option 218 activates various help files while the log out menu option 220 exits the program.
The summary screen 200 and subsequent screens also have a title bar 222 which displays the menu title of the screen. The title bar 222 has a company selection box 224 which allows a user to select different subsidiaries for which summaries of trades are to be displayed on the trade screen.
After the matching process takes place, the program allows additional functionality. Logging in or selecting the summary menu option 208 from any screen results in the display of the summary screen 200 which enables a user to display the results of the matching engine in accordance with all of the trades which have been compared using the above process. The summary screen 200 also has a filter bar 252 , a status tab section 254 and a summary table 256 . The filter bar 252 has a drop down market type box 262 , a product box 264 , a counter party box 266 , a trade identification box 268 , a delivery location box 270 , a breaks box 272 , a date type box 274 , a date drop down box 276 , a search button 278 and a reset button 280 . By selecting the arrows in a box, a pull down menu with the stored options for a particular box such as the different types of markets or products in the market type box 262 and product type box 264 are displayed. A user may thus define search criteria for trades using the pull down menus with the boxes 262 - 276 . The user may specify a particular counter party or display trades of all counter parties using the counter party box 266 . The user may find a single trade by entering the trade identification number in the trade ID box 268 . The user may search by a particular delivery location or select all delivery locations in the delivery location box 270 . The user may search by broken fields after a first query is made by selecting a list of unmatched fields from the breaks box 272 . The user may select from a date type field as the date of the trade in the trade type box 274 . The user may also select a range of dates for the date type selected in the trade type box 274 by entering date information in the trade date box 276 .
Once the user has defined the search parameters and has clicked the search button 278 , the details of the trades that satisfy these criteria are displayed in the summary table 256 . A new search may be run by selecting the reset button 280 which clears the search fields in boxes 262 - 276 . The trades which meet the criteria the user selects from the filter bar 252 are further separated by their status. Trades of the same status that meet the selected criteria are displayed in the summary table 256 by selecting tabs 282 - 290 in the status tab section 254 . Thus, the status tab section 254 has a matched tab 282 , an unmatched tab 284 , a pending tab 286 , a canceled tab 288 and an alleged tab 290 . Selecting any of these tabs 280 - 290 will display data relating to all trades that satisfy the search criteria and all trades of that status. As explained above, selecting the matched tab 282 will display all trades in the summary table 256 that have all matchable fields matched and both trader and counter party are in agreement with the confirmation details. The confirmation details agreed and match upon depend on the particular product.
Selecting the unmatched tab 284 will display all trades in the summary table 256 that have all key fields matched and one or more of the non-key fields unmatched. Selecting the pending tab 286 will display all trades in the summary table 256 that do not have all key fields matched. The counter party for the confirmed pending trades will see those trades under their alleged trades. Selecting the canceled tab 288 will display all trades in the summary table 256 that have been chosen by the user to be canceled. Selecting the alleged tab 290 will display all trades in the summary table 256 which have been alleged to the user by the counter party. These trades are displayed to the counter party as pending if the counter party accesses the program.
The summary table 256 has various information from data fields which may be displayed relating to the selected trades under the status of the selected tabs 282 - 290 . In this example, the summary table 256 has all matched trades (from selecting tab 282 ) which are of the market type physical power (selected from box 262 ), of all product types (selected from box 264 ), with Palo Verde as a delivery location (selected from box 270 ) and for the dates between Mar. 25, 2002 to Apr. 25, 2002 (selected from box 276 ). The summary table 256 has a headings row 292 which displays different types of information. Different trade rows 294 under the headings row 292 represent different trades and the information from the data fields relating to those trades. The information in the headings row 292 depends on the market selected.
In the example in FIG. 5 , the information displayed in each of the trade rows 294 is specific to the physical power market and includes a message column 296 , an internal identification number column 298 , a trade date column 300 , a product traded column 302 , a reference price column 306 , a buy/sell selection column 308 , a counter party column 310 , a start and end date column 312 , a quantity column 314 , a total quantity column 316 , a price column 318 , a date column 320 , and a notes column 322 . These data fields are selected to provide the best overview of the trade details. Of course, other data fields such as delivery location may be displayed in the summary table 256 .
The user may view the message column 296 to determine whether any flags are indicated for a specific trade. These flags indicate whether a trade is disputed, click and confirmed, novated or cleared. A disputed trade is a transaction where all data fields are matched but one of the parties does not agree that the trade occurred. A click and confirmed trade is a trade that one user chooses to accept the trades alleged to them, and then clicks on the screen to confirm, rather than submitting the actual matching data through the matching engine 14 . When user clicks to confirm the trade, a match to the alleged trade is generated by the system 12 , and the trade moves in its pair to the matched status. A novated trade is a trade that has been processed through the matching engine 14 , deemed matched, and passed on to a clearing house such as the LCH. A novated trade cannot be disputed or canceled. A cleared trade is a trade that is sent into the system 12 and noted as cleared. This trade, once matched, will be processed and sent on to a clearing house.
The notes column 322 contains various icons which indicate various comments that are electronically associated with the page. An icon with a pencil indicates that a no comments have been attached to the trade, an icon with a pad and pencil indicates that the comment has been read and an icon with a pencil inside a notebook indicates that the comments have not been read. The information in the summary table 254 may be imported to a spread sheet by selecting an export button 324 . A split screen button 326 provides a user with the option of splitting the screen and displaying a second summary table 256 for purposes of comparisons.
All of the data fields relating to a trade may be displayed by selecting the trade identification of a trade in the rows 294 of the summary table 256 in FIG. 5. FIG. 6A shows a pending trade details screen 350 that is displayed on selecting a specific pending trade from the screen 200 in FIG. 5. The pending trade details screen 350 has the title bar 222 and an alleged trade details table 352 . The alleged trade table 352 has a status column 354 , a data field column 356 and a value column 358 . The data field column 356 lists all of the data fields relating to the trade that is displayed if a pending trade is selected from the summary table 256 in FIG. 5. The values of the data fields from the user (trader) are displayed under the value column 358 . The user may view the status column 354 to determine the matching significance of a particular data field. For example, a PM flag (PM) indicates that only one value is applicable for that product in that data field. Fields with the PM flag represent data that is derived from the product master values, for example, reference price or quantity unit. Such fields will automatically be designated by the data values from the product master. In addition, other fields which have default values will be assigned the default value initially.
A K flag indicates the data field is a Key field and required for first level matching. These fields include buyer, seller, price or quantity. An R flag indicates the field is Required for second level matching such as payment from or pricing frequency. An I flag indicates that the data field is for informational purposes only such as the broker or trader identity. Finally, an * indicator on any flag indicates the data field is required for submission.
Arrow buttons 360 and 362 allow a user to move to the previous or next trade in sequence and display the details of that trade in the trade table 352 . An edit button 364 allows a user to edit the details of the trade by selecting a new value in the value column 358 for any data field under the data field column 354 . A cancel button 366 allows a user to cancel pending trades which are submitted. Selecting the cancel button 366 will result in a pop-up screen asking the user to confirm the cancellation.
FIG. 6B is a trade details screen 370 accessed for matched or canceled trades. The trade details screen 370 displays all values of both sides of the trade for each of the data fields. The trade details screen 370 has the title bar 222 and a user trade table 372 and a counter party table 374 . The user trade table 372 has a status column 376 , a data field column 378 and a value column 380 . The counter party table 374 has a value column 382 that corresponds with the data fields listed in the data field column 378 . All matchable required fields will match between the parties on the screen 370 in the case of a matched trade. As in the case of the details screen 350 in FIG. 6A , the user may view the status column 376 for a flag to determine the matching significance of a particular data field. A user may scroll to the next or previous trade using arrow keys 360 and 362 .
The matched trade details screen 370 allows a user to dispute a trade via a dispute button 384 . The dispute button 384 is not present if the trade is canceled. By selecting the dispute button 384 , the user may elect to flag the matched trade as in dispute between the parties. An indicator of a disputed trade will then be displayed in the summary table 254 in FIG.5 .
FIG. 6C is a trade details screen 390 accessed for unmatched trades. The trade details screen 390 displays all values of the trade for the user and any other parties for each of the data fields. The trade details screen 390 has the title bar 222 , a user trade table 392 and a counter party table 394 . The user trade table 392 has a status column 396 , a data field column 398 and a value column 400 . The counter party table 394 has a value columns for each alleged trade which may match the trade in the user trade table 392 . In this case there are three alleged value columns 402 , 404 and 406 each of which have values corresponding with the data fields listed in the data field column 398 . All matchable required fields will match between the parties on the screen 370 in the case of a matched trade. As in the case of the details screen 350 in FIG. 6A , the user may view the status column 396 for a flag to determine the matching significance of a particular data field. A user may scroll to the next or previous trade using arrow keys 360 and 362 .
The data values that do not match between the two tables 392 and 394 will be highlighted as shown in a row 408 which is the pricing frequency data field. In the preferred embodiment, such values will be placed in a signifying color. Of course it is to be understood that other signifying symbols may be used such as bolding, underlining, flashing, etc. The details screen 390 also allows a user to edit the unmatched trades via the edit button 364 and the cancel button 364 as explained above.
FIG. 6D is a trade details screen 410 accessed for pending trades. The trade details screen 410 displays all values of the pending trade for the user. The trade details screen 410 has the title bar 222 and a user trade table 412 . The user trade table 412 has a status column 414 , a data field column 416 and a value column 418 . As in the case of the details screen 350 in FIG. 6A , the user may view the status column 414 for a flag to determine the matching significance of a particular data field. A user may scroll to the next or previous trade using arrow keys 360 and 362 . The details screen 410 also allows a user to print the screen and corresponding data fields by selecting a print button 420 . The user may also confirm the trade without submitting his or her own trade details by selecting a confirm button 422 .
Returning to the menu selections of any screen such as the screen 200 in FIG. 5 , selecting the logs menu option 212 allows a user to display a log screen 450 shown in FIG. 7A . The log screen 450 has the menu bar 202 , a title bar 222 , a log tab section 452 and a filter bar 454 . The log tab section 452 has a file upload log tab 456 , a message log tab 458 and an audit tab 460 . The logs may be filtered by adjusting a date range box 462 in the filter bar 454 . The logs each provide various information relating to the trades processed by the program. In FIG. 7A , the log tab 456 is selected and displays a file upload summary table 464 .
The file upload summary table 464 has a heading row 466 and rows of files 468 that have been uploaded in the selected date range. The rows of files 468 are updated by the date parameters selected in the date range box 462 by selecting a search button 470 . The heading row 466 has a date/time column 472 , a file name column 474 , a status column 476 , a total records column 478 , a pass column 480 and a fail column 482 . The date and time column 472 displays when the file was uploaded into the system. The file name column 474 displays the file name of the uploaded file. As explained above, a file may have the data fields for multiple numbers of trades. Such a file has different records with the data fields for each of the different trades. The status column 476 indicates whether the matching engine 14 has completed its processing of the trade or not. The total records column 478 displays the total number of trades stored in the file. The pass column 480 displays the number of records in the file that are compliant with the input data standards, while the fail column 482 displays the number of records in the file that are corrupted or not compliant. By selecting the fail column 482 , the program will display a pop up window with the identification number of each record that failed and the reason for the failure.
A message log screen 490 which is shown in FIG. 7B is displayed by selecting the message log tab 458 . The menu bar 202 , title bar 222 , log tab section 452 and filter bar 454 are the same as in FIG. 7A . A message log summary table 492 is displayed. The message log summary table 492 has a heading row 494 and rows of messages 496 which have been received in the selected date range. The rows of messages 496 are updated by the date parameters selected in the date range box 462 by selecting the search button 468 . The heading row 494 has an expansion column 500 , a message column 502 , a reference ID column 504 , a date column 506 , a type column 508 and a code column 510 . The message column 502 displays messages related to errors generated by the system due to actions such as upload, cancel, etc. The reference ID column 504 displays the trade reference identification number of the message. The date column 506 displays the date and time when the message was received from the system. The type column 508 displays an internal system tracking number and the code column 510 displays an internal reference code for use in troubleshooting errors. The expansion column 500 allows a user to expand the details of the trade by displaying additional values in the columns when a plus is selected or simply the message text when a minus is selected.
An audit log screen 520 which is shown in FIG. 7C is displayed by selecting the audit log tab 460 . The menu bar 202 , title bar 222 and log tab section 452 are the same as in FIG. 7A . A filter bar section 522 with a trade ID box 524 is displayed. By entering the trade identification number, a specific trade may be displayed by selecting a search button 526 . An audit summary table 528 has a heading row 530 and rows of actions 532 which have been taken relating to the trade with the selected identification number. The audit data displayed allows a user to follow the life cycle of each trade that is in the program. The heading row 530 has date/time column 540 , a trade status column 542 , a trade action column 544 and a detail column 546 . The date time column 540 displays the date and time of the trade action. The trade status column 542 displays whether the trade is matched, unmatched, pending or canceled. The trade status column 544 describes the action taken to the trade. The details column 546 provides further information that is useful in following the cycle of the trade through the system.
Returning to the menu selections of any screen such as the screen 200 in FIG. 5 , selecting the reports menu option 216 allows a user to display a report screen 550 shown in FIG. 8A . The report screen 550 has a manager's view tab 552 , a breaks tab 554 and a filter section 556 . FIG. 8A shows the manager's view tab 552 selected which displays a summary of the number of trades in each market type and their status. The report screen 550 has a date type box 558 that allows selection of values of particular date fields in conjunction with a date range selection box 560 . A search button 562 activates the program to screen trades satisfying the date and type parameters from the filter section 556 and display relevant data on a report table 564 .
In this example, the table 564 has a header row 566 and rows 568 representing different market types. The table 564 has a matched column 570 , an unmatched column 572 , a pending column 574 , an alleged column 576 , a canceled column 578 and a totals column 580 . The rows 568 show the numbers of each types of trades in columns 570 - 580 which are referenced to the particular market type during the selected time period. A bottom totals row 582 shows the total number of each column type. An export button 584 allows the user to export the data to a spreadsheet. By selecting a particular number entry in any of the rows 568 , the program will display the confirmation summary screen 200 as shown in FIG. 5.
Selecting the breaks tab 554 causes a breaks report screen 586 to be displayed as shown in FIG. 8B . The breaks report screen 586 displays the number of trades of each market type that have broken or unmatched data values. An additional counter party filter box 588 is in the filter section 556 that allows a user to filter by a specific counter party or to select all. The search button 562 activates the program to screen trades satisfying the date and counter party parameters from the filter section 552 and display relevant data on a report table 590 .
In this example, the table 590 has a header row 592 and a data field column 594 with entries representing different data fields. The table 590 also has a series of columns 596 each of which represents a particular market type. A series of rows 598 show the numbers of each trade of a particular market type having a broken or unmatched data field in the data Field column 594 . The bottom totals row 582 shows the total number of trades in each broken data type. By selecting the particular number, the program will display the confirmation summary screen 200 as shown in FIG. 5.
Returning to the menu selections of any screen such as the screen 200 in FIG. 5 , selecting the data mapping menu option 206 allows a user to convert data values to the standard used by the system 10 via a data mapping screen 600 shown in FIG. 9. Once the data is converted using the data mapping screen 600 , the matching process shown in FIG. 4 may be initiated. The data mapping screen 600 has a filter section 602 and a summary table 604 . The summary table 604 displays the data field mapping which is established on the data mapping details screen as will be explained below. The filter section 602 has a market type box 606 and a field box 608 . The market type box 606 allows a user to select a market type from the types stored in the database. The field box 608 allows a user to select fields such as delivery location, counter party, pricing frequency etc. A search button 610 when selected will filter the data selected in the filter section 602 .
The summary table 604 has a heading row 620 . The heading row 620 has a field name column 622 , a system value column 624 and a user value column 626 . The data fields entered in the columns 622 , 624 and 626 may be sorted ascending or descending by clicking on the column headings. In order to add a new mapped value, the user may select the market type and field via the boxes 606 and 608 and by selecting a map it button 628 .
Once the map it button 628 is selected, a data mapping details screen 650 is displayed as shown in FIG. 10. The data mapping details screen 650 has a filter section 652 which has a market type selection box 654 , a field selection box 656 and a search button 658 . The screen 650 also has a summary table 660 . The summary table 660 has a standard data value box 662 , a user data value box 664 , and various market type selections 666 . The summary table 660 includes a map it button 668 .
The user selects one field using the field selection box 656 and the market type box 654 and selects the search button 656 . After the user selects the field, the standard data value box 662 is updated and provides a list of all of the standard data values for the chosen field. The user selects the desired standard value, and enters the user value in the user data value box 664 . The entering of a user value activates various market type selections 666 and the user may select the market types for which the field applies by checking the boxes appearing next to each market type listed. These values are mapped to each other such that the user value is now the equivalent of the selected system value by selecting the map it button 668 .
The summary table 660 has a mapped value table 670 which shows the result of the mapped value. The mapped value table 670 has a heading bar 672 which has a matching area 674 that displays a user type column 676 , a standard value column 678 , and a market type column 680 . Each successive row 682 displays the user value that is mapped to the system value and the market type. Each row 682 has a check box 684 and the user value and the market type. The value may be deleted by checking the check box 684 and selecting a delete button 686 . The user may return to the data mapping screen 600 in FIG. 9 by selecting the done button 688 .
Returning to the menu selections of any screen such as the screen 200 in FIG. 5 , selection of the new confirmation menu option 210 allows a user to submit confirmation information on a confirmation submission screen 700 shown in FIG. 11. The submission screen 700 represents the submission of trade data through a web enabled computer such as the computer 22 in FIG. 1. Once the trade data is submitted via the submission screen 700 , the matching process described in FIG. 4 is performed to confirm the submitted trade.
A selection area 702 has a market type box 704 , a product box 706 , a counter party box 708 and an action box 710 . The market type box 704 and product box 706 have pull down lists that allow a user to select the desired market and product. The counter party box has a pull down list which includes all known counter parties for the user to select. The action box 710 allows the user to define the trade action as either buying or selling.
After selecting a certain type of trade, a data table 720 is populated with various data values. The data table 720 has a fields column 722 and a user values column 724 . The data table 720 has data rows 726 for each data field with the selected trade and a value for that data field. Each data field has a flag (PM, K, R, I or *) which signifies its importance to the matching process as explained above in FIG. 6A . Of course other indicators such as type style or color may be used to designate the status of the fields.
Certain fields such as a data field 730 which is the payment terms of the trade have a pull down menu with listed potential options for payment terms. The user may select a value from the list or enter his or her own value for the field which accepts unique values. Once a user has insured that values have been entered in all required fields, he or she may submit the trade data for confirmation by the matching engine by selecting a submit button 732 . The user may close the screen 700 by selecting a close button 734 .
Returning to the menu selections of any screen such as the screen 200 in FIG. 5 , selection of the file upload menu option 214 allows a user to upload files via a file upload screen 750 as shown in FIG. 12 . The file upload screen 750 represents the submission of trade data via a tab delimited file uploaded through a web enabled computer such as the computer 24 in FIG. 1. As explained, above, such a file must be written in a format with different trades in separate records that may be converted by the system to the system format.
The file upload screen 750 has an upload area 752 . The upload area 752 has file selection boxes 754 and browse buttons 756 . The selection boxes 754 and browse buttons 756 may be used to access the files stored on the computer or another networked computer. As may be seen in this example, up to three different files may be uploaded simultaneously; but it is to be understood that different numbers of files may also be uploaded. Once the files are selected, an upload button 758 is selected to send the files to the system.
Returning to the menu selections of any screen such as the screen 200 in FIG. 5 , selection of the administration menu option 204 allows an administrative user to manage the system via an administrative screen 800 as shown in FIG. I 3 A. The administrative screen 800 includes a counter party filter tab 802 , a default values tab 804 , a users tab 806 , a parents tab 808 a companies tab 810 , a products tab 812 and a data values tab 814 . By selecting the user tab 806 , a screen is presented to allow the user to associate a company name with system users, enter user data, add new users, set parameters for use such as the permissible market types for trades submitted by a user. The user screen may also be used to activate and deactivate users authorized for access to the system 10 as well as set passwords for those users.
By selecting the parents tab 808 , a screen is displayed to allow the administrative user to change data relating to parent companies. By selecting the companies tab 810 , a screen is displayed to allow the administrative user to change data relating to the companies allowed to trade. By selecting the products tab 812 , a screen is displayed to allow an administrative user to change data relating to the products associated with the system. By selecting the data values tab 814 , the administrative user may change the data values associated with the system.
By selecting the counter party filter tab 802 , the screen 800 is displayed with a filter bar 816 and a summary table 818 . Before trade data is accepted from a counter party, a counter party filter must be set up via the screen 800 that allows confirmations between various counter parties and traders. The filter bar 814 has a market type box 820 that allows the selection of a particular market type to classify counter parties. The summary table 818 has a user settings column 822 , a counter party settings column 824 , a user set counter party to column 826 , a company name column 828 , a counter party has user set to column 830 . Once the market type is selected via the market type box 820 , a list of companies (counter parties) will be listed in the summary table 818 . The user settings column 822 is used to hide fields containing economic values that are sent to the counter party for which the user does not have a match and which appear as alleged trades. This functionality is used to protect fields such as price, quantity, total quantity, start date, end date, etc. from being seen by a counter party a user may not be familiar with. Similarly, the setting column 824 is a read only column which displays whether the counter party has hidden these details. Both the user and the counter party must leave the respective settings columns 822 and 824 as not hidden in order for both to view price, volume and trade durations fields from the alleged screens.
The user set counter party to column 826 is used to enable or disable confirmation of trades with the counter party. The counter party has user set to column 828 is read only and shows the status that the counter party has designated the user to either enable or disable confirmation of trades via the system. In order to confirm trades both the user and the counter party must set the columns 826 and 828 to yes or enable.
A check all button 832 enables a user to check all the boxes at the same time. A clear all button 834 enables a user to clear the checks from all the boxes at the same time. A save button 836 allows a user to save the settings for the counter parties shown in the summary table 818 .
The capability to change data information in the display shown in FIG. 13A depends on the user's status. If a user has an administrative level clearance, more values may be changed via the tabs 802 - 814 . If a user is a normal user, a screen such as the default values screen 850 shown in FIG. 13B is displayed. The default values screen 850 in FIG. 13B only has the counter party filter tab 802 , the default values tab 804 and the users tab 806 . Since the user in this example is only a normal user the parents tab 808 , the companies tab 810 , the products tab 812 and the data values tab 814 in FIG. 13A are not displayed. By selecting the counter party filter tab 802 , a display similar to the one in FIG. 13A is displayed. By selecting the default values tab 804 in either FIG. 13A or 13 B, a default values screen 850 is displayed as shown in FIG. 13B . The default values screen 850 allows a user to enable default values for certain fields in trades of a certain market type or counter party. The default values screen 850 has a filter bar 852 with a market type box 854 and a product box 856 . By selecting a market type box 854 and a product box 856 , a user may display all counter party information and default values in a summary table 860 .
The summary table 860 includes a counter party column 862 and various other columns of field values 864 that represent different data values for the selected market type and product. The summary table 860 has other rows 866 each of which represents different counter parties that trade in the market type and product. The rows 866 each have a selection box 868 . By checking the selection box 868 , a user may select a clear button 870 to clear out all of the values for the selected row for the counter party. A user may also select a check all button 872 to check all of the rows 866 . A user may clear all the checks by selecting a clear all button 874 .
Certain fields in the summary table 860 such as a settlement frequency field 880 have “none” entered. In order to enter values, a user may select the field 880 which causes a pop up window 890 as shown in FIG. 13C to be displayed. The pop up window 890 has a filter bar 892 with a market type box 894 and a product box 896 which will initially have the selected market type and product from the default data screen 850 in FIG. 13B . The pop up window 890 will have selection boxes 898 that correspond to the fields that were selected from FIG. 13B . Each selection box 898 has a pull down list 900 which lists different default values. A user may select a default value or enter another value in the box 898 . The default values will be initially selected to none until changed by the user.
A show all button 902 allows a user to display other fields that may have default values set up for the particular product and market. The entered default values may be saved via a save button 904 and the pop up window 890 may be closed via a close button 906 .
It will be apparent to those skilled in the art that various modifications and variations can be made in the method and system of the present invention without departing from the spirit or scope of the invention. Thus, the present invention is not limited by the foregoing descriptions but is intended to cover all modifications and variations that come within the scope of the spirit of the invention and the claims that follow.
Claims ( 45 )
Priority Applications (3)
Applications Claiming Priority (5)
Publications (2)
ID=39873215.
Family Applications (2)
Family Applications After (1)
Country Status (4)
Cited By (2)
Families Citing this family (67)
Citations (50)
Family Cites Families (11)
Patent Citations (53)
Non-Patent Citations (6)
Cited By (3)
Also Published As.
Documentos semelhantes.
Legal Events.
Owner name : INTERCONTINENTAL EXCHANGE, GEORGIA.
Free format text : ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TUPPER, BRUCE;VICE, CHARLES;XIA, DONGCHUN;AND OTHERS;REEL/FRAME:013657/0183.
Owner name : INTERCONTINENTAL EXCHANGE, GEORGIA.
Free format text : ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MARCIAL, EDWIN;REEL/FRAME:014525/0236.
Owner name : INTERCONTINENTALEXCHANGE, INC., GEORGIA.
Free format text : CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED ON REEL 013657 FRAME 0183. ASSIGNOR(S) HEREBY CONFIRMS THE THE ASSIGNEE IS INTERCONTINENTALEXCHANGE, INC;ASSIGNORS:TUPPER, BRUCE;VICE, CHARLES;XIA, DONGCHUN;AND OTHERS;REEL/FRAME:026577/0826.
Owner name : INTERCONTINENTALEXCHANGE, INC., GEORGIA.
Free format text : CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED ON REEL 014525 FRAME 0236. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNEE IS INTERCONTINENTALEXCHANGE, INC;ASSIGNOR:MARCIAL, EDWIN;REEL/FRAME:026577/0695.
Owner name : INTERCONTINENTAL EXCHANGE HOLDINGS, INC., GEORGIA.
Free format text : CHANGE OF NAME;ASSIGNOR:INTERCONTINENTALEXCHANGE, INC.;REEL/FRAME:034838/0069.