Quantitative Developer · Agentic AI Engineer

Systematic and algorithmic trading · Energy trading & procurement · Quant research · Systematic trading decision engine · Agentic AI engineering

Backtesting · Monte Carlo · Risk systems · Execution diagnostics

Independent engineer in Berlin. Since February 2021 I have studied markets and built the software to test what I found. Four proprietary systems came out of it, each built end to end: a trading research and execution platform that runs live on MT5, a voice execution copilot, an energy procurement research and backtesting platform, and the AI agent platform that develops the trading decision engine and the copilot today, and built the energy platform.

Each one is built to operate, evaluate its own results and improve its decisions over time, with AI used as augmented intelligence: it extends my judgement, it does not replace it.

The four systems

01Proprietary platform · live on MT5

Private Trading Research & Execution Platform

The problem: Most trading ideas are never tested against real costs, real risk limits and a real broker before money is on the line.
What it does: It takes a market idea from data to research, backtesting, risk checks and live orders on MT5, then checks the results against the broker's records.

Proprietary · built end to end

1,217order records from live execution on MT5, with profit and loss reconciled against the broker to the cent.

This describes the engineering, never the strategy.

How it works · 6 steps

Simplified. What live trading shows, expected against actual, goes back into research.

Key terms, in plain words

Execution-aware backtesting: Replaying past markets to see what a rule would have done, including orders that would not have filled and the broker's costs.
Monte Carlo stress testing: Thousands of reshuffled histories, to see how bad it can get before any money is at risk.
Position sizing and drawdown limits: How big each trade may be, and a hard cap on how much the account may lose in a day and in total.
Broker reconciliation: Internal records matched against the broker's, down to the cent.
Systematic Trading Decision Engine: The next layer: a candidate decision rule must beat simpler baselines and pass statistical gates, under a safety veto that can always block it, before it can reach capital.
Silent-failure detection: A channel that is running but no longer writing is caught, instead of being reported as a normal day.

Evidence for technical readers

The full chain, with the figure behind each stage. Every figure is traced to a run manifest, the git history or the test directory.

Market data

MT5 tick and candle export, live and historical ingestion, gap and conflict checks, feed-freshness monitoring.

96series · 10 instruments, up to 10 timeframes

Research

Deterministic strategy rules, reproducible experiments, and systematic parameter exploration.

3 yearsof history under test

Simulation

Execution-aware backtesting with explicit fill, no-fill and rejection states, intrabar ordering, broker costs.

1,021,061,653simulated results

Risk

Monte Carlo stress analysis, position sizing, combined exposure, daily and total drawdown limits.

3,000Monte Carlo runs per finalist

Execution

Broker preflight, MT5 order submission, persisted lifecycle state, restart recovery, end-of-day controls, and post-trade P&L reconciliation against broker truth to the cent.

1,217executed order records

Operations

REST APIs, health and readiness telemetry, automated daily, weekly and monthly reporting, signal to order to fill diagnostics, and silent-failure detection: the business ledger is cross-checked against an independent process heartbeat.

243service endpoints

Quality

Regression, integration, golden-case and failure-path tests, and a pre-commit hook that blocks a commit when the architecture documentation is out of sync with the code.

1,043automated test files

Three research engines have produced 1,021,061,653 simulated results across ten markets and three years of history, every figure traced to a run manifest. The survivors then go through Monte Carlo stress before anything reaches a live account. Live today on FX, indices and crypto.

08 · NEXT

Systematic Trading Decision Engine

Offline policy learning · Off-policy evaluation · Champion-challenger governance

The platform is evolving from deterministic rules into a decision engine above the chain. The data picks the model family, with reinforcement learning among the candidates. Every candidate policy must beat simpler baselines and pass statistical promotion gates under a hard safety veto before it can reach capital. In plain words: a new decision rule is learned from recorded history and judged on past data before it risks money (offline policy learning, off-policy evaluation), and it replaces the rule in use only if it beats it (champion-challenger). The foundation so far: 188 TypeScript modules, 29 typed contract modules and 35 JSON schemas, verified by a full regression suite with no failing tests, with 157 of 185 planned tasks delivered.

The Private Trading Research & Execution Platform is proprietary. This page describes the scope of the engineering, not the strategy logic.

02Proprietary product · voice execution on MT5

Trading Execution Copilot

Augmented intelligence for trading: the trader decides, the copilot scores and executes.

The problem: When a trader places orders by hand under time pressure, one wrong size or price can cost real money.
What it does: The trader says the order out loud. The copilot turns it into a ticket, scores the setup on executed trade history, checks it, sizes the risk, reads it back and sends it to MT5 only after an explicit yes, then reconciles it with the broker. The human stays in the loop for every order.

Proprietary · built end to end

Nothing reaches MT5 without the trader's explicit yes, and every order is read back first.

How it works · 7 steps

The trader decides the trade. The copilot makes sure the order that goes out is the one that was meant.

Key terms, in plain words

Discretionary execution: The trader decides the trade; the copilot handles the order safely.
Ticket: The spoken order, written down as a structured order that software can check.
Risk sizing: The position size is worked out from the risk limit, not typed by hand.
Read back: The order is repeated back to the trader before anything is sent.
Broker reconciliation: An order counts as executed only when the broker's own record confirms it.

Evidence for technical readers

The path from spoken order to broker is built as separate, tested parts: a dictated-order parser, a ticket validator, a lot calculator and the read-back.
Nothing is sent without explicit confirmation, and nothing counts as executed without a reconciled broker acknowledgement.
776 automated tests passing, none failing.
Built with the agent platform, AWOP (system 04).

03Proprietary platform · deployed on-site in Oxford, UK (Sep - Oct 2026)

Energy Procurement Research & Backtesting Platform

The problem: I worked on-site in Oxford, UK, for a large energy buyer that spends heavily on power and gas every year and needed to lower its purchase cost.
What it does: A research and backtesting platform for power and gas procurement in European markets. It turns each buying idea into a testable rule, replays it on real exchange order-book and trade data with costs, and compares the result with the buyer's current practice and a market benchmark.

Proprietary · built end to end

2.5%below the buyer's current practice in 3 of 3 quarters (fees excluded), in its first exploratory backtest.

Built in under a month, for monthly and quarterly purchases. First applied on-site in Oxford, UK (Sep - Oct 2026), to a large energy buyer's procurement.

The first 5 buying strategies are ready for validation, and the method is open-ended: new strategies and hypotheses can be added for each buying problem to find the best result. An out-of-sample period stays sealed until a rule is frozen.

Data and detailed results stay confidential.

How it works · 6 steps

Simplified. Every hypothesis is compared with both references, never only with itself.

Key terms, in plain words

Energy procurement: How a company buys the power and gas it needs, here in monthly and quarterly products.
Hypothesis-driven research: Each idea is written as a testable claim, with its acceptance criteria, before it is measured.
Backtest and replay: Running a buying rule over past market data, with trading costs, as if it had been used at the time.
Point-in-time data: Each simulated decision sees only what was known at that moment.
Out-of-sample period: Data set aside before any selection, so the result is not tuned to it.
Market benchmark: A market reference to compare against, so a result means something beyond itself.

Evidence for technical readers

77 of 77 planned tasks accepted, 721 commits and 198 test files.
First exploratory backtest (source: the platform's backtest report, quarterly power): the buying rule came in 2.5% below the buyer's current practice, lower in 3 of 3 delivery quarters, fees excluded. That sits inside the 1 to 5% range McKinsey cites for strong energy procurement. Three quarters is a small sample: an exploratory reading, not a validated result.
The first 5 buying strategies are ready for validation, and the method is open-ended: new strategies and hypotheses can be added for each buying problem. The out-of-sample period stays sealed until a rule is frozen.
Strategy research, hypothesis methods and backtesting for European power and gas procurement, with monthly and quarterly delivery.
Point-in-time decision views kept separate from evaluation views, and an out-of-sample period reserved before any selection.
Replay with cost ledgers and run receipts for reproducibility, so far demonstrated on a synthetic fixture.
An offline value and policy learning cycle that only proposes candidate versions and never activates one, tested with synthetic fixtures only.
An operator UI for campaigns, replay, backtests and research; a designed market-state observability layer; and a path toward reinforcement learning for purchase decisions.
Every hypothesis is measured against the buyer's current practice and a market benchmark. The first end-to-end test sets the starting baseline, not the final result.
Built with the agent platform, AWOP (system 04).

04Proprietary platform · AI coding agents

Agentic Workflow Orchestration Platform (AWOP)

Agentic workflow orchestration: AI agents ship code, independent agents review it, tests decide what merges.

Multi-agent orchestration and coordination: agents share task ownership, handoffs and review rules. MCP (Model Context Protocol) connects assistants to the workflow; evals measure runs by model and role. Self-healing mechanisms handle stalled work and failed handoffs within explicit limits.

The problem: AI coding agents write code fast, but without structure nobody can say what changed, whether it was tested or who checked it.
What it does: It coordinates several AI agents in parallel, each on its own branch, with test gates on every merge and independent review on every autopilot merge. Human decisions and run records stay part of the workflow.

Proprietary · built end to end

341tasks merged across the four projects by AI agents, every one through the test gate.

It develops the trading decision engine and execution copilot today, and it built the energy platform.

How it works · 7 steps

Simplified. Independent review is mandatory on every autopilot merge; on the other routes a person decides.

Key terms, in plain words

Multi-agent orchestration: Several AI agents working on the same codebase at once, each on its own task.
Multi-agent coordination: Shared task ownership, handoffs, evidence and review responsibilities across agents and model families.
Augmented intelligence: AI supports human judgement instead of replacing it. In the Trading Execution Copilot the trader decides; the copilot scores the setup on executed trade history and executes only on an explicit yes.
Self-healing workflows: Recovery mechanisms detect stalled work, stop repeated ineffective corrections and route the next action. Recovery does not waive budgets, human decisions or independent verification, and does not guarantee that every failure resolves without intervention.
MCP (Model Context Protocol): A standard connector that lets an outside AI assistant see and operate the platform, through the same interface a person uses.
Evals: Every agent run is measured by model and role, so the choice of model rests on numbers, not impressions.
Model routing and failover: Each kind of job goes to a chosen account and model; when an account runs low on quota, the work moves to another one.
Isolated branch: Each agent writes in its own copy of the code, so parallel work cannot collide.
Test-regression gate: Nothing merges if the tests get worse than main.
Independent review: A different agent, not the one that wrote the change, checks the exact diff.
Autopilot merge: On routes agreed in advance, a change merges without a person once it has passed the gate and the independent review.
First-pass approval and rework rate: How often a change is accepted at once, and how often it goes back to be redone.

Evidence for technical readers

Measurement snapshot for the figures below: 30 October 2026. They are historical engineering evidence, not a live counter or a customer outcome.
341 tasks merged in 4 codebases (the trading decision engine, the execution copilot, the energy platform and the platform itself), each only after tests and an independent review; 289 of them merged by the autopilot without a human merge decision.
AI agents work in parallel across 6 provider accounts and 4 model families, under one shared engineering standard.
The independent review sent 319 of 402 agent changes back for fixes and raised 1,581 technical findings before anything merged.
An MCP server lets an outside AI assistant read the platform's state and operate it through the same API as the user interface.
Model routing by role and account, with a quota reserve per account and a handoff to another account when one runs low.
Bounded self-healing: repeated failed corrections trigger reclassification rather than an endless retry loop. Recovery keeps unresolved findings, budget limits and independent review in place. Targeted regression tests cover these paths; that is not a claim that all production failures recover automatically.
Every run is measured by model and role: first-pass approval, rework rate, review rounds to acceptance and tokens per accepted task, each rate with its sample size.
Limits, stated up front: agents work in isolated branches and working copies, which is not a security sandbox; independent review is mandatory on autopilot merges, not on every merge.
Private: it is not licensed or installed for clients. What I offer is the method, built on the client's own tools (AI coding-agent workflow consulting).

Most people who can trade cannot build this. Most people who can build it have never traded.

Since February 2021 I have studied markets and built the tools to test what I found, through four successive systems: roughly 25,000 hours of study, research and engineering. It is the same deliberate method that built a ten-year international music career before it. The Private Trading Research & Execution Platform is the fourth, built end to end, and it runs the whole chain above every day. I build systems that keep running without me.

Independent and self-funded, end to end. Every figure on this page can be traced back to the file it came from.

Based in: Berlin, Germany
Status: Open to remote roles worldwide
Looking for: Quantitative development · Trading systems engineering · Agentic AI engineering · Energy trading · Systematic trading · Remote
Stack: JavaScript · TypeScript · Python · Node.js · Express · React · MQL5 / MT5 · Streamlit
Languages: Spanish native · English professional · German A2.2, working toward B1

Looking for someone who has already built the whole thing?

Every figure above is traceable: the run manifest, the git history, the test directory. Ask me for any of them.

Bruno SaldivarBerlin, Germany

bru.daytrader@gmail.com LinkedIn Book a 30-min intro Full background