SRO SUSEP: checklist para validar dados antes do envio

Validar dados antes do envio ao SRO exige mais do que conferir campos obrigatórios. A operação precisa provar que está usando a versão correta do leiaute, que formatos e domínios são válidos, que chaves e dependências existem e que apólices, endossos, prêmios e sinistros contam uma história coerente. Um arquivo tecnicamente aceito ainda pode carregar um erro de negócio; um arquivo correto para o negócio ainda pode ser rejeitado por estrutura.

Este checklist parte do conteúdo informacional oficial do Sistema de Registro de Operações (SRO) e do Manual de Orientações da Superintendência de Seguros Privados (SUSEP). Ele complementa o guia introdutório sobre o que é o SRO e como preparar a operação com uma rotina voltada a dados, rejeições e evidências.

Resumo rápido

• Congele versão, escopo e data de corte antes de validar; o SRO possui leiautes e cronogramas que evoluem.
• Separe validação estrutural — formato, tamanho, cardinalidade, domínio e condicional — de validação de negócio.
• Teste chaves, sequências e dependências: alteração, sinistro ou exclusão não podem perder a referência ao registro de origem.
• Diferencie alteração contratual, retificação de erro e exclusão de envio equivocado; cada situação segue um fluxo próprio.
• Só encerre a rotina depois de reconciliar enviados, aceitos, rejeitados, corrigidos e pendentes com evidência.

Qual versão do SRO deve orientar a validação

A resposta depende da operação abrangida e da data de referência. Em 14 de agosto de 2026, a página oficial de leiautes do SRO indicava a versão 3.0.2 em produção para as operações 1 e 2, a obrigatoriedade da 3.0.3 a partir de 17 de agosto de 2026 e a 3.1.0, com ampliação para as operações 1 a 8, prevista para 1º de dezembro de 2026. Essas datas são um retrato da consulta, não um calendário permanente.

Antes de cada homologação, virada ou envio produtivo, registre em uma evidência: versão do leiaute, versão do manual, documento de perguntas e respostas, operações abrangidas, data de início e norma aplicável. A área de regulamentação do SRO concentra as Circulares e comunicações ao mercado. Para seguros de danos e seguros de pessoas em regime financeiro de repartição simples, a Circular SUSEP nº 710/2024 disciplina as condições do registro obrigatório. Uma regra criada para uma versão anterior deve ser revisada, não apenas reaproveitada.

As três camadas de uma validação confiável

1. Conformidade com o leiaute

O Manual de Orientações do SRO versão 17.3 descreve validações de tipo ou formato, tamanho, cardinalidade e condicionais. Datas e horários seguem o padrão indicado no leiaute; campos de domínio só aceitam valores previstos; blocos opcionais podem se tornar obrigatórios quando uma condição é atendida. Se uma condição falhar, a rejeição alcança o registro inteiro, e não apenas o campo problemático.

• Formato: o valor respeita tipo, padrão de data, casas decimais e composição exigida?
• Tamanho: o conteúdo cabe no limite definido para o campo?
• Domínio: o código está entre os valores permitidos na versão utilizada?
• Cardinalidade: o bloco aparece na quantidade mínima e máxima esperada?
• Condicional: um campo aparentemente opcional tornou-se obrigatório por ramo, produto ou resposta anterior?
• Hierarquia: todo bloco filho possui o bloco pai exigido — por exemplo, uma franquia ligada à cobertura correspondente?

2. Integridade das relações

O SRO mantém relações entre documentos e seus eventos. Uma alteração precisa apontar para o documento previamente registrado; um sinistro também referencia sua origem; blocos multivalorados precisam de identificadores únicos. O manual informa que chaves repetidas são rejeitadas e que a chave de identificação é formada pela concatenação de campos definidos no leiaute.

• a chave do documento é única e reproduzível;
• a referência usada pelo endosso é exatamente a chave da apólice aceita;
• a numeração sequencial das alterações não tem lacuna, repetição ou troca de ordem;
• cada cobertura, pessoa, objeto ou outro bloco repetível possui identificador próprio;
• registros dependentes não ficam órfãos após retificação ou exclusão;
• a mesma operação não foi produzida duas vezes por sistemas ou lotes diferentes.

3. Coerência de negócio

A validação estrutural não sabe, por si só, se um prêmio é plausível, se a vigência de uma cobertura cabe na apólice ou se um endosso refletiu no financeiro. Essa camada compara entidades e regras da operação:

• início e fim de vigência do documento, cobertura, endosso e objeto segurado;
• prêmio total, prêmios por cobertura, movimentação de endosso e parcelas;
• status da apólice, cancelamento, sinistro e movimentos posteriores;
• segurado, beneficiário, intermediário, objeto e produto corretos para a operação;
• valores acumulados, devolvidos ou totalizados coerentes com os fatos do período;
• classificação de ramo e domínio compatível com a natureza real do risco.

Passar pela validação da registradora prova aderência às regras de recepção; não prova, sozinho, que a realidade operacional foi representada corretamente.

Checklist antes de gerar o lote

1. Defina o universo. Liste empresas, operações, ramos, documentos e período alcançados pela versão aplicável.
2. Registre a fonte de cada campo. Identifique tabela, sistema, transformação e área dona; marque campos preenchidos por regra ou valor padrão.
3. Congele a versão das regras. Guarde leiaute, manual, domínios e data de vigência usados na extração.
4. Meça preenchimento e domínio. Conte nulos indevidos, códigos fora da lista, tamanhos excedidos e valores que acionam condicionais.
5. Teste chaves e duplicidades. Valide unicidade no lote e contra o histórico já aceito pela registradora.
6. Valide a ordem dos eventos. Documento deve anteceder alteração e sinistro; eventos retroativos exigem avaliação do que veio depois.
7. Reconcilie valores. Compare prêmio, coberturas, parcelas, devoluções e totalizadores com a origem financeira.
8. Reconcilie quantidades. Totalize apólices, alterações, sinistros e exclusões por empresa e período antes do envio.
9. Separe exceções aceitas. Toda exceção deve ter regra, justificativa, responsável e prazo — não apenas uma célula ignorada.
10. Gere uma amostra legível. Revise casos típicos, limites, endossos retroativos, cancelamentos e registros com muitos blocos.
11. Execute em homologação quando aplicável. Trate os relatórios de crítica e repita o ciclo com a mesma rastreabilidade da produção.
12. Aprove com evidência. Registre versão, contagens, testes executados, exceções e responsáveis pela liberação.

Alteração, retificação ou exclusão: não misture os fluxos

Uma das distinções mais importantes do manual é o motivo da mudança no dado:

• Alteração: o contrato mudou no mundo real e existe documento que sustenta o evento, como endosso ou aditivo. O leiaute de alteração representa o novo retrato do documento.
• Retificação: o contrato não mudou; o registro anterior foi enviado com informação errada. O mesmo tipo de registro é reenviado com a indicação de retificação e a mesma chave.
• Exclusão: um envio equivocado precisa ser removido e não pode ser corrigido por retificação, como um erro em campo que compõe a chave. Cancelamento de apólice não é exclusão de registro.

Essa separação evita dois danos opostos: criar um endosso que nunca existiu apenas para corrigir cadastro ou apagar do SRO uma apólice que, na realidade, foi cancelada. O manual também orienta que registros dependentes sejam considerados na exclusão para evitar, por exemplo, endosso sem apólice de origem.

Exemplo: como validar um endosso antes do registro

Considere um endosso hipotético que exclui uma cobertura e reduz o prêmio. A validação deve reconstruir o evento completo:

1. confirme que a apólice de origem já foi registrada e aceita;
2. valide a referência à chave do documento e a sequência da alteração;
3. confirme o documento de endosso, sua emissão e a data de início do efeito;
4. gere o retrato atualizado exigido pelo leiaute, incluindo os dados que permaneceram válidos;
5. marque corretamente a cobertura excluída e sua vigência, conforme as regras da versão;
6. reconcilie o prêmio anterior, a redução e o valor resultante com parcelas e financeiro;
7. verifique se alterações posteriores precisam refletir o efeito, especialmente quando o evento for retroativo;
8. depois do envio, confirme aceitação e compare o resultado registrado com o lote liberado.

O manual v17.3 esclarece que o leiaute “Documento Alteração” envia novamente o conjunto completo de dados atualizado, como um retrato da situação a partir daquela alteração. Ele também diferencia o número oficial do endosso da numeração sequencial usada para ordenar as alterações no SRO. Ignorar essa linha do tempo é uma fonte de duplicidade e rejeição.

Como tratar rejeições sem perder o controle

Segundo o manual, a registradora deve justificar a rejeição em relatório de crítica, e o registro rejeitado não integra a base. Por isso, a fila operacional precisa distinguir “enviado” de “aceito”. Um lote transmitido com sucesso técnico ainda pode conter registros não registrados.

1. Classifique a crítica. Separe formato, domínio, chave, dependência, regra de negócio e falha de integração.
2. Corrija na origem quando possível. Ajuste apenas na transformação quando houver regra documentada; evitar remendos reduz reincidência.
3. Reprocesse de forma idempotente. O reenvio não pode gerar cópia nem alterar a ordem dos eventos.
4. Reconcilie o retorno. Mantenha contagens por status: gerado, enviado, aceito, rejeitado, corrigido e pendente.
5. Meça a causa recorrente. Muitas críticas iguais indicam problema de mapeamento, domínio ou processo, não dezenas de casos isolados.

Indicadores para acompanhar a qualidade do SRO

• Taxa de aceitação na primeira remessa: percentual de registros aceitos sem correção.
• Rejeições por regra e origem: mostra qual campo, transformação ou sistema concentra falhas.
• Tempo de correção: mede o intervalo entre a crítica e a aceitação do reenvio.
• Registros pendentes além do prazo interno: antecipa risco antes do vencimento regulatório.
• Divergência entre ERP e posição registrada: detecta mudanças não refletidas ou duplicadas.
• Exceções recorrentes: revela regras que a operação normalizou sem corrigir a causa.

Onde o Kitopus pode apoiar hoje

O pilar regulatório SUSEP do Kitopus está indicado como “em breve”. Portanto, o produto não deve ser apresentado hoje como transmissor ou substituto da registradora. O apoio atual está antes do envio: análises recorrentes sobre dados do ERP para encontrar apólices com cadastros incoerentes, endossos sem reflexo, parcelas divergentes e outras exceções que degradam a matéria-prima do registro.

As regras podem ser executadas em modo somente leitura, com resultados, criticidade, histórico e tarefas de tratativa. Veja como funciona a auditoria contínua em um ERP de seguros ou conheça a página de compliance para seguradoras que usam i4pro. A responsabilidade pelo enquadramento regulatório, geração e transmissão permanece com a supervisionada e seus processos autorizados.

Limites e revisão humana

Leiaute, manual, perguntas e respostas, comunicações e normas podem mudar em ritmos diferentes. Valide sempre a versão aplicável à sua operação na data do envio. Este checklist não substitui a interpretação do responsável regulatório, a documentação técnica da registradora nem testes de homologação. Casos como retroatividade, transferência de carteira, cosseguro, bloqueios, gravames e produtos com regras específicas exigem análise própria.

Perguntas frequentes

O que deve ser validado antes de enviar dados ao SRO?

Valide versão e escopo, formato, tamanho, domínio, cardinalidade, condicionais, hierarquia de blocos, chaves, duplicidades, dependências e coerência entre apólice, endosso, prêmio, vigência e demais eventos. Depois, reconcilie aceitos, rejeitados e pendentes.

Um registro aceito pela registradora está necessariamente correto?

Não. A aceitação confirma que o registro passou pelas validações aplicadas na recepção. Valores plausíveis, vínculos de negócio e representação fiel do contrato ainda precisam ser conferidos pela supervisionada.

Qual é a diferença entre alteração e retificação no SRO?

Alteração representa uma mudança real no contrato e deve ter documento de suporte, como endosso. Retificação corrige um dado enviado errado sem que o contrato tenha mudado, usando o procedimento e o leiaute indicados no manual.

Cancelamento de apólice deve ser enviado como exclusão?

Não. O manual orienta que o cancelamento contratual seja registrado pelo leiaute de alteração correspondente. Exclusão remove um registro enviado equivocadamente que não pode ser corrigido por retificação.

O Kitopus já envia informações ao SRO?

Não é essa a oferta atual descrita pelo produto. O regulatório SUSEP está planejado como um pilar futuro. Hoje, o Kitopus apoia a qualidade dos dados com análises e tratativas sobre o ERP; transmissão e responsabilidade regulatória permanecem nos processos autorizados da supervisionada.