Skip to main content
A cascade fee lets an upstream master receive a percentage of the performance fees earned by a direct downstream master. It is separate from trade propagation:

Example hierarchy

Consider this direct hierarchy:
If Master B receives 200.00 USD in performance fees from its followers and the agreement with Master A has fee_rate=0.20:
The system debits 40.00 USD from Master B’s PAYMENT account and credits 40.00 USD to Master A’s PAYMENT account.
The fee is calculated on the performance fee actually credited to Master B. It is not calculated on Investor C’s profit, Master B’s balance, or trading volume.
Cascade-fee credits do not generate another cascade fee. Each agreement applies only to the regular performance-fee income of its direct downstream master.

Requirements

Before activating an agreement, confirm all of the following:
  • The upstream and downstream accounts are different, active MAM masters.
  • The downstream master is enabled as a follower and uses propagation_mode="CASCADE".
  • An active direct allocation exists from the upstream master to the downstream master.
  • Both masters have valid dedicated PAYMENT accounts.
  • The two PAYMENT accounts are different and use the same currency.
  • The downstream master does not already have another active cascade-fee agreement.
The rate must be greater than 0 and no greater than 1. Send 0.20 for 20%.

Activate an agreement

An identical request for the same active relationship and rate is safe to repeat. To change the upstream parent, deactivate the existing agreement first and then activate the new direct relationship.

When the charge is created

The cascade fee does not have an independent schedule. A charge is created only after the downstream master receives a performance-fee credit. This means it follows the downstream master’s performance-fee collection events: The API snapshots the credited performance-fee amount and the agreement rate:
The final amount is rounded to the two-decimal precision used for MT5 balance operations.

Settlement lifecycle

Cascade-fee settlement is asynchronous:
  1. A charge is created after the downstream performance-fee credit.
  2. The amount is reserved in the downstream PAYMENT account.
  3. The downstream PAYMENT account is debited.
  4. The upstream PAYMENT account is credited.
  5. The charge reaches EXECUTED.
If the upstream credit needs to be retried after the downstream debit, the charge remains DEBITED. The debit is not repeated.

PAYMENT balance and withdrawals

Retrieve the downstream master’s PAYMENT balance with its operational login:
The response distinguishes the MT5 amount from the amount available through the MAM API:
Always use withdrawable. It subtracts pending cascade-fee obligations from the amount reported as withdrawable by MT5.
Do not withdraw directly from the PAYMENT account in MT5. An external withdrawal can consume reserved funds and cause a cascade fee to become UNCOLLECTED.

Update or deactivate

Update the rate for future charges:
Deactivate the agreement:
The path identifies the downstream master. Updating the rate affects only charges created afterward. Deactivation prevents future charges but does not cancel charges that already exist.

Reconcile charges

List charge history with filters such as master login, status, currency, and date:
Use GET /api/v1/mam/cascade-fees/summary for counts and amounts grouped by currency. The complete filters, response fields, and status definitions are available in the cascade-fee reference.
Cascade-fee processing events are currently internal service events. They are not delivered to the customer webhook registered through /api/v1/mam/webhooks.
Last modified on September 7, 2026