> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cryptomate.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Active Management

> Centralize deposits and manage client balances with a secure virtual + holding wallet architecture.

## Overview

CryptoMate's **Active Management** product lets businesses manage their clients' digital assets through an integrated **Wallet** and **Holding Wallet** system. Deposits are received on dedicated addresses, while the real assets are consolidated in a secure, company-managed holding wallet.

The product is built on top of **Polygon**, **BNB Chain**, and **Tron**, providing a robust, transparent, and scalable foundation for business operations.

## Supported tokens

The tokens available for use across each blockchain are the default listed tokens plus any custom tokens your company has registered. You can consult the full list at any time via the [List custom tokens](/api-reference/management/blockchains/list-custom-tokens) endpoint.

## Core concepts

<Columns cols={2}>
  <Card title="Wallet" icon="inbox">
    A deposit address where cryptocurrencies are received. Incoming funds are recorded as a **virtual balance** — a debt owed by the company to its client.
  </Card>

  <Card title="Holding Wallet" icon="vault">
    The main repository for the real assets. Funds are automatically transferred here from the deposit wallet to maximize security and fund control.
  </Card>
</Columns>

## Deposit-to-holding flow

<Steps>
  <Step title="Receive the deposit">
    The client sends cryptocurrency to a unique wallet deposit address. The transaction is processed and recorded on the blockchain (Polygon, BNB, or Tron). The system registers the amount as a virtual balance that represents the company's debt to the client.
  </Step>

  <Step title="Transfer to the holding wallet">
    Real funds move from the deposit wallet to the holding wallet automatically or via rules, centralizing assets in a secure company-managed address.
  </Step>

  <Step title="Virtual balance reflection">
    The client sees their available virtual balance in real time and can use it per the platform's rules — transactions, payments, or internal operations.
  </Step>

  <Step title="Audit and transparency">
    The entire flow is traceable and auditable through the blockchain, so every movement can be verified end-to-end.
  </Step>
</Steps>

## Managing virtual wallets

**Deposits and withdrawals.** Clients can deposit and withdraw funds as needed from their virtual wallets.

**Withdrawals to external wallets.** When funds are withdrawn from a virtual wallet to an external address, the assets are deducted from the holding wallet, ensuring a real transfer of funds.

**Transfers between virtual wallets.** Internal transfers between two virtual wallets are simple virtual balance movements — **no blockchain transactions occur**. This prevents unnecessary holding wallet deductions for in-ecosystem operations.

## Managing the holding wallet

<AccordionGroup>
  <Accordion title="Deposit external funds">
    Companies can deposit cryptocurrency directly into the holding wallet from external sources for flexible resource management.
  </Accordion>

  <Accordion title="Withdraw to external wallets">
    Withdrawals are limited to the on-chain funds available in the holding wallet — no overdrafts are allowed. Keep sufficient balance to cover external withdrawals initiated from virtual wallets.
  </Accordion>

  <Accordion title="Transfer to a virtual wallet">
    The company can credit a client's virtual wallet even without enough holding wallet balance. This increases the company's debt to the client and should be used deliberately.
  </Accordion>
</AccordionGroup>

## Company clients and ramp operations

### What is a company client?

A **company client** is an end user that has completed KYC verification and can perform ramp operations (fiat-to-crypto and crypto-to-fiat).

### Client-wallet relationship

* **One wallet → one client.** Each virtual wallet is associated with exactly one client.
* **One client → multiple wallets.** A client can own multiple wallets across blockchains or purposes.
* **Active wallets only.** Only wallets in `active` status can be associated with a client.

### Prerequisites for ramp operations

<Steps>
  <Step title="Client creation">
    Complete KYC with personal ID documents, address verification, tax identification number (country-specific), and contact information.
  </Step>

  <Step title="Bank account setup">
    For off-ramp operations, at least one verified bank account must be linked to the client.
  </Step>

  <Step title="Active wallet association">
    At least one active virtual wallet must be created and associated with the client.
  </Step>
</Steps>

### On-ramp (fiat → crypto)

1. The client initiates an on-ramp request and receives fiat deposit information.
2. Funds are received and verified.
3. The equivalent amount of cryptocurrency is credited to the client's virtual balance.
4. The real assets are held in the holding wallet; the client's virtual balance reflects ownership.

### Off-ramp (crypto → fiat)

1. The client initiates a withdrawal from their virtual wallet to their bank account.
2. The system deducts the virtual balance.
3. Real cryptocurrency is transferred out of the holding wallet for fiat conversion.
4. Fiat currency is sent to the client's linked bank account.

### Colombian Peso (COP) ramps

COP ramps support two payment rails with different user experiences. You select the rail per operation by sending `payment_rail` in [Create bank ramp-on](/api-reference/virtual-wallets/ramps/bank-ramps/create-bank-ramp-on); for ramp-off the rail is inferred from the destination [bank account](/api-reference/management/clients/bank-accounts/list-bank-accounts).

<Note>
  All COP ramp-offs require a `reference` field (max 18 characters) — the concept that will appear on the recipient's bank statement.
</Note>

#### CO Bank Transfer (PSE)

PSE (Pagos Seguros en Línea) is a redirect-based flow. When you create a ramp-on with `payment_rail: "co_bank_transfer"`, you must also send a `redirect_url` — the URL will send the user back to after they authorize the payment with their bank.

1. You call [Create bank ramp-on](/api-reference/virtual-wallets/ramps/bank-ramps/create-bank-ramp-on) with `source_currency: "COP"`, `payment_rail: "co_bank_transfer"`, and a `redirect_url`.
2. The response includes a `start_url` — redirect the user there to begin the PSE checkout in their bank's interface.
3. The user selects their bank, logs in, and authorizes the COP transfer.
4. After authorization the user is sent back to your `redirect_url`.
5. Bridge processes the payment, credits the equivalent crypto amount to the virtual balance, and emits a `ramp_on` webhook event.

#### Bre-B

Bre-B is a key-based flow — no redirect. When you create a ramp-on with `payment_rail: "bre_b"`, the response includes a `bre_b_key` that you display to the user.

1. You call [Create bank ramp-on](/api-reference/virtual-wallets/ramps/bank-ramps/create-bank-ramp-on) with `source_currency: "COP"` and `payment_rail: "bre_b"`.
2. The response includes a `bre_b_key` — display it to the user so they can copy it.
3. The user opens their bank app, chooses "Pay with Bre-B", pastes the key, and sends the COP.
4. Bridge processes the payment, credits the equivalent crypto amount to the virtual balance, and emits a `ramp_on` webhook event.

For ramp-off the client must have an existing Bre-B [bank account](/api-reference/management/clients/bank-accounts/create-bre-b-bank-account) registered with the destination Bre-B key. Funds are sent from the holding wallet to that account.

## Webhooks

Active Management emits events with `product: "virtual_wallets"` so you can drive your UI and accounting as soon as funds move. Register a webhook URL and `webhook_key` from the Portal (or via the [Subscribe webhook URL](/api-reference/management/company/subscribe-webhook-url) and [Subscribe webhook key](/api-reference/management/company/subscribe-webhook-key) endpoints).

| Event      | When it fires                                                                                    |
| ---------- | ------------------------------------------------------------------------------------------------ |
| `deposit`  | A client deposit into a virtual wallet is detected on-chain and credited to the virtual balance. |
| `withdraw` | A withdrawal from a virtual wallet to an external address completes.                             |
| `ramp_on`  | A fiat-to-crypto ramp completes and the equivalent virtual balance is credited.                  |

See [Webhooks](/integration/webhooks) for the full envelope, authentication via `X-Webhook-Key`, retry behavior, and payload examples.

<Card title="Active Management API reference" icon="terminal" href="/api-reference/virtual-wallets/index" horizontal>
  Explore endpoints for wallets, holding, configuration, and ramps.
</Card>