Les autorités exigent par exemple une continuité de service lorsque les institutions financières souhaitent mettre en place des paiements instantanés. Lors du développement de TRAVIC-Payment Hub, nous avons nous-mêmes expérimenté ce que ces exigences impliquent dans l'architecture d'un logiciel. Il s'y ajoute un grand nombre de systèmes périphériques, comme ceux pour la lutte contre le blanchiment d'argent ou les listes d'embargo ou de sanction, sans parler des systèmes de routage. Pour des raisons de coûts, de nombreuses institutions financières préfèrent par conséquent ne pas du tout traiter ces transactions financières en interne et les externalisent auprès d’une institution centrale au sein d'un grand groupe. En revanche, ce procédé se révèle insatisfaisant si le transfert de paiements représente à terme une activité stratégique.
Plaque tournante pour paiements
C’est pourquoi nous avons recherché la composante spéciale qui doit être intégrée dans les systèmes de paiement par les institutions financières pour se démarquer de la concurrence et pour offrir leur propre transfert de paiements. Cet aspect est notamment pertinent pour les institutions qui se présentent comme prestataire de services auprès de clients entreprises pour le traitement d’opérations financières dans certaines régions du monde. Le résultat : les processus de nombreuses banques ne diffèrent guère les uns des autres. Souvent seul l'ordre dans lequel ils sont exécutés les différencie. Suite à ce constat, nous avons conçu une plaque tournante de paiement qui fonctionne comme un manège. Les fonctionnalités spéciales sont accessibles à chaque étape, de la même manière que les enfants peuvent accéder à n’importe quel manège de leur choix dans une fête foraine (voir aussi figure 1).
TRAVIC-Payment Hub permet à une institution financière d'offrir toute configuration envisageable. Cela s'applique à l’administration du routage, pour lequel un ensemble complexe de règles peut être défini, et également aux systèmes périphériques connectés. Mais de quelle façon TRAVIC-Payment Hub sait-il ce qui est censé se produire, si par exemple le système de conformité nécessite une action ? En règle générale, ce sont les systèmes périphériques qui doivent s'adapter aux indications du système principal. Donc pourquoi les banques s’encombreraient-elles d'un nouveau défi de transfert de paiements, surtout après avoir probablement abandonné un monolithe dans leur système central ? La solution est de doter chaque moteur de workflow intégré de son propre script, ce qui permet une connexion aisée et efficace du fournisseur (par exemple PPI) aux autres systèmes.
Le mot « Hub » dans TRAVIC-Payment Hub est donc dans le même temps un nom de produit et un service.
Développement de logiciel à l'inverse
Techniquement, nous nous penchons particulièrement sur ce qui autrement deviendrait une « monnaie » à l'extérieur. Le langage de script implémenté permet à une institution financière d'intégrer ses propres fonctionnalités métier dans TRAVIC-Payment Hub, sans devoir modifier le code source du logiciel. En raison de la séparation de la technique et de la fonctionnalité métier, une partie essentielle du développement du logiciel est ainsi transférée du fournisseur à l'utilisateur. De cette façon, les mises à jour sont toujours supportées, même si TRAVIC-Payment Hub doit gérer un réseau complexe de systèmes périphériques. De plus, les départements informatiques ne seront pas tentés de modifier le code du système de traitement des paiements principal et ne risqueront donc pas créer des problèmes en cascade.
Dans la pratique, TRAVIC-Payment Hub reçoit les différents statuts des systèmes connectés. Le langage de script est utilisé en interne par les développeurs du département informatique ou le prestataire intégrateur, pour définir la manière de traiter les paiements selon leurs différents statuts. Dès que la définition du workflow est terminée, le système compile le code pour que TRAVIC-Payment Hub s’exécute. Des tâches créées par le moteur de workflow sont traitées par un moteur de tâches interne. Ci-dessous un exemple simple sur la manière dont le langage script utilisé dans TRAVIC-Payment Hub de PPI traite les OUR Charges, c'est-à-dire comment TRAVIC-Payment Hub vérifie si les frais d'un paiement sont intégrés dans le paiement et s'ils peuvent être retenus ou si une demande de paiement doit être créée pour encaisser les frais.
Status CHECKINBOUNDCHRGS {
if payment is inbound and (payment is ourCharges) then {
if payment is ourChargesReceived then {
just set status VALIDATERECEIVCHGS and leave step
}
if payment is correspondentChargeExpected then {
if payment is debitAuthorized then {
just set status CREATEADVICEOFCHGS and leave step
}
just set status CREATECHARGEREQ and leave step
}
}
just set status DONE and leave step
}
Introduire TRAVIC-Payment Hub
Avec la gamme de produits TRAVIC, PPI couvre le processus entier de paiement d'une institution financière, depuis la réception du paiement jusqu'à sa compensation en passant par les activités interbancaires. TRAVIC-Payment Hub représente le traitement noyau des transactions financières. Notre solution fonctionne en tant que banque de client et banque de compensation – même en fonctionnement parallèle – et elle offre également une fonctionnalité pour paiements instantanés. En plus, la solution permet autant l’exploitation locale que l’externalisation du produit de haute disponibilité logicielle, en partenariat avec nos partenaires infrastructurels.
Auteur : Thomas Riedel
Plus d'informations :
- Utiliser un logiciel standard comme solution individuelle ? Télécharger l'article de Thomas Riedel et de Markus Seeliger avec l'aimable autorisation d'IT-Finanzmagazin (allemand)
- TRAVIC-Payment Hub pour les transactions financières en temps réel (paiements instantanés)
- TRAVIC-Payment Hub pour les paiements individuels
0 commentaires:
Enregistrer un commentaire