2.1 Why Transaction Linking Is Hard

A retail bank processes tens of millions of transactions per day across payment rails (SWIFT, SEPA, FPS, ACH, card networks). Each transaction is recorded as an independent row. Detecting that a series of individually innocuous payments form a coordinated scheme requires reasoning across dimensions that SQL WHERE clauses and threshold rule-engines cannot capture:

2.2 Regulatory and Business Context

• FATF Recommendations / 6AMLD: Transaction monitoring must detect all three stages of money laundering like placement (introducing cash into the financial system), layering (concealing the trail through complex transactions), and integration (reintroducing laundered funds as legitimate). The UN estimates $800 billion–$2 trillion is laundered globally each year (2–5% of global GDP).
• PSD2 / Open Banking fraud controls: Real-time payment screening requires knowing whether an outbound payment resembles previously confirmed fraud cases.
• FinCEN / BSA (US), FCA / PSR (UK): SARs require documented evidence of suspicious transaction chains. Regulators expect behavioural analytics, not only threshold rules.
• GDPR data minimisation: Analytics must run on the existing transactional store, not a copy on a data lake , exactly the SQL DI architecture.

3.1 IBM AML Synthetic Transaction Dataset (Kaggle, 2023)

The most significant publicly available benchmark for bank transaction AML was published by IBM Research in 2023 alongside the paper “Realistic Synthetic Financial Transactions for Anti-Money Laundering Models” (Atasu et al., arXiv:2306.16424). It is available on Kaggle as “IBM Transactions for Anti-Money Laundering (AML)”.

This dataset is the direct analogue of the table that SQL DI would be trained on. Its column set maps almost perfectly to the SQL DI TXNDB.PAYMENT_TRANSACTION schema developed in this document, confirming the column selection is grounded in real research practice.

3.2 Elliptic Bitcoin Transaction Dataset (2019)

Published by Weber et al. (“Anti-Money Laundering in Bitcoin: Experimenting with Graph Convolutional Networks for Financial Forensics”, arXiv:1908.02591), this is the first large publicly labelled transaction graph dataset.

3.3 PaySim Mobile Money Simulation Dataset (Kaggle)

Simulated mobile money transactions modelled after real African mobile money network data, originally published by Lopez-Rojas et al. (2016). Available on Kaggle as “Synthetic Financial Datasets For Fraud Detection”.

3.4 Credit Card Fraud Detection Dataset (Kaggle / ULB)

Anonymised real European credit card transactions from 2013, by Leborgne and Gégout (Université Libre de Bruxelles). One of the most-used fraud detection benchmarks.

4.1 Conventional Techniques (Industry Baseline)

4.2 The SQL DI Advantage and Mapping to Industry Techniques

SQL-DI trains a database embedding on the full row semantics of the transaction table. The resulting vector space is conceptually equivalent to a Word2Vec / transaction2vec embedding, but trained on the complete multi-column relational row, not just transaction sequences, and executed entirely within Db2.

Key difference from GNNs: SQL DI does NOT model the transaction graph topology (edges, hops, connectivity). It models the row-level semantic similarity of individual transaction records. This means:

• SQL DI is stronger at finding transactions with similar attributes (same payment rail, similar amount band, same counterparty country) across the entire table but does not stick to individual values, you can achieve that with regular SQL.
• GNNs are stronger at detecting multi-hop structural patterns (A→B→C fund flows) in the transaction graph.
• The two approaches are complementary, not competing. SQL DI delivers the “semantic similarity layer”; IBM Financial Crimes Insight’s graph component (Db2 Graph) delivers the “network topology layer”. Together they cover both the attribute and the structural dimensions.

5.1 Core Table: TXNDB.PAYMENT_TRANSACTION

Inspired by the IBM AML synthetic dataset schema (Atasu et al., 2023), this table holds the canonical transaction fact row. Column types map directly to the features that research has identified as most discriminative for transaction linking.

Note: TXN_DESCRIPTION and REMITTANCE_INFO require SQL DI Pro with PyAIDB (APAR PH69885, SQL DI 1.1.4). In base SQL DI, exclude these columns. The structured columns alone provide strong semantic linking capability as validated on the IBM AML and Elliptic datasets but having additional data in unstructured columns strengthens the accuracy of the solution.

On AMOUNT_BAND: The IBM AML dataset uses raw decimal amounts. The ULB Credit Card dataset uses raw Amount. Research consistently shows that amount magnitude bands are more discriminative for linking than exact amounts, because launderers vary exact amounts while staying in the same magnitude range. Configure AMOUNT_BAND as categorical so each pre-bucketed band is a discrete semantic token with stable, threshold-aware boundaries.

See Appendix A. How AMOUNT_BAND and base10Cluster Work in SQL DI for a full technical explanation.

5.2 Enriched View for Transaction Linking

CREATE VIEW TXNDB.TXN_LINKING_VIEW AS
SELECT
    T.TRANSACTION_ID,
    T.ACCOUNT_ID,
    T.CUSTOMER_ID,
    T.TO_BANK,
    T.COUNTERPARTY_ACCOUNT,
    T.COUNTERPARTY_BANK_BIC,
    T.COUNTERPARTY_COUNTRY,
    T.PAYMENT_FORMAT,
    T.PAYMENT_METHOD,
    T.TRANSACTION_TYPE,
    -- Log-scale amount band (research-grounded: IBM AML, Elliptic)
    SMALLINT(CASE
        WHEN T.AMOUNT_LOCAL <= 0       THEN 1
        WHEN T.AMOUNT_LOCAL <= 10      THEN 2
        WHEN T.AMOUNT_LOCAL <= 50      THEN 3
        WHEN T.AMOUNT_LOCAL <= 100     THEN 4
        WHEN T.AMOUNT_LOCAL <= 250     THEN 5
        WHEN T.AMOUNT_LOCAL <= 500     THEN 6
        WHEN T.AMOUNT_LOCAL <= 1000    THEN 7
        WHEN T.AMOUNT_LOCAL <= 2500    THEN 8
        WHEN T.AMOUNT_LOCAL <= 5000    THEN 9
        WHEN T.AMOUNT_LOCAL <= 9500    THEN 10
        WHEN T.AMOUNT_LOCAL <= 10000   THEN 11   -- threshold band
        WHEN T.AMOUNT_LOCAL <= 25000   THEN 12
        WHEN T.AMOUNT_LOCAL <= 50000   THEN 13
        WHEN T.AMOUNT_LOCAL <= 100000  THEN 14
        ELSE 15
    END) AS AMOUNT_BAND,
    T.CURRENCY_PAID,
    T.CURRENCY_RECEIVED,
    T.IS_CROSS_CURRENCY,
    T.MERCHANT_CATEGORY_CODE,
    T.MERCHANT_COUNTRY,
    T.CHANNEL,
    HOUR(T.TRANSACTION_TIMESTAMP)        AS TXN_HOUR_BAND,
    DAYOFWEEK(T.TRANSACTION_TIMESTAMP)   AS TXN_DAY_OF_WEEK,
    T.IS_CROSS_BORDER,
    T.IS_HIGH_RISK_COUNTRY,
    T.IS_FIRST_TXN_TO_COUNTERPARTY,
    T.LAUNDERING_FLAG,
    T.TXN_DESCRIPTION,     -- Pro only
    T.REMITTANCE_INFO      -- Pro only
FROM TXNDB.PAYMENT_TRANSACTION T;

6.1 Enabling the AI Object (base SQL DI)

-- Register the AI object against the transaction view.
-- Column configuration specified during enablement via SQL DI Web UI, REST API, or CLI.

-- SQL DI data type assignment:
--   key:         TRANSACTION_ID
--   categorical: ACCOUNT_ID, CUSTOMER_ID, TO_BANK, COUNTERPARTY_ACCOUNT,
--                COUNTERPARTY_BANK_BIC, COUNTERPARTY_COUNTRY, PAYMENT_FORMAT,
--                PAYMENT_METHOD, TRANSACTION_TYPE, CURRENCY_PAID,
--                CURRENCY_RECEIVED, IS_CROSS_CURRENCY, MERCHANT_CATEGORY_CODE,
--                MERCHANT_COUNTRY, CHANNEL, IS_CROSS_BORDER,
--                IS_HIGH_RISK_COUNTRY, IS_FIRST_TXN_TO_COUNTERPARTY,
--                LAUNDERING_FLAG
--   categorical: (also) AMOUNT_BAND
--   numeric:     TXN_HOUR_BAND, TXN_DAY_OF_WEEK

6.2 Enabling Text Columns (SQL DI Pro, APAR PH69885)

After PH69885 PTF: TXN_DESCRIPTION and REMITTANCE_INFO use COLTYPE = 'text' Verify column configuration after enabling:

7.1 Pattern 1 — Find Transactions Matching a Confirmed Fraud Modus Operandi

Industry equivalent: Random Forest / XGBoost similarity scoring; nearest-neighbour search on transaction feature vectors.

Use case: A transaction is confirmed fraud (e.g., authorised push-payment scam or a labelled IBM AML laundering transaction). Find all other transactions with the same semantic profile, same payment format, amount band, counterparty country, and channel — without specifying a rule for each dimension.

-- Top 25 transactions most similar to confirmed fraud case TXN-20240315-00987654
SELECT
    AI_SIMILARITY(T.TRANSACTION_ID, 'TXN-20240315-00987654') AS SIMILARITY_SCORE,
    T.TRANSACTION_ID,
    T.ACCOUNT_ID,
    T.CUSTOMER_ID,
    T.COUNTERPARTY_ACCOUNT,
    T.COUNTERPARTY_COUNTRY,
    T.PAYMENT_FORMAT,
    T.AMOUNT_BAND,
    T.CHANNEL,
    T.LAUNDERING_FLAG
FROM TXNDB.TXN_LINKING_VIEW T
WHERE T.TRANSACTION_ID <> 'TXN-20240315-00987654'
ORDER BY SIMILARITY_SCORE DESC
FETCH FIRST 25 ROWS ONLY;

Score thresholds (calibrate per bank):

7.2 Pattern 2 — Structuring Detection via AI_COMMONALITY

Industry equivalent: Statistical centroid profiling; detection of transactions engineered to blend into the population (the key challenge of the IBM AML dataset’s fan-in and scatter-gather laundering patterns).

Use case: Structuring transactions are specifically designed to appear “average” — they cluster near the centroid of the legitimate transaction distribution. High AI_COMMONALITY scores combined with repetition per account expose this pattern.

-- High commonality = statistically typical transaction → structuring signal
-- Accounts with many high-typicality transactions are structuring candidates
SELECT
    AI_COMMONALITY(T.TRANSACTION_ID)  AS TYPICALITY_SCORE,
    T.ACCOUNT_ID,
    T.CUSTOMER_ID,
    T.AMOUNT_BAND,
    T.TXN_HOUR_BAND,
    T.COUNTERPARTY_COUNTRY,
    T.PAYMENT_FORMAT,
    T.IS_FIRST_TXN_TO_COUNTERPARTY,
    T.LAUNDERING_FLAG
FROM TXNDB.TXN_LINKING_VIEW T
WHERE T.LAUNDERING_FLAG = 'N'
  AND T.IS_HIGH_RISK_COUNTRY = 'N'
ORDER BY TYPICALITY_SCORE DESC
FETCH FIRST 100 ROWS ONLY;

Downstream aggregation: Group this result by ACCOUNT_ID and count rows with TYPICALITY_SCORE > 0.80. Accounts with > N such rows within a time window match the structuring typology from the IBM AML dataset’s scatter-gather and fan-in patterns.

7.3 Pattern 3 — Mule Network Detection via Semantic Cluster Membership

Industry equivalent: GCN / GraphSAGE node classification; community detection in the transaction graph; IBM Financial Crimes Insight graph analytics network score.

Use case: Given confirmed mule transactions (seed set), find all transactions across the portfolio that are semantically clustered with the mule profile. The multi-seed AI_SEMANTIC_CLUSTER approximates the neighbourhood aggregation step of a GCN without requiring a graph materialisation.

-- Semantic cluster membership against confirmed mule transaction seeds
-- Seeds represent the IBM AML "fan-out" or "gather-scatter" laundering patterns
SELECT
    AI_SEMANTIC_CLUSTER(
        T.TRANSACTION_ID
        USING MODEL COLUMN TRANSACTION_ID,
        'TXN-MULE-SEED-001' USING MODEL COLUMN TRANSACTION_ID,
        'TXN-MULE-SEED-002' USING MODEL COLUMN TRANSACTION_ID,
        'TXN-MULE-SEED-003' USING MODEL COLUMN TRANSACTION_ID
    ) AS MULE_CLUSTER_SCORE,
    T.TRANSACTION_ID,
    T.ACCOUNT_ID,
    T.CUSTOMER_ID,
    T.COUNTERPARTY_ACCOUNT,
    T.COUNTERPARTY_COUNTRY,
    T.PAYMENT_FORMAT,
    T.AMOUNT_BAND,
    T.LAUNDERING_FLAG
FROM TXNDB.TXN_LINKING_VIEW T
WHERE T.TRANSACTION_ID NOT IN (
          'TXN-MULE-SEED-001', 'TXN-MULE-SEED-002', 'TXN-MULE-SEED-003'
      )
ORDER BY MULE_CLUSTER_SCORE DESC
FETCH FIRST 50 ROWS ONLY;

Why multi-seed is better: AI_SEMANTIC_CLUSTER scores the candidate against the entire seed cluster simultaneously. This mirrors the GraphSAGE aggregation insight from the Elliptic dataset, where aggregating over multiple neighbourhood nodes was more robust than pairwise comparisons, especially under the partial-label conditions typical of real bank data.

7.4 Pattern 4 — Real-Time Anomaly Scoring via Dissimilarity

Industry equivalent: Isolation Forest / Autoencoder reconstruction error on individual transactions; validated on ULB Credit Card Fraud dataset.

Use case: For each new transaction, score it against the customer’s established behavioural norm. Transactions maximally dissimilar from the customer’s history are the highest-risk anomalies, account takeover, novel fraud typology, first use of a stolen card. This is the SQL DI equivalent of Isolation Forest’s anomaly score.

-- Top 10 most anomalous transactions for customer CUST-00123456
-- vs. their established transaction profile
SELECT
    AI_SIMILARITY(T.TRANSACTION_ID, 'TXN-PROFILE-CUST-00123456', 'DISSIMILARITY')
        AS ANOMALY_SCORE,
    T.TRANSACTION_ID,
    T.ACCOUNT_ID,
    T.COUNTERPARTY_ACCOUNT,
    T.COUNTERPARTY_COUNTRY,
    T.PAYMENT_FORMAT,
    T.AMOUNT_BAND,
    T.CHANNEL,
    T.TXN_HOUR_BAND,
    T.IS_FIRST_TXN_TO_COUNTERPARTY
FROM TXNDB.TXN_LINKING_VIEW T
WHERE T.CUSTOMER_ID = 'CUST-00123456'
ORDER BY ANOMALY_SCORE DESC
FETCH FIRST 10 ROWS ONLY;

Note on the profile reference: TXN-PROFILE-CUST-00123456 is the TRANSACTION_ID of a representative transaction from the customer’s history, or the most recent transaction used as a “current state” anchor. The 'DISSIMILARITY' argument inverts the cosine similarity, consult the Db2 13 SQL reference for the exact syntax at your SQL DI release level.

7.5 Pattern 5 — Cross-Account Relationship Verification via Analogy

Industry equivalent: Rule-based transfer-relationship verification; analogy reasoning over transaction pair relationships.

Use case: A known clean payment relationship exists: Customer A regularly sends funds to Customer B (confirmed personal relationship, verified KYC). Use AI_ANALOGY to test whether a similar-looking fund flow from Customer C to Customer D follows the same semantic relationship, or whether the analogy breaks down, signalling disguised layering.

-- Does TXN-NEW-001 (C outbound) relate to TXN-NEW-002 (D inbound) in the same
-- way that TXN-KNOWN-A (A outbound) relates to TXN-KNOWN-B (B inbound)?
SELECT
    AI_ANALOGY(
        'TXN-KNOWN-A' USING MODEL COLUMN TRANSACTION_ID,
        'TXN-KNOWN-B' USING MODEL COLUMN TRANSACTION_ID,
        'TXN-NEW-001'  USING MODEL COLUMN TRANSACTION_ID,
        'TXN-NEW-002'  USING MODEL COLUMN TRANSACTION_ID
    ) AS ANALOGY_SCORE
FROM SYSIBM.SYSDUMMY1;

• High score (→ 1.0): New pair mirrors the known clean relationship, proceed.
• Low score (→ 0.0): Relationship is semantically different despite surface similarity, flag for investigation. Effective at detecting IBM AML “U-shape” and “cycle” laundering typologies where amounts/rails mimic legitimate flows.

7.6 Pattern 6 — Multi-Hop Fund Flow Chain (Iterative Similarity Traversal)

Industry equivalent: GNN multi-hop propagation; IBM FCI graph analytics with configurable hop depth; Db2 Graph network score.

Use case: Trace a suspected layering chain hop by hop. Each hop uses the top-scoring transactions from the previous hop as seeds for the next. This is the SQL DI approximation of multi-hop graph traversal, applied iteratively at the application layer.

Hop 1 — Find transactions semantically similar to a confirmed fraud seed:

-- Hop 1: find transactions from accounts linked to the seed fraud transaction
WITH SEED AS (
    SELECT 'TXN-FRAUD-A001' AS SEED_TXN_ID
)
SELECT
    AI_SIMILARITY(T.TRANSACTION_ID, S.SEED_TXN_ID) AS HOP1_SCORE,
    T.TRANSACTION_ID,
    T.ACCOUNT_ID,
    T.COUNTERPARTY_ACCOUNT,
    T.COUNTERPARTY_COUNTRY,
    T.PAYMENT_FORMAT,
    T.AMOUNT_BAND,
    T.TRANSACTION_TYPE
FROM TXNDB.TXN_LINKING_VIEW T,
     SEED S
WHERE T.ACCOUNT_ID IN (
          SELECT COUNTERPARTY_ACCOUNT
          FROM TXNDB.PAYMENT_TRANSACTION
          WHERE TRANSACTION_ID = 'TXN-FRAUD-A001'
      )
  AND T.TRANSACTION_ID <> S.SEED_TXN_ID
ORDER BY HOP1_SCORE DESC
FETCH FIRST 20 ROWS ONLY;

The application substitutes the TRANSACTION_ID values from the top hop-1 results as seeds for hop 2, repeating until scores fall below a configurable threshold or a maximum hop count is reached. This replicates the IBM FCI graph analytics “expand on demand” traversal model documented in the Financial Crimes Insight platform.

14.1 IBM Documentation

• IBM SQL Data Insights Pro 1.1.0 — Documentation Home
• Running AI queries with SQL Data Insights — Db2 13 for z/OS
• Db2 built-in functions for SQL DI — Db2 13 for z/OS
• Db2 built-in functions for SQL DI Pro — SQL DI Pro 1.1.0
• IBM Financial Crimes Insight — Graph Analytics Overview
• IBM Financial Crimes Insight — Data Analytics Pipeline
• IBM — Transaction Monitoring (Think)
• IBM — AML Transaction Monitoring (Think)
• New-function APARs for Db2 13 in 2025

14.2 Research Papers and Datasets

• Atasu, K. et al. (2023). Realistic Synthetic Financial Transactions for Anti-Money Laundering Models. arXiv:2306.16424. IBM Research. → IBM AML dataset on Kaggle
• Weber, M. et al. (2019). Anti-Money Laundering in Bitcoin: Experimenting with Graph Convolutional Networks for Financial Forensics. arXiv:1908.02591. → Elliptic dataset
• Lopez-Rojas, E. A., Elmir, A., & Axelsson, S. (2016). PaySim: A financial mobile money simulator for fraud detection. EMSS 2016. → PaySim dataset on Kaggle
• Dal Pozzolo, A. et al. (2015). Calibrating Probability with Undersampling for Unbalanced Classification. IEEE SSCI. → ULB Credit Card Fraud dataset on Kaggle
• FATF (2012, updated 2023). The FATF Recommendations. Financial Action Task Force. → AML typology reference
• MarketsandMarkets (2023). Transaction Monitoring Market — Global Forecast to 2028. USD 6.8 billion projection.

15.1 Two strategies for representing transaction amounts

There are two distinct strategies for feeding transaction amounts into an SQL DI model, and they behave very differently.

SELECT
    COLUMN_NAME,
    CLUSTER_MIN,
    LABEL
FROM SYSAIDB.SYSAICOLUMNCENTERS
WHERE MODEL_ID = (
    SELECT MODEL_ID FROM SYSAIDB.SYSAIOBJECTS
    WHERE SCHEMA = 'TXNDB' AND NAME = 'TXN_LINKING_VIEW'
)
  AND COLUMN_NAME = 'AMOUNT_LOCAL'
ORDER BY CLUSTER_MIN ASC;

15.2 Why Strategy B is better for AML transaction linking

15.3 A subtlety: why not numeric on the pre-bucketed integer?

If AMOUNT_BAND (values 1–15) were configured as numeric, base10Cluster would still run, but on the integers 1–15. Because log₁₀(10) = 1.0 and log₁₀(15) = 1.18, the redistribution step would compress bands 10–15 into fewer clusters, blunting the threshold boundary that was deliberately designed into the view. Configuring as categorical bypasses base10Cluster entirely for this column, preserving every band as its own discrete token.

IBM’s documentation states: “Treat a column of numeric SQL data type as a SQL DI categorical type if the column contains 10 or fewer distinct values.” With 15 bands, the principle extends: any pre-bucketed integer column whose bands carry explicit semantic meaning should be treated as categorical, regardless of its SQL data type.