DEV Community: Gueta Quant

Monte Carlo Permutation Testing in Python: How Random Trade Order Falsifies Your Equity Curve

Gueta Quant — Mon, 28 Sep 2026 06:18:04 +0000

Your backtest equity curve is merely one historical trajectory out of millions of equally probable alternatives.

The total profit of your trading system is invariant to order: 100 closed trades will yield the exact same ending dollar return whether the winning trades arrive first or last. However, path-dependent survivability metrics—Maximum Drawdown, Ulcer Index, Margin Call Probability, and Time-to-Recovery—are dominated by trade sequence.

If a cluster of 6 normal consecutive losses strikes at trade #1 instead of trade #70, an account operating under a strict 10% risk floor (common in institutional mandates and proprietary evaluation rules) is liquidated before the positive edge ever materializes.

In this article, we formulate and implement a vectorized Monte Carlo permutation engine in Python to rigorously falsify equity curves before committing live capital.

1. Permutation vs. Bootstrap: The Critical Distinction

Many trading platforms market "Monte Carlo analysis" without disclosing their resampling methodology. In quantitative finance, the distinction is fundamental:

Dimension	Permutation Testing (Without Replacement)	Bootstrap Resampling (With Replacement)
Mechanism	Random shuffle of historical trade order	Random draw where any trade can be selected $k$ times
P&L Distribution	100% Identical to sample (same mean, win rate, skewness)	Creates synthetic distributions with altered win rates
Statistical Target	Isolates sequence risk alone	Estimates sampling error under $i.i.d.$ assumption
Vulnerability	Assumes trades are conditionally independent	Heavily distorts tail risk if outliers are oversampled

For validating an existing trading journal or strategy backtest, Permutation Testing is the strict falsification baseline. It asks the minimal, humble question: "Given the exact trades we actually took, what percentage of alternate timelines would have breached our risk budget?"

2. The 4 Path Metrics That Expose Hidden Ruin

Looking solely at backtest Sharpe ratio or nominal net profit hides ruin. When running $N=5,000$ permutations, evaluate these four metrics:

Probability of Ruin ($P_{\text{ruin}}$): The percentage of shuffled paths whose equity breaches the hard drawdown barrier (e.g., $9,000$ on a $\$10,000$ starting balance) at any point along the horizon.
Median Max Drawdown ($MDD_{50}$): The central tendency of drawdown. If your backtest showed a 7% drawdown but the median shuffled drawdown is 16%, your historical curve was an unusually lucky sequence.
95th Percentile Max Drawdown ($MDD_{95}$): The stress-test boundary. 95% of simulated timelines experienced a drawdown less severe than this number; 5% suffered worse. This is your true operational capital requirement.
Drawdown Dispersion Ratio: $MDD_{95} / MDD_{50}$. A high ratio indicates severe tail-sequence vulnerability.

3. Vectorized Python Implementation (NumPy)

Iterating across 5,000 simulations using Python loops is computationally inefficient. Below is a high-performance, fully vectorized implementation using numpy.random.default_rng().permuted:

import numpy as np
from typing import Dict, Any

def run_monte_carlo_permutation(
    trades: np.ndarray,
    initial_capital: float = 10000.0,
    ruin_capital: float = 9000.0,
    num_simulations: int = 5000,
    seed: int = 42
) -> Dict[str, Any]:
    """
    Vectorized Monte Carlo Permutation Test (Resampling Without Replacement).
    Evaluates sequence risk and ruin probability on trade P&L arrays.
    """
    trades = np.asarray(trades, dtype=np.float64)
    n_trades = len(trades)
    if n_trades < 10:
        raise ValueError("At least 10 trades required for meaningful permutation testing.")

    rng = np.random.default_rng(seed)

    # 1. Broadcast and independently shuffle across simulations (without replacement)
    sim_matrix = np.tile(trades, (num_simulations, 1))
    shuffled_trades = rng.permuted(sim_matrix, axis=1)

    # 2. Vectorized cumulative equity trajectories
    cumulative_pnl = np.cumsum(shuffled_trades, axis=1)
    initial_col = np.full((num_simulations, 1), initial_capital)
    equity_paths = np.hstack([initial_col, initial_capital + cumulative_pnl])

    # 3. Peak equity and path drawdowns
    running_peaks = np.maximum.accumulate(equity_paths, axis=1)
    drawdowns_dollar = running_peaks - equity_paths
    drawdowns_pct = (drawdowns_dollar / running_peaks) * 100.0

    # 4. Max drawdown per trajectory
    max_mdd_pct = np.max(drawdowns_pct, axis=1)

    # 5. Ruin evaluation (breaching floor at any point in time)
    min_equity_per_path = np.min(equity_paths, axis=1)
    ruin_paths = np.sum(min_equity_per_path <= ruin_capital)
    prob_ruin = (ruin_paths / num_simulations) * 100.0

    return {
        "n_trades": n_trades,
        "initial_capital": initial_capital,
        "ruin_capital": ruin_capital,
        "nominal_net_pnl": float(round(np.sum(trades), 2)),
        "num_simulations": num_simulations,
        "prob_ruin_pct": float(round(prob_ruin, 2)),
        "mdd_p05_pct": float(round(np.percentile(max_mdd_pct, 5), 2)),
        "mdd_p50_median_pct": float(round(np.percentile(max_mdd_pct, 50), 2)),
        "mdd_p95_worst_pct": float(round(np.percentile(max_mdd_pct, 95), 2)),
        "falsification_verdict": "REJECT_EXCESSIVE_RUIN" if prob_ruin > 5.0 else "PASS_ROBUST_SEQUENCE"
    }

4. Empirical Case Study: The "Profitable" Strategy That Blows Up

Consider a 100-trade sample with a 52% win rate and positive net expectation:

52 winning trades (mean profit ~\$170)
48 losing trades (mean loss ~-\$170, with occasional -\$350 tail losses)
Nominal Net P&L: +$505.39 on a \$10,000 account (profitable on paper).

When we execute run_monte_carlo_permutation over 5,000 shuffles:

# Empirical verification run
result = run_monte_carlo_permutation(
    trades=trades_sample,
    initial_capital=10000.0,
    ruin_capital=9000.0, # 10% maximum drawdown ceiling
    num_simulations=5000,
    seed=42
)

print(result)

Exact Output:

{
  "n_trades": 100,
  "initial_capital": 10000.0,
  "ruin_capital": 9000.0,
  "nominal_net_pnl": 505.39,
  "num_simulations": 5000,
  "prob_ruin_pct": 42.64,
  "mdd_p05_pct": 11.3,
  "mdd_p50_median_pct": 16.77,
  "mdd_p95_worst_pct": 25.5,
  "falsification_verdict": "REJECT_EXCESSIVE_RUIN"
}

The Institutional Reality:

Even though the original single backtest ended with +$505.39 net profit, 42.64% of all possible alternate histories breached the 10% drawdown barrier.
In 95% of histories, the drawdown reached up to 25.50%—more than double the allowable risk budget.
Without Monte Carlo permutation, a developer deploying this system would falsely attribute failure to "market regime change" or "bad luck", when in reality the strategy was statistically insolvent against basic sequence risk from day one.

5. Methodological Boundaries (What Monte Carlo Cannot Do)

A rigorous quant must understand the falsification limits of permutation testing:

Serial Autocorrelation Breakdown: Permutation randomly destroys the temporal ordering of trades. If your strategy has positive autocorrelation in losses (e.g., clustered losses during high-volatility macro announcements), permutation may underestimate clustering severity.
Out-of-Distribution Shocks: Shuffling only explores combinations of events that already occurred. It cannot simulate a 5-sigma liquidity flash crash if none was present in your historical log.
Journal vs. Market: Monte Carlo evaluates the statistical fragility of the trade sequence, not the underlying market microstructure.

6. Open Source Implementation & References

Scientific DOI: Reproducible quant code registered under CERN Zenodo: 10.5281/zenodo.22012203.
GitHub Repository: guetaquant-byte/guetaquant-tools (AGPLv3).
Interactive Tool: Browser-based Monte Carlo permutation is integrated into the client-side Local-First Trading Journal.
In-Depth Study: Full mathematical derivation and percentile bands at Gueta Quant Monte Carlo Analysis.

Aviso Regulatorio (SFC Colombia — Decreto 2555 de 2010): Este artículo tiene un propósito 100% pedagógico, educativo y de investigación en ingeniería de software financiero. Gueta Quant no presta asesoría financiera ni emite señales de inversión.

By **Mahdi Goodarzi* (g.dev/mahdigoodarzi), Founder of Gueta Quant.*

cTrader cBot Risk Engine: High-Precision C# Dynamic Stop-Loss Architecture

Gueta Quant — Mon, 21 Sep 2026 08:36:17 +0000

Static stop-losses break across volatility regimes. A fixed 20-pip stop that is conservative on EUR/USD during Asia session is noise-level on XAU/USD during New York open. In cTrader Automate (C#), the robust pattern is a dedicated risk engine: signal logic decides direction, the engine decides size and stop distance from live volatility.

This post documents the architecture — educational, no trade signals, no return claims.

1. Separate Sizing From Signals

The most common cBot flaw is inline risk math inside OnBar(): volume computed next to entry conditions, stop distance hardcoded. When volatility doubles, the same stop gets hunted and the same volume carries twice the dollar risk.

Split the cBot into two units:

Signal module — produces direction only (e.g., breakout, trend filter).
Risk engine — given direction, computes stop distance from ATR and volume from a fixed monetary budget.

// RiskEngine.cs — pure logic, no cTrader dependencies (unit-testable)
public static class RiskEngine
{
    public static double StopDistancePrice(double atr, double multiplier)
    {
        return atr * multiplier;
    }

    public static long VolumeInUnits(double riskMoney, double stopDistancePrice,
                                     double tickValuePerUnit, double pipSize,
                                     long volumeMin, long volumeMax, long volumeStep,
                                     out bool clampedToMin, out double effectiveRisk)
    {
        double raw = riskMoney / (stopDistancePrice / pipSize * tickValuePerUnit);
        long floored = (long)Math.Floor(raw / volumeStep) * volumeStep;
        clampedToMin = false;
        if (floored < volumeMin) { floored = volumeMin; clampedToMin = true; }
        long finalVolume = Math.Min(floored, volumeMax);
        effectiveRisk = finalVolume * (stopDistancePrice / pipSize * tickValuePerUnit);
        return finalVolume;
    }
}

Note the clampedToMin flag: when the budgeted volume falls below the broker minimum, the engine clamps up and reports the effective risk, which now exceeds the budget. Silently reporting the original budget while carrying higher exposure is the exact failure we dissected in The Silent Position Sizer Bug — never repeat it.

2. ATR-Based Dynamic Stops

Average True Range adapts the stop to current volatility. A 1.5x–2.0x ATR stop keeps the exit outside normal noise on any symbol and any session:

private double GetAtrStopPips(int atrPeriod = 14, double multiplier = 2.0)
{
    var atr = Indicators.AverageTrueRange(atrPeriod, MovingAverageType.Exponential);
    double stopPrice = atr.Result.LastValue * multiplier;
    return stopPrice / Symbol.PipSize;
}

Because the stop distance is measured, not assumed, the same cBot behaves sanely on a 0.0001-pip Forex pair and a 2-decimal metal without retuning magic numbers.

3. Wiring It Into the cBot

Volume in cTrader is expressed in units (100,000 units = 1.0 standard lot on FX). Always read the broker limits from the symbol — never hardcode them:

protected override void OnBar()
{
    if (Positions.Count > 0) return; // single-position example
    if (!GetSignal()) return;

    double stopPips = GetAtrStopPips();
    double stopPrice = stopPips * Symbol.PipSize;

    long volume = RiskEngine.VolumeInUnits(
        RiskMoney, stopPrice, Symbol.TickValue / Symbol.TickSize * Symbol.PipSize,
        Symbol.PipSize, Symbol.VolumeInUnitsMin,
        Symbol.VolumeInUnitsMax, Symbol.VolumeInUnitsStep,
        out bool clamped, out double effectiveRisk);

    if (clamped)
        Print("WARNING: volume clamped to broker minimum. " +
              "Effective risk {0} exceeds budget {1}.", effectiveRisk, RiskMoney);

    ExecuteMarketOrder(TradeType.Buy, SymbolName, volume,
                       "atr-risk", stopPips, null);
}

4. Trailing Without Chasing

Move the stop only when price has banked a multiple of the ATR distance — ratcheting on every tick bleeds to spread:

private void TrailAtr(Position position, double atrDistancePrice)
{
    double newStop = Symbol.Bid - 1.0 * atrDistancePrice; // long example
    if (newStop > position.StopLoss + Symbol.PipSize)
        ModifyPosition(position, newStop, position.TakeProfit);
}

5. Validation Checklist (Demo First)

Run 60 days on demo across at least two volatility regimes (e.g., Forex + metal).
Log every clamp event; if clamps exceed ~5% of trades, the risk budget is too small for the account — top up or widen the stop, never silence the warning.
Backtest with real-tick data; reject any result you cannot reproduce forward on demo.

Educational content under Colombia SFC Decreto 2555 de 2010: this is financial-engineering study material, not investment advice. No signals, no managed accounts.

By **Mahdi Goodarzi* (g.dev/mahdigoodarzi), Gueta Quant — interactive risk tools at guetaquant.com. Companion guide: cTrader Copy setup in Colombia.*

El bug silencioso de las calculadoras de lotaje: cuando la cuenta es pequeña, tu riesgo se duplica

Gueta Quant — Tue, 08 Sep 2026 15:14:42 +0000

Aviso. GuetaQuant es un portal de educación cuantitativa independiente. Este artículo es material pedagógico sobre implementación de software de gestión de riesgo. No es asesoría financiera, ni recomendación de inversión, ni captación de fondos. Operar en mercados apalancados conlleva riesgo de pérdida total del capital.

Casi todo el material sobre dimensionamiento de posición se detiene en la misma ecuación:

lotes = (balance × riesgo%) / (distancia_stop × valor_por_lote)

Es correcta, y es la parte fácil. El problema no está en la fórmula: está en las tres líneas que vienen después, cuando hay que ajustar ese número al paso de lote y al mínimo que exige el broker.

Ahí es donde encontramos un bug en nuestro propio código. Lo publicamos porque el patrón está en todas partes, y porque el error se concentra exactamente en las cuentas más pequeñas.

1. El bug: `MathMax(minLot, lotes)`

Este es el cierre habitual de una función de lotaje. Aparece en foros de MQL5, en repositorios de GitHub y estaba en el fragmento que nosotros mismos publicábamos:

double lots = MathFloor(rawLot / lotStep) * lotStep;
return MathMax(minLot, MathMin(maxLot, lots));   // <-- aquí

MathFloor está bien: redondear hacia abajo garantiza no pasarse del presupuesto. El problema es MathMax(minLot, ...).

Cuando el lote presupuestado queda por debajo del mínimo del broker, MathFloor devuelve 0.00. MathMax entonces lo sube a minLot. La función devuelve un lote operable و no dice nada.

Ese lote ya no respeta el presupuesto. Y la función sigue reportando el presupuesto original como si fuera el riesgo asumido.

2. La medición

Cuenta de 500 USD. Riesgo 0.5%. Stop de 500 ticks, valor del tick 1.00 USD.

Concepto	Valor
Presupuesto de riesgo (0.5% de 500)	2.50 USD
Lotes brutos	0.005
`floor` al paso de 0.01	0.00
Devuelto tras `MathMax(minLot, …)`	0.01
Riesgo real de esos 0.01 lotes	5.00 USD
Riesgo reportado por la función	2.50 USD

El riesgo efectivo es el doble del presupuestado, y nada en la respuesta lo indica.

No es un caso de laboratorio: es una cuenta de 500 USD operando con riesgo conservador. Es el perfil de quien más necesita que el límite se respete.

El mismo problema con `round()` en lugar de `floor()`

Una variante frecuente es usar round() en vez de floor(). Buscamos por fuerza bruta el peor caso sobre una malla de balances (500–20.000 USD), stops (5–120 pips) y riesgos (0.5%, 1%, 2%):

Paso de lote	Peor sobrepaso medido	Caso
0.01	+99.15%	balance 1.175 USD, riesgo 0.5%, stop 117 pips
0.1	+99.58%	balance 12.025 USD, riesgo 0.5%, stop 120 pips

En ambos casos los lotes brutos caen justo por encima de la mitad del paso (0.0050 y 0.0501), round() sube al siguiente escalón y el riesgo casi se duplica. El sobrepaso no está acotado a "unos centavos": está acotado a medio paso de lote, que cerca del mínimo equivale a un 100% del presupuesto.

Y un tercer caso: el valor del pip quemado en el código

Muchas implementaciones asumen valor_pip = 10 USD, que solo es cierto para pares con USD como divisa cotizada y lote estándar. En XAUUSD el valor real ronda 1 USD por pip.

Con balance de 10.000 USD, riesgo 1% (presupuesto 100 USD) y stop de 320 pips:

Asumiendo 10 USD/pip: lotes brutos 0.0312 → riesgo real 9.60 USD. Se arriesga una décima parte de lo previsto, y la estrategia queda infra-dimensionada sin que nadie lo note.
Con el valor real de 1 USD/pip: lotes brutos 0.3125 → riesgo real 99.20 USD. Correcto.

Este falla en silencio y hacia abajo, que es peor de detectar: nadie revisa una función de riesgo porque esté arriesgando de menos.

3. El arreglo

La regla es simple: si el lote presupuestado no llega al mínimo del broker, la operación no cabe dentro del riesgo definido. Subirla a minLot no es un ajuste, es cambiar el presupuesto sin avisar.

La función debe rechazar la entrada y devolver el dato para que decida la persona:

import math

def tamano_posicion(balance, riesgo_pct, sl_ticks, valor_tick,
                    paso_lote=0.01, lote_min=0.01, lote_max=100.0):
    presupuesto = balance * riesgo_pct / 100
    perdida_por_lote = sl_ticks * valor_tick
    lotes_brutos = presupuesto / perdida_por_lote

    lotes = math.floor(lotes_brutos / paso_lote) * paso_lote

    if lotes < lote_min:
        return {
            "operable": False,
            "motivo": "el lote presupuestado esta por debajo del minimo del broker",
            "lotes_brutos": round(lotes_brutos, 6),
            "presupuesto": round(presupuesto, 2),
            "riesgo_si_usas_el_minimo": round(lote_min * perdida_por_lote, 2),
        }

    lotes = min(lotes, lote_max)
    riesgo_real = lotes * perdida_por_lote
    return {
        "operable": True,
        "lotes": round(lotes, 2),
        "presupuesto": round(presupuesto, 2),
        "riesgo_real": round(riesgo_real, 2),
    }

Salida real de las dos llamadas:

>>> tamano_posicion(500, 0.5, 500, 1.0)
{'operable': False,
 'motivo': 'el lote presupuestado esta por debajo del minimo del broker',
 'lotes_brutos': 0.005, 'presupuesto': 2.5, 'riesgo_si_usas_el_minimo': 5.0}

>>> tamano_posicion(10_000, 1.0, 500, 1.0)
{'operable': True, 'lotes': 0.2, 'presupuesto': 100.0, 'riesgo_real': 100.0}

El primer caso no devuelve un lote. Devuelve el motivo y el número que hay que mirar: operar el mínimo cuesta 5.00 USD contra un presupuesto de 2.50. La decisión de aceptar ese riesgo es del trader, no de una línea de código que se lo oculta.

Y en MQL5:

double lots = MathFloor(rawLot / lotStep) * lotStep;

// Si el lote presupuestado no alcanza el minimo del broker, la operacion NO cabe
// dentro del riesgo definido. Subirlo a minLot arriesgaria mas de lo presupuestado.
if(lots < minLot) return 0.0;

return MathMin(maxLot, lots);

4. Tres reglas para revisar tu propia implementación

Nunca round(), siempre floor(). El sobrepaso de round() llega a medio paso de lote, que cerca del mínimo es ~100% del presupuesto.
Nunca subir a minLot en silencio. O se rechaza la entrada, o se devuelve el riesgo efectivo junto con una bandera de que hubo ajuste. Devolver solo el presupuesto teórico es reportar un número falso.
Nunca quemar el valor del pip. Léelo del símbolo (SYMBOL_TRADE_TICK_VALUE y SYMBOL_TRADE_TICK_SIZE en MQL5). Un 10.0 fijo rompe en oro, índices y cripto.

5. Nota de transparencia

Este bug estaba en nuestro propio código, en el endpoint público /api/position-size/, que devolvía roundedLots: 0.01 junto a riskAmount: 2.5 cuando el riesgo real era 5.00 USD. Ya está corregido: la respuesta ahora incluye effectiveRiskAmount, effectiveRiskPercent, clampedToMin y clampedToMax, y hay dos pruebas de regresión que fallan si alguien vuelve a ocultar el ajuste.

La calculadora web sí mostraba la advertencia correctamente desde el principio; el fallo estaba en la librería que alimenta la API y en el fragmento MQL5 publicado. Publicamos el error porque un portal que enseña gestión de riesgo y esconde sus propios defectos no sirve para nada.

La calculadora, la fórmula completa y el indicador en MQL5 bajo licencia AGPLv3 están acá:
Calculadora de lotaje MT5 — GuetaQuant

¿Cómo maneja tu implementación el caso de lote por debajo del mínimo? Me interesa saber si alguien lo rechaza, lo clampa o lo reporta.

Algorithmic Risk Management in MT5: ATR Volatility Position Sizing & MQL5 Architecture

Gueta Quant — Wed, 19 Aug 2026 12:30:02 +0000

Algorithmic Risk Management in MT5: Dynamic Position Sizing & MQL5 Architecture

Most retail trading failures stem from static lot sizing. Trading a fixed 1.0 lot on EUR/USD creates vastly different dollar drawdowns compared to 1.0 lot on Gold (XAU/USD) or NASDAQ (NAS100) due to differing point values and underlying volatility regimes.

In professional quantitative finance, position sizing is dynamically governed by the asset's Average True Range (ATR) and a fixed risk budget per trade:

$$\text{Position Size (Lots)} = \frac{\text{Account Balance} \times \text{Risk \%}}{\text{Stop Loss Distance (Points)} \times \text{Tick Value}}$$

In this technical guide, we implement an open-source, production-grade MQL5 risk engine that dynamically computes lot sizes and routes orders with slippage protection.

Original interactive tool and web calculator available at GuetaQuant MT5 Position Sizer.

1. MQL5 Dynamic Lot Calculation Class

//+------------------------------------------------------------------+
//|                                             GQ_RiskEngine.mqh    |
//|                             Copyright 2026, Gueta Quant (AGPLv3) |
//|                                       https://guetaquant.com     |
//+------------------------------------------------------------------+
#property copyright "Gueta Quant"
#property link      "https://guetaquant.com"

class CGQRiskManager
{
private:
   string   m_symbol;
   double   m_risk_pct;

public:
   CGQRiskManager(string symbol, double risk_pct) : m_symbol(symbol), m_risk_pct(risk_pct) {}

   double CalculateLots(double sl_distance_price)
   {
      if (sl_distance_price <= 0) return 0.0;

      double balance     = AccountInfoDouble(ACCOUNT_BALANCE);
      double risk_amount = balance * (m_risk_pct / 100.0);

      double tick_size   = SymbolInfoDouble(m_symbol, SYMBOL_TRADE_TICK_SIZE);
      double tick_value  = SymbolInfoDouble(m_symbol, SYMBOL_TRADE_TICK_VALUE);
      double min_lot     = SymbolInfoDouble(m_symbol, SYMBOL_VOLUME_MIN);
      double max_lot     = SymbolInfoDouble(m_symbol, SYMBOL_VOLUME_MAX);
      double lot_step    = SymbolInfoDouble(m_symbol, SYMBOL_VOLUME_STEP);

      if (tick_size == 0 || tick_value == 0) return 0.0;

      double loss_per_lot = (sl_distance_price / tick_size) * tick_value;
      if (loss_per_lot <= 0) return 0.0;

      double raw_lots = risk_amount / loss_per_lot;

      // Normalize to broker lot step
      double normalized_lots = MathFloor(raw_lots / lot_step) * lot_step;

      if (normalized_lots < min_lot) normalized_lots = min_lot;
      if (normalized_lots > max_lot) normalized_lots = max_lot;

      return normalized_lots;
   }
};

2. ATR Volatility Trailing Stops

Using historical volatility avoids getting stopped out during normal market noise while protecting capital during structural trend shifts:

double GetATRDistance(string symbol, ENUM_TIMEFRAMES tf, int period, double multiplier)
{
   int handle = iATR(symbol, tf, period);
   if (handle == INVALID_HANDLE) return 0.0;

   double atr_val[1];
   if (CopyBuffer(handle, 0, 0, 1, atr_val) <= 0) return 0.0;

   return atr_val[0] * multiplier;
}

3. Open Source Tools Ecosystem

All our quantitative software is published under open-source AGPLv3:

44 Open Source Trading Tools: GitHub Repository
CERN Zenodo DOI Registry: DOI 10.5281/zenodo.22012203
Local-First Trading Journal: GuetaQuant Journal

Compliance: Strictly educational and research material. Does not constitute financial advice. Compliant with Colombian SFC Decreto 2555/2010.

Pine Script v6 in 2026: math.sum, math.tanh, User Defined Types & Risk Management Engine

Gueta Quant — Wed, 19 Aug 2026 11:52:14 +0000

Overview: Pine Script v6 & Institutional Risk Architecture

TradingView's Pine Script v6 introduced critical architectural upgrades for quantitative developers. Moving beyond basic visual scripts, v6 provides strict type enforcement, built-in tensor-like math functions (math.sum(), math.tanh()), User-Defined Types (UDTs), and native webhook JSON formatting for institutional order routing.

In this guide, we break down the most essential v6 syntax upgrades and build a full production-ready risk engine with volatility-adjusted sizing.

Original in-depth research published at GuetaQuant.

1. Key Mathematical Upgrades in Pine Script v6

In previous versions (v5), performing mathematical reductions across arrays or custom series required cumbersome loops. Pine Script v6 optimizes computational performance by executing core vector operations natively in C++:

`math.sum()` & `math.tanh()`

//@version=6
indicator("Pine Script v6 Math & Non-Linear Activation", overlay=false)

// Native vector sum across an array of returns
var float[] log_returns = array.new_float(0)
float current_return = math.log(close / close[1])
array.push(log_returns, current_return)
if array.size(log_returns) > 50
    array.shift(log_returns)

// Hyperbolic tangent non-linear activation (useful for signal bounding [-1.0, 1.0])
float normalized_zscore = (close - ta.sma(close, 20)) / ta.stdev(close, 20)
float bounded_signal = math.tanh(normalized_zscore)

plot(bounded_signal, "Tanh Signal", color=color.emerald)
hline(0.8, "Upper Bound", color=color.gray)
hline(-0.8, "Lower Bound", color=color.gray)

2. Object-Oriented Architecture with User-Defined Types (UDTs)

Pine Script v6 fully embraces struct-like User-Defined Types. This allows you to encapsulate complete trade contexts (entry, stop loss, risk budget, target) into a single object:

//@version=6
indicator("GQ Trade Context Engine", overlay=true)

type TradeRiskContext
    string symbol
    float entryPrice
    float stopLossPrice
    float lotSize
    float riskAmountUSD

// Factory method to calculate ATR-based risk
fn_create_context(float risk_pct, int atr_len, float atr_mult) =>
    float atr_val = ta.atr(atr_len)
    float sl_distance = atr_val * atr_mult
    float sl_price = close - sl_distance
    float risk_dollars = (strategy.equity * risk_pct) / 100.0
    float calculated_lots = risk_dollars / (sl_distance * 10.0) // 10 USD per pip standard

    TradeRiskContext.new(syminfo.ticker, close, sl_price, calculated_lots, risk_dollars)

var TradeRiskContext active_trade = na
if ta.crossover(ta.ema(close, 9), ta.ema(close, 21))
    active_trade := fn_create_context(1.0, 14, 2.5)

3. Webhook JSON Alert Formatting for Automated Execution

Routing alerts to MetaTrader 5 (MT5), cTrader, or custom Python execution servers requires strictly formatted JSON payloads:

//@version=6
strategy("GQ Webhook Strategy - Pine v6", overlay=true, initial_capital=10000)

fn_build_order_json(string action, float size, float sl_price) =>
    '{"action":"' + action + '","symbol":"' + syminfo.ticker + '","lots":' + str.tostring(size) + ',"sl":' + str.tostring(sl_price) + '}'

if ta.crossover(ta.sma(close, 20), ta.sma(close, 50))
    string payload = fn_build_order_json("BUY", 0.50, close - 2.5 * ta.atr(14))
    strategy.entry("Long", strategy.long, alert_message=payload)

4. Explore More Open-Source Tools

All our MQL5 EAs, cTrader cBots, and Pine Script v6 indicators are open-source under AGPLv3:

44 Open Source Quantitative Tools: GitHub Repository
Interactive MT5 Lot Size Calculator: GuetaQuant MT5 Position Sizer
Local-First Quantitative Trading Journal: GuetaQuant Journal

Disclaimer: Educational research only. Does not constitute investment advice. Compliance with SFC Colombia Decreto 2555/2010.

Pine Script v6 in 2026: math.sum, math.tanh, User Defined Types & Risk Management Engine

Gueta Quant — Wed, 19 Aug 2026 11:44:24 +0000

Liquid syntax error: Unknown tag 'endraw'

DEV Community: Gueta Quant

Monte Carlo Permutation Testing in Python: How Random Trade Order Falsifies Your Equity Curve

1. Permutation vs. Bootstrap: The Critical Distinction

2. The 4 Path Metrics That Expose Hidden Ruin

3. Vectorized Python Implementation (NumPy)

4. Empirical Case Study: The "Profitable" Strategy That Blows Up

Exact Output:

The Institutional Reality:

5. Methodological Boundaries (What Monte Carlo Cannot Do)

6. Open Source Implementation & References

cTrader cBot Risk Engine: High-Precision C# Dynamic Stop-Loss Architecture

1. Separate Sizing From Signals

2. ATR-Based Dynamic Stops

3. Wiring It Into the cBot

4. Trailing Without Chasing

5. Validation Checklist (Demo First)

El bug silencioso de las calculadoras de lotaje: cuando la cuenta es pequeña, tu riesgo se duplica

1. El bug: MathMax(minLot, lotes)

2. La medición

El mismo problema con round() en lugar de floor()

Y un tercer caso: el valor del pip quemado en el código

3. El arreglo

4. Tres reglas para revisar tu propia implementación

5. Nota de transparencia

Algorithmic Risk Management in MT5: ATR Volatility Position Sizing & MQL5 Architecture

Algorithmic Risk Management in MT5: Dynamic Position Sizing & MQL5 Architecture

1. MQL5 Dynamic Lot Calculation Class

2. ATR Volatility Trailing Stops

3. Open Source Tools Ecosystem

Pine Script v6 in 2026: math.sum, math.tanh, User Defined Types & Risk Management Engine

Overview: Pine Script v6 & Institutional Risk Architecture

1. Key Mathematical Upgrades in Pine Script v6

math.sum() & math.tanh()

2. Object-Oriented Architecture with User-Defined Types (UDTs)

3. Webhook JSON Alert Formatting for Automated Execution

4. Explore More Open-Source Tools

Pine Script v6 in 2026: math.sum, math.tanh, User Defined Types & Risk Management Engine

1. El bug: `MathMax(minLot, lotes)`

El mismo problema con `round()` en lugar de `floor()`

`math.sum()` & `math.tanh()`