Transaction monitoring built so that every tuning decision has evidence behind it, alert quality comes from segmentation rather than from thresholds, and coverage can be mapped against your own risk assessment.
A fraud programme can point to money it saved. A monitoring programme cannot, because the harm it exists to address happens elsewhere, to people the institution will never meet, and the counterfactual is unknowable.
The two functions use similar data, similar techniques and sometimes the same platform, and they are different disciplines with different objectives. Managing one with the other’s metrics is where most of the avoidable damage in this space comes from.
Alert volume exceeds the capacity to investigate
So the backlog becomes the real tuning mechanism.
Thresholds were set once and never evidenced
Nobody can say why the current settings are the right ones.
Everybody is calibrated as an average customer
Which generates noise for every customer who is not.
Scenarios exist that have never escalated anything
And nobody can retire them or justify keeping them.
Coverage has never been mapped to the risk assessment
So gaps are found during an examination rather than before.
Customer and transaction data sit apart
And context is what distinguishes unusual from expected.
Investigation quality falls quietly under pressure
Faster closures, less evidence, no measurement of either.
Fraud metrics were imported wholesale
Efficiency targets that are a liability in this setting.
Pick one scenario and ask why its current settings are what they are. Not what the settings are, why. Who set them, when, against what analysis, and what has changed since. In a great many institutions the answer is that they came from the vendor default or from an implementation several years ago and nobody has revisited them. That is the single most likely examination finding in this domain, it is entirely fixable, and establishing it takes one afternoon per scenario.
Monitoring programmes are scoped around scenarios and alerts. The artifact that matters most is neither of those. It is the record of how each decision was reached, because that record is what gets examined and what makes the programme defensible.
Which means the evidence is produced as the work happens rather than assembled afterwards, and assembled-afterwards evidence is visible as such.
Step 1
Start from your risk assessment, not from the scenario library
Step 2
Map existing coverage against those risks
Step 3
Establish customer and transaction data completeness as a control
Step 4
Integrate customer risk context with transaction data
Step 5
Segment the population into meaningful peer groups
Step 6
Define or review scenarios against named risks
Step 7
Test settings with evidence before changing them
Step 8
Document every judgement as it is taken
Step 9
Validate with your model risk function
Step 10
Design prioritisation and the investigation record together
Step 11
Deploy with quality assurance sampling in place
Step 12
Monitor quality, coverage, ageing and effectiveness separately
Ask how many of your scenarios have produced an escalation in the past year. The answer is almost always that several have produced none. Each of those is a finding in one of two directions: either the scenario is miscalibrated and is missing what it was built for, or the risk it addresses is not present in your business and it should be retired with a documented rationale. Both conclusions are defensible. What is not defensible is running it indefinitely without having reached either.
Grouped by what each capability contributes to a defensible programme rather than by technique, because in this domain the technique is rarely the limiting factor.
Monitoring and detection
Rules-based scenario monitoring, implemented against named risks and traceable back to them
Behavioural analytics at the customer and peer-group level, which is where context changes the interpretation
Anomaly detection used to surface what a scenario library was not written for, as a complement rather than a replacement
Transaction risk indicators combining customer risk context with activity, under definitions your financial crime function owns
Coverage mapping, so every monitored risk has a scenario and every scenario has a risk
Segmentation and tuning
Population segmentation and peer group construction, which is the main lever on alert quality
Scenario testing infrastructure that samples both sides of a setting and presents cases for investigator review
Tuning analysis with the evidence produced as an artifact rather than as a slide
Scenario effectiveness analysis, including those that have never escalated anything
Threshold change records, retained in a producible form
Entity, network and prioritisation
Entity resolution and relationship analytics, taken from the platform work rather than rebuilt here
Network analytics where the unit of interest is a group of related parties rather than one account
Alert grouping into a single case where alerts relate to one subject or one connected group
Risk-based prioritisation of the queue, with the basis documented
Investigation and evidence
Investigator-facing context
customer risk profile, relationship, history, prior cases and why the alert fired
Case record design, so the investigation file is complete, structured and producible without reconstruction
Quality assurance sampling of closed alerts, which is the control on investigation quality
Lineage from alert to case to any onward reporting, reproducible as it stood at the time
These are the scenario families named in most monitoring estates. This page describes what each one requires from the data and the governance to be defensible. It does not describe how detection works, and that omission is deliberate.
| Scenario family | What it depends on | Where it usually fails |
|---|---|---|
| Unusual activity for the customer | A reliable picture of normal, per peer group | Normal defined for an average customer |
| Activity arranged to avoid review | Aggregation across accounts and time windows | Aggregation stopping at the account boundary |
| Rapid movement of funds | Sequence, timing and linkage between movements | Transfers treated as unrelated single events |
| Cross-border activity | Counterparty, corridor and purpose context | Reference data quality on the counterparty side |
| Related party networks | Entity resolution and relationship data | Duplicate identities producing confident nonsense |
| Investigation and escalation | Context, case structure and reproducibility | The record being incomplete years later |
Monitoring architecture is usually drawn as a pipeline into a detection engine and out into case management. That diagram is complete and it omits the component that makes the programme defensible.
Tuning requires the ability to run a proposed setting against history, sample what sits on either side of it, present those cases to investigators and retain the result. Without that, every tuning decision is an opinion, and opinions are what examinations find.
Customer and transaction integration from core banking, payment platforms, channels and onboarding, on the patterns described on our Banking Data Platform Engineering page
Customer risk profile and rating data, carried as versioned and effective-dated values rather than as current state, since a historical decision used the rating in force then
A monitoring engine running rules and scenarios, with versioning over the scenario logic itself
Analytical and modelling capability alongside it for segmentation, behavioural work and anomaly detection
A tuning and testing environment with access to history, which is the component this section exists to argue for
Entity resolution and aggregation capability spanning accounts, parties and relationships
Case management as the system of record, and lineage from alert through case to any onward submission
And integration with your regulatory reporting workflow, under the controls described on our Regulatory Reporting & Compliance page
Integration boundaries. We build alongside your existing platforms and case management rather than requiring their replacement, which is both the faster route and usually the only one a risk function will approve
Source system protection. Extraction uses approved interfaces and agreed windows, without adding load to systems whose first job is to keep running, as described on our Banking Data Platform Engineering page
Named ownership of production failures. Every pipeline, job and interface has a person accountable for it when it breaks, agreed before go-live rather than discovered during an incident
Deployment pattern chosen on your policy. Cloud, on-premises and hybrid are decided by your residency, resilience, latency and cost position rather than by a preference we brought with us
Ask whether you can run a proposed threshold against last year and see what it would have missed. If the answer is that testing requires a project, an extract and a month, then tuning in your institution is effectively impossible and the current settings will persist by default. The testing capability is unglamorous infrastructure and it is what converts tuning from an argument into an evidenced decision. It is also the single most useful thing to build first in a programme under alert volume pressure.
Which AML and counter-terrorist-financing obligations apply, how risk is assessed, what monitoring is required, what constitutes suspicion and what must be reported are determined by your compliance, legal, risk and financial crime functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports an AML control framework. It does not independently establish one, and no platform makes an institution compliant.
Risk basis and coverage
- Every scenario traceable to a risk named in your risk assessment, and every identified risk traceable to a control
- Coverage mapped across products, channels, rails and customer types, with gaps named and owned rather than discovered
- Customer risk rating applied as versioned, effective-dated data, so a historical decision can be explained with the rating in force then
- Changes to the risk assessment flowing through to coverage as a controlled change rather than as a later discovery
Scenario and model governance
- Scenarios treated as models, tiered, documented and independently reviewed where your framework requires it
- Segmentation governed on the same basis, since it changes what every scenario considers normal
- Version control over scenario logic, thresholds and segment definitions, with effective dates
- Tuning evidence retained in a producible form, including what was tested, what was seen and who approved it
Investigation and record
- A defined standard for a complete investigation record, agreed before anybody is measured on throughput
- Quality assurance sampling of closed alerts, weighted toward those closed with no further action
- Lineage from alert to case to any onward escalation, reproducible as it stood at the time
- Retention per your records policy, in a form that outlives the platform that produced it
Access, privacy and confidentiality
- Access to alerts, cases and subject data scoped to named investigators rather than to the analytics population
- Confidentiality constraints respected across the analytical environment, including the suppression and activation paths described on our Customer & Transaction Analytics page
- Privacy and minimisation applied to monitoring data, which is among the most sensitive the institution holds
- Audit trails over access, alert decisions, closures, scenario changes and tuning approvals
Monitoring reporting is dominated by volume and false positive rate, and neither establishes whether the programme is working. The measures below are chosen because they say something about effectiveness and about defensibility.
Baselines and targets are agreed with you before anything is deployed. We do not claim a percentage improvement in the abstract, because the number depends on where you are starting from and that is knowable only once we have looked.
More importantly, every measure here can be improved in a way that makes the institution worse off. A smaller queue, a faster conclusion, a higher automation rate and a shorter cycle are all achievable by doing less, and none of them is an improvement if coverage, accuracy, fairness or control effectiveness fell to produce it. Each number is read with the thing it could be trading against.
| Failure | How it presents |
|---|---|
| A threshold moved to relieve the queue | Volume fell, and no tuning evidence exists |
| Investigation quality fell under pressure | Faster closures, thinner records, unchanged metrics |
| A scenario has never escalated anything | Running for years, neither validated nor retired |
| A data feed was incomplete | Alert volume dipped and nobody read it as a gap |
| Coverage drifted from the risk assessment | A new product live, and no scenario covering it |
| Aggregation stops at the account | Scenarios technically working on a narrow input |
| Backlog is doing the prioritisation | Alerts ageing out rather than being dispositioned |
| A segment became unstable | Normal redefined without anybody deciding to |
The outcomes below follow from three choices: evidence every tuning decision, reduce volume through segmentation rather than thresholds, and measure investigation quality before measuring speed.
Monitoring effectiveness that can be demonstrated, because each scenario traces to a risk and each setting to evidence
Lower investigation effort on alerts that were never going to escalate, achieved through segmentation and prioritisation
Audit readiness as a by-product rather than a project, since the evidence is produced as the work happens
Coverage gaps found internally rather than externally, which is the entire difference in how they are treated
Investigation records that hold up years later without the original analyst
Financial crime visibility across related parties rather than per account
A backlog that is managed rather than functioning as the undocumented tuning mechanism
We will take one scenario and establish four things: whether its settings can be evidenced, whether its input data supports what it is meant to detect, what it would have surfaced at a different setting, and whether the risk it addresses is covered anywhere else. You get the findings whether or not we build anything.
CaliberFocus builds transaction monitoring analytics where every tuning decision is evidenced, coverage is mapped against your own risk assessment, and investigation quality is measured rather than assumed. We reduce alert volume through segmentation rather than thresholds, build the testing environment that makes tuning defensible, and treat scenarios as governed models.
- Tuning evidence produced as the work happens, not afterwards
- Alert quality improved through segmentation rather than thresholds
- Coverage mapped to every risk in your risk assessment
- Investigation quality sampled and reported alongside turnaround
Security & Compliance
