Les questions à se poser avant de choisir un PMS

Le choix d’un PMS – Portfolio Management System – constitue une décision structurante, qui engage sur plusieurs années. Pour parvenir à déterminer la solution la plus adaptée à ses besoins, il me semble nécessaire de répondre à au moins quatre questions essentielles.

Ces questions essentielles s’accompagnent chacune de réflexions corollaires non exhaustives tout aussi déterminantes. Y répondre avec rigueur me semble être LE préalable indispensable à un processus de sélection de PMS, que ce soit via RFI ou des ateliers de présentation. Pour faciliter cette démarche, je recommande d’ailleurs vivement l’organisation d’un PoC – Proof of Concept – qui permettra de tester le comportement de chaque solution candidate sur des cas d’utilisation précis et dans des conditions les plus proches possibles de la réalité.

La solution est-elle cohérente par rapport à mon univers d’investissement ?

Supposons par exemple que je pratique la multigestion alternative. Il s’agit ici de déterminer comment l’investissement dans des parts de hedge funds est modélisé dans tel ou tel outil. Je pense en particulier aux spécificités de type prépaiement sur les souscriptions, règlements échelonnés sur les rachats, soft/hard lock-ups, investor gates. Sont-elles gérées nativement ? Si la réponse est négative, je dois dès à présent réfléchir aux adaptations qui devraient être apportées pour qu’elles soient supportées.

Supposons à présent que certains de mes fonds détiennent des swaps OTC (typiquement, des variance swaps, correlation swaps, TRS, ou autres swaps de performance). L’idée est de savoir si ces instruments sont supportés par l’outil étudié, comment ils sont modélisés et valorisés, quels types de sous-jacent sont disponibles, ou encore quels évènements de leur cycle de vie sont gérés.

Supposons enfin que mes fonds aient en inventaire de nombreuses cessions temporaires. Là encore, il faut déterminer comment celles-ci sont représentées, valorisées, et quels évènements sont supportés (que ce soit sur le contrat lui-même – prorogation, changement de taux d’intérêt, changement de nominal, échéance – ou sur l’instrument sous-jacent – détachement de coupon / dividende, split).

La gestion des spécificités par pays (ex : futures sur obligations australiens cotés en yield, obligations mexicaines dénombrées en units…) constitue également un critère à étudier.

Lorsque tel type d’instrument financier, telle propriété ou tel événement de son cycle de vie n’est pas géré de façon native par un logiciel, je recommande de porter un regard critique sur l’adaptation ou la solution de contournement proposée. Si celle-ci existe, bien entendu. Cette solution peut-elle être mise en œuvre aisément ? Dispose-t-on de suffisamment d’autonomie vis-à-vis de l’éditeur dans le cadre de sa maintenance et des éventuelles évolutions qu’on souhaiterait voir apporter ? Sera-t-elle pérenne ? En particulier qu’adviendra-t-il lors des futures montées de version de l’outil ? Il me paraît important d’éviter de construire une usine à gaz difficilement maintenable et non évolutive.

Les fonctionnalités de base répondent-elles à mes cas d’utilisation ?

Le socle d’un PMS est la tenue de positions. Etudions ici la gestion de la pile d’opérations (traitement en FIFO, LIFO, calcul de PRMP, …) et le cycle de vie des transactions (quels sont les statuts gérés ? Comment s’opèrent les transitions entre ces statuts ?). Il faut aborder les modalités de calcul et de stockage des positions (en temps réel / par snapshots, en engagement / par date valeur, positions persistées ou constamment re-calculées à partir de transactions) et de leur valorisation (application de pricing policies et de profils de taux de change définis). A ce stade on doit s’interroger sur les possibilités de ségrégation de ces positions à l’actif (par poches, par stratégies) et au passif (par parts, par groupes de parts) en se demandant par exemple comment ces caractéristiques sont propagées le long du STP, ou encore dans quelle mesure les flux de cash peuvent également être ségrégués (ventilation par poche, possibilité de paramétrer plusieurs comptes cash pour un même fonds et une même devise…).

Une fois que ces problématiques sont arbitrées, les fonctionnalités s’appuyant sur la base de cette tenue de positions doivent être étudiées. Il s’agit en particulier de détailler les indicateurs mis à disposition dans le cadre du suivi des fonds (exposition, sensibilité, duration, grecques, VaR, expected shortfall, tracking error, ratio de Sharpe, max drawdown…), les méthodologies de calcul de performance et de risques, l’impact sur ces différents indicateurs de scénarii / stress tests / simulations. Il faut également aborder les modalités de calcul d’actif net et de valeur liquidative : gestion du multipart (parts capitalisées, distribuées) et, en particulier, des parts hedgées (couverture par part ou groupe de parts, via instruments OTC ou dérivés listés), calcul des frais de gestion fixes et variables (via quelles méthodologies ?), gestion de spécificités de calcul (swing pricing, …).

Les écrans / modules principaux permettant d’interagir avec ces fonctionnalités de base ne doivent pas être négligés  : écrans d’inventaires, de passage et suivi des ordres, de suivi de la trésorerie, modules de réconciliations des flux / stocks, d’administration / application des OST…

A ce stade, l’ergonomie de l’outil peut être étudiée. Peut-on par exemple accéder à l’information et interagir avec celle-ci facilement via un nombre limité d’actions ? Ou, au contraire, est-il nécessaire d’ouvrir 25 fenêtres différentes pour pouvoir travailler, obligeant l’utilisateur de jongler de l’une à l’autre ? Ces questions sont légitimes, un outil d’utilisation instinctive est  généralement accepté plus facilement par les équipes. Attention néanmoins à ne pas donner plus d’importance à ces critères qu’ils n’en ont réellement : une bonne ergonomie, une IHM soignée, ne peuvent masquer des problèmes de fond, en termes de modélisation par exemple.

L’outil s’intègre-t-il à mon écosystème sans (trop de) difficultés ?

L’intégration d’un PMS constitue une opération complexe et coûteuse. Il ne faut pas négliger les problématiques de connectivité, que ce soit au sein du SI de mon organisation, ou avec l’extérieur. Je pense notamment aux modalités d’interfaçage suivantes : lien avec l’OMS (passage d’ordres, remontée des données d’exécutions), lien avec l’outil de gestion du passif (récupération des souscriptions / rachats), interface avec le(s) référentiel(s) (récupération des caractéristiques instruments / tiers / portefeuilles, des données de marchés), alimentation d’un éventuel infocentre, interaction avec les outils / bibliothèques de pricing et de calcul de risques.

Il faut aussi tenir compte des liens avec les entités extérieures (protocoles de communication, formats de données) : dépositaires, valorisateurs, autorités de régulation, fournisseurs de données …

Les performances de la solution sont-elles acceptables pour mes utilisateurs ?

Le prérequis est de disposer d’éléments de volumétrie concernant mon organisation : nombre de fonds gérés, nombre de lignes de positions (par jour, et au global), nombre de transactions (par jour, et au global), nombre d’utilisateurs.

Sur cette base, il s’agit de déterminer certaines métriques, comme par exemple le temps de calcul et d’affichage d’un inventaire valorisé d’un fonds de grande taille (et de son benchmark), voire d’un groupe de fonds (par exemple, l’ensemble des fonds d’une ligne de gestion). Il faut se demander si ces positions et les indicateurs qui les accompagnent sont préchargés / précalculés pour gagner en performance. Et, si oui, comment et à quelle fréquence sont-ils rafraîchis ? Il est indispensable également d’estimer le temps de passage d’un bloc d’ordres (par exemple suite à un rebalancement d’indice, ou dans le cadre d’un roll de dérivés). On peut également mesurer le temps nécessaire à l’affichage de l’historique de transactions, et celui relatif au calcul de flux de trésorerie prévisionnelle.

Je vous recommande à cette étape de demander à l’éditeur des références de clients de taille comparable ou supérieure. Un outil utilisé uniquement par des petites ou moyennes structures risque de ne pas avoir le niveau de performance requis pour un gros asset manager. Il devra en tout cas faire l’objet de tests de charge particulièrement poussés.