# Paper trading vs. live trading: what changes?

> The main difference is not the interface. It is who confirms identity, orders, fills, funds, and risk state. Similar screens can represent very different facts.

Canonical HTML page: https://qanterion.com/blog/paper-vs-live-trading

**Short answer:** Local simulation validates interface and logic. Paper trading records virtual orders, fills, and ledger state on a server. Live trading also requires real broker or exchange execution, funding, and risk infrastructure. Similar screens do not represent the same business facts.

## The core differences

| Dimension        | Local simulation              | Paper trading                       | Live trading                           |
| ---------------- | ----------------------------- | ----------------------------------- | -------------------------------------- |
| Primary use      | Interface and flow validation | Rule and server-workflow validation | Real market execution                  |
| Account funds    | Sample or local state         | Server-owned virtual ledger         | Real account and funding records       |
| Orders and fills | Locally simulated             | Paper matching or execution model   | Broker/exchange confirmation           |
| Risk controls    | Guidance or local rules       | Server-owned paper risk             | Real risk and execution constraints    |
| Funding          | No real movement              | No custody settlement               | Requires payment, custody, or clearing |

## What local simulation can validate

Simulation is useful for checking whether the product is understandable and the strategy workflow is complete. It can help users learn:

- how to read accounts and strategies;
- how to start, pause, or stop a simulated run;
- how to interpret positions and risk;
- how funding request states are organized.

Browser state does not prove that a server accepted an order and cannot change a real balance.

## What server-owned paper trading adds

Paper trading usually gives the server ownership of identity, commands, execution, and ledger state. Even without a live market connection, it can validate:

- sessions and permissions;
- accepted, rejected, and idempotent commands;
- virtual orders, fills, positions, and P&L;
- server-owned risk rules;
- traceable ledger and event history.

This is closer to a production workflow, but it does not silently become live trading.

## What live trading still requires

Live operation needs several conditions at once:

1. account identity and trading permissions;
2. an available and compliant market, broker, or exchange connection;
3. real order and fill acknowledgements;
4. custody, payment, clearing, or financial-ledger capability;
5. risk limits, monitoring, audit, and incident handling;
6. product, regional, and user eligibility.

A UI setting or “live” toggle cannot replace these conditions.

## Reading state labels correctly

In a trading terminal:

- “submitted” means intent was sent or recorded;
- “accepted” does not mean filled;
- “running” must identify whether local, paper, or trading-core state confirms it;
- “completed” should have a corresponding order, fill, ledger, or platform record.

Precise state language prevents process from being mistaken for outcome.

## The current QANTERION boundary

QANTERION currently focuses on simulation and paper-trading workflows. Live execution, custody, and real-money processing become available only when the related services, account permissions, and compliance conditions are explicitly enabled.

For the paper-first workflow described above — live market data, realistic fills, fees, and risk context — see [crypto paper trading](/paper-trading) on QANTERION.

Continue with [What is an AI quant trading terminal?](/blog/ai-quant-terminal-guide), then review the [FAQ](/faq) and [risk disclosure](/legal/risk).