Transaction Monitoring

Transaction monitoring works by looking not at a single transaction but at a subject's behaviour over time. Lunixi does this with five counting nodes, each answering one question:

Node	Question it answers
`velocity-check`	How many transactions / how much volume did this subject do in this window?
`event-count-check`	How many times did this event occur in this window?
`distinct-count-check`	How many distinct payees / senders / IPs / cards did we see?
`inter-arrival-check`	How much time passed between two consecutive transactions?
`history-aggregate-check`	What was the prior period's total or average, and how far does today deviate from it?

These nodes get their power from being combined. "Structuring" is not a single count: it is sub-threshold amounts + many transactions within a day + short gaps — all three together.

Ready-made rule templates

The fraud engine ships with 53 ready-made rule templates. These are not a marketing list but working rules mapped to regulatory text; you adapt the thresholds and publish them.

Template pack	Templates
TCMB 3.1.x	37
Account takeover (ATO)	5
Remittance	5
UK APP / PSR	6

JMLSG — money laundering typologies

Template	Pattern
`jmlsg_mt_structuring_daily_count`	Structuring — many sub-threshold transactions within a day
`jmlsg_mt_funnel_senders_daily`	Funnelling — many distinct senders paying into one account in a day
`jmlsg_mt_fanout_beneficiaries_daily`	Fan-out — payments to many distinct beneficiaries in a day (classic mule pattern)
`jmlsg_mt_inter_arrival`	Layering — incoming funds forwarded within minutes
`jmlsg_mt_cumulative_exposure_90d`	Cumulative exposure — 90-day total crossing a threshold

TCMB Risk Management Guide

Section	Coverage	Example templates
3.1.1	Customer and IP velocity checks	`tcmb_3_1_1_1_txn_out_daily`, `tcmb_3_1_1_2_distinct_payees_daily`, `tcmb_3_1_1_8b_ip_distinct_accounts_daily`, `tcmb_3_1_1_13_risky_country_ip`
3.1.2	Merchant risk indicators	`tcmb_3_1_2_1_own_turnover_4x`, `tcmb_3_1_2_4_night_ratio_monthly`, `tcmb_3_1_2_5_flat_ratio_monthly`, `tcmb_3_1_2_iban_change_3_in_90d`, `tcmb_3_1_2_domain_age_lt_90`
3.1.3	Bill payment and remittance	`tcmb_3_1_3_1a_bill_payment_customer_monthly`, `tcmb_3_1_3_6_remittance_inter_arrival`, `tcmb_3_1_3_9_related_party_self_funding`
3.1.4	Phone-based patterns	`tcmb_3_1_4_ghs_a_phone_txn_1h`, `tcmb_3_1_4_ghs_b_phone_multi_merchant_1h`

Each template carries its own reason-code prefix (JMLSG, TCMB), so a rule that fires can be traced from the response's reasonCodes straight back to the regulatory clause.

How the typologies are built

Structuring / smurfing

Splitting amounts to stay under a reporting threshold.

event-count-check   →  N+ transactions within a day
+ rule              →  each below the threshold
+ inter-arrival     →  short gaps between them
⇒ review

Funnelling

Many distinct senders converging on one account. distinct-count-check gives the sender count; history-aggregate-check measures how far that count deviates from the customer's own baseline.

Fan-out

One account paying out to many distinct beneficiaries — the classic mule-network pattern. See Mule Account Detection.

Layering

Incoming funds forwarded onward quickly. inter-arrival-check measures the gap between the credit and the debit; payment-lookup retrieves the prior transaction.

What we do not do

⚠️

There is no trained ML pattern model in the fraud engine, and no graph-database transaction-network analysis on the fraud side. Every typology above is built deterministically from counting nodes and rules.

Graph analysis exists on the sanctions side and does a different job: it computes indirect exposure over an identity/entity relationship graph. Call it from a flow with the sanction-indirect-exposure node. See Sanctions Screening.
Transaction-monitoring results do not come back as a separate transactionMonitoring object. They merge into the standard decision response: decision, score, reasonCodes, flowPath. Field contract: Decision API.

Flows and Resolution — the scope you publish these templates under
Mule Account Detection — fan-out and funnelling in depth
Decision API — the fields the counting nodes read

Mule Account Detection Case Management