Wymiana informacji finansowych

„NAPRAWIONY” przekierowuje tutaj. W przypadku firmy medialnej i wytwórni płytowej zobacz FiXT .

Protokół Financial Information eXchange ( FIX ) to elektroniczny protokół komunikacyjny zapoczątkowany w 1992 r. w celu międzynarodowej wymiany w czasie rzeczywistym informacji związanych z transakcjami i rynkami papierów wartościowych . Przy obrotach bilionami dolarów rocznie tylko na NASDAQ , podmioty świadczące usługi finansowe wykorzystują bezpośredni dostęp do rynku (DMA), aby przyspieszyć swoje działania na rynkach finansowych. Zarządzanie dostarczaniem aplikacji handlowych i utrzymywanie niskich opóźnień w coraz większym stopniu wymaga zrozumienia protokołu FIX.

Historia

Specyfikacja protokołu FIX została pierwotnie opracowana w 1992 r. przez Roberta „Boba” Lamoureux i Chrisa Morstatta w celu umożliwienia elektronicznej komunikacji danych dotyczących obrotu akcjami między Fidelity Investments i Salomon Brothers . FIX początkowo zajmował się informacjami między brokerami-dealerami a ich klientami instytucjonalnymi. W tym czasie informacje te były przekazywane ustnie przez telefon. Fidelity zdała sobie sprawę, że informacje od ich brokerów-dealerów mogą zostać przekierowane do niewłaściwego inwestora lub po prostu utracone, gdy strony odłożą słuchawkę. Chciała, aby taka komunikacja została zastąpiona danymi do odczytu maszynowego , które następnie można by udostępniać handlowcom, analizować, podejmować na ich podstawie działania i przechowywać. Na przykład maklerzy-dealerzy dzwonią ze wskazaniem zainteresowania ( IOI ), aby kupić lub sprzedać pakiet akcji. Inicjatywa FIX stworzyła nowe komunikaty, takie jak IOI .

Według FIX Trading Community, FIX stał się de facto standardem komunikacji przedtransakcyjnej i handlowej na światowych rynkach akcji i rozszerza się na przestrzeń posttransakcyjną, aby wspierać bezpośrednie przetwarzanie, a także nadal się rozwijać na rynki walutowe , instrumentów o stałym dochodzie i instrumentów pochodnych .

Społeczność handlowa FIX

FIX Trading Community jest organizacją non-profit działającą w branży, której misją jest zajmowanie się kwestiami biznesowymi i regulacyjnymi mającymi wpływ na obrót wieloma aktywami na globalnych rynkach finansowych poprzez zwiększone wykorzystanie standardów, w tym języka komunikatów FIX Protocol, dostarczanie efektywność operacyjną, większą przejrzystość oraz obniżone koszty i ryzyko dla wszystkich uczestników rynku.

Użytkownicy

FIX jest szeroko stosowany zarówno przez stronę kupującą (instytucje), jak i stronę sprzedającą (brokerzy/dealerzy) rynków finansowych . Wśród jego użytkowników są fundusze inwestycyjne , banki inwestycyjne , brokerzy, giełdy i ECN . Zobacz FIX Trading Community Organization , aby zapoznać się z obszerną listą głównych użytkowników FIX.

FIX stał się standardowym protokołem elektronicznym do komunikacji przedtransakcyjnej i realizacji transakcji. Chociaż jest używany głównie do transakcji kapitałowych w front office , możliwe są również instrumenty pochodne na obligacje i transakcje walutowe. Można powiedzieć, że podczas gdy SWIFT jest standardem przesyłania wiadomości na zapleczu , FIX jest standardem przesyłania wiadomości na froncie. Jednak obecnie członkostwo w FIX Protocol Ltd. rozszerza FIX na transakcji pakietowych i inne fazy procesu handlowego na każdym rynku, dla praktycznie każdej klasy aktywów.

Specyfikacja techniczna

Pierwotnie standard FIX był monolityczny i obejmował semantykę warstwy aplikacji, kodowanie komunikatów i warstwę sesji w jednej specyfikacji technicznej. Pozostał monolityczny do wersji FIX 4.2. Następnie kodowanie wiadomości i specyfikacje warstwy sesji zaczęto rozdzielać na osobne dokumenty, aż ostatecznie FIX przekształcił się w rodzinę powiązanych standardów technicznych.

Kodowanie wiadomości

Kodowanie komunikatów, zwane w modelu Open Systems Interconnection (model OSI) warstwą prezentacji , odpowiada za format przewodowy komunikatów.

Kodowanie tagvalue (klasyczny FIX)

Oryginalne kodowanie komunikatów FIX jest znane jako kodowanie tagvalue. Każde pole składa się z unikalnego znacznika numerycznego i wartości. Znacznik identyfikuje pole semantycznie. Dlatego wiadomości same się opisują. Kodowanie wartości znaczników jest oparte na znakach przy użyciu kodów ASCII .

FIX format komunikatu wartości znacznika

Pola wiadomości są oddzielone znakiem ASCII 01 <początek nagłówka>. Składają się z hedera, korpusu i przyczepy.

Do wersji FIX.4.4 nagłówek zawierał trzy pola: 8 ( BeginString ), 9 ( BodyLength ) i 35 ( MsgType ) znaczników.

Począwszy od FIXT.1.1 / FIX.5.0, nagłówek zawiera pięć pól obowiązkowych i jedno pole opcjonalne: 8 ( BeginString ), 9 ( BodyLength ), 35 ( MsgType ), 49 ( SenderCompID ), 56 ( TargetCompID ) i 1128 ( ApplVerID - jeśli obecny musi być na 6 miejscu).

Treść w treści wiadomości jest określona przez (tag 35, MsgType ) typ wiadomości zdefiniowany w nagłówku.

Ostatnim polem komunikatu jest tag 10, FIX Message Checksum. Zawsze jest wyrażona jako liczba trzycyfrowa (np. 10=002 ).

Header+Body+Trailer: FIX Content

Przykład komunikatu FIX: Raport wykonania (znak kreski jest używany do reprezentowania znaku SOH ) 

8=NAPRAWA.4.2 | 9=178 | 35=8 | 49=PLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=TESTOWANIE KAPITAŁOWE PHLX | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |

W powyższym FIXMessage długość treści 9 jest poprawna, a suma kontrolna 10 została sprawdzona przy użyciu źródła dostępnego w QuickFIX , implementacji FIX typu open source.

Ciało

Komunikaty FIX są tworzone z kilku pól; każde pole ma parowanie wartości znacznika, które jest oddzielone od następnego pola ogranicznikiem SOH (0x01). Znacznik jest liczbą całkowitą, która wskazuje znaczenie pola. Wartość jest tablicą bajtów, które mają określone znaczenie dla określonego znacznika (np. znacznik 48 to SecurityID, łańcuch znaków identyfikujący zabezpieczenie; znacznik 22 to IDSource, liczba całkowita wskazująca używaną klasę identyfikatora). Wartości mogą być w postaci zwykłego tekstu lub zakodowane jako czysto binarne (w takim przypadku wartość jest poprzedzona polem długości). Protokół FIX definiuje znaczenie większości tagów, ale pozostawia zakres tagów zarezerwowanych do użytku prywatnego między wyrażającymi zgodę stronami.

Protokół FIX definiuje również zestawy pól tworzących określoną wiadomość; w zestawie pól niektóre będą obowiązkowe, a inne opcjonalne. Kolejność pól w wiadomości generalnie nie ma znaczenia, jednak powtarzające się grupy są poprzedzone liczbą, a pola zaszyfrowane są poprzedzone ich długością. Wiadomość jest podzielona na trzy odrębne sekcje: głowa, tułów i ogon. Pola muszą pozostać w odpowiedniej sekcji, aw każdej sekcji pozycja może być ważna, ponieważ pola mogą działać jako ograniczniki, które uniemożliwiają przejście jednej wiadomości do następnej. Ostatnim polem w każdym komunikacie FIX jest tag 10 ( suma kontrolna ).

Istnieją dwie główne grupy wiadomości — admin i application. Komunikaty administratora obsługują podstawy sesji FIX. Pozwalają na rozpoczęcie i zakończenie sesji oraz odzyskanie utraconych wiadomości. Komunikaty aplikacji dotyczą wysyłania i odbierania informacji związanych z handlem, takich jak zapytanie o zlecenie lub informacje o aktualnym stanie i późniejszej realizacji tego zlecenia.

nagłówek
Wzrost


Długość ciała to liczba znaków, począwszy od znacznika 35 (włącznie) aż do znacznika 10 (wykluczone). Ograniczniki SOH liczą się do długości ciała. Na przykład: (SOH zostały zastąpione przez'|') 

8=FIX.4.2|9=65|35=A|49=SERWER|56=KLIENT|34=177|52=20090107-18:15:16|98=0|108=30|10=062| 0 + 0 + 5 + 10 + 10 + 7 + 21 + 5 + 7 + 0 = 65


Ma długość Body równą 65. Ogranicznik SOH na końcu Tag=Value należy do Tagu.

Zwiastun: Suma kontrolna

Suma kontrolna komunikatu FIX jest zawsze ostatnim polem w komunikacie. Składa się z trzech znaków i ma znacznik 10. Jest podawany przez zsumowanie ASCII wszystkich znaków w wiadomości, z wyjątkiem samego pola sumy kontrolnej, i wykonanie modulo 256 na wynikowym sumowaniu. Na przykład w powyższym komunikacie suma wszystkich wartości ASCII (w tym znaku SOH, który w tablicy ASCII ma wartość 1) daje wynik 4158. Wykonanie operacji modulo daje wartość 62. Ponieważ suma kontrolna składa się z trzy znaki, używane jest 062. QuickFixJ domyślnie używa CRC-8.

FIXML

FIXML to schemat XML dla komunikatów FIX. Jest semantycznie odpowiednikiem wiadomości zakodowanych w tagvalue, ale wykorzystuje technologię parsera XML. FIXML jest powszechnie używany w aplikacjach zaplecza i rozliczeniowych, a nie w handlu.

Proste kodowanie binarne (SBE)

Simple Binary Encoding definiuje format przewodowy przy użyciu prymitywnych typów danych, które są natywne dla systemów komputerowych. Kodowanie i dekodowanie wiadomości ma zatem znacznie mniejsze opóźnienia niż protokoły znakowe, ponieważ nie jest potrzebne żadne tłumaczenie, aby umieścić dane w formacie, z którego mogą korzystać komputery. Oprócz korzyści związanych z opóźnieniem, wydajność jest bardziej deterministyczna, ponieważ komunikaty SBE są ograniczone przez szablony i preferowane są elementy danych o stałej długości. Inną konsekwencją jest to, że pola są na ogół w stałej pozycji, dzięki czemu filtry wiadomości i routery nie muszą łamać całej wiadomości, aby uzyskać dostęp do kluczowych pól.

SBE został opracowany przez grupę roboczą FIX High Performance w celu wspierania handlu o wysokiej wydajności. Uznano, że kodowanie wartości tagów nie nadaje się już do celu, ponieważ jest oparte na znakach, a nie binarnych, a jego pola i komunikaty o zmiennej długości skutkują niedeterministyczną wydajnością.

W przeciwieństwie do tagvalue i FIXML komunikat SBE nie jest samoopisujący. W sieci przesyłane są tylko dane z minimalnym nagłówkiem, aby zidentyfikować szablon kontrolujący wiadomość. Metadane opisujące układ wiadomości są wymieniane poza pasmem między urządzeniami równorzędnymi.

FIX Trading Community publikuje schemat XML dla schematów komunikatów SBE. Schemat wiadomości może zawierać dowolną liczbę szablonów wiadomości. Szablon opisuje pola, które składają się na wiadomość. Dodatkowo schemat zawiera listę prostych i złożonych typów danych, które mogą być ponownie wykorzystane przez dowolną liczbę pól.

Z praktycznego punktu widzenia, zakładając implementację C/C++ i dostosowując się do endianizmu: większość typów niezłożonych w wiadomości jest bezpośrednio mapowana na ten sam typ w języku. Na przykład 32-bitowe mapy liczb całkowitych na uint32_t , stałe ciągi mapują const char * , mapy zmiennoprzecinkowe na float i tak dalej. Można wygenerować strukturę C/C++ z definicji schematu. Następnie, biorąc pod uwagę wskaźnik do bufora komunikatów, dostęp do pól niezłożonych komunikatu sprowadza się do rzutowania go na wskaźnik do struktury i bezpośredniego dostępu do elementów struktury. 


  
  
   
  
    
  


   
          
    
  
 /* Struktura wygenerowana ze schematu */  struct  Message  {  ...  uint32_t  qty  ;  ...  const  char  *  symbol  ;  ...  };  nieważna  wiadomość_konsumująca  (  nieważna  *  wiadomość_przychodząca  )  {  const  struct  Wiadomość  *  msg  =  (  const  struct  Wiadomość  *  )  wiadomość_ przychodząca  ;  printf  (  "Wymiana %u z %s  \n  "  ,  msg  ->  ilość  ,  msg  ->  symbol  );  ...  }

Inne kodowania FIX

FIX Trading Community opracowała również standardowe mapowania między FIX a innymi protokołami komunikatów, w tym:

Protokoły sesji

Warstwa sesyjna odpowiada za wymianę komunikatów, w tym mechanizmy odzyskiwania punktów kontrolnych.

Transport FIX (FIX)

Oryginalny protokół sesji FIX nie miał własnej nazwy, ponieważ był częścią monolitycznej specyfikacji obejmującej semantykę warstwy aplikacji i kodowanie komunikatów. Jednak począwszy od wersji FIX 5.0 warstwa sesyjna została wydzielona jako niezależna specyfikacja wraz z wprowadzeniem FIXT. FIXT był w dużej mierze taki sam, jak oryginalna nienazwana warstwa sesji w wersji 4.x, ale oferowała jedną istotną innowację — zapewniała mechanizm mieszania wersji warstwy aplikacji FIX ze wspólną wersją sesji. Obecna wersja FIXT to 1.1.

Teoretycznie FIXT jest niezależny od transportu. Jednak zwykle jest stosowany w protokole kontroli transmisji (TCP).

FIXT to protokół punkt-punkt. Gwarantuje dostarczenie wiadomości w obu kierunkach. Wiadomości wysyłane w każdym kierunku mają w nagłówku kolejny numer wiadomości. Jeśli wystąpi błąd komunikacji, peer może zażądać retransmisji nieodebranych wiadomości. Dostarczanie wiadomości jest obsługiwane nawet w przypadku rozłączenia i późniejszego ponownego nawiązania sesji.

Aby zaimplementować ustanowienie sesji i gwarantowane dostarczenie, FIXT i klasyczny FIX 4.x definiują następujące typy komunikatów sesji:

  • Bicie serca
  • Żądanie testu
  • Wyślij ponownie żądanie
  • Odrzucić
  • Resetowanie sekwencji
  • Wyloguj
  • Zalogować się
  • XMLnonFIX

Warstwa sesji wydajności FIX (FIXP)

FIXP został opracowany przez grupę roboczą FIX High Performance Working Group w celu zaspokojenia potrzeb handlu o wysokiej wydajności. Podstawową potrzebą jest kodowanie i dekodowanie wiadomości o niskim opóźnieniu oraz kontrola nad gwarancjami dostarczania wiadomości.

Aby zapewnić niskie opóźnienia, kodowanie komunikatów binarnych jest obsługiwane zarówno w przypadku warstwy sesji, jak i komunikatów aplikacji. Rzeczywisty format przewodu jest wyabstrahowany w specyfikacji FIXP, więc użytkownicy mogą wybrać kodowanie FIX według własnego wyboru, o ile partnerzy uzgodnią protokół, który ma być używany. Wczesny rozwój wykorzystywał proste kodowanie binarne.

FIXP obejmuje przypadki użycia zarówno typu punkt-punkt, jak i multiemisji ze wspólnymi prymitywami.

Po ustanowieniu sesji punkt-punkt uczestnicy negocjują gwarancje dostawy spośród następujących opcji:

  • Możliwość odzyskania: dostarczenie wiadomości dokładnie raz. Jeśli zostaną wykryte luki, pominięte wiadomości mogą zostać odzyskane przez retransmisję.
  • Idempotentne: dostawa co najwyżej jednorazowa. Jeśli zostaną wykryte luki, nadawca zostanie o tym powiadomiony, ale odzyskanie jest pod kontrolą aplikacji, jeśli w ogóle zostanie wykonane.
  • Niesekwencjonowane: nie gwarantuje dostawy. Ten wybór jest odpowiedni, jeśli gwarancje są niepotrzebne lub jeśli odzyskiwanie odbywa się w warstwie aplikacji lub za pośrednictwem innego kanału komunikacji.
  • Uwaga: Żadne komunikaty aplikacji nie powinny być wysyłane w jednym kierunku sesji.

Gwarancje dostawy mogą być asymetryczne. Na przykład inwestor może wprowadzać zlecenia w przepływie idempotentnym, podczas gdy egzekucje są zwracane w przepływie możliwym do odzyskania. Na szybko zmieniających się rynkach opóźnienie nieodłącznie związane z retransmisją jest często niepożądane, co skutkuje straconymi szansami lub złymi transakcjami.

Schematyczne przedstawienie systemu FIX

Poniżej znajduje się diagram, jak NAPRAWIĆ wygląd wiadomości między stroną kupującą/klientem a stroną sprzedającą/dostawcą.

Financial Information eXchange System Connectivity Diagram.svg

Najnowsze osiągnięcia w protokole FIX

Najnowsza wersja protokołu FIX implementuje „Transport Independence”, umożliwiając przenoszenie wielu wersji komunikatów aplikacji w ramach jednej wersji sesji FIX niezależnej od transportu (FIXT.1.1 i nowsze).

Niezależność od transportu toruje również drogę do wykorzystania protokołów transportowych, takich jak kolejki komunikatów i usługi sieciowe, zamiast tradycyjnego FIX przez TCP.

FIX obsługuje teraz handel algorytmiczny przy użyciu języka FIX Algorithmic Trading Definition Language FIXatdl .

W 2005 roku FIX Trading Community wydało protokół FAST , który oznacza FIX Adapted for Streaming. FAST jest protokołem binarnym i jest używany głównie do przesyłania danych rynkowych Multicast przez połączenia UDP.

Ponadto w 2020 r. FIX Trading Community wprowadzi nowe kodowanie binarne FIX, oparte na prostym kodowaniu binarnym (SBE), mające na celu uzupełnienie istniejącego kodowania FAST.

Zobacz też

Notatki

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Financial_Information_eXchange&oldid=1127201825 ”