> 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/from-transaction-to-decision.md). # From transaction to decision **For:** Brand administrators, Finance, Risk, and Treasury owners. Start here when a transaction is pending and you need to know *which approval path actually owns it*. This guide describes the current product behavior; the brand's approved policy still determines who should be assigned. ## First identify what happened to the transaction | Transaction event | Does an approval request open? | Workflow trigger and initiator | If no live workflow covers it | | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Client submits a **manual bank deposit** with payment evidence. | Yes. The deposit waits for a decision before credit. | **Manual / bank deposit created**, client-initiated. | Backend authoritative **Risk → Finance** review. The current Admin decision screens do not provide a complete enforced two-person bank-deposit path; see [the limitation](/crm-admin/platform-configuration/configure-financial-approval-flows/manual-deposits/manual-deposits-authoritative.md). | | PSP confirms a **deposit within all applicable automatic-credit limits**. | No approval request for this reason; eligible credit follows the normal PSP path. | None. | Not applicable. | | PSP confirms a **deposit held by an auto-credit ceiling or brand daily amount/count limit**. | Yes. The confirmed payment is held before credit. | **Overlimit Deposits**, **system-initiated**; choose **Both** in the editor to cover it. | **One** authorized transaction-level decision, not a mandatory Risk-then-Finance sequence. | | Client requests a **withdrawal**. | Yes; funds are reserved pending review. | **Withdrawal requested**, client-initiated. | Authoritative **Risk → Finance** review, then a separate payment stage. This is exceptional where a built-in withdrawal workflow is live. | This edition covers client-submitted **bank** deposits, PSP-confirmed overlimit deposits, and client withdrawals. It does not prescribe the operator-created manual-deposit funnel or other manual payment methods. ## Then resolve the approval route Follow the rows in order for the transaction's event. A workflow is selected by the transaction's **tenant, brand, trigger, and initiator channel**. A draft is not live. | Question, in order | If yes | If no | | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | | 1. Is there an applicable **live** workflow for this event and initiator? | The workflow owns the request. Continue to question 2. | Use the transaction-specific authoritative route in the table above. | | 2. Does an active, effective **rule** match? | Use the **first matching rule's outcome**: its approval chain, automatic approval, or automatic rejection, subject to execution safeguards. | Use this workflow's **fallback chain**. Do **not** switch to authoritative approval. | | 3. Does a human approval chain run? | Levels run in order. Each level waits for its configured quorum and eligible approver; permitted decisions include approve, reject, request information, and, where enabled, return. | For an automatic outcome, inspect the actual resulting transaction and audit entry; do not infer success from the rule name. | | 4. Is **direct approval** enabled and exercised by an authorized holder while the request is pending? | That decision **supersedes the workflow** and expires pending level approvals. Treat this as a deliberate override, not as an ordinary level or the no-workflow authoritative route. | Continue through the selected chain. | | 5. Has the final decision been applied to the transaction? | For a deposit, verify exactly one credit; for a withdrawal, verify the reserved/debited state and proceed to the **separate payment stage**. | Keep the request pending or on hold; investigate the decision and transaction separately. | Within an applicable workflow, rule conditions combine with **AND**. Effective dates and status matter. Regulation-bound rules are considered before brand-only rules; then priority runs from the lowest number upward, with a stable tie-break. The first match wins. A rule is an *exception selector*, not a requirement for the workflow to operate: zero matching rules means the fallback chain. > **Publication changes policy.** Publishing a workflow that overlaps an existing live trigger and initiator channel can disable that workflow or narrow its remaining channel. A workflow set to **Both** can take both client and operator traffic. Review the old and proposed coverage before publishing. Requests already in progress retain their workflow version, but event creation/recovery can be asynchronous; verify the route recorded on a representative transaction rather than assuming a form-submit instant fixed it. ## What final approval means in each flow | Flow | Final approval applies | It does **not** prove | | --------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Manual bank deposit | Credit of the approved deposit, once the applicable decision is accepted. | That uploaded payment evidence was authentic; a reviewer must inspect it in transaction details. | | PSP overlimit deposit | Credit of the already PSP-confirmed, held amount once. | That a rejection automatically refunded the PSP payment. Refund/reconciliation is separate. | | Withdrawal | Approval of the withdrawal and movement toward payment processing. | That Treasury submitted it, the PSP accepted it, or the client received funds. The default waits for Treasury; eligible automatic submission requires published brand settings. | In a custom/rule-selected withdrawal chain, the **workflow decision history** identifies the real approvers and levels. The older withdrawal record may show a synthetic **System Risk** decision and label the final workflow approver **Finance**. Those labels are not evidence of additional human Risk or Finance sign-offs. The built-in Risk → Finance fallback records its actual actors. A final approver recorded as Finance cannot perform the later manual Treasury settlement of that same withdrawal. ## Quick diagnosis of a “wrong route” 1. Open the transaction and note its origin, status, tenant, brand, initiator, and event. For bank deposits, open the client's uploaded evidence **from transaction details**; the workflow Decision tab links to the transaction but does not display the file itself. 2. In **Tenants & Brands → Approval Workflows**, inspect **Live**, trigger, **Applies to**, rule status/effective period, priority, and fallback. Do not mistake an unmatched rule for an absent workflow. 3. Check the workflow decision history and the transaction state. For withdrawals, inspect Treasury/payment status separately. 4. Check the relevant role/desk has **active** operators and decision permission. A role with **0 active** people is not a usable approval stage, even if it appears in a level. 5. Check [notification template mappings](/crm-admin/platform-configuration/configure-financial-approval-flows/approval-email-templates.md). A selected template code alone does not prove that email or in-app notification was delivered. Use the separate [manual bank deposit](/crm-admin/platform-configuration/configure-financial-approval-flows/manual-deposits.md), [PSP overlimit](/crm-admin/platform-configuration/configure-financial-approval-flows/overlimit-deposits.md), and [withdrawal](/crm-admin/platform-configuration/configure-financial-approval-flows/withdrawals.md) guides for configuration steps and screenshots. Test a matched rule, an unmatched fallback, a rejection, and the final financial outcome in QA before publishing a new version. --- # 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/from-transaction-to-decision.md?ask=&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.