Digital Life Insurance Underwriting & Decisioning Platform

What if every life insurance application could be automatically approved, referred for underwriting, or declined based on configured rules?

1. Overview

A life insurance provider wanted to demonstrate how its customer onboarding journey could be handled digitally, from the initial application through underwriting and policy issuance. The requirement covered customer data capture, identity verification, product selection, quotations, automated checks, underwriting, and decisioning.

Webelight Solutions built the journey as a connected digital experience rather than treating the application as a standalone online form. The platform brought together configurable insurance rules, automated assessment, document and identity processing, underwriting workflows, AI-assisted review, and auditability.

The resulting solution demonstrated three distinct application outcomes: eligible cases could be automatically approved, cases requiring further assessment could be routed to an underwriter, and applications meeting configured decline criteria could be declined automatically.

2. Mapping the Existing Insurance Journey

Before building the digital journey, we mapped the complete process an insurance application had to pass through. The existing flow started with lead generation and an insurance adviser, followed by a fillable or PDF application. 

The sales office then entered the application into the core system, reviewed and endorsed it, and assessed whether it could proceed through straight-through processing. Applications that could not follow that path moved to underwriting for risk assessment before reaching an approval or decline decision.

That process gave us the structure for the digital journey. We needed to connect the customer-facing experience with the operational stages that followed it, including:

• Customer, proposer and beneficiary information
• Needs assessment and product recommendation
• Quotation and premium calculation
• Identity verification and document processing
• Health and lifestyle information
• Automated checks and configurable rules
• Straight-through approval, underwriting referral or decline
• Underwriter review and decision
• Payment, electronic consent and policy issuance
• Audit history and decision evidence
• Secure REST API integration with core insurance and CRM systems

Once these stages were connected, the application could move through a single digital workflow instead of treating customer onboarding, assessment, underwriting and policy processing as isolated steps.

3. Designing the Digital Customer Journey

We designed the customer journey as a connected digital flow that progressively captured the information required for recommendation, quotation, verification, application assessment, and underwriting.

3.1 Supporting self-service, assisted, and adviser-led applications

The journey supported three entry modes:

• On my own for customers completing the application independently
• With some help for customers requiring assistance during the journey
• Adviser-led for applications completed with an insurance adviser

The experience also supported saving and resuming an application and maintained adviser attribution where applicable.

3.2 Calculating insurance needs from customer financial information

Before recommending a product, the platform captured the customer's financial protection requirements, including:

• Debts requiring coverage
• Income replacement requirements
• Mortgage requirements
• Children's education requirements
• Existing savings
• Annual income
• Monthly affordability

These inputs were used to calculate an indicative coverage requirement that informed the subsequent product recommendation.

3.3 Recommending suitable insurance products

The platform presented three demonstrated plan options:

• Basic
• Just Right
• Extended

The recommended plan was identified based on the customer's captured needs, with a “Why [plan]?” explanation showing the basis of the recommendation.

The journey also presented the applicable disclosure that the recommendation was needs-based and not personal financial advice.

3.4 Generating dynamic quotations based on selected coverage

After selecting a plan, the customer could adjust the coverage amount and view the corresponding quotation.

The quotation presented:

• Coverage amount
• Monthly premium
• Annual premium
• Payment frequency
• Product inclusions
• Premium calculation factors

The demonstrated calculation factors included the base rate, age band, smoker status, and payment frequency.

3.5 Verifying identity and extracting information from submitted documents

The identity-verification workflow supported:

• Fiji National ID
• Passport
• Document upload
• OCR-based information extraction
• Structured application data

Using OCR-based document processing, the demonstrated workflow extracted details such as:

• First and last name
• Date of birth
• Gender
• Identification number
• Address
• City
• Region

The extracted information was then available as structured data for the subsequent application stages.

3.6 Capturing dynamic health, lifestyle and application information

The application used contextual questions to collect health and lifestyle information. Additional questions were prompted by the customer's responses, allowing relevant conditions to be explored without presenting every question upfront.

The journey also surfaced contextual indicators through “Things we noticed,” including:

• Diabetes
• Heart conditions
• Family history

Before submission, the customer reviewed the relevant policy and recommendation disclosures, with the acknowledgements recorded in the audit trail.

4. Applying Configurable Rules to Determine the Application Outcome

Once the application data had been captured, the platform evaluated the case against administrator-configured rules and decisioning logic to determine the appropriate processing path.

4.1 Automatically approving applications that met the configured criteria

The platform automatically approved applications when the submitted information satisfied the configured straight-through processing criteria.

The approval path evaluated:

• Applicant eligibility
• Product criteria
• Coverage thresholds
• Health and lifestyle responses
• Other configured underwriting conditions

Once all required criteria were met, the application proceeded through straight-through processing without manual underwriting.

4.2 Referring applications that required human underwriting

The platform routed applications to an underwriter when the configured rules identified conditions that required further assessment without triggering an automatic decline.

The demonstrated referral conditions included:

• Coverage exceeding the no-underwriting default
• Coverage exceeding the manual-review ceiling
• Declaration and medical-report mismatch
• Low-confidence income-document extraction

The application was then transferred to the underwriter workflow for further review and final decisioning.

4.3 Automatically declining applications that triggered configured decline criteria

The platform declined applications when one or more configured rules produced a decline outcome.

The demonstrated decline assessment evaluated six configured rules covering:

• PEP watchlist matching
• Maximum product entry age
• STP eligibility
• Disclosed medical conditions
• Automatic age-band criteria
• Smoker status

The system identified the rules responsible for the decline, including the demonstrated PEP match and age-related decline conditions.

4.4 Making every automated decision explainable and auditable

The platform recorded the rule-level evidence behind each automated decision instead of exposing only the outcome.

The decision view provided:

• Rules evaluated
• Individual rule outcomes
• Contribution factors
• Overall decision rationale
• Decision explanation
• Rule-derived contribution weights
• PDF decision export
• JSON decision data

This made the automated outcome traceable to the configured rules and provided structured evidence for review and audit.

5. Using AI to Assist Underwriters With Referred Applications

When an application was referred for further assessment, we moved the case into a dedicated underwriter workflow that brought the relevant application, document, risk, compliance, and affordability information into one place.

5.1 Consolidating referred applications for underwriter review

The underwriter workspace brought together:

• Applicant details
• Age and smoker status
• Occupation
• Selected product
• Requested coverage
• Premium
• Risk flags
• Extracted document information
• Compliance context
• Affordability information

This gave the underwriter a consolidated case view instead of requiring information to be reviewed across separate application stages.

5.2 Surfacing extracted information and confidence indicators

The platform presented OCR-extracted information from submitted documents alongside the application data.

The demonstrated case included extracted details such as:

• Identity information
• Occupation
• Annual income
• Employer
• Net pay
• Product and coverage
• Beneficiary information
• Passport information

Where an extracted value had low confidence, the platform surfaced that condition for review rather than treating the extracted information as definitive.

5.3 Generating AI-assisted case summaries and decision rationale

The platform introduced an AI-drafted review capability for referred applications. Machine learning and AI capabilities can support the analysis of application and document data, helping surface relevant risk indicators and information for underwriter review.

The AI-assisted workflow generated:

• Case summaries
• Draft decision rationale
• Relevant risk considerations
• Suggested follow-up actions
• Additional information that the underwriter may need to investigate

The rationale could identify conditions such as coverage exceeding defined underwriting thresholds, document or declaration inconsistencies, and other factors contributing to the referral.

5.4 Keeping the underwriter responsible for the final decision

The AI output was presented as “AI-drafted · review before deciding”, keeping the underwriter in control of the outcome.

The demonstrated workflow therefore separated the responsibilities clearly:

Configured rules determined the referral → AI assisted the review → the underwriter made the final decision.

The underwriter could then approve or decline the referred application and continue the approved case through the subsequent payment, consent, and policy-issuance stages.

6. Maintaining an Auditable Application-to-Policy Lifecycle

The workflow did not end when an application received an underwriting decision. We carried the application record through the subsequent payment, consent, and policy-issuance stages while recording key actions along the way. This gave the workflow a continuous history from application creation to the final policy outcome.

6.1 Recording customer disclosures and consent

Before submission, the customer reviewed and acknowledged the required disclosures within the application.

The demonstrated disclosures covered:

• Policy provisions, exclusions, and conditions
• Non-guaranteed projected benefits
• Basis of the product recommendation

The customer's acknowledgements were recorded as part of the application audit trail, creating a traceable record of the information presented and confirmed during onboarding.

6.2 Maintaining application and decision history

The platform maintained an event history across the application lifecycle rather than recording only the final underwriting outcome.

The demonstrated audit history included events such as:

• Application creation
• Adviser attribution
• Suitability assessment
• Declaration updates
• Application updates
• Underwriting activity
• AI-assisted case summarisation
• Underwriter decision
• Payment authorization
• Consent capture
• Policy issuance

This allowed the application record to retain the sequence of actions that led from the initial application through to its outcome.

6.3 Completing payment, electronic consent and policy issuance

For an approved referred application, the workflow continued beyond the underwriter's decision. The demonstrated journey moved through payment authorization and electronic consent before the policy was issued.

The electronic consent flow allowed the customer to:

• Enter their name
• Draw their signature
• Confirm consent to electronic signing
• Complete the signing process

The signature and consent were recorded with a timestamp in the audit trail, after which the application could proceed to policy issuance.

7. Connecting the Digital Workflow With Existing Insurance Systems

The digital platform was designed to work with the insurer's existing technology environment rather than operate as an isolated application. The integration requirement covered the exchange of customer, application, policy, and underwriting information with the core policy administration environment, along with connectivity to the CRM system.

7.1 Exchanging Application Data Through Secure REST APIs

The integration layer was defined around secure RESTful APIs so that information captured and generated throughout the digital journey could be exchanged with the insurer's existing systems. The required data exchange covered:

• Customer information
• Application information
• Policy information
• Underwriting information

This approach kept the digital application layer separated from the underlying systems responsible for core insurance operations.

7.2 Integrating the Digital Journey With CRM

CRM integration was included as part of the broader solution requirement so that the customer information captured during onboarding could connect with the insurer's existing customer-management environment.

The integration scope covered information generated through the digital journey, including:

• Customer records
• Application information
• Relevant application status information

This positioned the onboarding platform as part of the existing insurance technology ecosystem rather than as a standalone customer-facing application.

7.3 Keeping Core-System Integration API-Driven

The integration model was explicitly constrained to secure RESTful APIs. Database-level access and file-based integrations were not permitted, so the solution was designed around controlled API-based communication with the insurer's existing systems.

The requirement specifically excluded:

• Database-level integrations
• File-based integrations
• Direct access to underlying core-system databases

Where the demonstration identified particular external checks or connections as future integrations, we treated those as planned integration points rather than representing them as completed live integrations.

8. What the Three Decision Paths Changed in the Insurance Workflow

The decisioning layer gave the application three distinct paths instead of sending every case through the same processing route. Once the configured rules had evaluated the application, the platform could determine whether the case was suitable for straight-through processing, required human underwriting, or met the conditions for an automated decline.

8.1 Straight-through approval for eligible applications

Applications that satisfied the configured criteria could proceed through straight-through processing without being routed to an underwriter.

The demonstrated flow was:

• Application submitted
• Configured rules evaluated
• Eligibility criteria satisfied
• Application automatically approved
• Application continued toward subsequent policy processing

This kept manual underwriting intervention for cases where it was actually required.

8.2 Underwriting referral for applications requiring further assessment

Applications that did not qualify for straight-through processing but did not meet automatic decline conditions were routed to an underwriter.

The referred workflow provided:

• Consolidated application information
• Extracted document information
• Confidence indicators
• Risk and compliance context
• Affordability information
• AI-drafted case summary and rationale
• Suggested follow-up actions
• Human underwriter decision

The demonstrated referred case was approved by the underwriter and continued through payment authorization, electronic consent, and policy issuance.

8.3 Automated decline for applications meeting configured decline conditions

Applications that triggered configured decline rules could be declined without entering the manual underwriting workflow.

The demonstrated decline case evaluated six rules and identified decline conditions including:

• PEP watchlist match
• Applicant age exceeding the product maximum

The platform also displayed the other evaluated rule outcomes, allowing the final decline to be traced back to the configured decision criteria.

8.4 Faster assessment with visible decision evidence

The demonstrated assessment experience presented the rules evaluation as taking approximately one second, compared with approximately 20 minutes of traditional underwriting shown in the demonstration.

More importantly, the speed was combined with decision evidence rather than a simple automated status. The platform showed the evaluated rules, their outcomes, contribution factors, decision explanation, and downloadable PDF and JSON evidence, making the automated processing both faster and traceable.

9. From Digital Application to Explainable Insurance Decisioning

The completed workflow connected the customer-facing application with the assessment, decisioning, underwriting, and policy-processing stages into one continuous journey. Information captured at the beginning of the application continued through the relevant checks and workflows instead of being treated as isolated form data.

9.1 Connecting the complete application journey

The demonstrated workflow progressed through:

• Digital application initiation
• Needs assessment and coverage calculation
• Product recommendation
• Quotation
• Identity verification
• Application and health information
• Automated checks
• Configurable rules evaluation
• Straight-through approval, underwriting referral, or decline
• Underwriter review where required
• Payment authorization
• Electronic consent
• Policy issuance

This created a single application lifecycle from the customer's initial interaction through to the final policy outcome.

9.2 Combining deterministic decisioning with human underwriting

The solution separated automated processing from human judgement, using configured rules for defined decision paths while allowing AI and machine learning capabilities to support more complex assessment and review scenarios.

• Eligible applications followed the straight-through processing path
• Referred applications were passed to an underwriter with consolidated case information and AI-assisted review
• Declined applications were stopped when configured decline conditions were triggered

This allowed automation to handle defined decision paths while retaining human involvement where further underwriting assessment was required.

9.3 Making automated outcomes traceable

The platform did not treat an automated decision as a final status without supporting evidence. The demonstrated decision view showed the rules evaluated, individual outcomes, contribution factors, and the explanation behind the resulting decision.

The workflow also maintained audit events covering the application and subsequent processing stages, providing a record of actions from application creation through underwriting, consent, payment authorization, and policy issuance.

The result was a digital insurance workflow that combined automated application processing, configurable rules-based decisioning, AI-assisted underwriting, human oversight, and auditable decision evidence within a single journey.

10. Closing the Journey With a More Controlled Decisioning Model

The implementation brought the customer application, automated assessment, underwriting review, and policy processing into one connected workflow. Rather than sending every application through the same process, the platform evaluated each case against configured criteria and directed it to the appropriate outcome.

The demonstrated workflow produced three distinct processing paths:

• Straight-through approval for applications that satisfied the configured criteria
• Underwriting referral for applications that required additional assessment
• Automated decline for applications that triggered configured decline conditions

The automated assessment also demonstrated a substantial difference in processing time. The interface showed an assessment time of ~1 second, compared with ~20 minutes for the traditional underwriting process referenced in the demonstration. Based on those figures, the demonstrated assessment was approximately 1,200× faster, representing a ~99.9% reduction in assessment time.

The decisioning workflow also provided visibility into how automated outcomes were reached. In the demonstrated decline case, 6 rules were evaluated, with individual rule outcomes and contribution factors shown alongside the final decision. Referred applications then received AI-assisted case summarisation, draft decision rationale, and suggested follow-up actions before the underwriter made the final decision.

The result was a demonstrated digital insurance workflow that connected:

• Digital customer onboarding
• Needs-based product recommendation
• Dynamic quotation
• Identity and document processing
• Rules-based assessment
• Three-way application decisioning
• AI-assisted underwriting
• Electronic consent and payment authorization
• Policy issuance
• Auditable decision and application history

For Webelight Solutions, the implementation demonstrated how a life-insurance application could move from digital onboarding to an explainable decision and, where approved, through to policy issuance within a single connected workflow.

Looking to build a similar digital insurance onboarding and decisioning platform? Let’s discuss how Webelight Solutions can help you build it.