vendredi 19 juillet 2013

Communauté SEPAmail : PPI


Nous continuons notre tour des entreprises de la communauté SEPAmail avec la société PPI France, spécialiste des échanges de données informatiques financières, notamment dans le cadre de l'échange ebics.
J'ai rencontré et interrogé Marc Dutech, directeur général.

Quand a été créé PPI, dans quel contexte ?


PPI France, créée en 2010, est la filiale française de PPI AG, leader européen dans le domaine des transactions financières et des EDI financiers. PPI France propose les produits de la gamme TRAVIC, suite complète et modulaire d’Electronic-Banking dédiée aux Banques, Entreprises, Prestataires pour la dématérialisation de leurs flux financiers. PPI France fournit également des composants permettant aux éditeurs de logiciels d’implémenter rapidement la gestion du protocole EBICS au sein de leurs applications.


Combien PPI comptent de collaborateurs ?


PPI France compte 6 collaborateurs et fait appel fréquemment aux ressources humaines de PPI AG forte d’un effectif de 350 employés. Les collaborateurs de PPI France se consacrent à la localisation de l’offre TRAVIC pour ses marchés (France, Péninsule Ibérique, Pays d’Afrique francophone), à leur commercialisation, à leur déploiement et à leur support de premier niveau.

Quels sont vos principaux produits ?


La suite TRAVIC se compose de plusieurs logiciels :
  • TRAVIC-Corporate : serveur multi-protocolaire utilisé par les Banques et Prestataires pour les échanges télématiques avec leur clientèle Entreprise et avec d’autres institutions financières dans le cadre d’échanges interbancaires,
  • TRAVIC-Link : solution d’automatisation des échanges et des traitements des flux financiers particulièrement bien adapté aux Entreprises ayant des volumétries conséquentes à traiter,
  • TRAVIC-Port : solution permettant de mettre en œuvre rapidement un portail de Coporate-Banking sur Internet,
  • EBICS-Kernel : composant logiciel destiné à être intégré au sein d’application tierces pour la gestion du protocole EBICS toutes versions,
PPI fournit l’assistance au déploiement et à la mise en production de TRAVIC ainsi que son support après-vente. PPI propose également des prestations de conseil métier et IT dans les domaines ayant trait aux échanges de flux financiers.

Quels est le profil de vos clients, quelles sont vos références ?


Les clients de PPI sont des Banques de toute taille (Crédit Mutuel/CIC, Caisses d’Epargne Allemande, Commerzbank, Deutsche Bank, Banque Delubac,…) des Prestataires et Opérateurs (Docapost, Atos Worldline, GAD,EBA Clearing,…), des Entreprises (ADP GSI, AMB Generali,…) et des éditeurs de logiciel (Datalog Finance, CPI Software, Kyriba, Alsyon,…).

Quelles sont vos spécificités ?


 
Dès 2008 PPI a fait le pari qu’EBICS deviendrait un protocole couramment utilisé non seulement en France et en Allemagne mais aussi dans d’autres pays d’Europe et du reste du monde. De même qu’elle a prévu son utilisation à grande échelle non seulement dans le cadre des échanges Banque-Entreprise mais également dans le cadre des échanges interbancaires et B2B.
PPI a donc consacré une part importante de son effort R&D au développement d’applications basées sur le protocole EBICS afin de proposer des applications innovantes, robustes et performantes. A ce jour, plus de 70 employés sont dédiés au développement et au support de ces applications, faisant de PPI un acteur unanimement reconnu pour la qualité de ses logiciels et leur adéquation aux besoins de tous les marchés dans lesquels elle est présente.
Le pari fait en 2008 est en train de se réaliser et PPI y contribue largement, d’une part en proposant des prestations de conseil et une offre produit efficientes et d’autres part en participant activement à la promotion d’EBICS au niveau international.

Quel est votre lien à SEPAmail ?


PPI a proposé ses connaissances et ses produits pour tester la capacité d’EBICS à échanger des flux SEPAmail.
Ces tests, réalisés début 2013, se sont avérés concluants.

Quel est votre implication dans la communauté SEPAmail ?


Outre le fait que PPI continue à proposer ses services pour d’éventuels tests ou expérimentations supplémentaires, PPI entend informer ses clients et son marché de l’adéquation du protocole EBICS et de ses logiciels à l’échange des flux SEPAmail.




lundi 8 juillet 2013

SEPAmail : la portée de l'acquitement

Le protocole de messagerie SEPAmail comprend un acquittement des messages échangés. Cet acquittement est réalisé par le fournisseur de l'accès à SEPAmail (l'adhérent) pour le compte du destinataire dès réception du message.
Cet acquittement est obligatoire dans tous les cas pour tous les fournisseurs d'accès à SEPAmail, quel que soit l'expéditeur et le destinataire, dans les cas où l'acquittement est possible.

Ces règles sont décrites dans la directive d'implémentation de la missive.

Cet acquittement permet à l'expéditeur du message, ainsi qu'à son fournisseur d'accès à SEPAmail d'être assuré :
  • de la bonne réception du message émis (contenu dans une missive nominale), réception, horodatage, validité, authentification des fournisseurs d'accès et de sécurité SEPAmail
  • du routage qui sera réalisé vers le destinataire du message (défini par l'entête de la missive)
  • de la capacité de distribution du message au destinataire
On remarque que la prise en charge des fonctionnalités autour du message ne fait pas partie de la fonction de l'acquittement.


L'acquittement se présente sous la forme d'un statut succès (ACK) ou échec (NAK) avec, facultativement, un code de retour pour expliquer le statut. Ces codes retour sont décrits ici et sont tous valides sauf ceux correspondant au sujet 4, à savoir les codes 541, 248, 249 (ces trois codes ont été utilisés dans le cadre de l'expérimentation mais ils ne correspondent pas à des retours possibles pour une messagerie; ils sont liés à l'application de SEPAmail RUBIS).

Comme pour tout protocole en couche, il est important que la messagerie SEPAmail ne se substitue pas aux couches au dessus et en dessous (en amont et en aval du traitement) pour son action.

Prenons un exemple dans le cadre d'une demande de règlement RUBIS pour bien comprendre la portée de l'acquittement.

Supposons qu'une personne A veuille transmettre à une personne B une demande de règlement.
Les fournisseur d'accès a SEPAMail de A (FasA) et B (FasB) leur proposent le service RUBIS.

Voici trois cas d'usage de réception par FasB de la missive nominale contenant la demande de réglement :
  • cas 1 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest n'étant pas conforme au schéma XML
  • cas 2 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivationRequest conforme au schéma mais pas à la directive d'implémentation RUBIS de ce message
  • cas 3 : l'enveloppe SEPAmail contient une missive nominale avec un message PaymentActivtationRequest conforme au schéma et à la directive d'implémentation RUBIS du message avec une seule demande de paiement en trois fois que FasB ne propose pas à son client B
Le cas 1 est le plus simple à comprendre et l'acquittement SEPAmail permet de traiter ce cas quelque soit le message contenu dans une missive nominale, c'est un acquittement NAK avec un code retour de sujet contenu et de code 581 "XML syntax error, non conforming to schema".
Remarque : on voit par ce retour que SEPAmail permet d'acquitter la présence d'un message conforme (au sens des schéma XML) au sein de la missive, ce qui dépasse en fontionnalité l'accusé de réception postal.

Le cas 2 pourrait être, par exemple, un champ  PaymentMethod à CHQ alors que ce champs, au sein du pain.013 est annoncé dans la directive d'implémentation comme "Mandatory. The only value currently accepted here is "TRF". Note : if the OtherPmtMtd field, in the non-ISO part, is used, this field will be ignored"ou un élément ChargeBearer qui ne serait pas à la valeur "SLEV" comme exigé par l'implémentation de RUBIS.
Ce cas ne relève pas de la messagerie SEPAmail puisque le message PaymentActivationRequest est intègre du point de vue de son schéma.
C'est l'application RUBIS de SEPAmail qui doit (ou peut) répondre. Si FasB pense que c'est une bonne idée dans sa relation avec FasA de boucler le processus, FasB devrait donc préparer un PaymentActivationReport négatif avec une mention de non prise en charge des ces options de la demande de règlement pour non conformité à la norme RUBIS.

Le cas 3 est cas de conformité à la norme SEPAmail et à la norme RUBIS non pris en charge par FasB. FasB est donc peut-être dans l'impossibilité de transmettre le message et prendre en charge la demande fonctionnelle associée à ce message.
Selon les cas de la relation et du contrat que FasB et B ont signé, FasB peut:
  • transmettre le message pour seule prise en compte du signifiant,
  • répondre pour le compte de son client de façon négative en motivant le refus
  • ne rien faire

Dans les cas 2 et 3, la missive nominale a été acquittée normalement (code retour 219) car la missive a bien été reçue conforme et relayée en terme de messagerie.

Certains sont tentés de reporter l'impossibilité fonctionnelle du fournisseur d'accès à SEPAmail de transmettre le message (ce message ne répond pas à la norme RUBIS ou le cas n'est pas traité par le fournisseur d'accès du destinataire) au sein de l'acquittement de la messagerie.
Il ne faut pas céder à cette tentation, au risque de confondre la couche SEPAmail (messagerie) et la couche RUBIS (application de SEPAmail). En faisant cela, on dénature l'acquittement et son intérêt en terme d'accusé réception.

SEPAmail.eu pourrait, à mon sens, pour lever les ambiguités sur ce sujet :
  • préciser des cas d'usage, pour bien expliquer l'interprétation qui doit être faite de la norme autour de l'acquittement
  • séparer la norme de messagerie SEPAmail de chacune des normes des applications utilisant SEPAmail
  • enlever les scories due à l'expérimentation, comme les codes retour d’acquittement de sujet 4
     







mercredi 3 juillet 2013