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.

Notificações

Informes

Confira as últimas atualizações da Estrutura de Governança do Open Banking Brasil.

Open Banking Informa #1 - 31/05/21 – download
Open Banking Informa #2 - 07/06/21 – download
Open Banking Informa #3 - 09/06/21 – download
Open Banking Informa #4 - 11/06/21 – download
Open Banking Informa #5 - 14/06/21 – download
Open Banking Informa #6 - 15/06/21 – download
Open Banking Informa #7 - 17/06/21 – download
Open Banking Informa #8 - 21/06/21 – download
Open Banking Informa #9 - 22/06/21 – download
Open Banking Informa #10 - 24/06/21 – download
Open Banking Informa #11 - 25/06/21 – download
Open Banking Informa #12 - 28/06/21 – download
Open Banking Informa #13 - 30/06/21 – download
Open Banking Informa #14 - 02/07/21 – download
Open Banking Informa #15 - 03/07/21 – download
Open Banking Informa #16 - 07/07/21 – download
Open Banking Informa #17 - 08/07/21 – download
Open Banking Informa #18 - 09/07/21 – download
Open Banking Informa #19 - 13/07/21 – download
Open Banking Informa #20 - 13/07/21 – download
Open Banking Informa #21 - 14/07/21 – download
Open Banking Informa #22 - 15/07/21 – download
Open Banking Informa #23 - 16/07/21 – download
Open Banking Informa #24 - 20/07/21 – download
Open Banking Informa #25 - 23/07/21 – download
Open Banking Informa #26 - 24/07/21 – download
Open Banking Informa #27 - 26/07/21 – download
Open Banking Informa #28 - 27/07/21 – download
Open Banking Informa #29 - 28/07/21 – download
Open Banking Informa #30 - 30/07/21 – download
Open Banking Informa #31 - 02/08/21 – download
Open Banking Informa #32 - 05/08/21 – download
Open Banking Informa #33 - 06/08/21 – download
Open Banking Informa #34 - 07/08/21 – download
Open Banking Informa #35 - 10/08/21 – download
Open Banking Informa #36 - 11/08/21 – download
Open Banking Informa #38 - 12/08/21 – download
Open Banking Informa #39 - 13/08/21 – download
Open Banking Informa #40 - 16/08/21 – download
Open Banking Informa #41 - 17/08/21 – download
Open Banking Informa #42 - 18/08/21 – download
Open Banking Informa #43 - 20/08/21 – download
Open Banking Informa #44 - 24/08/21 – download
Open Banking Informa #45 - 26/08/21 – download
Open Banking Informa #46 - 27/08/21 – download
Open Banking Informa #47 - 30/08/21 – download
Open Banking Informa #48 - 31/08/21 – download

Workshops com OpenID Foundation

Publicado em 26 de maio de 2021

A OpenID Foundation promoveu dois workshops para os participantes do Open Banking Brasil sobre o perfil de segurança FAPI e o conjunto de testes de conformidade e certificação FAPI.

Os workshops tiveram 5 objetivos principais:

• Atualizar os participantes dos últimos desenvolvimentos no perfil OIDF Financial-Grade API (FAPI) e nos requisitos brasileiros;

• Demonstrar as respectivas ferramentas de conformidade e os benefícios da certificação;

• Oferecer aos participantes apoio no uso dessas ferramentas;

• Incentivar um maior número de certificações;

• Ajudar a expandir o ecossistema de Open Banking, aumentando a segurança e os benefícios para os participantes e clientes finais.

No dia 17 de maio de 2021 foi realizado o primeiro workshop, que consistiu em uma introdução à OpenID Foundation, padrões OpenID incluindo FAPI e o programa de certificação OpenID. A gravação do workshop pode ser acessada pelo link

No dia 24 de maio de 2021 foi realizado o segundo workshop, que possuiu um aprofundamento mais técnico. Neste workshop, foi abordado o detalhamento das características do FAPI, incluindo o FAPI 2.0, e uma demonstração abrangente do pacote de conformidade FAPI, incluindo uma demonstração ao vivo de uma implementação FAPI. A gravação do workshop pode ser acessada pelo link

Atualização das APIs no diretório

Publicado em 14 de abril de 2021

Seguindo determinação do Banco Central do Brasil, todas as instituições financeiras vinculadas à Fase 1 do Open Banking deverão especificar todas as ramificações (endpoints) de suas famílias de APIs no diretório de participantes do Open Banking. Essa atualização deverá ser feita em até 15 dias a partir da data de envio deste documento.

Na prática, as instituições deverão excluir a entrada que já existe no diretório de participantes e incluir cada uma das ramificações que entenda serem válidas para o seu próprio caso.

Tratam-se de 4 famílias de APIs, com até 20 ramificações no total. Essa atualização proporcionará mais transparência ao consumidor, que terá mais facilidade para localizar as informações das instituições. A ação também evitará distorções nas métricas de disponibilidade de interfaces, já que as instituições não deverão cadastrar endpoints relativos a dependências ou a produtos e serviços que não tenham, não ofertem ou não distribuam.

Dessa maneira, a mensagem de erro 404 não será mais exibida nestes casos. Até o dia 16 de abril de 2021, uma FAQ com as principais dúvidas será disponibilizada, assim como um manual com passo a passo para a atualização das APIs.

São Paulo, 14 de abril de 2021

Grupo de Trabalho de Infraestrutura do Open Banking Brasil

Como realizar a publicação das APIs da Fase 1 do Open Banking

Publicado em 14 de abril de 2021

Para a primeira fase do Open Banking Brasil, conhecida como Open Data, as instituições registradas no ecossistema com o papel “instituição transmissora e receptora de dados” deverão realizar a publicação das suas APIs no diretório de participantes.

O papel “instituição transmissora e receptora de dados”, abreviada por DADOS no diretório de participantes, é destinado a todas as instituições dos agrupamentos S1 e S2, em caráter obrigatório, e a qualquer outra instituição regulada pelo Banco Central do Brasil, em caráter voluntário.

Para publicar as APIs da fase 1 descritas no Portal do Desenvolvedor do Open Banking o administrador da instituição no diretório de participantes com papel “DADOS” deve seguir as instruções contidas no Guia do diretório.

Caso a publicação tenha sido realizada de forma correta os endpoints das APIs poderão ser consultados através do JSON retornado pela API de participantes do diretório: https://data.directory.openbankingbrasil.org.br/participants. O acesso a essa API é livre e seu conteúdo é atualizado a cada 15 minutos.

Qualquer dúvida em relação ao processo de cadastro deverá ser enviado ao service desk do Open Banking.

Materiais adicionais:

Comunicado atualização do diretório

FAQ Diretório atualizado

Cadastro endpoints

Guia de Experiência de Compartilhamento de Dados e Iniciação de Pagamento

Esse guia é parte integrante do regulamento do Open Banking no Brasil e engloba um conjunto de requisitos mínimos que devem ser seguidos pelas instituições participantes com o objetivo de nortear a sua implantação e garantir uma experiência adequada e padronizada ao cliente, com foco na jornada do usuário para compartilhamento de dados e iniciação de pagamento.

Direcionado às instituições participantes do Open Banking no Brasil, o guia de experiência apresenta princípios, diretrizes, referências, requisitos obrigatórios e recomendações para a criação da jornada do usuário para compartilhamento de dados e iniciação de pagamento.

As recomendações podem ser seguidas para complementar a experiência, porém funcionalidades não previstas nesse documento serão aceitas, desde que atendam aos princípios e às diretrizes da regulamentação em vigor.

Cada caso de uso é acompanhado de telas ilustrativas para facilitar a compreensão do texto que não implicam em obrigatoriedade para o desenvolvimento das interfaces.

O guia v3.03.02 pode ser baixado nesse link (OpenBanking - Guia de Experiência do Usuário para Compartilhamento de Dados e Iniciação de Pagamento).

Definições para o Lançamento Escalonado da fase 2

Retorno para pedidos fora da janela de funcionamento

Chamadas às interfaces de compartilhamento de dados, fora dos horários estipulados de cada ciclo, conforme IN 136, deve retornar HTTP Status Code 425.

Clientes para o cálculo do número de consentimentos

O cálculo porcentual seria feito sobre o total de clientes (considerando pessoas naturais e jurídicas), seguindo a mesma regra do envio da base de clientes ao BCB.

Base de clientes elegíveis

Para o cálculo do percentual de clientes elegíveis em cada ciclo do lançamento escalonado, a instituição participante deve considerar a base total de clientes, a qual já é comunicado mensalmente ao Banco Central.

Deve ser considerada a última data disponível de referência para o levantamento do número total de clientes, com base nos números comunicados ao BCB. (Utilizar 30/05 como base para cálculo dos percentuais de todos os 4 ciclos do lançamento escalonado da Fase 2).

Código de retorno para pedidos de consentimento para a transmissora que já atingiu o limite de consentimentos

Caso a transmissora já tenha atingido o limite de consentimentos permitidos no ciclo, a solicitação do consentimento deve retornar erro HTTP Status Code 429.

Devolução de mensagem padronizada

Quando a receptora receber o erro da transmissora, de que o limite de consentimentos do ciclo foi atingido, deve ser exibida ao cliente uma mensagem padronizada:

No momento, a instituição de origem dos dados não poderá atender esta solicitação, pois atingiu os limites de compartilhamentos estabelecidos. O Open Banking está sendo disponibilizado gradualmente para garantir um sistema seguro e estável. (Recomendação para que a Instituição Receptora sugira o que fazer, ex.: call to action)

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 alvo da 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.

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.

Princípio 10: Idempotência

As 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 de perda de comunicação e não deve se limitar aos verbos HTTP, devendo ser aplicado ao design completo da API.

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 mais abaixo. Observação: com a implementação do cadastro por endpoint no diretório de participantes e conforme orientação do regulador, as instituições participantes NÃO DEVEM cadastrar endpoints de produtos ou serviços que não ofertem. Neste caso específico - a consulta em um endpoint não cadastrado - o status code esperado na resposta é o 404 - NOT FOUND.

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 devem ter uma marcação de restrição vinculada a eles na documentação da API (Swagger), no campo 'description'. Esses atributos terão a coluna 'Mandatoriedade' preenchida como 'Condicional', além de terem a situação descrita na coluna 'Restrições' 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 navegaçã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".

Princípios para a formação de IDs (identificadores) de recursos nas APIs

• O ID DEVE ser uma string com limitação de 100 caracteres - limite que poderá ser revisitado em caso de necessidade apresentada por quaisquer dos participantes do Open Banking Brasil e - aderente aos padrões apresentados na seção 2.1 da RFC 2141;
• Uma vez que será trafegado nas chamadas de interface, o ID NÃO DEVE conter dados classificados como PII - Personally identifiable information (Informação Pessoalmente Identificável) ou Informação de Identificação Pessoal;
• DEVE ser garantida a unicidade do ID dentro do contexto da API assim como a estabilidade do mesmo, sendo a estabilidade condicionada à manutenção das características de identificação natural do recurso em questão (por exemplo, as informações de banco, agência e conta na API de Contas). A alteração das características de identificação natural implica na geração de um novo identificador associado ao recurso;
• A utilização de meios técnicos razoáveis e disponíveis para a formação do ID é de livre implementação por parte da instituição transmissora dos dados, de forma que apenas a aderência aos princípios elencados nesta documentação é mandatória.

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:

Guia do usuário: Instituição Transmissora

Este guia visa fornecer às instituições transmissoras de dados o passo a passo para implementação de aplicações de acordo com o framework do Open Banking Brasil. Os detalhes deste guia podem ser consultados nos endereços:

https://openbanking-brasil.github.io/specs-seguranca/aspsp-user-guide-ptbr.html (em português)

https://openbanking-brasil.github.io/specs-seguranca/aspsp-user-guide.html (em inglês)

Guia do usuário: Instituição Receptora ou Iniciadora de Pagamentos

Este guia visa fornecer às instituições receptoras de dados ou iniciadores de pagamentos o passo a passo para implementação de aplicações de acordo com o framework do Open Banking Brasil. Os detalhes deste guia podem ser consultados nos endereços:

https://openbanking-brasil.github.io/specs-seguranca/tpp-user-guide-ptbr.html (em português)

https://openbanking-brasil.github.io/specs-seguranca/tpp-user-guide.html (em inglês)

Dynamic Client Registration

O Dynamic Client Registration é mandatório para os participantes do Open Banking.

Os detalhes das especificações devem ser consultadas nos endereços:

https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1-ptbr.html (em português).

https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-dynamic-client-registration-1_ID1.html (em inglês).

FAPI Security Profile 1.0

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.

Os detalhes das especificações devem ser consultadas nos endereços:

https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID2-ptbr.html (em português)

https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-financial-api-1_ID2.html (em inglês)

Padrão de Certificados

O padrão de certificados necessários para o Open Banking Brasil devem ser utilizados por seus participantes para garantir interoperabilidade para autenticação, confidencialidade, integridade e não repúdio entre as entidades participantes, bem como para os usuários e consumidores destas entidades.

Os detalhes das especificações devem ser consultadas no endereço https://openbanking-brasil.github.io/specs-seguranca/open-banking-brasil-certificate-standards-1_ID1.html.

Assinaturas

Sobre os certificados exigidos para assinatura de mensagens - Padrões de certificados digitais Open Banking Brasil: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-certificate-standards-1_ID1.md#certificado-de-assinatura-certificadoassinatura

Sobre os algoritmos usados para assinatura de mensagens JWS - Perfil de segurança FAPI - Open Banking Brasil: https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/open-banking-brasil-financial-api-1_ID1.md#algorithm-considerations

Sobre mensagens assinadas, JWS e JWKS - Guia de usuário (Receptoras e iniciadoras de pagamento): https://github.com/OpenBanking-Brasil/specs-seguranca/blob/main/tpp-user-guide.md#143-what-is-a-jwt-jwe-jws-and-jwk

Casos de Erro

A convenção do Open Banking Brasil mapeou alguns erros esperados durante o fluxo do usuário no ecossistema. Existem orientações especificas já tratadas no Manual do Usuário. Aqui, trataremos a visão mais técnica do que pode ser feito em caso de erro.

• Durante o redirecionamento do Consentimento, não se encontrou o browser no dispositivo do usuário: Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo consentimento para tentar novamente a autorização do usuário.
• Durante o redirecionamento do Consentimento, houve um problema inesperado no servidor do Transmissor (HTTP Code 4xx ou 5xx): Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo consentimento para tentar novamente a autorização do usuário.
• Durante o redirecionamento do Consentimento, houve um problema inesperado no servidor do Transmissor (Timeout, queda de Internet, etc): Além da orientação do usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo consentimento para tentar novamente a autorização do usuário.
• Durante o redirecionamento do Consentimento, houve um problema com o Login do usuário (erro de credenciais): Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo consentimento para tentar novamente a autorização do usuário.
• Após o consentimento do lado do Receptor, o usuário não confirma o compartilhamento: Além da orientação ao usuário, deve-se perceber que o fluxo de Consentimento continua pendente. Como a intenção de consentimento segue válida por 60 minutos, deve-se tentar utilizar o mesmo consentimento para tentar novamente a autorização do usuário.
• Após o consentimento completo, o app do Receptor não consegue acessar os dados por indisponibilidade: Deve-se tentar novamente. Access Token ainda é válido, portanto deve-se tentar novamente sem maiores prejuízos técnicos.
• Após o consentimento completo, o app do Receptor não consegue acessar os dados por pendência de autorização de um terceiro (ex.: Dupla alçada): Deve-se consultar a API de Resources para verificar as pêndencias e saber como proceder.

Redirecionamento App-to-app

O redirecionamento 'App-to-App' permite que a Instituição Receptora redirecione um usuário do seu aplicativo (em um navegador ou app) para o App da Instituição Transmissora, instalado no dispositivo do usuário. Nesse caso, a receptora é capaz de transmitir detalhes de sua solicitação junto com as preferências do usuário (por exemplo, tipo de produto, one-step authentication, etc) e ligar diretamente o seu usuário à tela ou função de login do aplicativo da transmissora, através de um deep-link. O usuário é então autenticado no aplicativo usando as mesmas credenciais/métodos normalmente usados quando ele acessa diretamente sua conta. Isso não deve envolver nenhuma etapa adicional (como, por exemplo, ser redirecionado primeiro para uma página da web para selecionar qual aplicativo da instituição transmissora usar) e não deve exigir que o usuário forneça qualquer identificador ou outras credenciais diferentes das já exigidas pela Instituição Transmissora em seu App. Quando o usuário não tem o App da transmissora, eles devem experimentar um fluxo de redirecionamento que também não deve envolver etapas adicionais do que seria o caso quando ele autentica diretamente na transmissora (por exemplo, ser redirecionado para o site mobile da transmissora).

Como funciona o fluxo de redirecionamento

Ao usar um serviço baseado no padrão de APIs Open Banking Brasil para redirecionamento, o usuário será redirecionado duas vezes:

1. Da interface instituição receptora para a interface da transmissora (para autenticar e autorizar). O URI do servidor de autorização é especificado por cada transmissora em seu endpoint conhecido.

2. Na volta da interface da transmissora para a interface da receptora (para completar qualquer operação com a receptora). Este redirecionamento é especificado pela receptora como parte do primeiro redirecionamento.

Implementação de deep links

Uma jornada perfeita para o usuário, que ignora o navegador integrado (por exemplo, Safari) em seu dispositivo mobile, pode ser implementada para qualquer URL, ou seja, ambos: a) para o redirecionamento inicial para o qual a transmissora envia o usuário para os servidores da transmissora, E b) a URL de redirecionamento para o qual a transmissora envia o usuário de volta para a receptora após a autenticação/autorização.

Tanto transmissoras quanto receptoras devem seguir as orientações da Apple e do Google abaixo:

• iOS: https://developer.apple.com/ios/universal-links/ (cobre mais de 99% de todos os usuários iOS, que estão no iOS 9 ou superior).

• Android: https://developer.android.com/training/app-links/index.html (cobre 65% de todos os usuários do Android, que estão no Android 6.0 ou posterior).

No caso de um usuário não ter o aplicativo instalado em seu dispositivo, ou se ele tiver um sistema operacional mais antigo ou sem suporte (por exemplo, Windows Mobile), esses métodos permitirão que o usuário seja redirecionado para uma página web mobile.

Glossário de Segurança

Referências normativas

Referências informativas

Certificação de Conformidade

Diretrizes técnicas de certificação de conformidade

Para a segunda fase do Open Banking Brasil, as instituições financeiras dos segmentos S1 e S2 e as que se voluntariaram para participar como “instituição transmissora e receptora de dados”, abreviada por DADOS no diretório de participantes, deverão realizar a certificação de conformidade dos seus Authorization Servers, conforme resolução do BACEN, antes de iniciarem o envio dos dados de usuários.

O motor de conformidade de segurança da OIDF foi publicado em versão beta com os perfis FAPI Advanced – Brasil e DCR- Brasil, já sendo possível as Instituições realizarem testes de segurança nas suas implementações. O início da certificação de conformidade com esse plano de testes será realizado a partir 28/06.

O motor de conformidade funcional do Sandbox foi publicado em versão beta com os testes para as APIs da Fase 2, já sendo possível as Instituições realizarem testes de funcionais nas suas implementações.

O cronograma de certificação será da seguinte forma:

Cronograma de certificação

É importante ressaltar que a certificação de conformidade é necessária para a publicação das APIs no ambiente produtivo, sendo assim mandatórios para o go-live da Fase 2.

Para suportar as instituições na obtenção do certificado de conformidade disponibilizamos o seguinte guia:

Guia de certificação de conformidade

Informamos que o guia está em processo contínuo de atualização, podendo sofrer alterações.

Workshops:

Para demonstração dos motores de testes de conformidade funcional e de segurança foram realizados os seguintes workshops:

• 1° Workshop com OpenID Foundation (17/05/2021)
• 2° Workshop com OpenID Foundation (24/05/2021)
• 3° Workshop com OpenID Foundation - Motor de certificação de segurança
• 1° Workshop ferramenta de certificação funcional (15/06/2021)

FAQ

A F.A.Q. relativa à política de conformidade pode ser acessada por meio do link a seguir F.A.Q – Testes e Homologação.

Diretrizes técnicas do diretório

Guia Operacional do Diretório Central

Este guia serve para orientar os participantes a atuar no Diretório Central em procedimentos necessários para a operação no Open Banking Brasil.

Destina-se a administradores, contatos técnicos primários e secundários.

Aqui estão descritas as etapas técnicas para cadastrar usuários, criar e manter declarações de software, tokens de acesso e servidores de autorização no ambiente de sandbox e produção do Diretório Central.

O documento está estruturado nas seguintes seções:

1. Introdução
2. Registrando um usuário no Diretório
3. Acessando uma Organisation
4. Cadastrando contatos de notificação
5. Cadastrando reivindicações de domínio de autoridade
6. Cadastrando reivindicações de autoridade
7. Cadastrando um Authorisation Server
8. Cadastrando Recursos de uma API
9. Criando um Software Statements
10. Criando uma nova reivindicação de autoridade de software
11. Criando certificados de transporte e assinatura em Sandbox
12. Carregando certificados emitidos por autoridade de certificação em Produção
13. Cadastrando administradores da organização
14. Obtendo um Software Statements Assertion
15. Configurando eventos de notificação no Diretório
16. Obtendo um token de acesso para as APIs do Diretório
17. Listando as organizações cadastradas no Diretório via API
18. Listando os servidores de autorização de uma organização via API
19. Obtendo um Software Statement via API
20. Obtendo um Software Statement Assertion via API
21. Suporte
22. Anexos

O guia pode ser baixado nesse link (OpenBanking - Guia de operação do diretório central).

Especificações de APIs do Diretório e do Service Desk

APIs Diretório

O Diretório Central do Open Banking Brasil pode ser acessado tanto via interface gráfica quanto por meio de integração por APIs.

Para acessar as APIs do Diretório, verifique o item 10 do guia operacional do Diretório Central - “Obtendo um token de acesso para acessar as APIs do Diretório”. O guia está disponível na sessão “Diretrizes técnicas do Diretório”.

Para entender como usar cada API, leia a especificação do Swagger da API do Diretório disponível nesse link (https://github.com/OpenBanking-Brasil/specs-directory/blob/main/openapi.yaml).

As funcionalidades previamente liberadas para acesso são:

• Organisations
• References - Authority
• References - Authorisation Domain
• References - Authorisation Domain Role
• References - Authority Authorisation Domain
• Organisation Authority Domain Claims
• Organisation Authority Claims
• Organisation Authority Claims Authorisations
• Contacts
• Authorisation Servers
• Authorisation Servers - API Resources
• Authorisation Servers - API Discovery Endpoints
• Software Statements
• Software Statement Authority Claims
• Software Statement Certificates
• Software Statement Assertions

APIs Service Desk

O Service Desk do Open Banking Brasil pode ser acessado tanto via interface gráfica quanto por meio sistêmico através de APIs.

Para acessar a documentação das APIs do Service Desk é necessário logar na ferramenta via interface gráfica, acessar a sessão de FAQ e selecionar o menu "API SysAid".

As funcionalidades previamente liberadas para acesso são:

• (Status) Encaminhado N2 atendimento
• (Status) Em Análise N2
• (Status) Em Atendimento N2
• (Status) Encaminhado N1 Encerramento
• Interação com chamado através da API do SysAid

Como documento adicional, é possível fazer o download de um PDF nesse link (Especificação APIs Service Desk) contendo todas as informações listadas no repositório acima.

Problemas conhecidos da especificação

Especificações da fase 1 do Open Banking Brasil

Apresentamos neste item orientações para problemas conhecidos da fase 1 do Open Banking Brasil. Na tabela a seguir listamos a versão inicial de problemas identificados e seu direcionamento.

Especificações da fase 2 do Open Banking Brasil

Apresentamos neste item orientações para problemas conhecidos da fase 2 do Open Banking Brasil.

Disponibilizamos neste link o arquivo com a lista inicial de problemas conhecidos das especificações das APIs da fase 2, contendo orientações às instituições participantes até que se publiquem as correções.

Este arquivo poderá ser atualizado conforme novos itens sejam identificados.
Sua eventual atualização será previamente comunicada através dos informes do Open Banking Brasil.

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.

Monitoramento - APIs v1.0.2

APIs comuns

API de status

Exemplo de código

GET https://api.banco.com.br/open-banking/discovery/v1/status HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/discovery/v1/status", true);
req.send();

O comando acima retorna uma estrutura json como exemplificada abaixo, e no caso em que o status devolvido seja OK, o array unavailableEndpoints deve estar vazio:

{
  "data": {
    "status": [
      {
        "code": "SCHEDULED_OUTAGE",
        "explanation": "Manutenção Planejada",
        "detectionTime": "2020-01-01T01:00:00Z",
        "expectedResolutionTime": "2020-01-01T01:00:00Z",
        "updateTime": "2020-01-02T01:00:00Z",
        "unavailableEndpoints": [
          "https://api.banco.com.br/open-banking/channels/v1/branches"
        ]
      },
      {
        "code": "PARTIAL_FAILURE",
        "explanation": "Falha na execução do serviço",
        "detectionTime": "2020-01-01T01:00:00Z",
        "expectedResolutionTime": "2020-01-01T01:00: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/discovery/v1/status"
    },
    "meta": {
      "totalRecords": 1,
      "totalPages": 1
    }
  }
}

GET /discovery/v1/status

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)

Resposta

API de outages

Exemplo de código

GET https://api.banco.com.br/open-banking/discovery/v1/outages HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/discovery/v1/outages", true);
req.send();

Na estrutura de retorno exemplificada abaixo, no caso em que o parâmetro isPartial devolvido seja true, o array unavailableEndpoints deve conter a lista de endpoints indisponíveis:

{
  "data": {
    "outages": [
      {
        "outageTime": "2020-07-21T08:30:00Z",
        "duration": "PT2H30M",
        "isPartial": false,
        "explanation": "Atualização do API Gateway",
        "unavailableEndpoints": [
          "https://api.banco.com.br/open-banking/discovery/v1/outages"
        ]
      }
    ]
  },
  "links": {
    "self": "https://api.banco.com.br/open-banking/discovery/v1/outages"
  },
  "meta": {
    "totalRecords": 1,
    "totalPages": 1
  }
}

GET /discovery/v1/outages

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

Resposta

API - Admin

As APIs administrativas são recursos que podem ser consumidos apenas pelo diretório para avaliação e controle da qualidade dos serviços fornecidos pelas instituições financeiras.

Métricas

Exemplo de código:

GET https://api.banco.com.br/open-banking/admin/v1/metrics HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/admin/v1/metrics", true);
req.send();

O comando acima retorna uma estrutura json como essa:

{
  "data": {
    "requestTime": "string",
    "availability": {
        "uptime" : {
            "generalUptimeRate" : "",
            "endpoints" : [
                {
                    "url" : "",
                    "uptimeRate" : ""
                }
            ]
        },
        "downtime" : {
            "generalDowntime" : 0,
            "scheduledOutage" : 0,
            "endpoints" : [
                {
                    "url" : "",
                    "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": "string"
  },
  "meta": {}
}

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.

Parâmetros de entrada

Enum AdminMetricsPeriod

Especificação em OAS 3.0

Download da Especificação (OAS 3.0)

Resposta

Schemas

AvailabilityMetrics

{
  "uptime" : {
      "generalUptimeRate" : "",
      "endpoints" : [
          {
              "url" : "",
              "uptimeRate" : ""
          }
      ]
  },
  "downtime" : {
      "generalDowntime" : 0,
      "scheduledOutage" : 0,
      "endpoints" : [
          {
              "url" : "",
              "partialDowntime" : 0
          }
      ]
  }
}

AverageMetrics

{
  "unauthenticated": {
    "currentDay": 0,
    "previousDays": [
      0
    ]
  },
  "highPriority": {
    "currentDay": 0,
    "previousDays": [
      0
    ]
  },
  "mediumPriority": {
    "currentDay": 0,
    "previousDays": [
      0
    ]
  },
  "unattended": {
    "currentDay": 0,
    "previousDays": [
      0
    ]
  },
}

AverageTPSMetrics

{
  "currentDay": 0,
  "previousDays": [
    0
  ]
}

DiscoveryOutage

{
  "outageTime": "string",
  "duration": "string",
  "isPartial": boolean,
  "explanation": "string",
  "unavailableEndpoints": [
    "string"
  ]
}

DiscoveryStatus

{
  "code": "string",
  "explanation": "string",
  "detectionTime": "string",
  "expectedResolutionTime": "string",
  "updateTime": "string",
  "unavailableEndpoints": [
    "string"
  ]
}

LinksPaginated

MetaPaginated

ResponseDiscoveryStatusList

{
  "data": {
    "status": [
      {
        "code": "string",
        "explanation": "string",
        "detectionTime": "string",
        "expectedResolutionTime": "string",
        "updateTime": "string",
        "unavailableEndpoints": [
          "string"
        ]
      },
      {
        "code": "string",
        "explanation": "string",
        "detectionTime": "string",
        "expectedResolutionTime": "string",
        "updateTime": "string",
        "unavailableEndpoints": [
          "string"
        ]
      }
    ],
    "links": {
      "self": "string"
    },
    "meta": {
      "totalRecords": 1,
      "totalPages": 1
    }
  }
}

ResponseMetricsList

{
  "data": {
    "requestTime": "string",
    "availability": {
        "uptime" : {
            "generalUptimeRate" : "",
            "endpoints" : [
                {
                    "url" : "",
                    "uptimeRate" : ""
                }
            ]
        },
        "downtime" : {
            "generalDowntime" : 0,
            "scheduledOutage" : 0,
            "endpoints" : [
                {
                    "url" : "",
                    "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": "string"
  },
  "meta": {}
}

ResponseDiscoveryOutagesList

{
  "data": {
    "outages": [
      {
        "outageTime": "string",
        "duration": "string",
        "isPartial": boolean,
        "explanation": "string",
        "unavailableEndpoints": [
          "string"
         ]
      }
    ]
  },
  "links": {
    "self": "string"
  },
  "meta": {}
}

Fase 1 - APIs do Open Banking Brasil v1.0.2

Estas APIs disponíveis visam exibir e compartilhar dados não sensíveis de instituições participantes do OpenBanking Brasil, disponibilizando ao público informações sobre os seus canais de atendimento e as características de produtos e serviços bancários tradicionais que oferecem.

API - Canais de atendimento

Dependências próprias

Exemplo de código

GET https://api.banco.com.br/open-banking/channels/v1/branches HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/channels/v1/branches", true);
req.send();

O comando acima retorna uma estrutura json como essa:

{
  "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": "3515890",
                "countrySubDivision": "SP",
                "postCode": "17500001",
                "country": "Brasil",
                "countryCode": "BRA",
                "geograficCoordinates": {
                  "latitude": "-90.009876543",
                  "longitude": "-180.00986543"
                }
              },
              "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
  }
}

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)

Resposta

Canais de atendimento eletrônico

Exemplo de código

GET https://api.banco.com.br/open-banking/channels/v1/electronic-channels HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/channels/v1/electronic-channels", true);
req.send();

O comando acima retorna uma estrutura json como essa:

{
  "data": {
    "brand": {
      "name": "Organização A",
      "companies": [
        {
          "name": "Empresa A1",
          "cnpjNumber": "45086338000178",
          "urlComplementaryList": "https://empresaa1.com/branches-banking",
          "electronicChannels": [
            {
              "identification": {
                "type": "INTERNET_BANKING",
                "urls": [
                  "https://empresaa1.com/internet-banking"
                ]
              },
              "services": [
                {
                  "name": "ABERTURA_CONTAS_DEPOSITOS_OU_PAGAMENTO_PRE_PAGA",
                  "code": "ABRE_CONTA_DEPOSITO_OU_PRE_PAGA"
                },
                {
                  "name": "CARTAO_CREDITO",
                  "code": "CARTAO_CREDITO"
                }
              ]
            },
            {
              "identification": {
                "type": "MOBILE_BANKING",
                "urls": [
                  "https://empresaa1.com/mobile-zeta",
                  "https://empresaa1.com/mobile-aaa",
                  "https://empresaa1.com/mobile-bbb"
                ]
              },
              "services": [
                {
                  "name": "CARTAO_CREDITO",
                  "code": "CARTAO_CREDITO"
                },
                {
                  "name": "OPERACOES_ARRENDAMENTO_MERCANTIL",
                  "code": "OPERA_ARRENDAMENTO_MERCANTIL"
                },
                {
                  "name": "OUTROS_PRODUTOS_SERVICOS",
                  "code": "OUTROS_PRODUTOS_SERVICOS",
                  "additionalInfo": "Atendimento em outros idiomas"
                }

              ]
            },
            {
              "identification": {
                "type": "CHAT",
                "urls": [
                  "https://empresaa1.com/channels-chat1",
                  "https://empresaa1.com/channels-chat2"
                ]
              },
              "services": [
                {
                  "name": "SEGUROS",
                  "code": "SEGUROS"
                },
                {
                  "name": "APLICACOES_RESGATES_INVESTIMENTOS",
                  "code": "APLICA_RESGATA_INVESTIMENTOS"
                },
                {
                  "name": "EXECUCAO_ATIVA_PASSIVA_ORDENS_PAGAMENTO_SOLICITACAO_CLIENTES_USUARIOS",
                  "code": "EXECUCAO_ATIVA_PASSIVA_ORDENS_PAGTO"
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "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
  }
}

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)

Resposta

Canais de atendimento telefônico

Exemplo de código

GET https://api.banco.com.br/open-banking/channels/v1/phone-channels HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/channels/v1/phone-channels", true);
req.send();

O comando acima retorna uma estrutura json como essa:

{
  "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 ' ', DDD ' ', 40043277', 'Para regiões metropolitanas'"
                  },
                  {
                    "countryCallingCode": "NA",
                    "areaCode": "NA",
                    "number": "40043277",
                    "additionalInfo": "DDI ' ', DDD ' ', 40043277', 'Para demais 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
  }
}

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)

Resposta

Correspondentes bancários

Exemplo de código:

GET https://api.banco.com.br/open-banking/channels/v1/banking-agents HTTP/1.1
Host: api.banco.com.br
Accept: application/json

var req = new XMLHttpRequest();
req.setRequestHeader("Accept", "application/json");
req.open("GET", "https://api.banco.com.br/open-banking/channels/v1/banking-agents", true);
req.send();

O comando acima retorna uma estrutura json como essa:

{
  "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": "02345876000299",
                    "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": "17500-001",
                        "additionalInfo": "Loja B.",
                        "ibgeCode": "3550308",
                        "country": "Brasil",
                        "countryCode": "BRA",
                        "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"
                    },
                    {
                      "name": "REALIZACAO_RECEBIMENTOS_PAGAMENTOS_TRANSFERENCIAS_ELETRONICAS_VISANDO_MOVIMENTACAO_CONTAS_DEPOSITOS_TITULARIDADE_CLIENTES_MANTIDAS_INSTITUICAO_CONTRATANTE",
                      "code": "REALIZA_RECEBIMENTOS_PAGAMENTOS_TRANSFERENCIAS_ELETRONICAS"
                    },
                    {
                      "name": "RECEBIMENTOS_PAGAMENTOS_QUALQUER_NATUREZA_OUTRAS_ATIVIDADES_DECORRENTES_EXECUCAO_CONTRATOS_CONVENIOS_PRESTACAO_SERVICOS",
                      "code": "RECEBIMENTOS_PAGAMENTOS_QUALQUER_NATUREZA_EXECUCAO_CONTRATOS_CONVENIO"
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  },
  "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
  }
}