The assessment model designed for behavioural transaction monitoring.

Transaction monitoring needs a different kind of strategy.

Current transaction monitoring systems run on scenarios built from human intuition. A team of experienced investigators looks at how money laundering tends to show up, such as funds that pass straight through an account, transfers split to stay under a threshold, or sudden activity on a dormant account, and turns each pattern into a rule with fixed thresholds. These scenarios serve a purpose. They capture years of expertise, shaped by the capabilities of existing monitoring technology, and they catch only the patterns they were written for.

Where they fail is in keeping up with customers whose behaviour is always changing. A scenario applies predefined rules and thresholds across the customers or customer segments it covers, so customers covered by the same scenario are evaluated against the same criteria, regardless of differences in their individual behaviour. It does not know how a particular customer normally behaves, who is on the other side of the transaction, or which of the institution's procedures applies. Customers grow, change counterparties and shift their activity over time, while the scenario stays as it was written until someone retunes it. Every compliance team knows the result: queues full of alerts that turn out to be nothing, and real risk that slips through because it did not match a rule.

This approach has worked for a long time, and it is still how most institutions monitor their transactions. But it comes with well-known problems. Alerts arrive hours or days after the transaction has cleared, analysts spend a large share of their time closing alerts that should never have been raised (false positives), and the context each rule was missing has to be rebuilt by hand for every case.

That calls for a different strategy, one that evaluates every transaction on its own terms, adapts as each customer's behaviour changes, and applies your procedures consistently enough that every decision can be explained and defended. The assessment model is how we built it.

What an assessment model is.

An assessment model works differently from the large language models most people are now familiar with. A general-purpose large language model typically produces open-ended language: given a prompt, it generates an answer token by token. An assessment model is built to choose from a pool of options it is given. It is given a case and a fixed set of questions, each with a fixed set of possible answers, and it returns the most likely answer to every question together with a confidence score for each option.

The underlying approach is not ours. Typesafe AI's Jev showed that a model of this kind could make fast, consistent decisions inside automated workflows, and Cloudflare recently took the approach further with Clef, an open-source decision model it uses for its own security and support work. Both are general-purpose: they will classify a support ticket as readily as a website. Brayns took the same principle for a single job: assessing a transaction, in the context of the customer, before it clears. That meant teaching the model to read what a compliance analyst reads, and to answer the questions a compliance analyst would consider when assessing the transaction.

What the model reads.

When a transaction arrives, the model does not look at it in isolation. It reads four things together, the way an analyst reads a case file: the transaction itself, the counterparty, the institution's own procedures, and the customer's behaviour over time. The underlying data and policies belong to the institution, and Brayns brings that context together for the assessment.

First is the transaction itself: the amount, the payment rail, the time, and the fact that it has not yet cleared. With it comes the counterparty, the person or company on the other side of the transaction. Who they are, where they are based, how long they have existed and whether the customer has ever transacted with them before often say as much about a transaction as the amount does.

Brayns brings two additional layers of context that traditional scenario-based monitoring does not typically evaluate together. The first is the institution's own procedures, their standard operating procedures (SOPs). Brayns reads your SOPs, your risk appetite and the conditions under which you expect a transaction to be flagged or stopped, so the assessments it makes follow your policies and institution-specific framework rather than applying a generic view of what constitutes risk. When a procedure changes, that change is reflected in how subsequent transactions are assessed.

The second is the customer's behaviour. Using the institution's own customer and transactional data, Brayns maintains an evolving picture of how each customer actually behaves: how many transactions are conducted, how funds move, how products/services are being used, and how that activity develops over the last week, month, quarter and year. That observed behaviour can also be assessed against what the customer has declared about their expected activity and other relevant customer information held by the institution.

Because this picture is updated as new transactions arrive, the model assesses each transaction in the context of the customer's current and historical behaviour, without requiring the model itself to be retrained as that behaviour changes. The same EUR 198,000 transfer can carry very different significance for a wholesaler that normally receives EUR 58,000 a month and for a distributor that routinely moves EUR 2 million. The assessment model can account for that difference.

Together, these four layers of context give the model the view of the case an experienced investigator would want before making a call, at the moment the transaction is made.

What it returns.

Once the model has read the case, it answers a fixed set of questions about it, all at once. Should the transaction be cleared, flagged or blocked? Which typology, if any, does the activity match? How far does it depart from the customer's normal behaviour? Does one of your procedures apply, and which one? How risky is it overall? Because the model reads the case a single time and scores every answer from that one reading, there is no back-and-forth and no text to generate. The answers arrive together, fast enough for the decision to sit inside the transaction flow, and the same facts always produce the same answers.

Explainability and observability are crucial for financial institutions. An assessment that cannot be explained cannot be defended, whether to an auditor, to a regulator or when reviewing why a customer's transaction was stopped. That is why the model assesses each case against your SOPs and states which specific procedures applied. When the model identifies that a transaction falls within your procedure for pass-through activity above EUR 100,000, the assessment card names that procedure, so anyone reviewing the case can check the decision against the policy it relied on. Alongside it, the card shows the key signals from the customer's normal behaviour that influenced the assessment, such as inflows over the last 30 days running at seven times their usual monthly level, or four times the usual number of incoming transactions. Every assessment is recorded together with what the model saw and what it relied on, so the reasoning behind any transaction and assessment can be followed, monitored and audited long after it was made.

Clear, flag or block. You draw the lines.

The assessment only matters if it can translate into action, and here the institution stays in charge. You define the confidence levels and conditions required for each outcome, and every transaction then takes one of determined paths.

Most transactions are routine, and the model clears them. The transaction goes through and nobody needs to look at it, which keeps the work that never needed a human out of the queue entirely. When something looks off but not seriously enough to stop the money, the model flags the transaction. It still goes through, and the case is picked up for review later with the assessment card already attached, so the analyst starts from the model's reasoning instead of from a blank screen.

Where those lines sit is a policy choice, and it belongs to you. Each institution can set escalation thresholds according to their risk appetite. Because equivalent facts are assessed consistently against the same criteria, and each assessment comes with its basis, those choices can be documented, tested and defended to a regulator in the same way as any other part of your compliance framework.

Built on real cases.

Compliance assessments are hard to replicate with synthetic data. Real transactions reflect the complexity, edge cases and judgement calls of actual customer behaviour in ways synthetic data cannot fully reproduce. So we built the assessment model together with our design partners, and tested it on real transactions and on the assessments their teams actually made about them.

Each case was reviewed at second and third level, by the partners' compliance teams and by Brayns' compliance experts, giving us a high-quality reference assessment grounded in the judgement of experienced compliance professionals rather than relying on a first-pass review.

See behavioural transaction monitoring in your environment.

The assessment model is part of Brayns, and it runs behind transaction monitoring today. The best way to judge it is on your own transactions, with your own procedures and your own customers. Through our pilot programme, we set it up in your environment so your team can see how it assesses each transaction, what it relies on and why, and compare the results against your existing setup before anything changes in production. Get in touch to join the pilot.