Intégration bancaire

Nous travaillons avec les messages ISO 20022 que les banques utilisent pour les paiements et le reporting des entreprises : pain.001 pour les paiements, pain.002 pour les statuts, et camt.052, camt.053 et camt.054 pour les relevés de compte. Nous traitons aussi les relevés SWIFT MT940 et MT942 que de nombreuses banques envoient encore. Pour le transport, nous utilisons SFTP host-to-host, EBICS lorsque les banques le proposent, et les API bancaires. Chaque banque a sa propre variante de chaque format : nous développons donc à partir du guide de mise en œuvre de la banque, et non de la seule norme.

Nous connectons les banques à SAP S/4HANA, Oracle NetSuite, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, Odoo et Sage, ainsi qu’aux systèmes de trésorerie et aux systèmes sur mesure. Certains ERP disposent de leurs propres modules de communication bancaire. Dans ce cas, nous les configurons et les étendons plutôt que de les contourner. La mention d’un produit sur cette page ne signifie pas un partenariat avec son éditeur.

Cela dépend surtout de la banque, et non du code. Chaque banque fixe ses propres étapes d’enrôlement, ses fenêtres de test et ses validations, et certaines exigent des contrats ou des échanges de clés avant le début des tests. Le nombre de banques, de types de paiement et de pays compte également. Après l’étape de correspondance, nous vous remettons un plan par banque et commençons les tests avec la première banque prête.

Le nombre de banques et de canaux, les types de paiement et les pays du périmètre, ce que votre ERP prend déjà en charge, et la complexité de vos règles de rapprochement. Les exigences de signature et de chiffrement ainsi que le processus de test de chaque banque demandent un effort supplémentaire. Nous chiffrons par banque et par flux après le cadrage, afin que vous puissiez échelonner les travaux et leur coût.

Les fichiers de paiement sont signés et chiffrés selon les exigences de chaque banque, par exemple avec OpenPGP, et ne transitent que par le canal convenu. Les clés et les certificats sont conservés dans votre coffre-fort de clés ou votre module de sécurité matériel (HSM), jamais dans le code, et seules des personnes nommément désignées peuvent y accéder. Les fichiers sont contrôlés avant leur envoi et chaque transfert est journalisé, ce qui vous permet de retrouver qui a validé et envoyé chaque paiement.

Elle rejoint une liste de revue avec les correspondances probables et le motif de l’écart, par exemple une différence de montant ou une référence manquante. Votre équipe la traite à cet endroit, et les règles peuvent être ajustées pour que le même cas soit rapproché la fois suivante. Rien n’est comptabilisé dans le grand livre sans un rapprochement que vous avez validé.

Les banques annoncent leurs changements de format à l’avance, comme beaucoup l’ont fait lors du passage des messages SWIFT MT aux messages ISO 20022. Nous suivons ces annonces pour les banques que nous connectons, évaluons l’impact, et planifions avec la banque le changement et ses tests avant l’échéance qu’elle a fixée. Ce suivi peut faire partie d’un contrat de support.

Dès le premier commit, vous êtes titulaire de la propriété intellectuelle des travaux que nous réalisons pour vous : aucune cession n’est à prévoir en fin de projet. Cela couvre le code spécifique, la documentation et les autres livrables réalisés pour vous. Les éléments préexistants que nous apportons, tels que des outils internes ou des bibliothèques, restent notre propriété, et vous recevez une licence pour les utiliser dans vos systèmes. Les composants open source conservent leurs propres licences, et nous vous en fournissons la liste.