Practical Ways to Assign Trading Fees to Each Filled Order
Explore reliable methods for assigning trading fees to individual orders, covering attribution models, capture timing, risk limits, and reconciliation steps.
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01Fee attribution can follow per‑order, batch‑prorated, or period‑based models depending on data availability.
- 02Capturing fees pre‑trade, post‑trade, or at settlement each impacts balance accuracy and risk visibility.
- 03Owner‑signed limits can enforce daily or per‑order fee caps but do not remove market or operational risk.
- 04Reconciliation compares system records with venue statements using unique identifiers and timestamps.
- 05Transparent fee assignment improves decision‑making while acknowledging estimation uncertainty.
Assigning trading fees to each filled order requires a clear rule that aligns with the reporting horizon and respects the risk controls defined by the owner. The most direct approach records the exact fee returned by the venue for the order at settlement, while alternative methods such as prorating a batch total are useful when only aggregate data is available. Accurate fee attribution supports reliable performance metrics, informs risk limits, and simplifies regulatory reporting.
What attribution models are available?
- Per‑order attribution records the fee reported for each individual order, providing the highest granularity.
- Batch prorating divides a total fee amount across a set of orders based on notional or volume, useful when venue data is only available in aggregates.
- Period‑based allocation applies fees to a reporting period after settlement using a reconciliation step that matches fees to orders retrospectively.
When should fees be captured in the workflow?
- Pre‑trade capture estimates the fee before execution, useful for budgeting but may differ from the actual cost.
- Post‑trade capture records the fee immediately after the order fills, providing higher accuracy for intraday reporting.
- Settlement capture records the fee when the venue confirms settlement, ensuring the final amount is known and immutable.
What are the downsides of each capture timing?
Pre‑trade estimates can be misleading if venue fee structures change or if the order is routed differently than expected. Post‑trade capture improves accuracy but requires reliable real‑time data feeds; any latency can cause temporary mismatches. Settlement capture offers certainty but introduces a delay that may obscure short‑term cost exposure and affect risk metrics that rely on timely fee information.
How do fee limits interact with risk controls?
Owner‑signed limits can include daily fee caps or per‑order fee ceilings. If a calculated fee would exceed a limit, the trade‑scoped agent key is rejected and the owner must review the request. These limits reduce unexpected cost spikes but cannot guarantee that all fees stay within budget because venue fee structures may change without notice.
Can limits be adjusted dynamically?
Limits can be updated by the owner through signed policy changes, but each update must be recorded and propagated to active agent keys before new orders are accepted. Dynamic adjustment helps respond to market‑wide fee changes, yet it introduces operational overhead and requires careful audit trails.
How should fee reconciliation be performed?
Reconciliation compares the fee records stored in the trading system with the official statements from each venue. Any discrepancy should trigger an investigation because a timeout or missing data does not prove an order failed. Durable mutation identifiers and explicit error states help trace the source of mismatches.
- 01Collect venue fee reports at the end of each settlement cycle.
- 02Match each reported fee to the corresponding order using unique identifiers.
- 03Flag any unmatched or mismatched entries for manual review.
- 04Update the system ledger only after successful verification.
Helpful references and tools
- Review the guidance on Assigning Trading Fees to Each Executed Order for detailed examples.
- Read about Why Fees and Slippage Change a Trading Backtest to understand the impact on strategy evaluation.
- Explore the basics of fee attribution in How to Attribute Trading Fees to Executed Orders.
Frequently asked questions
Per‑order attribution gives the most accurate cost picture, but it requires that the venue provides fee data for each order. If only batch totals are available, prorating may be necessary, acknowledging the added estimation error.
Settlement capture ensures the final fee amount is known, but it introduces a delay in cost visibility, which can temporarily inflate reported performance and affect risk metrics.
Limits can restrict the maximum fee per order or per day, causing the system to reject orders that would exceed those caps. However, limits do not eliminate the risk of unexpected fee changes from the venue.
First, verify the unique identifiers used for matching. Then, compare timestamps and source data to locate the discrepancy. If the mismatch persists, flag it for manual review and consider adjusting the attribution model.
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.
Copying a trading strategy can speed up learning, but it also brings the original risk profile. This guide outlines the limits, key scoping, emergency stop handling, and data validation needed to protect your capital.
AI trading bots continuously process market data, use trained models to create trade signals, and convert those signals into signed orders while enforcing strict risk controls and safety checks.