Glossário

Termos regulatórios e técnicos usados nesta documentação, em ordem de assunto. Quando existe um termo oficial em português, ele aparece primeiro.

Regulação e governança

• Banco Central do Brasil (BCB): Regulador do Open Finance Brasil. Aprova a convenção dos participantes e edita, com o CMN, as normas do ecossistema, como a Resolução Conjunta nº 1/2020.

• Conselho Monetário Nacional (CMN): Coedita com o BCB as resoluções do Open Finance Brasil.

• Superintendência de Seguros Privados (SUSEP): Reguladora do Open Insurance Brasil. Define as diretrizes do ecossistema e pode incorporar as propostas técnicas dos participantes à regulação.

• Conselho Nacional de Seguros Privados (CNSP): Edita a Resolução CNSP nº 415/2021, que institui o Open Insurance Brasil.

• Estrutura de governança: Entidade formada pelos participantes de cada ecossistema. Opera o Diretório de Participantes, publica os padrões técnicos (APIs e perfil de segurança) e conduz a certificação funcional.

• Diretório de Participantes: Cadastro oficial de cada ecossistema, com as organizações, os servidores de autorização, os softwares registrados, os certificados e as chaves públicas (JWKS). É operado pela estrutura de governança. Uma organização pode ter mais de um servidor de autorização.

• Certificação: A certificação funcional das APIs é conduzida pela estrutura de governança. A certificação do perfil de segurança é feita pela OpenID Foundation (OIDF), com a suíte oficial de conformidade.

Ecossistemas

• Open Finance Brasil (OFB): Ecossistema do BCB para compartilhamento de dados e serviços financeiros. Está organizado em quatro fases:

  • Fase 1: dados abertos das instituições, como canais de atendimento e produtos.
  • Fase 2: dados cadastrais e transacionais dos clientes, como contas, cartões e operações de crédito.
  • Fase 3: serviços, como a iniciação de pagamentos via Pix e o encaminhamento de propostas de crédito.
  • Fase 4: outros dados, como câmbio, credenciamento, seguros, investimentos e previdência.

• Open Insurance Brasil (OPIN): Ecossistema da SUSEP para compartilhamento de dados e serviços de seguros, previdência aberta e capitalização. Está organizado em três fases: dados abertos das sociedades; dados dos clientes; e serviços de iniciação de movimentação, como contratação, resgate, portabilidade e pagamento de sorteio.

Papéis dos participantes

• Instituição transmissora de dados: Instituição que detém o relacionamento com o cliente e compartilha os dados dele, com consentimento, por meio das APIs reguladas. No Open Insurance: sociedade transmissora. Em textos em inglês também aparece como data holder ou data provider.

• Instituição receptora de dados: Instituição que, com o consentimento do cliente, consome os dados compartilhados por uma transmissora. No Open Insurance: sociedade receptora. Em inglês: data receiver.

• Instituição detentora de conta: No Open Finance, a instituição onde o cliente mantém a conta de onde sai o pagamento.

• Iniciadora de transação de pagamento (ITP): No Open Finance, a instituição que inicia um pagamento, a pedido do cliente, na instituição detentora da conta.

• Sociedade iniciadora de serviço de seguro (SISS): No Open Insurance, a sociedade que inicia serviços, como contratação ou resgate, a pedido do cliente, na sociedade onde o produto é mantido.

• Servidor de autorização: Serviço OAuth 2.0 / OpenID Connect de um participante, registrado no Diretório, que autentica o cliente e emite os tokens de acesso às APIs.

Consentimento

• Consentimento: Autorização expressa do cliente para compartilhar dados ou iniciar um serviço, com finalidade, permissões e prazo definidos. Os estados variam conforme a API:
  • Compartilhamento de dados (Open Finance e Open Insurance): AWAITING_AUTHORISATION, AUTHORISED e REJECTED. A revogação pelo cliente leva o consentimento a REJECTED, com o motivo CUSTOMER_MANUALLY_REVOKED. No Open Insurance também existe o estado CONSUMED.
  • Pagamentos (Open Finance): incluem ainda CONSUMED (consentimento utilizado) e PARTIALLY_ACCEPTED.
  • Pagamentos automáticos (Open Finance): são os únicos com o estado REVOKED.

Segurança

• FAPI (Financial-grade API): Perfil de segurança da OpenID Foundation para APIs financeiras, construído sobre OAuth 2.0 e OpenID Connect.

• Perfil de segurança FAPI-BR: Perfil brasileiro, baseado no FAPI 1.0 Advanced, adotado pelo Open Finance e pelo Open Insurance. A versão vigente é a 2.1. Exige:

  • assinatura PS256;
  • autenticação forte do cliente, como private_key_jwt;
  • PAR e PKCE com S256;
  • ID token criptografado;
  • tokens vinculados ao certificado mTLS do cliente.

  Existe um perfil baseado em FAPI 2.0 em rascunho, ainda não vigente.

• PS256: Algoritmo de assinatura RSASSA-PSS com SHA-256, exigido pelo perfil FAPI-BR. O RS256 não é aceito.

• mTLS (TLS mútuo): Conexão TLS em que cliente e servidor apresentam certificados. No ecossistema, os tokens de acesso ficam vinculados ao certificado do cliente, de modo que um token copiado não funciona sem o certificado.

• ICP-Brasil: Infraestrutura de Chaves Públicas Brasileira. Emite os certificados usados nos ecossistemas:

  • BRCAC: certificado de transporte (mTLS).
  • BRSEAL: certificado de assinatura.

• PAR (Pushed Authorization Request): O cliente envia os parâmetros da autorização diretamente ao servidor e recebe um request_uri, que o navegador usa em seguida. É obrigatório em todos os fluxos de autorização do perfil FAPI-BR.

• PKCE: Proof Key for Code Exchange. O cliente prova, no endpoint de token, que é o mesmo que iniciou a autorização. O perfil FAPI-BR exige o método S256.

• JWE / ID token criptografado: O perfil FAPI-BR exige que o ID token seja criptografado para o cliente (RSA-OAEP com A256GCM), usando a chave de criptografia publicada no JWKS do software.

• DPoP: Demonstrating Proof of Possession. Alternativa ao mTLS para vincular tokens a uma chave do cliente. O perfil FAPI-BR não exige DPoP.

• CIBA: Client-Initiated Backchannel Authentication. Fluxo de autorização desacoplado. O perfil FAPI-BR permite que o servidor de autorização o suporte, mas não o exige.

• DCR / DCM: Dynamic Client Registration e Dynamic Client Management. Registro e manutenção automáticos do cliente de uma receptora ou iniciadora no servidor de autorização da transmissora, usando um SSA.

• SSA (Software Statement Assertion): JWT assinado pelo Diretório de Participantes que atesta o cadastro de um software. Ele é apresentado no DCR.

• JWKS: Conjunto de chaves públicas (JSON Web Key Set) de um software ou servidor de autorização, publicado no Diretório para validar assinaturas e cifrar tokens.

Plataforma Finnest Power

• CLI finnest: Ferramenta de linha de comando que prepara, implanta, verifica e opera a plataforma na nuvem da instituição. Veja Instalar a CLI.

• Alvo de deploy (target): Combinação de nuvem (aws ou azure) e ambiente (sandbox ou prod) em que a plataforma é implantada. É configurado no arquivo finnest.toml.

• Power Admin: Console web de administração da plataforma implantada.

• Evidência de execução: Registro local e redigido de cada comando da CLI, em .finnest/runs/. É usado para diagnóstico, auditoria e suporte.

• Outbox transacional: Padrão que grava cada evento no banco na mesma transação da operação de negócio. Um processo separado entrega o evento à fila, o que evita perder eventos ou publicá-los sem a gravação correspondente.