> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Fund Model: User Wallets vs the Enterprise Security Deposit
> The funding mental model behind Partner-Managed mode: the two-leg liability (an authorization hold followed by a settlement debit) and the payout rhythm (DCS pays the card network on T+1, you replenish the security deposit on T+X).
## 📄 Guide
Whether you are an exchange, a wallet or a platform, Partner-Managed mode keeps every cardholder's spending limit **in your hands** and leaves every authorization **decision** to you, while DCS turns those decisions into real money at the card network. This page explains the two ideas that make the fund model click: the **two-leg liability** (an authorization hold and a settlement debit are two separate events) and the **payout rhythm** (DCS pays the card network on T+1, you replenish the security deposit on T+X).
Once these two are clear, you can model your own ledger correctly: no double-holding of user funds, and no security deposit drained before settlement lands.
***
## Two pools of money: user wallets vs the enterprise security deposit
Partner-Managed mode involves two distinct pools of money. Always keep them apart:
| Money | Held where | Who owns the limit rules | Purpose |
| ---------------------------------------------------- | ------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **User wallet** (user limit/balance) | Limit rules and decisions sit on the partner side | **Partner** | The cardholder's spendable funds. The DCS partner-facing API neither exposes them to you nor requires you to custody user-level balances (DCS internal bookkeeping is transparent to the partner) |
| **Enterprise security deposit** (Enterprise Balance) | DCS side, per enterprise and per currency | **DCS** | The pooled funds you prefund, used as the working capital DCS draws on to settle with the card network on T+1 |
> **Key point**: user limit rules are maintained by the partner, and whether any single authorization passes is **decided by the partner against its own limit rules** (this is exactly what authorization forwarding means, see [Authorization Forwarding Model](./auth-forwarding-model)). After the partner approves, DCS checks that your **enterprise security deposit** is sufficient: if `availableAmount` falls short, the authorization is declined.
Real-time figures for the security deposit come from the enterprise balance endpoint, which returns three amount fields:
| Field | Meaning |
| ----------------- | -------------------------------------------------- |
| `totalAmount` | Total security deposit |
| `availableAmount` | Currently available limit (holds already deducted) |
| `usedAmount` | Amount held by authorizations or already used |
> Endpoint: `GET /open-api/enterprise/v2/enterprise-balance` (queried by `cardProfileId`). Line-level records are available from `GET /open-api/enterprise/v1/enterprise-balance-record`.
***
## Fund model 1: the two-leg liability, an authorization hold then a settlement debit
In funding terms a card purchase is not a single deduction but **two events that happen in sequence**. This is the fundamental difference from "a wallet debiting the balance directly".
* **Leg one, authorization**: when the cardholder pays, the card network sends an authorization request in real time. DCS forwards it to the partner, who **decides** whether to approve it against its own user limit rules. On approval the partner places a **hold** on the matching limit, and DCS reserves the same amount against `availableAmount` in the security deposit. At this point **no money has actually moved**.
* **Leg two, settlement**: the merchant later presents the transaction for settlement (usually from T+1 onwards, sometimes later); only once DCS receives it does the **actual debit** happen, and the hold from leg one is released.
The authorized amount and the settled amount **need not match**: a merchant may settle for less (a restaurant dropping the pre-authorized tip), for more (fuel stations, hotels), in several instalments, or settle with no prior authorization at all (offline transactions). DCS uses **Outstanding** (the unsettled balance) as the intermediate ledger that ties the two legs together, so holds and debits always reconcile back to zero.
Common combinations (all 13 scenarios are covered in [Authorization and Settlement Scenarios](../how-to-use/transactions/auth-and-settlement)):
| Scenario | Authorization (hold/release) | Settlement (debit/refund) | Final Outstanding |
| -------------------------------------------------- | ----------------------------------------------- | ------------------------- | ----------------: |
| Normal authorization to normal settlement | Hold 100 | Debit 100 | 0 |
| Normal authorization, partial reversal, settlement | Hold 100 − release 30 | Debit 70 | 0 |
| Normal authorization, full reversal | Hold 100 − release 100 | None | 0 |
| Normal authorization, over-settlement | Hold 100 (the 50 difference held via ForceAuth) | Debit 150 | 0 |
| Force settlement (no authorization) | No hold | Direct debit 100 | 0 |
> **Practical reminder for partners**: place the hold on the user wallet when you respond to the **authorization forwarding notification (authUrl)**, and only debit and release the hold once the settlement appears in the **daily transaction reconciliation file**. Never debit the balance at authorization time, or reversals, under-settlements and expiry releases will leave your books out of step with reality. The data structures for authorizations and transactions are documented in the [Authorization Data Dictionary](../how-to-use/transactions/authorization) and the [Transaction Data Dictionary](../how-to-use/transactions/transaction).
***
## Fund model 2: the payout rhythm, DCS pays the card network on T+1, the partner replenishes on T+X
The second fund model is about **timing**. Authorization is real time, actual funds settle later, and DCS's payout obligation to the card network is non-negotiable:
* **DCS to the card network: T+1 payout**. Whatever time the settled funds actually arrive from the cardholder side, DCS must front the payout on the card network's schedule (usually T+1). The money for that advance is your prefunded **enterprise security deposit**.
* **Partner to DCS: T+X replenishment**. Once the deposit has been consumed you need to prefund promptly, bringing `availableAmount` back to a safe level. The exact replenishment cycle and method follow your contract.
> **Hard risk limit**: once `availableAmount` in the security deposit is no longer sufficient, DCS declines subsequent authorizations, even if the user wallet still has a balance. Set an alert threshold on `availableAmount`, poll it regularly, and schedule replenishment ahead of time. Push-based alerting and webhooks are on the roadmap; for now, monitor the level by polling the enterprise balance endpoint.
***
## Next steps
With the fund model settled, head to the [Transaction Lifecycle](./transaction-lifecycle) to follow one transaction end to end from authorization to settlement. For reconciliation files, see [Daily Reconciliation Reports](../how-to-use/reports/overview).