Banking

Behavioral Engine for Neobank

Behavioral Engine for Neobank

Behavioral Engine for Neobank

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

Built on Pragmatiq, Day10’s enterprise-ready, open-source implementation of the PRAGMA architecture pioneered by Revolut. Day10 built the path from raw event logs to live scoring inside the bank's own environment.

Built on Pragmatiq, Day10’s enterprise-ready, open-source implementation of the PRAGMA architecture pioneered by Revolut. Day10 built the path from raw event logs to live scoring inside the bank's own environment.

/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.

As more behavioral data flows through the shared model, whatever task it's used for, every task built on top of it gets a little more accurate, not just the one that data came from.

As more behavioral data flows through the shared model, whatever task it's used for, every task built on top of it gets a little more accurate, not just the one that data came from.

How we shipped

A production foundation-model stack – data pipeline, training infrastructure, serving layer – built at pod speed, not platform-team speed. Here's how:

A production foundation-model stack – data pipeline, training infrastructure, serving layer – built at pod speed, not platform-team speed. Here's how:

/01

Linear-first execution

Linear-first execution

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

Claude Code as the engineering pair

Claude Code as the engineering pair

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

Benchmark-gated iteration

Benchmark-gated iteration

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

Synthetic data first

Synthetic data first

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

6+ fragmented, task-specific models

6+ fragmented, task-specific models

One shared foundation model

One shared foundation model

02

A new use case built from scratch

A new use case built from scratch

A new use case fine-tuned on the shared backbone

A new use case fine-tuned on the shared backbone

03

Months of manual work

Months of manual work

24 hours to fine-tune a new task

24 hours to fine-tune a new task

04

Six teams, six reads on the same customer

Six teams, six reads on the same customer

One continuously updated behavioral signal

One continuously updated behavioral signal

Results by use case

+107% PR-AUC

+107% PR-AUC

Credit scoring

+535% recall

+535% recall

Fraud detection

+53% prediction accuracy

+53% prediction accuracy

Communication targeting

/05

Team snapshot

AI-Augmented Senior Pod

2 FTE

+

Senior ML Engineer

Senior ML Engineer

1 FTE

1 FTE

Senior AI Engineer

Senior AI Engineer

1 FTE

1 FTE

We help teams build AI-first companies from day one and re-architect existing businesses to operate at AI speed.

131 Spring Street

New York, NY 10012

2026 All rights reserved.

We help teams build AI-first companies from day one and re-architect existing businesses to operate at AI speed.

131 Spring Street

New York, NY 10012

2026 All rights reserved.

We help teams build AI-first companies from day one and re-architect existing businesses to operate at AI speed.

131 Spring Street

New York, NY 10012

2026 All rights reserved.