Financial Services
Decisions at transaction speed, taken on the raw event history of each account instead of on aggregates that were already stale when they were computed.
the entity here isan accountWhat the model actually reads
No aggregation, no feature engineering — the events your systems already write, in the order they happened.
- authorisations
- chargebacks
- logins and device changes
- limit changes
- service calls
- payments and transfers
What breaks with one model per problem
Fraud moves faster than the feature store
By the time a pattern has been engineered into a feature and backfilled, the pattern has changed. Reading the sequence removes that lag entirely.
One model per question, and a pipeline for each
Fraud, credit, churn and collections each carry their own dataset, their own drift and their own on-call. One foundation collapses that fleet.
Regulators ask what went in
Every dataset is profiled, versioned and traceable to the model it trained, which is the answer an audit actually needs.
One foundation, a specialisation per question
Each of these is a head on the same trained model, not a separate project with its own pipeline.
Fraud detection
Score the live transaction stream against everything the account has ever done, not against a window of averages.
Credit scoring
Behaviour over time, including the thin-file customers a bureau score has nothing to say about.
Churn and retention
The signal that someone is leaving is in the sequence long before the cancellation call.
Hyper-personalised offers
One next action per customer per interaction, calibrated rather than bucketed into segments.
What we can point at
AUPRC on the IBM TabFormer card-fraud benchmark
parameters — against 29M and 100M for the models it beats
to train, on 4× NVIDIA GB200