Échange d'informations financières - Financial Information eXchange

« FIXT » redirige ici. Pour la société de médias et la maison de disques, voir FiXT .

Le protocole Financial Information eXchange ( FIX ) est un protocole de communication électronique lancé en 1992 pour l'échange international en temps réel d'informations relatives aux transactions et aux marchés de valeurs mobilières . Avec des milliards de dollars négociés chaque année sur le seul NASDAQ , les entités de services financiers utilisent l'accès direct au marché (DMA) pour augmenter leur vitesse d'accès aux marchés financiers. Gérer la livraison des applications de trading et maintenir une latence faible nécessite de plus en plus une compréhension du protocole FIX.

Histoire

La spécification du protocole FIX a été initialement rédigée en 1992 par Robert "Bob" Lamoureux et Chris Morstatt pour permettre la communication électronique des données de négociation d' actions entre Fidelity Investments et Salomon Brothers . FIX s'occupait initialement des informations entre les courtiers et leurs clients institutionnels. À l'époque, cette information était communiquée verbalement par téléphone. Fidelity s'est rendu compte que les informations de ses courtiers pouvaient être acheminées vers le mauvais commerçant ou simplement perdues lorsque les parties raccrochaient leur téléphone. Il souhaitait que ces communications soient remplacées par des données lisibles par machine qui pourraient ensuite être partagées entre les commerçants, analysées, exploitées et stockées. Par exemple, les courtiers appellent avec une indication d'intérêt ( IOI ) pour acheter ou vendre un bloc d'actions. L'initiative FIX a créé de nouveaux messages tels que l' IOI .

Selon la communauté de négociation FIX, FIX est devenu la norme de messagerie de facto pour la communication pré-négociation et commerciale sur les marchés boursiers mondiaux, et se développe dans l'espace post-négociation pour prendre en charge le traitement direct , tout en continuant à se développer. sur les marchés des changes , des titres à revenu fixe et des produits dérivés .

Communauté de trading FIX

La communauté de négociation FIX est un organisme de normalisation à but non lucratif, axé sur l'industrie, dont la mission est de résoudre les problèmes commerciaux et réglementaires ayant une incidence sur le commerce de plusieurs actifs sur les marchés financiers mondiaux grâce à l'utilisation accrue de normes, y compris le langage de messagerie du protocole FIX, offrant l'efficacité opérationnelle, une transparence accrue et une réduction des coûts et des risques pour tous les acteurs du marché.

Utilisateurs

FIX est largement utilisé par le côté achat (institutions) ainsi que le côté vente (courtiers / négociants) des marchés financiers . Parmi ses utilisateurs figurent des fonds communs de placement , des banques d'investissement , des courtiers, des bourses et des ECN . Voir FIX Trading Community Organization pour une liste complète des principaux utilisateurs de FIX.

FIX est devenu le protocole électronique standard pour les communications pré-négociation et l'exécution des transactions. Bien qu'il soit principalement utilisé pour les transactions sur actions dans le domaine du front office , les transactions sur obligations, dérivés et devises sont également possibles. On pourrait dire que si SWIFT est la norme pour la messagerie back-office , FIX est la norme pour la messagerie front-office. Cependant, aujourd'hui, l'adhésion à FIX Protocol Ltd. étend FIX à l' allocation de blocs et à d'autres phases du processus de négociation, sur chaque marché, pour pratiquement toutes les classes d'actifs.

Spécifications techniques

À l'origine, la norme FIX était monolithique, comprenant la sémantique de la couche application, l'encodage des messages et la couche session dans une seule spécification technique. Il est resté monolithique jusqu'à la version 4.2 de FIX. Par la suite, les codages des messages et les spécifications de la couche session ont commencé à être divisés en documents distincts et, finalement, FIX a évolué en une famille de normes techniques connexes.

Encodages de messages

Le codage des messages, appelé couche de présentation dans le modèle d'interconnexion des systèmes ouverts (modèle OSI), est responsable du format filaire des messages.

Codage de valeur de balise (FIX classique)

L'encodage du message FIX d'origine est connu sous le nom d'encodage tagvalue. Chaque champ se compose d'une balise numérique unique et d'une valeur. La balise identifie le champ sémantiquement. Par conséquent, les messages sont auto-descriptifs. L'encodage Tagvalue est basé sur des caractères et utilise des codes ASCII .

Format de message de valeur de balise FIX

Les champs du message sont délimités à l'aide du caractère ASCII 01 <début de l'en-tête>. Ils sont composés d'une tête, d'un corps et d'une remorque.

Jusqu'à FIX.4.4, l'en-tête contenait trois champs : 8 ( BeginString), 9 ( BodyLength) et 35 ( MsgType).

A partir de FIXT.1.1 / FIX.5.0, l'en-tête contient cinq champs obligatoires et un champ facultatif : 8 ( BeginString), 9 ( BodyLength), 35 ( MsgType), 49 ( SenderCompID), 56 ( TargetCompID) et 1128 ( ApplVerID- s'il est présent doit être en 6ème position ).

Le contenu du corps du message est spécifié par (balise 35, MsgType) le type de message défini dans l'en-tête .

Le dernier champ du message est la balise 10, FIX Message Checksum. Il est toujours exprimé sous la forme d'un nombre à trois chiffres (par exemple 10=002).

En-tête+Corps+Trailer : Contenu FIX

Exemple de message FIX : Execution Report (Le caractère Pipe est utilisé pour représenter le caractère SOH ) 

8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 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=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |

Dans le FIXMessage ci-dessus, la longueur du corps 9 est correcte et la somme de contrôle 10 a été extraite en utilisant la source disponible à partir de QuickFIX , une implémentation FIX open source.

Corps

Les messages FIX sont formés à partir d'un certain nombre de champs ; chaque champ est une paire de valeurs de balise qui est séparée du champ suivant par un délimiteur SOH (0x01). La balise est un entier qui indique la signification du champ. La valeur est un tableau d'octets qui ont une signification spécifique pour la balise particulière (par exemple, la balise 48 est SecurityID, une chaîne qui identifie la sécurité ; la balise 22 est IDSource, un entier qui indique la classe d'identifiant utilisée). Les valeurs peuvent être en texte brut ou codées en binaire pur (auquel cas la valeur est précédée d'un champ de longueur). Le protocole FIX définit la signification de la plupart des balises, mais laisse une gamme de balises réservées à un usage privé entre les parties consentantes.

Le protocole FIX définit également des ensembles de champs qui font un message particulier ; dans l'ensemble des champs, certains seront obligatoires et d'autres facultatifs. L'ordre des champs dans le message est généralement sans importance, cependant les groupes répétés sont précédés d'un nombre et les champs cryptés sont précédés de leur longueur. Le message est divisé en trois sections distinctes : la tête, le corps et la queue. Les champs doivent rester dans la section correcte et dans chaque section, la position peut être importante car les champs peuvent agir comme des délimiteurs qui empêchent un message de s'exécuter dans le suivant. Le dernier champ de tout message FIX est la balise 10 ( somme de contrôle ).

Il existe deux groupes principaux de messages : admin et application. Les messages d'administration gèrent les bases d'une session FIX. Ils permettent de démarrer et de terminer une session et de récupérer les messages manqués. Les messages d'application traitent de l'envoi et de la réception d'informations liées au commerce telles qu'une demande d'ordre ou des informations sur l'état actuel et l'exécution ultérieure de cet ordre.

Entête
La longueur du corps

La longueur du corps est le nombre de caractères commençant à la balise 35 (inclus) jusqu'à la balise 10 (exclu). Les délimiteurs SOH comptent dans la longueur du corps.
Par exemple : (SOH ont été remplacés par '|')

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

A une longueur de corps de 65.
Le délimiteur SOH à la fin d'un Tag=Value appartient au Tag.

Bande-annonce : Somme de contrôle

La somme de contrôle d'un message FIX est toujours le dernier champ du message. Il est composé de trois caractères et a la balise 10. Il est donné en additionnant la valeur ASCII de tous les caractères du message, à l'exception de ceux du champ de somme de contrôle lui-même, et en effectuant modulo 256 sur la somme résultante. Par exemple, dans le message ci-dessus, la somme de toutes les valeurs ASCII (y compris le caractère SOH, qui a une valeur de 1 dans la table ASCII) donne 4158. L'exécution de l'opération modulo donne la valeur 62. Étant donné que la somme de contrôle est composée de trois caractères, 062 est utilisé.

FIXML

FIXML est un schéma XML pour les messages FIX. Il est sémantiquement équivalent aux messages codés tagvalue mais tire parti de la technologie d'analyseur XML. FIXML est couramment utilisé pour les applications de back-office et de compensation plutôt que pour le trading.

Encodage binaire simple (SBE)

Le codage binaire simple définit un format de fil à l'aide de types de données primitifs natifs des systèmes informatiques. L'encodage et le décodage des messages ont donc une latence bien inférieure à celle des protocoles basés sur des caractères, car aucune traduction n'est nécessaire pour mettre les données dans un format utilisable par les ordinateurs. Outre les avantages de latence, les performances sont plus déterministes car les messages SBE sont limités par des modèles et les éléments de données de longueur fixe sont préférés. Une autre conséquence est que les champs sont généralement à une position fixe, de sorte que les filtres de messages et les routeurs n'ont pas besoin de déchiffrer un message entier pour accéder aux champs clés.

SBE a été développé par le groupe de travail FIX High Performance pour prendre en charge le trading haute performance. Le codage Tagvalue n'a plus été jugé adapté à l'usage car il est basé sur des caractères plutôt que binaire et ses champs et messages de longueur variable entraînent des performances non déterministes.

Contrairement à tagvalue et FIXML, un message SBE n'est pas autodescriptif. Seules les données sont envoyées sur le fil avec un en-tête minimal pour identifier le modèle qui contrôle un message. Les métadonnées qui décrivent une présentation de message sont échangées hors bande entre pairs.

FIX Trading Community publie un schéma XML pour les schémas de messages SBE. Un schéma de message peut contenir un nombre quelconque de modèles de message. Un modèle décrit les champs qui constituent un message. De plus, un schéma fournit une liste de types de données simples et composites qui peuvent être réutilisés par un nombre quelconque de champs.

D'un point de vue pratique, en supposant une implémentation C/C++ et en ajustant l'endianité : la plupart des types non composites du message correspondent directement au même type dans le langage. Par exemple, les entiers 32 bits sont mappés sur uint32_t, les chaînes de caractères fixes sont mappées const char *, les virgules flottantes sont mappées sur floatet ainsi de suite. On peut générer un C/C++ à structpartir de la définition du schéma. Ensuite, étant donné un pointeur vers un tampon de message, accéder aux champs non composites du message revient à le transtyper en un pointeur vers la structure et à accéder directement aux membres de la structure. 

/* Generated struct from schema */
struct Message {
  ...
  uint32_t qty;
  ...
  const char *symbol;
  ...
};

void consume_message(void *incoming_message) {
  const struct Message *msg = (const struct Message*) incoming_message;
  printf("Traded %u of %s\n", msg->qty, msg->symbol);
  ...
}

Autres encodages FIX

FIX Trading Community a également développé des mappages standard entre FIX et d'autres protocoles de messagerie, notamment :

Protocoles de session

La couche session est responsable de l'échange de messages, y compris les mécanismes de récupération des points de contrôle.

Transport FIX (FIXT)

Le protocole de session FIX d'origine n'avait pas son propre nom car il faisait partie d'une spécification monolithique couvrant également la sémantique de la couche application et le codage des messages. Cependant, à partir de la version 5.0 de FIX, la couche session a été séparée en tant que spécification indépendante avec l'introduction de FIXT. FIXT était en grande partie le même que la couche de session sans nom d'origine dans la version 4.x, mais il offrait une innovation importante - il a fourni un mécanisme pour mélanger les versions de la couche d'application FIX sur une version de session commune. La version actuelle de FIXT est 1.1.

Théoriquement, FIXT est indépendant du transport. Cependant, il est généralement utilisé sur le protocole TCP ( Transmission Control Protocol ).

FIXT est un protocole point à point. Il garantit la livraison des messages dans les deux sens. Les messages envoyés dans chaque direction portent un numéro de séquence de message dans l'en-tête du message. S'il y a un défaut de communication, un pair peut demander la retransmission des messages manqués. La livraison des messages est prise en charge même en cas de déconnexion et de rétablissement ultérieur d'une session.

Pour mettre en œuvre l'établissement de session et la livraison garantie, FIXT et FIX 4.x classique définissent ces types de messages de session :

  • Battement de coeur
  • Demande de test
  • RenvoyerDemande
  • Rejeter
  • SequenceReset
  • Se déconnecter
  • Se connecter
  • XMLnonFIX

Couche de session de performances FIX (FIXP)

FIXP a été développé par le FIX High Performance Working Group pour répondre aux besoins du trading haute performance. Le besoin principal est le codage et le décodage des messages à faible latence et le contrôle des garanties de livraison des messages.

Pour fournir une faible latence, les codages de messages binaires sont pris en charge à la fois pour la couche session et les messages d'application. Le format de fil réel est résumé dans la spécification FIXP, de sorte que les utilisateurs peuvent sélectionner un codage FIX de leur choix, tant que les pairs se mettent d'accord sur un protocole à utiliser. Les premiers développements ont utilisé le codage binaire simple.

FIXP couvre à la fois les cas d'utilisation point à point et multicast avec des primitives communes.

Lorsqu'une session point à point est établie, les pairs négocient des garanties de livraison parmi les choix suivants :

  • Récupérable : livraison du message en une seule fois. Si des lacunes sont détectées, les messages manqués peuvent être récupérés par retransmission.
  • Idempotent : accouchement au plus une fois. Si des lacunes sont détectées, l'expéditeur est averti, mais la récupération est sous le contrôle de l'application, si elle est effectuée.
  • Non séquencé : ne donne aucune garantie de livraison. Ce choix est approprié si les garanties sont inutiles ou si la récupération est fournie au niveau de la couche application ou via un autre canal de communication.
  • Aucun : aucun message d'application ne doit être envoyé dans une seule direction d'une session.

Les garanties de livraison peuvent être asymétriques. Par exemple, un trader peut saisir des ordres sur un flux idempotent tandis que les exécutions sont renvoyées sur un flux récupérable. Sur les marchés en évolution rapide, le retard inhérent à la retransmission est souvent indésirable, entraînant des opportunités manquées ou de mauvaises transactions.

Représentation schématique du système FIX

Vous trouverez ci-dessous un schéma de l'apparence de la messagerie FIX entre le côté acheteur/client et le côté vendeur/fournisseur.

Diagramme de connectivité du système d'échange d'informations financières.svg

Derniers développements du protocole FIX

La dernière version du protocole FIX met en œuvre « l'indépendance du transport » en permettant à plusieurs versions de messages d'application d'être transportées sur une seule version de la session FIX indépendante du transport (FIXT.1.1 et versions ultérieures).

L'indépendance du transport ouvre également la voie à l'utilisation de protocoles de transport tels que les files d'attente de messages et les services Web à la place du FIX traditionnel sur TCP.

FIX prend désormais en charge le trading algorithmique en utilisant le langage de définition de trading algorithmique FIX FIXatdl .

FIX Protocol Limited a publié le protocole FAST qui signifie FIX Adapted for Streaming. FAST est un protocole binaire utilisé principalement pour envoyer des données de marché multicast via des connexions UDP.

Outils de test

De nombreuses entreprises proposent des produits et services de test FIX :

  • PhiFIX sensible
  • Lefinsys Testamatiq
  • FAITS B2Bits
  • CameronTec VeriFIX
  • Esprow ETP Studio pour FIX
  • Outils de test Exactpro
  • FIX Flyer Allumage
  • GDS Fizzer - FIX Fuzzing Framework
  • Examen Wipro FIX
  • FixSpec Central

Voir également

Remarques

Liens externes