Anti Money Laundering (AML) and Fraud Detection
Compliance Guidance
Author: Richard Churchman
Version: 3.1
Date: 13th March 2026
1
Contents
Contents..........................................................................................................................1
Amendments...................................................................................................................4
Introduction to Methodology ...........................................................................................5
Training and Implementation ...........................................................................................6
Core Principles of AML Monitoring ...............................................................................6
Countermeasures and Customer Due Diligence (CDD) ...............................................7
Automated Monitoring Systems ...................................................................................7
Jube’s Data-Driven Risk-Based Approach ....................................................................7
About Jube.......................................................................................................................9
Focus on AML Transaction Monitoring..........................................................................9
Value Proposition for End Users ...................................................................................9
Further Reading............................................................................................................9
Risk Factors ...................................................................................................................10
Modelling Risk Factors in Jube....................................................................................10
Sanctions................................................................................................................10
Product Characteristics ..........................................................................................10
Product MCC Spend ...............................................................................................11
Product Country Spend ..........................................................................................11
Account Characteristics .........................................................................................11
Lists............................................................................................................................11
Further Reading ......................................................................................................12
Sanctions ...................................................................................................................12
Further Reading ......................................................................................................12
Product Characteristics .............................................................................................12
Further Reading: .....................................................................................................14
Product MCC Spend...................................................................................................14
Product Country Spend..............................................................................................15
CDD and Account Factors..........................................................................................15
Data Integration.............................................................................................................18
Example Models.........................................................................................................18
Model Configuration...................................................................................................18
Integration Method.....................................................................................................18
2
Optional IP Address Decoding....................................................................................19
Outcomes of Integration ............................................................................................19
Further Reading..........................................................................................................19
MLRO Dashboards.........................................................................................................20
Objectives of MLRO Dashboards................................................................................20
Design and Customization .........................................................................................20
Benefits of MLRO Dashboards and Risk Factor Lists ..................................................20
Further Reading..........................................................................................................20
Machine Learning ..........................................................................................................22
Classification (Supervised Learning)..........................................................................22
Unsupervised Learning ..............................................................................................22
Exhaustive Adaptation Concepts ...............................................................................23
Exhaustive Training Algorithm.....................................................................................23
Further reading...........................................................................................................24
Data Foundations & Minimum Dataset Requirements...................................................25
Further Reading..........................................................................................................25
Analytical Methodology (Quantitative Framework) ........................................................25
Label Data Availability and Fallback Methodology .....................................................26
Standard Use of Label Data ....................................................................................26
Fallback Methodology for Weak or Absent Labels...................................................26
Governance and Audit Considerations.......................................................................27
Key Performance Indicators (KPIs) .............................................................................27
Statistical and Analytical Methodology ......................................................................28
Model Validation and Performance Assurance...........................................................29
Objectives of Model Validation ...............................................................................30
Distributional Analysis and Feature Validation........................................................30
Model Calibration and Probability Validation ..........................................................30
Discriminatory Power and Ranking Validation.........................................................31
Stability and Population Drift Analysis ....................................................................31
Sensitivity and Stress Testing ..................................................................................31
Back-Testing and Outcome Review.........................................................................32
Sign-Off Expectations.................................................................................................32
Further Reading..........................................................................................................33
3
Activation Rules.............................................................................................................33
Further Reading ......................................................................................................34
Case Management ........................................................................................................35
Case Audit..................................................................................................................35
Case Uploads.............................................................................................................35
Case Escalation .........................................................................................................36
Further Reading..........................................................................................................36
Summary .......................................................................................................................37
Risk Factors................................................................................................................37
Core Principles...........................................................................................................37
Automated Monitoring................................................................................................37
Data‑Driven Risk‑Based Approach .............................................................................37
Case Management .....................................................................................................37
MLRO Dashboards .....................................................................................................38
Integration and Data Processing.................................................................................38
Analytical Methodology and Minimum Dataset Requirements...................................38
Performance Measurement and Validation ................................................................38
Value Proposition .......................................................................................................39
4
Amendments
Date Author Version Description
28th February 2025 Richard
Churchman
2.0 Substantial update
and rewrite from
version one.
Improved writing
and linked to
documentation
instead of using
images.
3
rd March 2025 Richard
Churchman
2.1 Updated to include
details about
training.
6
th February 2026 Richard
Churchman
3 Updated for more
rigorous analytical
methodology.
14th March 2026 Richard
Churchman
3.1 Title page and font
formatting.
Updated training
block for new plan.
5
Introduction to Methodology
This document outlines a framework designed to assist in monitoring compliance with
Anti-Money Laundering (AML) regulations using Jube, open-source software utilized for
fraud prevention and transaction monitoring, but with a sharp focus on regulatory
prescribed transaction monitoring such as Anti Money Laundering (AML). This
framework is based on regulatory guidance from the Financial Action Task Force (FATF),
and the Wolfsberg Principles. Jube, being open-source and with global reach, is
foreseeably exposed to local market regulations, and the working assumption is that
such regulations will be derivative of FATA and the Wolfsberg Principles to some extent,
but not enough to be compliant.
The scope of AML compliance is extensive, and this document focuses specifically on
the monitoring requirements outlined in the guidance. While guidance does not endorse
a rigid, unthinking approach, it highlights several clear risk factors, including:
• Country and Geographic Risk
• Distribution Channels Risk
• Transaction Behavioural Risk
• Product Liquidity and Use of Cash-Like Instruments (e.g., utility instruments like
petrol, highly negotiable instruments like Bitcoin, and products linked to crime
such as gambling and adult services)
• Anonymous Financial Products
• Online Products Vulnerable to Impersonation
• Person-to-Person Remittance and Low Financial Inclusion Products
The guidance acknowledges that risk factors often interact, with high-risk factors
potentially being offset by low-risk ones. While the guidance suggests a subjective,
experience-based weighting of risks, this approach is prone to judgmental bias. A datadriven approach, combined with subjective judgment, is recommended as a more
reliable method. This trade-off approach aligns well with supervised and unsupervised
learning techniques.
6
Training and Implementation
Speed up implementation with hands-on, face-to-face training from the developer.
This training specifically focuses on the AML (Anti-Money Laundering) use case and is
structured around this guidance. Compliance managers are encouraged to adapt it to
align with their organisation's specific regulatory obligations, which are typically derived
from Financial Action Taskforce (FATF) guidelines and further reflected in the Wolfsberg
Principles.
Jube operates as a real-time system, and while the training emphasises implementation
of this guidance, other transaction monitoring use cases are addressed by implication
throughout. The underlying concepts are largely adjacent and require similar
methodologies, with only subtle differences in application.
Training is delivered remotely over seven weeks directly by the developer. By the end of
the programme, participants will have configured rules, machine learning models, and
case management workflows against this guidance, and will have deployed and chaostested a production-grade high availability cluster — covering Docker Swarm, Patroni,
Redis Sentinel, and HAProxy. The aim is that your team leaves with the confidence and
capability to operate Jube independently in a real environment, not just familiarity with
its features.
Visit https://jube.io/jube-training for details.
Core Principles of AML Monitoring
The overarching principle of AML compliance is Know Your Customer (KYC), achieved
through due diligence, understanding the business and products, and conducting
ongoing transaction monitoring in a timely (though not necessarily real-time) manner.
Financial institutions are granted significant latitude under a Risk-Based Approach
7
(RBA), allowing them to assess risk factors and implement controls proportionate to the
risks posed by their products.
Countermeasures and Customer Due Diligence (CDD)
The primary countermeasure available to financial institutions is the rigorous
application of Customer Due Diligence (CDD). CDD aims to ensure that institutions can
verify the identity of customers, beneficial owners, and the nature of their transactions.
There are five practical levels of CDD:
• Anonymous: No due diligence.
• Simplified Due Diligence (SDD): Verification of identity, sanctions, political
exposure, and address. Monitoring product use within strict thresholds and
limits.
• Enhanced Due Diligence (EDD): Verification of identity, address, and source of
funds.
• Enhanced Monitoring (EM): Diligent monitoring of transactions within tight
thresholds or manually.
• Suspicious Activity Reporting (SAR): Reporting suspicious activities to financial
crime investigation authorities.
The weaker the CDD, the greater the exposure to money laundering. Therefore, the
standard of CDD must be considered during monitoring, alongside a thorough
understanding of product risks and prevailing risk factors. Additionally, maintaining a
robust audit trail is critical to demonstrate diligent transaction monitoring and CDD
escalation to regulators.
Automated Monitoring Systems
The use of automated monitoring systems is permitted and, in some cases, encouraged
by regulatory guidance. However, the Money Laundering Reporting Officer (MLRO) must
fully understand how these systems function. Given the evolving nature of financial
crime, monitoring frameworks must be adaptable to emerging threats.
Regarding "tipping off" (the risk of alerting suspects to investigations), there is no
requirement for real-time monitoring. Implementing systems on a batch or
asynchronous basis (after the event) can reduce the risk of compromising
investigations. Notwithstanding, Jube is real-time in its nature, refereeing to data
integration as follows in this document.
Jube’s Data-Driven Risk-Based Approach
Jube promotes a Data-Driven Risk-Based Approach to monitoring, addressing a key
challenge in AML: the absence of absolute outcomes. Instead, AML outcomes involve
varying levels of suspicion. To address this, the proposed model focuses on anomaly
detection and classification based on subjective levels of suspicion, as determined by
rules that escalate cases to case management.
8
This approach ensures that monitoring is both adaptive and proportionate, leveraging
data-driven insights to enhance the effectiveness of AML compliance efforts.
9
About Jube
Jube is an open-source software designed for monitoring transactions and events. It
features:
• Real-Time Data Processing
• AI-Driven Decision-Making
• Case Management
Jube excels in fraud prevention and abuse detection, with a particular focus on the AntiMoney Laundering (AML) transaction monitoring use case. The platform is built on the
principle that adjacent use cases—while keeping in mind Jube’s fastidious real-time
capabilities—will derive from the same foundational methodology.
Focus on AML Transaction Monitoring
Jube maintains a sharp focus on the AML transaction monitoring use case, developing
deep expertise in this area. The platform’s training and support are strongly oriented
toward this use case and its associated methodology.
Value Proposition for End Users
It is recognized that the discipline of AML is well-established. When end users evaluate
Jube, they are typically not looking for a greenfield implementation but rather:
• Cost Reduction: Eliminate the prohibitive costs associated with proprietary
solutions.
• Vendor Lock-In Eradication: Gain flexibility and control by avoiding dependency
on single vendors.
• Improved Compliance: Access more advanced tooling to enhance compliance
with regulatory requirements.
Jube represents a powerful, cost-effective, and flexible solution for AML transaction
monitoring. By leveraging its real-time capabilities, advanced tooling, and open-source
nature, financial institutions can reduce costs, eliminate vendor lock-in, and enhance
compliance. Jube’s focus on AML, combined with its adaptability to derivative use
cases, makes it an asset in the fight against financial crime.
Further Reading
• About Jube: https://jube-home.github.io/jube/
• Getting Started: https://jube-home.github.io/jube/GettingStarted/
• GitHub: https://github.com/jube-home/jube
10
Risk Factors
Risk factors are developed by aggregating customer account transactions and product
characteristics. These factors focus on four core areas, aligned with the most prevalent
risk factors outlined in regulatory guidance:
Characteristic Grouping Description
Product
This grouping captures the behavioural characteristics of
financial products. It includes summary statistics that
describe typical product behaviour and the degree of
variation in that behaviour.
Product MCC Spend
This grouping contains aggregated data on spending
by Merchant Category Code (MCC) for a given product type. It
provides summary statistics describing typical monetary
outflows for the product.
Product Country Spend
This grouping contains aggregated data on spending
by Country Code for a given product type. It provides
summary statistics describing typical monetary outflows for
the product.
Account Characteristics
This grouping captures behavioural characteristics of
individual accounts. It includes summary statistics and
behavioural flags that describe account behaviour and the
operating environment of the account.
Modelling Risk Factors in Jube
The following factors will be modelled in Jube to enable Machine
Learning and Activation Rules. In Jube, risk factors can be modelled using Abstraction
Rules. Below is an explanation of the factors within their core groupings:
Sanctions
• Distance: First and foremost, the obligation to screen customer names, source
and destination account names via sanctions lists. Distance algorithms ensure
than minor variations, deliberate or otherwise, do not evade sanctions
screening.
Product Characteristics
• Typical Behaviour: Summary statistics describing the normal usage patterns of
the product (e.g., average transaction size, frequency, and volume).
• Behavioural Variance: Measures of how much the product's usage deviates from
the norm (e.g., standard deviation of transaction amounts or frequencies).
11
Product MCC Spend
• MCC-Based Spending Patterns: Aggregated data on spending by Merchant
Category Code (MCC), such as retail, travel, or entertainment.
• Typical Outflows: Summary statistics describing the average monetary outflows
for specific MCCs associated with the product.
Product Country Spend
• Country-Based Spending Patterns: Aggregated data on spending by Country
Code, highlighting geographic trends in product usage.
• Typical Outflows: Summary statistics describing the average monetary outflows
for specific countries associated with the product.
Account Characteristics
• Behavioural Flags: Indicators of unusual account activity (e.g., sudden spikes in
transaction volume, changes in spending patterns).
• Environmental Factors: Contextual information about the account's operating
environment (e.g., high-risk jurisdictions, use of anonymous products).
• Summary Statistics: Metrics describing the account's transaction behaviour
(e.g., average balance, transaction frequency, and amounts).
By modelling these risk factors, Jube enables a data-driven approach to AML
monitoring, allowing financial institutions to identify anomalies, assess risks, and
implement targeted controls effectively. This structured approach ensures compliance
with regulatory requirements while minimizing judgmental bias and enhancing the
overall effectiveness of transaction monitoring.
Lists
The Data-Driven Risk-Based Approach relies on several lists that can be referenced
in Activation Rules and Machine Learning models. These lists require regular
maintenance to remain effective. Below are the key lists that should be included and
regularly updated by the MLRO:
List Name Description
FATF Uncooperative
Countries
A list of countries identified by the Financial Action Task Force
(FATF/GAFI) as non-cooperative in AML efforts.
High-Risk Human
Trafficking Countries
A list of countries identified as high-risk for human trafficking,
based on resources such as the UNODC Global Report on
Trafficking in Persons.
Low GDP Per Capita
Countries
A list of countries with low GDP per capita, used to identify high
spending from regions with limited economic means.
12
List Name Description
Political Instability
Countries
A regularly updated list of countries exhibiting political
instability risks.
Sanctioned Countries A list of countries subjected to international sanctions.
Further Reading
• Lists: https://jube-home.github.io/jube/Configuration/Models/Lists/
• Dictionaries: https://jubehome.github.io/jube/Configuration/Models/Dictionaries/
Sanctions
The primary requirement is to screen customer names, as well as the names of source
and destination accounts, against sanctions lists. To account for minor variations—
whether intentional or unintentional—distance algorithms (e.g., Levenshtein Distance)
are used to ensure effective screening.
Characteristic Definition Period Grouping
Sanctions Distance
Recipient on Send
Sanctions match with a Levenshtein Distance
greater than two, applied to the recipient’s
name for each transaction.
Period: For each
transaction
Sanctions Distance
Sender on Receipt
Sanctions match with a Levenshtein Distance
greater than two, applied to the sender’s name
for each transaction.
Period: For each
transaction
Sanctions could be taken to be any textual dataset that has been published via a
regulator or central bank, such as US Office of Foreign Assets Control, or more
universally available as CSV from consolidated sources such as OpenSanctions.
Further Reading
• Sanctions: https://jube-home.github.io/jube/Configuration/Sanctions/
Product Characteristics
These characteristics are available for each Product ID and are used to describe the
typical behaviour and variability of financial products. Below is a detailed breakdown of
each characteristic, including its definition, applicable periods, and grouping:
13
Characteristic Definition Period Grouping
Average Inflow The average amount deposited
into a product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance Inflow
Describes the variability of the
average inflow, indicating its
reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average Outflow The average amount withdrawn
from a product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance Outflow
Describes the variability of the
average outflow, indicating its
reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average Maximum
Inflow
The average of the maximum
deposit amounts across
accounts for the product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance
Maximum Inflow
Describes the variability of the
average maximum inflow,
indicating its reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average Maximum
Outflow
The average of the maximum
withdrawal amounts across
accounts for the product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance
Maximum Outflow
Describes the variability of the
average maximum outflow,
indicating its reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average Minimum
Inflow
The average of the minimum
deposit amounts across
accounts for the product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance Minimum
Inflow
Describes the variability of the
average minimum inflow,
indicating its reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average Minimum
Outflow
The average of the minimum
withdrawal amounts across
accounts for the product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
14
Characteristic Definition Period Grouping
Variance Minimum
Outflow
Describes the variability of the
average minimum outflow,
indicating its reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average
Frequency Inflow
The average frequency (count)
of deposits across accounts for
the product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance
Frequency Inflow
Describes the variability of the
average frequency of inflows,
indicating its reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Average
Frequency
Outflow
The average frequency (count)
of withdrawals across accounts
for the product.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Variance
Frequency
Outflow
Describes the variability of the
average frequency of outflows,
indicating its reliability.
Periods: Day, Week, Month, Year,
Lifetime. Grouped: POS and
Cash/Quasi Cash.
Further Reading:
• Abstraction Rules: https://jubehome.github.io/jube/Configuration/Models/AbstractionRules/
• TTL Counters: https://jubehome.github.io/jube/Configuration/Models/TTLCounters/
• Environment Variables: https://jubehome.github.io/jube/Concepts/EnvironmentVariables/
Product MCC Spend
These characteristics are available for each Product ID and Merchant Category Code
(MCC), providing insights into spending patterns associated with specific product types
and merchant categories. Below is a detailed breakdown of each characteristic,
including its definition, applicable periods, and grouping:
Characteristic Definition Period Grouping
Average Transaction
Amount
The average transaction amount for a given
product and MCC.
Periods: Rolling
Three Months.
Variance Transaction
Amount
Describes the variability of the average
transaction amount, indicating its reliability.
Periods: Rolling
Three Months.
15
Product Country Spend
These characteristics are available for each Product ID and Country Code of Spend,
providing insights into spending patterns associated with specific product types and
geographic regions. Below is a detailed breakdown of each characteristic, including its
definition, applicable periods, and grouping:
Characteristic Definition Period Grouping
Average Transaction
Amount
The average transaction amount for a given
product and country.
Periods: Rolling
Three Months.
Variance Transaction
Amount
Describes the variability of the average
transaction amount, indicating its reliability.
Periods: Rolling
Three Months.
CDD and Account Factors
These characteristics are available for each Account or Relationship ID, providing
detailed insights into customer behaviour and due diligence status. Below is a detailed
breakdown of each characteristic, including its definition, applicable periods, and
grouping:
Characteristic Definition Period Grouping
eKYC Flag
A Yes/No (1/0) flag indicating if the customer
has been verified by eKYC verification
methods.
Periods: Lifetime.
Manual KYC Flag
A Yes/No (1/0) flag indicating if the customer
has been verified by manual KYC verification
methods.
Periods: Lifetime.
Days Since
Account Open
The number of days elapsed since the
account was opened. Periods: Lifetime.
Days Since
Account
Transacting
The number of days elapsed since the
account first started transacting. Periods: Lifetime.
Identity
Duplication
A Yes/No (1/0) flag indicating if heuristics
(e.g., name, address, date of birth, email, or
device recognition) suggest duplication with
another account.
Periods: Lifetime.
Inflow The absolute amount deposited into the
customer account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
16
Characteristic Definition Period Grouping
Outflow The absolute amount withdrawn from the
customer account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Maximum
Transaction
Inflow
The largest deposit into the customer
account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Minimum
Transaction
Inflow
The smallest deposit into the customer
account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Maximum
Transaction
Outflow
The largest withdrawal from the customer
account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Minimum
Transaction
Outflow
The smallest withdrawal from the customer
account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Transaction
Frequency Inflow
The number of deposits into the customer
account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Transaction
Frequency
Outflow
The number of withdrawals from the
customer account.
Periods: Day, Week,
Month, Year,
Lifetime. Grouped: POS
and Cash/Quasi Cash.
Source of Funds
Underwritten
A Yes/No value indicating if a Source of
Funds Underwriting Process has been
completed.
Periods: Lifetime.
Spends Outside
Top 10 MCC
Indicates if the customer spends outside
the Top 10 Merchant Category Codes
(MCCs) for the product.
Periods: Day, Week,
Month, Year, Lifetime.
Spends Outside
Top 5 Countries
Indicates if the customer spends outside
the Top 5 Countries for the product.
Periods: Day, Week,
Month, Year, Lifetime.
17
Characteristic Definition Period Grouping
Spends Outlier
for MCC
Indicates if the customer’s spending falls
outside the range of 90% of customers for a
given MCC.
Periods: Day, Week,
Month, Year, Lifetime.
Spends Outlier
for Country
Indicates if the customer’s spending falls
outside the range of 90% of customers for a
given country.
Periods: Day, Week,
Month, Year, Lifetime.
18
Data Integration
The effectiveness of risk factors in Jube relies on the seamless integration of relevant
data sources. Integration is achieved through the concept of models, which are
configured to process, aggregate, and analyse data for monitoring purposes. Below is an
outline of the proposed models, integration methods, and additional functionalities:
Example Models
The following models are recommended to ensure comprehensive data integration:
• Payment scheme authorisations:
o Purpose: Capture all authorization records for payment scheme or brand
transactions.
o Outcome: Provides a complete and enhanced view of transactions
processed through these payment networks.
• Financial Transactions and Clearing:
o Purpose: Capture all financial transactions representing inflows and
outflows to an account.
o Includes: Deposits, withdrawals, and abridged cleared payment scheme
transactions.
• Customer Due Diligence (CDD) Events
o Purpose: Capture events related to customer verification processes.
o Examples: Address validation, identity validation, source of funds
verification, sanctions matching, etc.
Model Configuration
Each model is configured via Jube’s user interface, where key values and fields are
specified. The Request XPath page is used to define:
• Additional Fields: Fields made available for rule creation.
• Search Keys: Designated fields that enable the model to perform aggregations as
outlined in the risk factors section.
Integration Method
The proposed integration method involves the following steps:
• Real-Time or Batch Preparation: Prepare messages in real-time or relay data from
a database or other latent data store.
• Message Compilation: Compile the data into a JSON message.
• Data Transmission: Relay the message to Jube via HTTP.
• Serial Processing: Even if the data is latent, it will be processed serially in
ascending datetime order, simulating real-time transaction processing.
19
Optional IP Address Decoding
Where available, IP addresses are decoded to provide geographic and contextual
information about the session. This is achieved using an Inline Script to
call IP2Location, which returns details such as:
• Country
• Coordinates
• ISP (Internet Service Provider)
• Region
• Usage Type/Connection
• Net Speed
• City
• Domain
• IDD & Area Code
• ZIP Code
• Elevation
• Weather Station
Outcomes of Integration
The integrated data and risk factors can be utilized in the following ways:
• Comprehensive Data Coverage: Ensures all relevant transaction and customer
data is captured and analysed.
• Enhanced Monitoring: Enables real-time or near-real-time processing of latent
data.
• Geographic Insights: Decodes IP addresses to provide contextual information for
risk assessment.
• Flexibility: Supports integration with external services for PEP and sanctions
validation.
• Actionable Insights: Facilitates the creation of dashboards, machine learning
models, and activation rules for proactive AML compliance.
Further Reading
• Models: https://jube-home.github.io/jube/Configuration/Models/Models/
• Request XPath: https://jubehome.github.io/jube/Configuration/Models/RequestXPath/
• Inline Scripts: https://jubehome.github.io/jube/Configuration/Models/InlineScripts/
• Gateway Rules: https://jubehome.github.io/jube/Configuration/Models/GatewayRules/
20
MLRO Dashboards
The framework outlined in this document emphasizes that AML (Anti-Money
Laundering) monitoring must be an evolving process. To support this, it is critical
that MLRO Dashboards provide timely, comprehensible, and visually intuitive reporting.
These dashboards enable the Money Laundering Reporting Officer (MLRO) to gain a
deep understanding of:
• Product Behaviour
• Customer Activity
• Territorial Risks
• Distribution Channels
The scope of MLRO reports should not be limited to the current framework but should
also serve as a tool for proactively creating new controls and adapting to emerging risks.
Objectives of MLRO Dashboards
The primary objectives of MLRO dashboards are:
• Drive Innovation: Facilitate the creation of innovative control hypotheses to
address emerging risks.
• Monitor Rule Performance: Profile the performance of rules and assess their
proportional contribution to the Data-Driven Risk-Based Approach.
• Evolve Risk Factors: Ensure that risk factors and rules are continuously updated
based on insights derived from the dashboard.
Design and Customization
MLRO Dashboards can be instantly designed and customized using Jube’s Reporting
Designer. This tool allows for the creation of tailored visualizations and reports that align
with the MLRO’s specific needs, ensuring flexibility and adaptability.
Benefits of MLRO Dashboards and Risk Factor Lists
The combination of MLRO Dashboards and Risk Factor Lists ensures that financial
institutions can:
• Monitor and Adapt: Continuously evolve their AML monitoring frameworks based
on real-time insights.
• Proactively Manage Risks: Identify emerging threats and implement targeted
controls to mitigate them.
• Ensure Compliance: Maintain alignment with regulatory requirements and global
best practices.
Further Reading
• Visualisations: https://jube-home.github.io/jube/Configuration/Visualisations/
21
22
Machine Learning
Jube supports the use of risk factors in both Machine Learning (ML) and Activation
Rules. The platform offers two types of Machine Learning:
• Classification (Supervised Learning).
• Unsupervised Learning.
Classification (Supervised Learning)
• Purpose: Identifies accounts that conform to a known classification, such as
"Suspected Money Laundering."
• Process: Analysts must diligently flag highly suspicious transactions in the Case
Management System using the star rating functionality.
• Outcome: A curated sample of highly suspicious transactions is used to train
Jube’s embedded classification engine.
• Goal: Distils numerous risk factors into a score that indicates the likelihood of a
transaction being related to money laundering.
• Use Case: The score is recalled for each transaction processed through Jube and
can be used in Activation Rules to escalate accounts to Case Management if the
score exceeds a predefined threshold.
Limitations of Classification:
• Rapidly Changing Risks: Classification models are less effective in environments
where risk typologies evolve quickly, as they are better at detecting known
patterns than emerging risks.
• Anomaly Detection: Classification models are less capable of identifying new or
anomalous behaviour.
Unsupervised Learning
To counter the limitations of Classification, Jube employs One-Class Support Vector
Machine (SVM), a technique that groups customers based on similar behaviours using
the risk factors described in this document. Unlike Classification, Unsupervised
Learning does not require transactions to be marked as suspicious to learn.
Benefits of Unsupervised Learning:
• Anomaly Detection:
o Most customers fall into a small number of clusters representing typical
behaviour.
o Outlier clusters represent anomalous behaviour, which can be flagged for
further investigation.
• Unbiased:
o Anomalies are identified based on behavioural similarities without
predefined labels.
23
Exhaustive Adaptation Concepts
Traditional risk management or anomaly detection is typically rule-based. Examples of
rules might include:
• More than four transactions in one day.
• More than two declined transactions in one day.
• More than two different transactions in one day.
• More than five transactions at the same merchant in one day.
• Transactions more than twice (x2) the customer’s average transaction.
While rules are effective, their derivation is often anecdotal, and thresholds are rarely
adapted over time. This leads to:
• Rule Proliferation: The number of rules tends to grow, making them difficult to
manage.
• Diminishing Efficacy: Rules often fail to adapt to new risk typologies, reducing
their effectiveness.
Jube combines Supervised and Unsupervised Learning to create a robust and adaptive
risk management system.
Key Steps in Jube’s Machine Learning Process:
• Data Extraction: Data is extracted from Jube for Abstraction Rules, which include
continuous values such as transaction counts, declined transactions, and
customer averages.
• Anomaly Detection: Data is trained based on anomaly, where highly anomalous
events are classified as fraudulent.
• Blending Feedback Data: Anomaly data is blended with specific feedback data
tagged by analysts, which is lower in volume but highly salient.
• Neural Network Training: Multiple neural network topologies (e.g., hidden layers,
activation functions) are trialled, evolved, and trained based on the data.
Outcome:
• A complex neural network model is created on a quantitative basis.
• The model identifies optimal topology using the Levenberg-Marquardt
Backpropagation Algorithm.
• The system continuously adapts by retraining models in a champion-challenger
framework, ensuring ongoing relevance and accuracy.
Exhaustive Training Algorithm
Jube’s Exhaustive training algorithm follows these steps:
1. Variable Collation: Eligible variables (e.g., from Abstraction Calculations, TTL
Counters, and Abstraction Rules) are collated.
24
2. Data Sampling: A sample of data is extracted from the archive, excluding class
variables.
3. Statistical Analysis: Statistics are performed on the sample for Z-score
normalization.
4. Normalization: Continuous variables are normalized, while binary variables
remain unchanged.
5. Anomaly Detection: A One-Class Support Vector Machine is trained to detect
anomalies.
6. Data Blending: Anomaly data is blended with feedback data tagged by analysts.
7. Model Training: Neural networks are trained exhaustively, with topology and
variables selected randomly.
8. Performance Validation: Models are validated using testing data, and the most
performant model is selected.
9. Monte Carlo Simulation: A Monte Carlo simulation is performed to analyse
model sensitivity.
Further reading
• Exhaustive Adaptation: https://jubehome.github.io/jube/Configuration/ExhaustiveAdaptation/
• HTTP Adaptation: https://jubehome.github.io/jube/Configuration/Models/HTTPAdaptation/Index.html
25
Data Foundations & Minimum Dataset Requirements
A coherent and defensible AML monitoring programme must begin with clarity regarding
the minimum viable data estate required to implement the methodology. In keeping
with regulatory expectations and the principle of proportionality, the foundational
requirement is the transaction journal, which—when properly engineered—provides a
sufficiently rich basis for detecting anomalous behaviour and supporting both
rule‑based and probabilistic controls. The transaction journal encapsulates the
essential behavioural and financial descriptors upon which risk factors are constructed,
and, crucially, offers the temporal granularity required to develop, monitor, and validate
controls in a manner that is reproducible, empirically grounded, and operationally
practical.
While additional artefacts such as IP telemetry, device metadata, session attributes,
and biometric signals may enhance contextual richness, they are explicitly not
prerequisites for compliance or for the deployment of the methodology described
herein. Such artefacts are best treated as desirable or opportunistic rather than
foundational: their presence can refine feature engineering and improve discriminative
power, but their absence must not be permitted to delay the implementation of
mandated AML controls. A pragmatic approach is therefore required—one that
emphasises the sufficiency of the transaction journal while allowing the broader data
environment to mature in parallel, rather than conditioning regulatory progress on the
existence of an idealised data lake or vendor‑grade behavioural telemetry.
This pragmatic stance is particularly important in regulated environments where project
timelines, supervisory scrutiny, and legacy architecture place constraints on data
accessibility. The methodology is expressly designed to operate effectively within such
constraints: comprehensive feature construction, anomaly detection, threshold
calibration, and model validation can all be achieved using the minimum dataset, with
incremental enhancement applied as and when new data sources become reliably
available. In this way, the institution remains compliant, auditable, and operationally
aligned, while retaining a clear and ordered path towards continuous improvement of
the analytical estate.
Further Reading
• Jube R Advanced Analytics Guidance:
https://jube.io/AdvancedAnalyticsWithRGuidance.pdf
• Jube R Advanced Analytics Training:
http://advancedanalyticswithrtrainingplan.pdf/
Analytical Methodology (Quantitative Framework)
This document introduces the methodology for developing rules, models, and policies
in anti-money laundering and transaction fraud monitoring across a variety of channels,
with a sharp focus on regulated environments. Given regulated environments and the
26
prospect of a Central Bank audit, it is of paramount importance that a methodology be
followed to ensure all stakeholders coalesce and, above all, allow the data, thus policy,
to speak for itself.
Regulatory guidance tends not to be highly prescriptive, and it is for the regulated entity
to create rules and policies within the broad guidance; therefore, it is incumbent on the
bank to adopt a quantitative approach such that, upon scrutiny, objective justification
for all regulations and policies exists. While the guidance might not be wholly
prescriptive, it is not devoid of a framing of risk factors, which will hereinafter be referred
to as Features, and, alongside the consultant's own expertise in the domain, provides a
solid platform for implementing the methodology set out in this document.
Label Data Availability and Fallback Methodology
In practice, the methodology prioritizes the use of reliable labelled data to inform
supervised modelling and validate rules, ensuring that detection mechanisms are
grounded in known outcomes. When such labels are incomplete, inconsistent, or
unavailable, a robust fallback approach is applied, leveraging unsupervised analysis,
probabilistic inference, and expert-guided calibration to identify anomalous or high-risk
activity. As new and more reliable labels become available, the methodology
continuously incorporates them to refine models, thresholds, and rules, maintaining a
defensible, auditable framework that ensures regulatory compliance and operational
effectiveness throughout the lifecycle of the monitoring program.
Ideally, the bank maintains a dataset of transactions labelled as fraudulent or nonfraudulent. Such labels significantly enhance supervised learning and rule validation.
However, in practice, existing label data is often incomplete, inconsistent, or
unavailable, especially in early-stage implementations.
It is therefore critical that the methodology accounts for both reliable and unreliable
label scenarios, ensuring continuous and defensible risk monitoring.
Standard Use of Label Data
When trustworthy labels exist:
• Use them to train supervised Bayesian or probabilistic models.
• Validate feature importance, rule thresholds, and model calibration against
known outcomes.
• Compute KPIs such as True Positive Rate (TPR), False Positive Rate (FPR),
Precision, and ROC curves using labelled data.
Labels are also used to support rule recall testing, sensitivity analysis, and operational
calibration.
Fallback Methodology for Weak or Absent Labels
When label data is incomplete or unreliable, the methodology employs robust fallback
techniques:
27
• Unsupervised / Probabilistic Detection:
o Bayesian networks or similar probabilistic models detect anomalous
behavior without requiring labels.
o Conditional probabilities are computed based on feature states,
historical distributions, and transaction context.
• Feature-based Scoring:
o Risk scores are derived from engineered features such as transaction
amount, velocity, deviation from historical patterns, and behavioral
signals.
o Multiple features are combined probabilistically or via weighted
aggregation to flag high-risk transactions.
• Expert-guided Calibration:
o High-risk transactions identified by probabilistic or feature-based scoring
are reviewed by domain experts.
o Expert feedback informs threshold selection and refinement of rules for
deployment.
• Iterative Validation:
o As reliable label data becomes available over time, models, thresholds,
and rules are recalibrated.
o All adjustments are fully documented for auditability and regulatory
review.
Governance and Audit Considerations
The fallback methodology ensures that no critical risk is ignored due to missing labels.
All steps — feature derivation, probabilistic inference, expert oversight, and rule
thresholding — are documented and reproducible, satisfying audit and regulatory
requirements. KPI tracking (e.g., FPR, TPR, ROC curves, operational metrics) remains
active even under fallback conditions, ensuring continuous monitoring and defensible
reporting.
Key Performance Indicators (KPIs)
The following KPIs provide quantitative measures for evaluating rule and model
performance, ensuring robust governance and defensible reporting:
KPI Definition Purpose / Regulatory
Relevance
False Positive Rate (FPR) Percentage of legitimate
transactions flagged as
suspicious
Monitors operational
efficiency; controls
unnecessary customer
friction
Detection Rate / True
Positive Rate (TPR)
Percentage of fraudulent
transactions correctly
flagged
Measures effectiveness of
fraud/AML detection;
supports compliance
objectives
28
Precision / Positive
Predictive Value (PPV)
Fraction of flagged
transactions that are truly
fraudulent
Balances efficiency and
accuracy; informs
resource allocation for
investigation teams
Rule Coverage / Feature
Coverage
Proportion of transaction
types and portfolio
segments monitored by
rules/models
Ensures comprehensive
risk coverage and
regulatory defensibility
Model Calibration Metrics Comparison of predicted
vs. actual outcomes (e.g.,
expected vs. observed
probability of fraud)
Ensures probabilistic
predictions are accurate
and interpretable;
supports auditability
Case / Operational Metrics Volume of flagged
transactions, time-toreview, analyst workload
Tracks operational impact
of rules and models; helps
maintain sustainable
workflows
Cost Curves / ROC
Analysis
Receiver Operating
Characteristic (ROC)
curves, cost-benefit
curves for thresholds
Supports optimization of
thresholds and trade-offs
between detection and
false positives
Continuous Improvement
Metrics
Improvements in detection
or reduction in false
positives over time
Demonstrates ongoing
governance, learning, and
adaptive methodology
KPIs should be tracked per channel and transaction type to account for portfolio
heterogeneity, and periodically reviewed with compliance, audit, and risk teams.
Statistical and Analytical Methodology
All rules and models are grounded in quantitative, reproducible, and auditable
statistical techniques:
• Feature Engineering:
o Derive candidate features from transaction journal, IP/proxy, device,
session, and other accessible sources.
o Features include velocity, amount distributions, ratios, historical
patterns, and behavioural signals.
o Oftentimes this emulates features of another fraud management system,
compensating for lack of underlying data availability for analysis.
o Feature Engineering is laid out more prescriptively in the following
document: https://jube.io/JubeAMLMonitoringComplianceGuidance.pdf
• Exploratory Data Analysis (EDA):
o Univariate Analysis: Examine distributions, outliers, and anomalies per
feature.
o Bivariate / Multivariate Analysis: Identify relationships and dependencies
between features.
29
o Outliers are investigated and contextualized before model inclusion.
• Label Analysis and Feature Selection:
o Labelled transaction data, when available, is used to inform feature
importance.
o In cases of incomplete labels, unsupervised / Bayesian inference
techniques are used to probabilistically assess anomalous behaviour.
o Feature selection balances predictive power, interpretability, and
deployability within vendor systems.
• Modeling Framework:
o Bayesian Networks form the primary probabilistic framework for both
anomaly detection and prescriptive analytics.
o Probabilities of anomalous or fraudulent behaviour are inferred
conditional on feature states.
o Where label data exists, supervised Bayesian models are used to refine
detection probability estimates.
o Models are validated against historical data to ensure robustness,
calibration, and defensibility.
• Validation and Sensitivity Analysis:
o Rule thresholds are calibrated using ROC curves, cost curves, confusion
matrices, and expected vs. actual outcomes.
o Sensitivity of rules/models to parameter changes is tested to ensure
stability.
o Performance metrics (KPIs) are recalculated across simulated scenarios
to assess robustness under varied transaction volumes and risk profiles.
o Any calibration adjustments are documented for audit purposes.
• Continuous Improvement:
o Models, rules, and thresholds are reviewed periodically with new
transaction data, feature improvements, and evolving threat patterns.
o KPI trends over time inform adjustments, ensuring that probabilistic
models remain aligned with real-world behaviour.
The methodology ensures that all rules and models are defensible, reproducible, and
aligned with regulatory guidance, allowing auditors and compliance officers to verify the
rationale, implementation, and performance quantitatively.
Model Validation and Performance Assurance
A challenge with AML and fraud regulations is that they are not very prescriptive yet
carry significant financial penalty if not implemented properly. In keeping with this
methodology, everything is approached from a quantitative basis (i.e., we don't look at
that because it is in this dense section of the probability density, etc.). To model
validation, while this remains nonprescription for AML and fraud regulations,
techniques have evolved through several iterations of Basel, and that can be overlaid
into this regulatory problem.
30
Model validation within this methodology is designed to provide a rigorous,
proportionate, and auditable assurance framework aligned in principle with Credit Risk
model governance. Validation encompasses feature-level distributional analysis,
calibration of probabilistic outputs, assessment of discriminatory power, stability and
drift monitoring, sensitivity testing, and outcome-based back-testing where labels exist.
The approach explicitly recognizes that fraud and AML environments are adversarial and
non-stationary, that labelled outcomes may be incomplete or delayed, and that expert
judgement must complement statistical evidence. Accordingly, validation focuses on
defensibility, transparency, and stability of model behavior over time, rather than
spurious precision, ensuring that all models and rules remain fit for purpose,
interpretable, and aligned with regulatory expectations.
Objectives of Model Validation
Model validation ensures that all probabilistic models, rules, and thresholds are
statistically sound, stable over time, and fit for purpose within a regulated environment.
The objectives are to:
• Demonstrate that models behave consistently with observed data.
• Ensure outputs are interpretable, calibrated, and defensible.
• Identify model degradation, instability, or unintended bias.
• Provide an auditable trail equivalent in spirit to Credit Risk model validation.
Validation is performed prior to deployment, at material change, and on a periodic basis
thereafter.
Distributional Analysis and Feature Validation
Consistent with Credit Risk practice, validation begins at the feature level:
• Empirical distributions of all key features are examined (amounts, velocities,
ratios, behavioral indicators).
• Candidate parametric distributions (e.g. log-normal, Poisson, exponential, and
mixture distributions) are assessed where appropriate.
• Goodness-of-fit is evaluated using visual inspection (histograms, plots) and
statistical measures were meaningful.
• Features exhibiting instability, extreme skew, or structural breaks are either
transformed, segmented, or excluded.
This ensures that model inputs are well-behaved, interpretable, and stable, and that
probabilistic inference is not driven by artefacts.
Model Calibration and Probability Validation
For probabilistic and Bayesian models:
• Predicted risk probabilities are compared to observed outcomes where labels
exist (expected vs. observed).
• Calibration is assessed at portfolio, segment, and channel level.
31
• Where labels are weak or absent, calibration is assessed indirectly via:
o Stability of posterior distributions
o Consistency of anomaly scores over time
o Expert review of high-risk tails
Calibration analysis ensures that model outputs can be interpreted as meaningful risk
measures, not just rankings.
Discriminatory Power and Ranking Validation
Where labels exist, standard discriminatory measures are used:
• ROC curves and AUC.
• Precision / Recall.
• KS-style separation where applicable.
Where labels are weak or absent:
• Relative ranking stability is assessed across time windows.
• Concentration of risk in high-score bands is reviewed.
• Manual outcomes and downstream investigative feedback are incorporated.
This mirrors Credit Risk practice where full default histories may not yet exist.
Stability and Population Drift Analysis
Models and features are tested for temporal stability, including:
• Feature distribution drift over time.
• Changes in score distributions.
• Volume and composition of high-risk flags.
While PSI/CSI may be used cautiously, the emphasis is on interpretation rather than
mechanical thresholds, reflecting the dynamic nature of fraud behavior.
Significant drift triggers:
• Review of feature definitions.
• Recalibration of thresholds.
• Potential model re-estimation.
Sensitivity and Stress Testing
Sensitivity analysis is conducted to understand model robustness:
• Impact of threshold shifts on FPR, TPR, and queue volumes
• Behavior under elevated transaction volumes or changed customer behavior
• Impact of removing or perturbing key features
This ensures that models are operationally safe and not brittle.
32
Back-Testing and Outcome Review
Where historical outcomes exist:
• Models and rules are back tested on prior periods.
• Differences between historical and current performance are analyzed.
• Any material deviations are explained and documented.
Back-testing supports:
• Regulatory defensibility.
• Management confidence.
• Change approval decisions.
Sign-Off Expectations
All validation activities produce documented artefacts. Recommended actions
At key stages throughout the methodology, formal sign-off is expected from designated
stakeholders to ensure governance, accountability, and regulatory defensibility. These
checkpoints provide assurance that all analyses, models, and rules are reviewed,
validated, and approved before deployment. Typical sign-off points include:
• Feature Specification and Analytical Dataset Creation:
o Approval by Risk and Compliance teams that the selected features are
appropriate, relevant, and sufficient for the intended monitoring
objectives.
• Modelling Framework and Threshold Definition:
o Review and sign-off by Data Science Lead, Risk, and Compliance
confirming the probabilistic model structure, assumptions, and threshold
rationale.
• Rule Derivation and Deployment:
o Approval by Operations, Risk, and Compliance ensuring that rules derived
from model outputs are operationally feasible, aligned with risk appetite,
and implementable within vendor systems.
• Validation, Sensitivity Analysis, and KPI Assessment:
o Sign-off by Audit and Compliance to confirm that model performance,
rule calibration, and KPI tracking meet regulatory and internal standards.
• Ongoing Review and Continuous Improvement:
o Periodic governance reviews to approve updates to models, thresholds,
or rules as new data, labels, or operational insights become available.
All sign-offs are documented, time-stamped, and retained as part of the audit trail. This
ensures that all decisions are transparent, defensible, and fully traceable in compliance
with regulatory expectations.
33
Further Reading
• Jube R Advanced Analytics Guidance:
https://jube.io/AdvancedAnalyticsWithRGuidance.pdf
• Jube R Advanced Analytics Training:
http://advancedanalyticswithrtrainingplan.pdf/
Activation Rules
Activation Rules are used to escalate accounts and transactions into Case
Management based on risk factors and machine learning outcomes. Below is a list of
proposed Activation Rules:
Name Description
High TXN Amount >= 4000 A transaction exceeds EUR 4000 in value.
Automated Fuel Dispenser
(5542) >= 3txns in 1 day
More than three fuel dispensers used in a single day.
(Applies to utility transactions.)
High Velocity >= 7 Txns in a
day More than seven transactions in a day.
High Risk MCC >= 4txns in 5
hours
More than four transactions in a high-risk MCC within
five hours.
High Withdrawal >= 2000 in 2
days
More than 2000 EUR withdrawn from an account within
two days.
High Risk MCC High Amount
>= 1000 in 2 days
Transactions in high-risk MCCs (e.g., utilities or
negotiable instruments) exceeding 1000 EUR in two
days.
High Risk Country >= 2000 in 5
hours
More than 2000 EUR transacted in a high-risk country
within five hours.
High Amount >= 3000 over 2
days
More than 3000 EUR transacted within two days.
3 Countries in 6 hours and 1
HR Country
More than three transactions in three different countries
within six hours, with one high-risk country.
3 Countries in 1 day Not
Ecommerce
More than three transactions in one day, excluding
eCommerce transactions.
High Risk MCC >= 4 Txns in 6
hours
More than four transactions in high-risk MCCs within six
hours.
34
Name Description
Same Merchant >=3 txns in 1
day
Transactions where the same merchant is used more
than three times in one day.
ATM >= 500.00 EUR/day on 3
consecutive days
ATM withdrawals exceeding 500 EUR per day for three
consecutive days.
High Risk MCC >= 50,000 in 1
day
A high-risk MCC transaction exceeding EUR 50,000 in
one day.
High Deposit >= €300 in 6
hours
More than 300 EUR deposited into an account within six
hours.
Load then Refund in 1 day A load followed by a refund observed within one day.
Refund on two consecutive
days Two refunds observed on two consecutive days.
Multiple Refunds >= 3 in 2
days More than three refunds made within two days.
Further Reading
• Basic Activation Rules: https://jubehome.github.io/jube/Configuration/Models/BasicActivationRules/
• Response Elevation: https://jubehome.github.io/jube/Configuration/Models/ResponseElevation/
• TTL Counter Activation Rule Incrementation: https://jubehome.github.io/jube/Configuration/Models/TTLCounterActivationRuleIncrement
ation/
• Activation Watcher: https://jubehome.github.io/jube/Configuration/Models/ActivationWatcher/
• Activation Rule Notifications: https://jubehome.github.io/jube/Configuration/Models/ActivationRuleNotifications/
• Activation Rules Suppression: https://jubehome.github.io/jube/Configuration/Models/ActivationRulesSuppression/
• Rule Compilation Algorithm: https://jubehome.github.io/jube/Configuration/Models/RuleCompilationAlgorithm/
• Reprocessing: https://jube-home.github.io/jube/Configuration/Reprocessing/
35
Case Management
Case Management is the central hub where accounts flagged by rules are reviewed and
investigated by analysts. In Jube, cases are organized by workstreams, and each case
can have one of the following statuses:
• Refer to MLRO: Escalated to the Money Laundering Reporting Officer for further
review.
• No Further Action: No suspicious activity detected; case closed.
• Pending EDD Documentation: Awaiting Enhanced Due Diligence (EDD)
documentation.
• Pending CDD Documentation: Awaiting Customer Due Diligence (CDD)
documentation.
• SAR Sent by MLRO: A Suspicious Activity Report (SAR) has been filed by the
MLRO.
Case Audit
Jube provides robust Case Audit features to ensure transparency and compliance.
These features allow regulators to review the lifecycle of a case on demand. Key audit
functionalities include:
• Single Open Case per Account:
o Only one case can be open for an account at any given time.
o Once a case is closed, it can be reopened if necessary.
• Full Case Journal:
o Only one case can be open for an account at any given time.
o Once a case is closed, it can be reopened if necessary.
• Full Case Journal:
o A complete record of all open and previously closed cases is maintained.
• Action Tracking:
o Every action performed on a case—whether voluntary (e.g., adding notes)
or involuntary (e.g., reviewing a case)—is recorded in the audit trail.
• Analyst Notes:
o Analysts are required to add notes to explain the circumstances
surrounding case creation and their actions during the investigation.
Case Uploads
As part of the investigation process, Enhanced Due Diligence (EDD) documentation
may be required. Jube allows for the seamless upload and management of such
documents:
• Document Upload: EDD documentation can be uploaded directly to the case.
• Centralized Access: All relevant documents are stored in a specific location for
easy review.
36
Case Escalation
Cases may need to be escalated for further review by the MLRO or for the creation of
a Suspicious Activity Report (SAR). Escalation in Jube is straightforward:
• Change Workflow Status:
o Analysts can escalate a case by changing its workflow status to "Refer to
MLRO".
• MLRO Review:
o The MLRO can filter and view escalated cases for review.
• SAR Creation:
o SARs can be created by completing a case form within Jube.
o MLRO reports allow for the creation of template SARs, which can be
emailed directly to the relevant authorities.
Further Reading
• Case Management: https://jubehome.github.io/jube/Configuration/CaseManagement/
37
Summary
This document presented a framework for monitoring Anti‑Money Laundering (AML)
compliance using Jube, an open‑source software designed for fraud prevention and
transaction monitoring. The framework is based on regulatory guidance from the
Financial Action Task Force (FATF) and the Wolfsberg Principles, focusing on transaction
monitoring and risk‑based approaches to AML compliance. It integrates both the
high‑level AML operating model and the deeper quantitative methodology required for
rule justification, model calibration, and regulatory defensibility.
Risk Factors
• Country and Geographic Risk: High‑risk jurisdictions.
• Transaction Behavioural Risk: Unusual transaction patterns.
• Product Risk: Liquidity, cash‑like instruments, and anonymous products.
• Customer Risk: Low financial inclusion, person‑to‑person remittances, and
online impersonation risks.
Core Principles
• Know Your Customer (KYC): Central to AML compliance, involving due diligence
and ongoing monitoring.
• Risk‑Based Approach (RBA): Financial institutions assess risks and implement
proportionate controls.
• Customer Due Diligence (CDD): Five levels of diligence, from anonymous to
enhanced monitoring and suspicious activity reporting (SAR).
Automated Monitoring
• Jube supports real‑time and batch processing for transaction monitoring.
• Monitoring is implemented through anomaly detection and classification using
supervised and unsupervised machine‑learning techniques.
• Activation rules escalate suspicious cases for further investigation.
Data‑Driven Risk‑Based Approach
• Jube uses risk factors such as product characteristics, transaction behaviour,
and geographic spending patterns.
• Machine‑learning models (e.g., One‑Class SVM) identify anomalies and classify
suspicious activities.
• Risk factors are modelled using abstraction rules and integrated into activation
rules for case escalation.
Case Management
• Cases flagged by rules are reviewed by analysts, with statuses such as Refer to
MLRO, No Further Action, or SAR Sent.
38
• Robust audit trails ensure transparency, and EDD documentation can be
uploaded for further investigation.
• Escalation to the Money Laundering Reporting Officer (MLRO) and SAR creation
are streamlined.
MLRO Dashboards
• Provide real‑time insights into product behaviour, customer activity, and
territorial risks.
• Enable initiative‑taking risk management and adaptation to emerging threats.
Integration and Data Processing
• Jube integrates data from various sources (e.g., MasterCard/Visa authorizations,
financial transactions, and CDD events).
• IP address decoding provides geographic and contextual insights for risk
assessment.
• Data is processed serially, even in batch mode, to simulate real‑time monitoring.
Analytical Methodology and Minimum Dataset Requirements
• The methodology adopts a minimum‑dataset principle, centred on the
transaction journal, which provides the essential behavioural and financial
descriptors needed for defensible feature engineering, anomaly detection, and
threshold calibration.
• Additional artefacts (IP telemetry, device metadata, session attributes) enhance
context but are not prerequisites; their absence must not delay regulatory
compliance.
• The Analytical Methodology defines how features are engineered, how labels are
used when reliable, and how fallback modelling (probabilistic, unsupervised,
expert‑guided calibration) ensures continuous detection capability where labels
are incomplete or weak.
Performance Measurement and Validation
• A comprehensive KPI framework supports governance, including FPR, TPR,
Precision, Rule/Feature Coverage, Calibration, Operational Metrics, and
Continuous Improvement Metrics.
• Statistical techniques include exploratory data analysis, Bayesian modelling,
anomaly‑detection frameworks, threshold calibration via ROC/cost curves,
sensitivity analysis, and population‑drift monitoring.
• Validation encompasses feature‑level distributional analysis,
discriminatory‑power assessment, calibration checks, ranking stability, drift
testing, and back‑testing.
• Formal sign‑off checkpoints ensure all analytical artefacts are reviewed by Risk,
Compliance, Audit, and operations stakeholders, with versioned and
time‑stamped documentation retained for auditability.
39
Value Proposition
• Cost Reduction: Eliminates prohibitive costs of proprietary solutions.
• Vendor Lock‑In Eradication: Open‑source nature ensures flexibility.
• Improved Compliance: Advanced tooling enhances regulatory adherence.
Jube provides a powerful, flexible, and cost‑effective solution for AML transaction
monitoring. By combining real‑time capabilities with a rigorous quantitative annex—
covering data sufficiency, fallback methods, performance measurement, and
validation—the framework enables institutions to enhance compliance, reduce costs,
and adapt to evolving financial crime threats. The result is a fully integrated,
data‑driven, risk‑based methodology that is transparent, defensible, and aligned with
regulatory expectations.