Banque, trésorerie et connectivité ISO 20022
Paiements sortants, relevés entrants, rapprochés automatiquement dans toutes les devises
Les équipes trésorerie ressaisissent encore les paiements et rapprochent les relevés à la main
Beaucoup d’équipes trésorerie saisissent les paiements dans les portails bancaires, collectent les relevés dans des formats différents selon chaque banque et rapprochent les comptes dans des tableurs à la clôture du mois. Chaque étape manuelle est un délai, un coût et une occasion de fraude ou d’erreur.
Les banques passent par ailleurs à ISO 20022, la norme internationale des messages financiers, qui porte des données plus riches et structurées que les anciens formats SWIFT MT. Les systèmes incapables de les produire et de les lire prennent du retard sur leurs banques.
Ce qui change pour vous
Traitement de bout en bout
Les lots de paiement approuvés quittent l’ERP sous forme de fichiers signés ou d’appels d’API, et les relevés reviennent sous une forme que l’ERP rapproche seul.
Une clôture plus rapide
Un rapprochement multidevise quotidien, au lieu de téléversements CSV manuels et d’ajustements sur tableur en fin de mois.
Chaque exception confiée à une personne
Les paiements rejetés et les lignes non rapprochées arrivent dans une file d’exceptions de messages morts avec leur motif, jamais perdus dans une boîte aux lettres.
Ce que nous livrons
Connectivité host-to-host et accès direct aux banques
Connexions par SFTP, EBICS et SWIFT, et API bancaires directes ou d’open banking, choisies banque par banque et pays par pays.
Génération des fichiers de paiement
Fichiers de paiement ISO 20022 pain.001 construits à partir de vos lots de paiement, validés selon la variante de chaque banque et signés ou chiffrés comme elle l’exige.
Traitement des statuts et des rejets
Rapports de statut pain.002 relus, pour que chaque paiement apparaisse comme accepté, rejeté ou en attente, avec le code de motif de la banque.
Ingestion des relevés
Relevés de fin de journée camt.053 et MT940 et rapports intrajournaliers collectés, contrôlés pour les manques et les doublons, puis chargés dans l’ERP.
Messagerie interbancaire pour banques et fintechs
Messages pacs pour les virements et leur statut entre institutions financières, reliés aux grands livres des systèmes cœur de banque.
Rapprochement multidevise
Des règles de rapprochement qui soldent automatiquement les écritures ouvertes entre devises et comptes, et envoient le reste dans une file d’exceptions.
Preuves de test bancaire et manuels d’exploitation
Cas de test de chaque banque exécutés et consignés pour vos auditeurs, et alertes pour les fichiers manquants, les virements en échec et les clés ou certificats arrivant à expiration.
Comment nous travaillons
Cartographier banques et flux
Nous listons vos banques, comptes, types de paiement et étapes manuelles actuelles, et convenons des flux à traiter en premier.
Spécifier chaque format
Nous partons du guide d’implémentation de chaque banque et rédigeons la correspondance, y compris la signature, le chiffrement et le nommage des fichiers.
Construire les connecteurs
Nous construisons l’export des paiements, l’import des statuts et des relevés et le rapprochement, avec des tests automatisés pour chaque format.
Tester avec chaque banque
Nous exécutons les cas de test convenus dans l’environnement de test de la banque et corrigeons tout ce que sa validation rejette.
Mettre en production banque par banque
Nous basculons une banque à la fois, le processus actuel restant prêt comme solution de repli jusqu’à preuve du nouveau.
Superviser et accompagner
Nous surveillons les virements, les clés et l’expiration des certificats, et planifions les changements de format à mesure que les banques les annoncent.
Faites défiler horizontalement pour voir l’ensemble du schéma.
De l’ERP à la banque : paiements sortants, relevés entrants
Les paiements approuvés quittent l’ERP sous forme de fichiers ISO 20022 signés, via un canal host-to-host. Les comptes rendus de statut et les relevés reviennent par le même chemin et sont rapprochés des postes ouverts. Les rejets et les lignes non rapprochées sont transmis à votre équipe, motif à l’appui.
- Flux principal
- Asynchrone
- Chemin d’exception
Le flux en 10 étapes
Le flux, étape par étape
- De ERP à Couche d’intégration : Campagne de paiements approuvée, via REST/JSON · IDoc (flux principal).
- De Couche d’intégration à Canal bancaire sécurisé : Fichier de paiement signé et chiffré, via ISO 20022 pain.001 · OpenPGP (flux principal).
- De Canal bancaire sécurisé à Banque : Remis à la banque, via SFTP H2H (flux principal).
- De Banque à Canal bancaire sécurisé : Comptes rendus de statut et relevés, via pain.002 · camt.053 · MT940 (asynchrone).
- De Canal bancaire sécurisé à Couche d’intégration : Collectés et validés, via SFTP H2H (asynchrone).
- De Couche d’intégration à Moteur de rapprochement : Lignes de relevé, via camt.053 (asynchrone).
- De Moteur de rapprochement à ERP : Écritures rapprochées comptabilisées, via REST/JSON (flux principal).
- De Couche d’intégration à Équipe trésorerie et finance : Paiements rejetés, avec le code motif, via pain.002 RJCT (chemin d’exception).
- De Moteur de rapprochement à Équipe trésorerie et finance : Lignes non rapprochées : écart de rapprochement (chemin d’exception).
- De Équipe trésorerie et finance à ERP : Corrigés et soumis à nouveau (chemin d’exception).
Faites défiler horizontalement pour voir l’ensemble du schéma.
Open banking : données et paiements avec le consentement du client
Le client donne son consentement, le connecteur conserve les jetons, et chaque appel à la banque est autorisé et journalisé. Lorsque le consentement expire ou est retiré, l’application sollicite à nouveau le client au lieu d’échouer sans rien signaler.
- Flux principal
- Asynchrone
- Chemin d’exception
Le flux en 7 étapes
Le flux, étape par étape
- De Client à Votre application ou plateforme : Donne son consentement (flux principal).
- De Votre application ou plateforme à Connecteur open banking : Demandes de comptes et de paiements, via REST/JSON (flux principal).
- De Connecteur open banking à API bancaires ou agrégateur : Appels API autorisés, via OAuth 2.0 · FAPI · REST (flux principal).
- De API bancaires ou agrégateur à Connecteur open banking : Soldes, transactions et statut des paiements, via REST/JSON · webhook (asynchrone).
- De Connecteur open banking à ERP ou grand livre : Transactions normalisées, via REST/JSON (flux principal).
- De API bancaires ou agrégateur à Connecteur open banking : Consentement expiré ou retiré, via HTTP 401 · 403 (chemin d’exception).
- De Connecteur open banking à Votre application ou plateforme : Client invité à renouveler son consentement (chemin d’exception).
Standards, formats et canaux
Nous construisons à partir du guide d’implémentation de chaque banque, et non de la norme seule. Nommer un produit ne signifie pas un partenariat avec son éditeur.
- Standards et canaux bancaires
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Des preuves en production
Pour une banque de premier rang du CCG et un conglomérat régional, nous avons relié SAP S/4HANA aux rails bancaires régionaux en ISO 20022. Les paiements sont signés, les exceptions arrivent dans des files de messages morts et le rapprochement entre ses comptes bancaires est automatique.
Comment démarrer
Des exigences bancaires et de format claires mènent directement à une proposition. Plusieurs banques, plusieurs pays ou une interface existante non documentée commencent généralement par le studio Blueprint ou le diagnostic brownfield.
Les prochaines étapes
Entretien préalable
Un entretien préalable gratuit de 30 minutes en ligne : nous passons en revue vos objectifs, vos systèmes et vos contraintes.
Revue de préparation
Lors d’une revue de préparation gratuite de 48 heures, un architecte principal confronte votre projet à la définition de « prêt » en 6 points et recommande le parcours adapté.
Choisir le parcours
Les projets au périmètre prêt reçoivent une proposition ferme sous 3 à 5 jours ouvrés. Les projets au stade du concept démarrent dans le studio Blueprint. Un système en production qui défaille, n’est pas documenté ou doit être intégré commence par un diagnostic de 1 à 2 semaines. Le studio Blueprint et le diagnostic ont chacun des honoraires fixes, indiqués dans la proposition.
Réalisation en cinq étapes
Mobilisation, sprints avec démonstrations en direct, intégration et durcissement, recette et mise en production, puis services gérés. Après la mise en production vient une période de garantie, puis une assistance et une maintenance optionnelles.
Projets à résultat ferme et services managés 24 h/24
Une réalisation à périmètre ferme, jalonnée et dirigée par des responsables de livraison désignés, et des services managés applicatifs 24 h/24 avec gouvernance des SLA.
Spécialistes intégrés et renfort stratégique
Des ingénieurs principaux et des spécialistes nearshore et sur site, et des architectes de solution, de transformation, de PQC et d’intégration intégrés à vos équipes.
Questions et réponses
Qu’est-ce qu’ISO 20022, et pourquoi est-ce important ?
ISO 20022 est la norme internationale des messages financiers. Ses messages XML portent des données structurées, comme les noms complets, les adresses et les détails de règlement, que les anciens formats SWIFT MT ne peuvent pas transporter. Les banques et les systèmes de paiement y sont passés, si bien que les fichiers de paiement et de relevés construits sur cette norme se rapprochent mieux et passent plus souvent les contrôles de conformité.
Avec quels formats et canaux bancaires travaillez-vous ?
Nous utilisons pain.001 pour les paiements, pain.002 pour les statuts, camt.052, camt.053 et camt.054 pour les relevés de compte, et les messages pacs entre banques. Nous lisons aussi les relevés MT940 et MT942 que beaucoup de banques envoient encore. Le transport est host-to-host SFTP, EBICS, SWIFT ou des API bancaires. Chaque banque a sa propre variante de chaque format, si bien que nous partons de son guide d’implémentation.
À quels ERP pouvez-vous connecter les banques ?
SAP S/4HANA, Oracle Fusion Cloud ERP et NetSuite, Microsoft Dynamics 365, Odoo et Sage, ainsi que des systèmes de trésorerie et des systèmes spécifiques. Lorsque l’ERP dispose de son propre module de communication bancaire, nous le configurons et l’étendons plutôt que de construire à côté.
Comment sécurisez-vous les fichiers de paiement ?
Les fichiers de paiement sont signés et chiffrés comme chaque banque l’exige et ne circulent que par le canal convenu. Les clés et certificats sont conservés dans votre coffre de clés ou module de sécurité matériel, jamais dans le code. Les fichiers sont validés avant envoi, et chaque virement est journalisé, pour que vous puissiez tracer qui a approuvé et envoyé chaque paiement.
Que se passe-t-il lorsqu’une ligne de relevé ne se rapproche pas ?
Elle arrive dans une liste de revue avec les candidats probables et la raison du non-rapprochement, comme un montant différent ou une référence manquante. Votre équipe la traite là, et les règles peuvent être ajustées pour que le même cas se rapproche la fois suivante. Rien n’est comptabilisé au grand livre sans un rapprochement que vous avez approuvé.
Qu’est-ce qui donne le rythme d’une intégration bancaire ?
Surtout la banque, pas le code. Chaque banque fixe ses étapes d’intégration, ses fenêtres de test et ses approbations, et certaines exigent des contrats ou des échanges de clés avant le début des tests. Après l’étape de correspondance, nous vous donnons un plan par banque et commençons les tests avec la première banque prête.
Que se passe-t-il lorsqu’une banque change de format ?
Les banques annoncent les changements de format à l’avance, comme beaucoup l’ont fait en passant de SWIFT MT à ISO 20022. Nous suivons ces annonces pour les banques que nous connectons, évaluons l’impact et planifions le changement et ses tests avec la banque avant son échéance.
Prêt à construire ? Demandez une proposition.
Envoyez vos exigences ou votre appel d’offres. Nos architectes les valident et reviennent avec une proposition ferme à périmètre défini.
Les prochaines étapes
Revue de préparation
Lors d’une revue de préparation gratuite de 48 heures, un architecte principal confronte votre projet à la définition de « prêt » en 6 points et recommande le parcours adapté.
Proposition ferme
Après validation de l’architecture sans frais, vous recevez une proposition ferme à périmètre défini sous 3 à 5 jours ouvrés : jalons, architecture, structure d’équipe et SLA. Sur demande, nous signons avec vous un accord de confidentialité (NDA) avant que vous ne nous communiquiez vos exigences.
Mobilisation
Une fois le contrat signé, nos équipes d’ingénierie lancent le sprint 0 dans les 5 à 10 jours ouvrés suivant la signature du contrat.
Réalisation en cinq étapes
Mobilisation, sprints avec démonstrations en direct, intégration et durcissement, recette et mise en production, puis services gérés. Après la mise en production vient une période de garantie, puis une assistance et une maintenance optionnelles.