O Open Finance ou Sistema Financeiro Aberto é uma iniciativa do Banco Central do Brasil que tem como principais objetivos trazer inovação ao sistema financeiro, promover a concorrência, e melhorar a oferta de produtos e serviços financeiros ao consumidor final. Este guia tem o objetivo de auxiliar os profissionais envolvidos no negócio e no desenvolvimento desse serviço, facilitando e esclarecendo dúvidas relacionadas ao Diretório e boas práticas envolvidas.
Antes de Começar!
| Informações |
|---|
Esse guia tem como objetivo demostrar de forma prática a operação do Diretório Central do Open Finance Brasil. Além disso, ele é complementar a outras documentações disponibilizadas pela governança e não fazem parte do escopo do mesmo quaisquer detalhamentos relacionados a experiência do usuário e desenvolvedor, definições de segurança e especificação de APIs. Todas as funcionalidades estão disponíveis em sandbox e podem ser testadas em: https://web.sandbox.directory.openbankingbrasil.org.br Procedimentos em produção pendentes serão disponibilizados assim que possível. As ações aqui apresentadas podem ser realizadas tanto por administradores quanto por contatos técnicos primários e secundários. Para ilustrar este guia e tentar deixar as situações de uso mais palpáveis, foram criadas instituições e telas fictícias. Para ilustrar este guia e tentar deixar as situações de uso mais palpáveis, foram criadas instituições e telas fictícias.
|
| Âncora | ||||
|---|---|---|---|---|
|
Neste exemplo, mostramos as diversas possibilidades suportadas de atribuições de função para um usuário cadastrado no Diretório.
Público | O Diretório possibilita o cadastramento de usuários sem vínculos com nenhuma instituição. Esse tipo de usuário não tem nenhum acesso ou poder no Diretório. O cadastramento de um usuário relacionado a um participante, até que não seja feito o vinculo no Diretório, possui essas mesmas características. |
|---|---|
Administrativo | Usuários com poderes de administração no Diretório, podendo realizar todas ações. |
Operação | Usuários com poderes específicos no Diretório. |
Plataforma | Usuários para gestão e operação das plataformas do ecossistema, como o Service Desk, Portal, Plataforma de Resolução de Disputas e Plataforma Centralizada (Ressarcimento). |
Para obter mais detalhes sobre consulte Cadastrando um usuário de domínio de autorização e Poderes dos Usuários no Diretório.
| Âncora | ||||
|---|---|---|---|---|
|
Neste exemplo, mostramos as diversas possibilidades suportadas para se realizar cadastros de organizações no Diretório. Assim, uma organização pode ser cadastrada de forma independente ou pertencente a um conglomerado. Já as marcas são uma forma mais amigável, democrática e fácil para identificação das instituições participantes. Uma Marca de um conglomerado pode estar correlacionada a mais de uma Instituição Participante, assim
como uma Instituição Participante pode estar
correlacionada a mais de uma marca.
Importante: a Marca cadastrada no diretório será a mesma apresentada para escolha do usuário na Jornada de Compartilhamento de Dados e Iniciação de Pagamentos. As Instituições Participantes (ou organizações) também serão apresentadas em tela, apenas em caráter informativo. Para maiores detalhes, consulte o Guia de Experiência do Usuário.
Para obter mais detalhes sobre como cadastrar uma marca veja a seção Cadastrando um Authorisation Server.
| Âncora | ||||
|---|---|---|---|---|
|
Uma marca é representada por um Authorisation Server e o mesmo sempre deve ser cadastrado associado a uma organização;
O vinculo entre uma organização master (mãe) e uma organização que pertence ao conglomerado é realizado via o preenchimento do campo Parent Organization Reference ID no cadastro da organização filha, informando o CNPJ da organização mãe (caso seja necessário ajuste, favor entrar em contato com cadastro@openfinancebrasil.org.br);
Quando a estrutura for de um conglomerado (uma organização master e uma ou mais organizações relacionadas) é recomendado do o cadastro da marca na instituição mãe, caso as filhas venham a utilizar somente a mesma marca e arquitetura de autenticação. Importante ressaltar que caso não seja cadastrado uma marca exclusiva para o organização filha, a mesma irá herdar a(s) marca(s) da será inferido que os cadastros de marcas para atendimento dos papéis regulatórios foi realizado na organização mãe;
Caso uma marca pertença a uma organização filha o cadastro deve ser exclusivamente realizado na filha;Caso a mesma marca pertença a mais de uma organização, deve esta deverá ser realizado cadastra como um cadastro de Authorisation Servers para cada único Authorisation Server em apenas uma das organizações. É recomendado que as configurações dos Authorisation Servers sejam iguais, principalmente o campo Customer Friendly Server Name (marca);Quando for necessário cadastrar uma marca exclusiva para uma organização filha ela deixa de herdar a(s) marca(s) da organização mãe. Caso uma filha tenha que estar relacionada a uma marca exclusiva e também a da mãe, é necessário cadastrar a marca da mãe na filhavedado a duplicação de marcas;
Caso uma marca pertença exclusivamente a uma organização filha o cadastro poderá ser realizado apenas na filha;
É permitido que o papel regulatório pertencente apenas à uma organização filha seja replicado na organização mãe para permitir o reuso de solução arquitetural e Authorisation Server.
| Âncora | ||||
|---|---|---|---|---|
|
API Participants: Prefira por consumir dados da API Participants. Ela permite que o conteúdo seja fornecido ao usuário através de um servidor mais próximo, acelerando, assim, a distribuição e melhorando a experiência de consumo.
Webhook do Diretório: Inscreva-se no webhook do Diretório para receber os eventos de notificação das principais atualizações, como alteração de cadastro, atualização de marca, entre outros.
Cache local: Alguns participantes optam pela utilização de estruturas de cache local. Assim, é recomendável a revalidação diária dos dados, a fim de mantê-los íntegros e com a versão mais recente possível.
| Nota |
|---|
Importante! Caso a instituição queira utilizar alguma chave forte, recomendamos utilizar o AuthorisationServerID. Os campos Customer Friendly Server Name e Description são especialmente susceptíveis a atualizações pelas organizações e não devem ser utilizados para esse fim |
| Âncora |
|---|
Se o cadastramento do Authorisation Server na Fase 1 já foi realizado com uma marca válida para a
Fase 2:É necessário cadastrar os recursos de Fase 2 no mesmo Authorisation Server, mantendo o Customer Friendly Server Name (marca) da Fase 1;
Se o cadastramento do Authorisation Server na Fase 1 não foi realizado com uma marca válida para a Fase 2:
É necessário atualizar o Customer Friendly Server Name (marca) para a Fase 2 e cadastrar os recursos de Fase 2 no mesmo;
Os recursos da Fase 1 devem estar declarados em pelo menos um Authorisation Server do participante válido para a Fase 2;
Após esse processo, caso a instituição venha a ter Authorisation Servers / marcas oferecendo recursos exclusivos de fase 2, recomenda-se a criação de novos registros sem os recursos de Fase 1.
| Âncora | |||
|---|---|---|---|
|
Organização e Marcas |
 Neste exemplo, temos uma |
“Organização” que não |
possui organizações filhas e possui os papéis regulatórios DADOS e CONTA. Neste cenário a organização possui apenas um AS/marca, a |
“Marca 1”, que possui todos os recursos necessários para atendimento dos seus papéis regulatórios. |
Organização e Marcas |
 Neste exemplo, temos uma “Organização” que não |
possui organizações filhas e possui os papéis regulatórios DADOS e CONTA. Neste cenário a organização possui dois AS/marca, a “Marca 1” que possui os recursos necessários para atendimento do papel DADOS e a “Marca 2” que possui os recursos referente ao papel “CONTA”. |
Conglomerado |
 O relacionamento entre as “organizações filhas” com a “organização mãe” é realizado via PARENT ORGANISATION REFERENCE ID, preenchendo o Parent das “organizações filhas” com o CNPJ da “organização mãe”. |
Quando uma “organização mãe” tem uma ou mais de uma “organização filha”, temos um conglomerado Neste exemplo, temos uma “organização mãe” que possui |
duas filhas e todas possuem os mesmos papéis regulatórios DADOS e CONTA. Neste cenário a “organização mãe” possui um AS/marca, a “Marca 1”, que possui apenas um AS/marca, a “Marca 1” que possui todos os recursos necessários para atendimento dos seus papéis regulatórios. Ambas as suas organizações filhas compartilham da mesma arquitetura e infraestrutura de autenticação, utilizando o mesmo AS/marca para compartilhamento dos seus recursos. |
Organização e Marcas |
 Neste exemplo, temos uma “organização mãe” que possui |
duas filhas que possuem papéis regulatórios distintos. A “organização mãe” e a “organização filha 1” |
A “organização filha 1” deve apresentar a “marca 1” e a “marca 2”, como ela possui uma marca não receberia a da “organização mãe” por isso ambas as marcas devem ser declaradas.
Atenção! Uma “organização filha” que tenha qualquer marca cadastrada, não assume a marca da mãe! A “organização filha” só assume a marca da mãe se não tiver nenhuma marca cadastrada nela!
Lembrando, o relacionamento entre as organizações é realizado via preenchimento do campo PARENT ORGANISATION REFERENCE ID na instituição filha referenciando a mãepossuem o papel regulatório DADOS, enquanto a “Organização Filha 2” possui o papel regulatório CONTA. Neste cenário a “organização mãe” possui um AS/marca, a “Marca 1”, que possui apenas um AS/marca, a “Marca 1”, entregando todos os recursos necessários para atendimento do papéis regulatórios tanto para a “Organização Mãe”, quanto para a “Organização Filha 1”, compartilhando a mesma arquitetura e infraestrutura de autenticação. A “Organização Filha 2” possui a “Marca 2” que entrega os recursos necessários para atender ao seu papel regulatório. Neste caso, a “Organização Filha 2” possui a sua própria arquitetura e infraestrutura de autenticação. |
Organização e Marcas |
 Neste exemplo, temos uma “organização mãe” que possui |
Já a “organização filha 1” e “organização filha 2” possuem sua próprio marca, que é a “marca 2” e devem ser relacionada a cada uma delas.
Se a “marca 2” fosse adicionada na “organização mãe” a “organização filha 3” iria receber também.
Lembrado, o relacionamento entre as organizações é realizado via preenchimento do campo PARENT ORGANISATION REFERENCE ID na instituição filha referenciando a mãeduas filhas que possuem papéis regulatórios distintos. A “Organização Mãe” e a “Organização Filha 1” possuem o papel regulatório DADOS, enquanto a “Organização Filha 2” possui o papel regulatório CONTA. Com a intenção de reuso da arquitetura e infraestrutura de autenticação, o participante replicou o papel regulatório da “Organização Filha 2” para a “Organização Mãe” e desta forma, com uso de uma única marca/AS, a “Marca A”, entrega todos os recursos necessários para atender aos papéis regulatórios do conglomerado. |
Organização e Marcas |
 Neste exemplo, temos uma “Organização Mãe” que possui duas filhas e todas possuem os mesmos papéis regulatórios DADOS e CONTA. Neste cenário a “organização mãe” |
possui |
Já a “organização filha 1” e “organização filha 2” possuem sua própria marca igual “marca 2” mas que está relacionada a apenas a elas.
A “organização filha 3” possui duas marcas exclusivas dela “marca 3” e “marca 4”.
Lembrando, o relacionamento entre as organizações é realizado via preenchimento do campo PARENT ORGANISATION REFERENCE ID na instituição filha referenciando a mãeum AS/marca, a “Marca 1”, que possui apenas um AS/marca, a “Marca 1” que possui todos os recursos necessários para atendimento dos papéis regulatórios da “Organização Mãe” e “Organização Filha 1”. A “Organização Filha 2” possui a “Marca 2” que entrega os recursos necessários para atender dos seus papéis regulatórios. Neste caso, a “Organização Filha 2” possui a sua própria arquitetura e infraestrutura de autenticação. |