In this episode of “The Digital Broker”, Steve and Ryan speak to Frank Sentner, the original founder of Sagitta ™ a legendary figure in the insurance industry. Frank is the owner of Sentwood Consulting and has been providing technology consulting and mentoring to individuals and companies in the insurance industry for 42 years.
By listening to this episode, you will learn:
- How ACORD pioneered the development of data standards
- How data standards have developed over time
- Whether the insurance market still needs data standards
- About the growing importance of Application Programming Interfaces (APIs) in the insurance market
- The latest developments in the insurance technology arena and the challenges faced by new players
- Tips to evaluate insurtech startups
Full Recap
Over the past four decades, there have been incredible technological advances and the insurance industry has been deeply involved in growing and changing with each advance. Frank Sentner has been there during every step of the way over the past 40 years, not as an observer, but as a leader of the development and implementation of technology within the industry. Technology continues to be developed, especially through entrepreneurial and innovative ideas developed in insurance technology startup companies and incubators. In this discussion, Ryan, Steve, and Frank discuss the growing use of APIs in the insurance sector as well as the future of data standards. In addition, the current state of developing insurance technology is examined with advice provided on how to evaluate which technologies are the right choice.
Who is Frank Sentner? (1:45)
Frank Sentner started out in sales for InsureNet, one of one of the earliest agency management software (AMS) providers. While at InsureNet, he created the first ACORD forms-based policy and claims administration system which mirrored the ACORD forms on green screens and allowed them to be printed on pre-printed forms using impact printers. After branching out on his own, Frank created the AMS software, Sagitta ™, which is now owned by Vertafore. Sagitta was built using the ACCORD AL3 EDI data standard, which remains in widespread use today. For the last 22 years, Frank has been working with insurance agencies, brokers, and carriers on systems integrations using ACORD forms. In addition, Frank enjoys mentoring insurance technology startup companies. Over the past four years, he has collaborated with ACORD on their innovation challenges which have exposed him to people advancing innovative ideas to address problems in the insurance space. Frank became a member of the steering committee which created the Hartford InsurTech hub, an initiative of a group of Connecticut insurance carriers and other executives, which is intended to build a culture of innovation in the Hartford area. In addition, he has worked with representatives from the state and local government, universities, and insurance companies as well as InsurTech Hartford to raise funds to operate the first InsurTech Accelerator in Connecticut.
Has the Industry Outgrown the Need for Data Standards? (6:50)
In an earlier episode of the Digital Broker, APIs and Why Your Agency Should Care, Ryan and Steve discussed how application programming interfaces (API) provide ways to automate the transfer of data and information between systems. Since the 1980s, the Association for Cooperative Operations Research and Development (ACORD), using the AL3 Data Standard, has been at the forefront of data standards and implementation solutions for the insurance industry. The forms developed by ACORD have long standardized applications for most insurance companies.
APIs have continued to develop over the years on a variety of platforms. An example which exemplifies the advance in the development of APIs is seen in the Zapier software, which offers over a thousand web-based platforms, allowing anyone using the Zapier interface to create a data connection. This advance in technology raises the question of whether data standards are still necessary. With the developments of API technology, users are no longer as concerned about data standards but rather being able to get the actual data into the platform application. Some argue that using ACORD AL3, a technology developed in the 1980s should give way to a more modern and easier to use technology. However, while the AL3 standard does date back to the 1980s, it should be noted that it has been updated continuously over the decades. The advancement of API functionality has been a significant development especially in the field of data integration. Improvements in API functionality has resulted in the recognition that the structural components of ACORD AL3 and ACORD XML are no longer as important as they were in the past. The critical item that the industry agrees that is needed currently is a common business glossary. Regardless of the advancement of API functionality, without a glossary providing normalized terminology, it is difficult for programs and users to understand the meaning of the data being sent and received. Frank points out that the API has all the “verbs” that it needs. The specifications for the API already support the required structure of the data, utilizing what is colloquially known as “CRUD” (Create, Read, Update or Delete). Both the ACORD messaging capability on the ACORD XML side as well as the hierarchy and data structure embedded in ACORD AL3 is irrelevant in a world that is supported by APIs. What is really needed is the terminology that will allow a program to identify the individual elements necessary to fulfill the required API dataset. There is a hope that developing Natural Language Processing technology will eliminate or at least minimize the need for the business glossary. The development of a data dictionary that could translate the terminology would eliminate the need for a glossary, but the technology is not yet there. There is a recognition within the industry that the goal is to develop and apply domain-specific terminology in the building of the API which could mitigate the need for translation by layers of Subject Matter Experts. ACORD development included the creation of a business glossary that was cross-programmed, international and technology agnostic.
Terminology within insurance specialties is not standardized. The life insurance industry often uses one term and the property/casualty industry uses another for the same concept. Words like “policy” and “agreement” often refer to the same thing. It likely is the wrong approach to try to translate generic language into something specific and unique for each insurance domain. The better approach may be creating a glossary with a myriad of synonyms for concepts that are domain specific yet point to the same essential data needed to be transferred. ACORD is the ideal body to bring representatives together from the various domains and industry partners to foster agreement on a universal business glossary with all required translations. The master glossary could be made a part of the API and achieve upwards of 90 percent accuracy in translation. This type of industry leadership could be the direction of ACORD for the future as well as developing new applications to further leverage APIs. An example of leveraging APIs is shown in ACORD’s e-forms residing in the cloud. The user simply must implement an API with the ACORD’s e-Forms to eliminate the need to store forms and ensure that the forms are current. This is a huge saving for the industry. There are industry-beneficial non-profit opportunities at ACORD but also profitable ventures for them as well.
How Would the Glossary/Data Dictionary Be Used? (18:20)
Most agencies would not use it, but their agency management system vendors would, although a lot of Sagitta users do their own data integration. There is an existing business glossary implicit within the ACORD XML standards and a full business glossary within the Reference materials at ACORD. It needs some development, but the essential backbone of the work is complete. An industry dictionary would need to be more robust than generic dictionaries, such as the one offered in MS-Word. An insurance data dictionary would require sufficiently discreet terms to avoid the concept identification and translation problems offered by synonym and homonyms.
What is the Biggest Challenge for New Players Joining the Industry? (21:10)
The biggest challenge for InsureTech startups is often missing real industry experience. There are some exceptions, specifically where people have come from within the industry to create startups. The fresh players entering the market often lack industry domain expertise as well as not having industry contacts. Ironically, one of the things that are beneficial for the startups to leverage is the time-tested ACORD AL3. ACORD helps in this situation through the providing technology that is perfect for both the initial load of data as well nightly process updating policy and claims information. This type of information is well suited for mobile apps and provides a low-cost solution for insurance carriers. The provider can send information to a mobile app provider and have them map it to their software, immediately producing a complete picture of an insured. This is an opportunity for insurance companies to provide both a retention as well as a cross-selling tool to their agents by simply closing existing data. This literally is functionality that can be off and running overnight. Mapping the data and creating the glossary is still necessary but the database is easily created.
How Should Startups Be Evaluated? (25:00)
InsureTech opportunities, when considered, need to be divided into two broad categories: risk mitigation and risk transfer. Most insurance agencies and insurance companies operate in the realm of risk transfer. Most InsureTech opportunities involve risk mitigation. Insurance carriers have largely exited the loss prevention and engineering services markets. Some entrepreneurial agents have picked up that business as a niche market, hiring engineers and loss prevention specialists to be able to offer a specialized service. A number of small to medium-sized businesses need risk mitigation services in order to reduce their risk transfer (insurance) costs. If a business is focused on lowering risk thresholds for insureds, then risk mitigation technologies should be considered. The caveat with risk mitigation technologies is if they are “active” such as a Nest thermostat, cyber liability is something that must be considered. Most risk mitigation technology is passive technology, so there is no risk of hacking.
The risk transfer area divides into three discrete categories: Firstly, the customer experience side which includes mobile apps, chatbots, artificial intelligence (AI) platforms for phones, text, and communications. A second area is in operational fulfillment which encompasses agency management systems and policy management systems. The third area is “big data” and AI which is better suited for the larger agents.
Entering the insurance technology area requires picking battles and deciding between risk mitigation side (“the safety side”) by helping to prevent loss or choosing the risk-transfer side by focusing on lowering costs and increasing customer engagement. One thing is for certain – there are a lot of new technologies out there providing many opportunities for the agency owners and the manager with an open mind in selling.
Start Using Indio Today
Find out why agents everywhere are talking about Indio.