O Open Insurance já faz parte da estrutura regulatória e tecnológica do mercado segurador brasileiro.
Para as sociedades participantes, a discussão deixou de estar concentrada somente na publicação inicial das APIs. O foco passou para a sustentação do ecossistema, o gerenciamento de versões, as certificações, a interoperabilidade e a capacidade de adaptar sistemas internos às atualizações técnicas.
Em 2026, o cronograma do Open Insurance Brasil contempla melhorias nas APIs das Fases 1, 2 e 3, incluindo novas funcionalidades, ajustes em regras existentes e aprimoramentos técnicos voltados à estabilidade, à padronização e à conformidade entre as participantes.
A SUSEP também incluiu a revisão da regulamentação do Open Insurance em seu Plano de Regulação para 2026 e, no primeiro semestre, promoveu uma tomada de subsídios sobre aspectos estruturais, operacionais e regulatórios do sistema. Entre os temas avaliados estavam governança, participação, certificação de jornadas, interoperabilidade e monitoramento.
Esse cenário amplia a pressão sobre arquiteturas rígidas, integrações pontuais e fluxos de dados pouco rastreáveis.
O desafio atual vai além da disponibilização de uma API. A seguradora precisa sustentar o compartilhamento de dados ao longo do tempo, acompanhar mudanças de especificação, administrar consentimentos, integrar informações internas e responder às exigências técnicas sem transformar cada atualização em um novo projeto de grande porte.
Principais pontos sobre o Open Insurance
- O Open Insurance permite o compartilhamento padronizado de dados e serviços mediante consentimento do cliente.
- Participam diretamente seguradoras, entidades abertas de previdência complementar e sociedades de capitalização autorizadas pela SUSEP.
- A participação é obrigatória para sociedades enquadradas nos segmentos prudenciais S1 e S2 e opcional para as demais sociedades autorizadas.
- Sociedades credenciadas como Processadoras de Ordem do Cliente também podem atuar nas jornadas de iniciação previstas pelo sistema.
- Os principais marcos de implementação das Fases 1, 2 e 3 já foram concluídos.
- Em 2026, o ecossistema está concentrado em sustentação, versionamento, certificações e releases de melhoria.
- Sistemas legados não impedem, por si só, a integração com o Open Insurance.
- A operação precisa conectar APIs externas, consentimentos e registros internos com controle e rastreabilidade.
- A escolha entre integrações pontuais, equipe interna ou plataforma especializada depende da quantidade de conexões, da capacidade técnica e dos objetivos do negócio.
A SUSEP esclarece que a participação direta é restrita às seguradoras, entidades abertas de previdência complementar e sociedades de capitalização autorizadas. A obrigatoriedade alcança as organizações de maior porte, enquadradas nos segmentos S1 e S2.
⚠️ Ponto de atenção
Quando a participação no Open Insurance depende de integrações desenvolvidas isoladamente para cada fase, versão ou sistema, a fragilidade pode permanecer pouco visível durante os primeiros ciclos.
O problema tende a aparecer quando:
- Diferentes versões de APIs precisam coexistir.
- Uma alteração técnica afeta vários fluxos internos.
- O consentimento está registrado em um ambiente e o uso do dado ocorre em outro.
- Cada integração depende de conhecimento concentrado em poucas pessoas.
- Inconsistências precisam ser investigadas em sistemas distintos.
- A equipe precisa repetir validações a cada nova atualização.
Com o aumento do número de conexões, parceiros e serviços, essa estrutura pode gerar retrabalho, divergências entre sistemas e dificuldade para reconstruir o caminho percorrido pelos dados.
O ponto central é garantir que a camada de integração tenha governança própria, processos documentados e monitoramento contínuo.
Mapeie onde sua operação ainda depende de ajustes manuais para integrar dados, consentimentos e sistemas.
O que é Open Insurance e como o Sistema de Seguros Aberto funciona no Brasil?
Open Insurance é o sistema que permite aos consumidores de produtos de seguros, previdência complementar aberta e capitalização autorizar o compartilhamento de seus dados entre sociedades participantes.
Esse compartilhamento ocorre por meio de APIs padronizadas e depende da manifestação do cliente, que deve definir quais informações poderão ser acessadas, por quem e durante qual período.
A base regulatória do sistema foi estabelecida pela Resolução CNSP nº 415/2021 e pela Circular SUSEP nº 635/2021. Os normativos organizaram as diretrizes, responsabilidades e etapas de implementação do Open Insurance no Brasil.
O modelo foi organizado em três fases.
Fase 1: Dados abertos
A primeira fase envolve o compartilhamento público de informações sobre:
- Canais de atendimento.
- Produtos.
- Coberturas.
- Condições.
- Preços e características dos serviços disponibilizados.
Esses dados não identificam consumidores. O objetivo é facilitar comparações, ampliar a transparência e criar uma estrutura padronizada de consulta ao mercado.
Fase 2: Compartilhamento de dados pessoais
A segunda fase permite o compartilhamento de informações relacionadas ao cliente, mediante consentimento.
Entre os dados abrangidos podem estar:
- Informações cadastrais.
- Apólices e contratos.
- Movimentações.
- Coberturas contratadas.
- Dados de sinistros.
- Produtos de previdência complementar aberta.
- Títulos de capitalização.
O cliente permanece no centro da jornada. A sociedade receptora precisa obter o consentimento, enquanto a sociedade transmissora deve autenticar o titular e confirmar o compartilhamento.
A LGPD também exige que o tratamento de dados pessoais tenha finalidade definida e respeite os direitos do titular, incluindo acesso a informações sobre uso compartilhado e possibilidade de revogação do consentimento nas hipóteses aplicáveis.
Fase 3: Serviços de iniciação de movimentação
A terceira fase incorpora serviços que permitem iniciar movimentações dentro do ecossistema aberto.
Isso significa que o cliente pode, conforme os serviços disponíveis e as regras aplicáveis:
- Solicitar uma proposta.
- Contratar determinados produtos.
- Alterar características de um contrato.
- Realizar movimentações relacionadas aos produtos abrangidos.
- Iniciar uma jornada em uma sociedade e concluí-la em outra.
As Sociedades Processadoras de Ordem do Cliente, conhecidas como SPOCs, exercem uma função relevante nessa etapa. Elas podem iniciar as ordens autorizadas pelo consumidor e encaminhá-las às sociedades participantes responsáveis pela execução.
Qual é o estágio do Open Insurance em 2026?
Em 2026, o Open Insurance já concluiu os principais ciclos de implementação das três fases e entrou em uma etapa de sustentação do ecossistema.
Essa mudança altera a natureza do desafio.
Durante a implementação inicial, a principal preocupação estava relacionada ao cumprimento dos cronogramas e à disponibilização das APIs previstas. Na etapa atual, as sociedades precisam garantir que a estrutura continue funcionando enquanto especificações, regras e versões evoluem.
O cronograma técnico de 2026 prevê releases de melhoria nas APIs das três fases, com:
- Ajustes em regras existentes.
- Novas funcionalidades.
- Aprimoramentos técnicos.
- Períodos de convivência entre versões.
- Processos de certificação.
- Atualização das implementações pelas participantes.
Os próprios manuais do Open Insurance preveem revisão e atualização periódicas para acompanhar mudanças regulatórias e tecnológicas.
Para as seguradoras, isso exige capacidade de atualização contínua. Uma integração preparada apenas para a entrega inicial tende a acumular dependências conforme o ecossistema avança.
Onde o Open Insurance aparece na operação da seguradora?
O Open Insurance atravessa diferentes áreas da organização. Por isso, tratá-lo como uma iniciativa restrita à equipe de tecnologia pode criar lacunas entre o que foi implementado e o que precisa ser sustentado.
Produtos, emissão e apólices
Dados sobre produtos, coberturas, condições e canais precisam seguir padrões definidos pelo ecossistema.
Quando as informações de produto estão dispersas entre sistemas, planilhas e bases distintas, a publicação das APIs pode exigir tratamentos manuais ou regras duplicadas.
Canais digitais e distribuição
Corretoras, plataformas digitais e outros parceiros podem utilizar os dados e serviços do ecossistema para construir jornadas de comparação, contratação e atendimento.
Para a seguradora, isso amplia a necessidade de manter:
- Catálogos de produtos atualizados.
- Regras comerciais consistentes.
- Informações disponíveis em tempo adequado.
- Integrações estáveis com diferentes canais.
- Mecanismos de autenticação e autorização.
Atendimento ao cliente
O consumidor precisa entender:
- Quais dados serão compartilhados.
- Com qual sociedade.
- Por quanto tempo.
- Para qual finalidade.
- Como cancelar ou alterar o consentimento.
Uma jornada tecnicamente funcional pode continuar inadequada quando essas informações aparecem de forma confusa ou fragmentada.
Sinistros e movimentações
Dados relacionados a sinistros, contratos e movimentações podem estar distribuídos entre sistemas centrais, ferramentas de atendimento, plataformas de parceiros e ambientes especializados.
Sem uma camada de integração, cada consulta pode exigir regras próprias de transformação, validação e atualização.
Governança de dados e LGPD
Cada API que compartilha dados pessoais precisa estar conectada a controles de consentimento, segurança, finalidade e rastreabilidade.
O consentimento não pode existir apenas como uma confirmação na interface. A organização precisa registrar e conseguir recuperar:
- Quem autorizou.
- Quais dados foram autorizados.
- Qual sociedade recebeu a autorização.
- Qual era a finalidade.
- Qual era o período de validade.
- Se houve revogação.
- Quais sistemas utilizaram os dados.
Tecnologia e arquitetura
A equipe de tecnologia precisa estruturar a integração de sistemas no setor de seguros para que sistemas internos, APIs, parceiros e canais consigam trocar informações com consistência.
Quando esses elementos são construídos de forma isolada, cada mudança regulatória ou técnica pode gerar uma nova sequência de desenvolvimentos.
Avalie se sua arquitetura conecta produto, consentimento, operação e canais externos em um fluxo rastreável.
Conheça as soluçõesO custo de tratar o Open Insurance como uma obrigação pontual
A adequação mínima pode cumprir uma entrega específica, mas não necessariamente cria uma estrutura preparada para sustentar o ecossistema.
O custo dessa decisão costuma aparecer em três frentes.
1. Competitividade
Insurtechs, plataformas de distribuição e novos canais digitais trabalham com modelos baseados em conectividade.
Uma seguradora com dificuldade para disponibilizar dados, produtos ou serviços por APIs pode levar mais tempo para:
- Estruturar parcerias.
- Lançar novos canais.
- Testar produtos.
- Adaptar jornadas.
- Participar de ecossistemas digitais.
- Viabilizar modelos de seguro embarcado.
A consequência não é uma exclusão automática do mercado. O risco está na perda de velocidade diante de empresas que já possuem uma arquitetura preparada para integrar parceiros.
2. Conformidade e rastreabilidade
Sistemas desconectados aumentam a dificuldade de identificar onde um dado foi criado, alterado, compartilhado ou utilizado.
Quando a informação apresentada por uma API não corresponde ao registro interno, a equipe precisa reconstruir o fluxo em diferentes ambientes.
Esse cenário amplia o esforço de:
- Auditoria.
- Investigação de inconsistências.
- Atendimento a solicitações.
- Comprovação de consentimento.
- Correção de dados.
- Resposta a incidentes.
3. Velocidade de resposta
O Open Insurance continua evoluindo.
Empresas com arquitetura rígida podem enfrentar cada nova versão como um projeto separado. A equipe precisa revisar integrações, localizar regras, alterar sistemas, executar novos testes e repetir processos de certificação.
Em uma estrutura modular, parte dessas atualizações pode ser absorvida por uma camada de integração, reduzindo o impacto direto sobre o sistema central.
Analise quanto esforço sua equipe consome hoje para adaptar uma integração já existente.
Simplifique integraçõesRiscos de uma adequação superficial
Expor as APIs obrigatórias resolve somente uma parte do problema.
Uma implementação superficial pode deixar riscos relevantes dentro da operação.
1. Consentimento sem rastreabilidade ponta a ponta
O consentimento pode estar registrado corretamente na jornada do cliente, mas desconectado dos sistemas que efetivamente utilizam os dados.
Nesse caso, a empresa sabe que houve autorização, porém encontra dificuldade para comprovar todo o caminho percorrido pela informação.
O controle precisa conectar:
- Captura do consentimento.
- Autenticação.
- Dados autorizados.
- Prazo.
- Sociedade receptora.
- Sistemas consultados.
- Compartilhamentos realizados.
- Revogação ou encerramento.
2. Dependência de conhecimento concentrado
Integrações construídas como projetos pontuais costumam concentrar conhecimento em poucas pessoas.
Quando a documentação é incompleta, uma troca de equipe, ausência prolongada ou mudança de fornecedor pode afetar a continuidade da operação.
A estrutura precisa ser compreensível para além de quem participou da implementação inicial.
3. Ausência de monitoramento contínuo
APIs podem apresentar:
- Indisponibilidade.
- Dalhas de autenticação.
- Divergências de dados.
- Lentidão.
- Erros de versão.
- Certificados vencidos.
- Alterações não refletidas em sistemas internos.
Sem monitoramento, o problema pode ser percebido somente depois de afetar uma jornada, um parceiro ou uma obrigação operacional.
4. Regras duplicadas em diferentes sistemas
Quando cada canal implementa a própria lógica, regras de produto, validação e compartilhamento podem começar a divergir.
A mesma informação passa a ser interpretada de formas diferentes pelo core, pelo portal, pelo parceiro e pela API.
5. Integrações difíceis de atualizar
Uma integração pode funcionar no momento da entrega e ainda assim ser difícil de manter.
O risco cresce quando:
- Não existe controle de versão.
- Os contratos das APIs não estão documentados.
- Testes dependem de execução manual.
- Alterações no core afetam vários fluxos.
- Não existe separação entre regra de produto e regra de integração.
Quando faz sentido agir agora e quando não faz
Nem toda seguradora precisa iniciar uma reestruturação completa imediatamente.
A decisão deve considerar o estágio atual da operação, o volume de integrações, a capacidade da equipe e os objetivos do negócio.
Considere manter a estrutura atual quando:
- As integrações existentes são poucas.
- O escopo operacional permanece estável.
- A equipe consegue acompanhar as novas versões.
- Há documentação suficiente.
- O monitoramento das APIs já está estruturado.
- Não existem planos de expansão relevantes no curto prazo.
- O esforço de manutenção permanece proporcional ao uso.
Considere uma evolução gradual quando:
- O esforço de manutenção começou a crescer.
- Novas integrações são solicitadas com frequência.
- Existem regras duplicadas.
- A equipe depende de intervenções manuais.
- Auditorias ou revisões internas identificaram lacunas.
- A empresa pretende ampliar canais digitais.
- O core não pode receber mudanças frequentes.
Considere uma plataforma especializada quando:
- A operação depende de vários parceiros.
- Cada integração ainda é desenvolvida ponto a ponto.
- O sistema central possui limitações de integração.
- O lançamento de produtos depende de alterações extensas.
- Diferentes canais utilizam regras próprias.
- A manutenção das APIs ocupa uma parcela desproporcional da equipe.
- Há planos de expansão por canais digitais.
- A empresa precisa estruturar uma modernização progressiva.
Avalie o esforço necessário para manter integrações isoladas frente à estrutura exigida para sustentar novos canais.
Critérios técnicos para uma arquitetura preparada para o Open Insurance
Antes de comparar soluções, a seguradora precisa definir o que espera da arquitetura. Uma arquitetura orientada a APIs ajuda a desacoplar sistemas, padronizar interfaces e criar uma estrutura mais preparada para conectar novos serviços e parceiros.
Segurança e controle de acesso
A estrutura deve seguir os requisitos técnicos e de segurança definidos pelo Open Insurance, incluindo controles de autenticação, proteção de dados, detecção de falhas e resposta a incidentes.
Os manuais oficiais estabelecem requisitos mínimos para as sociedades participantes e preveem atualizações conforme o sistema evolui.
Gestão de consentimento
A operação precisa registrar o ciclo completo do consentimento.
Isso inclui:
- Criação.
- Confirmação.
- Validade.
- Finalidade.
- Dados autorizados.
- Sociedade receptora.
- Uso.
- Alteração.
- Revogação.
- Encerramento.
Governança de versões
As especificações das APIs podem mudar.
A arquitetura precisa permitir:
- Identificação das versões em uso.
- Convivência temporária entre versões.
- Testes antes da migração.
- Atualização de contratos.
- Comunicação com parceiros.
- Desativação controlada de versões anteriores.
Coexistência com sistemas legados
A integração com o Open Insurance não exige, em todos os casos, a substituição imediata do core system de seguros. A decisão depende das limitações do sistema atual, das interfaces disponíveis e do nível de desacoplamento necessário.
Uma camada intermediária pode:
- Consumir dados do sistema existente.
- Transformar informações para o padrão exigido.
- Aplicar regras de integração.
- Controlar chamadas externas.
- Centralizar logs.
- Desacoplar canais digitais do core.
A viabilidade depende da capacidade de integração do ambiente atual e deve ser avaliada tecnicamente.
Rastreabilidade ponta a ponta
A seguradora precisa conectar o que é disponibilizado externamente ao que está registrado internamente.
Isso permite investigar:
- Origem do dado.
- Transformação aplicada.
- Sistema consultado.
- Autorização utilizada.
- Horário do compartilhamento.
- Resposta enviada.
- Erro registrado.
- Correção realizada.
Observabilidade
A arquitetura deve oferecer visibilidade sobre disponibilidade, desempenho, falhas e comportamento das integrações.
Sem observabilidade, a equipe opera de forma reativa.
Modularidade
Uma estrutura modular permite substituir, atualizar ou ampliar componentes sem alterar todo o ambiente.
Esse atributo é especialmente importante quando a organização precisa evoluir gradualmente.
Comparação entre os caminhos possíveis
Não existe uma única alternativa adequada para todas as seguradoras.
Onde uma plataforma de integração especializada resolve o problema
Quando a análise aponta para uma plataforma especializada, o principal critério é a capacidade de organizar produtos, canais e parceiros sem criar novas dependências desnecessárias.
Uma plataforma pode atuar como camada intermediária entre:
- O core.
- As APIs do Open Insurance.
- Os canais digitais.
- Os parceiros.
- As regras de produto.
- Os sistemas de atendimento.
- Os ambientes de dados.
Essa camada recebe informações do ambiente interno, aplica transformações e disponibiliza serviços para os demais componentes da operação.
O sistema central pode continuar como sistema de registro enquanto a camada digital assume funções de integração, orquestração e exposição de serviços.
Esse modelo tende a ser útil quando a seguradora precisa:
- Preservar parte da infraestrutura existente.
- Reduzir mudanças diretas no core.
- Integrar novos canais.
- Organizar regras de produtos.
- Criar APIs reutilizáveis.
- Monitorar conexões.
- Acelerar novos projetos.
Como o Proteo pode apoiar essa evolução
O Proteo é uma plataforma end to end para seguradoras que pode apoiar diferentes frentes da operação, incluindo integração, gestão de produtos, emissão, sinistros e conexão com canais de distribuição.
A solução pode apoiar diferentes frentes da operação, incluindo integração, gestão de produtos, emissão, sinistros e conexão com canais de distribuição. A aplicação exata depende do desenho tecnológico e das necessidades de cada seguradora.
Em cenários de modernização progressiva, o Proteo pode funcionar como uma camada desacoplada do sistema central, permitindo que novos canais e serviços sejam estruturados sem concentrar todas as alterações no legado.
A Tecnologia Única já apresenta o Proteo como uma alternativa para integrar sistemas legados, lançar produtos e ampliar canais digitais sem exigir, necessariamente, uma substituição imediata do sistema central.
A arquitetura modular também permite avaliar quais componentes devem ser adotados primeiro, em vez de iniciar uma transformação ampla sem priorização.
Proteo na estrutura da Herval Seguradora
O case da arquitetura tecnológica da Herval Seguradora mostra uma aplicação do Proteo como plataforma central de uma operação criada com APIs e integração entre diferentes canais de distribuição.
O caso demonstra a capacidade da plataforma de estruturar uma operação digital e conectá-la a diferentes canais de distribuição. Ele não deve ser interpretado, isoladamente, como uma prova de preservação de um core legado, pois o projeto envolveu a construção tecnológica da nova seguradora.
Para empresas que já possuem sistemas consolidados, a aplicação precisa ser avaliada a partir da arquitetura existente, das integrações disponíveis e das funções que deverão permanecer no core.
Avalie com a Tecnologia Única quais integrações podem evoluir sem comprometer o que já funciona.
O que costuma dar errado na prática
| Erro recorrente | Por que acontece | Consequência possível | Como reduzir o risco |
|---|---|---|---|
| Tratar o Open Insurance como projeto isolado de TI | Compliance, jurídico, produto e operação entram tarde no processo. | Consentimentos, regras e controles ficam desconectados. | Estruturar uma governança multidisciplinar. |
| Expor APIs sem revisar o ciclo do consentimento | O foco permanece na entrega técnica. | A empresa perde visibilidade sobre o uso do dado. | Mapear o consentimento da coleta ao encerramento. |
| Criar uma integração para cada parceiro | Falta de uma camada comum. | Regras duplicadas e manutenção crescente. | Criar serviços e componentes reutilizáveis. |
| Concentrar conhecimento em poucas pessoas | Documentação e governança insuficientes. | Dependência operacional e demora na resolução de falhas. | Documentar fluxos, contratos e responsabilidades. |
| Atualizar APIs diretamente no core | Arquitetura sem desacoplamento. | Cada mudança amplia o risco operacional. | Utilizar uma camada intermediária. |
| Ignorar a convivência entre versões | Planejamento concentrado apenas na nova release. | Interrupção de parceiros ainda não atualizados. | Estruturar multiversionamento e migração controlada. |
| Migrar dados sem saneamento | Pressão por prazo. | Inconsistências entre sistemas internos e APIs. | Validar origem, formato e qualidade dos dados. |
| Não monitorar as integrações | Ausência de observabilidade. | Falhas percebidas apenas pelo cliente ou parceiro. | Centralizar logs, alertas e indicadores. |
| Usar o Open Insurance apenas para conformidade | A iniciativa não se conecta à estratégia de produto. | Investimento sem aproveitamento comercial. | Relacionar integração, canais e experiência do cliente. |
Como estruturar o próximo passo
Independentemente do estágio atual, a seguradora pode organizar a evolução em etapas.
Mapeie as integrações existentes
Liste todas as conexões relacionadas ao Open Insurance, incluindo:
- APIs.
- Sistemas internos.
- Bancos de dados.
- Parceiros.
- Canais.
- Ferramentas de consentimento.
- Serviços de autenticação.
- Processos manuais.
Identifique quais fluxos dependem de ajustes recorrentes.
Documente o caminho dos dados
Registre:
- Onde o dado é criado.
- Onde é armazenado.
- Como é transformado.
- Quais sistemas o consultam.
- Quando é compartilhado.
- Qual consentimento sustenta o uso.
- Como é corrigido ou excluído.
Avalie o ciclo do consentimento
Confirme se a organização consegue relacionar cada compartilhamento ao consentimento correspondente.
Verifique também:
- Prazos.
- Finalidade.
- Escopo.
- Revogação.
- Histórico.
- Comunicação com o cliente.
Identifique dependências do core
Separe o que precisa permanecer no sistema central do que pode ser desacoplado.
Considere:
- Regras de produto.
- Emissão.
- Cobrança.
- Sinistros.
- Dados cadastrais.
- Integrações.
- Canais digitais.
- Relatórios.
Priorize os pontos de maior risco
Comece pelas integrações que apresentam:
- Maior volume.
- Maior dependência manual.
- Maior frequência de mudança.
- Maior impacto sobre clientes.
- Menor rastreabilidade.
- Maior concentração de conhecimento.
Defina critérios de arquitetura
Antes de escolher uma solução, estabeleça os requisitos mínimos.
Por exemplo:
- Segurança.
- Disponibilidade.
- Escalabilidade.
- Modularidade.
- Observabilidade.
- Controle de versões.
- Documentação.
- Capacidade de integração.
- Continuidade operacional.
Teste a coexistência
Quando a estratégia envolver uma camada intermediária, execute um projeto controlado antes de expandir.
Escolha um fluxo com relevância suficiente para validar a arquitetura, mas que não coloque toda a operação em risco.
Estruture a governança
Defina:
- Responsáveis.
- Processo de aprovação.
- Documentação.
- Indicadores.
- Rotina de atualização.
- Gestão de incidentes.
- Critérios de priorização.
Acompanhe os documentos oficiais
Os manuais e especificações do Open Insurance são atualizados periodicamente.
A operação precisa acompanhar:
- Novas releases.
- Cronogramas.
- Certificações.
- Mudanças regulatórias.
- Versões descontinuadas.
- Orientações da governança.
Estruture o próximo passo com critérios técnicos, regulatórios e comerciais claros.
Diagnóstico de maturidade para o Open Insurance
Antes de iniciar uma nova integração ou contratar uma plataforma, avalie as afirmações abaixo:
Marque os pontos que sua arquitetura já consegue atender de forma consistente.
0 de 10 critérios atendidos
Comece a avaliação
Marque os critérios atendidos para visualizar quantos pontos da arquitetura ainda dependem de avaliação.
Avalie a maturidade da sua arquitetura
Uma avaliação técnica pode ajudar a identificar se o cenário exige melhorias pontuais, uma camada de integração ou uma modernização mais ampla.
Conclusão
O Open Insurance entrou em uma etapa de evolução contínua no Brasil.
Os principais ciclos de implementação abriram caminho para um ecossistema baseado em dados, consentimentos, APIs e serviços integrados. A partir de agora, a capacidade de sustentar essa estrutura se torna tão relevante quanto a entrega inicial.
Para as seguradoras, isso exige mais do que conformidade pontual.
É necessário conectar:
- Dados.
- Consentimentos.
- Produtos.
- Sistemas internos.
- Canais.
- Parceiros.
- Regras.
- Monitoramento.
- Governança.
Uma arquitetura rígida pode continuar funcionando durante um período, mas tende a consumir mais esforço conforme surgem novas versões, integrações e jornadas.
A decisão entre manter a estrutura, evoluir gradualmente ou adotar uma plataforma especializada deve partir de um diagnóstico técnico e operacional.
Quando as integrações dependem de ajustes manuais, regras duplicadas ou conhecimento concentrado, uma camada de integração pode ajudar a organizar a evolução sem interromper o que já funciona.
A Tecnologia Única apoia seguradoras na avaliação da arquitetura, na integração de sistemas e na construção de soluções digitais preparadas para acompanhar o crescimento da operação.
Estruture os próximos passos considerando arquitetura, integração, operação e requisitos regulatórios do seu contexto.
Perguntas Frequentes (FAQ)
Não. A participação é obrigatória para as sociedades de maior porte enquadradas nos segmentos prudenciais S1 e S2. Para as demais seguradoras, entidades abertas de previdência complementar e sociedades de capitalização autorizadas pela SUSEP, a participação é opcional.
Corretoras não são automaticamente sociedades participantes. Elas podem ser impactadas pelo ecossistema, atuar em parcerias e, quando credenciadas pela SUSEP, exercer a função de Sociedade Processadora de Ordem do Cliente.
Os dois modelos permitem o compartilhamento padronizado de dados mediante autorização do cliente.
O Open Insurance é regulado pela SUSEP e pelo CNSP e abrange seguros, previdência complementar aberta e capitalização. O Open Finance é regulado pelo Banco Central e está relacionado ao sistema financeiro.
O escopo inclui dados públicos sobre canais e produtos, além de dados pessoais relacionados a cadastro, contratos, apólices, movimentações, sinistros, previdência complementar aberta e capitalização.
O compartilhamento de dados pessoais depende do consentimento do cliente e deve seguir os padrões técnicos aplicáveis.
Não. O compartilhamento de dados pessoais depende da autorização do cliente.
O titular deve receber informações sobre os dados, a finalidade, a sociedade receptora e o período de validade.
Sim. O cliente pode revogar o consentimento conforme as regras aplicáveis à jornada e ao tratamento dos dados.
A seguradora precisa garantir que a revogação seja refletida nos sistemas relacionados ao compartilhamento.
A Fase 3 permite iniciar serviços e movimentações dentro do ecossistema aberto.
Com ela, a jornada pode avançar do compartilhamento de informações para a execução de solicitações autorizadas pelo cliente.
Não necessariamente.
A seguradora pode integrar o sistema existente a uma camada intermediária responsável por APIs, canais e serviços. A viabilidade depende da arquitetura atual, da qualidade das interfaces disponíveis e das limitações do core.
SPOC é a sigla para Sociedade Processadora de Ordem do Cliente.
Trata-se de uma organização credenciada pela SUSEP para iniciar ordens autorizadas pelo consumidor no âmbito do Open Insurance.
Os principais marcos de implementação das três fases foram concluídos, mas o ecossistema continua evoluindo.
Em 2026, existem releases de melhoria, ajustes de regras, certificações e atualizações técnicas nas APIs.
Referências
[1] Superintendência de Seguros Privados. Plano de Regulação da SUSEP para 2026.
[4] Superintendência de Seguros Privados. Sociedades participantes do Open Insurance.
[5] Superintendência de Seguros Privados. Normas que regulamentam a implementação do Open Insurance.
[6] Superintendência de Seguros Privados. Manual de Segurança do Open Insurance.
[7] Superintendência de Seguros Privados. Manual de APIs do Open Insurance.
[8] Brasil. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais.
[10] Tecnologia Única. Herval e Proteo: a tecnologia por trás da nova seguradora.
PT 
EN 
ES 
FR 
IT 
DE 