Three environments, three different questions
An internal simulator creates prices and fills inside an application. It helps you work through controls, rules, and states without connecting a brokerage account. Its fills reflect the simulator’s assumptions.
A paper or sandbox account usually uses a broker’s test services. It can reveal authentication problems, invalid order formats, rejections, and API responses. Market data and fill conditions may differ from live trading; the details depend on the provider.
A live account sends instructions to a real account. Even there, an accepted order is not necessarily a filled order. Keep submission, acceptance, partial fill, full fill, cancellation, and rejection separate.
What to test at each stage
| Question | Simulator | Paper | Live |
|---|---|---|---|
| Do I understand the workflow and controls? | Useful | Useful | Also useful |
| Will the API accept this instruction? | Does not prove it | Depends on the broker | Yes, for that account |
| What will the final price be? | Does not prove it | Does not guarantee it | Known after the fill |
| How will I handle a rejection? | If simulated | Can be observed | Must be supervised |
With options, the gap can be wider when bid-ask spreads are large or liquidity changes. A screenshot of a paper result does not show that the same price was available to a real order.
Keep an honest test log
- Write down the specific hypothesis, such as “a manual close appears in the history.”
- Record the environment, date, instrument, order type, and size.
- Save what you observed: acceptance, rejection, fill, and elapsed time.
- Mark what you did not test, such as live liquidity or behavior during a disconnection.
Moving to live trading is a personal risk decision. A run of simulated results cannot make that decision for you.