# 11. Maker Checker Approval


Maker Checker Approval is where actions that need approval are set up and where the resulting requests are tracked. Administrators use **Configs** to define each activity that needs approval, with its SLA, warning point, approval count and the maker and checker permissions. **Tickets** lists the approval requests raised against those activities, so you can follow their status, review them and withdraw a request you raised.

<dl class="chapter-facts"><div><dt>For</dt><dd>Administrators</dd></div><div><dt>In the menu</dt><dd>Maker Checker Approval</dd></div><div><dt>Reading time</dt><dd>About 13 min</dd></div></dl>

::: checks
- [Configs](#s-11-1): see which activities need approval and the rules set for each.
- [Search and filter activities](#s-11-2): find an activity by UID, name, domain or status.
- [Activity actions](#s-11-3): edit, view or deactivate an activity.
- [Create an activity](#s-11-4): set up a new activity with its timing, approvals and permissions.
- [Tickets](#s-11-5): follow the approval requests raised against activities.
- [Search and filter tickets](#s-11-6): find a ticket by request ID, domain, activity, maker or status.
- [Ticket statuses](#s-11-7): look up the eight ticket statuses.
- [View a ticket](#s-11-8): review a request's details and remarks, or withdraw your own request.
:::

**Maker Checker Approval** is its own item in the sidebar, below **Fyscal ARCX**. It expands into **Configs** and **Tickets**.

::: note AML context
Maker checker is the four-eyes principle: one person proposes a change and a different person approves it. Auditors and supervisors expect this separation of duties for changes to detection rules and screening settings. An SLA and a warning point turn each approval into a timed control.
:::

## Configs {#s-11-1}

::path[Maker Checker Approval → Configs]

Use Configs to see which actions need approval and the approval rules for each. Configs lists every activity configuration. An activity names an action somewhere in the platform, for example **AML Name Screening Config** under *Fyscal ARCX/Name Screening/Configuration/Screening*, and sets the approval rules for it.

::figure[Configs: search (1), Create Activity (2), Show Filters (3), a UID (4), Status (5), the row menu (6) and paging (7).]{src="maker-checker/01-configs-list.png" id="fig-maker-checker-configs-list"}

::: legend
1. **Search by activity UID or name**.
2. **+ Create Activity** opens the **Create Activity** form (see [Create an activity](#s-11-4)).
3. **Show Filters** shows the **Domain** and **Status** filters; the button then reads **Hide Filters**.
4. **UID**: the activity's code, beginning **ACT\_**, shortened with "…" and with a copy icon.
5. **Status**: **Active** (green) or **Inactive** (red).
6. **Actions** (⋮): opens the row menu (see [Activity actions](#s-11-3)).
7. Paging: **Showing 1-20 of 51**, **Rows per page** (20), **Page 1 of 3**, and first, previous, next and last page buttons.
:::

| Column | What it shows | Example |
| --- | --- | --- |
| **UID** | Activity code, shortened, with a copy icon. | ACT\_DAR2N8OM… |
| **Name** | Activity name. | AML Name Screening Config, Add Role, Create Account Type |
| **Section** | Path of the part of the platform the activity belongs to. Long paths are cut short with "…". | Fyscal ARCX/Name Screening/Configuration/Screening; Admin/Roles/Add Role; Payments/Treasury/Cash |
| **SLA (hrs)** | SLA in hours. | 24 |
| **Warning At (%)** | Warning point as a percentage; a dash (-) when not set. | 75 |
| **Status** | Whether the activity is active. | Active, Inactive |
| **Actions** | Row menu (⋮). | Edit, View, Deactivate |

#### AML activities seen in the example

The example lists 51 activities. Those seen belong mostly to other parts of the platform (for example Admin and Payments). Two AML actions were seen:

| Activity | Section or domain | Where it was seen |
| --- | --- | --- |
| **Activate Typology** | Fyscal ARCX/Transaction Monitoring/Typology | Tickets raised when a typology is activated (see [Tickets](#s-11-5)) |
| **AML Name Screening Config** | Fyscal ARCX/Name Screening/Configuration/Screening | The Configs list and the ticket **Activity Name** filter |

## Search and filter activities {#s-11-2}

::path[Maker Checker Approval → Configs]

Use search and the filters to find an activity by UID, name, domain or status.

::: step Search
Type an activity UID or name in **Search by activity UID or name**.
:::

::: step Show the filters
Click **Show Filters**. The **Domain** (**Select Domain**) and **Status** (**Select Status**) filters appear above the list.
:::

::: step Filter by domain
Click **Select Domain** (1) and choose a domain. In the example below, the list is empty and shows **No options found** (2).

::figure[The Domain filter (1) open, showing No options found (2).]{src="maker-checker/02-configs-domain-filter.png" id="fig-maker-checker-configs-domain-filter"}
:::

::: step Filter by status
Click **Select Status** (1) and choose **Active** or **Inactive** (2).

::figure[The Status filter (1): Active and Inactive (2).]{src="maker-checker/03-configs-status-filter.png" id="fig-maker-checker-configs-status-filter"}
:::

## Activity actions {#s-11-3}

::path[Maker Checker Approval → Configs → ⋮]

Use the row menu to change, inspect or deactivate an existing activity. Click ⋮ (1) in the **Actions** column of an activity. The **Actions** menu offers **Edit** (2), **View** (3) and **Deactivate** (4, in red).

::figure[The Actions menu (1) of an active activity: Edit (2), View (3) and Deactivate (4).]{src="maker-checker/04-configs-row-menu.png" id="fig-maker-checker-configs-row-menu"}

| Action | What the screen shows |
| --- | --- |
| **Edit** | Opens the **Edit Activity** form, subtitled "Configure the approval flow, context queries, and permission gates for this MCA activity." It has the same fields as **Create Activity** (see [Create an activity](#s-11-4)), with **Close** and **Save**. The activity's values are loaded: for **AML Name Screening Config**, the **Domain** (Fyscal ARCX/Name Screening/Configura…), **SLA Duration (hrs)** 24, **Warning At (%)** 75 and **Approval Count** 1. In that example **Operation Point** shows its placeholder, **Select modal/screen**. |
| **View** | Opens a window headed with the activity name and its full UID (for example **AML Name Screening Config**, **ACT\_dar2n8om2lbc73do21eg**), with **Close**. |
| **Deactivate** | Shown in red in the menu. |

::figure[View for AML Name Screening Config: the activity name and UID (1), the error Unable to load MCA config: insufficient scopes in the provided token (2), and Close (3).]{src="maker-checker/05-config-view-error.png" id="fig-maker-checker-config-view-error"}

::: note
View can show the error **Unable to load MCA config** with the message **insufficient scopes in the provided token**, as in [](#fig-maker-checker-config-view-error). In that case Edit shows the same message (**insufficient scopes in the provided token**) in the **Diff Fields** box.
:::

## Create an activity {#s-11-4}

::path[Maker Checker Approval → Configs → + Create Activity]

Create an activity when an action in the platform needs to go through approval. **+ Create Activity** opens the **Create Activity** form. The form scrolls: the top part sets the activity and its timing, and the lower part sets the context queries and permissions. Fields marked \* are required.

::figure[Create Activity, top part: Activity Name (1), Domain (2), Operation Point (3), SLA Duration (hrs) (4), Warning At (%) (5), Approval Count (6) and Diff Fields (7).]{src="maker-checker/06-create-activity-part1.png" id="fig-maker-checker-create-activity-part1"}

::figure[Create Activity, lower part: Context Type (1), Pre-validation Hook (2), Abort Hook (3), Maker Permission (4), Checker 1 Permission (5) and Save (6).]{src="maker-checker/07-create-activity-part2.png" id="fig-maker-checker-create-activity-part2"}

<div class="table-wrap"><table class="compact"><thead><tr><th>Field</th><th>What it expects</th><th>Required</th><th>Default, placeholder or options</th></tr></thead><tbody><tr><td><strong>Activity Name</strong></td><td>Name of the activity.</td><td>Yes</td><td>Placeholder: e.g. Edit Email Template</td></tr><tr><td><strong>Domain</strong></td><td>The domain the activity belongs to.</td><td>Yes</td><td>Drop-down: Select Domain</td></tr><tr><td><strong>Operation Point</strong></td><td>The modal or screen the activity applies to. Has an info icon (ⓘ).</td><td>Yes</td><td>Drop-down: Select modal/screen</td></tr><tr><td><strong>SLA Duration (hrs)</strong></td><td>SLA in hours.</td><td>Yes</td><td>4</td></tr><tr><td><strong>Warning At (%)</strong></td><td>Warning point as a percentage.</td><td>No</td><td>80</td></tr><tr><td><strong>Approval Count</strong></td><td>Number of approvals. Has an info icon (ⓘ).</td><td>Yes</td><td>1</td></tr><tr><td><strong>Diff Fields</strong></td><td>Filled in by the form: "Select Domain and Operation Point above. All available diff fields from that modal will be auto-populated here".</td><td>No</td><td>Read-only until Domain and Operation Point are chosen</td></tr><tr><td colspan="4"><strong>Context Queries</strong></td></tr><tr><td><strong>Context Type</strong></td><td>The type of additional context for the request.</td><td>No</td><td>Drop-down: Select context type. Options: <strong>Generic Additional Context</strong>, <strong>Tailored Additional Context</strong></td></tr><tr><td><strong>Pre-validation Hook</strong></td><td>A pre-validation hook.</td><td>No</td><td>Drop-down: Select pre-validation hook (optional)</td></tr><tr><td><strong>Abort Hook</strong></td><td>An abort hook.</td><td>No</td><td>Drop-down: Select abort hook (optional)</td></tr><tr><td colspan="4"><strong>Assign Permissions</strong></td></tr><tr><td><strong>Maker Permission</strong></td><td>The permission for the maker. Has an info icon (ⓘ).</td><td>Yes</td><td>Drop-down: Select permission</td></tr><tr><td><strong>Checker 1 Permission</strong></td><td>The permission for the first checker. Has an info icon (ⓘ).</td><td>Yes</td><td>Drop-down: Select permission</td></tr></tbody></table></div>

::: step Open the form
On **Configs**, click **+ Create Activity**.
:::

::: step Name the activity and choose where it applies
Enter the **Activity Name**, then select the **Domain** and the **Operation Point**. **Diff Fields** fills in from the chosen modal or screen.
:::

::: step Set the timing and approvals
Change **SLA Duration (hrs)** (4), **Warning At (%)** (80) and **Approval Count** (1) if the defaults do not fit.
:::

::: step Set the context queries
Scroll down. Under **Context Queries**, select a **Context Type** and, if you need them, a **Pre-validation Hook** and an **Abort Hook**.
:::

::: step Assign the permissions
Under **Assign Permissions**, select the **Maker Permission** and the **Checker 1 Permission**. Both are required.
:::

::: step Save
Click **Save**. To leave without saving, click **Close** or the × at the top right.
:::

## Tickets {#s-11-5}

::path[Maker Checker Approval → Tickets]

Use Tickets to follow approval requests and see where each one stands. A ticket is a request raised for an activity and waiting for approval. For example, activating a typology in [Transaction Monitoring](#transaction-monitoring) raises a ticket for the **Activate Typology** activity, with the domain *Fyscal ARCX/Transaction Monitoring/Typology*. Tickets lists these requests.

<dl class="key-facts"><div><dt>Raised by</dt><dd>The maker's action, for example Activate Typology</dd></div><div><dt>Decided by</dt><dd>A checker; the maker's view offers no approve or decline buttons</dd></div><div><dt>Progress</dt><dd><strong>Checker Progress</strong>, for example 0 / 1 checkers acted</dd></div><div><dt>The maker can</dt><dd>View, Watch, and Withdraw a Pending ticket</dd></div></dl>

<figure class="diagram swimlane"><div class="dg-lanes n6"><div class="dg-lane l1">Maker</div><div class="dg-lane l2">Checker</div><div class="dg-lane l3">System</div><div class="dg-task l1 s1">Activates; picks the mode</div><div class="dg-task l1 s2">Submits with a Reason</div><div class="dg-task l3 s3">Raises a Pending ticket</div><div class="dg-task l2 s4 is-tbc">Reviews the ticket</div><div class="dg-task l2 s5 is-tbc">Approves or declines</div><div class="dg-task l3 s6 is-tbc">Applies the change</div></div><figcaption><span class="cap-num">Diagram 11.1</span> — Maker, checker and system steps for an Activate Typology request</figcaption></figure>

Diagram 11.1 follows one request. The maker's steps and the system's response were seen on screen: after **Submit Request** the confirmation reads "Submitted for governance review (ticket AMLTM\_…). It will be applied once approved.", the typology stays **Draft**, and a **Pending** ticket appears here with **Checker Progress** "0 / 1 checkers acted". The maker's side is described step by step in [Request Shadow activation](#s-9-5). While the ticket is Pending, the maker can withdraw it (see [View a ticket](#s-11-8)).

::figure[Tickets: search by request ID (1), Show Filters (2), the request ID (3), the status (4) and the row menu (5); maker names hidden.]{src="maker-checker/08-tickets-list.png" id="fig-maker-checker-tickets-list"}

::: legend
1. **Search by request ID**.
2. **Show Filters** shows the **Domain**, **Activity Name**, **Maker** and **Status** filters.
3. **Request ID**, with a copy icon.
4. **Status** of the ticket (see [Ticket statuses](#s-11-7)).
5. **Actions** (⋮): **View** and **Watch**.
:::

| Column | What it shows | Example |
| --- | --- | --- |
| **Request ID** | Ticket number, with a copy icon. The ticket's details and the confirmation message show a longer ticket ID beginning **AMLTM\_** instead (see [View a ticket](#s-11-8)). | 914 |
| **Activity ID** | UID of the activity, shortened, with a copy icon. | ACT\_D9LKNFJ1… |
| **Activity Name** | Name of the activity. | Activate Typology |
| **Status** | Ticket status tag. | Pending, Expired |
| **Maker** | The user who raised the request. | (user name) |
| **Created At** | When the ticket was raised. | Oct 6, 2026, 10:57:55 AM |
| **Actions** | Row menu (⋮). | View, Watch |

Below the list, **Page** shows the current page number with previous and next buttons.

## Search and filter tickets {#s-11-6}

::path[Maker Checker Approval → Tickets → Show Filters]

Use the search box and filters to find a ticket by request ID, domain, activity, maker or status. Click **Show Filters**. Four filters appear above the list, and the button reads **Hide Filters**.

::figure[Ticket search (1) and the Domain (2), Activity Name (3), Maker (4) and Status (5) filters, with Hide Filters (6).]{src="maker-checker/09-tickets-filters.png" id="fig-maker-checker-tickets-filters"}

| Filter | Placeholder | Options |
| --- | --- | --- |
| Search | Search by request ID | Free text |
| **Domain** | Select Domain | On Configs, the Domain filter lists **No options found** ([](#fig-maker-checker-configs-domain-filter)). |
| **Activity Name** | Select Activity | The activity names from Configs, for example AML Name Screening Config, Create Account Constraint, Add Role, Edit Role, Unfreeze Account |
| **Maker** | Select Maker | - |
| **Status** | Select Status | Pending, In Progress, Execution Pending, Approved, Declined, Withdrawn, Expired, Execution Failed |

::: step Find a ticket by number
Type the request ID in **Search by request ID**.
:::

::: step Filter by status
Click **Select Status** and choose a status.

::figure[The ticket Status filter (1): Pending, In Progress, Execution Pending, Approved, Declined, Withdrawn, Expired and Execution Failed (2).]{src="maker-checker/10-tickets-status-filter.png" id="fig-maker-checker-tickets-status-filter"}
:::

::: step Filter by activity or maker
Click **Select Activity** and choose an activity name, or click **Select Maker** and choose a maker.
:::

## Ticket statuses {#s-11-7}

::path[Maker Checker Approval → Tickets]

Use this table to look up a status shown on a ticket or in the **Status** filter. The **Status** filter lists eight ticket statuses. The screen does not describe them; the table notes what the example tickets show. Only **Pending** and **Expired** have been seen on tickets.

| Status | As seen on screen |
| --- | --- |
| **Pending** | Tickets 991 to 1005 (Activate Typology, raised on 8 Oct 2026) while they waited, and ticket 914 when it was first seen on 6 Oct. The details show **Checker Progress** "0 / 1 checkers acted", and the maker can withdraw the ticket. |
| **In Progress** | Listed in the Status filter only. |
| **Execution Pending** | Listed in the Status filter only. |
| **Approved** | Listed in the Status filter only. |
| **Declined** | Listed in the Status filter only. |
| **Withdrawn** | Listed in the Status filter only. |
| **Expired** | Tickets 911 and 914, and tickets 991 to 1005 by 11 Oct (raised 8 Oct, no checker acted). Ticket 914 was Pending on 6 Oct, with "0 / 1 checkers acted", and Expired on 8 Oct. The tag is the same yellow as Pending. |
| **Execution Failed** | Listed in the Status filter only. |

<figure class="diagram lifecycle"><ol class="dg-track"><li class="dg-state is-start is-key">Pending</li><li class="dg-edge is-tbc"><span>Checker approves</span></li><li class="dg-state is-end is-tbc">Approved</li></ol><div class="dg-fork"><span class="dg-fork-label">If the checker declines</span><ol class="dg-track"><li class="dg-state is-ref">Pending</li><li class="dg-edge is-tbc"><span>Decline</span></li><li class="dg-state is-end is-tbc">Declined</li></ol></div><div class="dg-fork"><span class="dg-fork-label">If the maker withdraws</span><ol class="dg-track"><li class="dg-state is-ref">Pending</li><li class="dg-edge is-tbc"><span>Withdraw</span></li><li class="dg-state is-end is-tbc">Withdrawn</li></ol></div><div class="dg-fork"><span class="dg-fork-label">Seen on ticket 914, with no checker action recorded</span><ol class="dg-track"><li class="dg-state is-ref">Pending</li><li class="dg-edge"></li><li class="dg-state is-end">Expired</li></ol></div><figcaption><span class="cap-num">Diagram 11.2</span> — Ticket statuses and the paths out of Pending</figcaption></figure>

Diagram 11.2 shows the paths a ticket can take out of **Pending**. Only Pending to **Expired** appears in this guide's screenshots (ticket 914, above). The other paths follow the actions on screen (**Withdraw** in the maker's view) and the status names in the filter (**Approved**, **Declined**, **Withdrawn**).

## View a ticket {#s-11-8}

::path[Maker Checker Approval → Tickets → ⋮ → View]

Open a ticket to review what was requested, the proposed change and any checker remarks, or to withdraw a request you raised. Click ⋮ in the **Actions** column of a ticket. The **Actions** menu offers **View** and **Watch**. **View** opens **Request Details**.

::figure[The ticket Actions menu (1): View (2) and Watch (3).]{src="maker-checker/11-ticket-row-menu.png" id="fig-maker-checker-ticket-row-menu"}

::figure[Request Details for an Expired Activate Typology ticket, Maker Submission tab: request ID and status (1), created and requested by (2), domain, action and checker progress (3), tabs (4), reason and attachments (5), Data Difference (6), Additional Context (7) and Close (8).]{src="maker-checker/12-ticket-view.png" id="fig-maker-checker-ticket-view"}

::: legend
1. **Request ID**, beginning **AMLTM\_** (shortened, with a copy icon), and the status tag. The Tickets list shows the same ticket by its number, here 1005.
2. **CREATED** date and time and **REQUESTED BY** with the maker's name (hidden here).
3. **Domain** (*Fyscal ARCX/Transaction Monitoring/Typology*), **Action** (**Activate Typology**) and **Checker Progress** ("0 / 1 checkers acted").
4. Tabs: **Maker Submission** and **Remarks**.
5. **Reason** given by the maker, and **Attachments** ("No attachments" when there are none).
6. **Data Difference**: a table of **Field**, **Current Value** and **Proposed Value**. In the example, **Activation Mode** changes from - to **shadow**.
7. **Additional Context**: a table of **Field** and **Value**, for example the **Rule URL** (a link to the rule, hidden here) and, further down, the **Rule Name**.
8. **Close**. While a ticket is **Pending**, its maker also sees a **Remarks \*** box ("Required for withdrawal") and **Withdraw** here; once the ticket has expired they are no longer shown.
:::

::figure[The Remarks tab (1): Request Decision (2), showing No checker remarks recorded for this request.]{src="maker-checker/13-ticket-view-remarks.png" id="fig-maker-checker-ticket-view-remarks"}

The **Remarks** tab shows **Request Decision**. When no checker has added remarks, it reads "No checker remarks recorded for this request." On a **Pending** ticket, the maker's **Remarks \*** box and **Withdraw** stay at the bottom on both tabs.

::: step Open the ticket
On **Tickets**, click ⋮ on the ticket, then **View**.
:::

::: step Review the request
On **Maker Submission**, read the **Reason**, **Attachments**, **Data Difference** and **Additional Context**. Click **Remarks** to see any checker remarks.
:::

::: step Withdraw your own request
If you raised the ticket, enter a reason in **Remarks**, which is required for withdrawal, then click **Withdraw**. To leave without changes, click the × at the top right.
:::

::: 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. The checker's view is not shown in this guide (see [Tickets](#s-11-5)). Ask your administrator which users act as checkers for each activity, or contact support at [hello@fyscaltech.com](mailto:hello@fyscaltech.com).
:::