Ensuring a Live Account‑Value Figure Is Trustable
A step‑by‑step guide to confirming that a live account‑value figure reflects accurate market data, proper key controls, and reliable reconciliation.
Produced with automation, then checked by deterministic quality rules and an independent source-grounded review before publication.
- 01The market price source, timestamp, and freshness warnings must be visible and validated.
- 02Owner‑authorized keys hold ultimate control while agent keys operate under documented scope limits.
- 03Unique mutation identifiers allow precise tracing of each order through the system.
- 04Explicit error codes separate network issues from genuine order rejections.
- 05Independent verification combines data freshness, transaction reconciliation, and key‑policy checks.
A live account‑value figure is trustworthy when the price feeding the balance, the permissions governing the funds, and the record‑keeping of each trade can all be independently confirmed. This requires a clear data source, immutable identifiers for every mutation, and transparent error reporting. Together these elements prevent hidden mismatches.
What market‑data attributes guarantee price reliability?
A price used in the account‑value calculation must include three core attributes: the originating exchange or aggregator, an exact UTC timestamp, and any freshness or delay warnings. Without these, the figure may be based on stale or erroneous information, which can mislead risk assessments.
- The feed identifier (e.g., NYSE, a certified aggregator, or another exchange).
- The precise timestamp when the price snapshot was generated.
- Coverage details that list which symbols are included in the feed.
- Explicit warnings if the data is delayed, missing, or flagged for quality issues.
How do ownership and agent keys affect balance integrity?
Funds are ultimately controlled by an owner key. Agent keys operate under scopes that the owner defines, such as maximum order size, daily notional caps, or expiry windows. Because withdrawals require a separate owner‑signed intent, the live account‑value figure reflects only the portion of capital that can be moved under the current agent permissions.
- The owner key retains ultimate authority over all balances.
- Agent keys are limited by explicit policy fields documented in the platform’s reference guide.
- Withdrawal actions need a distinct owner signature, preventing accidental fund loss.
- Policy limits are enforced in real time by the runtime status endpoint.
Why are durable mutation identifiers essential for reconciliation?
Every order mutation receives a unique identifier that persists across the ingestion, matching, and settlement layers. Auditors can trace a mutation ID from the initial request through to the final balance adjustment, even if a network timeout occurs. This prevents a timeout from being mistakenly recorded as a failed trade, which would otherwise distort the account‑value figure.
- Immutable IDs link each order to its eventual fill or rejection.
- Reconciliation processes match mutation IDs with balance changes.
- Timeout events are logged separately from explicit success or failure codes.
What role do explicit error states play in the verification chain?
The system distinguishes between network timeouts, validation rejections, and successful executions using discrete error codes. When an error is recorded, verification logic can decide whether the account‑value figure should remain unchanged (e.g., for a timeout) or be adjusted (e.g., for a confirmed rejection).
- Network timeout - no balance change until a definitive outcome is received.
- Validation error - order rejected, balance stays the same.
- Execution success - balance updated according to the fill details.
How can a trader independently confirm a live account‑value figure?
Independent confirmation follows three practical steps:
- 01Validate market‑data freshness by fetching the latest price, its source, and timestamp.
- 02Reconcile each mutation ID with the recorded fill and resulting balance change.
- 03Verify that the active agent key respects its scoped limits and that any withdrawal requires a fresh owner signature.
Verification is only as strong as the weakest link in the data, control, or reconciliation chain.
For deeper insight into related verification topics, see the guide on How an AI Trading App Can Verify Live Cash and PnL, the article on Daily Notional Limits: How They Protect a Trading Agent, and the reference on Testing Position Sizing Across Different Account Sizes.
Frequently asked questions
Treat the missing price as unavailable rather than zero and wait for a fresh update before trusting the account‑value figure.
No. A timeout indicates uncertainty; the system must wait for an explicit success or error message before adjusting the balance.
Limits reduce exposure but cannot eliminate loss risk; market moves can still exceed configured caps.
Reconciliation should occur after each batch of orders and periodically during idle periods to catch any missed updates.
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
- Felix runtime statuslive status
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.
Assigning capital to a trial trading agent requires clear owner‑signed limits, continuous data monitoring, and a reliable emergency stop. This guide walks through setting up controls, tracking performance, and protecting assets while testing new strategies.
A daily notional limit caps the total value an agent can trade each day, offering a clear risk guardrail. This guide explains the mechanics, benefits, and practical considerations for using this control.