Setting a monthly cap on automated buys is the primary risk-sizing control available to VelaDeck users. Without it, a strategy that rotates several holdings in a single month can deploy far more capital than you planned for.
Without a cap, a busy rebalance can surprise you
Monthly strategies issue one BUY signal for each ticker that enters the composition. A strategy holding 20 names might replace four to six of them in a given month. At $500 notional per holding, that is $2,000–$3,000 deployed in a single week — which may exceed your Alpaca cash position or simply be more than you intended for that period.
The monthly cap sets a hard ceiling on total BUY notional for a given strategy within a calendar month. SELL and REWEIGHT signals are not subject to it — those execute against positions you already hold.
How the monthly cap works mechanically
The cap is per-strategy and per-calendar-month. When VelaDeck plans a BUY, it totals all BUY notional already planned or sent for that strategy in the current month. If the new order would push the running total above the cap, the row is written with status `skipped_over_cap` instead of `planned`.
The signal detail is still fully visible on the dashboard — ticker, notional, direction, and the reason it was held back. Nothing disappears silently.
At the start of each calendar month, the counter resets to zero.
Sizing the cap: three starting frames
There is no universal correct number. Three frames to start from:
- **Cash-flow sizing.** If you fund your Alpaca account monthly, set the cap to roughly what you deposit. The strategy can never spend faster than you refill.
- **Allocation fraction.** A common approach: cap at 20–30% of the total USD assigned to a strategy. A $5,000 allocation in US20 with a $1,000–$1,500 cap limits any single month to about one quarter of the assigned balance — enough room for a partial rebalance without deploying everything at once.
- **Signal frequency.** US20 and SP20 typically rotate 3–6 positions per month; DOW10, with only 10 total holdings, is more stable. A cap of 3–4× the per-holding notional usually lets a normal rebalance through without triggering `skipped_over_cap`.
VelaDeck does not custody funds and does not recommend allocation sizes — the sizing decision is yours. These are mechanical frames, not advice.
What happens to a skipped order
A `skipped_over_cap` row is not carried forward to the next month. It stays in the dashboard history as a record of what was held back and why. If the ticker is still in the model composition the following month, a fresh BUY signal may be generated — which counts against the new month's cap, not the previous one.
The practical implication: a cap that is consistently too tight for the strategy's normal turnover will cause some holdings to never be purchased. The portfolio held in Alpaca will drift away from the model composition over time. That is a valid trade-off when cash constraints require it — but worth monitoring.
You can close any accumulated gap by running the sync tool, which compares what the strategy should hold against what has actually been bought and fills in the difference. Sync-generated orders carry type `SYNC` so they do not mix with the regular BUY/SELL signal history. See [how VelaDeck automates monthly rebalancing](/blog/how-veladeck-automates-alpaca-rebalancing) for more on the ingester and diff cycle.
Getting started with a monthly cap
- Open the allocation settings for any [strategy](/strategies).
- Set the monthly cap to the maximum USD you want deployed as new BUYs in any calendar month for that strategy.
- Run in paper mode first. Let one full rebalance cycle complete and review the order rows — any `skipped_over_cap` entries tell you whether the cap is tighter than the strategy's typical behavior.
- Adjust the cap if needed, then opt into live trading in Settings when you are satisfied.
Live trading is off by default and requires an explicit per-user toggle. Past strategy returns are historical and simulated — not a forecast of what the strategy will do going forward. Try it on paper first at [veladeck.com/signup](/signup).
How is the monthly cap different from the total allocation?
The total allocation is how much USD you have assigned to a strategy — it determines per-holding notional. The monthly cap controls how much of that notional can be deployed via BUY orders within a calendar month. The two are independent: a large allocation with a tight cap means the strategy buys a fraction of the model each month rather than the full composition.
Does the cap apply to SELL orders?
No. The monthly cap only limits BUY notional. SELL signals execute against your current position quantity and are not subject to any spending ceiling.
What happens if a skipped ticker gets dropped from the strategy before next month?
If a ticker is skipped in month A and then removed from the strategy before month B, no BUY is ever generated for it. You will not hold it — and you will also not receive the SELL signal when the strategy drops it. The composition you hold in Alpaca becomes a subset of the model rather than an exact mirror. The sync tool can surface this drift and let you decide whether to close it.
Can I set different caps per strategy?
Yes. Each [strategy allocation](/strategies) has its own monthly cap field. Higher-turnover strategies like US20, SP20, and MM20 benefit from a more generous cap. WB15 rebalances quarterly and rarely generates more than a handful of BUY signals per quarter — a low cap has minimal practical effect there.
What happens if I skip setting a monthly cap on automated buys entirely?
Without a cap, every planned BUY order is submitted. For a 20-holding strategy with $500 notional per holding, a full composition rotation could deploy up to $10,000 in one month. If that exceeds your Alpaca cash balance, Alpaca will reject or partial-fill the orders. Setting a monthly cap prevents the submission from happening in the first place — a cleaner outcome than an Alpaca rejection that leaves partial fills in an ambiguous state.