Introduction

Le back-office s’occupe de toute la gestion post-négociation des opérations financières. Le domaine, bien que moins prestigieux que celui des salles de marché, mobilise beaucoup plus de ressources humaines et technologiques pour mener à bien une quantité infiniment plus vaste de tâches. Les back-offices sont des centres de coût, mais l’expérience a montré qu’un établissement ne peut pas se permettre de sous-dimensionner son back-office.

C’est d’ailleurs pour cela que de plus en plus d’établissements sous-traitent leur fonction back-office. Sur le marché de la sous-traitance, la demande de petits établissements peu dotés en moyens humains et techniques rencontre l’offre d’établissements désirant optimiser de gros investissements technologiques.

Le document ci-dessous liste les fonctions de référence que l’on retrouvera dans tous les systèmes d’information back-office de marchés financiers. Certaines ne sont que mentionnées parce que bien que fréquemment citées par les éditeurs, elles couvrent un besoin plus global que le traitement des opérations elles-mêmes. Ces fonctions sont décrites dans des pages dédiées du site.

Référentiels

Pour des raisons de cohérence et de fiabilité de l’information, les données de référence de l’établissement ont vocation à être gérées dans une base de données indépendante des applicatifs front et / ou back. Ceux-ci iraient y chercher les informations nécessaires, qui, gérées de manière centralisée, ne sont ainsi pas dupliquées inutilement et surtout avec des risques d’erreur.

Toutefois, pour rationnel qu’il paraisse au premier abord, ce choix peut occasionner des difficultés lors de l’installation d’un progiciel dans l’établissement. En effet les progiciels proposent généralement leurs propres référentiels, qu’il va falloir alimenter avec celui de la banque, sachant que le modèle de données choisi ne sera fatalement pas identique. C’est pourquoi dans la pratique, les données de référence se retrouvent souvent disséminées, et encore plus souvent dupliquées, dans différentes applications.

Données de marché

De même que pour les données de référence, les données de marché ont tout lieu d’être gérées de manière centralisée puis distribuées à toutes les applications pouvant en avoir besoin.

Création et validation des deals

Le système doit disposer d’une fonction de saisie des deals et surtout de la possibilité d’importer automatiquement des tickets en provenance du système front, voire d’un système externe dans le cas de sous-traitance de back-office.

La fonction de saisie manuelle est détaillée dans les fonctions front office. En effet dans l’idéal, les systèmes front et back sont connectés, voire intégrés, et il n’est pas nécessaire de ressaisir les opérations. Dans le cas de saisie manuelle, le système applique souvent le principe des  » quatre yeux  » ( » four eyes principle « ) : toute opération doit être validée par un utilisateur différent de celui qui a effectué la saisie.

Confirmations

Une confirmation est un message que les 2 contreparties d’un deal s’échangent après la négociation afin que chacune puisse vérifier qu’il n’y a pas eu d’erreur ou d’incompréhension de part et d’autre. La confirmation matérialise également l’engagement pris par chaque partie à respecter les termes du contrat.

Bien souvent les procédures prévoient qu’aucune instruction de paiement ou de règlement-livraison ne soit émise avant la réception de la confirmation de la contrepartie et le rapprochement de celle-ci avec les caractéristiques du deal dans le système.

La confirmation reprend donc les caractéristiques du deal qui vient d’être négocié ainsi que les circuits de règlement-livraison (intermédiaires, systèmes de paiement et d’échange) qui vont être utilisés pour s’échanger les flux de titres ou d’espèces générés par le contrat.

Les confirmations s’échangent par messagerie SWIFT, par fax, télex, voire par courrier.

Paiement et règlement livraison

Le système back-office produit, en fonction des événements liés à chaque opération, les messages de paiement et de règlement livraison adressés aux intermédiaires ou au systèmes de place.

Pour générer ces messages on doit s’appuyer sur les instructions de règlement de la contrepartie. Ces informations sont en principe gérées dans le référentiel tiers. C’est une étape importante des traitements car l’émission de messages vers l’extérieur engage la responsabilité de la banque . Les erreurs de montant ou de sens ne sont pas recommandées ! Les opérations les plus simples et rodées sont réglées automatiquement ( » Straight Through Processing « ) mais l’utilisateur doit aussi avoir le moyen de contrôler les paiements avant leur émission.

Le netting de flux permet de générer un transfert unique quand plusieurs montants doivent être échangés avec la même contrepartie le même jour, d’où des économies, l’accès aux systèmes de money transfer étant relativement coûteux.

Modélisation des instruments financiers

La modélisation des instruments financiers permet à l’utilisateur de prédéfinir le comportements attendus (événements, méthodes de calcul…) d’une opération en fonction de la nature de l’instrument utilisé. La modélisation permet de standardiser, pour chaque instrument utilisé :

  • Le format de présentation des caractéristiques de l’opération dans :
    • Les masques de saisie
    • Les confirmations
    • Les reportings
  • Les caractéristiques techniques de l’opération et son mode de prise en charge dans les traitements :
    • Les événements générés par l’opération
    • Les calculs de réévaluation, de résultat, etc.
    • La prise en compte de l’opération dans les positions
    • Les schémas comptables

Gestion des événements

En fonction du type d’instrument traité, le système doit être capable de créer les événements de la vie de l’opération et de déclencher les flux d’information qui en découlent.

L’engagement, le départ, l’échéance, les tombées d’intérêts, sont autant d’événements qui sont susceptibles de produire des messages de paiement et de règlement-livraison à transmettre aux systèmes d’échange.

Certains calculs doivent être effectués périodiquement : liquidation, réévaluation, calcul de résultat, calculs d’appels de marge.

Enfin le système back-office doit alimenter la comptabilité de la banque.

Gestion de portefeuille

On regroupe sous cette rubrique toutes les fonctions prenant en compte une collection d’opérations appartenant au même portefeuille ou centre de profit suivant la terminologie employée dans les établissements.

  • Définition des portefeuilles
  • Calcul de positions
  • Valorisation
  • Suivi des risques
  • Calcul de résultat de gestion
  • Production d’échéanciers, d’impasse de trésorerie

En pratique l’utilisation de ce type de fonction n’est possible que si toutes les opérations d’un même portefeuille sont prises en charge par le même système d’information. Sinon l’information produite ne couvrira qu’une partie de l’activité et ne sera donc pas exploitable. C’est pourquoi les systèmes back-office se veulent le plus souvent aussi généralistes que possible, ce qui ne manque pas de poser des problèmes au niveau de la complexité et donc de la soutenabilité de l’ensemble.

Dans le cas de gestion pour compte de tiers, le système doit pouvoir prendre en compte les objectifs ou les contraintes définis par le client :

  • Profil de risque
  • Profil de résultat
  • Définition de limites
  • Profil d’investissement

Comptabilité

Le schéma comptable d’une opération décrit toutes les écritures comptables qui doivent être générées. Un événement dans la vie d’une opération déclenche une ou plusieurs écritures. Le système back-office calcule et alimente les CRE (Compte-rendu d’Evénement) comptables.

États de gestion

Échéanciers : en s’appuyant sur le stock d’opérations en cours dans le portefeuille, l’échéancier permet de visualiser, en position ou en flux, les fluctuations futures de la trésorerie.

Traitements globaux

Le système doit effectuer un certain nombre de traitements globaux, c’est-à-dire affectant l’ensemble des opérations : calcul de résultat, réévaluation, calculs de risque, génération des CRE comptables. Ces traitements sont le plus souvent organisés sous forme de batches planifiés à heure fixe, bien que la tendance soit de plus en plus à la mise à jour en temps réel des positions, résultats, etc.

La valorisation, ou réévaluation, consiste à calculer une valeur de marché pour chaque opération. Il existe plusieurs méthodes de réévaluation, la plus connue étant le Mark to Market. Comme son nom l’indique cette méthode consiste à affecter une valeur au contrat en fonction des prix de marché aujourd’hui.

Le calcul du résultat dégagé par chaque opération s’effectue suivant 2 méthodes : en intérêts courus ou en Mark to Market. Le calcul en Mark to Market consiste à calculer la différence entre la valeur de marché du jour du contrat et la valeur de marché de la veille : le résultat dégagé sur la journée écoulée est cette différence. Le calcul en intérêts courus consiste à étaler les flux d’intérêts générés par le contrat. Il est important de savoir qu’in fine, c’est-à-dire à l’échéance du contrat, les 2 méthodes aboutissent au même résultat.

États réglementaires

Le système doit produire les états ou fichiers obligatoires à l’intention des autorités de tutelle. Dans ce domaine les éditeurs de logiciel locaux détiennent un avantage sur les étrangers car ils sont mieux au fait des spécificités de la réglementation du pays.