Introdução

Sejam bem-vindos à área do desenvolvedor do Portal do Open Banking Brasil

Nessa área os desenvolvedores encontrarão informações para observância obrigatória de todos os participantes, sejam eles obrigatórios ou voluntários, incluindo padrões técnicos de interfaces, glossário de termos técnicos, especificações dos diferentes tipos de APIs - incluindo seu versionamento, requisitos não funcionais como SLAs e limites de tráfego de requisições, informações de desempenho e disponibilidade, FAQ com diversas orientações aos desenvolvedores, entre outros elementos necessários à implementação do Sistema Financeiro Aberto. Todas as informações foram definidas de acordo com a regulamentação vigente no País, respeitando instruções normativas e resoluções do Banco Central do Brasil e do Conselho Monetário Nacional.

Este sítio eletrônico e seu conteúdo foram criados e são mantidos pela Estrutura responsável pela Governança do Open Banking Brasil, formada por integrantes de múltiplas associações: Febraban, ABBC, ACREFI, ABBI, OCB, Abecs, Abipag, Abranet, Câmara e-net, ABCD e ABFintechs.

Padrões

Estes padrões representam a versão 1.0.0, a qual fornece uma visão alto nível dos padrões. Consulte a seção versionamento para obter mais informações sobre como as versões são gerenciadas com o padrão.

Observe que, nesta proposta, as palavras-chave DEVEM, NÃO DEVEM, NECESSÁRIAS, RECOMENDADO, PODE e OPCIONAL, devem ser interpretadas conforme descrito na RFC2119.

Princípios

Os seguintes princípios técnicos não exaustivos constituem a base para o desenvolvimento e implementação das APIs para o Open Banking no Brasil.

Princípio 1: Segurança

A adoção de mecanismos de segurança no design e implementação das APIs do Open Banking no Brasil deverá considerar os padrões aplicáveis a cada uma de suas fases, visando a proteção e a disponibilidade do ecossistema como um todo, considerando clientes, participantes e os dados específicos compartilhados em cada fase.

Princípio 2: RESTful APIs

A API irá aderir aos conceitos de RESTful API sempre que for possível e sensato.

Princípio 3: Padrões existentes

Os padrões existentes serão adotados sempre que sua aplicação for relevante/apropriada e desde que não violem nenhum dos demais princípios, com foco na experiência do desenvolvedor e do usuário, e ainda, prevendo a extensibilidade, resiliência e a evolução do Open Banking no Brasil.

Princípio 4: ISO 20022

Os payloads das APIs serão desenvolvidos utilizando como base os elementos e componentes de mensagem ISO 20022, que poderão ser modificados, caso necessário, para deixar o payload mais simples e/ou atender às características locais, tal como implementado em diferentes jurisdições.

Princípio 5: Extensibilidade

Os fluxos das APIs serão estendidos para atender a casos de uso mais complexos em futuros releases, e, portanto, esse princípio será mantido em mente durante o design, e os procedimentos serão detalhados durante a implementação.

Princípio 6: Códigos de Status

A API usará dois códigos de status que atendem a dois propósitos diferentes: (i) o HTTP status code reflete o resultado da chamada da API e (ii) um campo status em alguns resource payloads reflete o status dos resources nos casos de acesso write (p.ex. iniciação de pagamento).

Princípio 7: Identificadores únicos

Um recurso REST deverá ter um identificador exclusivo que possa ser usado para identificar o recurso, com formato e padrão a ser definido a partir da Fase 2 do Open Banking no Brasil.

Princípio 8: Categorização dos requisitos de implementação

Quando um requisito estiver sendo implementado por um transmissor e/ou um receptor, uma categorização diferente será aplicada. As funcionalidades, endpoints e campos em cada recurso serão categorizados como 'Obrigatório', 'Condicional' ou 'Opcional'.

Princípio 9: Agnósticas

As APIs serão agnósticas à implementação onde elas poderão ser consumidas independente das tecnologias adotadas no ecossistema, porém com aderência aos princípios contidos nesta documentação.

Versionamento

O controle de versão contemplará 4 tipos de lançamento (p.ex. major, minor, patch e release candidate) e terá prazos definidos para lançamento e implementação de novas versões major, bem como suporte de versões anteriores.

No link Anexo: Guia de Versionamento, integrante desta documentação, estão documentados os casos previstos em que uma nova versão de API poderá vir a quebrar o contrato estabelecido

O versionamento terá o seguinte formato contemplando 4 tipos de lançamentos de versões: 1.12.2.rc1 - significando versão major 1, versão minor 12 , aplicação de patchs versão 2 e release candidate 1

• Major: inclui novas características da implementação, mudanças, correções a serem incorporadas e que poderão vir a quebrar o contrato.
  • P.ex. v1.0.0, v2.0.0.
• Minor: pequenas mudanças nos elementos já existentes, com manutenção da compatibilidade e sem quebra de contrato.
  • P.ex. v1.1.0, v1.2.0
• Patch: esclarecimentos às especificações publicadas pelo diretório, não incluem alterações funcionais.
  • P.ex. v1.1.1, v1.1.2
• Release candidate: versões de pré-lançamento de qualquer patch futuro, minor ou major.
  • P.ex. v1.0.0-rc , v1.0.0-rc2

Será definido um cronograma de novas versões dos padrões para que os participantes consigam se planejar e desenvolver novas APIs, com cada um dos lançamentos tendo um prazo pré-estabelecido para ser implementado pelos participantes, mitigando, desta forma, o risco de múltiplas versões.

Não serão feitos mais do que um lançamento de versão major em um período de 6 meses. No entanto, serão previstas exceções para atender às alterações urgentes que não podem esperar até a próxima versão principal (major). Lançamentos de versões minor e patch podem ocorrer a qualquer momento.

Lançamentos minor não podem configurar em quebra de contrato, impactar significativamente endpoints e/ou exigir manutenção crítica.

Por fim, credenciais de acesso associadas às APIs deverão ser agnósticas à versão.

Estrutura da URI

A estrutura da URI para os endpoints deve ser implementada conforme abaixo:
<host> / open-banking / <api> / <versão> / <recurso>

Os componentes desta estrutura de URI estão descritos abaixo:

• Host: O host de API da entidade financeira implementadora é um endereço base definido pela entidade transmissora de dados.
• “open-banking”: Esta é uma string constante que representa a finalidade desta API.
• API: A API que será consumida (p.ex. channels).
• Versão: O número da versão da API. Na URI a versão deve ser precedida pela letra "v" seguida pelo número da versão a ser consumida (p.ex. v1, v2, v25).
• Recurso: O recurso a ser consumido dentro de uma API. Utilizando como exemplo a API channels, a mesma possui 5 recursos:
  • branches
  • banking-agents
  • electronic-channels
  • phone-channels
  • shared-automated-teller-machines

A versão minor será repassada apenas no header do payload de resposta, orientando a instituição receptora sobre quais serão os dados no retorno.

Como exemplo, para realizar o consumo do método electronic-channels da API channels na versão 1, a URI ficaria com a seguinte estrutura:

<host>/open-banking/channels/v1/electronic-channels

Cabeçalhos HTTP

Cabeçalhos HTTP suportados e suas funções.

Cabeçalho de requisição

Cabeçalho de resposta

Códigos de resposta HTTP

Os códigos de resposta HTTP devem ser utilizados conforme tabela abaixo.

Códigos

Convenções de payload

Esta seção do padrão descreve as estruturas padrões de requisição e resposta para todos os endpoints das APIs, assim como as convenções de nomenclatura para os atributos.

Estrutura de requisição

Estrutura da requisição

{
  "data": {
    "..."
  }
}

Cada requisição deve ser um objeto JSON contendo um objeto data para armazenar os dados primários da requisição.

No mesmo nível do objeto data, poderá existir um objeto meta se assim for especificado pelo endpoint. O objeto meta é usado para fornecer informações adicionais ao endpoint, como parâmetros de paginação, contagens de paginação ou outros propósitos complementares ao funcionamento da API.

A definição do conteúdo para o objeto data será definida separadamente para cada endpoint.

Estrutura de resposta

Estrutura de resposta

{
  "data": {
    "..."
  },
  "links":{
    "..."
  },
  "meta": {
    "..."
  }
}

Cada endpoint retornará um objeto JSON contendo os atributos abaixo:

• Se a resposta for bem-sucedida (200 OK), o objeto JSON irá conter:
  • obrigatóriamente um objeto data
  • obrigatóriamente um objeto links
  • opcionalmente um objeto meta, se necessário pela definição do endpoint requisitado
• Se a resposta for malsucedida (não 200 OK), o objeto JSON poderá conter:
  • um objeto errors (conforme a definição específica do endpoint)

A definição do conteúdo para os objetos data e meta será definida separadamente para cada endpoint.

O objeto links irá conter hypermedia (referências para recursos relacionados) para outros recursos da API requisitada.

O objeto de links sempre irá conter o atributo self que irá apontar para a URI da solicitação atual.

Estrutura de resposta de erros

{
  "errors": [
    {
        "code": "...",
        "title": "...",
        "detail": "..."
    }
  ],
  "meta":{
    "..."
  }
}

• O objeto errors será um array de zero ou mais objetos. Os atributos deste objeto serão os descritos abaixo:
  • obrigatoriamente o atributo code contendo um código de erro específico do endpoint;
  • obrigatoriamente o atributo title contendo um título legível por humanos do erro deste erro específico;
  • obrigatoriamente o atributo detail contendo uma descrição legível por humanos deste erro específico;
  • opcionalmente o objeto meta contendo dados adicionais sobre o endpoint que seja relevante para o erro.

Convenções de nomenclatura de atributos

Caracteres válidos em nomes de atributos

Todos os nomes de objetos e atributos definidos nos objetos JSON de requisição e resposta devem ser nomeados seguindo o padrão camelCase, tendo seu nome composto apenas por letras (a-z, A-Z) e números (0-9).

Qualquer outro caractere não deve ser usado nos nomes dos objetos e atributos, com exceção do caractere - (hífen), que poderá ser utilizado apenas conforme descrito na seção Extensibilidade.

Estilo de nomeação de atributos

Os nomes dos objetos e atributos devem ser nomes significativos e em língua inglesa. Quando houver diferença entre inglês americano e inglês britânico no termo a ser utilizado, deverá ser utilizado o termo em inglês britânico. P.ex. Utilizar o termo Post Code (Reino Unido) ao invés de Zip Code (Estados Unidos).

Arrays devem ser nomeados no plural. Demais atributos deverão ser nomeados no singular.

Convenções de propriedade dos atributos

Tipos de dados dos atributos

Cada atributo deverá estar associado a um tipo de dado. A lista de tipos de dados válidos está definida na seção tipos de dados comuns. Se um tipo de dado personalizado é necessário para um atributo, o mesmo deverá ser classificado como uma string com uma descrição clara de como o valor da propriedade deve ser interpretado.

Atributos Obrigatórios / Opcionais

Segundo Instrução Normativa nº 34, BCB de 2020: ‘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’.

Os atributos obrigatórios devem estar presentes e ter um valor não nulo, seja em uma requisição ou resposta, para que payload seja considerado válido.

Os atributos condicionais podem ter uma restrição vinculada a eles, tornando-os obrigatórios conforme a situação descrita na coluna 'restrição' do dicionário de dados.

Atributos vazios / nulos

Um atributo omitido (ou seja, um atributo que não está presente no payload) será considerado equivalente a um atributo que esteja presente com o valor null.

Uma string vazia (“”) não será considerada equivalente a null.

O valor booleano false não será considerado equivalente a null. Os atributos booleanos opcionais, por definição, possuirão três valores possíveis: verdadeiro (true), falso (false) e indeterminado (null).

Na situação onde o campo a ser informado no payload seja obrigatório e a Instituição, seja consumidora no envio ou transmissora no retorno, não a possuir, deve-se implementar o valor padronizado: “NA” - Não se Aplica, com exceção dos campos declarados como ENUM que deverão ser sempre preenchidos com os valores válidos para o ENUM correspondente.

Convenções de nomenclatura

Todos os nomes devem ser autoexplicativos, sem redundância de termos e sem ambiguidade de entendimento, além de seguir o padrão Lower Camel Case (primeira letra de cada termo maiúscula, com exceção do primeiro termo, que fica todo em minúsculas e sem espaços ou pontuações entre os termos). Ex: “areaCode”.

Os nomes das estruturas (composição de atributos sobre um assunto) que podem ter mais de uma ocorrência devem sempre estar no plural.

Os nomes dos atributos devem:

• Sempre estar no singular

• Nos casos em que o nome não ficar claro, devem ser incluídos mais termos para esclarecer o entendimento

• Para garantir o entendimento e a padronização, nos casos de atributos que tratem dados específicos, sempre devem ser usados termos complementares no fim dos nomes. São esses:

  • nomes = Name (p.ex. ownerName)
  • datas = Date (p.ex. openingDate)
  • horários = Time (p.ex. openingTime)
  • quantidades = Quantity (p.ex. eventLimitQuantity)
  • textos explicativos = Info* (p.ex. additionalInfo)

  *Para textos explicativos de informações complementares, o nome completo do atributo é “additionalInfo”

• Em atributos que sejam indicadores binários (flags), o nome deve estar formatado como pergunta, com um verbo como primeiro termo. Ex: “hasRewardProgram”

Tipos de dados comuns

Propriedades

Paginação

Cada recurso de cada API pode possuir ou não paginação, caso a quantidade de registros retornados justifique a mesma. A paginação estará disponível e deverá funcionar independente se o recurso permite filtros por query ou POST. Isso é, filtros e paginação são aplicados de forma independente.

Parâmetros de Requisição

Exemplo de query com paginação

GET {uri}?page=1&page-size=25

Quando existir paginação para o recurso deverão ser utilizados os parâmetros de query abaixo para a navegação dos resultados:

Atributos de Resposta

Exemplo de paginação

{
  "data": {
    "..."
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/products-services/v1/personal-invoice-financing",
    "first": "https://api.banco.com.br/open-banking/products-services/v1/personal-invoice-financing",
    "prev": null,
    "next": null,
    "last": "https://api.banco.com.br/open-banking/products-services/v1/personal-invoice-financing"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Além dos dados requisitados, as respostas paginadas também terão em sua estrutura dois objetos adicionais que incluirão parâmetros para facilitar a nagevação das páginas:

Links

O objeto links passará por revisão subsequente de modo a atender as próximas Fases do Open Banking, em especial a partir da Fase 2. No objeto links, serão retornadas hypermedia (referências para os recursos relacionados) de paginação conforme parâmetros abaixo:

Meta

No objeto meta, serão retornadas informações sobre o total de registros disponíveis

Regras Adicionais

• Não é esperado que os provedores implementem paginação com isolamento de transação. Os dados que serão retornados podem mudar entre requisições subsequentes. Isto pode causar situações onde um mesmo registro pode ser retornado em mais de uma página.
• O tamanho máximo da página é 1000 registros para qualquer endpoint (a menos que na documentação desse esteja informando outros valores).
• Se for requisitado uma quantidade de registros maior que o suportado, o retorno será o código HTTP status code 422 Unprocessable Entity, indicando que o servidor entendeu a requisição, mas não é possível processá-la conforme foi solicitado.

Formação e Estabilidade do ID

Dentro desses padrões, a serem melhor especificados a partir da Fase 2 do Open Banking no Brasil, os IDs de recursos são necessários para atender ao seguinte:

• O ID de um recurso deve ser especificado no endpoint de uma API apenas para obter detalhes do recurso ou para realizar alterações no mesmo.
• Se o ID for especificado nos padrões do Open Banking, então ele é obrigatório e deverá ser fornecido pela entidade implementadora da API de acordo com o padrão definido.
• Se um ID for especificado, o mesmo deverá ser totalmente desconectado de significados com outras entidades. Por exemplo, um ID não deve ser uma combinação de outros campos ou uma string que possa ter conteúdo sensível que possa ser extraído.
• Os IDs devem ser únicos, e sua padronização será detalhada a partir da Fase 2 do Open Banking no Brasil, porém sua unicidade pode estar dentro de um contexto. Por exemplo, um ID de conta corrente deve ser único, porém apenas dentro do contexto de conta corrente.
• Nos payloads o nome de campo "id" nunca deverá ser utilizado. Cada campo ID deverá ter um nome significativo, dessa forma independentemente de onde o ID for utilizado entre múltiplos endpoints, ele sempre irá se referir ao seu objeto principal. Por exemplo, IDs para conta deverão ser representados no JSON como "accountId".

Idempotência (princípio adicional)

APIs serão definidas como idempotentes para não causar uma experiência ruim ao consumidor ou aumentar os indicadores de risco falso positivo. Trata-se de recurso necessário para garantir que não haja duplicidade em caso deperda de comunicação e não deve se limitar aos verbos HTTP, devendo ser aplicado ao design completo da API.

Identificadores únicos (princípio já existente)

Um recurso REST deverá ter um identificador exclusivo que possa ser usado para identificar o recurso alvoda API. Este identificador será usado para criar URLs que permitam endereçar recursos específicos,obedecendo aos padrões definidos nesta documentação,no item Formação e estabilidade do ID.

Extensibilidade

Os padrões de Open Banking podem não cobrir todas as possibilidades de objetos retornados ou APIs que os participantes desejam expor. Os participantes podem ter o desejo de realizar inovações sobre os padrões definidos oferecendo mais dados afim de atender demandas específicas de mercado. É nossa intenção que os padrões definidos não apenas permitam estas extensões como também sirvam como base para futuras alterações na própria definição dos padrões.

No entanto, é importante que um participante que esteja querendo estender as APIs não impeça um consumidor que foi projetado para consumir apenas o endpoint padrão funcione corretamente.

Para atender tanto as demandas de quem deseja estender as APIs (participantes) quanto as demandas de quem irá realizar o consumo (consumidor das APIs), foram definidos os critérios abaixo.

É possível estender os padrões nos seguintes aspectos:

• O participante pode oferecer uma API completamente nova que não está coberta nos padrões definidos
• O participante pode oferecer novos endpoints em uma API que já foi definida no padrão
• O participante pode oferecer campos de entrada e retorno opcionais para um endpoint que já foi definido no padrão

ID dos participantes

Cada participantes terá um ID que representa a sua instituição. Os participantes da atual versão estão listados abaixo:

• BBAS - Banco do Brasil
• BBCD - Bradesco
• BTGP - BTG Pactual
• CAIX - Caixa Econônica Federal
• ITAU - Itau
• STDR - Santander
• BRGS - Banrisul
• BNBR - Banco do Nordeste do Brasil
• BNDS - BNDES
• CITI - Citibank
• SAFR - Safra
• BABV - Votorantim

Participantes que desejam estender os padrões devem adicionar seu prefixo para identificar todas as extensões. Campos adicionais no retorno de endpoints existentes ou em novos endpoints devem usar o prefixo do participante. O prefixo deve ser no formato exposto ao lado (4 letras) e não devem haver prefixos duplicados entre os participantes.

Nesta documentação, quando tivermos que nos referir ao prefixo do participante, o termo <PID> será utilizado.

Novas APIs

Quando a extensão for a criação de uma nova API, o participante deve adicionar seu prefixo a URI antes do nome da nova API, conforme exemplo abaixo.

Por exemplo, uma API definida pelo padrão seguirá o seguinte formato: <host> / open-banking / <api> / <versão> / <recurso>

Uma API estendida por um participante deverá estar no formato abaixo: <host> / open-banking / <PID> / <api> / <versão> / <recurso>

Para os endpoints definidos dentro da estrutura acima, os atributos dos payloads não precisam conter o prefixo do participante, pois entende-se que todos os recursos da API estendida não conflitam de nenhum modo com as definidas pelo padrão.

Novos endpoints em APIs existentes

Quando o participante desejar adicionar um novo endpoint em uma API já especificada no padrão, o participante deve incluir seu <PID> como prefixo do recurso que será implementado.

Por exemplo, assumindo a existência do endpoint abaixo para consulta das transações de uma conta: <host>/open-banking/accounts/v1/accounts/{account ID}/transactions

Se o participante deseja adicionar um novo endpoint que resume as transações por um período, então este endpoint poderia ser definido como: <host>/open-banking/accounts/v1/accounts/{account ID}/<PID>-balance-movement

Campos de retorno adicionais em um endpoint existente

Quando o participante desejar adicionar um novo campo ao payload de resposta, o atributo deverá receber o prefixo do participante seguido por um hífen <PID>-.

Se um objeto estiver sendo adicionado ao payload de resposta, apenas o nome do objeto precisa receber o prefixo. Qualquer atributo dentro do novo objeto pode ser nomeado normalmente.

Parâmetros query adicionais

Quando for adicionado um novo parâmetro de query a um endpoint existente, o novo parâmetro deve ter o prefixo <PID>-, evitando assim colisões com parâmetros já existentes.

Filtro de Dados

Opcionalmente, a entidade transmissora de dados poderá realizar filtro de dados através de query de entrada, baseado em campos que julgue relevante para a melhor experiência do cliente.
A informação de quais possibilidades estarão disponíveis (query parameter) deverá constar em documentação adicional disponibilizada pela entidade transmissora.

Extensão do versionamento

Como descrito na seção versionamento, o versionamento existe apenas no nível das APIs e não no nível dos endpoints, no entanto caso seja necessário realizar versionamento de um endpoint customizado, o participante poderá utilizar o header x-<PID>-v para que o consumidor possa especificar qual versão do endpoint está requisitando.

Glossário

Glossário

Agência (Branch)

É a dependência destinada ao atendimento aos clientes, ao público em geral e aos associados de cooperativas de crédito, no exercício de atividades da instituição, não podendo ser móvel ou transitória

Adiantamento a Depositante (Unarranged Account Overdraft)

O valor que o banco libera na conta-corrente do cliente, em casos excepcionais, o valor necessário para cobrir algum saque, pagamento, débito automático ou cheque, quando o saldo disponível não é suficiente.

Bandeira (Credit Card Network)

São instituições que autorizam o uso de sua marca e de sua tecnologia por emissores e credenciadoras de estabelecimentos. Essas marcas aparecem nos cartões e nos estabelecimentos credenciados.

Cartão Múltiplo (Multiple CreditCard)

Trata-se de um único cartão que possui mais de uma função, ou seja, que pode ser utilizado como débito, crédito e para a movimentação da conta.

CBO (Cbo Code)

A Classificação Brasileira de Ocupações (CBO) é um documento que retrata a realidade das profissões do mercado de trabalho brasileiro. Foi instituída com base legal na Portaria nº 397, de 10.10.2002. Trata-se de um sistema de classificação responsável pela codificação dos títulos e conteúdos dos cargos e ocupações do mercado de trabalho brasileiro

Cheque Especial (Arranged Overdraft)

É uma operação de crédito, a exemplo do empréstimo, mas que é pré-aprovada e vinculada a uma conta de depósitos à vista. Tem o objetivo de cobrir movimentações financeiras quando não há mais saldo disponível na conta.

O banco disponibiliza ao cliente um limite de crédito rotativo que, embora apareça no extrato da conta, não é um recurso do cliente. Quando utilizado esse valor, o banco pode cobrar juros sobre o valor usado, ou seja, sobre o saldo devedor.

Fonte: link

CNAE (Cnae Code)

Trata-se de um código utilizado para identificar quais são as atividades econômicas exercidas por uma empresa. A Classificação Nacional de Atividades Econômicas - CNAE é oficialmente adotada pelo Sistema Estatístico Nacional e pelos órgãos federais gestores de registros administrativos

CNPJ (CNPJ Number)

Código gerido pela Secretaria da Receita Federal e utilizado para identificação das empresas no Cademp. O CNPJ corresponde ao número de inscrição no Cadastro de Pessoa Jurídica. Composto por: os oito primeiros números à esquerda (XX. XXX. XXX) formam a "raiz" ou base, que identifica a empresa de forma única. Os quatro seguintes números de ordem das filiais da empresa. Normalmente a empresa matriz tem este campo preenchido com '0001'. Os dois últimos números correspondem ao dígito verificador. composição do CNPJ pode ser assim representada, conforme ex. '50.685.362/0001-35'.

Código Compe (compeCode)

O Compe (Sistema de Compensação de Cheques e Outros Papéis) é um sistema que identifica e processa as compensações bancárias. Ele é representado por um código de três dígitos que serve como identificador de bancos, sendo assim, cada instituição bancária possui um número exclusivo.

Código Ocupação Receita Federal – Receita Federal Code

Código da atividade profissional relacionada com a principal fonte pagadora dos seus rendimentos, assim entendida a que pagou maior rendimento independentemente de escolaridade ou de formação acadêmica

Fonte: link

Conta Individual (Sole Account)

Tipo de conta que comporta apenas um titular.

Conta Conjunta Não-solidária (Joint Account And)

Tipo de conta que comporta mais de um titular, em que os titulares dependem da autorização de “pelo menos” um diferente titular para realização de movimentações em contas.

Conta Conjunta Solidária (Joint Account Or)

Tipo de conta que comporta mais de um titular, tendo todos os titulares livre movimentação sem que seja exigida a autorização de outros titulares.

Conta de Depósito à Vista (Current Account)

Conhecida popularmente pelo nome de conta corrente. É a maneira mais comum de manter dinheiro em uma instituição financeira. Funciona como um cofre, em que o cliente deposita seu dinheiro e pode ter acesso a serviços como pagamento de contas, saques, transferências, emissão de cheques e realização de compras com cartão de débito, entre outros. Para guardar o dinheiro e oferecer serviços como os citados, a instituição financeira pode cobrar tarifas, mas o cliente é quem escolhe se prefere pagar uma tarifa individualizada por serviço que utilizar ou uma tarifa única que dá direito a um pacote de serviços.

Conta de Pagamento Pós-paga (Credit Card)

Referente a cartão de crédito. Instrumento de pagamento que possibilita a aquisição de produtos e serviços com liquidação futura, de acordo com requisitos predeterminados, tais como limite de crédito e validade. O pagamento do valor correspondente ao produto ou ao serviço adquirido será efetuado ao emissor do cartão de crédito em data previamente acordada.

Conta de Pagamento Pré-paga (Prepaid Payment Account)

Destinada à execução de transações de pagamento em moeda eletrônica realizadas com base em fundos denominados em reais previamente aportados.

Conta de Poupança (Savings Account)

A conta de depósitos de poupança, popularmente conhecida como conta poupança, conta de poupança ou ainda caderneta de poupança, é um tipo de investimento criado com o objetivo de estimular a economia popular. Assim, para abrir e manter uma conta de poupança, o cliente não paga tarifas, não paga imposto de renda sobre o dinheiro aplicado e ainda pode depositar pequenos valores, que passam a gerar rendimentos mensalmente. Se um valor depositado na conta de poupança não for mantido aplicado por pelo menos um mês, isto é, se for resgatado antes, não ocorrerá remuneração desse dinheiro.

Correspondente Bancário (Banking Agent)

Empresas, integrantes ou não do Sistema Financeiro Nacional, contratadas por instituições financeiras e demais instituições autorizadas a funcionar pelo Banco Central do Brasil para a prestação de serviços de atendimento aos clientes e usuários dessas instituições. Os correspondentes mais conhecidos são as lotéricas e o banco postal.

CPF - Cadastro de Pessoa Física (CPF Number)

O CPF é o Cadastro de Pessoa Física. Ele é um documento emitido pela Receita Federal e serve para identificar os contribuintes. O CPF é uma numeração com 11 dígitos, que só mudam por decisão judicial

Crédito (Credit)

É um termo geral, utilizado para nomear as diferentes maneiras com que bancos, financeiras e outras instituições emprestam dinheiro a seus clientes. Ou seja, quando essas instituições emprestam dinheiro para alguém ou financiam alguma compra de uma pessoa, elas estão concedendo um crédito. Exemplo de uso: Em uma operação de crédito, quem empresta o dinheiro é chamado credor, e quem toma o dinheiro emprestado é chamado devedor.

Fonte: link

Crédito Rotativo (Overdraft)

É um tipo de empréstimo que os bancos concedem para os clientes terem a possibilidade de não pagar, na data do vencimento, o valor total da fatura do cartão de crédito. Isto é, por causa do crédito rotativo, é possível que o cliente pague, no dia do vencimento, qualquer valor entre o pagamento mínimo e o total da fatura. A diferença entre o valor total que deveria ter sido pago e o valor que o cliente efetivamente pagou na data do vencimento é financiada pelo banco e será incluída, acrescida de juros, na fatura do mês seguinte. Quando o cliente não paga o total da fatura, é como se ele estivesse automaticamente pegando emprestado o valor que ele deixou de pagar.

Custo Efetivo Total (CET)

Custo Efetivo Total. Corresponde a todos os encargos e despesas incidentes nas operações de crédito e de arrendamento mercantil financeiro, contratadas ou ofertadas a pessoas físicas, microempresas ou empresas de pequeno porte. Deve ser informado pelas instituições financeiras e pelas sociedades de arrendamento mercantil antes da contratação de operações de crédito e de arrendamento mercantil e também em qualquer outro momento, a pedido do cliente. Também deve constar dos informes publicitários das instituições quando forem veiculadas ofertas específicas (com divulgação da taxa de juros cobrada, do valor das prestações, etc).

Fonte: Resolução 3.517, de 6/12/2007. link

Débito (Debit)

De uma forma geral, significa dívida. Exemplo de uso: Estou em débito com o Fernando, devo R$50 a ele. Ver também: crédito, credor, devedor, dívida.

Débito (no extrato) Em um extrato bancário, os débitos, marcados com a letra “D” ao lado do valor registrado, informam as saídas de dinheiro na conta-corrente. Exemplo de uso: Fiz uma compra com a função débito do cartão e apareceu o valor da compra, com um “D”, no extrato da minha conta, diminuindo o saldo.

Fonte: link

Débito Automático (Direct Debit)

Débitos autorizados pelo titular de conta de depósitos ou de conta de pagamento mantidas nas instituições mencionadas

Direito Creditório Descontado (Invoice Financing)

É o direito de receber dinheiro ou títulos, sejam eles oriundos de operações financeiras, comerciais, imobiliárias ou mesmo de ativos financeiros e investimentos. Esta opção abrange tanto pessoas físicas quanto entidades. Normalmente, ele “existe” na forma de um título.

Dependência (Branch)

Dependência de instituições financeiras e demais instituições, autorizadas a funcionar pelo Banco Central do Brasil, destinada à prática das atividades para as quais a instituição esteja regularmente habilitada. (Agência é a dependência destinada ao atendimento aos clientes e ao público em geral no exercício de atividades da instituição, não podendo ser móvel ou transitória)

Empréstimo (Loan)

É o mecanismo utilizado para ter disponível, no presente, uma quantia que só se conseguiria alcançar no futuro, fazendo poupança. O valor emprestado, mais os juros e encargos cobrados pela instituição financeira, vira uma dívida, que deverá ser paga na forma e no prazo combinados (valor e quantidade de parcelas, por exemplo). No empréstimo, o valor emprestado não tem destinação específica, isto é, a pessoa pode utilizar o dinheiro que pegou emprestado onde e como quiser.

Empréstimo Cartão Consignado (Payroll Loan)

É um tipo de operação de crédito contratada no Cartão de Crédito, na qual o pagamento das compras do titular são descontadas diretamente em folha ou benefício do INSS

Encargo (Charge)

As instituições financeiras e as sociedades de arrendamento mercantil podem cobrar de seus clientes, no caso de atraso no pagamento ou na liquidação de obrigações, exclusivamente os seguintes encargos: I - juros remuneratórios, por dia de atraso, sobre a parcela vencida; II - multa, nos termos da legislação em vigor; e III - juros de mora, nos termos da legislação em vigor.

Fonte: link

Ente Consignante (CnpjConsignee)

É a empresa pública ou privada que mantém convênio com entidades Consignatárias afim de descontar no contracheque de seus funcionários os valores mensais referente as operações financeiras contratadas pelos mesmos obedecendo a regra da margem consignável.

Os entes consignantes podem ser :

• Privado - Destinado a funcionários de empresas do setor privado
• Público - (prefeituras, estados, órgãos) - Destinado a servidores públicos federais, estaduais ou municipais
• INSS - Destinado a beneficiários (aposentados e / ou pensionistas) do INSS.

Fatura (Bill)

Fatura é o documento através do qual o emissor realiza a prestação de contas ao portador titular. Nos meses em que ocorrer movimentação, o emissor do cartão de crédito enviará a Fatura discriminando as respectivas transações do período.

Financiamento (Financing)

Parcelamento. Compra parcelada. Compra a prazo. É um crédito que a pessoa obtém para comprar um bem, como uma casa, um carro, um eletrodoméstico. O pagamento do bem é feito de forma parcelada por meio de carnês, boletos de cobrança, débitos em conta corrente, cartão de crédito, cheques etc. O financiamento pode incluir custos como juros, tarifas, impostos, entre outros encargos.

Garantia (Warranty)

Ativo que é entregue pelo outorgante da garantia para assegurar uma obrigação à parte que toma a garantia. Os acordos de garantia podem tomar diversas formas legais; as garantias podem ser obtidas por transferência de títulos ou penhora.

Fonte: link

Identificação (Identification)

Agrupador das informações relativas a Identificação ou seja a ação e o efeito de identificar de forma única a pessoa através de seus dados cadastrais

Identificador Padronizado da Operação de Crédito – Ipoc Code

O identificador padronizado da operação de crédito é atribuído a todas as operações de crédito informadas ao SCR (Sistema de Informações de Crédito do Banco Central do Brasil – SCR é um instrumento de registro e consulta de informações sobre as operações de crédito, como empréstimos, financiamentos, avais ou fianças, realizadas entre as Instituições Financeiras e seus Clientes).

O IPOC será formado pela concatenação das informações contidas nos campos do SCR abaixo discriminados, respeitando-se a seguinte ordem:

1. CNPJ da instituição
2. Modalidade da operação
3. Tipo do cliente
4. Código do cliente
5. Código do contrato

Fonte: link

Indexador (Indexer)

É o termo utilizado para se referir aos índices usados como base para corrigir os valores monetários de um determinado ativo. Os índices mais utilizados são IPCA, INPC, IGP-M, CDI, Taxa Selic.

Instituição Financeira (Company)

Instituições que prestam serviços financeiros e são autorizadas a funcionar pelo Banco Central do Brasil.

Limite Flexível (Flexible Limit)

Geralmente esses cartões não possuem limite oculto inferior a R$ 50 mil, ou seja, é o mesmo que sem limite pré-estabelecido de despesas. Pois são voltados para consumidores de alto poder aquisitivo, sendo considerado um cartão de crédito diferenciado, pois permite ao portador comprar o que quiser.

Marca (Brand)

A marca é em essência uma promessa da empresa em fornecer uma série específica de atributos, benefícios e serviços uniformes aos clientes.

MCC (Merchant Category Code)

O MCC ou o código da categoria do estabelecimento comercial. Os MCCs são agrupados segundo suas similaridades. O MCC é usado para classificar o negócio pelo tipo fornecido de bens ou serviços. Os MCCs são atribuídos por tipo de comerciante (por exemplo, um para hotéis, um para lojas de materiais de escritório, etc.) ou por nome de comerciante (por exemplo, 3000 para a United Airlines).

Mês de Referência (Reference Month)

O mês de referência será tratado como “M-1”.

Nome Civil Completo (Civil Name)

Nome civil completo da pessoa natural é aquele atribuído à pessoa natural desde o registro de seu nascimento, com o qual será identificada por toda a sua vida, bem como após a sua morte. Trata-se de um Direito fundamental da pessoa natural

Nome Social (Social Name)

O nome social é definido como a adoção/ adequação do senso de identificação do sujeito referenciando o nome que o representa (Decreto Nº 51.180, de 14 de janeiro de 2010), evitando a exposição desnecessária do indivíduo, o constrangimento de ser tratado de uma forma que não condiz com sua condição humana, psicológica, moral, intelectual, emocional e que não o representa. Tem por objetivo o reconhecimento social e individual segundo o Art. 16 do Código Civil, toda pessoa tem direito ao nome, nele compreendidos o prenome e o sobrenome.

Pacote de Serviços (Service Bundles)

Cesta de serviços. É uma combinação de diferentes quantidades de serviços bancários (saques, extratos, transferências, cheques e outros) que o cliente pode usar por mês. Antes da contratação de um pacote de serviços, é importante verificar quais os serviços que são efetivamente usados ao longo do mês e se o custo desses serviços, cobrados isoladamente, não é menor que o do pacote de serviços.

Pagador (Payer)

É a pessoa ou a empresa que deve pagar o valor cobrado em um boleto bancário, normalmente por ter feito uma compra, um financiamento ou por estar pagando por um serviço, como uma mensalidade escolar, por exemplo. O banco recebe o pagamento feito pelo sacado e transfere o valor pago para a conta do beneficiário. No boleto, o campo “pagador” costuma trazer outras informações além do nome do pagador, como o seu endereço. Exemplo de uso: Ao receber um boleto para pagar, a pessoa deve sempre conferir se seus dados estão corretos no campo “pagador”. Se houver algum erro, ela deve procurar o banco que emitiu o boleto

Fonte: link

Pagamento Autorizado (Authorised Payment)

São transações a crédito ou débito que ainda não foram registradas no extrato, mas que a instituição possui autorização do cliente para realizar o débito.

Fonte: link

Posto de Atendimento Bancário - PAB (Branch)

São as dependências de bancos múltiplos com carteira comercial, instaladas em recinto interno de entidade da administração pública ou de empresa privada e destinadas a prestar todos os serviços para os quais a instituição esteja regularmente habilitada de exclusivo interesse do respectivo governo e de seus funcionários, quando instalados em entidade de administração pública, ou da respectiva empresa, de seus empregados e administradores, quando instalados em dependências de empresa privada.

Posto de Atendimento Eletrônico – PAE (Branch)

O Posto de Atendimento Bancário Eletrônico, Fixo ou Móvel (PAE), é uma extensão automatizada de dependências bancárias, que pode funcionar até 24 (vinte e quatro) horas por dia, ligada à central de controle e processamento.

Prestação Regular (Instalment)

Refere-se a comprar um produto ou serviço de forma parcelada e assim dividir o pagamento em partes, em prestações a serem pagas ao longo de um período de tempo em intervalos regulares, p.ex. parcelas mensais, onde o vencimento acontecerá regularmente todo dia 10 de cada mês

Procurador (Procurator)

Pessoa autorizada por procuração para dirigir os negócios de outrem ou agir como seu agente, representante, substituto ou advogado.

Qualificação (Qualification)

Considera-se qualificação as informações que permitam as instituições apreciar, avaliar, caracterizar e classificar o cliente com a finalidade de conhecer o seu perfil de risco e sua capacidade econômico-financeira

Razão Social (Company Name)

A razão social é o nome de registro de uma empresa junto aos órgãos do governo e cartório e é o que vai constar em contratos, escrituras, documentos legais, notas fiscais etc. Ela é criada junto com o CNPJ e também é chamada de Denominação social – exatamente por ser, na prática, o nome da pessoa jurídica

Recebedor (Payee)

Pessoa natural ou jurídica, destinatário final dos recursos de uma transação de pagamento

Fonte: link

Relacionamento (Financial Relation)

Considera-se relacionamento as informações que permitam conhecer desde quando a pessoa consultada é cliente da instituição, bem como um indicador dos produtos e serviços que ela consome atualmente e seus representantes

Representante Legal (Legal Representative)

Nome Civil completo da Pessoa Natural que represente uma entidade ou uma empresa e é nomeado em seu ato constitutivo, ou seja, no contrato social ou estatuto social

Saldo (Account Balance)

Quantia que representa o excedente do total de créditos e do total de débitos de uma conta.

Saldo Bloqueado (Cash Blocked)

É um valor que o banco informa estar separado na conta-corrente para o pagamento, ao fim do dia, de alguma obrigação que tem vencimento naquele dia.

Exemplo de uso:

• Se o saldo da minha conta é de R$1.000, mas eu vejo que tem um saldo provisionado de R$400, isso quer dizer que só posso movimentar R$600, se não quiser entrar no vermelho.
• Valor depositado na conta que se encontra bloqueado para utilização, como bloqueios judiciais.

Fonte: link

Saldo Devedor (Outstanding Balance)

Corresponde ao valor que falta ser pago de uma dívida. Ao longo do tempo, os juros fazem o saldo devedor crescer, enquanto as amortizações pagas pelo devedor fazem o saldo devedor diminuir. O saldo devedor pode vir tanto de um empréstimo ou financiamento quanto de um pagamento inferior ao valor total de uma fatura de cartão de crédito. Ou ainda, em conta-corrente, o que significa que o cliente está “no vermelho” ou “no negativo”, isto é, entrou no limite de crédito do cheque especial ou utilizou o adiantamento a depositantes.

Saldo Disponível (Cash Amount)

É o valor total à disposição do cliente em sua conta-corrente, que inclui tanto o dinheiro que ele tem depositado nela quanto o limite de cheque especial pré-aprovado pelo banco. 43 Exemplo de uso: Ao consultar o extrato bancário, para saber quanto dinheiro seu de fato tem depositado em conta, o cliente não pode considerar o saldo disponível.

Fonte: link

Sexo (Sex)

“Conjunto de características anatomofisiológicas que distinguem o homem e a mulher: Sexo masculino; sexo feminino”. No caso de não ser feminino nem masculino é classificado como outros.

Sistema de Amortização Constante (SAC)

É aquele em que o valor da amortização permanece igual até o final. Os juros cobrados sobre o parcelamento não entram nesta conta.

Sistema de Amortização Misto (SAM)

Cada prestação (pagamento) é a média aritmética das prestações respectivas no Sistemas Price e no Sistema de Amortização Constante (SAC)

Sistema Francês de Amortização (Price)

As parcelas são fixas do início ao fim do contrato. Ou seja, todas as parcelas terão o mesmo valor, desde a primeira até a última. Nos primeiros pagamentos, a maior parte do valor da prestação corresponde aos juros. Ao longo do tempo, a taxa de juros vai decrescendo. Como o valor da prestação é fixo, com o passar das parcelas, o valor de amortização vai aumentando.

Tarifa (Fee)

A Resolução 3.919, de 25/11/2010, classifica em quatro modalidades os tipos de serviços prestados às pessoas físicas:

1. serviços essenciais – não podem ser cobrados;
2. serviços prioritários – relacionados a contas de depósitos, transferências de recursos, operações de crédito e de arrendamento mercantil, cartão de crédito básico e cadastro, somente podendo ser cobrados os serviços constantes da Lista de Serviços da Tabela I anexa à (Resolução CMN 3.919, de 2010, devendo ainda ser observados a padronização, as siglas e os fatos geradores da cobrança, também estabelecidos por meio da citada Tabela I;
3. serviços especiais – legislação e regulamentação específicas definem as tarifas e as condições em que são aplicáveis, a exemplo dos serviços referentes ao crédito rural, ao Sistema Financeiro da Habitação (SFH), ao Fundo de Garantia do Tempo de Serviço (FGTS), ao Fundo PIS/PASEP, às chamadas contas-salário, e às operações de microcrédito de que trata a Resolução 4.000, de 2011;
4. serviços diferenciados – podem ser cobrados desde que explicitadas ao cliente ou ao usuário as condições de utilização e de pagamento

Fonte: link

Taxa Efetiva (EffectiveTax)

É a taxa de juros em que a unidade referencial coincide com a unidade de tempo da capitalização. Como as unidades de medida de tempo da taxa de juros e dos períodos de capitalização são iguais, usa-se exemplos simples como 1% ao mês, 60% ao ano.

Taxa nominal (NominalTax)

É uma taxa de juros em que a unidade referencial não coincide com a unidade de tempo da capitalização. Ela é sempre fornecida em termos anuais, e seus períodos de capitalização podem ser diários, mensais, trimestrais ou semestrais.

Taxa Referencial – TR (Referential Rate)

É a taxa de juros de referência. É uma taxa calculada pelo Banco Central do Brasil e utilizada para determinar o rendimento de investimentos, como a caderneta de poupança e a correção de financiamentos imobiliários.

Terminais de Autoatendimento Compartilhados (Shared Automatic Teller Machine)

É o compartilhamento dos terminais de autoatendimento (ATM - dispositivo eletromecânico que permite aos usuários, geralmente usando cartões de plástico legíveis em máquina, a realização de um ou mais tipos de operações, tais como saques, depósitos, emissão de extratos e saldos, realização de pagamentos de contas e títulos, transferência de fundos e outro) para aumentar a eficiência do sistema de pagamento de varejo.

Transação Agendada (Scheduled Payment)

O usuário poderá agendar uma transação de DOC, TED, PIX ou boleto bancário para uma determinada data futura

Fontes: link 1 e link 2

Transações Realizadas (Completed Transaction)

Operações segmentadas efetuadas por tipo de acesso físico (agências e postos tradicionais, caixas de autoatendimento e correspondentes bancários) ou remoto (home e office banking, call centers, smartphones e PDAs) e por tipo de transações( Bloqueto de cobrança e convênios, depósitos, ordem de transferência de crédito, empréstimos e financiamentos, saques, outras transações financeiras, consultas a extratos e saldos e outras transações não financeiras)

Fontes: link 1 e link 2

Unidade Administrativa Desmembrada (UAD) - (Branch)

É a dependência destinada à execução de atividades administrativas da instituição, tal como atividades contábeis e administrativas de natureza interna, desde que tal unidade esteja instalada no mesmo Município da sede do grupo financeiro, ou de uma agência da instituição e é vedado o atendimento ao público.

Segurança

Introdução - Segurança

Esta seção tem como finalidade auxiliar na auto avaliação aos cumprimentos dos requisitos de segurança da informação relacionados a autorização e autenticação de APIs e End-Users, emissão de certificados digitais e requisitos para o onboarding no Diretório de participantes para as Instituições participantes do Open Banking.

As instituições participantes do Open Banking possuem a obrigação de acompanhar a edição e a revogação de eventuais normas com impacto no tema de forma a estar permanentemente em dia com as determinações legais. Compõem, de forma não exaustiva, o rol de atos normativos cuja observância é essencial pelas instituições participantes do Open Banking:

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

Além desse guia, foi elaborado um checklist para auxiliar os participantes do Open Banking a alcançar um nível adequado de Segurança da Informação, esse checklist pode ser baixado em formato Word ou Excel a seguir.

Download Autoavaliação dos requisitos de SI - 1.0.docx
Download Autoavaliação dos requisitos de SI - 1.0.xlsx

Visão geral

As APIs de Open Banking estão dividas em dois escopos:

• open-data
• customer-data

Segue, a continuação, um overview das camadas de segurança básicas para atender os contextos Open-data:

Perfil de segurança

Sobre os padrões de perfil de segurança de API.

É necessário que os participantes do Open Banking adotem padrões de autenticação e autorização para as APIs e End-Users, utilizando frameworks e mecanismos aprovados pelo mercado, garantindo assim, a integridade, a confidencialidade e a disponibilidade dos dados.

Conjunto de referências normativas adotadas pelo Open Banking:

Para melhor entendimento do FAPI-Read and Write API Profile e do CIBA-Financial-grade API: Client Initiated Backchannel Authentication Profile, é preciso ter conhecimento sobre OAuth2 e OpenID Connect.

OAuth 2.0

OAuth 2.0 é um framework de autorização que habilita um aplicativo a obter acesso limitado para um serviço de terceiro, introduzindo uma camada de autorização e segmentando as funções do client. Ao invés de utilizar credenciais fornecidas pelo proprietário do recurso, o client recebe um Access Token, contendo o escopo do acesso, tempo de vida, entre outros atributos. Os Access Tokens são emitidos para clients terceiros por um servidor de autorização com a aprovação do proprietário do recurso.

O OAuth 2.0, define 4 papéis.

• End-User: Uma entidade capaz de conceder acesso a recursos protegidos. Quando o proprietário do recurso é um usuário, ele provê o nível de acesso, limitando o escopo de autorização (leitura ou escrita).
  
• Resource Server: Servidor que hospeda os recursos protegidos, capaz de aceitar e responder a solicitações de recursos protegidos utilizando tokens de acesso.
• Client: Um aplicativo que faz solicitações a recursos protegidos em nome do proprietário do recurso, com a sua autorização.
• Authorization Server: É o servidor que emite tokens de acesso ao client, após autenticar com sucesso e obter autorização do End-User.

Tokens

O OAuth 2.0 faz o uso de diversos tokens, entre eles, o access token, refresh token e Authorization "code".

• Access token: Um token de acesso é utilizado por um client para acessar um recurso, geralmente possuem ciclo de vida curto (minutos ou horas), sendo consumidos durante uma sessão. O Access token indica que o client está autorizado a consumir um recurso protegido, respeitando os scopes para qual o token foi emitido. O token pode ser renovado através de um refresh token. O tipo de Access Token será o "Bearer" OAuth Access Token, referenciado em [RFC 6750].
• Refresh token: Representa uma autorização de longa duração de um client. Esses tokens são trocados entre o client e o Authorization Server e são utilizados para obter (“atualizar”) novos tokens de acesso.
• Authorization code: É um código de autorização que representa o resultado do processo de autorização bem sucedido do usuário final e é utilizado pelo client para obter acesso e atualizar status dos tokens.

É necessário a implementação de um endpoint adicional no Authorization Server que possibilita a revogação do Access Token e do Refresh Token. Um request de revogação invalidará um ou mais Tokens (se aplicável), baseados na mesma concessão de acesso, conforme [RFC 7009].
Também será adotado o OAuth Token Introspection que define um método para um recurso protegido consultar um Authorization Server sobre o estado e os metadados de um Token, conforme [RFC 7662].
Devido a ampla aplicação do uso do OAuth 2.0, as melhores práticas de segurança do OAuth 2.0 estão em constate atualização e podem ser consultadas neste endereço https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16.

Início do fluxo de uma API com a obtenção de um Access Token.

Diagrama – Obtendo um Access Token.

1. Estabelece conexão TLS 1.2 entre o usuário e o client.
2. Estabelece conexão mTLS 1.2 entre o client e o Authorization Server.
3. Efetua um POST com as credenciais de autenticação do client e o escopo da solicitação.
4. Valida a autenticação de credenciais do client, o escopo e o certificado SSL.
5. Devolve o Access Token com a mensagem HTTP 200 (OK).
6. Estabelece conexão mTLS 1.2 entre o Client e o Resource Server.
7. Efetua um POST com o Access Token e o escopo.
8. Valida o Access Token, o escopo e o certificado.
9. Resposta com a mensagem HTTP 201 com o ID da transação.
10. Início do Hybrid Flow.

OpenID Connect (OIDC)

O OpenID Connect é uma camada de identidade sobre o protocolo OAuth 2.0, que permite a identificação de um usuário final com base na autenticação realizada por um Authorization Server. OpenID Connect permite uma grande variedade de tipos de clients, sendo, clients Web, clients móveis e JavaScript, oferecendo suporte a recursos opcionais, como criptografia de dados de identidade, descoberta de provedores de OpenID e gerenciamento de sessão.
Existem três papéis envolvendo uma solução de OIDC:

• End-User: É o sujeito a ser autenticado.
  
• OpenID Provider - OP: O provedor OpenID é um servidor de autorização OAuth 2.0 que implementa OIDC e pode autenticar um usuário e retornar claims sobre o usuário autenticado e o evento de autenticação para uma parte confiável, geralmente um aplicativo.
• Relying Party – RP: Um client OAuth 2.0 que delega a autenticação de usuários para um provedor de OpenID e solicita claims sobre o usuário do provedor OpenID, geralmente denominado, client.

ID Token

O OIDC utiliza o authorization code, access token e refresh token descrito na seção anterior sobre OAuth e define um outro tipo de Token, o ID Token.

• ID Token: Um token utilizado para transmitir claims sobre um evento de autenticação e um usuário autenticado (End-user) para um client. Tokens de identificação são codificados em JSON Web Token (JWT) e deve estar em conformidade com a LGPD.

{"iss": "http://YOUR_DOMAIN/",
"sub": "xpto|123456",
"aud": "YOUR_CLIENT_ID",
"exp": "1311281970",
"iat": "1311280970",
"id": "1234567"}

UserInfo Endpoint: Retorna claims sobre um usuário autenticado. Chamar o endpoint requer um Access Token e as claims retornadas são regidos pelo Access Token.
Exemplo de resposta bem-sucedida contendo um ID Token assinado:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": "3600",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"}

JWT

O formato JWT (JSON Web Token) é projetado para transmitir claims entre duas partes. O JWT consiste em um Header, um payload e uma assinatura. O cabeçalho do ID Token contém informações sobre o tipo de objeto (JWT) e o algoritmo de assinatura utilizado para proteger a integridade dos claims do payload. O algoritmo de assinatura exigido é o PS256 (RSASSA-PSS utilizando SHA-256 e MGF1 com SHA-256). A seção do payload contém as claims sobre um usuário e o evento de autenticação. A seção de assinatura contém uma assinatura digital com base no payload do ID Token e uma chave secreta conhecida pelo provedor OpenID.

O JWT é formado por três seções: Header, Payload e Signature.
O Header contém somente a informação tipo e algoritmo:

{"typ": "JWT",
"alg": " PS256"}

Payload

O Payload é um objeto JSON com as Claims da entidade tratada, normalmente o usuário autenticado.
Claims são informações afirmadas sobre um sujeito, por exemplo um ID Token, pode conter uma claim chamada name que afirma que o usuário autenticado é quem diz ser. Em um JWT uma claim aparece como um par nome/valor em que o nome é sempre uma string e o valor pode conter qualquer conteúdo JSON. Essas claims podem ser de 3 tipos:

Reserved claims: São claims definidas pela especificação do JWT e contém atributos não obrigatórios (mais recomendados) que são usados na validação do token pelos protocolos de segurança das APIs. É possível verificar a lista completa de Reserved Claims em [IANA JSON Web Token Claims Registry].

{"sub": "Subject, entidade à quem o token pertence, normalmente o ID do usuário",
"iss": "Issuer, emissor do token",
"exp": "Expiration, timestamp de quando o token irá expirar",
"iat": "Issued at, timestamp de quando o token foi criado",
"aud": "Audience, destinatário do token, representa a aplicação que irá usá-lo"}

Public claims: atributos utilizados nas aplicações. Normalmente armazenamos as informações do usuário autenticado na aplicação.

{"name": "Joe",
"roles": "Administrator",
"permissions": "Full"}

Private claims: são claims personalizadas e contém atributos definidos para compartilhar informações entre aplicações.

{"sub": "1234567890",
"name": "Jose Doe"
"admin": "true"}

Conjunto de claims para um ID Token do Open Banking:

{"iss": "Emissor do token",
"sub": "Identificador único do subject",
"openbanking_intent_id": "Intent ID da solicitação",
"aud": "Público alvo para o qual o ID Token é destinado (deve incluir o Client ID)",
"exp": "Data/hora de expiração do token",
"iat": "Data/hora de emissão do token",
"auth_time": "Data/hora de autenticação do End-user",
"nonce": "Valor string que associa uma sessão do cliente com um ID Token usado para ajudar na mitigação de ataques de replay",
"acr": "Authentication Context Class Reference",
"amr": "Authentication Methods References",
"azp": "Authorized party",
"s_hash": "State hash value",
"at_hash": "Access Token hash value",
"c_hash": "Code hash value"}

Assinatura

A assinatura é o header e o payload criptografados com um secret.

PS256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

Para obter o token JWT, as três seções header (vermelho), payload (roxo) e signature (azul) são codificadas com Base64-URL e unidas por pontos.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJz
dWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4g
RG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSM
eKKF2QT4fwpMeJf36POk6yJV_adQssw5c

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. -> Header
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ. -> Payload
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c -> Signature

Este token JWT deve ser enviado no cabeçalho Authentication HTTP usando o esquema Bearer. O conteúdo do cabeçalho deve seguir este formato:

Authorization: Bearer

Fluxo OpenID Connect (OIDC)

O OpenID Connect define os seguintes fluxos:

• Authorization Code Flow: Para autenticar um usuário, o client redireciona o usuário para um provedor de OpenID. O provedor OpenID autentica o usuário e redireciona o usuário de volta para o client com um código de autorização. O aplicativo usa o código de autorização para obter um ID Token, Access Token e, opcionalmente, um Refresh Token do endpoint do provedor OpenID.
• Implicit flow: Todos os tokens são retornados pelo endpoint de autorização, o Endpoint de Token não é utilizado, esse tipo de fluxo é usado principalmente por Clients implementados em um navegador utilizando uma linguagem de script. O Access Token e o ID Token são devolvidos diretamente ao Client, que pode expô-los ao usuário final e aos aplicativos que têm acesso
• Hybrid flow: O Hybrid Flow, combina elementos do Authorization Code Flow e Implicit Flow, esse modelo permite retornar um ID Token e um Authorization Code como uma resposta ao front-end do client, deixando o backend obter um Access Token e opcionalmente um Refresh Token do endpoint de token utilizando o Authorization Code. Esse padrão de autenticação foi escolhido como mandatório pelo Open Banking e pode ser observado no diagrama a seguir.

Diagrama - Fluxo Hybrid Flow

1. Usuário acessa o aplicativo e faz requisições ao Client.
2. Client redireciona a requisição de autenticação ao Authorization Server.
3. O Authorization Server interage com o usuário com a requisição de autenticação e o consentimento sobre o escopo.
4. Usuário efetua a autenticação e provê o consentimento, o Authorization Server cria ou atualiza uma sessão para o usuário.
5. Authorization Server direciona o End-User de volta ao client com um código de autorização e, dependendo do tipo da resposta, com parâmetros adicionais.
6. O Client solicita uma resposta ao Authorization Server com o código de autorização para obter os demais tokens.
7. O Authorization Server responde com o ID Token e um Access Token.
8. O Client valida o ID Token e busca o Subject Identifier do End-User. O Authorization Server deve suportar request objects conforme especificado na seção 6.1 (Request Object) do OIDC.

   Financial-grade API (FAPI)

   Financial-grade API, o FAPI, é uma especificação técnica desenvolvida pelo Grupo de Trabalho Financial-grade API da OpenID Foundation. Ele utiliza OAuth 2.0 e OpenID Connect (OIDC) como sua base e define requisitos técnicos adicionais para o setor financeiro e outros setores que exigem maior segurança.

FAPI: Read and Write API Security Profile

É obrigatório o uso do perfil de segurança FAPI-Financial-grade API: Read and Write API Security Profile, referenciado no endereço: https://openid.net/specs/openid-financial-api-part-2-wd-06.html.

FAPI: CIBA-Client Initiated Backchannel Authentication Profile

A autenticação pelo CIBA fornece um fluxo desacoplado, possibilitando autorizar um pagamento por exemplo em um terminal de ponto de venda ou em um posto de combustível. O perfil de segurança CIBA: Client Initiated Backchannel Authentication Profle será opcional pelos participantes do Open Banking, referenciado no endereço: https://openid.net/specs/openid-financial-api-ciba.html.

Fluxos de autenticação e autorização

Um Autorizador deve usar o protocolo OpenID Connect (OIDC) e o OAuth 2.0 Authorization Framework para autenticar usuários e obter sua autorização para acessar recursos protegidos.
A autenticação e a autorização representam funções fundamentalmente diferentes, conforme comparativo abaixo:

Camada de transporte

A comunicação entre os aplicativos terceiros e os recursos protegidos, devem ser sempre protegidas utilizando uma conexão TLS versão 1.2 ou superior. A conexão TLS deve ser estabelecida sempre utilizando o certificado qualificado para a autenticação do site e o certificado deve ser emitido seguindo as normas definidas para o Open Banking.

Fluxo client credentials

Com aplicativos machine-to-machine (M2M), como serviços em execução no back-end, o sistema autentica e autoriza o Client em vez de um usuário. Para este cenário, esquemas de autenticação típicos como nome de usuário + senha ou logins sociais não fazem sentido.

Em vez disso, as aplicações M2M usam o fluxo Client Credentials utilizando mTLS (definido em OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound RFC 8705) e infraestrutura de chave pública (PKI). No qual o Client, o Authorization Server e o Servidor API são autenticados usando certificados X.509. O Access Token também é vinculado ao Client e validado utilizando certificados X.509.

Este método acrescenta uma restrição com chave de confirmação (ou prova de posse) ao Client que deseja utilizar um token emitido, com isso ele mitiga a possibilidade de uso abusivo dos Access Tokens Oauth tradicionais em caso de vazamento.

Diagrama – Fluxo de credenciais do client.

1. O client e o servidor de autenticação estabelecem uma conexão mTLS, e o Client solicita um Access Token.
2. O Servidor de Autenticação gera uma impressão digital SHA-256 do certificado do Client e a incorpora em um Access Token JWT. Isto limita o Access Token ao Client.
3. O servidor de autenticação emite o Access Token como uma resposta ao Client.
4. Os Clients fazem uma solicitação de recursos ao Servidor API usando o Access Token.
5. O Servidor de API solicita ao Authorization Server que valide o Access Token.
6. O Servidor API usa a impressão digital embutida para validar o Access Token.
7. O Servidor de Autenticação retorna o resultado da validação do token.
8. O Servidor API responde com o recurso solicitado.

Conforme definido na Seção 6.1 do RFC8705, os endpoints utilizados para emissão e validação de tokens que requerem uma conexão mTLS são endpoints convencionais separados por hostname ou porta diferente.

Fluxo do Authorization Code

No Fluxo do Authorization Code, o Client pode recuperar um Access Token e, opcionalmente, um Refresh Token. É considerada a escolha mais segura, pois o Access Token é passado diretamente para o servidor que hospeda o Client, sem passar pelo navegador do usuário e correr o risco de exposição.

Como os Clients são aplicativos do lado do servidor em que o código-fonte não é exposto publicamente, eles podem usar o fluxo do Authorization Code (definido no OAuth 2.0 [RFC 6749], seção 4.1 ), que troca um Authorization Code por um token. Seu Client deve estar no lado do servidor, porque durante essa troca, você também deve passar adiante o client secret do seu Client, que deve ser mantido sempre seguro, e deve armazená-lo em seu client.

Diagrama - Fluxo do código de autorização.

1. O usuário clica em Login no Client.
2. O client redireciona o usuário para o Authorization Server.
3. O Authorization Server redireciona o usuário para o prompt de login e autorização.
4. O usuário se autentica usando uma das opções de login configuradas e verá uma página de consentimento listando as permissões que o Autorizador dará ao Client.
5. O Authorization Server redireciona o usuário de volta ao client com um Authorization Code, que é válido para um uso.
6. O client envia esse código para o Authorization Server junto com o Client ID e o client secret do Client.
7. O Authorization Server verifica o código, o Client ID e o client secret do client.
8. O Authorization Server responde com um ID Token e um Access Token (e, opcionalmente, um Refresh Token).
9. O Client usa o Access Token para chamar uma API para acessar informações sobre o usuário.
10. A API responde com os dados solicitados.

Fluxo de Consentimento

[EM REVISÃO/ALTERAÇÃO - ABRIL DE 2021]

Pedidos de revogação de consentimentos feitos pelo usuário final por meio de API´s da instituição receptora devem obrigatoriamente implicar na revogação dos tokens de acesso e de consentimento relacionados por meio de chamadas executadas no servidor de autorização da instituição transmissora responsável pelo consentimento e/ou em API de consentimento mantida pelo transmissor. A instituição transmissora deve disponibilizar, por meio de API específica para o controle de consentimentos, interface que permita à instituição receptora detentora de consentimentos a verificação do seu estado. O acesso à API de consentimento deve ser precedido de autenticação e a consulta deve ser restrita ao consentimento a que a instituição receptora teve autorização prévia para acesso, com vistas a garantir que apenas a instituição receptora que registrou o pedido de consentimento possa realizar a consulta sobre o seu estado. A instituição receptora de dados detentora de consentimentos e de tokens de autorização deve revogá-los, por meio de chamadas específicas às API´s das instituições transmissoras publicadas para esse fim, quando perceber violações à confidencialidade dos tokens ou no fim da prestação dos serviços ao usuário final.

Padrão Lodging Intent

Essa seção descreve o padrão Lodging Intent, utilizado para parametrizar solicitações de autorização OAuth complexas de maneira confiável e segura. O OAuth por si, suporta apenas autorizar ações simples de leitura, o parâmetro scope é definido por uma lista delimitada por espaços contendo strings simples, quando se trata de autorizações mais complexas, como o início de um pagamento, o suporte integrado do OAuth não é suficiente. O padrão Lodging Intent pode ser utilizado para passar informações de forma confiável para o processo de autorização, independente das restrições de comprimento de URL, enquanto as informações também são protegidas contra modificação sem a necessidade de assiná-las digitalmente, reduzindo os custos de implementação. Executar um processo de autorização utilizando o padrão Lodging Intent e o Code Flow, funciona da seguinte maneira:

• O client cria um recurso contendo todos os dados necessários para informar o processo de autorização no Authorization Server, a criação do Lodging Intent pode exigir uma autorização própria, nesse caso, o client precisa obter antecipadamente um Access Token com o escopo adequado, normalmente usando a concessão do Client Credentials com o* Authorization Server*.
• O serviço de Lodging Intent responde ao client com um id e/ou link para o recurso criado.
• O client então envia a referência do recurso com o pedido de autorização para o Authorization Server. O Authorization Server obtém os dados da transação do recurso de hospedagem e depois de autenticar o usuário, utiliza-os para apresentar uma interface de consentimento. Por exemplo, no caso de um pagamento, o Authorization Server mostra ao devedor, o valor e informações adicionais sobre a transação de pagamento ao usuário e pede o seu consentimento.
• Se o usuário consentir com a autorização solicitada, o Authorization Server associa os dados de autorização à concessão criada (ou atualizada) e os respectivos Access Tokens emitidos com base nessa concessão. Por último, o Authorization Server precisa fornecer os dados de autorização ao respectivo Resource Server, para que seja incorporado no Access Token ou na resposta de Introspection do Token.

Mais detalhes sobre o funcionamento do padrão Lodging Intent pode ser consultado em https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.md .

Assinatura de mensagens

A assinatura de mensagens deve ser aplicada a APIs específicas, de acordo com a definição na documentação do Endpoint.
Para a assinatura de mensagens, deve ser suportado o uso de um JWT assinado (JWS). JWS representa o conteúdo protegido com assinaturas digitais ou com Message Authentication Codes (MACs) utilizando estruturas de dados JSON, referenciado em [RFC 7515].

Estrutura de um token com JWS.

Certificados

Dois tipos de certificados serão emitidos pelo ICP-Brasil para serem utilizados no Open Banking com as funções de transporte e assinatura. Atributos comuns a ambos os certificados:

Transporte

Certificado de transporte para a proteção e autenticação do canal (mTLS) e será utilizado para criptografar requisições e respostas entre Third Parties e bancos. Atributos específicos do certificado de transporte:

Assinatura

O certificado de assinatura de mensagens é utilizado para criar o JWS para assinar o payload JWT durante o processo de onboarding e authorization. Atributos específicos do certificado de assinatura:

Algoritmo de criptorgrafia

Tipos de certificados

Requisitos adicionais

• Protocolo HTTP versão 1.1.
• Criptografia TLS versão 1.2 suportando somente as seguintes cifras:
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• Autenticação mútua.
• Algoritmo ECDSA.
• Algoritmo de troca de chaves de curva elíptica ECDHE.
• Criptografia simétrica AES com chave de 128 bits
• MAC com SHA de chaves de 256 bits.

Definições

A ICP-Brasil (Infraestrutura de Chaves Públicas Brasileira) consiste em uma cadeia hierárquica composta por uma autoridade gestora de políticas e autoridades certificadoras que utilizam um conjunto de tecnologias, práticas, técnicas e procedimentos para realizar a transação de documentos eletrônicos com segurança. O objetivo da ICP é fazer com que a utilização de criptografia de chaves públicas se torne mais fácil, tendo como principais componentes as autoridades certificadoras, autoridades de registro e o repositório. Sua hierarquia se dá da seguinte forma:

• 1º. Comitê Gestor (CG);
• 2º. Autoridade Certificadora (AC Raiz);
• 3º. Autoridades Certificadoras de 1º e 2º nível (ACs);
• 4º. Autoridades de Registros (ARs);
• 5º. usuário final.

A validação requer um par de chaves, sendo que uma delas é de conhecimento geral, ou seja, de acesso ao público, e a outra de conhecimento apenas do proprietário. Por isso, seus dados precisam estar contidos em um certificado digital para que seja possível fazer a tramitação do documento.

Além disso, é preciso que a entidade certificadora seja integrante da infraestrutura do governo e receba uma classificação quanto ao seu nível de segurança. Desse modo, é possível garantir a validade jurídica dos documentos eletrônicos, bem como sua autenticidade e integridade.

As Autoridades Certificadoras (ACs) são responsáveis por gerenciar o ciclo de vida dos certificados digitais, controlando os processos de solicitação, emissão e revogação dos mesmos.

A Autoridade de Registro (AR) e o Repositório de Certificados Digitais também recebem tarefas delegadas da AC Raiz. À AR cabe a tarefa de verificar o conteúdo de requisições de certificados, enquanto o Repositório de Certificados Digitais tem como objetivo publicar os certificados digitais e as listas de certificados revogados emitidos por uma ou mais ACs. No Brasil, a hierarquia da Certificação Digital obedece ao ICP-Brasil, que deve ser:

• 1º nível – Autoridades Certificadoras Raiz (AC Raiz): Instituto Nacional de Tecnologia da Informação.
• 2º Nível – Autoridades Certificadoras de primeiro nível: Responsável pela emissão, revogação e gerenciamento dos Certificados Digitais de AC.
• 3º nível – Autoridades Certificadoras de segundo nível: Responsável pela emissão, revogação e gerenciamento dos Certificados Digitais.
• 4º nível – Autoridades de Registro: Responsável por identificar o usuário e solicitar e emitir os certificados.

Após o prazo de encerramento do Certificado Digital, ele é automaticamente expirado e, qualquer documento assinado após a data de vencimento não possui qualquer validade legal. Já os documentos que forem assinados dentro do período de validade do certificado, tem sua validade assegurada por tempo indeterminado.

A Certificação Digital é a tecnologia que permite que as transações eletrônicas sejam realizadas com segurança, por meio de algoritmos matemáticos capazes de garantir que as informações sejam manipuladas com autenticidade, integridade e confiabilidade.

A Assinatura Digital nada mais é que um processo eletrônico que faz uso de chaves criptografadas. De maneira geral, documentos que são assinados digitalmente passam por um processo de codificação das informações eletrônicas, de forma que somente receptor e emissor possam acessar os documentos compartilhados.

O uso do Certificado Digital é utilizado entre outras atividades para validar as transações bancárias on-line. Ou seja, para comprovar a autenticidade do serviço, o banco utiliza um certificado que assegura ao usuário que ele realmente está acessando o servidor do banco. Assim, ao acessar a sua conta bancária, por exemplo, o usuário pode utilizar seu certificado para autenticar-se diante do banco.

Guia das Etapas de Solicitação

Diagrama - Solicitação de um certificado digital.

A obtenção de um Certificado Digital compreende 4 etapas:

1. Solicitação: O interessado (pessoa física ou jurídica) deve acessar uma das Autoridades Certificadoras, escolher o tipo e a validade do Certificado Digital e encaminhar para o processo de compra.
2. Identificação Presencial: Após feita a solicitação, o interessado deve providenciar os documentos necessários para a emissão do certificado escolhido e agendar uma visita presencial em uma das Autoridades de Registro para realizar a identificação.
3. Validação e Verificação dos documentos: Depois de apresentar os documentos obrigatórios, o interessado deve aguardar a liberação da validação e verificação realizadas pela Autoridade de Registro. Caso esteja em conformidade com as exigências, é possível seguir para o processo de emissão.
4. Emissão: Na emissão, é gerado um par de chaves RSA com tamanho de 2048 bits e algoritmo de assinatura SHA 256 na mídia criptográfica do usuário.

Contudo, antes de requerer um Certificado Digital, o interessado deve analisar qual a finalidade de uso, a forma de armazenamento e o período de validade no qual deve obter seu documento para, então, solicitar o tipo de certificado adequado. É imprescindível que o interessado conheça as características de cada certificado antes de comprá-lo pelo site em uma das Autoridades Certificadoras habilitadas.

Emissão de certificados pelo Diretório de Participantes

O Diretório de Participantes foi escolhido como uma alternativa para a emissão de certificados, tornando-se uma Autoridade Certificadora para emissão de certificados para Clients (aplicativos).

Diagrama - Emitindo um certificado pelo Diretório

A obtenção de um Certificado Digital pelo Diretório, compreende 3 etapas:

1. Solicitação: O solicitante deve assinar a solicitação (CSR) utilizando o e-CNPJ e efetuar o upload no Diretório de Participantes.
2. Verificação: O Diretório realiza a verificação, estando em conformidade, prossegue para o processo de emissão.
3. Emissão: O Diretório emite um certificado e retorna para o solicitante.

CSR

Esse bloco consiste em um exemplo de como gerar o Certificate Signing Requests (CSR) para o PKI do Open Banking.
Existem vários utilitários para gerar CSRs para serem enviados a uma autoridade certificadora, neste exemplo vamos utilizar OpenSSL para demonstrar como um CSR válido é gerado para enviar ao Open Banking para emitir um certificado x509 de transporte ou assinatura.
OpenSSL é compatível com Windows ou Linux, podendo ser emitido no sistema operacional preferido:

Gerando CSR de transporte
$ openssl req -new -config transporte.cnf -out transporte.csr -keyout transporte.key

Gerando CSR de assinatura
$ openssl req -new -config assinatura.cnf -out assinatura.csr -keyout assinatura.key

Exemplo:

$ openssl req -new -config /share/ob/transporte.cnf -out transporte.csr -keyout transporte.key
Generating a RSA private key
........................................+++++
............+++++
writing new private key to 'assinatura.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
BR []:BR

O CSR resultante deve ser carregado para o Open Banking PKI para emitir um certificado público de transporte ou assinatura associado à sua chave privada. Os arquivos resultantes devem ser protegidos pelas políticas de segurança da instituição.

Perfil de solicitação de assinatura de certificado X509 de transporte

Este bloco demonstra como gerar um CSR válido por um client que requer um Certificado de transporte X.509 utilizando um arquivo .cnf como base.
O seguinte arquivo de configuração é utilizado para gerar um CSR para um certificado de transporte usando OpenSSL.

Arquivo CNF OPENSSL Transporte apenas de exemplo, as configurações podem variar de acordo com a Autoridade Certificadora e para quem será emitido o certificado, alterar os campos como CNPJ e NOME da instituição:

# OPENSSL CSR REQUEST CONFIGURATION FILE
# ======================================
otherName = 2.16.76.1.3.3
otherName = 2.16.76.1.3.8
#otherName = 2.16.76.1.3.X #OID a ser confirmado com a informação dos endpoints
subjectAltName=@san
#CNPJ
otherName.1=2.16.76.1.3.3;UTF8:64721803000118
#Nome conforme consta no CNPJ
otherName.2=2.16.76.1.3.8;UTF8:Nome da instituicao
#Endpoints
#otherName.3=2.16.76.1.3.X;UTF8:Endpoints
# OpenSSL may not recognize this OID so need to add.
[ req ]
default_bits = 2048
#ou
#default_bits = 4096
# RSA key size
encrypt_key = yes
# Protect private key: yes or no. yes recommended
default_md = sha256
# MD to use. sha256 recommended
utf8 = yes
# Input is UTF-8.
string_mask = utf8only
# Emit UTF-8 strings
distinguished_name = client_dn
req_extensions = client_reqext
[ client_dn ]
countryName = "BR"
[ client_reqext ]
keyUsage = critical,digitalSignature
subjectKeyIdentifier = hash
extendedKeyUsage = clientAuth, serverAuth

Perfil de solicitação de assinatura de certificado X509 de assinatura

Este bloco demonstra como gerar um CSR válido por um client que requer um Certificado de assinatura X.509 utilizando um arquivo .cnf como base.
O seguinte arquivo de configuração é utilizado para gerar um CSR para um certificado de assinatura usando OpenSSL.

Arquivo CNF OPENSSL de Assinatura apenas de exemplo, as configurações podem variar de acordo com a Autoridade Certificadora e para quem será emitido o certificado, alterar os campos como CNPJ e NOME da instituição:

# OPENSSL CSR REQUEST CONFIGURATION FILE
# ======================================
otherName = 2.16.76.1.3.3
otherName = 2.16.76.1.3.8
subjectAltName=@san
#CNPJ
otherName.1=2.16.76.1.3.3;UTF8:64721803000118
#Nome conforme consta no CNPJ
otherName.2=2.16.76.1.3.8;UTF8:Nome da instituicao
# OpenSSL may not recognize this OID so need to add.
[ req ]
default_bits = 2048
#ou
#default_bits = 4096
# RSA key size
encrypt_key = yes
# Protect private key: yes or no. yes recommended
default_md = sha256
# MD to use. sha256 recommended
utf8 = yes
# Input is UTF-8.
string_mask = utf8only
# Emit UTF-8 strings
distinguished_name = client_dn
req_extensions = client_reqext
[ client_dn ]
countryName = "BR"
[ client_reqext ]
keyUsage = critical,digitalSignature,nonRepudiation
subjectKeyIdentifier = hash

O arquivo CSR OPENSSL resultante pode ser analisado com o seguinte comando:

$ openssl req -new -config assinatura.cnf -out assinatura.csr -keyout assinatura.key

Diretório de participantes

Introdução

O Diretório de Participantes do Open Banking é o principal componente de arquitetura que permite que instituições provedoras se registrem e iniciem interações por meio de APIs com instituições transmissoras, também fornece um ambiente de testes.
O Diretório é um serviço de gerenciamento de identidade e acesso que fornece informações de identidade que dão suporte aos participantes do Ecossistema do Open Banking.
O Diretório de Participantes disponibiliza os recursos funcionais necessários para que as instituições provedoras possam se autenticar no Open Banking e também recursos para identificar as instituições transmissoras.
O Registro dos Provedores é obrigatório para usar as APIs fornecidas pelas instituições transmissoras.
As instituições transmissoras devem utilizar as informações técnicas contidas no Diretório para realizar o gerenciamento da identidade e da autorização das aplicações das instituições Participantes, que abrange a identificação, a autorização e a revogação de certificados utilizados no compartilhamento de dados e serviços do escopo do Open Banking.

Recursos funcionais do Diretório de Participantes:

• Gerenciar identidades e acesso: a capacidade de emitir e gerenciar registros de identidade para organizações e pessoas físicas que interagem com o Diretório.
• Gerenciar certificados e chaves: A capacidade de fazer upload, gerenciar e remover certificados, chaves de assinatura e chaves de criptografia. A capacidade de emitir, gerenciar e revogar certificados digitais do Open Banking.
• Gerenciar informações do Diretório: a capacidade de atualizar e localizar informações mantidas no diretório - por meio de APIs e/ou uma interface de usuário (IU).

Padrões

• Adoção de padrões abertos
  • O design do Diretório de Participantes do Open Banking será baseado em padrões abertos e amplamente adotados, como API Restful, OpenID Connect e OAuth2.
• Participantes devem estar registrados
  • Os participantes devem ser autorizados e registrados na autoridade competente.
• Uso de certificados
  • Os participantes que possuem um certificado válido podem se registrar no diretório mais rapidamente e sem a necessidade de realizar etapas manuais.

Registro de uma Instituição Provedora

O Diretório deverá realizar validações para o Registro de uma instituição receptora, depois destas validações, solicitações e respostas de API e/ou dados de contas podem ser compartilhadas com segurança entre as duas partes. O diretório deve validar, se:

• A instituição receptora está utilizando um certificado digital.
• O certificado se encontra em conformidade com os padrões do Open Banking Brasil.
• O certificado não está expirado.
• O certificado foi emitido por uma Entidade Emissora válida.
• O certificado não foi revogado.

Depois que todas as verificações forem realizadas, será estabelecido uma conexão TLS segura, mutuamente autenticada entre o Diretório e a instituição receptora.

Funções Operacionais dos Participantes

Fluxos para instituições receptoras

Fluxos para instituições transmissoras

Registro no diretório de participantes

Para poder consumir APIs disponibilizadas por uma instituição transmissora, uma instituição receptora deverá realizar um registro junto a instituição transmissora, esse processo de autenticação do participante deve ser feita de forma centralizada no Diretório de Participantes, sendo necessário a federação do seu portal ao Diretório. A instituição transmissora deve implementar um processo de integração da instituição receptora ao seu sistema, esse processo deve:

• Validar se a instituição receptora é autorizada por uma autoridade competente.
• Validar as informações da instituição receptora.

Após a instituição receptora realizar o registro no Diretório de Participantes, o mesmo poderá realizar o registro de clients (aplicações) na instituição transmissora. Para a realização do registro de clients no Open Banking, é mandatório a disponibilização do processo de registro de Client dinâmico, conforme [RFC 7591].

Registro de Client dinâmico

O registro de Client dinâmico é mandatório para os participantes do Open Banking. Com uma API de registro de client dinâmico do Open Banking, utilizando o padrão de segurança OpenID Connect, as instituições receptoras podem se registrar junto a instituição transmissora.

• Para usar o Registro dinâmico de client, uma instituição receptora deve se registrar no Diretório de Participantes e obter um SSA e demais certificados digitais.
• O Client envia o SSA a uma instituição transmissora para registro dinâmico na instituição transmissora.

O diagrama abaixo mostra o fluxo do registro dinâmico de uma instituição receptora.

Diagrama - Fluxo de registro dinâmico.

As instituições receptoras precisam obter o SSA do Diretório de Participantes do Open Banking.
Uma API de Registro dinâmico consiste em endpoints, que realizam a concessão de credencias do client e a autenticação mútua de TLS para autenticar a instituição receptora. A API deve permitir que as seguintes operações sejam realizadas:

• Registro de um Client.
• Recuperar um Client.
• Atualizar um Client.
• Excluir um Client.

Teste e homologação

A fase de teste e homologação, tem como finalidade, garantir que os participantes que desejam operar no Ecossistema do Open Banking, possam fazer isso de forma assertiva e segura. Isso incluí o suporte para as instituições receptoras com a capacidade de testar seus produtos e serviços desde o lançamento, quanto nas atualizações, fornecendo uma série de ferramentas e infraestrutura no serviço de Diretório para garantir que seus produtos tenham sido testados tempestivamente antes de entrar em produção.
É obrigatório o teste e a homologação para instituição receptora e instituição transmissora. Instituições receptoras devem utilizar o serviço de Sandbox fornecido pelo Diretório.
As instituição transmissoras devem prover um ambiente de teste que possibilite as instituições receptoras autorizados a realizarem testes de conexão e testes funcionais de seus produtos e serviços. Este recurso deve refletir ao máximo o ambiente de produção e deve fornecer o acesso aos desenvolvedores com os seguintes aspectos:

• Funcionalidade: Deve incluir todas as funcionalidades da interface de produção relacionadas aos casos de uso. Deve funcionar de maneira equivalente ou representativa para a interface de produção, incluindo casos de uso negativos e códigos de erro.
• Segurança: Deve utilizar o mesmo perfil de segurança das APIs em produção.
• On-boarding: Deve replicar o processo de on-boarding das instalações de produção da instituição transmissora, incluindo o on-boarding e a troca de certificados para identificação e assinatura de mensagem.
• Certificados: Deve permitir o uso de certificados de teste (que têm o mesmo formato/estrutura dos certificados de produção) de modo que as instituições receptoras possam replicar a funcionalidade relacionados à troca de certificados para identificação e assinatura de mensagens.
• Dados de teste: Não deve incluir quaisquer dados reais de usuários finais. O volume e a variação dos dados devem ser suficientes para dar suporte a todos os testes técnicos e funcionais, incluindo paginação (onde for compatível com a interface dedicada).
• Contas de teste: Deve fornecer para as instituições receptoras um número de contas de teste que habilitem a funcionalidade e o acesso aos dados que os usuários reais experimentarão na produção.
• Autenticação: A instituição transmissora deve fornecer recurso que permita que as instituições receptoras testem os procedimentos de autenticação, inclusive em produção, utilizando suas próprias contas e/ou contas de teste.
• Disponibilidade e desempenho: Não deve lidar com volumes de produção (ou seja, não deve ser usada por instituição transmissora ou instituição receptora para teste de estresse), no entanto, deve ter disponibilidade, capacidade, desempenho e outras características suficientes para facilitar a conexão eficaz e realista a testes funcionais da instituição receptora.
• Suporte: A instalação deve ter um nível apropriado de suporte para permitir a comunicação de problemas ou questões por instituições receptoras para instituições transmissoras e fornecer soluções eficientes e eficazes.
• Documentação: Instituição transmissora devem publicar externamente um resumo das especificações da instalação de teste em seu site, incluindo detalhes de acesso e cobertura de teste.

Os testes devem garantir escopo mínimo para cobrir todos os casos de uso e de requisitos de segurança, evidenciados de forma que seja possível garantir que o processo de homologação foi efetuado.
Os testes para instituições receptoras devem acontecer em 3 etapas:

• Testes de integração: Testes utilizando APIs de um Banco de exemplo no Sandbox do Diretório.
• Testes no Ecossistema: Testes realizados no ecossistema apenas em Sandbox para validar novas funcionalidades ou melhorias.
• Testes de primeira ocorrência: Testes baseados em acordos entre transmissoras e receptoras efetuados no ambiente de produção.

Ainda, recomenda-se que seja feito o teste de conformidade ao FAPI, disponível em https://openid.net/certification/fapi_op_testing/.

CORS

Contexto Open-Data

O Cross-Origin Resource Sharing (CORS) para todas as origens (valor " * ") será permitido nos seguintes endpoints:

• Open Data APIS
  • Canais de Atendimento
  • Produtos e Serviços

Endpoints

Contexto Open-data

Não haverá endpoints específicos para Autorização e Autenticação com o intuito de maximizar o uso do Open-data.

Será opcional a disponibilização de um endpoint para validação WKS:

api.banco.com.br/openbanking/security/v1/.well-known/jwks.json

Glossário de Segurança

Referências normativas

Referências informativas

Problemas conhecidos da especificação

Atualmente não há problemas conhecidos

Guias de implementação

Acesse neste link uma implementação de referência da fase 1.

Esta implementação de exemplo permite ao desenvolvedor realizar testes referentes à fase 1 (open-data) do Open Banking Brasil.

Fase 1 - APIs do Open Banking Brasil v1.0.0

Scroll down for code samples, example requests and responses. Select a language for code samples from the tabs above or the mobile navigation menu.

Base URLs:

• https://api.banco.com.br/open-banking

• https://apih.banco.com.br/open-banking

Email: Governança do Open Banking Brasil - Interfaces Web: Governança do Open Banking Brasil - Interfaces License: Apache 2.0

API - Admin

Obtém as métricas de disponibilidade das APIs

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/admin/v1/metrics");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/admin/v1/metrics", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/admin/v1/metrics")
  .header("Accept", "application/json")
  .asString();

GET /admin/v1/metrics

Visão geral

Este endpoint possibilita ao diretório consultar estatísticas operacionais das APIs disponibilizadas pelas instituições financeiras, a fim de avaliar a qualidade dos serviços fornecidos ao usuário final.

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

Detailed descriptions

period: Período a ser consultado * CURRENT - Métricas do dia atual. * ALL - Métricas de todo o período disponível.

Enumerated Values

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": {
    "requestTime": "2019-08-24T14:15:22Z",
    "availability": {
      "uptime": {
        "generalUptimeRate": "string",
        "endpoints": {
          "url": "string",
          "uptimeRate": "string"
        }
      },
      "downtime": {
        "generalDowntime": 0,
        "scheduledOutage": 0,
        "endpoints": {
          "url": "string",
          "partialDowntime": 0
        }
      }
    },
    "invocations": {
      "unauthenticated": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      },
      "highPriority": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      },
      "mediumPriority": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      },
      "unattended": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      }
    },
    "averageResponse": {
      "unauthenticated": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      },
      "highPriority": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      },
      "mediumPriority": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      },
      "unattended": {
        "currentDay": 0,
        "previousDays": [
          0
        ]
      }
    },
    "averageTps": {
      "currentDay": 0,
      "previousDays": [
        0
      ]
    },
    "peakTps": {
      "currentDay": 0,
      "previousDays": [
        0
      ]
    },
    "errors": {
      "currentDay": 0,
      "previousDays": [
        0
      ]
    },
    "rejections": {
      "currentDay": 0,
      "previousDays": [
        0
      ]
    }
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/admin/v1/<resource>",
    "first": "https://api.banco.com.br/open-banking/admin/v1/<resource>",
    "prev": "string",
    "next": "string",
    "last": "https://api.banco.com.br/open-banking/admin/v1/<resource>"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Resposta

API - Comuns

Obtém a descrição referente ao código de status retornado pelas APIs.

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/discovery/v1/status");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/discovery/v1/status", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/discovery/v1/status")
  .header("Accept", "application/json")
  .asString();

GET /discovery/v1/status

Visão geral

Obtêm a lista de indisponibilidade agendada para os serviços.

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": {
    "status": [
      {
        "code": "OK",
        "explanation": "Retorno com Sucesso",
        "detectionTime": "2020-07-21T08:30:00Z",
        "expectedResolutionTime": "2020-07-21T08:30:00Z",
        "updateTime": "2020-01-02T01:00:00Z",
        "unavailableEndpoints": [
          "https://api.banco.com.br/open-banking/channels/v1/electronic-channels"
        ]
      }
    ]
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/admin/v1/<resource>",
    "first": "https://api.banco.com.br/open-banking/admin/v1/<resource>",
    "prev": "string",
    "next": "string",
    "last": "https://api.banco.com.br/open-banking/admin/v1/<resource>"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Resposta

Obtêm a lista de indisponibilidade agendada para os serviços.

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/discovery/v1/outages");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/discovery/v1/outages", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/discovery/v1/outages")
  .header("Accept", "application/json")
  .asString();

GET /discovery/v1/outages

Visão geral

Obtém a descrição referente ao código de status retornado pelas APIs.

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": [
    {
      "outageTime": "2020-07-21T08:30:00Z",
      "duration": "PT2H30M",
      "isPartial": false,
      "explanation": "Atualização do API Gateway"
    }
  ],
  "links": {
    "self": "https://api.banco.com.br/open-banking/admin/v1/<resource>",
    "first": "https://api.banco.com.br/open-banking/admin/v1/<resource>",
    "prev": "string",
    "next": "string",
    "last": "https://api.banco.com.br/open-banking/admin/v1/<resource>"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Resposta

API - Canais de Atendimento

Obtém a lista de correspondentes bancários da instituição financeira.

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/channels/v1/banking-agents");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/channels/v1/banking-agents", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/channels/v1/banking-agents")
  .header("Accept", "application/json")
  .asString();

GET /channels/v1/banking-agents

Visão geral

Obtém a lista de Correspondentes bancários.

Tags: Correspondente bancário (Banking Agent), CNPJ (CNPJ Number), Marca (Brand) e Instituição Financeira (Company).

Visão de alto de nível das estruturas de dados

Dicionário de dados

Fazer download do dicionário de dados

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": {
    "brand": {
      "name": "Organização A",
      "companies": [
        {
          "name": "Empresa A1",
          "cnpjNumber": "45086338000178",
          "contractors": [
            {
              "name": "Empresa Contratante 1",
              "cnpjNumber": "99558332000137",
              "bankingAgents": [
                {
                  "identification": {
                    "corporationName": "Empresa Correspondente A",
                    "groupName": "Grupo Master",
                    "cnpjNumber": 2345876000299,
                    "isUnderestablishment": true
                  },
                  "locations": [
                    {
                      "postalAddress": {
                        "address": "Av Tasuko Ykeda, 25",
                        "districtName": "Centro",
                        "townName": "Marília",
                        "countrySubDivision": "SP",
                        "postCode": "17500001",
                        "additionalInfo": "Loja B.",
                        "ibgeCode": "3550308",
                        "country": "Brasil",
                        "countryCode": "BRA",
                        "geographicCoordinates": {
                          "latitude": "-90.8365180",
                          "longitude": "-180.836519"
                        }
                      },
                      "phones": [
                        {
                          "type": "FIXO",
                          "countryCallingCode": "55",
                          "areaCode": "14",
                          "number": "35721199"
                        },
                        {
                          "type": "MOVEL",
                          "countryCallingCode": "55",
                          "areaCode": "14",
                          "number": "997865532"
                        }
                      ],
                      "availability": {
                        "standards": [
                          {
                            "weekday": "SEGUNDA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "TERCA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "QUARTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "QUINTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "SEXTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          }
                        ],
                        "exception": "Exceto feriados municipais, estaduais e nacionais",
                        "isPublicAccessAllowed": true
                      }
                    },
                    {
                      "postalAddress": {
                        "address": "R Yroshima Takasi, 72",
                        "districtName": "Altos da Colina",
                        "townName": "Marília",
                        "countrySubDivision": "SP",
                        "postCode": "17526760",
                        "additionalInfo": "Loja 2.",
                        "ibgeCode": "3550308",
                        "country": "Brasil",
                        "countryCode": "BRA",
                        "geographicCoordinates": {
                          "latitude": "-90.8365180",
                          "longitude": "-180.836519"
                        }
                      },
                      "phones": [
                        {
                          "type": "FIXO",
                          "countryCallingCode": "55",
                          "areaCode": "14",
                          "number": "64721199"
                        }
                      ],
                      "availability": {
                        "standards": [
                          {
                            "weekday": "SEGUNDA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "TERCA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "QUARTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "QUINTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "SEXTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          }
                        ],
                        "exception": "Exceto feriados municipais, estaduais e nacionais",
                        "isPublicAccessAllowed": true
                      }
                    },
                    {
                      "postalAddress": {
                        "address": "Al Nasso Origami, 15, bloco A",
                        "districtName": "Centro",
                        "townName": "Marília",
                        "countrySubDivision": "SP",
                        "postCode": "17500001",
                        "additionalInfo": "Loja B.",
                        "ibgeCode": "3550308",
                        "country": "Brasil",
                        "countryCode": "BRA",
                        "geographicCoordinates": {
                          "latitude": "-90.8365180",
                          "longitude": "-180.836519"
                        }
                      },
                      "availability": {
                        "standards": [
                          {
                            "weekday": "SEGUNDA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "TERCA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "QUARTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "QUINTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          },
                          {
                            "weekday": "SEXTA_FEIRA",
                            "openingTime": "10:00:57Z",
                            "closingTime": "16:00:57Z"
                          }
                        ],
                        "exception": "Exceto feriados municipais, estaduais e nacionais",
                        "isPublicAccessAllowed": true
                      }
                    }
                  ],
                  "services": [
                    {
                      "name": "RECEPCAO_ENCAMINHAMENTO_PROPOSTAS_ABERTURA_CONTAS_DEPOSITOS_VISTA_PRAZO_POUPANCA_MANTIDOS_INSTITUICAO_CONTRATANTE",
                      "code": "RECEBE_ENCAMINHA_PROPOSTAS_ABERTURA_CONTAS",
                      "additionalInfo": "NA"
                    },
                    {
                      "name": "REALIZACAO_RECEBIMENTOS_PAGAMENTOS_TRANSFERENCIAS_ELETRONICAS_VISANDO_MOVIMENTACAO_CONTAS_DEPOSITOS_TITULARIDADE_CLIENTES_MANTIDAS_INSTITUICAO_CONTRATANTE",
                      "code": "REALIZA_RECEBIMENTOS_PAGAMENTOS_TRANSFERENCIAS_ELETRONICAS",
                      "additionalInfo": "NA"
                    },
                    {
                      "name": "RECEBIMENTOS_PAGAMENTOS_QUALQUER_NATUREZA_OUTRAS_ATIVIDADES_DECORRENTES_EXECUCAO_CONTRATOS_CONVENIOS_PRESTACAO_SERVICOS",
                      "code": "RECEBIMENTOS_PAGAMENTOS_QUALQUER_NATUREZA_EXECUCAO_CONTRATOS_CONVENIO",
                      "additionalInfo": "NA"
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/channels/v1/banking-agents",
    "first": "https://api.banco.com.br/open-banking/channels/v1/banking-agents",
    "prev": "null",
    "next": "null",
    "last": "https://api.banco.com.br/open-banking/channels/v1/banking-agents"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Resposta

Obtém a lista de dependências próprias da instituição financeira.

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/channels/v1/branches");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/channels/v1/branches", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/channels/v1/branches")
  .header("Accept", "application/json")
  .asString();

GET /channels/v1/branches

Visão geral

Obtém a lista de dependências próprias da instituição financeira.

Dependência própria é o espaço físico destinado ao atendimento ao público.

Tags: Agência (Branch), CNPJ (CNPJ Number), Marca (Brand), Dependência (Branch), Instituição Financeira (Company), Posto de Atendimento Bancário - PAB (Branch), Posto de Atendimento Eletrônico – PAE (Branch) e Unidade Administrativa Desmembrada – UAD (Branch).

Visão de alto de nível das estruturas de dados

Dicionário de dados

Fazer download do dicionário de dados

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": {
    "brand": {
      "name": "Organização A",
      "companies": [
        {
          "name": "Empresa A1",
          "cnpjNumber": "45086338000178",
          "urlComplementaryList": "https://empresaa1.com/branches-banking",
          "branches": [
            {
              "identification": {
                "type": "AGENCIA",
                "code": "0001",
                "checkDigit": "9",
                "name": "Marília",
                "relatedBranch": "0001",
                "openingDate": "2010-01-02"
              },
              "postalAddress": {
                "address": "Av Naburo Ykesaki, 1270",
                "additionalInfo": "Loja B",
                "districtName": "Centro",
                "townName": "Marília",
                "ibgeCode": "3550308",
                "countrySubDivision": "SP",
                "postCode": "17500-001",
                "country": "Brasil",
                "countryCode": "BRA",
                "geographicCoordinates": {
                  "latitude": "-90.8365180",
                  "longitude": "-180.836519"
                }
              },
              "availability": {
                "standards": [
                  {
                    "weekday": "SEGUNDA_FEIRA",
                    "openingTime": "10:00:57Z",
                    "closingTime": "16:00:57Z"
                  },
                  {
                    "weekday": "TERCA_FEIRA",
                    "openingTime": "10:00:57Z",
                    "closingTime": "16:00:57Z"
                  },
                  {
                    "weekday": "QUARTA_FEIRA",
                    "openingTime": "10:00:57Z",
                    "closingTime": "16:00:57Z"
                  },
                  {
                    "weekday": "QUINTA_FEIRA",
                    "openingTime": "10:00:57Z",
                    "closingTime": "16:00:57Z"
                  },
                  {
                    "weekday": "SEXTA_FEIRA",
                    "openingTime": "10:00:57Z",
                    "closingTime": "16:00:57Z"
                  }
                ],
                "exception": "Exceto feriados municipais, estaduais e nacionais",
                "isPublicAccessAllowed": true
              },
              "phones": [
                {
                  "type": "FIXO",
                  "countryCallingCode": "55",
                  "areaCode": "14",
                  "number": "35721199"
                },
                {
                  "type": "MOVEL",
                  "countryCallingCode": "55",
                  "areaCode": "14",
                  "number": "997865532"
                }
              ],
              "services": [
                {
                  "name": "RECEBIMENTOS_PAGAMENTOS_QUALQUER_NATUREZA",
                  "code": "RECEBE_PAGA_QUALQUER_NATUREZA"
                },
                {
                  "name": "OUTROS_PRODUTOS_SERVICOS",
                  "code": "OUTROS_PRODUTOS_SERVICOS",
                  "additionalInfo": "Renegociação"
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/channels/v1/branches",
    "first": "https://api.banco.com.br/open-banking/channels/v1/branches",
    "prev": "null",
    "next": "null",
    "last": "https://api.banco.com.br/open-banking/channels/v1/branches"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Resposta

Obtém a lista de canais eletrônicos de atendimento da instituição financeira.

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/channels/v1/electronic-channels");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/channels/v1/electronic-channels", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/channels/v1/electronic-channels")
  .header("Accept", "application/json")
  .asString();

GET /channels/v1/electronic-channels

Visão geral

Obtém a lista de canais eletrônicos próprios da instituição financeira.

Esse endpoint retorna os possíveis canais de atendimento eletrônico, bem como suas informações, serviços prestados e formas de acesso.

Tags: CNPJ (CNPJ Number), Marca (Brand) e Instituição Financeira (Company).

Visão de alto nível das estruturas de dados

Dicionário de dados

Fazer download do dicionário de dados

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": {
    "brand": {
      "name": "Organização A",
      "companies": [
        {
          "name": "Empresa A1",
          "cnpjNumber": "45086338000178",
          "urlComplementaryList": "https://empresaa1.com/branches-banking",
          "electronicChannels": [
            {
              "identification": {
                "type": "INTERNET_BANKING",
                "additionalInfo": "NA",
                "urls": [
                  "https://empresaa1.com/internet-banking"
                ]
              },
              "services": [
                {
                  "name": "ABERTURA_CONTAS_DEPOSITOS_OU_PAGAMENTO_PRE_PAGA",
                  "code": "ABRE_CONTA_DEPOSITO_OU_PRE_PAGA",
                  "additionalInfo": "NA"
                },
                {
                  "name": "SEGUROS",
                  "code": "SEGUROS",
                  "additionalInfo": "NA"
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/channels/v1/electronic-channels",
    "first": "https://api.banco.com.br/open-banking/channels/v1/electronic-channels",
    "prev": "null",
    "next": "null",
    "last": "https://api.banco.com.br/open-banking/channels/v1/electronic-channels"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

Resposta

Obtém a lista de canais telefônicos de atendimento da instituição financeira.

Exemplo de código

const data = null;

const xhr = new XMLHttpRequest();
xhr.withCredentials = true;

xhr.addEventListener("readystatechange", function () {
  if (this.readyState === this.DONE) {
    console.log(this.responseText);
  }
});

xhr.open("GET", "https://api.banco.com.br/open-banking/channels/v1/phone-channels");
xhr.setRequestHeader("Accept", "application/json");

xhr.send(data);

import http.client

conn = http.client.HTTPSConnection("api.banco.com.br")

headers = { 'Accept': "application/json" }

conn.request("GET", "/open-banking/channels/v1/phone-channels", headers=headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

HttpResponse<String> response = Unirest.get("https://api.banco.com.br/open-banking/channels/v1/phone-channels")
  .header("Accept", "application/json")
  .asString();

GET /channels/v1/phone-channels

Visão geral

Obtém a lista de canais telefônicos próprios da instituição financeira.

Esse endpoint retorna os possíveis canais de atendimento telefônico bem como suas informações, serviços prestados e formas de acesso.

Tags: CNPJ (CNPJ Number), Marca (Brand) e Instituição Financeira (Company).

Visão de alto nível das estruturas de dados

Dicionário de dados

Fazer download do dicionário de dados

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Parâmetros

O comando acima retorna uma estrutura json como essa:

200 Response

{
  "data": {
    "brand": {
      "name": "Organização A",
      "companies": [
        {
          "name": "Empresa A1",
          "cnpjNumber": "45086338000178",
          "urlComplementaryList": "https://empresaa1.com/branches-banking",
          "phoneChannels": [
            {
              "identification": {
                "type": "CENTRAL_TELEFONICA",
                "phones": [
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "35721199",
                    "additionalInfo": "NA"
                  },
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "997865532",
                    "additionalInfo": "NA"
                  }
                ]
              },
              "services": [
                {
                  "name": "ABERTURA_CONTAS_DEPOSITOS_OU_PAGAMENTO_PRE_PAGA",
                  "code": "ABRE_CONTA_DEPOSITO_OU_PRE_PAGA"
                },
                {
                  "name": "RECEBIMENTOS_PAGAMENTOS_QUALQUER_NATUREZA",
                  "code": "RECEBE_PAGA_QUALQUER_NATUREZA"
                },
                {
                  "name": "OUTROS_PRODUTOS_SERVICOS",
                  "code": "OUTROS_PRODUTOS_SERVICOS",
                  "additionalInfo": "Atendimento em outros idiomas"
                }
              ]
            },
            {
              "identification": {
                "type": "SAC",
                "phones": [
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "40044828",
                    "additionalInfo": "DDI '55'; DDD '11', 40044828, 'Para clientes no exterior'"
                  },
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "40044828",
                    "additionalInfo": "DDI ' ', DDD ' ', 40044828, 'Para regiões metropolitanas'"
                  },
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "40044828",
                    "additionalInfo": "DDI ' ', DDD ' ', 40044828, 'Para demais localidades'"
                  }
                ]
              },
              "services": [
                {
                  "name": "RECLAMACOES",
                  "code": "RECLAMACOES"
                },
                {
                  "name": "INFORMACOES",
                  "code": "INFORMACOES"
                },
                {
                  "name": "CANCELAMENTO",
                  "code": "CANCELAMENTO"
                }
              ]
            },
            {
              "identification": {
                "type": "OUVIDORIA",
                "phones": [
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "40045555",
                    "additionalInfo": "DDI '55'; DDD '11', 40045555, 'Para clientes no exterior'"
                  },
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "40045555",
                    "additionalInfo": "DDI ' ', DDD ' ', 40045555, 'Para regiões metropolitanas'"
                  },
                  {
                    "countryCallingCode": "55",
                    "areaCode": "14",
                    "number": "40045555",
                    "additionalInfo": "DDI ' ', DDD ' ', 40045555, 'Para demais localidades'"
                  }
                ]
              },
              "services": [
                {
                  "name": "RECLAMACOES",
                  "code": "RECLAMACOES"
                },
                {
                  "name": "INFORMACOES",
                  "code": "INFORMACOES"
                }
              ]
            },
            {
              "identification": {
                "type": "OUTROS",
                "additionalInfo": "Receptivo",
                "phones": [
                  {
                    "countryCallingCode": "55",
                    "areaCode": "NA",
                    "number": "40043277",
                    "additionalInfo": "DDI '55'; DDD '11', 40043277, 'Para clientes no metropolitanas'"
                  },
                  {
                    "countryCallingCode": "NA",
                    "areaCode": "NA",
                    "number": "40043277",
                    "additionalInfo": "DDI ' ', DDD ' ', 40043277, 'Para regiões localidades'"
                  }
                ]
              },
              "services": [
                {
                  "name": "OUTROS_PRODUTOS_SERVICOS",
                  "code": "OUTROS_PRODUTOS_SERVICOS",
                  "additionalInfo": "Previdência Privada"
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/channels/v1/phone-channels",
    "first": "https://api.banco.com.br/open-banking/channels/v1/phone-channels",
    "prev": "null",
    "next": "null",
    "last": "https://api.banco.com.br/open-banking/channels/v1/phone-channels"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}