How transaction monitoring works

The Transaction Monitoring System (TMS) monitors deposits, withdrawals, transfers and related events to detect AML risks, financial fraud and operational anomalies in time. In iGaming, this is the core of money protection: at the entrance - data of payments and behavior, at the exit - ranked alerts, cases for investigations and regulatory reports.

1) Data streams: what exactly we collect

Payments and disbursements: 'authorized/captured/refunded/chargeback', amounts, currency, method, bank/PSP, fees.

Wallet: 'wallet. debit/credit ', balances, cancellations, idempotency (' txn _ id ',' Idempotency-Key ').

KYC/AML signals: age/address, liveness, sanctions/PEP, adverse media, SoF/SoW (in EDD).

Behavior: session frequency, "chase," betting speed, night activity.

Network and device: device fingerprint, IP/ASN, proxy/VPN, geo-drift.

Connections: general cards/wallets/devices, referral graphs.

Provider webhooks: signed by HMAC, with anti-replay ('timestamp', nonce).

💡 All events pass through the bus (Kafka/PubSub) and receive end-to-end keys: 'trace _ id', 'txn _ id', 'player _ ref'.

2) TMS architecture (layers)

1. Ingest and normalization: bringing PSP statuses to a common scheme, deduplication, validation of currencies/amounts.

2. Feature Store: online/offline features (velocity, geo-stability, chargeback history, graph connections).

3. Rules and models: deterministic thresholds + ML/anomalies + graph detectors.

4. Scoring and orchestration of decisions: single risk rate, action policy (skip/limit/hold/EDD/block).

5. Alerting and case management: queues, prioritization, checklists, SLA.

6. Reporting and audit: dashboards, STR/SAR, WORM archive, export to the regulator.

3) First level rules (fast detectors)

Velocity: N deposits/withdrawals in X minutes; surges of cancellations/refund.

Geo/method: map country and IP mismatch; rare PSPs/wallets.

Pass-through: large deposit → minimal activity → fast withdrawal.

Structuring: split amounts near KYC/AML threshold.

Behavioral triggers: multi-account by device/IP, night peaks.

Each rule has a window, threshold, severity and action (soft-limit, hold, manual review).

4) Second level models

Anomalies: Isolation Forest/autoencoder for "non-standard" transaction pattern.

Supervision: gradient boosting/logreg on marked history (chargeback/confirmed fraud).

Graph: link prediction/Node2Vec/GNN for syndicates, general requisites, "mules."

Cut-off calibration: TPR/FPR balance on business goals, stability on seasonality.

5) Scoring and decision making

We collect the aggregated risk rate (0-1 or Low/Med/High).

Politicians:

Low → skip/soft limits;
Med → step-up KYC/EDD, output delay;
High → hold/block and immediate investigation.
Signal combinations (high ML-rate + graph-flag) give priority in the queue.

6) Case management and investigations

Automatic context collection: payments, KYC, IP/ASN, graph links, chargeback history.

Checklists: what to ask the client (address/SoF), what to verify (koshelyok↔PSP) when to escalate.

Result: cleared/restrictions/EDD/STR/SAR; all actions are logged to the WORM archive.

SLA: reaction and closure time according to the severity of the case, alerts "when it burns."

7) STR/SAR and compliance

Case with signs of laundering/financing of terrorism → STR/SAR report is generated (facts, amounts, communication of participants, timeline).

Terms and format - by jurisdiction; tipping-off is prohibited.

Materials are stored in unchanging storage, access is strictly by role.

8) Security and privacy in TMS

Encryption: TLS 1. 2+/1. 3 "en route," AES-GCM "in storage," keys in KMS/HSM, rotations.

Aliasing: 'player _ ref' instead of PII; communication with PII - separately, with field encryption.

Access: RBAC/ABAC, JIT rights to sensitive cases, read/export audit.

Webhooks/external: HMAC signature, anti-replay, idempotent retrays.

9) Event schema (example 'payment. captured`)

json
{
"event_id": "evt_9ab…",  "occurred_at": "2025-10-17T10:15:22. 512Z",  "trace_id": "trc_41c…",  "txn_id": "txn_dep_784…",  "player_ref": "plr_0f2…",  "method": "card",  "amount": 150. 00,  "currency": "EUR",  "psp": "acq_X",  "geo": {"ip":"203. 0. 113. 5","country":"DE","asn":"AS12345"},  "device": {"fp":"dfp_a18…","platform":"ios"},  "risk": {"velocity_5m":3,"asn_reputation":"medium"},  "integrity": {"signature":"base64:…"}
}

Similar schemes are for'wallet. credit`, `payout. settled`, `kyc. verified`, `graph. linked`.

10) TMS Quality Metrics

Precision/Recall, TPR/FPR on alerts and cases.

Alert-to-Case Ratio and TTR/MTTR investigations.

SAR rate and cases confirmed by the regulator.

Chargeback/Fraud-loss% and ROI filters.

Customer friction: average time of withdrawal,% of "clean" customers who are checked.

Stability: latency scoring, timeouts, flow availability.

11) Tuning and drift control

Backtesting: rule/model runs on history, comparison with reference.

Champion/Challenger: parallel models in prod.

Data drift: PSI/KS tests, alerts when changing the mix of methods/geo.

Retraining: regular windows + manual marking of "gold" by the compliance team.

12) Operation: Observability and SLO

Dashboards: alerts/cases per hour, p95 scoring latency, timeout share, investigation queue, pass-through rate.

SLO: "scoring ≤150 ms p95," "TTR High-case ≤ 24 h," "erroneous budget" on FPR.

End-to-end tracing ('trace _ id') - fast drill-down from payout to root cause.

13) Typical errors

Bet only on rules or, conversely, only on ML. Need composition.

There is no idempotency of money. Webhook repeats → duplicate operations and false alerts.

Poor normalization of PSP statuses. "Gray" states break the fold.

Lack of graph analytics. Syndicates and "farms" remain invisible.

There is no feedback in the model. Mistakes do not turn into training - quality stagnates.

PII mixing in events. Violation of minimization and unnecessary risks of GDPR.

14) Implementation checklist (save)

Single event bus, PSP status normalization
Pass-through keys: 'trace _ id', 'txn _ id', 'player _ ref'
Feature Store (online/offline) and feature catalog
Composition: rules + anomalies + supervised + graph
Real-time scoring ≤150 ms + fallback solutions
Case Management - Queues, Checklists, SLAs, WORM Archive
STR/SAR process and report templates
Privacy/Encryption (TLS/KMS/HSM), RBAC/ABAC, JIT Access
Observability: dashboards, tracing, alerts
Backtesting, Champion/Challenger, drift monitoring
Auto- koshelyok↔PSP, discrepancy investigation
Documentation: policies, support playbooks, analyst training

15) Mini-FAQ

TMS = Antifraud? Overlapping, but goals are wider: AML/regulatory, STR/SAR, reporting.

Can FPR be lowered without losing TPR? Yes: graph signals and a cascade of rules + ML, plus fine calibration of thresholds.

Why is real-time important? Delays = "bad" conclusions and irretrievable losses.

Do you need external providers? Often yes (sanctions/PEP, KYC, behavioral reputation of ASN/devices).

How not to "strangle" honest players? Stepwise measures: soft limits → step-up KYC → hold only at high risk.

A working transaction monitoring system is an agreed pipeline: normalized events, uniform features, cascade of rules and models, graph analytics, fast scoring and investigation discipline. Such a TMS simultaneously reduces losses, fulfills the requirements of the regulator and keeps a good UX "clean" players.