Archives pour la catégorie Protocoles

Les protocoles utilisés dans le secteur de la finance (FIX, SWIFT, FPML…)

Tutorial QuickFixJ (client et serveur)

Le protocole FIX, l’un des standards de communications utilisés dans la finance, est facile à comprendre et largement employé. Il existe donc plusieurs moteurs FIX payants sur le marchés  tels que Cameron FIX ou encore OnixS FIX Engine. On trouve aussi des moteurs gratuits tels que fix8 ou QuickFix. Nous allons ici nous intéresser à la façon d’implémenter simplement un serveur et un client FIX en utilisant la version version Java du framework QuickFix : QuickFixJ.
(Pour plus d’informations sur le protocole, vous pouvez jeter un oeil à notre introduction au protocole FIX).

 Installer QuickFIXJ

En premier lieu il faut télécharger les jars qui vont biens à partir de la section téléchargement du site de quickfixj

Vous devriez avoir un répertoire similaire à celui ci-dessous :

repertoire de jar quickfixj
jar utilisés par quickfixj

Vous pouvez maintenant utiliser vote IDE Java favori pour créer un projet et rajoutez les jar de QuickFixJ ainsi que ceux se trouvant dans le repertoire « lib » (sl4j-api et mina qui sont requis pour faire tourner QuickFixJ)

Ceci étant fait, le reste devrait être d’une simplicité déconcertante. Quickfix possède 2 composants de base: l’interface « Application » et le fichier de configuration.

L’interface Application

QuickFixj est construit autour d’une interface de base que tout client/serveur doit implémenter: l’interface Application.
Cette interface définie les méthodes qui seront appelées lors des différents évènement de la communication FIX (création de session, login, réception de messages…).
Il suffit donc de rajouter votre code dans la classe qui implémente Application et le tour est joué!

Les méthodes définies par Applications sont les suivantes:

onCreate: méthode appelée lors de la création de la session

onLogon: méthode appelée lors de la connexion (utile pour rajouter des informations de login telles qu’un mot de passe)

onLogout: méthode appelée lors de la déconnexion

toAdmin: méthodes appelées lorsque l’on envoie un message d’administration (heartbeat, rejection…)

toApp : méthode appelée lorsque l’on envoie un message applicatif  (nouvel ordres, demande de données marché…)

fromAdmin: méthode appelée lorsque l’on reçoit un message d’administration

fromApp: méthode appelée lorsque l’on reçoit un message applicatif

et… c’est tout, pas grand-chose de compliqué au final.

 

Le fichier de configuration

L’autre element important de QuickFixJ est le fichier de configuration, il permet de définir le type de programme que l’on développe: Les termes utilisés par quickfixj sont « Acceptor » pour un serveur FIX et « Initiator » pour le client FIX.

Le fichier de configuration contient donc cette information en plus d’autre paramètres de base (répertoire pour les logs, identifiant de connexion,version de FIX utilisée…)

Code & conf pour serveur

Le code java (implémentation de l’interface est une méthodes main qui loade la conf et crée l’Acceptor):

public class FIXServer extends MessageCracker implements Application {
    @Override
     public void fromAdmin(Message arg0, SessionID arg1) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue,
             RejectLogon {
     }
    @Override
     public void fromApp(Message arg0, SessionID arg1) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue,
             UnsupportedMessageType {
     }
    @Override
     public void onCreate(SessionID arg0) {
     }
    @Override
     public void onLogon(SessionID arg0) {
     }
    @Override
     public void onLogout(SessionID arg0) {
     }
    @Override
     public void toAdmin(Message arg0, SessionID arg1) {
     }
    @Override
     public void toApp(Message arg0, SessionID arg1) throws DoNotSend {
     }
    public static void main(String[] args) throws ConfigError {
         SessionSettings settings = new SessionSettings("./files/acceptor.cfg");        FIXServer acceptor = new FIXServer();
         ScreenLogFactory screenLogFactory = new ScreenLogFactory(settings);
         DefaultMessageFactory messageFactory = new DefaultMessageFactory();
         FileStoreFactory fileStoreFactory = new FileStoreFactory(settings);
         SocketAcceptor socketAcceptor = new SocketAcceptor(acceptor, fileStoreFactory, settings, screenLogFactory, messageFactory);
         socketAcceptor.start();
     }
 }

 

Et le fichier de configuration (avec les commentaires)

 [DEFAULT]
# indique un serveur FIX
ConnectionType=acceptor
# stockage des infos de connexion (séquence...)
FileStorePath=./files/  
# stockage des logs
FileLogPath=./files/
[SESSION] #exemple de session

# version de FIX
BeginString=FIX.4.2
# identifiant du client
SenderCompID=clientID
# identifiant du serveur
TargetCompID=serverID
# heure de début de session
StartTime=00:00:00
# heure de fin de session
EndTime=00:00:00
# port
SocketAcceptPort=4242           
# IP
SocketAcceptAddress=127.0.0.1   

Code & conf pour client

Le code pour le client est très similaire à celui du serveur, on va simplement déclarer un objet Initiator au lieu d’un Acceptor

public class FIXClient implements Application {
    @Override
    public void fromAdmin(Message arg0, SessionID arg1) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue,
            RejectLogon {
    }
@Override

    public void fromApp(Message arg0, SessionID arg1) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue,
            UnsupportedMessageType {
    }

    @Override
    public void onCreate(SessionID arg0) {
    }

   @Override
    public void onLogon(SessionID arg0) {
    }

    @Override
    public void onLogout(SessionID arg0) {
    }

    @Override
    public void toAdmin(Message arg0, SessionID arg1) {
    }

    @Override
    public void toApp(Message arg0, SessionID arg1) throws DoNotSend {
    }

    public static void main(String[] args) throws ConfigError {
        Application application = new FIXClient();
        SessionSettings settings = new SessionSettings("./files/initiator.cfg");
        MessageStoreFactory storeFactory = new FileStoreFactory(settings);
        LogFactory logFactory = new FileLogFactory(settings);
        MessageFactory messageFactory = new DefaultMessageFactory();
        Initiator initiator = new SocketInitiator(application, storeFactory, settings, logFactory, messageFactory);
        initiator.start();
        while (1 == 1) {
            ;
        }
        // acceptor.stop();

    }
}

 

Le fichier de conf et lui aussi très similaire a celui de l’acceptor, si ce n’est que les SenderCompID & TargetCompID sont maintenant inversés:

[DEFAULT]
# indique un client FIX
ConnectionType=initiator
FileStorePath=./files/  
FileLogPath=./files/
[SESSION]
BeginString=FIX.4.2

#attention c'est l'inverse du cote serveur!
TargetCompID=clientID
SenderCompID=serverID
StartTime=00:00:00
EndTime=00:00:00
SocketConnectPort=4242
SocketConnectHost=127.0.0.1
#intervalle en seconde entre 2 messages de heartbeat
HeartBtInt=20

et après?

Et voila vous devriez être capable d’avoir un serveur et un client FIX, il suffit maintenant d’appeler la méthode « sendToTarget(Message message) » de l’objet « Session » (dispo dans les objets Initiator & Acceptor) et le message sera envoyé!

A partir de la vous avez la base pour créer un algo de matching, et développer votre marché :-)

Protocole FIX: introduction & utilisation

Un des protocoles de communication les plus utilisé en finance est le protocole FIX (Financial Information eXchange). Il permet d’envoyer toutes sorte d’informations financières allant de la market data aux instructions de settlement.

Histoire du protocole FIX

Le protocole FIX a été crée en 1992 par Robert Lamoureux (qui travaillait chez Fidelity Investment, une multinationale spécialisée dans la gestion d’actifs) et Christopher Morstatt (lorsqu’il était employé chez Salomon Brothers, une banque d’investissement de Wall Street) pour le trading d’equity.
Le Financial Information Exchange protocol a ensuite évolué pour permettre de gerer les activites de post-trades ainsi que les autres classes d’actifs.

Voila un court historique des versions

4.1: Ajout de message pour le middle office et back office (settlement Instruction)
4.2: Nouveaux instruments et ajout de messages (Market Data, Security And Trading Session Definition Or Status)
4.3: Ajout de messages (Registration Instruction, Cross Orders, Multileg Orders, Trade Capture)
4.4: Ajout de messages (Multileg Orders, Trade Capture, Confirmation, Position Maintenance, Collateral Management)
5.0: ?
5.0sp1: Ajout de messages (Reference Data, Market Structure, Order Mass Handling)
5.0sp2: Ajout de messages (Securities ReferenceData, Market Structure Reference Data)

Fonctionnement du protocole FIX:

FIX est un protocole permettant d’échanger des données au niveau session (création/conclusion d’une connexion, authentification, heart-beat pour confirmer que la connexion est toujours valide…) ainsi qu’au niveau application (envoie d’ordre au marche, récupération de la définition des instruments financiers, confirmation d’exécution d’ordre…).

Un message FIX est une chaine de caractères constituée de plusieurs couples clé/valeur séparés par le caractère <SOH> (« Start of Header« , la valeur 1 en ASCII).

La clé  est un nombre (appelé « tag »), la valeur est une chaine de caractères pouvant représenter toute sorte de types (entier,  float, char, string,  timestamp… Même du XML ou encore des données binaires).

Exemple de message FIX(le caractère SOH est remplacé par ‘|’):

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 |

Chaque message contient 3 différents composants: Le Header, le Body et le Trailer.

Le Header contient les informations de base du message: Version de FIX, taille du message,  envoyeur, destinataire, numéro de séquence et surtout, le tag 35: Message Type.
Les tags attendus dans le Body changent en fonction du message type , par exemple:

35=D –> défini un message de type « NewOrderSingle » (nouvel ordre) et contiendra des informations liées au passage d’un ordre (prix, instrument, marché, date…)

35=d –> défini un message de type « SecurityDefinition » (définition d’instrument financier) et contiendra les informations liées a un instrument (symbole, date d’expiration, strike, cap price…)

Le Body contient l’ensemble des tags utiles, c’est la partie la plus intéressante du message. C’est la que se trouvent toute l’information sur les transactions, les instruments, les instructions de règlement…)

Le Trailer est un simple checksum pour vérifier la validité du message.

Format de message FIX
Format d’un message FIX

On retrouve ces 3 éléments dans le message FIX d’exemple (un TradeCaptureReport 35=8):

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 |

 

Utiliser le protocole FIX

Il existe différents moteurs FIX propriétaires qui peuvent être utilisés pour se connecter en FIX, on trouve par exemple APPIA développé par NYSE technology qui a été mis sur le marché en 1994 et offre de bonnes performance et de faibles latences. On trouve encore d’autre outils tels que Cameron FIX  engine, Fidessa FIX portal, ou le moteur de FIX de UL Link. Une recherche google devrait permettre de trouver les différents vendeurs qui proposent de telles solutions.

Il existe une très bonne alternative a ces solution: quickfix

Quickfix offre une implémentation gratuite de FIX pour différents langages de programmation (C/C++, Java, Python, .net et ruby). La version Java est basée sur Apache MINA et permet d’implémenter un serveur FIX ou un client FIX en quelques heures. C’est l’outil parfait pour commencer a programmer avec FIX (probablement le sujet d’un futur article).

Liens utiles

Fiximate (version 3.0):
Fiximate est l’outil de référence lorsque l’on travaille avec FIX, très bien organisé et d’utilisation intuitive, il permet de trouver le contenu de chaque message, mais aussi de savoir dans quel messages se trouve un tag précis. Un outil incontournable.

Trés bon outil pour le protocole FIX: fiximate version 3.0
Exemple d’utilisation de fiximate

 

FIX Protocol Message Parser/Analyzer:
Un autre outil particulièrement pratique, est cet analyseur/parseur de message FIX. Il suffit de copier le message ou d’uploader un fichier de logs pour obtenir pour chaque tag son numéro, sa signification et la valeur associée. En cliquant sur le nom du champ on obtient sa description.

Analyse de message qu protocole FIX en ligne
Analyseur de messages au format FIX en ligne

Wireshark:
Pas un site internet, mais un analyseur de paquet libre (le plus connu sans doute). Wireshark permet de visualiser très facilement ce qui transite sur un réseau et contient des filtres pour FIX. Il est extrêmement pratique lors du développement d’application qui utilisent FIX (ou pour tout autre développement lie au réseau d’ailleurs)

exemple d'utilisation de wiresharj
Screenshot de wireshark