Pillar one · Real-time underwriting
A worker who says yes to more coverage should get an answer in the same session.
Not three weeks later by mail. Reflex IQ runs the carrier's own rules through the EOIX Cloud SaaS AI Platform and the underwriting engine, pulling third-party data in real time. The decision is binary and it comes back inside the enrollment flow. This page is written for carrier underwriting and product leaders; the mechanism reads the same for Ben Admin, investor, and recruiting audiences.
The belief
Underwriting friction is not a law of nature. It is a delivery problem.
Everything above GI used to require paper, weeks of waiting, and a phone-call appeal path. That delay is where the intent dies. The architecture below is built to close that gap.
The interview is Reflex IQ. It is not a static form. Question by question, it adapts to the answer the employee just gave, the carrier's rules for that product, the employee's eligibility, and the workflow logic the carrier configured. If a healthy 32-year-old says no to every condition, the interview is short. If an answer flags risk, the interview goes deeper where the carrier's rules say to go deeper.
Reflex IQ runs on the EOIX Cloud SaaS AI Platform. The platform holds the adaptive intelligence: it knows the rules, it talks to the carrier's underwriting engine in real time, it pulls the third-party data sources the carrier's rules require (driving history, prior application history, and prescription history), and it returns the engine's decision back to the workflow.
The underwriting engine is configured by the carrier with the carrier's own risk parameters, the same risk parameters it uses today for manual underwriting. The engine is what returns approved or not approved. EOIX executes the carrier's rules at digital speed. EOIX does not write underwriting rules.
The output is a binary decision returned in real time, written back to the EOIX portal and to the Ben Admin shopping cart where the integration exists. The employee sees the result in the same session. The carrier sees the case in the portal the moment it is decided. This architecture is built to deliver that experience; it is in conversation with multiple Tier-1 group carriers and runs in pre-pilot today.
The mechanism, end to end
From the employee's click to the decision in seven stops.
The traditional path is Employee, then Forms, then Manual Underwriting, then Delays, then Abandonment. The EOIX path is the chain below.
Step 01
Employee
Step 02
Forms
Step 03
Manual Underwriting
Step 04
Delays
Step 05
Abandonment
The path ends here.
Step 01
Employee
Inside the enrollment session, elects coverage above the GI threshold.
Step 02
Reflex IQ
Adaptive digital interview. Question depth follows the carrier's rules.
Step 03
EOIX Cloud SaaS AI Platform
Pulls the third-party data sources the carrier's rules require (driving history, prior application history, and prescription history) and orchestrates the call.
Step 04
Underwriting engine
Configured by the carrier with the carrier's own rules. Returns the decision.
Step 05
Instant Decision
Binary: approved or not approved. No partial offers.
Step 06
Enrollment Write-Back
Approved coverage lands in the Ben Admin shopping cart in real time.
Step 07
Governance Visibility
Every event lands in the EOIX portal so the carrier can see the case.
Four ways to reach the interview
Carrier-branded. Case-specific. No sensitive data in URLs.
SSO where available, secure token plus identity verification everywhere else. Every link is carrier-branded. Every link is case-specific. Sensitive data is never exposed in the URL itself.
| Launch option | Who it reaches | How identity is proven | Use when |
|---|---|---|---|
| Option 01Enrollment Flow SSO Launch | Employee | Already signed in to the parent system, so the EOI app trusts that identity. No second login. | The cleanest experience. Use whenever the parent platform supports SSO. |
| Option 02Secure Token Link | Employee or spouse | Opaque token in a secure link, plus private information (date of birth, last four of SSN) and a one-time email or text code if required. | SSO is not available, or the path needs to reach a spouse who has no login on the parent system. |
| Option 03Admin One-Off Link with Employer SSO | Employee | Redirected through employer SSO so the app can confirm they are the same person on the case file. | The path back into enrollment is broken or lost, or HR needs to re-send manually. |
| Option 04Spouse Link with Identity Verification | Spouse | Private information (date of birth, last four of SSN), plus a one-time email or text code if required. | Spousal life coverage is chronically underpenetrated because the spouse has no easy way to complete EOI. |
Scroll the table sideways to see every column.
Option 01
Enrollment Flow SSO Launch
Audience: employee.
While inside the HRIS (Human Resources Information System) or Ben Admin (Benefits Administration platform) enrollment flow, the employee clicks Complete EOI. Because they are already signed in to the parent system, the EOI app trusts that identity and the employee goes straight into the interview. No second login.
Setup: Ben Admin or HRIS configures one of three SSO (Single Sign-On) formats: SAML (Security Assertion Markup Language) legacy, OIDC (OpenID Connect) modern, or signed JWT (JSON Web Token).
When to use: the cleanest experience. Use whenever the parent platform supports SSO.
Option 02
Secure Token Link
Audience: employee or spouse.
The system sends a secure link by email or text. The applicant opens it, confirms private information (date of birth, last four of SSN), confirms a one-time email or text code if required, and enters the interview. The token in the URL is opaque. Sensitive data is never in the URL itself.
Setup: no SSO required. Ben Admin or carrier supplies applicant identity, case ID, coverage, and verification data.
When to use: SSO is not available, or the path needs to reach a spouse who has no login on the parent system.
Option 03
Admin One-Off Link with Employer SSO
Audience: employee.
An employer admin generates a one-off link and sends it by email, internal chat, copy-paste, or one-click. The employee clicks, gets redirected through employer SSO so the app can confirm they are the same person on the case file, then lands in the interview.
Setup: employer configures their SAML or OIDC identity provider and exposes a matching claim.
When to use: the path back into enrollment is broken or lost, or HR needs to re-send manually.
Option 04
Spouse Link with Identity Verification
Audience: spouse.
Employee, carrier, system, or admin portal sends a spouse-specific link by email or text. The spouse opens it, verifies identity with private information (date of birth, last four of SSN), confirms a one-time email or text code if required, and completes the EOI.
Setup: no SSO. Carrier provides employee and spouse context, coverage, case ID, and verification data.
When to use: spousal life coverage is chronically underpenetrated because the spouse has no easy way to complete EOI. This is the path that closes that tier.
Part 1: https://eoi.carrier.comPart 2: /startPart 3: ?t=Part 4: secure(employeeId)Part 5: &dob=Part 6: &ssn=
Carrier-branded host
Every link is carrier-branded.
The interview entry point
Where the applicant lands. Option 01 lands on /launch instead, straight from the enrollment flow.
The token parameter
An opaque token
The token in the URL is opaque, and every link is case-specific.
Date of birthNever present
Confirmed by the applicant inside the interview. Sensitive data is never in the URL itself.
Last four of SSNNever present
Confirmed by the applicant inside the interview. Sensitive data is never in the URL itself.
The boundary
What EOIX does, and what it deliberately does not.
The carrier holds every rule. EOIX runs the workflow. The boundary appears on every pillar page for a reason.
Next step
Book a 30-minute carrier discovery call.
We walk your underwriting and product teams through the architecture, the rule-ownership boundary, and a sample carrier-branded link. No carrier names in the room without your consent.