IT & Bank luxembourg

Type d’article bank 50%  IT 50%

Pour suivre à la micro seconde les évolutions des marchés, de plus en plus d'organisme laissent à des logiciels la décision de passer des ordres en bourses. C'est ce qu'on appelle l'automatic trading. Si un ordinateur peut être le pilote automatique d'un avion pourquoi ne pourrait-il pas prendre des décisions d'investissement ?

Que ce soit un être humain qui passe un ordre ou une machine, le résultat est le même et l'organisme émetteur est engagé. Un bug qui achèterait n'importe quoi serait une sorte de Kirviel qui pourrait passer des centaines d'ordre par seconde. On imagine les dégâts...

Heureusement, les informaticiens et les banquiers sont des gens sérieux et les logiciels de trading automatique sont conçus, testés et exploités avec la plus grande rigueur. Enfin presque...

Selon un article du Financial Times (http://www.ft.com/cms/s/0/84950872-09e5-11df-8b23-00144feabdc0.html?nclick_check=1), des bugs ont été constatés par différentes bourses. A la manière des pirates informatiques qui font tomber des serveurs en leur envoyant des milliers de requête, ces bugs auraient noyés les bourses sous des montagnes d'ordre erroné. La seule conséquence aurait été de perturber le fonctionement des bourses.

A quand une affaire à la Kirviel avec une baie de serveur informatique dans le box des accusés?

Gwenael Oliot

Type d’article: Bank 50%  IT 50%

I hope this document helps IT people and fund people understand each other building the best solution for fund services. Comments are welcome in this blog or by mail at oliotg@yahoo.fr

Type d’article : Bank 50%  IT 50%

Gwenael Oliot

Type d'article: Bank 100%  IT 0% 

La circulaire CSSF 02/77 protége les investisseurs OPC des erreurs de calcul de VNI et des dépassements de limite d’investissement.

Les OPC ne sont pas des produits financiers tout à fait comme les autres :

• La plupart des produits financiers s’échangent sur le principe du marché, un acheteur et un vendeur se mettent d’accord sur un prix. Pour les OPC, les acheteurs et les vendeurs s’adressent au fond pour obtenir un prix qui résulte d’un calcul comptable (la VNI). Que se passe-t-il si le comptable s’est trompé dans son calcul ?
• Les OPC sont des produits diversifiés. Cette diversification est régie par des règles définies par la loi et dans les prospectus. Que se passe-t-il quand un fond ne respecte pas ces limites ?

La CSSF a répondu à ces deux questions dans la circulaire 02/77.

Quand une erreur de calcul de VNI est identifiée, l’administration centrale d’un fond doit se poser la question suivante: Est-ce que cette erreur est significative (seuil de matérialité) ? Si oui il faut :

1. Informer le promoteur du fond, le dépositaire du fond, et la CSSF.
2. Déterminer l’impact de l’erreur.
3. Réparer les préjudices.
4. Faire intervenir le réviseur du fond pour valider la procédure d’indemnisation.
5. Communiquer aux investisseurs à indemniser.

Dans tous les cas les frais occasionnés par les opérations de redressement sont à la charge de l’administration centrale ou du promoteur. Plus l’erreur est détectée tardivement, plus le nombre rachat/souscription passé est élevé, et plus le redressement est complexe et coûteux…

Pour un franchissement de limite d’investissement le processus est sensiblement le même sauf que le notion de seuil de matérialité n’est pas applicable et qu’il faut lancer la procédure au moindre dépassement.

Cette procédure n’est pas théorique, elle est appliquée régulièrement au Luxembourg. En 2008, 714 erreurs de VNI et 1519 dépassement de limite d’investissement ont été signalés à la CSSF. Ces chiffres peuvent paraître importants mais cela ne représente environ qu'une erreur pour pour mille calcul de VNI.

Gwenael Oliot

Pour en savoir plus

• La circulaire CSSF 02/77: http://www.cssf.lu/uploads/media/cssf02_77.pdf
• Les erreurs de VNI en 2008 http://www.cssf.lu/uploads/media/RA2008_chap02.pdf page 94.

Type d'article: Bank 50%  IT 50%

L'Institut de Formation Bancaire Luxembourg (IFBL) propose des programmes de certification professionnelle pour tous les métiers de la banque. L'offre de certification est particulièrement bien fournie pour le secteur des fonds. Il y a une certification pour tous les métiers : Agent de transfert OPC, Comptable OPC, Agent banque dépositaire OPC, juriste OPC. Seuls les informaticiens ont été oubliés...

Aujourd'hui l'informatique est la colonne vertébrale de l'organisation des OPC. De plus en plus de règles métiers sont dans les systèmes IT à tel point que certaines activités traditionnelles sont vidées de leur substance. Combien y a-t-il de comptable fonds qui saisissent des transactions dans le système IT sans savoir vraiment sur quels comptes vont être passées les écritures ?

Pour les informaticiens OPC comprendre une exigence métier OPC et la première étape pour concevoir une solution IT OPC. Pour cela il faut être informaticien ET agent métier OPC. C'est là que l'IFBL pourrait apporter son savoir faire en formant les informaticiens.

Qu'est-ce que pourrait être le parcours de certification « Informaticien OPC » ?

D'abords comme pour toutes les autres certifications métiers OPC on pourrait imaginer devoir subir le parcours de base OPC. Ce parcours de base présente les produits financiers les plus rependus ainsi qu'une vision d'ensemble du métier des fonds.

Ensuite il faudrait ajouter des cours métiers complémentaires qui existent déjà dans l'offre IFBL : Un M1 comptabilité, un M1 agent de transfert, un M1 agent banque dépositaire. Ainsi l'informaticien aurait une vision d'ensemble des opérations d'un fond.

Enfin il faudrait concevoir et mettre en place de nouveaux modules de formation propre aux métiers informatiques. On peut imaginer :

• M1 : Connaitre l'urbanisme des systèmes IT OPC. L'objectif serait de connaître les grands blocs applicatifs présent dans un système informatique OPC : le signalétique valeur, le référenciel fonds, les systèmes comptables, TA, Custody ainsi que les flux de données échangés entre ces blocs.
• M1 : Connaitre la messagerie SWIFT pour les OPC. L'objectif est de connaitre les infrastructures techniques SWIFT et les principaux messages SWIFT et normes ISO15022, ISO20022.
• M1 : Connaitre les solutions d'échanges IT avec les fournisseurs de données de marché. Connaitre les infrastructures techniques et protocole d'échanges avec les principaux market data provider : Bloomberg, Telekurs etc...
  

Le parcours de certification ne devrait pas contenir de cours trop techniques lié à tel ou tel langage de programmation ou tel ou tel système d'exploitation. Il serait également hors de propos de faire de la publicité pour tel ou tel progiciel bancaire.

Y aurait-t-il des étudiants intéressés par des formations OPC IT de l'IFBL ?

Mon expérience personnelle montre que le marché n'est pas nul. J'ai suivi plusieurs formations IFBL et il m'est arrivé de n'être pas le seul informaticien à venir apprendre le métier de banquier. Il est également possible que l'offre stimule la demande et que la création d'une certification IT draine de nouveaux étudiants. Il serait souhaitable de faire un sondage auprès des membres de l'ABBL pour valider l'opportunité de cours IFBL IT. Je suis convaincu que des informaticiens formés aux métiers des OPC seraient un atout pour la place financière Luxembourgeoise.

Si l'IFBL trouve mon idée intéressante, je suis à sa disposition pour l'aider à la mettre en place.

Gwenael Oliot

Type d’article : Bank 100%  IT 0%

Un article paru sur Reuters (à lire ici) parle d’un boom des hedge funds au Luxembourg.

Avec la chute de Lehman et de Madoff même les investisseurs les plus ouverts aux risques ont été des échaudés. Le cadre législatif du Luxembourg qui est plus rigoureux que celui des places off shore a de quoi rassurer.

Les gestionnaires de hedge funds sont de plus en plus séduits par le grand duché. Les nouveaux SIF autorisent la souplesse de gestion attendue dans un cadre prudentiel qui rassure. La fermeté de la CSSF vis-à-vis d’UBS la banque dépositaire du fonds Luxalpha (à lire Madoff / Luxalpha: CSSF vs UBS) est une démonstration de la solidité du système. Les suites de cette affaire sont suivies par nombre d’investisseurs comme un test grandeur nature.

Selon l’ALFI, le boom ne se fait pas encore ressentir en terme de volume d’actif sous gestion au Luxembourg, mais le nombre de hedge funds est en nette croissance.

On ne peut que souhaiter que ce mouvement se confirme!     

Gwenael Oliot

 type de sujet: 10%IT 90%Banque

Quelles sont les compétences recherchées dans le secteur bancaire au Luxembourg ?

Pour répondre à cette question voici une étude basée sur le site de recrutement jobs.lu.

• On se connecte à http://fr.jobs.lu/ version française.
• Dans le champ type d’emploi on sélectionne « Banque / Assurances ».
• Dans le champ Zone géographique on sélectionne « Luxembourg ».
• Dans le champ mots clé on saisie « un mot clé ».
• On clique sur rechercher.
• On compte le nombre de résultat.

• Mot clé « domaine métier » :

1. Accounting :       24 (177) chiffre au 10/11/2009 (chiffre au 25/07/2008)
2. Risk :                19 (74)  
3. Compliance :      18 (53)
4. Transfert:           13 (9)
5. Retail /détail :    15 (5)
6. Custody :           2 (56)

• Mot clé « progiciel bancaire » 

1. Multifonds :        2 (23)
2. Olympic :           0 (15)
3. T24 :                 0 (0)
4. Triple :              0 (0)

• Mot clé « fonction »

1. Manager :          38 (150)
2. Analyste :          7 (64)
3. Projet        :       3 (3)

• Mot clé « technologie IT »

1. Oracle :             3 (6)
2. Java :                1 (4)
3. Cobol :               0 (0)
4. .NET :                0 (0)

• Mot clé « expérience »

1. Senior :             27 (106)
2. Junior :              6 (32)

 Je vous laisse tirer vos conclusions.

Gwenael Oliot

Etude au 25/07/2008 http://oliotg.blog.lu/archives/553/20080726

Type d'article: Bank 100%  IT 0% 

Target2 Securities va offrir une opportunité de simplification du réseau de correspondant des banques dépositaires Luxembourgeoises.

Une banque doit avoir un sous dépositaire dans chaque pays où investi ses clients ou faire appel à un ICSD (Clearstream ou Euroclear) là où elle n’a pas de réseau. Le schéma ci-dessous représente le cas d’école d’une banque dépositaire présente dans le monde entier et qui ne ferait pas appel à un ICSD.

Après T2S cette banque va pouvoir simplifier son réseau en supprimant ses sous dépositaires dans les pays dont les CSD participent à T2S.

Cette banque pourra choisir d’accéder à T2S soit directement soit via Clearstream qui est le CSD Luxembourgeois. Si elle choisit l’accès direct, elle devra adopter le format de message SWIFT ISO20022 qui est le seul supporté par T2S. Si elle choisit l’accès via le CSD elle pourra utiliser tous les formats supportés par Clearstream.

D’autres options non représentés sur le schéma sont également possibles. Par exemple, si cette banque fait partie d’un groupe international, ce groupe peut choisir d’accéder à T2S via un autre CSD que le CSD Luxembourgeois.

On peut également noter que le réseau de correspondant cash sera lui aussi simplifié. Une seule banque centrale nationale pourra jouer le rôle du réseau dans les pays du périmètre de T2S.

Gwenael Oliot

Type d'article: Bank 100%  IT 0%

Un des objectifs du cadre légal des OPC est de protéger les investisseurs par des règles de diversification. Ces règles complexes sont définies dans plusieurs textes de loi et circulaires CSSF.

L’objet de cet article est de donner une vision d’ensemble de ces règles. Il ne s’agit ici pas d’être exhaustif et le lecteur est invité à consulter directement les textes publiés au Journal Officiel du Grand-Duché de Luxembourg qui seuls font foi.

Gwenael Oliot

Le texte des lois et circulaires est disponible ici: http://www.cssf.lu/index.php?id=7

Type d'article: Bank 100%  IT 0%

La session d'information T2S du 7 octobre 2009 s'est déroulée en partenariat avec l'ABBL dans les locaux de la BCEE à Luxembourg. Environ 150 personnes sont venues assister à l'événement des quatre coins de l'Europe. Les débats étaient présidés par Marc Bayle directeur du programme T2S de la BCE.

La journée s'est déroulée en quatre temps :

1. Un point sur l'avancement du projet.
2. Une discussion sur l'estimation du volume de transaction dans T2S.
3. Une discussion sur l'opportunité de doter T2S de fonctionnalités complémentaires en termes de gestion de liquidité.
4. Une discussion sur les apports de T2S pour l'industrie des fonds.

Les parties qui m'ont le plus intéressé ont été les deux dernières.

Un des grands apports de T2S est de pouvoir settler les transactions de titre européen en un lieu unique, en monnaie de banque centrale. Ceci permet de concentrer dans un seul compte cash les liquidités nécessaires aux achats de titres qu'il fallait par le passé éparpiller chez plusieurs correspondants commerciaux. Avec T2S, le montant de liquidité nécessaire sera plus faible et déposé chez un tiers plus fiable.

Une fonctionnalité est nécessaire pour que ces avantages soit réellement exploités : c'est une gestion performante du collatéral. Pour que la liquidation des transactions soit efficace, il est nécessaire de faire des prêts aux acheteurs en manque de liquidité. Il est indispensable que ses prêts soient limités et couverts par du bon collatéral.

Les exigences métiers actuelles (URD) de T2S prévoient déjà une gestion du collatéral. L'objet du débat était l'opportunité d'améliorer cette gestion, en la rendant plus automatique et plus en ligne avec le modèle légal de T2S. La majorité des intervenants étaient favorables à ce perfectionnement. En l'absence de telles fonctionnalités il est possible que de nombreux acteurs ne puissent accéder à T2S qu'à travers un tiers gestionnaire de collatéral.

Le débat sur l'apport de T2S au monde des fonds a également été intéressant. Un fonds a deux faces, Asset side, c'est un investisseur qui gère un portefeuille d'actifs ; Liability side c'est un produit financier dans lequel on peut investir.

Asset side, les fonds bénéficieront des baisses de coût de liquidation promises par T2S comme tous les autres investisseurs. Liability side, la question est plus ouverte. Les fonds sont-ils des actifs liquidables comme les actions classiques ?

Le monde des fonds est différent de celui des actions. Les actions classiques sont essentiellement échangées sur le marché secondaire, les fonds sont échangés principalement sur le marché primaire. Les actions sont tradables aussi longtemps que la bourse est ouverte, les fonds ne sont tradables qu’à des instants particuliers (cut off de VNI). La commercialisation des fonds mobilise un réseau de distributeur qu’il faut rémunérer.

Le monde des fonds n’est pas uniforme. Certains marchés sont basés sur le modèle « agent de transfert » d’autres sur le modèle « CSD ». Certains sont domestiques, d’autres sont internationales.

On le voit, les fonds ne sont pas des actifs comme les obligations ou les actions classiques pour lesquels T2S a été conçu. Modifier T2S pour qu’il s’adapte aux fonds ne serait-il pas trop lourd ? Comment être en ligne avec toutes les spécificités des OPC ?

Marc Bayle a terminé par une note d’optimisme, T2S a déjà su surmonter tant de particularisme...

Pourtant beaucoup de fonds européens sont dénominés en devises étrangères hors du périmètre de T2S. Il est clair qu’il est plus important pour l’industrie des fonds de rester ouverte aux investisseurs non européens que de faire de petites économies sur les coûts de settlement.

A suivre…

Gwenael Oliot

Pour avoir les supports de la présentation, cliquez ici

Type d'article: Bank 50%  IT 50%

Enfin je me permets d'ajouter une référence française vers l'excellent site du CIGREF http://www.cigref.fr/

Bonne lecture,
 
Gwenaël Oliot

Type d'article: Bank 100%  IT 0%

La règle du jeu des fonds va changer en Europe et donc au Luxembourg. Voici un article qui présente l’essentiel des évolutions :

http://investments.lawyers.com/blogs/archives/381-Luxembourg-Investment-Funds-From-UCITS-III-to-UCITS-IV.html

Bonne lecture, 

Gwenaël Oliot

Type d’article: Bank 0%  IT:100%

Rond comme un ballon, jaune comme un citron, c’est Pac Man. Gentil petit bonhomme poursuivit par des fantômes, c’est Pac Man. Cela vous dit quelque chose ? Eh bien à moi oui… Il s’agit d’un jeu vidéo des années 1980. Une petite boule jaune pilotée par le joueur est poursuivie par des fantômes dans un labyrinthe et doit manger des pilules sans jamais être rattrapé.

C’est en 1987, quand j’étais en seconde, que j’ai programmé mon premier Pac Man. A cette époque j’avais un ordinateur Amstrad CPC 464. Cette superbe machine était équipée d’un écran 256 couleurs, d’un lecteur de cassette (les disques dures et les cartes flash n’existaient pas, et les lecteurs de disquette étaient trop chers) et de 64 ko de mémoire vive. Pour moi le grand atout de l’Amstrad face à son concurrent le Comodore était la simplicité de son langage de programmation.

J’ai passé plusieurs vacances scolaires à programmer mon Pac Man. Un des plus grand problème auquel j’ai dû faire face était la nécessité de faire bouger le Pac Man en même temps que le fantôme. Je bien dit « Le » fantôme car mon Pac Man n’avait qu’un seul fantôme mais doté du pouvoir de traverser les murs du labyrinthe. Ce pouvoir présente deux avantages. Le premier est que tous les vrais fantômes traversent les murs (c’est bien connu). Le second est que l’algorithme de poursuite du Pac Man est beaucoup plus simple, il suffit de diminuer la distance entre le fantôme et sa proie sans se soucier des murs… Le programme final comptait plusieurs milliers de ligne de Basic.  

J’ai codé mon deuxième Pac Man en 1994. Fraîchement diplômé de mon école d’ingénieur j’étais à la recherche d’un premier emploi. Lors d’un entretien d'embauche, Nat Systèmes, l’éditeur du logiciel de développement NSDK m’avait donné pour chalenge de réaliser en une semaine un programme quelconque. Contrairement aux autres candidats qui avaient choisis des programmes très sérieux de gestion, j’ai choisi de coder une nouvelle version de mon Pac Man sur PC avec NSDK. Le contrat a été rempli, je me souviens que le recruteur jouait avec enthousiasme avec mon jeu. C’est donc Pac Man qui m’a permis de décrocher mon premier job. Plus tard j’ai utilisé les possibilités de NSDK pour faire tourner mon Pac Man sur Macintosh.

J’ai codé mon troisième Pac Man en Java en 1999. Il s’agissait d’une applet que j’ai programmé en un week end. Tout cela était orienté objet, quelques classes et quelques centaines de ligne de Java ont suffit.

A quand la quatrième version de Pac Man ? En quelle technologie ? Le dernier langage que j’ai exploré en 2008 est le Flex, mais il est trop proche de Java pour me donner envie de créer un quatrième Pac Man… Je suis cependant certain que cela me reprendra. J’aime trop la programmation pour que cela s’arrête. L’inspiration reviendra tôt ou tard…

Gwenael Oliot,

Type d’article: Bank 100%  IT 0%

Target2 Securities est en cours d’implémentation (Cf T2S pour les nuls). Il est possible de connaître assez précisément ce que va être cette plateforme en lisant le document d’exigence utilisateur qui est téléchargeable gratuitement sur le site de la Banque Centrale Européenne.

Ce document de 863 pages (en anglais) est le cahier des charges que devra remplir T2S. Se lancer dans l’analyse d’un tel pavé n’est pas un petit travail. Prendre connaissance des 20 principes qui gouvernent T2S est un bon point de départ.

Voici ces principes :

1. L’Eurosysteme sera en charge de développer et d’exploiter T2S en assumant sa propriété pleine et entière.
2. T2S sera basé sur la plateforme Target2, et fournira le même niveau de disponibilité de résilience et de sécurité que Target2.
3. T2S ne sera pas impliqué dans le paramétrage et l’exploitation des Dépositaires Titre Centraux (CSD), mais servira uniquement de plateforme technique de settlement pour les CSD.
4. La gestion des comptes utilisateurs de chaque CSD restera légalement attribuée à chaque CSD.
5. Le service de settlement T2S permettra aux CSD d’offrir de manière harmonisée à leurs participants un niveau settlement équivalent en terme de fonctionnalité et de couverture.
6. Les positions titres devront être changées uniquement dans T2S.
7. Certains CSD participants à T2S devront être désignés sous la directive Settlement Finality (SFD) dans leur juridiction respective.
8. T2S fera son settlement uniquement sur des positions cash en banque centrale.
9. L’objectif premier de T2S sera le settlement en Euro
10. Techniquement, il devra être possible de paramétrer d’autres devises que l’Euro.
11. T2S devra permettre à certains usagers d’être connecté directement à sa plateforme.
12. La participation des CSD à T2S ne sera pas obligatoire.
13. Tout CSD dont le settlement fonctionne en Euro sur des positions cash de banque centrale sera éligible pour participer à T2S.
14. Tous les CSD connecté à T2S bénéficieront des mêmes conditions.
15. Les CSD connectés à T2S le seront via des relations contractuelles harmonisées.
16. Tous les CSD connectés à T2S devront avoir un calendrier des jours ouvrables harmonisé et des horaires d’ouverture et de fermeture harmonisés.
17. Les règles et procédures de settlement devront être communes à tous les participants
18. T2S fonctionnera de la manière économe et n’aura pas pour objectif de faire du profit.
19. Les services T2S devront être compatibles avec les principes du code de conduite Européen pour le Clearing et Settlement
20. T2S devra offrir aux CSD participants un support qui respecte les cadres légaux et de supervision.

Gwenael Oliot

Pour en savoir plus: http://www.ecb.eu/paym/t2s/pdf/T2S_URD_V4.1_Final_March2009.pdf

Type d’article : Bank 0%  IT 100%

L’activité du test fonctionnel est à la frontière entre le métier et L’IT, incluse entre les tests unitaires du programmeur et les tests métiers de la maîtrise d’ouvrage.

Les tests unitaires sont des tests « boites blanches » d’un module d’application, les tests fonctionnels sont des tests « boites noires » d’une application, les tests métiers sont des tests « boites noires » d’un processus et donc de plusieurs applications.

Le point d’entrée du travail du testeur fonctionnel est la documentation des exigences fonctionnelles. La première tâche consiste à rédiger les cas de test. Il faut recenser les exigences fonctionnelles et pour chacune  prévoir le ou les cas de tests qui permettent de garantir la conformité du logiciel. Il s’agit d’être astucieux en créant les cas les plus simples possibles tout en étant exhaustif.

Une fois les cas définis, il s’agit de les enchaîner sous forme de scénario. L’ordre d’exécution ne doit pas être laissé au hasard. Une bonne pratique consiste à estimer le niveau de risque des cas de test et de commencer quand c’est possible par les plus risqués. Ainsi on peut augmenter la probabilité que les bugs les plus graves soient trouvés en début de campagne de test, ce qui laissera plus de temps pour les corriger. Il est également utile d’estimer la complexité des cas de test car cela permet de suivre plus finement l’avancement des campagnes de test.

L’étape suivante est la préparation des tests. Pour chaque cas il s’agit de préparer les données de test. Deux solutions sont possibles, soit identifier des données existantes soit construire des données sur mesure. La première approche qui est la plus simple est conseillée. Malheureusement il arrive que les données n’existent pas, par exemple pour un tout nouveau système ou quand il s’agit de tester un cas très particulier. La préparation des tests inclut la réalisation d’outillage de test. Les tests fonctionnels se limitant à une seule application il est souvent nécessaire de simuler la présence d’application amont ou aval. Pour réaliser ces outils le testeur fonctionnel doit le plus souvent faire appel à un programmeur.

L’étape suivante est l’exécution des tests. Chaque cas est exécuté si possible dans l’ordre défini par les scénarios avec les données et les outils préparés aux étapes précédentes. Quand un résultat n’est pas conforme aux exigences, le testeur en informe l’équipe de développement qui confirme le bug ou remet en cause la pertinence du cas de test. Le testeur doit donner les informations les plus précises possibles au programmeur pour l’aider dans son diagnostique. S’il s’agit d’un bug, une nouvelle version du programme doit être livrée et testée. Un processus clair de suivi des bugs et corrections est indispensable. Régulièrement le testeur fonctionnel rend compte de l’avancement de ses tests. Le nombre de cas de test exécuté pondéré par leur complexité est un bon indicateur d’avancement.

Un bon testeur fonctionnel doit être rigoureux pour ne rien laisser passer, astucieux pour trouver les cas de test les plus simples, patient quand rien ne marche, diplomate pour signaler les bugs sans agresser les programmeurs et disponible quand il s’agit de donner un coup de collier à quelques jours de la mise en production. Une bonne connaissance de l’application à tester est un grand atout et du bon sens est indispensable.

Quelques conseils pour un testeur fonctionnel :

• Avant toute chose, il faut réclamer des documents d’exigence fonctionnelle (ou en rédiger).
• Ne pas négliger la phase de préparation pour utiliser la phase d’exécution des tests à tester réellement (La phase de préparation n'est pas sur le chemin critique du projet alors que l'exécution oui).
• 33% de l’effort sur la rédaction des cas de test, 33% sur la préparation, 33% sur l’exécution est un bon ordre de grandeur pour la repartission de la charge.
• Lors de la planification d’une campagne il est sage de prévoir une durée et des ressources pour exécuter plusieurs fois tous les cas de test. En effet, certains bugs peuvent bloquer l’exécution des tests pendant de longue période, ou la livraison successive de corrections nécessiter d’exécuter plusieurs fois les même cas.
• Soyez courtois avec le programmeur même si rien ne marche.
• Soyez inflexible sur le respect des exigences fonctionnelles, c’est votre raison d’être. Si une exigence n’est pas respectable alors il faut négocier son amendement mais ne pas cacher une non-conformité.
• Gardez autant que possible des preuves de vos tests (par exemple des print screen), car il se trouvera toujours quelqu’un pour vous reprocher de ne pas les avoir exécuté correctement.

Gwenaël Oliot

Article sur les tests unitaires: http://oliotg.blog.lu/post/553/2619

Type d'article: IT 50%  Bank 50% 

SWIFT est-il un sujet pour informaticien ou pour banquier?

SWIFT est une coopérative de banque, offrant des services et interfaces informatiques sécurisées entre plus de 7500 institutions financières réparties sur 200 pays. Les interfaces informatiques sont affaires d’informaticien mais la communication interbancaire est une affaire de banquier.

Voici un exemple de message SWIFT ISO15022 MT540 :

:16R:GENL

:20C::SEME//MYREF001

:23G:NEWM

:16S:GENL

:16R:TRADDET

:98A::SETT//20080623

:98A::TRAD//20080620

:35B:ISIN CH0001234567

:16S:TRADDET

:16R:FIAC

:36B::SETT//UNIT/521,

:97A::SAFE//54321

:16S:FIAC

:16R:SETDET

:22F::SETR//TRAD

:16R:SETPRTY

:95R::DEAG/CEDE/12345

:16S:SETPRTY

:16R:SETPRTY

:95P::PSET//CEDELULL

:16S:SETPRTY

:16S:SETDET

La chose est maintenant entendue, il faut forcement être informaticien pour comprendre un truc pareil !

Après traduction en français, le message ci-dessus est une instruction de réception de titre en free of payment. La référence du message est MYREF001, la date de la transaction est le 20/06/2008, la date souhaitée de settlement est le 23/06/2008. La réception porte sur 521 titres ISIN CH0001234567 à livrer sur le compte numéro 54321. Le settlement a lieu en Clearstream et les titres proviennent du compte numéro 12345 : Il n’y a qu’un agent back office d’une banque qui peut comprendre ce jargon !

Il faut donc être informaticien et banquier pour comprendre un message SWIFT.

L’exemple ci-dessus est tiré d’un contexte back office titre, mais SWIFT a une couverture beaucoup plus large. Elle traite également en amont de l’initiation et de la confirmation d’ordre et en aval de custody ou de gestion de collatéral. La gestion cash a également ses propres messages…

La maîtrise de SWIFT passe par la connaissance d’un socle technique commun auquel il faut ajouter la connaissance de métiers bancaires particuliers. Dans le socle technique on trouve la connectivité (le réseau, les passerelles, l’adressage, etc…) et la grammaire des messages. D’un point de vue métier, en continuant dans l’exemple du back office titre, il s’agit de connaître en détail le cycle de vie d’une instruction de son émission au settlement en passant par le matching et éventuellement par sa cancellation.

En synthèse, SWIFT est un sujet qui intéresse le banquier et l’informaticien en permettant l’implémentation de processus métiers interbancaires en STP (Straight Through Processing).

Gwenael Oliot

Type d'article IT:100%  Bank:0%

MEGA, la suite logicielle de modélisation des systèmes d’information s’est mise au goût du jour en étant certifié TOGAF par l’Open Group.

Le saut n’a pas dû être trop grand, puisque MEGA offrait déjà toutes les fonctionnalités nécessaires : MEGA est un outil de modélisation puissant construit autour d’un référentiel d’entreprise.

Toutes les strates d’un systèmes d’information peuvent être représentés dans MEGA : processus métiers, couche fonctionnelle, strate applicative, strate technique, modèle de données etc… Le référentiel MEGA, assure une intégrité entre les différents modèles et une gestion multi utilisateur des mises à jours. C’est aussi un outils de communication puisque tous les diagrammes peuvent être publiés dans un intranet au format HTML.

Tous les ingrédients étaient donc déjà présents pour que MEGA soit reconnu comme étant un outil support de TOGAF. Ceci a été chose faite quand MEGA a publié sa nouvelle fonctionnalité appelée « MEGA EA Accelerator for TOGAF »

Les nombreuses sociétés déjà utilisatrices de MEGA sont en bonnes positions pour une adoption de TOGAF et celle encore non outillées peuvent voire en MEGA un référentiel d’architecture éprouvée.

Méthode de pointe + Suite logiciel éprouvée = Une solution pour l’architecte d’entreprise.

Gwenael Oliot

Type d’article : Bank 80%  IT 20%

Un article sur le passage à l’euro! Fin 2008! Sept ans de retard ce n’est pas un peu trop? Eh bien non le passage à l’Euro est encore d’actualité pour les cinq millions et demi de Slovaque qui abandonnent leurs Couronnes au profit de l’Euro.

Hors de Slovaquie, ce passage a un impact sur les systèmes d’informations de toutes les banques dépositaires qui ont des positions en Couronne Slovaque (SKK). Pour un système bancaire, un passage à l’Euro consiste principalement en deux opérations : la conversion des positions cash en euro et la redenomination des titres en Euro.

Le taux de conversion de la Couronne Slovaque en Euro est de 1 euro = 30,1260 SKK. La conversion consiste à diviser les positions cash en SKK par 30,1260 pour les transformer en Euro.

La redenomination est elle aussi une division mais cela est un peu plus subtile. La valeur nominale d’une obligation ou le montant de capital social associé à une action sont des attributs importants de ces titres exprimées en devise. La redenomination consiste à changer la définition des titres pour transformer ces montants exprimés en SKK en Euro. La redénomination n’est pas obligatoire, il s’agit d’un choix de l’émetteur du titre. Ainsi l’émetteur d’une obligation Slovaque peut choisir de garder le libellé de son émission en Couronne. Cela ne change pas grand-chose puisque redenominé ou pas plus aucune transaction ne pourra se faire en SKK après le 01/01/2009. Ainsi pour acheter un titre libellé en SKK il faudra utiliser des Euros ou tout autre monnaie ayant cours.

Dans un passage à l’Euro le timing est important car avant l’heure ce n’est pas l’heure et après l’heure ce n’est plus l’heure. Ainsi une instruction d’achat de titre reçue en SKK en 2008 une seconde avant le cut off du changement d’année doit être traitée même si son dénouement est prévu en janvier 2009. S’il s’agit d’une Receipt Versus Paiement, la partie cash d’une telle instruction doit être convertie en Euro. Cette même instruction reçue une seconde plus tard doit être rejetée car à cet instant la Couronne Slovaque n’a plus cours.

Souhaitons, bon courage aux informaticiens et agents de banque qui travaillent aujourd’hui et demain à cette migration au lieu de fêter la nouvelle année.

Gwenael Oliot

PS : Je vous souhaite tous mes meilleurs voeux pour l’année 2009

Gwenael Oliot, consultant en informatique des fonds.

• Principal
• Archives
• Albums
• Liens
• dashboard

• Management [9]
• IT [24]
• Banque [20]
• Fonds [12]
• Général [2]

• Automatic trading et bugs automatiques.
• IT architecture of a fund service provider
• L’automatisation gagne du terrain dans les fonds luxembourgeois
• Circulaire CSSF 02/77 : les erreurs de VNI et dépassements de limite d’investissement.
• Et si des informaticiens OPC étaient certifiés par l'IFBL ?
• Le boom des hedge funds au Luxembourg
• Top compétence au 10/11/2009
• Target2 Securities (T2S) simplifie les réseaux de sous dépositaire.
• Les restrictions d’investissement des fonds luxembourgeois
• Target2 securities (T2S) au Luxembourg
• Les directeurs informatiques du secteur bancaire Luxembourgeois.
• De UCITS III à UCITS IV
• Pac Man Story
• Les 20 principes de Target2 securities (T2S)
• Le test fonctionnel pour les nuls.

• mehdi benammar: le développer en haskell (http://www.haskell.org/), langage fonctionnel, "sans boucle sans...
• nvitale: Si vous comprenez l'anglais, vous serez potentiellement intéressé par la vidéo ici:...
• Nicolas: Bon, impossible de poster un commentaire de plus de 20 caractères, doc je répond là : ...
• oliotg: paperJam Business Club: donne un avis actualisé sur la note de PricewaterhouseCoopers...
• superRIA:Comparer Flex et les applets, c'est comme comparer une lampe à pétrole et une lampe hallogène....
• Laurent U.:Merci pour cet article qui peut contribuer à la pédagogie autour des RIAs au Luxembourg.
• Laurent U.:Simple petit apport par rapport à mon expérience, les développeurs Java maitrisent Flex et...
• Olivier Gourment:Bonne analyse des deux nouveautés de SOA: standards et gouvernance. Le second est souvent...

• Dark pools et bourses classiques. (2644 Times)
• Comparatif AJAX, FLEX et Applet. (1570 Times)
• Migration de la Banque Raiffeisen vers T24 (1174 Times)
• De SWIFT ISO15022 à ISO20022 : un exemple tiré des fonds. (1113 Times)
• Témoignage sur les certifications OPC IFBL/ALFI (1021 Times)
• Introduction to ADOBE Flex technology (836 Times)
• Impact de MIFID sur la fonction de compliance. (828 Times)
• Message SWIFT pour les nuls (818 Times)
• SOA dans l’industrie des fonds : Révolution ou pétard mouillé ? (791 Times)
• Passage à l’Euro (762 Times)