Panic Button
Access prerequisites
- Permission (module):
panicButton - License/Feature: None
- Menu container: GENERAL → Audit group
What is it / when to use
The Panic Button screen (/panic-button) is the operational emergency kill-switch for the platform. It allows immediate suspension of entire categories of operations across the entire tenant — without touching user-by-user — when an ongoing incident is detected (mass fraud, bug exploitation, integration compromise).
Each category is an independent card that can be suspended (stop) or resumed (return to operation). It is the response counterpart to incident management; detection comes from the Antifraud Log and the Audit Alerts.
Prerequisites
- Permission: module
panicButton. Permission is dual — enum CPM on the backend + dynamic module in the DB. The suspend/resume buttons are protected by the*appHasPermission="'panicButton'"directive. - License/Feature: none.
- Dependencies from other screens: none. The effect is global on the tenant — services check the suspension state (AntifraudService) before executing the corresponding operation.
Step by step
- Navigate to GENERAL → Audit → Panic Button.
- The screen displays one card per category, each showing its current status (Active or Suspended).
- To suspend: click Suspend on the card, provide the reason (min. 10 characters) and the MFA code (6 digits) in the dialog, and confirm.
- To resume: click Resume on the card and provide the MFA code (6 digits).
- Suspended cards show who suspended it, the reason, and the date.
Suspension categories
| Category | Value (suspensionType) | What stops on the backend |
|---|---|---|
| Account creation | account_creation | Blocks new registrations/account openings on the tenant |
| Withdrawals | withdrawals | Blocks withdrawals (PIX/bank/crypto) — contains fund leakage in an incident |
| Transfers | transfers | Blocks internal/external transfers |
| Order creation | order_creation | Blocks opening new orders (e.g., buy/sell) |
| Auto purchases | auto_purchases | Blocks automatic/recurring purchase executions |
Dialog fields (suspension)
| Field | What it is | Required? | Effect on system/backend |
|---|---|---|---|
| Reason | Justification for the suspension | Yes (min. 10 characters) | Recorded in reason; becomes the incident audit trail |
| MFA Code | 6-digit code from the authenticator app | Yes (pattern ^\d{6}$) | Mandatory re-authentication for the sensitive action (step-up). Without a valid MFA, the backend rejects it |
On resume, only the MFA code is required (reason is not requested).
Actions and modals
- Suspend: opens the action dialog (
suspend); on confirmation, sendssuspensionType+reason+mfaCode. On success, reloads status and displays confirmation. Backend errors (e.g., invalid MFA) are shown with the returned message. - Resume: opens the action dialog (
resume); on confirmation, sendssuspensionType+mfaCodeand reopens the category. - Refresh: reloads the state of all categories.
Business rules / cautions
Immediate and broad effect
- Suspension is a global kill-switch for the tenant: it affects all users in that operation category instantly, not just suspects. Use with discretion — it is an incident containment measure, not routine management.
- Leaving a category suspended paralyzes the business (e.g., suspended
account_creationprevents any new customer). Always resume as soon as the incident is contained.
Warning
- Mandatory step-up: both suspend and resume require MFA code (re-authentication). This ensures the kill-switch is not triggered by a compromised session.
- The action records who suspended it (
suspendedBy), reason, and date — it is the incident audit trail. In a coordinated response, record the incident number in the reason field. - The Panic Button is not 4-eyes (dual approval): it is a unilateral action protected by step-up. For decisions requiring two approvers, use the approval flows defined in the admin antifraud ADR.
Examples
Scenario 1 — Contain mass withdrawals during an incident
A suspected exploitation is draining funds via crypto withdrawals. The security operator:
- Opens Panic Button and clicks Suspend on the Withdrawals card (
withdrawals). - In the dialog, writes the reason: "INC-2026-014: withdrawal block due to suspected exploit in crypto flow" and provides the 6-digit MFA code.
- Confirms. From that moment on, no withdrawal is processed on the tenant. The card moves to Suspended, showing the operator, reason, and date.
- After correction and validation, clicks Resume, provides the MFA code, and withdrawals resume operating.
Scenario 2 — Pause registrations during a wave of fraudulent accounts
Automated account creation is detected (bot). The operator suspends the Account creation category (account_creation) with reason "Automated account creation wave — preventive block". New registrations stop; existing users continue operating normally. When the filter/captcha is reinforced, the category is resumed.
Scenario 3 — Freeze auto purchases after a pricing error
A quote bug is triggering auto purchases at the wrong price. The operator suspends Auto purchases (auto_purchases), containing the loss, while the team fixes the pricing. Other operations (withdrawals, transfers) remain enabled, minimizing business impact.