Fix protocol - Implémenter un système de trading avec Java et Spring Boot [Partie 1]

Si vous avez déjà transmis des ordres sur des marchés comme le NASDAQ, le NYSE ou le CME, il y a de fortes chances que vos transactions aient transité via le protocole FIX.

Le protocole Financial Information eXchange (FIX) est une norme conçu pour faciliter la communication électronique des transactions de titres.
Il sert de framework de messagerie, permettant aux courtiers, investisseurs institutionnels et même, indirectement, aux clients particuliers via des courtiers en ligne d’effectuer des tâches cruciales telles que la récupération d’informations sur les instruments financiers, la gestion des ordres, ainsi que la réception des mises à jour en temps réel des transactions.

Dans cette série en trois parties, nous allons développer un système de trading simple qui génère et traite des ordres en utilisant le protocole FIX (version 4.2).

Nous commencerons par explorer ses concepts fondamentaux, puis nous procéderons à l’implémentation d’un Initiator et d’un Acceptor avec Java, Spring Boot et QuickFIX/J.

Les fondamentaux du protocole FIX

Dans le protocole FIX, il y a trois entités clés : l’Initiator, l’Acceptor et la Session.

🔵 L’Initiator est la partie qui initie la connexion et envoie les ordres. Il s’agit généralement du client ou d’une entreprise buy-side, comme un hedge fund ou une société de gestion.

🔵 L’Acceptor est la contrepartie qui reçoit et exécute ces ordres. Typiquement, il s’agit d’une plateforme d’exécution, un market maker ou une bourse.

🔵 La Session agit comme le canal de communication, permettant à l’Initiator et à l’Acceptor d’échanger des messages FIX de manière fluide et sécurisée.

Flux de communication du protocole FIX

Voici un flux de communication typique du protocole FIX :

Initiator (Client)                  Acceptor (Server)
       |                                   |
       |------- Logon (A) ---------------->|
       |<------ Logon (A) -----------------|
       |                                   |
       |------- New Order Single (D) ----->|
       |<------ Execution Report (8) ------|
       |                                   |
       |<------ Execution Report (8) ------|
       |                                   |
       |------- Logout (5) --------------->|
       |<------ Logout (5) ----------------|

1. L’Initiator s’authentifie auprès de l’Acceptor en envoyant un message de Logon. Une fois la connexion établie, les parties peuvent échanger des messages.

2. Dans cet exemple, l’Initiator envoie un message New Order Single pour soumettre un ordre.

3. L’Acceptor répond avec un message Execution Report pour confirmer la réception de l’ordre.

4. Après l’exécution, l’Acceptor envoie un autre message Execution Report pour transmettre les informations d’exécution (partielle ou totale). Ce message peut aussi notifier des événements autres que l’exécution (ex : rejet, confirmation, etc.).

5. Enfin, l’Initiator envoie un message Logout pour terminer la session.

Pour une liste complète de tous les messages FIX et leurs détails, consultez le dictionnaire FIX.

Format des messages FIX

Un message FIX est composé de trois parties :

1. Header (Obligatoire): Contient des métadonnées telles que le type de message, l’expéditeur et la cible. Cela permet d’identifier le message et les parties impliquées dans la communication.

2. Body (dépend du type de message): Contient les données du message, telles que les détails de l’ordre ou les rapports d’exécution.

3. Trailer (Obligatoire): Inclut un checksum pour garantir l’intégrité du message.

Les messages FIX utilisent un format de paire tag-valeur, où chaque champ est représenté sous la forme : Tag=Value.

Chaque tag est un identifiant numérique correspondant à un champ spécifique, suivi d’un signe égal (=) et de sa valeur associée. Les champs sont séparés par le caractère SOH (Start of Heading), représenté par \x01 en ASCII ou 0x01 en hexadécimal.

Voici un exemple de message FIX :

8=FIX.4.4|9=122|35=D|49=Client|56=Server|34=1|52=20231010-10:30:00|11=12345|21=1|55=AAPL|54=1|60=20231010-10:30:00|38=100|40=2|44=150.25|10=123|

🔵Header: 8=FIX.4.4|9=122|35=D|49=Client|56=Server|...
🔵Body: 11=12345|21=1|55=AAPL|54=1|60=2023101010:30:00|38=100|40=2|...
🔵Trailer: 10=123|

Numéros de séquence, écarts, Et Resend Requests dans FIX

Dans le protocole FIX, les numéros de séquence jouent un rôle essentiel pour garantir une livraison fiable et ordonnée des messages entre l’Initiator et l’Acceptor.

Chaque message FIX se voit attribuer un numéro de séquence unique, qui s’incrémente à chaque message envoyé. Les numéros de séquence aident les deux parties à suivre l’ordre des messages et à détecter tout message manquant ou hors séquence.

1. Numéros de séquence

1. Chaque session FIX maintient deux numéros de séquence : un pour les messages sortants et un pour les messages entrants.
2. Les numéros de séquence commencent à 1 lorsqu’une session est établie et s’incrémentent de 1 pour chaque message suivant.
3. Exemple: Si l’Initiator envoie trois messages, leurs numéros de séquence seraient 1, 2 et 3.

2. Detection des écarts

1. Un écart se produit lorsqu’un message est perdu ou arrive hors de séquence, provoquant une incohérence dans les numéros de séquence.
2. Exemple: Si l’Acceptor reçoit les messages avec les numéros de séquence 1, 2 et 4, il détecte un écart au numéro de séquence 3.

3. Resend Requests (ResendRequest)

1. Lorsqu’un écart est détecté, la partie réceptrice envoie un message ResendRequest pour demander les messages manquants.
2. Le ResendRequest spécifie la plage des numéros de séquence manquants.
3. Exemple: BeginSeqNo=3|EndSeqNo=3 demande le message avec le numéro de séquence 3.
4. L’expéditeur doit renvoyer soit les messages manquants spécifiques, soit un Gap Fill si les messages ne sont plus pertinents.

Dans certains cas, l’expéditeur peut réinitialiser les numéros de séquence en utilisant un message SequenceReset. Cela se fait généralement lors de la récupération de la session ou lorsque la session est redémarrée.

Exemple: Un message SequenceReset avec NewSeqNo=1 réinitialise le numéro de séquence à 1.

Implémentation FIX

Une implémentation du protocole FIX est généralement appelée un moteur FIX (FIX engine).

L’une des implémentations de moteur FIX les plus largement utilisées est la famille QuickFIX.

Le moteur QuickFIX est disponible dans une variété de langages de programmation, y compris C++, Python, Ruby, .NET et Go.

QuickFIX/J est un moteur de messagerie complet pour le protocole FIX.

Il s’agit d’une implémentation 100 % Java et open-source du moteur QuickFIX, offrant un support robuste pour la création d’applications basées sur FIX en Java.

Bien que d’autres alternatives existent, nous utiliserons QuickFIX/J dans les sections suivantes pour implémenter à la fois l’Initiator et l’Acceptor.

Conclusion

Dans cette première partie Implémenter un système de trading avec Java et Spring Boot, nous avons exploré les éléments essentiels du protocole FIX, y compris :

1. Un aperçu du protocole FIX et des entités clés impliquées (Initiator et Acceptor).
2. Un exemple de flux de messages entre ces entités.
3. La structure et le format des messages FIX.
4. L’importance du numéro de séquence pour garantir la fiabilité.
5. Une introduction au moteur QuickFIX/J.

Dans la prochaine section (Partie 2), nous adopterons une approche pratique en implémentant un Initiator à l’aide de QuickFIX/J.