Binding Quotes

Herald’s bind workflow enables you to transform a bindable quote issued by an institution into a full insurance policy. The bind workflow contains the following steps

1. Creating and completing a bind application
2. Submitting the bind application (initiating the bind process with the institution)
3. Completing any actions required before policy creation

Creating and Completing a Bind Application

Institutions often require more information beyond what was collected in the initial application to bind a quote. In some cases information that was optional as part of the quoting process becomes required as part of the binding process. For example, additional risk information about the insured, information about the producer, or even logistical information like payment details.

Herald uses the Bind Application to collect the information to initiate the bind process. Any requirements that are knowable BEFORE the bind process begins are incorporated into the bind application in preparation for communication with the carrier. In contrast, any requirements that are dynamic or only knowable in communication with the carrier are handled via the Policy entity and the Finishing the Bind Process step.

By calling [.h-code]GET[.h-code][.h-endpoint-link]/quotes/{quote_id}/bind_application[.h-endpoint-link] you can see a [.h-code]bind_application[.h-code] object that is attached to a [.h-code]quote[.h-code]. Here’s an example response:

Copied

{
    "bind_application": {
        "quote_id": "a0d7d67c-773d-41ab-8fe1-09ba7da5a141",
        "status": "complete",
        "products": ["prd_0010_herald_general_liability"],
        "coverage_values": [
            {
                "coverage_parameter_id": "cvg_o3mw_cyb_effective_date",
                "value": "2024-06-01",
            }
        ],
        "risk_values": [
            {
                "risk_parameter_id": "rsk_o1mw_cyb_effective_date",
                "value": "2024-06-01",
            }
        ],
        "admin_values": [
            {
                "admin_parameter_id": "adm_o1mw_cyb_effective_date",
                "value": "2024-06-01",
            }
        ],
    }
}
 

[.icon-circle-blue][.icon-circle-blue] The bind application is different from the application process used to get a quote. The two only interact in that a bindable quote is required to progress into the binding process.

‍

Creating and working with the Bind Application

When a [.h-code]quote[.h-code] has progressed to a [.h-code]status[.h-code] of “active” it will automatically have a [.h-code]bind_application[.h-code] attached to it; there is no need to explicitly create bind applications. The presence of the [.h-code]bind_application[.h-code] and the ability to progress in the bind process is explicitly indicated by the   [.h-code]bind_request_available[.h-code] field; when this status is true then the next step is to fetch the [.h-code]bind_application[.h-code] object by calling [.h-code]GET[.h-code][.h-endpoint-link]/quotes/{quote_id}/bind_application[.h-endpoint-link].

The bind_application contains any outstanding requirements in the form of risk_values and coverage_values arrays but also may require admin_values and files. See here for guidance on completing open requirements by Building a Dynamic Application. Once all information required is complete thenbind_application.status will be ”complete” and you are ready to progress to Submitting the Initial Bind Request.

‍

Working with bind application statuses

For more detail on the interaction between the [.h-code]bind_request_available[.h-code] and [.h-code]bind_application.status[.h-code] fields see the “Bind Applications” - Statuses  guide.

‍

Some more info on requirements in bind applications

In the illustration above, you can see that the information collected in the bind application includes:

• A risk parameter for an applicants phone number, which was previously optional in the application but required in the bind application.
• An admin parameter for payment plan, that was not relevant for the application but is required in the bind application.

It’s worth noting that unlike applications, bind applications tend to require much less information. You can imagine a bind application as a checkout experience where the remaining information is collected. If you are planning to bind policies through Herald, you should be familiar with risk and coverage parameters. When filling out a bind application to request a policy, the same complexities (such as conditionality) of our risk and coverage parameters apply.

‍

Automatic Pre-filling

Unlike the applications submitted to get quotes, a newly created bind application may have a status of complete before submitting any values. This is because Herald offers automatic pre-filling for bind applications. For example, some institutions will provide quotes without an effective date for the policy, meaning the value for effective date is optional in the application. Naturally, effective date becomes required to bind, meaning the value for effective date is required in the bind application.

If you choose to provide the effective date when it is optional, Herald will pre-fill this value in the bind application. For certain products, it is possible to have every required parameter pre-filled in the bind application, meaning the bind application would be complete at the time of creation. Obviously, you can change those pre-filled values when filling out your bind application if you need to.

‍

‍

How do you determine if an optional question on an application will be required later in a bind application? The [.h-code]required_for[.h-code] value in the application parameter will be set to “policy.”

Submitting the Initial Bind Request

After completing the bind application you need to initiate the bind process with the institution by submitting the completed bind application via the Policies endpoint. Start by creating a policy using [.h-code]POST[.h-code][.h-endpoint-link]/policies[.h-endpoint-link] with [.h-code]quote_id[.h-code] in the body.

Copied

{
    "quote_id": "497f6eca-6276-4993-bfeb-53cbbbba6f08"
}
 

This starts the communication process with the institution and creates a policy entity within Herald. You can see the [.h-code]policy[.h-code] object by calling [.h-code]GET[.h-code][.h-endpoint-link]/policies/{policy_id}[.h-endpoint-link][.h-endpoint-link]

Copied

{
    "policy": {
        "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",
        "quote_id": "68926946-e925-4e9a-9fa1-8e800a9d09f6",
        "coverage_values": [...],
        "bind_details": {
            "status": "accepted",
        }
        "policy_number": "EHJ-ADK00460738",
        "product_id": "prd_0050_herald_cyber",
        "prices": {
            ...
        },
        "prices_details": {
            ...
        },
        "portal_links": [...],
        "files": [...],
        "created_at": "2024-03-06T23:59:59Z",
        "updated_at": "2024-03-06T23:59:59Z"
    },
    "actions": [...]
}
 

All steps after the initial bind application submission are managed via the Policies endpoint and the [.h-code]policy[.h-code] object; the original [.h-code]quote[.h-code] will reflect status updates from the bind process but will no longer be used from an action or data perspective.

Finishing the Bind Process

The result of the initial bind request and progress through the bind process is managed via the [.h-code]policies.bind_details.status[.h-code] field. The process is sequential with each stage represented by the below statuses:

• “pending” - Waiting for institution response to initial bind request
• “requested” - Bind request received and acknowledged by the institution, but there are likely actions required in order to progress
• “accepted” - Carrier has officially confirmed intention to bind; any policy details provided at this point are included

All statuses (even “accepted”) may require additional information or action, such as payment information or agreeing to a set of terms and conditions, before it is possible to progress the bind request. Handling this is covered in the next section Interpreting and Working with Actions.

Interpreting and Working with Actions

Any additional information required to complete the bind process is expressed and managed via [.h-code]actions[.h-code] and their associated workflow. Conceptually, the presence of an uncompleted action indicates a scenario where the institution either:

• Requires more information before the bind process can continue (ex. “need more risk information about the insured before a binder can be issued” or “need supplemental contact information for the insured before policy can be issued”) OR
• Is expressing a condition or contingency of the current stage (ex. “the binder is confirmed but payment must be completed or the binder will be invalidated”)

A bind request with an outstanding action looks like this:

Copied

{
    "policy": {
        "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08",
        "quote_id": "68926946-e925-4e9a-9fa1-8e800a9d09f6",
        "coverage_values": [...],
        "bind_details": {
            "status": "requested",
        }
        "policy_number": "EHJ-ADK00460738",
        "product_id": "prd_0050_herald_cyber",
        "prices": {
            ...
        },
        "prices_details": {
            ...
        },
        "portal_links": [...],
        "files": [...],
        "created_at": "2024-03-06T23:59:59Z",
        "updated_at": "2024-03-06T23:59:59Z"
    },
    "actions": [{
            "id": "sfr4279a-5450-4e79-bcfc-e918b3c8a564",
            "status": "open"
        }
    }
}
 

‍

‍