# 9. Typology Library Fifteen typologies for patterns that standard AML rule libraries cover: structuring, velocity, high value, dormant accounts, fan-out, fan-in, large single payments, smurfing, spikes against a customer’s own history, many devices, IP addresses, instruments, currencies and destination countries, and cross-border volume. Every rule here was built in Fyscal ARCX, tested with a dry run and submitted for Shadow activation, and each step shows the screen it was done on. Follow a rule step by step, then adjust its numbers to your own risk policy.
For
Administrators
In the menu
Fyscal ARCX → Transaction Monitoring → Variables and Typology
Reading time
About 2 h
::: checks - [Building blocks](#s-9-1): what the variable and typology forms can express, time windows, empty values, AND and OR, and how to read a dry run of 0 alerts. - [Rule index](#s-9-2): all fifteen rules compared on one page, with their dry-run results. - [Before you build](#s-9-3): the schedule, naming and activation rules that apply to every typology. - [Rule 1 · Structuring](#s-9-r1): several transactions just below an amount you review. - [Rule 2 · Velocity](#s-9-r2): an unusually high number of transactions in one day. - [Rule 3 · High value](#s-9-r3): a large total sent within 30 days. - [Rule 4 · Dormant account](#s-9-r4): no activity for 100 days, then a sudden payment. - [Rule 5 · Fan-out](#s-9-r5): one sender paying many different receivers. - [Rule 6 · Fan-in](#s-9-r6): many different senders paying one receiver. - [Rule 7 · Large single transaction](#s-9-r7): one very large payment in a day. - [Rule 8 · Smurfing](#s-9-r8): many very small payments in a day. - [Rule 9 · Spike against own history](#s-9-r9): a week’s total that is large against the customer’s 90 days. - [Rule 10 · Many devices](#s-9-r10): one sender using several devices. - [Rule 11 · Many IP addresses](#s-9-r11): one sender using many IP addresses. - [Rule 12 · Many instruments](#s-9-r12): one sender paying from many cards or accounts. - [Rule 13 · Many currencies](#s-9-r13): one sender using several currencies. - [Rule 14 · Many destination countries](#s-9-r14): payments to receivers in several countries. - [Rule 15 · Cross-border volume](#s-9-r15): a large total sent abroad within 30 days. - [Test a typology with Dry Run](#s-9-4): run a draft on past records, judge the result and tune it. - [Request Shadow activation](#s-9-5): submit a draft for approval in Shadow Mode. - [Tuning and false positives](#s-9-6): what to adjust in each rule and the ordinary activity that sets it off. - [Proposed typologies](#s-9-7): further rules built from the same parts, not yet tested. ::: ::: note About the examples The screenshots come from building these rules in Fyscal ARCX. There, each example is named with a **GUIDE EXAMPLE** (typology) or **guide\_example\_** (variable and schedule) prefix so it can be told apart from real rules. Each example name also carries the build number used on the test system (R01 to R06 and R09 to R17); the [Rule index](#s-9-2) maps them to the rule numbers here. In the text the names are shown without the prefix: use your own names. All amounts are in pesos (₱) and are starting values, not recommendations; set them from your own risk assessment. ::: ## Building blocks {#s-9-1} Every rule in this chapter is made from the same few parts. This table lists what the forms offer, as seen while building the rules. For a tour of each form, see [Build a typology from scratch](#s-8-11). | Part | Where | What you can set | | --- | --- | --- | | **Field** | Create Variables → Aggregation | One of the transaction fields, for example `amount`, `id`, `sender_entity_id`, `receiver_entity_id`, `sender_amount`, `receiver_amount`, `receiver_provider_country`. | | **Function** | Create Variables → Aggregation | Depends on the field. Numeric fields such as `amount` offer **Count**, **Count Distinct**, **Sum**, **Average**, **Minimum** and **Maximum**. Text and ID fields such as `id` or `receiver_entity_id` offer only **Count**, **Count Distinct**, **Minimum** and **Maximum**. | | **Group by** | Create Variables → Aggregation | The field the result is calculated per, usually `sender_entity_id` (per sender) or `receiver_entity_id` (per receiver). | | **Time Window** | Create Variables | A unit (**Hours**, **Days**, **Weeks**, **Months**, **Years**) and a range "Analyze Transaction from *X* to *Y* … ago". The range can end before now: **100 to 1 Days** covers the 100 days up to yesterday. | | **Filters** | Create Variables → Filters (optional) | Rows of *field · operator · value*, combined as "AND — all must match". Number fields: Equal, Not Equal, Greater Than, Greater Than Equal, Less Than, Less Than Equal, Between, Not Between, In, Not In. Text fields: Equal, Not Equal, In, Not In, Contains, Not Contains, Starts With, Ends With, Is Null, Is Not Null. **In** takes a list (type a value and press Enter for each). **Static** compares with a value you type; **Dynamic** compares with another field. | | **Condition** | Create Typology → Group | **WHEN** a variable, an operator, and a comparison with a **Static Value** or another **Variable**. When you compare with a variable, a **THAN MULTIPLIER** box lets you compare with a fraction or multiple of it (for example 0.9 for 90%). | | **Groups** | Create Typology | Rows in a group are combined with **Match** AND or OR; several groups are combined with **Combine groups with** AND or OR. | | **Typology type** | Create Typology | A category from the list, for example Structuring (TP100), Velocity (V-01), High Value (HV01), Cardinality (C-01), Large Transaction (LT-01), Anomaly (TP103). | | **Suppression Window** | Create Typology | A number and a unit (Hour, Day, Week, Month, Year). | ::: note The rules in this chapter set the **Suppression Window** to the same length as their variable window. ::: **Time windows** A variable's window is counted back from the trigger time T of each run. The first number is where the window starts and the second where it ends, both in days (or the chosen unit) before T. Diagram 9.1 places the three kinds of window used in this chapter on one line.
Diagram 9.1 — Variable windows counted back from the trigger time T (not to scale)
**7 to 0 Days ago** covers the last 7 days up to T. Most rules here use a window that ends at 0. **100 to 1 Days ago** ends one day before T, so it leaves out the most recent day. The form's timeline then reads **1 day ago**. On a typology page the variable card shows only the start (“in last 100 day”); check the end on **View Variable**. **1 to 0 Days ago** covers only the most recent day. Rule 4 pairs it with the 100-to-1 window: the two windows meet at “1 day ago” and do not overlap, so “no activity before, then a payment now” can be tested. **An empty value is not 0** When a customer has no transactions in a variable’s window, the variable has no value for that customer: it is empty, not 0. A comparison with a fixed number, such as **Equal** 0 or **Less Than Equal** 0, therefore does not match that customer. The operator list also offers **Is Null** and **Is Not Null**, but do not use them in a typology condition: the condition is not saved with the rule, and the rule runs without it. No message is shown, and the rule page then lists only the other conditions. When one variable is compared with another, an empty value counts as 0. [Rule 4](#s-9-r4) uses this to test for “no transactions”: it compares the amount sent in the last day with the earlier transaction count multiplied by 1,000,000,000,000. One earlier transaction makes that product far larger than any amount, so the condition fails. No earlier transaction makes it 0, so the condition passes.
Condition on a Count variableSender with 4 transactions in the windowSender with no transactions in the window
Value of the variable4Empty (no value)
Equal 0 matchesNoNoRule 4 first version: 0 alerts
Greater Than Equal 0 matchesYesNoTest with no matching transactions: 0 alerts
Is Null in a typology conditionNot savedNot savedRule 4 second version ran as “≥ ₱5,000” only
Last-day sum Greater Than Equal the count × 1,000,000,000,000 (Rule 4)NoYesRule 4: 279 alerts
**How AND and OR combine conditions** Inside a group, **Match** decides how the rows combine; the form and the rule page print the choice between the rows as **AND — all must match** or **OR — any one matches**. For two conditions A and B on the same sender:
Condition ACondition BMatch AND: alertMatch OR: alert
TrueTrueYesYes
TrueFalseNoYes
FalseTrueNoYes
FalseFalseNoNo
Groups combine the same way, following **Combine groups with**. The rule in [Typology detail](#s-8-3) (Figure 8.6) has **AND — all must match** inside each group and **OR — any one matches** between its three groups: it alerts when any one group is fully true. Every rule in this chapter uses a single group; Rules 4 and 9 have two conditions joined by AND. **Reading a dry run of 0 alerts** A dry run that creates 0 alerts can mean that the test period has no such pattern, or that the rule cannot read the data. A positive control tells them apart: lower the threshold for one run so that any matching record would alert, then restore it. The method is shown step by step in [Test a typology with Dry Run](#s-9-4).

0 alerts. With the threshold lowered for one run (for example Greater Than Equal 1), does the dry run create alerts?

Diagram 9.2 — Does a rule with 0 alerts work? The positive-control check
Nine of the fifteen rules in this chapter created 0 alerts at their real threshold, and every one of them created alerts in its positive control (see the [Rule index](#s-9-2)). A control only shows that the variable reads data: for Rule 13 it shows that `currency_code` is filled in, not that any sender uses several currencies. ## Rule index {#s-9-2} All fifteen rules at a glance. **Entity** is the field the variables are grouped by: `sender_entity_id` (per sender) for every rule except Rule 6, which uses `receiver_entity_id` (per receiver). **Dry run** gives the alerts created at the rule’s real threshold; where that was 0, **Control** gives the result with the threshold lowered for one run (see [Test a typology with Dry Run](#s-9-4)). ::: note Screenshot labels On the test system the rules were built under build numbers R01 to R17, and every screenshot carries that number in the example name. Rules 1 to 6 here are R01 to R06; Rules 7 to 15 are R09 to R17. R07 and R08 are not part of this chapter. The first column gives each rule’s build number. :::
Rule (screens)Red flagEntityVariable typeWindowThresholdDry runControlVerdict
1 · Structuring (R01)Several payments just under an amount you reviewSenderSTR_AGG_COUNT, two amount filters7 to 0 Days≥ 3 between ₱450,000 and ₱499,9990≥ 1: 4Works; pattern not in test data
2 · Velocity (R02)A burst of transactions in a daySenderSTR_AGG_COUNT1 to 0 Days≥ 100≥ 1: 764Works; pattern not in test data
3 · High value (R03)A large total sent in 30 daysSenderNUM_AGG_SUM30 to 0 Days≥ ₱5,000,0000≥ 1: 6,512Works; pattern not in test data
4 · Dormant account (R04)Activity after a long quiet periodSenderSTR_AGG_COUNT and NUM_AGG_SUM100 to 1 Days and 1 to 0 DaysSum ≥ ₱5,000 AND sum ≥ 1,000,000,000,000 × count279Not neededFires
5 · Fan-out (R05)One sender paying many receiversSenderSTR_AGG_COUNT_DISTINCT7 to 0 Days≥ 10 receivers240Not neededFires
6 · Fan-in (R06)Many senders paying one receiverReceiverSTR_AGG_COUNT_DISTINCT7 to 0 Days≥ 10 senders240Not neededFires
7 · Large single transaction (R09)One very large paymentSenderNUM_AGG_MAX1 to 0 Days≥ ₱1,000,0000≥ 1: 764Works; pattern not in test data
8 · Smurfing (R10)Many very small payments in a daySenderSTR_AGG_COUNT, amount filter1 to 0 Days≥ 20 under ₱1,0000≥ 1: 339Works; pattern not in test data
9 · Spike against own history (R11)A week that is large against the sender’s 90 daysSenderNUM_AGG_SUM (two variables)7 to 0 Days and 90 to 0 Days7-day ≥ ₱100,000 AND ≥ 0.5 × 90-day42Not neededFires
10 · Many devices (R12)One account used from many devicesSenderSTR_AGG_COUNT_DISTINCT7 to 0 Days≥ 3 devices0≥ 1: 4,043Works; pattern not in test data
11 · Many IP addresses (R13)One account used from many network locationsSenderSTR_AGG_COUNT_DISTINCT7 to 0 Days≥ 15 IP addresses120 (758 at ≥ 5)Not neededFires; threshold tuned
12 · Many instruments (R14)Payments funded from many cards or accountsSenderSTR_AGG_COUNT_DISTINCT7 to 0 Days≥ 5 instruments0≥ 1: 4,615Works; pattern not in test data
13 · Many currencies (R15)Switching between currenciesSenderSTR_AGG_COUNT_DISTINCT30 to 0 Days≥ 3 currencies0≥ 1: 6,512Works; the control only shows that currency_code is filled in
14 · Many destination countries (R16)Payments spread across countriesSenderSTR_AGG_COUNT_DISTINCT30 to 0 Days≥ 3 countries94Not neededFires
15 · Cross-border volume (R17)A large total sent abroadSenderNUM_AGG_SUM, Dynamic country filter30 to 0 Days≥ ₱1,000,0000≥ 1: 991Works; pattern not in test data
::: note About the test data Every dry run covered the same four one-day windows, 04 Oct 2026, 09:00 am to 08 Oct 2026, 09:00 am, and scanned 1,560 records. Only two of the four windows held records (1,140 and 420); the two newest windows scanned 0. A rule with a 7- or 30-day variable can still alert in a window that scanned 0 records, because its variable looks further back than the window (Rule 5 created 60 alerts in each window). The counts show that a rule works on this data; they are not the alert volume to expect on your own data. ::: The variables and conditions of each rule: | Rule | Variables | Condition | Type · suppression | | --- | --- | --- | --- | | [1 · Structuring](#s-9-r1) (R01) | `struct_count_7d`: Count of transactions, last 7 days, amount ≥ 450,000 and < 500,000 | ≥ 3 | Structuring (TP100) · 7 Day | | [2 · Velocity](#s-9-r2) (R02) | `txn_count_1d`: Count of transactions, last 1 day | ≥ 10 | Velocity (V-01) · 1 Day | | [3 · High value](#s-9-r3) (R03) | `sent_sum_30d`: Sum of amount, last 30 days | ≥ 5,000,000 | High Value (HV01) · 30 Day | | [4 · Dormant account](#s-9-r4) (R04) | `count_100d_to_1d`: Count, 100 to 1 days ago · `sent_sum_1d`: Sum of amount, last 1 day | second ≥ 5,000 AND second ≥ 1,000,000,000,000 × first | Anomaly (TP103) · 1 Day | | [5 · Fan-out](#s-9-r5) (R05) | `distinct_receivers_7d`: Count Distinct of receivers, last 7 days | ≥ 10 | Cardinality (C-01) · 7 Day | | [6 · Fan-in](#s-9-r6) (R06) | `distinct_senders_7d`: Count Distinct of senders per receiver, last 7 days | ≥ 10 | Cardinality (C-01) · 7 Day | | [7 · Large single transaction](#s-9-r7) (R09) | `max_amount_1d`: Maximum of amount, last 1 day | ≥ 1,000,000 | Large Transaction (LT-01) · 1 Day | | [8 · Smurfing](#s-9-r8) (R10) | `small_txn_count_1d`: Count of transactions, last 1 day, amount < 1,000 | ≥ 20 | Structuring (TP100) · 1 Day | | [9 · Spike against own history](#s-9-r9) (R11) | `sent_sum_7d_spike`: Sum, last 7 days · `sent_sum_90d`: Sum, last 90 days | 7-day ≥ 100,000 AND 7-day ≥ 90-day × 0.5 | Anomaly (TP103) · 7 Day | | [10 · Many devices](#s-9-r10) (R12) | `distinct_devices_7d`: Count Distinct of sender\_device\_id, last 7 days | ≥ 3 | Anomaly (TP103) · 7 Day | | [11 · Many IP addresses](#s-9-r11) (R13) | `distinct_ips_7d`: Count Distinct of sender\_ip, last 7 days | ≥ 15 | Anomaly (TP103) · 7 Day | | [12 · Many instruments](#s-9-r12) (R14) | `distinct_instruments_7d`: Count Distinct of sender\_instrument\_id, last 7 days | ≥ 5 | Cardinality (C-01) · 7 Day | | [13 · Many currencies](#s-9-r13) (R15) | `distinct_currencies_30d`: Count Distinct of currency\_code, last 30 days | ≥ 3 | Anomaly (TP103) · 30 Day | | [14 · Many destination countries](#s-9-r14) (R16) | `distinct_dest_countries_30d`: Count Distinct of receiver\_provider\_country, last 30 days | ≥ 3 | Anomaly (TP103) · 30 Day | | [15 · Cross-border volume](#s-9-r15) (R17) | `crossborder_sum_30d`: Sum of amount, last 30 days, receiver country ≠ sender country | ≥ 1,000,000 | High Value (HV01) · 30 Day | ## Before you build {#s-9-3} These points apply to every rule in this chapter. - **Create variables first.** A typology's conditions can only pick variables that already exist. - **Names.** Typology names can contain only letters, digits, spaces, hyphens, underscores and parentheses, so write amounts as "PHP 5000" rather than "₱5,000". A name must be 3 to 100 characters (see [Rule 9](#s-9-r9)). - **A schedule with a future start.** Save as Draft stays disabled until you choose a schedule whose start time is in the future. Rule 1 creates a daily schedule; the other rules reuse it. Its start was later moved from 01 Jan 2027 to 09 Oct 2026, 09:00 AM (Rule 1, step 31); screenshots taken before the change still show 01/01/2027. Choosing an existing schedule shows its fields in the form; those fields belong to that schedule, which other rules may also use. - **Saving.** After **Save as Draft**, wait a few seconds: the page becomes **Update Typology** and the rule is listed as **Draft**. - **Before it goes live.** Test each rule with **Dry Run** (see [Test a typology with Dry Run](#s-9-4)) and request activation, which goes through Maker Checker Approval (see [Request Shadow activation](#s-9-5)). ## Rule 1 · Structuring {#s-9-r1}

Red flagSeveral payments just under an amount you review

Logic
Counts the sender's transactions of ₱450,000 up to ₱499,999 in the last 7 days.
Window
7 to 0 Days
Threshold
≥ 3 between ₱450,000 and ₱499,999

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who makes three or more transactions within 7 days, each from ₱450,000 up to just under ₱500,000. Several payments that each stay just below an amount you want reviewed can be one larger sum split up to avoid that review, so the pattern is worth a look even when no single payment stands out. This is the most detailed of the rules: it shows every screen once, including the schedule that the other rules reuse. In the screenshots every example object carries the **GUIDE EXAMPLE** or `guide_example_` prefix; the text gives the names without it (see [Before you build](#s-9-3)). For a tour of each form, see [Build a typology from scratch](#s-8-11). | Item | Setting | | --- | --- | | Variable `struct_count_7d` | **Count** of `id` (the number of transactions), grouped by `sender_entity_id`, **Days** from 7 to 0, filters `amount` **Greater Than Equal** 450000 AND `amount` **Less Than** 500000 | | Typology type | Structuring (TP100) | | Suppression Window | 7 Day | | Condition | Group 1, Match AND: `struct_count_7d` **Greater Than Equal (>=)** Static Value 3 | | Schedule | New schedule `schedule_2027`: every 1 Day, no end time; created with the start 01 Jan 2027, 09:00 AM and later moved to 09 Oct 2026, 09:00 AM (step 31) | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Go to **Transaction Monitoring → Variables** and click **+ New**. In **Create Variables**, leave **Transaction** selected. In **Variable name** (1) type `struct_count_7d`. In **Description** (2) write what the number means, for example “Number of transactions per sender between PHP 450000 and 500000 in the last 7 days.” The name says what is counted and over which window, so it is easy to pick later in a condition. ::figure[Create Variables: Variable name and Description filled in]{src="typology-library/r01-var-name.png" id="fig-typology-library-r01-var-name"} ::: ::: step Choose the Field: id Open **Field**. The list has a **Search Fields** box and the 51 transaction fields. Choose `id`. Every transaction has one `id`, so counting `id` values counts transactions. ::figure[The Field list, before id is chosen]{src="typology-library/r01-var-field.png" id="fig-typology-library-r01-var-field"} ::: ::: step Choose the Function: Count Open **Function**. Because `id` is an ID field, the list offers only **Count**, **Count Distinct**, **Minimum** and **Maximum**; **Sum** and **Average** appear only for numeric fields such as `amount`. Choose **Count**: the rule needs the number of qualifying transactions. ::figure[Function for the id field: Count, Count Distinct, Minimum, Maximum]{src="typology-library/r01-var-function.png" id="fig-typology-library-r01-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`. The count is then calculated separately for each sender, which is what makes it a per-customer measure. ::figure[The Group by list]{src="typology-library/r01-var-groupby.png" id="fig-typology-library-r01-var-groupby"} ::: ::: step Set the time window: Days, 7 to 0 Scroll down. **Group by** now reads `sender_entity_id` (1). Under **Time Window**, click **Days** (2); the default is **Hours**. In **Analyze Transaction from** enter 7 and in **to** enter 0 (3). The line reads “from 7 to 0 Days ago”: the 7 days up to the trigger time, shown as “Triggered at T (00:00)”. ::figure[Group by set, and the time window set to 7 to 0 Days ago]{src="typology-library/r01-var-window.png" id="fig-typology-library-r01-var-window"} ::: ::: step Add filter 1: choose the amount field Under **Filters (1)** *(optional)*, open **Field** in the blank row and type `amount`. Four fields match: `amount`, `orig_currency_amount`, `receiver_amount` and `sender_amount`. Choose `amount`. The filters decide which transactions are counted; without them every transaction would count. ::figure[Filter row 1: the field search for amount]{src="typology-library/r01-var-filter-field.png" id="fig-typology-library-r01-var-filter-field"} ::: ::: step Filter 1: choose Greater Than Equal and type 450000 Open **Operator...**. For a number field the list is **Equal**, **Not Equal**, **Greater Than**, **Greater Than Equal**, **Less Than**, **Less Than Equal**, **Between**, **Not Between**, **In** and **Not In** (scroll for the last four). Choose **Greater Than Equal**, then type 450000 in **Enter value**. This sets the lower edge of the band: ₱450,000 itself is counted. ::figure[Filter operators for a number field]{src="typology-library/r01-var-filter-operator.png" id="fig-typology-library-r01-var-filter-operator"} ::: ::: step Why not Between Choosing **Between** (1) replaces the value box with **From** and **To** (2). The screen does not say whether Between includes its end values, so this rule uses two rows with explicit operators instead. Under every row is a **Static** / **Dynamic** toggle (3): **Static** compares with a value you type. ::figure[Between shows From and To boxes; the Static and Dynamic toggle]{src="typology-library/r01-var-filter-between.png" id="fig-typology-library-r01-var-filter-between"} ::: ::: step Add filter 2: amount Less Than 500000 With row 1 reading `amount` **Greater Than Equal** 450000 (1), click **Add Filter**. A second row appears, joined to the first by **AND — all must match** (2): a transaction is counted only if it passes both rows. Choose `amount`, open the operator list, type `Less Than` and choose **Less Than** (3). Type 500000. ₱500,000 itself is not counted, so the band is ₱450,000 up to, but not including, ₱500,000. ::figure[Filter row 2 added, joined by AND — all must match]{src="typology-library/r01-var-filter-row2.png" id="fig-typology-library-r01-var-filter-row2"} ::: ::: step Keep Static Clicking **Dynamic** (1) changes the value box to **Field...**, a list of other numeric fields to compare with: `mode_of_transaction`, `orig_currency_amount`, `receiver_amount` and `sender_amount` (2). This rule compares with fixed amounts, so switch the row back to **Static** and keep 500000. ::figure[Dynamic compares with another numeric field]{src="typology-library/r01-var-filter-dynamic.png" id="fig-typology-library-r01-var-filter-dynamic"} ::: ::: step Check the form and save Check the whole form: `id` / **Count** / `sender_entity_id` (1), **Days** 7 to 0 (2), and **Filters (2)** with both rows set to **Static** (3). Click **Save Variable** (4). ::figure[The completed variable form before saving]{src="typology-library/r01-var-filled.png" id="fig-typology-library-r01-var-filled"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, with its ID (VAR-08102026-000769 in the example) and the **Created** time. ::figure[The new variable at the top of the Variables list]{src="typology-library/r01-var-saved.png" id="fig-typology-library-r01-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** opens with the type tag **STR\_AGG\_COUNT** (1), the **CREATED** and **UPDATED** times and user (2), and **Edit**, **Delete** and **Duplicate** (3). The fields are read-only. ::figure[View Variable: type tag, created and updated, Edit, Delete and Duplicate]{src="typology-library/r01-var-view-top.png" id="fig-typology-library-r01-var-view-top"} ::: ::: step Check that both filters were saved Scroll down. **Filters (2)** (1) shows both rows joined by **AND — all must match**. **Update Variable** (2) is greyed out until you click **Edit**. Close the dialog with ×. ::figure[View Variable: both filters saved]{src="typology-library/r01-var-view-filters.png" id="fig-typology-library-r01-var-view-filters"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Name the rule and set the suppression window Go to **Transaction Monitoring → Typology** and click **+ New**. In **Typology Name** (1) type `R01 Structuring - 3 or more transactions between PHP 450000 and 500000 in 7 days`; names allow only letters, digits, spaces, hyphens, underscores and parentheses, so the amount is written as PHP. In **Suppression Window** type 7 (2), open the unit list (**Hour**, **Day**, **Week**, **Month**, **Year**) and choose **Day** (3). The example matches the 7-day variable window (see [Building blocks](#s-9-1)). ::figure[Typology Name, Suppression Window 7 and the unit list]{src="typology-library/r01-typ-name-suppression.png" id="fig-typology-library-r01-typ-name-suppression"} ::: ::: step Choose the typology type Open **Typology type** *(optional)* and type `Struct`. One type matches: **Structuring** TP100. Click it. Do not click **+ New**, which creates a new type. ::figure[Typology type search: Structuring TP100]{src="typology-library/r01-typ-type.png" id="fig-typology-library-r01-typ-type"} ::: ::: step Write the description and check the card In **Description** state the rule in words, for example “Flags a sender with 3 or more transactions of PHP 450000 to under 500000 in 7 days.” The card now shows the name (1), the chip **Structuring (TP100)** (2), **7 Day** (3) and the description (4). ::figure[The completed details card]{src="typology-library/r01-typ-details.png" id="fig-typology-library-r01-typ-details"} ::: ::: step Choose the variable in row 1 Below the card, leave **Combine groups with** and **Match** on **AND**. In **Group 1**, click **Select field** next to **WHEN**, type `struct` and click `struct_count_7d` under **VARIABLES**. ::figure[Row 1: the variable search]{src="typology-library/r01-typ-row1-field.png" id="fig-typology-library-r01-typ-row1-field"} ::: ::: step Choose the operator: Greater Than Equal Open **Select operator**. The list is **Equal**, **Not Equal**, **Greater Than**, **Greater Than Equal**, **Less Than**, **Less Than Equal**, then (scroll) **Between**, **Not Between**, **In**, **Not In**, **Is Null** and **Is Not Null**. Choose **Greater Than Equal**; the field shows **Greater Than Equal (>=)**. ::figure[Row 1: the operator list]{src="typology-library/r01-typ-row1-operator.png" id="fig-typology-library-r01-typ-row1-operator"} ::: ::: step Keep Static Value The compare-to list offers **Static Value** (selected) and **Variable**; **Ingested Data** is greyed out. Keep **Static Value**: the threshold is a fixed number. ::figure[Row 1: compare with Static Value]{src="typology-library/r01-typ-row1-compare.png" id="fig-typology-library-r01-typ-row1-compare"} ::: ::: step Enter 3 and go to the next step Type 3 in **Enter value**. Check the page: name (1), type (2), **7 Day** (3), description (4), **Match** AND (5) and the row `struct_count_7d` **Greater Than Equal (>=)** **Static Value** 3 (6). **Next Step** (7) is now available. Click it. ::figure[The completed Create Typology page]{src="typology-library/r01-typ-completed.png" id="fig-typology-library-r01-typ-completed"} ::: **Part C: Create the schedule and save** ::: step Read the Review & schedule rule page **Review & schedule rule** opens. **Select Schedule** (1) is empty. **Dry Run** (2) and **Save as Draft** (3) are greyed out. **Previous Step** (4) returns to the conditions. ::figure[Review & schedule rule before a schedule is chosen]{src="typology-library/r01-review.png" id="fig-typology-library-r01-review"} ::: ::: step Start a new schedule Open **Select Schedule**. The search finds only an older schedule from another walkthrough. This rule creates its own, so click **+ New**. A schedule can serve many rules, which is why the other rules reuse this one. ::figure[Select Schedule with + New]{src="typology-library/r01-schedule-new-button.png" id="fig-typology-library-r01-schedule-new-button"} ::: ::: step Read the empty schedule fields The card shows **Name** (1), **Execution Interval** (2) with a **Unit** list (3), **Start Time** (4), filled with the current date and time, and **End Time** *(optional)* (5). A **Save as Draft** button (6) appears inside the card, greyed out. ::figure[Empty fields for a new schedule]{src="typology-library/r01-schedule-new.png" id="fig-typology-library-r01-schedule-new"} ::: ::: step Name the schedule and set every 1 Day Type `schedule_2027` in **Name** and 1 in **Execution Interval** (1). Until you choose a unit, the message “Interval unit is mandatory” shows under the field. Open **Unit** and choose **Day** (2). The rule then runs once a day. ::figure[Execution Interval 1 and the Unit list]{src="typology-library/r01-schedule-unit.png" id="fig-typology-library-r01-schedule-unit"} ::: ::: step Open the start time picker Click **Start Time**. The calendar opens on the current month; dates before today are greyed out. Below it are **Time** and **Clear**. ::figure[The Start Time calendar]{src="typology-library/r01-schedule-picker.png" id="fig-typology-library-r01-schedule-picker"} ::: ::: step Set 01 Jan 2027, 09:00 AM Click the next-month arrow until January 2027, click 1 (2) and type 09:00 AM in **Time** (3). The field reads 01/01/2027 09:00 AM (1). The start time must be in the future for **Save as Draft** to become available (see [Before you build](#s-9-3)). ::figure[Start Time set to 01/01/2027 09:00 AM]{src="typology-library/r01-schedule-start.png" id="fig-typology-library-r01-schedule-start"} ::: ::: step Leave End Time blank and save the draft Leave **End Time** empty (1): “End date is optional — leave blank to run indefinitely.” Click **Save as Draft** in the card (2). ::figure[The completed schedule and Save as Draft]{src="typology-library/r01-schedule-filled.png" id="fig-typology-library-r01-schedule-filled"} ::: ::: step Check the saved draft Wait a few seconds: the title changes to **Update Typology** (1). **Select Schedule** shows `schedule_2027` (2) and the card reads “This rule will run every 1 day starting 01 Jan 2027, 09:00:00 am” (3). **Save as Draft** is replaced by **Update** (4); **Dry Run** (5) and **Activate** (6) are now available. To test and activate, see [Test a typology with Dry Run](#s-9-4) and [Request Shadow activation](#s-9-5). ::figure[After Save as Draft: the Update Typology page]{src="typology-library/r01-saved-draft.png" id="fig-typology-library-r01-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID, here TMR-08102026-001123 (1); the summary **EXECUTION PERIOD** 01 Jan 2027, 09:00:00 am → N/A, **INTERVAL** Every 1 day, **SUPPRESSION** 7Day and **TYPOLOGY** Structuring (2); the condition (3); and the variable card, **Str\_agg\_count**, **WINDOW** in last 7 day, **GROUP** `sender_entity_id` (4). ::figure[The saved Rule 1 as a Draft]{src="typology-library/r01-detail.png" id="fig-typology-library-r01-detail"} ::: ::: step Move the schedule’s start (later change) The example schedule was later moved to start on 09 Oct 2026, so the rules could be activated sooner. On any rule that uses it, open **Review & schedule rule**, click **Start Time**, pick the date and keep 09:00 AM: the field reads 10/09/2026 09:00 AM (1) and the card “This rule will run every 1 day starting 09 Oct 2026, 09:00:00 am” (2). Click **Update** (3) and confirm the dialog (see [Test a typology with Dry Run](#s-9-4), step 5). The change is on the shared schedule: Rule 1’s page showed the new start after a reload. ::figure[Start Time moved to 10/09/2026 09:00 AM; Update]{src="typology-library/r01-schedule-moved.png" id="fig-typology-library-r01-schedule-moved"} ::: **How it evaluates.** At each daily run the variable counts, for each sender, the transactions in the last 7 days whose amount is at least ₱450,000 and below ₱500,000. Sender A sent ₱480,000, ₱495,000 and ₱460,000 during those 7 days: the count is 3, 3 >= 3 is true, and the rule raises an alert. Sender B sent ₱480,000, ₱490,000 and ₱500,000: the ₱500,000 payment fails **Less Than** 500000, so the count is 2 and there is no alert. Sender C sent ₱300,000 four times: none is in the band, the count is 0, no alert. **Tuning.** The numbers you can change are: the band (the two filter values, 450000 and 500000), set from the amount you want reviewed; the count threshold (3) in the condition; the window (**Analyze Transaction from** 7); and the **Suppression Window** (7 Day). A wider band, a lower count or a longer window raises more alerts. The example sets the **Suppression Window** to the same length as the variable window (see [Building blocks](#s-9-1)). Run a **Dry Run** after each change to see the alert volume. **Dry-run result.** In testing, the rule created 0 alerts at 3 or more transactions: few transactions fall in the ₱450,000 to ₱499,999 band. With the threshold temporarily at 1 it created 4 alerts, so the variable and its two filters work. The full dry run, control and restore for this rule are shown in [Test a typology with Dry Run](#s-9-4). ## Rule 2 · Velocity {#s-9-r2}

Red flagA burst of transactions in a day

Logic
Counts the sender's transactions in the last day.
Window
1 to 0 Days
Threshold
≥ 10

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who makes 10 or more transactions in one day. A sudden burst of activity can mean an account is being used to move money quickly, so a count well above what your customers normally do is worth reviewing. The screens are the same as in [Rule 1](#s-9-r1); this section shows each step with this rule's values. | Item | Setting | | --- | --- | | Variable `txn_count_1d` | **Count** of `id` (the number of transactions), grouped by `sender_entity_id`, **Days** from 1 to 0, no filters | | Typology type | Velocity (V-01) | | Suppression Window | 1 Day | | Condition | Group 1, Match AND: `txn_count_1d` **Greater Than Equal (>=)** Static Value 10 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables**. Leave **Transaction** selected, type `txn_count_1d` in **Variable name** (1) and a description such as “Number of transactions per sender in the last 1 day.” (2). ::figure[Rule 2 variable: name and description]{src="typology-library/r02-var-name.png" id="fig-typology-library-r02-var-name"} ::: ::: step Choose the Field: id Open **Field**, type `id` in **Search Fields** and choose `id`, the first match. Counting `id` counts transactions. ::figure[Field search for id]{src="typology-library/r02-var-field.png" id="fig-typology-library-r02-var-field"} ::: ::: step Choose the Function: Count Open **Function** (**Count**, **Count Distinct**, **Minimum**, **Maximum**) and choose **Count**. ::figure[Function: Count]{src="typology-library/r02-var-function.png" id="fig-typology-library-r02-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` and choose `sender_entity_id`, so each sender gets their own count. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r02-var-groupby.png" id="fig-typology-library-r02-var-groupby"} ::: ::: step Set the time window: Days, 1 to 0 Click **Days** (1) and set **Analyze Transaction from** 1 **to** 0 (2): the last day up to the trigger time T. ::figure[Time window 1 to 0 Days ago]{src="typology-library/r02-var-window.png" id="fig-typology-library-r02-var-window"} ::: ::: step Leave the filter row empty and save Leave the blank row under **Filters (1)** (1) empty: every transaction counts. A blank row is dropped when you save. Click **Save Variable** (2). ::figure[Blank filter row and Save Variable]{src="typology-library/r02-var-filters-save.png" id="fig-typology-library-r02-var-filters-save"} ::: ::: step Find the variable in the list The new variable is the first row, here VAR-08102026-000770. ::figure[Rule 2 variable in the Variables list]{src="typology-library/r02-var-saved.png" id="fig-typology-library-r02-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows **STR\_AGG\_COUNT** (1), the created and updated details (2), the window 1 to 0 **Days ago** (3) and **Filters (0)** (4), confirming that the blank row was not saved. ::figure[View Variable for the Rule 2 variable]{src="typology-library/r02-var-view.png" id="fig-typology-library-r02-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Velocity Click **+ New** on **Typology**. Type the name `R02 Velocity - 10 or more transactions in 1 day` (1). Set **Suppression Window** to 1 and choose **Day** from the unit list (2), matching the 1-day window. Write a description (3). Open **Typology type** (4), type `Velo` and click **Velocity** V-01. ::figure[Rule 2 details and the Typology type search for Velocity]{src="typology-library/r02-typ-type.png" id="fig-typology-library-r02-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field**, type `txn` and click `txn_count_1d`. ::figure[Rule 2 row 1: variable search]{src="typology-library/r02-typ-row1-field.png" id="fig-typology-library-r02-typ-row1-field"} ::: ::: step Choose Greater Than Equal Open **Select operator** and choose **Greater Than Equal**. ::figure[Rule 2 row 1: operator list]{src="typology-library/r02-typ-row1-operator.png" id="fig-typology-library-r02-typ-row1-operator"} ::: ::: step Keep Static Value Keep **Static Value** in the compare-to list. ::figure[Rule 2 row 1: Static Value]{src="typology-library/r02-typ-row1-compare.png" id="fig-typology-library-r02-typ-row1-compare"} ::: ::: step Enter 10 and go to the next step Type 10 in **Enter value**. The page shows the name (1), **Velocity (V-01)** (2), **1 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 2 page]{src="typology-library/r02-typ-completed.png" id="fig-typology-library-r02-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the existing schedule On **Review & schedule rule**, open **Select Schedule**, type `schedule_2027` and click `schedule_2027` (SCH-08102026-000463), created in Rule 1. Do not click **+ New**. ::figure[Select Schedule: the schedule from Rule 1]{src="typology-library/r02-schedule-select.png" id="fig-typology-library-r02-schedule-select"} ::: ::: step Check the schedule and save the draft The schedule's fields fill in (2): 1 **Day**, start 01/01/2027 09:00 AM, no end time. They belong to the shared schedule, so leave them unchanged; editing them would affect every rule that uses it. The screenshots show the start in force when they were taken. Click **Save as Draft** (3). ::figure[The selected schedule and Save as Draft]{src="typology-library/r02-schedule-selected.png" id="fig-typology-library-r02-schedule-selected"} ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1), with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). ::figure[Rule 2 after Save as Draft]{src="typology-library/r02-saved-draft.png" id="fig-typology-library-r02-saved-draft"} ::: ::: step Check the rule page The rule page shows **Draft** TMR-08102026-001124 (1), **SUPPRESSION** 1Day and **TYPOLOGY** Velocity (2), the condition `txn_count_1d` **Greater Than Equal (>=)** 10 (3) and the variable card with **WINDOW** in last 1 day (4). ::figure[The saved Rule 2 as a Draft]{src="typology-library/r02-detail.png" id="fig-typology-library-r02-detail"} ::: **How it evaluates.** At each daily run the variable counts each sender's transactions in the last day, whatever their amount. Sender A made 12 transfers of about ₱1,000 each: 12 >= 10, so the rule raises an alert. Sender B made 9 transfers totalling ₱900,000: 9 is below 10, so there is no alert from this rule (Rule 3 looks at value instead). **Dry-run result.** In testing, the rule created 0 alerts at 10 or more transactions in a day. With the threshold temporarily at 1 it created 764 alerts (0 / 0 / 500 / 264 by window, newest first): the 1-day window only finds transactions in the days that contain records. The threshold was then restored to 10. ::figure[Rule 2 positive control (threshold temporarily >= 1): 764 alerts]{src="typology-library/r02-dryrun.png" id="fig-typology-library-r02-dryrun"} **Tuning.** You can change the count threshold (10), the window (**Analyze Transaction from** 1, or a different unit such as **Hours** for a shorter burst) and the **Suppression Window** (1 Day). To count only one kind of transaction, add a filter row to the variable, as in Rule 1. Set the threshold from what your customers normally do, and check the volume with a **Dry Run**. ## Rule 3 · High value {#s-9-r3}

Red flagA large total sent in 30 days

Logic
Adds up the amount the sender sent in the last 30 days.
Window
30 to 0 Days
Threshold
≥ ₱5,000,000

✓ Verified by positive control

**What it detects and why.** This rule flags a sender whose payments add up to ₱5,000,000 or more within 30 days. Looking at the 30-day total, rather than single payments, catches a large amount moved in several pieces as well as in one. The screens are the same as in [Rule 1](#s-9-r1). The difference is the variable: it sums `amount` instead of counting transactions. | Item | Setting | | --- | --- | | Variable `sent_sum_30d` | **Sum** of `amount`, grouped by `sender_entity_id`, **Days** from 30 to 0, no filters | | Typology type | High Value (HV01) | | Suppression Window | 30 Day | | Condition | Group 1, Match AND: `sent_sum_30d` **Greater Than Equal (>=)** Static Value 5000000 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables**. Type `sent_sum_30d` in **Variable name** (1) and a description such as “Total amount sent per sender in the last 30 days.” (2). ::figure[Rule 3 variable: name and description]{src="typology-library/r03-var-name.png" id="fig-typology-library-r03-var-name"} ::: ::: step Choose the Field: amount Open **Field** and choose `amount`, the transaction amount. ::figure[Field: amount]{src="typology-library/r03-var-field.png" id="fig-typology-library-r03-var-field"} ::: ::: step Choose the Function: Sum Open **Function**. Because `amount` is numeric, all six functions are offered: **Count**, **Count Distinct**, **Sum**, **Average**, **Minimum** and **Maximum**. Choose **Sum** to add the amounts together. ::figure[Function for amount: all six functions]{src="typology-library/r03-var-function.png" id="fig-typology-library-r03-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` and choose `sender_entity_id`, so each sender gets their own total. ::figure[Group by: sender\_entity\_id]{src="typology-library/r03-var-groupby.png" id="fig-typology-library-r03-var-groupby"} ::: ::: step Set the time window: Days, 30 to 0 Click **Days** (1) and set **Analyze Transaction from** 30 **to** 0 (2). ::figure[Time window 30 to 0 Days ago]{src="typology-library/r03-var-window.png" id="fig-typology-library-r03-var-window"} ::: ::: step Leave the filter row empty and save Leave the blank filter row (1) empty, so every payment counts towards the total, and click **Save Variable** (2). ::figure[Blank filter row and Save Variable]{src="typology-library/r03-var-filters-save.png" id="fig-typology-library-r03-var-filters-save"} ::: ::: step Find the variable in the list The new variable is the first row, here VAR-08102026-000771. ::figure[Rule 3 variable in the Variables list]{src="typology-library/r03-var-saved.png" id="fig-typology-library-r03-var-saved"} ::: ::: step Check the saved variable **View Variable** shows the type tag **NUM\_AGG\_SUM** (1), the created and updated details (2), 30 to 0 **Days ago** (3) and **Filters (0)** (4). ::figure[View Variable for the Rule 3 variable]{src="typology-library/r03-var-view.png" id="fig-typology-library-r03-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose High Value Click **+ New** on **Typology**. Type the name `R03 High value - PHP 5000000 or more sent in 30 days` (1), set **Suppression Window** 30 **Day** (2), matching the 30-day window, and write a description (3). Open **Typology type** (4) and type `High`: three types match, **High Value** HV01, **High Value Transfer** HV02 and **High Value** HV03. Click **High Value** HV01. ::figure[Rule 3 details and the Typology type search for High]{src="typology-library/r03-typ-type.png" id="fig-typology-library-r03-typ-type"} ::: ::: step Choose the variable in row 1 Click **Select field** and type `sent_sum`. The list can show similar variables from other rules; click `sent_sum_30d`. ::figure[Rule 3 row 1: choose sent\_sum\_30d]{src="typology-library/r03-typ-row1-field.png" id="fig-typology-library-r03-typ-row1-field"} ::: ::: step Choose Greater Than Equal Open **Select operator** and choose **Greater Than Equal**. ::figure[Rule 3 row 1: operator list]{src="typology-library/r03-typ-row1-operator.png" id="fig-typology-library-r03-typ-row1-operator"} ::: ::: step Keep Static Value Keep **Static Value**. ::figure[Rule 3 row 1: Static Value]{src="typology-library/r03-typ-row1-compare.png" id="fig-typology-library-r03-typ-row1-compare"} ::: ::: step Enter 5000000 and go to the next step Type 5000000 (no separators) in **Enter value**. Check the name (1), **High Value (HV01)** (2), **30 Day** (3), description (4), **Match** AND (5) and the row (6), then click **Next Step** (7). ::figure[The completed Rule 3 page]{src="typology-library/r03-typ-completed.png" id="fig-typology-library-r03-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the existing schedule Open **Select Schedule**, search for `schedule_2027` and click it. ::figure[Select Schedule: the schedule from Rule 1]{src="typology-library/r03-schedule-select.png" id="fig-typology-library-r03-schedule-select"} ::: ::: step Save the draft Leave the shared schedule's fields (2) unchanged and click **Save as Draft** (3). ::figure[The selected schedule and Save as Draft]{src="typology-library/r03-schedule-selected.png" id="fig-typology-library-r03-schedule-selected"} ::: ::: step Check the saved draft The page becomes **Update Typology** (1) with the run sentence (3), **Dry Run** (5) and **Activate** (6). ::figure[Rule 3 after Save as Draft]{src="typology-library/r03-saved-draft.png" id="fig-typology-library-r03-saved-draft"} ::: ::: step Check the rule page The rule page shows **Draft** TMR-08102026-001125 (1), **SUPPRESSION** 30Day and **TYPOLOGY** High Value (2), the condition with 5000000 (3) and the variable card, **Num\_agg\_sum**, in last 30 day (4). ::figure[The saved Rule 3 as a Draft]{src="typology-library/r03-detail.png" id="fig-typology-library-r03-detail"} ::: **How it evaluates.** At each daily run the variable adds up each sender's payments over the last 30 days. Sender A sent ₱2,000,000, ₱1,800,000 and ₱1,500,000: the total is ₱5,300,000, which is >= 5000000, so the rule raises an alert. Sender B sent one payment of ₱4,900,000: the total is below ₱5,000,000 and there is no alert. **Dry-run result.** In testing, no sender reached ₱5,000,000 in 30 days, so the rule created 0 alerts. With the threshold temporarily at 1 it created 6,512 alerts, then the threshold was restored. ::figure[Rule 3 positive control (threshold temporarily >= 1): 6,512 alerts]{src="typology-library/r03-dryrun.png" id="fig-typology-library-r03-dryrun"} **Tuning.** You can change the amount (5000000), the window (30 Days), and the **Suppression Window** (30 Day). Variant, not tested with Dry Run: for incoming value, build a second variable that sums `amount` grouped by `receiver_entity_id`. To total only one kind of transaction, add a filter row. Choose the amount from your own risk assessment and check the alert volume with a **Dry Run**. ## Rule 4 · Dormant account {#s-9-r4}

Red flagActivity after a long quiet period

Logic
Checks that the sender had no transactions from 100 to 1 days ago, then adds up what they sent in the last day.
Window
100 to 1 Days and 1 to 0 Days
Threshold
Sum ≥ ₱5,000 AND sum ≥ 1,000,000,000,000 × count

✓ Verified · 279 alerts

**What it detects and why.** This rule flags a sender who made no transactions from 100 days ago up to yesterday, and then sends ₱5,000 or more in the last day. An account that wakes up after a long quiet period and moves money straight away is a change in behaviour worth reviewing. It needs two variables, one for the quiet period and one for the new activity, and two conditions that must both be true. The screens are the same as in [Rule 1](#s-9-r1). | Item | Setting | | --- | --- | | Variable A `count_100d_to_1d` | **Count** of `id`, grouped by `sender_entity_id`, **Days** from 100 to 1: the transactions from 100 days ago up to 1 day ago, leaving out the last day | | Variable B `sent_sum_1d` | **Sum** of `amount`, grouped by `sender_entity_id`, **Days** from 1 to 0: the amount sent in the last day | | Typology type | Anomaly (TP103) | | Suppression Window | 1 Day | | Conditions | Group 1, Match AND: `sent_sum_1d` **Greater Than Equal (>=)** 5000 AND `sent_sum_1d` **Greater Than Equal (>=)** variable `count_100d_to_1d`, multiplier 1000000000000 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, start moved to 16 Oct 2026, 10:00 AM, no end time | **Part A: Create variable A, the quiet period** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name variable A Click **+ New** on **Variables**. Type `count_100d_to_1d` (1) and a description such as “Number of transactions per sender from 100 days ago up to 1 day ago (excludes the last day).” (2). ::figure[Variable A: name and description]{src="typology-library/r04-varA-name.png" id="fig-typology-library-r04-vara-name"} ::: ::: step Choose the Field: id Open **Field**, search `id` and choose `id`. ::figure[Variable A: Field id]{src="typology-library/r04-varA-field.png" id="fig-typology-library-r04-vara-field"} ::: ::: step Choose the Function: Count Choose **Count**: the rule needs to know whether there were any transactions at all. ::figure[Variable A: Function Count]{src="typology-library/r04-varA-function.png" id="fig-typology-library-r04-vara-function"} ::: ::: step Choose Group by: sender\_entity\_id Search `sender_entity` and choose `sender_entity_id`. ::figure[Variable A: Group by sender\_entity\_id]{src="typology-library/r04-varA-groupby.png" id="fig-typology-library-r04-vara-groupby"} ::: ::: step Set the window: Days, 100 to 1 Click **Days** (1), then enter 100 in **Analyze Transaction from** and 1 in **to** (2). The form accepts a window that ends before the trigger time, and the caption reads “1 day ago · Triggered at T (00:00)” (3). Ending at 1 leaves out the last day, so the payment that wakes the account up does not count against the quiet period. ::figure[Variable A: window 100 to 1 Days ago]{src="typology-library/r04-varA-window.png" id="fig-typology-library-r04-vara-window"} ::: ::: step Leave the filter row empty and save Leave the blank filter row (1) empty and click **Save Variable** (2). ::figure[Variable A: blank filter row and Save Variable]{src="typology-library/r04-varA-filters-save.png" id="fig-typology-library-r04-vara-filters-save"} ::: ::: step Find variable A in the list Variable A is the first row, here VAR-08102026-000772. ::figure[Variable A in the Variables list]{src="typology-library/r04-varA-saved.png" id="fig-typology-library-r04-vara-saved"} ::: ::: step Check variable A **View Variable** shows **STR\_AGG\_COUNT** (1), the created and updated details (2), 100 to 1 **Days ago** (3), **Filters (0)** (4) and the caption “1 day ago” (5): the end of the window was saved. ::figure[View Variable for variable A, window 100 to 1]{src="typology-library/r04-varA-view.png" id="fig-typology-library-r04-vara-view"} ::: **Part B: Create variable B, the new activity** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name variable B Click **+ New** again. Type `sent_sum_1d` (1) and a description such as “Total amount sent per sender in the last 1 day.” (2). ::figure[Variable B: name and description]{src="typology-library/r04-varB-name.png" id="fig-typology-library-r04-varb-name"} ::: ::: step Choose the Field: amount Open **Field** and choose `amount`. ::figure[Variable B: Field amount]{src="typology-library/r04-varB-field.png" id="fig-typology-library-r04-varb-field"} ::: ::: step Choose the Function: Sum Choose **Sum** from the six functions offered for a numeric field. ::figure[Variable B: Function Sum]{src="typology-library/r04-varB-function.png" id="fig-typology-library-r04-varb-function"} ::: ::: step Choose Group by: sender\_entity\_id Search `sender_entity` and choose `sender_entity_id`. Both variables must use the same Group by, so that the two conditions talk about the same sender. ::figure[Variable B: Group by sender\_entity\_id]{src="typology-library/r04-varB-groupby.png" id="fig-typology-library-r04-varb-groupby"} ::: ::: step Set the window: Days, 1 to 0 Click **Days** (1) and set 1 **to** 0 (2): the last day, the part that variable A leaves out. ::figure[Variable B: window 1 to 0 Days ago]{src="typology-library/r04-varB-window.png" id="fig-typology-library-r04-varb-window"} ::: ::: step Leave the filter row empty and save Leave the blank filter row (1) empty and click **Save Variable** (2). ::figure[Variable B: blank filter row and Save Variable]{src="typology-library/r04-varB-filters-save.png" id="fig-typology-library-r04-varb-filters-save"} ::: ::: step Find variable B in the list Variable B is the first row, here VAR-08102026-000773. ::figure[Variable B in the Variables list]{src="typology-library/r04-varB-saved.png" id="fig-typology-library-r04-varb-saved"} ::: ::: step Check variable B **View Variable** shows **NUM\_AGG\_SUM** (1), the created and updated details (2), 1 to 0 **Days ago** (3) and **Filters (0)** (4). ::figure[View Variable for variable B]{src="typology-library/r04-varB-view.png" id="fig-typology-library-r04-varb-view"} ::: **Part C: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Anomaly Click **+ New** on **Typology**. Type the name `R04 Dormant account - no activity for 100 days then PHP 5000 or more in 1 day` (1), set **Suppression Window** 1 **Day** (2), matching the 1-day activity window, and write a description (3). Open **Typology type** (4), type `Anomaly` and click **Anomaly** TP103. ::figure[Rule 4 details and the Typology type search for Anomaly]{src="typology-library/r04-typ-type.png" id="fig-typology-library-r04-typ-type"} ::: ::: step Row 1: variable B Greater Than Equal 5000 In **Group 1**, click **Select field** (1), type `sent_sum` in the search box (2) and click `sent_sum_1d` (3). Choose **Greater Than Equal**, keep **Static Value** and type 5000. ::figure[Row 1: Select field (1), the search sent\_sum (2) and the variable sent\_sum\_1d (3)]{src="typology-library/r04-typ-row1-field.png" id="fig-typology-library-r04-typ-row1-field"} ::: ::: note Why not Is Null A sender with no transactions from 100 days ago to 1 day ago has no value for variable A: it is empty, not 0, so **Equal** 0 never matches. **Is Null** is in the operator list, but it is not saved in a typology condition: an earlier version of this rule used it, and the saved rule contained only “`sent_sum_1d` ≥ 5000”. On the same days that version created 1,727 alerts, against 279 for the rule below. Row 2 tests “no transactions” in a way that is saved: it compares variable B with variable A, and an empty value counts as 0 in that comparison. ::: ::: step Row 2: compare variable B with a variable Row 1 (1) now reads `sent_sum_1d` **Greater Than Equal** 5000. Click **Add Condition**. In row 2 choose `sent_sum_1d` again and **Greater Than Equal** (2). Open the value type, which reads **Static Value** (3), and choose **Variable** (4). ::figure[Row 1 complete (1); row 2 field and operator (2); the value type list (3) with Variable (4)]{src="typology-library/r04-fix-operator.png" id="fig-typology-library-r04-fix-operator"} ::: ::: step Row 2: choose variable A and the multiplier Click **Select variable**, type `count_100d` and click `count_100d_to_1d`. A **THAN MULTIPLIER** box appears under it: type 1000000000000 (one trillion). Row 2 now asks whether the amount sent in the last day is at least variable A × 1,000,000,000,000. ::: ::: step Check both rows and go to the next step Row 1 (1) reads `sent_sum_1d` **Greater Than Equal** 5000. **AND — all must match** (2) joins it to row 2: `sent_sum_1d` **Greater Than Equal** (3), compared with the **Variable** `count_100d_to_1d` (4) and the multiplier 1000000000000 (5). Keep **Match** on AND: with OR, every sender of ₱5,000 would alert on row 1 alone. Click **Next Step** at the bottom right. ::figure[Rule 4 conditions: row 1 (1), AND (2), row 2 field and operator (3), variable A (4) and the multiplier (5)]{src="typology-library/r04-fix-is-null.png" id="fig-typology-library-r04-fix-is-null"} ::: **Part D: Choose the schedule and save** ::: step Select the existing schedule Open **Select Schedule**, search for `schedule_2027` and click it. ::figure[Select Schedule: the schedule from Rule 1]{src="typology-library/r04-schedule-select.png" id="fig-typology-library-r04-schedule-select"} ::: ::: step Check the start time and save the draft **Select Schedule** shows `schedule_2027` (1). The shared schedule's **Start Time** (2) must be in the future: if it is in the past, the form shows “Start time cannot be in the past” and **Save as Draft** stays greyed out. Pick a later date and time; here the start was moved to 16 Oct 2026, 10:00 AM. Two schedules with exactly the same interval and start cannot both exist: if another schedule already uses that start, the save does nothing, so choose a different time. Click **Save as Draft** (3). ::figure[The selected schedule (1), its start time (2) and Save as Draft (3)]{src="typology-library/r04-schedule-selected.png" id="fig-typology-library-r04-schedule-selected"} ::: ::: note A typology name must be unique. If another rule already has the name, **Save as Draft** does nothing and no message appears. The rebuilt example was saved with “(v2)” at the end of its name because the earlier version keeps the original one. ::: ::: step Check the saved draft The page becomes **Update Typology** (1), with the run sentence “This rule will run every 1 day starting 16 Oct 2026, 10:00:00 am” (2), **Dry Run** (3) and **Activate** (4). ::figure[Rule 4 after Save as Draft: Update Typology (1), the run sentence (2), Dry Run (3) and Activate (4)]{src="typology-library/r04-saved-draft.png" id="fig-typology-library-r04-saved-draft"} ::: ::: step Check the saved conditions on the rule page Open the rule from **Transaction Monitoring → Typology**: **Draft**, TMR-15102026-001217 (1). **Group 1** shows both saved conditions: row 1 (2), `sent_sum_1d` **Greater Than Equal (>=)** 5000, and row 2 (3), `sent_sum_1d` **Greater Than Equal (>=)** `count_100d_to_1d` (multiplied by 1000000000000). Under **VARIABLES 2** (4) both variables are listed. Always check this page after saving: a condition that was not saved does not appear here. ::figure[Rule 4 rule page: the draft ID (1), the two saved conditions (2) and (3), and the two variables (4)]{src="typology-library/r04-detail-vars.png" id="fig-typology-library-r04-detail-vars"} ::: ::: note The variable card on the rule page summarises variable A's window as “in last 100 day” and does not show that the window ends 1 day ago. The saved setting is 100 to 1 Days ago, as **View Variable** shows in step 8. Check the window on **View Variable**, not on the card. ::: **How it evaluates.** At each daily run both variables are calculated for each sender, and both conditions must be true. Sender A last transacted 120 days ago and sent ₱20,000 in the last day: variable A (100 to 1 days ago) is empty and counts as 0 in row 2, so ₱20,000 >= 5000 and ₱20,000 >= 0 × 1,000,000,000,000 are both true: the rule raises an alert. Sender B also sent ₱20,000 in the last day but made one ₱500 payment 40 days ago: variable A is 1, and ₱20,000 is far below 1 × 1,000,000,000,000, so row 2 is false and there is no alert. Sender C was quiet for 100 days and sent ₱3,000 in the last day: row 1 is false, no alert. Because variable A stops 1 day ago, sender A's ₱20,000 payment does not count in variable A. **Dry-run result.** In testing the rule created 279 alerts: 0 / 50 / 126 / 103 by window, newest first (1 to 4). On the same four days, the earlier version, saved without its “no transactions” condition, created 1,727: row 2 removes the senders who had transactions in the previous 100 days. ::figure[Rule 4 dry run: 279 alerts (1), and the windows with 50 (2), 126 (3) and 103 (4) alerts]{src="typology-library/r04-dryrun.png" id="fig-typology-library-r04-dryrun"} **Tuning.** You can change the length of the quiet period (100 in variable A, keeping the end at 1 so it never overlaps variable B's window), the amount that counts as reactivation (5000), the activity window (variable B's 1 to 0, with variable A's end value moved to match) and the **Suppression Window** (1 Day). Keep the multiplier at 1000000000000: it only has to be larger than any amount a sender could send in a day. A shorter quiet period or a lower amount raises more alerts. Confirm the result with a **Dry Run**. ## Rule 5 · Fan-out {#s-9-r5}

Red flagOne sender paying many receivers

Logic
Counts the different receivers the sender paid in the last 7 days.
Window
7 to 0 Days
Threshold
≥ 10 receivers

✓ Verified · 240 alerts

**What it detects and why.** One sender pays 10 or more different receivers within 7 days, for example ₱3,000 to each of twelve new accounts. Spreading funds across many receivers is a common way to move money onward quickly or to hide who finally receives it. | Item | Setting | | --- | --- | | Variable `distinct_receivers_7d` | The number of different receivers (**Count Distinct** of `receiver_entity_id`) each sender paid in the last 7 days (**Group by** `sender_entity_id`, from 7 to 0 Days ago). No filters. | | Typology type | Cardinality (C-01) | | Suppression Window | 7 Day | | Condition | `distinct_receivers_7d` **Greater Than Equal (>=)** 10 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | ::: note The screenshots show the example objects with a *GUIDE EXAMPLE* / `guide_example_` prefix so they are easy to find on the test system. The text gives the values without the prefix. Use your own names. For a full description of each screen, see [Build a typology from scratch](#s-8-11). ::: ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open Create Variables and name the variable Go to **Transaction Monitoring → Variables** and click **+ New** (the empty form is shown in [Part 2 of the walkthrough](#s-8-13)). Leave **Transaction** selected (1): the variable is calculated from transactions. In **Variable name** (2) type `distinct_receivers_7d`. In **Description** (3) type a note such as “Number of distinct receivers per sender in the last 7 days.” The description appears on the variable card of every typology that uses the variable. ::figure[Transaction selected, Variable name distinct\_receivers\_7d and Description filled in]{src="typology-library/r05-01-var-name.png" id="fig-typology-library-r05-01-var-name"} ::: ::: step Choose the Field Open **Field** and type `receiver_entity` in **Search Fields**. Choose `receiver_entity_id`. This is the value the variable counts: the ID of the customer who received each transaction. ::figure[The Field list searched for receiver\_entity: choose receiver\_entity\_id]{src="typology-library/r05-02-var-field.png" id="fig-typology-library-r05-02-var-field"} ::: ::: step Choose the Function Open **Function**. For `receiver_entity_id` the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum** only (text and ID fields have no **Sum** or **Average**). Choose **Count Distinct**. **Count Distinct** counts each receiver once, so ten payments to the same receiver count as 1. **Count** would count transactions instead. ::figure[The Function list for receiver\_entity\_id: choose Count Distinct]{src="typology-library/r05-03-var-function.png" id="fig-typology-library-r05-03-var-function"} ::: ::: step Choose Group by Open **Group by** and type `sender_entity` in the search box. Choose `sender_entity_id`. The count is calculated separately for each sender, so the rule can flag the sender who fans out. ::figure[Group by searched for sender\_entity: choose sender\_entity\_id]{src="typology-library/r05-04-var-groupby.png" id="fig-typology-library-r05-04-var-groupby"} ::: ::: step Set the time window and check the form Scroll down to **Time Window**. Click **Days** (1); the default is **Hours**. In **Analyze Transaction from** enter **7** and in **to** enter **0** (2). The line reads “from 7 to 0 Days ago”: the last 7 days up to the trigger time T. Leave the blank filter row under **Filters (1)** (3) empty, so every transaction counts; a blank row is not saved. Click **Save Variable** (4). ::figure[Time Window Days, from 7 to 0 Days ago, the blank filter row and Save Variable]{src="typology-library/r05-05-var-window.png" id="fig-typology-library-r05-05-var-window"} ::: ::: step Find the saved variable The dialog closes. The new variable is the first row of the **Variables** list, with its Variable ID (VAR-08102026-000774 in the example) and its created time. ::figure[The new variable distinct\_receivers\_7d at the top of the Variables list]{src="typology-library/r05-06-var-saved.png" id="fig-typology-library-r05-06-var-saved"} ::: ::: step Check the View Variable page Click the row to open **View Variable**. Check the type tag (1), **STR\_AGG\_COUNT\_DISTINCT**; the **CREATED** and **UPDATED** lines (2), with the date and time and the user who saved it; **Field**, **Function** and **Group by** (3): `receiver_entity_id`, **Count Distinct**, `sender_entity_id`; the window (4), 7 to 0 **Days** ago; and the filters heading (5). Close the dialog with ×. ::figure[View Variable for distinct\_receivers\_7d: type STR\_AGG\_COUNT\_DISTINCT, receiver\_entity\_id / Count Distinct / sender\_entity\_id]{src="typology-library/r05-07-var-view.png" id="fig-typology-library-r05-07-var-view"} ::: ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Open Create Typology, name the rule and choose the type Go to **Transaction Monitoring → Typology** and click **+ New**. In **Typology Name** (1) type **R05 Fan-out - one sender to 10 or more receivers in 7 days** (letters, digits, spaces, hyphens, underscores and parentheses only). In **Suppression Window** (2) type **7** and choose **Day**. Type the description in **Description** (3). Open **Typology type**, type `Cardin` in **Search typology type** and click **Cardinality** (C-01). ::figure[Name, Suppression Window 7 Day and description entered; Typology type searched for Cardin]{src="typology-library/r05-08-typ-name-type.png" id="fig-typology-library-r05-08-typ-name-type"} ::: ::: step Check the details card The type shows as a chip, **Cardinality (C-01)**, with × to remove it. **Typology type** is a multi-select: after you pick a type the list stays open, hides the type you chose and shows “No typologies found” for the same search. Click anywhere outside the list to close it. A suitable description is “Flags a sender who pays 10 or more distinct receivers in 7 days.” ::figure[The Cardinality (C-01) chip in Typology type]{src="typology-library/r05-09-typ-details.png" id="fig-typology-library-r05-09-typ-details"} ::: ::: step Choose the variable in row 1 Below the card, **Combine groups with** is **AND** and Group 1 has **Match** **AND**; one condition needs no change. In Group 1 click **Select field** next to **WHEN**, type part of the name, for example `distinct`, and click `distinct_receivers_7d`. ::figure[The Select field list searched by name: both distinct-count variables]{src="typology-library/r05-10-typ-row1-field.png" id="fig-typology-library-r05-10-typ-row1-field"} ::: ::: step Choose the operator Open **Select operator** and choose **Greater Than Equal**. The row shows it as “Greater Than Equal (>...”. **Greater Than Equal** includes the threshold itself in the alert. The full operator list is in [Part 4 of the walkthrough](#s-8-15). ::figure[The operator list: choose Greater Than Equal]{src="typology-library/r05-11-typ-row1-operator.png" id="fig-typology-library-r05-11-typ-row1-operator"} ::: ::: step Keep Static Value and enter the threshold Open the compare-to list: **Static Value**, **Variable**, and **Ingested Data** greyed out. Keep **Static Value**, because the threshold is a fixed number, and type **10** in **Enter value**. A sender with 10 or more different receivers in the window meets the condition. ::figure[The compare-to list: Static Value, Variable, Ingested Data greyed out]{src="typology-library/r05-12-typ-row1-compare.png" id="fig-typology-library-r05-12-typ-row1-compare"} ::: ::: step Check the whole form and click Next Step The first page is complete: name (1), type chip (2), **Suppression Window** (3), description (4) and the condition (5). **Next Step** (6) is now available. Click it. ::figure[Create Typology complete: distinct\_receivers\_7d Greater Than Equal 10; Next Step available]{src="typology-library/r05-13-typ-complete.png" id="fig-typology-library-r05-13-typ-complete"} ::: ::: step Select the shared schedule **Review & schedule rule** opens. Open **Select Schedule**, type the schedule name in **Search Schedule** and click the schedule created in Rule 1 (`schedule_2027`, SCH-08102026-000463 in the example). One schedule can drive many rules, so every example rule reuses it. ::figure[Select Schedule searched: the shared schedule and its SCH- ID]{src="typology-library/r05-14-schedule-search.png" id="fig-typology-library-r05-14-schedule-search"} ::: ::: step Check the schedule and save the draft The schedule shows in **Select Schedule** (1). Its fields (2) are filled from the schedule: **Execution Interval** 1 **Day**, **Start Time** 01/01/2027 09:00 AM (the start at the time of the screenshot), no **End Time**. Leave them unchanged: they belong to the shared schedule. Click **Save as Draft** (3). ::figure[The shared schedule selected; Save as Draft available]{src="typology-library/r05-15-schedule-selected.png" id="fig-typology-library-r05-15-schedule-selected"} ::: ::: step Read the result Wait a few seconds: the page title changes to **Update Typology** (1) and the card shows “This rule will run every 1 day starting 01 Jan 2027, 09:00:00 am” (2). **Save as Draft** is replaced by **Update** (3); **Dry Run** (4) and **Activate** (5) are now available. The rule is a Draft and does not run until it is activated; to test it, see [Test a typology with Dry Run](#s-9-4). ::figure[After Save as Draft: Update Typology, the run summary, Update, Dry Run and Activate]{src="typology-library/r05-16-draft-saved.png" id="fig-typology-library-r05-16-draft-saved"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. The page shows the **Draft** chip and rule ID (1), TMR-08102026-001127, created 08 Oct 2026, 11:50:20 am. The summary strip (2) reads **EXECUTION PERIOD** 01 Jan 2027, 09:00:00 am → N/A, **INTERVAL** Every 1 day, **COMPLEXITY** Advanced, **SUPPRESSION** 7Day and **TYPOLOGY** Cardinality. Group 1 (3) shows `distinct_receivers_7d` **Greater Than Equal (>=)** 10. **VARIABLES** (4) shows the variable card: Str\_agg\_count\_distinct, **WINDOW** in last 7 day, **GROUP** `sender_entity_id`. ::figure[The draft rule page: TMR-08102026-001127, Draft]{src="typology-library/r05-17-typology-detail.png" id="fig-typology-library-r05-17-typology-detail"} ::: **How it evaluates.** At each run the variable counts, for each sender, the different receivers paid in the last 7 days. Example: in the 7 days before a run: | Sender | Payments in the window | distinct\_receivers\_7d | Result | | --- | --- | --- | --- | | A | 12 payments of ₱3,000, each to a different receiver | 12 | 12 >= 10: alert | | B | 25 payments totalling ₱75,000, all to the same 4 receivers | 4 | 4 >= 10 is false: no alert | | C | 10 payments to 10 different receivers | 10 | 10 >= 10: alert (the threshold is included) | Amounts play no part in this rule: sender B moves more money than A but pays only 4 receivers. **Dry-run result.** In testing, the rule created 240 alerts at its real threshold, 60 in each of the four windows. ::figure[Rule 5 dry run at >= 10: 240 alerts]{src="typology-library/r05-dryrun.png" id="fig-typology-library-r05-dryrun"} **Tuning.** Choose the threshold (10) to suit how many receivers your customers normally pay: a remittance business that pays many beneficiaries may need a higher number, and a retail book a lower one. Choose the window (7 Days in the variable) and keep **Suppression Window** the same length or longer, as in the example. To ignore very small payments, add a filter to the variable, for example `amount` **Greater Than Equal** a value you choose; filters are shown in [Rule 8](#s-9-r8). ## Rule 6 · Fan-in {#s-9-r6}

Red flagMany senders paying one receiver

Logic
Counts the different senders that paid the receiver in the last 7 days.
Window
7 to 0 Days
Threshold
≥ 10 senders

✓ Verified · 240 alerts

**What it detects and why.** One receiver is paid by 10 or more different senders within 7 days, for example ₱2,000 from each of fifteen unrelated people. Collecting funds from many sources into one account is typical of money-mule and pooling accounts. | Item | Setting | | --- | --- | | Variable `distinct_senders_7d` | The number of different senders (**Count Distinct** of `sender_entity_id`) that paid each receiver in the last 7 days (**Group by** `receiver_entity_id`, from 7 to 0 Days ago). No filters. | | Typology type | Cardinality (C-01) | | Suppression Window | 7 Day | | Condition | `distinct_senders_7d` **Greater Than Equal (>=)** 10 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | This rule is the mirror of [Rule 5](#s-9-r5): the counted field and the **Group by** field swap places. For a full description of each screen, see [Build a typology from scratch](#s-8-11). ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open Create Variables and name the variable Go to **Transaction Monitoring → Variables** and click **+ New** (the empty form is shown in [Part 2 of the walkthrough](#s-8-13)). Leave **Transaction** selected (1): the variable is calculated from transactions. In **Variable name** (2) type `distinct_senders_7d`. In **Description** (3) type a note such as “Number of distinct senders per receiver in the last 7 days.” The description appears on the variable card of every typology that uses the variable. ::figure[Transaction selected, Variable name distinct\_senders\_7d and Description filled in]{src="typology-library/r06-01-var-name.png" id="fig-typology-library-r06-01-var-name"} ::: ::: step Choose the Field Open **Field** and type `sender_entity` in **Search Fields**. Choose `sender_entity_id`. This is the value the variable counts: the ID of the customer who sent each transaction. ::figure[The Field list searched for sender\_entity: choose sender\_entity\_id]{src="typology-library/r06-02-var-field.png" id="fig-typology-library-r06-02-var-field"} ::: ::: step Choose the Function Open **Function**. For `sender_entity_id` the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum** only. Choose **Count Distinct**. Each sender is counted once, however many times they paid the receiver. ::figure[The Function list for sender\_entity\_id: choose Count Distinct]{src="typology-library/r06-03-var-function.png" id="fig-typology-library-r06-03-var-function"} ::: ::: step Choose Group by Open **Group by** and type `receiver_entity` in the search box. Choose `receiver_entity_id`. The count is calculated separately for each receiver, so the rule flags the receiving customer. ::figure[Group by searched for receiver\_entity: choose receiver\_entity\_id]{src="typology-library/r06-04-var-groupby.png" id="fig-typology-library-r06-04-var-groupby"} ::: ::: step Set the time window and check the form Scroll down to **Time Window**. Click **Days** (1); the default is **Hours**. In **Analyze Transaction from** enter **7** and in **to** enter **0** (2). The line reads “from 7 to 0 Days ago”: the last 7 days up to the trigger time T. Leave the blank filter row under **Filters (1)** (3) empty, so every transaction counts; a blank row is not saved. Click **Save Variable** (4). ::figure[Time Window Days, from 7 to 0 Days ago, the blank filter row and Save Variable]{src="typology-library/r06-05-var-window.png" id="fig-typology-library-r06-05-var-window"} ::: ::: step Find the saved variable The dialog closes. The new variable is the first row of the **Variables** list, with its Variable ID (VAR-08102026-000775 in the example) and its created time. ::figure[The new variable distinct\_senders\_7d at the top of the Variables list]{src="typology-library/r06-06-var-saved.png" id="fig-typology-library-r06-06-var-saved"} ::: ::: step Check the View Variable page Click the row to open **View Variable**. Check the type tag (1), **STR\_AGG\_COUNT\_DISTINCT**; the **CREATED** and **UPDATED** lines (2), with the date and time and the user who saved it; **Field**, **Function** and **Group by** (3): `sender_entity_id`, **Count Distinct**, `receiver_entity_id`; the window (4), 7 to 0 **Days** ago; and the filters heading (5). Close the dialog with ×. ::figure[View Variable for distinct\_senders\_7d: type STR\_AGG\_COUNT\_DISTINCT, sender\_entity\_id / Count Distinct / receiver\_entity\_id]{src="typology-library/r06-07-var-view.png" id="fig-typology-library-r06-07-var-view"} ::: ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Open Create Typology, name the rule and choose the type Go to **Transaction Monitoring → Typology** and click **+ New**. In **Typology Name** (1) type **R06 Fan-in - 10 or more senders to one receiver in 7 days** (letters, digits, spaces, hyphens, underscores and parentheses only). In **Suppression Window** (2) type **7** and choose **Day**. Type the description in **Description** (3). Open **Typology type**, type `Cardin` in **Search typology type** and click **Cardinality** (C-01). ::figure[Name, Suppression Window 7 Day and description entered; Typology type searched for Cardin]{src="typology-library/r06-08-typ-name-type.png" id="fig-typology-library-r06-08-typ-name-type"} ::: ::: step Check the details card The type shows as a chip, **Cardinality (C-01)**, with × to remove it. **Typology type** is a multi-select: after you pick a type the list stays open, hides the type you chose and shows “No typologies found” for the same search. Click anywhere outside the list to close it. A suitable description is “Flags a receiver paid by 10 or more distinct senders in 7 days.” ::figure[The Cardinality (C-01) chip in Typology type]{src="typology-library/r06-09-typ-details.png" id="fig-typology-library-r06-09-typ-details"} ::: ::: step Choose the variable in row 1 Below the card, **Combine groups with** is **AND** and Group 1 has **Match** **AND**; one condition needs no change. In Group 1 click **Select field** next to **WHEN**, type part of the name, for example `distinct`, and click `distinct_senders_7d`. ::figure[The Select field list searched by name: both distinct-count variables]{src="typology-library/r06-10-typ-row1-field.png" id="fig-typology-library-r06-10-typ-row1-field"} ::: ::: step Choose the operator Open **Select operator** and choose **Greater Than Equal**. The row shows it as “Greater Than Equal (>...”. **Greater Than Equal** includes the threshold itself in the alert. The full operator list is in [Part 4 of the walkthrough](#s-8-15). ::figure[The operator list: choose Greater Than Equal]{src="typology-library/r06-11-typ-row1-operator.png" id="fig-typology-library-r06-11-typ-row1-operator"} ::: ::: step Keep Static Value and enter the threshold Open the compare-to list: **Static Value**, **Variable**, and **Ingested Data** greyed out. Keep **Static Value**, because the threshold is a fixed number, and type **10** in **Enter value**. A receiver paid by 10 or more different senders in the window meets the condition. ::figure[The compare-to list: Static Value, Variable, Ingested Data greyed out]{src="typology-library/r06-12-typ-row1-compare.png" id="fig-typology-library-r06-12-typ-row1-compare"} ::: ::: step Check the whole form and click Next Step The first page is complete: name (1), type chip (2), **Suppression Window** (3), description (4) and the condition (5). **Next Step** (6) is now available. Click it. ::figure[Create Typology complete: distinct\_senders\_7d Greater Than Equal 10; Next Step available]{src="typology-library/r06-13-typ-complete.png" id="fig-typology-library-r06-13-typ-complete"} ::: ::: step Select the shared schedule **Review & schedule rule** opens. Open **Select Schedule**, type the schedule name in **Search Schedule** and click the schedule created in Rule 1 (`schedule_2027`, SCH-08102026-000463 in the example). One schedule can drive many rules, so every example rule reuses it. ::figure[Select Schedule searched: the shared schedule and its SCH- ID]{src="typology-library/r06-14-schedule-search.png" id="fig-typology-library-r06-14-schedule-search"} ::: ::: step Check the schedule and save the draft The schedule shows in **Select Schedule** (1). Its fields (2) are filled from the schedule: **Execution Interval** 1 **Day**, **Start Time** 01/01/2027 09:00 AM (the start at the time of the screenshot), no **End Time**. Leave them unchanged: they belong to the shared schedule. Click **Save as Draft** (3). ::figure[The shared schedule selected; Save as Draft available]{src="typology-library/r06-15-schedule-selected.png" id="fig-typology-library-r06-15-schedule-selected"} ::: ::: step Read the result Wait a few seconds: the page title changes to **Update Typology** (1) and the card shows “This rule will run every 1 day starting 01 Jan 2027, 09:00:00 am” (2). **Save as Draft** is replaced by **Update** (3); **Dry Run** (4) and **Activate** (5) are now available. The rule is a Draft and does not run until it is activated; to test it, see [Test a typology with Dry Run](#s-9-4). ::figure[After Save as Draft: Update Typology, the run summary, Update, Dry Run and Activate]{src="typology-library/r06-16-draft-saved.png" id="fig-typology-library-r06-16-draft-saved"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. The page shows the **Draft** chip and rule ID (1), TMR-08102026-001128, created 08 Oct 2026, 11:51:57 am. The summary strip (2) reads **EXECUTION PERIOD** 01 Jan 2027, 09:00:00 am → N/A, **INTERVAL** Every 1 day, **COMPLEXITY** Advanced, **SUPPRESSION** 7Day and **TYPOLOGY** Cardinality. Group 1 (3) shows `distinct_senders_7d` **Greater Than Equal (>=)** 10. **VARIABLES** (4) shows Str\_agg\_count\_distinct, **WINDOW** in last 7 day, **GROUP** `receiver_entity_id`. ::figure[The draft rule page: TMR-08102026-001128, Draft]{src="typology-library/r06-17-typology-detail.png" id="fig-typology-library-r06-17-typology-detail"} ::: **How it evaluates.** At each run the variable counts, for each receiver, the different senders that paid it in the last 7 days. | Receiver | Payments in the window | distinct\_senders\_7d | Result | | --- | --- | --- | --- | | D | 15 payments of about ₱2,000, from 15 different senders | 15 | 15 >= 10: alert | | E | A salary of ₱40,000 from one employer and 6 transfers from 3 relatives | 4 | 4 >= 10 is false: no alert | **Dry-run result.** In testing, the rule created 240 alerts at its real threshold, 60 in each of the four windows. ::figure[Rule 6 dry run at >= 10: 240 alerts]{src="typology-library/r06-dryrun.png" id="fig-typology-library-r06-dryrun"} **Tuning.** Choose the threshold (10) from how many senders your receiving customers normally have; merchants, collection accounts and charities receive from many payers, so you may exclude them with a filter or use a higher number. Choose the window length and keep the suppression window at least as long. To count only payments above a size you choose, add an `amount` filter to the variable. ## Rule 7 · Large single transaction {#s-9-r7}

Red flagOne very large payment

Logic
Takes the sender's largest single amount in the last day.
Window
1 to 0 Days
Threshold
≥ ₱1,000,000

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who makes one transaction of ₱1,000,000 or more within a day. One very large payment is reviewed on its own, whatever else the customer does, which is why the variable takes the largest amount rather than the total (Rule 3 looks at totals). | Item | Setting | | --- | --- | | Variable `max_amount_1d` | **Maximum** of `amount`, grouped by `sender_entity_id`, **Days** from 1 to 0, no filters | | Typology type | Large Transaction (LT-01) | | Suppression Window | 1 Day | | Condition | Group 1, Match AND: `max_amount_1d` **Greater Than Equal (>=)** Static Value 1000000 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `max_amount_1d` in **Variable name** (1) and a description such as “Largest single transaction amount per sender in the last 1 day.” (2). ::figure[Rule 7 variable: name and description]{src="typology-library/r09-var-name.png" id="fig-typology-library-r09-var-name"} ::: ::: step Choose the Field: amount Open **Field**, type `amount` and choose `amount`, the first of four matches. ::figure[Field search for amount]{src="typology-library/r09-var-field.png" id="fig-typology-library-r09-var-field"} ::: ::: step Choose the Function: Maximum Open **Function**. For a numeric field the list offers **Count**, **Count Distinct**, **Sum**, **Average**, **Minimum** and **Maximum**. Choose **Maximum**: the variable keeps the largest single amount, not the total. ::figure[Function: Maximum]{src="typology-library/r09-var-function.png" id="fig-typology-library-r09-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the largest amount is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r09-var-groupby.png" id="fig-typology-library-r09-var-groupby"} ::: ::: step Set the time window: Days, 1 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 1 in **Analyze Transaction from** and 0 in **to** (2): the 1 day up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Time window 1 to 0 Days ago, blank filter row and Save Variable]{src="typology-library/r09-var-window.png" id="fig-typology-library-r09-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000796. ::figure[Rule 7 variable in the Variables list]{src="typology-library/r09-var-saved.png" id="fig-typology-library-r09-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **NUM\_AGG\_MAX** (1), the **CREATED** and **UPDATED** times and user (2), `amount` / **Maximum** / `sender_entity_id` (3), 1 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for max\_amount\_1d]{src="typology-library/r09-var-view.png" id="fig-typology-library-r09-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Large Transaction Click **+ New** on **Typology**. Type the name `R09 Large single transaction - PHP 1000000 or more in one transaction in 1 day` (1). Set **Suppression Window** to 1 and choose **Day** (2): the window is one day. Write a description (3). Open **Typology type** (4), type `Large` and click **Large Transaction LT-01**. ::figure[Rule 7 details and the Typology type search]{src="typology-library/r09-typ-type.png" id="fig-typology-library-r09-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `max_amount_1d`. ::figure[Rule 7 row 1: variable search]{src="typology-library/r09-typ-row1-field.png" id="fig-typology-library-r09-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 7 row 1: operator list]{src="typology-library/r09-typ-row1-operator.png" id="fig-typology-library-r09-typ-row1-operator"} ::: ::: step Enter 1000000 and go to the next step Type 1000000 in **Enter value**. Check the name (1), the type chip **Large Transaction (LT-01)** (2), **1 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 7 page]{src="typology-library/r09-typ-completed.png" id="fig-typology-library-r09-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule** (1), search for `schedule_2027` and click it. Its fields fill in (2); leave them unchanged, because they belong to the shared schedule. The screenshot was taken before the start was moved to 09 Oct 2026, so it shows 01/01/2027. Click **Save as Draft** (3). ::figure[The shared schedule selected; Save as Draft]{src="typology-library/r09-schedule-selected.png" id="fig-typology-library-r09-schedule-selected"} ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 7 after Save as Draft]{src="typology-library/r09-saved-draft.png" id="fig-typology-library-r09-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID TMR-08102026-001131, created 08 Oct 2026, 05:15:18 pm (1); the summary with **INTERVAL** Every 1 day, **SUPPRESSION** 1Day and **TYPOLOGY** Large Transaction (2); the condition, with the operator shown as **Greater Than Equal (>=)** (3); and the variable card `max_amount_1d`, Num\_agg\_max, **WINDOW** in last 1 day, **GROUP** `sender_entity_id` (4). ::figure[The saved Rule 7 as a Draft, TMR-08102026-001131]{src="typology-library/r09-detail.png" id="fig-typology-library-r09-detail"} ::: **How it evaluates.** At each daily run the variable takes, for each sender, the largest single amount in the last day. Sender A sent ₱1,200,000 once and ₱5,000 twice: the maximum is ₱1,200,000, so the rule alerts. Sender B sent ₱600,000 twice (₱1,200,000 in total): the maximum is ₱600,000, so there is no alert from this rule. **Dry-run result.** In testing, the rule created 0 alerts at its real threshold (>= 1000000) in all four windows: the test data has no single transaction of ₱1,000,000 or more. To prove the rule works, the threshold was lowered to >= 1 for one dry run. That created 764 alerts (0 / 0 / 500 / 264 by window, newest first), then the threshold was restored and a new dry run returned 0 again. See [Test a typology with Dry Run](#s-9-4) for the method. ::figure[Rule 7 positive control (threshold temporarily >= 1): 764 alerts]{src="typology-library/r09-dryrun.png" id="fig-typology-library-r09-dryrun"} **Tuning.** Set the amount (1000000) from the size of payment you want reviewed individually. A longer window (for example 7 to 0 Days) catches the same payment on more runs, so keep the **Suppression Window** at least as long as the window. ## Rule 8 · Smurfing {#s-9-r8}

Red flagMany very small payments in a day

Logic
Counts the sender's transactions under ₱1,000 in the last day.
Window
1 to 0 Days
Threshold
≥ 20 under ₱1,000

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who makes 20 or more transactions under ₱1,000 in one day. Many very small payments in a short time can be a way to move money in amounts that do not stand out one by one. | Item | Setting | | --- | --- | | Variable `small_txn_count_1d` | **Count** of `id`, grouped by `sender_entity_id`, **Days** from 1 to 0, filter `amount` **Less Than** 1000 | | Typology type | Structuring (TP100) | | Suppression Window | 1 Day | | Condition | Group 1, Match AND: `small_txn_count_1d` **Greater Than Equal (>=)** Static Value 20 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `small_txn_count_1d` in **Variable name** (1) and a description such as “Number of transactions under PHP 1000 per sender in the last 1 day.” (2). ::figure[Rule 8 variable: name and description]{src="typology-library/r10-var-name.png" id="fig-typology-library-r10-var-name"} ::: ::: step Choose the Field: id Open **Field**, type `id` and choose `id`, the first match. Counting `id` counts transactions. ::figure[Field search for id]{src="typology-library/r10-var-field.png" id="fig-typology-library-r10-var-field"} ::: ::: step Choose the Function: Count Open **Function**. For an ID or text field the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum**. Choose **Count**. ::figure[Function: Count]{src="typology-library/r10-var-function.png" id="fig-typology-library-r10-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the count is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r10-var-groupby.png" id="fig-typology-library-r10-var-groupby"} ::: ::: step Add the filter: choose the amount field Scroll to **Filters (1)**. In the blank row open **Field** (1), type `amount` and choose `amount`. The filter decides which transactions are counted. ::figure[Filter row: the field search for amount]{src="typology-library/r10-var-filter-field.png" id="fig-typology-library-r10-var-filter-field"} ::: ::: step Choose Less Than and type 1000 Open **Operator...** and choose **Less Than**, then type 1000 in **Enter value** and keep **Static**. ₱1,000 itself is not counted. ::figure[Filter operators: Less Than]{src="typology-library/r10-var-filter-operator.png" id="fig-typology-library-r10-var-filter-operator"} ::: ::: step Set the time window: Days, 1 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 1 in **Analyze Transaction from** and 0 in **to** (2): the 1 day up to the trigger time T. The filter row (3) reads `amount` **Less Than** 1000, **Static**. Click **Save Variable** (4). ::figure[Time window 1 to 0 Days ago, the amount filter and Save Variable]{src="typology-library/r10-var-window.png" id="fig-typology-library-r10-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000797. ::figure[Rule 8 variable in the Variables list]{src="typology-library/r10-var-saved.png" id="fig-typology-library-r10-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **STR\_AGG\_COUNT** (1), the **CREATED** and **UPDATED** times and user (2), `id` / **Count** / `sender_entity_id` (3), 1 to 0 **Days ago** (4) and the saved filter, `amount` **Less Than** 1000 (5). ::figure[View Variable for small\_txn\_count\_1d]{src="typology-library/r10-var-view.png" id="fig-typology-library-r10-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Structuring Click **+ New** on **Typology**. Type the name `R10 Smurfing - 20 or more transactions under PHP 1000 in 1 day` (1). Set **Suppression Window** to 1 and choose **Day** (2): the window is one day. Write a description (3). Open **Typology type** (4), type `Struct` and click **Structuring TP100**. ::figure[Rule 8 details and the Typology type search]{src="typology-library/r10-typ-type.png" id="fig-typology-library-r10-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `small_txn_count_1d`. ::figure[Rule 8 row 1: variable search]{src="typology-library/r10-typ-row1-field.png" id="fig-typology-library-r10-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 8 row 1: operator list]{src="typology-library/r10-typ-row1-operator.png" id="fig-typology-library-r10-typ-row1-operator"} ::: ::: step Enter 20 and go to the next step Type 20 in **Enter value**. Check the name (1), the type chip **Structuring (TP100)** (2), **1 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 8 page]{src="typology-library/r10-typ-completed.png" id="fig-typology-library-r10-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 8 after Save as Draft]{src="typology-library/r10-saved-draft.png" id="fig-typology-library-r10-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID TMR-08102026-001132, created 08 Oct 2026, 05:17:54 pm (1); the summary with **INTERVAL** Every 1 day, **SUPPRESSION** 1Day and **TYPOLOGY** Structuring (2); the condition, with the operator shown as **Greater Than Equal (>=)** (3); and the variable card `small_txn_count_1d`, Str\_agg\_count, **WINDOW** in last 1 day, **GROUP** `sender_entity_id` (4). The card does not show the variable’s filter; check it on **View Variable**. ::figure[The saved Rule 8 as a Draft, TMR-08102026-001132]{src="typology-library/r10-detail.png" id="fig-typology-library-r10-detail"} ::: **How it evaluates.** At each run the variable counts, for each sender, the transactions under ₱1,000 in the last day. Sender A made 25 payments of ₱500: 25 >= 20, alert. Sender B made 30 payments, 15 of them under ₱1,000: the count is 15, no alert. **Dry-run result.** In testing, the rule created 0 alerts at its real threshold (>= 20) in all four windows: the test data has transactions under ₱1,000, but no sender with 20 of them in a day. To prove the rule works, the threshold was lowered to >= 1 for one dry run. That created 339 alerts (0 / 0 / 194 / 145 by window, newest first), then the threshold was restored and a new dry run returned 0 again. See [Test a typology with Dry Run](#s-9-4) for the method. ::figure[Rule 8 positive control (threshold temporarily >= 1): 339 alerts]{src="typology-library/r10-dryrun.png" id="fig-typology-library-r10-dryrun"} **Tuning.** You can change the small-amount limit (the filter value 1000), the count (20) and the window. A higher limit or a lower count raises more alerts. ## Rule 9 · Spike against own history {#s-9-r9}

Red flagA week that is large against the sender’s 90 days

Logic
Compares the sender's 7-day total with their 90-day total.
Window
7 to 0 Days and 90 to 0 Days
Threshold
7-day ≥ ₱100,000 AND ≥ 0.5 × 90-day

✓ Verified · 42 alerts

**What it detects and why.** This rule compares a sender with their own past. It flags a sender who sent ₱100,000 or more in the last 7 days when that is at least half of everything they sent in the last 90 days. A sudden jump against a customer’s own baseline can matter even when the amount is ordinary for other customers. | Item | Setting | | --- | --- | | Variable A `sent_sum_7d_spike` | **Sum** of `amount`, grouped by `sender_entity_id`, **Days** from 7 to 0 | | Variable B `sent_sum_90d` | **Sum** of `amount`, grouped by `sender_entity_id`, **Days** from 90 to 0 | | Typology type | Anomaly (TP103) | | Suppression Window | 7 Day | | Conditions | Group 1, Match AND: `sent_sum_7d_spike` **Greater Than Equal (>=)** Static Value 100000 AND `sent_sum_7d_spike` **Greater Than Equal (>=)** Variable `sent_sum_90d`, **THAN MULTIPLIER** 0.5 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create variable A, the recent total** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name variable A Click **+ New** on **Variables**. Type `sent_sum_7d_spike` (1) and a description such as “Total amount sent per sender in the last 7 days.” (2). ::figure[Variable A: name and description]{src="typology-library/r11-varA-name.png" id="fig-typology-library-r11-vara-name"} ::: ::: step Choose amount and Sum Open **Field** and choose `amount`. Open **Function** and choose **Sum**. Then open **Group by** and choose `sender_entity_id`, as in Rule 7. ::figure[Variable A: Function Sum]{src="typology-library/r11-varA-function.png" id="fig-typology-library-r11-vara-function"} ::: ::: step Set the window: Days, 7 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 7 in **Analyze Transaction from** and 0 in **to** (2): the 7 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Variable A: window 7 to 0 Days ago and Save Variable]{src="typology-library/r11-varA-window.png" id="fig-typology-library-r11-vara-window"} ::: ::: step Check variable A The variable is listed as VAR-08102026-000798. Click the row. **View Variable** shows the type tag **NUM\_AGG\_SUM** (1), the **CREATED** and **UPDATED** times and user (2), `amount` / **Sum** / `sender_entity_id` (3), 7 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for variable A]{src="typology-library/r11-varA-view.png" id="fig-typology-library-r11-vara-view"} ::: **Part B: Create variable B, the sender’s own baseline** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name variable B Click **+ New** again. Type `sent_sum_90d` (1) and a description such as “Total amount sent per sender in the last 90 days (the sender’s own baseline).” (2). ::figure[Variable B: name and description]{src="typology-library/r11-varB-name.png" id="fig-typology-library-r11-varb-name"} ::: ::: step Choose amount, Sum and sender\_entity\_id; set 90 to 0 and save Choose `amount`, **Sum** and `sender_entity_id`, as for variable A. Scroll down. Click **Days** (1); the default is **Hours**. Enter 90 in **Analyze Transaction from** and 0 in **to** (2): the 90 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Variable B: window 90 to 0 Days ago and Save Variable]{src="typology-library/r11-varB-window.png" id="fig-typology-library-r11-varb-window"} ::: ::: step Find variable B in the list Variable B is the first row, here VAR-08102026-000799. ::figure[Variable B in the Variables list]{src="typology-library/r11-varB-saved.png" id="fig-typology-library-r11-varb-saved"} ::: ::: step Check variable B Click the row. **View Variable** shows the type tag **NUM\_AGG\_SUM** (1), the **CREATED** and **UPDATED** times and user (2), `amount` / **Sum** / `sender_entity_id` (3), 90 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for variable B]{src="typology-library/r11-varB-view.png" id="fig-typology-library-r11-varb-view"} ::: **Part C: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details; keep the name to 100 characters Click **+ New** on **Typology**. Set **Suppression Window** to 7 **Day**, write a description, and in **Typology type** search `TP103` and click **Anomaly**. Names are limited to 100 characters: the first name tried for this example was longer, and **Next Step** stopped with “Rule name must be 3-100 characters” under **Typology Name**. The final name is `R11 Spike vs own history - PHP 100000 or more in 7 days and half of 90-day total`. ::figure[A name over 100 characters: Rule name must be 3-100 characters]{src="typology-library/r11-typ-name-error.png" id="fig-typology-library-r11-typ-name-error"} ::: ::: step Row 1: variable A Greater Than Equal 100000 In **Group 1**, click **Select field**, type `sent_sum` and click `sent_sum_7d_spike`. Choose **Greater Than Equal**, keep **Static Value** and type 100000. ::figure[Row 1: choose variable A]{src="typology-library/r11-typ-row1-field.png" id="fig-typology-library-r11-typ-row1-field"} ::: ::: step Add row 2 Click **Add Condition**. A second row appears, joined to the first by **AND — all must match** (1). In row 2 (2) choose `sent_sum_7d_spike` again and **Greater Than Equal**. ::figure[Row 2 added, joined by AND — all must match]{src="typology-library/r11-typ-row2-added.png" id="fig-typology-library-r11-typ-row2-added"} ::: ::: step Row 2: compare with variable B In row 2 open the compare-to list and choose **Variable** (1). **Select variable** (2) lists the variables, newest first, without a search box and without the row’s own variable. Choose `sent_sum_90d`. ::figure[Row 2: compare with a Variable, the Select variable list]{src="typology-library/r11-typ-row2-variable.png" id="fig-typology-library-r11-typ-row2-variable"} ::: ::: step Enter the multiplier 0.5 and go to the next step Type 0.5 in **THAN MULTIPLIER**. Row 2 now means “the 7-day total is at least half of the 90-day total”. Check the name (1), **Anomaly (TP103)** (2), **7 Day** (3), row 1 (4) and row 2 (5), then click **Next Step** (6). ::figure[The completed Rule 9 page with two conditions]{src="typology-library/r11-typ-completed.png" id="fig-typology-library-r11-typ-completed"} ::: **Part D: Choose the schedule and save** ::: step Select the shared schedule and save the draft Open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft The page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). ::figure[Rule 9 after Save as Draft]{src="typology-library/r11-saved-draft.png" id="fig-typology-library-r11-saved-draft"} ::: ::: step Check the rule page The rule page shows **Draft** TMR-08102026-001133 (1), **SUPPRESSION** 7Day and **TYPOLOGY** Anomaly (2), both conditions, the second reading “sent\_sum\_90d (multiplied by 0.5)” (3), and both variable cards, in last 90 day and in last 7 day (4). ::figure[The saved Rule 9 as a Draft, TMR-08102026-001133]{src="typology-library/r11-detail.png" id="fig-typology-library-r11-detail"} ::: **How it evaluates.** The 90-day total includes the last 7 days. Sender A sent ₱150,000 in the last 7 days and ₱200,000 in 90 days: ₱150,000 >= 100000 and ₱150,000 >= 0.5 × ₱200,000, so the rule alerts. Sender B sent ₱150,000 in 7 days but ₱1,000,000 in 90 days: ₱150,000 is below ₱500,000, no alert. Sender C sent ₱40,000 in 7 days and ₱50,000 in 90 days: row 1 fails, no alert. **Dry-run result.** In testing, the rule created 42 alerts at its real thresholds: 0, 6, 16 and 20 across the four windows, newest first. ::figure[Rule 9 dry run: 42 alerts]{src="typology-library/r11-dryrun.png" id="fig-typology-library-r11-dryrun"} **Tuning.** Raise the minimum (100000) to ignore small spikes, and change the multiplier: 0.5 means half of the 90-day total; 0.3 is broader. Keep both variables grouped by `sender_entity_id` so they describe the same sender. ## Rule 10 · Many devices {#s-9-r10}

Red flagOne account used from many devices

Logic
Counts the different devices (sender_device_id) the sender used in the last 7 days.
Window
7 to 0 Days
Threshold
≥ 3 devices

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who used 3 or more different devices in 7 days. A customer account operated from many devices can mean that others are using it, as with a shared or rented mule account. | Item | Setting | | --- | --- | | Variable `distinct_devices_7d` | **Count Distinct** of `sender_device_id`, grouped by `sender_entity_id`, **Days** from 7 to 0, no filters | | Typology type | Anomaly (TP103) | | Suppression Window | 7 Day | | Condition | Group 1, Match AND: `distinct_devices_7d` **Greater Than Equal (>=)** Static Value 3 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `distinct_devices_7d` in **Variable name** (1) and a description such as “Number of distinct sender devices per sender in the last 7 days.” (2). ::figure[Rule 10 variable: name and description]{src="typology-library/r12-var-name.png" id="fig-typology-library-r12-var-name"} ::: ::: step Choose the Field: sender\_device\_id Open **Field** and type `device`. Two fields match, `receiver_device_id` and `sender_device_id`. Choose `sender_device_id`. ::figure[Field search for device: choose sender\_device\_id]{src="typology-library/r12-var-field.png" id="fig-typology-library-r12-var-field"} ::: ::: step Choose the Function: Count Distinct Open **Function**. For an ID or text field the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum**. Choose **Count Distinct**: each different value is counted once. ::figure[Function: Count Distinct]{src="typology-library/r12-var-function.png" id="fig-typology-library-r12-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the count is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r12-var-groupby.png" id="fig-typology-library-r12-var-groupby"} ::: ::: step Set the time window: Days, 7 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 7 in **Analyze Transaction from** and 0 in **to** (2): the 7 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Time window 7 to 0 Days ago, blank filter row and Save Variable]{src="typology-library/r12-var-window.png" id="fig-typology-library-r12-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000800. ::figure[Rule 10 variable in the Variables list]{src="typology-library/r12-var-saved.png" id="fig-typology-library-r12-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **STR\_AGG\_COUNT\_DISTINCT** (1), the **CREATED** and **UPDATED** times and user (2), `sender_device_id` / **Count Distinct** / `sender_entity_id` (3), 7 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for distinct\_devices\_7d]{src="typology-library/r12-var-view.png" id="fig-typology-library-r12-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Anomaly Click **+ New** on **Typology**. Type the name `R12 Many devices - 3 or more sender devices in 7 days` (1). Set **Suppression Window** to 7 and choose **Day** (2): it matches the 7-day window. Write a description (3). Open **Typology type** (4), type `TP103` and click **Anomaly TP103**. ::figure[Rule 10 details and the Typology type search]{src="typology-library/r12-typ-type.png" id="fig-typology-library-r12-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `distinct_devices_7d`. ::figure[Rule 10 row 1: variable search]{src="typology-library/r12-typ-row1-field.png" id="fig-typology-library-r12-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 10 row 1: operator list]{src="typology-library/r12-typ-row1-operator.png" id="fig-typology-library-r12-typ-row1-operator"} ::: ::: step Enter 3 and go to the next step Type 3 in **Enter value**. Check the name (1), the type chip **Anomaly (TP103)** (2), **7 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 10 page]{src="typology-library/r12-typ-completed.png" id="fig-typology-library-r12-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 10 after Save as Draft]{src="typology-library/r12-saved-draft.png" id="fig-typology-library-r12-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID TMR-08102026-001134, created 08 Oct 2026, 05:24:06 pm (1); the summary with **INTERVAL** Every 1 day, **SUPPRESSION** 7Day and **TYPOLOGY** Anomaly (2); the condition, with the operator shown as **NUM\_GTE (>=)** (3); and the variable card `distinct_devices_7d`, Str\_agg\_count\_distinct, **WINDOW** in last 7 day, **GROUP** `sender_entity_id` (4). ::figure[The saved Rule 10 as a Draft, TMR-08102026-001134]{src="typology-library/r12-detail.png" id="fig-typology-library-r12-detail"} ::: **How it evaluates.** Sender A sent 6 payments in 7 days from 4 different devices: 4 >= 3, alert. Sender B sent 40 payments from the same 2 devices: 2, no alert. **Dry-run result.** In testing, the rule created 0 alerts at its real threshold (>= 3) in all four windows: in the test data each sender used 1 or 2 devices. To prove the rule works, the threshold was lowered to >= 1 for one dry run. That created 4,043 alerts (1,046 / 1,059 / 1,061 / 877 by window, newest first), then the threshold was restored and a new dry run returned 0 again. See [Test a typology with Dry Run](#s-9-4) for the method. ::figure[Rule 10 positive control (threshold temporarily >= 1): 4,043 alerts]{src="typology-library/r12-dryrun.png" id="fig-typology-library-r12-dryrun"} **Tuning.** Set the number of devices from what is normal for your customers; a household or a business may use several. Keep the **Suppression Window** at least as long as the window. ## Rule 11 · Many IP addresses {#s-9-r11}

Red flagOne account used from many network locations

Logic
Counts the different IP addresses (sender_ip) the sender used in the last 7 days.
Window
7 to 0 Days
Threshold
≥ 15 IP addresses

✓ Verified · 120 alerts

**What it detects and why.** This rule flags a sender who used 15 or more different IP addresses in 7 days. Logging in from many network locations in a short time can mean the account is being operated by several people or through changing connections. | Item | Setting | | --- | --- | | Variable `distinct_ips_7d` | **Count Distinct** of `sender_ip`, grouped by `sender_entity_id`, **Days** from 7 to 0, no filters | | Typology type | Anomaly (TP103) | | Suppression Window | 7 Day | | Condition | Group 1, Match AND: `distinct_ips_7d` **Greater Than Equal (>=)** Static Value 15 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `distinct_ips_7d` in **Variable name** (1) and a description such as “Number of distinct sender IP addresses per sender in the last 7 days.” (2). ::figure[Rule 11 variable: name and description]{src="typology-library/r13-var-name.png" id="fig-typology-library-r13-var-name"} ::: ::: step Choose the Field: sender\_ip Open **Field** and type `_ip`. Two fields match, `receiver_ip` and `sender_ip`. Choose `sender_ip`. ::figure[Field search for \_ip: choose sender\_ip]{src="typology-library/r13-var-field.png" id="fig-typology-library-r13-var-field"} ::: ::: step Choose the Function: Count Distinct Open **Function**. For an ID or text field the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum**. Choose **Count Distinct**: each different value is counted once. ::figure[Function: Count Distinct]{src="typology-library/r13-var-function.png" id="fig-typology-library-r13-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the count is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r13-var-groupby.png" id="fig-typology-library-r13-var-groupby"} ::: ::: step Set the time window: Days, 7 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 7 in **Analyze Transaction from** and 0 in **to** (2): the 7 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Time window 7 to 0 Days ago, blank filter row and Save Variable]{src="typology-library/r13-var-window.png" id="fig-typology-library-r13-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000801. ::figure[Rule 11 variable in the Variables list]{src="typology-library/r13-var-saved.png" id="fig-typology-library-r13-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **STR\_AGG\_COUNT\_DISTINCT** (1), the **CREATED** and **UPDATED** times and user (2), `sender_ip` / **Count Distinct** / `sender_entity_id` (3), 7 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for distinct\_ips\_7d]{src="typology-library/r13-var-view.png" id="fig-typology-library-r13-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Anomaly Click **+ New** on **Typology**. Type the name `R13 Many IPs - 15 or more sender IP addresses in 7 days`, set **Suppression Window** to 7 and choose **Day**, and write a description. Open **Typology type**, type `TP103` and click **Anomaly TP103**. The screens are the same as in Rule 10; the example was first saved with the name and threshold for 5 IP addresses, then changed to 15 after the dry run (see [Test a typology with Dry Run](#s-9-4)). ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `distinct_ips_7d`. ::figure[Rule 11 row 1: variable search]{src="typology-library/r13-typ-row1-field.png" id="fig-typology-library-r13-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 11 row 1: operator list]{src="typology-library/r13-typ-row1-operator.png" id="fig-typology-library-r13-typ-row1-operator"} ::: ::: step Enter 15 and go to the next step Type 15 in **Enter value** and click **Next Step**. In the list of typologies the rule then shows its name, `R13 Many IPs - 15 or more sender IP addresses in 7 days`, with **Draft** and its rule ID, TMR-08102026-001135. ::figure[The Rule 11 example in the typology list, with its final name]{src="typology-library/r13-renamed.png" id="fig-typology-library-r13-renamed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 11 after Save as Draft]{src="typology-library/r13-saved-draft.png" id="fig-typology-library-r13-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology** to check it, as in Rule 10. It is listed as **Draft**, TMR-08102026-001135, with the typology type Anomaly. ::: **How it evaluates.** Sender A used 18 IP addresses in 7 days: 18 >= 15, alert. Sender B used 6: no alert. **Dry-run result.** The threshold was set from the dry run. At 5 IP addresses the rule created 758 alerts across the four windows, far too many to review; at 10 it created 240, at 20 none, and at 15 it created 120 (30 in each window). The rule was saved at 15 and renamed to match. The tuning steps are in [Test a typology with Dry Run](#s-9-4). ::figure[Rule 11 at the final threshold, >= 15: 120 alerts]{src="typology-library/r13-dryrun.png" id="fig-typology-library-r13-dryrun"} **Tuning.** Mobile customers can change IP address often, so set the threshold from a dry run on your own data, as shown for this rule, rather than from a fixed number. ## Rule 12 · Many instruments {#s-9-r12}

Red flagPayments funded from many cards or accounts

Logic
Counts the different instruments (sender_instrument_id) the sender paid from in the last 7 days.
Window
7 to 0 Days
Threshold
≥ 5 instruments

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who paid from 5 or more different instruments (for example cards or accounts) in 7 days. Funding payments from many instruments can hide where the money comes from. | Item | Setting | | --- | --- | | Variable `distinct_instruments_7d` | **Count Distinct** of `sender_instrument_id`, grouped by `sender_entity_id`, **Days** from 7 to 0, no filters | | Typology type | Cardinality (C-01) | | Suppression Window | 7 Day | | Condition | Group 1, Match AND: `distinct_instruments_7d` **Greater Than Equal (>=)** Static Value 5 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `distinct_instruments_7d` in **Variable name** (1) and a description such as “Number of distinct sender instruments (cards or accounts) per sender in the last 7 days.” (2). ::figure[Rule 12 variable: name and description]{src="typology-library/r14-var-name.png" id="fig-typology-library-r14-var-name"} ::: ::: step Choose the Field: sender\_instrument\_id Open **Field** and type `instrument`. The matches include `receiver_instrument_id`, `receiver_instrument_subtype`, `receiver_instrument_type` and `sender_instrument_id`. Choose `sender_instrument_id`. ::figure[Field search for instrument: choose sender\_instrument\_id]{src="typology-library/r14-var-field.png" id="fig-typology-library-r14-var-field"} ::: ::: step Choose the Function: Count Distinct Open **Function**. For an ID or text field the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum**. Choose **Count Distinct**: each different value is counted once. ::figure[Function: Count Distinct]{src="typology-library/r14-var-function.png" id="fig-typology-library-r14-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the count is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r14-var-groupby.png" id="fig-typology-library-r14-var-groupby"} ::: ::: step Set the time window: Days, 7 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 7 in **Analyze Transaction from** and 0 in **to** (2): the 7 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Time window 7 to 0 Days ago, blank filter row and Save Variable]{src="typology-library/r14-var-window.png" id="fig-typology-library-r14-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000802. ::figure[Rule 12 variable in the Variables list]{src="typology-library/r14-var-saved.png" id="fig-typology-library-r14-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **STR\_AGG\_COUNT\_DISTINCT** (1), the **CREATED** and **UPDATED** times and user (2), `sender_instrument_id` / **Count Distinct** / `sender_entity_id` (3), 7 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for distinct\_instruments\_7d]{src="typology-library/r14-var-view.png" id="fig-typology-library-r14-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Cardinality Click **+ New** on **Typology**. Type the name `R14 Many instruments - 5 or more sender instruments in 7 days` (1). Set **Suppression Window** to 7 and choose **Day** (2): it matches the 7-day window. Write a description (3). Open **Typology type** (4), type `Cardin` and click **Cardinality C-01**. ::figure[Rule 12 details and the Typology type search]{src="typology-library/r14-typ-type.png" id="fig-typology-library-r14-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `distinct_instruments_7d`. ::figure[Rule 12 row 1: variable search]{src="typology-library/r14-typ-row1-field.png" id="fig-typology-library-r14-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 12 row 1: operator list]{src="typology-library/r14-typ-row1-operator.png" id="fig-typology-library-r14-typ-row1-operator"} ::: ::: step Enter 5 and go to the next step Type 5 in **Enter value**. Check the name (1), the type chip **Cardinality (C-01)** (2), **7 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 12 page]{src="typology-library/r14-typ-completed.png" id="fig-typology-library-r14-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 12 after Save as Draft]{src="typology-library/r14-saved-draft.png" id="fig-typology-library-r14-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID TMR-08102026-001136, created 08 Oct 2026, 05:28:28 pm (1); the summary with **INTERVAL** Every 1 day, **SUPPRESSION** 7Day and **TYPOLOGY** Cardinality (2); the condition, with the operator shown as **Greater Than Equal (>=)** (3); and the variable card `distinct_instruments_7d`, Str\_agg\_count\_distinct, **WINDOW** in last 7 day, **GROUP** `sender_entity_id` (4). ::figure[The saved Rule 12 as a Draft, TMR-08102026-001136]{src="typology-library/r14-detail.png" id="fig-typology-library-r14-detail"} ::: **How it evaluates.** Sender A paid from 6 different cards in a week: 6 >= 5, alert. Sender B paid 30 times from 1 account: no alert. **Dry-run result.** In testing, the rule created 0 alerts at its real threshold (>= 5) in all four windows: no sender in the test data used 5 instruments in 7 days. To prove the rule works, the threshold was lowered to >= 1 for one dry run. That created 4,615 alerts (1,164 / 1,187 / 1,222 / 1,042 by window, newest first), then the threshold was restored and a new dry run returned 0 again. See [Test a typology with Dry Run](#s-9-4) for the method. ::figure[Rule 12 positive control (threshold temporarily >= 1): 4,615 alerts]{src="typology-library/r14-dryrun.png" id="fig-typology-library-r14-dryrun"} **Tuning.** Set the number of instruments from what your customers normally hold. To count only one kind of instrument, add a filter on `sender_instrument_type`. ## Rule 13 · Many currencies {#s-9-r13}

Red flagSwitching between currencies

Logic
Counts the different currencies (currency_code) the sender used in the last 30 days.
Window
30 to 0 Days
Threshold
≥ 3 currencies

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who transacted in 3 or more different currencies in 30 days. Frequent switching between currencies is unusual for most retail customers and can be part of moving value across borders. | Item | Setting | | --- | --- | | Variable `distinct_currencies_30d` | **Count Distinct** of `currency_code`, grouped by `sender_entity_id`, **Days** from 30 to 0, no filters | | Typology type | Anomaly (TP103) | | Suppression Window | 30 Day | | Condition | Group 1, Match AND: `distinct_currencies_30d` **Greater Than Equal (>=)** Static Value 3 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `distinct_currencies_30d` in **Variable name** (1) and a description such as “Number of distinct transaction currencies per sender in the last 30 days.” (2). ::figure[Rule 13 variable: name and description]{src="typology-library/r15-var-name.png" id="fig-typology-library-r15-var-name"} ::: ::: step Choose the Field: currency\_code Open **Field** and type `currency`. The matches are `currency_code`, `orig_currency_amount`, `orig_currency_code`, `receiver_currency_code` and `sender_currency_code`. Choose `currency_code`. ::figure[Field search for currency: choose currency\_code]{src="typology-library/r15-var-field.png" id="fig-typology-library-r15-var-field"} ::: ::: step Choose the Function: Count Distinct Open **Function**. For an ID or text field the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum**. Choose **Count Distinct**: each different value is counted once. ::figure[Function: Count Distinct]{src="typology-library/r15-var-function.png" id="fig-typology-library-r15-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the count is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r15-var-groupby.png" id="fig-typology-library-r15-var-groupby"} ::: ::: step Set the time window: Days, 30 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 30 in **Analyze Transaction from** and 0 in **to** (2): the 30 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Time window 30 to 0 Days ago, blank filter row and Save Variable]{src="typology-library/r15-var-window.png" id="fig-typology-library-r15-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000803. ::figure[Rule 13 variable in the Variables list]{src="typology-library/r15-var-saved.png" id="fig-typology-library-r15-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **STR\_AGG\_COUNT\_DISTINCT** (1), the **CREATED** and **UPDATED** times and user (2), `currency_code` / **Count Distinct** / `sender_entity_id` (3), 30 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for distinct\_currencies\_30d]{src="typology-library/r15-var-view.png" id="fig-typology-library-r15-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Anomaly Click **+ New** on **Typology**. Type the name `R15 Many currencies - 3 or more currencies in 30 days` (1). Set **Suppression Window** to 30 and choose **Day** (2): it matches the 30-day window. Write a description (3). Open **Typology type** (4), type `TP103` and click **Anomaly TP103**. ::figure[Rule 13 details and the Typology type search]{src="typology-library/r15-typ-type.png" id="fig-typology-library-r15-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `distinct_currencies_30d`. ::figure[Rule 13 row 1: variable search]{src="typology-library/r15-typ-row1-field.png" id="fig-typology-library-r15-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 13 row 1: operator list]{src="typology-library/r15-typ-row1-operator.png" id="fig-typology-library-r15-typ-row1-operator"} ::: ::: step Enter 3 and go to the next step Type 3 in **Enter value**. Check the name (1), the type chip **Anomaly (TP103)** (2), **30 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 13 page]{src="typology-library/r15-typ-completed.png" id="fig-typology-library-r15-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 13 after Save as Draft]{src="typology-library/r15-saved-draft.png" id="fig-typology-library-r15-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. The page has the same layout as in Rule 12: **Draft** with the rule ID TMR-08102026-001137, **SUPPRESSION** 30Day, **TYPOLOGY** Anomaly, the condition and the variable card. ::: **How it evaluates.** Sender A sent payments in PHP, USD and EUR within 30 days: 3 >= 3, alert. Sender B paid only in PHP: 1, no alert. **Dry-run result.** In testing, the rule created 0 alerts at its real threshold (>= 3) in all four windows: no sender in the test data used 3 currencies in 30 days. To prove the rule works, the threshold was lowered to >= 1 for one dry run. That created 6,512 alerts (1,671 / 1,680 / 1,685 / 1,476 by window, newest first), then the threshold was restored and a new dry run returned 0 again. See [Test a typology with Dry Run](#s-9-4) for the method. This control shows that `currency_code` is filled in for every sender; with only one currency per sender in the test data, it cannot show a sender with several currencies. ::figure[Rule 13 positive control (threshold temporarily >= 1): 6,512 alerts]{src="typology-library/r15-dryrun.png" id="fig-typology-library-r15-dryrun"} **Tuning.** Set the number of currencies from your product range: a foreign-exchange or remittance customer may normally use several. ## Rule 14 · Many destination countries {#s-9-r14}

Red flagPayments spread across countries

Logic
Counts the different destination countries (receiver_provider_country) the sender paid into in the last 30 days.
Window
30 to 0 Days
Threshold
≥ 3 countries

✓ Verified · 94 alerts

**What it detects and why.** This rule flags a sender who paid receivers in 3 or more different provider countries in 30 days. Spreading payments across many countries is a common way to move funds out of reach. | Item | Setting | | --- | --- | | Variable `distinct_dest_countries_30d` | **Count Distinct** of `receiver_provider_country`, grouped by `sender_entity_id`, **Days** from 30 to 0, no filters | | Typology type | Anomaly (TP103) | | Suppression Window | 30 Day | | Condition | Group 1, Match AND: `distinct_dest_countries_30d` **Greater Than Equal (>=)** Static Value 3 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `distinct_dest_countries_30d` in **Variable name** (1) and a description such as “Number of distinct receiver provider countries per sender in the last 30 days.” (2). ::figure[Rule 14 variable: name and description]{src="typology-library/r16-var-name.png" id="fig-typology-library-r16-var-name"} ::: ::: step Choose the Field: receiver\_provider\_country Open **Field** and type `country`. Two fields match, `receiver_provider_country` and `sender_provider_country`. Choose `receiver_provider_country`. ::figure[Field search for country: choose receiver\_provider\_country]{src="typology-library/r16-var-field.png" id="fig-typology-library-r16-var-field"} ::: ::: step Choose the Function: Count Distinct Open **Function**. For an ID or text field the list offers **Count**, **Count Distinct**, **Minimum** and **Maximum**. Choose **Count Distinct**: each different value is counted once. ::figure[Function: Count Distinct]{src="typology-library/r16-var-function.png" id="fig-typology-library-r16-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the count is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r16-var-groupby.png" id="fig-typology-library-r16-var-groupby"} ::: ::: step Set the time window: Days, 30 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 30 in **Analyze Transaction from** and 0 in **to** (2): the 30 days up to the trigger time T. Leave the blank row under **Filters (1)** (3) empty: a blank row is dropped when you save. Click **Save Variable** (4). ::figure[Time window 30 to 0 Days ago, blank filter row and Save Variable]{src="typology-library/r16-var-window.png" id="fig-typology-library-r16-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000804. ::figure[Rule 14 variable in the Variables list]{src="typology-library/r16-var-saved.png" id="fig-typology-library-r16-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **STR\_AGG\_COUNT\_DISTINCT** (1), the **CREATED** and **UPDATED** times and user (2), `receiver_provider_country` / **Count Distinct** / `sender_entity_id` (3), 30 to 0 **Days ago** (4) and **Filters (0)** (5). ::figure[View Variable for distinct\_dest\_countries\_30d]{src="typology-library/r16-var-view.png" id="fig-typology-library-r16-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose Anomaly Click **+ New** on **Typology**. Type the name `R16 Many destination countries - 3 or more receiver countries in 30 days` (1). Set **Suppression Window** to 30 and choose **Day** (2): it matches the 30-day window. Write a description (3). Open **Typology type** (4), type `TP103` and click **Anomaly TP103**. ::figure[Rule 14 details and the Typology type search]{src="typology-library/r16-typ-type.png" id="fig-typology-library-r16-typ-type"} ::: ::: step Choose the variable in row 1 In **Group 1**, click **Select field** next to **WHEN**, type part of the name and click `distinct_dest_countries_30d`. ::figure[Rule 14 row 1: variable search]{src="typology-library/r16-typ-row1-field.png" id="fig-typology-library-r16-typ-row1-field"} ::: ::: step Choose Greater Than Equal and keep Static Value Open **Select operator** and choose **Greater Than Equal**. Keep **Static Value** in the compare-to list: the threshold is a fixed number. ::figure[Rule 14 row 1: operator list]{src="typology-library/r16-typ-row1-operator.png" id="fig-typology-library-r16-typ-row1-operator"} ::: ::: step Enter 3 and go to the next step Type 3 in **Enter value**. Check the name (1), the type chip **Anomaly (TP103)** (2), **30 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 14 page]{src="typology-library/r16-typ-completed.png" id="fig-typology-library-r16-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 14 after Save as Draft]{src="typology-library/r16-saved-draft.png" id="fig-typology-library-r16-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID TMR-08102026-001138, created 08 Oct 2026, 06:39:17 pm (1); the summary with **INTERVAL** Every 1 day, **SUPPRESSION** 30Day and **TYPOLOGY** Anomaly (2); the condition, with the operator shown as **Greater Than Equal (>=)** (3); and the variable card `distinct_dest_countries_30d`, Str\_agg\_count\_distinct, **WINDOW** in last 30 day, **GROUP** `sender_entity_id` (4). ::figure[The saved Rule 14 as a Draft, TMR-08102026-001138]{src="typology-library/r16-detail.png" id="fig-typology-library-r16-detail"} ::: **How it evaluates.** Sender A paid receivers in 4 countries within 30 days: 4 >= 3, alert. Sender B paid 20 receivers, all in 1 country: no alert. **Dry-run result.** In testing, the rule created 94 alerts at its real threshold: 31, 31, 31 and 1 across the four windows, newest first. ::figure[Rule 14 dry run at >= 3: 94 alerts]{src="typology-library/r16-dryrun.png" id="fig-typology-library-r16-dryrun"} **Tuning.** Set the number of countries from your customers’ normal corridors, and check the volume with a dry run. ## Rule 15 · Cross-border volume {#s-9-r15}

Red flagA large total sent abroad

Logic
Adds up the amount the sender sent to a country other than their own in the last 30 days.
Window
30 to 0 Days
Threshold
≥ ₱1,000,000

✓ Verified by positive control

**What it detects and why.** This rule flags a sender who sent ₱1,000,000 or more abroad within 30 days, counting only payments whose receiver’s provider country differs from the sender’s. It separates cross-border value from domestic value. | Item | Setting | | --- | --- | | Variable `crossborder_sum_30d` | **Sum** of `amount`, grouped by `sender_entity_id`, **Days** from 30 to 0, filter `receiver_provider_country` **Not Equal** `sender_provider_country` (**Dynamic**) | | Typology type | High Value (HV01) | | Suppression Window | 30 Day | | Condition | Group 1, Match AND: `crossborder_sum_30d` **Greater Than Equal (>=)** Static Value 1000000 | | Schedule | Existing `schedule_2027` (created in [Rule 1](#s-9-r1)): every 1 Day, starting 09 Oct 2026, 09:00 AM, no end time | **Part A: Create the variable** ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open the form and name the variable Click **+ New** on **Variables** and leave **Transaction** selected. Type `crossborder_sum_30d` in **Variable name** (1) and a description such as “Total amount sent per sender in the last 30 days where the receiver provider country differs from the sender provider country.” (2). ::figure[Rule 15 variable: name and description]{src="typology-library/r17-var-name.png" id="fig-typology-library-r17-var-name"} ::: ::: step Choose the Field: amount Open **Field**, type `amount` and choose `amount`, as in Rule 7. ::: ::: step Choose the Function: Sum Open **Function** and choose **Sum** to add the amounts together. ::figure[Function: Sum]{src="typology-library/r17-var-function.png" id="fig-typology-library-r17-var-function"} ::: ::: step Choose Group by: sender\_entity\_id Open **Group by**, type `sender_entity` in **Search Fields** and choose `sender_entity_id`, so the total is calculated separately for each sender. ::figure[Group by search: sender\_entity\_id]{src="typology-library/r17-var-groupby.png" id="fig-typology-library-r17-var-groupby"} ::: ::: step Add the filter: receiver\_provider\_country Scroll to **Filters (1)**. In the blank row open **Field**, type `country` and choose `receiver_provider_country`. ::figure[Filter row: the field search for country]{src="typology-library/r17-var-filter-field.png" id="fig-typology-library-r17-var-filter-field"} ::: ::: step Choose Not Equal Open **Operator...**. For a text field the list is **Equal**, **Not Equal**, **In**, **Not In**, **Contains**, **Not Contains**, then (scroll) **Starts With**, **Ends With**, **Is Null** and **Is Not Null**. Choose **Not Equal**. ::figure[Filter operators for a text field: Not Equal]{src="typology-library/r17-var-filter-operator.png" id="fig-typology-library-r17-var-filter-operator"} ::: ::: step Compare with the sender’s country: Dynamic Click **Dynamic** (1). The value box becomes **Field...**, a list of other fields. Type `provider_country` and choose `sender_provider_country` (2). A transaction is now counted only when the receiver’s provider country differs from the sender’s. ::figure[Dynamic compare: sender\_provider\_country]{src="typology-library/r17-var-filter-dynamic.png" id="fig-typology-library-r17-var-filter-dynamic"} ::: ::: step Set the time window: Days, 30 to 0, and save Scroll down. Click **Days** (1); the default is **Hours**. Enter 30 in **Analyze Transaction from** and 0 in **to** (2): the 30 days up to the trigger time T. The filter row (3) reads `receiver_provider_country` **Not Equal** `sender_provider_country`, **Dynamic**. Click **Save Variable** (4). ::figure[Time window 30 to 0 Days ago, the Dynamic filter and Save Variable]{src="typology-library/r17-var-window.png" id="fig-typology-library-r17-var-window"} ::: ::: step Find the variable in the list The dialog closes and the variable is the first row of the **Variables** list, here VAR-08102026-000805. ::figure[Rule 15 variable in the Variables list]{src="typology-library/r17-var-saved.png" id="fig-typology-library-r17-var-saved"} ::: ::: step Check the saved variable Click the row. **View Variable** shows the type tag **NUM\_AGG\_SUM** (1), the **CREATED** and **UPDATED** times and user (2), `amount` / **Sum** / `sender_entity_id` (3), 30 to 0 **Days ago** (4) and the saved **Dynamic** filter (5). ::figure[View Variable for crossborder\_sum\_30d]{src="typology-library/r17-var-view.png" id="fig-typology-library-r17-var-view"} ::: **Part B: Create the typology** ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Fill in the details and choose High Value Click **+ New** on **Typology**. Type the name `R17 Cross-border volume - PHP 1000000 or more sent abroad in 30 days` (1). Set **Suppression Window** to 30 and choose **Day** (2): it matches the 30-day window. Write a description (3). Open **Typology type** (4), type `HV01` and click **High Value HV01**. ::figure[Rule 15 details and the Typology type search]{src="typology-library/r17-typ-type.png" id="fig-typology-library-r17-typ-type"} ::: ::: step Choose the variable, operator and compare-to in row 1 In **Group 1**, click **Select field**, type part of the name and click `crossborder_sum_30d`. Choose **Greater Than Equal** and keep **Static Value**. ::figure[Rule 15 row 1: variable search]{src="typology-library/r17-typ-row1-field.png" id="fig-typology-library-r17-typ-row1-field"} ::: ::: step Enter 1000000 and go to the next step Type 1000000 in **Enter value**. Check the name (1), the type chip **High Value (HV01)** (2), **30 Day** (3), the description (4), **Match** AND (5) and the row (6). Click **Next Step** (7). ::figure[The completed Rule 15 page]{src="typology-library/r17-typ-completed.png" id="fig-typology-library-r17-typ-completed"} ::: **Part C: Choose the schedule and save** ::: step Select the shared schedule and save the draft On **Review & schedule rule**, open **Select Schedule**, search for `schedule_2027`, click it and click **Save as Draft**, as in [Rule 7](#s-9-r7). ::: ::: step Check the saved draft Wait a few seconds: the page becomes **Update Typology** (1) with the schedule (2), the run sentence (3), **Update** (4), **Dry Run** (5) and **Activate** (6). The screenshot shows the start in force when it was taken (01 Jan 2027). ::figure[Rule 15 after Save as Draft]{src="typology-library/r17-saved-draft.png" id="fig-typology-library-r17-saved-draft"} ::: ::: step Check the rule page Open the rule from **Transaction Monitoring → Typology**. It shows **Draft** and the rule ID TMR-08102026-001139, created 08 Oct 2026, 06:42:04 pm (1); the summary with **INTERVAL** Every 1 day, **SUPPRESSION** 30Day and **TYPOLOGY** High Value (2); the condition, with the operator shown as **Greater Than Equal (>=)** (3); and the variable card `crossborder_sum_30d`, Num\_agg\_sum, **WINDOW** in last 30 day, **GROUP** `sender_entity_id` (4). The card does not show the variable’s filter; check it on **View Variable**. ::figure[The saved Rule 15 as a Draft, TMR-08102026-001139]{src="typology-library/r17-detail.png" id="fig-typology-library-r17-detail"} ::: **How it evaluates.** Sender A sent ₱700,000 to a receiver abroad and ₱400,000 to another receiver abroad: ₱1,100,000, alert. Sender B sent ₱3,000,000, all to receivers in the same country: the filter leaves nothing to add, no alert. **Dry-run result.** In testing, the rule created 0 alerts at its real threshold (>= 1000000) in all four windows: no sender in the test data sent ₱1,000,000 abroad in 30 days. To prove the rule works, the threshold was lowered to >= 1 for one dry run. That created 991 alerts (276 / 278 / 282 / 155 by window, newest first), then the threshold was restored and a new dry run returned 0 again. See [Test a typology with Dry Run](#s-9-4) for the method. The control also shows the filter at work: 991 alerts against 6,512 for the unfiltered 30-day total of Rule 3 at the same threshold. ::figure[Rule 15 positive control (threshold temporarily >= 1): 991 alerts]{src="typology-library/r17-dryrun.png" id="fig-typology-library-r17-dryrun"} **Tuning.** Set the amount from your cross-border risk appetite. Variant, not tested with Dry Run: to cover only some countries, use **In** on `receiver_provider_country` instead of the Dynamic compare (see [proposal P1](#s-9-7)). ## Test a typology with Dry Run {#s-9-4} ::path[Fyscal ARCX → Transaction Monitoring → Typology → rule → Update → Next Step] A dry run runs a saved draft against past records and reports how many alerts it would have created. Every rule in this chapter was dry-run on 08 Oct 2026; the results are in the [Rule index](#s-9-2). ::: step Open the rule’s Review page Open the saved draft, click **Update**, then **Next Step**. **Review & schedule rule** shows the card **Dry run on historical records** (1): “Test this rule against past data before going live. No alerts are created during a dry run.” **Dry Run** (2) is available once the rule is saved as a draft with a schedule; **Activate** (3) is next to **Previous Step**. ::figure[Review & schedule rule with the Dry run card (Rule 1)]{src="typology-library/dr-01-review.png" id="fig-typology-library-dr-01-review"} ::: ::: step Click Dry Run Click **Dry Run**. No dialog or date choice appears. When the run finishes, the result opens in the card, **Dry Run** is replaced by **Re-run** and **Hide Result** (1), and the message “Dry run executed successfully” (2) appears at the bottom right. ::figure[The finished dry run: Re-run, Hide Result and the success message]{src="typology-library/dr-02-finished.png" id="fig-typology-library-dr-02-finished"} ::: ::: step Read the result The top row (1) shows **Time Windows**, **Records Scanned** and **Alert Created** for the whole run. Below, one card per window (2) shows the window’s dates and its own **Records Scanned** and **Alert Created**. In the example the run tested 4 windows of one day each, the schedule’s interval, from 04 Oct 2026, 09:00 am to 08 Oct 2026, 09:00 am, newest first, and scanned 1,560 records. Rule 1 created 0 alerts. **Re-run** (3) runs it again. ::figure[Dry-run result for Rule 1: 4 windows, 1,560 records, 0 alerts]{src="typology-library/dr-03-result.png" id="fig-typology-library-dr-03-result"} ::: ::: step Compare with a rule that finds something Rule 5 (fan-out) created 240 alerts (1), 60 in each window. Window 01 (2) scanned 0 records and still created 60 alerts: the window’s **Records Scanned** counts the records in that day, while the rule’s variable looks back 7 days. A rule with a 1-day variable, such as Rule 2, created alerts only in the windows that contained records. ::figure[Dry-run result for Rule 5: 240 alerts, 60 per window]{src="typology-library/dr-04-r05.png" id="fig-typology-library-dr-04-r05"} ::: ::: note What a dry run shows The result shows counts per window only. It does not list the senders or transactions that matched, and the counts cannot be opened. No alerts are created. ::: ::: step Edit the rule: the dry run is erased If you change the rule or its schedule and click **Update**, the dialog **Update Typology** says “Your dry run results would be erased once you update and save the rule again”. Click **Update** to save; the result is cleared and you run the dry run again. Until you confirm, the page waits behind the dialog, so look for it if **Update** seems to do nothing. While the form has unsaved changes, **Re-run** and **Activate** are greyed out. ::figure[Update Typology: Your dry run results would be erased]{src="typology-library/dr-05-erase-dialog.png" id="fig-typology-library-dr-05-erase-dialog"} ::: **Judge the result: 0 is not proof** A result of 0 can mean that the data has no such pattern, or that the rule cannot read the data, for example because a field is empty. To tell them apart, run a positive control: lower the threshold so that any matching record would alert, check that alerts appear, then restore the threshold. The zero-alert rules in this chapter were all checked this way. Diagram 9.2 in [Building blocks](#s-9-1) summarises the decision. ::: step Lower the threshold for one run In the rule, change the threshold to a value that must match if the data is read, here **Greater Than Equal** 1 instead of 3. Click **Update**, confirm the dialog, click **Next Step** and run **Dry Run**. Rule 1 created 4 alerts (1), so the variable, its filters and the condition work. ::figure[Positive control for Rule 1: threshold temporarily >= 1, 4 alerts]{src="typology-library/dr-06-control.png" id="fig-typology-library-dr-06-control"} ::: ::: step Restore the real threshold Change the threshold back (here 3), click **Update**, confirm, and run the dry run again. It returns to 0 alerts (1). Do not request activation with the lowered threshold. ::figure[Rule 1 with the threshold restored to >= 3: 0 alerts]{src="typology-library/dr-07-restored.png" id="fig-typology-library-dr-07-restored"} ::: **Tune a noisy rule** If a rule creates more alerts than your team can review, raise the threshold step by step and re-run. ::: step Start from the first result Rule 11 (many IP addresses) was first saved at 5 or more IP addresses in 7 days. The dry run created 758 alerts in four days of data, about 190 a day. ::figure[Rule 11 at >= 5: 758 alerts]{src="typology-library/dr-08-tune-5.png" id="fig-typology-library-dr-08-tune-5"} ::: ::: step Raise the threshold and re-run At 10 the rule created 240 alerts. At 20 it created none. Each change needs **Update**, the confirmation and a new dry run. ::figure[Rule 11 at >= 10: 240 alerts]{src="typology-library/dr-09-tune-10.png" id="fig-typology-library-dr-09-tune-10"} ::: ::: step Settle on a value and rename the rule At 15 the rule created 120 alerts, 30 a day (see [Rule 11](#s-9-r11)). The example was saved at 15 and its name and description were changed to say 15, so the name still describes the condition. ::: ## Request Shadow activation {#s-9-5} ::path[Fyscal ARCX → Transaction Monitoring → Typology → rule → Update → Next Step → Activate] In Shadow Mode a rule runs on live data and its alerts are shown on the rule’s page, not sent to Alert Manager. Activation is a Maker Checker request: you (the maker) submit it, and a checker reviews it in [Maker Checker Approval](#maker-checker). While the request waits, the rule stays a **Draft**. ::: step Click Activate and read the modes On **Review & schedule rule**, click **Activate**. **Activation Mode** offers **Shadow Mode** (1), “Alert generated against live data will be shown in rule detail page.”, and **Published Mode** (2), “Alert from this rule will flow into Alert Manager.” Published is a separate mode and is not covered here. **Activate** (3) continues. ::figure[Activation Mode: Shadow Mode and Published Mode]{src="typology-library/sh-01-activate.png" id="fig-typology-library-sh-01-activate"} ::: ::: step Select Shadow Mode Click the **Shadow Mode** card so that its radio button is filled (1), then click **Activate** (2). ::figure[Shadow Mode selected]{src="typology-library/sh-02-shadow-selected.png" id="fig-typology-library-sh-02-shadow-selected"} ::: ::: step Read the Submit Request dialog **Submit Request** asks for a **Reason** (1), required, and optional **Supporting Documents** (2): 1 file, max 2 MB, .jpg, .jpeg, .jpe, .png, .pdf, .webp or .md, added with **Attach File**. **Confirm** (3) is greyed out until a reason is entered. ::figure[Submit Request: Reason, Supporting Documents and Confirm]{src="typology-library/sh-03-submit-empty.png" id="fig-typology-library-sh-03-submit-empty"} ::: ::: step Write the reason and confirm Type a reason the checker can act on (1), for example the rule’s purpose, the dry-run result and “start in Shadow”. The example used a short test reason. Click **Confirm** (2). ::figure[Reason entered; Confirm available]{src="typology-library/sh-04-submit-filled.png" id="fig-typology-library-sh-04-submit-filled"} ::: ::: step Read the confirmation The typology list opens and a message gives the request’s ticket ID: “Submitted for governance review (ticket AMLTM\_…). It will be applied once approved.” ::figure[Submitted for governance review, with the ticket ID]{src="typology-library/sh-05-toast.png" id="fig-typology-library-sh-05-toast"} ::: ::: step Check the rule: it is still a Draft Open the rule. It still shows **Draft** (1) and **Activate** (2): the request has not changed the rule. The **EXECUTION PERIOD** (3) starts at the schedule’s start, 09 Oct 2026, 09:00:00 am. ::figure[Rule 1 after the request: still Draft]{src="typology-library/sh-06-still-draft.png" id="fig-typology-library-sh-06-still-draft"} ::: ::path[Fyscal ARCX → Maker Checker Approval → Tickets] ::: step Find the request in Tickets Go to **Maker Checker Approval → Tickets**. The request is the top row: Request ID 991, **Activate Typology**, status **Pending**, with the maker and the time it was created. ::figure[Tickets: the Activate Typology request, Pending]{src="typology-library/sh-07-tickets.png" id="fig-typology-library-sh-07-tickets"} ::: ::: step Open the ticket Click ⋮ in **Actions** and choose **View**. (**Watch** is the other choice.) ::figure[The row’s Actions menu: View and Watch]{src="typology-library/sh-08-actions.png" id="fig-typology-library-sh-08-actions"} ::: ::: step Read the request **Request Details** shows the request ID and **Pending** (1); the **Domain** Fyscal ARCX/Transaction Monitoring/Typology, the **Action** Activate Typology and **Checker Progress** 0 / 1 checkers acted (2); the **Reason** (3); and under **Data Difference** (4) the change requested: **Activation Mode** from - to shadow. Below, **Additional Context** gives the rule name and URL. Further down, the maker’s view has a **Remarks** box and **Withdraw**. ::figure[Request Details for an Activate Typology request]{src="typology-library/sh-09-ticket-view.png" id="fig-typology-library-sh-09-ticket-view"} ::: Every rule in this chapter was submitted for Shadow activation on 08 Oct 2026: 15 requests, numbers 991 to 1005. No checker acted on them, and by 11 Oct 2026 all 15 showed **Expired**, so the rules are still Draft. Rule 4 was rebuilt on 15 Oct 2026 as a new draft (see [Rule 4](#s-9-r4)). A request has to be approved before it expires; if it expires, submit a new one. ::figure[Tickets: the 15 Shadow requests for this chapter’s rules, all Pending]{src="typology-library/sh-10-all-pending.png" id="fig-typology-library-sh-10-all-pending"} ::: note When the maker opens their own ticket, the only action offered is **Withdraw**. No approve or decline buttons appear in the maker's view. Ask a colleague with the checker role to review the ticket; see [View a ticket](#s-11-8). ::: ## Tuning and false positives {#s-9-6} The settings each rule lets you change, and the ordinary activity that most often sets it off. The settings come from the rules above; the causes of false positives are general AML experience, not results from Fyscal ARCX. After each change, run a [Dry Run](#s-9-4) and compare the alert count with the previous one. | Rule | Settings to tune | Common legitimate causes of alerts | | --- | --- | --- | | [1 · Structuring](#s-9-r1) | Band edges (filter values), count, window | Instalments, rent or payroll of a fixed size that happens to sit inside the band | | [2 · Velocity](#s-9-r2) | Count, window and its unit (Hours for shorter bursts) | Merchants, payroll and bill-payment accounts that transact many times a day | | [3 · High value](#s-9-r3) | Amount, window | Corporate and treasury accounts, property or vehicle purchases, loan drawdowns | | [4 · Dormant account](#s-9-r4) | Length of the quiet period, reactivation amount | Seasonal workers, customers who return from abroad, maturing deposits or annual payments | | [5 · Fan-out](#s-9-r5) | Distinct-receiver count, window, optional amount filter | Payroll, supplier runs, remittance businesses, family support to many relatives | | [6 · Fan-in](#s-9-r6) | Distinct-sender count, window, optional amount filter | Merchants, collection accounts, charities, landlords with many tenants | | [7 · Large single transaction](#s-9-r7) | Amount | Known large clients, property settlements, business-to-business payments | | [8 · Smurfing](#s-9-r8) | Small-amount limit, count, window | Micro-payment, transport, gaming top-up or e-wallet usage patterns | | [9 · Spike against own history](#s-9-r9) | Minimum amount, multiplier | New customers with little history, salary bonuses, seasonal or one-off purchases | | [10 · Many devices](#s-9-r10) | Distinct-device count, window | New or replaced phones, households sharing an account, business staff | | [11 · Many IP addresses](#s-9-r11) | Distinct-IP count, window | Mobile networks that change IP addresses often, travel, public Wi-Fi | | [12 · Many instruments](#s-9-r12) | Distinct-instrument count, optional instrument-type filter | Customers with several cards or accounts at one institution, card replacements | | [13 · Many currencies](#s-9-r13) | Distinct-currency count, window | Foreign-exchange, remittance, travel and import-export customers | | [14 · Many destination countries](#s-9-r14) | Distinct-country count, window | Remittance and trade customers with several regular corridors | | [15 · Cross-border volume](#s-9-r15) | Amount, window, the country filter | Overseas workers’ family support, tuition abroad, regular trade payments | ::: note AML context Record why each threshold was chosen, test every change before it goes live, and review alert outcomes regularly. A rule that produces many alerts that are all closed as not suspicious usually needs a narrower variable (a filter) or a higher threshold, rather than more analysts. ::: ## Proposed typologies {#s-9-7} ::: important The rules in this section are proposals. None of them has been built, dry-run or submitted for activation, so none is part of the verified library above. Each uses only fields, functions and operators that the forms offer (see [Building blocks](#s-9-1)), but whether a rule behaves as described is not yet known. Build one as a Draft, dry-run it with a positive control and start it in Shadow Mode before you rely on it. ::: Each proposal lists its variables and conditions, and the point to check first. Thresholds are placeholders for your own risk assessment. **P1 · Payments to high-risk countries** · *Proposed — not yet tested* | Red flag | A sender pays receivers in countries your policy treats as high risk. | | --- | --- | | Variable | **Count** of `id`, grouped by `sender_entity_id`, 30 to 0 Days, filter `receiver_provider_country` **In** your list of countries | | Condition | Variable **Greater Than Equal (>=)** 1 | | Check first | The format of `receiver_provider_country` values (for example two-letter codes or names) is not visible in the product, and the test data had no payments to the countries tried. | **P2 · Pass-through account** · *Proposed — not yet tested* | Red flag | Money received is sent on almost in full within a short time (layering). | | --- | --- | | Variables | A: **Sum** of `amount`, grouped by `receiver_entity_id`, 7 to 0 Days (received). B: **Sum** of `amount`, grouped by `sender_entity_id`, 7 to 0 Days (sent). For a faster pattern, use **Hours** as the unit. | | Conditions | Match AND: A **Greater Than Equal (>=)** a minimum you choose, and B **Greater Than Equal (>=)** Variable A with **THAN MULTIPLIER** 0.9 | | Check first | Whether a typology that compares a variable grouped by `receiver_entity_id` with one grouped by `sender_entity_id` matches the same customer. | **P3 · Repeated identical amounts** · *Proposed — not yet tested* | Red flag | Many payments of exactly the same amount, which can indicate structured or scripted transfers. | | --- | --- | | Variables | A: **Count** of `id`, grouped by `sender_entity_id`, 7 to 0 Days. B: **Count Distinct** of `amount`, same grouping and window. | | Conditions | Match AND: A **Greater Than Equal (>=)** 5, and B **Less Than Equal** 1 | | Check first | That **Count Distinct** on `amount` counts different amounts as expected. The typology type list includes “identical transactions”. | **P4 · Jump in average payment size** · *Proposed — not yet tested* | Red flag | A sender’s typical payment becomes much larger than their own usual size. | | --- | --- | | Variables | A: **Average** of `amount`, grouped by `sender_entity_id`, 7 to 0 Days. B: **Average** of `amount`, same grouping, 90 to 0 Days. | | Condition | A **Greater Than Equal (>=)** Variable B with **THAN MULTIPLIER** 3 | | Check first | That the multiplier accepts values above 1 (only 0.5 has been tested). Customers with a short history can alert easily. | **P5 · One device used by many customers** · *Proposed — not yet tested* | Red flag | Several customers send from the same device, a common sign of accounts controlled by one person (money mules). | | --- | --- | | Variable | **Count Distinct** of `sender_entity_id`, grouped by `sender_device_id`, 7 to 0 Days | | Condition | Variable **Greater Than Equal (>=)** 3 | | Check first | Which customer the alert is raised against when the variable is grouped by device rather than by customer. | **P6 · One IP address used by many customers** · *Proposed — not yet tested* | Red flag | Several customers send from the same network location. | | --- | --- | | Variable | **Count Distinct** of `sender_entity_id`, grouped by `sender_ip`, 7 to 0 Days | | Condition | Variable **Greater Than Equal (>=)** a value set from a dry run | | Check first | As P5. Shared networks (offices, mobile carriers) can put many legitimate customers behind one address. | **P7 · Payments to merchant categories you treat as high risk** · *Proposed — not yet tested* | Red flag | Spending with merchant types your policy flags, such as gambling or money services. | | --- | --- | | Variable | **Count** of `id`, grouped by `sender_entity_id`, 30 to 0 Days, filter `merchant_category_code` **In** your list of codes | | Condition | Variable **Greater Than Equal (>=)** a value you choose | | Check first | The format of `merchant_category_code` values in your data. | **P8 · Activity above the customer’s declared profile** · *Proposed — not yet tested* | Red flag | A customer sends far more in a month than the expected monthly spend recorded at onboarding. | | --- | --- | | Variables | A: an **Entity** variable on `expected_monthly_spend`. B: **Sum** of `amount`, grouped by `sender_entity_id`, 30 to 0 Days. | | Condition | B **Greater Than Equal (>=)** Variable A with **THAN MULTIPLIER** 2 | | Check first | Whether an Entity variable can be compared with a Transaction variable in one typology, and on which customer key. The Entity field list includes `expected_monthly_spend` and `expected_txn_frequency`. |
Related in Detection & Monitoring
Name ScreeningTransaction MonitoringData Ingestion