Daily Notional Limits: How They Protect a Trading Agent
Learn how a daily notional limit caps the total value an agent can order each day, the enforcement steps the system follows, and how owners can safely adjust
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01The daily notional limit caps the total trade value an agent may submit in a 24‑hour period.
- 02It is enforced by an owner‑signed policy attached to the agent’s scoped key.
- 03The limit only restricts order placement; it does not close positions or affect token allowances.
- 04Once the limit is reached, further orders are rejected until the next daily reset.
- 05Owners can modify or revoke the limit, but changes apply only to future orders.
A daily notional limit defines the maximum aggregate value of orders a trading agent may place within a calendar day. The limit is checked when the agent signs an order with its scoped key, and any order that would push the cumulative notional above the ceiling is rejected until the limit resets at the start of the next day. This simple control lets owners bound exposure while preserving the agent’s ability to act autonomously within defined parameters.
Why Implement a Daily Notional Limit?
Limiting daily notional provides a quantitative guardrail that aligns with an owner’s risk appetite. It prevents a runaway algorithm from exhausting capital in a short burst, especially during volatile market conditions. The limit works alongside other policy fields such as order-size caps, daily loss thresholds, and expiry dates to create a layered risk-management framework.
What risk scenarios does the limit address?
The limit mitigates the risk of rapid, high-value order spikes that could deplete allocated capital before the owner can intervene. It also reduces the impact of coding errors that might generate unintended large orders.
How Is the Limit Enforced by the System?
When an owner creates an agent key, they attach a signed policy that specifies the daily notional ceiling. Each order submitted includes the intended notional amount; the runtime aggregates these values and compares the total to the stored limit. If the new order would exceed the ceiling, the system returns a deterministic error and does not forward the order to the venue. This check is independent of market data quality. For related context, see When Should a Trading Agent Use a Market Order vs a Limit Order?.
Which internal components perform the check?
The enforcement logic resides in the runtime that validates signed orders against the owner‑provided policy. It uses the cumulative counter stored in the agent’s state, ensuring that the limit is applied consistently across all venues.
What Happens When the Limit Is Reached?
Reaching the limit does not automatically close existing positions or cancel pending orders. Those actions require separate owner authority. The agent simply stops receiving approval to place new orders until the next daily reset. Owners may manually adjust the limit, revoke the agent key, or invoke an emergency stop, each of which has distinct operational implications.
Does the system reset the counter at a fixed time?
Yes, the counter resets at UTC midnight each day. Owners can change the reset timezone only by deploying a new policy that defines a custom reset schedule.
When Might a Daily Notional Limit Be Insufficient?
The limit controls only the aggregate notional of placed orders, not the potential loss from those trades. A series of small, losing positions can still deplete capital even if the notional ceiling is never reached. Additionally, the limit does not protect against external risks such as venue outages, smart‑contract bugs, or extreme market volatility that can affect execution quality.
Can other controls complement the notional limit?
Yes. Owners often pair a daily notional limit with a daily loss cap, an emergency stop, and least‑privilege key scopes to create a comprehensive safety net. For related context, see Understanding Daily Notional Limits for Trading Agents.
How Can Owners Adjust or Complement the Limit?
Owners can modify the daily notional value by issuing a new signed policy for the agent key. The change takes effect for subsequent orders but does not retroactively affect trades already executed. Complementary controls such as a daily loss cap, an emergency stop, or tighter key scopes provide additional layers of protection.
Where can I find guidance on related controls?
For a broader view of safety mechanisms, see the discussion on emergency stops in the article What an AI Trading Emergency Stop Actually Does.
A daily notional limit is a safety net, not a guarantee of profit or loss avoidance.
- The limit caps total order value, not realized loss.
- It is enforced at order signing, not by market conditions.
- It does not close positions; separate owner actions are required.
- Reaching the limit only stops new order placement.
- Owners can update the limit via a new signed policy.
Frequently asked questions
A daily notional limit caps the total value of orders an agent can place, while a daily loss limit caps the amount of realized loss the owner is willing to tolerate in a day.
Yes, the owner can issue a new signed policy that updates the limit. The new value applies only to orders submitted after the policy change.
No. The limit only stops new order placement. Closing positions requires a separate owner‑authorized action.
An emergency stop revokes the calling key, preventing further activity, but it does not automatically close positions or reset the notional counter. Those steps must be handled separately by the owner.
The system requires verified market data for order validation. If data is missing or flagged as stale, the order is rejected and the notional counter is not incremented.
Sources and verification
Product claims in this article were checked against these first-party references. Runtime status remains authoritative for current availability.
- Felix documentationfirst party
- Felix machine referencefirst party
Build with Felix now.
Felix infrastructure is live through MCP and the API. The Felix V1 retail quant-desk private beta is planned for September 22.
An AI trading agent needs clear exit strategies to protect capital and meet owner policies. This article explains exit‑plan components, timing, and safe execution practices.
Effective risk management is essential for any automated trading system. This guide explains how to set owner‑authorized limits, monitor market data quality, handle execution failures, and use emergency stops without assuming safety or profit guarantees.