FIXatdl

FIX Algorithmic Trading Definition Language , mer känt som FIXatdl , är en standard för utbyte av metainformation som krävs för att möjliggöra algoritmisk handelsaktivitet på finansmarknaderna. Det fungerar tillsammans med Financial Information eXchange (FIX)-protokollet som är lingua franca för elektronisk handel värdepappersmarknaden .

Bakgrund

Före mitten av nittiotalet skedde praktiskt taget all handel med värdepapper via telefon, men med tillkomsten av FIX gick handeln stadigt över till elektroniska medel. FIX-protokollet används för att kommunicera mellan orderhanteringssystem på säljsidan och köpsidan (OMS) för att utbyta order och orderutförandeinformation utan mänsklig inblandning, med hjälp av standardiserade meddelanden och arbetsflöden som definieras av protokollet. Till en början gav företag på säljsidan endast tillgång till sina "handelsbord" via FIX, vilket innebar att när en order väl kom till mäklaren på säljsidan, hanterades den av en mänsklig handlare, åtminstone i början av dess livscykel. Därefter började säljsidan erbjuda direktåtkomst via FIX till de börser/marknader de var medlemmar i; detta kallas direkt marknadstillträde (DMA). Vid den här tiden hade många företag på säljsidan sina egna proprietära system för att handla automatiskt på marknaden, med hjälp av algoritmiska handelsstrategier , och med tiden började de inse att att erbjuda tillgång till dessa handelsstrategier till köpsidan var ett sätt att attrahera affärer och öka intäkterna.

Även om FIX är ett utbyggbart protokoll, fanns det två utmaningar som uppstod som ett resultat av att företag på säljsidan erbjöd tillgång till sina algoritmiska handelsstrategier via FIX. Den första var att varje strategi på säljsidan hade sina egna parametrar som måste inkluderas som en del av beställningen, så varje företag krävde en annan uppsättning fält (kända i FIX som "taggar") för att inkluderas i FIX. meddelande. Detta gjorde livet mycket svårt för köpsidan, och i synnerhet för deras leverantörer, eftersom att lägga till nya algoritmer till deras handelssystem och hantera alla olika kombinationer av taggar blev en betydande overhead för deras utvecklingsverksamhet.

Den andra frågan för marknaden var att varje säljsideföretag hade ett specifikt sätt de ville att deras algoritmer skulle visas på köpsidans OMS, med kontroller i användargränssnittet logiskt arrangerade för enkel orderingång. Återigen visade detta sig vara en utmaning för systemleverantörerna på köpsidan, eftersom varje ny skärm för varje mäklare på säljsidan krävde en dedikerad utvecklings- och testinsats.

Historia

För att ta itu med dessa problem etablerade FIX Protocol Limited arbetsgruppen för algoritmisk handel under tredje kvartalet 2004. Gruppens initiala fokus var att lösa det första av dessa problem, vilket den gjorde genom att definiera en ny grupp av fält, StrategyParametersGrp, som består av FIX-taggar 957 till 960 – dessa taggar introducerades formellt i och med lanseringen av FIX 5.0 under fjärde kvartalet 2006. Genom att tillåta företag på säljsidan att inkludera sina egna fält i en repeterande namn-värde-parstruktur, fanns det inget krav för OMS-leverantörer att definiera specifika FIX-meddelandestrukturer för varje handelsdestination på säljsidan.

Denna lösning användes inte i stor utsträckning, dels på grund av den begränsade penetrationen av FIX 5.0 och dels på grund av det faktum att företag redan hade fungerande implementeringar på marknaden som de inte var villiga att ändra utan goda skäl. Kanske ännu viktigare, det misslyckades med att lösa det som var det mer väsentliga problemet för marknaden, komplexiteten för köpsidans leverantörer till följd av bristen på standardisering.

Idén att använda en XML-struktur för att beskriva presentationen av algoritmanvändargränssnitt och deras medföljande parametrar föreslogs först inom arbetsgruppen av Daniel Clayden, sedan av JP Morgan Chase i ett foruminlägg 2005. Medlemmar i arbetsgruppen utvecklade denna idé under 2006 och bjöd i januari 2007 in bredare branschdeltagande vid en workshop för att se över sina idéer. En specifikation togs så småningom fram och denna började betatestning i juli 2007. Denna specifikation blev FIXatdl 1.0 som godkändes av FPL Global Technical Committee (GTC) den 28 mars 2008.

Trots viss initial entusiasm fick version 1.0 totalt sett ett svagt mottagande av marknaden. Vissa leverantörer såg en möjlighet att tillhandahålla tjänster kring standarden, till exempel ULLINK (nu en del av Itiviti) med sin algoritmpublicering och hantering och verktyg UL AMS, men medan de stora OMS-leverantörerna var irriterade över den omkostnad de skulle ha med att implementera nya mäklaralgoritmer, hade de vuxit för att kunna dra nytta av de intäkter som de kan få från både sina kunder och från mäklare som är angelägna om att få sina algoritmer på köpbord.

Även om version 1.0 var ett stort steg framåt, hade den några betydande begränsningar. I synnerhet var definitionen av de data som skulle överföras och dess presentation i användargränssnittet tätt sammanbundna, vilket begränsade den flexibilitet som mäklare på säljsidan hade när det gäller att definiera sina algoritmer. 1.0-specifikationen gav också otillräcklig kontroll när det gäller layouter för användargränssnitt. Arbetsgruppen hade för avsikt att ta itu med dessa begränsningar i vad som skulle bli version 1.1 av specifikationen. Den första stora förändringen var att dela upp definitionen av datainnehållet från presentationen, definiera vad som kallas ett separat "Datakontrakt" som består av algoritmparametrarna, deras datatyper och stödjande information såsom minimi- och maximivärden. En separat del av XML-dokumentet handlar sedan om layouten på användargränssnittet, vilka kontroller som ska användas för varje parameter och var de ska placeras på skärmen. Ett XSD-schema tillhandahålls för att säkerställa att FIXatdl-filer är giltiga och välformade.

FIXatdl version 1.1 godkändes preliminärt av GTC den 9 februari 2010, när den gick in i en offentlig kommentarsperiod, och godkändes sedan slutligen den 3 mars 2010. Specifikationen introducerades formellt på marknaden vid FPL:s Europa Mellanöstern och Afrika konferens den 23 mars 2010.

En del tidigt arbete utfördes på en version 1.2 av standarden, men bristen på intresse från industrin för att ta emot ytterligare förändringar innebar att standarden förblev på version 1.1.

Dokumentstruktur

Ett FIXatdl-dokument kan innehålla en eller flera strategidefinitioner. Inom en strategidefinition finns det fyra huvudavsnitt enligt följande:

  • Metadatasektion som definierar vilka geografiska regioner, marknader (börser) och tillgångsklasser strategin är tillämplig på
  • Parametrarsektion, som listar var och en av parametrarna som används av strategin, deras datatyper, begränsningar (t.ex. minimum- och maximivärden) och hur de ska representeras i det resulterande FIX-meddelandet
  • StrategyLayout avsnitt som definierar användargränssnittskontrollerna som ska användas för denna strategi, hur de ska läggas ut på skärmen och hur de mappar till parametrarna som beskrivs i föregående avsnitt av dokumentet
  • StrategyEdit-avsnittet som beskriver valideringsreglerna som ska tillämpas – vanligtvis kommer dessa att vara valideringar över fält

FIXatdl-dokument bör valideras mot uppsättningen av XSD-scheman som tillhandahålls av FPL. Dessa scheman är organiserade i följande fyra kategorier:

  • Kärna (definierar datainnehåll, datatyper, begränsningar, etc.)
  • Layout (definierar kontrollerna som kan användas och hur de är upplagda)
  • Validering (självförklarande)
  • Flöde (gör att kontroller kan aktiveras/inaktiveras, döljas/visas och uppdateras, beroende på tillståndet eller innehållet i andra kontroller)

Användargränssnittsfunktioner

Strategipaneler

Version 1.1 stöder 14 olika användargränssnittskontroller, som kan grupperas enligt följande:

  • Etiketter
  • Textinmatningsfält (kallas ofta textrutor)
  • Kryssrutor och alternativknappar, både separat och i listor
  • Listboxar, både enstaka och flerval
  • Dropdown-listor, både redigerbara och icke-redigerbara
  • Klockkontroller, för inmatning av datum/tid
  • Reglage för att välja en av ett litet antal inställningar
  • Numeriska spinnare, både enkla och dubbla för heltal respektive flyttal

Kontroller är upplagda med hjälp av en hierarki av paneler (kallade StrategyPanels), som var och en kan vara horisontell eller vertikal i orientering. Bilden till höger visar hur XML-elementen refererar till de enskilda panelerna inom en given layout.

Adoption

Till skillnad från den tidigare versionen var version 1.1 allmänt accepterad och antagen av värdepappersbranschen. Redan i slutet av 2009 fanns det redan företag som använde 1.1-standarden, trots dess pre-release-status. Exempel på företag som stöder FIXatdl-standarden inkluderar:

  • RealTick Execution Management System, av Eze Software Group
  • SimCorp Dimensions Order Manager-modul
  • Itiviti, med deras Algorithm Management System, UL AMS
  • Portware Execution Management System
  • RapidAddition, med deras FIXatdl-redigerare
  • Assimilera teknologi, med deras Visual FIX-produkt
  • Cornerstone Technology, med deras FIXatdl Jump-Start-paketerade konsulttjänst, offentliga FIXatdl-utbildningsverkstäder och gratis FIXatdl-valideringstjänst, AtdlTools

Det finns även Java- och .NET -implementationer med öppen källkod, atdl4j respektive Atdl4net, som båda är version 1.1-kompatibla.

Andra standarder för användargränssnitt

Frågan har ofta ställts, varför använder FIXatdl inte en standard för användargränssnitt, som Mozillas XUL , Microsofts Windows Presentation Foundation eller Apache Flex ? Detta är en giltig fråga, men det verkar som om författarna till specifikationen ville behålla fullständigt plattformsoberoende och att anta vilken plattform som helst skulle riskera att skada detta förslag. Även om den saknar graden av sofistikering hos vissa av dessa plattformar, ger den nuvarande specifikationen en acceptabel grad av kontroll när det gäller användargränssnittets layout utan att vara onödigt restriktiv. Det återstår att se hur detta designval kommer att utvecklas, och det verkar troligt att ytterligare förfining av denna del av specifikationen kommer att behövas när antagandet växer.

Se även

externa länkar