# 8. Transaction Monitoring Transaction Monitoring is where you build and run the rules that scan transactions for suspicious patterns. A rule is called a **typology**; it is made of conditions on reusable calculations called **variables**, and it runs on a **schedule**. Compliance analysts and rule owners use the three pages under the menu: **Typology**, **Variables** and **Schedules**.
For
Compliance analysts and rule owners
In the menu
Fyscal ARCX → Transaction Monitoring
Reading time
About 43 min
The main example in this chapter is the typology **High volume and Value outgoing Remittances** (**TMR-01072026-000463**). For ready-made rules you can build with the same screens, see the [Typology Library](#typology-library). ::: checks - **Typologies**: [Typology list](#s-8-1), [Filter and sort the list](#s-8-2), [Typology detail](#s-8-3), [Schedule Details](#s-8-4) and the [Create Typology form](#s-8-5). - **Variables**: [Variables list](#s-8-6), [View Variable](#s-8-7) and [Create a variable](#s-8-8). - **Schedules**: [Run History](#s-8-9) and [Schedule List](#s-8-10). - **Build a typology from scratch**: the [walkthrough](#s-8-11) in seven parts ([1](#s-8-12), [2](#s-8-13), [3](#s-8-14), [4](#s-8-15), [5](#s-8-16), [6](#s-8-17), [7](#s-8-18)), then [How conditions are evaluated](#s-8-19). ::: ## Typology list {#s-8-1} ::path[Fyscal ARCX → Transaction Monitoring → Typology] The **Transaction Monitoring Typologies** page lists every typology (rule) with its status and category. Start here to find a rule, open it, or create a new one. ::figure[The typology list searched for Remittance: search (1), Refresh (2), Show Filters (3), + New (4), a rule and its ID (5), status chips (6), typology type (7), the row menu (8) and the count (9)]{src="transaction-monitoring/01-typology-list.png" id="fig-transaction-monitoring-typology-list"} ::: legend 1. **Search by rule name and id**: type part of a rule name or a rule ID such as TMR-01072026-000463. Here “Remittance” finds 8 rules. 2. **Refresh**: reloads the list. 3. **Show Filters**: opens the filter bar (the button then reads **Hide Filters**). See [Filter and sort the list](#s-8-2). 4. **+ New**: opens **Create Typology** (see [Create Typology form](#s-8-5)). 5. **Rule**: the rule name, with its rule ID in a chip below it. The chip has a copy icon. 6. **Status**: Draft, Published or Shadow, with a run-state chip such as **Paused** or **Completed** beside it. 7. **Typologies**: the typology type chosen for the rule, or *No category* when none was chosen. 8. **Actions**: the ⋮ menu for the row. 9. Pagination: **Showing 1-8 of 8** and **Page 1 of 1**, with first, previous, next and last buttons. Without a search the list shows 10 rules per page. ::: | Column | What it shows | | --- | --- | | **Rule** | Rule name (long names are shortened with …) and rule ID, for example TMR-06102026-001090. | | **Status** | The rule's status chip: Draft, Published or Shadow. | | **Typologies** | The typology type, for example Anomaly, Structuring, Cardinality, Velocity, Large Transaction, SMURFING; *No category* if none. | | **Created** | Date and time the rule was created, for example 06 Oct 2026, 10:55:47 am. | | **Updated** | Date and time of the last change. | | **Actions** | ⋮ menu with row actions. | **Statuses and run state** | Value | Where it appears | Meaning as shown on screen | | --- | --- | --- | | **Draft** | Status | A saved rule that has not been activated. New rules are saved as Draft. | | **Shadow** | Status | Activated in Shadow Mode: “Alert generated against live data will be shown in rule detail page.” | | **Published** | Status | Activated in Published Mode: “Alert from this rule will flow into Alert Manager.” | | **Paused** | Chip beside the status, in the list and on the rule's page | The rule is not currently running; the page offers **Resume**. | | **Completed** | Chip beside the status, in the list | The rule's schedule has passed its **End Time**, so no further runs are planned. | ::: note Some Transaction Monitoring screens use other names than the rest of Fyscal ARCX. The breadcrumb of the typology pages reads **FT AML** → **Transaction Monitoring Typologies**, and the Variables page breadcrumb reads **Transaction Monitoring Rules**. The **Activation Mode** dialog describes Published Mode as “Alert from this rule will flow into Alert Manager.” This guide quotes those labels as they appear. ::: ::: note AML context A typology is a known pattern of money-laundering or terrorist-financing behaviour, such as structuring, rapid movement of funds or use of mule accounts, written as conditions that can be measured on transactions. Institutions usually set the thresholds from their own risk assessment, test a rule before it raises alerts, and review it periodically. ::: ## Filter and sort the list {#s-8-2} ::path[Fyscal ARCX → Transaction Monitoring → Typology → Show Filters] The filter bar has two filters and a sort control. ::: step Open the filter bar Click **Show Filters**. Three controls appear below the search box: **All Typologies** (1), **All Statuses** (2) and **Sort By** (3). The button now reads **Hide Filters** (4). ::figure[The filter bar: All Typologies (1), All Statuses (2) and Sort By (3), with Hide Filters (4)]{src="transaction-monitoring/02-typology-filters.png" id="fig-transaction-monitoring-typology-filters"} ::: ::: step Filter by typology type Open **All Typologies** (1) and choose a type from the list (2). The list shows the types in use, for example SMURFING, Mule Networks, Layering, High Value, High Value Transfer, Support, Structuring and identical transactions; some names appear twice because two types were created with the same name. Scroll the list with the arrow at the bottom (3) for more, such as Anomaly, Cardinality, Large Transaction and Velocity. ::figure[All Typologies (1) open: the list of typology types (2) and the scroll arrow (3)]{src="transaction-monitoring/03-typology-filter-typologies.png" id="fig-transaction-monitoring-typology-filter-typologies"} ::: ::: step Filter by status Open **All Statuses** (1) and choose **Draft**, **Published** or **Shadow** from the list (2). Choose **All Statuses** to clear the filter. ::figure[All Statuses (1) open: All Statuses, Draft, Published and Shadow (2)]{src="transaction-monitoring/04-typology-filter-status.png" id="fig-transaction-monitoring-typology-filter-status"} ::: ::: step Sort the list Open **Sort By** and choose **Newest First** (the default) or **Oldest First**. ::: ::: step Use the row menu Click ⋮ (2) in the **Actions** column. On a **Draft** rule (1) the **Actions** menu offers **Duplicate** (3), which makes a copy of the rule. ::figure[The Actions menu (2) on a Draft rule (1): Duplicate (3)]{src="transaction-monitoring/05-typology-row-menu.png" id="fig-transaction-monitoring-typology-row-menu"} ::: ## Typology detail {#s-8-3} ::path[Fyscal ARCX → Transaction Monitoring → Typology → (click a row)] Click a row to open the typology's page. It shows the rule read-only: its status, timing, condition groups and the variables it uses. The example below is a Published rule that is currently Paused. ::figure[Typology detail for High volume and Value outgoing Remittances (TMR-01072026-000463): Published, Paused, three condition groups and six variables]{src="transaction-monitoring/06-typology-detail.png" id="fig-transaction-monitoring-typology-detail"} ::: legend 1. Status chips (**Published**, **Paused**), the rule ID with a copy icon, and the description (here “No description provided.”). 2. Page actions: **Schedule Details** (the rule's run history, see [Schedule Details](#s-8-4)), **Duplicate Typology**, **Resume** (shown because the rule is paused) and **Timeline & Notes**. 3. **CREATED** and **UPDATED**: date, time and the user. 4. Summary strip: **EXECUTION PERIOD** (01 Jul 2026, 02:30:00 pm → 07 Jul 2026, 12:00:00 am), **INTERVAL** (Every 2 days), **COMPLEXITY** (Advanced), **SUPPRESSION** (2Day) and **TYPOLOGY** (Layering). 5. A condition group, with its number of conditions (**2 conditions**). Each row reads **WHEN** variable, operator, value. 6. **AND — all must match**: the link between conditions inside a group. 7. **OR — any one matches**: the link between groups. 8. **VARIABLES** with a count (6): one card per variable, showing its type, **WINDOW** and **GROUP**. ::: The three groups of the example read as follows. The rule alerts on a sender when any one group is fully true. | Group | Condition 1 | | Condition 2 | | --- | --- | --- | --- | | 1 | outgoing remittance 1 day vol **Greater Than Equal (>=)** 5 | AND | outgoing remittance 1 day sum **Greater Than Equal (>=)** 10000 | | 2 | outgoing remittance 14 day vol **Greater Than Equal (>=)** 5 | AND | outgoing remittance 14 day sum **Greater Than Equal (>=)** 20000 | | 3 | outgoing remittance 30 day vol **Greater Than Equal (>=)** 14 | AND | outgoing remittance 30 day sum **Greater Than Equal (>=)** 50000 | | Variable | Type | WINDOW | GROUP | | --- | --- | --- | --- | | outgoing remittance 30 day sum | Num\_agg\_sum | in last 30 day | `sender_entity_id` | | outgoing remittance 30 day vol | Str\_agg\_count\_distinct | in last 30 day | `sender_entity_id` | | outgoing remittance 14 day sum | Num\_agg\_sum | in last 14 day | `sender_entity_id` | | outgoing remittance 14 day vol | Str\_agg\_count\_distinct | in last 14 day | `sender_entity_id` | | outgoing remittance 1 day sum | Num\_agg\_sum | in last 1 day | `sender_entity_id` | | outgoing remittance 1 day vol | Str\_agg\_count\_distinct | in last 1 day | `sender_entity_id` | ::: step See how a variable is calculated Click a variable card. A popup shows the variable's name, its type (1), a **DESCRIPTION** (2) of the calculation, its **WINDOW** (3) and its **GROUP** (4). For **outgoing remittance 30 day sum** the description reads *NUM\_AGG\_SUM(amount), type STR\_EQ REMITTANCE, grouped by sender\_entity\_id, window: (now() - INTERVAL 30 DAY, now())*: the sum of `amount` for transactions whose type equals REMITTANCE, per sender, over the last 30 days. Click × (5) to close. ::figure[Variable popup for outgoing remittance 30 day sum: type (1), description (2), window (3), group (4) and close (5)]{src="transaction-monitoring/07-typology-variable-popup.png" id="fig-transaction-monitoring-typology-variable-popup"} ::: ::: step Read or add notes Click **Timeline & Notes**. The **Activity Timeline** panel opens with the rule ID, an **ADD A NOTE** box (1), **Attach File** (2) and **Add note** (3). Events for the rule are listed below (4); for this rule the panel shows *No activity found.* Click × (5) to close. ::figure[Activity Timeline for TMR-01072026-000463: note box (1), Attach File (2), Add note (3), events (4) and close (5)]{src="transaction-monitoring/08-typology-timeline-notes.png" id="fig-transaction-monitoring-typology-timeline-notes"} ::: ::: note The buttons at the top depend on the rule's state. On this Paused, Published rule they are **Schedule Details**, **Duplicate Typology**, **Resume** and **Timeline & Notes**. A Draft rule's page offers **Delete**, **Update**, **Duplicate Typology**, **Activate** and **Timeline & Notes**. The condition fields are read-only on this page. ::: ## Schedule Details (a typology's run history) {#s-8-4} ::path[Fyscal ARCX → Transaction Monitoring → Typology → (rule) → Schedule Details] **Schedule Details** lists every run of one typology. The breadcrumb links back to the list and to the rule. ::figure[Schedule Details for High volume and Value outgoing Remittances: run totals and one completed live run]{src="transaction-monitoring/09-typology-schedule-details.png" id="fig-transaction-monitoring-typology-schedule-details"} ::: legend 1. Totals: **TOTAL**, **COMPLETED**, **FAILED** and **RUNNING** runs (1, 1, 0, 0 here). The rule's status (**PUBLISHED**) is shown above its name. 2. **Refresh**, the run count (**1-1 of 1 runs**) and **Show Filters**. 3. The runs table. ::: | Column | What it shows | Example | | --- | --- | --- | | **Run ID** | Identifier of the run | Run 10037 | | **Records Scanned** | Records the run read | 0 | | **Alerts Generated** | Alerts the run raised | 0 | | **Started At** / **Ended At** | Start and end date and time | 01 Jul 2026, 02:30:00 pm / 02:30:53 pm | | **Run Type** | How the rule ran | Live | | **Status** | Outcome of the run | Completed | | **Duration (sec)** | Run length | 53.0s | ::: note A run with **Records Scanned** 0 had no transaction data to read in its window. Check data ingestion for that period before judging the rule. ::: ## Create Typology form {#s-8-5} ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] **+ New** opens **Create Typology**. The first page holds the rule's details and its conditions; **Next Step** goes to the schedule page ([Part 5 of the walkthrough](#s-8-16)). ::figure[Create Typology, first page: details, Combine groups with, Group 1 and its first condition row]{src="transaction-monitoring/10-typology-create-form.png" id="fig-transaction-monitoring-typology-create-form"} ::: legend 1. **+ Variable**: creates a variable without leaving the form (opens **Create Variables**). 2. **Typology Name** (required). 3. **Typology type** (optional). 4. **Suppression Window**: a number and a unit. 5. **Description**. 6. **Combine groups with**: **AND** or **OR**. 7. **Match**: **AND** or **OR** for the conditions inside this group. 8. A condition row: **WHEN**, field, operator, value type and value. 9. **Add Condition**: adds a row to this group. 10. **Add Group**: adds another group. 11. **Cancel** and **Next Step**. **Next Step** stays greyed out until the required details and conditions are complete. ::: | Field | What it expects | Required | Options or format | | --- | --- | --- | --- | | **Typology Name** | The rule's name as it will appear in the list | Yes (\*) | Free text | | **Typology type** | The category the rule is filed under; it is what the **All Typologies** filter uses | No (optional) | **Select typology type**; each type shows a short code, for example Structuring (TP100), Anomaly (TP103), Large Transaction (LT-01). The chosen type shows as a chip with ×. | | **Suppression Window** | A time period set on the rule. An information icon (ⓘ) next to the label holds the field's help text. | No | A number (default 0) and a unit (default **Hour**; Day is also used, for example 30 Day) | | **Description** | What the rule monitors and why | No | Free text; placeholder “Describe what this rule is monitoring and why” | | **Combine groups with** | How groups combine | — | **AND** (default) or **OR** | | Group **Match** | How conditions inside the group combine | — | **AND** (default) or **OR** | | **WHEN** field | The variable to test | Yes | **Select field**: lists your variables | | Operator | The comparison | Yes | **Select operator** (greyed until a field is chosen). Twelve operators, from Equal to Is Not Null; the full list is in the [Part 3 field reference](#s-8-14). | | Value type | What the field is compared with | Yes | **Static Value** (default) or **Variable**; a third entry, **Ingested Data**, is shown greyed out | | Value | The threshold | Yes | With **Static Value**: a number in **Enter value**. With **Variable**: a variable picker and a **THAN MULTIPLIER** box. | With **Variable** as the value type, the condition compares two variables, scaled by the multiplier. For example, in [Rule 9 of the Typology Library](#s-9-r9) the condition `sent_sum_7d_spike` **Greater Than Equal (>=)** Variable `sent_sum_90d` with **THAN MULTIPLIER** 0.5 means “the 7-day total is at least 0.5 × the 90-day total”. The rule page shows the compared variable as “sent\_sum\_90d (multiplied by 0.5)”. When a group has more than one condition, the form shows **AND — all must match** or **OR — any one matches** between rows, following the group's **Match** setting. The same labels appear between groups, following **Combine groups with**. Each extra group has a **Remove** button and each extra row an ×. A worked example is in [How conditions are evaluated](#s-8-19). ## Variables list {#s-8-6} ::path[Fyscal ARCX → Transaction Monitoring → Variables] A variable is a named calculation, such as the number of transactions a sender made in the last 7 days. Typology conditions test variables, and one variable can be used by many typologies. The **Variables** page lists them all. ::figure[The Variables list searched for sender\_txn: search (1), Refresh (2), Show Filters (3), + New (4), a variable name (5) and ID (6), and the count (7)]{src="transaction-monitoring/11-variables-list.png" id="fig-transaction-monitoring-variables-list"} ::: legend 1. Search box (*variable name*). Here “sender\_txn” finds 21 variables; the search also shows as a **Search:** chip with **RESET FILTERS** below the box. 2. **Refresh**. 3. **Show Filters**. 4. **+ New**: opens **Create Variables**. 5. **Variable Name / Variable ID**: the name, for example `sender_txn_sum_365d`, and its ID, for example VAR-06102026-000735. 6. The Variable ID chip, with a copy icon. 7. Pagination (**Showing 1-10 of 21**, **Page 1 of 3**). ::: | Column | What it shows | | --- | --- | | **Variable Name / Variable ID** | Name and VAR- identifier | | **Created** | Date and time created | | **Updated** | Date and time last changed | Variable names in the product follow a pattern of subject, measure and window, for example `sender_txn_count_7d`, `sender_txn_sum_90d`, `sender_txn_max_amount_7d`, `sender_txn_avg_amount_5d`. Use the same pattern so variables are easy to find and reuse. ::: step Sort the list Click **Show Filters**. A single **Sort By** control (1) appears (placeholder **Select Sort By**), and the button reads **Hide Filters** (2). ::figure[Variables with filters shown: Sort By (1) and Hide Filters (2)]{src="transaction-monitoring/12-variables-sort-by.png" id="fig-transaction-monitoring-variables-sort-by"} ::: ## View Variable {#s-8-7} ::path[Fyscal ARCX → Transaction Monitoring → Variables → (click a row)] Click a variable to open **View Variable**. It shows the variable's definition and every rule that uses it. ::figure[View Variable for sender\_txn\_count\_7d (NUM\_AGG\_COUNT): used in two rules, so it cannot be edited]{src="transaction-monitoring/13-variable-view.png" id="fig-transaction-monitoring-variable-view"} ::: legend 1. The variable type tag, here **NUM\_AGG\_COUNT**. 2. **CREATED** and **UPDATED**, with date, time and user. 3. **Used in:** each typology that uses the variable, as a link. Here: Banking- Structured Transactions 3K to 5K (1 Week), and the walkthrough's rule GUIDE EXAMPLE - Velocity (see [Build a typology from scratch](#s-8-11)). 4. **Note**: “Variables that are already live in existing rules cannot be edited”. 5. **Edit**, **Delete** and **Duplicate**. For this variable **Edit** and **Delete** are greyed out; **Duplicate** is available. 6. **Transaction** / **Entity**. 7. **Aggregation**: **Field** (`amount`), **Function** (Count), **Group by** (`sender_entity_id`). 8. **Time Window** (scroll down for the window and **Filters**). 9. **Update Variable** (greyed out). ::: ::: note A variable that is used in a live rule cannot be changed in place. To change the calculation, click **Duplicate**, adjust the copy, save it under a new name, and point the rule at the new variable. ::: ## Create a variable {#s-8-8} ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] **+ New** on the Variables page, or **+ Variable** on Create Typology, opens **Create Variables**. ::figure[Create Variables: the empty form, with Select an existing variable on the left and Configure Variable on the right]{src="transaction-monitoring/14-variable-create-form.png" id="fig-transaction-monitoring-variable-create-form"} ::: legend 1. **Select an existing variable**: pick a variable that already exists instead of creating a duplicate. 2. **Transaction** / **Entity**: whether the calculation is on transactions or entity data. 3. **Variable name** (required; placeholder “e.g. total\_outgoing”). 4. **Description** (optional internal note). 5. **Aggregation**: **Field**, **Function** and **Group by**, all required. 6. **Time Window**, with **Filters** below it. 7. **Save Variable**. ::: | Field | What it expects | Required | Options or format | | --- | --- | --- | --- | | **Transaction** / **Entity** | Data the variable is calculated from | — | Two tabs; **Transaction** is selected by default | | **Variable name** | Unique name | Yes (\*) | Free text, for example `sender_txn_sum_90d` | | **Description** | Internal note | No | Free text | | **Field** | The data field to calculate on | Yes (\*) | Dropdown (placeholder Field/amount), for example `amount`, `receiver_amount` | | **Function** | The calculation | Yes (\*) | Depends on the field. A numeric field such as `amount` offers **Count**, **Count Distinct**, **Sum**, **Average**, **Minimum**, **Maximum**. An ID or text field such as `id` or `receiver_entity_id` offers only **Count**, **Count Distinct**, **Minimum**, **Maximum**. The variable's type tag follows the field and function, for example NUM\_AGG\_SUM, NUM\_AGG\_COUNT, STR\_AGG\_COUNT, STR\_AGG\_COUNT\_DISTINCT. | | **Group by** | Calculate separately for each value of this field | Yes (\*) | Dropdown, for example `sender_entity_id` (one result per sender) | | **Time Window** unit | Unit of the window | — | **Hours**, **Days**, **Weeks**, **Months**, **Years** | | **Analyze Transaction from** … **to** … ago | Start and end of the window, counted back from the trigger time | — | Two number boxes followed by the unit and “ago”, for example from 90 to 0 Days ago | | **Filters** (optional) | Restricts the calculation to matching transactions | No | **Add Filter** adds a row: **Field**, an operator (**Select field first**), a value, and **Static** or **Dynamic**. The heading counts the rows, for example **Filters (1)**. | Below the window boxes the form draws a timeline labelled, for example, **0 days ago** and **Triggered at T (00:00)**, with the sentence “This variable will be triggered time 00:00:00 on day T.” The window is measured back from T. The second box is the end of the window: **0** ends the window at T, so *from 90 to 0 Days ago* is the last 90 days. The end can also be above 0: *from 100 to 1 Days ago* covers the 100 days up to one day before T, and the form's timeline then reads **1 day ago**. The variable card on a typology page shows only the start (“in last 100 day”), so check the end on **View Variable**. The [Typology Library's building blocks](#s-9-1) draw the windows side by side. Filters are how a variable counts only some transactions. The variable **outgoing remittance 30 day sum** in the main example is a Sum of `amount` with a filter on type equal to REMITTANCE (its description reads *type STR\_EQ REMITTANCE*). ## Schedules: Run History {#s-8-9} ::path[Fyscal ARCX → Transaction Monitoring → Schedules → Run History] A schedule sets when rules run: a name, an execution interval, a start time and an optional end time. One schedule can drive several rules. The **Schedules** page has two views, **Run History** and **Schedule List**. **Run History** logs every run of every schedule. ::figure[Schedules, Run History view, with the Run Status filter open]{src="transaction-monitoring/15-schedules-run-history.png" id="fig-transaction-monitoring-schedules-run-history"} ::: legend 1. View switch: **Run History** / **Schedule List**. 2. Search (*Schedule Name, Schedule ID*). 3. **Run Status** filter: **All**, **Running**, **Completed**, **Partially Failed**, **Failed**. 4. **Sort By**: **Newest first** by default. 5. **Live Alerts**: alerts raised by Published rules in the run. 6. **Shadow Alerts**: alerts raised by Shadow rules in the run (for example 504 for Every\_Quarter, 19 for Migrated legacy schedule 297). 7. **Run Status** of each run. ::: | Column | What it shows | | --- | --- | | **Schedule Name / Schedule ID** | Schedule name and SCH- identifier | | **Live Alerts** | Alerts from Published rules in this run | | **Shadow Alerts** | Alerts from Shadow rules in this run | | **Start Time** / **End Time** | When the run started and ended | | **Duration** | Run length, for example 3.75s | | **Run Status** | Running, Completed, Partially Failed or Failed | ::: tip To see the runs of one rule, use [Schedule Details](#s-8-4) on the rule's page. ::: ## Schedules: Schedule List {#s-8-10} ::path[Fyscal ARCX → Transaction Monitoring → Schedules → Schedule List] **Schedule List** shows every schedule and how many rules use it. Schedules are created from the Create Typology schedule page ([Part 5 of the walkthrough](#s-8-16)); this page has no create button. ::figure[Schedule List searched for Every: view switch (1), search (2), Sort By (3), Last Executed (4), Rules Linked (5) and Status (6)]{src="transaction-monitoring/16-schedules-list.png" id="fig-transaction-monitoring-schedules-list"} ::: legend 1. View switch. 2. Search (*Schedule Name*). Here “Every” finds 12 schedules. 3. **Sort By** (shows **All**). 4. **Last Executed**: date and time of the last run, or — if it has not run. 5. **Rules Linked**: how many rules reference the schedule (Every\_day: 22). 6. **Status**: **Active**, **Inactive**, or **Completed** once the schedule has passed its End Time. ::: ::: step Open a schedule Click a row. The **View** dialog shows the schedule's ID (1), **CREATED BY** (2), **Edit** (3) and the **Schedule** fields (4): **Name**, **Execution Interval** (a number and a unit), **Start Time** and **End Time (optional)**, followed by a summary sentence (5) such as “This rule will run every 1 day starting 07 Oct 2026, 12:00:00 am”. **Live in:** (6) names the active rule the schedule drives, or “Not used in any active rule”. **Used in:** (7) lists every rule that references it, each as a link. ::figure[View Every\_day: ID (1), CREATED BY (2), Edit (3), schedule fields (4), summary (5), Live in (6) and Used in (7)]{src="transaction-monitoring/17-schedule-view.png" id="fig-transaction-monitoring-schedule-view"} ::: ::: step Edit a schedule Click **Edit** (3) in the dialog to change the fields. ::: ::: note A schedule can be linked to many rules (Every\_day is used in 22). A change to its interval or times applies to every rule in its **Used in** list, so check that list before you edit. ::: ## Build a typology from scratch: walkthrough {#s-8-11} ::path[Fyscal ARCX → Transaction Monitoring → Variables / Typology]
Where
Transaction Monitoring → Variables and Typology
Saved as
A Draft rule
Maker Checker
Yes, for activation (Part 7)
Output
An Activate Typology request, Pending a checker
This walkthrough builds a complete rule, screen by screen, from a new variable to a saved draft. The worked example is a Velocity rule: **flag a sender who makes 3 or more outgoing transactions totalling ₱5,000 or more within 7 days**. Follow the parts in order; each step is one action, and the figure under it shows the screen after that action. | Part | Screen | What you do | | --- | --- | --- | | [1](#s-8-12) | — | Plan the rule: the variables, conditions, type, suppression and schedule it needs | | [2](#s-8-13) | Variables → **Create Variables** | Create the 7-day sum variable | | [3](#s-8-14) | Typology → **Create Typology** | Name the rule, choose its type, set suppression and a description | | [4](#s-8-15) | **Create Typology**, conditions | Add the two conditions in Group 1 | | [5](#s-8-16) | **Review & schedule rule** | Choose an existing schedule or create a new one | | [6](#s-8-17) | **Review & schedule rule** → **Update Typology** | Save the rule as a Draft and check it | | [7](#s-8-18) | Dry run, **Activate**, Maker Checker Approval | Test the rule and request activation |
  1. Create variablesField, Function, Group by, Time Window, Filters
  2. Create TypologyDetails, then conditions in groups
  3. Choose a scheduleExisting or + New; start in the future
  4. Save as DraftStatus Draft; page becomes Update Typology
  5. Dry RunCounts on past records; no alerts created
  6. ActivateActivation Mode, then Submit Request
Diagram 8.1 — Building a typology, from variable to activation request
Diagram 8.1 shows the order the screens impose. A typology's conditions can only pick variables that already exist, so variables come first. **Save as Draft** needs a schedule, and **Dry Run** needs a saved draft. **Activate** does not switch the rule on: it sends a request to Maker Checker Approval (Diagram 8.2 in Part 7). ::: note In the screenshots the example objects carry a *GUIDE EXAMPLE* prefix so they are easy to find on the test system: the rule is named **GUIDE EXAMPLE - Velocity 3 or more outgoing transactions totalling PHP 5000 in 7 days**, the new variable `guide_example_sender_txn_sum_7d` and the new schedule `guide_example_schedule`. The steps below give the values without the prefix. Use your own names. ::: ## Part 1: Plan the rule {#s-8-12} Before you open a form, write the rule down as variables and conditions. A **variable** calculates one number per sender; a **condition** compares that number with a threshold. The example needs two numbers per sender over the last 7 days: how many transactions they sent, and the total amount they sent. | Item | Value in the example | Where you set it | | --- | --- | --- | | Count of transactions per sender, last 7 days | Variable `sender_txn_count_7d`: **Field** `amount`, **Function** Count, **Group by** `sender_entity_id`, window 7 days. It already exists, so it is reused. | [View Variable](#s-8-7) ([](#fig-transaction-monitoring-variable-view)) | | Total amount per sender, last 7 days | New variable `sender_txn_sum_7d`: **Field** `amount`, **Function** Sum, **Group by** `sender_entity_id`, from 7 to 0 Days ago, no filters | Part 2 | | Condition 1 | `sender_txn_count_7d` **Greater Than Equal (>=)** 3 | Part 4 | | Condition 2 | `sender_txn_sum_7d` **Greater Than Equal (>=)** 5000 | Part 4 | | How the conditions combine | Both in Group 1, **Match** **AND** (both must be true) | Part 4 | | Typology type | Velocity (V-01) | Part 3 | | Suppression Window | 7 Day | Part 3 | | Schedule | Every 1 Day, starting at 09:00 AM on a future date, no end time | Part 5 | Check for variables you can reuse before creating new ones: open **Select an existing variable** in **Create Variables**, or search the [Variables list](#s-8-6). Here the count variable exists and the 7-day sum does not, so Part 2 creates only the sum. ## Part 2: Create the variable {#s-8-13} ::path[Fyscal ARCX → Transaction Monitoring → Variables → + New] ::: step Open Create Variables Go to **Transaction Monitoring → Variables** and click **+ New** (1) at the top right. ::figure[+ New (1), at the top right of the Variables page, opens Create Variables]{src="transaction-monitoring/18-walk-variables-new.png" id="fig-transaction-monitoring-walk-variables-new"} ::: ::: step Read the empty form The **Create Variables** dialog opens. **Select an existing variable** (1) is on the left; **Configure Variable** is on the right, with **Transaction** / **Entity** (2), **Variable name** (3), **Description** (4), **Field** (5), **Function** (6), **Group by** (7) and **Time Window** (8) further down. **Function** stays greyed out until you choose a **Field**, and **Save Variable** (9) stays greyed out until the required fields are filled. ::figure[Create Variables, empty: Select an existing variable (1), Transaction / Entity (2), Variable name (3), Description (4), Field (5), Function (6), Group by (7), Time Window (8) and Save Variable (9)]{src="transaction-monitoring/19-walk-variable-form.png" id="fig-transaction-monitoring-walk-variable-form"} ::: ::: step Name and describe the variable Leave **Transaction** (1) selected. In **Variable name** (2) type `sender_txn_sum_7d`. In **Description** (3) type a note such as “Total amount sent per sender over the last 7 days.” ::figure[Transaction selected (1), Variable name (2) and Description (3) filled in]{src="transaction-monitoring/20-walk-variable-name.png" id="fig-transaction-monitoring-walk-variable-name"} ::: ::: step Choose the Field Open **Field** (1) (placeholder **Field/amount**). The list has a **Search Fields** box (2) and the 51 transaction fields. Choose `amount` (3). ::figure[The Field list (1) open: Search Fields (2) and amount (3) at the top]{src="transaction-monitoring/21-walk-variable-field.png" id="fig-transaction-monitoring-walk-variable-field"} ::: ::: step Choose the Function With **Field** set to `amount` (1), open **Function** (2), now available. The options are **Count**, **Count Distinct**, **Sum**, **Average**, **Minimum** and **Maximum**. Choose **Sum** (3). ::figure[Field amount (1); the Function list (2): Count, Count Distinct, Sum (3), Average, Minimum, Maximum]{src="transaction-monitoring/22-walk-variable-function.png" id="fig-transaction-monitoring-walk-variable-function"} ::: ::: step Choose Group by Open **Group by** (1). It lists the same fields as **Field** without `amount`. Type `sender_entity` in **Search Fields** (2): two fields remain, `sender_entity_id` and `sender_entity_name`. Choose `sender_entity_id` (3), so the sum is calculated separately for each sender. ::figure[Group by (1) searched for sender\_entity (2): choose sender\_entity\_id (3)]{src="transaction-monitoring/23-walk-variable-groupby.png" id="fig-transaction-monitoring-walk-variable-groupby"} ::: ::: step Set the time window 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. The form starts with one blank filter row under **Filters (1)** (3). Leave it empty: this variable sums every transaction the sender made. The blank row is dropped when you save. ::figure[Time Window: Days (1), from 7 to 0 Days ago (2); the blank filter row (3); Save Variable (4)]{src="transaction-monitoring/24-walk-variable-window.png" id="fig-transaction-monitoring-walk-variable-window"} ::: ::: step Save the variable Click **Save Variable** (4 in [](#fig-transaction-monitoring-walk-variable-window)). The button shows **Saving...** and the fields grey out. The dialog then closes, and the new variable is the first row of the list with its ID, here VAR-07102026-000736. No confirmation message is shown. To find it again later, type its name in the search box (1): the row shows the name (2) and the Variable ID (3). ::figure[The saved variable found by name (1): its name (2) and Variable ID (3)]{src="transaction-monitoring/25-walk-variable-saved.png" id="fig-transaction-monitoring-walk-variable-saved"} ::: ::: step Check the saved variable Click the row to open **View Variable**. The type tag (1) reads **NUM\_AGG\_SUM**, and the form shows `amount`, **Sum** and `sender_entity_id`. **CREATED** and **UPDATED** (2) show the date and time and the user. **Edit**, **Delete** and **Duplicate** (3) are at the top of **Configure Variable**; **Update Variable** (4) is greyed out. Scroll down ([](#fig-transaction-monitoring-walk-variable-filters)): **Days** (1) is selected, the window reads 7 to 0 **Days** ago (2) and the heading reads **Filters (0)** (3). Close the dialog with ×. ::figure[View Variable for the new variable: type tag (1), created and updated (2), Edit, Delete and Duplicate (3), Update Variable (4)]{src="transaction-monitoring/26-walk-variable-view.png" id="fig-transaction-monitoring-walk-variable-view"} ::figure[View Variable, lower part: Days (1), 7 to 0 Days ago (2) and Filters (0) (3)]{src="transaction-monitoring/27-walk-variable-filters.png" id="fig-transaction-monitoring-walk-variable-filters"} ::: **Create Variables: field reference** | Field | Required | What to enter / options | | --- | --- | --- | | **Select an existing variable** | No | Opens a list of existing variables. Use it to check whether the calculation already exists. | | **Transaction** / **Entity** | — | Two tabs. **Transaction** is selected by default. The example uses **Transaction**. | | **Variable name** | Yes (\*) | Free text; placeholder “e.g. total\_outgoing”. Example: `sender_txn_sum_7d`. | | **Description** | No | Free text; placeholder “Optional internal note”. It is shown on the variable card on the typology page ([](#fig-transaction-monitoring-walk-draft-detail)). | | **Field** | Yes (\*) | A searchable list of 51 transaction fields (listed below). Example: `amount`. | | **Function** | Yes (\*) | **Count**, **Count Distinct**, **Sum**, **Average**, **Minimum**, **Maximum**. Greyed out until a **Field** is chosen. Example: **Sum**. | | **Group by** | Yes (\*) | A searchable list: the same fields as **Field**, without `amount`. Example: `sender_entity_id`. | | **Time Window** unit | — | Buttons: **Hours** (default), **Days**, **Weeks**, **Months**, **Years**. Example: **Days**. | | **Analyze Transaction from** … **to** … ago | — | Two numbers, counted back from the trigger time T. The empty form shows 10 and 0. Example: 7 and 0. | | **Filters** (optional) | No | One blank row at the start: **Field**, an operator (**Select field first**), **Enter value**, and **Static** / **Dynamic**. **Add Filter** adds rows; the bin icon removes one. A blank row is not saved. Example: none. | The 51 fields offered under **Field** are: `amount`, `category`, `channel`, `check_number`, `currency_code`, `custom_data.`, `id`, `ingested_at`, `merchant_category_code`, `mode_of_transaction`, `occurred_at`, `orig_currency_amount`, `orig_currency_code`, `product_type`, `purpose_of_remittance`, `receiver_address`, `receiver_amount`, `receiver_bank_city_code`, `receiver_bank_swift_code`, `receiver_currency_code`, `receiver_device_id`, `receiver_entity_id`, `receiver_entity_name`, `receiver_geo_coordinates.latitude`, `receiver_geo_coordinates.longitude`, `receiver_instrument_id`, `receiver_instrument_subtype`, `receiver_instrument_type`, `receiver_ip`, `receiver_provider_country`, `receiver_provider_name`, `regulatory_transaction_code`, `remarks`, `sender_address`, `sender_amount`, `sender_bank_city_code`, `sender_bank_swift_code`, `sender_currency_code`, `sender_device_id`, `sender_entity_id`, `sender_entity_name`, `sender_geo_coordinates.latitude`, `sender_geo_coordinates.longitude`, `sender_instrument_id`, `sender_instrument_subtype`, `sender_instrument_type`, `sender_ip`, `sender_provider_country`, `sender_provider_name`, `status`, `type`. ## Part 3: Create the typology {#s-8-14} ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New] ::: step Open Create Typology Go to **Transaction Monitoring → Typology** and click **+ New** (1). ::figure[+ New (1), at the top right of the Typologies page, opens Create Typology]{src="transaction-monitoring/28-walk-typology-new.png" id="fig-transaction-monitoring-walk-typology-new"} ::: ::: step Read the details card **Create Typology** opens on its first page. The top card holds **Typology Name** (2), **Typology type** (3), **Suppression Window** (4) and **Description** (5). **+ Variable** (1) creates a variable without leaving the form. The conditions are below the card (Part 4). The page has no **Save as Draft** button: you save on the next page. ::figure[Create Typology, empty details card: + Variable (1), Typology Name (2), Typology type (3), Suppression Window (4), Description (5)]{src="transaction-monitoring/29-walk-typology-form.png" id="fig-transaction-monitoring-walk-typology-form"} ::: ::: step Enter the name In **Typology Name** type **Velocity 3 or more outgoing transactions totalling PHP 5000 in 7 days**. A name may contain only letters, digits, spaces, hyphens, underscores and parentheses. Any other character turns the field red (1) with the message (2) “Rule name can only include letters, digits, spaces, hyphens, underscores, and parentheses”. The name in [](#fig-transaction-monitoring-walk-typology-name-rule) contains a colon, a plus sign, commas, an en dash and ₱, none of which is in that list. That is why the example name spells the amount as “PHP 5000”. ::figure[A name with characters outside the allowed set (1), and the validation message (2)]{src="transaction-monitoring/30-walk-typology-name-rule.png" id="fig-transaction-monitoring-walk-typology-name-rule"} ::: ::: step Open Typology type Open **Typology type** (1) (marked optional). The list has a **Search typology type** box (2) and shows each type with its code (3): SMURFING (TP01), Mule Networks (ML01), Layering (LA01), High Value (HV01), High Value Transfer (HV02), High Value (HV03), Support (TP00), Structuring (TP100), identical transactions (TP101), identical transactions (TP102), Anomaly (TP103), banking threshhold (TP104), Cardinality (C-01), Large Transaction (LT-01), Velocity (V-01), Transactions (T-01) and Anamoly (A01). The list ends with **+ New**. ::figure[The Typology type list (1), with its search box (2) and each type with its code (3)]{src="transaction-monitoring/31-walk-typology-type-list.png" id="fig-transaction-monitoring-walk-typology-type-list"} ::: ::: step Choose Velocity Type `Velo` in the search box (1). Only **Velocity** (V-01) (2) remains. Click it. It appears in the field as a chip, **Velocity (V-01)**, with × to remove it. ::figure[Typology type searched for Velo (1): Velocity, V-01 (2)]{src="transaction-monitoring/32-walk-typology-type-velocity.png" id="fig-transaction-monitoring-walk-typology-type-velocity"} ::: ::: step Set the suppression window In **Suppression Window** type **7** in the number box (2) (default 0). Open the unit list (3) (default **Hour**): **Hour**, **Day**, **Week**, **Month**, **Year**. Choose **Day** (4). The **Velocity (V-01)** chip (1) is in **Typology type** above. The example uses the same length as the variables' 7-day window (see [Create Typology form](#s-8-5)). ::figure[The Velocity (V-01) chip (1); Suppression Window 7 (2) and the unit list (3): Hour, Day (4), Week, Month, Year]{src="transaction-monitoring/33-walk-typology-suppression.png" id="fig-transaction-monitoring-walk-typology-suppression"} ::: ::: step Write the description In **Description** (placeholder “Describe what this rule is monitoring and why”) state the rule in words, for example “Flags a sender with 3 or more outgoing transactions totalling ₱5,000 or more within 7 days.” The description is shown under the rule ID on the typology page. The completed card is shown in [](#fig-transaction-monitoring-walk-typology-complete). ::: **Create Typology, details: field reference** | Field | Required | What to enter / options | | --- | --- | --- | | **Typology Name** | Yes (\*) | 3 to 100 characters (a longer name is rejected after **Next Step** with “Rule name must be 3-100 characters”). Letters, digits, spaces, hyphens, underscores and parentheses only. Placeholder “This is true, please proceed”. Example: Velocity 3 or more outgoing transactions totalling PHP 5000 in 7 days. | | **Typology type** | No (optional) | A searchable list of types with codes (see step 4); the choice shows as a chip with ×. Example: Velocity (V-01). | | **Suppression Window** | No | A number (default 0) and a unit: **Hour** (default), **Day**, **Week**, **Month**, **Year**. Example: 7 Day. | | **Description** | No | Free text. Example: what the rule flags and why. | | **Combine groups with** | — | **AND** (default) or **OR**. Applies when there is more than one group. | | Group **Match** | — | **AND** (default) or **OR**, for the conditions inside the group. Example: **AND**. | | **WHEN** field | Yes | **Select field**: a searchable list headed **VARIABLES**, newest first. | | Operator | Yes | **Select operator**, greyed out until a field is chosen: **Equal**, **Not Equal**, **Greater Than**, **Greater Than Equal**, **Less Than**, **Less Than Equal**, **Between**, **Not Between**, **In**, **Not In**, **Is Null**, **Is Not Null**. | | Compare to | Yes | **Static Value** (default) or **Variable**. A third entry, **Ingested Data**, is shown greyed out. | | Value | Yes | With **Static Value**: a number in **Enter value** (greyed out until an operator is chosen). | ## Part 4: Add the conditions {#s-8-15} ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New (conditions)] Below the details card, **Combine groups with** is set to **AND** and **Group 1** has one empty row with **Match** set to **AND**. The example uses one group, so leave both settings as they are. ::: step Open the field picker in row 1 In Group 1 click **Select field** (1) next to **WHEN**. A list opens with a **Search..** box (2) and the heading **VARIABLES** (3); the newest variable is first. Type part of a name to narrow the list, for example `sender_txn`. ::figure[Group 1, row 1: Select field (1), the Search.. box (2) and the VARIABLES list (3), narrowed to sender\_txn]{src="transaction-monitoring/34-walk-condition-field.png" id="fig-transaction-monitoring-walk-condition-field"} ::: ::: step Choose the count variable Type `sender_txn_count_7d` in the search box (1). One match remains (2). Click it. ::figure[The variable list searched for sender\_txn\_count\_7d (1): one match (2)]{src="transaction-monitoring/35-walk-condition-search.png" id="fig-transaction-monitoring-walk-condition-search"} ::: ::: step Choose the operator With the variable chosen (1), open **Select operator** (2), now available. The list shows **Equal**, **Not Equal**, **Greater Than**, **Greater Than Equal**, **Less Than** and **Less Than Equal**; scroll for **Between**, **Not Between**, **In**, **Not In**, **Is Null** and **Is Not Null**. Choose **Greater Than Equal** (3). The field then reads **Greater Than Equal (>=)**, shortened to “Greater Than Equal (>...” in the row. ::figure[Row 1: the variable (1) and the operator list (2): choose Greater Than Equal (3)]{src="transaction-monitoring/36-walk-condition-operator.png" id="fig-transaction-monitoring-walk-condition-operator"} ::: ::: step Keep Static Value Open the compare-to list (1). It offers **Static Value** (2) (selected) and **Variable** (3); **Ingested Data** (4) is greyed out. Keep **Static Value**, because the threshold is a fixed number. ::figure[The compare-to list (1): Static Value (2), Variable (3), and Ingested Data (4) greyed out]{src="transaction-monitoring/37-walk-condition-compare.png" id="fig-transaction-monitoring-walk-condition-compare"} ::: ::: step Enter the threshold In **Enter value** type **3**. Row 1 is complete: the variable (1), **Greater Than Equal** (2), **Static Value** (3) and 3 (4). **Next Step** (5) becomes available. ::figure[Row 1 complete: sender\_txn\_count\_7d (1), Greater Than Equal (2), Static Value (3), 3 (4); Next Step available (5)]{src="transaction-monitoring/38-walk-condition-row1.png" id="fig-transaction-monitoring-walk-condition-row1"} ::: ::: step Add the second row Click **Add Condition**. A second **WHEN** row appears, the group heading changes to **2 conditions** (1), and the label **AND — all must match** (2) appears between the rows. Click **Select field** (3) in row 2, type the name of the variable from Part 2 in the search box (4) (the screenshot searches for `guide_example_sender`) and click it (5). ::figure[Row 2 added: 2 conditions (1), the AND — all must match label (2), Select field (3), the search (4) and the variable from Part 2 (5)]{src="transaction-monitoring/39-walk-condition-row2.png" id="fig-transaction-monitoring-walk-condition-row2"} ::: ::: step Complete row 2 Choose **Greater Than Equal** from the same operator list as in step 3, keep **Static Value**, and type **5000** in **Enter value**. ::: ::: step Check the whole form The first page is complete: name (1), **Velocity (V-01)** (2), **Suppression Window** 7 **Day** (3), description (4), Group 1 with **Match** **AND** (5), row 1 (6) and row 2 (7). Each extra row has an × to remove it. Click **Next Step** (8). ::figure[Create Typology, first page complete: name (1), Velocity (2), Suppression Window (3), description (4), Group 1 (5), row 1 (6), row 2 (7) and Next Step (8)]{src="transaction-monitoring/40-walk-typology-complete.png" id="fig-transaction-monitoring-walk-typology-complete"} ::: ::: note Both conditions are in one group with **Match** **AND**, so the rule flags a sender only when the 7-day count is at least 3 *and* the 7-day total is at least 5000. To flag a sender when either is true, set **Match** to **OR**. See [How conditions are evaluated](#s-8-19). ::: ## Part 5: Choose or create a schedule {#s-8-16} ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New → Next Step] ::: step Read the Review & schedule rule page **Next Step** opens **Review & schedule rule** (“Validate your rule, run it on historical data, then schedule and activate.”). The **Schedule** card has **Select Schedule** (1), placeholder “Select from schedule list”. **Dry Run** (2) is greyed out, with the note “Please add execution interval and save this rule as a draft to dry run the results.” **Previous Step** (3) returns to the conditions. **Save as Draft** (4) is greyed out until a schedule is chosen. ::figure[Review & schedule rule: Select Schedule (1), Dry Run (2), Previous Step (3) and Save as Draft (4)]{src="transaction-monitoring/41-walk-review-schedule.png" id="fig-transaction-monitoring-walk-review-schedule"} ::: ::: step Open Select Schedule Open **Select Schedule**. The list has a **Search Schedule** box (1) and shows each existing schedule with its name and SCH- ID (2), for example Every\_Quarter (SCH-07102026-000430), Every\_week, Every\_month and Every\_day; the screenshot searches for “Every”. **+ New** (3) is at the bottom. ::figure[The Select Schedule list: search (1), an existing schedule with its ID (2) and + New (3)]{src="transaction-monitoring/42-walk-schedule-dropdown.png" id="fig-transaction-monitoring-walk-schedule-dropdown"} ::: **Using an existing schedule.** When you choose an existing schedule (1), its fields appear in the card and can be edited. If its **Start Time** is in the past, the field turns red with “Start time cannot be in the past” (2) and **Save as Draft** (3) stays greyed out. Every\_day (start 10/07/2026 12:00 AM) and Every\_week (start 10/06/2026 12:10 AM) both showed this message. These fields belong to the existing schedule, and one schedule can drive many rules (see [Schedule List](#s-8-10)). The example therefore creates a new schedule instead. ::figure[Every\_day chosen (1): “Start time cannot be in the past” (2), and Save as Draft greyed out (3)]{src="transaction-monitoring/43-walk-schedule-past.png" id="fig-transaction-monitoring-walk-schedule-past"} ::: step Start a new schedule Open **Select Schedule** again and click **+ New**. Empty schedule fields appear: **Name** (1), **Execution Interval** (2) with a **Unit** list (3), **Start Time** (4), filled with the current date and time, and **End Time** (5), marked optional. A **Save as Draft** button (6) appears in the card, greyed out. ::figure[+ New: Name (1), Execution Interval (2), Unit (3), Start Time (4), End Time (5) and Save as Draft (6)]{src="transaction-monitoring/44-walk-schedule-new.png" id="fig-transaction-monitoring-walk-schedule-new"} ::: ::: step Name the schedule and set the interval Type a **Name** (1) (the screenshots use `guide_example_schedule`). In **Execution Interval** (2) type **1**. Open **Unit** (3): **Hour**, **Day**, **Week**, **Month**, **Year**. Until you choose a unit, a red message under the field says “Interval unit is mandatory when interval is selected”. Choose **Day** (4). ::figure[Name (1) and interval (2) entered; the Unit list (3): Hour, Day (4), Week, Month, Year]{src="transaction-monitoring/45-walk-schedule-unit.png" id="fig-transaction-monitoring-walk-schedule-unit"} ::: ::: step Open the start time picker Click **Start Time** (1). A calendar opens on the current month, with arrows for the previous and next month. Dates before today (2) are greyed out and cannot be chosen. Below the calendar are a **Time** box (3) and **Clear** (4). ::figure[The Start Time field (1) and picker: past dates greyed out (2), Time (3) and Clear (4)]{src="transaction-monitoring/46-walk-schedule-picker.png" id="fig-transaction-monitoring-walk-schedule-picker"} ::: ::: step Choose the start date and time Click a future date (2) (here 16 October 2026) and type the time in **Time** (3) (09:00 AM). The field (1) reads **10/16/2026 09:00 AM** (month/day/year). The rule shown in Part 6 was saved on 7 October 2026 with a start of 08 Oct 2026, 09:00 AM. ::figure[16 October chosen (2) and 09:00 AM typed in Time (3); the field reads 10/16/2026 09:00 AM (1)]{src="transaction-monitoring/47-walk-schedule-start.png" id="fig-transaction-monitoring-walk-schedule-start"} ::: ::: step Leave End Time blank Leave **End Time** (optional) (1) empty: the card states “End date is optional — leave blank to run indefinitely.” With **Name**, **Execution Interval**, **Unit** and a future **Start Time** set, **Save as Draft** (2) becomes available. ::figure[The new schedule complete: End Time blank (1) and Save as Draft available (2)]{src="transaction-monitoring/48-walk-schedule-filled.png" id="fig-transaction-monitoring-walk-schedule-filled"} ::: **Schedule fields: reference** | Field | Required | What to enter / options | | --- | --- | --- | | **Select Schedule** | Yes (a schedule) | A searchable list of existing schedules (name and SCH- ID), and **+ New** to create one. | | **Name** | Yes (\*) | Free text; placeholder “Enter Name”. | | **Execution Interval** | Yes (\*) | A number (placeholder 0) and a **Unit**: **Hour**, **Day**, **Week**, **Month**, **Year**. Example: 1 Day. | | **Start Time** | Yes (\*) | Date and time, MM/DD/YYYY hh:mm AM/PM. Filled with the current date and time for a new schedule. Past dates are greyed out in the picker; a past start shows “Start time cannot be in the past”. Example: 10/08/2026 09:00 AM. | | **End Time** | No (optional) | Placeholder “Select end date & time”. Leave blank to run indefinitely. | ## Part 6: Save as draft {#s-8-17} ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New → Next Step → Save as Draft] ::: step Save the draft Click **Save as Draft** in the schedule card. Wait a few seconds: the page title changes to **Update Typology** (1). **Select Schedule** (2) now shows the new schedule, and the card shows the sentence “This rule will run every 1 day starting 08 Oct 2026, 09:00:00 am” (3). **Save as Draft** is replaced by **Update** (4), greyed out. **Dry Run** (5) is now available, and **Activate** (6) appears at the bottom right. Opened again after its start time has passed, as in the screenshot, the page also shows “Start time cannot be in the past” under **Start Time**; the saved draft is not affected. ::figure[After Save as Draft: Update Typology (1), the schedule (2), the run summary (3), Update (4), Dry Run (5) and Activate (6)]{src="transaction-monitoring/49-walk-draft-saved.png" id="fig-transaction-monitoring-walk-draft-saved"} ::: ::: step Find the draft in the list Open **Transaction Monitoring → Typology**. The new rule is the first row; later, find it by typing its name in the search box (1). The row shows the name and rule ID (2) (TMR-07102026-001091 in the example), status **Draft** (3), typology **Velocity** (4) and its creation time (5). ::figure[The new rule found by name (1): rule ID (2), status Draft (3), Velocity (4) and creation time (5)]{src="transaction-monitoring/50-walk-draft-in-list.png" id="fig-transaction-monitoring-walk-draft-in-list"} ::: ::: step Check the rule page Click the row. The rule page shows the **Draft** chip and rule ID with the description (1), and the Draft actions **Delete**, **Update**, **Duplicate Typology**, **Activate** and **Timeline & Notes** (2). The summary strip (3) reads **EXECUTION PERIOD** 08 Oct 2026, 09:00:00 am → N/A, **INTERVAL** Every 1 day, **COMPLEXITY** Advanced, **SUPPRESSION** 7Day and **TYPOLOGY** Velocity. Group 1 (4) shows both conditions read-only, joined by **AND — all must match**. **VARIABLES** (5) has a card for each variable: the new one as Num\_agg\_sum and `sender_txn_count_7d` as Num\_agg\_count, both with **WINDOW** in last 7 day and **GROUP** `sender_entity_id`. ::figure[The draft rule page: Draft chip, ID and description (1), Draft actions (2), summary strip (3), Group 1 (4) and the two variables (5)]{src="transaction-monitoring/51-walk-draft-detail.png" id="fig-transaction-monitoring-walk-draft-detail"} ::: ::: step Check the new schedule Open **Transaction Monitoring → Schedules** and switch to **Schedule List**. The new schedule is the first row; later, find it by typing its name in the search box (1). The row shows its name and ID (2) (SCH-07102026-000397 in the example), **Last Executed** — (3), **Rules Linked** 1 (4) and status **Inactive** (5). ::figure[Schedule List searched by name (1): the new schedule (2), Last Executed — (3), Rules Linked 1 (4), Inactive (5)]{src="transaction-monitoring/52-walk-schedule-in-list.png" id="fig-transaction-monitoring-walk-schedule-in-list"} ::: ::: note A Draft rule does not run. The next controls are **Dry Run** and **Activate** ([](#fig-transaction-monitoring-walk-draft-saved)), described in Part 7. ::: ## Part 7: Next: test and activate {#s-8-18} ::path[Fyscal ARCX → Transaction Monitoring → Typology → + New → Next Step → Save as Draft] These steps start from the **Update Typology** page in [](#fig-transaction-monitoring-walk-draft-saved). ::: note Illustrated steps The Typology Library shows these steps screen by screen: [Test a typology with Dry Run](#s-9-4) and [Request Shadow activation](#s-9-5). ::: ::: step Run a dry run In **Dry run on historical records** (“Test this rule against past data before going live. No alerts are created during a dry run.”), click **Dry Run**. It is available once the execution interval is set and the rule is saved as a draft. The result shows **Time Windows**, **Records Scanned** and **Alert Created** in total and per window; **Re-run** repeats the test and **Hide Result** collapses it. The dry run offers no date choice: in the Typology Library tests, with a schedule that runs every 1 day, it covered the last four one-day windows. If Records Scanned is 0, there was no data in the tested dates. A result of 0 alerts does not prove the rule works; see [Judge the result: 0 is not proof](#s-9-4). If the alert count is more than your team can review, raise the thresholds and re-run. ::: ::: step Request activation Click **Activate**. In **Activation Mode** choose **Shadow Mode** (“Alert generated against live data will be shown in rule detail page.”) or **Published Mode** (“Alert from this rule will flow into Alert Manager.”). The **Submit Request** dialog asks for a **Reason** (required) and optional **Supporting Documents** (1 file, max 2 MB, .jpg, .jpeg, .jpe, .png, .pdf, .webp or .md) added with **Attach File**. Write a reason a reviewer can act on, for example “Velocity rule, 3 or more transactions totalling ₱5,000 in 7 days; dry run reviewed; start in Shadow”. Click **Confirm**. ::: ::: step Wait for approval Activation goes through Maker Checker Approval. The request appears as an **Activate Typology** ticket, with status Pending, in [Maker Checker Approval → Tickets](#maker-checker), where a checker reviews it. Until it is approved, the rule stays a **Draft** in the typology list. :::
  1. Draft
  2. Submit Request
  3. Pending
After a checker approves a Shadow Mode request
  1. Pending
  2. Approved
  3. Shadow
After a checker approves a Published Mode request
  1. Pending
  2. Approved
  3. Published
Diagram 8.2 — What an activation request changes: the ticket is Pending and the rule stays Draft
The main track of Diagram 8.2 is what the screens show after **Confirm**. **Draft** is the rule's status; **Pending** is the status of the **Activate Typology** ticket in Maker Checker Approval. While the ticket is Pending, the rule's status is still **Draft**. The dashed branches use the statuses the typology list offers (**Shadow**, **Published**); an approval is not shown in this guide's screenshots. ::: step Check the live rule Open the rule from the list. Its page shows the status (**Shadow** or **Published**), the execution period and interval from the schedule, and the conditions and variables. Use **Schedule Details** to see each run, and the **Shadow Alerts** and **Live Alerts** columns in [Run History](#s-8-9) to see how many alerts each run raised. A paused rule shows **Paused** and a **Resume** button. ::: ::: note AML context Running a new or changed rule in parallel with production, without sending its alerts to analysts, is a common way to check alert volume and quality before go-live. ::: ## How conditions are evaluated: an example {#s-8-19} Each run calculates every variable once per **Group by** value (here, per sender) over its window, ending at the trigger time T. Then each group is checked. Example: at a run on 10 Jul, sender A's outgoing remittances in the last 14 days were as below, and the run calculated the variable values in the second table. | Date | Amount | | --- | --- | | 09 Jul | ₱2,000 | | 09 Jul | ₱3,500 | | 09 Jul | ₱1,500 | | 09 Jul | ₱2,500 | | 09 Jul | ₱3,000 | | 01 Jul | ₱8,000 | | Variable | Value for sender A | | --- | --- | | outgoing remittance 1 day sum | ₱12,500 | | outgoing remittance 1 day vol | 5 | | outgoing remittance 14 day sum | ₱20,500 | | outgoing remittance 14 day vol | 6 | 1. Group 1: 1 day vol 5 >= 5 is true, AND 1 day sum ₱12,500 >= 10000 is true. Group 1 is true. 2. Group 2: 14 day vol 6 >= 5 is true, AND 14 day sum ₱20,500 >= 20000 is true. Group 2 is true. 3. Groups are combined with OR, so one true group is enough: the rule raises an alert for sender A. The rule also has a **Suppression Window** of 2 Day (see [Create Typology form](#s-8-5)). If sender A had made no transactions at all in a variable's window, that variable would have no value for A, not 0. A condition such as **Equal** 0 then never matches, and **Is Null** is not saved in a typology condition. To test for “no transactions”, compare with the variable through a large multiplier, as the Typology Library's [Rule 4](#s-9-r4) shows. A **variable** only calculates a value. A **condition** decides whether that value is suspicious. Keeping them separate is what lets one variable serve many rules.
Related in Detection & Monitoring
Name ScreeningTypology LibraryData Ingestion