Risk models

Ce contenu n’est pas encore disponible dans votre langue.

In short

A risk model gives every transaction an anomaly score from 0 to 1: how unusual the transaction is compared with what your own workspace usually sees. About 0.5 is ordinary. The closer to 1, the more unusual.

Three things to hold on to:

A score decides nothing. The model never blocks, holds or alerts. It only adds a number that rules can read. An alert or a blocked payment still always comes from a rule that someone wrote and someone else approved.
Unusual is not the same as suspicious. The model knows what is rare. It does not know what is fraud or money laundering.
Your model is yours. It learns from your workspace’s transactions only and is used only in your workspace.

A workspace without a model behaves exactly as it did before models existed.

Why have one at all

Rules catch what somebody has already described: more than five agents in a day, a payout soon after a SIM swap. They can’t catch what nobody has thought to describe yet.

A model looks from the other side. It doesn’t know any typology. It learns what a normal day looks like for your customers and says, of each new transaction, this is like the others or this is not. That gives your rule authors a second signal to combine with the first:

 rule alone:           amount over GHS 20,000                        → many alerts, most ordinary
 rule + score:         amount over GHS 20,000 AND unusual for you    → fewer, more worth a look

How the score is worked out, in plain words

The model is an isolation forest. The name is the method: it measures how easy a transaction is to isolate from all the others.

Think of the game of twenty questions, played on a crowd. You want to single out one person by asking yes-or-no questions chosen at random: taller than 1.70 m? older than 40? Someone average takes many questions, because every answer still leaves plenty of similar people. Someone seven feet tall is alone after one or two.

The model plays that game on transactions:

In training, it takes a random sample of your past transactions and splits it again and again with random questions about their features (amount above this? more than that many payments this week?), until each transaction stands alone. That makes one tree.
It grows many trees (100 unless you choose otherwise), each on a different random sample.
To score a new transaction, it asks each tree how many questions that transaction takes to isolate, and averages the answers.

Few questions means easy to single out, which means unusual, which means a score towards 1. Many questions means the transaction sits in a crowd, and the score stays near 0.5 or below.

What the model looks at

The questions are about features: numbers that describe the transaction and the recent behaviour around it. Every model reads the same 16 standard ones:

About	Features
The transaction	Its amount, and the hour of the day
The customer	Days since onboarding; how many transactions and how much in the last 24 hours; how many in the last 7 days; money out and money in over 7 days; average and largest transaction over 30 days; how many different counterparties in 30 days
The account	Transactions in the last 24 hours; total value over 30 days
The counterparty	Transactions in the last 30 days
Comparisons	The amount against the customer’s 30-day average; the customer’s last 24 hours against their last 7 days

A model can also read the aggregates your own live rules compute (up to 16 more), so it looks at what your workspace already decided matters.

The model sees numbers only. It never sees a name, a phone number, an account number or any other identifier.

Score and percentile

A score comes with a percentile, and the percentile is usually the easier one to use.

	What it is	Example
Score	The model’s own measure, 0 to 1	`0.71`
Percentile	Where that score falls among the scores of the transactions the model was trained on, 0 to 100	`99.2`: more unusual than 99.2% of them

The score’s scale shifts a little from one trained version to the next. The percentile always means the same thing: 99 is the most unusual 1% of what the model learned from. That makes “percentile at or above 99” a steadier condition for a rule than “score above 0.68”.

Reasons: no score without an explanation

Every score comes with its reasons: up to three features that pushed it up most, strongest first, each with the value it had for that transaction. For example:

Reason	Value
Amount compared with the customer’s 30-day average	14.2
Customer: number of transactions, last 24 hours	23
Hour of the day	3

So an analyst never has to take the number on trust. They read this is 14 times this customer’s usual amount, at three in the morning, on their busiest day this month, and judge that.

The reasons are exact, not an approximation: each feature’s share is the part of the path through the trees that its questions account for, and the shares of all the features together account for the whole score, with nothing left unexplained. SpeculaPro never shows or stores a score without its reasons.

Why it needs no labels

Many models learn from labels: thousands of past transactions marked fraud or not fraud. Most institutions don’t have those in any number, and the ones they have describe yesterday’s fraud.

This model needs none. It learns only from what your transactions look like. That is why it can be trained on day one of a pilot, and also why it has limits:

It can’t tell you a transaction is fraud. It can only tell you it is rare.
There is no accuracy figure to report: with no labels, there is nothing to be right or wrong against. The model card reports the spread of its scores instead.

Draft, shadow, live, retired

A model version moves through four states, and it can only feed rules in one of them.

 train ──▶ Draft ──▶ Shadow ──▶ Live ──▶ Retired
           scores     scores     rules read
           nothing    recorded,  its score
                      hidden
                      from rules

State	What it does
Draft	Trained, or still training. Scores nothing
Shadow	Scores every transaction. The scores are counted so you can see how the model behaves, and never reach a rule
Live	The model rules read
Retired	Stopped for good. Kept in the registry for the record

Shadow is a rehearsal on real traffic. You see how the model’s scores are spread and whether they stay steady, before a single rule depends on them. A version can only go live from shadow.

Going live always needs a second person. Whoever proposes it gives a reason, and someone else approves. No setting turns that off, and the database itself refuses a live model without an approver who is not its proposer.

The Risk models page with its registry: one version, v1, in the Shadow state, with its training window, transactions, features and a Stable drift reading

A workspace runs one live model and one shadow model at a time. Promoting a new version retires the one before it.

Models get stale: drift

A model describes the weeks it was trained on. When your customers or products change (a new merchant product, a salary season, a fee change), today’s transactions stop looking like the training data, and scores shift. That is drift.

SpeculaPro measures it with the population stability index (PSI), a standard figure that compares two spreads of values: recent ones against the training ones.

PSI	Reading
Under 0.1	Stable
0.1 to 0.25	Moderate drift: keep an eye on it
Above 0.25	Significant drift: train a new version

When a shadow or live version’s drift is significant, the people who train and approve models (models.manage, models.approve) get a notification, Risk model version N has drifted, once a week for as long as it lasts.

Nothing changes what scores by itself. A person trains a new version, watches it in shadow and proposes it. A workspace can switch on a retraining schedule, weekly or monthly, so that a fresh draft is waiting; the schedule never moves a version to shadow or live. See The retraining schedule.

The model card

Each trained version carries a model card: one document saying what the model is, what data it learned from, what it is for and not for, its limits, what the stored model contains and how it is governed. It is the page to hand an auditor or a regulator who asks what is this model and who approved it?

Limits to keep in mind

Unusual is not suspicious. A bonus, a house purchase or a new line of business scores high too. Expect false positives, and combine the score with other conditions.
Usual is not legitimate. Activity that was already common when the model was trained, such as an established mule pattern, looks ordinary to it.
New customers read oddly. With little history, their aggregates are small, which can look unusual in either direction.
Scheduled rules don’t get a score. Only real-time and post-event rules do.
This is the first stage. There is one kind of model (the anomaly score), no models that learn from your labels yet. A retraining schedule can train drafts for you, but nothing is promoted automatically.