Repensando seguros usando Event Driven Patterns

Este é um artigo traduzido originalmente publicado dia 09/03/2023 no blog do Naveen Nandan: "Rethinking Insurance using Event Driven Patterns". Siga o Naveen no LinkedIn para se manter atualizado com novas publicações.

Isenção de responsabilidade: Visão geral como cliente de seguros e como um processo de negócios pode ser modelado usando uma arquitetura orientada a eventos. Em outras palavras, eu sei tão pouco sobre esta indústria.

Meu entendimento ingênuo era que a indústria de seguros foi modelada com base em um princípio humano básico - "o medo de perder algo que pertence a você". Mas evoluiu para ser muito mais do que isso. Filosofia à parte, com a pilha de tecnologia moderna disponível hoje, vamos ver como um processo de negócios voltado para o cliente no domínio de seguros pode ser modelado usando uma abordagem orientada a eventos.

Nos seguros, os clientes assinam produtos chamados apólices e pagam um prêmio recorrentemente - mensalmente/anualmente, com o qual se comprometem por um período fixo ou de longo prazo, muito parecido com o Confluent Cloud ou qualquer outro software como serviço que usamos hoje. Normalmente, você faria isso por meio de um mercado on-line ou obteria a ajuda de um Agente em quem confia, com quem construiu um relacionamento e com quem pode entrar em contato/terá que entrar em contato com você caso tenha um problema relacionado a ser resolvido ou queira para saber mais sobre novos produtos/serviços, como seus executivos de contas ou SDRs para serviços de software.

Como cliente, você interage com o serviço para pagar esses prêmios regulares (ou registrar-se em um serviço de pagamento automático que pode fazer isso por você) ou para registrar reclamações de eventos que são suportados por sua apólice. Normalmente, o cliente e o agente são notificados quando um prêmio é pago, o pagamento do prêmio é perdido ou quando uma reclamação é feita e eventualmente resolvida e paga. Cada interação que o cliente faz com a plataforma pode ser tratada como um evento em tempo real que aciona um processo de negócios e eventualmente resulta em um evento de pagamento ou notificação.

Padrões Produtor-Consumidor para o ciclo de vida de pagamento Premium

Padrões Produtor-Consumidor para Pagamento de Prêmio e Notificações

Normalmente, os clientes usam um aplicativo/portal ou quiosques físicos para fazer pagamentos premium e isso, por sua vez, aciona um serviço de back-end que pode enviar esse evento de pagamento para um tópico Kafka. Na extremidade receptora, pode haver um serviço que notifique o agente de que um determinado cliente efetuou o pagamento do prêmio ou não o pagou e, por sua vez, envia um lembrete inscrevendo-se em eventos desse tópico. O serviço Produtor pode enviar o evento para o Confluent usando o protocolo Kafka nativo ou HTTP/S por meio de um Proxy/Gateway, e o serviço Consumidor, por sua vez, pode escolher:

• ouvir um novo evento premium pago e processá-lo

• solicite e verifique se há um novo evento premium pago por HTTP/S

• enviá-lo como um evento para um terminal de serviço HTTP/S

ROI para o negócio: verificações automatizadas em tempo real para pagamentos premium feitos e lembretes para pagamentos perdidos se traduzem em fluxo de caixa previsível. Tempo mais rápido para comercializar novos serviços seguindo padrões semelhantes.

Benefícios para o cliente: Melhores níveis de serviço e experiência.

Processamento de reivindicações usando processamento de fluxo

Processamento de Reivindicações via ksqlDB

Da mesma forma, as reclamações podem ser levantadas através da plataforma onde o valor da reclamação, tipo e vários outros parâmetros são verificados e validados antes de calcular o valor da liquidação e notificar um responsável para aprovação ou notificar o cliente.

Algumas dessas verificações/validações podem ser modeladas usando instruções semelhantes a SQL usando ferramentas de processamento de fluxo, como ksqlDB, onde os eventos levantados de reivindicações são a entrada para essas etapas e o evento de liquidação final gravado em outro tópico resultante.

ROI para o negócio: Retorno mais rápido para processar sinistros. Esforço humano reduzido - foco nas tomadas de decisão/aprovações. Atendendo aos níveis de serviço esperados.

Benefícios para o cliente: Retorno mais rápido para liquidação de sinistros. Maiores índices de satisfação.

Avaliação de risco

Cálculo de risco e correção de curso

Insira um novo LoB que deseja oferecer um novo serviço que calcula uma pontuação de risco com base nos prêmios pagos anteriormente e nas reivindicações levantadas para fazer ajustes dinamicamente no prêmio a ser pago - digamos, se as coisas estiverem boas - continue, se as coisas estiverem melhorando ruim - penalize e observe as melhorias. Muito parecido com um loop de feedback. Para isso, os dados de origem podem ser todos os tópicos em 1) e 2) acima com uma lógica de processamento um pouco mais complexa contida em um aplicativo Kafka Streams que faz esses ajustes dinamicamente.

ROI para o negócio: Reduz o risco de ter que liquidar grandes sinistros. Economiza $$$. Aumento do lucro líquido. Mais capital para novos investimentos.

Benefícios para o cliente: Prêmios com desconto.

Esta é uma visão rápida de como alguns processos comuns de negócios de seguros voltados para o cliente podem ser projetados usando uma abordagem orientada a eventos.

PS Resultado de um recente "quadro branco" + "conversas técnicas" + "pessoal de TI" com uma perspectiva de seguro.