Decision Intelligence for Insurance & Loan

Most risk-scoring AI draws a single line: accept or reject. DEIN, the platform I work on, treats it as a richer decision. On the insurance side that means standard, decline, surcharge, exclusion, or coverage limit — explained in business terms (which loss-ratio or incidence driver makes an applicant risky), not just SHAP values on a score. On the loan side it means finding the optimal rate and limit for segments the model has never seen ground truth on, rather than declining them by default.

Both domains share the same problem: the data you have is biased by decisions already made. DEIN reasons about what the data doesn't contain — estimating outcomes for historically rejected applicants and simulating the effect of changing the rules. The throughline of my work here is one conviction — a more accurate model isn't automatically more valuable; it has to move a business KPI.

To lower the loss ratio on new policies for a major insurer, we wanted to anticipate an applicant's disease risk from their past insurance-claim history — a signal feeding underwriting decisions and what-if simulations.

The hard part wasn't the model; it was defining the prediction target. Grouping diseases naively is meaningless — a cold is common but tells you nothing, and a cold and a cancer aren't related. So I used pointwise mutual information (PMI) to measure how strongly diseases actually co-occur, kept only associations within a confidence band I trusted, and used the hierarchical structure of diagnosis codes to group similar diseases into sensible inputs and outputs.

On top of that target I built a two-step design — candidate generation then ranking — so the prediction could also be reused as a single feature elsewhere; the predictor itself is an MLP. Data was prepared as a mart over existing internal tables (SQL + Polars) with a batch program, and the training pipeline ran on AWS SageMaker.

As loan markets saturate, lenders need to expand into thin-file segments — the underserved and younger customers who were historically declined not because they're risky, but because there's no repayment data on them. The problem: credit models only learn from borrowers who were approved, so they're blind to these segments by design.

I build the reject inference layer of DEIN that estimates outcomes for those no-data segments, so a lender can expand approvals without flying blind on risk. The approach combines five strategies: niche scoring models built from similar approved-segment profiles, a safety margin on top of the risk estimate to account for data uncertainty, a profitability model that folds in expected card spend alongside default risk, a simulation engine that finds the optimal rate and limit for each segment, and a champion-challenger framework that rolls out changes incrementally while monitoring delinquency in real time.

I also build the business-rule logic that turns a lender's own KPIs — approval-rate target, delinquency cap, margin floor — into the actual decisions the platform makes. The bridge between "what the business cares about" and "what the system does."

On the insurance side I build a multi-agent system that lets underwriters and actuaries query the platform in plain language — no SQL, no analyst bottleneck. An underwriter can ask "is there fraud-like activity in our book this month?" and get a structured answer backed by actual data, not a hallucination.

The architecture combines three patterns. RAG over internal book data and GA reports grounds the agents in real numbers. Tool use lets agents call live APIs — pulling insurance news, running market research, triggering report generation — rather than relying on stale context. A multi-agent setup routes different task types to specialized agents: one handles analytical questions over internal data, another handles market and news research, a third generates structured reports on demand.

One architectural decision driven by security: sensitive internal book data never leaves the environment, so those agents run on a self-hosted model. External-facing tasks — market research, news summarization — use Claude. The split is a deliberate tradeoff between capability and data governance, not a cost optimization.