Blockchain em seguros e insurtech para coordenar sinistros e pagamentos

O seguro começa antes do sinistro. A seguradora identifica o cliente e o interesse segurado, estima frequência e severidade, fixa condições, cobra um prêmio e reserva capital. Se ocorrer um evento, deve verificar vigência, cobertura, nexo causal, dano e possível fraude antes de pagar. Depois, recupera valores quando existe sub-rogação e compartilha parte do risco com resseguradoras.

Cada fase utiliza registros e participantes distintos. Intervêm corretores, peritos, oficinas, hospitais, provedores de dados, seguradoras e resseguradoras. Uma mesma perda pode afetar várias apólices ou camadas de cobertura. O desafio operacional está em relacionar identidade, contrato, evidência e responsabilidade sem duplicar informação nem antecipar uma conclusão que ainda exige julgamento.

Blockchain se encaixa quando várias entidades precisam observar o mesmo estado contratual ou conciliar a mesma exposição. Sua contribuição potencial é um histórico compartilhado e regras executáveis. A obrigação jurídica continua nascendo da apólice e da regulamentação. O código não pode ampliar uma cobertura, resolver uma cláusula ambígua nem decidir sozinho se uma declaração foi fraudulenta.

Em seguros, blockchain funciona como uma camada de estado e execução, não como a apólice completa. O contrato legal define direitos e exceções; o smart contract representa apenas as condições que podem ser expressas de forma determinística. Quando recebe dados suficientes, pode registrar o evento, calcular um valor e ordenar ou executar o pagamento conforme os controles estabelecidos.

Para conhecer o mundo exterior, ele precisa de um oracle, uma fonte ou um conjunto de fontes que informa chuva, voo, índice, localização ou qualquer outro parâmetro. A automação é tão confiável quanto a definição do índice, a qualidade dessas fontes e o procedimento para resolver uma leitura errada. Em produtos não paramétricos, a investigação e a avaliação do dano continuam sendo essenciais.

O modelo mais defensável combina código e processo. A rede conserva versões e evidências compartilhadas; a seguradora mantém seus controles de sanções, fraude, solvência e atendimento ao cliente; e uma via de exceção permite revisar o resultado. O objetivo é automatizar o inequívoco e tornar rastreável o discutível, não fingir que todo sinistro é uma condição binária.

Um seguro paramétrico não indeniza necessariamente o dano observado. Paga o valor acordado quando um índice supera um limiar, como precipitação em uma estação, intensidade de um ciclone, produtividade regional ou atraso certificado. Essa objetividade reduz a perícia e permite desembolsar cedo, algo valioso quando o segurado precisa de liquidez imediata.

A contrapartida é o risco de base. O cliente pode sofrer uma perda sem que o índice acione o pagamento, ou recebê-lo sem uma perda equivalente. A qualidade do produto depende de o parâmetro se relacionar bem com o risco, de a área e o período serem adequados e de a explicação comercial não confundir pagamento paramétrico com indenização do dano real.

Blockchain automatiza a execução e torna verificável qual dado e qual versão da regra foram utilizados. Por si só, não melhora o índice. Deve existir uma política para fontes ausentes, revisões oficiais, divergência entre oracles e eventos extremos fora do modelo. Quanto mais irreversível for o pagamento, mais robusta deve ser a governança do dado.

Compartilhar apólices, faturas ou eventos pode dificultar pedidos de indenização duplicados e alterações posteriores. Também permite demonstrar que informação estava disponível quando uma decisão foi tomada. Mas grande parte da fraude ocorre antes de o dado chegar ao registro, por meio de identidade sintética, dano provocado, documento falso ou conluio entre fornecedores.

Se uma fonte falsa assina um evento, blockchain conserva a falsidade com excelente rastreabilidade. A prevenção continua exigindo validação de identidade, análise, investigação e cooperação dentro dos limites de privacidade e concorrência. A rede pode fornecer evidência e evitar que cada entidade reconstrua o mesmo dossiê; não deve ser apresentada como um detector automático de intenção.

Blockchain oferece um estado comum quando seguradoras, distribuidores, fornecedores, clientes e resseguradores precisam verificar a mesma apólice ou o mesmo evento. As regras podem coordenar cobertura, evidência, reservas e pagamento, enquanto cada entidade conserva seus sistemas. A utilidade aumenta quando a condição é objetiva e diminui quando causalidade, dano ou conduta exigem julgamento profissional.

No seguro tradicional, apólice, evidência, decisão, pagamento e recuperação percorrem sistemas e organizações diferentes. Uma rede blockchain pode manter estados compartilhados e executar regras acordadas. Não elimina investigação nem atendimento ao cliente, mas reduz a conciliação em processos repetíveis e deixa um histórico verificável de quem declarou, validou ou autorizou cada etapa.

O aviso abre um processo, mas não determina o pagamento. A seguradora verifica vigência, identidade, cobertura, exclusões e documentação; reserva uma estimativa; investiga quando cabe; calcula a prestação; paga; e pode recuperar junto a terceiros. Em saúde, automóvel ou responsabilidade civil, vários fornecedores acrescentam evidência e a causalidade raramente é um simples dado.

A DLT pode manter um estado comum, evitar solicitações repetidas e registrar quem forneceu cada documento. Os smart contracts podem executar etapas determinísticas, como verificar prazo, detectar duplicidade, reservar fundos ou distribuir um valor já aprovado. A decisão que afeta o cliente deve conservar explicação, responsável e direito de reclamação.

A melhor automação não elimina todas as revisões. Direciona os casos simples por uma via rápida e escalona as inconsistências. O desenho inclui reversão contábil, correção de fontes, fraude posterior ao pagamento e continuidade se a rede não estiver disponível. Um pagamento rápido que não pode ser explicado nem contestado transfere custo operacional para risco de conduta.

Em resseguro, cedente, corretor e ressegurador trocam contratos, bordereaux, prêmios, sinistros e recuperações. A informação chega em momentos e formatos diferentes e pode exigir meses de conciliação. Um registro comum pode vincular cada movimento à versão contratual aplicável e mostrar qual parte está aceita ou em disputa.

A dificuldade não é só técnica. Os tratados contêm limites, agregados, reintegrações, moedas e cláusulas que exigem interpretação. Além disso, as carteiras contêm informação comercial e pessoal que não deve circular entre concorrentes. A arquitetura costuma ser permissionada, com visibilidade seletiva e documentos detalhados off-chain.

A automação é útil para cálculos e movimentos aceitos, enquanto controvérsias e mudanças de estimativa conservam intervenção. O benefício se mede em fechamento mais rápido, menos diferenças, melhor visão de acumulações e menos capital retido, não em substituir o ressegurador por código.

A fraude custa cerca de 308.600 milhões de dólares por ano só nos EUA, segundo a Coalition Against Insurance Fraud em 2022. O número explica o interesse em compartilhar evidências e detectar duplicidades. Não demonstra que toda automação reduza fraude, porque identidade, causalidade e conluio podem falhar antes de um evento chegar ao registro.

A Etherisc e a ACRE Africa documentaram o uso de contratos inteligentes para seguro agrícola indexado no Quênia. A Ethereum Foundation descreveu em 2021 como o projeto conectava o cadastro de agricultores, dados meteorológicos e pagamentos. É um caso de implementação em um contexto específico. Avaliar sua transferência para outro mercado exige revisar distribuição, qualidade do índice, custos e acesso efetivo ao dinheiro, sem presumir percentuais universais de economia.

A adoção institucional, no entanto, continua em uma fase inicial em comparação com tecnologias como analytics, IA ou IoT. A EIOPA aponta que muitos desenvolvimentos europeus ainda são provas de conceito ou implantações pequenas. A evidência disponível demonstra viabilidade em processos específicos, não uma substituição geral dos sistemas de apólices e sinistros.

Nem todos os seguros se comportam da mesma forma. Um atraso de voo ou um índice meteorológico podem ser verificados com uma fonte acordada. Um dano em automóvel exige relacionar acidente, peças, reparo e possível responsabilidade. Uma cobertura de saúde incorpora necessidade médica e dados especialmente protegidos. Vida e responsabilidade civil podem depender de documentação e de decisões jurídicas prolongadas.

A programação deve ficar no ponto certo. Em um produto paramétrico, pode calcular toda a indenização; em um seguro indenizatório, talvez apenas valide a apólice, reúna evidências e distribua um pagamento já aprovado. Em resseguro, pode calcular participações aceitas sem decidir uma cobertura controversa. Apresentar todos esses processos como pagamento automático esconde a diferença entre evento, perda e obrigação.

A tabela de decisão combina objetividade do gatilho, qualidade da fonte, possibilidade de correção, impacto para o cliente e necessidade de julgamento. Quanto maior a ambiguidade, mais útil é a tecnologia blockchain como trilha compartilhada e menos adequada como executora irreversível. A maturidade não consiste em eliminar pessoas, mas em reservar sua intervenção para exceções que realmente exigem critério.

Um smart contract pode determinar que existe uma obrigação e enviar uma instrução a um sistema de pagamentos convencional. Também pode transferir dinheiro tokenizado se o produto, a entidade e a jurisdição permitirem. No primeiro modelo, a rede e o banco conciliam o resultado. No segundo, o ativo incorpora risco de emissor, custódia, liquidez e resgate.

Prêmios e indenizações estão sujeitos a moeda, impostos, sanções, prevenção à lavagem de dinheiro e proteção do cliente. Uma stablecoin não transforma automaticamente um pagamento internacional em dinheiro sem risco nem autoriza a seguradora a operar fora de sua licença. O beneficiário pode precisar de moeda local e de um canal de reclamação, mesmo que a movimentação on-chain seja final.

A liquidação atômica é mais relevante entre entidades que trocam posições e caixa, por exemplo em determinados fluxos de resseguro. Para o cliente de varejo, costumam pesar mais a disponibilidade, a reversão em caso de erro, o custo e a facilidade de acesso. A camada de pagamentos se escolhe depois de desenhar o produto de seguro, não o contrário.

Os usos com maior fundamento compartilham regras objetivas, dados governados e vários participantes que precisam verificar o mesmo estado. Seguros paramétricos, resseguro, certificados de cobertura, sub-rogação e reclamações simples podem se beneficiar. Os sinistros complexos continuam exigindo investigação, perícia, atendimento ao segurado e um canal claro para corrigir ou contestar decisões.

Uma arquitetura de produção conecta administração de apólices, sinistros, pagamentos, identidade, fornecedores e reporting. A DLT guarda estados ou provas que várias partes precisam verificar. Documentos, dados de saúde, telemetria e processos completos permanecem normalmente off-chain, sob permissões, retenção e retificação.

Os oracles exigem redundância, controle de mudanças e rastreabilidade. É preciso saber quem publica, com que frequência, o que acontece em caso de divergência e se o dado pode ser revisado depois. Um contrato não deveria executar uma obrigação material com base em uma API sem procedimento de contingência. A fonte faz parte do produto e do seu risco operacional.

Chaves e wallets também não podem bloquear direitos. O cliente precisa de recuperação, representação e canais alternativos. Em redes entre entidades, a governança define a entrada de nós, versões, resposta a incidentes, correções e saída. Distribuir a validação não elimina o controlador dos dados nem a seguradora obrigada perante o tomador do seguro.

Um piloto começa com uma regra objetiva, dados históricos suficientes e um grupo claro de segurados. Compara tempo de pagamento, custo de processamento, taxa de erro, risco de base e reclamações em relação ao processo atual. Também simula fonte ausente, dado corrigido, sanção, fraude e falha tecnológica.

Em resseguro ou em processos compartilhados, importam as conciliações eliminadas, a velocidade de fechamento, a completude e o tempo de integração de parceiros. Se a rede exige duplicar todos os registros ou as disputas continuam sendo resolvidas fora sem reflexo no registro, o estado on-chain perde autoridade operacional.

Escalar exige governança de produto, modelo atuarial, distribuição, suporte e capital, não apenas contratos auditados. A tecnologia blockchain merece permanecer quando reduz uma fricção multilateral ou viabiliza um produto que não era possível. Se uma API com assinatura e um operador reconhecido oferecem o mesmo resultado, essa costuma ser uma opção mais simples.

Em um seguro paramétrico, o teste deve comparar o gatilho com perdas conhecidas para entender o risco de base. Pode haver dano sem acionamento ou acionamento sem um dano equivalente. O objetivo não é eliminar essa diferença por software, mas medi-la e explicá-la antes da contratação. O dossiê deve conservar a fonte do índice, sua versão e as regras para dados ausentes ou corrigidos. Também deve ser testado o que acontece quando o provedor de informação deixa de responder durante o período coberto.

A execução precisa confirmar que existe cobertura vigente, que o prêmio foi tratado conforme o contrato e que o pagamento ainda não foi realizado. Depois, conecta o cálculo a fundos disponíveis e a um beneficiário verificado. Uma instrução repetida não deve gerar outra indenização. Se o pagamento falhar, o segurado mantém um canal de informação e reclamação, e a obrigação pendente permanece visível. A rapidez se mede até a disponibilidade do dinheiro, incluindo controles e exceções, não apenas até o contrato emitir um evento.

A lacuna de proteção da Swiss Re é uma estimativa modelada de necessidades de cobertura, diferente de somar as perdas não seguradas observadas em um ano. Da mesma forma, o cenário de automação da McKinsey inclui tecnologias e mudanças operacionais mais amplas que blockchain. Essas referências situam o problema do setor segurador, mas o projeto deve demonstrar sua própria melhoria em cobertura, gestão e custo. A comparação precisa manter a mesma população segurada e as mesmas condições de apólice para ser interpretável.

O MiCA regula criptoativos, não produtos de seguro. Uma seguradora que adota blockchain continua sujeita ao marco setorial, incluindo Solvência II, e às obrigações de resiliência digital do DORA sob supervisão competente, além de proteção de dados e conduta. O MiCA entra em cena se a estrutura incorporar um criptoativo regulado.

O MiCA só entra em cena se a solução usar um criptoativo, por exemplo uma stablecoin para pagar prêmios ou indenizações. Distinguir o produto de seguro do veículo tecnológico, e aplicar a cada um sua norma, é o ponto de partida de qualquer projeto.

A automação não reduz as obrigações de informação, adequação do produto, gestão de reclamações nem supervisão de fornecedores. Na União Europeia, o DORA inclui seguradoras e resseguradoras em seu marco de risco de TIC e resiliência. Operar nós ou depender de oracles e custodiantes exige inventário, contratos, testes, continuidade e reporte de incidentes, conforme o caso.

Um produto paramétrico deve continuar sendo um seguro corretamente desenhado e distribuído. O cliente precisa compreender o índice e o risco de base. Se, além disso, uma participação econômica for tokenizada, uma mútua descentralizada for criada ou ativos digitais forem empregados, podem se somar normas de valores mobiliários, criptoativos, pagamentos e prevenção à lavagem de dinheiro. A classificação se faz por funções e direitos, não por chamar o código de insurtech.

A maioria dos clientes não consegue auditar um contrato inteligente e, mesmo que conseguisse, o código não contém necessariamente toda a apólice. Condições, exclusões, definição do índice, fontes, taxas e procedimento de reclamação devem ser comunicados em linguagem compreensível antes da contratação. Uma interface que esconde blockchain não pode esconder as consequências do produto.

Toda decisão automatizada com efeito significativo precisa de rastreabilidade e supervisão conforme o marco aplicável. O segurado deve saber qual dado acionou ou impediu a indenização, como corrigi-lo e quem responde. Se o oracle modificar uma observação ou duas fontes divergirem, a plataforma deve conservar as versões e suspender ou revisar a execução quando for o caso.

A inclusão financeira também não se presume. Um pagamento móvel rápido pode ser valioso no agronegócio ou em catástrofes, mas o produto deve considerar conectividade, letramento, custódia, taxas e conversão para moeda utilizável. A eficiência só é real se o cliente recebe uma cobertura adequada e pode exercer seus direitos sem dominar wallets ou redes.

A tecnologia pode tornar uma regra mais rápida e auditável, mas não transforma uma cobertura ruim, um índice frágil ou uma decisão injusta em um bom produto. Também não determina causalidade, não avalia danos complexos, não evita uma identidade falsa nem garante que o dado do oráculo represente a perda real sofrida pelo segurado.

Estes conceitos distinguem cobertura contratual, evento medido, dano real, fonte de dados e mecanismo de pagamento. Também separam automação de decisão, paramétrico de indenizatório e registro compartilhado de dinheiro tokenizado. Essa precisão permite avaliar uma proposta sem presumir que um smart contract substitui a apólice, o perito ou a supervisão do setor segurador.