Qu’est-ce qu’une payment factory ?

Payment factory : un logiciel pour professionnels

English version

Une payment factory est un logiciel destiné aux professionnels (ie progiciel) de la finance, et plus précisément de la Trésorerie qui a pour but la centralisation des paiements. Il peut être traduit par « plateforme de paiement » en français.
La cible et les utilisateurs de ce type de solutions informatiques peut même être réduite à une niche se limitant aux trésoriers des grandes entreprises et à leurs collaborateurs. En effet, ces progiciels paraîtront sans doute surdimensionnés aux petites entreprises et à toutes celles qui ne gèrent pas une multitude de flux et de paiements chaque jour.

Schéma d’une payment factory

Par « grandes entreprises », on entend le plus souvent les grands groupes, c’est-à-dire des sociétés souvent multinationales qui possèdent des filiales dans de nombreux pays, voire sur plusieurs continents, et qui organisent leur trésorerie et veulent centraliser leur trésorerie, au choix, de la manière suivante :

• workflow local : import ou saisie des paiements au niveau de la filiale puis transmission à la banque
• workflow local + central : import ou saisie des paiements au niveau de la filiale puis envoi à la maison-mère qui valide puis transmet à la banque
• workflow central : l’ensemble des opérations se déroulent au niveau de la maison-mère, de la création du paiement à sa transmission à la banque

Workflow et centralisation des paiements

Selon les procédures internes de l’entreprise, le nombre d’étapes à effectuer dans l’application de paiement avant la transmission bancaire peut être plus ou moins élevés.
En effet, on peut imaginer :

• la saisie manuelle ou l’import des paiements dans le logiciel (depuis une application amont) au sein d’une filiale
• la constitution automatisée ou manuelle en lots de paiements selon des critères communs aux paiements
• ces lots seront envoyés à un premier responsable qui validera ou non la constitution de chacun de ces lots (en fonction du type et de la sévérité de la validation mise en place, un lot peut être rejeté si un seul des paiements inclus est rejeté, ou se voir validé malgré tout après le retrait du paiement incriminé)
• ce premier responsable enverra à son propre N+1 ces lots de paiements validé ; celui-ci signera numériquement (via un token, une clé, ou simplement via un clic) ces lots
• un 5e intervenant sera alors prévenu par le logiciel que des lots peuvent être envoyés à la centrale de trésorerie située dans la maison-mère
• au sein de la maison-mère, un nouveau workflow peut alors se mettre en place au sein de la payment factory et calquer tout ou partie des étapes indiquées ci-dessus
• enfin, un dernier responsable enverra le lot ou les lots de paiements ayant passé avec succès les différentes étapes de validation décrites ici vers l’établissement bancaire, toujours via le logiciel si celui-ci intègre bien un module de communication bancaire

Chacun de ces utilisateurs intervenant dans le processus de validation est le plus souvent prévenu par le système d’une nouvelle action à effectuer par messagerie électronique (envoi automatique par le système), et/ou directement dans le logiciel via un tableau de bord et/ou des écrans dédiés aux actions auxquels l’utilisateur est affecté.

Certaines sociétés ont une approche des workflows au sein d’une payment factory diamétralement opposée à celle qui est décrite ici. Celles-ci préfèrent au contraire tout automatiser jusqu’à la dernière ou l’avant-dernière étape du processus, juste avant l’envoi en banque, et ainsi laisser l’application faire passer les lots aux statuts supérieurs (un statut correspondant à une étape) sans intervention humaine ou presque.

Lots de paiements vs paiements unitaires

Comme on vient de le voir, les meilleures payment factories proposent l’envoi en banque non pas de simples paiements unitaires, mais de lots de paiements. En effet, pour des raisons de productivité évidentes, lorsque des milliers d’opérations liées à des paiements et à des encaissements sont versées dans le logiciel, le traitement par lot permet de gagner un temps précieux. Les paiements sont donc centralisés, puis groupés.
La payment factory permet ainsi grâce à des macros (programmes permettant d’automatiser des tâches, le plus souvent récurrentes) de définir quels types de paiements seront versés dans un lot. Par exemple, on peut imaginer qu’un lot sera constitué, au choix :

• de tous les paiements du jour à effectuer vers un même compte en banque
• de tous les paiements effectués par une entité donnée à une autre entité
• de tous les virements de paye
• de tous les encaissements de la semaine liés à un fournisseur particulier
• etc.

L’utilisateur qui sera autorisé à valider peut ainsi être choisi en fonction de ses connaissances spécifiques liées aux caractéristiques des paiements inclus dans un type de lot précis.

On peut aussi noter dans certaines payment factories, à l’inverse, que le niveau de détail des flux financiers traiter peut aller au-delà des paiements et des lots de paiements avec, par exemple :

• des factures attachées à un paiement
• des groupes de lots de paiements à envoyer à la banque

Communication bancaire et paiements

La payment factory est chargée de centraliser et de communiquer les paiements et les lots de paiements aux différentes banques renseignées dans le référentiel, de recevoir les réponses de ces banques (acceptation, refus, demande d’informations…) et autres messages bancaires, puis de les transférer à l’initiateur, c’est-à-dire à l’utilisateur de la payment factory qui a impulsé l’exécution de la communication bancaire.
A l’instar des protocoles Internet – http(s), (s)ftp, smtp, pop, imap… – il existe différents protocoles de communication bancaire. Les plus fameux, sécurisés, mais aussi les plus utilisés sont :

• SWIFTNet : protocole d’échange d’informations bancaires à échelle mondiale, géré par la société SWIFT (Society for Worldwide Interbank Financial Telecommunication)
• EBICS (Electronic Banking Internet Communication Standard) : protocole de communication basé sur https choisi par le CFNOB (Comité français d’organisation et de normalisation bancaires) pour remplacer les protocoles ETEBAC (ETEBAC 3 et ETEBAC 5), jugés trop lents et moins sécurisés, au début des années 2010

Logo officiel de SWIFT

Ces protocoles sont aujourd’hui (2016) utilisés en masse par l’ensemble des grands groupes internationaux dans le cadre de leurs paiements et encaissements.

Payment factory ou Collection factory ?

Le terme « payment factory » est en fait restrictif, car il ne recouvre que la moitié des activités de cette catégorie de logiciels. En effet, « l’usine » traite et centralise à la fois les paiements de l’entreprise, mais aussi ses encaissements. On devrait donc plutôt parler de « payment and collection factory » ou « plateforme de paiement et encaissement ».

En effet, les flux et paiements traités dans les payment factories couvrent une grande diversité de moyens de paiement et de types comptables, relatifs au domaine d’activité de l’entreprise, à sa clientèle (B2C vs B2B) et à ses choix stratégiques :

• virements (masse, RH et salaires, fournisseurs, internes…)
• prélèvements (TIP, bientôt remplacé par les prélèvements SEPA, dits SDD pour SEPA Direct Debit, mais aussi non SEPA, notamment pour les prélèvements non européens) et encaissements (abonnés, clients…)
• opérations de netting, de marché, de trésorerie
• LCR
• chèques
• …

 Droits et privilèges des utilisateurs dans la centralisation

Une bonne payment factory possède une administration et un paramétrage des utilisateurs permettant de définir finement les possibilités d’action et de visualisation données à un utilisateur, comme :

• l’accès au logiciel
• la complexité de son mot de passe
• l’expiration de ses identifiants
• la visualisation de certains menus
• la visualisation de certaines opérations
• la visualisation de certains détails au sein de certains opérations (ex : nom d’une personne ou montant versé dans un virement)
• l’interdiction d’accès à certaines données (ex : si l’utilisateur Dupont n’a pas accès à une entité X et si X est concernée par un paiement que Dupont est supposé avoir le droit de voir, ce dernier peut s’en voir refuser la visualisation)
• la validation de certaines opérations ou de certains changements
• l’appartenance à un groupe d’utilisateurs possédant des droits et privilèges communs
• le droit d’administration
• la signature électronique
• l’envoi à la banque
• la création de macros
• la réceptions de messages bancaires
• …

Référentiel intégré à la payment factory

Pour pouvoir obtenir une payment factory efficace, il faut bien entendu récupérer tous les paiements pour les centraliser. Néanmoins, c’est insuffisant pour constituer un logiciel prêt à l’emploi, et de nombreuses données doivent être versées à la base de données du logiciel. Elles sont souvent récupérées depuis un logiciel amont par le biais d’un moteur d’import-export qui retranscrit les données au formats demandés par la plateforme de paiements. Il s’agit, entre autres, des :

• entités (filiales, émettrices ou bénéficiaires)
• banques
• comptes
• pays
• devises
• jours fériés
• structures IBAN
• codes BIC
• type d’opérations
• plafonds de signature
• types de paiements
• …

Ce référentiel de données est alors utilisé dans les paiements ou dans le paramétrage des différentes étapes du workflow spécifique à chaque type d’opérations.

Technologies et Payment Factories en 2016

Quelques plateformes de paiement utilisent encore des technologies clients-serveur et nécessitent donc des installations sur chacun des postes utilisateurs, en plus du serveur logiciel et de la base de données (VB, C++, SQL Server pour Windows).
Lourdes et dépassées depuis plusieurs années, ces technologies ont été remplacées progressivement par les éditeurs de logiciels par les technologies et langages Web (Java J2EE, php, python…) et associées aux serveurs d’applications (Tomcat, WebSphere, WebLogic…) et aux SGBD (Système de Gestion de Base de Données : Oracle, DB2, MySQL, SQL Server…) les plus robustes et les plus répandues sur le marché.

Les logiciels basés sur les technologies Web présentent l’avantage de pouvoir être déployés rapidement et de ne nécessiter aucune installation sur les postes utilisateurs.
En effet, un simple navigateur Web (Microsoft IE ou Edge, Google Chrome, Mozilla Firefox, Apple Safari…) est alors suffisant pour accéder et se connecter à la payment factory.

Payment factories et progiciels hybrides

Les payment factories peuvent être intégrées à des gammes de logiciels offrant un panel plus large d’outils dédiés aux trésoriers, voire aux traders, aux DAF (Directeur Administratif et Financier) et aux comptables.
Les métiers étant complexes et les ponts entre les différentes responsabilités et tâches des trésoriers étant parfois peu évidents, ces suites d’applications sont rares. Elles se font fort d’adjoindre à la plateforme de centralisation de paiement différentes solutions spécifiques :

• le logiciel de trésorerie « basique » (rapprochement des prévisions et des réalisations, gestion des placements et crédits, fiches en valeur, voire netting, reporting de trésorerie…)
• le rapprochement bancaire-comptable (matching automatisé des extraits de comptes bancaires et des écritures)
• le TMS (Treasury Management System) ou smart TMS ou TRM (Treasury and Risk Management) qui permet, selon son approche, de gérer tous les aspects du trading groupe depuis la stratégie de création de l’opération financière (Front Office) à sa comptabilisation (Back Office) en passant par le contrôle (Middle Office) et la gestion des risques associés

Typologie de l’offre et pricing

On trouve 3 grands types d’offres de payment factory, qui valent également pour toute la gamme de logiciels orientés Trésoreries grands groupes :

• achat sec de licences + maintenance : la société acquiert auprès de l’éditeur de logiciels ou de son distributeur un nombre de licences permettant d’installer le logiciel in house (serveur dans ses propres locaux), de créer N utilisateurs et/ou administrateurs et/ou types de flux financiers sans limite de temps, et achète une maintenance à l’année (correction de bugs, support…) renouvelable
• offre SaaS (Software as a Service) ou PaaS (Platform as a Service) : offre la plus moderne et la plus simple, permettant d’accéder à la plateforme de paiement installée sur un serveur mutualisé géré et maintenu par l’éditeur ou le distributeur, sans limite de temps. Paiement mensuel ou trimestriel le plus fréquemment, dont le montant est calculé sur la volumétrie et le nombre d’utilisateurs.
• offre hébergée simple : accès à la payment factory installée sur un serveur dédié, géré et maintenu par l’éditeur ou le distributeur, sans limite de temps. Paiement mensuel ou trimestriel le plus fréquemment, dont le montant est calculé sur la volumétrie et le nombre d’utilisateurs.

Si le SaaS ou PaaS (version évoluée du SaaS basée sur le cloud computing) a aujourd’hui le vent en poupe dans de nombreux secteurs, les Trésoriers demeurent réticents à l’idée d’héberger des données sensibles (flux de paiements et informations utilisateurs) hors de leur infrastructure et de leur DSI.

Quelle que soit la solution choisie, la payment factory sera amenée à évoluer, et de nouvelles versions, mineures ou majeures, du logiciel seront proposées sous forme de mises à jour aux décideurs par les commerciaux ou consultants de l’entreprise conceptrice de l’application.