Train a Classification Model on Linux
Train a model to identify transactions labeled as money laundering in IBM’s synthetic AML dataset. This example prepares account and transaction tables, connects them in a graph, trains a binary classifier, and saves the model for later predictions. It uses Kumo Engine’s local Python API on a Linux GPU machine.
Before You Begin
Complete Linux Machine Deployment Setup and activate the installed Python environment.
Keep KUMO_SCRATCH set to a writable directory on local NVMe SSD storage.
Allow space for the downloaded data, a prepared copy, graph indexes, training files, and saved model.
See GPU Sizing for compute guidance.
Download and extract the IBM Transactions for Anti Money Laundering dataset. Use these two files:
Review IBM’s data description and license to determine whether the dataset is suitable for your use.
The archive also contains LI-Medium_Patterns.txt, which describes the generated laundering attempts.
Use it as a reference only: its outcome annotations would reveal the answers if added as model features.
Point IBM_AML_SOURCE to the extracted files.
Choose new directories for the prepared tables and saved model, separate from the source files and scratch:
Run the Python blocks below in order in the same process. Configure scratch for that process before building the graph:
Prepare the Input Tables
Create an account key from the bank ID and account number so each transaction can connect to its sender and recipient.
The source files pad bank IDs differently, so normalize them before creating the keys.
The transaction file also has two columns named Account; read those columns by position to distinguish the two roles.
The following code writes accounts.csv and transactions.csv without changing the downloaded files.
It streams transactions and keeps account keys in memory to check duplicates and missing accounts.
Each transaction receives an ID based on its position in the source file.
The printed counts summarize the prepared data and any transaction endpoints missing from the account table. A missing endpoint has no account row to connect to; check the source files and key formatting if the count is unexpected. If preparation fails, correct the reported input problem and use a new prepared directory.
Build the Graph
Add the account table twice, as senders and recipients, to represent the two roles in a transaction.
Connect each transaction to those accounts and use its timestamp as the event time.
snapshot.id identifies the materialized graph used for training.
Kumo stores its graph indexes in the configured scratch directory.
Define the Classification Task
The predictive query asks whether each transaction’s IsLaundering value equals 1.
The comparison defines a binary classification target.
Kumo treats that target as the value to predict, rather than an input feature for the transaction being scored.
Use a chronological split with training, validation, and test ratios of 0.8, 0.1, and 0.1.
Validation and test examples follow the training period:
Preview ten generated rows without loading the full training table into memory:
ENTITY1 identifies the transaction, TIMESTAMP is its event time, and TARGET1 is the binary label.
For more on training populations and splits, see Predictive Queries.
Train and Save the Model
Start with one experiment and up to five epochs. Use area under the precision-recall curve (AUPRC) to select the model because laundering labels are rare. The plan also records AUROC, precision, and recall. See Training to adjust the training budget.
The following code saves the plan as model-plan.json and publishes the trained model under model/ in your output directory:
Review the Results
Use the validation metrics printed by the fit to adjust the training budget and prediction threshold. Reserve the test split for the final evaluation after choosing those settings. For this imbalanced task, use AUPRC, precision, and recall to assess how well the model finds positive examples; accuracy alone can hide missed laundering cases. Choose a prediction threshold based on the tradeoff between missed events and false alerts. The data is synthetic, so evaluate the model on representative data before using it for real transactions.
Keep the complete model/ directory on storage that survives the machine’s lifetime.
The published bundle can be loaded in a later Python process; detailed trial histories and explanation files remain in scratch.
Use Training Diagnostics to inspect and retain those files.
Next Steps
- Making Predictions: Score new transactions using the same account keys, table schema, and compatible graph relationships.
- Publish and Retrieve Models: Load the saved model in a new process and recreate its prediction context.
- Predict a Yes or No Outcome on Linux: Work through an example that applies probability thresholds and inspects saved predictions.