AI智能总结
Guidewire 软件高级分析高级总监 Chris Cooksey 在我们之前的白皮书中你真的有数字战略吗 ?我们讨论了互操作性的问题,即保险生态系统中各种模型和系统之间普遍存在的连接不足。这是一个广泛的话题,可以从多个角度来考虑它。无论从哪个角度来看,与其他行业参与者合作所面临的痛苦阻碍了资本的高效使用和市场的有效性。 在讨论如何解决保险行业互操作性不足的问题时,我们使用了“吃大象”的比喻,指出这不能一次性完成,而是“一口一口来”。在本文中,我们借鉴了另一个不同的“吃大象”比喻。1那就像盲人摸象的故事中所描述的那样,每个盲人只触摸到大象身体的一个部分,认为自己摸到的部分就是整个大象。只有通过交流和比较,他们才能开始了解这头动物的真正面貌。 在这篇论文中,我们探索了互操作性的四个不同领域——个人险种参与、商业险种数据、B2B以及再保险——以了解挑战的范围并开始构想潜在的解决方案。 它值得注意的是,从总体上看,数据通常从被保险人流向保险公司,并进一步流向监管机构和再保险公司,而来自预测模型的信息和见解则反向流动。这种互操作性的双向性质有助于进行区分。 无论从哪个角度审视,与其他行业企业合作所带来的痛苦都妨碍了资本的有效利用和市场的有效性。 个人线路参与 : 我们可以通过更少的摩擦来变得更好吗 ? 随着互联网的普及,数字化成为下一个重大创新,并且随着时间的推移变得越来越复杂。如今,通过供应商解决方案和可用的数据,消费者只需输入姓名、地址和驾驶执照即可获得准确的保险报价。他们还可以直接在线访问其保单信息。 考虑个人保险业务中信息流与消费者之间的关系。为了签订保险合同,保险公司必须首先获得足够的关于所覆盖风险性质的信息,而消费者则需要适当的信息来做出关于保险范围、限额和免赔额的决策。数据需要单向流动,而保险公司的信息则需要反向流动。这使得数据方面的问题变得更加复杂,因为个人保险业务公司必须在高效的信息收集需求与客户体验之间寻求平衡。 它可能有助于将这个问题视为两个问题——一个是众多保险公司试图从众多被保险人那里获取数据,另一个是为被保险人提供一种获取所需信息的方式。在数据方面,每家保险公司都规定了他们所需的资料格式,被保险人必须相应地调整其信息。在这种情况下,保险公司通过代理人、易于使用的呼叫中心或高质量的数字界面等方式,能够在这一过程中获得竞争优势。 对于这个问题,许多几十年来它都是通过人类手动收集信息的方式来解决的——这是大多数互操作性问题最初被解决的方式。保险代理人会逐项回答预设的问题列表,并手工记录答案,同时向客户解释相关产品信息。后来,行业引入了直接面向消费者的呼叫中心,这有助于降低运营成本,但并未从根本上改变信息交换的本质。 解决这一问题的方法应该是以成本高效的方式为客户提供所需的支持,从而满足保险公司的需求,这将是最佳方案。显然,技术为保险公司提供了更多的选择。一个强大可靠且能够以满足客户方式提供所需信息的生成式AI版本,有可能改变个人保险的销售方式。 商业线路数据 : 数据聚合器能解决问题吗 ? 尽管数据聚合商的作用日益重要,商业险种领域仍然存在“多供多需”的问题,尽管信息流动的两端都变得更加复杂精细。这种两家企业之间需要交换信息的问题因隐私考虑而变得更加复杂,但技术解决方案也更加广泛多样。 商业保险展示了解决互操作性问题的另一种潜在解决方案。商业险业务与个人险种有很多相似之处,尽管确定风险所需的资料更为复杂。例如,一份住宅保险报价需要了解住宅物业的特点,而商业财产保险报价则可能需要关于成千上万个地点(无论是详细信息还是汇总信息)的信息,以及关于公司及其子公司的信息。 未来解决方案将有助于消费者更好地利用来自众多信息源的见解。Guidewire 的方法在于其“记录系统到洞察系统的approach”,这也是其收购HazardHub, Inc.的主要策略。 要求投保人自行收集和提供所有所需信息将是一个耗时且低效的过程,对客户来说并不理想。这为供应商创造了市场机会,通过整合必要的数据以供风险评估和承保使用来增加价值。诸如邓白氏、穆迪、CoreLogic、益百利、埃奎福等公司能够使保险公司根据需要获取关于投保人的详细且汇总的信息。 值得从具体写作个人保险和商业保险的例子转向更一般的问题,即保险B2B : API 让我们谈谈, 但我们知道该说些什么吗 ? 公司与其他企业实体交换信息。 现代保险市场充满了提供各种服务的供应商,这些服务远远超越了基本的数据提供。考虑光学字符识别(OCR),这一能力通过使索赔处理更快捷以及数据录入更准确,已经彻底改变了保险业的文档处理方式。或者考虑预测分析,它使保险公司能够更精确地定价并更高效地运营。保险公司的数据分析需求包括用于分析数据的平台。and由此生成的预测模型。每个模型都需要连接到保险公司的系统,但方式非常不同。这些平台需要访问大量数据,但预测模型需要集成到实时的保险工作流程中。 这里我们看到,供应商几乎可以默认提供一种数据标准,使保险公司能够遵循这种标准以实现高效的数据流动。同时,随着可用数据范围的不断扩大,保险公司必须与越来越多的各方建立连接并进行整合,包括保险生态系统之外的供应商。当使用一组一致的供应商时,可用数据的变化也会导致标准不断变化。 每种情况都需要独立的计算机系统进行“交流”,以通过交易双方都能利用的方式共享信息。交互的目标是为保险公司运营提供信息或见解。发送一个PDF文件,然后通过OCR返回其电子副本。发送理赔信息,并从预测模型中获得成功追偿的可能性。 再保险 : 复杂的关系意味着需要更多的沟通 保险生态系统中各参与方之间的互操作性在面临不同供应商的多样化要求以及数据量大且复杂的情况下显得尤为挑战。通用化的工具能够使保险公司将其自身数据模型转换以符合多种标准,从而简化这一过程。这种工具可能对再保险生态系统产生何种影响? 初期定制化的系统集成在20世纪90年代促成了早期的互操作性标准,而互联网的兴起则带来了基于XML和服务导向(Web服务)的新协议。类似地,移动应用的需求推动了当前RESTful API(应用程序编程接口)的标准。这一过程持续发展,但标准的概念本身源于对普遍挑战的一种通用解决方案:系统集成。 在深入思考这一问题时,理解准确定价再保险合同所涉及的复杂性是非常有帮助的。再保险结构的多样性意味着这个问题远不止是从主要保险公司获取数据那么简单。再保险经纪人作为可信赖的合作伙伴,为许多保险公司提供的价值远不止于数据整理。然而,获取可用于实际操作的数据集所需的繁琐工作仍然是再保险收购过程中一个公认的问题点。 我们强调APIs,因为它们是解决互操作性问题的一种自发解决方案,这一解决方案随着技术的发展和需求的变化而不断演变。然而,允许系统之间进行通信仅仅是问题的一部分。APIs就像一种通用语言,但在交易中实现有意义的信息交换时,每一方都必须符合其他各方的预期。 例如,以Supercede这家供应商为例,它提供一个数据平台来促进再保险交易。其解决方案允许主要保险公司迅速组织和结构化其数据,并将其与各种再保险结构对齐。然而,Supercede用于向保险公司提供洞察的数据源自保险公司的核心系统。虽然从一个系统下载数据并在另一个系统中上传数据在短期内可行,但这种方法无法代表最高效的途径。构建系统之间的互操作性将惠及所有人,并使专家能够专注于风险转移的基本问题。 我们认为生成式AI可能会改变这一动态,因为其核心能力在于理解上下文。在当前的方法中,一行代码中的单个错误可能会使整个集成失效。相比之下,生成式AI可能能够使集成的方式更加灵活,通过表达集成的意图并由AI转换器处理具体的转换,从而实现集成的意图。Guidewire正在试验这样的工具,以确定它能否处理各种集成,从而使每个集成更具通用性且更易于实施。 我们也应记住,信息流动并非单向的。数据流向再保险公司,而再保险公司则可以分享其见解。尽管原保险公司在他们承保的风险方面具有复杂的视角,再保险公司和经纪人也同样了解这些风险,并且是从不同的角度来理解的。如果这些见解得以共享,原保险公司将获得多种视角以更好地管理自身风险,从而有助于降低整体的承保风险。从行业角度来看,更大的知识共享可能导致保险资本更高效的分配。 这是因为多种原因,最主要的一点是我们认为自身的独特性是竞争优势。从某种角度来看,它们确实可能是优势。使用代理来收集个人保险客户的资料是一种低效的方式,但代理仍然存在,因为它们为客户提供了一种其他分销渠道无法提供的价值。这不仅仅关乎效率。 为了理解互操作性挑战的范围并展示潜在解决方案部分影响,本文聚焦于四个案例。这些案例包括使客户能够以他们偏好的格式提供和接收信息的接口、聚合数据以高效地提供客户原本认为过于繁重的信息的供应商、采用已成为保险行业乃至更广泛领域标准的API协议,以及分享数据和见解以优化资本和人才。 指导软件采用平台化的方法整合预测模型的输出,这可以使再保险商和经纪人获得的洞察力应用于业务流程。通过建立可靠且可重复的信息分享方法,可以改变信息流动的方向,使其变得一致和高效。 不断变化的技术和人工智能的进步可能挑战我们对数据和见解交换的假设。创造力和主动性将使行业不仅仅实现渐进式的改进,而是能够创造整个行业的共同价值。当今可用的技术和数据类型创造了一种环境,使得重新构想我们彼此合作的方式成为可能,这些方式既能保持每家公司的竞争力,又能更轻松地交换信息。如果我们以协作的精神面对互操作性的挑战,致力于更好地服务客户并促进保险资本的有效使用,那么在保险领域最大化互操作性互惠利益的实际进展就可以取得。 Conclusion 保险之所以能够运作,是因为我们找到了转移信息问题的解决方案,从而能够理解和定价风险。然而,我们的解决方案一直受限于当时的科技水平,随着这些能力的扩展,我们的解决方案也随之改进。尽管如此,普遍认为生态系统中的低效率仍然高于应有的程度,这在很大程度上是由于互操作性不足所导致的。