Protokol FIX (“FIX Algorithmic Trading Definition Language”) je standard pro výměnu metainformací potřebných pro algoritmické obchodování na finančních trzích. Pracuje společně s protokolem FIX (Financial Information eXchange), který je lingua franca elektronického obchodování na trhu s cennými papíry.
Před polovinou devadesátých let se prakticky veškeré obchodování s cennými papíry uskutečňovalo po telefonu, ale s příchodem FIX se obchodování postupně přesunulo na elektronické prostředky. Protokol FIX se používá ke komunikaci mezi systémy pro správu příkazů na straně prodeje a na straně nákupu (OMS) k výměně příkazů a informací o provedení příkazů bez lidského zásahu pomocí standardizovaných zpráv a pracovních postupů, které jsou definovány protokolem.
Zpočátku firmy na straně prodeje poskytovaly prostřednictvím FIX pouze přístup ke svým “trading deskům”, což znamenalo, že jakmile příkaz dorazil k makléři na straně prodeje, zpracovával jej lidský obchodník, alespoň na začátku jeho životního cyklu. Následně začaly firmy na straně prodeje nabízet přímý přístup přes FIX na burzy/trhy, jichž byly členy; tento přístup je znám jako přímý přístup na trh (DMA). V této době mělo mnoho firem na straně prodeje vlastní systémy pro automatické obchodování na trhu pomocí algoritmických obchodních strategií a časem začaly chápat, že nabízet přístup k těmto obchodním strategiím straně nákupu je způsob, jak přilákat obchodníky a zvýšit příjmy.
FIX je sice rozšiřitelný protokol, ale v důsledku toho, že firmy na straně prodeje nabízejí přístup ke svým algoritmickým obchodním strategiím prostřednictvím FIX, vznikly dva problémy. První spočíval v tom, že každá strategie na straně prodejce měla své vlastní parametry, které musely být součástí příkazu, takže každá firma nakonec vyžadovala, aby do zprávy FIX byla zahrnuta jiná sada polí (ve FIXu známých jako “tagy”). To velmi ztěžovalo život nákupním stranám, a zejména jejich dodavatelům, protože přidávání nových algoritmů do jejich obchodních systémů a správa všech různých kombinací tagů se staly značnou režií pro jejich vývojové operace.
Druhým problémem pro trh bylo, že každá firma na straně prodeje měla specifický způsob, jakým chtěla, aby se její algoritmy zobrazovaly v systému OMS na straně nákupu, přičemž ovládací prvky v uživatelském rozhraní byly logicky uspořádány pro snadné zadávání příkazů. To se opět ukázalo jako výzva pro dodavatele systémů na straně nákupu, protože každá nová obrazovka pro každého makléře na straně prodeje vyžadovala zvláštní úsilí při vývoji a testování.
Toto řešení nebylo široce přijato, zčásti kvůli omezenému rozšíření FIX 5.0 a zčásti kvůli tomu, že firmy již měly na trhu funkční implementace, které nebyly ochotny bezdůvodně měnit. Možná ještě důležitější je, že se nepodařilo vyřešit to, co bylo pro trh podstatnějším problémem, a to složitost pro prodejce na straně nákupu vyplývající z nedostatečné standardizace.
Myšlenku použít strukturu XML k popisu prezentace uživatelských rozhraní algoritmů a jejich doprovodných parametrů poprvé v rámci pracovní skupiny navrhl Daniel Clayden, tehdy z JP Morgan Chase, v příspěvku na fóru v roce 2005. Členové pracovní skupiny tuto myšlenku rozvíjeli v průběhu roku 2006 a v lednu 2007 vyzvali širší průmyslovou veřejnost k účasti na semináři, na němž byly jejich nápady přezkoumány. Nakonec byla vypracována specifikace, která se začala beta testovat v červenci 2007. Tato specifikace se stala verzí FIXatdl 1.0, kterou schválil globální technický výbor FPL (GTC) 28. března 2008.
Přes počáteční nadšení se verze 1.0 na trhu celkově setkala s nevýrazným přijetím. Někteří dodavatelé viděli příležitost poskytovat služby v souvislosti s tímto standardem, jako například ULLINK se svou publikací a správou algoritmů a nástroj UL AMS, ale zatímco hlavní dodavatelé OMS byli podrážděni režijními náklady na implementaci nových makléřských algoritmů, začali se těšit z příjmů, které mohli získat jak od svých zákazníků, tak od makléřů, kteří chtěli dostat své algoritmy na pulty na straně nákupu.
Přestože verze 1.0 znamenala významný krok vpřed, měla některá významná omezení. Zejména definice přenášených dat a jejich prezentace v uživatelském rozhraní byly úzce svázány, což omezovalo flexibilitu makléřů na straně prodeje při definování jejich algoritmů. Specifikace 1.0 také neposkytovala dostatečnou kontrolu, pokud jde o rozvržení uživatelského rozhraní.
Pracovní skupina se rozhodla tato omezení odstranit ve verzi 1.1 specifikace. První významnou změnou bylo oddělení definice obsahu dat od jejich prezentace a definování takzvané samostatné “datové smlouvy”, kterou tvoří parametry algoritmu, jejich datové typy a podpůrné informace, jako jsou minimální a maximální hodnoty. Samostatná část dokumentu XML se pak zabývá rozvržením uživatelského rozhraní, tím, jaké ovládací prvky se mají použít pro jednotlivé parametry a kam je umístit na obrazovce. K zajištění platnosti a správného tvaru souborů FIXatdl je k dispozici schéma XSD.
FIXatdl verze 1.1 byl předběžně schválen GTC 9. února 2010, kdy vstoupil do období pro veřejné připomínky, a poté definitivně schválen 3. března 2010. Specifikace byla oficiálně uvedena na trh na konferenci FPL pro Evropu, Střední východ a Afriku 23. března 2010.
Dokument FIXatdl může obsahovat jednu nebo více definic strategie. V rámci definice strategie existují následující čtyři hlavní části:
Možnosti uživatelského rozhraní[]
Verze 1.1 podporuje 14 různých ovládacích prvků uživatelského rozhraní, které lze rozdělit do následujících skupin:
Ovládací prvky jsou uspořádány pomocí hierarchie panelů (označovaných jako StrategyPanels), z nichž každý může být orientován horizontálně nebo vertikálně. Obrázek vpravo ukazuje, jak prvky XML odkazují na jednotlivé panely v rámci daného rozložení.
Další standardy uživatelského rozhraní[]
Často byla kladena otázka, proč FIXatdl nepoužívá hotový standard uživatelského rozhraní, jako je XUL od Mozilly, Windows Presentation Foundation od Microsoftu nebo Apache Flex? To je oprávněná otázka, ale zdá se, že autoři specifikace chtěli zachovat naprostou nezávislost na platformě a přijetím jakékoli platformy by riskovali, že tento návrh bude poškozen. Současná specifikace sice není tak propracovaná jako některé z těchto platforem, ale poskytuje přijatelnou míru kontroly, pokud jde o uspořádání uživatelského rozhraní, aniž by byla nepřiměřeně omezující. Uvidíme, jak se tato volba návrhu osvědčí, a zdá se pravděpodobné, že s rostoucím počtem uživatelů bude nutné tuto část specifikace dále zdokonalovat.