Turning client behaviour into insight

Clustering & Modelling learns what normal looks like for every client. It groups clients with similar behaviour, builds a profile from each one’s own history, and measures new activity against both. The same approach that flags unusual activity for compliance can rank opportunities for the business, such as interest in a product or the risk of a client leaving. Profiles keep updating as activity arrives, and models work alongside your rules, not in place of them.

Customers grouped by behaviour

Each customer is measured against the customers who behave like them.

DetectX® groups customers into clusters of similar behaviour, using their history and the data your systems already hold about them. It keeps statistics on every cluster and its members over time, so normal is defined by real peers, not by one fixed threshold.

Grouped by behaviourValueFrequency
Activity level, set by DetectX®

Level reflects how regular and how large a customer’s activity is. Clusters themselves are built for each bank.

Illustrative customers and clusters.

How each customer is compared

Against their own history, and against the customers like them.

Every period, DetectX® compares each customer’s activity with two expected values: what is normal for them, and what is normal for their cluster. A change one comparison misses, the other catches. Significant deviations raise an alert.

Try a scenario
Against their own historyWithin range
Expected for this customer20–80
Against their cluster · Level 2Within range
Expected for customers like them50–140
No alertIn line with their own history and with their cluster.

Illustrative customer and values. Expected values are set by DetectX® from the data and move as it changes.

How thresholds are set

Set by the system, from the data, and kept current.

A fixed threshold treats every customer the same and never changes. DetectX® sets thresholds from each customer’s own behaviour and their cluster, and adjusts them as your customer base and the wider economy shift. The thresholds can then be used in your business rules, daily or in real time.

One customer · 24 months
050100150200Month 1Month 4Month 7Month 10Month 13Month 16Month 19Month 22The business grows →
Fixed threshold
0alerts
One every month once the business grew, so the real spike is lost among them.
DetectX® threshold
0alert
It rose with the customer and flagged the one month that was truly out of character.

Illustrative customer and values.

When it runs

Monthly, daily, and in real time where you need it.

Behaviour is checked on more than one clock. A monthly run looks back over the whole previous calendar month, a daily run over a window you set, and connected to Transaction Filtering, checks can run in real time as activity happens.

Every month

Monthly

Looks back over the previous calendar month for each customer, against their own history and their cluster.

Every day

Daily

Looks at activity within a time window you set, so a change surfaces without waiting for month end.

Optional

Real time

Connected to Transaction Filtering, the same statistics are checked as each payment is processed.

Needs additional implementation
Once, at set-up

Before the first run

The model is built from your history: at least two years is recommended. Starting from historical data gets alerts running sooner.

24 months of history

Getting started

From your history to a working model.

Clustering is built from your own data, not a generic template. It works alongside Client Risk Scoring and Transaction Monitoring, and is tuned with you until the alerts are the ones your team wants to see.

Your clustering projectHover any phase
01
Collect

A script gathers anonymised customer and activity data from your systems. Nothing in it identifies a person.

OutcomeAn anonymised dataset

Phases are shown in order, not to scale. Works with Client Risk Scoring and Transaction Monitoring; Transaction Filtering is optional, for real time.

Explore the DetectX® Platform

Rules work with every capability.

The Clustering & Modelling decides what happens. The other capabilities give it more to decide on. Pick one to see what it does.

All capabilities

Clustering & Modelling FAQs

What compliance and risk teams usually ask before they choose Clustering & Modelling.

Something we have not covered?Talk to our team

Your own history: client, account and activity data your systems already hold, prepared by Extraction & Transformation. Prospero recommends at least one year of history, ideally two or more. There's no single minimum record count; what matters is data quality, how far back it goes, and whether each client group is well represented.

Clients are grouped by how they behave, using their history and the data your systems hold about them. The clusters are built for each institution from its own data, not from a generic template, and DetectX® keeps statistics on every cluster and its members over time.

No. Your business rules stay in place as explicit controls. Clustering adds signals alongside them: each client's deviation from their own history and their peers, and thresholds that move with behaviour. During implementation, existing rules are analysed and backtested alongside the models.

Training, model selection and testing use separate datasets, with backtesting on your own history and evaluation at different thresholds. For regulator-facing use, Prospero offers a model-risk package covering intended use, data provenance, limitations, independent challenge, monitoring, version control and change approval.

Model performance can drift as behaviour and patterns change. DetectX® supports feedback learning, recalibration and thresholds that move with each client. A production plan monitors detection rates, false positives and alert volumes, with agreed triggers for recalibration and controlled model changes.

Monthly over the previous calendar month, daily over a window you set, and in real time where it's connected to Transaction Filtering, which needs additional implementation.

Yes. The same approach can find opportunity as well as risk, for example ranking cross-sell interest or churn risk. Data collected for AML purposes, and assessments derived from it, are not reused for sales. That would need separately collected data, processed lawfully and with the right permissions.

See Clustering & Modelling in a demo

Book a working session on your own portfolio. Bring your questions about how entities are grouped and what that changes downstream.