Pular para o conteúdo principal

​
Custódia da autorização de consulta

Quem consulta o SCR do Banco Central precisa guardar a autorização do cliente por cinco anos contados da data da última consulta, num meio que permita comprovar a autenticidade dela (Resolução CMN 5.037/2022, art. 12, § 3º). O módulo authorization_custody faz essa guarda por você: amarra a autorização à identidade verificada e ao consentimento da sessão, assina cada ato com Ed25519 e entrega um pacote de prova que qualquer pessoa confere sem consultar a UNIFOKAL. O texto da autorização nunca passa por nós. Você cria a sessão com o SHA-256 do texto que o titular leu, a versão desse texto no seu sistema e o escopo. O CPF lido do documento entra no registro só como compromisso criptográfico, com um sal aleatório próprio de cada autorização que não viaja no pacote de prova: quem tem só o pacote não chega ao CPF, e quem tem o CPF confere o titular com a abertura que o painel entrega a quem informa esse mesmo CPF.
Se a verificação aprovar, o registro é emitido na mesma transação da decisão e o check_details traz o identificador que você usa no painel:
O collection_mode diz como o titular aceitou o texto: signed_by_subject quando o mesmo flow tem o módulo esignature e o documento assinado é o próprio texto da autorização (mesmo hash); accepted_in_widget quando o titular autorizou na tela do widget, que mostra o código do texto declarado na criação da sessão (o nome da instituição pode vir em data-custody-institution-name, só como rótulo); e declared_by_customer quando o texto foi mostrado na sua interface e você declarou o hash. Os motivos de não emissão são nomeados: verification_not_approved, consent_missing (a sessão não registrou o consentimento), subject_document_missing (sem CPF lido do documento), consultation_authorization_declined (o titular respondeu “Não autorizo” na tela do widget; a verificação segue sem a custódia) e consultation_authorization_missing. O relógio conta da última consulta. A cada consulta ao SCR feita com a autorização, registre o dia no painel, em Conformidade, um por vez ou em lote (até 500 por envio, a partir de um arquivo CSV lido no seu navegador). O prazo passa a ser a data da consulta mais cinco anos, contados pelo Código Civil (art. 132, § 3º: 29 de fevereiro mais cinco anos vence em 1º de março). O prazo nunca diminui: registrar uma data anterior à última fica no histórico e não encurta nada, a mesma data de novo não duplica, data futura ou anterior à emissão é recusada, e autorização revogada só aceita o registro de consulta feita até o dia da revogação (a guarda do que já foi consultado continua). O prazo padrão é de cinco anos e você pode ampliá-lo até vinte no painel; salvar um prazo leva a ele as autorizações já emitidas que têm prazo menor, e nenhuma guarda encurta. A prova, verificável fora da UNIFOKAL. No painel, a exportação devolve um arquivo JSON no formato unifokal/custody-authorization@2: a cadeia de eventos (registro, consultas, revogação), cada um com o texto canônico exato que foi assinado, o SHA-256 dele, o do evento anterior e a assinatura; e o estado atual, assinado no instante da exportação. Evento gravado antes de 18/10/2026 continua com o tipo de antes (versão 1) e confere do mesmo jeito: a cadeia liga os bytes, não o nome do tipo. Esse arquivo não carrega dado pessoal em claro e pode ser entregue a um auditor. Para provar de quem é a autorização, informe no painel o CPF do titular: se ele casar com o compromisso assinado, você recebe a abertura do titular (formato unifokal/custody-authorization-subject@2), com o sal do compromisso. Junto com o pacote, a abertura identifica o titular: entregue as duas só a quem já tem o CPF. O caminho de referência é a função dos SDKs, que confere tudo sem rede e devolve o motivo de cada recusa: cada evento assinado por chave da lista abaixo, do mesmo ambiente e já em vigor no instante do evento; o SHA-256 de cada texto canônico, a sequência e o encadeamento; o estado apontando para o último evento, sem prometer prazo menor do que a cadeia prova; depois de uma revogação, só o registro de consulta feita até o dia dela; e, com o CPF e a abertura, o titular contra o compromisso assinado no registro, nunca contra a cópia de leitura do envelope.
Sem o SDK, os dois trechos abaixo fazem a mesma conferência, com a lista de chaves acima em pinadas. A comparação de datas é de texto: o formato ISO-8601 ordena igual ao tempo.
Quando não cobra. O registro só existe se a verificação aprovar, com o texto carimbado na criação da sessão, o consentimento registrado e o CPF lido do documento. Sem isso o módulo devolve "issued": false com o motivo e sai do preço daquela verificação. Registrar consultas, exportar a prova e ampliar o prazo não custam nada. O bloco consultation_authorization da criação é obrigatório quando o flow contém o módulo (422 consultation_authorization_required), recusado quando não contém (422 consultation_authorization_not_supported), e chave desconhecida dentro dele é 400 unknown_consultation_authorization_key: nunca aceito e ignorado em silêncio. O link hospedado não leva esse bloco: a emissão de link para um flow com o módulo é recusada com o mesmo 422 consultation_authorization_required, e a sessão desse flow nasce pela API.