Sistema de negociação dtc

Interpretação:
Confirmação e Afirmação de Negociações de Valores Mobiliários; Coincidindo.
COMISSÃO DE SEGURANÇA E CÂMBIO.
17 CFR PARTE 241.
(RELEASE Nº 34-39829; ARQUIVO Nº S7-10-98)
CONFIRMAÇÃO E AFIRMAÇÃO DE NEGOCIAÇÕES DE VALORES MOBILIÁRIOS; COINCIDINDO.
AGÊNCIA: Comissão de Valores Mobiliários.
AÇÃO: Liberação Interpretativa; Pedido de Comentários.
RESUMO: A Comissão de Valores Mobiliários e Câmbio ("Comissão") está publicando sua interpretação de que um "& quot; matching & quot; serviço que compara as informações de negociação de valores mobiliários com uma corretora e com o cliente do corretor é uma função da agência de compensação. A Comissão também está solicitando comentários sobre duas abordagens possíveis para fornecer isenção do regulamento de agência de compensação completa para fornecedores de confirmação de comércio eletrônico qualificado ("ETC") que se enquadram na interpretação da Comissão de agência de compensação porque eles fornecem um serviço correspondente. .
DATAS: A interpretação contida na Seção III deste comunicado é efetiva (inserir data de publicação no Registro Federal).
Os comentários devem ser enviados em ou antes (inserir data de 60 dias após a publicação no Registro Federal).
ENDEREÇOS: As pessoas interessadas devem enviar comentários em triplicado para Jonathan Katz, Secretário da Securities and Exchange Commission, 450 5th Street, N. W., Washington, DC 20549-6009. Os comentários podem ser enviados eletronicamente no seguinte endereço de e-mail: rule-comments@sec. gov. Todas as cartas de comentário 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 submetidas eletronicamente serão publicadas no site da Internet da Comissão (sec. gov).
PARA MAIS INFORMAÇÕES, CONTACTE: Jerry W. Carpenter, Subdiretora; Jeffrey Mooney, conselheiro especial; ou Theodore R. Lazo, advogado; em 202 / 942-4187, Escritório de Gestão e Controle de Riscos, Divisão de Regulamentação de Mercado, Securities and Exchange Commission, Washington, D. C. 20549.
INFORMAÇÃO SUPLEMENTAR:
Recentemente, a New York Stock Exchange ("NYSE"), a National Association of Securities Dealers ("NASD") e o Municipal Securities Rulemaking Board ("MSRB") (coletivamente "SROs") propuseram mudanças de regras propostas de acordo com a Seção 19 (b) do Securities Exchange Act de 1934 ("Exchange Act") 1 para alterar suas regras referentes ao processamento pós-negociação de negócios executados por seus membros. Os SROs & # 146; as regras atuais exigem que seus membros corretor-revendedor usem as facilidades de um depositário de títulos 2 para a confirmação eletrônica e afirmação de transações em que o corretor oferece pagamento contra pagamento ("DVP") ou recebimento contra pagamento (& quot; ; RVP & quot;) 3 privilégios para o seu cliente (& quot; regras de confirmação SRO & quot;). 4 Como uma questão prática, as regras de confirmação do SRO exigem que os corretores usem o sistema de Entrega Institucional ("ID") da Depository Trust Company ("DTC") porque é o único serviço de confirmação / afirmação oferecido por um depositário de valores mobiliários. 5 De acordo com as alterações propostas às regras de confirmação do SRO, os corretores terão permissão para usar entidades que não sejam agências de compensação registradas para confirmação e confirmação de transações RVP / DVP, desde que as entidades sejam fornecedores qualificados de ETC, conforme definido pelo SRO. regras. Um intermediário de fornecedor de ETC qualificado apenas transmitirá informações entre as partes de um negócio, e as partes confirmarão e confirmarão a exatidão das informações.
A Comissão entende que o próximo passo na evolução do processamento pós-negociação será o desenvolvimento de serviços de correspondência. & quot; Correspondente & quot; é o termo usado para descrever o processo pelo qual um intermediário reconcilia informações comerciais do corretor e seu cliente para gerar uma confirmação afirmada que é então usada para efetuar a liquidação do negócio.
A Comissão considera 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) do Exchange Act. 6 Especificamente, a correspondência constitui "comparação de dados respeitando os termos de liquidação de transacções de valores mobiliários". A Comissão conclui que a correspondência está tão intimamente ligada ao processo de compensação e liquidação que é diferente, não só em grau, mas também em espécie, do atual processo de confirmação e afirmação. O objetivo deste comunicado é buscar o comentário sobre o conceito de oferecer isenção, seja através do registro de agências de compensação sujeitas a requisitos reduzidos ou através da concessão de uma isenção condicional de registro para fornecedores de EPT qualificados que forneçam um serviço de correspondência.
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 custodiantes sobre os termos de uma negociação executada pelo investidor institucional. Como as negociações de investidores institucionais envolvem somas maiores de dinheiro, quantias maiores de títulos, mais partes e mais etapas entre a entrada de pedidos e a liquidação final, as negociações institucionais são geralmente mais complexas do que as transações de varejo.
1. Confirmação usando o sistema de identificação.
Os componentes típicos do & quot; lado do cliente & quot; A liquidação de um comércio institucional sob as atuais regras de confirmação do SRO estão ilustradas na Figura 1. 7.
Normalmente, um comércio institucional começará com o gerente de investimento da instituição fazendo um pedido com o corretor. Após o corretor negociar a negociação, o corretor informará a instituição dos detalhes da execução. Isso é comumente chamado de aviso de execução (etapa 1 da Figura 1). A instituição então aconselha a corretora sobre como o negócio deve ser alocado entre suas contas (etapa 2 da Figura 1). 8 O corretor-negociante submete então os dados de negociação ao DTC (etapa 3 da Figura 1).
Em seguida, o DTC adiciona a transação ao banco de dados comercial do sistema de identificação, atribui um número de controle de identidade 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 revisa a confirmação da precisão. Se preciso, a instituição ou seu agente de afirmação designado afirma o comércio através do sistema de identificação (etapa 5 da Figura 1). O DTC gera então uma confirmação afirmada e envia-a ao corretor e ao agente de liquidação da instituição (passo 6 da Figura 1). 9 Neste ponto, a negociação é enviada para o sistema de liquidação da DTC (isto é, o sistema de identificação não é um sistema de liquidação em que nenhum dinheiro ou títulos se movem através dele) e deve ser autorizado pela parte obrigada a entregar os títulos. (ou seja, a parte vendedora) ou o agente de liquidação antes da liquidação ocorrer (etapas 7 e 8 da Figura 1). "Controle de Qualidade" envolve o monitoramento e a produção do 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 (etapa 9 da Figura 1).
2. Confirmação Utilizando um Fornecedor ETC Qualificado.
Sob as mudanças propostas na regra do SRO, um fornecedor ETC qualificado pode ser usado para o processo de confirmação / afirmação. O corretor-negociante submete os dados de negociação para o fornecedor de EPT qualificado que gera e envia uma confirmação para a instituição (etapas 3 e 4 da Figura 1). Após revisar a confirmação, a instituição envia uma declaração ao corretor através das instalações do fornecedor de EPT qualificado (etapa 5 da Figura 1). Em algum ponto desse processo, o fornecedor ETC qualificado encaminha a confirmação ao DTC em um formato de sistema de identificação para que o DTC possa atribuir um número de controle de ID ao negócio. O DTC envia a confirmação com o número de controle de volta ao fornecedor ETC qualificado, e o fornecedor ETC qualificado fornece o número de controle ao corretor e à instituição. Após o recebimento da afirmação da instituição, o fornecedor ETC qualificado envia a confirmação afirmada com o número de controle de ID para o DTC no formato do sistema de identificação. Nesse processo, um fornecedor de EPT qualificado só transmite informações entre as partes do negócio e as partes confirmam a exatidão das informações.
Os componentes da liquidação do lado do cliente de um comércio institucional através de um & quot; matching & quot; sistema são ilustrados na Figura 2.
& quot; Correspondente & quot; é o termo usado para descrever o processo pelo qual um intermediário compara a submissão de dados comerciais do intermediário (etapa 2 da Figura 2) com as instruções de alocação da instituição (etapa 1 da Figura 2) para determinar se as duas descrições do comércio . 10 Se os dados do comércio e as instruções de alocação da instituição coincidirem, é produzida uma confirmação afirmada (etapa 3 da Figura 2). Isso eliminaria as etapas separadas de produzir uma confirmação (etapa 4 da Figura 1) para a instituição revisar e afirmar (etapa 5 da Figura 1). Neste ponto, a negociação entra no processo de liquidação da DTC, mas deve ser autorizada pelo agente da parte cedente antes que ocorra a liquidação (etapas 4 e 5 da Figura 2). 11
III CORRESPONDÊNCIA COMO FUNÇÃO DE AGÊNCIA DE COMPENSAÇÃO.
A Seção 3 (a) (23) (A) do Exchange Act define uma agência de compensação como “qualquer pessoa que atue como intermediária na realização de pagamentos ou entregas, ou ambas relacionadas a transações de valores mobiliários ou que forneça recursos para comparação de dados respeitando os termos de liquidação de transacções de valores mobiliários, para reduzir o número de liquidações de transacções de valores mobiliários, ou para a atribuição de responsabilidades de liquidação de valores mobiliários. 12 A Seção 17A do Exchange Act e a Regra 17Ab2-1 abaixo exigem que qualquer pessoa que se dedique a qualquer uma dessas funções se registre na Comissão como órgão de compensação ou obtenha uma isenção de registro. 13
Com base no idioma, propósitos 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 vendedor de títulos e realiza uma conciliação independente ou correspondência dessas informações é fornecendo facilidades para a comparação de dados dentro do escopo da Exchange Act, Seção 3 (a) (23). 14 Como resultado, o intermediário está desempenhando uma função de agência de compensação. Consequentemente, sob esta interpretação, apenas uma entidade registrada como agência de compensação ou isenta de tal registro pode fornecer um serviço de correspondência.
O histórico legislativo das Emendas às Leis de Valores Mobiliários de 1975 ("Emendas de 1975") apóia essa interpretação estatutária, 15 incluindo os propósitos de estabelecer um sistema nacional de compensação e liquidação e o escopo de autoridade concedida à Comissão. Além disso, considerar que um serviço de correspondência é uma função de agência de compensação é consistente com os propósitos do regulamento da Lei de Câmbio do sistema de compensação e liquidação. O Congresso considerou o sistema de compensação e liquidação no início dos anos 70 como inadequado e, nas Emendas de 1975, ordenou à Comissão que facilitasse o desenvolvimento de um sistema nacional melhorado de compensação e liquidação. O Congresso articulou os objetivos desse sistema nacional na Seção 17A do Exchange Act, 16 e deu à Comissão a autoridade e responsabilidade de regular, coordenar e dirigir as operações de todas as pessoas envolvidas no processamento de transações de títulos visando o objetivo de um sistema nacional o apuramento rápido e preciso e a liquidação de transacções de valores mobiliários. 17 O Congresso se recusou especificamente a abordar os méritos de qualquer sistema em particular ou a ditar a forma que um sistema nacional de compensação e liquidação deveria tomar. 18 Em vez disso, o Congresso reconheceu que "processamento de dados e técnicas de comunicação" envolvidos nos processos de liquidação e liquidação continuariam a evoluir. 19 Consequentemente, a Comissão recebeu uma ampla autoridade sobre o sistema de compensação e liquidação e um amplo poder discricionário para determinar quais as atividades abrangidas pela função de agência de compensação que desencadeiam o requisito de registo como uma agência de compensação.
Na verdade, o processo de liquidação e liquidação para as transações institucionais evoluiu dramaticamente. Quando as Emendas de 1975 foram promulgadas, o processamento dos 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 de confirmação eletrônica e afirmação de negócios institucionais foram adotadas em resposta à crescente complexidade dos negócios institucionais e à necessidade de automatizar o processo. Hoje, o volume de negócios institucionais cresceu até um ponto em que eles agora respondem por uma grande parte da atividade comercial nos mercados de valores mobiliários norte-americanos. 20 Devido ao aumento do volume e da complexidade dos negócios institucionais, praticamente todos eles agora são processados ​​por meio de sistemas eletrônicos.
A correspondência está inextricavelmente interligada com o processo de liquidação e liquidação. Um fornecedor que forneça um serviço de comparação comparará ativamente as informações de comércio e alocação e emitirá a confirmação afirmada que será usada na liquidação da transação. 21 Além disso, a correspondência aborda duas áreas que a Comissão e o setor de valores mobiliários consideram críticas para a manutenção de um sistema sólido de compensação e liquidação: reduzir os erros e reduzir o tempo de liquidação.
Como mencionado acima, a correspondência combina certas etapas no processo de confirmação e afirmação e, portanto, pode ajudar a reduzir erros. A correspondência efetiva também será essencial em qualquer esforço para encurtar o ciclo de liquidação. 22 Ao mesmo tempo, a correspondência concentra o processamento do risco na entidade que realiza a 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 uma etapa de afirmação separada que permitiria a detecção de erros que poderiam atrasar a liquidação ou fazer com que a negociação falhasse. 23
Por conseguinte, a Comissão considera que uma entidade que fornece a correspondência teria um impacto significativo no sistema nacional de compensação e liquidação. O desmembramento da capacidade de um sistema emparelhar de comparar com precisão as informações comerciais de centenas de instituições e corretoras que envolvem milhares de transações e milhões de dólares em valores mobiliários pode resultar em uma falha sistêmica generalizada do sistema nacional de compensação e liquidação. . 24 Sem qualquer autoridade regulamentar sobre os fornecedores correspondentes, a Comissão teria apenas uma capacidade limitada para se precaver contra tal falha. O Congresso concedeu à Comissão amplos poderes para estabelecer um sistema centralizado de regulamentação sobre o sistema nacional de compensação e liquidação, a fim de evitar que tal situação ocorra. 25 Tendo em conta o papel significativo desempenhado pelos serviços de correspondência e com o âmbito da definição, a Comissão considera que alguma forma de regulamentação é adequada para garantir o apuramento e a liquidação rápidos e exatos dos valores mobiliários. 26
IV. ABORDAGENS REGULAMENTARES POSSÍVEIS.
Embora os serviços de correspondência sejam abrangidos pela definição de agência de compensação, a Comissão considera, a título preliminar, que uma entidade que limita as suas funções de agência de compensação à prestação de serviços de correspondência não está sujeita à plena panóplia de regulação das agências de compensação. A Comissão tem ampla autoridade de isenção nos termos da Seçã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 Secção 17A se a Comissão considerar que tal isenção é consistente com o interesse público, a protecção dos investidores e os objectivos do Seção 17A.
Duas abordagens alternativas podem fornecer uma estrutura reguladora apropriada para entidades que fornecem recursos de correspondência: registro limitado ou isenção condicional. De acordo com qualquer uma das abordagens, apenas os requisitos regulamentares que a Comissão considera necessários e apropriados para alcançar os objetivos da Seção 17A seriam aplicáveis ​​a uma entidade que oferecesse uma facilidade correspondente. 27 A alternativa de registro limitada é um & quot; redimensionado & quot; abordagem, que registraria o provedor de serviços de correspondência como uma agência de compensação, ao mesmo tempo em que oferecia isenções dos requisitos de agências de compensação individuais. A alternativa de isenção condicional é um & quot; bloco de construção & quot; abordagem, o que isentaria a entidade do registo da agência de compensação, sujeito a condições adequadas. 28 De acordo com qualquer abordagem, a Comissão publicaria para comentários uma notificação do pedido do fornecedor de EPC qualificado para registo limitado ou isenção condicional, incluindo os termos propostos para o registo ou isenção, antes de aprovar o pedido. 29
A Comissão solicita aos comentadores & # 146; pontos de vista sobre se o registro limitado da agência de compensação ou a isenção condicional do registro das agências de compensação é a melhor alternativa para regulamentar os fornecedores de EPT qualificados que fornecem serviços correspondentes. Uma ou ambas as alternativas propostas fornecem um método prudente para garantir a segurança e solidez do sistema nacional de compensação e liquidação de transacções de valores mobiliários e o desenvolvimento contínuo de mecanismos de apuramento ligados e coordenados sujeitos a normas uniformes? De um modo geral, quais os requisitos da agência de compensação nos termos da Seção 17A (b) seriam necessários e apropriados para os serviços correspondentes, e quais não seriam? Existem outras alternativas através das quais a Comissão poderia manter a supervisão da correspondência por parte de fornecedores de CTE qualificados que assegurariam a segurança e solidez do sistema nacional de compensação e liquidação?
Lista de Assuntos em 17 CFR Parte 241.
Alteração do Código de Regulamentos Federais.
Pelos motivos expostos no preâmbulo, o Título 17, Capítulo II do Código de Regulamentações Federais é emendado conforme estabelecido abaixo:
PARTE 241 - LIBERTAÇÕES INTERPRETATIVAS RELACIONADAS À LEI DE CÂMBIO DE VALORES MOBILIÁRIOS DE 1934 E REGRAS GERAIS E REGULAMENTOS NESTE DOCUMENTO.
A parte 241 é emendada pela adição do Release No. 34-39829 e a data de lançamento de 6 de abril de 1998 para a lista de releases interpretativos.

Protocolo de Comunicação de Dados e Negociação (DTC).
Introdução ao Protocolo DTC.
O Protocolo de Comunicação de Dados e Negociação (Protocolo DTC abreviado) é um protocolo de comunicações abertas para a comunidade comercial do mercado financeiro.
O Protocolo DTC é uma iniciativa para estabelecer um protocolo de comunicações aberto para dados do mercado financeiro, negociação, dados históricos do mercado e dados históricos de preços.
O Protocolo DTC define um conjunto comum de mensagens e campos dentro dessas mensagens, e possui procedimentos claros para trabalhar com essas mensagens e campos para criar interoperabilidade confiável e plug-and-play entre Clientes e Servidores trabalhando com dados do mercado financeiro e funções de negociação .
O protocolo DTC é baseado no protocolo FIX, tanto quanto possível. Mensagens e campos de negociação estão intimamente relacionados ao protocolo FIX.
Os dados de mercado no Protocolo DTC seguem um modelo usado por feeds de dados bem projetados e eficientes.
O protocolo DTC permite qualquer negociação manual, negociação automatizada / algorítmica, gráficos, análise de mercado ou um tipo semelhante de programa (o cliente) e serviços de dados e negociação de mercado (o servidor), para interagir uns com os outros de forma confiável e eficiente.
Este protocolo é para qualquer tipo de usuário, seja um indivíduo escrevendo um programa para uso próprio, um provedor comercial de software de negociação e gráficos, um operador institucional de alta frequência ou um provedor de serviços de Dados ou Negociação.
A definição de um serviço "Dados" é um serviço que fornece dados do mercado financeiro. A definição de um serviço de "Negociação" é um serviço que pode fornecer dados do mercado financeiro, fornece conectividade a trocas ou opera sua própria troca, e eles também podem lidar com transações de clientes.
Este é um protocolo projetado para trabalhar diretamente em um link de comunicação de rede e pode ser usado em conexões de rede SSL / TLS e não-SSL / TLS.
O protocolo DTC é um protocolo de mensagens simples. No Protocolo do DTC, o Cliente e o Servidor trocam mensagens entre si com campos e procedimentos bem definidos.
O termo Mensagem refere-se a uma instância de mensagem enviada por um link de comunicação de rede seguro ou não seguro, que normalmente é uma conexão TCP / IP pela Internet.
Existem diferentes métodos de codificação que são suportados pelo protocolo DTC.
A documentação completa dos campos Mensagens e Mensagem do Protocolo DTC pode ser encontrada na página Mensagens e Procedimentos do DTC.
É senso comum que é melhor para os provedores de serviços de Data e Trading, e os usuários que programam para esses serviços, seguirem um protocolo de comunicações padrão.
Em vez de um cliente escrevendo para o protocolo ou API usado pelo servidor, que geralmente é o caso, ou o servidor escrevendo para o protocolo ou API usado pelo cliente, menos frequentemente o caso, agora há uma especificação única, neutra e aberta protocolo que cada lado irá escrever. Portanto, nem o servidor nem o cliente estão executando um trabalho de integração específico de um determinado cliente ou servidor.
O modelo de trabalho adequado é que nenhum dos lados está se integrando aos outros serviços / produtos e cada lado usa um protocolo padronizado comum no qual eles se concentram e garantem 100% de confiabilidade e compatibilidade.
DTC é completamente neutro. O que isto significa é que não favorece o cliente ou o servidor.
Pense se um navegador da Web precisou ser projetado para funcionar com um protocolo diferente de todos os sites existentes. Isso faria sentido? A resposta óbvia é que isso não faz sentido e é por isso que é necessário estabelecer um protocolo de especificação aberto comum. O protocolo DTC é a solução.
Padrões são muito comuns em comunicações eletrônicas de dados e redes eletrônicas físicas. A Internet nem seria possível sem padrões. Existe o padrão TCP / IP. Camadas de hardware são altamente padronizadas. Existe um padrão para Ethernet. Não há como as redes físicas poderem interoperar sem padronização.
Onde a Internet estaria sem padrões de comunicação? O crescimento explosivo visto na Internet, que começou nos anos 90, ao longo da primeira década do século XXI, e continua até hoje, não teria ocorrido sem padrões.
Quando o programa de negociação ou de gráfico de cliente de front-end suporta muitos serviços externos, trabalhar com vários protocolos ou APIs torna-se difícil e problemático, especialmente se componentes de API em processo são usados.
É a opinião de que, no processo, os componentes da API são muito problemáticos e se são de código aberto ou caixa preta, forçam o desenvolvedor a usá-los para seguir um determinado modelo de entrada-saída que pode não corresponder ao Cliente ou Servidor que os está usando.
Um programa aplicativo, seja ele suporte a negociação manual, negociação algorítmica, gráficos, análise de mercado ou qualquer outra coisa, se ele suportar o Protocolo DTC, será automaticamente compatível com qualquer Servidor que também suporte o DTC.
É muito mais produtivo para os desenvolvedores de sistemas Clientes e Servidores se concentrarem em manter e integrar um único protocolo de especificação aberta, em vez de vários protocolos / APIs que existem nesta indústria.
No caso do Cliente, há muito mais tempo disponível para o desenvolvimento do software do cliente, em vez de se integrar aos Servidores e lidar com os vários problemas associados.
Tanto o Cliente quanto o Servidor trabalharão duro para seguir estritamente o protocolo, portanto, há compatibilidade automática. Este é um requisito do protocolo DTC.
Por que não corrigir?
O FIX é considerado um protocolo de alta sobrecarga para dados de mercado. O FAST é uma solução para isso, mas tecnicamente é complexo de implementar.
Para alguns usuários, o FIX não é facilmente implementado e usado. Os provedores de serviços de dados e negociação sabem que muitos de seus clientes terão dificuldade em usar o FIX.
Em uma conexão TCP / IP autenticada, o FIX possui campos desnecessários, como o ID do Remetente, o ID de Destino de Destino e a soma de verificação.
FIX não é um padrão rigoroso. Embora um Cliente e o Servidor possam implementar o FIX, eles não são automaticamente compatíveis entre si, a menos que sigam uma implementação específica do FIX na qual concordam.
O FIX não tem mensagens para dados de preços históricos. E também o FIX não é eficiente com o transporte de dados históricos. Considerando que a DTC, tem suporte total para dados históricos de preços da maneira mais eficiente possível.
O protocolo DTC é muito eficiente e requer uma largura de banda de rede mínima ao usar codificação binária.
A padronização é possível?
É possível padronizar os dados do mercado financeiro e a negociação?
Para responder a essa pergunta, é necessário que observemos exatamente o que está sendo comunicado entre clientes e servidores.
Para dados de mercado, trata-se da comunicação de um Servidor para um Cliente em resposta a solicitações do Cliente, de dados de preços, índices ou indicadores. Esse tipo de dados consiste em dados de captura instantânea representando valores de Liquidação, Abertura, Alto e Baixo e vários outros campos durante a sessão de negociação, além de atualizações em tempo real para esses campos. Tudo isso é facilmente padronizado. A atividade histórica desses dados de preços também é facilmente padronizada.
Para negociar, um Cliente precisará enviar um pedido para comprar ou vender um determinado título ao Servidor e receber atualizações sobre o status do pedido e as posições para a conta ou várias contas. Entrada de pedidos e posições também têm campos comuns na negociação no mercado financeiro. Portanto, a padronização é possível.
O próprio fato de que o protocolo FIX existe, também prova que a padronização é possível. Embora o protocolo FIX não seja um protocolo plug-and-play altamente padronizado. O protocolo DTC é.
Por que nós, como cliente ou servidor, devemos adotar o DTC?
Quer você desenvolva uma análise de mercado do lado do cliente e / ou programa de negociação, ou um serviço de dados ou comércio do lado do servidor, a adoção do Protocolo DTC aumenta muito suas opções de conectividade com outros clientes e servidores que adotam o Protocolo DTC.
A longo prazo, reduz as despesas de desenvolvimento relacionadas à integração com outros Clientes ou Servidores, porque um protocolo padronizado comum está sendo usado.
Os usuários do Protocolo DTC seguem um protocolo comum que facilita a compatibilidade plug-and-play quase imediata entre si.
Conexões entre Clientes e Servidores são muito simplificadas e fáceis de manter porque um protocolo padrão está sendo seguido.
Se você é o cliente ou o servidor, ou ambos, é o espírito do protocolo DTC que cada lado se esforçará para seguir este protocolo para que haja total compatibilidade e confiabilidade.
Não é o propósito do protocolo DTC substituir quaisquer protocolos proprietários ou métodos de integração que um Cliente ou Servidor já implementa ou gostaria de implementar.
O que temos atualmente neste setor é desorganizado com tantos tipos diferentes de métodos e protocolos de conectividade. Isso é realmente combinado quando essas APIs proprietárias em processo são usadas.
Faz mais sentido para todos nós nos concentrarmos no desenvolvimento de nossos próprios produtos e serviços, em vez de ter alguém que esteja interessado em nosso produto ou serviço, para então ter que passar pelo tempo, esforço e despesa para integrar-se a ele usando uma propriedade proprietária. método.
Se o método de integração proprietária envolve um componente de API, isso provou ser confuso e ter dificuldades contínuas e forçar o outro lado a seguir o modelo de entrada-saída criado por alguém fora de sua equipe de desenvolvimento. Na prática, esse tipo de modelo é altamente impraticável e problemático. A indústria deve evitar o uso de componentes de API proprietários.
O protocolo DTC é um protocolo plug-and-play. Portanto, os clientes e servidores que implementam esse protocolo podem começar imediatamente a interoperar uns com os outros sem esforço. Haverá alguns casos especializados, onde isso pode não ser bem o caso. No entanto, em geral, este é o objetivo do Protocolo DTC.
Para serviços que fornecem serviços de negociação, ao adotar o Protocolo DTC, você pode garantir que o processamento de pedidos no lado do cliente seja feito corretamente.
O Protocolo do DTC usa a mensagem ORDER_UPDATE para atualizar uma ordem de negociação e fornecer o motivo da atualização e o status atual do pedido por meio dos campos OrderUpdateReason (equivalente ao campo FIX ExecutionType) e OrderStatus.
A mensagem ORDER_UPDATE é uma única mensagem unificada para o servidor fornecer qualquer tipo de feedback relacionado a um pedido de negociação. Ao usar esta mensagem, não há espaço para um Cliente interpretar erroneamente um estado de ordens e para manipular incorretamente um pedido.
Considerando que, com APIs e protocolos proprietários, geralmente leva muito tempo através da leitura da documentação da API, teste e feedback do usuário que a manipulação da ordem de negociação foi implementada adequadamente para um serviço de negociação. Este não é um resultado desejável porque fornece uma experiência negativa ao usuário. O protocolo DTC resolve esse problema.
Uma implementação completa dos cabeçalhos do Protocolo DTC, não aplicável à codificação JSON, é definida e pode ser usada livremente.
A documentação completa e formal está disponível para este protocolo. Você está convidado a fazer uma cópia desta documentação. Não há direitos autorais aqui.
A única maneira em que a interoperabilidade fácil entre Clientes e Servidores pode ser alcançada é abraçando e suportando um protocolo comum. Nós não vamos resolver o problema atual que existe na indústria, fazendo nada. Todos nós devemos avançar com isso.
Você precisa se perguntar, você pode sobreviver a longo prazo sem seguir padrões bem projetados? Você vai ficar isolado seguindo seus próprios protocolos proprietários?
Se você for um provedor de serviços de dados ou de negociação, poderá se convencer de que os usuários existentes que integraram seus protocolos e APIs estão satisfeitos com o que você oferece. Como você sabe que eles não ficarão ainda mais satisfeitos com o Protocolo DTC? Especialmente sendo este é um protocolo de comunicação muito básico que pode servir como base para métodos de interface de alto nível que usam o Protocolo DTC em seu núcleo.
Quem usa o DTC?
Além do acima, há programas de servidor independentes do lado do cliente que usam o protocolo DTC e estabelecem uma ponte entre um cliente DTC e servidores não-DTC. Um foi desenvolvido para o serviço de plataforma de negociação backend Rithmic e também o serviço de dados TeleTrader.
Nome e logotipo.
O nome desse protocolo é o protocolo DTC. Isso significa Data and Trading Communications Protocol.
O logotipo está abaixo.
As imagens do logotipo da DTC foram doadas para a comunidade para uso livre. The only conditions are that they are used in association with the Data and Trading Communications Protocol and that you use them only if you implement the DTC protocol either on the Client and/or the Server side.
Working Group.
To be part of the DTC Protocol working group, contact us at [Java Script Is Required. To View The Email, enable Java Script] .
The working group responsibilities are to implement and maintain the DTC Protocol according to the intentions described on this page.
This protocol is adaptable. New messages can be added and fields can be added to existing messages.
The LOGON_RESPONSE message has flags indicating what messages the Server supports.
The Client will support the messages that it needs to based upon the requirements of the Client.
For information about how new fields are handled in existing messages, refer to Versioning.
Tight Protocol With Support for New Message Types.
The FIX protocol has variations in the tags used in specific FIX messages, some variations with the specific meaning of the different message tags, no strict standard for Order ID handling, and uses custom tags.
With the DTC Protocol, it is designed to be a tightly defined protocol with a clear set of messages and fields which have specific meanings. The protocol is also expandable.
Anyone using this protocol, should be able to connect to the other side, and expect everything to work properly. This is the purpose of the protocol.
To request new message types and add fields to an existing message, contact [Java Script Is Required. To View The Email, enable Java Script] and request the particular messages and/or fields to be added. The major working group members will review and evaluate the request and discuss it with you.
In the case of binary encoding, new fields must always be added onto the end of a structure. Existing structure fields must not change in order to maintain protocol safety.
New message types which are considered very proprietary need to have a Type number that is in the 10000 range.
The DTC Protocol recognizes that some messages will be unsupported by a Server. If a Server does not support a particular message category, indicate so through the corresponding flags in the LOGON_RESPONSE message.
Message Format and Encoding.
In the current implementation of DTC, the following encodings are defined.
In the case of when separate network connections are used for market data and trading, the market data connection could use Binary Encoding, and the trading connection could use JSON Encoding. Therefore, there is complete flexibility to use multiple encoding methods and the most appropriate encoding method depending upon whether the connection is used for market data or for trading.
The DTC Protocol supports specifying the encoding to be used over the network connection. Refer to the Encoding Request Sequence for the procedure for specifying the encoding.
Binary Encoding.
Binary Encoding is the most basic method of encoding. In binary encoding, messages are encoded using fixed size binary data structures with embedded fixed length strings. This allows for very easy implementation in code, compactness of messages (in the case of market data messages) and very fast performance.
With binary encoding, the beginning of each structure begins with a 2 byte size and a 2 byte type indicating the message type and the total size of the message including the size and type fields.
New messages can be defined when needed and additional fields can be added to the end of existing message structures. The data held in the message structures is directly usable in program code without any translation or parsing.
Binary With Variable Length Strings Encoding.
The Binary With Variable Length Strings Encoding is very similar to the standard Binary Encoding except the fixed length strings from the binary encoded DTC messages are replaced with variable length strings. This enables shorter messages to be sent, and also allows strings that are larger than the defined fixed length strings to be sent.
There is a separate header file, DTCProtocolVLS. h , that redefines messages that contain strings.
Any DTC messages that do not contain strings continue to use the exact same messages as Binary Encoding, so this header should be used along with the main DTC Binary Encoding header file.
DTC messages that contain strings are re-defined by replacing the fixed length string field in the DTC message with a 16-bit Offset and a 16-bit Length field in the data structure. These two fields are contained in the s_VariableLengthStringField structure.
Variable Length String Structure.
The actual variable length strings are appended to the end of the fixed size portion of the DTC message in the stream, and the message Size field includes these bytes. The Offset field specifies the offset from the base on the DTC message where the variable length string starts. The Offset is relative to an index of 0 at the base. The Length field specifies how long the string is, including the null terminator. Variable length strings should always include a null terminating char (zero). If the string is not present, an Offset and Length of zero must be specified which is the default.
In the Binary Encoding with Variable Length Strings C++ Header File, there are functions that show how a string is be added to a message and parsed from a message: AddVariableLengthStringField() and GetVariableLengthStringField() . When sending a message with variable length strings, it is imperative that the strings are sent in the same order that they were added to the base structure.
Each DTC message that supports variable length strings has Add*(uint16_t StringLength) and Get*() functions for adding a string and getting a string respectively in the DTC message.
Similar to the binary encoding, the messages for the Binary with Variable Length Strings Encoding each begin with a 2 byte message size and a 2 byte type indicating the message type.
JSON Encoding.
The JSON Encoding sends each DTC message as a JSON object with name:value pairs. Inherently JSON supports variable length strings and allows the very easy adding and removing of fields. Therefore, it is a flexible encoding method for the DTC Protocol.
Messages using the JSON encoding, do not contain a size field like the binary encoding, and so each DTC JSON message object is separated with a null (8 bit numeric 0) terminator in the network data stream.
Each JSON message needs to be encoded using 8-bit characters. Unicode is not supported.
The name:value pair names match the DTC message field names, and the value portion matches the type of the DTC field.
The values are either a number, a string, an array, or a "null" . A null value indicates that the field is not set. String values are only present for string fields. An array is only present for several DTC messages that contain depth arrays.
An unset field can be left out of JSON object.
The following is a JSON Encoding example of a s_MarketDataUpdateTrade message:
The Type field should be first. Otherwise, the general field order does not matter.
To determine the number for the Type field for a particular DTC message, look up the message type constant in the DTCProtocol. h file and use that message number. Example: LOGON_REQUEST = 1 .
Compact JSON Encoding.
The Compact JSON Encoding sends high frequency DTC messages in a more compact form with no field names, while sending the remaining messages in the standard JSON Encoding.
This encoding maintains many of the strengths of the standard JSON encoding while vastly improving the efficiency of high frequency messages.
Messages using the compact JSON encoding, do not contain a size field like the binary encoding, and so each DTC JSON message object is separated with a null terminator in the network data stream. The Type name:value pair is maintained to allow compact JSON messages to be initially parsed in a similar manner to the standard JSON encoding.
All of the remaining type:value pairs are replaced with a single JSON pair named "F" , and the value contains all of the DTC message fields represented as an array of values in the same order as they exist in the standard DTC Binary Encoding message. Each value matches the type of the corresponding DTC Protocol field.
The values are either a number, a string, an array, or a "null". A null value indicates that the field is not set. String values are only present for string fields. An array is only present for several DTC messages that contain market depth data arrays.
The following is a Compact JSON Encoding example of a s_MarketDataUpdateTrade message:
The Type field must be first. For this encoding, the field order must match the order of the corresponding DTC Protocol Binary Encoding message.
The following types use the compact JSON format:
HEARTBEAT MARKET_DATA_SNAPSHOT MARKET_DATA_SNAPSHOT_INT MARKET_DATA_UPDATE_TRADE MARKET_DATA_UPDATE_TRADE_COMPACT MARKET_DATA_UPDATE_TRADE_INT MARKET_DATA_UPDATE_LAST_TRADE_SNAPSHOT MARKET_DATA_UPDATE_BID_ASK MARKET_DATA_UPDATE_BID_ASK_COMPACT MARKET_DATA_UPDATE_BID_ASK_INT MARKET_DATA_UPDATE_SESSION_OPEN MARKET_DATA_UPDATE_SESSION_OPEN_INT MARKET_DATA_UPDATE_SESSION_HIGH MARKET_DATA_UPDATE_SESSION_HIGH_INT MARKET_DATA_UPDATE_SESSION_LOW MARKET_DATA_UPDATE_SESSION_LOW_INT MARKET_DATA_UPDATE_SESSION_VOLUME MARKET_DATA_UPDATE_OPEN_INTEREST MARKET_DATA_UPDATE_SESSION_SETTLEMENT MARKET_DATA_UPDATE_SESSION_SETTLEMENT_INT MARKET_DEPTH_SNAPSHOT_LEVEL MARKET_DEPTH_SNAPSHOT_LEVEL_INT MARKET_DEPTH_UPDATE_LEVEL MARKET_DEPTH_UPDATE_LEVEL_COMPACT MARKET_DEPTH_UPDATE_LEVEL_INT MARKET_DEPTH_FULL_UPDATE_10 MARKET_DEPTH_FULL_UPDATE_20 HISTORICAL_PRICE_DATA_RECORD_RESPONSE HISTORICAL_PRICE_DATA_TICK_RECORD_RESPONSE HISTORICAL_PRICE_DATA_RECORD_RESPONSE_INT HISTORICAL_PRICE_DATA_TICK_RECORD_RESPONSE_INT.
Google Protocol Buffers (GPB)
The DTC Protocol supports Google Protocol Buffer encoding. All DTC meesages and constants are defined in the Google Protocol Buffer Encoding file.
The proto file is then used with the protocol buffer compiler (protoc) to generate a language specific API like for C++ or whatever language. The generated API is then used to build, encode, decode, and extract messages and message fields.
DTC messages are built using the generated API message object/methods. All DTC messages are then serialized into encoded blocks of data via the SerializeTo() methods in the generated API. These encoded messages are then sent over the network. Because the protocol buffer wire format is not self-delimiting, a small header is used to delimit and describe the encoded messages. The header is a 4-byte header containing a 2-byte unsigned integer size and a 2-byte unsigned integer message type. Each field is sent in little endian format.
The header Size field is set to the length of the encoded message plus the size of the header. The Size field allows the receiver to know when an entire message has been received. The Type field contains the DTC Message type, which are all defined in the DTCMessageType enum in the proto file.
The Type field is then used by the receiver to parse the encoded message into the associated object with the Google Protocol Buffers API Parse() methods. The generated API is then used to access the message fields.
For more information about Google Protocol Buffers, refer to the Google Protocol Buffers Documentation.
Underlying Transport Layer and Security.
The DTC Protocol does not define what the underlying transport layer is for the DTC messages.
For communication over the public Internet, the underlying transport is going to be a TCP/IP network connection.
However, the websocket protocol could also be used. Although we see no advantage of using the websocket protocol in the case of when using TLS over a TCP/IP network connection.
In general, the use of the websocket protocol as the underlying transport layer for the DTC Protocol over the public Internet should be unnecessary unless there is a very specific reason why it is needed.
The underlying connection must use TLS for security when the connection is used for trading. This protects both the Username and Password from being intercepted. And if the security certificate is checked by the Client to ensure that it is from a trusted authority, also verifies that the Client is connecting to a trusted Server.
Server Can Be Local or Remote.
The DTC Protocol supports a Server which can exist remotely on the network, or locally on a client computer. For Data or Trading service providers that do not want to support connectivity straight to their backend, for whatever reason, can still support the DTC Protocol through a local Server program.
For more information about using a local server executable program, refer to Proposal for Using a Local Server Executable Program.
DTC Projects.
The DTC Working Group will provide simple C++ projects which use the DTC Protocol. These will serve as examples.
These will be posted here as they become available.
The full source code will be provided.
Open Specification.
The specifications for the DTC Protocol has no license and is in the public domain.
The greater the adoption of the protocol by Clients and Servers, the greater the success.
The DTC Protocol is designed to be a practical and straightforward protocol that is easy to implement.
Complete and open documentation for the DTC Protocol is found on the DTC Messages and Procedures page. It has no copyrights.
These are the basic objectives of the DTC protocol:
It is the purpose of the DTC protocol to define a common set of messages and fields within those messages, and establish clear procedures for working with these messages and fields in order to create reliable and plug-and-play interoperability between Clients and Servers for the communication of financial market data and trading messages. The header of each message contains the message type, the same as FIX messages. The message types and fields for trading related messages should be the same or similar to FIX where possible and appropriate. The DTC Protocol needs to be simple and should not get out of control with excessive number of messages and fields. Although it will grow as needed. It is for this reason, that managed order types like trailing stops should not be adopted by the standard DTC Protocol implementation.
A Client or Server that follows the DTC Protocol, will be able to reliably establish connectivity to any other side supporting the DTC Protocol.
Patent/License: This protocol has no patent or license. The protocol is in the public domain. The protocol is based upon very straightforward, common sense, and established programming methods. For example, using the beginning of a data block to identify the size and the type of the data block. Therefore, this does not even remotely come close to meet the non-obvious patent test.

Dtc trading system

Development Trading Company is one of the leading and first companies to specialize in the field of Security Printing and Services in the Kingdom of Saudi Arabia and the Gulf Region.
Our Activities Concentrate upon Security field, such as Security Printing, Security Materials, Access Control and Machineries, Participating in Currency Printing, Passports, ID Cards, as well as most of the Government Security Documents is one of our Main Concerned Activity; besides offering a huge range of Security features to such Documents. Through our Good Relationship & Excellent Cooperation with most of the Government Organizations & Agencies, we could developa Harmonically Trustful relationship with most of their Departments which has helped us a lot in running our Business.
Now we are looking to the future with the same Enthusiasm that DTC started with, assuring our partners and our dealers that they will have the best assistance and support in the Kingdom of Saudi Arabia.
RFID in hospitals Live stock system RFID library systems Asset & Inventory systems.
Building up a brand costs millions - protecting it costs only a fraction of this. Optical security features from DTC protect your image and offer an effective defense against counterfeiting. These economical and widely-used features ensure that genuine products stay genuine.
To prevent loss of sales and damage to your image, effective product protection is becoming more and more important - for example, through optically variable security features from DTC.
Medical Products Food & Drinks Products Entertainment Products Commercial Products.

Deposit/Withdrawal At Custodian - DWAC.
What does 'Deposit/Withdrawal At Custodian - DWAC' mean.
Deposit/withdrawal at custodian (DWAC) is a method of electronically transferring new shares or paper share certificates to and from the Depository Trust Company (DTC), using a Fast Automated Securities Transfer service (FAST) transfer agent as the distribution point. The deposit/withdrawal at custodian (DWAC) is one of two ways of transferring between broker/dealers and the DTC, the other being the Direct Registry System (DRS) method. Both enable investors to hold securities in registered form on the books of the transfer agent, rather than in physical form. DRS is different from DWAC in that shares in DRS have already been issued and are held electronically on the books of the transfer agent.
Stock Certificate.
Transferência de livros.
SEC Form TA-2.
BREAKING DOWN 'Deposit/Withdrawal At Custodian - DWAC'
The DWAC process offers a number of benefits to investors, including time and cost savings and lower risk.
As an electronic system, DWAC allows for immediate transfer to a brokerage account. There is no time needed for physical delivery so the settlement process is made more efficient and significantly accelerated. It also saves on costs associated with printing a physical certificate and mailing.
Because there are no physical certificates transferred, there is no risk of loss or damage when transporting and handling such certificates.
While not typically a concern of investors, there are several requirements for DWAC. Shares must be free trading or eligible for restriction removal. The broker must be a DTC participant and the issuer must be DWAC eligible.
What is FAST?
The Fast Automated Securities Transfer Program (FAST) is a contract between DTC and transfer agents whereby FAST agents act as custodians for DTC. It eliminates the movement of physical securities.
The FAST program facilitates the industry’s dematerialization efforts and plays a significant role in reducing the costs associated with shipping certificates to and from agents as well as those related to printing and processing certificates. The FAST program does not apply to money market securities.
Requesting and Delivering Physical Certificates.
While this process is electronic, shareholders can still withdraw their stock from their brokerage accounts and request a physical stock certificate by either having the broker initiate the request through DTC or by having their broker send the shares electronically directly to the transfer agent through the DWAC system. There may be fees for this service.
Shareholders can deposit their stock into a brokerage account by either sending their physical stock certificate to their broker or by having the transfer agent send the shares directly to the broker through the DWAC system.
To deposit your shares to your broker via DWAC, shareholders must provide original stock certificate(s), the DWAC deposit form and applicable fees.

Dtc trading system

DTC Eligibility and Issues.
The Depository Trust Company (“DTC”) is a central securities depository in the U. S. which was originally created as a central holding and clearing system to handle the flow of trading securities and the problems with moving physical certificates among trading parties. The DTC is regulated by the SEC, the Federal Reserve System and the New York State Department of Financial Services. Today, and as noted by the SEC, the “… DTC provides clearance, settlement, custodial, underwriting, registration, dividend, and proxy services for a substantial portion of all equities, corporate and municipal debt, exchange traded funds, and money market instruments available for trading in the United States.”
DTC eligibility is an important aspect of being a public company for all OTC Issuers. Obtaining and maintaining eligibility is of utmost importance for the smooth trading of an Issuer’s float in the secondary market. Moreover, DTC eligibility is a prerequisite for OTC Issuers’ shareholders to deposit securities with their brokers and have such securities be placed in street name. Legal & amp; Compliance keeps abreast of DTC requirements to assist clients in avoiding disruptions to their stock trading activity.
Like a Form 15c2-11 submittal to FINRA, an Issuer cannot make direct application to the DTC for eligibility. An application must be submitted and sponsored by a DTC Participant. A current list of DTC Participants can be found on the DTC website. Many market makers and transfer agents maintain a relationship with DTC participants and can arrange the application process on an Issuer’s behalf.
A Participant can submit an application for a new offering or for a security that has already been issued and is already trading on the OTC market. Note that already-traded securities will be reviewed for eligibility following a reorganization, such as a reverse merger.
Prior to submittal of the application, the Issuer must have a transfer agent and that transfer agent must have a completed DTC Operational Arrangements Agent Letter on file with the DTC and must be participating in the DTC’s Fast Automated Securities Transfer (“FAST”) program. Accordingly, and obviously, this is one of the first questions an Issuer should ask when choosing a transfer agent.
Where the Issuer’s securities are already issued and outstanding (not a new offering), the Participant will need to submit a copy of the physical certificate and a transfer Agent Attestation Form. Most of the forms are PDF fill-in forms and can be uploaded or printed directly from the website. An eligibility application will be reviewed for completeness and will be subject to comments. It is the responsibility of the Participant sponsoring the application to address the comments and provide all information requested. An Issuer should work closely with the Participant to make sure all information is accurate, complete and up to date.
The DTC will also require a legal opinion. Legal opinion letters must be provided by an experienced securities practitioner, properly licensed and in good standing with their bar association. Letters will not be accepted from in-house counsel and the opining attorney may not have a beneficial ownership interest in the security covered by the letter and may not be an officer, director or employee of the Issuer.
The DTC Operational Arrangements criteria (available on the DTC website) sets forth in-depth requirements for eligibility. In addition to the Operational Arrangements, in order to be DTC eligible, an Issuer’s securities must:
(i) be issued in a transaction registered with the SEC under the Securities Act of 1933, as amended (“Securities Act”);
(ii) be issued in a transaction exempt from registration under the Securities Act and that, at the time of seeking DTC eligibility, are no longer restricted; ou.
(iii) be eligible for resale pursuant to Rule 144A or Regulation S under the Securities Act.
A DTC chill is the suspension of certain DTC services with respect to an Issuer’s securities. Those services can be book entry clearing and settlement services, deposit services (“Deposit Chill”) or withdrawal services. A chill can pertain to one or all of these services.
For a chill on all services, including book entry transfers, deposits, and withdrawals, the term of art is a “Global Lock.”
On March 15, 2012, the Securities and Exchange Commission (SEC) issued an administrative opinion stating that an Issuer is entitled to due process proceedings by the DTC as a result of a DTC chill placed on an Issuer’s securities (In the Matter of the Application of International Power Group, Ltd. Admin. Proc. File No. 3-13687). Following International Power, the DTC immediately began changing its procedures in dealing with Issuers, although it was a slow and evolving process. In September 2013, the DTC published a white paper explaining the circumstances under which a Deposit Chill or Global Lock may be imposed, and procedures that the DTC has developed for Issuers, including notice and opportunities to object. Although the DTC also proposed new procedures by filing a rule change with the SEC, they subsequently withdrew the proposed rules.
The attorneys of Legal & Compliance, LLC are experienced in addressing and removing DTC chills and global locks on behalf of OTC issuers. Contact us if you are currently experiencing any of the aforementioned DTC issues.