Herald Changelog

Cyber Insurance

We recently launched our first carrier for our fourth line of business: Cyber. As businesses invest more and more in technology and attackers get more and more sophisticated, cyber events have become one of the fastest-growing categories of risk. As a result, more small businesses either choose to carry cyber insurance or are compelled to in the terms of their contracts with key customers. In turn, our distribution partners frequently request that Herald support Cyber quotes on our platform.

Here are some of the updates we made made to support Cyber:

• We added new Cyber risk parameters.
• We created a standard set of Cyber coverage parameters across multiple carriers’ products.

Fixes and Improvements

In addition to adding a new line of business, we made various fixes and improvements to Herald:

• We added a new internal feature that allows us to more safely and efficiently manage how producers are authenticated with carriers when they request quotes. This internal feature lays down the foundation to eventually externalize this function for distributors who want to add and manage producers programmatically in the future.
• We standardized how we handle “data coercion” across carriers. Data coercion allows us to nudge coverage values from what our distributors request towards the closest acceptable value for each insurance carrier.
• We also updated how we handle coercion scenarios where one coverage value is related to another. For instance, some General Liability carriers require that the “General Aggregate Limit” be exactly 2x the “Each Occurrence Limit.” Now Herald takes a standard approach towards updating the most important coverage values first and cascading the consequences of that value from there.

‍

Preparing for scale

As more distributors and carriers join Herald, it becomes important to update our team, processes, and technology to support the growth of our ecosystem. This sprint, we focused on making updates to our infrastructure that enables us to scale:

• We automated parts of our data pipeline to enable our team to more quickly integrate new products.
• We launched an internal tool that improves how we manage the relationships between our customers, enabled producers, and the insurance products those producers are authorized to quote and bind. This tool allows our customer success team to react more quickly to requests and helps our engineers focus on building new features.
• We improved our authentication and authorization for better performance and security.
• We added useful metadata to our alert suite that allows us to automate messages at a higher level of precision.

That said, we’re always improving our insurance capabilities:

• We added support for several more General Liability class codes, including: Appliance installation, Freight Forwarding, Interior Decorating, Furniture manufacturing, and Excavation.
• We made adjustments to how we gather information on full-time and part-time employees for Workers’ Compensation policies.
• We updated the “data coercion” rules for our BOP products. Data coercion allows Herald to find the closest match for the set of requested coverage parameters with each carrier partner.

We also launched a News page on our website for other updates about Herald from both the press and our team’s blog.

Fixes and improvements

We also made a couple of small fixes and improvements to the Herald platform:

• We fixed a bug that would cause an error when effective dates were (way) too far in the past.
• We updated the http error code when certain child parameters were missing from 500 to 400.
• We fixed a bug that retried failed webhook notifications for customers who do not have webhooks enabled.

‍

Thank you for your patience here. This entry is about a week late because your beloved author was traveling to sunny San Diego. But this one is worth the wait, because we launched three big features.

1. Another BOP carrier

Markel’s Business Owners’ Policy (BOP) product is now available through Herald. Not only does this addition expand our BOP appetite, but it also represents the first carrier with two separate products available through our API. This title won’t belong exclusively to Markel for long; we’ve got a long list of carriers with multiple automatically-underwritten products that we’re integrating as quickly as possible.

2. Webhooks

When you create a submission through Herald, we immediately return a quote id for every product you’ve requested. Today, our customers use that id to poll our API (using the GET /quotes endpoint) and check each quote’s status. When the quote status moves from “pending” to “active” our customers can show the price.

This approach required our customers to write polling logic that can be frustrating to build and maintain. With webhooks, we remove this frustration by returning push notifications for certain events. To start, Herald will send notifications when quotes change status. In the future, we will use this same infrastructure to send notifications for other events.

3. "Conversational" applications

Our customers build applications that collect information about a business and submit it to carriers through Herald. But building an application that collects all of the required information for a submission is a complex task. Today, our customers must account for the following four elements in their applications:

1. Questions: The user must answer all the risk and coverage questions that carriers require to get a quote for their product. This list grows when getting quotes for multiple products.
2. Conditionality: You have to show users additional questions according to conditional logic. For example, some questions are only relevant for businesses within a certain state or industry.
3. Validation: Risk and coverage values must be sent to Herald in a valid format so that we can send that information to all relevant carriers at the correct level of specificity.
4. Maintenance: These elements shift as carriers change questions, validation rules, and conditional logic over time.

Last week, we launched a new “conversational” application endpoint (/applications) that removes the burden of these four elements from our customers. This endpoint receives any known information about the applicant, and returns the full list of required questions to render on screen for the user. Our customers can iterate on this process until the application status becomes “complete.” At this point, the application can be submitted and the user can receive quotes.

This feature is currently available in beta. If you are interested in trying it out, or learning more, please reach out to us at hello@heraldapi.com.

Fixes and improvements

In addition to Markel’s BOP product, webhooks, and the /applications endpoint, we also made various other fixes and improvements:

• We added support for multi-location, multi-building BOP submissions.
• We updated the quote status for certain classes of business to “unsupported” when applying for BOP products. We will support more and more of these classes over time.
• We updated the flowchart in our API documentation to reflect the “unsupported” status.
• We updated our documentation to reflect the /applications endpoint (in beta).
• We edited the documentation around the /submissions endpoint for brevity and clarity.

‍