DEV Community: Gueta Quant

Deriv in Colombia: COP Deposits, Synthetic Indices and Pip Math

Gueta Quant — Tue, 13 Oct 2026 14:01:10 +0000

Two questions dominate Colombian search around Deriv: does it accept Colombian pesos (COP)? and what are synthetic indices, mathematically? This post answers both with verifiable mechanics — no signals, no account handling, no return claims.

1. COP Deposits: Routes, Not Promises

Deriv is a foreign broker (not supervised by Colombia's SFC — same framework as every international CFD broker in our Colombia brokers guide). For funding from Colombia, the routes that exist in practice are:

Local payment rails (where available): cards and e-wallets that settle in COP and convert at the processor's rate. Availability changes — verify on Deriv's cashier page before assuming anything.
P2P / payment agents: third-party exchangers. Highest counterparty risk of the three; never share account credentials, and test with a minimum amount first.
Crypto on-ramp: fund with crypto, convert inside. Adds a second volatile leg — track the conversion rate separately from trading P&L.

General rule: the COP→USD conversion cost is part of your trading cost. A 2–3% round-trip conversion drag means your strategy must earn that back before it earns anything. Log it like commission.

2. Synthetic Indices: RNG Markets, 24/7

Synthetic indices are audited random-number-generator markets with constant volatility parameters (e.g., Volatility 100 claims roughly constant 100% annualized vol). Consequences:

They trade 24/7 — no sessions, no fundamentals, no closes. Your backtest has no weekend gaps to handle, but also no mean-reverting session effects to exploit.
Price is path-independent noise by design. Trend-following assumptions imported from Forex need re-validation; falsify them on demo before sizing up.
Spikes and jumps are part of the generator spec on crash/boom variants — read the contract specs, don't discover them with real money.

3. Pip and Lot Math on Deriv

# Generic pip-value sketch (verify contract size per symbol on Deriv first)
balance, risk_pct = 500.0, 0.005
stop_pips, pip_value_per_lot = 50.0, 1.0   # EXAMPLE values, not Deriv quotes
lots = (balance * risk_pct) / (stop_pips * pip_value_per_lot)
print(f"Budgeted lots: {lots:.3f}")

Two Deriv-specific traps: (a) contract sizes differ per synthetic — never reuse a Forex lot figure; (b) multipliers/options have built-in stops with different payoff math than spot CFDs. Paper-trade each instrument type separately — our MT5 position sizer explains the clamp bug that silently doubles small-account risk when minimums bind.

4. Taxes and Legality in One Paragraph

Own-account trading with a foreign broker is the same SFC/DIAN framework as everywhere on this site: the SFC does not supervise Deriv, you carry counterparty risk, and profits are declarable income in Colombia (see the DIAN guide). Full mechanics in Spanish: Deriv en Colombia.

Study material under Colombia SFC Decreto 2555 de 2010 — education, not advice. No signals.

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

Statistical Arbitrage & Cointegration in LATAM Equities (BVC) with Python

Gueta Quant — Tue, 13 Oct 2026 13:33:23 +0000

Two stocks can rise together for years and still be untradeable as a pair. Correlation measures co-movement; pairs trading needs cointegration — a stationary, mean-reverting spread. This post builds the standard test pipeline in Python and shows where most LATAM pairs fail.

Educational content: methodology, no signals, no return claims.

1. Correlation Lies, Cointegration Trades

Correlated prices drift apart permanently (both trend up, spread widens forever). A cointegrated pair has a spread that reverts to a stable mean, which is what a long/short entry bets on. The Engle–Granger (1987) two-step procedure tests exactly this:

Regress Y on X by OLS → hedge ratio β.
Run an Augmented Dickey–Fuller (ADF) test on the residual spread. Only a stationary spread (low ADF p-value) is tradeable.

import numpy as np
import statsmodels.api as sm
from statsmodels.tsa.stattools import coint, adfuller

# y, x: aligned log-price series of the two candidate assets
score, pvalue, _ = coint(y, x)          # Engle-Granger cointegration test
print(f"EG p-value: {pvalue:.4f}")      # tradeable only if clearly < 0.05

res = sm.OLS(y, sm.add_constant(x)).fit()
beta = res.params[1]                    # hedge ratio: short beta units of X per 1 of Y
spread = y - beta * x

adf_stat, adf_p, *_ = adfuller(spread)[:2]

A p-value above conventional significance is not a "weak pair" — it is a rejection. Discard it. Most random pairs fail; that is the expected outcome, not bad luck. (Our falsification-first protocol for backtests is documented in Why Perfect Backtests Fail.)

2. Half-Life: How Fast Does It Revert?

A stationary spread that reverts once a year is untradeable. Estimate the half-life with a simple AR(1) regression of spread changes on lagged spread:

d_spread = np.diff(spread)
lag = spread[:-1]
beta_hl = np.polyfit(lag, d_spread, 1)[0]
halflife = -np.log(2) / beta_hl
print(f"Half-life: {halflife:.1f} bars")

Practical rule: half-life should sit comfortably between transaction-cost frequency (too fast = costs eat everything) and your holding horizon (too slow = capital sits idle). Both extremes fail — for opposite reasons.

3. Entries on the Z-Score, Exits on Discipline

z = (spread - spread.mean()) / spread.std()
# Enter when |z| > 2.0 (long the laggard, short the leader),
# exit when z crosses back through ~0.25 — never "wait for full reversion".

Hard stops still apply: cointegration breaks (mergers, regime changes, delistings). A pair that held for three years can decouple in a week. Size every pair as if the spread can go to 3–4σ and stay there.

4. Why LATAM (BVC) Pairs Are Harder

Applying this to Colombian equities (BVC) adds three frictions US textbook examples ignore:

Liquidity: wider spreads and thin books mean your backtest fill assumptions are fiction unless you model slippage explicitly. Test with volume-capped fills.
Costs: commissions, exchange fees and taxes compound on a strategy that trades often. Recompute the half-life economics after costs — many "profitable" spreads die here.
Short access: pairs trading needs both legs. If you cannot reliably short one side, the strategy is long-only spread timing, a different (usually worse) trade. Verify borrow availability before any capital.

No specific pairs are recommended here — universes change, and any named pair would be stale on arrival. Run the pipeline above on current data instead.

5. Validation Checklist

In-sample cointegration + out-of-sample spread stability (Walk-Forward, not one fit).
Half-life compatible with costs and horizon.
Break scenario sized and stop-defined before the first trade.
60+ days paper trading the exact execution path.

Study material under Colombia SFC Decreto 2555 de 2010 — financial-engineering education, not investment advice. No signals, no managed accounts.

By **Mahdi Goodarzi* (g.dev/mahdigoodarzi), Gueta Quant — research notes at guetaquant.com/blog. Related: Pine Script v6 guide.*

Building an Automated Broker Risk & Tier-1 Regulatory Auditor in Python

Gueta Quant — Mon, 05 Oct 2026 09:42:31 +0000

When algorithmic traders design risk models, they rigorously calculate Kelly fractions, Value at Risk (VaR), and dynamic ATR trailing stops. Yet, one catastrophic risk is almost universally ignored in retail algorithm architecture: counterparty custody failure.

If your broker becomes insolvent, executes negative slippage with impunity, or freezes withdrawals during an extreme volatility event, mathematical edge is meaningless.

In emerging markets across Latin America, Southeast Asia, and Africa, retail traders are especially vulnerable to Regulatory Arbitrage and Entity Switching: a global broker advertises its prestigious UK FCA or Australian ASIC license, but quietly routes local clients to an unregulated shell company in St. Vincent or Seychelles.

This engineering guide explains the fiduciary mechanics of broker regulation and provides a complete, reusable Python engine to score broker counterparty risk programmatically.

1. The Fiduciary Mechanics of Tier-1 vs. Offshore Regulation

Financial regulators exist on a strict hierarchy of fiduciary protection, capital adequacy requirements, and legal enforceability:

Regulatory Tier	Primary Jurisdictions	Statutory Capital Requirement	Retail Leverage Limits	Client Money Segregation & Compensation Scheme
Tier-1 (Institutional)	UK (FCA), Australia (ASIC), USA (CFTC/NFA)	$\ge \$1\text{M} - \$20\text{M}$	Capped at 1:30 (ESMA/FCA) or 1:50 (NFA)	Mandatory trust segregation. UK FSCS covers up to £85,000 per eligible claimant.
Tier-2 (Moderate)	Cyprus (CySEC), UAE (DFSA)	$\ge \$750\text{k}$	1:30 retail, higher professional	Segregated accounts. CySEC ICF covers up to €20,000.
Tier-3 / Offshore	Seychelles (FSA), Bahamas (SCB), St. Vincent	Minimal ($<\$50\text{k}$) or None	Uncapped (1:500 to 1:2000)	No statutory compensation scheme. Zero regulatory recourse for foreign residents.

Under Tier-1 regulations, client deposits are held in statutory trust accounts segregated from the broker’s operational funds. If the broker defaults or enters liquidation, institutional creditors cannot seize client trading funds. Under offshore jurisdictions, commingling of funds is legal or virtually unmonitored.

2. Detecting the "Entity Switching" Pattern

How do brokers pull off entity switching?

Top-Level Domain (TLD) Cloaking: The main domain (broker.com) displays FCA and ASIC license badges prominently in the header.
Geotargeted Client Routing: An automated IP lookup detects a visitor connecting from Colombia, Argentina, or Mexico.
Contract Fine Print: The sign-up form automatically selects the offshore subsidiary (e.g., Broker Ltd (Seychelles) instead of Broker UK Ltd).
Waiver of Rights: The trader inadvertently agrees to terms that strip all Tier-1 Ombudsman dispute resolution mechanisms and FSCS deposit insurance.

3. The Python Broker Risk & Fiduciary Auditor

The following Python script models an automated risk assessment pipeline. It parses contract metadata, evaluates leverage limits, verifies corporate identity match, and computes a Fiduciary Safety Index (0 to 100):

"""
Broker Counterparty Fiduciary Risk Auditor
Gueta Quant Open Research — AGPLv3
"""

from dataclasses import dataclass
from typing import List, Dict

@dataclass
class BrokerEntity:
    brand_name: str
    contracted_legal_name: str
    regulator: str
    license_number: str
    max_offered_leverage: int
    negative_balance_protection: bool
    segregated_tier1_bank: bool
    regulatory_tier: int  # 1 = FCA/ASIC, 2 = CySEC/DFSA, 3 = Offshore/None
    dispute_resolution_scheme: bool

class BrokerAuditor:
    # Regulatory weights for quantitative risk scoring
    TIER_WEIGHTS = {1: 45, 2: 25, 3: 5}

    @classmethod
    def audit_entity(cls, entity: BrokerEntity) -> Dict[str, any]:
        score = 0
        critical_red_flags = []
        positive_factors = []

        # 1. Primary Regulatory Tier Check (Max 45 pts)
        tier_pts = cls.TIER_WEIGHTS.get(entity.regulatory_tier, 0)
        score += tier_pts
        if entity.regulatory_tier == 1:
            positive_factors.append(f"Tier-1 Oversight ({entity.regulator}) with statutory protection.")
        elif entity.regulatory_tier == 3:
            critical_red_flags.append(f"Offshore jurisdiction ({entity.regulator}) — No statutory depositor safety net.")

        # 2. Segregated Trust Accounts (Max 25 pts)
        if entity.segregated_tier1_bank:
            score += 25
            positive_factors.append("Client capital segregated in Tier-1 custodian bank.")
        else:
            critical_red_flags.append("High commingling risk: lack of verified Tier-1 custodian segregation.")

        # 3. Negative Balance Protection (Max 15 pts)
        if entity.negative_balance_protection:
            score += 15
            positive_factors.append("Guaranteed negative balance protection.")
        else:
            critical_red_flags.append("No negative balance guarantee — account can owe debt after market gaps.")

        # 4. Leverage Sanity Check (Max 15 pts)
        if entity.max_offered_leverage <= 30:
            score += 15
            positive_factors.append("Institutional retail leverage cap (1:30 ESMA/FCA standard).")
        elif entity.max_offered_leverage <= 100:
            score += 8
        else:
            # Extreme leverage (1:500+) strongly indicates B-book / offshore dealing desk
            critical_red_flags.append(f"Excessive leverage (1:{entity.max_offered_leverage}) indicates dealing desk insolvency risk.")

        # Determine Classification
        if score >= 80:
            rating = "Grade A: Institutional / Highly Safe"
        elif score >= 55:
            rating = "Grade B: Acceptable with Prudent Position Sizing"
        else:
            rating = "Grade C: High Counterparty Risk / Unregulated"

        return {
            "Brand": entity.brand_name,
            "Contracting Entity": entity.contracted_legal_name,
            "Fiduciary Safety Score": f"{score}/100",
            "Rating": rating,
            "Positive Factors": positive_factors,
            "Critical Red Flags": critical_red_flags
        }

if __name__ == "__main__":
    # Test Entity 1: Tier-1 Verified Provider
    tier1_broker = BrokerEntity(
        brand_name="Global FX UK",
        contracted_legal_name="Global FX Financial Services Ltd",
        regulator="FCA",
        license_number="123456",
        max_offered_leverage=30,
        negative_balance_protection=True,
        segregated_tier1_bank=True,
        regulatory_tier=1,
        dispute_resolution_scheme=True
    )

    # Test Entity 2: Offshore Subsidiary (The Common Retail Trap)
    offshore_broker = BrokerEntity(
        brand_name="Global FX (Offshore Branch)",
        contracted_legal_name="Global FX Markets Ltd (Seychelles)",
        regulator="FSA Seychelles",
        license_number="SD-099",
        max_offered_leverage=500,
        negative_balance_protection=False,
        segregated_tier1_bank=False,
        regulatory_tier=3,
        dispute_resolution_scheme=False
    )

    print("=== TIER-1 AUDIT ===")
    res1 = BrokerAuditor.audit_entity(tier1_broker)
    for k, v in res1.items():
        print(f"{k}: {v}")

    print("\n=== OFFSHORE AUDIT ===")
    res2 = BrokerAuditor.audit_entity(offshore_broker)
    for k, v in res2.items():
        print(f"{k}: {v}")

4. The Colombian Benchmark: SFC Decreto 2555 de 2010

In Colombia, the legal framework provides a clear boundary:

Under Decreto 2555 de 2010 (Parte 4) and SFC Concepto 2015112607-002, foreign institutions offering financial services or derivatives must establish an official representative office (oficina de representación) or execute a formal correspondent contract (contrato de corresponsalía) with an authorized local broker (Sociedad Comisionista de Bolsa).

Furthermore, the Superintendencia Financiera de Colombia (SFC) explicitly declared on September 3, 2021, that no foreign CFD/Forex platform holds direct local authorization to operate or promote financial markets within Colombia.

For Colombian and Latin American traders operating under the free convertibility regime (Banco de la República Resolución Externa 1 de 2018), counterparty risk is borne entirely by the individual. Therefore, verifying that your foreign provider is subject to enforceable Tier-1 supervision (FCA or ASIC) is not an option—it is the foundational prerequisite of solvency.

To review the complete regulatory inventory, audited licenses, and the official SFC warning checklist:
👉 Guía y Lista Maestra: Brokers Regulados y Autorizados en Colombia (SFC & Tier-1).

5. The 4-Step Verification Protocol

Before funding any live account:

Inspect Footer Terms: Never rely on the homepage marketing banner. Scroll to the footer of the legal agreement and extract the exact company name signing your contract.
Search the Official Register: Navigate directly to register.fca.org.uk or asic.gov.au and check that the company name and approved domains match.
Cross-Check SFC Warnings: Ensure the broker does not appear on the SFC Colombia Lista de Firmas No Autorizadas.
Test Withdrawal Channels: Execute a small deposit and immediate withdrawal test via bank wire or regulated payment rails before allocating meaningful algorithmic capital.

Educational research paper strictly compliant with SFC Colombia Decreto 2555 de 2010. No investment advice, no signals, no managed accounts.

By **Mahdi Goodarzi* (g.dev/mahdigoodarzi), Founder & Product Builder at Gueta Quant. Open-source tools available at guetaquant.com.*

Auditing Broker Execution Latency, FIX Protocol & Asymmetric Slippage in Algorithmic Trading

Gueta Quant — Mon, 05 Oct 2026 09:41:52 +0000

Most quantitative trading models fail when transitioned from historical backtest to live execution not because the mathematical alpha was flawed, but because the backtesting engine assumed frictionless, zero-latency execution.

In a simulation, your order fills instantly at the exact millisecond bar close. In live market routing, every order traverses network topologies, broker matching engines, liquidity provider aggregation pools, and clearing gateways. During that round-trip window (50ms to 400ms), asset prices move.

When that movement is structurally skewed against you, your edge evaporates to asymmetric slippage.

This engineering paper details how to model, record, and audit broker execution quality programmatically, measure round-trip time (RTT), and verify whether your counterparty operates under enforceable regulatory execution standards.

1. The Zero-Latency Fallacy in Retail Backtests

Retail backtesting frameworks (such as standard vectorbt, TradingView Pine Script, or naive MT5 tick simulations) make three fatal assumptions:

Infinitely Deep Top-of-Book: The entire order volume fills at the posted Best Bid / Best Offer without price impact.
Deterministic Fill Price: Fill Price = Order Price.
Symmetric Slippage Distribution: If slippage occurs, price variance is assumed to be a Gaussian normal distribution centered at zero ($\mu = 0$).

In real-world retail CFD and FX execution, slippage is asymmetric. Market makers and B-book brokers frequently route trades where favorable price movement (positive slippage) during the execution lag is swallowed by the dealer or requoted, while unfavorable price movement (negative slippage) is passed entirely to the client account.

Even a modest execution drag of 0.3 pips per side destroys high-frequency and intraday momentum strategies where the expected payoff per trade is only 1.5 to 2.5 pips.

2. Anatomy of FIX Protocol 4.4 Execution Lag

For algorithmic traders connecting via FIX (Financial Information eXchange) Protocol 4.4 or broker REST/WebSocket APIs, the execution lifecycle consists of discrete network and processing hops:

[Quant Server]                 [Broker Gateway]              [Liquidity Provider]
      |                                |                               |
   T0 |-- NewOrderSingle (35=D) ------>|                               |
      |                                |-- Order Routing (A/B-Book) -->|
      |                                |                               |-- Fill Match
      |                                |<-- ExecutionReport (35=8) ----|
   T1 |<-- ExecutionReport (35=8) -----|                               |
      |    (ExecType=0 New/Ack)        |                               |
      |                                |                               |
   T2 |<-- ExecutionReport (35=8) -----|                               |
      |    (ExecType=F Filled)         |                               |

The critical metric is the Tick-to-Fill Latency ($\Delta T_{fill} = T2 - T0$), composed of:

Network Ingress / Egress: Distance between client VPS and broker server (e.g., Equinix LD4 London or NY4 New York).
Internal Queue Delay: The broker's internal risk check (pre-trade margin validation and book routing).
LP Fill & Acknowledgment: Market execution by external Tier-1 liquidity providers or internal matching engine.

3. Detecting Asymmetric Slippage: The Python Audit Engine

To audit your broker objectively, log the target signal price ($P_{target}$), the requested order price ($P_{order}$), the actual executed price ($P_{fill}$), and the round-trip latency ($\Delta T$) on every single order.

Here is a standalone Python analytics engine to compute the Execution Drag Index (EDI) and test for statistical asymmetry using the Wilcoxon signed-rank test:

"""
Broker Execution Quality & Asymmetric Slippage Auditor
Gueta Quant Open Research — AGPLv3
"""

import numpy as np
import pandas as pd
from scipy import stats

def audit_broker_execution(trades_df: pd.DataFrame, pip_size: float = 0.0001):
    """
    Analyzes execution records for asymmetric slippage and latency drag.

    Expected DataFrame columns:
    - order_type: 'BUY' or 'SELL'
    - target_price: float (price when signal triggered)
    - fill_price: float (actual executed price from broker)
    - rtt_ms: float (round-trip execution time in milliseconds)
    """
    df = trades_df.copy()

    # Calculate slippage in pips
    # For BUY: Fill > Target is negative slippage (worse price)
    # For SELL: Fill < Target is negative slippage (worse price)
    is_buy = df['order_type'].str.upper() == 'BUY'

    df['slippage_points'] = np.where(
        is_buy,
        df['target_price'] - df['fill_price'],  # Positive if filled better, negative if worse
        df['fill_price'] - df['target_price']
    )
    df['slippage_pips'] = df['slippage_points'] / pip_size

    # Segment positive vs negative slippage
    positive_slip = df[df['slippage_pips'] > 0]['slippage_pips']
    negative_slip = df[df['slippage_pips'] < 0]['slippage_pips']
    zero_slip = df[df['slippage_pips'] == 0]['slippage_pips']

    total_trades = len(df)
    neg_slip_rate = len(negative_slip) / total_trades if total_trades else 0
    pos_slip_rate = len(positive_slip) / total_trades if total_trades else 0

    mean_slippage = df['slippage_pips'].mean()
    median_slippage = df['slippage_pips'].median()

    # Asymmetry ratio: Negative volume / Positive volume
    total_neg_pips = abs(negative_slip.sum())
    total_pos_pips = abs(positive_slip.sum())
    asymmetry_ratio = total_neg_pips / (total_pos_pips + 1e-9)

    # Statistical Hypothesis Testing: H0: Slippage distribution is symmetric around 0
    # Wilcoxon signed-rank test
    stat, p_value = stats.wilcoxon(df['slippage_pips']) if len(df) >= 20 else (0, 1.0)

    # Execution Drag Index (EDI): Average pip drag per 100ms latency
    mean_rtt = df['rtt_ms'].mean()
    edi = (abs(mean_slippage) / (mean_rtt / 100.0)) if mean_rtt > 0 else 0

    report = {
        "Total Trades Audited": total_trades,
        "Mean Round-Trip Latency (ms)": round(mean_rtt, 2),
        "Negative Slippage Frequency": f"{neg_slip_rate * 100:.1f}%",
        "Positive Slippage Frequency": f"{pos_slip_rate * 100:.1f}%",
        "Zero Slippage Frequency": f"{(len(zero_slip) / total_trades) * 100:.1f}%",
        "Mean Net Slippage (pips)": round(mean_slippage, 3),
        "Median Slippage (pips)": round(median_slippage, 3),
        "Asymmetry Ratio (Loss/Gain)": round(asymmetry_ratio, 2),
        "P-Value (Asymmetry Significance)": f"{p_value:.5f}",
        "Is Systematically Skewed": (p_value < 0.05 and mean_slippage < 0),
        "Execution Drag Index (pips/100ms)": round(edi, 3)
    }

    return report

if __name__ == "__main__":
    # Simulated sample of 200 trades from a questionable dealer:
    np.random.seed(42)
    n = 250
    # Skewed execution: 65% suffer adverse slippage, only 15% get positive
    slips = np.concatenate([
        np.random.exponential(scale=0.4, size=int(n * 0.65)) * -1, # adverse
        np.random.exponential(scale=0.15, size=int(n * 0.15)),      # positive
        np.zeros(int(n * 0.20))                                     # zero slip
    ])
    rtts = np.random.normal(loc=120, scale=30, size=len(slips))

    mock_data = pd.DataFrame({
        "order_type": np.random.choice(["BUY", "SELL"], size=len(slips)),
        "target_price": 1.0850,
        "fill_price": 1.0850 - (slips * 0.0001),
        "rtt_ms": np.maximum(20, rtts)
    })

    results = audit_broker_execution(mock_data)
    for k, v in results.items():
        print(f"{k:35}: {v}")

If the p-value is below $0.05$ and the Asymmetry Ratio exceeds 2.0x, your broker is not providing symmetric market execution. You are absorbing the costs of a dealing desk.

4. The Regulatory Layer: Offshore Subsidiarity vs. Tier-1 Mandates

Why does this happen predominantly in retail emerging markets (Latin America, Southeast Asia)?

Brokers operating under Tier-1 regimes (such as the UK FCA or Australian ASIC) are legally bound by Best Execution mandates (formerly RTS 27/28 in MiFID II). Under these frameworks, brokers must publish quarterly execution quality metrics and demonstrate that positive slippage is passed to retail clients in full.

However, retail brokers frequently employ Entity Switching:

They market the reputation of their UK FCA or Australian ASIC license.
When an algorithmic trader or resident from Colombia, Mexico, or Chile registers, they are onboarded under a subsidiary domiciled in the Bahamas, Seychelles, or St. Vincent.
Under these offshore subsidiaries, statutory protections (such as the UK FSCS £85,000 compensation fund) and Best Execution auditing are legally null and void.

In Colombia, the Superintendencia Financiera de Colombia (SFC) explicitly notes under Decreto 2555 de 2010 that foreign CFD brokers possess no banking license within Colombian territory, and counterparty risks are assumed 100% by the investor.

To verify whether your broker operates with genuine Tier-1 regulatory backing or an offshore pass-through entity, refer to our comprehensive independent audit:
👉 Brokers Regulados y Autorizados en Colombia: Auditoría Legal y de Ejecución.

5. Pre-Deployment Execution Checklist

Before deploying real capital to an algorithmic strategy:

Audit Contract Multipliers: Confirm SYMBOL_TRADE_CONTRACT_SIZE and SYMBOL_TRADE_TICK_VALUE in MT5 or cTrader to avoid position-sizing explosions on non-USD quote pairs.
Measure Tick Latency to Matching Engine: Ensure VPS latency to the broker's real trading server is $<5\text{ms}$.
Log Fill Discrepancies: Record every fill price against local quote prices during news releases (CPI, NFP) to compute the Execution Drag Index.
Inspect Regulatory Jurisdiction: Always demand proof of account segregation and check the registration number directly on the regulator's portal (register.fca.org.uk or asic.gov.au).

Educational research paper strictly compliant with SFC Colombia Decreto 2555 de 2010. No investment advice, no signals, no managed accounts.

By **Mahdi Goodarzi* (g.dev/mahdigoodarzi), Founder & Product Builder at Gueta Quant. Explore open-source quantitative toolkits at guetaquant.com.*

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

Deriv in Colombia: COP Deposits, Synthetic Indices and Pip Math

1. COP Deposits: Routes, Not Promises

2. Synthetic Indices: RNG Markets, 24/7

3. Pip and Lot Math on Deriv

4. Taxes and Legality in One Paragraph

Statistical Arbitrage & Cointegration in LATAM Equities (BVC) with Python

1. Correlation Lies, Cointegration Trades

2. Half-Life: How Fast Does It Revert?

3. Entries on the Z-Score, Exits on Discipline

4. Why LATAM (BVC) Pairs Are Harder

5. Validation Checklist

Building an Automated Broker Risk & Tier-1 Regulatory Auditor in Python

1. The Fiduciary Mechanics of Tier-1 vs. Offshore Regulation

2. Detecting the "Entity Switching" Pattern

3. The Python Broker Risk & Fiduciary Auditor

4. The Colombian Benchmark: SFC Decreto 2555 de 2010

5. The 4-Step Verification Protocol

Auditing Broker Execution Latency, FIX Protocol & Asymmetric Slippage in Algorithmic Trading

1. The Zero-Latency Fallacy in Retail Backtests

2. Anatomy of FIX Protocol 4.4 Execution Lag

3. Detecting Asymmetric Slippage: The Python Audit Engine

4. The Regulatory Layer: Offshore Subsidiarity vs. Tier-1 Mandates

5. Pre-Deployment Execution Checklist

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()`