Arquitetura dos relatórios regulatórios
Os dois modelos de operação dos relatórios ao Banco Central: o agente que roda na infraestrutura da PSAV e o modelo gerenciado pela Clav.
Dois modelos, o mesmo motor
A Clav gera, valida e envia ao Banco Central os relatórios regulatórios da PSAV, como o CCS e o ACAM212. A PSAV escolhe onde esse trabalho acontece: dentro da própria infraestrutura, com um agente da Clav, ou na Clav, em um ambiente isolado só para ela.
Modelo A: agente
O agente roda na infraestrutura da PSAV. Os dados pessoais dos clientes e a credencial do Sisbacen ficam lá, e a Clav recebe apenas metadados.
Modelo B: gerenciado
A Clav opera tudo. Os dados chegam por API ou CSV e ficam em um banco próprio da PSAV, cifrados com uma chave exclusiva dela.
O motor de geração e o formato dos dados de entrada são os mesmos nos dois modelos, então a PSAV pode começar em um e migrar para o outro depois.
Modelo A: agente na PSAV
O agente da Clav é instalado no ambiente da PSAV, que precisa de Kubernetes ou Docker e de um cofre de segredos. Ele lê os dados por conectores locais (banco de dados, API ou CSV), gera o arquivo e faz o envio ao Banco Central.
Os dados pessoais dos clientes não saem da PSAV, e a credencial do Sisbacen também fica lá. Para a Clav vão apenas metadados, que alimentam o painel de status. Por isso, nesse modelo, a Clav não trata dados pessoais e a due diligence de nuvem fica mais leve.
Quando o Banco Central muda o layout de um relatório, a Clav publica um pacote assinado e o agente aplica a atualização.
Modelo B: gerenciado pela Clav
A PSAV não precisa de infraestrutura nenhuma. A Clav recebe os dados, gera os relatórios, faz o envio e aplica as mudanças de layout sem que a PSAV precise fazer nada.
Como os dados chegam
| Forma de envio | Quando usar |
|---|---|
| Push via API | Forma principal. Cada PSAV recebe um certificado de cliente próprio, e o gateway identifica a PSAV pelo certificado. |
| Pull | Quando a PSAV já expõe uma API e aceita abrir acesso de entrada para a Clav. |
| Upload de CSV | Pelo painel ou por SFTP. Indicado para PSAVs pequenas e como contingência. |
A ingestão é idempotente. Cada evento leva um ID gerado pela PSAV, e reenviar o mesmo evento não duplica o registro.
Níveis de isolamento
| Nível | Como funciona | Quando usar |
|---|---|---|
| Banco por PSAV (padrão) | Banco ou instância própria, com role e chave KMS próprias | Plano padrão do modelo gerenciado |
| Conta ou projeto de nuvem por PSAV | Rede, IAM e billing separados | Plano premium, para PSAVs grandes ou com due diligence mais exigente |
Schemas separados dentro de um mesmo banco não são oferecidos, porque esse nível de separação não é suficiente para dados pessoais.
Controles de segurança
Cada PSAV tem a sua célula: banco, chave KMS e segredos próprios. O worker que processa os relatórios de uma PSAV assume uma role IAM que só alcança os recursos daquela célula, então um worker comprometido não chega aos dados de outra PSAV.
CPF, CNPJ e nome são cifrados campo a campo com a chave da PSAV (envelope encryption). Dumps e backups guardam apenas texto cifrado. Buscas e o cálculo de deltas usam um índice cego, um HMAC do CPF calculado com a chave da PSAV, e assim não precisam do valor em claro.
A senha do Sisbacen também é cifrada com a chave da PSAV. Somente o worker a decifra, no momento do envio.
Por padrão, ninguém da Clav tem acesso aos dados da PSAV. Quando um acesso é necessário, ele é concedido sob demanda (just-in-time), com aprovação e trilha de auditoria.
Os dados ficam em região brasileira. A Clav guarda apenas o necessário para calcular deltas, fazer retificações e cumprir os prazos legais, e segue uma política documentada de descarte.
Credencial do Sisbacen
O manual do Sisbacen prevê que cada operador use o próprio usuário. A recomendação é a PSAV criar um usuário dedicado à integração, sob sua responsabilidade, que ela pode revogar a qualquer momento.
LGPD e contratação
No modelo gerenciado, a Clav atua como operadora dos dados pessoais dos clientes da PSAV. Isso pede contrato de operador, registro das operações de tratamento e um plano de resposta a incidentes para cada PSAV.
Para a PSAV, a Clav passa a ser um serviço relevante de processamento e armazenamento em nuvem. A due diligence desse tipo de contratação costuma pedir relatório SOC 2 ou ISO 27001, pentests periódicos e cláusulas que garantam ao Banco Central acesso aos dados.
Comparativo
| Critério | Modelo A: agente | Modelo B: gerenciado |
|---|---|---|
| Infraestrutura da PSAV | Kubernetes ou Docker, cofre de segredos | Nenhuma |
| Dados pessoais saem da PSAV | Não | Sim, cifrados com a chave da PSAV |
| Credencial do Sisbacen | Fica na PSAV | Fica na Clav, cifrada com a chave da PSAV |
| Papel da Clav na LGPD | Não trata dados pessoais | Operadora |
| Due diligence de nuvem | Leve, só metadados | Completa, serviço relevante |
| Esforço de integração | Conectores locais (banco, API ou CSV) | Push via API ou CSV |
| Atualização de layout | Pacote assinado aplicado pelo agente | Transparente |
| Visibilidade de status | Painel da Clav | Painel da Clav |
| Perfil indicado | PSAVs com equipe de infraestrutura ou política de não compartilhar dados | PSAVs pequenas ou sem equipe de infraestrutura |
Qual escolher
Regra prática
Se a PSAV tem equipe de infraestrutura ou uma restrição interna para compartilhar dados de clientes, o modelo A é o mais indicado. Se não tem infraestrutura e prefere terceirizar a operação, o modelo B resolve sem exigir nada do lado dela.