Um sistema de resseguro é a plataforma que registra os contratos de cessão, aplica suas regras às apólices, calcula capitais ressegurados, prêmios, comissões e recuperações e mantém prazos, evidências e conciliação financeira em uma base única. Sua função é sustentar a execução do programa de resseguro ao longo do tempo, e não apenas arquivar o contrato assinado.
A diferença entre as duas coisas costuma aparecer tarde. O contrato é negociado uma vez; a operação que decorre dele acontece todos os dias — a cada emissão que entra no tratado, a cada endosso que muda a exposição, a cada aviso de sinistro que pode gerar recuperação, a cada prestação de contas com a resseguradora ou com a corretora.
Este conteúdo trata da camada operacional: quais funções um sistema de resseguro precisa sustentar, o que a regulação vigente e a que entra em vigor em janeiro de 2027 transformaram em requisito técnico, quando planilhas e módulos genéricos deixam de ser suficientes e quais critérios usar para decidir entre manter, integrar ou adotar uma solução dedicada.
Se o que você procura é o conceito da operação — cessão, retrocessão, estruturas proporcionais e não proporcionais —, comece por o que é resseguro e como a operação funciona.
Principais pontos
- Um sistema de resseguro precisa fazer mais do que guardar contratos: ele aplica parâmetros contratuais a dados de apólices, calcula valores, controla prazos e sustenta a conciliação com contrapartes.
- A maior parte das falhas não nasce no cálculo inicial, e sim na atualização: endossos, cancelamentos e sinistros que não chegam ao controle de resseguro.
- A Resolução CNSP nº 494/2026, em vigor em 2 de janeiro de 2027, transforma em exigência prática o que depende de registro datado — recepção de propostas, formalização em 90 dias, percentuais de cessão acompanhados ao longo do ano.
- Nenhum sistema, isoladamente, produz conformidade. Ele torna viável demonstrar o que foi feito, quando e com base em qual informação.
- A decisão entre planilha, módulo do core, integração e sistema dedicado depende de volume, diversidade de estruturas contratuais e do custo atual de reconstruir informação.
⚠️ Ponto de atenção: a cessão que não acompanhou o endosso
O ponto mais frágil de uma operação de resseguro raramente é o cadastro do contrato. É o intervalo entre uma alteração na apólice e sua repercussão na cessão.
Um endosso que aumenta a importância segurada altera o capital cedido, o prêmio de resseguro e, em contratos não proporcionais, a posição da exposição em relação à prioridade.
Quando essa atualização depende de um arquivo mensal, de uma exportação manual ou da lembrança de alguém, a divergência existe desde o dia do endosso — mas só aparece no fechamento, na prestação de contas ou, no pior cenário, na hora de pleitear uma recuperação.
A condição que torna isso relevante é conhecida: carteiras com muitos endossos, contratos facultativos com condições próprias, renovações concentradas em poucas datas e equipes enxutas. Nenhuma dessas situações provoca falha imediata. Elas aumentam, de forma gradual, o número de conferências necessárias para que o mês feche.
“Sistema de resseguro” tem dois significados e os dois importam
Quando alguém pesquisa o termo, pode estar procurando duas coisas diferentes.
O sistema de resseguro como estrutura de mercado
No Brasil, a estrutura atual decorre da Lei Complementar nº 126/2007, que abriu o mercado e criou as categorias de ressegurador local, admitido e eventual.
Em números recentes divulgados pela Susep, no primeiro quadrimestre de 2026, de aproximadamente R$ 74,8 bilhões em prêmios emitidos, cerca de R$ 9,8 bilhões foram cedidos em resseguro.
O sistema de resseguro como software
É a plataforma que a cedente usa para administrar seu programa de resseguro, concentrando informações sobre contratos, contrapartes, cálculos, moedas, cessões e demais eventos da operação.
Quanto mais formatos de contrato, resseguradores, estruturas proporcionais e não proporcionais e fluxos com ou sem corretora entram na operação, maior se torna a necessidade de organizar essas informações em uma camada única e rastreável.
A abertura do mercado multiplicou formatos de contrato, contrapartes, moedas e critérios de cálculo. Uma operação que negocia com resseguradores de três categorias distintas, em estruturas proporcionais e não proporcionais, com e sem intermediação de corretora, passa a enfrentar um problema de administração de informação que não existia no modelo anterior.
O restante deste conteúdo trata do segundo sentido.
O que um sistema de resseguro precisa fazer
Listas de funcionalidades de fornecedores tendem a se parecer. O que diferencia as soluções é o que acontece com cada função quando o dado muda depois da primeira execução.
| Função | O que precisa estar registrado | Origem do dado | Sinal de que falta estrutura |
|---|---|---|---|
| Cadastro e parametrização do contrato | Tipo, vigência, limites, prioridades, camadas, percentuais, comissões, participação nos lucros, painel de resseguradores. | Contrato ou slip formalizado. | Cada estrutura nova exige desenvolvimento ou uma planilha própria. |
| Vínculo entre apólice e cessão | Quais riscos entraram em qual contrato, sob qual versão da apólice. | Administração de apólices. | A cessão é montada a partir de extrações pontuais. |
| Cálculo de capitais e prêmios cedidos | Base de cálculo, critério aplicado, data e resultado, com histórico. | Apólices, endossos e parâmetros do contrato. | Refazer um cálculo antigo exige reconstruir premissas. |
| Sinistros e recuperações | Enquadramento no contrato, parcela recuperável, documentos, status do pleito. | Gestão de sinistros. | O acompanhamento das recuperações vive em planilha. |
| Conta corrente com contrapartes | Borderôs, prestações de contas, prêmios, comissões, corretagem, pagamentos e recebimentos por contrato e período. | Financeiro e contratos. | A conciliação é feita fora do sistema, contraparte por contraparte. |
| Moeda e câmbio | Valor na moeda do contrato, equivalente em reais, taxa e data aplicadas. | Contrato e política cambial. | Ajustes manuais entre a data do cálculo e a do pagamento. |
| Prazos, documentos e trilha | Datas de proposta, recepção, aceite, formalização, endossos, versões e responsáveis. | Fluxo de colocação. | Prazos são controlados em agenda e caixa de e-mail. |
| Concentração e percentuais | Exposição por contraparte e grupo, percentual cedido acumulado no ano. | Cadastro de contrapartes e base de prêmios. | O percentual só é conhecido no fechamento anual. |
Duas dessas funções costumam ser subestimadas na escolha de um sistema de resseguro.
A primeira é o recálculo retroativo. Quando um endosso retroage à data de emissão, o sistema precisa refazer a cessão daquele período e registrar tanto o valor anterior quanto o novo, com o motivo da diferença. Sistemas que apenas sobrescrevem o cálculo resolvem o número do mês e destroem a explicação.
A segunda é o controle de reintegração em contratos não proporcionais. Depois de um sinistro que consome parte do limite, a operação precisa saber quanto de limite resta, se há reintegração disponível e qual prêmio ela gera. É um controle contratual específico, que raramente existe em módulos genéricos.
O que a regulação transformou em requisito de sistema
A Lei nº 15.040/2024, o Marco Legal do Contrato de Seguro, está em vigor desde 11 de dezembro de 2025 e trata do resseguro nos artigos 60 a 65. Entre outros pontos, prevê que o contrato de resseguro se forma pelo silêncio da resseguradora no prazo de 20 dias contados da recepção da proposta.
A Resolução CNSP nº 494/2026, publicada em julho de 2026, revoga a Resolução CNSP nº 451/2022 e entra em vigor em 2 de janeiro de 2027, com adaptação das operações anteriores no momento da renovação. Da perspectiva de sistemas, quatro pontos concentram o impacto:
Datas comprováveis
O prazo de aceitação tácita começa na recepção da proposta. Isso exige identificação única da proposta, comprovante de envio e de recebimento e vínculo com as manifestações posteriores.
Formalização em 90 dias
O prazo de formalização contratual passa de 180 para 90 dias contados do início da vigência da cobertura, com prazo próprio para endossos. Na prática, é um controle de aging: quais coberturas já iniciaram e ainda não têm contrato assinado.
Justificativas técnicas anuais
Cessões em resseguro acima de 90% e retrocessões acima de 70% por resseguradores locais, consideradas na globalidade das operações do ano civil, exigem justificativa técnica à Susep até 31 de março do ano seguinte. Quem só mede o percentual no fechamento descobre a obrigação depois que ela já se consumou.
Política de transferência de riscos ligada aos sistemas
O artigo 7º detalha requisitos mínimos da política, incluindo monitoramento de concentração por contraparte e grupo econômico, acúmulo por produto, ramo, região e segurado, descasamento entre o contrato de resseguro e o contrato subjacente e, explicitamente, os procedimentos operacionais e sistemas que asseguram o cumprimento da política.
Some-se a isso a manutenção da oferta preferencial mínima de 40% de cada cessão automática ou facultativa aos resseguradores locais, com tratamento equânime e informações idênticas — o que só é demonstrável com registro de quem foi consultado, quando e em quais condições.
💡 Vale a distinção: nada disso significa que uma ferramenta produza conformidade. A aderência depende de interpretação jurídica, contratos, processos, responsabilidades e qualidade da informação. O que o sistema muda é a viabilidade de demonstrar o que foi feito sem reconstruir histórico.
Para a leitura detalhada da norma, veja os impactos da Resolução CNSP nº 494/2026 na operação.
Quantos contratos da carteira renovam entre janeiro e março de 2027 e quantos deles ainda dependem de planilha para fechar prêmio e conta corrente? Esse levantamento dimensiona a janela real de implementação e ajuda a priorizar onde a estrutura precisa mudar primeiro.
Cenário ilustrativo: onde a estrutura costuma quebrar
Duas seguradoras têm carteiras parecidas: um tratado quota-parte, um excesso de danos por evento e cerca de trinta operações facultativas por ano.
Na primeira, os contratos estão cadastrados em um sistema que lê diariamente as emissões e os endossos da administração de apólices. Quando um endosso altera a importância segurada, a cessão é recalculada e a diferença fica registrada com data e origem. O fechamento consiste em revisar exceções.
Na segunda, o mesmo trabalho existe, distribuído. Uma planilha calcula o quota-parte a partir de um arquivo mensal. Os facultativos são acompanhados em uma pasta compartilhada. As recuperações são controladas por uma pessoa que conhece os contratos. O fechamento funciona — enquanto as três condições se mantiverem: volume estável, poucas exceções e a mesma pessoa disponível.
A diferença entre as duas não aparece em um mês normal. Aparece quando um sinistro relevante exige reconstruir a posição de cobertura na data do evento, quando uma auditoria pede a memória de cálculo de uma cessão de dois anos atrás ou quando a operação precisa absorver um novo tipo de contrato em três semanas.
O efeito aqui é condicional, não inevitável: operações pequenas e estáveis podem conviver bem com controles manuais por muito tempo. O que muda o cálculo é a combinação de crescimento, diversidade contratual e rotatividade de equipe.
Onde o sistema de resseguro se encaixa na arquitetura
Um sistema de resseguro é um consumidor intenso de dados de terceiros. Ele quase nunca é a fonte original da informação que usa — e é por isso que a arquitetura importa mais do que a tela.
Três definições precisam estar claras antes de qualquer escolha de ferramenta:
Qual é a fonte de verdade de cada dado
Importância segurada, vigência, cobertura e prêmio pertencem à administração de apólices . Aviso, reserva e pagamento pertencem a sinistros. Recebimentos e pagamentos pertencem ao financeiro. O sistema de resseguro é a fonte apenas dos parâmetros contratuais, dos cálculos de cessão e da posição com cada contraparte. Quando duas áreas mantêm versões próprias do mesmo dado, o problema é de governança, e trocar de ferramenta não o resolve.
Com que frequência o dado chega
Uma integração por arquivo mensal produz uma cessão estruturalmente defasada em relação aos endossos do período. Isso pode ser aceitável em uma carteira estável e inadequado em uma carteira com muitas alterações. A pergunta correta não é “tem API?”, e sim “qual evento dispara a atualização e em quanto tempo ela chega?” Esse é o tipo de decisão tratado em integração de sistemas no setor de seguros .
Quem escreve de volta
Prêmio cedido, comissão e recuperação precisam alcançar o financeiro e a contabilidade. Se esse retorno é manual, a conciliação vira um processo de digitação, com o erro aparecendo no fechamento e não na origem.
Quando faz sentido e quando não faz
Manter a estrutura atual tende a ser razoável quando:
O número de contratos é baixo e estável.
Os formatos são poucos e padronizados.
Os cálculos são conferidos sem retrabalho recorrente.
As exceções são raras.
A operação consegue reconstruir uma cessão antiga sem mobilizar várias pessoas.
Uma evolução por integração tende a bastar quando:
O problema está concentrado na transferência de dados entre sistemas que, isoladamente, atendem suas funções.
Os cálculos estão corretos, mas chegam atrasados.
A maior parte do esforço está em digitação e conferência, não em parametrização.
Uma solução dedicada entra na conversa quando:
A carteira usa estruturas contratuais diversas.
Há colocação entre vários resseguradores, moeda estrangeira ou retrocessão.
Cada contrato fora do padrão gera um controle paralelo.
Prazos e evidências dependem de acompanhamento individual.
A reconstrução de histórico já consome tempo relevante da equipe.
Há também um cenário em que a resposta é esperar: quando a operação está no meio de uma migração de core ou de uma mudança de processo. Nesse caso, adicionar mais um sistema antes de estabilizar as fontes de dados costuma transferir o problema, não resolvê-lo.
Comparação com alternativas
| Alternativa | Quando pode funcionar | Limitação principal | Impacto possível | Critério para avançar |
|---|---|---|---|---|
| Planilhas e controles manuais | Poucos contratos, formatos padronizados, equipe estável. | Depende de disciplina e de conhecimento individual. | Divergências descobertas no fechamento; dificuldade de reconstruir histórico. | Aumento de exceções, rotatividade na equipe ou pedidos de memória de cálculo. |
| Módulo de resseguro dentro do core ou do sistema de apólices | Estruturas simples, sobretudo proporcionais. | Menor flexibilidade para contratos fora do padrão. | Cada exceção vira planilha ao lado do sistema. | Contratos não proporcionais, multi-moeda ou painéis de resseguradores. |
| Integração entre os sistemas existentes | Sistemas adequados que trocam dados de forma insuficiente. | Exige definir responsabilidades e fonte de verdade por dado. | Reduz digitação sem ampliar a capacidade de parametrização. | A dificuldade está na transferência, não na regra do contrato. |
| Desenvolvimento interno | Requisitos muito específicos e capacidade técnica própria sustentada. | Manutenção, documentação e conhecimento ficam com a empresa. | Custo migra de licença para time e continuidade. | Existe requisito real que o mercado não atende e equipe para mantê-lo por anos. |
| Sistema de resseguro dedicado | Diversidade contratual, volume crescente e necessidade de rastreabilidade. | Exige diagnóstico, integração, migração e mudança de processo. | Concentra cálculo, conta corrente e histórico em uma base. | A limitação deixou de ser pontual e afeta fechamento, auditoria e recuperações. |
| Manter e revisar o processo, sem trocar tecnologia | Quando o gargalo é de definição, não de ferramenta. | Não amplia capacidade quando o volume cresce. | Ganho rápido e barato, com teto conhecido. | Regras indefinidas, papéis pouco claros ou dado sem dono. |
A combinação é comum e legítima: integrar primeiro, padronizar o processo e só depois avaliar a substituição do componente que concentra a dependência.
Antes de abrir um processo de seleção, vale entender como cotação, gestão de apólices e resseguro podem se organizar em uma mesma frente. Isso ajuda a avaliar a solução dentro da arquitetura e da operação como um todo, e não como uma ferramenta isolada.
O que costuma dar errado na prática
| Erro ou risco de execução | Por que acontece | Consequência possível | Como reduzir o risco |
|---|---|---|---|
| Escolher pelo comparativo de funcionalidades | A avaliação lista recursos, sem testar comportamento com dados reais. | A ferramenta atende a demonstração e falha nas exceções da carteira. | Testar contratos representativos, incluindo os atípicos, antes de decidir. |
| Migrar apenas contratos vigentes | O histórico é tratado como arquivo morto. | Cálculos antigos e recuperações em curso perdem rastreabilidade. | Definir quanto histórico migra e o que permanece consultável na origem. |
| Integrar só a emissão | O endosso é visto como exceção. | A cessão fica defasada desde o primeiro mês. | Tratar endosso, cancelamento e reativação como eventos de integração. |
| Parametrizar contrato por desenvolvimento | O sistema não comporta a estrutura negociada. | Cada renovação vira projeto técnico. | Exigir configuração por parâmetro para as estruturas usadas na carteira. |
| Automatizar sobre dados sem dono | A automação entra antes da governança. | Inconsistência processada com mais velocidade. | Definir fonte oficial e regra de atualização por informação. |
| Tratar prazo regulatório como campo de cadastro | A data é registrada, mas não gera acompanhamento. | Prazos de formalização vencem sem alerta. | Vincular prazo a evento comprovável, responsável e evidência. |
| Deixar a conta corrente fora do escopo | O foco fica no cálculo técnico. | Conciliação com resseguradoras e corretoras segue manual. | Incluir borderôs e prestação de contas no desenho desde o início. |
Nem todos esses erros têm a mesma frequência em todas as operações. Eles funcionam melhor como hipóteses a verificar do que como diagnóstico pronto.
Critérios de avaliação: perguntas que separam as opções
Estas perguntas servem tanto para avaliar um fornecedor quanto para examinar o sistema de resseguro que você já tem.
Parametrização
Quais estruturas da nossa carteira são configuráveis sem desenvolvimento? Peça a demonstração com um contrato real, não com um exemplo padrão.
Endosso e recálculo
O que acontece quando um endosso retroage? O sistema recalcula, mantém o valor anterior e registra o motivo da diferença?
Não proporcional
Camadas, prioridade, agregação por evento e reintegração de limite são tratadas no fluxo ou fora dele?
Painel e corretagem
É possível dividir a mesma colocação entre resseguradores com participações distintas e separar corretagem de comissão?
Moeda
O sistema guarda a taxa e a data aplicadas em cada evento, permitindo reproduzir o cálculo depois?
Prazos e evidências
Proposta, recepção, aceite, formalização e endossos ficam vinculados, com responsável e documento?
Rastreabilidade
É possível responder “por que este valor foi cedido assim, nesta data” sem consultar a equipe?
Integração
Quais eventos da administração de apólices e de sinistros são consumidos, com que frequência e por qual mecanismo?
Migração
Como entram os contratos vigentes, as posições em aberto e as recuperações em andamento?
Governança
Quem pode alterar parâmetros, o que fica registrado e como o acesso é segregado entre áreas?
Respostas vagas em parametrização, recálculo e migração costumam custar mais caro do que a ausência de um recurso específico, porque aparecem depois da contratação.
Quais requisitos a sua carteira exige de um sistema de resseguro?
Marque as estruturas e situações que já existem na operação. Para cada uma, o mapa mostra o que o sistema precisa sustentar e de onde vem o dado. Não é uma nota de maturidade: é uma pauta de avaliação para conversas internas e com fornecedores.
0 de 9 situações marcadas · 0 blocos de requisitos exibidos
Marque ao menos uma situação para ver os requisitos correspondentes. Todos os blocos permanecem disponíveis nesta página, mesmo sem interação.
Contratos automáticos proporcionais
- Parametrizar percentual de cessão, limites por risco, comissão de resseguro e participação nos lucros sem depender de desenvolvimento.
- Aplicar o contrato automaticamente às apólices que atendem aos critérios, incluindo as emitidas depois do início da vigência.
- Recalcular a cessão quando um endosso altera importância segurada, vigência ou cobertura.
Dado de origem: administração de apólices (emissões, endossos, cancelamentos) e cadastro do contrato.
Contratos não proporcionais
- Registrar prioridade, limite, camadas e a base de acionamento (por risco, por evento ou agregada).
- Controlar reintegrações de limite e prêmio de reintegração após um sinistro relevante.
- Acumular perdas por evento, o que exige data de ocorrência, localização e critério de agregação definidos.
Dado de origem: sinistros (avisos, reservas, pagamentos) e parâmetros contratuais por camada.
Resseguro facultativo
- Vincular cada colocação a uma apólice ou risco específico, com condições próprias.
- Guardar proposta, data comprovada de envio e de recepção, manifestações e versão final aceita.
- Acompanhar o prazo de formalização do contrato e dos endossos por operação, não por carteira.
Dado de origem: fluxo de colocação (propostas e comunicações) e apólice subjacente.
Colocação entre vários resseguradores
- Registrar a participação de cada ressegurador e mantê-la ao longo de todos os cálculos.
- Ratear prêmios, comissões, pagamentos e recuperações por participante.
- Acompanhar pendências financeiras individualmente, já que um participante pode atrasar sem afetar os demais.
Dado de origem: painel de colocação do contrato e cadastro das contrapartes.
Intermediação por corretora de resseguro
- Separar o que é devido à corretora do que é devido ao ressegurador, com corretagem calculada por contrato.
- Registrar documentos recebidos por meio da corretora e diferenciar nota de cobertura de contrato formalizado.
- Preservar o histórico de quem intermediou cada operação.
Dado de origem: cadastro de intermediários e documentos da colocação.
Operações em moeda estrangeira
- Manter valores na moeda do contrato e no equivalente em reais, com a taxa e a data usadas em cada evento.
- Reproduzir o cálculo depois, com a mesma taxa aplicada na origem.
- Tratar a variação entre a data do cálculo e a do pagamento sem ajuste manual em planilha.
Dado de origem: contrato, tabela de câmbio adotada e eventos financeiros.
Cosseguro
- Registrar a cota de cada participante, a liderança e os instrumentos emitidos.
- Distinguir a parcela retida da parcela em cosseguro antes de calcular a cessão em resseguro.
- Conciliar repasses e prestações de contas por apólice e por participante.
Dado de origem: apólice, instrumento de cosseguro e financeiro.
Retrocessão
- Tratar a operação em dois papéis: o que foi aceito e o que foi repassado adiante.
- Acompanhar o percentual retrocedido ao longo do ano, e não apenas no fechamento.
- Manter a cadeia completa entre risco original, aceitação e retrocessão para sustentar recuperações.
Dado de origem: contratos aceitos, contratos retrocedidos e movimentação financeira.
Cessões ao exterior e oferta preferencial
- Classificar a contraparte por categoria (local, admitido ou eventual) e validar essa classificação na colocação.
- Registrar quais resseguradores foram consultados, quando, com quais informações e condições.
- Consolidar percentuais de cessão por período, com os dados necessários a uma justificativa técnica.
Dado de origem: cadastro de contrapartes, histórico da colocação e base de prêmios emitidos e cedidos.
Este mapa organiza requisitos a partir das estruturas indicadas e não avalia conformidade regulatória, risco ou adequação de um fornecedor. A análise depende dos contratos, dos sistemas e dos processos de cada operação.
Use o mapa acima como pauta: cada bloco exibido corresponde a uma exigência concreta que a sua carteira impõe ao sistema. Leve o conjunto para a próxima conversa com as áreas de resseguro, tecnologia e controles — e compare, item a item, com o que a estrutura atual entrega hoje.
Como o Flexus se conecta a esse cenário
Uma distinção honesta: o que uma solução da categoria deveria oferecer, descrito nas seções anteriores, não é automaticamente o que um produto específico entrega. O que segue vem das informações públicas da solução.
O Flexus é o sistema de resseguro da frente de Insurance Management da Tecnologia Única. Segundo a página oficial, foi desenvolvido no contexto da abertura do mercado ressegurador brasileiro — que ampliou a variedade de formatos contratuais — e permite configurar diversos tipos de contrato, com negociações específicas e parametrizações flexíveis.
No setup inicial, integra-se ao sistema de administração de apólices da seguradora para coletar as informações necessárias ao cálculo dos capitais ressegurados e dos prêmios devidos às resseguradoras, sendo o cálculo e a gestão dos pagamentos realizados na própria ferramenta.
O mecanismo relevante, aqui, é o que a arquitetura organiza: a parametrização do contrato deixa de viver em planilhas paralelas, e os dados de exposição vêm da administração de apólices em vez de serem redigitados. Isso reduz o número de sistemas que precisam concordar para que um período feche.
O que essa descrição não comprova: ganho de tempo, redução de custo ou adequação a uma norma específica. A aderência ao seu caso depende dos formatos de contrato utilizados, dos sistemas a integrar, da qualidade dos dados de origem, do histórico que precisa ser preservado e do desenho de implantação. É isso que uma avaliação técnica precisa verificar antes de qualquer compromisso.
Como estruturar o próximo passo
Inventarie os contratos
Tipo, estrutura, vigência, contrapartes, moeda, intermediação e data de renovação. Esse inventário é a base de qualquer decisão posterior.
Desenhe o caminho de um contrato
Escolha um contrato representativo e percorra apólice → cessão → cálculo → prêmio → pagamento → eventual recuperação, anotando cada ponto em que alguém digita, confere ou consulta outra fonte.
Defina a fonte oficial de cada dado
Onde a pergunta não tiver resposta única, registre a divergência como item a resolver antes de automatizar.
Relacione prazos a eventos comprováveis
Para cada obrigação, identifique o evento que inicia a contagem, o responsável e a evidência que a comprova.
Priorize por renovação
Os contratos que renovam primeiro em 2027 definem a ordem de trabalho, porque são os que precisarão observar as novas regras antes.
Estabeleça a linha de base
Tempo de fechamento, número de intervenções manuais, divergências por período e recuperações em aberto. Sem esses números, será difícil avaliar se a mudança funcionou.
Conclusão
A escolha de um sistema de resseguro raramente se resolve comparando listas de recursos. Ela se resolve quando a operação entende quais estruturas contratuais precisa sustentar, de onde vem cada dado que alimenta o cálculo e quanto esforço consome, hoje, reconstruir uma informação que deveria estar registrada.
Enquanto o volume é baixo e os formatos são poucos, controles manuais sustentam o processo. À medida que a carteira ganha estruturas diferentes, contrapartes em mais de uma categoria e prazos que precisam ser comprovados, o custo da fragmentação deixa de ser visível apenas no fechamento e passa a limitar a capacidade de resposta.
A entrada em vigor da Resolução CNSP nº 494/2026, em 2 de janeiro de 2027, com adaptação na renovação, dá um calendário concreto para essa revisão — sem tornar obrigatória a troca de tecnologia.
Perguntas frequentes sobre sistema de resseguro
É a plataforma que registra os contratos de cessão, aplica seus parâmetros aos dados das apólices, calcula capitais ressegurados, prêmios, comissões e recuperações e mantém prazos, documentos e conciliação financeira por contrato e contraparte.
Não. O core concentra funções centrais da seguradora, como emissão, cobrança e sinistros. O sistema de resseguro trata de um domínio específico — contratos de cessão, cálculos, conta corrente com contrapartes e recuperações — e depende de dados que nascem no core ou na administração de apólices.
Dá, com transferência manual ou por arquivo. O efeito é uma defasagem entre o que foi emitido ou endossado e o que está refletido na cessão. Em carteiras estáveis, isso pode ser administrável; em carteiras com muitas alterações, tende a gerar conciliação recorrente.
Não. A norma exige processos, responsabilidades, registros e evidências. Um sistema pode tornar viável comprovar datas, prazos e percentuais, mas a adequação depende da interpretação das regras e do desenho operacional de cada instituição, com validação jurídica e de compliance.
O inventário dos contratos por tipo e estrutura, o calendário de renovações, os sistemas que precisarão ser integrados, os pontos atuais de digitação e conferência e o histórico que precisa ser preservado. Sem isso, as demonstrações mostram o produto, não a aderência.
Não há prazo único. O tempo depende do número e da diversidade dos contratos, das integrações necessárias, da qualidade dos dados de origem, do volume de histórico a migrar e do nível de parametrização exigido. Estimativas confiáveis só surgem depois do mapeamento técnico.
EN 
PT 
ES 
FR 
IT 
DE 