Workflow

Smart Platform’s workflow manages the lifecycle of insurance policies, from initial quotes through to binding and potential modifications. It handles policy versions, state transitions, and role-based access control to ensure proper insurance operations.

Core concepts

Policy lifecycle states

A policy in Smart Platform progresses through these sequential states:

  1. Draft

    • The user creates the initial version of the policy or placement.

    • All fields are editable during this stage.

    • The system performs only basic validation.

  2. Submitted

    • The system validates the policy and marks it as ready for review.

    • The user has completed all mandatory fields.

    • The system evaluates referral conditions.

  3. Referred

    • An underwriter reviews the policy at this stage.

    • The system identifies that additional checks are required.

    • Special conditions may apply based on the referral.

  4. Accepted or declined

    • The underwriter makes a decision to accept or decline the policy.

    • The underwriter sets the terms and conditions.

    • The system documents the final decision.

  5. Firm order noted

    • The broker confirms acceptance of the terms.

    • The system locks the agreed terms.

    • The policy is now ready for binding.

  6. Bound

    • The policy becomes active.

    • Any changes now require formal endorsements.

    • The system maintains a full audit trail of all actions.

  7. Not Taken Up

    • The process terminates without activation of the policy.

    • The system documents the reason for termination.

    • No further changes are permitted.

  8. Archived

    • The policy is no longer active.

    • The system retains it as a historical record.

    • Users can access the policy for reference only.

Version types

Policies can have three types of versions:

  1. Base version

    • The policy includes foundational information in this version.

    • It outlines the initial terms and conditions.

    • This version serves as the starting point for any future changes.

  2. Endorsements

    • The user makes modifications to the active policy.

    • These changes are time-bound and apply for a specific period.

    • The system enables delta tracking to capture differences from the base version.

  3. Cancellations

    • The policy undergoes early termination.

    • The system performs pro-rata calculations to adjust premiums or refunds.

    • This stage reflects the final state changes to the policy.

Workflow process

1. Draft to submitted

Initial state: Draft

  • The user creates the policy with a base version.

  • The user must complete all mandatory fields.

  • The policy dates must fall within a valid range.

  • An assistant or broker can edit all fields at this stage.

Gates to progress:

  • The user has filled all required data points.

  • The policy has passed basic validation rules.

  • The system confirms that the dates are within the allowed range.

2. Submitted to referred

Initial state: Submitted

  • The system locks the policy for assistant edits.

  • The system evaluates referral conditions automatically.

  • A broker or underwriter can still modify the policy.

Referral evaluation:

// Example of referral condition
when insured.country == "Russia"
    then refer with "Insured country is Russia"
else "Insured country is not Russia"

3. Referred to accepted/declined

Initial state: Referred

  • The system locks the policy for assistant edits.

  • The underwriter is enabled to review the policy.

  • The system provides full data visibility for assessment.

Decision requirements:

  • The underwriter completes their assessment.

  • The underwriter sets the terms and conditions.

  • The system documents the decision.

4. Accepted to firm order noted

Initial state: Accepted

  • The underwriter has set the terms.

  • The system enables the broker to review the terms.

  • Any changes will require a re-referral.

Progress requirements:

  • There are no outstanding required data fields.

5. Firm order noted to bound

Initial state: Firm order noted

  • All parties have accepted the terms.

  • The system performs final validation.

  • The policy is prepared for binding.

Binding requirements:

  • The policy dates are valid.

  • The system confirms premium details.

  • There are no outstanding referrals.

  • The version status is marked as bindable.

6. Binding process

The bind{} goal represents the final activation stage:

@adjustable
bind = {};

Binding components

  1. Prerequisites

    • The policy must be in the Firm Order Noted state.

    • All data must be validated.

    • There must be no outstanding referrals.

    • The policy version must be marked as bindable.

  2. State changes

    • The system locks the version to prevent further edits.

    • The system sets the binding date.

    • The policy enters its initial bound state.

  3. Version management

    • The system creates a binding record.

    • It establishes the foundation for future endorsements.

    • The bound state is preserved for reference.

  4. Data preservation

    • The system captures all policy values at the time of binding.

    • It establishes a baseline for future changes.

    • Delta calculation is enabled to track differences from the bound version.

7. Endorsement management

Endorsements use a sophisticated delta calculation system:

  1. Version datapoints

    @derived version.limit = policy.limit;
@derived version.period = num_days(version.inforce_date_readonly, version.outforce_date_readonly);

version = {
    version.inforce_date_readonly: optional(version.inforce_date_readonly),
    version.outforce_date_readonly: optional(version.outforce_date_readonly),
    version.period: optional(version.period)
};

  2. Pro-rata calculations

    @overall @derived
pro_rata.intervals = evaluate_across_inforce_intervals({
    limit: version.limit / 1<policy.currency>,
    period: policy.period
});

@overall @derived
pro_rata.layers = [
    let val = interval->value ?? {limit: 0.0, period: 0} in
    let inforce_days = num_days(interval->inforce_date, interval->outforce_date) in
    let scale = inforce_days / val->period in {
        limit: val->limit * scale
    }
    | interval <- pro_rata.intervals
];

  3. Overall values

    @overall @derived
overall.limit = pro_rata->limit;
overall.limit has {
    prompt = "Limit ({{policy.currency}})",
    round_places = 0,
    ui_prefix = "{{policy.currency}} "
};

  4. Delta calculations

    @derived @shallow
delta.limit =
    round0(value_at_binding(overall.limit) -
           (value_before_current_layer(overall.limit) ?? 0));
delta.limit has {
    prompt = "Change in Limit",
    description = "Difference in limit between original and endorsed policy",
    ui_prefix = "{{policy.currency}} "
};

Key functions

  • value_at_binding: Current version value

  • value_before_current_layer: Previous version value

  • evaluate_across_inforce_intervals: Time period calculations

  • num_days: Duration calculations

Cancellation management

Cancellations represent early termination of a policy. They are structured similarly to endorsements but with specific differences:

cancel = {
    policy_dates,    // Original policy timing
    version,         // Cancellation timing
    delta,          // Financial impact
    cancel.reason    // Documentation
};

Key aspects of cancellations

  1. Timing

    • The cancellation process uses the same version timing mechanism as endorsements.

    • The effective date of cancellation must fall within the policy period.

    • The effective date becomes the final end date of the policy.

  2. Financial impact

    • The system calculates financial impact through the delta system.

    • Premiums are adjusted on a pro-rata basis.

    • The system determines final settlement values.

  3. Documentation

    • The user must provide a reason for the cancellation.

    • The system maintains a full audit trail of the cancellation process.

    • The policy history is preserved for reference.

  4. State changes

    • The system terminates the active coverage.

    • It prevents any further endorsements to the policy.

    • A historical record of the policy is maintained.