Giolit Labs presents
Algorithmic trading
risk verifier
Giolit Trading Risk Verifier 1.0
Your backtest checked what happened. Giolit checks everything that could happen — every possible sequence of orders, fills, cancels and price moves — and gives you one of two answers: mathematical proof that a rule can never be broken, or the exact step-by-step sequence that breaks it.
What you get back
Rule: “never hold more than 1,000 shares.”
The limit checks shares held, not shares ordered. Two buy orders slip through before either fills — position ends at 1,099.
Count open orders too, and no sequence of events — for any number of orders — can breach 1,000 again.
Real results from examples 01 and 02 in the free trial.
Every combination of prices, fills, rejects and cancels your rules allow — for any number of orders.
If a rule can break, you see how — usually in 3 to 15 events — in a file your developers can replay.
Reads your existing Python, C++ or Java. Nothing rewritten by hand, nothing run live.
For every proven limit, how close you ever get to it — with a 1–5 star score your risk committee can read.
0
wrong answers on 180 benchmark trading rules
100,000
orders at once — a limit proved in under half a second
4 of 5
open-source trading strategies we checked broke a rule
On-prem
your code and data never leave your servers
Why it matters
A human makes a mistake once. An algorithm makes it thousands of times before anyone can react. The incidents below had different triggers — but each ended with orders that the firm's own limits should never have let through.
2012 · US
$460M+
lost in about 45 minutes
Retired order logic woke up on one server. Filled orders were never marked as filled, so it kept sending more — millions of them.
A “never buy more than the parent order” rule, proved, cannot be broken that way.
Source ↗2022 · UK
£61.6M
in UK fines (plus €13M in Germany)
An oversized basket got past controls that could be overridden; $1.4bn of European shares were sold before it was stopped.
A maximum order value that is proved to hold leaves no path for that order to reach the market.
Source ↗2013 · China
¥523M
regulatory fine
A fault in the order-generation system fired ¥23.4bn of buy orders in seconds.
Order-size and exposure caps that are proved, not assumed.
Source ↗2012 · India
−15.5%
intraday fall in the Nifty
One set of wrongly sized orders (about ₹650 crore) triggered circuit breakers on NSE.
Size and price-band checks that hold for every order, every time.
Source ↗Figures from regulators and press reports linked above. Not every incident was a logic bug; each is a case where a proved limit would have held.
Backtesting vs proof
A backtest is a fire drill. It shows the building held up on the day you tried. A proof is the structural engineer's sign-off: it shows the building holds under every load the code allows.
Most trading blow-ups aren't caused by a crazy market. They're caused by an unusual order of events — a fill that lands between two confirmations, a cancel that crosses a fill. Like two bank tellers approving withdrawals from the same balance at the same moment: each check was right, the timing broke the rule. History records one order of events per day. Giolit checks them all.
Backtest
History records one order of events per day. The sequence that breaks your limit — the red dot — needs a fill to land at just the wrong moment. It is not in the data, so it is found in production.
Giolit proof
Every price move, fill, reject and cancel, in every order. When PROVEN, no sequence — however unlikely — breaks the rule. When one exists, you get the shortest.
60-second self-check
Six ordinary sequences of events behind real trading losses. Answer honestly — “yes” only if you could show proof, not just that it hasn't happened yet.
01Does your position limit count orders that are sent but not yet filled?
02If you route to more than one exchange, can the same quantity never fill twice?
03Is a cancelled order guaranteed never to fill afterwards in your logic?
04Does your kill switch stop every venue — including orders sent from fill handlers?
05For pair or hedge trades, is there a rule for when one leg is rejected?
06Is your risk check guaranteed to see the latest position, never an out-of-date one?
0 of 6 answered. Most desks answer “not sure” to at least two — these are exactly the cases backtests never exercise.
A real example — step through it
An algo buys Infosys (INFY) 100 shares at a time and hedges each purchase by selling TCS. The risk rule: never more than 100 shares unhedged. In years of historical data, the hedge always came back before the next price update — so every backtest passed.
The verifier found the sequence history never contained. Click through it — six ordinary events.
Your developers get the same sequence as a replay file for their own tools. Both the broken and the fixed strategy ship in the free trial.
Replay · step 1 of 6
Rule: never more than 100 shares unhedged
Price update on INFY
The market moves.
→ Algo buys 100 INFY
How it works
Send your risk policy — “max 1,000 shares”, “no orders after the kill switch”, “never overfill the parent”. Or point the verifier at your strategy code.
Every price move, every fill and partial fill, every cancel and reject, in every possible order — for any number of orders, across every exchange you trade on.
PROVEN: no sequence of events can break the rule, with evidence to keep. Or BROKEN: the exact steps that break it, for your team to fix and re-check.
Runs entirely on your own machines. No cloud, no upload, no third-party solver — and nothing added to your live trading path. Checks run before release, not during trading.
Who it's for
“Can a client's algo get past our limits?”
Prove your pre-trade limits hold against any algorithm a client could ever run — without seeing their code or their strategy. Built for the broker-as-principal model of SEBI's retail algo framework.
“Will Monday's release breach a limit at the open?”
Check every release automatically. If a change can break a limit, the release is blocked and you see exactly how — before it trades.
“How do we show brokers our algo is safe?”
Ship each version with a signed certificate, checked across every setting a client can choose — not just the defaults you tested. Faster approvals, a sharper pitch.
“Show me evidence, not a folder of test logs.”
A signed certificate per version — proofs and safety margins your auditors can check offline — plus checks of live trading logs against your rules. Evidence for your compliance work; it does not make you compliant by itself.
“What's our exposure if the algo misbehaves?”
Find the costly failure in an afternoon, not in production. Your code and data stay on your own servers.
India · SEBI retail algo framework
Since 1 April 2026, every broker offering retail algos must get each one approved by the exchange, tag its orders with an algo ID, and seek fresh approval after any change. Hand the exchange — and yourself — a proof, not a promise.
SEBI circular, 4 Feb 2025 ↗Pre-trade risk controls
The controls regulators and the FIA's automated-trading guidance expect — and what the verifier proves about each one, for any strategy and any number of orders.
No order larger than the cap can ever reach the market — whatever the algo does.
The position never exceeds the limit, counting orders still in flight — per symbol, per exchange, net and gross.
Every order is priced within the band around the market at the moment it is sent.
After the switch, no new order leaves on any exchange, and every working order is cancelled.
Execution algos and routers never buy or sell more than the parent order — even when two exchanges fill at once.
Rules about what may be sent hold on every path, including code that reacts to fills.
Tested on code we didn't write
We pointed the verifier at public strategies from Hummingbot and WonderTrader — popular open-source trading frameworks — without changing a line, and stated the rules any desk would expect them to keep. Each finding is a concrete sequence of events you can re-run from the free trial.
Built your bot on one of these? Check the version you forked before it trades real money.
When it refreshes its quotes, it sends new ones before the old ones are confirmed cancelled — two live quotes on each side. Found in 2 steps.
When the broker reports a fill as two messages (as many Chinese broker APIs do), more than one order works at once and the position cap is crossed.
The execution algorithm can trade past its target quantity — in 4 steps from a flat start.
Same rule, same outcome: the position can pass the target.
Stays within its lot limits and never flips long-to-short without going flat first — both proven.
Certificate of formal verification
When every rule holds, you don't just get a green tick — you get a signed Certificate of Formal Verification. Hand it to the exchange with your algo approval, file it for your auditor, or give it to the broker you're selling to. They can check it themselves, offline, without our tool.
Page 1 excerpts of real documents issued under professional license GIOLIT-PRO-2026-000003 on 27 October 2026. Every document carries its own number, the SHA-256 of the specification, and the full proofs or failing sequences on the following pages.
Regulation
Regulators ask you to test your algorithms, control every order and review it all once a year. Tests sample what could happen; a proof covers all of it. That is the evidence the verifier adds.
| Requirement | Where it comes from | What the verifier gives you |
|---|---|---|
| Exchange approval of each algo | SEBI retail algo framework (all brokers from 1 Apr 2026) · NSE / BSE algo approval | Evidence that each strategy keeps its order-size, position and kill-switch rules on every path — re-run in minutes when the algo changes. |
| Pre-trade risk controls | SEC Rule 15c3-5 · MiFID II RTS 6 · FIA best practices | Signed certificates proving that order size, value, price-band, position and kill-switch controls hold for any strategy. |
| Testing before go-live & after changes | RTS 6 testing · SEBI system audit | Every rule checked against every order of events; failures as replayable logs; the same check on every release. |
| Annual review & certification | RTS 6 self-assessment · 15c3-5 annual review and CEO certification | A signed certificate per version: proofs, safety margins and SHA-256 hashes, checkable offline by your auditor. |
The verifier supplies evidence; it does not by itself make a firm compliant with any regulation. Rules differ by jurisdiction and change — check the current text with your compliance team. Trial documents are watermarked; signed certificates are issued by the licensed edition.
Get started
Start here
1000 checks over 50 days on your own Linux machine — with 22 worked examples, 9 strategy templates and everything you need to check your own strategy.
Start your free trialFor approvals & audits
We verify your strategy or risk gateway and issue a signed Certificate of Formal Verification — ready for your exchange approval, audit or annual review.
Talk to our teamFor desks & platforms
Run it on every release, in your own build pipeline, for every strategy and every client algo.
Get a licenceThe 6-page brochure
Forward it to your head of risk, your CTO or your compliance officer.
FAQ
Backtesting tells you how a strategy would have performed on historical data — keep doing it. But history contains only one order of events per day. The failures that cost money usually need an unusual order of events: a fill arriving between two confirmations, a cancel that crosses a fill, a hedge that comes back late. The verifier checks every order of events your rules allow, so it finds those before the market does.
No. You state rules in plain terms — “never hold more than 1,000 shares”, “nothing trades after the kill switch”, “never buy more than the parent order”. You get back PROVEN, or the exact step-by-step sequence that breaks the rule. Our team can help you turn your existing risk policy into rules.
Yes. Tell us what you trade and which limits matter most, and we'll help you set up the free trial and write your first rules. Your code never needs to leave your network.
Most checks finish in seconds to a few minutes on a laptop. A position limit was proved for 100,000 simultaneous orders in under half a second; a limit across 16 exchanges in 21 seconds.
You get the exact sequence of events that breaks the rule — usually 3 to 15 steps — as a readable report and as a replay file your developers can load into their own tools. They fix it, you run the check again, and the fix is proved.
Yes. When every rule holds, the licensed edition issues a signed Certificate of Formal Verification: each rule and its verdict, the proof, the safety margin for every limit, and SHA-256 hashes of the specification and evidence, signed under your licence. Your exchange, auditor or customer can check it offline without our tool. Giolit can also verify your strategy or risk gateway and issue the certificate for you.
No. Backtests measure profit; the verifier guarantees rules. It gives your risk, compliance and engineering teams evidence they cannot get from testing alone.
Use three layers: backtest for performance, paper-trade or test in an exchange mock session for connectivity, and verify the risk rules against every possible sequence of orders, fills, cancels and market moves. Only the last layer covers the rare timing cases behind most costly incidents.
Prove two things: after the switch is pulled, no new order can leave on any venue — including orders triggered by fills that arrive afterwards — and every working order gets a cancel. The verifier checks both for every order of messages, and shows the exact sequence if either can fail.
Yes. Under SEBI's circular of 4 February 2025 on safer participation of retail investors in algorithmic trading — applicable to all brokers from 1 April 2026 — brokers are responsible as principals for the algos they offer, each algo needs exchange approval and a unique identifier, and changes need fresh approval. The verifier helps produce testing evidence for those approvals; it does not by itself make a firm compliant.
Maximum order size and value, price bands and collars, position and exposure limits (per symbol, per venue, net, gross and beta-weighted), market-order bans, kill switches, and no-overfill rules for execution algos and smart order routers — the controls listed in FIA's automated-trading guidance, SEC Rule 15c3-5 and MiFID II RTS 6.
Yes. The verifier can treat the client algo as completely unknown — able to send any order or cancel at any moment — and prove your pre-trade limits still hold. No client code, no strategy secrets, nothing to disclose.
Strategies in C++, Python or Java are read directly from their source code — never executed — or described in a short rule file. Built-in templates cover market making, TWAP, VWAP, POV, pairs, lead–lag, delta hedging, smart order routing and pre-trade risk gateways. Five open-source strategies from Hummingbot and WonderTrader were checked from unmodified code.
No. Every engine is Giolit's own — no third-party solver, no cloud, no upload — and it adds nothing to your live trading path: checks run offline, before release.
1000 checks within 50 days on one Ubuntu 24.04 computer: the trade-verify tool, 22 worked examples (each bug next to its fix), 9 strategy templates, the full 180-rule benchmark with every result, and the brochure, tutorials and reference manual. Trial reports are watermarked; signed certificates come with a licence.
For engineers & quants
The model, the rule language, code import, evidence formats, templates, benchmarks and CI — everything your engineering team will want to check. Open any section.
Each rule is one line. Prices, quantities, money and time carry units, so mixing up ticks and rupees is an error, not a silent bug.
long_limit: always position <= max_long;
kill_stops: after kill_switch: never new_order;
order_size: always on new_order: order.qty <= max_clip;
Point the verifier at the strategy or risk layer you already run, in C++, Python or Java. Nothing is restated by hand, nothing is executed, and any simplification the verifier makes is reported to you — never hidden.
Risk headroom
For every proven limit the verifier tightens it step by step and proves again: the worst value any run reaches, whether a run reaches it, and how much of the limit is never used.
long_limit ≤ max_long = 1000
A run reaches exactly 1000 — controls built to stop at the limit.
strategy proven to stay ≥ 50% below
Room to spare — evidence for setting a tighter limit.
$ trade-verify --headroom examples/06_controls_only.gts
PROVEN long_limit always position <= max_long
headroom: max 1000, reached; 0% unused *....
Evidence bundle
Proof
A proof for every rule that holds, stated in your own terms — for your records and your auditors.
Certificate or report
A signed PDF certificate when all is proven; a violation report with every failing sequence when not.
Every run
As text, JSON, FIX 4.4 messages and a CSV market path — replay it in your harness.
Integrity
SHA-256 of the specification and every evidence file; an offline check script for auditors.
$ trade-verify desk.gts --report=bundle --issued-to="Acme Broking"
$ trade-verify desk.gts --conform=dropcopy-2026-10-09.fix
IMPOSSIBLE message 7: a fill needs a live acknowledged order
Result: THE LOG DOES NOT CONFORM TO THE SPECIFICATION
Check pre-trade controls on their own: an unknown algorithm may send any order or cancel at any moment.
Reads the strategy or risk layer from C++, Python or Java via a short mapping file. Read, never run.
Messages from different exchanges arrive in any order; risk checks may run on their own thread.
Positions per symbol; net, gross and beta-weighted exposure; multi-leg orders checked together.
A model's output (a z-score, a fair value) can take any value in its range — verify the logic without disclosing the model.
Strategies written with floating point are checked bit-for-bit as your code computes them, rounding included.
How close every proven limit ever gets, and how far it could be tightened.
A signed certificate when every rule holds; a report with every failing sequence (text, JSON, FIX, price path) when not.
Replay a production trading log against your rules: every impossible message, every order the rules would not send.
Take an algo's client parameters from FIXatdl and verify every value a client can choose.
Prove the edge a market maker locks in and its worst-case loss; show “never loses money” false with a sequence.
Prove a parent order can — or can never — complete on schedule; bound execution cost from both sides.
Market maker
inventory limits · quotes never cross · quote size · limit orders only · kill switch
TWAP · VWAP · POV
never overfilled · on schedule · participation cap · child size · one side
Pairs
at most one pair half-done · leg caps · gross and beta-weighted exposure
Lead–lag
trades the follower only · position limits · one order at a time
Delta hedge
every hedge reduces net delta · never overshoots · hedge limits
Smart order router
no overfill across exchanges · per-exchange exposure · cancels everything after the kill switch
Pre-trade risk gateway
order size · order value · price band · no market orders · position limits · kill switch
$ trade-verify --template=pairs > my_pairs.gts
01 / 02 position_limit
A check on the position alone lets two orders through (6 events) — counting open orders proves it.
03 / 04 kill_switch
A fill handler sends an order after the kill switch; a control stops it, proved.
05 late_fill
An exchange that fills after a cancel: overfill and a fill after cancel.
06 / 07 controls_only
Controls proved against any strategy — and a gap on the sell side.
08 / 09 vwap
A VWAP schedule that can never complete — proved impossible — and its fix.
12 / 13 avellaneda_stoikov
Skewed quotes cross the market; clamped quotes are proved.
14 / 15 smart_order_router
NSE + BSE both fill (overfill); a kill switch that stops one exchange.
16 market_maker_pnl
Edge locked in and worst-case loss proved; “never loses” broken.
19 / 20 pairs_legs
A rejected leg leaves the pair half done; opening only from balanced positions is proved.
Release benchmark
Tutorial examples
position limits, kill switch, SOR, pairs, market makers, VWAP
Strategy templates
9 families, every standard constraint proved as shipped
Imports from C++, Python, Java
the same clip strategy in three languages, ladders, a C++ market maker, a pre-trade gateway
Open-source strategies
Hummingbot and WonderTrader, unmodified code at pinned commits, with their licenses
44 specifications. Every result ships in the trial — console output, results.json and reproduce.sh — and MANIFEST.tsv lists each rule with its expected verdict. Rerun any of them yourself.
Scale
Measured on a laptop, one run at a time. Proofs hold for any number of orders.
$ trade-verify strategy.gts --timeout=120 \
--json=results.json --junit=results.xml \
--baseline=release-1.4.json
# a lost proof is a regression: the build fails, the run attached
Exit 0
all proven
Exit 1
violated
Exit 2
undecided
Exit 3/4
usage / license
GitHub Actions and GitLab CI configurations ship in the trial.
C++ SDK: run checks, safety margins, log replays and reports from your own tools.
Outputs: JSON, JUnit, FIX 4.4 and CSV — runs load into your FIX tools, backtester and dashboards.
Requirements: one Ubuntu 24.04 x86-64 machine. Full install steps are on the download page.
Tutorials & Reference Manual on GitHubThe Giolit Program Verifier proves C projects free of run-time errors; the Giolit SVA Verifier proves SystemVerilog assertions for all inputs — useful for the FPGA and low-latency C under your stack.
Free trial
1000 checks over 50 days, with worked examples for the most common trading failures. Nothing leaves your network. Questions along the way? Our team is happy to help.
