Banking
Banks generate massive volumes of client behavior across transactions, app sessions, trades, and support, but that data still lives in dozens of fragmented, task-specific models with no shared intelligence between them.

/01
Client
Our client's mission is to give retail customers a faster, more transparent alternative to traditional banking.
Like every bank at scale, its intelligence had grown one model at a time.
/02
Challenge
01
Credit risk, fraud, and churn each ran on their own model
Each one had its own feature pipeline, training cycle, and ongoing maintenance, built and run separately from the rest. Together, that meant enormous operational cost and an inconsistent read on the same customer across teams.
02
A new use case meant building a new model
Entering a new market or launching a new product typically meant starting over: new features, new labeled data, months of engineering before the first prediction went live.
/03
Solution
/01
Every transaction, app session, trade, KYC event, and support chat gets lined up into one timeline per customer, so nobody has to hand-build features for each task anymore.
/02
The model learns from that timeline on its own, by guessing missing events from the ones around them, so it doesn't need labeled examples to start understanding behavior.
/03
Adding a new task like credit risk or fraud just means fine-tuning that same model, which takes a fraction of the time it used to take to build one from scratch.
/04
The finished model runs in production through ONNX/Triton, hosted on-premise or in the bank's own cloud.
How we shipped
/01
Every piece of work, from tokenizer design to Triton deployment, lives as a Linear ticket with an explicit owner and definition of done. On an ML build, where "still training" can hide a week of drift, the discipline matters more, not less.
/02
The stack is built with Claude Code in the loop end to end: the key-value-time tokenization pipeline, sequence packing and dynamic batching for training throughput, LoRA fine-tuning harnesses, ONNX/Triton serving. Infrastructure that normally takes an ML platform team, shipped by an embedded senior pod.
/03
Every architecture decision is validated against downstream task probes before it earns its way into the backbone. Cheap linear probes first, LoRA fine-tuning only on what survives. Engineering effort goes toward what's already proven to move the metric.
/04
The pipeline, tokenization, training, fine-tuning, serving, was built and pressure-tested on synthetic banking event data first, so the infrastructure was already proven before it touched the client's real data
/04
Impact
We built a single foundation model that replaced six fragmented systems with one shared source of behavioral truth. For a bank scoring risk and fraud on every transaction, that's not just fewer models to maintain. It's a compounding accuracy advantage that only grows with every transaction that runs through it.
01
Before
After
01
02
03
04
Results by use case
Credit scoring
Fraud detection
Communication targeting

/05
Team snapshot
AI-Augmented Senior Pod
2 FTE
+
