Foresight

Inspiration

A job loss, a raise, or a death in the family shows up in someone's bank account weeks before it shows up as a missed car payment or a switch to another brand. Banks and lenders usually find out too late, when the options are worse for everyone.

We talked to the Toyota Financial Services team, who told us their real problem is retention, not acquisition: they already have the customer, and new entrants are eating their market share. They also told us the most valuable thing a tool could do is predict when to act, not just who is at risk. We talked to Capital One's team too, and they said most hackathon projects force Nessie in without making it do real financial work. So we asked: what if the bank noticed life changes first, and acted for the customer?

What it does

Foresight predicts the moment a customer needs help and acts before it's too late.

Sense: Foresight reads a customer's consented banking activity in Capital One's Nessie API (paychecks, purchases, bills, the car loan) and detects life changes: income stopping or rising, new recurring expenses, savings draining. It tracks runway, the number of days until the balance can't cover the next car payment.
Predict: a timing model predicts when a lender like Toyota Financial Services should reach out to each customer (hardship help, lease-end options, or an upgrade window), and explains why. We backtested outreach timing strategies (day of, 2 weeks before, 90 days before, 6 months before, and model-timed) on held-out customers.
Connect to the real world: live SerpAPI data (car market values for equity, competitor promotions and rates, local gas prices, nearby dealers, and job openings after a job loss) feeds both the model and what the customer sees.
Act, with consent: after the customer confirms, Foresight writes back to Nessie (for example, transferring money into a car-payment buffer or shifting a bill's due date) and shows the right TFS options through the customer's own dealer.

Demo story: Maria's paychecks stop. Foresight flags it, shows her car payment is at risk. James gets a raise, and as his equity turns positive his upgrade window opens.

Responsible by design: lenders only receive minimal, consented signals (for example, "payment risk elevated in 30 days"), never raw transactions. Hardship and bereavement switch to support-only mode with no sales messages. Every number shown to a customer comes from code, and the LLM only rewords it.

Scalable: Foresight is built as a platform. Toyota is client #1. A new client defines what "losing a customer" means, which moments matter, and which actions are allowed, and the same engine trains and runs. [If you built it: We onboarded a second client, an insurer, live in the demo.]

How we built it

Synthetic data: a seeded Python generator creates [10,000] customers with accounts, [18–36] months of transactions, contracts, and planted life events (job loss, raise, new child, bereavement, lease end) with hidden ground truth. All assumptions live in one config file, are shown in the app, and are adjustable. We anchored them to industry figures where available and labeled the rest as assumptions.
Nessie: a seeding script created a demo cohort of [N] customers (customers, accounts, deposits, purchases, bills, loans). An ingestion worker reads activity back, and an action executor writes transfers and bill changes, with idempotency keys so retries never double-transfer.
Feature engine and event detector: income change, runway, savings trend, spending shifts, payment-to-income ratio, and equity, plus explainable rules that detect life events.
Timing model: LightGBM classifiers predicting missed payment, churn, and upgrade within 30/60/90 days, with train/test split by customer. SHAP gives the top reasons per prediction, and [Gemini] turns them into plain language, with a check that no numbers appear that weren't in the input.
SerpAPI: Shopping/Search for vehicle values, promos, and rates; Maps for dealers; Google Jobs for openings. Responses are cached so the app never stalls on a live call.
App: [FastAPI backend and React frontend] with a time-travel slider that replays a customer's year, a customer view, and a lender dashboard with the backtest and assumption sliders.

Challenges we ran into

Nessie at scale: pushing thousands of customers' histories through an API wasn't practical, so we trained on a large local synthetic set and seeded only a small demo cohort into Nessie. Both come from the same generator.
"You planted the patterns": training on data we generated risks circular results. We built a recovery test: planted patterns the model is never told about, then checked that it rediscovers them on held-out customers.
Avoiding fake accuracy: we split train and test by customer, not by row, to prevent leakage.
Reliability of live data: API limits and outages meant caching and a replay mode so the demo can't break.
Sensitive moments: job loss and bereavement shouldn't trigger sales messaging, so we designed support-only mode and customer approval for every action.

What we learned

Timing is a different problem from scoring: knowing who is at risk isn't enough, and when to act matters just as much.
Explainability is a feature. Customers and lenders both need to know why a message arrived when it did.
With synthetic data, the honest thing is to prove the pipeline (recovery tests, held-out evaluation) and state the assumptions openly.

What's next for Foresight

Real data: retrain the same pipeline on a lender's real data, with their own assumptions replacing ours.
Open banking: extend beyond a native bank partner to consented connections at any bank.
More clients and industries: auto lenders, banks, insurers, and anyone with customers on contracts, each onboarded by configuration instead of rebuilding.
Fairness audits: test outreach timing and treatment across customer groups before launch.
Human-in-the-loop tools: let lender staff review and approve sensitive outreach at scale.

Tracks: Toyota Financial Services, Capital One (Best Use of Nessie), SerpApi (Best Use of SerpApi)