> For the complete documentation index, see [llms.txt](https://docs.brokvix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brokvix.com/crm-admin/platform-configuration/configure-financial-approval-flows.md).

# Configure deposit and withdrawal approvals

**For:** SaaS, tenant, and brand administrators, with Finance and Risk process owners reviewing the configuration. Work in the intended tenant and brand. Your role determines which menus and decisions you can see.

There are two approval routes in Brokvix CRM. A **live, applicable workflow** owns a request and uses its first matching rule or, when no rule matches, its fallback chain. The **authoritative route** applies only when no live workflow covers that request. A workflow does not append authoritative sign-offs to its own chain.

If you are looking at a pending transaction rather than creating a policy, start with [From transaction to decision](/crm-admin/platform-configuration/configure-financial-approval-flows/from-transaction-to-decision.md). It traces the initiating event, workflow selection, rule/fallback, final decision, and financial outcome. For notification setup, use [Choose approval email templates](/crm-admin/platform-configuration/configure-financial-approval-flows/approval-email-templates.md).

Before naming people on a level or asking another operator for advice, use [Set up approvers and advice collaborators](/crm-admin/platform-configuration/configure-financial-approval-flows/approver-and-advice-eligibility.md). It explains the operator setting, role permissions, and why a selected approver can still be read-only.

| Request                                                                                                                                                 | Workflow route                                                                 | Authoritative route when no workflow applies                                                                               |
| ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| [Client-submitted manual bank deposit](/crm-admin/platform-configuration/configure-financial-approval-flows/manual-deposits.md)                         | A rule or the fallback chain decides.                                          | Backend Risk → Finance review; the current Admin decision path does **not** expose a complete enforced two-person process. |
| [Confirmed PSP deposit held over an automatic-credit limit](/crm-admin/platform-configuration/configure-financial-approval-flows/overlimit-deposits.md) | An **Overlimit Deposits** rule or fallback chain decides.                      | One authorized transaction-level decision, **not** two successive Risk and Finance stages.                                 |
| [Client withdrawal](/crm-admin/platform-configuration/configure-financial-approval-flows/withdrawals.md)                                                | A withdrawal rule or fallback chain decides; payment release remains separate. | Risk → Finance review, followed by a separate payment stage.                                                               |

Each transaction type has a separate overview, authoritative guide, and workflow guide. Manual deposits here means **client-submitted bank deposits only**; other manual deposit methods and operator-created requests are outside this edition.

## Common workflow configuration

1. Open **Tenants & Brands → Approval Workflows** in the correct workspace. Check whether a live workflow already covers the trigger and whether it applies to client-initiated, operator-initiated, or both request types. Publishing an overlapping workflow can replace the live route for that channel.
2. Choose the correct trigger and **Applies to** value. Overlimit PSP holds are system-initiated, so select **Both**. Include the client-initiated channel for bank deposits and client withdrawals.
3. Configure the fallback approval chain, level approvers, quorum, deadlines, escalation, permission to decide, and notifications. Add Risk and Finance levels explicitly if policy requires both; custom chains do not inherit those departments automatically.
4. Review **Requester cannot approve** and **Same person cannot approve two levels** separately. The latter can be configured for a custom workflow; the built-in withdrawal fallback has distinct approvers. **Direct approval** is a separate permissioned override, not another level. Turn it off if every decision must traverse the configured chain.
5. Add rules for deliberate exceptions. A rule's conditions combine with AND; lower priority numbers run first; the first matching rule wins. If none matches, the **workflow fallback chain** applies—there is no switch back to authoritative review.
6. Select [approved email templates](/crm-admin/platform-configuration/configure-financial-approval-flows/approval-email-templates.md) for outcome and level events, or choose **No email** intentionally. A selected code without resolvable publishable content may produce neither email nor in-app notification; current publish warnings do not block that situation. An active SaaS body can be a fallback even without an exact brand mapping.
7. Use **Simulate** with a suitable QA request to inspect the selected rule or fallback and currently eligible approvers. Review the actual request, decision history, and financial outcome in QA before publishing. Simulation is read-only and does not prove that money was credited or sent.

The [manual bank](/crm-admin/platform-configuration/configure-financial-approval-flows/manual-deposits/manual-deposits-workflow.md), [PSP overlimit](/crm-admin/platform-configuration/configure-financial-approval-flows/overlimit-deposits/overlimit-deposits-workflow.md), and [withdrawal](/crm-admin/platform-configuration/configure-financial-approval-flows/withdrawals/withdrawals-workflow.md) workflow guides each include QA screenshots. Unsaved editor examples illustrate the controls; they are not active policies or recommended approver assignments.

## Before enabling a brand configuration

* Confirm the correct tenant, brand, origin, live workflow version, queue permissions, and transaction state. A draft does not govern new requests.
* Test a matching rule and a no-match fallback. Verify the actual decision sequence and transaction result, not just the queue label.
* Have Finance and Risk approve the business policy. For bank deposits, do not use the current authoritative Admin route as an enforced two-person control. For overlimit PSP deposits, determine whether one decision or an explicit two-level chain is required. For withdrawals, verify the later Treasury handoff separately.
* Review notification templates and actual delivery. **No email** sends no fallback wording. A selected template without publishable content can also leave both email and in-app notification silent; a warning may appear without stopping publication.

If a request or menu is missing, check the workspace, trigger, initiator coverage, published status, queue permissions, and request state. See [Access and permissions](/crm-admin/getting-started/access-and-permissions.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.brokvix.com/crm-admin/platform-configuration/configure-financial-approval-flows.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.