Instrução Normativa BCB N° 306 🔗 💻 🔒

INSTRUÇÃO NORMATIVA BCB Nº 306, DE 19 DE SETEMBRO DE 2022

Documento normativo revogado, a partir de 1º/3/2024, pela Instrução Normativa BCB nº 456, de 29/2/2024.

Divulga a versão 4.0 do Manual de APIs do Open Finance.

Os Chefes do Departamento de Regulação do Sistema Financeiro (Denor) e do Departamento de Tecnologia da Informação (Deinf), no uso das atribuições que lhes conferem os arts. 23, inciso I, alínea "a", e 62, inciso IV, do Regimento Interno do Banco Central do Brasil, anexo à Portaria nº 84.287, de 27 de fevereiro de 2015, com base no art. 3º, inciso II, da Resolução BCB nº 32, de 29 de outubro de 2020,

R E S O L V E M :

Art. 1º  Esta Instrução Normativa divulga a versão 4.0 do Manual de APIs do Open Finance, de observância obrigatória por parte das instituições participantes, conforme Anexo.

Parágrafo único.  O manual de que trata o caput, em sua versão mais recente, estará acessível na página do Open Finance no sítio eletrônico do Banco Central do Brasil na internet e no Portal do Open Finance no Brasil, mantido pela Estrutura Responsável pela Governança do Open Finance de que trata o art. 44, § 1º, da Resolução Conjunta nº 1, de 4 de maio de 2020.

Art. 2º  Fica revogada a Instrução Normativa nº 130, de 22 de julho de 2021.

Art. 3º  Esta Instrução Normativa entra em vigor em 1º de outubro de 2022.

João André Calvino Marques Pereira                   Haroldo Jayme Martins Froes Cruz
Chefe do Departamento de Regulação                Chefe do Departamento de
do Sistema Financeiro                                            Tecnologia da Informação

ANEXO À INSTRUÇÃO NORMATIVA BCB Nº 306, DE 19 DE SETEMBRO DE 2022

Manual de APIs do Open Finance Versão 4.0

Histórico de revisão

Termos de Uso

Este manual detalha os requisitos técnicos para a implementação dos elementos necessários à operacionalização do Open Finance, complementando a regulamentação vigente sobre o tema.

O manual será revisto e atualizado periodicamente a fim de preservar a compatibilidade com a regulamentação, bem como para incorporar os aprimoramentos decorrentes da evolução do Open Finance e da tecnologia.

Informações mais detalhadas e exemplos da aplicação deste manual poderão ser encontrados nos guias e tutoriais disponíveis no Portal do Open Finance no Brasil, na Área do Desenvolvedor.

Sugestões, críticas ou pedidos de esclarecimento de dúvidas relativas ao conteúdo deste documento podem ser enviados ao Banco Central do Brasil por meio dos canais institucionais dessa autarquia.

Referências

As especificações deste manual baseiam-se, referenciam e complementam, quando aplicável, os seguintes documentos:

1. Introdução

O Open Finance está intrinsecamente ligado ao uso de Application Programming Interface (API), interfaces por meio das quais será possível interligar os diferentes sistemas das instituições. Ao serem disponibilizadas pelos participantes, as APIs precisam satisfazer condições tais como padronização, robustez e segurança, a fim de que o compartilhamento de dados e serviços seja realizado a contento.

Nesse sentido, este manual define os principais aspectos relativos às especificações e implementações das APIs que integram o Open Finance no País, observando as disposições da Resolução Conjunta nº 1, de 4 de maio de 2020, e da Resolução BCB nº 32, de 29 de outubro de 2020.

São tratados neste manual aspectos como: formato para a troca de dados, desenho da interface, protocolo para transmissão de dados, versionamento, modelo de APIs e endpoints. Desse modo, o manual estabelece as diretrizes gerais sem esgotar todos os aspectos necessários à implementação das APIs para o Open Finance. As demais definições a cargo das instituições participantes por meio da estrutura responsável pela governança, nos termos da Circular nº 4.032, de 23 de junho de 2020, estão disponíveis no Portal do Open Finance no Brasil, no qual podem ser encontrados guias, tutoriais e outras informações operacionais sobre as APIs.

Ao longo deste manual, será constante o uso de siglas e terminologia específica para designar algumas expressões cotidianas dos profissionais da área de tecnologia. Alguns exemplos das mais frequentemente utilizadas, com as correspondentes definições, são as seguintes:

I - API (Application Programming Interface): um conjunto de definições sobre como um sistema pode acessar dados ou funcionalidades providos por um outro sistema;

II - REST (Representational State Transfer): estilo arquitetural de software;

III - API RESTful: API que adere às restrições do estilo arquitetural REST;

IV - OpenAPI: linguagem de especificação de APIs RESTful;

V - Endpoint: elemento de uma especificação OpenAPI sobre o qual podem ser executadas operações para acessar dados ou funcionalidades;

VI - HTTP (Hypertext Transfer Protocol): protocolo para sistemas hipermídia, distribuídos e colaborativos; e

VII - Operação: elemento de uma especificação OpenAPI que declara uma maneira válida de se acessar um endpoint, informando, por exemplo, qual método HTTP (GET, POST, etc.) utilizar, nomes e tipos de parâmetros, etc.

2. APIs do Open Finance

A tabela abaixo exibe as APIs que integram o Open Finance.

3. Princípios

Os princípios abaixo norteiam as especificações e implementações das APIs do Open Finance.

3.1 Experiência do usuário

As especificações e implementações das APIs devem oferecer uma boa experiência para os usuários, sejam eles implementadores ou consumidores das APIs.

3.2 Independência de tecnologia

As especificações das APIs devem ser independentes de tecnologia, podendo ser implementadas e consumidas em diferentes linguagens e/ou plataformas tais como Java, JavaScript, Python e Windows, Linux, Android e iOS.

3.3 Segurança

Procedimentos e controles (assinaturas digitais, criptografia, protocolos de autenticação e autorização, entre outros) devem ser adotados de forma a proteger os participantes do Open Finance, seus clientes, os consumidores das APIs e demais participantes do ecossistema, observada a compatibilidade com a política de segurança cibernética da instituição.

3.4 Extensibilidade

No futuro, as APIs poderão ser aprimoradas para atender a novos casos de uso e, portanto, devem ser especificadas e implementadas de forma a permitir e facilitar extensões como, por exemplo, novos endpoints, operações, parâmetros e propriedades.

3.5 Padrões abertos

Padrões abertos devem ser adotados sempre que possível.

3.6 APIs RESTful

As especificações das APIs devem atender às restrições do estilo arquitetural REST sempre que possível.

3.7 ISO 20022

As respostas das APIs devem ter como base os elementos e componentes de mensagem ISO 20022 (https://www.iso20022.org/). Os casos particulares em que a adoção do padrão ISO não seja possível ou recomendada poderão sofrer adequações, desde que especificamente apontados para avaliação pelo Banco Central do Brasil.

3.8 Declaração de obrigatoriedade

Todos os elementos que compõem as especificações das APIs (endpoints, operações, parâmetros, propriedades de respostas, etc.) devem ser explicitamente declarados como "Obrigatório", "Opcional" ou "Condicional", caso sejam obrigatórios apenas em certas condições.

Funcionalidades que sejam de implementação opcional pelo transmissor devem ficar explícitas na sua documentação, tanto para informar adequadamente ao público transmissor, que poderá ou não implementar a funcionalidade, quanto ao público consumidor, que pode não encontrar a funcionalidade disponível em alguns transmissores.

4. Definições e recomendações

As definições e recomendações abaixo devem ser observadas pelas especificações e implementações das APIs do Open Finance.

4.1 Especificações

As APIs devem ser especificadas com a versão 3.0.0 ou superior da linguagem OpenAPI (https://github.com/OAI/OpenAPI-Specification/blob/3.0.0/versions/3.0.0.md).

As especificações das APIs devem ser analisadas com a versão 5.9.0 ou superior do software livre e de código aberto Spectral (https://github.com/stoplightio/spectral/tree/v5.9.0). A análise deve ser feita com o conjunto de regras (ruleset) padrão desta versão do Spectral. O resultado da análise não deve conter erros ou alertas.

É recomendado que a versão 3.0.25 ou superior do software livre e de código aberto Swagger Codegen (https://github.com/swagger-api/swagger-codegen/tree/v3.0.25) seja utilizada para gerar o código de clientes e também o código inicial de implementações das APIs a partir de suas especificações. Recomenda-se que o código gerado seja analisado com o intuito de identificar possíveis recursos da linguagem OpenAPI que foram utilizados nas especificações, mas que não são adequadamente suportados pelo Swagger Codegen e, possivelmente, por outros softwares que trabalham com especificações OpenAPI. Caso isto ocorra, deve-se avaliar se não é possível alterar as especificações para não mais fazer uso destes recursos.

Implementações de exemplo das APIs devem ser disponibilizadas. Os dados retornados por elas não precisam ser dados reais e nem volumosos, pois o objetivo da disponibilização é dar ao Banco Central do Brasil, aos implementadores e aos consumidores das APIs mais um recurso para dirimir eventuais dúvidas acerca de suas especificações e implementações. É recomendado que o código inicial de implementações das APIs mencionado anteriormente seja complementado de forma a constituir-se nas implementações de exemplo.

As informações disponibilizadas nos dicionários de dados devem ser consistentes com as especificações OpenAPI associadas.

Todos os endpoints das APIs implementados devem ser previamente registrados no diretório de participantes.

Todos os endpoints registrados que retornem listas, caso os parâmetros sejam válidos, devem retornar a lista associada, mesmo que seja lista vazia. Não é considerado um retorno válido o erro 404, neste cenário, quando não houver a informação associada.

4.2 Versões

As versões das especificações das APIs serão tipificadas como "major", "minor", "patch" e "release candidate" de acordo com os critérios a seguir:

I - major: inclui novas características da implementação, mudanças, correções a serem incorporadas e que podem ser incompatíveis com versões anteriores, por exemplo, v1.0.0 e v2.0.0;

II - minor: pequenas mudanças nos elementos já existentes, com manutenção da compatibilidade com as versões até a major imediatamente anterior, por exemplo, v1.1.0 e v1.2.0;

III - patch: esclarecimentos às especificações minor, não incluem alterações funcionais, por exemplo, v1.1.1, v1.1.2; e

IV - release candidate: versões de pré-lançamento de qualquer versão futura do tipo patch, minor ou major, por exemplo, v1.0.0-rc e v1.0.0-rc2.

A Estrutura Responsável pela Governança do Open Finance, de que trata o art. 44, § 1º, da Resolução Conjunta nº 1, de 2020, poderá lançar novas versões das APIs. O Banco Central do Brasil poderá definir o cronograma de implantação das novas versões major e de certificação das instituições participantes.

Por fim, credenciais de acesso associadas às APIs devem ser agnósticas às suas versões.

4.3 Portal do Open Finance no Brasil

O sítio eletrônico de que trata o art. 15 da Resolução BCB nº 32, de 2020, deverá conter definições e recomendações acessórias não presentes neste manual, bem como outros artefatos necessários à especificação, implementação e consumo das APIs do Open Finance. Todas as definições e recomendações acessórias e artefatos publicados no portal deverão estar em concordância com este e com os demais manuais do Open Finance.

4.4 Cronograma

O Portal do Open Finance deverá listar as APIs em produção, suas versões atuais, datas em que entraram em produção, link para suas especificações e lista de mudanças desde a última publicação. Também deverá apresentar o cronograma de homologação das APIs, indicando versão, data de divulgação, data prevista de entrada em produção e outras informações relevantes.

4.5 Logs de mudanças

Todas as versões já publicadas das APIs devem ser listadas no Portal do Open Finance, juntamente com os respectivos logs de mudanças e períodos em que estiveram em produção.

4.6 Definições acessórias

A Estrutura Responsável pela Governança do Open Finance deverá estabelecer e publicar no Portal do Open Finance um guia de estilo de especificações de APIs contendo definições e recomendações para os seguintes elementos:

I - Estrutura de URIs (Uniform Resource Identifiers);

II - Cabeçalhos HTTP;

III - Códigos de status HTTP;

IV - Convenções de corpo de requisições e respostas;

V - Convenções de nomenclatura;

VI - Tipos de dados comuns;

VII - Paginação; e

VIII - Estabilidade de identificadores.

4.7 Processo de gerência de mudanças

A Estrutura Responsável pela Governança do Open Finance deve estabelecer e publicar no Portal do Open Finance o processo que ela adotará para gerenciar mudanças nas especificações das APIs.

4.8 Tutoriais

Todas as informações necessárias para o desenvolvimento, testes e entrada em produção de aplicações ou APIs no Open Finance devem estar disponíveis em tutoriais publicados na Área do Desenvolvedor no Portal do Open Finance. Cada tutorial deve conter todos os passos necessários para o completo desenvolvimento da atividade em questão, como desenvolvimento e uso de aplicações e APIs, autenticação e autorização, uso da Sandbox, aplicação de testes de conformidade e cadastramento no diretório. Quando pertinente, devem ser fornecidos exemplos de código fonte ou de capturas de telas, tornando o processo o mais claro possível para todos os participantes e interessados.

4.9 Extensibilidade

As especificações das APIs do Open Finance podem não dar acesso a todos os dados e funcionalidades que um ou mais participantes desejam expor para os consumidores das APIs. Isso pode ser necessário para melhor suportar casos de uso ou possibilitar inovações em produtos e serviços financeiros. Para atender estas e outras necessidades, é facultado aos participantes implementarem versões estendidas das APIs inteiramente compatíveis com as especificações padrões das APIs que são:

I - novos endpoints;

II - novas operações em endpoints pré-existentes;

III - novos parâmetros em operações pré-existentes, desde que opcionais; e

IV - novas propriedades em respostas pré-existentes.

A Estrutura Responsável pela Governança do Open Finance deverá publicar no Portal do Open Finance as definições e recomendações acessórias relacionadas às extensões das APIs.

Todas as extensões implementadas pelos participantes deverão estar listadas, com sua documentação referenciada, em seção específica no Portal do Open Finance e disponíveis para consumo, observadas as regras de ressarcimento de despesas previstas na regulamentação vigente.

5. Requisitos não funcionais

Esta seção apresenta os requisitos não funcionais que as instituições participantes devem observar na implementação das APIs do Open Finance.

Para auxiliar na definição de alguns requisitos não funcionais, é necessário que cada endpoint seja classificado no site do Open Finance de acordo com a sua frequência de atualização dos dados, conforme as opções abaixo:

I - Alta frequência;

II - Média frequência; e

III - Baixa frequência

Limites de tráfego por origem, limites operacionais e tempo de resposta (desempenho) serão definidos baseados nessa classificação.

5.1 Limites de tráfego

5.1.1 Limites por origem

Cada endpoint implementado no Open Finance pode ter uma restrição quanto ao tráfego a partir de determinada origem. Em APIs do tipo ‘dados abertos’ a origem é o IP de onde partiu a requisição, em APIs autenticadas é a IF/organizationId que fez a requisição.

No caso de uma instituição implementar limites, eles devem respeitar os valores mínimos de Transações por Minuto (TPM). conforme definido abaixo:

I - 2.000 TPM, por endpoint e por origem, em endpoints classificados como de alta frequência;

II - 1.000 TPM, por endpoint e por origem, em endpoints classificados como de média frequência; e

III - 500 TPM, por endpoint e por origem, em endpoints classificados como de baixa frequência.

Aplicabilidade: Alguns endpoints não podem ter limites de tráfego definidos por origem, como nas APIs do tipo Serviços, Segurança (Token – consumo OAuth 2.0 (FAPI), Token – DCR/DCM), Recursos e de Consentimento. A informação definindo se o limite por origem é ‘aplicável’ ou ‘não aplicável’ deve estar explícita por endpoint no site do Open Finance.

As requisições que excederem os limites implementados deverão ser respondidas com o código de status HTTP 429 (Too Many Requests).

Por fim, as requisições que ultrapassarem os limites deverão ser desprezadas no cálculo do tempo de resposta das implementações das APIs.

5.1.2 Limites globais

A infraestrutura das instituições provendo APIs no Open Finance deve ter a capacidade de, no mínimo, atender a 300 requisições simultâneas por segundo (TPS).

Caso o limite de 300 TPS seja atingido, no contexto do Open Finance, a instituição deve ampliar sua capacidade de infraestrutura para possibilitar um acréscimo de 150 TPS ao limite anterior. Tal aumento deve ocorrer novamente a cada vez que o limite vigente na instituição for atingido. Cada instituição deve criar monitoramento preventivo, de acordo com critérios definidos; as evidências devem estar a disposição do Banco Central do Brasil por um período de doze meses.

As requisições que excederem os limites de TPS deverão ser respondidas com o código de status HTTP 529 (Site is overloaded).

O Portal do Open Finance deverá conter uma especificação detalhada de como TPS e gatilhos para aumento ou diminuição da capacidade serão calculados.

Endpoints criados dentro do conceito de extensibilidade, sejam dentro de novas APIs ou em APIs existentes, não podem ser considerados para controle do limite global de transações simultâneas.

5.2 Limites operacionais

É facultado às instituições participantes implementarem um limite de acesso mensal por endpoint e por cliente.

Em endpoints que acessem recursos ou produtos, os limites serão também considerados por recurso ou produto.

A contabilização dos acessos deve ser realizada por:

I - mês;

II - endpoint;

III - objeto mais granular referenciado na chamada (consentimento/recurso/produto);

IV - cliente (CPF ou CNPJ); e

V - IF consumidora da informação.

Por exemplo: uma instituição receptora ‘A’ pode acessar um endpoint ‘B’, acessando o recurso ‘C’, de um cliente “D” da instituição transmissora ‘E’, no mínimo ‘N’ vezes (ou chamadas) com sucesso por mês.

Aplicabilidade dos limites operacionais: todos endpoints das APIs do tipo Dados Cadastrais e Transacionais (conforme classificação de Tipo), destes excetuam-se aqueles endpoints das APIs de Consentimento (Consents) e Recursos (Resources). As APIs dos tipos Dados Abertos e de Serviços (como de Iniciação de Pagamento) não podem ter restrições de limites operacionais.

A implementação dos limites operacionais é opcional pelas instituições transmissoras, mas, uma vez que sejam implementados, devem garantir o consumo mínimo estabelecido no site do Open Finance. É facultada à instituição a possibilidade de ampliar esses limites, mas vedada a implementação de limites inferiores aos estabelecidos.

O site do Open Finance deve listar os valores mínimos de limites operacionais a serem considerados, por endpoint, que devem ser iguais ou maiores que os abaixo, de acordo com a classificação de frequência de utilização:

I - 4 chamadas ao mês, para endpoint classificado como de baixa frequência;

II - 30 chamadas ao mês, para endpoint classificados como de média frequência;

III - 240 chamadas ao mês, para endpoint classificado como de alta frequência; e

IV - 420 chamadas ao mês, para os seguintes endpoints da API de Contas: ‘Saldos da conta’ e ‘Limites da conta’.

Só deverão ser contabilizadas nos limites operacionais requisições respondidas com código de status HTTP 2XX (com sucesso), sendo que as requisições adicionais a um endpoint para fins de paginação não devem ser contabilizadas.

As requisições que excederem os limites operacionais deverão ser respondidas com o código de status HTTP 423.

Todas requisições autenticadas em endpoints sujeitos ao limite operacional devem possuir o atributo x-fapi-interaction-id preenchido no seu header pela receptora, que deve ser copiado pela transmissora nos headers da resposta. Essa definição objetiva permitir um adequado rastreamento de divergências que podem ocorrer entre transmissoras e receptoras associadas ao limite operacional.

5.3 Desempenho

Deverá ser medido o tempo de resposta de cada requisição, ou seja, o tempo transcorrido entre o recebimento de uma requisição que não ultrapassa os limites de tráfego e o momento em que a requisição é completamente respondida. Adicionalmente, esta medição deverá ser feita de maneira que os tempos medidos sejam os mais próximos possíveis dos tempos de resposta experimentados por quem fez a requisição. Neste contexto, os endpoints das APIs deverão manter o percentil 95 do tempo de resposta em no máximo:

I - 1.500ms, em endpoints classificados como de alta frequência;

II - 2.000ms, em endpoints classificados como de média frequência; e

III - 4.000ms, em endpoints classificados como de baixa frequência.

Por exemplo, em um dia que um endpoint de alta frequência receba 10.000 requisições, o tempo de resposta de pelo menos 9.500 requisições deve ser inferior a 1.500ms.

5.4 Disponibilidade

As APIs classificadas como ‘Dados Abertos’, ‘Dados Cadastrais e Transacionais’ e ‘Relatórios e métricas’, listadas na Seção 2 deste manual, deverão satisfazer requisitos mínimos de disponibilidade abaixo. Cada um de seus endpoints deverá estar disponível:

I - 95% do tempo a cada 24 horas; e

II - 99,5% do tempo a cada 3 meses.

As APIs classificadas como ‘Serviços’ deverão possuir a mesma disponibilidade do arranjo de pagamento ou do serviço aos quais estão associadas.

O Portal do Open Finance deverá conter uma especificação detalhada de como a disponibilidade de cada endpoint será calculada.

5.5 Timeout

Padronização do timeout de tempo de resposta do servidor (server) e do tempo de resposta do consumidor (client) em quinze segundos.

As requisições que excederem o limite de timeout do servidor deverão ser respondidas com o código de status HTTP 504 (Gateway Timeout).

6. Disposições Transitórias

O processo de publicação em produção da versão 2.0.1 das APIs de ‘Dados Cadastrais e Transacionais’, cuja especificação foi lançada no portal do Open Finance em 20/06/2022, deverá considerar os seguintes pontos de controle:

As modificações dos requisitos de qualidade, atualizados neste manual, devem ser aplicadas a partir da data de publicação das novas APIs pelas instituições.

Brasília, 19 de setembro de 2022.

NOTA 1135/2022-BCB/DENOR, DE 13 DE SETEMBRO DE 2022.

Fundamenta proposta de edição de instrução normativa que estabelece a versão 4.0 do Manual de APIs do Open Finance.

                            Senhores Chefes do Denor e do Deinf,

                  A presente Nota fundamenta proposta de edição de instrução normativa pelo Departamento de Regulação do Sistema Financeiro (Denor) e pelo Departamento de Tecnologia da Informação (Deinf), no uso da atribuição que lhes confere o art. 23, inciso I, alínea "a", do Regimento Interno do Banco Central do Brasil, anexo à Portaria nº 84.287, de 27 de fevereiro de 2015, e observado o inciso IX do art. 51 da Resolução Conjunta nº 1, de 4 de maio de 2020.

2.                   A respeito, a proposta trata de edição de instrução normativa que estabelece a versão 4.0 do Manual de APIs do Open Finance, revogando a Instrução Normativa BCB nº 130, de 22 de julho de 2021, que divulga a versão 3.0 do Manual de APIs do Open Banking.

3.               As alterações referem-se à atualização da expressão Open Banking por Open Finance, conforme mudanças realizadas pela Resolução Conjunta nº 4, de 24 de março de 2022, a esclarecimentos sobre o processo de lançamento de novas APIs e suas versões e à adequação ao padrão ISO 20022; bem como à adequação técnica em pontos concernentes a limites de tráfego e operacionais, à disponibilidade e desempenho das APIs e à padronização de tempo de resposta (time-out). A proposta de instrução normativa dispõe, ainda, sobre pontos de controle para publicação da versão 2.0.1 das APIs de ‘Dados Cadastrais e Transacionais’, cuja especificação foi lançada no portal do Open Finance em 20 de junho de 2022.

4.               Por fim, em atendimento ao previsto no art. 5º da Lei nº 13.874, de 20 de setembro de 2019, o Decreto nº 10.411, de 30 de junho de 2020, determina que as propostas de atos normativos de interesse geral de agentes econômicos formuladas por órgãos e entidades da administração pública federal direta, autárquica e fundacional, bem como por colegiados por meio do órgão ou da entidade encarregada de lhe prestar apoio administrativo, sejam precedidas de Análise de Impacto Regultório (AIR).

5.               No entanto, vale destacar que as alterações e os ajustes propostos não causam impactos significativos para o conjunto de instituições participantes do Open Finance, por tratar-se de esclarecimentos e adaptações em orientações já constantes em atos normativos vigentes, como no caso do tópico sobre versões, e a adequações relacionadas a tráfego, limites e métricas de chamadas com o objetivo de aperfeiçoar o fluxo de informações entre as instituições participantes do Open Finance, de forma a possibilitar o seu monitoramento e esclarecer eventuais disputas. Nesse sentido, de acordo com o art. 4º, inciso III, do referido Decreto, o ato normativo ora proposto fica dispensado de elaboração de AIR por ser considerado de baixo impacto.

                         À consideração de V.Sas.

Mardilson Fernandes Queiroz                            Aristides Andrade Cavalcante Neto
Consultor do Departamento                              Chefe Adjunto do Departamento de
de Regulação do Sistema Financeiro                Tecnologia da Informação

                        
                        De acordo.

João André Calvino Marques Pereira              Haroldo Jayme Martins Froes Cruz
Chefe do Departamento de Regulação           Chefe do Departamento de
do Sistema Financeiro                                       Tecnologia da Informação