Approvals & maker-checker¶
Sensitive actions in Cortex are captured by one person and authorised by another: four eyes. The Approvals queue is where that authorisation happens. It underpins so much of the day-to-day work that it is worth its own page.
Where: Approvals (top-level, outside the domain groups).
How it works¶
When you submit an action that needs authorisation (a large transfer, a manual journal, a loan approval), it does not execute. Instead Cortex serialises the exact command into an approval record and tells you it has been sent to Approvals. A checker later opens it and either:
- Approves & executes: the original command is replayed and takes effect; or
- Rejects: with a note.
Either way the decision is recorded. The maker cannot decide their own request. Attempting to do so is refused (four eyes). The checker needs both the matching approve permission and a sufficient approval tier for the amount.
The queue¶
The Approvals workspace has three scopes:
| Scope | Shows | Needs |
|---|---|---|
| My queue | Exactly what you, as checker, can decide (filtered by your domains, branch and tier) | approval:view |
| My submissions | What you parked as maker | approval:view |
| Everything | An oversight register across the institution | approval:view-all |
At the top, cards count what needs your decision, what is overdue (older than 24 hours), and what you have decided today. Each row shows the operation, domain, subject, amount, branch (or "bank-wide"), the maker, the age (colour-coded as it ages past SLA), the sign-offs collected versus required, and the status.
The decision drawer renders the parked command twice: as labelled, human-readable fields ("what will be executed") and as the raw payload, so you can see precisely what you are authorising before you approve or reject.
What routes here¶
Operations that go through Approvals include, among others:
LOAN_APPROVE · LOAN_WRITE_OFF · FUNDS_TRANSFER · PAYMENT · STANDING_ORDER · FX_CONVERT ·
BILLPAY_PAYMENT · TELLER_CASH · TRANSACTION_REVERSAL · BENEFICIARY_REGISTER ·
AGENT_ONBOARD · PAYMENT_RECOVERY
Setting the rules¶
Administrators configure when four eyes applies under Access & Security → Approval policy, a matrix mapping each operation and amount band to how many approvers are required and their minimum tier. A rule with zero approvers is straight-through. See Users, roles & access.
Key terms¶
- Maker / checker
- The person who captures an action, and the person who authorises it. They must be different people.
- Approval tier
- The amount authority a checker holds: T1 (≤ 1M), T2 (≤ 10M) or T3 (unlimited).
- Straight-through
- An action below the threshold that executes immediately, with no approval needed.