Real-Time Underwriting Risk and Fraud Analytics for an Embedded Patient-Financing Provider
Let's Connect
Overview
What we built
A patient-financing provider was approving treatment plans with a manual checklist while patients waited at the front desk, and losses were climbing. We replaced the checklist with a real-time risk engine that decides in seconds.
In plain terms: this fintech lets patients at roughly 60 dental offices spread the cost of treatment, with the approval decision made at the front desk. That decision used to be a person working through a rules checklist while the patient stood waiting, often for several minutes. Applications that did not fit the checklist neatly were rejected by default, identity fraud was slipping through unnoticed, and the share of plans unpaid at 90 days had climbed above 9%.
We built a real-time underwriting engine that scores each application twice at once: a repayment-risk model trained on how past plans actually performed, and a fraud layer checking device, identity and velocity signals. The decisioning API returns approve, decline or refer in under 20 seconds, with genuinely borderline cases routed to a human review queue. Decision time fell from over 4 minutes to under 20 seconds, delinquency dropped from 9.1% to 6.4% at an unchanged approval rate, and confirmed identity-fraud losses fell 38%.
The Problem
Slow approvals, rising losses
The approval moment happened in the worst possible setting for a manual process: a patient at the front desk, a receptionist working through a rules checklist, and a queue forming behind. Decisions took several minutes, which is a long time to stand at a counter wondering whether you can afford your treatment, and an awkward one for the practice hosting the wait.
The checklist was blunt as well as slow. It could pass or fail an application, but it could not weigh one, so borderline cases defaulted to rejection and creditworthy patients walked away unfunded. At the other end of the spectrum it had no defence against deliberate deception: identity fraud was slipping through unnoticed, because a static rules list checks what an applicant says, not whether the applicant is who they claim to be.
The portfolio showed the accumulated damage. Delinquency at 90 days had climbed above 9%, and every point of it squeezed the margin on all the plans that were performing. Roughly 60 dental offices were writing this risk daily, with no scoring, no fraud signals and no feedback loop from how past plans had actually repaid.
Minutes-long counter decisions
Manual checklist underwriting took several minutes per application while the patient waited at the front desk and the practice queue built behind them.
Borderline means rejected
The checklist could only pass or fail, so applications that did not fit neatly were declined by default, turning away patients a model would have approved.
Fraud passing unnoticed
Static rules checked the application's contents, not its authenticity, so identity fraud moved through the funnel without triggering anything.
Losses eroding margin
Delinquency at 90 days had climbed above 9%, squeezing the economics of every funded plan across roughly 60 dental offices.
What it was costing them
Delinquency above 9% at 90 days ate directly into the margin on every funded plan, and confirmed fraud losses compounded it from another direction. Default-rejected borderline applicants were revenue turned away at the counter, patients associated the product with an awkward multi-minute wait, and the dental offices hosting that wait had every reason to question whether embedded financing was helping their front desk or clogging it.
The Solution
Real-time risk scoring engine
We built the underwriting engine around two models running in parallel on every application. The first is a gradient-boosted repayment-risk model trained on the provider's own historical plan performance, so it scores each new applicant against how similar plans actually repaid. The second is a fraud layer scoring device, identity and velocity signals, catching the applications whose problem is not creditworthiness but authenticity.
Both verdicts feed a single decisioning API that returns approve, decline or refer in under 20 seconds, fast enough that the answer arrives within the natural rhythm of a front-desk conversation. Refer is the deliberate third path: genuinely borderline cases route to a human review queue rather than defaulting to rejection, narrowing manual underwriting to the 7% of applications where judgement adds something.
Because models degrade quietly, we built the monitoring in from the start. Drift dashboards watch whether incoming applications still resemble the data the models were trained on, and portfolio dashboards track delinquency and fraud outcomes against expectations, so the team can see both models earning their keep, or needing attention, continuously.
Key decisions
Two models, one decision
Repayment risk and fraud are scored by separate specialised models on every application, then combined into a single verdict, because the two failure modes need different evidence.
Train on own plan history
The risk model learned from the provider's historical plan performance rather than generic credit heuristics, anchoring scores to how these patients actually repay.
Refer instead of reject
Borderline applications route to a human review queue rather than defaulting to decline, recovering the creditworthy applicants the old checklist turned away.
Decide inside the conversation
The API answers in under 20 seconds, so approval fits the front-desk moment instead of interrupting it with a multi-minute wait.
Monitor drift from day one
Drift and portfolio dashboards keep both models continuously observed, so degradation shows up in a chart before it shows up in losses.
Measurable Impact
What changed after launch
At the counter, the change is immediate: median point-of-sale decision time fell from over 4 minutes to under 20 seconds, so financing now resolves within the conversation it started in. In the portfolio, 90-day delinquency dropped from 9.1% to 6.4% at an unchanged overall approval rate, which is the combination that matters: better selection, not tighter rationing.
The fraud layer proved itself in the same period, with confirmed identity-fraud losses down 38% across the first two quarters after launch. And the human underwriters were not replaced so much as refocused: manual reviews narrowed to 7% of applications via the referral queue, the genuinely ambiguous cases where their judgement changes the outcome rather than every application that walked in.
Decision speed
Several minutes of manual checklist at the desk
Median under 20 seconds via the decisioning API
Portfolio health
90-day delinquency above 9%
6.4% at an unchanged approval rate
Fraud defence
Identity fraud slipping through unnoticed
Confirmed fraud losses down 38% in two quarters
Manual workload
Every application handled by hand
Reviews narrowed to 7% via the referral queue
Headline results
Median point-of-sale decision time cut from over 4 minutes to under 20 seconds
90-day delinquency reduced from 9.1% to 6.4% at an unchanged overall approval rate
Confirmed identity-fraud losses down 38% across the first two quarters after launch
Manual underwriting reviews narrowed to 7% of applications via the referral queue
Tech & Tools Used
What powered the build
Every tool below earned its place in this engagement. Here is the part each one played.
Python (FastAPI)
Implements the decisioning API that scores each application and returns approve, decline or refer to the point of sale in real time.
XGBoost
The gradient-boosted repayment-risk model at the engine's core, trained on historical plan performance to score each applicant's likelihood of repaying.
scikit-learn
Provided the feature pipelines, calibration and evaluation tooling used to build and benchmark both the risk and fraud models.
Apache Kafka
Streams application events, decisions and outcome signals between services, feeding the fraud layer's velocity checks and the monitoring pipelines.
PostgreSQL
The system of record for applications, decisions, referral-queue cases and plan outcomes that the models and dashboards read from.
Redis
Serves the low-latency lookups the fraud layer needs, including device and velocity counters, inside the decision window.
AWS SageMaker
Hosts model training and deployment, keeping retrained risk and fraud models versioned and promotable without touching the serving path.
Docker
Containerises the decisioning services and model servers so the same builds run identically from development through production.
Grafana
Drives the drift and portfolio dashboards that keep both models continuously monitored against incoming application patterns and repayment outcomes.
React
The interface for the human review queue, where underwriters work referred borderline cases with the models' signals alongside.
Ready to Build your Healthcare Fintech Business with Fraud, Risk & Anomaly Detection
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
