The "News Nuke" - Close All Positions Safely During Extreme Volatility

[PTScalper]

Pine Script runs in the cloud and evaluates on bar/tick updates. It cannot natively read your real-time broker spread, loop through active account tickets, slice lot sizes, or handle requote execution loops (Sleep() does not exist in Pine).

To achieve the "V3 Enterprise" logic using TradingView, you have to split the architecture into two parts:

1.) The Signal Engine (Pine Script): Detects the condition or manual trigger and fires a JSON Webhook.

2.) The Execution Bridge (Your Server/EA): A webhook receiver (like PineConnector, AutoView, or a custom Python script on your cloud server) that receives the payload and executes the retry/slicing/spread logic locally on the terminal.

The Pine Script Code (v5)

Code: Select all

//@version=5
strategy("News Panic Close Bridge [Enterprise]", overlay=true, calc_on_every_tick=true)

// =====================================================================
// 1. INPUTS & TRIGGERS
// =====================================================================
grp_exec = "--- Execution Triggers ---"
// A manual toggle you can click in the UI to instantly fire the close protocol
panic_button  = input.bool(false, title="🚨 MANUAL PANIC BUTTON", group=grp_exec, confirm=true)
news_time_hr  = input.int(14, title="Auto-Close Hour (Server Time)", minval=0, maxval=23, group=grp_exec)
news_time_min = input.int(29, title="Auto-Close Minute", minval=0, maxval=59, group=grp_exec)
auto_trigger  = input.bool(false, title="Enable Auto-Time Close?", group=grp_exec)

grp_bridge = "--- Webhook Bridge Settings ---"
// Standard routing syntaxes for execution bridges (e.g., PineConnector)
license_id    = input.string("YOUR_LICENSE_ID", title="Bridge License ID", group=grp_bridge)
sym_override  = input.string("", title="Symbol Override (Leave blank for chart)", group=grp_bridge)

// =====================================================================
// 2. LOGIC & ROUTING
// =====================================================================
// Determine target symbol format for the bridge
target_sym = sym_override == "" ? syminfo.ticker : sym_override

// Check time-based auto trigger
is_news_time = auto_trigger and (hour == news_time_hr) and (minute == news_time_min) and (second == 0)

// Master trigger condition
trigger_close = panic_button or is_news_time

// Ensure we only fire once per trigger event
var bool alert_fired = false
if (trigger_close and not alert_fired)
    
    // 1. Flatten the local TradingView strategy (Visual sync)
    strategy.close_all(comment="PANIC CLOSE EXECUTED")
    strategy.cancel_all()
    
    // 2. Construct the Webhook Payload (Adjust syntax for your specific bridge)
    // Example format: licenseID,cmd,symbol,risk
    string alert_msg = license_id + ",close_all," + target_sym
    
    // 3. Fire the execution webhook to the broker terminal
    alert(alert_msg, alert.freq_once_per_bar)
    
    alert_fired := true

// Reset the trigger lock once the condition passes
if (not trigger_close)
    alert_fired := false

// =====================================================================
// 3. VISUALS
// =====================================================================
bgcolor(trigger_close ? color.new(color.red, 70) : na, title="Panic Flash")

The Missing V3 Logic (Spread, Slicing, Retries)
Because Pine Script cannot read MODE_MAXLOT, MODE_SPREAD, or broker requotes, you must configure the V3 logic on the receiving end.

If you are writing your own custom Python webhook receiver (which is highly recommended for high-volume scalping rather than relying on a commercial bridge), your backend flow should look like this:

[LondonNewsTrader]

If this is running on an optimized server setup—like a low-latency VPS physically located near the broker's data center—the Sleep(50) commands inside the trade context loops will process incredibly fast.

There's a problem with the slicing that will show up exactly when it's needed. After the first partial OrderClose, MT4 closes the original ticket and opens the remainder under a new ticket number. The loop then calls ExecuteClose with the old OrderTicket(), which no longer exists, so the second slice fails as a fatal error and the rest of the position stays open. The remainder has to be found again, for example by searching for the order whose comment contains "from #" plus the old ticket. In practice the slicing branch rarely runs anyway, since an order can't be opened above MODE_MAXLOT in the first place.

The spread check is the part I'd reconsider for a panic script. It skips any position whose spread is above 150 points, but in a real news shock that's when spreads are widest, so the script refuses to close the positions you most want closed. A warning in the log is useful; skipping the close probably isn't.

I'd also delete the pending orders in a first pass and close positions in a second, so no stop entry triggers while the script is working through the list.

[FXS Prop Desk]

A close-all script is one of the most practical tools a scalper can have, and you are right that clicking through positions one by one during a news spike is far too slow.

One thing we would add: a retry loop with a short wait when the close fails because of a requote or "off quotes" error, plus a log of the actual closing price and spread for each position. After a few news events that log tells you a lot about how your broker behaves under stress.

It is also worth testing the script on a demo during a real release, not just on a quiet market. Some brokers reject rapid sequential orders, and it is better to discover that before you really need it.