What does cTrader NoMoney mean?
NoMoney means the account lacks enough available funds/margin for the requested operation. Reduce exposure or investigate margin, leverage and existing positions instead of resending unchanged.
Why this matters
Reliable automation separates signal calculation, TradingView alert generation, webhook transport, connector processing, cTrader execution and broker outcome. A user should be able to identify the last stage that definitely succeeded and inspect the next one.
Automation chain
Pine / TradingView logic
→ server-side alert
→ webhook delivery
→ NRUNO validation/routing
→ cTrader execution
→ broker result
→ final order/position
Real-world scenarios
Scenario A — Oversized volume
How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.
Scenario B — Existing positions consume margin
How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.
Scenario C — Leverage/margin changes
How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.
Deep diagnostic workflow
- Record symbol, timeframe, UTC timestamp, alert name and intended action.
- Prove the TradingView trigger using the alert log.
- Record webhook delivery status and HTTP result.
- Record receiver validation, normalized command and signal ID.
- Record cTrader dispatch and exact TradeResult/error.
- Verify the final position/order state.
- Change one variable at a time and retest on demo.
Worked example — EURUSD
A EURUSD long signal should be traceable from the TradingView event through the final cTrader result. If TradingView fired at 10:00:00, NRUNO received at 10:00:00.120, dispatched at 10:00:00.130 and cTrader rejected at 10:00:00.180 with BadVolume, the webhook was not the failure. The execution parameters were.
Worked example — fast 1-minute automation
A trader sees a live signal during an open candle but later cannot reproduce it historically. First determine whether the script intentionally used realtime updates. Only after separating Pine timing from network and broker timing should latency or connector behavior be blamed.
Reliability / failure policy
- Every signal gets a unique lifecycle: received → validated → dispatched → accepted/rejected.
- Duplicate delivery must be safe.
- Transport retry and broker retry are different decisions.
- Stale signals need an explicit expiry policy.
- Broker errors should remain visible and exact.
- Never silently transform an invalid command into a different trade.
- Demo testing must include failure paths, not only successful entries.
NRUNO implication
NRUNO is the execution connector, not the signal generator. For this topic its UI should distinguish webhook received, validation rejected, duplicate ignored, cTrader unavailable, dispatched, broker accepted and broker rejected. That distinction also makes support questions reusable as future Wiki scenarios.
Primary sources
Need a TradingView → cTrader execution route?
NRUNO routes your TradingView instructions to cTrader. Your strategy and signal logic remain yours.