# Mechanika plnění: co se děje s *příkazem* od kliknutí po vyplnění

Autor: Jiří Fabšic · 12. 7. 2026 · Kategorie: Platforma
Kanonická URL: https://www.binaryfintech.com/blog/mechanika-plneni/

> Co se skrývá za kliknutím na „koupit

## TL;DR

- **Kliknutí na „koupit" není nákup — je to příkaz:** objekt s vlastním typem, dobou platnosti a životním cyklem, který putuje burzou, rizikovou vrstvou a matching enginem. Každý z nich ho může přijmout, odmítnout, naplnit po částech, nebo nechat vypršet.
- **„Koupit" má devět podob.** Market, limit, stop a jejich příbuzní se liší v jediném: co obětují — jistotu ceny, nebo jistotu plnění. K tomu doba platnosti a instrukce jako „jen maker", „jen zavírej pozici" nebo „z objemu ukaž jen kousek".
- **Velký objem nejde do trhu najednou.** Rozprostře se do menších dílčích příkazů v čase, aby netlačil na cenu — je to volba mezi spěchem a náklady. Institucionální trading v malém.
- **Poctivá simulace tohle všechno modeluje** — typ příkazu, jeho životní cyklus, plnění po částech i pojistky, které nepustí nemožný obchod. Kde to backtest odbude, tam zase začíná lhát.

V článku [Proč backtest lže](https://www.binaryfintech.com/blog/proc-backtest-lze/) jsme si řekli, že poctivý test musí počítat s poplatky, spreadem, frontou a skluzem — a slíbili jsme, že se do mechaniky příkazů podíváme zblízka. Tady je. Protože za tím nenápadným kliknutím na „koupit" se skrývá překvapivě bohatý svět: **váš příkaz má typ, dobu platnosti a vlastní život**, během kterého projde burzou, rizikovou vrstvou i matching enginem.

Možná jste to zažili: zadáte nákup na deset kusů a vyplní se vám tři. Zbytek visí. Nebo pošlete příkaz a burza ho rovnou odmítne, protože něčemu neodpovídá. **Příkaz totiž není tlačítko „staň se", ale žádost s pravidly** — a čím dřív těm pravidlům rozumíte, tím míň vás naživo překvapí. Naivní backtest je nezná: pošle, naplní celé, za cenu na grafu, pokaždé. Skutečná burza je o poznání méně velkorysá.

Projdeme to popořadě: jaké typy příkazů vůbec existují a co který obětuje, jakým životním cyklem příkaz projde, jak se v živém orderbooku tvoří cena, jak se velký objem plní po částech, aby netlačil na cenu, a jaké pojistky brání tomu, aby prošel nemožný obchod. U každého kroku ukážeme, **jak s ním počítá náš engine** — protože přesně tam, kde se tahle mechanika modeluje poctivě, přestává backtest lhát.

## Zvěřinec příkazů: víc než „market" a „limit"

V minulém článku nám stačila dvojice market a limit — vzít cenu hned, nebo si počkat na svou. Skutečná paleta je ale širší a každý typ příkazu je jiná dohoda o tomtéž: **co obětujete — jistotu ceny, nebo jistotu plnění.**

- **Market.** Jistota plnění, ne ceny. Berete likviditu, platíte spread a skluz.
- **Limit.** Jistota ceny, ne plnění. Stojíte ve frontě a cena kolem vás může proletět, aniž se na vás dostane.
- **Stop (market, nebo limit).** Spící příkaz, který se probudí, až cena dosáhne spouštěče. Pak se chová buď jako market (jistota plnění za tržní cenu), nebo jako limit (za vaši cenu, ale bez jistoty). Klasika pro stop-loss i pro nákup na proražení.
- **„If touched" varianty.** Zrcadlo stopu obrácené na druhou stranu — spustí se, když se cena úrovně dotkne shora. Hodí se na nákup na předem zvolené úrovni.
- **Trailing stop.** Spouštěč, který se posouvá s trhem. Drží zisk a utahuje se, jak jde cena vaším směrem; otočí-li se, vezme vás ven.
- **Market-to-limit.** Vejde do trhu jako market, ale tu část, která se hned nenaplní, si položí jako limit — místo aby se slepě prokousávala hlouběji do orderbooku.

**Drtivá většina backtestů tyhle specifické typy příkazů úplně ignoruje** — a přitom volba typu příkazu je sama o sobě součástí strategie. Ke každé strategii patří i její **strategie plnění**: jak přesně otevírat a zavírat pozice. Někdy hrajete o čas a jistotu — chcete mít aktivum nakoupené hned, ať to stojí, co to stojí; jindy hrajete o cenu a můžete si počkat. Který režim zvolit, se navrhuje podle brokera a jeho poplatkových pásem: u velkoobjemových strategií, kde jde limitky uplatnit, vám levnější maker plnění pomůže — ale tam, kde je riziko obrácení ceny proti vám neúnosné, vůbec neřešíme, jestli zaplatíme maker, nebo taker poplatek; bereme jistotu plnění a poplatek je vedlejší.

V kvalitních strategiích se způsoby plnění navíc **kombinují** — a protože jsou to plnohodnotné parametry, patří i ony do testů. Jednou ze závěrečných fází testování je právě otázka, **jaký typ příkazu a jaká strategie plnění se pro danou strategii hodí nejlíp.** Trend-following se třeba vyplatí zkusit na trailing limitkách: když už momentum jede, vezeme se s ním a nechceme zavřít předčasně. Jindy sáhneme po pevných limitkách, které se dají doladit podle nového vývoje trhu. A někdy visíme v limitce, trh se ale zlomí — pak ji zrušíme a pozici zavřeme okamžitým marketem.

S tím souvisí i jistá **zdrženlivost**: do obchodu vstupujeme většinou v klidu, s dobrou pravděpodobností a s možností počkat si na svou cenu — kdežto **výstup musí být často rázný, rychlý a „dražší"**, když jím předcházíme ještě větší ztrátě. Vstup a výstup zkrátka nejsou symetrické.

**Právě proto je obří výhoda, že náš engine umí velmi věrně napodobit všechny běžně používané typy příkazů** — strategii plnění tak u nás otestujete stejně poctivě jako samotné vstupy a výstupy.

K typu příkazu patří i jeho **doba platnosti** — jak dlouho má v orderbooku žít, než ho burza zahodí. *Do zrušení* (GTC) platí, dokud ho sami nestáhnete; *okamžitě, zbytek zruš* (IOC) naplní hned, co jde, a co nejde, škrtne; *všechno, nebo nic* (FOK) naplní celý příkaz naráz, jinak nic; *do data* (GTD) vyprší v určený čas; a jsou i varianty do konce dne nebo na otevření a zavření trhu. Není to formalita — na rychlém trhu je rozdíl mezi „naplň, co stihneš" a „všechno, nebo nic" rozdílem mezi obchodem a prázdnem. A i tyhle detaily mají hlubší smysl: chcete-li, aby **tentýž kód běžel v backtestu i naživo** — jeden spustitelný soubor pro obojí — musí s nimi počítat rovnou. A protože je za vás obstará engine, zůstává samotná strategie co nejštíhlejší, nejpřehlednější a nejefektivnější.

A pak jsou tu instrukce, které příkaz doladí: **jen maker** (post-only — když by se z příkazu měl stát taker, radši ho neposílej, ať neplatíte vyšší poplatek), **jen zavírej** (reduce-only — tenhle příkaz smí pozici pouze snižovat, nikdy omylem neotevře opačnou) a **iceberg** (z objemu ukaž navenek jen špičku, zbytek drž skrytý, ať velký příkaz nevystraší trh). Strategie si tak sáhne přesně po tom nástroji, který na její záměr sedí.

## Životní cyklus příkazu: ne „poslal → vyplnil"

V hlavě si příkaz snadno zjednodušíme na dvě polohy: poslal jsem ho, a buď se vyplnil, nebo ne. Skutečnost je jemnější — **příkaz prochází celým životním cyklem a o každé jeho změně dostane strategie zprávu.**

Nejdřív vznikne u vás. Než odejde na burzu, projde **rizikovou kontrolou** — a tady může skončit dřív, než začal: když něčemu neodpovídá, je **zamítnut** (o těch pojistkách za chvíli). Projde-li, je **odeslán** a burza ho buď **přijme**, nebo **odmítne**. Přijatý příkaz čeká v orderbooku; stop navíc čeká na svůj **spouštěč**. Pak přijde plnění — a to nemusí být naráz: příkaz může být **částečně vyplněn**, kus po kuse, než je **vyplněn** celý. Cestou může být **zrušen**, nebo **vypršet**.

*Obrázek: Životní cyklus příkazu ve dvou doménách, které dělí latence: v **našem enginu** příkaz vznikne a projde rizikovou kontrolou, na **burze** je přijat a vyplněn — po částech, nebo naráz. Vedle téhle hlavní cesty vedou i jiné konce: zamítnutí, odmítnutí, zrušení nebo vypršení.*

Proč to není hnidopišství? Protože **naivní backtest zná jen dva z těch stavů — poslán a vyplněn — a všechno mezi tím přeskočí.** Nevidí zamítnutí, odmítnutí, částečné plnění (to jde zčásti statisticky modelovat) ani expiraci. A přitom právě ty rozhodují: příkaz, který by naživo burza odmítla nebo naplnila jen zpola, se v takovém testu klidně naplní celý — a equity křivka nabere obchody, které by v realitě nikdy neproběhly. Náš engine prochází celým cyklem a strategie reaguje na každý jeho krok stejně, jako by reagovala naživo — je to totiž přesně tentýž kód, o čemž je řeč v článku [Backtest, který se chová jako živý trh](https://www.binaryfintech.com/blog/backtest-jako-zivy-trh/).

## Mechanika orderbooku: cena je průsečík, ne číslo

Než se pustíme do velkých objednávek, musíme si přiznat jednu věc o orderbooku: **je živý.** To, jak orderbook vypadá teď, neříká skoro nic o tom, jak bude vypadat za deset milisekund — především co se týče spreadu a jemu nejbližších hladin. Nabídky (ask) a poptávky (bid) na jednotlivých hladinách vznikají, mizí a přeskakují v každém okamžiku — proto se s orderbookem nezachází jako s fotkou, ale jako s proudem: **snapshot stavu a pak nekonečná řada přírůstkových změn** na hladinách. Kdo si trh zredukuje na jediné číslo „cena", tohle celé přehlédne. A pokud pro své backtesty sháníte orderbooková data: samotné snapshoty jsou podle nás k ničemu — bez proudu přírůstkových změn nezachytí, co se mezi nimi v orderbooku doopravdy dělo.

V minulém článku jsme řekli, že backtest si trh rád zjednoduší na **nejlepší nabídku a poptávku** — spread mezi nejvyšším bidem a nejnižším askem. I kdyby ale bral zrovna tuhle cenu, chybí mu ta podstatná otázka: **kolik jí na té nejlepší úrovni vlastně leží?** Na nejlepším asku může sedět pět kusů, nebo pět tisíc — a jestli se váš příkaz vejde, rozhodne, za kolik se naplníte. Když je objednávka větší než dostupný objem, prokoušete se hlouběji do orderbooku, hladinu po hladině, za čím dál horší ceny. **Nerozhoduje „jaká je cena", ale „jak hluboký je orderbook vůči velikosti mé objednávky."** Drobný příkaz na likvidním trhu tuhle starost skoro nemá; velký — nebo na tenkém trhu — ji má celou.

Stojí za to si u toho srovnat i samotný pojem ceny. Když cena vyskočí na dvojnásobek, kapitalizace trhu se zdvojnásobí taky — **ale peněz, které do trhu reálně natečou, může být jen zlomek toho nárůstu.** Cena totiž není účetní suma, ale **marginální průsečík: nabídka prodat se protíná s aktuální potřebou koupit, a naopak.** Určuje ji ten následující dotek na hraně orderbooku — a hrstka rozhodnutých kupců proti tenké nabídce ji zvedne víc než obří, ale nečinný kapitál, který jen přihlíží. Ten skok v kapitalizaci je pak z větší části papírové přecenění, ne hora peněz, co někam natekla.

Odtud plyne i to, proč se trh umí hnout zdánlivě z ničeho. **Zmizí-li z jedné strany orderbooku likvidita** — třeba když se nad trhem stáhnou prodejní limitky — zůstane po ní řídké pásmo a cena jím proletí skokem. A ten skok se rád **řetězí a zesiluje:** první pohyb probudí algoritmy, které na něj reagují, a ty ho přiživí. Přidají se likvidace pozic, scalpovací automaty, další účastníci — a k tomu ryze lidská složka, **FOMO** při rychlém růstu. Během takového pohybu navíc leckdo své prodejní příkazy naopak **ruší**, aby nevystoupil moc brzo, a nabídku tím ztenčí ještě víc. Smyčka se sama krmí a opakuje — **dokud nezačne slábnout momentum.** Tuhle dynamiku, podloženou čísly a backtesty, rozebereme v samostatném článku; tady nám stačí vidět, že se celá odehrává uvnitř orderbooku.

Pro naši mechaniku plnění z toho plyne jediný, ale zásadní závěr: **za jakou cenu — a jestli vůbec — se váš příkaz naplní, určuje hloubka a pohyb orderbooku, ne číslo na grafu.** Poctivá simulace proto s tou hloubkou pracuje (snapshotem i změnami) a **své plnění průběžně srovnává s tím, co v trhu reálně padlo.** Jinak uvěří i tomu, co orderbook jen „ukazuje" — jako u **iceberg orderů**, které z celého objemu vystrčí navenek jen špičku a zbytek nechají schovaný pod hladinou. Kolik je za nejlepší cenou doopravdy, prozradí až skutečné obchody — a přesně proti nim plnění ověřujeme.

## Plnění po částech: když strategie nespěchá

Vraťme se k orderbooku a jeho hladinám. Když má strategie zobchodovat velký objem, naráží na to, co jsme právě viděli: **vložit ho do trhu najednou nejde, aniž by si sama zhoršila cenu.** Velký market se prokouše hladinami a čím výš leze, tím dráž nakupuje. Velká limitka zase v orderbooku „svítí" a prozradí záměr ostatním, kteří se podle něj zařídí.

Řešení, které používají profesionálové i náš engine, je prosté: **velký příkaz se rozprostře do řady menších dílčích objednávek rozložených v čase.** Místo jednoho úderu pošle strategie objem po dávkách — pravidelně, přes zvolený časový horizont. Účel je jediný: **nekoncentrovat objem do jednoho okamžiku, a tím netlačit na cenu.** Je to institucionální uvažování ve zmenšenině — a přesně ten způsob plnění, který naivní backtest, jenž celou pozici odbaví jednou cenou, vůbec nevidí.

*Obrázek: Stejné osy pro obě strategie — kolik koupíte (vodorovně) a za jakou cenu se to plní (svisle). Naráz se cena šplhá po hladinách nahoru (vysoký průměr), po částech drží u nejlepší nabídky (nízký průměr); šrafovaný rozdíl průměrů je market impact, cena za spěch.*

Má to ale svou cenu, a tou je **čas.** Rozprostření dává smysl jen tehdy, **když strategie nespěchá** — když jí nevadí plnit se pozvolna výměnou za lepší průměrnou cenu a menší stopu v trhu. Kde je záměrem chytit rychlý pohyb, je tenhle luxus pryč a platí se plnou cenou okamžitého plnění. Je to volba, ne automatika: **spěch, nebo náklad.** Strategie u nás si ji řídí sama — určí horizont a tempo, a engine se o rozdělení postará; a když by byl dílčí kousek menší než nejmenší množství, které trh přijme, pošle příkaz radši celý, ať to nekomplikuje zbytečně.

## Podmíněné příkazy: vstup, cíl a stop jako jeden celek

Málokdy chcete jen „koupit". Většinou chcete koupit **a zároveň** předem vědět, kde vyberete zisk a kde ustřihnete ztrátu. Od toho jsou **podmíněné (bracketové) příkazy** — svázané skupiny, kde příkazy hlídají jeden druhého.

Dvě spojení stačí znát. **Jeden ruší druhý:** k pozici visí cíl i stop-loss zároveň, a jakmile se naplní jeden, ten druhý se sám zruší — nezůstane osiřelý příkaz, který by vás později vtáhl do trhu podruhé. **Jeden spouští druhý:** teprve když se naplní vstup, uvolní se k němu navázaný cíl a stop. Spojíte-li obojí, dostanete klasický bracket: vstup, který za sebou automaticky rozsvítí ochranu zisku i ztráty.

Proč to zmiňujeme u mechaniky plnění? Protože i tohle je součást toho, **jak se příkazy chovají — a jak se musí chovat i v testu.** Backtest, který svázané příkazy nezná, může nechat stop viset i po výstupu, nebo naopak uvolnit cíl dřív, než vstup vůbec proběhl — a počítá pak s obchody, které by ve svázané realitě nevznikly. Náš engine ty vazby drží, včetně toho, co se stane při **částečném** plnění vstupu: ochrana se uvolní jen na tu část pozice, která se skutečně otevřela.

Bracket ale není „nastav a zapomeň". Je to spíš **počáteční premisa**: podle toho, jak se trh vyvíjí — a co k tomu říká strategie, míra rizika i čerstvá data — se plánovaný výstup může posouvat, měnit, nebo úplně přehodnotit. A i když se stop nebo cíl vystaví rovnou na burze (to je jistota — burza na náhlou změnu zareaguje i bez nás, rychleji než náš systém), pořád se s tím příkazem dá dál pracovat: utáhnout ho, posunout, zrušit a nahradit. Vystavená ochrana je výchozí bod, ne konečná stanice.

## Vestavěné pojistky: proč u nás test nemůže podvádět

Zbývá vrstva, o kterou jsme párkrát zavadili: **pojistky, které stojí mezi vaším příkazem a trhem.** Naivní backtest je nemá — a proto v něm strategie beztrestně dělá věci, které by jí živý trh nedovolil. Poctivá simulace drží stejné mantinely jako burza a riziková vrstva před ní:

- **Nekoupíte za peníze, které nemáte.** Před odesláním projde příkaz kontrolou zůstatku, přesnosti a limitů objemu; co jim neodpovídá, je rovnou zamítnuto — s uvedeným důvodem, ne potichu.
- **Zacyklení neprojde.** Rychlostní limit utne strategii, která by chrlila příkazy nad rozumnou mez — pojistka proti chybě, jež by naživo spálila účet na poplatcích.
- **Exit neotočí pozici.** Uzavírací příkaz označený „jen zavírej" nikdy omylem neotevře opačný obchod — konec jedné běžné a drahé záměny.
- **Jedna pozice, ne skrytá druhá.** V režimu započítávání se opačné příkazy střetnou s otevřenou pozicí, místo aby vedle ní tiše vznikla druhá proti ní.
- **Nouzová brzda.** Celý provoz jde přepnout do režimu „jen snižuj expozici", nebo úplně zastavit — kill-switch pro chvíli, kdy se něco pokazí.

Každá z těch pojistek zní samozřejmě — dokud ji test nemá. Pak strategie na papíře nakupuje bez peněz, chrlí příkazy bez následků a omylem obrací pozice, a výsledek vypadá líp než cokoli, co by naživo přežilo. **Backtest, který tyhle mantinely ignoruje, zase začíná lhát** — jen tišeji než u poplatků. My je proto necháváme platit i v testu: co by neprošlo naživo, neprojde ani u nás.

Popravdě většinu takových chyb odchytíme a doladíme dávno před produkcí; tyhle pojistky jsou až poslední, nejhlubší vrstva. A právě v tom je princip **defence in depth** — obrany do hloubky: vedle robustnosti druhý pilíř, na kterém stavíme svůj přístup i engine, aby žádná jediná chyba neprošla celou cestou až k účtu. Téhle myšlence — v obchodování i v bezpečnosti celé platformy — se budeme věnovat v samostatném článku.

## Závěr: příkaz má svůj život

Za nenápadným „koupit" se skrývá celá mechanika: příkaz má svůj **typ**, svou **dobu platnosti**, svůj **životní cyklus** a své místo v živém orderbooku, který se mění rychleji, než stačíte mrknout. Velký objem se plní **po částech**, ochrana visí ve **svázaných** skupinách a nad vším bdí **pojistky**, které nepustí nemožné. Nic z toho není detail — všechno rozhoduje o tom, za jakou cenu a jestli vůbec se váš obchod stane.

A právě proto na tom v testu tak záleží. **Backtest, který příkaz zjednoduší na tlačítko „staň se", měří jiný trh než ten, na kterém pak obchodujete** — pohodlnější a neexistující, přesně jak jsme popsali v článku [Proč backtest lže](https://www.binaryfintech.com/blog/proc-backtest-lze/). Náš engine jde opačnou cestou: prochází celou tuhle mechaniku událost po události, tak jak rozebíráme v [Backtestu, který se chová jako živý trh](https://www.binaryfintech.com/blog/backtest-jako-zivy-trh/) — protože test, kterému máte věřit své peníze, musí příkaz brát stejně vážně jako burza.

**Čtení:** Navazuje na: [Proč backtest lže](https://www.binaryfintech.com/blog/proc-backtest-lze/) · [Backtest, který se chová jako živý trh](https://www.binaryfintech.com/blog/backtest-jako-zivy-trh/). Celá cesta strategie od nápadu po produkci: [testovací protokol](https://www.binaryfintech.com/blog/testovaci-protokol/).