Regulatório SUSEP: o que as obrigações exigem dos seus dados
SRO, SES, FIP e provisões técnicas têm uma coisa em comum: todos são alimentados pelos mesmos dados operacionais que já estão no ERP. Quando esses dados divergem entre si, a rejeição no envio é só o sintoma — a causa estava na operação semanas antes.
- SRO
- Registro de operações: cada apólice, endosso e sinistro precisa chegar íntegro e vinculado.
- SES
- Estatísticas periódicas construídas a partir de prêmio, sinistro e provisão do período.
- FIP
- Quadros que consolidam a posição patrimonial e operacional a partir do razão.
- Provisões técnicas
- PSL, IBNR, IBNER e PPNG calculadas sobre o estado dos processos e das apólices.
A obrigação regulatória é um teste de coerência da sua base
Nenhuma dessas obrigações pede um dado novo. Todas pedem uma leitura organizada de dados que a seguradora já mantém: apólices, endossos, parcelas, sinistros, movimentos financeiros e lançamentos contábeis. É por isso que o envio funciona como um teste: ele encontra a incoerência que a operação não encontrou.
O problema é o momento. A rejeição chega com prazo correndo, e a correção exige voltar à origem — uma apólice emitida há dois meses, um endosso sem vínculo, um sinistro encerrado com reserva viva. O tempo de investigação é o mesmo de sempre, mas a folga de calendário não é.
Conferir a coerência durante o mês inverte a ordem. A base chega ao envio já validada nos mesmos critérios que o regulador vai aplicar, e o envio vira confirmação em vez de descoberta.
O que costuma derrubar um envio
Vínculo ausente
Endosso, parcela ou sinistro sem a chave que o liga à apólice de origem.
Campo obrigatório vazio
Registros operacionalmente válidos que não carregam um dado exigido pelo leiaute.
Domínio inválido
Código de ramo, cobertura ou situação fora da tabela aceita pelo regulador.
Data incoerente
Vigência, emissão ou movimentação em ordem cronológica impossível.
Valor divergente
Prêmio, reserva ou pagamento que não reconcilia com a contabilidade do período.
Registro duplicado
O mesmo evento enviado duas vezes por reprocessamento de carga.
Provisões técnicas dependem do estado dos processos
A PSL é construída a partir dos sinistros avisados e não liquidados. Se um processo foi encerrado operacionalmente e a reserva não foi baixada, a provisão fica inflada. Se um sinistro foi pago acima do reservado sem reforço, ela fica subestimada. Nos dois casos o número reportado não descreve a carteira.
O mesmo raciocínio vale para a PPNG, que depende da vigência correta das apólices: vigência encerrada em apólice ativa, ou endosso de prorrogação sem reflexo, distorcem o prêmio não ganho do período.
Por isso a conferência de provisão não começa na planilha atuarial. Ela começa na coerência entre status, saldo e movimento dentro do ERP — que é exatamente o que a auditoria contínua verifica todo dia.
Como preparar a base antes de cada janela
- 01
Mapear o que cada envio exige
Levantar campos, domínios e vínculos obrigatórios por obrigação, e traduzir cada um em critério verificável.
- 02
Rodar durante o mês
Executar as regras de completude e coerência sobre a produção corrente, não só na véspera do envio.
- 03
Tratar por criticidade
Separar o que impede o envio do que apenas degrada a qualidade do dado, e atacar o primeiro grupo primeiro.
- 04
Guardar a evidência
Manter o histórico das execuções para demonstrar o controle prévio caso o dado enviado seja questionado.
Perguntas frequentes
O Kitopus faz o envio para a SUSEP?+
Não. O envio continua sendo feito pelos sistemas e processos da operação. O Kitopus atua antes: confere completude, vínculos e coerência dos dados que alimentam a obrigação, para que a base chegue validada.
O que é o SRO?+
O Sistema de Registro de Operações concentra o registro das operações de seguro. Ele exige que cada apólice, endosso e sinistro chegue com os campos obrigatórios preenchidos e com o vínculo correto com o registro de origem.
Qual a diferença entre PSL, IBNR e IBNER?+
PSL cobre sinistros já avisados e não liquidados. IBNR cobre sinistros ocorridos e ainda não avisados. IBNER cobre o ajuste esperado sobre sinistros já avisados cujo valor final deve diferir do reservado hoje.
Por que a rejeição aparece só no envio?+
Porque o ERP valida cada registro isoladamente, e o leiaute regulatório valida o conjunto: vínculos entre registros, domínios de código e coerência de datas e valores entre módulos. São critérios diferentes, aplicados em momentos diferentes.
Dá para conferir a base de um período já fechado?+
Dá. As regras podem rodar sobre qualquer recorte de período, o que é útil tanto para preparar um envio retroativo quanto para dimensionar o passivo de correção antes de uma auditoria.
Chegue no envio com a base já conferida
Mostramos as regras de completude e coerência rodando sobre um recorte real da sua carteira, antes da próxima janela de envio.
Solicitar demonstração