MAM5- SI 5 - MASTER IMAFA PROJETS 2010 -11

1. Déroulement 2 décembre: choix des sujets mi janvier : soutenance intermédiaire: specs/maquette/prototype 28 février : soutenance MAM5- SI 5 - MASTER IMAFA PROJETS 2010 -11

2. 1 - calcul de la VAR Monte carlo qui intègre les Scenario de Stress Testing.   • La VAR est l’estimation de la perte que peut subir un portefeuille sur une durée (en général de 1 à 10 jours) et avec une certaine probabilité. En général, une institution financière pourra calculer sa VAR quotidienne avec une probabilité de 99%, ce qui indiquera la perte maximale que peut subir le portefeuille en une journée dans 99% des cas. • La VAR repose sur des hypothèses souvent restrictives et peu réalistes, notamment l’hypothèse de distribution normale de rendements des actifs qui constituent le portefeuille. Afin d’avoir une image plus complète des risques du portefeuille, les techniques de stress testing sont en général appliqués en complément de la VAR. Ces techniques permettent de simuler les rendements du portefeuille en situation de crises (crash Octobre 1987, Crise russe, Sub Primes, etc…).  La VAR est de nature statistique et probabiliste, tandis que les calculs de stress testing ne le sont pas. La difficulté pour un trader ou un Risk Manager est de pouvoir intégrer ses deux visions. • L’objectif du projet consiste à mettre en place une solution de calcul de la VAR Monte carlo pour des portefeuilles de crédit ou de taux qui intègrent les scenarios de Stress Testing, afin de donner une dimension statistique aux résultats de Stress testing. Dans un premier temps, le projet va porter sur une familiarisation avec la mise en place d’un moteur de calcul de la VAR Montecarlo sur un portefeuille d’actifs financiers, ainsi que des techniques actuelles de stress testing. Dans un second temps, le projet va porter sur une revue de la littérature existante sur les solutions intégrées VAR/Stress Testing et enfin sur la mise en place d’une des méthodes existantes. • L’intérêt du projet est de se familiariser avec la mise en place de la Var par la méthode Monte Carlo ainsi que des techniques de stress testing.  • Ce projet est recommande pour des élèves très motivés par les techniques modernes de calcul de risques de marchés et de crédit et souhaitant se familiariser avec les concepts de VAR Montecarlo, CVar(Expected Shortfall or Conditionnal VAR),EVT…. • MATERIELS ET LOGICIELS UTILISES : –PExcel, C/C++, VBA, QuantLib, Mathematica, XML • NOMBRE D'ELEVES :  2 eleves – plusieurs binômes possibles

3. 2 - INRIA Mireille Bossy / Nicolas Champagnat • Simulation de carnet d’ordres – aspects mathématiques • contact : • Email: Mireille.Bossy@sophia.inria.fr ; • Nicolas.Champagnat@sophia.inria.fr • 04 92 38 79 82 • Nombre d’étudiants : 2 ou 3 – 1 ou 2 groupes maximum

4. 3 - Développement de pricers sous quantlib • La bibliothèque quantlib fournit des composants financiers open source • Le projet consiste à (re)coder des pricers en C++ • Les étudiants auront en charge la modélisation et le développement de ces modules. • Les modules seront intégrés à Quantlib • Luigi Ballabio présentera le projet le 26 novembre • Nombre d’étudiants : 2/4/6/8 • Coordonnées des encadreurs :   • hugues@unice.fr - + Luigi Ballabio : luigi.ballabio@gmail.com

5. 4 TradeLab, (entreprise en cours  de formation) • Gestion des protocoles de communication (FixML) entre nos serveurs de tests et les puces sur réseau à très haut débits (fibre optique), gestion des protocoles de haut niveau, analyse des débits effectifs, reporting, tableaux de bords, outils de monitoring, codage-décodage, cryptage-décryptage, authentification, non répudiation. Par ailleurs la première équipe procédera également au développement de nos outils de tests et simulation (simulateurs de trading aléatoire) et de monitoring de ces activités de tests automatisés. • Les projets se déroulent hors des locaux de l’entreprise mais sur nos serveurs par l’intermédiaire de clients VPN, si nécessaire, en nos bureaux. • Une rémunération peut être envisagée sous forme de prime sur base de la qualité du travail fourni. • Qualités requises : qualité de développement en C++/Java/.Net/SQL Server, capacité d’analyser et de maitriser els composantes fonctionnelles (trading électronique) et techniques (gestion transactionnelle à très haut débit) • A l’issue du projet, si les prototypes se révèlent satisfaisants , il sera proposé un stage de fin d’étude suivi, le cas échéant d’un emploi à plein temps au sein de la structure. • Nombre d’étudiants : 2 à 3 élèves • Coordonnées des encadreurs  : jean.rene.giraud@am-ic.com

6. 5 TradeLab, (entreprise en cours  de formation) • Conception et développement d’une interface graphique de monitoring de l’activité interne des circuits programmables (analyse des flux, des temps de réaction, des débits), visualisation des carnets d’ordre en temps réel … • Les projets se déroulent hors des locaux de l’entreprise mais sur nos serveurs par l’intermédiaire de clients VPN, si nécessaire, en nos bureaux. Une rémunération peut être envisagé sous forme de prime sur base de la qualité du travail fourni. • Qualités requises : qualité de développement en C++/Java/.Net/SQL Server, capacité d’analyser et de maitriser els composantes fonctionnelles (trading électronique) et techniques (gestion transactionnelle à très haut débit) • A l’issue du projet, si les prototypes se révèlent satisfaisants, il sera proposé un stage de fin d’étude suivi, le cas échéant d’un emploi à plein temps au sein de la structure. • Nombre d’étudiants : 2 à 3élèves • Coordonnées des encadreurs  : jean.rene.giraud@am-ic.com

7. 6 Octopus • Micro crédit – open source • Etablir des critères pour effectuer du credit scoring à partir du projet de l'an dernier • Benchmark des outils – choix d'un outil – développement • Intégrer le module à Octopus • Nombre d’étudiants : 2 à 3élèves • Coordonnées des encadreurs  : • Yoann GUIRIMAND • yoann@octopusnetwork.org

8. Octopus Microfinance Suite Projet « Credit Scoring » - PolytechNice

9. Contexte 1,6 milliards de personnes n’ont pas accès aux services financiers leur permettant de développer leur activité. La microfinance (microcrédit, épargne, assurance) apporte ces services financiers aux plus pauvres, jugés non solvables/rentables par les banques classiques. De 2001 à 2010 le nombre d’IMF (institutions de microfinance) est passé de 1500 à 10000, permettant de toucher 150 millions de clients. (100Md US$, croissance de 30% / an). Or 90% de ces IMF n’ont pas de système d’information, et fonctionnent soit sur du papier, soit avec des tableaux Excel, ce qui impacte fortement leur gestion opérationnelle, leur viabilité, leur transparence et par conséquent leur développement. -> Octopus est un logiciel gratuit et open-source de gestion des IMF. Il s’adresse principalement aux petites et moyennes IMF (de 500 à 50.000 clients) pour les aider à se structurer selon les meilleures pratiques de la microfinance -> Au-delà du logiciel, Octopus est un social-business qui a pour objectif d’accompagner les IMF et de les aider à atteindre leur viabilité opérationnelle. L’accent est mis sur la formation, le transfert de compétences nord-sud et sud-sud, et les services de proximité.

10. L’écosystème d’ Octopus A l’origine du projet, il y a ACTED, ONG internationale présente dans 30 pays, et sa branche OXUS, opérateur de microfinance, principalement en Asie Centrale. En 2006, OXUS recherche un logiciel fiable pour ses opérateurs de microfinance et fait le constat suivant : il existe une trentaine de logiciels sur le marché, mais aucun n’est simple d’utilisation pour des petites et moyennes IMF, et aucun ne fonctionne correctement, en respectant les bonnes pratiques de microfinance. OXUS s’associe avec le groupe OCTO, éditeur de logiciel informatique pour développer Octopus : c’est le début du projet. Le logiciel est développé durant 3 ans. En janvier 2009, une société est créée pour formaliser le projet; cette société est dissoute fin 2009 suite à divers problèmes opérationnels et de viabilité financière. En 2010, Octopus est relancé comme un projet incubé chez OXUS le temps de reprendre son autonomie. Les problèmes de gestion sont résolus, une équipe de développeurs est mise en place au Kirghizstan pour créer 80% de la valeur ajoutée dans les pays du sud, effectuer un transfert de technologie et surtout être au plus près des besoins des IMF utilisatrices. En septembre 2010, l’équipe est constituée de Michael Knaute (directeur d’Octopus), Julien Mahuzier, (coordinateur de l’équipe de 6 développeurs IT, basé au Kirghizstan) et Yoann Guirimand (Business Developer). Le projet est renforcé par l’apport de compétences IT de Naxos, un éditeur de logiciel basé en Belgique

11. Le logiciel Octopus est un système d’information qui gère les fonctions métiers d’une IMF (crédit, épargne) et support (comptabilité). A ce tronc de base en open-source s’ajoutent des modules complémentaires en cours de développement : synchronisation, consolidation, reporting, Business Intelligence... en fonction des besoins des IMF et de leur degré de maturité. L’objectif du projet étant avant tout social (il s’agit de contribuer à la professionnalisation du secteur grâce à un logiciel performant et d’aider les plus petites IMF à se structurer), il est essentiel de concevoir un logiciel souple, adaptable et réactif utilisable par tout type d'IMF. L‘open source s’est naturellement imposé comme le mode de distribution idéal dans cette perspective. Il nous permet de réduire les coûts pour nos clients (pas de licence) et de constituer une communauté d’experts locaux pour apporter un service de proximité aux IMF Grâce au processus de développement basé sur la méthode AGILE, (méthode de développement informatique itérative, permettant une plus grande réactivité ) Octopus est un logiciel efficace, capable de livrer des nouvelles fonctionnalités rapidement tout en conservant sa stabilité et sa simplicité. Cette facette unique sur le marché permet à Octopus d'agréger les meilleures pratiques de Micro Finance découvertes autour du monde par les praticiens sur le terrain. Aujourd’hui, le produit est utilisé par une quinzaine d’IMF dont Octopus assure l’assistance technique, une vingtaine d’IMF indépendantes, et est porté par une communauté « open source » de 400 membres. La dernière version du logiciel est téléchargée environ 300 fois chaque mois. L’objectif est d’atteindre 50 IMF clientes fin 2011 et 100 IMF en 2012.

12. Un social-business model en évolution Un produit open-source : le logiciel de base est gratuit en téléchargement libre sur internet, quel que soit la taille de l’IMF. Des modules complémentaires payants sont disponibles sous licence pour des besoins spécifiques (synchronisation online, Business Intelligence…) Un volet économique : l’équipe Octopus propose des services connexes (audit du SI des IMF, mise en œuvre / migration de leur SI, formation, maintenance sur site ou via hotline, développements spécifiques. La réponse aux appels d’offres des moyennes IMF constitue l’essentielle de son activité Un volet social : pour les IMF n’ayant pas de quoi payer les missions d’implémentation d’Octopus, l’équipe souhaite mettre en place un modèle hybride constitué de bourses de formation, provenant principalement de bailleurs institutionnels. Ce volet est au cœur de la mission d’Octopus : ces petites IMF sont bien souvent celles qui ont le plus d’impact social car elle touchent des clients plus pauvres, ou dans des régions rurales que les grosses IMF n’investiront pas (pas rentables), et qui ont le plus besoin de formation pour se structurer. Un réseau mondial de proximité : le produit ne peut être réellement utilisé que s’il y a des ressources locales pour assurer le support, la formation et l’assistance technique. Pour cela, nous recherchons et formons des experts IT dans les pays où nous intervenons. A chaque nouvelle implémentation d’Octopus, nous nous assurons d’avoir formé un expert IT local pour la maintenance de base. Une fois celui-ci formé, il devient VAR (Value-Added Reseller) et peut démarrer sa propre activité de consultant / commercial Octopus. Nous proposons à nos VAR des cursus réguliers de formation pour rester à la pointe du logiciel, et un programme de certification « octopus university » est en cours de formalisation.

13. Projet « credit scoring » Une étude préliminaire a été réalisée l’an dernier par des étudiants de Polytech’Nice. Celle-ci peut être poursuivie dans le cadre d’un nouveau projet d’étude. A partir de l’existant, les étudiants devront répondre aux besoins suivants Besoin #1 benchmark des outils « credit scoring »microfinance : faire une liste la plus exhaustive et détaillée possible des outils, méthodes, matrices de credit scoring adaptés à la microfinance (livrable 1). A partir de cette documentation, fournir un benchmark des outils et des recommandations sur les solutions les plus pertinentes (livrable 2) Besoin #2 Modèle mathématique : Une fois la solution la plus pertinente choisie avec l’équipe Octopus, développer le modèle mathématique correspondant et fournir un rapport détaillé sur ce modèle et le moyen de l’implémenter dans Octopus (livrable 3). Besoin #3 Tester le modèle : A partir du modèle mathématique, fournir un jeu de tests avec les principaux cas possibles et les résultats attendus en conséquence (livrable 4) Besoin #4 intégrer les informations manquantes à Octopus : A partir des livrables 2 et 3, lister les informations déjà présentes dans Octopus, et indiquer la liste des informations manquantes pour établir (livrable 5). Intégrer les nouveaux champs nécessaires dans la GUI d’Octopus Besoin #5 Développer le module : développer le module de calcul de Scoring et l’intégrer à Octopus. Tester le modèle à partir du jeu de tests.

14. Contraintes du projet Contrainte #1 travail à distance : notre principal centre de développement est à Bishkek, Kirghizstan. Les RDV réguliers de suivi de projet et de rendu des livrables se feront par Skype. Les démonstrations pourront se faire en remote-control. Les développements se feront en SVN sur notre serveur de développement. Contrainte #2 livrables en anglais : a minima, les livrables techniques devront être rendus en anglais. Le suivi du développement sera supervisé exclusivement en anglais. La partie définition du projet et choix du modèle mathématique pourra se faire en français. Contrainte #3 Développement C# / environnement .Net : Octopus est entièrement développé en C#, les étudiants devront être familiers avec l’environnement .Net pour pouvoir développer correctement le module de Credit Scoring.

15. Contact : Yoann GUIRIMAND Octopus Business Developer 33, rue Godot de Mauroy, 75009 PARIS, France yoann@octopusnetwork.org skype : yoann.guirimand

16. Editeurs ISSOS : Christine BALLESTER, Denis Bonavida - Sophia – jeudi 9 décembre Sungard Services (ex Cadextan) : maud.medard@sungard.com attend les cv ATOS WORDLINE : Philippe BESSIS Philippe.BESSIS@atosorigin.com ThomsonReuters  Sandrine.lancet@thomsonreuters.com ; vendredi 7 janvier Murex – pas de réponse Wall Street Systems cf M Akre IBM : Laurence Gauvin, laurence.gauvin@fr.ibm.com (10 décembre pour l’instant) Quid stage en sécurité SSII : pas de réponse Lunalogic Teamtrade Maltem Banques Société Générale Calyon Cfm Bnp Sites http://www.dogfinance.com/ Mathfi International Singapour : philippe.anselmevatin@gmail.com Angleterre auguste_nguetsop@hotmail.com Stages : entreprises contactées –

17. Recommandations pour la soutenance et le rapportProjet Carnet d’ordres • Sur la partie Génie Logiciel et UML vous serez jugés sur • Cas d’utilisation et scénarios – pour la soutenance dites ce qui marche • Collaborations et Diagrammes de séquence • Diagrammes de classes • Diagramme états transition d’un ordre • Diagramme de déploiement • Gestion de projet : diagramme de Gantt – rapports d’activités – gestion de versions • Tous ces éléments doivent figurer dans le rapport • pour la soutenance , faire impérativement une intro au sujet – montrer impérativement un diagramme de séquence mettant en scène une page jsp, une servlet – un objet java – la base de données • Sur la partie BD vous serez jugés sur • Modèle ORM – modèle logique de données – DDL • Explications techniques : choix des clés, rafraichissement, session….. • Démo • Tous ces éléments doivent figurer dans le rapport, • pour la soutenance on veut voir le modèle logique de données et les explications techniques. • La démo doit clairement suivre un scénario. • Recommandations pour la soutenance • Vos noms sur la première page et en pied de page • Numéros de diapos sur chaque page